AVISO: Nos hemos integrado con Facebook y Twitter. Ahora, podrás decir si te gusta o no uno de nuestros artículos con tu usuario de la red social. También podrás difundir los artículos que más te gusten a través de cualquier medio. Ayúdanos a que los artículos sean más interesantes dándonos tu opinión. Gracias.

miércoles, 17 de julio de 2013

Riojaparty 2013 y juegos de hacking

Este año, como no podía ser de otra manera, IBERDAT ha colaborando con la party regional RIOJAPARTY2013. En esta ocasión se realizaron charlas muy interesantes y de muy diversa temática.

Hubo charlas de IDS del compañero Jesús José Jimenez (Alias Chus) y así como charlas sobre impresión digital 3D o sobre posicionamiento web.

Nuestra charla se centró en el aprendizaje de la metodología de como se desarrolla un ataque y las medidas que se pueden utilizar para mitigar los riesgos.

En este certamen no nos quisimos quedar solamente en la participación en la charla, sino que participamos "off the record" en la prueba de Hacking que preparó Chus. Siempre nos ha gustado jugar con estas cosas y más con algo que nos supone un pequeño reto. ;-)

Si bien en la Party no hubo ningún ganador, aunque sabemos de buena tinta que se quedaron muy cerca de conseguir el premio, vamos a aprovechar para publicar la prueba con permiso de Chus. Eso si, hemos añadido un pequeño incentivo para los que superen la prueba.

Aquellos que consigan superar el reto, se les enviará por correo electrónic el pequeño obsequio que conseguirán.

Os animamos a que participéis. Esta será el primer challenge de IBERDAT, pero seguramente no será el último.

Aquí os dejo los dos links que necesitáis para poder acceder a la prueba:

Link con los ficheros: Haz click aquí
Link para comprobación: Haz click aquí

Ánimo a los que queráis participar. Si tenéis cualquier pregunta o duda, podéis comentar en esta entrada del blog.

viernes, 14 de junio de 2013

Ataque masivo contra hostings con Plesk

Hace mucho tiempo que no escribía en el blog por falta de tiempo, pero después de lo de hoy, vamos ha hacer un recomienzo para avisar a los usuarios de hosting con plesk que hayan sido víctimas de un ataque y que pasos deben seguir para solucionar el tema.

Iniciemos esta historia con un correo de un cliente que había recibido de su servidor de hosting diciéndole que su máquina había sido detectada como participante en un ataque DDOS. A causa de esto, el proveedor apagó la máquina no dando acceso ni a través de consola, ni a las web del cliente ni a nada. Asustado, me envió inmediatamente el correo y comenzamos con el tema.

En primer lugar, hay que conseguir que el proveedor nos de acceso a la máquina. Tras 2 llamadas y un correo del cliente a su proveedor, conseguimos que enciendan la máquina y nos den acceso por SSH.

En nuestra cabeza ya nos esperábamos lo peor. Así que, lo primero que hicimos es planificar un poco los pasos a dar una vez dentro para coger evidencias lo más rápido posible.

Empezamos lanzando los típicos comandos: last (para saber si había habido accesos de usuarios no controlados), netstat -na (para ver las conexiones), un ps -ef, un iptables -L -n y empezamos ha hacer una copia de los discos duros a un servidor de la empresa con dd.

Lo primero que nos encontramos curioso fue lo siguiente:

Proto Recv-Q Send-Q Local Address Foreign Address State 
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 
tcp 0 0 0.0.0.0:65533 0.0.0.0:* LISTEN 
tcp 0 0 82.xxx.xxx.xxx:48470 212.117.168.16:4042 ESTABLISHED 
tcp 0 0 :::22 :::* LISTEN 
tcp 0 680 ::ffff:82.xxx.xxx.xxx:22 ::ffff:83.YYY.YYY.YYY:1152 ESTABLISHED 
tcp 0 0 ::ffff:82.xxx.xxx.xxx:22 ::ffff:83.YYY.YYY.YYY:64220 ESTABLISHED udp 0 0 0.0.0.0:68 0.0.0.0:*

