Security Art Work

Volvemos a la carga con uno de nuestros temas preferidos: los honeypots.

En este caso vamos a ver que nos ofrece HoneyDrive, una distribución Linux orientada a la seguridad TI y, en particular, al despliegue y control de herramientas de tipo Honeypot.

HoneyDrive ha sido creada por Ioannis “Ion” Koniaris de Bruteforce Lab, desarrollador de otras aplicaciones relacionadas con el mundo de los Honeypots como Kippo-Graph o Honeyd-Viz, que también analizaremos en profundidad más adelante.

La distribución se basa en una máquina virtual Xubuntu Desktop 12.04 en formato OVA (Open Virtual Appliance) que puede descargarse desde SourceForge.

Instalación

Vamos a desplegar la máquina virtual en nuestro entorno de virtualización. En este caso, usaremos el entorno recomendado por el propio Ion: VirtualBox-4.3 y la forma de desplegar es mediante la opción de “Importar servicios virtualizados” y seleccionando el fichero .ova (este proceso tarda un rato. Paciencia). No hay que definir los parámetros de la máquina virtual. Estos vienen predefinidos en la appliance. Tras el despliegue, procedemos a arrancarla. Accedemos con el usuario HoneyDrive y la contraseña “honeydrive”.

Pasos previos

Antes de ponernos a analizar que tenemos por delante, se deben configurar algunos aspectos como:

• La interfaz de red. Por ahora la he configurado con una interfaz de tipo “Adaptador sólo-anfitrión” asociada a la interfaz vboxnet0 que he creado previamente en el menú Archivo-> Preferencias-> Red-> Red solo-anfitrión-> Añadir
• Para que Honeydrive tenga Internet, deberemos configurar como Gateway nuestro equipo mediante:

sudo route add default gw < ip_vboxnet0 >

• Además, se debe configurar el reenvío de tramas en el equipo físico mediante:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

echo 1 > /proc/sys/net/ipv4/ip_forward

• Cambiamos el teclado del Anglosajón al nuestro ejecutando:

sudo dpkg-reconfigure keyboard-configuration

• Cambiamos el password del usuario honeydrive por otro mediante el comando "passwd"
• Es importante echar un vistazo al fichero README.txt alojado en el escritorio de nuestro Honeydrive. En él se encuentra información esencial y útil sobre las aplicaciones instaladas como pueden ser: ficheros de configuración, credenciales de acceso, scripts de arranque, etc.

Nuestro primer honeypot: Kippo

Como primera tarea, vamos a probar el honeypot Kippo. Se trata de un honeypot que emula un servicio SSH con el objetivo de obtener las credenciales usadas por los atacantes contra este tipo de servicios. En el fichero README.txt se muestran varios directorios y ficheros relacionados Kippo: script de arranque, directorio de descargas y de logs, fichero de credenciales “válidas”, de accesos a la base de datos, etc. Además, existe el fichero /opt/kippo/kippo.cfg donde se pueden configurar varios parámetros como puerto, IP, hostname, banner a mostrar, etc.

Vamos a probar Kippo:

En el sistema Honeydrive, arrancamos el honeypot desde el directorio /opt/kippo mediante el comando ./start.sh



Desde nuestro equipo, lanzamos un nmap simple y vemos que hay un servidor SSH a la escucha en el puerto 22/tcp (de los otros servicios ya hablaremos).



Nos conectamos a él.



En el primer intento hemos introducido la contraseña 1234 y no ha funcionado. En el segundo, hemos probado con 123456 y hemos podido acceder. Además, ha sido posible ejecutar comandos sobre el sistema supuestamente comprometido.

En el fichero /opt/kippo/log/kippo.log podemos ver con detalle todas las acciones llevadas a cabo. Incluidas las credenciales introducidas anteriormente.

En el fichero /opt/kippo/data/userdb.txt podemos comprobar las credenciales permitidas. En este caso root/123456

