Ataque de denegación de servicio en redes 2G

lunes, 31 de marzo de 2014

La técnica descrita en esta entrada fue propuesta en 2010 por Sylvain Munaut. Aunque una denegación de servicio suene a aprovechamiento de algún fallo o recursos agotados, realmente esta técnica no viola ningún principio de la arquitectura 2G y es perfectamente viable. Se trata de un ataque dirigido que se fundamenta en una idea muy sencilla. El atacante suplanta la identidad del usuario y envía un mensaje de IMSI detach a la red. De esta manera, la red marca a la MS del usuario como detached, y por tanto inalcanzable.

En post anteriores hemos visto cómo llevar a cabo ataques man in the middle en redes GSM. Una vez que las comunicaciones entre la víctima y la red pasaban por la estación base falsa que el atacante había configurado, se podía hacer prácticamente cualquier cosa, desde simplemente intervenir la comunicación, hasta robar información vía ingeniería social suplantando a entidades oficiales o realizar una denegación de servicio. Pero este ataque que vamos a describir realizará una denegación de servicio sin necesidad de complejos recursos, sino aprovechando un punto débil del protocolo.

El IMSI (International Mobile Subscriber Identity) es un número que identifica de forma única a un usuario de una red móvil. Este dato es confidencial, puesto que a partir de él es posible averiguar información sobre el usuario, incluyendo su localización. Por esta razón se almacena solo en la SIM y en la red (y no en las estaciones base). Para "protegerlo", la norma recomienda el empleo de un identificador temporal o TMSI en su lugar. Sin embargo, ya hemos descrito que bajo determinadas circunstancias una estación base puede forzar el envío del IMSI en claro.

IMSI attach procedure

El IMSI attach procedure es un procedimiento de registro del terminal móvil en la red. Tiene lugar fundamentalmente bajo dos circunstancias: cuando el móvil se enciende (es decir, pasa a estado activo) o cuando el móvil entra en una zona de cobertura. En el registro de ubicación de visitante (VLR, Visitor Location Register), la MS se marca con el flag attached, que indica que el terminal móvil es alcanzable por la red y por tanto puede enviar y recibir llamadas. Este procedimiento, en detalle, requiere los siguientes pasos: 
  • Al encenderse, la MS del usuario envía a la estación base más cercana un mensaje Channel Request solicitando un canal dedicado. Esta petición la realiza a través del canal común (RACH, Random Access Channel).
  • La red asigna un canal dedicado a la MS (SDCCH, Stand-alone Dedicated Control Channel) y se lo notifica con un mensaje de asignación de canal.
  • Una vez el canal está establecido, la MS envía un mensaje IMSI attach request hacia la estación base, que lo reenvía al MSC y después al VLR. El VLR marca el IMSI como attached y envía un mensaje IMSI attach acknowledge al MSC, que lo redirige de vuelta a la BS y por tanto a la MS.
  • El MSC envía un mensaje Clear Command para forzar la liberación del canal SDCCH asignado a la MS.

IMSI attach procedure. Fuente: www.iosrjen.org

IMSI detach procedure

El proceso contrario, en el que una MS "sale" de la red, se conoce como IMSI detach procedure, y es la clave de este ataque. Se produce en dos casos: si se apaga el terminal móvil o si se extrae la SIM. Al igual que en el IMSI attach, cuando se produce este evento el VLR marca a la MS con el flag detached, indicando que ya no es alcanzable por la red. Cuando una MS está detached, no puede transmitir, recibir... ni tampoco recibe los mensajes broadcast de paging de las estaciones base. De esta manera, la red no desperdicia recursos intentando contactar con MS apagadas. El procedimiento consta de unos pasos equivalentes a los del IMSI attach:

  • Al apagarse la MS envía una petición de asignación de canal dedicado a través del RACH.
  • La BS asigna un canal dedicado (SDCCH) a la MS y se lo notifica a través del canal AGCH (Access Grant Channel).
  • Con el canal ya establecido la MS envía un IMSI detach request a la estación base, que lo reenvía al núcleo de la red. El VLR actualiza el flag, y notifica al HLR que el terminal móvil ya no está registrado mediante un mensaje Deregister Mobile Subscriber.
  • El HLR marca la MS como “no registrada” y contesta al VLR con un “Deregistration Accepted”. El VLR envía un mensaje IMSI detach acknowledge de vuelta al MSC. Este mensaje no se retransmite a la MS, porque en este punto ya se habrá apagado.
  • Por último, el MSC envía un Clear Command para liberar el canal SDCCH asignado a la MS.

IMSI detach procedure. Fuente: www.iosrjen.org

La técnica de ataque

El primer punto crítico es que el atacante necesita conocer el IMSI de la víctima. Para ello puede valerse de la infraestructura descrita en el post de ataques MITM: con una estación base falsa a modo de IMSI catcher, el atacante puede elaborar listas de IMSIs en varias localizaciones donde tenga la certeza de que se encuentra el usuario y cruzarlas posteriormente para determinar el IMSI deseado. Aunque siempre existe la alternativa (mucho más sencilla) de utilizar un servicio online que permita consultar HLRs.

Servicio de consulta de HLRs de telesigmobile.com. Fuente: coseinc.com

Superada esta dificultad, el siguiente paso consiste en suplantar el móvil de la víctima frente a la red. Esto requiere una mínima inversión y algunos conocimientos técnicos. Para la parte software se utiliza la herramienta libre OsmocomBB, que corre sobre Linux, y en cuanto al hardware basta con disponer de un terminal móvil con procesador de banda base Calypso y chipsets Rita e Iota para demodulación y conversión DA (por ejemplo los Motorola modelo Cxxx, aunque hay más terminales compatibles).

Placa de circuito impreso de un Motorola C123. Fuente: bb.osmocom.org
La idea es sustituir el firmware del teléfono con la pila de protocolos GSM modificada que implementa OsmocomBB. Las modificaciones que incluye permiten establecer canales de control, inyectar información de señalización en ellos (justo lo que el atacante quiere en este caso), y por supuesto generar tráfico de voz y datos.