Las conexiones al puerto 22 eran nuestras, pero claro, ¿y la del puerto 48470? No es un puerto que esté en escucha, por lo que es una conexión desde la máquina hacia ese servidor al puerto 4042. Buscando en google no encontramos nada acerca de ese puerto, así que vamos a ver que proceso está corriendo ese servicio:

$netstat -tupn |grep 4042 

tcp 0 0 82.xxx.xxx.xxx:48470 212.117.168.16:4042 ESTABLISHED 4976/kupdated

Hmm, ¿un proceso kupdated? Bueno, veamos a ver quien lo ejecuta y donde está. Para eso vemos los procesos (ps -ef):

apache 4963 1 0 13:34 ? 00:00:00 [kjournald] 
apache 4976 1 0 13:34 ? 00:00:00 [kupdated]

Esto ya empieza a ser ampliamente sospechoso. Que aparezcan entre corchetes indica que no se puede localizar ningún argumento para este proceso. Aparte, está lanzado con el usuario apache. Ya tenemos un primer punto para eliminar de la máquina. Así que viendo que no es del sistema, les hacemos un kill. Para nuestra sorpresa, al cabo de 30 segundos vemos que vuelven a aparecer. ¿pero cómo?

Nos revisamos la lista de procesos entera y no vemos ninguno que esté corriendo con el usuario apache u otro usuario que nos resulte sospechoso. Así que empezamos a mirar hacia el cron. Para ver todo lo que está en el cron lanzamos el siguiente comando:

for user in $(cut -f1 -d: /etc/passwd); do echo $user; crontab -u $user -l; done

De esta manera no se nos escapa uno. Entre otras cosas vemos lo siguiente:

Usuario apache 
*/2 * * * * /var/tmp/.tmp/kupdatedb >/dev/null 2>&1 
*/2 * * * * /var/tmp/.tmp/httpscron >/dev/null 2>&1

Ya sabemos quien ejecuta este proceso, y no solo eso, también sabemos donde está el ejecutable. No pueden ser otros, así que hacemos la prueba, comentamos el crontab del usuario apache y comentamos las entradas. Después volvemos a matar los procesos y.... perfecto, ya aparecen muertos y bien muertos. Primera parte conseguida. Ahora vamos a ver desde cuando estaban ahí. Para eso vamos al directorio en cuestión y vemos que hay:

httpscron
httpscron.o
kupdatedb
kupdated.o
ppp

Así que realizamos un "stat" de los ficheros

File: `httpscron' 
Size: 38726 Blocks: 80 IO Block: 4096 regular file
Device: 306h/774d Inode: 369216247 Links: 1
Access: (0755/-rwxr-xr-x) Uid: ( 48/ apache) Gid: ( 48/ apache)
Access: 2013-06-13 13:51:54.161672812 +0200
Modify: 2009-01-21 09:39:48.000000000 +0100
Change: 2013-06-12 00:04:43.157937112 +0200

File: `httpscron.o'
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: 306h/774d Inode: 369216249 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 48/ apache) Gid: ( 48/ apache)
Access: 2013-06-13 13:54:05.782149114 +0200
Modify: 2009-01-21 09:39:48.000000000 +0100
Change: 2013-06-12 00:04:43.157937112 +0200

File: `kupdatedb'
Size: 169 Blocks: 8 IO Block: 4096 regular file
Device: 306h/774d Inode: 369216245 Links: 1
Access: (0777/-rwxrwxrwx) Uid: ( 48/ apache) Gid: ( 48/ apache)
Access: 2013-06-13 13:53:20.435248789 +0200
Modify: 2013-06-13 13:38:01.044331226 +0200
Change: 2013-06-13 13:38:01.052346996 +0200

File: `kupdated.so'
Size: 5 Blocks: 8 IO Block: 4096 regular file
Device: 306h/774d Inode: 369216246 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 48/ apache) Gid: ( 48/ apache)
Access: 2013-06-13 13:54:16.891624290 +0200
Modify: 2013-06-13 13:38:01.056283701 +0200
Change: 2013-06-13 13:38:01.056283701 +0200

