S21sec Blog. Seguridad digital.

NFC práctico: monta tu propio laboratorio

noreply@blogger.com (S21sec Labs) — Wed, 23 May 2012 14:36:25 PDT

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

noreply@blogger.com (S21sec Labs) — Thu, 17 May 2012 10:19:08 PDT

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

noreply@blogger.com (S21sec Labs) — Thu, 17 May 2012 00:39:57 PDT

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

noreply@blogger.com (S21sec Labs) — Fri, 11 May 2012 02:57:16 PDT

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

noreply@blogger.com (S21sec Labs) — Wed, 09 May 2012 02:27:51 PDT

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?

noreply@blogger.com (S21sec Labs) — Thu, 03 May 2012 08:04:25 PDT

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

noreply@blogger.com (S21sec Labs) — Wed, 02 May 2012 01:18:23 PDT

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

En 2011 se detectó un incremento del 21% en los ataques a dispositivos móviles

noreply@blogger.com (S21sec Labs) — Thu, 29 Mar 2012 00:31:56 PDT

Presentamos el segundo Informe sobre Malware en Smartphones, informe que nos permite reflejar la situación actual respecto a la seguridad de los smartphones, describiendo las principales amenazas detectadas, así como las medidas existentes para mitigar los riesgos asociados.

La popularización de este tipo de dispositivos ha sido vertiginosa, sobre todo debido a la gran oferta de tarifas planas que ofrecen todos los operadores y al acceso a atractivas aplicaciones gratuitas o de pago en las diversas plataformas, ya sean para el uso privado o profesional.

El principal problema detectado a raíz del estudio, es que los usuarios no son conscientes de los peligros que entraña no tener protegido su dispositivo móvil y como consecuencia de esto, las mafias existentes han ampliado sus horizontes de actuación y han incluido este sector entre sus objetivos. Un objetivo de gran crecimiento y alta remuneración.

La limitada concienciación en lo referente a seguridad de los usuarios y su consecuente comportamiento pueden ser los factores de mayor riesgo para los smartphones a corto plazo, por lo que en el informe, además de analizar los principales ataques que se han dado durante el 2011, se facilitan las claves para proteger nuestros dispositivos móviles:

Recomendaciones para proteger nuestro smartphone

Habilitar medidas de acceso al dispositivo como el PIN o contraseña si está disponible.
Configurar el smartphone para su bloqueo automático pasados unos minutos de inactividad.
Sólo instalar aplicaciones que provengan de fuentes de confianza.
Prestar atención a los permisos solicitados por las aplicaciones y servicios a instalar.
Mantener el software actualizado, tanto el sistema operativo como las aplicaciones.
Deshabilitar características mientras no se usen: Bluetooth, infrarrojos o Wi-fi.
Configurar el Bluetooth como oculto y con necesidad de contraseña.
Realizar copias de seguridad periódicas.
Cifrar la información sensible cuando sea posible.
Utilizar software de cifrado para llamadas y SMS.
Siempre que sea posible no almacenar información sensible en el smartphone.
Al deshacerse del smartphone borrar toda la información contenida en el dispositivo.
En caso de robo o pérdida del smartphone informar al proveedor de servicios aportando el IMEI del dispositivo para proceder a su bloqueo.
En determinados casos utilizar opciones de borrado remoto o automático después de varios intentos de acceso fallidos.
Monitorizar el uso de recursos en el smartphone para detectar anomalías.
Revisar facturas para detectar posibles usos fraudulentos.
Mantener una actitud de concienciación en el correcto uso de estos dispositivos y los riesgos asociados.
Extremar la precaución al abrir un correo, un adjunto de un SMS o hacer click en un enlace. Cabe destacar que ésta fue una de las vías de entrada del Zeus-Mitmo.
Desconfiar de los archivos, enlaces o números que vengan en correos o SMS no solicitados.
Evitar el uso de redes Wi-fi que no ofrezcan confianza.
Tener en cuenta este tipo de dispositivos en su política de seguridad corporativa.
Restringir las llamadas y mensajes a números premium, al extranjero o por lo menos su control, como puede ser el establecimiento de límites de gasto o alertas a partir de cierto gasto. Los operadores suelen tener estos servicios que si bien no son muy conocidos pueden ser de gran ayuda.
Prestar especial atención a los comportamientos extraños del teléfono, como llamadas o mensajes no requeridos o una descarga de la batería anormal, así como esperas anormales para abrir aplicaciones.

Con este informe, ofrecemos una visión de la evolución de los distintos tipos de fraude online que afectan a los smartphones en los últimos meses. Puedes descargarte el informe completo aquí.

S21sec

En 2011 en S21sec detectamos 7.000 vulnerabilidades

noreply@blogger.com (S21sec Labs) — Wed, 14 Mar 2012 01:25:21 PDT

Presentamos el primer ‘Informe de Vulnerabilidades’ elaborado por el equipo de Ecrime donde se recogen los datos de las vulnerabilidades detectadas por S21sec en la última década. Este informe, pretende constituir una radiografía de las principales amenazas que afectan en la actualidad tanto a empresas e instituciones como a usuarios.

2011 ha sido un año marcado por la aparición de un elevado número de vulnerabilidades de alto riesgo y el número de vulnerabilidades se mantuvo relativamente constante entre un mes y otro, a excepción de marzo. El tercer mes del año registró un elevado número de vulnerabilidades sobre software de Apple que afectaron a un gran número de sus productos tales como iTunes, Safari, Apple IOS, Mac OSX, iPhones IOS, entre otros.

Se puede decir que hemos detectado un aumento de las vulnerabilidades, con un aumento de las explotaciones remotas de vulnerabilidades y una sofisticación de los troyanos orientados a la industria como ha sido el caso de Stuxnet o Duqu. Asímismo se puede observar una tendencia cambiante en los navegadores donde se refleja un cambio en la explotación de vulnerabilidades de Firefox a Chrome ya que este último está siendo el que mayor cota de mercado está alcanzando.

