Blogs

Destapando el "nuevo" Eurograbber: ¿36 millones de euros realmente?

Eurograbber ha llegado para quedarse. Hace unos días Versafe y Check Point Software Technologies publicaron un informe sobre una “nueva” amenaza titulado “A Case Study of Eurograbber: How 36 Million Euros was Stolen via Malware”. Como se puede ver, el título es bastante sensacionalista. Si estuviera bien fundamentado no tendría nada que decir, pero resulta que no se trata de algo tan nuevo, ya que se habla sobre algo que escribí a finales de septiembre cuando todavía trabajaba en S21sec. Entonces lo llamé Botnet Sopelka.

Aparte de ser algo nuevo o no (creo que quien más quien menos alguna vez ha creído ser el primero en algo cuando no lo era), este informe incorpora unas estadísticas sobre usuarios/bancos afectados y, quizá lo más importante, las cantidades robadas en cada país por los ciberdelincuentes: más de 16 millones de euros en Italia, casi 13 millones de euros en Alemania, casi 6 millones de euros en España y más de un millón de euros en Holanda. En total más de 36 millones de euros, como dice el título del informe. Teniendo en cuenta los duros momentos que estamos viviendo en Europa es para pararse a pensar en ello, verdad?

Este informe y, sobre todo, estas cantidades robadas han aparecido publicadas en gran cantidad de medios online, propagándose más rápido que cualquiera de los conocidos troyanos bancarios. Es por eso que me gustaría hacer algunos comentarios sobre el propio informe y estas sorprendentes estadísticas:

 

Botnet Sopelka: tres troyanos bancarios y un sólo panel

La botnet Sopelka empezó a gestarse en mayo de este año y su actividad cesó a finales del mes pasado. Tiene el nombre Sopelka debido al path usado en la distribución de binarios y archivos de configuración, y era una curiosa mezcla de variantes de los conocidos troyanos bancarios Tatanga, Feodo y Citadel. El objetivo de esta botnet era la recolección de credenciales bancarias de entidades europeas, afectando en gran medida a España y Alemania, pero también a Holanda, Italia y Malta. Además, se hacía uso de diferentes componentes móviles para teléfonos Android, BlackBerry, y también Symbian, el primer sistema operativo  detectado con este tipo de componente malicioso, hace ya más de dos años.
Durante el tiempo de actividad de la botnet se realizaron por lo menos cinco campañas, aunque seguramente se hubieran realizado más. De estas cinco campañas tres de ellas instalaban variantes de Citadel (versiones 1.3.4.0 y 1.3.4.5), otra, Feodo, y en la restante fue Tatanga el troyano elegido. Todas las campañas de Citadel llevaban la palabra "sopelka" (un tipo de flauta, en ruso) en su path de descarga, tanto de binarios como de archivos de configuración, pero no así en el caso de Tatanga y Feodo.

0-day en Java 1.7.x sin parche oficial: resumen de ideas y análisis

El pasado domingo se publicó una vulnerabilidad en el blog de FireEye  que afecta a la última versión de Java (1.7.x) y que se utilizó en un ataque dirigido, usando el RAT Poison Ivy como malware ejecutado, y con poca propagación del exploit. Eso fue hasta que se publicó el código fuente en pastie.org, como antesala de la publicación de un módulo de Metasploit. El código asignado para esta vulnerabilidad es CVE-2012-4681.

Crónica de Black Hat y DEF CON (Las Vegas, 2012)

Hace poco más de una semana se celebraron las dos míticas conferencias de seguridad en Las Vegas, Black Hat y DEF CON. Además, también a la vez tenía lugar la BSidesLV y algunos otros eventos para los que se necesitaba invitación, como el de IOActive. Tuve la suerte de estar por allá y vivir todo eso en primera persona, ya era hora ;) No voy a hacer un post detallado de todo esto, sino más bien un resumen rápido de todo lo que se vio por allá y las sensaciones del post-Vegas. 

La Black Hat comenzó el 21 de julio con una lista bastante larga de trainings que duraron hasta el 24. Posteriormente comenzaron las charlas, workshops y arsenal, donde más gente había, que transcurrieron durante el miércoles 25 y jueves 26. Según me comentaron este año hubo más gente que el anterior, unas 7500 personas.

Nuevo peepdf v0.2 (versión Black Hat Vegas)

Hace unos días tuve la oportunidad de presentar en las Vegas una nueva versión de peepdf, la 0.2. Ya habían pasado unos cuantos meses desde mi última release en Black Hat Amsterdam, así que ya tocaba volver a empaquetar. Podéis bajar la nueva versión desde aquí o ejecutar "peepdf -u" para actualizarla directamente desde el repositorio.