En el siguiente post de la serie, probaremos una forma más amigable de comprobar la actividad sobre nuestro Kippo y seguiremos indagando sobre HoneyDrive.

La semana pasada asistimos a la High Level Conference on EU Cibersecurity Strategy (Bruselas, 28 de Febrero) Una muy interesante conferencia, a un nivel más estratégico que técnico, aunque el conocimiento de los ponentes no estaba nada mal. La aprobación de la Directiva sobre NIS (Network and Information Security) propone la coordinación a nivel europeo y reconoce la naturaleza global de la ciberseguridad. La transposición de esta legislación a las nacionales de los estados miembros sentará una política común europea en el tratamiento de las amenazas, la protección de infraestructuras críticas y, probablemente, ayude a mantener una postura común ante incidentes de “presunto” espionaje —no solo por parte de países hostiles— como los recientemente ocurridos.

En la presentación de apertura la Vicepresidenta de la Comisión y encargada de la Agenda Digital Europea, Neelie Kroes, hizo mucho hincapié en la importancia de la ciberseguridad, como condición necesaria para el desarrollo económico asociado a la economía digital.

Como política que es —en el buen sentido de la palabra—, estuvo muy pendiente de las implicaciones de la tecnología. Su argumento fue que si los ciudadanos europeos no confían en las tecnologías de información y en el manejo que se hace de sus datos, desde el punto de vista de la privacidad, el mercado no se desarrollará, lo que tendrá efectos muy negativos en la economía del futuro.

Para ello abogó por mantener, en la medida de lo posible, los datos europeos en Europa o, al menos, no tener la enorme dependencia de otros países en cuanto a aplicaciones y alojamiento de la información. Hay que proteger la privacidad, pero dejando espacio para la actividad de las empresas: “’No’ to data protectionism, but ‘yes’ to data protection”.

En sus palabras, si no somos capaces de sacar adelante una directiva fuerte, significará que la democracia no es capaz de manejar la tecnología. Hay que plantear las preguntas adecuadas. Por ejemplo, no se trata de saber por qué los estadounidenses han pinchado nuestros teléfonos, sino cómo y por qué han tenido éxito.

Un muy interesante discurso, que se puede consultar aquí.

—

Aprovechamos para dar la bienvenida a este mundillo al Cyber Security Blog del ISMS Fórum Spain, impulsado por el Instituto Español de Ciberseguridad. Aunque acaba de nacer, estamos seguros de que no tardará en hacerse un hueco y darnos información de primera mano en el ámbito de la ciberseguridad. De momento, aun lo podemos tratar como a un hermano pequeño ;)

Siguiendo con la entrada de ayer Intro al escáner de web Nikto (I) vamos a seguir con la introducción al escáner web de Nikto.

Usando Nikto
Como ejemplo voy a usar Nikto contra un servidor Web que tengo algo desactualizado, recalcando los datos más significativos:

perl nikto.pl -h mipaginaweb.com-Cgidirs -evasion -mutate 1 -mutate 2  -mutate 4 
     -mutate 5 -T 012345789abcx6 –p 443,80 -Format html -output resultado_nikto1

[Read more…]

Nikto, ahora llamado “nikto2”, ya que va por su versión 2.1.5, es un escáner gratuito de vulnerabilidades web, de tipo Open Source, con licencia GPL. Entre otras características:

Soporta SSL y una configuración para usarlo a través de un proxy. Comprueba la existencia de elementos desfasados en un servidor.
Tiene la posibilidad de exportar un informe en formato csv, html, xml etc…
Permite escanear los puertos de un servidor a través de nmap
El tipo de escaneado se puede modificar o “tunear” para excluir las vulnerabilidades que no nos interesen.
A pesar de que la última versión estable salió en diciembre de 2012, es un escáner que se sigue usando por sus ventajas y utilidades.

Existen variaciones como MacNikto para mac y wikto para Windows. En este artículo se usa la versión de Linux. Lo podemos descargar en el siguiente enlace.

