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\Virtual Roots\cripts
el valor “,,217”
– Asigna a
SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\Virtual Roots\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 probabilidad Resultado
——– ————- ——————-
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.
xcaballe@quands.com
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
Deja un comentario