Archive for Miguel A. Arroyo

Aprender de ataques para un WordPress más seguro

Introducción

El pasado 13 de mayo tuve la oportunidad de participar en la sexta edición de la WordPress Meetup Córdoba celebrada en la Facultad de Ciencias del Trabajo de esta misma ciudad. Lo hice con una charla sobre seguridad en WordPress, como no podía ser de otra forma, y en la que, basándome en 10 frases extraídas de la obra El Arte de la Guerra de Sun Tzu, traté algunos conceptos para aumentar la seguridad de nuestro WordPress.

Aprende de los ataques para hacer tu WordPress más seguro

Objetivo

El objetivo era transmitir a los asistentes la importancia de analizar los ataques que recibimos a nuestro sitio web (porque creedme, los recibimos), con la intención de aprender de ellos, saber por dónde intentan atacarnos o cuáles son los patrones habituales de los ataques. Se remarcó lo útil que es monitorizar y analizar los logs que se generan, donde podemos encontrar información muy valiosa para cumplir nuestro objetivo; hacer nuestro sitio WordPress más seguro. Y como si de una estrategia militar se tratara, se mencionaron otros aspectos importantes de la seguridad en WordPress buscando la similitud de éstos con algunas de las frases más populares de Sun Tzu.

Recurso

Finalmente, para los que no pudisteis asistir y estéis interesados en obtener la presentación en PDF que utilicé en la charla, aquí os dejo un enlace de descarga de la misma.

Aprende de los ataques para hacer tu WP más seguro

Como siempre, espero que resulte de vuestro interés.

Miguel Ángel Arroyo

@miguel_arroyo76

Ransomware en MongoDB

Introducción

En las últimas semanas se han producido varios ataques de ransomware contra servidores de bases de datos MongoDB, concretamente se calculan que más de 20.000 bases de datos se han visto afectadas en todo el mundo dando lugar a cerca de 680 TB de fuga de información.

El problema está en la gran cantidad de servidores publicados y en este caso que vamos a comentar, indexados por Shodan. Vale con una simple búsqueda utilizando ciertos filtros de Shodan para descubrir los servidores de MongoDB publicados en Internet.

Shodan en acción

Podemos usar el filtro “product” como vemos a continuación.

product:mongodb

Donde obtenemos 38.845 resultados tal y como se puede ver en la imagen.

Ransomware en MongoDB

Otra opción es usando el filtro “port” indicando el número de puerto correspondiente por defecto a las instancias de MongoDB, el 27017.

port:27017

Obteniendo aproximadamente unos 500 resultados más, 39.311, posiblemente como consecuencia de haber aplicado “seguridad por oscuridad“, ocultando nombre de producto, versiones, etc.

Read more

OWASP Mobile Security Project

Introducción

OWASP (Open Web Application Security Project) nos provee de una serie de recursos basados sobre todo en guías y herramientas para que nuestros proyectos web sean lo más seguros posibles, tanto desde el punto de vista de desarrollo seguro como de la evaluación de la seguridad de éstos.

Para los desarrolladores ofrece una gran cantidad de recursos para ayudar a llevar a cabo un ciclo de vida de desarrollo de software seguro (S-SDLC, Secure Software Development Life Cycle).

Para los auditores de seguridad ofrece una gran cantidad de recursos como guías y herramientas para evaluar la seguridad de las aplicaciones móviles.

OWASP Objetivos

OWASP Mobile Security Project

Pues bien, tanto los desarrolladores de aplicaciones móviles como los auditores de éstas, pueden aprovecharse también de recursos de este tipo para poder alcanzar el objetivo de la máxima seguridad posible. Para ello OWASP nos propone su Mobile Security Project.

owasp-msp-logo

La imagen anterior es el logotipo oficial del proyecto OWASP Mobile Security Project.

OWASP ProcesosAl igual que en las aplicaciones web, para conseguir el nivel máximo de seguridad posible es imprescindible que todos los factores se alineen; personas, procesos y tecnología.

Recursos OWASP Mobile Security Project

A continuación nombraremos algunos de los recursos disponibles en este proyecto.

Top 10 Mobile Risks: Tal y como podemos encontrar con el Top 10 de riesgos en aplicaciones web, también tenemos este recurso disponible en el proyecto MSP.

