Ataques contra redes de satélites (I)

jueves, 27 de febrero de 2014

Los sistemas satelitales juegan un papel clave a nivel mundial, porque facilitan la transmisión de información a todo el 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.

Ideas preliminares

Antes de profundizar en los ataques que pueden sufrir, es conveniente conocer algunas ideas básicas relacionadas con las redes de satélites. A pesar de existir distintas topologías, la estructura más habitual de un sistema de comunicaciones vía satélite incluye los siguientes elementos:
  • Uno o más satélites de comunicaciones, que no son más que repetidores radioeléctricos situados en el espacio que reciben señales desde un punto de la Tierra y las reenvían a otro.
  • Un centro de control TT&C (Tracking, Telemetry and Control). Es una estación en tierra que se ocupa de la gestión y monitorización de la posición y rendimiento del satélite.
  • Una o varias estaciones de comunicaciones que realizan las funciones de transmisión/recepción de los datos y actúan de interfaz con otras redes de comunicaciones (por ejemplo Internet).
  • Dispositivos de usuario, tales como equipos comerciales que hacen uso del enlace descendente para recibir información, como por ejemplo los dispositivos de navegación GPS o las antenas parabólicas de televisión por satélite.
Elementos de una red satelital. Fuente: http://www.netcomsec.co.jp/

Distinguiremos entre cuatro tipos de ataque contra redes satelitales, y añadiremos algún caso histórico en el que haya sido pública la perpetración con éxito del ataque descrito.

Denegación de servicio ("jamming")

La naturaleza radioeléctrica y la capacidad de "broadcast" del medio de transmisión hacen que este ataque sea uno de los más factibles. La idea sobre la que se basa es muy sencilla: emitir una señal no deseada (por ejemplo, ruido blanco) con la suficiente potencia como para saturar la porción del espectro radioeléctrico que utiliza el satélite objetivo. El alcance del ataque y su dificultad están relacionados. Atacar el enlace descendente es relativamente sencillo, pues basta con conocer la frecuencia de emisión del satélite y disponer de una antena directiva con la que apuntar al receptor para inhabilitarlo. Sin embargo, con esta técnica el atacante tan solo puede dejar fuera de servicio a una pequeña fracción de los usuarios del sistema. Si por el contrario se ataca el enlace ascendente (lo que es más difícil, ya que requiere conocimiento de la posición del satélite y una potencia de emisión mucho mayor), se puede dejar sin servicio a todos los usuarios de la red.

A lo largo de la historia se han documentado numerosos casos de "jamming" a satélites, muchos de ellos en el ámbito de la llamada "ciberguerra". Por ejemplo, en el año 2000, durante unas maniobras de entrenamiento en Grecia, tanques británicos y estadounidenses tuvieron graves problemas de navegación. Investigaciones posteriores revelaron que una agencia de seguridad francesa fue responsable del incidente, utilizando dispositivos situados sobre el terreno para realizar jamming a la señal GPS. En 2003, Cuba e Irán colaboraron para bloquear las transmisiones del Telstar-12, un satélite comercial estadounidense situado en órbita geoestacionaria sobre el Atlántico. En 2005, el gobierno Libio ordenó un ataque de "jamming" contra dos satélites de comunicaciones, interrumpiendo servicios de televisión en Europa e interfiriendo comunicaciones militares estadounidenses.

Captura de tráfico

Con un presupuesto relativamente bajo, un atacante puede adquirir el equipo necesario para realizar "eavesdropping" en comunicaciones vía satélite. El ejemplo más frecuente y conocido es la recepción ilegal de televisión por satélite. El grado de dificultad que conlleva montar una antena receptora "pirata" es mínimo. Pero existen más alternativas, mucho más peligrosas. Las llamadas telefónicas vía satélite. Si bien hoy en día son menos frecuentes gracias al uso de cables submarinos, están expuestas a escuchas ilegales, por lo que resulta fundamental cifrar las comunicaciones. En el ámbito militar el panorama es aún más grave. Multitud de transmisiones militares vía satélite son sensibles al "eavesdropping". En 2009, insurgentes afganos e iraquíes lograron capturar vídeos grabados por drones "Predator" que se transmitían en claro hacia el satélite, usando como única herramienta SkyGrabber, un software comercial de la empresa rusa SkySoftware que cuesta tan solo 26 dólares.


Esquema de comunicación estación terrena - dron - satélite. Fuente: http://www.nasa.gov/

Continuaremos en la siguiente entrega, hablando del secuestro de la comunicación o de cómo se puede llegar a tomar el control completo de un satélite.

* Ataques contra redes de satélites (y II)

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

El negocio de las "FakeApps" y el malware en Google Play (II): Tipos de "fakes"

martes, 25 de febrero de 2014

¿Qué tipo de "malware" encontramos en Google Play? Ante esta discusión sobre niveles de infección que presentábamos en una entrada anterior, no es sencillo saber quién tiene razón. Lo primero que habría que definir es qué es malware exactamente, al menos en el contexto de Google Play.

Seguimos observando las apps falsas en Google Play. En esta entrada estudiaremos una posible clasificación del "fakes" que se puede encontrar en el market oficial, junto con algunos ejemplos. Esta clasificación no pretende ser demasiado rigurosa ni exhaustiva puesto que se basa más en el "aspecto" que pueden adoptar las apps falsas que en lo que pueden llegar conseguir en el teléfono. En estos casos, su objetivo suele ser siempre conseguir descargas oportunistas, rápidas y lucrativas. Normalmente intentan la instalación en el teléfono (aunque sea efímera) y que esto le permita al menos ser pagado por instalación de un paquete de publicidad, u obtener datos relevantes.

Troyanos (bancarios o no)


Se podría incluir aquí el concepto de malware de Windows trasladado a Android. Esto, aunque parezca muy amplio, quiere decir que se traslada el concepto de lucro despiadado a través del robo de datos, suplantación de apps bancarias, phishing... También los hay incluso que intentan infectar Windows a través del teléfono y viceversa cuando se conectan. De estos hay tantos como malware en Windows, y cada uno con su forma particular de actuar, pero aprovechan especialmente las particularidades del sistema operativo. Afortunadamente, son los más difíciles de ver en Google Play, pero no por ello son "raros".


Lo cierto es que parece una industria al alza, con avistamientos de malware sofisticado, con un funcionamiento (tanto técnico como logístico) muy parecido al malware bancario tradicional para Windows, como por ejemplo el reciente iBanking, cuyo código fuente se ha filtrado, pero se estaba vendiendo en entornos underground. Contaba con un panel de control web, al estilo del malware "tradicional" para Windows.

Malware y aplicaciones "espía"

Sin intentar imitar a nadie, son realmente sistemas de rastreo, espía, etc. Quizás orientados al control de menores. Pensadas para usuarios que deseen directamente espiar/troyanizar a alguien. No se ocultan, y dejan a criterio del usuario su utilidad. A veces Google Play las retira.

Programas que "parecen" otros, pero no lo son realmente. 

Ejemplo de app que, aun usando la imagen original del juego,
deja claro que se trata de una guía

