Ayer por la tarde me llevaron a la oficina un servidor que estaba alojado en SICOM (http://www.sicom.edu.mx), este servidor pertenece a una empresa llamada IDSCorp (¿¿??). Los detalles de la razón por la cual el servidor de una empresa se encuentra alojado y utilizando recursos de una dependencia del gobierno del estado de Puebla (México) (http://www.puebla.gob.mx) me resultan obscuras y no trataré de esclarecerlos.
El hecho es que este servidor marcaba un Kernel Panic durante el proceso de arranque.
Obviamente se trata de una máquina con GNU/Linux, y para ser precisos, RedHat versión 9. Ante este escenario lo más lógico pensar era que el administrador o "alguien" había recompilado el kernel y habría hecho algo indebido o bien que simplemente se habían puesto a jugar con el archivo de configuración del grub. Pues bien, lo más lógico era entrar con un disco de rescate de esa distribución en particular y de ahí tratar de rienstalar el kernel o bien los paquetes que fieran necesarios.
¡Oh sorpresa! el rpm no funciona, es decir, al menos responde un rpm -q, pero con todo lo demás simplemente manda un error. Visto esto, es muy probable que rpm esté simplemente troyaneado (de la misma forma que yo troyaneé anteriormente ps, w, finger, who y algunas cositas más). En eso se me ocurrió ejecutarle un init 1 (es decir, cambiar al nivel de administración del servidor) a ver si algo respondía e imagínense mi cara cuando descubrí que el problema era que tenían un backdoor instalado llamado suckIT (Una excelente chat-conferencia sobre los backdoors la pueden encontrar en: http://umeet.uninet.edu/umeet2003/spanish/talks/20031219.3.es.html).
El problema radicaba en que después de la instalación de este rootkit cualquier comando ejecutado en el sistema simplemente causaba y un error de instrucción no válida en el procesador y la consecuente caída del sistema, lo cual me impedía llevar a cabo un trazado del proceso que estaba ejecutando el mentado rootkit. El hecho es que como este juguetito suele "esconder" sus huellas, es decir, esconde los procesos que utiliza, resulta difícil de hallar para un ojo no experimentado.
Una muy breve descripción de suckIT sería: "SucKIT is a rootkit presented in Phrack issue 58, article 0x07 ("Linux on-the-fly kernel patching without LKM", by sd & devik). This is a fully working rootkit that is loaded through /dev/kmem (i.e. it does not need a kernel with support for loadable kernel modules. It provides a password protected remote access connect-back shell initiated by a spoofed packet (bypassing most of firewall configurations), and can hide processes, files and connections.". El detalle es que al momento no esta disponible la página de phrack, pero el link original del artículo es: https://www.phrack.com/show.php?p=58&a=7
Total, como al final me desesperó que no podía hallar el mentado código opté por la reinstalación y recuperación del sistema. Proceso que me llevó algo de tiempo pero finalmente rindio frutos.
Un análisis forénse un ataque similar está muy bien documentado en (http://www.seguridad.unam.mx/eventos/reto/nueve_tecnico.pdf), por lo que recomiendo su lectura y análisis posterior.
Las moralejas del cuento son varias:
Como mencioné se trataba de un RedHat 9, es decir, una instalación vieja sin actualizar.
Por consecuencia los paquetes instalados como MySQL eran ya muy viejos pues traía una versión 3. y pelos, el PHP era versión 4 aún y el apache aunque ya era de la serie 2.0.X de todos modos ya no era muy buena que digamos.
Por otro lado, el amdinistrador dejó mucho que desear puesto que al preguntarle varios datos respecto a la configuración de red del sistema pues simplemente no supo.
El Servidor estaba tomado por un grupo brasileño desde hacía ya algunos meses y la administración pensó que instalando un firewall se iban a arreglar los problemas.
En pocas palabras, se trataba de un servidor auto administrado.. cuyo fin fue la reinstalación.
No hay comentarios.:
Publicar un comentario