Blog personal de Jacob Fernández

Hoy he leído una noticia bastante interesante acerca de una denegación de servicio en Apache. Tal y como dice la noticia original existe multitud de código que permite explotar este problema.

Cuando se inicia la conexión el servidor espera a las cabeceras enviadas por el cliente. Después de enviar parte de la cabecera legítima, éste (DoSer) envia unas cabeceras especialmente manipuladas que provocan que el servidor no finalice la conexión y permanezca a la espera de las demás partes de la cabecera. Para poder mandar la cabecera que “mantiene al servidor a la escucha” en la cabecera legítima no se envia un CLRF final, sino que después de un tiempo se le envía la cabecera:

X-a: b\r\n
que provoca que el servidor siga aún esperando el resto de la cabecera al no estar finalizada a través de el CLRF que mencionamos anteriormente. Debido a que este ataque se puede realizar moviendo un volumen pequeño de datos como bien apunta la fuente original cualquier usuario con un ancho de banda mínimo podría explotar esta vulnerabilidad en servidores con un ancho de banda relativamente grande.

Si habéis pensado en el parámetro MaxClients lo que hará será incrementar las necesidades de ancho de banda y CPU de los atacantes. Según Tomasz Miklas es posible bloquear este tipo de ataques usando un proxy inverso como PerlBal usándolo delante del servidor con Apache

Apche 1.x y 2.x están afectadas, así como Squid.

[ad]

Quizás muchos de vosotros ya sabéis el problema que os voy a comentar a continuación. A través del blog de F-Secure me llega una noticia un tanto curiosa. Seguramente recordáis la problemática de las extensiones en muchas de las versiones del sistema operativo de Microsoft. Si alguien ponía una extensión del tipo .TXT.EXE aparentemente en el explorador se podía ver el iconito como si fuera realmente un archivo de texto, cuando no es así. Si alguien no tenía activado ver las extensiones completamente (la mayor parte de los usuarios de este sistema operativo) podría ‘caer en la tentación’ de abrir el fichero y fiarse de él además porque se supone que sería un fichero de texto.

Pues vien, la historia se repite. Haz click aquí para ver las imágenes en la web de F-Secure.

[ad]

Según Symantec, el nuevo gusano Conficker (Downup, Downadup, Kido) es el malware más complejo realizado hoy día. Según varios datos, ha llegado a infectar casi 9 millones de máquinas a través de una vulnerabilidad en Windows (más información también aquí) a través de la cual enviando una petición RPC determinada el atacante podría ejecutar código sin autenticación con la máquina atacada, pudiendo tomar el control total de la máquina.

Por lo visto existen más de 30 variantes de este simpático malware corriendo por internet, aunque algunas de ellas tengan diferentes nombres entre las compañías antivirus y sean las mismas. Según Eric Chien, la motivación de los creadores de malware está pasando a ser más monetaria que motivacional en el sentido de mientras más máquinas infecte, mejor.

Cada día se generan hosts (dominios) de donde Conficker recoge información y se actualiza. Se está investigando estos nombres de dominio, así como su titular, para poder darlos de baja rápidamente y así no ayudar a su rápida proliferación.

Por si fuera poco también posee un potente sistema P2P con el cual cada máquina infectada está conectada con las demás (como cualquier programa de descargas, véase Emule, uTorrent, etc) y con las cuales puede intercambiar información. Grosso modo, funcionaría de la siguiente manera:

1. Intento del atacante, probando la vulnerabilidad RPC anteriormente citada.

2. El malware reconoce que es una máquina que está también infectada.

3. La máquina víctima “le pide” información nueva si está disponible de Conficker.

4. La máquina atacante envía nuevos datos a la víctima.

5. Los datos nuevos recibidos son ejecutados en la máquina víctima.

A lo largo de este proceso, Conficker no sólo parchea la vulnerabilidad de RPC, sino que lo hace para que las máquinas que están infectadas se conozcan entre ellas para sincronizarse. Conficker es capaz de analizar el shellcode que recibe y revisa si concuerda con el que actualmente tiene. Si coincide, se extrae información de ésta para que la máquina víctima del ataque permita la conexión a través del protocolo HTTP, con un puerto seleccionado aleatoriamente.

Todo este mecanismo permite a resumidas cuentas verificar a Conficker si necesita actualizarse a través de otra máquina infectada. Esta información se guarda en el registro lo que permite a las demás máquinas infectadas que pidan información, conectarse y además que los datos permanezcan entre reinicios de la máquina. Por si fuera poco, también los guarda en el disco duro.

Información: Symantec, Peter Coogan (Symantec).

[ad]