Investigación de ataque a un WordPress

Introducción de un ataque a un WordPress

Hoy he tenido el placer de participar, por tercer año consecutivo, como ponente en la V WordPress Meetup Córdoba y al igual que en años anteriores, he disfrutado mucho, no solo durante mi charla (Investigación de ataque a un WordPress) sino durante toda la jornada, con charlas muy interesantes en dos tracks diferentes. ¡Lástima haberme perdido algunas de las charlas! Pero en dos tracks a la vez no se podía estar.

En cuanto a mi charla, se trataba de explicar un caso real de un ataque a un WordPress y dar algunos consejos prácticos y sencillos para poder hacer algunas labores de investigación en caso de sufrir un ataque.

La Web investigada había sufrido un ataque mediante el cual los atacantes habían conseguido subir una puerta trasera, en forma de una C99 Shell, aprovechando una vulnerabilidad de tipo “Remote Arbitrary File Upload” en un plugin del WordPress.

Como consecuencia, el servidor comprometido pasó a formar parte de la StealRat Botnet enviando una gran cantidad de spam con contenido variado; venta de productos farmacéuticos, venta de viagra y pornografía. Este envío masivo de spam originó que el servidor entrara en listas negras de reputación IP así como en servicios de bloqueo por spam.

Tras analizar el sistema de ficheros se descubrieron varios ficheros php con código malicioso ofuscado que fueron limpiados. En la siguiente imagen podemos ver uno de los ficheros infectados con código ofuscado

 A continuación se pueden ver algunos de los archivos maliciosos e infectados.

 La importancia del fingerprinting

La finalidad de la charla, y de este artículo, es de poder aportar un par de consejos prácticos para la localización de evidencias tanto del ataque como de los accesos anteriores de los atacantes rastreando el sitio Web con la intención de hacer un fingerprint del CMS (WordPress) y plugins instalados, entre ellos el plugin vulnerable.

Para esta tarea de descubrimiento de CMS utilizado y plugins instalados, es necesario que el atacante ejecute una serie de tareas. Existen muchas herramientas automatizadas que tienen como objetivo el descubrimiento del CMS, su versión, plugins y versiones de éstos.

Son varias las técnicas usadas por estas herramientas, desde una simple consulta a cabeceras HTTP en la respuesta del servidor, una consulta a etiquetas HTML (<meta name=”generator”…>) o la existencia del famoso readme.html en la raíz del sitio, hasta realizar “dirbusting” (descubrimiento de URL mediante fuerza bruta) para comprobar la existencia de un plugin en el WordPress.

La técnica más efectiva es la de dirbusting, pero también la que genera más “ruido” desde el punto de vista de seguridad. Un WAF, IPS o plugin de seguridad de WordPress podría aplicar un lockout tras un número determinado de accesos a recursos no existentes (error 404, not found).
¡Los archivos logs (error_log y access_log) sí son útiles!

Si nos centramos en analizar esos accesos no legítimos que intentan identificar nuestro WordPress y sus plugins deberíamos de apoyarnos en los registros de los sistemas que componen nuestra infraestructura Web. Si tenemos acceso a los logs del WAF o IPS, genial, pero si se trata de un servidor Web compartido a lo máximo que podemos aspirar es a los logs del propio servidor Web. Salvo que se trate de una incidencia grave y podamos solicitarle a nuestro proveedor de servicio de hosting los logs de sus sistemas de seguridad.

El fichero error_log nos aporta menos información que el access_log

 Sin embargo del access_log sí podemos extraer información importante y para ello vamos a hacer echar mano de los códigos de respuesta HTTP (2xx, 3xx, 4xx, etc.). Como sabéis estos códigos son devueltos por el servidor en función de si la petición es correcta, es incorrecta, hay alguna redirección o el recurso no está disponible, entre otras opciones. Lo habitual es que en el access_log veamos sobre todo respuestas del tipo 200 (OK), sin embargo si estamos siendo víctimas de un ataque de descubrimiento de plugins tendremos muchas respuestas del tipo 404 (not found) indicando que el recurso no está disponible.

 En la imagen anterior se ha hecho una búsqueda específica para mostrar sólo las respuestas que NO son código 200 (OK). Se puede observar como la IP en cuestión ha realizado varias peticiones a recursos no existentes (404) o a los cuales no tiene permisos para acceder (403).

Identificando y bloqueando estos tipos de ataques a tiempo, dificultaría al atacante poder lanzar posteriores ataques ya que no tendría información suficiente acerca de los plugins instalados y sus versiones.

Para finalizar, también podríamos prestar atención a peticiones no habituales, como por ejemplo aquellas que no sean del tipo GET o POST. En la siguiente imagen podemos ver peticiones realizadas con el método HEAD.