Este año seguiremos viendo un incremento de vulnerabilidades a dispositivos móviles gobernados por sistemas operativos como Android o iPhone OS. Actualmente existen unos 5.600 millones de móviles en funcionamiento (alrededor de un 77% de la población mundial dispone de uno), de los cuales unos 468 millones son smartphones y se estima que la cifra crecerá hasta 631 millones en 2015, por lo que, lógicamente, a más usuarios y más dispositivos se incrementará también el riesgo de vulnerabilidades.

El ‘Informe de Vulnerabilidades 2011’, elaborado por la unidad Ecrime de S21sec puede descargarse aquí.

S21sec

Campaña de spam simulando ser la Agencia Tributaria

noreply@blogger.com (S21sec Labs) — Wed, 15 Feb 2012 03:26:13 PST

Se tiene conocimiento de una campaña de fraude en la que los defraudadores se están haciendo pasar por la Agencia Tributaria española. El método de comunicación de esta campaña fraudulenta es mediante correos de spam.

En estos correos de spam, los delincuentes se identifican como la Agencia Tributaria, falseando el remitente del correo, y se nos informa de un supuesto reembolso que quieren hacernos efectivo, pero para el cual necesitan que les facilitemos primero ciertos datos..

Correo de spam, simulando ser la Agencia Tributaria

En el correo viene adjunto un fichero html, el cual nos invitan a descargar y abrir en nuestro navegador, para entonces rellenar los "datos necesarios", entre los que están los datos de la tarjeta de crédito.

Formulario fraudulento

Como es obvio, el formulario es falso y envía los datos a un servidor localizado en EEUU:

Servidor que recoge los datos robados

Un rápido vistazo al correo nos da una idea de que estamos ante un fraude, porque en la gran mayoría de los casos hay faltas de ortografía evidentes, o expresiones que resultan extrañas:

"..usted es elegible.."
"Descargue el formulario de devolución de impuestos unida a este mensaje.."
"Un reembolso se puede retrasar para una variedad de razones. Por ejemplo, la presentación registros inválidos o la aplicación después de la fecha límite."

Como conclusión, unas breves consideraciones:

- No facilitar los datos de la tarjeta (incluido el código de seguridad CVV), salvo en sitios web de confianza.
- La AEAT dispone a priori de todos nuestros datos.
- Dados los tiempos que corren resulta sospechoso que la Agencia Tributaria se ponga en contacto con nosotros por correo para devolvernos cualquier cantidad de dinero, ¿verdad?

Como siempre, el sentido común es el mejor aliado contra este tipo de fraudes.

Saludos.
Rubén Piñero
S21sec ecrime

Citadel, nuevo branch de ZeuS

noreply@blogger.com (S21sec Labs) — Fri, 10 Feb 2012 06:26:39 PST

Google Chrome es a día de hoy el segundo navegador más usado, por lo que era evidente que los troyanos bancarios más populares debían comenzar a soportarlo, pero este paso ha tardado más de la cuenta.

Citadel es una nueva ramificación de ZeuS, basada en el código fuente de la versión 2.0.8.9 filtrada un año atrás, y que ha formado un círculo social en el que los usuarios pueden solicitar nuevas funcionalidades y votar por las que más gusten. Como curiosidad, y como detalle de la profesionalización, vemos que tienen “horario laboral”, y los fines de semana no se responderá a los mensajes enviados. Podemos ver más detalles sobre esto en dos post de Brian Krebs (1 y 2).

Por supuesto, vista la orientación tomada por sus creadores, dos cambios muy importantes que ya están implementados son un cambio de cifrado y la afectación a Google Chrome.

Dentro de la afectación, vemos un detalle curioso, y es que algunos de los hooks establecidos no son detectados por las comprobaciones habituales, y es que estos hooks no están establecidos en funciones exportadas, sino que se establecen en funciones no exportadas de la librería chrome.dll. Estas funciones son:

SSLClientSocketNSS::Connect
SSLClientSocketNSS::Disconnect
SSLClientSocketNSS::Read
SSLClientSocketNSS::Write
TCPClientSocketWin::Connect
TCPClientSocketWin::Disconnect
TCPClientSocketWin::Read
TCPClientSocketWin::Write

En las siguientes dos imágenes se puede observar el hook establecido en "Connect".

Connect normal

Connect hookeado

Respecto al cifrado, comentar que en la última muestra analizada, el fichero de configuración se cifra con AES, tanto el descargado desde la web como el almacenado en el registro, pero el tráfico enviado al panel, como puede ser la petición de dicho fichero, que en este caso incluye una pequeña autenticación, sigue estando cifrada con RC4 + VisualEncrypt (xor).

Realmente son unos cambios muy interesantes y, al estar en pleno proceso de desarrollo, es de esperar que vayan surgiendo nuevas versiones con más funcionalidades y con mayor frecuencia que otras familias ya clásicas como pueden ser ZeuS y SpyEye.

Jozsef Gegeny & Mikel Gastesi

S21sec ecrime

Uno de febrero, día de cambiar contraseñas

noreply@blogger.com (S21sec Labs) — Thu, 29 Mar 2012 00:50:25 PDT

Desde Gizmodo se está promocionando ayer, el día 1 de febrero, como día de referencia para el cambio de contraseñas. Es una iniciativa interesante ya que marca un día destacado al año para recordar que es necesario el cambio de contraseñas. Cabe destacar que, en muchos casos, la contraseña es el único factor de autenticación para acceder a servicios como el de e-mail, redes sociales, etc.

Por ello, es fundamental que las contraseñas que se utilicen sean lo más seguras posibles.

Para poder decidir si la contraseña es segura es necesario conocer qué métodos usan los delincuentes informáticos de forma habitual, con la intención de (para) dificultar su tarea...

Los principales métodos de ataque para obtener las contraseñas son:

Ataques de diccionario: Se comprueba si la contraseña coincide con una lista de palabras anteriormente confeccionada. Esta listas, llamadas diccionarios, pueden ser de distinta temática, idioma, etc."
Ataques de fuerza bruta: Un ataque de fuerza bruta consiste en ir probando todas las combinaciones posibles de un conjunto de letras, símbolos y números previamente seleccionados, hasta dar con la contraseña.
Ataques de ingeniería social: Los ataques de ingeniería Social consisten en manipular y engañar al usuario para que de manera voluntaria, exponga su contraseña (o datos sensibles para forzar su recuperación).

Una vez expuestos los principales métodos para obtener contraseñas hay que desgranar los puntos para neutralizar estas amenazas de la manera más efectiva posible.

Una buena contraseña no debe ser una palabra que exista. Es la mejor manera de asegurarse de que la palabra elegida no está en los diccionarios del atacante. Cuanto más larga sea la contraseña más tiempo costará extraerla mediante fuerza bruta.

Además, si se utilizan mayúsculas, minúsculas, números y caracteres especiales, se provocará que el proceso sea más lento todavía, ya que hay que comprobar muchos más posibles valores, volviendo la contraseña más segura.

Es importante también no revelar bajo ningún concepto nuestras contraseñas a nadie.

Tampoco es conveniente utilizar una misma contraseña para servicios diferentes ya que si se compromete la contraseña todos los servicios que la compartan serán vulnerables (además de que en este caso habrá que cambiar muchas contraseñas para corregir el compromiso mientras que con el método de la contraseña única para cada servicio, con cambiar la del servicio afectado sería suficiente.)

Este último punto plantea la dificultad de recordar muchas contraseñas diferentes. Para solucionarlo, hay métodos que pueden facilitar el proceso:

El primer método es utilizar un programa de gestión de contraseñas como puede ser KeePass. KeePass es un programa gratuito open source que permite gestionar multitud de contraseñas de una manera muy cómoda. Sólo será necesario recordar una contraseña maestra que nos permitirá acceder a nuestro "llavero" de claves. Muy cómodo, con funciones muy bien pensadas y muy sencillo de utilizar. Se puede obtener aquí.

El otro método es la generación de contraseñas mediante un patrón.

1. Vamos a escoger un par de versos de una canción. Para este ejemplo se utilizarán dos estrofas de una canción de Rick Astley.

Las estrofas dicen así:

"Never gonna give you up

Never gonna let you down"

2. Vamos a seleccionar la primera letra de cada palabra. Quedará así:

NggyuNglyd

3. Ahora sustituiremos alguna letra por un carácter numérico. En éste se van a sustituir la letra g por 8. Nos queda así:

N88yuN8lyd

4. Como siguiente paso, añadiremos algún símbolo para que la contraseña sea todavía más segura:

@N88yuN8lyd!

5. Por último, añadiremos al principio o al final las 3 o 4 primeras letras del servicio para el que estamos creando la contraseña. De ésta manera aunque la base de la contraseña sea la misma, cambia para cada servicio diferente.

Es importante recalcar que en casos en los que se busque una mayos seguridad habría que hacer alguna operación sobre las letras que añadimos para identificar el servicio, para que el método resulte menos llamativo, como por ejemplo sustituir las letras que vamos a añadir por las siguientes en el alfabeto (o cualquier permutación que dificulte la identificación del patrón utilizado) aunque es un paso que se va a omitir en este tutorial.

Un par de ejemplos de cómo quedaría la contraseña según el servicio.

En una cuenta de google: @N88yuN8lyd!goog

En una cuenta de S21sec: @N88yuN8lyd!S21s

De ésta manera, se obtendrá una contraseña segura para cada servicio.

Es muy habitual que muchos servicios ofrezcan un servicio de recuperación de contraseñas mediante preguntas y respuestas (que decidimos al registrar el servicio). Una costumbre muy recomendable es que la respuesta que se dé a esas preguntas, no tenga ninguna relación con la pregunta ya que es relativamente fácil ( y hoy en día más aún con el auge de las redes sociales) obtener respuestas a preguntas típicas como el apellido de soltera de nuestra madre, colegio en el que estudiamos... etc.

Si se cumplen todos estos consejos, obtendremos una contraseña robusta que permitirá incrementar nuestra seguridad.

Resumiendo: Hay que cambiar periódicamente todas las contraseñas sobre las que se quiera mantener una mínima seguridad. Recordemos cambiarlas por lo menos una vez al año. El uno de febrero no es mala fecha para ello!

Mario González

S21sec ecrime

Se acabo el Pass-the-hash

noreply@blogger.com (S21sec Labs) — Wed, 01 Feb 2012 00:39:14 PST

Tradicionalmente se ha considerado que Windows no almacenaba las credenciales de sistema en claro en ningún momento. Ni siquiera en memoria, para evitar que pudiesen ser recuperadas de un equipo comprometido. La propia documentación de Microsoft inducia a ello.

Es por esto que se han popularizado en el mundo del pentesting las técnicas de Pass-the-hash para poder obtener acceso a otros equipos de la red desde un sistema comprometido sin tener acceso a las credenciales en claro (aprovechando las características de la autenticación NTLM de Windows).

Pero un investigador francés apodado "Gentil Kiwi" ha desvelado que esto no es del todo cierto. Veamos porque:

Dentro del sistema LSA (Local Security Authority) de Windows existen una serie de proveedores de autenticación activos por defecto, que podemos listar accediendo a su configuración en el registro: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages

A primera vista muchos de estos nombres no revelan su utilidad. El más importante es MSV1_0 que es el utilizado para los procesos de logon en local si no existe un proceso de autenticación personalizado. Cuando un usuario accede al equipo el servicio de LSA llama a MSV1_0 para que procese los datos recibidos por GINA (Graphical Identification and Authentication) desde el proceso Winlogon.

Además este proveedor almacena las contraseñas en memoria en forma de hashes, como estaba previsto, de manera que es relativamente seguro. Pero de la lista que hemos visto antes; ¿harán todos lo mismo?