Developer Cheat Sheet: Una “chuleta” con consejos para el desarrollador para evitar errores que puedan dar lugar a vulnerabilidades en su aplicación.

App Security Testing Cheat Sheet: Una “chuleta” para el auditor con información interesante para llevar a cabo la evaluación de la seguridad de la aplicación.

Secure Mobile Development: Recurso para el desarrollador que le ayudará durante el ciclo de desarrollo de software seguro (S-SDLC).

Security Tesing Guide: Similar a la Testing Guide para aplicaciones web, también podemos encontrar una guía de test para ayudar al auditor durante sus tareas de evaluación de los controles de seguridad de la aplicación.

Tools: OWASP nos propone un arsenal de herramientas que nos ayudarán tanto para el desarrollo seguro así como para testear los distintos controles de seguridad. Disponibles para las diferentes plataformas (Android, iOS o Windows Phone).

Top 10 Mobile Controls: Definidos conjuntamente por la ENISA y OWASP, nos indica el top 10 de los controles de seguridad a evaluar.

owasp-msp-resources

En próximos artículos en el blog hablaremos de los distintos recursos que acabamos de comentar. Como siempre, esperamos que sean de vuestros interés y esperamos vuestro feedback.

¡Saludos!

@miguel_arroyo76

 

 

Desactivando ASLR en una app iOS con Radare2 – Parte 2

Introducción

Continuamos con la segunda y última parte de este artículo acerca de cómo desactivar ASLR en una aplicación iOS con Radare2. En la primera parte, que podéis consultar aquí, vimos cómo comprobar si un binario de tipo Mach-O tiene activado o no la protección PIE (Position-Independent Executable). PIE permite el uso de Exec Shield o PAX que utilizan técnicas de direccionamiento aleatorio como ASLR (Address Space Layout Randomization).

También vimos que dependiendo de la arquitectura, ARMv7 o ARM64 tendríamos que buscar una cadena u otra. Además vimos que esa cadena a buscar en nuestro binario estaría cerca de la cadena _PAGEZERO, que nos puede servir de referencia.

Manos a la obra

Vamos a “parchear” nuestro binario para modificar unos bytes que nos permitirán desactivar el PIE. Para ello abriremos el binario en modo escritura con Radare2. Para abrir un binario en modo escritura utilizaremos el parámetro -w (write).

Radare2 - Write modeEn la imagen anterior podemos ver que hemos abierto ya no está cifrado (aplicado Clutch en la primera parte), y que tiene habilitado PIE.

Localizamos la cadena a buscar, tal y como hemos visto en la primera parte de este artículo, y pasaremos a explorar el binario para hacer el “parcheo“.

Con la tecla v (visual mode) de Radare2 podemos entrar en modo visual, lo que nos va a permitir a ver las distintas direcciones relativas y sus contenidos. Con la tecla c (cursor mode) activamos el cursor y podremos desplazarnos por los contenidos mostrados.

Una vez localizados los bytes a modificar, 850020 (recordad que varía según la arquitectura), procedemos a activar el modo insertar, para lo que pulsaremos la tecla i en Radare2.

Radare2 - Insert modeEn este modo de inserción, podremos modificar los bytes, dejándolos como vemos en la siguiente imagen.

Radare2 - Insert mode

Salimos de Radare2, los cambios se guardarán automáticamente porque hemos “escrito” directamente en el binario.

Comprobación

Comprobamos nuevamente con la herramienta otool si PIE sigue activado o no.

otool - iOS PIE

Podemos comprobar como efectivamente en el binario cuyo nombre acaba en _NoPIE hemos conseguido deshabilitar PIE.

Para finalizar, con otra herramienta del framework de Radare2, como es radiff2, podemos buscar diferencias entre dos binarios. Si lo aplicamos a los dos binarios con los que hemos estado trabajando, uno con PIE activado y el otro con el PIE desactivado con Radare2, podemos ver la diferencia en el byte modificado.

A continuación se puede ver un ejemplo de radiff2 con estos archivos.

Radiff2 - PIE

Hasta aquí este artículo que, como siempre, esperemos haya sido de vuestro interés. Todos los comentarios y sugerencias serán bienvenidos. Gracias de antemano.

¡Hasta pronto!