Una vez el atacante ha configurado correctamente su infraestructura, debe desplazarse al mismo Location Area (conjunto de celdas gestionadas por un mismo VLR) donde se encuentra la víctima. En este momento, el VLR de esa LA tiene marcado el IMSI de la víctima como attached. El atacante, con su móvil correctamente caracterizado, fuerza el envío de un mensaje IMSI detach. El VLR recibe el mensaje y cambia el flag del IMSI de la víctima a detached. Además, el HLR marca la MS como "no registrada", con lo que ya no recibirá mensajes de paging de la red. La víctima en ningún momento es consciente del ataque, puesto que como hemos visto, el IMSI detach aknowledge nunca se retransmite hacia su MS, sino que se queda en el MSC porque se da por supuesto que la MS estará ya apagada. Al llegar a este punto, la víctima quedará sin cobertura, por estar "apagada" a ojos de la red... y no podrá enviar ni recibir llamadas.

En este vídeo, el propio descubridor del problema expone el fallo (en 41 minutos) en la DeepSec de 2010.



Cristóbal Bordiú
cristobal.bordiu@11paths.com

Latch Event Monitor: Nueva herramienta para integrar Latch con los eventos de Windows

jueves, 27 de marzo de 2014


En el laboratorio de Eleven Paths, hemos creado Latch Event Monitor, una herramienta que monitoriza los eventos en Windows y ofrece al usuario la posibilidad de rastrear de una forma muy granular los logs, reaccionando de acuerdo a una respuesta preconfigurada en Latch. 

Esto quiere decir que Latch Event Monitor preguntará a los servidores Latch qué hacer cuando se generan ciertos eventos en una máquina Windows. De esta forma el administrador dispone de una herramienta para potencialmente reaccionar ante cualquier evento y modificar de cualquier forma y en cualquier momento el comportamiento y los scritps que se lanzan, con solo desplazar una barra desde su dispositivo móvil.

Cómo funciona

Latch Event Monitor funciona como un servicio, y dispone de una interfaz gráfica. Esto significa que también monitoriza los eventos cuando un usuario no se ha presentado en el sistema. El servicio monitoriza constantemente los eventos con una características dadas por el administrador. Cuando se produce ese evento, pregunta a Latch y reacciona de la forma en lo que lo haya configurado el usuario. Puede ser utilizado como un sistema de alerta, sin que exista una acción asociada a un evento. De forma que si ocurre un evento, se muestra un mensaje de bloqueo por parte de Latch en el dispositivo pero no se toma ninguna acción.

Latch Event Monitor con algunas reglas ya configuradas
Como instalarlo

No es necesaria una configuración especial durante la instalación. Se acepta la licencia y se elige la ruta donde se instalará. Si, por seguridad, no se desea que el servicio se ejecute como SYSTEM, se puede cambiar a la cuenta que se desee, siempre que disponga de privilegios para ejecutarse como servicio y tenga acceso a la red. Más información de cómo conseguirlo en el manual que acompaña a la herramienta.

El programa creará un fichero de configuración en formato XML, donde se almacenará el AppID, Secret de Latch, etc. También conviene vigilar los permisos de estos ficheros en sistemas compartidos.

Pareando con Latch

Antes de nada, se debe configurar una cuenta Latch. En la interfaz,se debe ir a la zona de configuración Latch arriba a la derecha y añadir el App ID y el secreto. En esta ventana también se puede especificar un "timeout". Si el sistema no está conectado a la red o, por cualquier otra razón no se obtiene respuesta de la Latch en el tiempo especificado (por defecto 0 milisegundos implicará que no hay "timeout") se aplicará la acción de "No response".

Cómo añadir y configurar un evento

Cada evento monitorizado vendrá definido por siguientes campos:
  • Name (opcional): Cualquier nombre que se le dará al evento que será monitorizado. El nombre solo sirve para representar mejor e identificar el evento en la lista.
  • Log: Fuente del árbol de eventos de Windows que se usa para clasificar los logs. Es la misma que se puede encontrar al lanzar eventvwr.msc. El éxito de la monitorización depende de esto, así que se debe elegir cuidadosamente qué fuente se utiliza. Es importante entender que algunas fuentes de eventos requieren más privilegios como, por ejemplo, "Security". Por esta razón es necesario asegurarse de que la cuenta bajo la que corre el servicio dispone de esos privilegios. Se tienen tantos logs que elegir como los que se muestren en eventvwr.msc. 
  • Source (opcional): Este campo representa la fuente del evento, presente en eventvwr.msc. Es opcional.
  • Message (opcional): El texto generado por un evento va a través de un sistema de correspondencia que puede ser usado para descartar o permitir algunos eventos. Si la cadena especificada casa con el evento monitorizado, se lanzará la consulta Latch. Se puede buscar por el comienzo ("Starts with"), solo que contenga una cadena ("Contains"), etc. 
  • Event ID: Si se genera este ID del evento, pasará a comprobar la cadena especificada más arriba.
  • Operation ID: El operation ID usado en Latch.
  • Actions.Open (opcional): Si la consulta a Latch responde con un "on", el proceso especificado se lanzará, con el argumento correspondiente (opcional).
  • Actions.Closed (opcional): Si la consulta a Latch responde con un "off", el proceso especificado se lanzará, con el argumento correspondiente (opcional).
  • Actions.No response (opcional): Si la consulta a Latch responde no responde (porque no hay conectividad por ejemplo, después del tiempo establecido en "Latch settings") el proceso especificado se lanzará, con el argumento correspondiente (opcional).
Ejemplo de configuración de evento monitorizado con VNC

En una entrada posterior, hablaremos de algunos ejemplos concretos. 

La herramienta está disponible en C# y puede ser descargada desde este enlace: http://elevenpaths.com/downloads/LatchEM-installer.exe

Invitamos al uso de la herramienta.

Latch Event Monitor: New tool to integrate Latch with Windows Events


Latch Event Monitor is a tool that monitors events in Windows and gives the user the possibility of tracking in a very granular way Windows logs, and react accordingly to a preconfigured Latch response. 

This means that Latch Event Monitor will ask Latch servers what to do when a certain event is generated in a Windows machine. So the administrator has a tool to potentially react to events, and modify the behavior and scripts launched in any way, at any moment, just sliding a bar from his mobile device.

How it works

Latch Event Monitor works as a service and has a GUI to configure it. That means it still works and monitors logs even when no user is logged in. The service is constantly monitoring any event with the characteristics given by the user. When it occurs, it asks Latch servers and reacts in the way that the user has configured it.

It may as well be used as an alerting system, with no action associated to an event. So if an event occurs, a blocking message is sent by Latch to the mobile device, but no action is taken.