Además de los diferentes bugs corregidos, éstas son las principales novedades:

  • Soporte para AES en el proceso de descifrado: Hasta ahora peepdf soportaba RC4 como algoritmo de descifrado, pero AES estaba en el TODO debido a las diferentes muestras que usaban este algoritmo para ocultar contenido malicioso. Según me comentaron en Las Vegas parece que habrá próximas modificaciones en la especificación PDF en este aspecto, por lo que es posible que haya más cambios en un futuro cercano.

Comprueba si leer un tag NFC es seguro

Como adelantamos en el anterior post, una de las utilidades de NFC es el uso de NFC Forum tags para guardar e intercambiar información, normalmente de tipo comercial. Estos tags deben ser fieles a una especificación determinada: el formato NDEF (NFC Data Exchange Format). Gracias a este formato es posible intercambiar mensajes NDEF entre las diferentes partes, pudiendo tener cada mensaje diferentes registros donde almacenar información. El tipo de información que se puede introducir en estos registros es variado, y puede ir desde texto simple a diferentes formatos de audio o vídeo (media), pasando por una URI para realizar acciones automáticas en el dispositivo lector, normalmente un teléfono móvil. Podéis echar un vistazo a la especificación de NDEF para profundizar más en el tema.

En este post nos vamos a centrar en las posibilidades que ofrecen los registros de tipo URI y qué acciones se pueden realizar al leerse en un teléfono móvil con tecnología NFC. Los tipos de URI que se aceptan según la especificación son los siguientes:

NFC práctico: monta tu propio laboratorio

NFC es la tecnología del futuro, o mejor dicho, del presente. Ya son muchos los lugares del mundo donde se está apostando por su uso, ya sea para micropagos, transporte, sistemas de acceso y casi todo lo que se nos pueda ocurrir (en países como Japón o Corea hace años que se usa de forma habitual). Incluso se puede realizar la lectura de tags desde un teléfono móvil con esta tecnología para realizar acciones como silenciar el teléfono, sincronizar datos, etc.

peepdf supports CCITTFaxDecode encoded streams

Stream filters, as I said some time ago, are a good way of obfuscating PDF files and hide Javascript code, for instance. Some weeks ago a post related to the use of the /CCITTFaxDecode filter was published by Sophos, although the Malware Tracker guys tracked a similar document created more than one year ago. Bad guys were using the /CCITTFaxDecode filter with some parameters to obfuscate the documents and try to bypass analysis tools and Antivirus. This filter was not supported by peepdf until the moment, so Binjo ported the Origami decoder to Python to include it (Thanks man!). Today I have uploaded the code and now peepdf also supports this filter :)

I've performed a quick analysis of the Sophos' document (6cc2a162e08836f7d50d461a9fc136fe) and it seems to work well:

 

 

We can identify two known vulnerabilities and it seems that object 30 contains Javascript code. If we take a look at the filters used in this stream we see that peepdf has been able to decode the /CCITTFaxDecode filter without problems:

 

New version of peepdf (v0.1 r92 - Black Hat Europe Arsenal 2012)

Last week I presented the last version of peepdf in the Black Hat Europe Arsenal. It was a really good experience that I hope I can continue doing in the future ;) Since the very first version, almost one year ago, I had not released any new version but I have been frequently updating the project SVN. Now you can download the new version with some interesting additions (and bugfixes), and take a look at the overview of the tool in the slides. I think it's important to mention that the version included in the Black Hat CD and the one in the Black Hat Arsenal webpage IS NOT the last version, this IS the last version. I've asked the Black Hat stuff to change the version on the site so I hope this can be fixed soon.
 

Sexo, Exploit Kits y Ransomware

Para gustos los colores. Cada uno tiene gustos diferentes y más si hablamos de artistas y actrices. A algunos les gusta Carlos Latre o Dani Martinez, a otros Lady Gaga o Camela y otros se decantan por Laura Lion o Nacho Vidal. No pasa nada con esto, a no ser que el hecho de visualizar algunos vídeos de estos profesionales pueda llevar a que tu equipo se infecte y no puedas volver a usarlo a no ser que pagues por ello. Esto es lo que le pasó a un conocido debido a su amor por la mencionada Laura Lion.
 
 

How to extract streams and shellcodes from a PDF, the easy way

Maybe it was not evident enough or not well documented, but until the moment there was a way of extracting streams, Javascript code, shellcodes and any type of information shown in the console output. What it's true is that it was not very straightforward. To extract something it was needed to set the especial variable "output" to a file or variable in order to store the console output in that new destination. For this to be accomplished we used the set command and after this the reset command to restore the original value of "output".

 

PPDF> set output file myFile
PPDF> rawstream 2