Como habéis podido observar, los archivos logs de nuestros servidores Web sí nos pueden aportar mucha información relevante a la hora de investigar una incidencia de seguridad en nuestro sitio Web, así como los códigos de respuesta HTTP o los métodos usados en las peticiones a nuestra Web

Como consecuencia, el servidor comprometido pasó a formar parte de la StealRat Botnet enviando una gran cantidad de spam con contenido variado; venta de productos farmacéuticos, venta de viagra y pornografía. Este envío masivo de spam originó que el servidor entrara en listas negras de reputación IP así como en servicios de bloqueo por spam.

Tras analizar el sistema de ficheros se descubrieron varios ficheros php con código malicioso ofuscado que fueron limpiados. En la siguiente imagen podemos ver uno de los ficheros infectados con código ofuscado

- See more at: http://hacking-etico.com/2015/11/21/investigacion-ataque-wordpress/#more-4766

Destapando el Phishing de Correos…por la mañana temprano.

Después del gran artículo de mi compañero .... en el que nos ilustra de como utilizar Python y Nmap para descubrir la red, hoy traemos este artículo recién cocinado e improvisado que explicamos a continuación. Os recomiendo totalmente, la “saga” que irá ampliando poco a poco “Descubriendo la red con Python y Nmap – Parte 1” y “Descubriendo la red con Python y Nmap – Parte 2“

Hace escasas horas, concretamente las 05:22 de la mañana, una hora muy prudencial, dónde las calles está cortadas e Internet apagado, le ha llegado a mi compañero Miguel Ángel Arroyo un correo que me ha reenviado posteriormente a mi cuenta para que le echara un vistazo.

Realmente, a mí todavía no me ha llegado a ninguna cuenta de correo, este tipo de phishing pero sentía curiosidad de como trabaja y por qué está haciendo daño. Aunque realmente, con el phishing se puede llegar muy muy lejos.

Un gran detalle de mi compañero que me manda malware en vez de un jamón jeje.

El artículo de hoy “Destapando el Phishing de Correos…por la mañana temprano” tratará de desgranar y/o identificar la procedencia del correo y de si es maligno o no. Además de extraer información

Desmontando la trama.

En un principio llega un correo a tu cuenta mail desde correos@sdacourier.net ya aquí hemos tenido que darle a suprimir pero como usuarios “despistados” no nos hemos coscado de este detalle y sí, de que pone correos y “algo” de Courier, una empresa de transporte.

La interfaz Web

Ignorantes nosotros hemos picado, y le hemos clicado en el enlace “Descargar información sobre su envío” porque queramos o no, el ser humano es curioso por naturaleza. Estoy por apostar que si pusiera “por favor no cliques aquí” tendría mucho más efecto que otro texto.

La interfaz está conseguida sin duda, aunque el captcha siempre es el mismo pero si entras un numerito diferente no te deja continuar. Que exigente, oiga!.

Nos hemos fijado que tiene un cuadro de texto para “buscar” y casualmente se nos ha caído la cabeza sobre el teclado metiendo el famoso alert para ver si hay algún XSS sin éxito aunque si nos ha revelado más info.

No es que sea algo relevante pero si sabemos que funciona bajo Apache 2.2.22 con algunos CVE que pueden ser aprovechados. Pero nosotros no hacemos eso ;).

La Web no tiene nada más, metes el captcha y se te descarga un ZIP el cual contiene tu carta certificada, pero… en EXE. Que nivel!! Correos mandando cartas certificadas en .EXE!!! Obviamente no vamos a abrirlo y lo eliminamos porque esto si que no cuadra. Podemos analizarlo con malwr.com por ejemplo o con nuestro antivirus para ver su peligrosidad.

Estructura del Phishing

Lo primero que vamos a ver es si localizamos información sobre el dominio “sdacourier.net” para saber de dónde viene la URL. Metemos el dominio en urlquery.net (recordad que es nuestro amigo xD) pero no obtenemos nada, incluso dice que es una URL inválida.

Probemos si tiene algún subdominio más tipo “webmail”, “mail” etcétera… en un principio probamos de forma manuel pero teniendo “amigos” que pueden hacer esto mucho más sencillo ¿por qué no utilizarlos?. Para ello vamos a lanzar fierce una aplicación integrada en Kali Linux para localizar recursos DNS.

Obtenemos los siguientes resultados:

Malamente, apuntan los DNS a dominios “.ru” ya otra señal de que algo bueno no es. Si probamos por ejemplo el subdominio mail.sdacourier.net veremos esta pantalla.

