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.
Espero que os resulte útil 😉
¡Hasta la próxima!