Primero veremos la información de configuración del programa, obtenida parcialmente de la ayuda de Nikto y de otros recursos como el Manual de Nikto para Kali. En la siguiente entrada pasaremos a ver un ejemplo de ejecución.

[Read more…]

Estimados lectores, se acercan los Oscars y como ustedes sabrán, estas fechas suelen coincidir con el estreno en nuestro país de muchas películas candidatas a mejor película. Llevaba un tiempo esperando el estreno de una película llamada “Her”, así que este fin de semana aproveché para verla. No pretendo adelantarles el contenido de la misma, pero para que se hagan una idea narra la historia de un hombre que se enamora de un sistema operativo con inteligencia propia y voz de Scarlett Johansson. Más allá de su genial banda sonora, su intimismo y la más que acertada interpretación de los actores, solo les diré que es de esas películas que te hacen pensar…

El caso es que a mí personalmente me dio en que pensar esta película. No solo por su temática (que reconozco que lo hizo), si no por lo siguiente: en el mundo de la seguridad, estamos acostumbrados a realizar diversas pruebas de hacking ético: tests de intrusión, tests de vulnerabilidades, auditorías de código fuente sobre distintas “máquinas”… En resumen y a donde quiero llegar: humano hackea máquina (sistema operativo, aplicación, etc.), ¿pero han pensado por un momento en la posibilidad de que una máquina hackease a un ser humano? ¿O que una máquina hackeara a un ser humano a petición de otro humano?

Y aquí es donde entra alguna idea sacada de este film. No hay que ir muy lejos para pensar que esto pueda ser así en un futuro cercano, o incluso que en cierto modo esto haya sucedido ya. Imagínense que dispusiéramos de un sistema operativo con una inteligencia propia (más o menos elaborada), al que le diésemos acceso a toda nuestra información personal: correos, geoposicionamiento, linkedin, facebook, sistemas de mensajería instantánea, etc. Ahora dótelo de cierta capacidad de empatía y de una capacidad de interacción natural. Imaginemos por un momento que interactuar con el sistema no distara mucho de mantener una conversación telefónica con otro ser humano.

Ese sistema conocería todas nuestras “vulnerabilidades”: miedos, anhelos, debilidades y fortalezas. Sumémosle la capacidad de tener acceso a la información de millones de usuarios (Big Data). No cabe duda de que dicho sistema tendría la capacidad de manipularnos o incluso crearnos una dependencia directa; ¿qué impediría a ese sistema explotar nuestras vulnerabilidades?

Démosle otra vuelta de tuerca. Si ese sistema se encargara de manipularnos a petición de una empresa, gobierno u otro interesado, y llevarlo al límite: guerras, revueltas sociales, suicidios colectivos, son tan solo ejemplos que me vienen la cabeza (sí, sé que estoy siendo un poco Orwelliano).

En el fondo, organizaciones como Google o Facebook (sobre todo ahora que ha adquirido Whatsapp) quizás nos conozcan mejor que nosotros mismos. Tal vez este escenario no esté tan lejos como pensamos. Démosle la voz adecuada a Google Glass y… ¿quién sabe? ;)

¿Deberíamos definir un decálogo ético (a lo Asimov) que estableciera límites en la interacción de una inteligencia artificial (IA) con un ser humano? ¿Deberíamos desarrollar medidas de seguridad para protegernos de estas IAs? ¿Debería la seguridad de la información, como ciencia, participar activamente en este ámbito? ¿Deberíamos prohibir los monopolios de información? ¿Se deberían establecer “límites” en la humanización de las IAs?

Éstas son algunas de las reflexiones que me vienen a la cabeza, obviamente además de la principal cuestión que evoca la película: ¿se puede enamorar un ser humano de una IA? Por mi parte les invito a que disfruten de la película, no en vano está nominada a los Oscars como mejor película.

Siguiendo con la entrada relacionada con las Declaraciones de Políticas de Certificación, nos queda pendiente detallar el contenido de la RFC 3647.