Latch Event Monitor with some configured rules

How to install it

No special instructions. Just accept the license and choose the path. If , for the sake of security, you do not want the service to run as SYSTEM, you may change it to whatever account you wish, as long as it has privileges to run as a service, and network access. More about how to achieve this, in the manual.

A config file is created in XML format. This file contains sensitive information. Take care with the permissions specially in shared computers.

Pairing with Latch

First of all, a Latch account has to be set with a pairing token. Go to Latch management and add the App ID and secret. A timeout is specified here. This means that if the computer is not connected to a network or, for any other reason it cannot get a response from Latch in the specified time limit (0 milliseconds by default which corresponds to no timeout) the "no response" action is applied.

How to add and configure an event

Each monitored event, may have this fileds:
  • Name (optional): Any name given to the event that is going to be monitored. The name is representative only to better identify the event on the list.
  • Log: Log tree source that Windows uses to classify logs. It is the same one you can find in eventvwr.msc. The success of your monitoring depends on this, so carefully choose which source you use. It is important to understand that some sources requires more privileges, like, for instance, "Security" so make sure that the account which the service runs under has such privileges. You have as many logs to choose from as Windows offers in eventvwr.msc
  • Source (optional): This field represents the source of event, present in eventvwr.msc. It's optional.
  • Message: The text generated with an event goes through a matching system that can be used to discard or allow some events. If the string set matches, the Latch query will be launched. This is treated as a string, so "Starts with", "Contains"... may be used to match.
  • Event ID: If the event id matches, it will go through the process of checking the string in the message body.
  • Operation ID: The operation ID used in Latch.
  • Actions.Open (optional): If the Latch query responds with an "on", the process specified here will be launched, with the specified argument set (optional). 
  • Actions.Closed (optional): If the Latch query responds with an "off", the process specified here will be launched, with the specified argument set (optional).
  • Actions.No response (optional): If the Latch query doesn't respond (because there's no connectivity, for instance, after the timeout declared in "Latch settings"), the process specified here will be launched, with the specified argument set (optional). 
Event details with VNC example

In a following post, we will talk about some examples.

The tool is available in C# and may be freely downloaded from: http://elevenpaths.com/downloads/LatchEM-installer.exe

We encourage you to use it.

El negocio de las "FakeApps" y el malware en Google Play (IV): Política y rentabilidad

lunes, 24 de marzo de 2014

Seguimos observando las apps falsas en Google Play. En esta entrada estudiaremos qué políticas establece Google para utilizar su market y qué rentabilidad podrían conseguir los atacantes. Esta clasificación tampoco pretende ser demasiado rigurosa puesto que algunas de las técnicas son totalmente opacas y además van cambiando periódicamente. 

La política de Google Play

Para analizar el alcance del problema real que pueden suponer estas "FakeApps", es necesario tener en cuenta muchos factores. Por ejemplo, entender la política de Google Play. En su market, cualquiera puede subir una aplicación (previo pago de unos 20 euros) sin demasiadas comprobaciones burocráticas o, al menos, mucho más relajadas que las que realizan otros. Esto convierte a Google Play en una store que, aunque oficial, no ofrece mucha resistencia desde el punto de vista legal (no es necesario demostrar ser una empresa o una entidad) e inevitablemente se presta al abuso. 

Desde le punto de vista técnico (automatizado), han implementado otras medidas. Se han puesto en marcha varios mecanismos que, como cualquier método "desatendido", sufre limitaciones. El problema de base sigue estando ahí, y es que cualquiera con una cuenta y de forma muy sencilla y sin costes significativos, puede subir aplicaciones. Sería equiparable al funcionamiento del buscador Google en la Internet "habitual": se puede publicar cualquier cosa en Internet con un coste muy bajo, y Google se encarga de mostrarlo "sin prejuicios" hasta que por alguna razón decida que no debe aparecer entre sus resultados (con lo que se puede dar por desaparecido). 

En resumen, se trata de un comportamiento reactivo que encasilla a Google Play en un modelo de lista negra. Los markets para Apple o Windows, por ejemplo, funcionan con una filosofía totalmente opuesta. Burocrácticamente (e incluso económicamente) resulta más difícil subir una aplicación, y si se cuela alguna maliciosa (algo que ha ocurrido más de una vez , pero de forma anecdótica en comparación), se ponen en marcha sistemas de "limpieza". Google solo los aplica "a posteriori".

¿Es rentable el negocio?

En resumen, Google prefiere dejar las puertas abiertas, y realizar trabajos de limpieza más intensos, algo condenado al fracaso puesto que al final, se expone durante un tiempo al usuario. ¿Ese riesgo es real? Como ya hemos mencionado, según Google, el nivel de aplicaciones fraudulentas que finalmente llegan a instalarse "es mínimo". Esto es bastante discutible. Es probable que muchos de estos intentos de los atacantes no tengan demasiado éxito... pero otros muchos sí. Desde luego, a los que utilizan la estrategia de las FakeApps para instalar adware sí les merece la pena. El razonamiento es simple: 
  • Crean cuentas a diario (a veces hasta dos y tres diferentes) lo que supone una inversión de 20 euros cada una. 
  • Las apps (y las cuentas) son retiradas entre 24 y 48 horas después de ser subidas. Dependiendo de su sutileza, a veces permanecen más tiempo.
  • Cada instalación o click posterior suelen ganar unos céntimos. Cuando más agresiva la publicidad, más le pagan por cada instalación. En la imagen de más abajo se puede observar a un usuario hablando de cuánto puede llegar a ganar por instalación o click.
  • Esta estrategia es seguida por decenas de desarrolladores a diario, desde hace mucho tiempo.
Un usuario explica en un foro cuánto gana añadiendo adware muy agresivo a sus apps
Tras observar este comportamiento entre muchos "desarrolladores" durante un largo periodo, se podría concluir que la actividad es rentable y que la inversión inicial merece la pena incluso si se trata de poco más de un céntimo por instalación. Para conseguir esa rentabilidad, esto se traduce en muchas instalaciones a diario. La relación entre la inversión en tiempo para subir el malware o adware y el beneficio obtenido parece, al menos, rentable.  

Otro ejemplo claro del "éxito" es el indicador de instalaciones de Google Play. Puede que a veces resulte extrañamente alto para aplicaciones falsas con adware o fraudes que han permanecido apenas unas horas en el market.