Intentan confundir al usuario. Su finalidad es conseguir descargas y lucrarse con la publicidad o realmente infectar al usuario a través de otros medios. Suelen ser oportunistas, esconderse bajo la coletilla de "wallpapers" sobre alguna actriz o película de moda, o bajo las palabras "guide", "hacks", "unlimited coins", "cheats".... como guías y trucos para pasar ciertas pantallas complejas de los juegos del momento. Mientras que las guías legítimas suelen dejar bien claro lo que son en la imagen y descripción de la app, otros no hacen distinción, invitan a la confusión e intentan infectar al usuario.
Ejemplo de app que, usando de manera ilegítima la imagen del juego,
añade "Tricks" al título para intentar pasar desapercibida

Los atacantes que utilizan la coletilla de "tricks" en sus nombres, manteniendo la imagen original del juego (y por tanto confundiendo al usuario) consiguen permanecer en Google Play mucho más días y pasar más desapercibidos. Durante el tiempo que ha durado este estudio, hemos observado algunos programas falsos que, siendo simplemente adware, con estas coletillas en el título han conseguido sobrevivir semanas en el market.
Otro ejemplo que añade "Free" al título para mantenerse más tiempo en el market

Original a la izquierda, falso a la derecha. Este tipo de apps suelen durar mucho más tiempo en Google Play, por pasar más desapercibidas. A cambio, suelen tener menos descargas y por tanto, "éxito"
Programa legítimo de pago y otro falso con el logotipo ligeramente modificado. Pocas descargas pero aún sigue disponible en Google Play



Programas que parecen otros, lo son e incluso puede que funcionen como el resto, pero además incluyen adware


Los atacantes reempaquetan el original al más puro estilo de los troyanos clásicos. Esto fue muy habitual hace pocos años y se generaron muchas alertas al respecto. Parece que ahora ocurre en menor medida después de que Google mejorara sus filtros. En algunos casos, la confusión es total sobre cuál es el juego "original".

¿Cuál es el Frozen Bubble "oficial"?
Todos tienen pesos diferentes (desde 600k hasta 8 megas) y requieren distintos permisos,
aunque dicen ser el... ¿mismo juego?


Programas estafa


Son los programas que buscan la estafa directamente, invitando al usuario a pagar por servicios por los que probablemente nunca pagaría conscientemente, o suscribiéndolos de forma poco clara a mensajes premium, incluso si necesitan confirmación. Ya son varias las muestras que se han encontrado en Google Play que eluden la confirmación a través de un PIN en un SMS, de forma que el propio programa lee el mensaje de confirmación y "responde" por el usuario. Así,queda suscrito de forma transparente (sin confirmación explícita) y se le comienza a cobrar por mensaje recibido. Este caso fue ampliamente discutido aquí, aunque Panda ya ha encontrado otros ejemplos similares.
Estafa a través de aplicación que invita a pagar 5 euros por un enlace a la descarga oficial
Dentro de este modelo, se pueden observar varios ejemplos centrados en España de los que hemos hablado en otras ocasiones.

Aquí podríamos incluir las supuestas "bromas" que solo sirven para robar datos. Es ya un clásico la broma de las WiFis. Se trata de aplicaciones que dicen poder "adivinar" las claves de las WiFi alrededor del teléfono. Algunas de ellas, avisan de que son una simple broma.

App que hace pensar que tiene unas funcionalidades, pero que solo avisa de que son mentira en su descripción


Pero muchas otras, no. De lo que tampoco avisan, es de que pueden contener código como este en su interior:

Código que envía información personal a un dominio, escondido en una aplicación supuestamente de broma


Las aplicaciones que supuestamente avisan de que son una "broma" a modo de "disclaimer", pueden permanecer en Google Play indefinidamente, independientemente de que realicen este robo de datos en segundo plano.

Programas que, en Google Play son presentados como réplicas casi exactas de otros 

Ejemplos muy logrados de apps falsas.
El verdadero fabricante de Candy Crush y Pet Rescue es king.com,
no King Mobile game
Estos han sido muy comunes durante todo 2013. Excepto en el nombre del fabricante y el número de descargas, sería complicado reconocer si una aplicación es legítima o no. Se trata de apps que son simplemente adware, no contienen la funcionalidad del software original que intentan suplantar. Serían las "FakeApps" que hemos estudiado y de las que hemos recopilado un buen puñado de ejemplos. En todos, el fabricante es simulado, inventado, o deliberadamente remite a alguna parte del título del juego. Suelen pesar entre 200 y 400 kilobytes (frente a los varios megas de las apps originales que simulan) y solo constan del código necesario para que se ejecute el adware.

Es importante destacar que en ocasiones, ni siquiera son cazados como malware por ningún motor antivirus. A veces incluso requieren menos permisos que las originales, o no contienen un sistema de profesionalización del malware. Basta con que no sean lo que prometen (no contengan en ningún momento la funcionalidad prometida) y supongan algún tipo de intrusión en el teléfono (con adware), como para que sean consideradas "fake".

El primero es el original, el segundo el fake. La palabra "Internacional" en el título queda casi oculta

En cualquier caso, resulta evidente la importancia del nombre y, sobre todo, la imagen. Más aún que la descripción, imágenes, o incluso descargas y reputación del fabricante. Un atacante que consigue mimetizar imagen y título de una app, tendrá muchas descargas rápidas garantizadas. Si la búsqueda se realiza desde un móvil, el desconcierto para el usuario y las posibilidades de que "pique" aumentan considerablemente, porque los elementos con los que cuenta el usuario para evaluar disminuyen, facilitando la estafa. En el ejemplo de la figura (donde se suplanta la imagen de BlackBerry Messenger), se muestra cómo la aplicación maliciosa puede llegar a aparecer antes incluso que la legítima en las búsquedas. 
El atacante aparece antes que la aplicación
legítima en las búsquedas

Este tipo de estafas ha sido muy común durante 2013 en Google Play, aunque parece que empieza a remitir el fenómeno. También, como último ejemplo, para el atacante es importante ser muy oportuno, en el sentido de estar al tanto de las últimas búsquedas y tendencias para practicar un buen SEO dentro de Google Play. Si es necesario, incluso pueden modificar nombre e icono de una aplicación cuando así lo requiere "el mercado" aun a riesgo de que no describa para nada la utilidad real. Solo para ganar descargas. Este es un buen ejemplo reciente.

Aplicación de audio y vídeo a la que modificaron el nombre y el icono tras el "boom" mediático de Flappy Bird
Continuaremos en la próxima entrega analizando qué aplicaciones suelen ser falseadas y más ejemplos.


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

Gravísimo error en sistemas operativos de Apple invalida el TLS/SSL. Goto fail

lunes, 24 de febrero de 2014

Apple ha cometido un gravísimo (que casi roza el ridículo) error en su implementación de SecureTransport, una capa del sistema de gestión de TLS/SSL como ya han contado nuestros compañeros en Seguridad Apple. En resumen, introduciendo por error una línea de código, ha invalidado por completo el SSL en iOS y Mac OS X durante unos dos años, la criptografía más fundamental y pilar de la confianza web. Tan simple y absurda, que podría parecer intencionada. Veamos qué ha pasado y sus consecuencias.

Apple lanzó una actualización muy urgente para iOS (no aún para Mac OS X que continúa con el problema). Como siempre, sin demasiados detalles y con vagas referencias a SSL. Pero poco después se descubrieron los detalles del problema.

Código abierto en http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslKeyExchange.c