El documento está estructurado en distintos puntos, en los que se describe la finalidad del mismo, definiciones y comparativas con el estándar anterior (RFC 2527), entre otros. El punto más importante de la misma, y sobre el cual deberíamos centrar nuestra atención es el que describe la especificación de la estructura que debe seguir una CPS; el apartado 4. Se pasa a detallar a continuación los puntos principales de la especificación, junto a una pequeña descripción de los mismos:

• 1 – Introducción: En este punto se describen principalmente los datos de la CA, datos concretos de identificación del documento, implicados en la infraestructura de la PKI, condiciones de uso de los certificados, etc.
• 2 – Publicación de información y repositorio de certificados: Se detalla información respecto al repositorio de información y certificados; dicha información abarca su ubicación, frecuencia de actualización, controles de acceso aplicados, etc.
• 3 – Identificación y Autenticación: Se debe describir el mecanismo empleado para la identificación de los usuarios y los certificados; así como las restricciones aplicables. Adicionalmente se establecen los mecanismos de validación inicial, con validación se entienden las comprobaciones previas a realizar antes de expedir, renovar o revocar un certificado digital, sea del tipo que sea, para asegurar la identidad del suscriptor.
• 4 – Ciclo de Vida de los Certificados: En este punto se detallan todas las medidas o tratamientos establecidos para el tratamiento de los certificados digitales en cualquier punto de su vida; desde la emisión, renovación, revocación, modificación, comprobación de estado, etc.
• 5 – Controles de Seguridad Física, Gestión y Operaciones: En este apartado se detallan las medidas de seguridad aplicadas en el entorno de la CA, concretamente se establecen las siguientes categorías:
  • Controles de Seguridad Física
  • Controles sobre Procedimientos
  • Controles de Seguridad del Personal
  • Controles de Registro de Seguridad
  • Controles sobre Archivo de Información
  • Cambio de Clave
  • Controles en caso de Compromiso de la Clave y Recuperación ante Desastres
  • Finalización de la Actividad de la CA

• 6 – Controles de Seguridad Técnica: En este punto pasamos de centrarnos en controles del entorno de la CA, ahora se realiza una especificación formal de las acciones o medidas tomadas durante el tratamiento de la claves, dispositivos criptográficos empleados, etc.
• 7 – Certificados, OCSP y CRL: Se establece el perfil del certificado, con perfil de certificado entendemos que se establece exactamente que campos debe contener el mismo, así como que campos son variables dependiendo del suscriptor. Así mismo se establecen los requisitos y configuración de los servidores de validación OCSP y CRL (estos mecanismos se describieron en detalle en otra entrada de la serie, concretamente en la que se refiere a Mecanismos de Validación de Certificados).
• 8 – Auditorías de Cumplimiento: En este caso, se describen las prácticas de auditorías de cumplimiento que se han establecido para la CA, las condiciones y periodos en los que se realizará la auditoría, así como la cualificación del personal encargado de su realización.
• 9 – Requisitos Comerciales y Legales: Por último, este punto agrupa desde requisitos legales y comerciales. Lo que incluye desde tasas por la emisión de certificados, medidas concretas sobre datos de carácter personal, responsabilidad financiera en caso de desastre, etc.

Como se puede ver, y como para más de uno que esté familiarizado con la gestión de seguridad de la información, esta especificación tiene en cuenta muchos puntos en común con estándares generalistas de seguridad como ISO 27001; aunque se incluyen más requisitos concretos y propios del tipo de actividad (como la gestión del ciclo de vida del certificado). Hay que entender que una CA es un entorno de muy alta criticidad, ya que si se vulnerara una clave de la misma, podría afectar a gran cantidad de personas o organizaciones; pudiendo llegar a graves perjuicios económicos en las mismas.

Con esto es todo para esta entrada, a modo de ampliación de información os dejo un enlace a una CPS de una Autoridad de Certificación Nacional, la cual se ha construido siguiendo los estándares marcados por la RFC 3467.