Ejemplo en móvil de Whatsapp falso (aunque el nombre y fabricante estén muy conseguidos).
El número de descargas y valoraciones es muy elevado. Se mantuvo unas 40 horas online

Obviamente, no todas las descargas ni votaciones que aparecen en las imágenes significan infecciones reales. Primero por las propias defensas del teléfono y algunos antivirus instalados, que detendrán la instalación antes de que suceda (aunque no la descarga). También, sobre todo, porque los atacantes engordan las descargas y las votaciones artificialmente. Saben que es un indicador de confianza para el usuario y lo usan como ingeniería social. Una buena parte de esas votaciones falsas las realizan los propios usuarios infectados, como veremos más adelante. Así, podremos observar aplicaciones fake, con muchos comentarios negativos, pero también con muchas valoraciones "5 estrellas".

Ejemplo de una alta valoración en apenas unas horas para un juego falso que simulaba ser Candy Crush, impuesta por los propios usuarios que son incitados a valorarla con 5 estrellas antes de jugar (cosa que nunca ocurre)
En la próxima entrega veremos qué técnicas de limpieza técnica utiliza Google, y qué políticas ha puesto en marcha en el último año.


El negocio de las "FakeApps" y el malware en Google Play (I): Introducción 
El negocio de las "FakeApps" y el malware en Google Play (II): Tipos de "fakes"
El negocio de las "FakeApps" y el malware en Google Play (III): Estrategias
El negocio de las "FakeApps" y el malware en Google Play (IV): Política y rentabilidad
El negocio de las "FakeApps" y el malware en Google Play (V): Limpieza automática
El negocio de las "FakeApps" y el malware en Google Play (VI): Limpieza "manual"
El negocio de las "FakeApps" y el malware en Google Play (VII): Cómo llegan a las víctimas
* El negocio de las "FakeApps" y el malware en Google Play (VIII): Permisos en las apps
El negocio de las "FakeApps" y el malware en Google Play (IX): ¿Qué hacen y cómo se programan las apps?


Sergio de los Santos
ssantos@11paths.com

Un error en Android permitía a una app instalar cualquier otra de forma transparente

miércoles, 19 de marzo de 2014

Daniel Divricean ha descubierto un fallo interesante en Android, que permitía la instalación de cualquier aplicación (con cualquier permiso) en cualquier dispositivo de un mismo usuario sin que se diera consentimiento explícito. El fallo fue descubierto en diciembre y ha sido corregido ahora.

La prueba de concepto construida por Divricean consistiría en crear una aplicación (que sería considerado como el "troyano") con permisos en principio inocuos o poco entendidos, como:
  • android.permission.INTERNET: Permiso para acceder a la red. Algo muy habitual.
  • android.permission.GET_ACCOUNTS: Permiso para acceder a la lista de cuentas. Muy usado, y poco entendido por los usuarios en general.
  • android.permission.USE_CREDENTIALS: Permite a las apps utilizar los tokens de autenticación del AccountManager.
Esta aplicación, crearía un WebView, que no es más que una ventana a una web. Se presentaría con la cuenta de Google del usuario gracias a los tokens recogidos con el permiso correspondiente. Esto sería transparente para el usuario. Esta web cargaría el Google Play e inyectaría JavaScript en la página. Con este código obtendría información del dispositivo y los tokens CSRF, además de la lista de otros dispositivos (si el usuario estuviera presentado en ellos con la misma cuenta). Desde aquí, podría requerir que se instalara cualquier aplicación de Google Play en el dispositivo o en otros bajo la misma cuenta. El usuario no podría detenerlo, y no se le preguntaría confirmación alguna.

Cabe recordar que ya existe la posibilidad de que las aplicaciones se actualicen de forma transparente, pero bajo dos condiciones: que posean el mismo certificado, y que no cambien sus permisos. De lo contrario, la app pedirá confirmación. El método encontrado por Divricean elude todo esto, y permite una instalación transparente de cualquier aplicación, con cualquier permiso. Como si el usuario aprobara la instalación desde el navegador en Google Play. Y esto es muy peligroso.

El investigador plantea escenarios todavía más complejos, en los que la app podría abrirse a pantalla completa y ocultar incluso la barra de instalación que delataría el proceso aunque sea automático. También la instalación en dispositivos diferentes, por lo que el usuario no notaría nada en el dispositivo donde ha instalado esa primera app con pocos permisos y que realizará la instalación posterior.

Google fue informada en diciembre, pero no se ha hecho público hasta que la solución no ha sido desplegada y se encuentra operativa. Parece que ahora impide que el navegador pueda presentarse de forma automática con la cuenta. Mostrará un texto advirtiendo que la aplicación quiere tener acceso a los datos de Google, y será el usuario el que tenga que aprobar esto explícitamente.

Si el usuario lo permite, parece que volveríamos a estar en la misma situación de peligro, y la aplicación podría instalar otras apps de forma transparente. Esta es la razón por la que Divricean prefiere no publicar la prueba de concepto... aunque con las pistas dadas, no resultaría difícil crearla.

Un modelo confuso

Existen varias mitigaciones en el modelo de ataque propuesto por Divricean. En principio el usuario debe instalar una app maliciosa con ciertos permisos reducidos. Pero, ¿es esto un problema realmente? Además, no olvidemos que las ya instaladas con estos permisos podrían actualizarse automáticamente (siempre que mantengan el certificado y los permisos) para realizar este ataque.

El hecho de que este fallo solo permita la instalación de apps ya alojadas en Google Play tampoco resta importancia al problema. Google mantiene una política de lista negra. En Google Play no es nada complicado subir aplicaciones troyanizadas, malware, o adware muy agresivo. Pueden desaparecer más o menos rápido, pero desde luego, no se debe transmitir la idea de que usar el market oficial es una garantía.

Además, la solución no parece muy robusta. Permitir al usuario la toma de decisiones sobre acciones que no termina de entender no resulta una barrera muy compleja de eludir para un atacante. El usuario nunca ha sido ni será bueno, a la hora de tomar decisiones de seguridad. Incluso las advertencias más llamativas y los permisos más explícitos no podrán con un usuario medio que confía en la aplicación, desconoce lo que implican los permisos y además, toma decisiones basadas en su comodidad eludiendo toda seguridad.

