Mobile

Red de publicidad instala Android FakeAV (Mobile Defender)

Hace un mes más o menos quería ver un partido de fútbol de la liga española (desde Holanda) y recurrí a la primera página de streaming que encontré, futbolenvivoaldia.com. Al final, esta página no era más que una redirección a la conocida página Tarjeta Roja. Bueno, la historia es que visitando la página con el teléfono móvil, aparecía el típico escaner antivirus y se intentaba descargar una aplicación con nombre “androidav_free.APK” (24f0a666a714e26c6c07ab407e37b112). 
 

 

 
El origen de esta pantalla era una de las redes de anuncios de tarjetaroja.eu, Mobicow, que después de varias redirecciones y URLs de tracking acababa devolviendo la siguiente URL:
 

hxxp://cleanupnowonline10.biz/?u=Y0vbAf0fW9lIhVAxPi2nZQo

 
Esta URL a su vez cargaba código Javascript desde:
 

hxxp://cleanupnowonline10.biz/js/wapc.js

 
El código estaba ofuscado, siendo éste el contenido final del archivo:  
 
 

Conferencia Troopers13 - Día 2

Comencé el día escuchando la ponencia “UI Redressing Attacks on Android Devices” de Marcus Niemietz sobre las posibilidades de engañar a los usuarios, con interfaces no visibles para ellos, que permitían realizar acciones no deseadas (tipo clickjacking). Para seguir con el tema móvil, Peter Kieserberg nos hablaba sobre códigos QR  y su uso como vector de ataque.

Después de comer fue el turno de Sergey Bratus y Travis Goodspeed que expusieron su visión sobre la seguridad de los puertos USB y cómo es posible llegar a comprometer un sistema a través de éstos. Sin duda un campo que merece atención y que puede explorarse gracias a toda la documentación que deja Travis en su blog.

 

 

Conferencia Troopers13 - Día 1

Hasta ahora no había tenido tiempo de escribir sobre mi primera Troopers, es lo que tiene cambiarse de país...El caso es que ya llevaba un tiempo queriendo asistir a esta conferencia, tenía muy buena pinta y además los comentarios sobre ella me animaban más. El año pasado tuve el placer de compartir mesa con Enno Rey, organizador de Troopers y CEO de ERNW, durante la celebración de BlackHat Europe, y ya vi que se trataba de un buen equipo con un trato muy cercano. Otros años no había podido acudir por una cosa o por otra, pero este año, viviendo a 4 horas en coche de Heidelberg, no había excusa posible.

Después de llegar a Heidelberg de madrugada debido al temporal de nieve (accidentes, carreteras cortadas y en mal estado, etc) pude descansar lo justo para estar la mañana siguiente preparado para las diferentes charlas del primer día. Eso sí, no llegué a tiempo de oír el keynote de Rodrigo Branco, pero me comentaron que estuvo bastante bien. La primera charla que vi fue la de Daniel Mende y Pascal Turbing sobre la seguridad de un modelo de cámara de fotos CANON, equipada con un adaptador wireless y demás funcionalidades. El resultado, entre otras cosas, es que se podían visualizar las imágenes realizadas, manejar el dispositivo de forma remota e interceptar las fotos al enviarlas a un servicio en la nube.

 

Sopelka VS Eurograbber: really 36 million EUR?

Ya ha pasado casi un mes de la celebración de la última edición de Rooted CON. Un año más tuve el placer de estar allí como ponente, junto con Mikel Gastesi, hablando de la botnet Sopelka y el posterior informe de Eurograbber que publicaron Check Point y Versafe. Podéis descargar la presentación desde este enlace.
 

 

NFC CreditCard Reader


 

Language: C

Publication date: 2012-12-21

Description: Program based on readnfccc (by Renaud Lifchitz) to read some private data from credit cards, like cardholder, Permanent Account Number (PAN), expiry date, etc., using NFC technology. It has been tested with Spanish contactless credit cards, but can also be used with other countries cards. Take a look at this post (Spanish) and this video.

Requirements: libnfc (and an NFC reader, of course!)

Download it!

 


Usage


 
After installing libnfc, just compile the code:

$ gcc nfc_creditcard_reader.c -lnfc -o nfc_creditcard_reader

 
Place an NFC credit card close to the reader and execute it:

Give me your credit card, the NFC way

Hace ya más de un mes realicé una presentación en la No cON Name (NcN) sobre privacidad en tarjetas de crédito NFC. No se trata de un tema nuevo, ni mucho menos, ya que sobre todo durante este año se han realizado diferentes ponencias sobre este tema a nivel internacional, aunque, hasta ese momento, no se habían hecho pruebas con tarjetas de crédito españolas (al menos de forma pública). Podéis descargar la presentación desde aquí.

 

 