Se observa una línea repetida "goto fail". La indentación es incorrecta y es lo que puede llevar a confusión, pero solo el primer "goto fail" está ligado al if. El segundo "goto fail" se ejecuta siempre, ocurra lo que ocurra con los if anteriores. Lo que quiere decir, que hay una parte del código a la que nunca se llega, y en la que se realiza una verificación importante relativa al intercambio de claves en el protocolo SSL. En otras palabras, si la operación SLHashSHA1.update es válida y "err" toma un valor válido, la verificación de la clave nunca dará error, aunque el resto de valores no se hayan comprobado. Para entender el fallo, nos ponemos un poco en situación con el protocolo SSL

El protocolo SSL

En TLS/SSL se puede utilizar Diffie/Hellman (DH) como protocolo de intercambio seguro de claves en un canal inseguro. Así, se negocia una clave DH efímera (se descarta después de cada uso) que permite el cifrado simétrico de la comunicación entre navegador y servidor. Pero TLS/SSL no solo permite cifrado sino que también autenticación. Para eso se utiliza el protocolo RSA y por supuesto los certificados. Estos se encargan de firmar la comunicación, es decir, garantizar que vienen del servidor correcto.

El fallo se produce en el momento de enviar el mensaje ServerKeyExchange. En este momento es cuando el servidor le ofrece al navegador o cliente esa clave efímera, y la firma con su clave privada que, avalada por su certificado, no dejan lugar a dudas de que proviene de quien dice provenir. Pero, debido al error, esto no tiene por qué ser así. Se le puede comunicar una clave efímera, pero no firmarla, o firmarla con un certificado incorrecto. El navegador o cliente nunca se quejaría. En otras palabras, podrías conectarte a una página por https que no fuera la que dice ser, pero ningún aviso en el navegador te diría lo contrario. Limpiamente un atacante podría obtener toda la información de la comunicación.

Eso sí, obviamente la red en la que se navega tendría que estar ya en cierta manera manipulada por el atacante, puesto que la víctima tendría que ser redirigida a nivel de dominio. Quizás, es una de las razones por las que Apple ha priorizado la solución para iOS. También por lo que se ha lanzado la teoría de la conspiración que siempre surge cuando se habla de la capacidad de descifrar las comunicaciones cifradas. Los gobiernos podrían tener la capacidad de desviar a los usuarios a servidores diferentes, puesto que podrían controlar los DNS de red. De hecho, algunos lo hacen.

¿Hay algo que mitigue el problema?

¿Y el certificate pinning? Ante este fallo, no serviría. El atacante podría enviar la cadena de certificados válidos, pero aun así una firma de la clave efímera perteneciente a otro, y el cliente SSL no se quejaría. ¿Y si no se usa DH para el intercambio de claves? No importaría, porque en SSL el servidor suele poder negociar qué suite de cifrado se quiere usar. Solo podrían librarse los navegadores o clientes que fuercen TLS 1.2 y no degraden a uno anterior aunque el servidor se lo solicite. Pocos navegadores lo hacen porque limitaría su capacidad de conexión con servidores que no lo soportan.

¿Lecciones aprendidas?

El bug dará para muchas discusiones, análisis (y mofas) durante mucho tiempo. Pocas veces se observa un fallo tan importante y simple. Quizás remite al fallo criptográfico de Debian ocurrido en 2008 explicado en detalle en esta conferencia de Luciano Bello. En primer lugar, sorprende (bueno, quizás no tanto) que un fallo tan absurdo haya ocurrido en código abierto. ¿Cuánto tiempo estuvo ahí? El código desvela también malas prácticas en el estilo de programación (deberían haberse utilizado llaves para contener el if, evitar los gotos...). La indentación, que aunque se considera una buena práctica, ha jugado una mala pasada. Incluso desvela malas prácticas de compilación. Existen técnicas y comandos a la hora de compilar que permiten lanzar una alerta en tiempo de compilación cuando si se detecta código al que nunca se puede llegar. Desde luego, Apple ha cometido un error gravísimo y ha puesto no solo en peligro a sus usuarios, sino que ha dejado en entredicho la calidad de sus pruebas de software.

¿Soy vulnerable?

Si se usa Mac OS X Mavericks, probablemente sí. Si usas iOS, se debe actualizar. El fallo fue introducido en la versión 6.0 de iOS, aparecido a mediados de 2012. El nivel de paranoia aumenta cuando se rumorea que Apple se adhirió a PRISM en octubre de ese año. En escritorio, se encuentra en Mavericks, pero no en anteriores. Ya existen páginas para comprobar si se es vulnerable. Aquí, y aquí.


Fuente: https://twitter.com/0xabad1dea/status/437291365508976640

Por último, advertir de que el fallo no solo afecta al navegador. El problema está en librerías a bajo nivel a las que acuden todo tipo de clientes, y por tanto la vulnerabilidad va mucho más allá. Por ejemplo, pensemos en el proceso de actualización de software, el uso de correo, mensajería, etc. Cualquier cosa que utilice SSL para cifrar su tráfico y no necesariamente nativa del sistema operativo, sino que simplemente utilice sus librerías. 

Sergio de los Santos
ssantos@11paths.com

El negocio de las "FakeApps" y el malware en Google Play (I): Introducción

viernes, 21 de febrero de 2014

El malware en Android es un problema. Quizás aún no llegue a los términos y cifras que barajan las casas antivirus y las empresas que venden soluciones, pero desde luego, tampoco se trata de una mera exageración como nos intentaba explicar la propia Google. La realidad suele acercarse al término medio. En cualquier caso, la fuerte asociación que se está creando entre Android y el malware, azuzada por los medios, además de la percepción que está calando entre los usuarios, constituyen ya un hecho del que le costará mucho deshacerse. 

Cisco Annual Security Report. 2013. Fuente: https://www.cisco.com/web/offer/gist_ty2_asset/Cisco_2014_ASR.pdf

Entre tanto, el asunto del malware en Android se manifiesta en muchas formas y dispone de diferentes frentes desde los que analizar el problema. Cuando se habla de "malware para Android" se debería ser mucho más específico. ¿De qué tipo? ¿De dónde viene? ¿Cómo me infecto? ¿Qué probabilidades existen? ¿Qué consecuencias tiene? ¿Cómo me protejo? ¿Cómo me defiende el sistema operativo? ¿Quién está detrás de todo esto? ¿Es realmente preocupante? Solo respondiendo a este tipo de cuestiones se podría conocer si realmente afrontamos un problema de seguridad como otro cualquiera o nos encontramos ante una grave epidemia contra la que deberíamos estar prevenidos.

En esta serie de entradas no se van a responder (al menos con la minuciosidad que requerirían cada una) a todas esas preguntas. Nos centraremos en un método de difusión concreto, y en una forma de malware definida. Sin embargo, podrá ofrecernos una idea de cómo se difunde una buena parte del malware para Android (que redunda en la sensación de (in)seguridad que mantienen los usuarios), y cómo funcionan ciertos atacantes y la propia Google Play a la hora de "defender" su market. Se intentará realizar aproximación realista y, esperamos, interesante.

Google Play y el malware

Google Play es la tienda "oficial" de aplicaciones de Android. Existen otras, de las que Google "no se responsabiliza" y, por tanto, pueden contener cualquier tipo de programa o aplicación. En principio, hay markets más serios y otros menos "profesionales". Pero nos centraremos en el oficial, Google Play, donde también se aloja malware o al menos, mucho adware. Una de cada diez aplicaciones en Google Play es maliciosa, afirmó Trend-Micro. Para valorar las "aplicaciones maliciosas" de esta forma entran en juego muchas variables, por lo que probablemente esas cifras sean discutibles. Con el objetivo de precisar el análisis, en este estudio vamos a centrarnos en las aplicaciones falsas, en cómo suelen funcionar los atacantes, en cómo suele reaccionar Google Play, sus técnicas y, a veces, saber quién está detrás de todo esto.