En el fondo, confiar en un modelo de permisos tampoco es una buena solución. El usuario (incluso los más avanzados) no saben que permisos aparentemente inocuos pueden suponer un problema grave para la privacidad y, como demuestra este fallo, pueden suponer el primer paso hacia un mal mucho mayor. De hecho, el adware (el malware más numeroso en Android) no necesita de tantos permisos como se piensa. Los atacantes saben adaptarse. Desde que con Windows Vista, el usuario no suele ser administrador "por defecto" (en rigor sí lo es, pero le separa el UAC de sus "poderes") el malware para Windows ha tenido que adaptarse a las circunstancias y asumir que no disponía de plenos permisos en el equipo. Se han revalorizado las posibilidades de elevar privilegios, sí, pero también la imaginación para explotar al usuario con los recursos de los que se disponen. De ahí, el auge del ransomware y el virus de la policía. No necesitan permisos especiales (con acceder a donde más duele al usuario, a sus documentos y fotos, le vale) y resultan igual de lucrativos. Un claro ejemplo es esta app falsa para Whatsapp alojada durante horas en Google Play, de la que ya hablamos hace tiempo, que necesitaba menos permisos que la original. Y eso no la hacía más segura precisamente.

WhatsApp Messenger falso colgado en Google Play

Por último, el sistema de "always logged in" de Google, que convierte Internet en una suerte de Single Sign-On para el usuario tanto en sus dispositivos como en la red, parece que también puede trasladar y amplificar problemas de una manera más compleja.

Sergio de los Santos
ssantos@11paths.com

"Latch: Protección de identidades digitales" en el X Ciclo de Conferencias UPM TASSI 2014

lunes, 17 de marzo de 2014

Ya se encuentra disponible en el canal YouTube de la Universidad Politécnica de Madrid, la primera conferencia del X ciclo UPM TASSI 2014, Temas Avanzados en Seguridad y Sociedad de la Información. El título de la conferencia es "Latch. Protección de identidades digitales".

Fue presentada el 20 de febrero de 2014 en el Campus Sur de la Universidad Politécnica de Madrid por nuestro compañero el  Dr. Antonio Guzmán Sacristán, director del área de investigación en Eleven Paths. En ella, durante más de una hora, explica desde el punto de vista técnico cómo funciona esta tecnología, cómo aprovecharla, y qué ventajas y soluciones propone. Antonio fue el encargado de redactar y dar forma a la patente bajo la que se registró esta tecnología.

Disponéis de más documentación y otras conferencias del ciclo en la sección Conferencias TASSI 2014 de Criptored: http://www.criptored.upm.es/paginas/docencia.htm#TASSI2014




BitCrypt y el malware fácil de descifrar (II): El porqué

viernes, 14 de marzo de 2014

El ransomware ha venido para quedarse. Existen fundamentalmente dos tipos: los que bloquean el acceso al sistema (que populariza todavía el "virus de la policía") y los que (incluso adicionalmente) cifran los contenidos. En ambos casos, el negocio se basa en pedir un "rescate" (bien por el control, bien por el contenido). En esta entrada se relatará técnica y matemáticamente el funcionamiento de uno de ellos, bitCrypt y cómo (y por qué) un error de cálculo ha permitido descifrar el contenido de los archivos que "secuestra".

Un rápido repaso al RSA

BitCrypt alardea de usar claves RSA de 1024. RSA es un algoritmo criptográfico de clave asimétrica, basado en una clave pública y en una privada (también un algoritmo de firma). Los parámetros necesarios que configuran este sistema se resumen como sigue:
  • m = número que representa el mensaje original que se desea cifrar.
  • c = mensaje cifrado.
  • n = pq = módulo para las claves.
  • p, q = factores de n.
  • e = clave pública o exponente público.
  • d = clave privada o exponente privado.
Para llevar a cabo la operación de cifrado se realiza el siguiente cálculo:

De la misma forma, para descifrar se utiliza:
Finalmente, se deben considerar las siguientes observaciones:


BitCrypt también dice que usa el RSA para cifrar la clave AES. Respecto a AES, únicamente mencionar que es un algoritmo de cifrado simétrico (usa la misma clave para cifrar y descifrar) con un tamaño de bloque fijo de 128 bits y variable de la clave entre 128 y 256 bits. Es bastante robusto y eficiente.

Cómo lo hace BitCrypt

Repasemos los pasos:
  • En primer lugar se genera una contraseña aleatoria para el archivo actual que será utilizada posteriormente por AES.
  • Se cifra con AES todo el fichero original con la contraseña anterior y se añade la extensión .bitcrypt.
  • Seguidamente se cifra con RSA la contraseña utilizada y se anexa al final del fichero. Junto con esto, se guarda información importante para el descifrado como el módulo de la clave pública (n), que se almacena codificada en algo que parece base64, pero no es más que un alfabeto de sustitución. El exponente público utilizado es siempre el mismo (el típico 0x10001). El uso tan frecuente de este valor se debe principalmente a la eficiencia de la exponenciación, llevada a cabo mediante 16 desplazamientos de bits a la izquierda sumando 1. Además, este número es lo suficientemente grande para evitar problemas con implementaciones incorrectas que no hagan un buen uso del padding.
En Cassidian Ciberscurity, analizaron los ficheros afectados y se dieron cuenta de que no era cierto lo indicado en la información proporcionada sobre el uso de RSA de 1024. La verdad era que se estaba utilizando RSA 426, lo que modificaba completamente el panorama. Al usar una clave tan corta resulta factible abordar su factorización, "rompiendo" por fuerza bruta el cifrado RSA. De hecho, la longitud mínima de n recomendada hoy en día es de 2048 bits.

Sabiendo que los atacantes usan criptografía fuerte, pero con claves débiles, ¿cómo (en la teoría) se produciría la ruptura?

Cómo se rompen las claves RSA

El objetivo de los algoritmos que intentar romper RSA consiste en determinar los valores correspondientes a los números d, p y q desconocidos en un comienzo. Una vez tengamos estos datos en nuestras manos se podría llevar a cabo el proceso de descifrado explicado anteriormente y recuperar por tanto el mensaje original.

Sin embargo, generalmente no resulta computacionalmente factible obtener estos valores. Lo más cómodo sería conseguir d, por lo que se hace uso de la observación 2 de RSA:


Por tanto, el objetivo principal se resume en resolver un problema de factorización de grandes números, es decir, encontrar los valores de p y q tales que satisfagan n = pq. Para ello usaron CADO-NFS.

La manera en la que el algoritmo CADO-NFS se encarga de romper el proceso de cifrado RSA utilizado por bitCrypt se basa en hacer cálculos matemáticos para llegar a encontrar la factorización (p y q) del número n (módulo utilizado en el algoritmo RSA).

En el caso de un módulo de 426 bits, tardará un promedio de unas 14 horas en un servidor de 24 núcleos y unas 43 horas en un ordenador doméstico de 4 núcleos. Comparado con los cientos o incluso miles de años que necesitaríamos para factorizar una clave de mayor tamaño, el método deja la puerta abierta a la recuperación de los archivos más importantes para los afectados por esta versión del troyano. Las instrucciones para conseguirlo pasan por utilizar este script.

Una vez encontrados p y q se obtiene el exponente privado d y se puede recuperar la contraseña aleatoria utilizada por AES que había sido cifrada con RSA de 426 bits anteriormente. Siguiendo los pasos del proceso de descifrado fichero a fichero se puede obtener la información original.

BitCrypt y el malware fácil de descifrar (I): El qué
Julia Llanos
julia.llanos@11paths.com

BitCrypt y el malware fácil de descifrar (I): El qué

miércoles, 12 de marzo de 2014

El ransomware ha venido para quedarse. Existen fundamentalmente dos tipos: los que bloquean el acceso al sistema (que populariza todavía el "virus de la policía") y los que (incluso adicionalmente) cifran los contenidos. En ambos casos, el negocio se basa en pedir un "rescate" (bien por el control, bien por el contenido). En esta entrada se relatará técnica y matemáticamente el funcionamiento de uno de ellos, bitCrypt y cómo (y por qué) un error de cálculo permite descifrar el contenido de los archivos que "secuestra".

El ransomware está de moda por varias razones.
  • Es relativamente sencillo de programar para los atacantes. No requiere de grandes privilegios en el sistema (principal problema para muchos creadores de malware gracias a la popularidad de Windows 7 y 8) y permite "tener el control" aunque no sea a bajo nivel del sistema operativo. Porque aun sin ser administrador de la máquina, el usuario infectado siempre tendrá acceso a lo que más le duele: sus documentos, fotografías y archivos personales.
  • Ha demostrado ser muy eficaz. Mucho ransomware apela a un potencial sentimiento de culpa del usuario ("en este ordenador se han encontrado archivos pirata", o "se han detectado actividad ilegal"...) y con ello han conseguido que muchas víctimas prefieran pagar, antes de (quizás) reconocer ciertas acusaciones como verdaderas. 
Además existen decenas de variantes y características. Como ejemplo reciente de malware que se puede considerar ransomware, (pero que ni cifra ni bloquea) en febrero de 2014 surgió Linkup. Se reconoce como el primer troyano ransomware basado en la modificación de la configuración del DNS, bloqueando así la conexión a Internet. Se pedía un rescate simbólico de 1 céntimo a través de una tarjeta de crédito, cuyos datos seguramente serían usados posteriormente para hacer fraude bancario. Para colmo, se ponía a minar bitcoins. Aunque ya se conocen de sobra los DNSchangers (que en vez de secuestrar desviaban el tráfico), esta variante toma "lo mejor de los dos mundos".

BitCrypt

Mensaje que aparece prometiendo una solución una vez se ha pagado el rescate
BitCrypt no resulta en esencia una gran novedad. Hablamos de él como excusa para repasar la criptografía. Surgido también en febrero de 2014, cifra los archivos del sistema infectado y abre un fichero de texto (bitcrypt.txt) que contiene las instrucciones para recuperar la información. Acepta solo bitcoins y la página de rescate se muestra como una empresa "salvadora" del desastre que sufre la víctima (obviando el pequeño detalle de que el problema lo ha generado ella misma). Si llama la atención este malware no es por su modo de operar (clásico) sino por un error criptográfico interesante.

Cómo funciona

El mensaje que abre bitCrypt. En él se observa que habla de claves de 1024 bits, y ofrece un ID
En el fichero de instrucciones se alerta de que los archivos están cifrados mediante RSA con clave de 1024 bits y los pasos que hay que seguir para recuperarlos. También, el identificador necesario para pagar, porque cada usuario afectado generará una clave de cifrado diferente. Nos proponen acceder a la dirección www.bitcrypt.info o alternativamente a unas direcciones de la red TOR, (por si dejaran de tener acceso a ese dominio, cosa que ya ha ocurrido). En esta página se introduce el identificador proporcionado y después el "wallet" para transferir el importe en bitcoins del rescate (0,4 bitcoins, aproximadamente 260 euros en esas fechas).

Una página muy "profesional" que ofrece la solución a "BitCrypt software"
Incluso cuenta con soporte online
Una vez finalizados estos pasos y verificado el pago, se supone que se facilita un programa encargado de recuperarlos. En el equipo, el malware crea un fichero de configuración (bitcrypt.ccw), evita la ejecución del administrador de tareas y el editor de registro de Windows y cifra todos los archivos con extensiones consideradas interesantes para la mayoría de usuarios (documentos de Word, Excel, bases de datos, comprimidos, imágenes... incluso los javascript....) utilizando para ello los datos del identificador como módulo de la clave pública de RSA.

El malware cifra usando una combinación de criptografía simétrica y asimétrica. Entraremos en los detalles matemáticos en la próxima entrada. Lo interesante es que observando un fichero cifrado cualquiera, lo primero que llama la atención es que aunque en el mensaje de advertencia se habla de un cifrado RSA con clave 1024 bits... esto no parece del todo cierto. Cassidian Cibersecurity, descubrió el problema.

Solo hay que observar detenidamente la longitud para comprobarlo. Veamos este ejemplo real de clave pública, extraída de un fichero infectado:

Ejemplos de ficheros cifrados a la izquierda, y uno de ellos abierto a la derecha, con detalle de clave pública
Fow7VwXer4QLrVghntG8qHlM+21u7KgS1291XY8akfjQ4lsVAojqBeW+mh3Bwk12hsGtkFU 


Aunque parece base64, no lo es. Acudimos a este script en python realizado para la ocasión, que traduce la clave a bits (6 bits por cada "letra" de su alfabeto), lo que hace un total de 71 * 6 = 426 bits.