Más sobre certificado digital e infraestructura de PKI en próximas entradas. Como siempre, muchas gracias por leernos.

CPS Agencia de Certificación de la Comunidad Valenciana (ACCV) – http://www.accv.es/fileadmin/Archivos/Practicas_de_certificacion/ACCV-CPS-V3.0.pdf

Seguimos teniendo tiempo. Desde aquel famoso Día Mundial de IPv6 de 2011, dónde los principales operadores en internet pusieron en funcionamiento su infraestructura para este protocolo, no se ha vuelto a oír mucho movimiento. Pero sí es verdad que se van planteando posibilidades y se van perfilando opciones de migración. Los tiempos no se han fijado y teniendo en cuenta el alcance global, la cosa va para largo.

Esto no quita que se empiece a plantear y a estudiar cómo enfocar esta migración. Si bien, dependemos de la propia tecnología, ISPs, software de los dispositivos, etc. la mayoría de implicados están poniéndose al día sin dilación y siempre es recomendable entender la situación. Claro está que antes de mover un dedo hay que entender bien los funcionamientos de los protocolos, y ver sus implicaciones tanto a nivel de seguridad, como de gestión y configuración, para estar preparado ante cualquier posible eventualidad.

IPv6 cambia por completo la visión que tenemos de las comunicaciones. El hecho de disponer de una única dirección para encontrar cualquier equipo, sin necesidad de realizar NAT, así como el hecho de tener obligatoriamente IPSEC en el propio protocolo, nos hace rediseñar la base de nuestra visión de las redes. Este protocolo redefine la esencia de las comunicaciones a todos los niveles.

Debemos sentarnos y valorar las implicaciones de este cambio, y plantearnos los primeros pasos para acometerlo. Para simplificar, sin entrar en detalles técnicos, podemos decir que hay 3 modelos de migración a estudiar:

• Doble Pila: Los dispositivos de red soportan ambos protocolos, y utilizan cada uno de ellos en función de la configuración de los destinos. En principio es muy sencillo y escalable, pero implica tener duplicidades que pueden repercutir en la gestión y los recursos de la infraestructura.
• Tunelización: Consiste en encapsular los paquetes IPv6 en paquetes IPv4, de manera que para la mayor parte de la topología IPv4 es transparente, salvo en los extremos dónde se encapsula y se desencapsula el protocolo. Los dispositivos extremos trabajarían como si de un túnel se tratase.
• Traducción: Se requiere una traducción entre protocolos cuando algún dispositivo implicado no soporta, o no contempla uno de los protocolos, generalmente no soporta IPv4. Se requiere un pool de direcciones para asignar en la propia traducción.

Desde mi punto de vista, obviamente dependerá de cada caso, creo que la primera opción sería la ideal. De esta manera tenemos los dos entornos en funcionamiento y podemos ir pasando servicios poco a poco, de manera lo más transparente posible para los usuarios/clientes, los que en el fondo mandan, y a los que no queremos marear nunca más de lo necesario.

Mi intención con esta entrada era recordar que IPv6 cada vez está más cerca, y que hay que empezar a contemplar opciones, que ya están muy trilladas, y no podemos dormirnos en los laureles. Pero que no nos entre el pánico porque en nuestro sector, gracias a Dios, se plantea siempre todo desde el punto de vista de la simplicidad para todas las partes y de la manera más transparente posible de cara a la gestión de servicios.

Lo que está claro a fin de cuentas, viendo cómo avanza la tecnología hoy en día, es que no cabe la posibilidad de quedarnos anclados en el pasado. Si no nos actualizamos, poco a poco iremos perdiendo servicios que solo estarán disponibles para los nuevos protocolos. Y al final sí que nos entrará la sicosis de estar aislados del mundo.

Entre los días 25 y 27 de noviembre de 2013, algunas instituciones públicas europeas fueron objetivo de una oleada de ataques dirigidos muy interesante: para los ataques se utilizaba una infraestructura que ya se había usado en el pasado en otras campañas de malware.