Cisco Annual Security Report. 2013. El envío de SMS premium sin consentimiento es el problema más habitual.
Fuente: https://www.cisco.com/web/offer/gist_ty2_asset/Cisco_2014_ASR.pdf
¿En realidad hay tanto malware en Google Play? 

En marzo de 2013 Trend Micro analizó dos millones de aplicaciones (Believe the hype, lo titularon). Casi medio millón se calificaron como "maliciosas". Así que algunos dedujeron que una de cada cuatro apps de Android era malware. De ese medio millón, casi 70.000 venían de Google Play. Como Goolgle Play alojaba en ese momento 700.000 apps, dedujeron a su vez que una de cada 10 apps de Google Play era malware. Todos estos datos venían como consecuencia de la detección del producto comercial de Trend Micro. Esas cuentas no eran precisas, se mirase por donde se mirase. Así el "estudio" nos dejaba con más preguntas que certezas sobre de dónde venían esas dos millones de aplicaciones y qué se consideraba malware exactamente.

En contraste, a finales de septiembre de 2013, Adrian Ludwig (jefe de seguridad de Android), dio una charla en la Virus Bulletin de Berlín destinada a quitar hierro al asunto del malware en Android . Con datos sobre la mesa, desmontó el supuesto "mito" de que Android se infecta mucho con malware. Alabó la defensa en profundidad que implementa su sistema operativo. Ludwig sostuvo que los investigadores son buenos a la hora de encontrar el malware, pero que no tienen datos fiables que indiquen la frecuencia con la que una aplicación ha sido instalada. y según Google, son muy pocas las veces que esto ocurre. Pretendía presentar un gran abismo entre lo que es la existencia de malware, y cuántos dispositivos están realmente infectados. Ese discurso era, cuando menos, discutible.

Otros estudios sobre infección, que detectan actividad sospechosa en la red generada por un terminal (y permiten detectar otro tipo de malware, aunque sigue sin ser un método perfecto), concluyen que el nivel de infección es de más del 1% de los dispositivos, o en números absolutos, más de 11 millones de dispositivos infectados.

Lo que pensamos que es más seguro, es de que la vía de infección más usada actualmente es la simple instalación por parte del usuario de aplicaciones fraudulentas. La infección por vulnerabilidades, aunque posible, todavía no es mayoritaria.. Recientemente Metasploit añadió un módulo para aprovechar una vulnerabilidad en Android de forma muy sencilla. El exploit, permite obtener el control del sistema con tan solo visitar una página web manipulada especialmente. Aprovecha una vulnerabilidad que afecta a las versiones anteriores a la 4.2 (Jelly Bean) y que publicada a finales de octubre de 2012. Aun así, con esta ventana de exposición tan "apetitosa"  para los atacantes, no se observa que este sea su método preferido de infección, como lo es en los sistemas de escritorio.

También es cierto que Google Play es el market más utilizado y "reputado" por ser el oficial. De él esperaríamos ciertas garantías a la hora de instalar aplicaciones y no infectar el dispositivo. Pero su modelo de negocio contiene errores de diseño que permiten que se ofrezca malware para descarga, algo que en otros markets o stores es poco habitual, anecdótico, o aún no ha ocurrido. Pero, ¿cuánto malware o adware y cómo se distribuye en Google Play? Daremos algunas pistas en las siguientes entregas.


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

MITM en GSM: ataque con falsa estación base (y II)

miércoles, 19 de febrero de 2014

Puesto que la telefonía móvil 4G es ya una realidad, pudiera parecer que la tecnología GSM (2G) ha quedado relegada a un segundo plano. Pero no es así. Millones de suscriptores en el mundo siguen haciendo uso de esta tecnología cada día y la práctica totalidad de los terminales móviles 3G son compatibles con GSM. GSM es muy débil en cuestión de seguridad. ¿Cómo funcionaría un ataque con estación base falsa?

Suplantando una BTS de un operador legítimo

Un atacante necesita, para comenzar, información sobre su objetivo. En especial si se pretende realizar un ataque dirigido. En un escenario ideal para el atacante, debe poder identificar a la víctima con su operador de red y su IMSI. Este último parámetro se almacena en la SIM del usuario y en el registro de ubicación base (HLR) de la red, que es una base de datos que almacena información estática sobre los usuarios.

Existen varias formas de obtener el IMSI de un suscriptor:
  • Algunos servicios web ofrecen la posibilidad de consultar directamente los HLR de las operadoras, y en algunos casos obtener el IMSI de un determinado número. 
  • Otro método consiste en que sea el propio atacante el que utilice la BTS como IMSI-Catcher. Para conseguirlo, se debe acercar a la ubicación física del objetivo, y cuando las MS intenten registrarse contra la BTS falsa, indicarles que no es posible resolver su TMSI. Como el  protocolo contempla que si esto ocurre, el teléfono envíe el IMSI, lo hará. El atacante puede rechazar el registro pero también almacenar el IMSI para así confeccionar una lista. Puesto que lo habitual es que se tengan muchas peticiones de otros usuarios que no sean la víctima concreta, deberá realizar esto mismo en diferente localizaciones donde sepa que se encuentra el objetivo... cruzar las listas y determinar el IMSI común.
El atacante también debe obtener información que le permita caracterizar su estación base con parámetros reales de estaciones base legítimas. De esta forma, a ojos del móvil, su BTS será más creíble, y aumentarán las posibilidades de realizar el ataque con éxito. Para esto se suele monitorizar el espectro radioeléctrico, en busca de señales de beacon provenientes de BTS legítimas.

Monitorización de los canales de señalización GSM con GNURadio, Airprobe y Wireshark. Fuente: rtl-sdr.com
Para su configuración, los parámetros más importantes que se deben determinar mediante el análisis de estas señales son:
  • La frecuencia a la que debe emitir la estación base falsa. Resulta un factor clave, porque se debe evitar interferir con un canal de la estación base de la célula en la que se encuentra el atacante y que, de esta forma, la presencia de la base pase inadvertida. Lo habitual es utilizar frecuencias de estaciones base de celdas adyacentes, lo que añadirá veracidad al ataque.
  • La potencia de emisión es también otro factor determinante, puesto que a mayor potencia, mejor recepción de la señal del atacante en el dispositivo del usuario y por tanto más fácil será que se conecte a la BTS.
Una vez configurada, se procede a emitir. Lo habitual es utilziar un inhibidor de frecuencia para saturar el espectro radioeléctrico en las frecuencias de la celda en la que se encuentran atacante y víctima, y de esta manera forzar al dispositivo de la víctima a registrarse en la BTS falsa. Otra manera es situarse lo suficientemente cerca para que la señal que reciba con más fuerza sea la falsa. De esta forma el móvil creerá que ha cambiado de celda y, si la BTS está correctamente caracterizada con la información que se ha obtenido anteriormente, se conectará.

Cuando la víctima intente conectarse se debe aceptar el registro automáticamente, pudiendo incluso obviar el proceso de autenticación. Como ya mencionamos, la MS no tiene capacidad para decidir qué tipo de cifrado emplear en las comunicaciones sino que utiliza el que le imponga la red. Basta con pedirle que utilice A5/0 y las comunicaciones irán en texto plano. Para la víctima, todo este proceso es transparente.