78 da dd 53 cb 6e c2 30 10 bc f7 2b 22 df c9 36 |x..S.n.0...+"..6|
39 54 15 72 c2 ad 3f 40 39 57 c6 5e 07 43 fc 50 |9T.r..?@9W.^.C.P|
6c 1e fd fb 6e 4a 02 04 54 a9 67 2c 59 9e 9d f5 |l...nJ..T.g,Y...|
8e 77 56 32 5f 9c 6c 9b 1d b0 8b c6 bb 8a 15 f9 |.wV2_.l.........|
2b cb d0 49 af 8c 6b 2a b6 fa fc 98 bd b3 45 fd |+..I..k*......E.|
92 d1 e2 27 15 e6 b4 33 aa 70 b1 47 15 db a4 14 |...'...3.p.G....|
e6 00 2e e6 42 f9 35 e6 d2 5b a0 04 b0 73 09 15 |....B.5..[...s..|
a1 aa 77 22 08 0e 04 46 4e 7a a7 4d 43 3a 92 84 |..w"...FNz.MC:..|
2e 22 c7 e3 31 b7 46 76 3e 7a 9d 72 df 35 10 e5 |."..1.Fv>z.r.5..|
06 ad 80 93 34 50 e6 6f 57 51 92 08 1d 46 74 e9 |....4P.oWQ...Ft.|
ca f4 9c d2 b7 31 31 83 af ba e0 30 c2 e9 05 bd |.....11....0....|
55 bb 36 8a ad f6 2a fc 1e 61 ab e8 5a ad 39 fc |U.6...*..a..Z.9.|
95 9a 0a 18 97 b0 13 32 99 03 f6 af dc 86 b7 ad |.......2........|

Dynamic analysis of a CVE-2011-2462 PDF exploit

After the exploit static analysis some things like the function of the shellcode were unclear, so a dynamic analysis could throw some light on it. When we open the exploit without the Javascript code used for heap spraying we obtain an access violation error in rt3d.dll. If we put a breakpoint in the same point when we launch the original exploit we can see this (better explanation of the vulnerability):

 

Instead of showing an access violation the CALL function is pointing to a valid address in icucnv36.dll, 0x4A8453C3. This address is not random and it's used in the Javascript code to perform part of the heap spraying:

 

 

 

Static analysis of a CVE-2011-2462 PDF exploit

CVE-2011-2462 was published more than one month ago. It's a memory corruption vulnerability related to U3D objects in Adobe Reader and it affected all the latest versions from Adobe (<=9.4.6 and <= 10.1.1). It was discovered while it was being actively exploited in the wild, as some analysis say. Adobe released a patch for it 10 days after its publication. I'm going to analyse a PDF file exploiting this vulnerability with peepdf to show some of the new commands and functions in action.

As usual, a first look at the information of the file:

info

I've highlighted the interesting information of the info command: one error while parsing the document, one object (15) containing Javascript code, one object (4) containing two ways of executing elements (/AcroForm, /OpenAction) and one U3D object (10), suspicious for its known vulnerabilities, apart of the latest one.

So we have several objects to explore, let's start from the /AcroForm element (object 4):

BlackHole leading to Feodo: Bank of America account frozen

I've received a Christmas gift some hours ago. In fact there were two gifts but only one has survived the trip. They are from Russia...with love. Of course I'm talking about two e-mails I've received with two suspicious links. Even the e-mail bodies were suspicious, I think they have packed very quickly my gifts or they are not very attentive to me...:( The From field included "bankofamerica" and the Subject "Accountfrozen" so I suppose this means that my Bank of America account is frozen, right?

After some redirections we can find the typical obfuscated Javascript code made in BlackHole:
 

After decoding the Javascript code we obtain the next step, also related to BlackHole. This time I can only see a unique Flash exploit trying to download and execute a binary from the same domain where the exploit kit is located (shellcode is XORed with 0x28).

Campaña navideña de robo de contraseñas

En estos días tan señalados, y como viene siendo habitual, proliferan las campañas realizadas a través de correo electrónico, con temática navideña, con la intención de vender Viagra, distribuir malware o intentar robar contraseñas de correo. Estos días he recibido varios correos de mis contactos para que visitara una postal navideña de un usuario anónimo, en nombre de Correos.

Está claro que no tiene buena pinta, y si seguimos el enlace nos encontramos con una pantalla de login, donde debemos meter nuestra contraseña de correo para, supuestamente, ver nuestra postal. Este login aparece en primer plano, mientras que de fondo se carga la página legítima de Correos para parecer más real y verídico.

Nuestra cuenta de correo se pasa como parámetro al pulsar el enlace y está codificada en Base64:

Distribuir contenido