Miguel A. Arroyo – @miguel_arroyo76

Desactivando ASLR en una app iOS con Radare2 – Parte 1

Introducción

En este artículo explicaremos cómo podemos desactivar ASLR (Address Space Layout Randomization) en una app iOS. Ya vimos en un artículo anterior cómo podemos comprobar con la herramienta otool si una aplicación iOS tiene activada esta protección o no. Podéis leer el artículo en este enlace.

ASLR, PIE, PAX y Exec Shield

En realidad lo que se comprueba es si el binario ha sido compilado con PIE (Position-Independent Executable). Los binarios de tipo PIE permiten en algunas distribuciones GNU-Linux orientadas a seguridad a hacer uso de PAX y Exec Shield, que son unas implementaciones realizadas a nivel de kernel. Estas implementaciones aumentan la seguridad del sistema, permitiendo por ejemplo el direccionamiento aleatorio de los objetos del programa en memoria, dificultando así posibles explotaciones de vulnerabilidades de tipo buffer overflow, entre otros. Aquí es donde ASLR entra en juego.

La siguiente imagen corresponde a la versión PAX de Tux. 😉

170px-pax_tux

Para evitar confusiones, aunque la finalidad es deshabilitar el direccionamiento aleatorio (ASLR), nos referiremos a PIE, ya que así es como se refleja el flag en el binario que vayamos a analizar. De hecho, con otool el resultado del análisis se muestra de la siguiente forma.

Comprobar PIE con otool

Se puede observar a la derecha de la imagen que el binario analizado muestra el flag PIE activado.

Radare2

Este magnífico framework de ingeniería inversa creado por Sergi Álvarez (@pancake), que surgió como una herramienta de forense, actuando como un editor hexadecimal capaz de abrir archivos de disco. A día de hoy cuenta con un interesante arsenal de utilidades que permiten analizar binario, desensamblar código, depurar programas o hacer depuración remota a través de servidores gdb.

Podéis encontrar toda la información en el siguiente enlace: https://github.com/radare/radare2

A título personal decir que, aunque la curva de aprendizaje es alta, es un framework que merece la pena conocer, estudiar y usar, sobre todo si te dedicas a ingeniería inversa, o estás pensando en dedicarte. Yo soy un auténtico novato de esta herramienta, pero lo poco que he aprendido hasta ahora quería compartirlo vosotros, y qué mejor manera que hacerlo de manera práctica con este ejemplo que estamos viendo.

¿Qué buscamos exactamente?

Después de analizar varios binarios de aplicaciones iOS de diferentes arquitecturas (ARMv7 y ARM64), he llegado a la conclusión que el volcado en hexadecimal que hay que buscar con Radare2 son los siguientes:

Hex bytes: 858021 para la arquitectura ARMv7

Después de abrir Radare2 con el binario a analizar (thin_binary), para lo que usaremos la sintaxis “r2 thin_binary“, haremos una búsqueda (seek) con el comando “s“, especificando que estamos buscando un volcado en hexadecimal, de ahí la “/x” y a continuación lo que queremos buscar (858021).

PIE hexdump in Radare2

Si estamos analizando una app de iOS de ARM64, los hex bytes a buscar serían 850020.

PIE flag in Radare2

Observad que en ambos casos, cuando encuentra el patrón buscado, es decir hace 1 hit, Radare2 automáticamente nos posiciona en el offset donde los ha encontrado (0x00000018, en el último ejemplo). Finalmente mostramos un volcado de 16 bytes con el comando “px” donde podemos ver que se muestran los hex bytes que estábamos localizando.

También podemos localizar fácilmente el offset donde encontrar estos hex bytes buscando la sección / segmento _PAGEZERO, que suele estar siempre muy cerca de estos bytes. Pero sin lugar a duda, lo más certero es utilizar el comando “s/x [hexbytes_armx]” para localizarlo y ubicarnos.

Hasta aquí esta primera parte de este artículo. En el siguiente artículo veremos qué bytes hay que modificar, cómo abrir el binario en Radare2 en modo escritura, cómo buscar diferencias enter el binario original y el parcheado con rabin2 y finalmente comprobar nuevamente con otool que hemos conseguido deshabilitar el flag de PIE.

Como siempre, espero que sea de vuestro interés y nos vemos pronto en la segunda parte de este artículo.

