Análisis del gusano "Code Red II"
[07-08-01]
Durante las últimas horas, ha aparecido una mutación del gusano "Code Red" especialmente peligrosa cuyo único parecido con la versión original es el mecanismo de propagación. Una de las características de esta nueva mutación es el abrir diversas puertas traseras en la máquina infectada.
Este nuevo gusano fue detectado por primera vez durante la tarde del pasado 4 de agosto. En este artículo hacemos un resumen de los diferentes análisis en profundidad realizado al código del virus.
Vulnerabilidad explotada
Esta variante del gusano utiliza el mismo mecanismo de la versión original de "Code Red" para infectar los servidores vulnerables. Es decir, el gusano busca servidores con Internet Information Server (IIS) a los que no se ha instalado la actualización necesaria para solucionar el desbordamiento de memoria intermedia existente en IDQ.DLL o bien no se han eliminado los mapeos de los scripts ISAPI. Para más información sobre esta vulnerabilidad, podéis consultar los boletines que en su día emitió Hispasec: [1] y [2].
Excepto en el mecanismo de infección utilizando este desbordamiento de memoria intermedia para ejecutar el código del gusano en el servidor vulnerable, el resto del gusano es totalmente nuevo y muy diferente de las diversas variedades de "Code Red" conocidas hasta la fecha (Code Red CRv1 y Code Red CRv2). [3]
---
Nota: Según el estudio de eEye, el código de este gusano sólo funciona correctamente en los sistemas Windows 2000 que tengan una versión vulnerable de IIS. Los servidores basados en Windows NT simplemente quedarán colgados en el momento de ejecutar el código del gusano. Los experimentos que hemos realizado, así como los comentarios de otros analistas parecen demostrar este punto.
---
Puerta trasera
La característica más peligrosa de este nuevo gusano es hecho que crea una puerta trasera (backdoor) en los servidores infectados, dejándolos por tanto a la merced de cualquier atacante.
El gusano copia el archivo %windir%\CMD.EXE en los siguientes directorios:
c:\inetpub\scripts\root.exe
c:\progra~1\common~1\system\MSADC\root.exe
d:\inetpub\scripts\root.exe
d:\progra~1\common~1\system\MSADC\root.exe
La instalación de estas copias de CMD.EXE permite a cualquier atacante ejecutar órdenes arbitrarias del sistema en la máquina comprometida.
Además, el gusano crea una copia modificada del EXPLORER.EXE, tal como describiremos más adelante. Si se utiliza esta versión modificada, IIS hará que los directorios raíz de las unidades C: y D: del servidor sean accesibles para cualquier atacante remoto, incluso si el programa ROOT.EXE (CMD.EXE) ha sido borrado de los directorios SCRIPTS y MSADC.
Versión modificada de EXPLORER.EXE
El gusano transporta su propia versión del archivo EXPLORER.EXE y se encarga de copiarla en los directorios C:\ y D:\. El hecho que sea copiado en estos directorios hace que Windows los encuentre y ejecute con preferencia a la versión real de EXPLORER.EXE, debido a la forma en que Windows busca los archivos ejecutables.
Si no se ha instalado la actualización que elimina la vulnerabilidad de las vías de acceso relativas, la próxima vez que un usuario abra una sesión en el sistema se ejecutará esta versión modificada de EXPLORER.EXE (para más detalles sobre esta vulnerabilidad y la actualización publicada por Microsoft, se pueden consultar [4] y [5].
Cuando se ejecuta esta versión modificada de EXPLORER.EXE, el gusano se encarga de ejecutar la versión autentica del programa de forma que el usuario no advierte ningún problema. A continuación, inicia a modificar el contenido del registro del sistema.
En primer lugar, añade a HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\WinLogin el valor SFCDisable=0xFFFFFF9D. Con esto deshabilita completamente el mecanismo de protección de archivos de Windows (Windows File Protection, WFP). WFP es quien se encarga de prevenir la sobreescritura de determinados archivos del sistema. Para más detalles acerca de WFP, consultar [6].
El segundo paso es la modificación de una serie de directorios virtuales dentro del registro:
- Asigna a SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\VirtualRoots\cript el valor ",,217"
- Asigna a
SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\VirtualRoots\msadc el valor ",,217"
El valor "217" indica que tanto el directorio SCRIPTS como el directorio MSADC (en donde, recordemos, se ha copia el archivo ROOT.EXE, una copia de CMD.EXE) tienen permiso de lectura, escritura y ejecución.
Por último, la versión modificada de EXPLORER.EXE crea dos directorios virtuales nuevos:
- Crea
SYSTEM\Current\ControlSet\Services\W3SVC\Parameters\Virtual Roots\c
con el valor "c:\,,217"
- Crea
SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\Virtual Roots\d
con el valor "d:\,,217"
Estos dos directorios virtuales, que habitualmente no existen, permiten acceder remotamente a los directorios raíz de las unidades C: y D: mediante el servidor web, con permisos de lectura, escritura y desarrollo.
---
Nota: Según el análisis de eEye, el objetivo de estos directorios virtuales es permitir la instalación de una puerta trasera en el sistema incluso cuando el archivo ROOT.EXE ha sido borrado del directorio /scripts. El atacante puede continuar comprometiendo el sistema con un ataque como este:
http://IP/c/inetpub/scripts/root.exe?/c+dir
(Si root.exe continua en el directorio scripts)
http://IP/c/winnt/system32/cmd.exe?/c+dir
(Donde "dir" puede ser cualquier orden que desee ejecutar el atacante).
---
Es importante indicar que hay suficiente con ejecutar una única vez la versión modificada del EXPLORER.EXE para que se realicen estos cambios en el sistema. Desde el momento en que se hagan estas modificaciones y se reinicie IIS, las puertas traseras estarán activas. Es más, éstas continuaran activas con independencia de si EXPLORER.EXE está funcionando o no.
Incluso, el hecho de detener el proceso de la versión modificada de EXPLORER.EXE no elimina las puertas traseras. Detener EXPLORER.EXE y borrar las copias de ROOT.EXE, así como borrar las entradas del registro *tampoco* eliminan las puertas traseras. En el momento en que vuelva a ejecutarse la versión modificada de EXPLORER.EXE (por ejemplo, cuando un nuevo usuario accede al sistema) se volverán a realizar los cambios en el registro y por tanto los directorios estarán de nuevo accesibles desde el exterior desde el mismo momento en que se reinicie el IIS (Para más detalles acerca de los directorios virtuales de IIS se puede consultar [7]).
Como consideración final, debe indicarse que el borrar las entradas del registro, borrar las copias de ROOT.EXE y borrar la versión modificada de EXPLORER.EXE puede no ser suficiente para limpiar un sistema infectado. Desde el momento en que existe una puerta trasera en el sistema, hay la posibilidad más que real de que un atacante instale otras puertas traseras que no estén relacionadas de ninguna forma con este gusano.
El proceso de la versión modificada de EXPLORER queda suspendido la mayor parte del tiempo, aunque cada diez minutos comprueba los valores de las variables modificadas en el registro. De esta forma, si un administrador de la máquina detecta los cambios y los borra, el gusano se encargará de restaurar estos valores a los pocos minutos.
Propagación
El método utilizado por el gusano varia en función de si el idioma chino está instalado en la máquina víctima. Si lo está, el gusano lanzará 600 threads que intentarán propagar el gusano a otros sistemas durante 48 horas.
Si el idioma chino no está instalado, el gusano lanza 300 threads y el periodo de propagación es de 24 horas.
Una vez transcurrido el periodo de propagación, el gusano fuerza una detención del sistema y su reinicio. De esta forma, el gusano desaparece de la memoria del ordenador, aunque las puertas traseras continuan activas.
Esta versión del gusano envía un paquete ligeramente diferente al atacar una máquina:
GET /default.ida?XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%
u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b0
0%u531b%u53ff%u0078%u0000%u00=a HTTP/1.0" 200 152 "-" "-"
Selección de víctimas
Los threads utilizados para la propagación (300 ó 600) funcionan de forma simultánea. Cada uno de ellos selecciona una dirección IP de forma aleatoria y a continuación aplica una de las siguientes máscaras
de red con un índice de probabilidades. Esto hace que la propagación del gusano se realice preferentemente en las máquinas con direcciones IP cercanas a las del ordenador infectado:
Máscara Índice Resultado
probabilidad
-------- ------------- -------------------
0.0.0.0 12,5% Dirección aleatoria
255.0.0.0 50,0% Dentro de la misma
clase A
255.255.0.0 37,5% Dentro de la misma
clase B
Las direcciones IP de las clases 127.x.x.x y 224.x.x.x son excluidas, así como las direcciones 0 y 255 de cada red. Tampoco intenta infectarse él mismo.
Proceso de infección
Antes de realizar una conexión a una posible nueva víctima, el gusano realiza una comprobación de la fecha del sistema: si el año es inferior al 2002 y el mes anterior a octubre. Sino se cumple alguna de estas dos condiciones, el gusano finaliza su ciclo de propagación y reinicia el servidor. Esto significa que el gusano dejará de propagarse el próximo 1 de octubre del presente año.
En vistas a mejorar el rendimiento, el gusano utiliza un socket sin bloqueo para conectar con la posible víctima. Como consecuencia, si un thread queda e la espera de la respuesta debido a una conexión lenta, esto no afectará al resto de threads.
Una vez finalizada la conexión TCP/IP con la posible víctima, el gusano envía todo el código a la vez y queda a la espera del acuse de recibo. A continuación, prueba de infectar a otra posible víctima.
Al llegar a una víctima, lo primero que comprueba el gusano es si la máquina ya ha sido infectada. En caso afirmativo, queda deshabilitado. La forma de comprobar la existencia consiste en determinar si se ha establecido el átomo CodeRedII mediante GlobalFindAtomA. Si encuentra la existencia de este átomo, queda en estado de suspensión. En caso de no existir, el gusano continua con su proceso normal de ejecución.
Opina sobre esta noticia:
http://www.hispasec.com/unaaldiacom.asp?id=1016
Más información:
[1] 18-06-01: Grave desbordamiento de búfer en todas las versiones de IIS http://www.hispasec.com/unaaldia.asp?id=967
[2] 19-07-01: Un nuevo gusano, .ida Red Code, ataca a los servidores IIS http://www.hispasec.com/unaaldia.asp?id=998
[3] 28-07-01: Alerta sobre una grave amenaza a Internet. Deben tomarse medidas antes del 31 de julio
http://www.hispasec.com/unaaldia.asp?id=1007
[4] 27-07-00: Vulnerabilidad "Relative Shell Path" en Windows NT y 2000 http://www.hispasec.com/unaaldia.asp?id=640
[5] Boletín de Microsoft sobre la vulnerabilidad de las vías de
acceso relativas
http://www.microsoft.com/technet/security/bulletin/MS00-052.asp
[6] Descripción de WFP (Windows File Protection)
http://support.microsoft.com/support/kb/articles/Q222/1/93.ASP
[7] Installing Web sites
http://www.avdf.com/jan98/art_ot001.html
Versión desensamblada del gusano y de la versión modificada de
EXPLORER.EXE
http://www.eikon.tum.de/~simons/ida_root/
Análisis de eEye y versión desensamblada del gusano
http://www.eeye.com/html/advisories/coderedII.zip
Versión binaria del gusano
http://www.unixwiz.net/techtips/CodeRedII.html
Análisis de CoreCode
http://archives.neohapsis.com/archives/incidents/2001-08/0092.html
Análisis de NAI
http://vil.nai.com/vil/virusChar.asp?virus_k=99177
Análisis de SecurityFocus
http://archives.neohapsis.com/archives/bugtraq/2001-08/0066.html
Versión en catalán de esta noticia
http://www.quands.com/alertes/html/code-red-ii.html
Xavier Caballe
xcaballe@quands.com
Artículos de actualidad ...
Archivo de artículos ...
|
