Tal como vimos en la entrada anterior, estamos intentando contrastar la información respecto a un fallo de seguridad en el FTP del IIS. Nos hemos dado cuenta de que tras ejecutar el exploit en todas sus versiones, no ha funcionado pese a ejecutarse sin fallos.
Revisando los logs del ftp, comprobando el tráfico con el tcpdump, y revisando el código del exploit seguíamos sin saber el motivo por el cual éste no funcionaba. La última opción que nos faltaba era usar el ollydbg con el inetinfo.exe, así como todo aquel programa que tenga relación con el FTP e intentar averiguar por qué el exploit fallaba. Pero lógicamente esto requería de un tiempo del que no disponíamos.
Analizando los motivos por el cual era posible que el exploit no funcionara decidimos realizar una maqueta lo más real posible. Instalamos un windows sobre una máquina física y conectamos a ésta otra máquina física que sería la máquina atacante. Pero el resultado fue el mismo: el exploit no funcionaba.
Analizando de nuevo el código, nos dimos cuenta que había direcciones estáticas, en concreto esta:
$retaddr = "\x9B\xB1\xF4\x77";
Esto nos hizo pensar que posiblemente esa dirección funcionara únicamente para la versión de Windows que tuviese el creador del exploit, la que resultó ser ni más ni menos que un windows 2000 pero en INGLÉS. Efectivamente, instalamos una versión en ingles sobre una máquina virtual para intentarlo de nuevo, y esta vez sí, el exploit funcionó concediendo una shell en el sistema atacado con permisos de usuario SYSTEM:
Esto confirmaba nuestras sospechas: el motivo del fallo en la ejecución del exploit era a causa de que éste toma las direcciones estáticas pensadas para funcionar sobre un windows en ingles. Lógicamente, si pensamos apilar la palabra “hello“, ésta requiere de 5 bytes mientras que la palabra “hola” requiere de 4 bytes, por lo que es muy posible que la dirección no fuera la misma en la versión en castellano.
Para terminar de confirmarlo pensamos en qué usuarios que no fueran de habla inglesa habrían buscado cual era la dirección correcta para ejecutar el exploit en sus sistemas. Me vinieron rápidamente a la cabeza los alemanes, así que me decidí a realizar búsquedas en foros alemanes que trataran el tema y por fin lo localice. Un usuario había publicado una variante del exploit para aquellas versiones de Windows en alemán, y tal como pensábamos, únicamente había que modificar la dirección del “retaddr”.
Por tanto, la vulnerabilidad existe, es un zero-day —ya que el creador del exploit no notificó al fabricante—, no hay todavía parche que la solucione y lo más importante, los sistemas en castellano si son vulnerables; lo único que el atacante debe hacer es modificar el retaddr del exploit por el que toca para entornos en castellano.
Entonces, ¿es una alerta grave? Si se cumplen los requisitos es gravísima, pero seamos sinceros, ¿qué administrador de sistemas concede permisos de escritura a usuarios anónimos o otros usuarios genéricos que no tengan contraseña? (alguno dirá que muchos, pero yo no llamaría a esos “administrador de sistemas”).
Donde reside realmente el problema de esta vulnerabilidad es en aquellos usuarios, que aunque protegidos con contraseñas, tengan permisos de escritura en el ftp. Si el atacante mediante diversos medios consigue obtener la contraseña del ftp del usuario podrá obtener una shell en el servidor. Teniendo en cuenta que las contraseñas del ftp se transmiten en texto plano, y que los usuarios por naturaleza no suelen tener excesivo cuidado en cuanto a la seguridad de sus máquinas personales, esta vulnerabilidad se convierte en un fallo de seguridad importante.
¿Solución? Pues hasta que salga el parche correspondiente para esta vulnerabilidad, la solución no es otra que revocar permisos de escritura a todos los usuarios, y emplear otros medios para subir los datos al ftp. De esta forma, todas las aplicaciones que dependan de la lectura de datos del ftp seguirán funcionando. Es algo “estricta”, pero si alguno de ustedes tiene una idea mejor, por favor que la indique en los comentarios.