Pues parece ser que al menos 2 de ellos no lo hacen así: tspkg y wdigest

Tspkg es un proveedor de servicios de seguridad para conexiones SSO (Single-sign-on) con Terminal Server. Está disponible por defecto en los sistemas Windows Vista y posteriores.

Wdigest es un proveedor de servicios de seguridad para conexiones HTTP que requieran autenticación de tipo Digest. Está disponible por defecto en los sistemas Windows XP y posteriores.

Ambos almacenan en memoria las credenciales de los usuarios que hayan accedido al sistema en local o mediante escritorio remoto codificadas de forma reversible. Es decir, la contraseña puede ser obtenida en claro sin necesidad de un proceso de cracking.

Aunque no conectemos nunca con servidores que requieran autenticación de tipo Digest o no utilicemos nunca conexiones de escritorio remoto con SSO, tendremos alguno de estos 2 módulos habilitados por defecto y nuestras contraseñas estarán accesibles en memoria.

Para recuperar las credenciales en claro solo es necesario contar con privilegios de Debug sobre el proceso LSASS. Privilegios normalmente disponibles para los usuarios del grupo de administradores.

Podemos comprobarlo con la herramienta que el propio "Gentil Kiwi" nos proporciona: mimikatz

Esta demostración esta realizada en un sistema Windows 7, pero cualquier Windows XP o posterior sería vulnerable por defecto.

Solo nos queda preguntarnos porque este hecho ha tardado tanto tiempo en salir a la luz. ¿Se ha ocultado intencionadamente esta información por parte de Microsoft? ¿Los investigadores punteros en materia de seguridad tenían guardado este as en la manga? ¿O tal vez nadie se había dado cuenta antes?

Ramón Pinuaga
Dep. Auditoría S21SEC

Sexo, Exploit Kits y Ransomware

noreply@blogger.com (S21sec Labs) — Sun, 05 Feb 2012 13:02:08 PST

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.

El caso es que el sistema no se podía utilizar, ya que nada más arrancar, y pasados unos segundos de que apareciera el Escritorio, sólo se podía ver una pantalla con un aviso, supuestamente enviado por el “Cuerpo Nacional de Policía”, alertando de que el equipo se había usado para realizar acciones ilegales tales como pornografía infantil, temas relacionados con terrorismo, violencia sobre menores, etc. : "Fue detectado un caso de actividad ilegal. El sistema operativo fue bloqueado por violación de las leyes de España!". Realmente es un aviso impactante para un usuario normal y puede llegar a preocupar bastante, por lo que se puede decir que la ingeniería social en este caso ha superado con creces su propósito de engañar. Sin embargo, el aviso también menciona que si se quiere quitar el bloqueo del ordenador se debe pagar una multa de 100€ mediante los sistemas de pago Ukash o Paysafecard, dato del que se puede desconfiar con facilidad y hace que se llame casi de inmediato al teléfono de la policía. Una vez que esta pantalla aparecía no se podía ejecutar el Administrador de Tareas, volver al Escritorio ni realizar ninguna otra acción.

Después de analizar el sistema infectado en Modo Seguro y sabiendo cuándo se utilizó correctamente por última vez se puede realizar una búsqueda de archivos creados ese día, estableciendo una línea temporal, y así conocer cómo se llegó a infectar el equipo. Gracias a esto se puede encontrar el ejecutable en cuestión y otros archivos interesantes, como unos *.idx con las peticiones HTTP realizadas a un dominio malicioso y un .jar. Las URLs encontradas fueron las siguientes:

http://car.xxxx.info/content/v1.jar
http://car.xxxx.info/w.php?f=23&e=0

Los paths de estas URLs son bastante familiares y pertenecen a un Exploit Kit, más concretamente BlackHole, como se puede ver si se realiza una búsqueda rápida. En este caso la vulnerabilidad que se explotó de forma satisfactoria fue la CVE-2011-3544 de Java, llevando a la descarga de la segunda URL y la ejecución del código malicioso.

El malware encontrado forma parte de la familia de los Ransomware, que, como se ha visto, bloquean el sistema o cifran los archivos pidiendo cierta cantidad de dinero a cambio de desbloquearlo. Normalmente se pide una especie de rescate (del inglés ransom) para liberar el sistema, pero en este caso se hace uso de ingeniería social para engañar al usuario y obtener el dinero. Las acciones más relevantes que realiza son las siguientes:

Asegura su inicio creando un acceso directo en \Documents and Settings\$USUARIO\Menú Inicio\Programas\Inicio para ejecutar rundll32.exe con la DLL descargada.

Deshabilita la seguridad de las zonas de Internet Explorer.

Deshabilita el atajo de teclado para el Administrador de Tareas (Ctrl+Alt+Supr).

Muestra el citado aviso, que no es más que una ventana de Internet Explorer con el contenido de la siguiente URL (todavía activa):

http://xxx.yyy.73.43/

De la misma forma, intenta descargar un módulo para el robo de credenciales de FTP, VPN, Mensajería instantánea, Navegadores y aplicaciones de Poker de la siguiente URL:

http://xxx.yyy.73.43/images.rar

Para saltarse el bloqueo del código malicioso es posible lanzar una nueva ventana de Internet Explorer con Ctrl+N. Esto es así porque la pantalla que se ve no es más que una ventana de Internet Explorer maximizada, por lo que es posible lanzar una nueva ventana, y, una vez abierta, podemos usar el ratón para hacer click en Archivo/Abrir y lanzar el explorer.exe que nos devolverá el control del sistema.

La forma de eliminarlo sin usar la técnica anterior sería entrar en el Modo Seguro de Windows y ejecutar alguna solución Anti-Spyware / Anti-Malware, o, de forma manual, localizar el acceso directo en \Documents and Settings\$USUARIO\Menú Inicio\Programas\Inicio y la DLL comentada, y eliminarlos. Para esta infección los archivos se llamaban 0.1998781520909214.exe.lnk y 0.1998781520909214.exe, aunque estos nombres podrían variar. También se podría hacer uso de un Live-CD para realizar la misma tarea.