File: `ppp'
Size: 55046 Blocks: 112 IO Block: 4096 regular file
Device: 306h/774d Inode: 369216248 Links: 1
Access: (0755/-rwxr-xr-x) Uid: ( 48/ apache) Gid: ( 48/ apache)
Access: 2013-06-13 13:54:27.337974959 +0200
Modify: 2009-01-21 09:39:48.000000000 +0100
Change: 2013-06-12 00:04:43.157937112 +0200
Bueno, con esto ya podemos empezar a investigar cuando se ha producido el acceso. Más o menos tendríamos que investigar la siguiente fecha: 2013-06-12 00:04:43. Pues ale, a por los logs, a ver si no tardamos mucho. Habrá que revisarse, siendo del usuario apache estos procesos, sobre todo los del servidor web.

Tras una revisión con el grep (vamos a acelerar las cosas), nos encontramos lo siguiente en el fichero de acceso:

188.138.91.103 - - [12/Jun/2013:00:04:42 +0200] "POST /%70%68%70%70%61%74%68/%70%68%70?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%6E HTTP/1.1" 200 62 "-" "Mozilla/5.0 (compatible; Googlebot/2.1;" (82.xxx.xxx.xxx)

En el fichero de error nos encontramos esto otro:

[Wed Jun 12 00:04:42 2013] [error] [client 188.138.91.103] ppp: Text file busy 
[Wed Jun 12 00:04:42 2013] [error] [client 188.138.91.103] httpscron: Text file busy

Pero, ¿qué ha lanzado al servidor web? Viendo la codificación solo tendremos que darle la vuelta así que buscamos una página que nos permita hacer esto de manera online que no queremos ponernos a realizar un perl para hacer esto. No estamos para perder tiempo ;-)

Si decodificamos la petición vemos lo siguiente (lo podéis hacer aquí):

/phppath/php?-d+allow_url_include=on+-d+safe_mode=off+-d+suhosin.simulation=on+-d+disable_functions=""+-d+open_basedir=none+-d+auto_prepend_file=php://input+-n

Vale, ya la hemos fastidiado. ¿De donde sale ese path "phppath"? Vamos a la configuración del servidor web y nos encontramos que tenemos un fichero llamado php_cgi.conf con lo siguiente:

scriptAlias /phppath/ "/usr/bin/" 
Action php-script /phppath/php-cgi

Pero, pero, ¿A quién se le ha ocurrido poner esto ahí y mapearlo contra el directorio "/usr/bin"?. Bueno, aquí se abren dos vías de actuación:
  1. Saber desde cuando están entrando a través del phppath y que han hecho en la máquina
  2. Saber quien ha introducido este alias en el servidor web y cuando.
  3. Saber que hace el software introducido.
Para la primera parte hay que seguir buscando en los logs y aquí el trabajo ya es un poco más manual.
Para la segunda solo tenemos que googlear un poco: http://kb.parallels.com/en/116241

El cliente ha sido víctima de una vulnerabilidad 0-days a través de un error de Plesk de parallels que ya dispone de parche.
Como curiosidad comentar que hemos realizado un pequeño análisis preliminar y los ficheros que se encontraban en el directorio /var/tmp/.tmp son un cliente IRC que está diseñado para realizar ataques DDOS. El código es público y se puede compilar.
Para no extenderme más, vamos a resumir los pasos que tienen que dar las personas afectadas:
  1. Eliminar del cron del apache las entradas existentes.
  2. Matar los procesos  [kjournald] y [kupdated].
  3. Descargarse el parche de Parallels y aplicarlo (aquí).
Acto seguido a esto, yo borraría cualquier elemento de Plesk, pero eso ya es otra historia. Ni que decir tiene que los ficheros malignos deberían ser también eliminados. No solo los que he comentado más arriba sino también el siguiente: /var/tmp/.dildo (Está claro que cuando nos la quieren colar lo hacen ;-))
Espero que tengáis suerte y no os hayan cerrado vuestro Hosting.