PD: Cualquier comentario, consulta y recomendación será bienvenido, sobre todo si es de Radare2, donde me tenéis que disculpar, pero soy muy novato. Eso sí, con muchas ganas de seguir aprendiendo y compartiendo. 🙂

 

Seguridad en las impresoras

Introducción

Cuando hablamos de seguridad en las empresas y qué activos proteger, enseguida se nos vienen a la cabeza los distintos vectores de ataque de nuestros sistemas de información y cómo protegernos de esos posibles ataques. Pero, ¿qué ocurre con la seguridad en las impresoras?

Seguridad perimetral, seguridad en las comunicaciones, seguridad en el puesto de trabajo, seguridad en los dispositivos móviles… son algunos de los ejemplos de protección de activos de la empresa.

Pero estamos pasando por alto un tema importante de seguridad en este planteamiento, y se trata de las impresoras. ¿Existen posibles vectores de ataque a este tipo de dispositivos? Si es así, ¿cuáles podrían ser? Quizás el problema radique en que vemos a la impresora como una “simple” máquina cuya función es imprimir lo que desde un ordenador enviamos.

Si nos detenemos en qué es una impresora, enseguida entenderemos que, además de la electrónica y mecánica pura de una impresora, está dotada de una serie de puertos, interfaz de red, controladores, disco duro y un pequeño ordenador, con su BIOS y con su sistema operativo, que maneja estos recursos.

OK, ahora más o menos nos hacemos una idea, pero ¿qué riesgos hay realmente? Vamos a dividirlos en varios apartados:

Vectores de ataque

Confidencialidad del documento impreso

En entornos corporativos es muy normal que se utilicen impresoras de red que está ubicadas en un lugar remoto de la oficina. ¿Qué ocurre si mandamos a imprimir un documento con información sensible? Desde que nos levantamos del puesto de trabajo hasta que recogemos el documento de la bandeja de la impresora, ¿quién ha podido ver o fotocopiar ese documento?

Las impresoras suelen incluir una funcionalidad llamada impresión privada, que permite proteger con un PIN la impresión del documento. Éste queda en cola hasta que el usuario, después de enviar el documento a imprimir, introduce su PIN de seguridad en la impresora para que ésta imprima el documento.

Vulnerabilidades

La impresora ejecuta una serie de servicios que se publican en unos puertos, por ejemplo para su administración. Hoy en día es bastante habitual que las impresoras puedan ser gestionadas vía Web, por lo tanto disponen de su propio servidor Web que permite esta administración.

El software que gestiona dicho servicio puede estar afectado por algún tipo de error que pueda dar lugar a una vulnerabilidad que podría ser aprovechada por un posible atacante y explotada para, por ejemplo, provocar una denegación del servicio.

Modificación de firmware

Las impresoras para mejorar sus funcionalidades o corregir posibles errores de sus software, permite la actualización de su firmware. Este firmware normalmente está disponible en la Web del fabricante. Un posible ataque podría ser la alteración de este firmware para tomar el control de la impresora de forma remota, capturar tráfico o para lanzar ataques a otros dispositivos de la red.

Robo de información

Ya existen muchas impresoras que incluyen un disco duro para el almacenamiento de información, como pueden ser trabajos, históricos de impresiones, documentos escaneados, etc. Al final ese disco duro podría ser extraído de la impresora, y si no hay un cifrado en la información de éste, se podría consultar sin ningún problema información sensible de los trabajos realizados en la impresora.

Indexación de impresoras en Internet

Muchas impresoras, por razones extrañas, son publicadas directamente en Internet. Esta publicación da lugar a que motores de indexación de dispositivos como Shodan acaben añadiendo a su base de datos información de la impresora como puede ser su banner del servidor Web, dirección IP pública, servicios publicados, localización… Si además, la administración Web no ha sido protegida de forma adecuada, se podría dar el caso de que algún atacante tuviera fácilmente acceso a ella.

Instalación de aplicaciones maliciosas

Por último, y no menos importante, es la mención a la posibilidad de instalar aplicaciones en las impresoras. Aplicaciones que pueden ser potencialmente peligrosas y pueden ser usadas de forma maliciosa para controlar la impresora con fines fraudulentos, como puede ser la captura de tráfico de la red o acceder a trabajos de ésta. Se han dado casos muy curiosos como la instalación del juego Doom en una impresora. Otro vector de ataque a tener muy en cuenta.