Este incidente se ha repetido en diferentes puntos de España (y anteriormente en el extranjero) y es una campaña todavía en uso, por lo que es recomendable el uso de protección al visitar ciertos sitios. No sólo hablo de un antivirus actualizado, que en este caso lo estaba, sino de estar al día con las actualizaciones de aplicaciones de terceros y del propio sistema operativo. Como comentaba, cada uno tiene sus gustos y aficiones, pero os recomendaría tener cuidado con ellos cuando se relacionan con las tecnologías, ya que la seguridad debe estar presente siempre ;)

Jose Miguel Esparza
S21sec e-crime
(Blog / Twitter)

Un Año de Fraude (1ª Parte)

noreply@blogger.com (S21sec Labs) — Fri, 03 Feb 2012 05:33:31 PST

Una vez concluido el año llega el momento de realizar un pequeño resumen sobre todo lo que hemos visto en 2011. Los datos que vamos a presentar hoy son relativos a los incidentes de fraude cerrados por el SOC/CERT de S21sec.

En total hemos actuado en 4.759 incidentes de fraude que afectaban directamente a nuestros clientes, un número ligeramente inferior a los registrados en el año anterior. Se puede observar la distribución de estos incidentes en la siguiente gráfica.

Una vez más el número de incidentes relacionados con phishings es muy superior a los relacionados con código malicioso. Esto se debe principalmente a nuestros clientes de Latinoamérica donde las incidencias de código malicioso son mínimas.

En la siguiente gráfica apilada se muestra la distribución mensual de todos los incidentes.

Se puede observar muy claramente que existen dos picos en la cantidad de incidentes registrados, este incremento de incidentes se repite año tras año. Normalmente suceden en fechas coincidentes con los periodos vacacionales, donde generalmente los usuarios están más relajados y menos concienciados con la seguridad.

A modo de reflexión personal de 2011 debo decir que han pasado los meses y aún continúo expectante de novedades, que finalmente no han llegado a producirse. El año 2010 fue un año muy interesante, donde pudimos observar tanto nuevas formas de ataques (MiTB, MitMo) como nuevas familias de código malicioso (Tatanga, SpyEye…)

¿Qué ha pasado en 2011?

Ahora que podemos analizar 2011 con una vista completa podemos considerarlo un año de transición, donde hemos observado cómo los ciberdelincuentes han mejorados los métodos y herramientas utilizados en el fraude, pero sin introducir ninguna novedad notoria.

¿Se debe este estancamiento a la crisis económica mundial?

Es difícil relacionar los cambios en la tipología del fraude con la realidad económica, pero es indudable que hay ciertos aspectos que han influido en los últimos meses.

Los ataques de ingeniería social, realizados generalmente por individuos no organizados, han aumentado considerablemente. Esto es debido principalmente a que los costes asociados a los mismos son mínimos, lo que ha provocado que entren en escena numerosos nuevos individuos que intentan obtener resultados rápidos con una mínima inversión. Este dato es muy interesante sobre todo en Latinoamérica, único lugar del mundo donde hemos observado un incremento de incidentes respecto a años anteriores.

En el lado opuesto tenemos a los ataques relacionados con código malicioso, mucho más complejos y costosos. Estos generalmente están realizados por mafias con abundantes recursos y muy bien organizadas. En este año esperábamos el despegue de SpyEye ya que ZeuS, su principal rival, abandonó su desarrollo a finales del año 2010 y su código fuente fue publicado. Sin embargo este hecho no se ha producido, probablemente debido a su alto precio. Hemos visto además cómo algunas “bandas” han aprovechado el código de ZeuS para desarrollar nuevas familias de malware sin tener que asumir un coste asociado.

David Ávila

S21sec ecrime

Tourist Periscope gestionará la información del sector turístico en la Red

noreply@blogger.com (S21sec Labs) — Wed, 25 Jan 2012 06:51:44 PST

Desde S21sec labs estamos liderando el proyecto Tourist Periscope, con el objetivo de desarrollar la solución tecnológica que ayudará a detectar diferentes oportunidades del mercado y a reducir el riesgo en la toma de decisiones estratégicas, previendo las tendencias turísticas.

Internet es fuente de innumerable cantidad de información, lo que en muchas ocasiones constituye una amenaza para una empresa por no poder gestionar el volumen de información o puede ofrecerle una oportunidad de negocio difícil de detectar entre tantos datos que circulan por la Red.

El gran incremento de información en el sector turístico supone graves dificultades para las empresas turísticas, instituciones y administraciones a la hora de gestionar, identificar y optimizar la búsqueda de contenidos de interés para su negocio.

Por esta razón S21sec creará, gracias a su experiencia en el desarrollo de tecnologías de búsqueda de información, indexación y clasificación de información de fuentes abiertas, la aplicación Tourist Periscope en su centro de I+D+i en seguridad S21sec labs y en colaboración con agentes especializados del sector turístico, tanto a nivel universitario como empresarial. Este proyecto de I+D+i está enmarcado dentro de los proyecto INNPACTO del Ministerio de Economía y Competitividad. La nueva plataforma TIC estará orientada al sector turístico y será capaz de gestionar y racionalizar la información en función del perfil del demandante y el objetivo que éste quiera conseguir. Esta nueva herramienta es capaz de analizar el entorno turístico de forma particularizada e integrada con las redes sociales generando así una unidad de Inteligencia Turística.

El objetivo de Tourist Periscope es dotar a las empresas del sector turístico de una nueva solución tecnológica de fácil uso para detectar las diferentes oportunidades del mercado y reducir el riesgo en la toma de decisiones estratégicas a través de la anticipación a los movimientos turísticos.

Dpto. Marketing S21sec

Nueva convocatoria planes de carrera online

noreply@blogger.com (S21sec Labs) — Thu, 19 Jan 2012 08:10:05 PST