Si modificamos un poco el script para que muestre la clave decodificada en binario, se observa perfectamente.

Script ligeramente modificado para que muestre la clave en bits, y se compruebe su tamaño real (426 bits)
Así que parece que la clave no es de 1024 bits, como afirmaban los atacantes, sino de 426. ¿Qué supone esto y cuál es el problema exactamente? Lo veremos en la siguiente entrada.

BitCrypt y el malware fácil de descifrar (II): El porqué

Julia Llanos
julia.llanos@11paths.com

Sergio de los Santos
ssantos@11paths.com

El negocio de las "FakeApps" y el malware en Google Play (III): Estrategias

lunes, 10 de marzo de 2014

Seguimos observando las apps falsas en Google Play. En esta entrada estudiaremos qué aplicaciones son las que más se "simulan". Esta clasificación tampoco pretende ser demasiado rigurosa ni exhaustiva puesto que las modas y las circunstancias van cambiando periódicamente. Sí que puede llegar a reflejar la tendencia del último trimestre de 2013, periodo durante el que se ha desarrollado el estudio principalmente.

Fundamentalmente, los atacantes se basan en tres pilares para saber qué aplicaciones falsificar:
  • Aplicaciones de pago que se ofrecen supuestamente gratis. Es el caso de, una de las más deseadas es Minecraft Pocket Edition, sin duda la más imitada durante meses y uno de los baluartes de los atacantes. La original cuesta 5,49 euros.

App de Wreck-it Ralph falsa (a la derecha), que pretende imitar a la oficial de pago (a la izquierda)

  • Aplicaciones que estuvieron disponibles oficialmente en Google Play hace tiempo, pero ya no aparecen (han sido expulsadas por políticas de uso u otras razones). Adblock Plus es un buen ejemplo. Los usuarios siguen buscándolas en el market oficial, y ahí es donde encuentran a sus víctimas despistadas.

Ejemplos de Adblock falso y Tubemate Falso en Google Play

  • Una de las más imitadas y usadas como reclamo son las aplicaciones que están a punto de salir para la plataforma Android. Es el caso de Clash of Clans. Durante 2013 se bombardeó Google Play con réplicas falsas de este juego. Finalmente se hizo oficial su aparición en Google Play el 1 de octubre. Igual ocurrió durante ese verano con Blackberry Messenger.
  • Aplicaciones muy populares. Obviamente, los atacantes usan la imagen de apps muy populares como reclamo. Es el caso de WhatsApp (donde un día se pudieron contar cerca de 30 falsificaciones subidas concurrentemente), GTA, Pinterest, Flappy Birds, Candy Crash...

Ejemplo de varias apps falsas de Pinterest, colgadas por un fabricante fraudulento

Real Racing 3 y app de Los Simpsons falsas, creadas por un mismo fabricante fraudulento

  • Aplicaciones que solo están disponibles para iPhone. Un reclamo son las apps que solo están disponibles para "la competencia" y puede que un futuro (o no) se programen en Android. Un claro ejemplo son Clumsy Ninja o Quiz Up.

Quiz Up es una app popular en iPhone, pero no disponible para Android
Clumsy Ninja se puede encontrar en Apple Store, pero no en Android. Mucho menos su inexistente (hasta la fecha), segunda versión


Sospechosos habituales


En general, los "sospechosos habituales" (esto es, las apps más populares del momento y muy suplantadas) son cambiantes. Durante el tiempo de este estudio y de forma habitual, destacan especialmente los siguientes.

  • Tubemate Youtube Downloader: Es una aplicación "rechazada" por Google Play que, por tanto, debe ser descargada e instalada desde otras fuentes. También es muy deseada, y por tanto un gancho fácil para quien desconozca que oficialmente no puede encontrarse en el market oficial pero la busque ahí.

Aviso oficial de la app TubeMate, advirtiendo de las apps falsas imitándola

  • Aptoide: Una aplicación para crear un market propio. Tampoco puede encontrarse oficialmente en Goolge Play, sin embargo, no es difícil encontrar fakes.

Dos ejemplos e Aptoides falsos en Google Play

  • BlackMart Alpha: Una aplicación que dice que descarga aplicaciones de pago gratis. Obviamente no debe estar en Google Play.

Un ejemplo de BlackMart Alpha en Google Play

  • Hay Day, Clash of Clans, Infitnity Blade III y Plant vs Zombies 2...: Las primeras del mismo fabricante (Supercell). Clash of clans está disponible en Google Play solo desde el 1 de octubre de 2013.

Ejemplo de varios Clash of Clans, TubeMate y Minecraft falsos en Google Play, un día cualquiera de finales de 2013
Ejemplo de Plants vs. Zombies 2 falso que permite grabar sonido

  • BBM, BlackBerry Messenger. Un "clásico". Su entrada en Google Play era muy esperada. Ya hace unos meses se encontraron aplicaciones falsas que simulaban ser BBM messenger, pero durante el mes de septiembre y octubre de 2013 la expectación ante su inminente aparición oficial aumentaba entre los usuarios, lo que disparó el número de apps falsas que decían serlo días antes de estar oficialmente disponible. Durante estos meses, muchos atacantes han centrado su gancho en ella.

Con esta "lista de deseos" de los usuarios, entre apps populares y esperadas, el atacante detalla un plan. Habitualmente, lo que hacen es que un mismo atacante sube un conjunto de estas aplicaciones falsas "sospechosos habituales" con ligeros cambios en el nombre una y otra vez, en grupos, aunque todas suelen ser más o menos el mismo adware, sin importar muy bien contra quién intenta realizar la suplantación. Así consiguen un mayor éxito, centrándose en el conjunto de aplicaciones "estrella" del momento, subiéndolas todas diariamente o cada vez que son retiradas.

Estos son algunos de los ejemplos de lotes de aplicaciones falsas agrupadas por "falso fabricante". Este falso fabricante (aunque detrás se encuentra un mismo atacante o grupo) subía a diario estos lotes. Observando el conjunto, se puede completar una buena parte de los títulos de apps más falsificados durante los últimos meses.
Ejemplos de diferentes fabricantes, durante diferentes días, que imitaban un buen número de apps falsas o bien aún no disponibles oficialmente en Google Play