Estructura del ataque. Fuente: criptored.upm.es
A partir de este momento el usuario está aislado de la red del operador en el sentido de que no podrá recibir comunicaciones entrantes. Si alguien intenta contactar con él, aparecerá como fuera de cobertura. Sin embargo, gracias a Asterisk el atacante podría redirigir llamadas salientes hacia la red.

El atacante está en medio ¿y ahora qué?

Una vez el atacante dispone del control de las comunicaciones del usuario, es posible hacer "de todo": escuchas, denegación de servicio, redirección de llamadas…

Veamos un caso práctico, entre muchos otros posibles. Supongamos que el atacante quiere robar los datos bancarios de la víctima. Podría empezar por mandarle un SMS haciendo coincidir el número de origen con el de su entidad bancaria. Esto es tremendamente sencillo porque el servicio SMS no implementa comprobación del número de origen (de hecho, para este paso no hace falta ninguna infraestructura específica puesto que ya hay servicios web gratuitos que permiten esta funcionalidad). En el SMS se comunica a la víctima que, debido a una actualización de la base de datos, es necesario que contacte con su banco para proporcionar unos datos.

Es posible que el usuario llame a la centralita de su entidad bancaria, pero la BTS falsa redirigirá la llamada a un teléfono controlado por el atacante. Como es la propia víctima quien realiza la llamada, es improbable que sospeche. El atacante, haciéndose pasar por un empleado del banco, podría solicitar su número de cuenta y clave de acceso.

En general, GSM es una tecnología muy vulnerable. Todos sus elementos de seguridad están obsoletos y su arquitectura presenta importantes brechas de seguridad. Su uso es desaconsejable aunque sigue estando muy extendido. Quizás con la expansión de las redes 4G su popularidad vaya decayendo paulatinamente, pero es probable sea necesario mucho tiempo hasta que se convierta en marginal, puesto que, a su favor, tiene los poderosos motivos de compatibilidad.

MITM en GSM: ataque con falsa estación base (I)

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

Careto (The Mask), la ciber-arma (posiblemente) española tenía "fecha de caducidad" (y otras curiosidades)

lunes, 17 de febrero de 2014

Kaspersky lo ha vuelto a hacer (suele ser el laboratorio que detecta e investiga la mayoría de amenazas sofisticadas). Ha desvelado la existencia de un malware interesante. Aunque ya estamos acostumbrados a este tipo de "ciber-armas" (se usa el sufijo "ciber" para darle un aire de sofisticación al malware que ha pasado desapercibido demasiado tiempo), Careto contiene (más allá de ciertas anécdota) características muy interesantes. ¿Algo que no se haya dicho aún? Vamos a intentarlo.

Por qué fue detectado

Careto intentaba utilizar un fallo en versiones no recientes de Kaspersky, por las que (tras enviar un comando especial al driver del antivirus) no se detectan ya los procesos con nombre "services.exe". Esto es lo que llamó la atención de la casa antivirus afectada cuando ninguna detectaba uno de sus componentes. Sin embargo, resulta una técnica un poco inútil por parte del atacante, puesto que para llegar a este punto y manipular el antivirus, otros componentes de la infección ya han tenido que someterse a análisis y podían haber sido detectados. Además, después de intentar este truco, ni siquiera usaban ni renombraban ningún proceso de esa manera. Por último, este fallo está arreglado en 2008, y no es nada habitual en malware intentar explotarlo, por lo que encendió todas las alarmas en Kaspersky. Un intento ingenioso de pasar desapercibido, que precisamente les ha valido la detección.

Cómo se expandía

A través de correos específicos, que intentaban que la víctima visitase una web. Una vez visitada, se redirigía a una página que contenía los exploits. Se intentaban aprovechar diferentes vulnerabilidades en el navegador y sus componentes (cómo no, Java principalmente), intentando ejecutar código de forma transparente. Hasta aquí, como cualquier otro. Luego la víctima era redirigida a páginas falsas de periódicos en subdominios tipo elpais.linkconf.net, www.publico.linkconf.net, y subdominos de tercer nivel con nombres de secciones de los periódicos.

Los detalles de la vulnerabilidad no son públicos
Fuente: http://www.securityfocus.com/archive/1/522413
Lo realmente interesante es que usaban un exploit especial: CVE-2012-0773. Una ejecución en código en Flash. Fue el primer exploit conocido capaz de eludir la sandbox de Chrome. Lo hizo VUPEN para ganar el concurso “pwn2own” hace dos años. Pero los ganadores no dieron detalles del exploit. VUPEN es una "controvertida" empresa que vive de crear exploit y venderlos a gobiernos para el espionaje.

A quién ha afectado

Kaspersky ha "secuestrado" servidores de los atacantes, y así han comprobado cuántas víctimas se han intentado conectar a ellos. Así han concluido que la mayoría provienen de Marruecos, Brasil y Reino Unido, aunque España es una constante en varios de los servidores. 1000 víctimas en 31 países (aunque obviamente habrá y ha habido más). Se comprueba a través de las IP que principalmente se interesaban por instituciones gubernamentales y diplomáticas. Almacenaban los datos de las víctimas en un directorio llamado "ClientsDirectory".

¿Un malware con fecha de caducidad?

Firma sin contrafirma... no se ven los detalles del certificado
Como el buen malware sofisticado, muchos ficheros que componían el malware estaban firmados criptográficamente. En este caso, por TecSytem Ltd (supuestamente de Sofia, Bulgaria). Lo curioso es que no se tiene la certeza de si es una compañía legítima o no, aunque el certificado sea válido y firmado por Verisign. Se han observado dos certificados en el malware; uno válido de desde el 28 de junio de 2011 al 28 de junio de 2013. Otro válido desde el 18 de abril de 2013 al 18 de julio de 2016. Curiosamente, la firma de los ficheros, según se deduce de la imagen de Kaspersky, no se encuentran contrafirmada (no tiene timestamping). Para las muestras no contrafirmadas, significaría dos cosas:

  • No sabemos exactamente cuándo fueron firmados esos binarios.
  • Condena a la firma criptográfica a no ser válida después de la fecha de caducidad del certificado, y por tanto, a que el archivo firmado sea rechazado después de ese día. La contrafirma sirve para precisamente, dar por válido un binario firmado aunque el certificado esté caducado puesto que la contrafirma certifica que se firmó durante el periodo válido del certificado.

Quedará más claro en un ejemplo. El segundo certificado de Careto va desde 18 de abril de 2013 al 18 de julio de 2016. Si se firma un fichero en 2014, pero no se contrafirma, cuando Windows ejecute ese binario el 19 julio de 2016 o cualquier fecha posterior, comprobará la firma y la rechazará por estar fuera del periodo de validez. Si se hubiera contrafirmado, nadie se quejaría, aunque el certificado ya habrá dejado de ser válido (y no se podrá hacer ya nada con él). Esto es lo más habitual para que los programas siembre sean válidos independientemente de que caduque un certificado ¿Por qué no contrafirmar? La contrafirma la valida una empresa externa (VeriSign, por ejemplo), habitualmente, a la que se le envía un hash del fichero y esta devuelve una estructura PKCS#9 que atestigua "esta cadena de bits que representa al binario existía al menos en esta fecha, porque me la enviaron. y así lo firmo yo". Si está dentro del periodo de validez del certificado, siempre se dará por válido el fichero. Quizás querían pasar más desapercibidos aún sin enviar el hash a nadie. En cualquier caso, no disponemos más detalles sobre esta teoría.