En S21sec seguimos apostando por la formación continua en seguridad, por lo que con el objetivo de seguir generando cultura de seguridad digital, el próximo 24 de enero damos el pistoletazo de salida al primer nivel de los planes de carrera online:

Puedes consultar nuestro catálogo completo de formación en nuestra web.

S21sec

Nueva campaña SpyEye + complemento móvil

noreply@blogger.com (S21sec Labs) — Thu, 05 Jan 2012 11:58:13 PST

Hace ya más de un año que vimos por primera vez cómo ZeuS incorporaba un componente móvil para tratar de robar el SMS enviado por nuestro bando al realizar una transferencia. Más adelante fue SpyEye el que incorporaba esta misma técnica.

Estos días se ha podido ver una nueva campaña afectando a entidades españolas, en las que se insta al usuario a instalar un componente si su teléfono es Android. Si bien las primeras muestras eran para Symbian y BlackBerry, las siguientes incorporaban Android entre sus objetivos, y es que el uso generalizado de esta plataforma, junto con la facilidad para desarrollar aplicaciones para la misma, han hecho que se convierta en uno de los objetivos favorito de los creadores de malware.

La infección del terminal móvil no es trivial, por lo que se trata de engañar al usuario para que sea él mismo quien infecte el móvil, utilizando para ello la ingeniería social. Es por este motivo que es muy importante que se conozca la amenaza, ya que un usuario que no es consciente de que su móvil puede ser infectado es totalmente vulnerable a este ataque.

En el caso que nos ocupa, al visitar la página de la entidad bancaria, un ordenador infectado tratará de convencer al usuario para que instale una aplicación en el móvil haciéndole creer que está instalando un programa para asegurar las comunicaciones.

Se procede a la verificación de la instalación, pidiendo un número que el móvil enseñará nada más instalarse

Por último, se mostrará el mensaje de instalación satisfactoria.

Si el móvil no es Android, el SpyEye simplemente nos dirá que no necesitamos más seguridad.

A pesar de que muchas veces hayamos podido oir el mal utilizado término "SpyEye para Android", debemos aclarar que el componente que infecta el móvil no se trata de una versión de SpyEye para el mismo, ya que no es capaz de interceptar la navegación en la banca electrónica ni nada parecido. Se trata una aplicación muy simple, pero capaz de reenviar los SMS recibidos a un servidor externo mediante una sencilla petición GET, con los datos como parámetros. Se trata de un mero complemento totalmente ajeno al malware que infecta el PC y que podría ser utilizado indistintamente por cualquier troyano bancario.

Como ejemplo de la simpilicidad de la aplicación, decir que el cifrado de la cadena de caracteres referente al servidor de envío de los SMS consiste únicamente en intercalar valores "=", "-" y "q", tal y como se puede ver en el siguiente ejemplo, muy similar a la URI original.

Por lo tanto, nos encontramos ante una nueva campaña de infección que realmente no tiene nada nuevo desde el punto de vista técnico, pero debemos recalcar la importancia de que la gente vaya conociendo este tipo de amenazas para evitar caer en el engaño.

Mikel Gastesi

S21sec e-crime

Murofet: cambiando a zlib

noreply@blogger.com (S21sec Labs) — Wed, 11 Jan 2012 04:16:21 PST

El tiempo pasa, y en el mundo del malware van a apareciendo nuevas amenazas, pero las ya consolidadas siguen evolucionando, y parece ser que todo apunta a que seguirán haciéndolo.

En esta ocasión vamos a volver de hablar de ZeuS, concretamente de la versión conocida como Murofet.

Alla por junio hablábamos de las diferentes ramificaciones del mismo, y también hemos visto que los desarrolladores de esta variante han implementado nuevas funcionalidades como el P2P o la generación de nombres de dominio, en lo también conocido como Murofet 2.0.

En una de las últimas muestras recibidas vimos que algo no encajaba con el comportamiento habitual, por lo que, tras analizarla con un poco más de calma, hemos podido comprobar que ciertas secciones que están comprimidas, en vez de utilizar UCL, ahora han pasado a ser comprimidas con zlib.

Uso de zlib v1.2.5

Zeus ha evolucionado mucho. Atrás queda el tiempo en el que cada botnet no tenía su clave y el cifrado constaba tan solo de un xor y poco más. Observando la evolución, se ha podido observar como los creadores han madurado, han dejado de reinventar la rueda y han incorporando algoritmos criptográficos ya existentes, mucho más robustos que los primeros, algo totalmente lógico.

Y hablando particularmente del gang detrás de Murofet, podemos observar una constante evolución, separándose cada vez más de la versión oficial. Los cambios que han incorporado poco a poco, tanto a nivel más interno (en cuanto a la modificación de características en la codificación del fichero de configuración) como el añadir las características antes mencionadas, indican un buen conocimiento de lo que se traen entre manos.

Además, no olvidemos el detalle de que la primera variante la pudimos ver antes de que el código fuente se filtrase, por lo que está claro que hay detrás un grupo con los objetivos claros.

Seguiremos jugando.

Jozsef Gegeny y Mikel Gastesi

S21sec e-crime

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

noreply@blogger.com (S21sec Labs) — Tue, 27 Dec 2011 09:36:47 PST

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:

Lo curioso es que el servidor lleva un registro de las cuentas válidas y no muestra el login siempre, sino que debe ser una cuenta a la que se haya enviado anteriormente el correo. En caso contrario muestra un error:

El objetivo de esta campaña parece claro, y no es otro que el robo de contraseñas de correo electrónico. Se trata de una cadena, en la que cuando suministras una contraseña correcta de correo, se registra y se buscan los contactos de esa cuenta para enviarles a su vez el mismo correo. La finalidad de esta recolección puede ir desde la venta de esta información en el mercado underground al uso de las cuentas para el envío de SPAM u otras campañas similares, por lo que se recomienda el cambio de la contraseña si se ha llegado a introducir en esta página fraudulenta.