El negocio de las "FakeApps" y el malware en Google Play (I): Introducción 
El negocio de las "FakeApps" y el malware en Google Play (II): Tipos de "fakes"
El negocio de las "FakeApps" y el malware en Google Play (III): Estrategias
El negocio de las "FakeApps" y el malware en Google Play (IV): Política y rentabilidad
El negocio de las "FakeApps" y el malware en Google Play (V): Limpieza automática
El negocio de las "FakeApps" y el malware en Google Play (VI): Limpieza "manual"
El negocio de las "FakeApps" y el malware en Google Play (VII): Cómo llegan a las víctimas
* El negocio de las "FakeApps" y el malware en Google Play (VIII): Permisos en las apps
El negocio de las "FakeApps" y el malware en Google Play (IX): ¿Qué hacen y cómo se programan las apps?


Sergio de los Santos
ssantos@11paths.com

Eleven Paths on "Digital Futures" video series

jueves, 6 de marzo de 2014

Telefonica Digital produces a video series called Digital Futures, which are publicly available here http://youtube.com/telefonicadigital. On the latest episode, some relevant people from the world of security gives us some insights. The episode features our very own Jose Palazón, from Eleven Paths.

In this episode of Digital Futures, they have quizzed an ethical hacker, top researcher, cyber forensics pro and security guru on trends in hacking and cyber security that we all need to look out for, both as a business or a consumer. The video is in English with Spanish subtitles.

This is a special longer version on cyber security, and is featuring relevant people like David Day (senior lecturer and Consultant, information security and forensics in Sheffield Hallam University), Eduard Lucas (Senior editor at The Economist author of The Snowden Operation: Inside the West's Greatest Intelligence Disaster), and Tim Holman, (CEO at 2-sec and president of ISSA-UK). And of course, Jose Palazón, responsible for Latch working properly.


Eleven Paths en la serie de vídeos "Digital Futures"

Telefonica Digital produce una serie de vídeos llamada Digital Futures, que está disponibles públicamente en este canal http://youtube.com/telefonicadigital. En el episodio más reciente, algunas personas muy relevantes en el mundo de la seguridad nos ofrecen su visión sobre el asunto. En este episodio aparece nuestro arquitecto de software en Eleven Paths, Jose Palazón.

En este episodio han preguntado a un hacker ético, a un investigador, un profesional forense y a un gurú de la seguridad, por las tendencias de la ciberseguridad y los atacantes de las que todos deberíamos estar al tanto, como empresas y consumidores. El vídeo se muestra en inglés con subtítulos en español.

Esta es una versión un poco más larga de lo habitual, en la que aparecen nombres relevantes como David Day (académico y consultor forense y de seguridad de la información en la Universidad Sheffield Hallam), Eduard Lucas (Editor senior en The Economist y autor de The Snowden Operation: Inside the West's Greatest Intelligence Disaster), y Tim Holman, (CEO de 2-sec y presidente de ISSA-UK). Por supuesto, también Jose Palazón, responsable del buen funcionamiento de Latch.


Ataques contra redes de satélites (y II)

lunes, 3 de marzo de 2014

Los sistemas satelitales juegan un papel clave a nivel mundial, porque facilitan la transmisión de información a todos los rincones del planeta, y esto influye tanto en el aspecto económico, como social, político y militar. Como consecuencia de la gran dependencia que se ha desarrollado hacia las tecnologías vía satélite garantizar la seguridad de su infraestructura es una cuestión vital. No conviene olvidar que a pesar de situarse a miles de kilómetros sobre nuestras cabezas, las redes de satélites son tan vulnerables como cualquier otra red de comunicaciones.

Veamos otros tipos de ataque posibles.

Hijacking (secuestro de la señal)

Este ataque está especialmente ligado a las transmisiones de "broadcast" y a las conexiones de Internet vía satélite. Los atacantes buscan hacer uso del satélite para transmitir su propia información, eliminando o alterando la información legítima. Llevar a cabo este ataque no requiere una infraestructura demasiado costosa, siendo relativamente sencillo obtener el software y el hardware necesarios. El caso de hijacking satelital por antonomasia es el del Capitán Midnight, cuando en 1986 un ingeniero electrónico de Florida se hizo con el control de la señal de un satélite de la cadena de televisión HBO e hizo que en las pantallas de los espectadores se imprimiese un mensaje en el que se quejaba del precio de la suscripción.

Mensaje del "Capitán Midnight" (Fuente: wikipedia)

Otro peculiar caso de secuestro más reciente ocurrió en 2013, cuando una televisión local de Montana causó un gran revuelo al emitir una transmisión de emergencia anunciando un supuesto apocalipsis zombi.

Control total del satélite 

Podría resultar en el más peligroso, porque además de comprometer la integridad de la información, también pone en riesgo la integridad del satélite en sí. Este ataque requiere conocimientos y equipo especializados, puesto que es necesario interrumpir el enlace entre la estación TT&C y el satélite. En el caso de los satélites militares no siempre es posible. El motivo es que en la mayoría de los casos la estación TT&C se encuentra en el interior de bases militares, y acceder a ellas físicamente supone el mayor obstáculo para los atacantes. En cambio, si se trata de tomar el control de un satélite comercial, el escenario es menos exigente.

Si un atacante toma el control completo de un satélite, puede hacer prácticamente de todo: desde variar ligeramente su órbita hasta forzar su reentrada en la atmósfera. Son pocos los casos confirmados de ataques de este tipo, siendo el más conocido el del satélite ROSAT. En 1998, uno de los propulsores de este satélite germano-estadounidense se activó a la máxima potencia. Como resultado, el satélite giró sin control y su cámara de alta resolución quedó expuesta directamente a la radiación solar. Quedó inutilizada. Investigaciones posteriores de la NASA determinaron que ciertos atacantes rusos habían burlado la seguridad del Goddard Space Flight Center y causado el incidente.

Redes críticas, también con vulnerabilidades

Actualmente existen más de un millar de satélites operacionales, pertenecientes a medio centenar de estados y organismos internacionales. Representan una infraestructura crítica de la que depende una gran parte del equilibrio económico y social del mundo. Necesitamos más que nunca las redes de satélites. Podemos concluir que un ataque persistente sobre ellas podría tener consecuencias desastrosas. Así que no se deben infravalorar las vulnerabilidades que presentan estos sistemas, ni olvidar la inversión necesaria para preservar su seguridad.

* Ataques contra redes de satélites (I)

Cristóbal Bordiú
cristobal.bordiu@11paths.com