¿Desde 2007?

Se ha dicho que este malware ha pasado inadvertido unos siete años. Para estas estimaciones, se suele acudir a la fecha de compilación de los ficheros binarios en sus cabeceras. Esto no es muy fiable, y puede ser modificado. De hecho, suele ser modificado por los atacantes. Así, han encontrado un componente de 2007, aunque la mayoría tiene fecha de compilación de 2012. Uno de los dominios utilizados en los ataques, también fue comprado en 2007.

Componentes de puerta trasera

Todo el malware actual necesita ser controlado en remoto, y para ello se vale de una puerta trasera. La de Careto es especialmente sofisticada, puesto que funciona en Windows de 32 y 64 bits y Mac OS X. Aunque se está diciendo que posiblemente existan versiones para iPad e iPhone, nadie ha visto ninguna muestra concreta. Solo se han visto user-agents de iPads e iPhones en la lista de infectados, pero ya en el C&C como texto... lo que es un indicio, pero ninguna prueba. Puede que una presunta víctima visitara algún C&C sin estar infectado, o que tuviera el user-agent modificado.

Qué podía hacer

De todo. Aquí es bastante sofisticado. Entre "lo típico" está robar las pulsaciones de teclado, tráfico SSL, capturas de pantalla... pero también robaba todo tipo de información criptográfica: VPN, claves PGP, claves SSH, fichero s RDP (para conexiones de escritorio remoto), conversaciones de Skype... y se hacía con una larga lista de ficheros según su extensión.

Cómo estaba estructurado

Algunos de los módulos de SGH, muy extensible
En primer lugar, el componente "Careto", que representaba a los componentes a nivel de usuario. Recibía información (y ejecutaba lo que le indicaba) del C&C, también robaba los ficheros. El otro componente llamado SGH, es el rootkit que operaba a bajo nivel, más sofisticado. Operaban normalmente juntos.

Por último, y basándose en "Shadowinteger's Backdoor" (sbd), que a su vez se basa en el código libre de un clon netcat, implementa otra puerta trasera. Este backdoor estaba preparado para Windows, Mac y Linux. Para instalarse en Linux y Mac OS X, se usaban extensiones de Firefox llamadas af_l_addon.xpi. El SGH es lo que resulta más sofisticado. Sirve como sistema de espionaje completo y además es muy extensible. Por ejemplo, utiliza sistemas de fichero virtuales cifrados para operar, donde guarda logs y extensiones. Se encontraba autocifrado en RC4 con la conocida contraseña "Caguen1aMar".

Cómo se escondía

Una de las técnicas es muy interesante. El malware conseguía registrarse como un módulo COM (ECD4FC4D-521C-11D0-B792-00A0C90312E1, relacionado con el Explorer de Windows), suplantándolo. Todo proceso que pidiera este componente, quedaba "infectado" con el malware inyectando una DLL. Desde ahí, conseguía hacerse pasar a su vez por una DLL conocida, elegida entre un conjunto de nombres legítimos.

Esto significa que a efectos prácticos, a un investigador que observara las DLL cargadas por un proceso le aparecían nombres de DLL y rutas "habituales" del sistema. Pero lo que ocurría es que el malware había conseguido reemplazar en memoria alguna de ellas. Esto es muy novedoso, porque normalmente el malware común se carga como DLL en un proceso, pero sin cuidar su nombre o ruta.

Este componente del malware, hookeaba entonces el creador de procesos y se enganchaba al navegador, actuando ligeramente distinto si se lanzaba iexplore.exe, firefox.exe, opera.exe, netscape o chrome.exe, pero infectándolos a todos. También se enganchaba a nombres como emule.exe.

Otras características y curiosidades


Los nombres de los módulos hacen referencia a "chef" (que implementa la conectividad), "waiter", (camarero) y "dinner" (cena). Los atacantes se ocupaban de cerrar los manejadores en memoria y programar de forma cuidadosa, algo poco usual, pero da una idea de lo estable que querían las máquinas los atacantes. También de que sus servidores pasaran desapercibidos, usando ficheros .htaccess para ahuyentar a ciertas compañías de seguridad e incluso para defenderse de un problema de DoS en Apache que descubrió Kingcope en 2011.


Como anécdota, el uso de ciertas expresiones "muy españolas" ha sido lo más comentado en redes sociales
Indicios muy curiosos sobre la procedencia española del malware.
.De las más sofisticadas

A pesar del uso de estas contraseñas (que podría dar la idea de una programación castiza, casera o descuidada dentro de un ambiente desenfadado) y de la poca profesionalidad que se desprende del uso de un inglés pobre, nos quedamos con esta importante frase en las conclusiones del informe de Kaspersky "In terms of sophisticated, we put Careto above Duqu, Gauss, RedOctober or Icefog, making it one of the most complex APT we observed. For Careto, we observed a very high degree of professionalism in the operational procedures of the group behind this attack, including monitoring of their infrastructure, shutdown of the operation, avoiding curious eyes through access rules, using wiping instead of deletion for log files and so on."


Sergio de los Santos
ssantos@11paths.com

Cómo obtener un modelo de visión global de amenazas (con FaasT)

viernes, 14 de febrero de 2014

En Eleven Paths, seguimos trabajando para hacer que el sistema de pentesting persistente FaasT no solo sea capaz de detectar vulnerabilidades en tiempo real y además de informar al cliente para que  pueda acometer las medidas de corrección adecuadas, sino que vaya mucho más allá. Nos gusta pensar en FaasT como una herramienta de visión global y continua, porque en su fase de "descubrimiento" utiliza ciertos recursos que aumentan con el paso del tiempo para lograr tener un mapa de activos lo más complejo y rico posible.

La riqueza de la fase de descubrimiento es una de las bases del éxito en el proceso de inventariado en el pentesting. Y en FaasT se intenta cuidar mucho este aspecto. Hemos explorado muchas alternativas y vías que nos permitan asegurar un mapa de activos con el que poder lanzar de la forma más efectiva las diferentes pruebas en fases posteriores. Porque aunque todo proceso comience con la fase de descubrimiento, es necesario recordar que ciertas pruebas en fase de análisis y explotación pueden reportar elementos que a su vez disparen de nuevo la fase de descubrimiento. Por ejemplo, la aparición de un nuevo dominio gracias a la detección y explotación de una vulnerabilidad. Este dominio llevaría asociado todo el camino en el árbol de acciones del pentesting.

Llevamos meses de análisis, diseño, implementación y pruebas. Durante todo este tiempo hemos orientado la herramienta hacia algo que va mucho más allá de lo que tradicionalmente se entiende como herramienta de pentesting basado en web. Hemos observado cómo FaasT ha madurando hacia un sistema mucho más complejo que permite una visión global y continua de la seguridad de una compañía de una forma mucho más amplia. FaasT evalúa muchos otros factores de forma inteligente y permite obtener un mapa de activos en Internet (todo lo que una empresa puede estar ofreciendo públicamente). Esto permite adoptar las medidas recomendadas de forma ordenada y constante.