También es destacable la firma y el contenido del correo. Se firma en nombre de una persona que realmente existe y está relacionada con el mundo del Marketing, como indica la firma del correo fraudulento. Si echamos un vistazo a la página web de la empresa para la que trabaja, vemos que se pueden enviar regalos navideños, y si nos fijamos en su texto promocional, éste coincide exactamente con el texto que se incluye en el correo electrónico. Por lo menos parece que los delincuentes se han molestado en usar identidades y textos reales para realizar esta campaña, dotándola de mayor realismo de cara a obtener el mayor número de contraseñas posibles.

El dominio se creó el 12 de diciembre (hace 15 días) y la IP a la que resuelve pertenece a un bloque de direcciones localizadas en China.

Como ya he comentado, es necesario que en estas fechas se esté más atento si cabe a este tipo de correos, evitando cualquier tipo de interacción con los servidores maliciosos. ¡Felices fiestas a todos! pero sin olvidarse de la seguridad... ;)

Jose Miguel Esparza
S21sec e-crime
(Blog / Twitter)

¡Felices Fiestas!

noreply@blogger.com (S21sec Labs) — Fri, 23 Dec 2011 01:22:32 PST

Desde S21sec os deseamos unas felices fiestas y un próspero año nuevo.
Muchas gracias por estar con nosotros un año más.

S21sec

Guia sobre Seguridad en Control Industrial de la ENISA

noreply@blogger.com (S21sec Labs) — Wed, 21 Dec 2011 06:39:38 PST

En marzo de 2011 ENISA encargaba un estudio sobre los sistemas de control industrial, bajo el nombre de “Protecting Industrial Control Systems. Recommendations for Europe and Member States”. Es ahora cuando esta organización saca a la luz la versión definitiva del estudio que podéis consultar aquí.

Los sistemas de control industrial (ICS) son los encargados de la regulación automática de operaciones, así como de la integración y coordinación de éstas en un sistema global de producción. El uso de estos sistemas comenzó en los años 50 extendiéndose su uso hasta nuestros días. Los sistemas de control industrial se están utilizando para el control de diversas infraestructuras, algunas, por su origen, pueden ser vitales para la sociedad, como puede ser una central nuclear o una planta química, y forman parte de las infraestructuras críticas. Debido al uso tan extendido y a la delicadeza de su naturaleza son necesarios unos pilares de seguridad en los que asentar a estos sistemas de control.

El equipo de investigadores encargado del estudio ha realizado un arduo trabajo de investigación documental para recopilar toda la información disponible sobre el estado del arte actual de seguridad de los ICS, los principales retos a los que se enfrentan, los proyectos de investigación existentes, los grupos de trabajo, el estado de las normativas en los diferentes estados miembros, así como otras iniciativas de interés a nivel nacional e internacional. Esta labor de investigación documental se complementa con los puntos de vista de más de 60 expertos del ámbito industrial (fabricantes, operadoras de infraestructuras críticas, proveedores de soluciones y servicios de seguridad, organismos de estandarización, organismos públicos, universidades y centros de investigación), a través del análisis de casi 50 cuestionarios y más de 20 entrevistas personales.

El estudio está formado por un documento principal y cinco anexos, todos ellos de alto interés. En el documento principal se proponen 7 recomendaciones de alto nivel orientados a los Estados Miembros y las instituciones europeas, consensuadas con los expertos en la materia y la propia ENISA. Con toda probabilidad estas recomendaciones acabarán definiendo las líneas maestras de las iniciativas políticas europeas en materia de ciberseguridad de los sistemas industriales de las infraestructuras críticas.

A este respecto, Rafal Leszczyna, uno de los editores del informe comenta:

"La seguridad real para los sistemas de control industrial solo pueden conseguirse con un esfuerzo común, caracterizado por la cooperación, intercambio de conocimiento y conocimiento mutuo de todas las partes implicadas" [ENISA]

Conviene destacar que el día 16 de septiembre de 2011 se realizó en Barcelona un workshop en el que se presentaron los primeros resultados de este proyecto a una representación amplia de los expertos que contribuyeron con su conocimiento y experiencia en la elaboración del informe. Este workshop permitió contrastar las principales conclusiones del informe y se discutieron las recomendaciones propuestas. El documento recoge en uno de sus apéndices las opiniones de unos y otros en torno a estas recomendaciones. Se trata de una lectura muy recomendable.

Para finalizar conviene destacar que durante 2011 ENISA ha tratado los principales temas en torno a la seguridad de ICS, comenzando con la valoración de las implicaciones de Stuxnet y el análisis del más reciente DuQu, así como ahora con este informe sobre seguridad en sistemas de control industriales. Esperamos que la lectura de estos documentos sea de vuestro agrado.

Victor Fidalgo Villar

S21sec labs

El fraude online vuelva a casa por Navidad

noreply@blogger.com (S21sec Labs) — Thu, 15 Dec 2011 07:53:05 PST

La Navidad es el periodo anual de compras por excelencia. La gran actividad que recoge la Red en estas fechas se convierte en el lugar de actuación ideal de los ciberdelincuentes para incrementar el número de víctimas de fraude online. La comodidad de poder comprar todos los regalos tranquilamente desde el sofa de casa y las prisas por hacer rápido algunas compras de última hora hacen que la web se convierta en un "hervidero" de compras a través de la Red.

Esta época del año hace que la gente sea un poco menos cuidadosa a la hora de abrir adjuntos o descargarse los archivos que sus familiares o amigos les envían con felicitaciones. Estas descargas pueden poner en riesgo nuestro equipo y toda la información personal que este contiene.

Durante 2011 S21sec ecrime ha sido capaz de recuperar 1 Tb de datos robados de ordenadores de todo el mundo.

La temporada navideña es la época en la que más ordenadores se infectan, debido a que suele suavizarse el nivel de seguridad al recibir muchas felicitaciones en diversos formatos que muchas veces abrimos sin pensar en las consecuencias. Las estadísticas muestran que en torno al 50% de los ordenadores españoles se encuentran infectados, por lo lo que es necesario extremar las medidas de precaución para poder protegernos frente a estos ataques.