Conclusión

Con los posibles vectores de ataque que acabamos de comentar, creemos que son lo suficientemente relevantes para que a dispositivos como impresoras le demos la importancia que realmente tienen, y se apliquen una serie de políticas de seguridad para mitigar o reducir los posibles riesgos que estos vectores puedan suponer para la empresa. Resumiendo, no nos podemos olvidar de la seguridad en las impresoras.

Patito Hunter – Detectar y bloquear un USB Rubber Ducky con Python

“Cazando al patito”

Introducción a USB Rubber Ducky

A estas alturas seguro que ya todos habéis visto (o padecido) o habéis escuchado hablar sobre USB Rubber Ducky, conocido familiarmente como el “patito“. Para los que no, simplemente decir que se trata de un dispositivo USB con apariencia similar a un pendrive o flashdrive de toda la vida pero que en realidad es un dispositivo HID (Human Interface Device). En este caso se trata de un teclado que almacena una serie de comandos que son ejecutados cuando el dispositivo se conecta a un ordenador, portátil, tablet o smartphone. Los comercializan los chicos de Hak5, pero en España también tenemos representación de la empresa Phoenix Intelligence & Security que también fabrican dispositivos similares. Como os podéis imaginar las posibilidades son infinitas.

Aquí tenéis dos artículos en nuestro blog mostrando sus posibilidades:

Cuando el pato teclea Cuack Cuack – Parte 1

Cuando el pato teclea Cuack Cuack – Parte 2

Cabe destacar además que a día de hoy, muy pocos fabricantes de malware detectan y bloquean este tipo de dispositivos, solo G-Data con su USB Keyboard Guard. Eso sí, de momento solo para Windows.

USB Rubber Ducky - Ninja

Objetivos

En este caso no he venido aquí para escribir cómo funciona el USB Rubber Ducky y sus posibilidades, que como ya he dicho antes, son muchas desde el punto de vista ofensivo. Los objetivos de este artículo son:

  1. Explicar en qué he basado mi investigación
  2. Presentar la herramienta “Patito Hunter
  3. Aprender, hackear y compartir.

Ya en este blog he ido publicando artículos sobre análisis de dispositivos USB con Wireshark, concretamente los artículos los podéis encontrar en estos enlaces:

Análisis de un dispositivo USB con Wireshark – Parte 1

Análisis de un dispositivo USB con Wireshark – Parte 2

En estos artículos se explica cómo capturar tráfico USB con Wireshark para a continuación analizar la información obtenida y saber cómo funcionan los dispositivos USB; desde que lo conectamos al equipo, se intercambia información del dispositivo, sus configuraciones o interfaces. Desde la publicación del primer artículo, en octubre de 2015, he ido analizando con Wireshark la información de distintos dispositivos USB, y de distintas clases (Mass Storage, Printer, HID, etc).

Esta misma información puede ser usada para analizar otros dispositivos de tipo Bad USB, como puede ser el propio USB Rubber Ducky o LAN Turtle (la famosa tortuga). Como he comentado en la introducción, un “patito” emula el funcionamiento de un dispositivo HID, concretamente un teclado, pero con sus diferencias. Y son precisamente estas diferencias las que me han llevado a desarrollar una pequeña herramienta, a la que he llamado cariñosamente “Patito Hunter” para detectar y bloquear los USB Rubber Ducky, basándome precisamente en esas diferencias. Read more

Análisis de un dispositivo USB con Wireshark – Parte 2

En la primera parte de esta serie de artículos sobre análisis de dispositivos USB con Wireshark, que podéis encontrar aquí, hicimos una primera aproximación a la investigación acerca del funcionamiento de un dispositivo USB. Si no recordáis cómo hacer una captura de tráfico con Wireshark de un USB, os recomiendo leer la primera parte de esta serie.

El primer artículo terminaba con una referencia a los conceptos que vamos a tratar aquí; clases, descriptores, interfaces, endpoints… Estos conceptos son fundamentales tenerlos claros para poder analizar y conocer cómo funcionan, y para ello seguiremos con nuestro análisis USB con Wireshark, cuando conectamos un dispositivo de este tipo a nuestro equipo.