,

 Podemos deducir que simplemente es un servidor de correo, con mail, smtp y pop configurado pero nada más. Otra señal que se une a las premisas encontradas antes.

¿Y si analizamos en urlquery.net los subdominios?

Intentémoslo con mail.sdacourier.net.

Localización, Ucrania. Más malas noticias. Podíamos parar el análisis y darnos cuenta de que no, de Courier, Correos o lo que sea no es realmente pero nos hemos propuesto sacar las máximas evidencias en pocos minutos. Sigamos pues.

Vamos ahora a intentar una transferencia de zonas DNS para revelar más información del atacante. Esta vez vamos a usar Windows, el cual tiene una utilidad que se llama nslookup que nos ayudará con esto. Lo que debemos introducir es lo siguiente, secuencialmente.
nslookup
server ip
set type=any
ls -d <nombre del dominio>

 Igualmente, apunta todo a Ucrania, seguimos con malas noticias xD.
Como veis, en cuestión de minutos (no más de 10) hemos desgranado la procedencia del mail que nos ha llegado tan temprano y descubierto detalles que deben hacernos sospechar muchísimo.
Estos pasos podemos seguirlos con cualquier correo que consideremos sospechoso. Evidentemente este proceso no te saca un cartel con “Esto no es de fiar” sino que hay que deducir tras analizar las premisas, si me conviene o no. Lo más rápido sería analizar el .exe con el antivirus o subirlo a virustotal.com para que nos de un resultado pero para ello hay que “clicar” el enlace y quizás en el navegador esté el exploit para infectarte. De ahí el ir paso por paso analizando el dominio, subdominios etcétera…

Podemos deducir que simplemente es un servidor de correo, con mail, smtp y pop configurado pero nada más. Otra señal que se une a las premisas encontradas antes.

¿Y si analizamos en urlquery.net los subdominios?

Intentémoslo con mail.sdacourier.net.

- See more at: http://hacking-etico.com/2015/04/23/destapando-el-phishing-de-correos-por-la-manana-temprano/#more-4245

No es que sea algo relevante pero si sabemos que funciona bajo Apache 2.2.22 con algunos CVE que pueden ser aprovechados. Pero nosotros no hacemos eso ;).

La Web no tiene nada más, metes el captcha y se te descarga un ZIP el cual contiene tu carta certificada, pero… en EXE. Que nivel!! Correos mandando cartas certificadas en .EXE!!! Obviamente no vamos a abrirlo y lo eliminamos porque esto si que no cuadra. Podemos analizarlo con malwr.com por ejemplo o con nuestro antivirus para ver su peligrosidad.

Estructura del Phishing

Lo primero que vamos a ver es si localizamos información sobre el dominio “sdacourier.net” para saber de dónde viene la URL. Metemos el dominio en urlquery.net (recordad que es nuestro amigo xD) pero no obtenemos nada, incluso dice que es una URL inválida.

Probemos si tiene algún subdominio más tipo “webmail”, “mail” etcétera… en un principio probamos de forma manuel pero teniendo “amigos” que pueden hacer esto mucho más sencillo ¿por qué no utilizarlos?. Para ello vamos a lanzar fierce una aplicación integrada en Kali Linux para localizar recursos DNS.

Obtenemos los siguientes resultados:

- See more at: http://hacking-etico.com/2015/04/23/destapando-el-phishing-de-correos-por-la-manana-temprano/#more-4245

Parando Metasploit con Snort

Hoy vamos a ver como podemos detectar cualquier tipo de ataque a una aplicación vulnerable de nuestro servidor, simplemente analizando aquellos posibles exploit que puedan ser lanzados contra este y añadiendo una regla en nuestro IDS para detectarlos y pararlos, en nuestro caso utilizaremos Snort. El escenario sería el siguiente:

La idea es identificar una característica única del exploit a detectar con el IDS y crear una regla con Snort para detectarlo. Para ello previamente lo que hacemos es lanzar el exploit para explotar la vulnerabilidad y capturar el tráfico para analizarlo.

En este momento tenemos que identificar una característica única/particular de este exploit. Debemos ser capaces de obtener la máxima información de como funciona el exploit, para ello podemos analizar el código del propio exploit así como examinar su documentación.

Exploit –> http://www.exploit-db.com/exploits/28681/

Concretamente hemos usado un exploit bajo metasploit para explotar el puerto 21 de un FreeFTPd con una vulnerabilidad que lleva a cabo un PASS Command Buffer Overflow, es decir, introducir una contraseña no esperada para provocar un desbordamiento de buffer. Lanzamos el exploit varias veces y obtenemos varios ficheros .pcap que nos disponemos a analizar exhaustivamente:

Una vez que somos capaces de sacar información que identifique al exploit unívocamente nos disponemos a generar una regla en Snort. Las reglas en Snort constan de dos partes: la cabecera y las opciones. El objetivo de este artículo no es explicar el funcionamiento de Snort, ni tampoco el de como crear una regla, para ello podéis consultar

http://manual.snort.org/

Si analizamos cada uno de los paquetes que lanza el exploit veremos que se están inyectando operaciones tipo NOPs (No-Operation, instrucciones que no hacen nada, como por ejemplo sumarle 0 a un registro) para rellenar instrucciones además del Payload inyectado. Esto se suele hacer por muchos tipos de malware para reconducir la ejecución del programa, caso de caer en una posición de memoria donde haya una NOP, se ejecutarán todas las instrucciones que no hacen nada hasta llegar al trozo de código malicioso que realmente quiere ejecutar el atacante. Vemos con Wireshark las NOPs y lo que realmente inyecta el Payload.

Con toda esta información ya podemos crear un regla en nuestro IDS Snort para detectar este exploit. A continuación mostramos la regla creada según las peculiaridades encontradas en el exploit:

drop tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:”Exploit FreeFTPd  PASS Command Buffer Overflow detectado by Hacking-Ético”;  content:”USER anonymous”; content:”PASS “; pcre:”/^PASS\s[^\n]{100}/smi”; classtype:shellcode-detect; sid:1000001; rev:1; nocase;) ;

Hemos visto que el exploit va dirigido al puerto 21, que hace uso del usuario anónimo y que introduce varios caracteres raros en la parte de la PASS, por tanto esas serán nuestras características concretas para nuestra regla.

Analicemos pues la parte de la cabecera:

drop tcp $EXTERNAL_NET any -> $HOME_NET 21

Se aplicará la regla de eliminación de paquete (drop) a todos aquellos paquetes que vengan vía tcp desde una red exterior ($EXTERNAL_NET es una variable que identifica cualquier IP externa) desde cualquier puerto de comunicación en el origen (any); y cuya petición vaya destinada a una IP interna ($HOME_NET idem IP interna) sobre el puerto 21.

Dentro de la parte de las opciones:

(msg:”Exploit FreeFTPd  PASS Command Buffer Overflow detectado by Hacking-Ético”;  content:”USER anonymous”; content:”PASS “; pcre:”/^PASS\s[^\n]{100}/smi”; classtype:shellcode-detect; sid:1000001; rev:1; nocase;) ;


En este apartado determinaremos que características tienen los paquetes que deben ser eliminados. Dejaremos constancia del bloqueo de paquetes en el log de Snort con el mensaje que aparece en msg.

El paquete debe ser una petición de usuario anónimo y que la clave contenga alguno de los datos contenidos en la expresión regular (pcre). Dicha expresión regular debe estar escrita en perl, podéis encontrar diferentes expresiones regulares y reglas en el fichero policy.rules de Snort. El resto de las opciones determinan la clase de paquete (classtype), el identificador de la regla local (sid) y revisión (rev); y por último añadimos la palabra nocase para indicar al motor de Snort que la aplicación de la regla no sea “case-sentitive“.

La regla se añadirá al final del fichero de configuración de snort (snort.conf). Una vez añadida se comprueba su funcionamiento con los .pcap capturados del ataque para ver si es efectiva en caso de producirse nuevo ataque.

snort -A fast -c /ruta/snort.conf –pcap-dir=”/ruta/pcaps/” -l .

-A modo de la alerta, rápida en este caso (fast)

-c fichero de reglas, en este caso el snort.conf que hace referencia a todos los ficheros de reglas de que se encuentra en la carpeta de snort (/rutaSnort/rules) y además contiene al final nuestra regla. Debe ponerse todo en una sola línea.

–pcap-dir indicamos la carpeta donde están los pcap para comprobar.

-l indicamos la carpeta de salida del log (se creará un fichero llamado alert)

Una vez comprobado el funcionamiento de las reglas con los pcaps que contienen la captura del exploit, obtenemos el siguiente resultado:

Vemos como además de nuestra regla, hay otras reglas dentro de snort que detectan el uso del usuario anonymous o el overflow en la PASS. Ahora sólo tendremos que coger un exploit de un 0day y analizarlo para crear una regla de Snort y que no afecte a nuestro servidor hasta que podamos parchear la vulnerabilidad en cuestión. También se suele analizar el tráfico que genera ciertos malware y crear reglas en función de las peticiones que realicen.

Bueno ahora sólo queda que os pongáis a jugar con algunos exploits y los analicéis para poder detectarlos.