A modo de ejemplo, vamos a ver brevemente algunos de los aspectos que cubre FaasT, otros se han hablado ya en este blog, y cómo se mostrarían a un cliente de FaasT en pantalla.
La consola FaasT mostrando metadatos en ficheros PDF en servidores web
  • Usuarios y correos: La recolección de usuarios y correos (localizables desde Internet) de una organización ya sea por detección y explotación de vulnerabilidad o análisis exhaustivo de activos, puede ser un punto de inflexión que desemboque en nuevas amenazas (desde ataques dirigidos hasta las técnicas más básicas de fuerza bruta). 
Esta es una muestra de los datos recopilados en forma de árbol
  •  Software: Conocer las versiones de software que están en uso o se han utilizado en una empresa otorga un conocimiento muy valioso al pentester. Permite buscar un fallo explotable en la actualidad, o en función de la familia de productos y del fabricante, en un futuro a corto plazo. Para conseguirlo se realiza una recopilación por distintas vías de todo el software posible que es utilizado alrededor de la organización. 
Versiones de software encontradas en escaneo
  •  Comprobación continua de errores: En algunas ocasiones vulnerabilidades o despistes en la configuración  típicos, conocidos desde hace muchos años, vuelven a aparecer en el entorno empresarial debido a que los administradores y proveedores de software relajan la política o vuelven a versiones desactualizadas por compatibilidad. Como curiosidad, en este período de tiempo hemos comprobado que ciertos dominios se encontraban con, por ejemplo, las famosas transferencias de zona de los servidores DNS durante ciertos periodos de tiempo. Con esta vulnerabilidad la capacidad de ataque y conocimiento sobre dominios y máquinas de la infraestructura crece en su explotación. FaasT la detecta rápidamente, y permite alertar de sus consecuencias, ofreciendo información relevante sobre sus potenciales peligros y cómo solucionarlo.
Error típico de transferencia de zona en servidores DNS, cómo lo muestra FaasT
  • ¿Qué hemos obtenido con cada fallo? Una de las características de FaasT es su capacidad para indicar al usuario claramente "¿Qué se ha obtenido de esta vulnerabilidad?". Gracias a esta información, el usuario puede entender mejor en qué perjudica un fallo o vulnerabilidad concreta a la organización,  y en qué ayuda al pentester la explotación de la vulnerabilidad. Cómo le permite avanzar en la investigación continua y desarrollar  una auditoría mucho más compleja.
Clasificación de los resultados y datos obtenidos en cada vulnerabilidad
Estos son solo algunos ejemplos que nos parecen interesantes, y que creemos que hacen de FaasT una herramienta muy diferente (mucho más rica, compleja y completa) que un "simple" sistema de búsqueda de vulnerabilidades online.

Pablo González
pablo.gonzalez@11paths.com

MITM en GSM: ataque con falsa estación base (I)

miércoles, 12 de febrero de 2014

Puesto que la telefonía móvil 4G es ya una realidad, pudiera parecer que la tecnología GSM (2G) ha quedado relegada a un segundo plano. Pero no es así. Millones de suscriptores en el mundo siguen haciendo uso GSM cada día y la práctica totalidad de los terminales móviles 3G son compatibles con 2G. GSM es muy débil en cuestión de seguridad. ¿Cómo funcionaría un ataque con estación base falsa?

Se puede suponer que una tecnología con semejante número de usuarios dispone de mecanismos que aseguran la seguridad de nuestras comunicaciones. Pero existe (y es más fácil de lo que parece) la posibilidad de que conversaciones o mensajes SMS acaben en manos de un tercero.

Mapa mundial de frecuencias GSM. En azul, GSM 850/1900. En verde, GSM 900/1800. En rojo, sin cobertura GSM. Fuente: hardcorpstravel.com
Realizar un ataque de hombre en el medio (MITM) en GSM es relativamente sencillo siempre y cuando se cuente con ciertos conocimientos técnicos concretos y presupuesto suficiente. A continuación veremos por qué se puede hacer, cómo se puede hacer y qué se podría conseguir.

Para entender cómo funciona un ataque de estación base falsa es necesario familiarizarse con unas nociones básicas de la arquitectura GSM.

Estructura jerárquica en GSM
En GSM existen dos subsistemas bien diferenciados: por un lado tenemos el Network and Switching Subsystem (NSS), que representa el núcleo de la red y se encarga de realizar tareas de conmutación (MSC), gestión de movilidad y autenticación de usuarios (HLR y VLR, registros de ubicación local y visitante). Por otra parte está el Base Station Subsystem (BSS), que implementa el interfaz radioeléctrico GSM para la comunicación con los dispositivos de usuario (MS). Consta de dos elementos:
  • Controlador de estaciones base (BSC): es el elemento de control que gestiona los recursos de una o varias estaciones base. Asigna frecuencias y regula potencias de emisión, además de controlar procedimientos internos como el paso de llamada.
  • Estación base (BTS): es el dispositivo que da cobertura a las MS. Consta de una serie de antenas de emisión y transmisión, así como de moduladores y demás electrónica de comunicaciones. Cada BTS proporciona cobertura en un área determinada denominada célula o celda. Las estaciones base anuncian su presencia mediante el canal de beacon, de manera que las MS puedan localizarlas y registrarse en ellas. 
¿Qué hace a GSM vulnerable?


El estándar GSM presenta desde su concepción ciertos puntos débiles que le hacen especialmente vulnerable. Uno de ellos afecta al IMSI (identificador de suscriptor). El IMSI es una información considerada altamente confidencial, porque a partir de ella se puede inferir la localización geográfica de un usuario. El IMSI es un valor único que podría llegar a identificar a un usuario. Si quedara registrado en las torres en las que se suscribe el usuario, se podría literalmente "espiar" por dónde se mueve. Para solucionar este problema de privacidad, la norma establece que por defecto el IMSI no debe ser enviado por el interfaz radioeléctrico, y que en su lugar ha de utilizarse el TMSI (identificador temporal de suscriptor) al realizar actualizaciones de posición (registros en nuevos VLR). Aun así es posible recuperar el IMSI. Un VLR guarda una tabla de correspondencias IMSI-TMSI, pero si por algún motivo es incapaz de resolver un TMSI determinado, la red puede solicitar a la MS el envío de su IMSI en claro.

Por otra parte, atendiendo a la confidencialidad de las comunicaciones, el estándar establece el A5/1 como algoritmo de cifrado por defecto. Pero también obliga a que todos los terminales GSM soporten A5/0 (transmisión sin cifrar). Además, la MS no tiene capacidad para decidir el método de cifrado, teniendo que aceptar el que le imponga la red.

Sin embargo, el verdadero talón de Aquiles que encontramos en GSM es su protocolo de autenticación. A diferencia de las redes UMTS, donde ya vimos que la autenticación se realizaba en los dos sentidos, el estándar GSM sólo autentica al usuario frente a la red, mientras que la identidad de la red no se verifica. Esta carencia hace que sea relativamente fácil para un atacante suplantar a una estación base legítima y de esta manera interceptar y alterar las comunicaciones.

Pero si se pretende suplantar una estación base, cabe plantearse por qué una MS (que ya está recibiendo servicio de una estación base legítima) se conectaría a la de un atacante. Existen varios eventos que pueden desencadenar un proceso de reselección de celda, y todos ellos pueden ser forzados por el atacante. Por ejemplo, con un inhibidor de frecuencias es posible provocar una pérdida de cobertura.

Dos tipos de ataque