Para evitar los fraudes online en estas fechas, a continuación os damos 5 sencillos consejos:

Ante la mínima duda ... ¡BÓRRALO!: Si ves que algo te "da mala espina" o no te fías del contenido que pueda tener o del remiente, bórralo inmediatamente. Es mucho mejor esa opción que correr el riesgo de ser infectado por un virus.
Conoce la web en la que te metes. Además de ser precavido a la hora de navegar por la Red, utiliza un software de seguridad que detecte los sites que puedan tener contenido fraudulento.
Ten claro lo que buscas. A pesar de que la mayoría de los timos a través de felicitaciones navideñas y los buenos deseos para Año Nuevo están muy logrados y parecen simples tarjetas inofensivas, siempre hay algunos detalles que los delatan: palabras mal deletreadas, remitente desconocido, URL extrañas...
Lee siempre la letra pequeña antes de aceptar nada. Algunas estafas de felicitaciones contienen dentro de sus condiciones el reenvío a través de tu lista de contactos. Asegúrate de que conoces lo que estás aceptando.
Mantente actualizado. Un gran porcentaje de las infecciones se producen gracias a fallos de seguridad en las aplicaciones, por lo que una buena política de actualización del sistema operativo y de las aplicaciones instaladas puede ayudar en gran medida a prevenirlas.

S21sec

Libro : Fraude online, Abierto 24 horas.

noreply@blogger.com (S21sec Labs) — Sun, 11 Dec 2011 23:00:01 PST

Como en cualquier disciplina medianamente compleja, el mundo del fraude electrónico tiene además como componente añadido una dinámica muy cambiante. Si bien es cierto que existe multitud de información sobre este fenómeno, creímos necesario un recurso que de manera genérica englobara todo aquel dato que permitiera al analista, técnico o simplemente curioso, tener una visión global de cómo está la situación actual del fraude online.

Y, qué mejor que un extracto de la propia introducción del libro para explicarlo:

"Con este libro pretendemos acercarnos un poco a este mundo oscuro del que hemos oído hablar alguna vez y del que no nos preocupamos hasta que no nos queda más remedio. Todos somos víctimas potenciales, por lo que el texto pretende servir tanto a profesionales que quieren conocer cómo funciona este mundillo como a usuarios que deben conocer a qué se enfrentan y qué peligros existen para no terminar siendo una víctima más.

Comenzaremos con una visión global, comentando cómo el PC doméstico es un objetivo para la comisión de fraude online y qué información puede resultar interesante. Veremos cómo se organizan los delincuentes virtuales, qué infraestructuras utilizan, y los entresijos del fraude online, desde la creación y distribución de malware, hasta el robo de dinero y su posterior monetización.

A bien de tener una visión completa, también nos detendremos un momento para conocer el funcionamiento del carding, esto es, el robo y manipulación de información de tarjetas bancarias.

Durante el transcurso del libro trataremos de no perdernos en un mar de detalles técnicos que podrían extender el mismo de manera excesiva, tratando siempre de exponer las peculiaridades más destacadas que permitan conseguir una visión global del mismo."

El índice se puede descargar desde aquí (pdf) y el libro puede ser adquirido aquí.

Agradecer a Informática64 y a S21sec y a todos los compañeros sin los que este ilusionante proyecto no podría haberse llevado a cabo.

Dani Creus / Mikel Gastesi
S21sec e-crime

Murofet v2.0 (ZeuS P2P)

noreply@blogger.com (S21sec Labs) — Fri, 18 Nov 2011 07:06:30 PST

Continuando con el post de ayer sobre la campaña de distribución de ZeuS "ACH transaction canceled", se aprovechó para analizar el binario que distribuía.

Se trata de la versión 2.0 de la variante de ZeuS conocida como Murofet. Y que se ha venido a llamar ZeuS P2P, por alguna de las nuevas características incorporadas, que hacen uso de dicha técnica.

Es la versión más evolucionada de todas las aparecidas últimamente, con muchos cambios respecto a la versión original, y la que más se rumorea que pueda provenir del autor original de ZeuS, debido a que para dichos cambios, hace falta una comprensión profunda del mismo.

Esta relación con el Murofet original se puede observar claramente en los ficheros de configuración, diferentes a la versión original de ZeuS e iguales entre sí, con nuevas etiquetas para algunas secciones o, como rasgo fácil de detectar, el delimitador ERCP, tal y como se ve en la siguiente imagen:

En esta variante el troyano utiliza una estructura P2P para la obtención del fichero de configuración, lo cual se trata de una interesante novedad. Para ello, utiliza en primera instancia unas IPs que incorpora, y a las que se conecta por UDP:

Una vez se comunica con los bots pertenecientes a la red P2P, si se detecta que existe una versión más nueva, ésta es descargada, para lo que utiliza TCP y un protocolo propio:

Si la comunicación P2P falla, se pasará a utilizar la generación de dominios, tal y como se hacía en la primera versión de Murofet.

La ruta de almacenamiento, tanto del binario como de las rutas de registro, son similares a las versiones anteriores, pero en esta versión el fichero de configuración es almacenado únicamente con el cifrado RC4, sin la capa XOR, también conocida como VisualEncrypt, algo lógico, ya que no aporta ninguna seguridad.

Del mismo modo, se han encontrado evidencias de que el troyano trata de borrar de memoria la clave de RC4 después de cada uso, en un claro intento de dificultar el hallazgo de la misma.

Finalmente el servidor de C&C mostrado en el fichero de configuración, parece ser falso, en un claro intento de despistar al analista y ganar tiempo.

En resumen, se está ante una versión modificada de ZeuS, con características muy avanzadas, y cambios más orientados a la protección frente al análisis automático del binario y la prevención frente a la destrucción de la infraestructura de red, pero sin cambios notables en cuanto a funcionalidad.

Jozsef Gegeny & Santiago Vicente
S21sec e-crime