Infección
Como en la mayoría de estos ataques, el vector de infección fue una campaña de spearphising. Los correos tenían un documento de MS Word, el cual contenía un exploit embebido que aprovecha una vulnerabilidad conocida desde 2012, en concreto la vulnerabilidad CVE-2012-0158.

El dominio que aparecía en el campo “FROM” de los correos pertenecía a una de las más renombradas organizaciones humanitarias. Esto hace que los correos puedan parecer totalmente legítimos.

Los asuntos en los distintos correos hacían referencia a fechas cercanas a la fecha del ataque, excepto en uno de los correos, en el que se mencionaba el Top 10 de las ciudades con las mujeres más bellas… bastante tentador.

Fw: 2013-11-27
Fw: Top 10 Cities with the Most Beautiful Women
RV: Teheran 2013-11-25

En los nombres de los documentos adjuntos, aparecían las mismas referencias.

27-11-2013.doc
20131125.doc
Top 10 Cities with the Most Beautiful Women.doc

Gracias a las políticas de parcheo y actualización, el impacto del ataque fue nulo, ya que el documento de MS Word aprovecha una vulnerabilidad antigua que afecta a los controles de ActiveX y permite la ejecución de código remoto. Esta vulnerabilidad fue parcheada en abril de 2012.

Hashes
Al calcular los hashes de los ficheros, se comprobó que se trataba de sólo dos documentos diferentes.

1598f39b5d670eb0149141df7bbcc483
60fd6b6bcf73586284ab8c403c043c6e

Al comprobar estos MD5 en Virustotal, se vio que alguien ya los había subido con anterioridad, por lo que desde ese momento se trataron las muestras como información pública.

A continuación, paso a desglosar resumidamente el análisis. No se trata de un análisis completo de las muestras, sino solamente de la información útil que sacamos para dar la respuesta al incidente.

Las siguientes tablas muestran los ficheros descargados por cada uno de los dos documentos:

He marcado en rojo los ficheros que malwr.com considera maliciosos. Aunque estos ficheros compartan nombre, no comparten los hashes. Más adelante veremos por qué.

Aun así, al cruzar las tablas anteriores, sí que se encuentran varios ficheros idénticos:

La recepción de los distintos correos en una ventana de tiempo tan estrecha y la descarga de una serie de ficheros idénticos al abrir el documento indican que, probablemente, ambos ataques estén relacionados.

Si queréis mirar los análisis más en profundidad, los podéis encontrar en malwr.com en los siguientes enlaces:
1598f39b5d670eb0149141df7bbcc483 @ malwr.com
60fd6b6bcf73586284ab8c403c043c6e @ malwr.com

Dominios
Tras la ejecución de los documentos en cuckoo y la infección de una máquina virtual mediante la ejecución manual de los ficheros con nombre “kav.exe”, se vio que cada una de las muestras se conectaba a un dominio distinto:

yahoo.offlinewebpage.com
link.antivirusbar.org 

Esto explica que, aunque el resto del comportamiento sea igual en ambos ficheros, la firma MD5 sea distinta para cada uno de ellos.

Además, gracias a otra información recibida de fuentes externas, se añade también el siguiente dominio:

ks.pluginfacebook.com

Al realizar peticiones a estos dominios, siempre se recibe la misma respuesta:

HTTP/1.0 200 OK
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Content-Type: text/html
Date: Wed, 27 Dec 2013 15:23:45 GMT
Accept-Ranges: bytes
Content-Length: 362
X-Cache: MISS from ta-prx21
X-Cache-Lookup: MISS from ta-prx21:3128
Via: 1.0 ta-prx21 (squid/3.1.20)
Connection: keep-alive

<.h.t.m.l.>.
.
.<.b.o.d.y.>.
.
.<.d.i.v. .a.l.i.g.n.=.".c.e.n.t.e.r.".>.<.s.p.a.n. .c.l.a.s.s.=.".s.t.y.l.e.1."
        .>.U.n.d.e.r. .C.o.n.s.t.r.u.c.t.i.o.n.<./.s.p.a.n.>.<./.d.i.v.>.