Antes de profundizar en los pasos del ataque, debe quedar claro que existen dos tipos, en función de cómo se comporta el atacante respecto a la red.
  • Por un lado está el ataque completo, en el que no solo se suplanta a la estación base sino que además se suplanta al usuario frente a la red. De esta manera la comunicación es totalmente bidireccional y el abanico de posibilidades de que disponemos se multiplica. El problema es que este tipo de ataque es muy complejo (sobre todo a la hora de sincronizar la señalización entre BTS, suplantador y víctima), y desde luego las herramientas necesarias no son tan fáciles de conseguir, 
  • Un ataque parcial, en el que solo se suplanta la estación base. En él, se restringe la comunicación un único sentido. En otras palabras, el usuario podrá realizar llamadas, pero no recibirlas. En esta entrada nos centraremos en este, mucho más sencillo.
¿Qué se necesita para suplantar a una estación base?

Para acometer un ataque de esta naturaleza, el atacante (dando por sentado que posee conocimientos de informática y telecomunicaciones lo suficientemente extensos) necesita un conjunto de elementos hardware y software muy específicos (en este libro, se entra en detalle sobre el funcionamiento y conocimiento necesarios)

USRP N120. Fuente: Ettus.com
Respecto a la parte hardware, el elemento principal es un dispositivo capaz de emitir en la banda de frecuencias de GSM (900 MHz y 1800 MHz en Europa), como por ejemplo alguno de la familia USRP de Ettus Research. El precio de estos aparatos oscila entre los mil y los tres mil euros (véase como ejemplo el N210). Además, son necesarias al menos dos antenas direccionales para la transmisión y recepción de datos, así como un modulador-demodulador de GMSK, que es la modulación empleada en GSM.

En general, el hardware del atacante tendrá una potencia de transmisión y una capacidad de gestión muy inferior a las de una estación base real, lo que obligará a situarse en una zona próxima al objetivo.


Con respecto al software, existe una gran variedad de herramientas de libre distribución que desempeña las funcionalidades de una estación base de GSM. Por un lado disponemos de OpenBTS (Open Base Transceiver Station), que hace las veces de punto de acceso software de GSM, implementando toda su pila de protocolos asociada. Y por otro lado tenemos Asterisk, que permite desarrollar las funciones de una central de conmutación. Por último, también será necesaria alguna herramienta que permita capturar el tráfico, como por ejemplo Airprobe.

Con los elementos anteriores u otros equivalentes, es posible iniciar el ataque.

MITM en GSM: ataque con falsa estación base (y II)

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


Nueva herramienta: GmtCheck. ¿De dónde viene esta app de Android o applet?

lunes, 10 de febrero de 2014


Existen millones de applets maliciosos (ficheros JAR) y apps de Android (ficheros APK) ahí fuera. ¿De dónde vienen? ¿De qué país? ¿Al menos, cuál es su zona horaria? En un estudio forense, puede ser relevante conocer (o al menos establecer indicios) si provienen de Rusia, Brasil, China, la India o Estados Unidos. Veamos cómo.

Los ficheros dentro de los ZIP

Los APK (apps de Android) y los applets (y programas Java) vienen todos del mismo formato: son un fichero ZIP. Esto quiere decir que comparten buena parte de las especificaciones PKzip. A la hora de crear un fichero ZIP, el atributo "fecha" de modificación de cada fichero se almacena dentro del ZIP. Se puede comprobar simplemente abriendo un fichero con cualquier herramienta.
 
La forma en la que se almacena este dato es curiosa, y hablaremos de ella en alguna otra entrada. La parte interesante es que el atributo "fecha y hora de modificación" con el que se almacenan es el mismo que el del sistema en el que se han compilado. También, que hay ficheros que se crean justo cuando se compila el programa, como el manifiesto (.mf). Pero, no se da ningún "offset" a esa hora, así que este dato por sí mismo no permite saber si el APK o el JAR está creado en un país concreto. Un fichero dentro del ZIP con fecha de modificación a las 23:45 no significa nada por sí solo. ¿Las 23:45 de qué país?


Fechas de modificación de los ficheros dentro de un APK

Ficheros firmados y certificados

Algunos applets se firman, de forma que pueden escapar de la sandbox de Java y atacar a los usuarios. Los APK casi siempre están firmados, porque Google Play y Android dicen que así debe ser para usarlo en su plataforma. Cuando están firmados, se añade un certificado dentro de los ficheros ZIP. Este certificado está en una estructura PKCS7, que es un fichero con extensión (entre otras) RSA o DSA en el directorio META-INF. Los certificados puede que estén autofirmados. Esto es gratis y los atacantes no tienen que demostrar a nadie quiénes son en realidad.

Atacantes y certificados
Fecha de creación del certificado... "Válido desde..."
Los atacantes odian los certificados firmados por CAs, pero les encantan (y tienen que hacerlo) los certificados autofirmados. Son gratis y desechables. Pueden crear un certificado autofirmado ad-hoc para una app y nunca usarlo más. Eclipse y otras plataformas de desarrollo ayuda en esta tarea de crear expresamente certificados a la hora de compilar ficheros apk, como último paso antes de enviarlo a Google Play.

Los certificados se almacenan dentro de los APK cuando se crean. Y aquí está el truco. Su hora de creación se almacena sin "zona horaria, o sea, en UTC. En concreto en formato YYMMDDHHMMSSZ. La Z corresponde a "hora zulú", que es UTC o a efectos prácticos,, casi igual que GMT+0. time zone.

Vista en formato ASN.1 de la fecha de un certificado
Como curiosidad, si un certificado contiene una fecha más allá de 2049, se usa un formato llamado "generalizado", que es fundamentalmente el mismo pero incluye la especificación completa del año con cuatro cifras. YYYYMMDDHHMMSSZ.

Poniéndolo todo junto

Así que por un lado tenemos la fecha de sistema del creador, y la hora UTC, que no es más que GMT+0. Solo tenemos que asumir que el certificado y los ficheros son creados justo en el mismo momento para hacer las cuentas y calcular el "offset" de la zona horaria.

Si un fichero manifest o de firmas (que son los últimos creados en la compilación de un JAR o APK) contiene la fecha de sistema 16:00, 1 de enero de 2014, y la hora UTC del certificado pone que fue creado a las 15:00 del 1 de enero de 2014, si asumimos que se crearon en el mismo momento, podríamos decir (a menos que el atacante haya modificado su hora de sistema) que el atacante vive en una zona horaria GMT+1.

Hora UTC - Ficheros ZIP... en su diferencia está el offset y, por tanto, la zona horaria (fuente del mapa: timeanddate.com)
La herramienta que hace el cálculo

Hemos creado una herramienta que realiza el cálculo. Lee un fichero JAR o APK y, si está firmado:
  • Intentará extraer la hora de creación (UTC) de un certificado.
  • Intentará leer la hora de modificación del último fichero creado en la compilación (normalmente el fichero .sf en el directorio meta-inf).
  • Hará las cuentas y dirá en qué zona horaria vive el desarrollador, asumiendo que la creación del certificado y la compilación han ocurrido en el mismo momento (minuto arriba, minuto abajo) y que el desarrollador no ha modificado su hora de sistema.
Estos son algunos ejemplos reales:

Una app fraudulenta desde España

Malware desde E.E.U.U

Una aplicación falsa desde Hong Kong

Este APK es de una aplicación india falsa. Teen Patti poker
La herramienta está disponible en Python y compilada en C#. Ambas pueden ser descargadas desde este enlace: http://elevenpaths.com/downloads/gmtcheck.zip

Invitamos al uso de la herramienta.
Sergio de los Santos
ssantos@11paths.com