En primer lugar tenemos que tener claro que existen muchos tipos de clases de USB, no solo aquellos con los que estamos más acostumbrados a trabajar, como pueden ser los dispositivos de almacenamiento, o los dispositivos de interfaz humana (HID, Human Interface Device).

Class: Una clase nos permite definer funcionalidades del dispositivo USB. Algunos ejemplos son:

  • Class 1 – Audio
  • Class 3 – HID (Human Interface Device)
  • Class 6 – Image
  • Class 7 – Printers
  • Class 8 – Mass Storage

Los pendrives que utilizamos para almacenar y transportar nuestros ficheros pertenecen a la clase 8 (Mass Storage), mientras que los ratones o teclados USB, pertenecen a la clase 3 (HID).

En las primeras capturas que realizamos con Wireshark ya pudimos observar en algunos de los paquetes cómo los dispositivos y el host utilizaban descriptores para solicitar e intercambiar información. Esta información, como su nombre indica, sirve para describir características y funcionalidades del dispositivo.

Wireshark - Descriptores USB

En la imagen anterior podemos observar en la columna Info que enter el host y el dispositivo (con dirección 7) se intercambian una serie de solicitudes y respuestas. El host solicita información que le describa el dispositivo, la configuración y otras cadenas con información de interés para que el host pueda proponer la configuración más idónea. Read more

ASCII Art en logs de servidor Web

Como estamos en vísperas del día de los Reyes Magos, hoy traemos una entrada divertida y que esperamos que os guste. Eso sí, como siempre, dadle buen uso. Vamos a insertar un poco de “arte” a modo de ASCII Art en los logs de un servidor Web. Mola, ¿no?

No es nada nuevo, de hecho la idea surge a raíz de un tweet de Mercè Molist donde se mostraba un mensaje que habían dejado en unos logs de un servidor. Me pareció bastante ingenioso, así que investigando un poco (es bastante simple como veréis a continuación) decidí replicarlo pero incluyendo un ASCII Art.

¿No sabéis lo que es? Seguro que estáis hartos de verlo, algo como esto:

 __  __           __   _                ________  _          
   / / / ____ ______/ /__(_____  ____ _   / ____/ /_(__________ 
  / /_/ / __ `/ ___/ //_/ / __ \/ __ `/  / __/ / __/ / ___/ __ \
 / __  / /_/ / /__/ ,< / / / / / /_/ /  / /___/ /_/ / /__/ /_/ /
/_/ /_/\__,_/\___/_/|_/_/_/ /_/\__, /  /_____/\__/_/\___/\____/ 
                              /____/

¿Y cómo lo vamos a hacer? Muy sencillo, seguiremos los siguientes pasos, que como podréis comprobar, son muy simples:

  1. Guardar nuestro ASCII Art en un fichero.
  2. Crear un script en Python que lea línea por línea el fichero.
  3. Por cada línea leída, hace una petición HTTP al servidor Web.

Aquí lo interesante es que modificaremos las cabeceras de HTTP en función de cómo queramos hacer la petición, y es que dependerá de varios factores, por ejemplo de cómo esté configurado el formato de log en el servidor.

Algo que en los servidores Apache, por ejemplo, se podría definir con la siguiente línea en su archivo de configuración:

CustomLog ${APACHE_LOG_DIR}/access.log combined

En el caso de servidores Web de tipo Apache, el formato de logs se puede personalizar, y existen varios formatos para ello. Por ejemplo, con el formato de log “common“, un access.log de un Apache tendría este aspecto:

[05/Jan/2016:11:02:26 +0100] “GET / HTTP/1.1” 200 572

Sin embargo, por ejemplo con el formato de log “combined“, un access.log tendría el siguiente aspecto:

[05/Jan/2016:11:40:53 +0100] “GET / HTTP/1.1” 200 572 “-” “”

En este último formato (combined), los dos últimos valores que van entre comillas, justo después del 572 (tamaño de petición), son el Referer (origen de la petición) y el User-agent, respectivamente.

Si el servidor está usando este formato, con nuestro script en Python podemos “jugar” a insertar nuestro ASCII Art a través de una de estas cabeceras.

Read more

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.

vulnerability-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.

Read more