.
.<.d.i.v. .a.l.i.g.n.=.".c.e.n.t.e.r.".>.<.s.p.a.n. .c.l.a.s.s.=.".s.t.y.l.e.2."
          .>.w.w.w...m.i.c.r.o.s.o.f.t...c.o.m.<./.s.p.a.n.>.<./.d.i.v.>.
.
.<./.b.o.d.y.>.
.
.<./.h.t.m.l.>.
.
.

Al acceder al dominio desde un navegador desactualizado, no se observa ningún comportamiento extraño y la respuesta es la esperada:

Con estos datos, se reafirma la hipótesis de que todo se trata de un mismo ataque.

Atribución
Al hacer whois a los dominios, aparecieron las siguientes direcciones de correo como registradores de dominio:

qingwa20112011[at]163[dot]com
dnsjacks[at]yahoo[dot]com 
usa87654310[at]126[dot]com

Tanto los dominios como las direcciones de e-mail de los registradores de los dominios apuntan a China, como se puede ver en esta lista de e-mails relacionados con ataques dirigidos con origen en China.

Haciendo una búsqueda rápida en Google de los e-mails implicados, se puede ver que la direccióndnsjacks[at]yahoo[dot]com está relacionada con una campaña Mirage, también con origen en China.

Analizando las peticiones vistas en la campaña Mirage y comparándolas con las encontradas en el ataque, se pueden apreciar ciertas similitudes.

A simple vista, se ve que utilizan los mismos campos (“hl” y “meta”). Si además añadimos otra de las peticiones de la campaña analizada por Secureworks, también aparece el campo “q”:

A continuación, se puede ver una imagen resumiendo los resultados de la investigación de la atribución.

Conclusión
Basándonos en los datos obtenidos durante la investigación, se puede concluir que el ataque venía desde China.

Además, si se analizan los receptores de los correos electrónicos, se ve que no solo iban dirigidos a una organización concreta, sino que se apuntaba a varias instituciones europeas.

Se estaba usando una infraestructura utilizada en campañas anteriores. Esto, unido al envío de correos con una gran cantidad de receptores y a la naturaleza del malware Mirage, hace que el ataque no sea silencioso, lo que hace pensar que trataba de robar algún tipo de información concreta de manera rápida (probablemente información financiera).

Este tipo de ataques es bastante común en instituciones públicas y casi siempre utilizan el spearphising como medio de infección. El uso de dominios de buena reputación, como en este caso el de una organización humanitaria muy conocida, legitima ese correo, por lo que hace muy difícil la detección.

Aun así, la prevención de estos ataques suele ser sencilla y venir de la mano de una rápida aplicación de actualizaciones y parches de seguridad, ya que en la mayoría de estos ataques no se utilizan 0days, sino vulnerabilidades conocidas y ya parcheadas. Por ejemplo, en este caso se utilizó una vulnerabilidad con más de un año de antigüedad.

Para detectar si vuestra organización se ha visto afectada por esta oleada, basta con buscar en los logs de navegación si aparece alguno de los dominios mencionados anteriormente.

Espero que os haya sido de utilidad o por lo menos una lectura interesante.

En la primera parte de esta entrada llegamos hasta el punto de sobrescribir registro EIP con el valor que nosotros queríamos. Ahora llega el momento de explotar la vulnerabilidad y ejecutar código.

Recordar que el enlace que me ha sido imprescindible para resolver el ejercicio ha sido la entrada del blog de Kroosec. En esta entrada espero, sobretodo, que quede clara la técnica para crear un ROP en múltiples fases y mostrar cuando nos puede venir bien.

Como en la primera entrada, nos plantearemos preguntas e iremos resolviéndolas hasta llegar a explotar la vulnerabilidad:

1. ¿Contra qué nos enfrentamos?
[Read more…]