Como ya comentaba en diferentes posts sobre el tema, el pago mediante la tecnología NFC se usa desde hace años en algunos países asiáticos, como Japón. Sin embargo no ha sido hasta este año 2012 cuando se ha empezado a impulsar en España con diferentes iniciativas promovidas por varias entidades bancarias. El resultado es que ahora mismo más de una persona puede tener una tarjeta de crédito NFC en su cartera sin ni siquiera saberlo. Esto no debería ser un problema si los datos estuvieran bien protegidos, pero esto es algo que no se puede dar por supuesto, de ahí el origen de esta presentación.

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.

writeURItoNFCtag


 

Language: Python

Publication date: 2012-07-01

Description: Simple script to write any URI to an NFC tag. Using the 0x00 URI type we can write any type of URI in the tag, without thinking about it. Based on the helloworld.py (nfcpy) script. You can take a look at the different URIs defined by the specification here and other special URIs related to installed mobile applications.

Requirements: nfcpy

Download it!

 


Usage


 

Usage: writeURItoNFCtag.py uri

 

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.

Más información y reflexiones sobre ZeuS MitMo

Hace mes y medio David Barroso y yo nos fuimos de visita a casa de un usuario de banca electrónica que vivía en un pueblo de Navarra. David extrajo un archivo de su teléfono móvil y yo recuperé algunos archivos relacionados con dos infecciones de ZeuS. Este fue el inicio del llamado ZeuS MitMo.

Cuando ZeuS inyecta código HTML, normalmente solicita al usuario que ingrese la clave de firma o las posiciones de la tarjeta de coordenadas para poder realizar transferencias fraudulentas, pero a veces esta información no es suficiente. Algunos bancos solicitan además un código, enviado a través de SMS, que el usuario (o el criminal) deberá introducir para completar la transacción. Cuando el MitMo no existía, esta segunda autenticación era un éxito, pero no a partir de aquel día. El grupo responsable de esta nueva oleada de infecciones se había preocupado de modificar las inyecciones HTML para solicitar, además de los datos habituales, el número de teléfono móvil. Ya lo habíamos visto anteriormente, pero hasta el momento nunca se había usado para cometer el fraude. En esta ocasión, una vez introducido el número de teléfono, los delincuentes enviaron un SMS a la víctima donde se incluía un enlace y se instaba al usuario a instalar un “certificado”. Cuando el usuario lo hizo, una aplicación maliciosa comenzó a monitorizar los mensajes entrantes en busca de los remitidos por el banco en cuestión, y reenviándolo a los criminales. De esta forma, tenían en su poder toda la información necesaria para poder realizar la transacción de forma satisfactoria.

More about the JailbreakMe PDF exploit

Today has been released the source code of the Jailbreakme exploit, so maybe this explanation comes a bit late. In the update of the previous post about this subject I knew that I was right about the overflow in the arguments stack when parsing the charstrings in the Type 2 format, so here is a little more info.

After decoding the stream of the object 13 we can see the following bytes (talking about this file):

cff_bytes

The selected bytes are the important ones for this exploit because the overflow occurs when parsing them. Like I mentioned, the Type 2 format is composed of operands, operators and numbers, and use the stack to push and pop values. This stack has a maximum size of 48 elements. We can understand better the meaning of these bytes with this tips:

 

About the JailbreakMe PDF exploit

Some days ago Comex published his JailbreakMe for the new iPhone 4 in the Defcon 18. The interesting thing is that in order to root the device he used a PDF exploit for Mobile Safari to execute arbitrary code and after this another kernel vuln to gain elevated privileges. I've being taking a look at the PDF files with peepdf and these are my thoughts about it.

The PDF file itself has no many objects and only one encoded stream:

The stream is encoded with a simple FlateDecode filter, without parameters, and if we decode its content we can see this strings, related to the JailbreakMe stuff:
 
As this object seems to contain the vulnerability we are looking for we'll take a closer look to this stream and what this is for:
 

Recovering deleted SMS from the SIM card

Some time ago I wanted to recover the deleted SMS from a friend's SIM card and I tried to find some programs to do it. After some time searching the web I found SIMCon and SIMEditor which made well the job, showing all the SMS slots, deleted and not, with the help of a SIM reader, of course. I was curious about the raw process of these programs so I search the web again ;)

First of all we'll need some software to send commands to the SIM card. I'm a Linux user so I used scriptor, contained in the pcsc-tools package. We need to know what to send and what the SIM card structure is. For this we have the GSM specification, a brief resume of the commands we must send and we can receive, and some information about the directories within a SIM card. These commands are called Application Protocol Data Units (APDU). After reading this links we know that we have to send the following commands:

  • VERIFY CHV (20): PIN authentication.
  • SELECT (A4): selection of the file we want to work with.
  • GET RESPONSE (C0): read the response data.
  • READ RECORD (B2): read the specified record.

Distribuir contenido