ElevenPaths Blog

Uno de los factores críticos sobre el que gira el mundo de la seguridad es el estudio y control de vulnerabilidades. Para ello existen organizaciones encargadas de tratar temas relacionados a este aspecto, como es el caso de MITRE, FIRST e ICASI. Veremos qué estándares utilizan y cómo aprovecharlos para entender mejor los problemas de seguridad. Si en la entrada anterior se cubrieron los CVE, en esta se hará los CWE y CAPEC.

CWE

CWE (Common Weakness Enumeration) es una lista de tipos de debilidades de software dirigida a desarrolladores y profesionales de la seguridad. Fue creada al igual que CVE para unificar la descripción de las debilidades de seguridad de software en cuanto a arquitectura, diseño y código se refiere. Se puede ver como un catálogo de debilidades documentadas que se suelen cometer programando, y que podría derivar en vulnerabilidades. Es muy utilizada por distintas herramientas de seguridad encargadas de identificar estas debilidades y para promover la identificación de las vulnerabilidades, mitigación y su prevención.

CWE satisface la necesidad que tienen las grandes empresas u organizaciones de conocer y tener catalogadas las distintas debilidades existentes. De esta forma pueden comprobar y asegurar sus productos frente a fallos de seguridad ya conocidos. De igual manera, los consumidores esperan que las soluciones compradas o contratadas estén correctamente protegidas frente a las debilidades conocidas, y así también utilizar este catálogo para analizar las posibles debilidades de soluciones adquiridas. Si se desarrolla con el ánimo de evitar las CWE en mente, se mitigan las posibilidades de que posteriormente se sufran vulnerabilidades.

Esta lista nace como iniciativa del MITRE para hacer frente a la diversidad de pensamiento sobre este asunto por parte de tres sectores: el académico, el comercial y el gubernamental.

La lista de CWE se ofrece en tres vistas:

Una de tipo diccionario, que incluye las debilidades debidamente enumeradas.
Una vista de árbol donde se clasifican las debilidades individuales.
Una nueva vista de árbol que permite a un usuario ampliar el conocimiento y las relaciones de las debilidades individuales encontradas en la vista anterior.

Cómo aprovechar la página del CWE

En el campo "Search by ID" podemos realizar una búsqueda especifica de aquellas debilidades cuando se conoce el CWE-ID sobre el cual está registrado.
En el enlace "Documents" se pueden encontrar todos los documentos públicos relacionados con CWE.
En los enlaces a "CWSS" y "CWRAF" se pueden encontrar toda la información relevante a estas dos siglas que se explicaran en próximos entradas.
En el enlace "Search the Site2 pueden realizarse búsquedas específicas de debilidades de software utilizando palabras clave que puede estar contenidas en el nombre o la descripción de las debilidades en caso de no conocer su CWE-ID.
Con el enlace "NVD (National Vulnerability Database)" se puede ir directamente a la página web de la base de datos de vulnerabilidades del NIST, de la que también se hablará en una próxima entrada.
Con los enlaces "Vulnerabilitties (CVE)" y "Attack Patterns (CAPEC)" puede consultarse las otras dos listas.
Con los enlaces "Weakness Scoring System (CWSS)" y "Weakness Risk Analysis Framework (CWRAF)", al igual que los enlaces comentados en el punto anterior, mostrará toda la información acerca de estas dos siglas.

La información almacenada por esta lista es clasificada para cada debilidad de la siguiente manera.

En la que se observa que una debilidad suele tener unas consecuencias comunes documentadas, unos patrones de ataque, y una probabilidad concreta de que sea explotada. Toda esta información permite saber a qué se enfrenta un usuario cuando ante una debilidad en el código.

En comparación con el catálogo de CVE, lógicamente esta lista contiene un numero considerablemente menor de registros. Mientras que en CVE existen unas 60.000 vulnerabilidades documentadas desde 1998 (ver gráfico), CWE almacena 714 debilidades conocidas.

Número de CVEs por año.
Fuente: http://www.inteco.es/blogs/post/Seguridad/BlogSeguridad/Articulo_y_comentarios/Ciberespionaje_criptografia

La última versión actualizada del top 25 de las debilidades más peligrosas que podrían encontrarse en el software, fue publicada el 13 de septiembre de 2011. Las cinco primeras de esta lista, son:

CWE-89: Improper Neutralization of Special Elements used in an SQL Command (SQL Injection)
CWE-78: Improper Neutralization of Special Elements used in an OS Command (OS Command Injection)
CWE-120: Buffer Copy without Checking Size of Input (Classic Buffer Overflow)
CWE-79: Improper Neutralization of Input During Web Page Generation (Cross-site Scripting)
CWE-306: Missing Authentication for Critical Function

CAPEC

CAPEC (Common Attack Pattern Enumeration and Classification) es un catálogo de patrones de ataque que se encarga de recolectar información sobre ellos, junto a un esquema de clasificación exhaustiva. Estos patrones de ataques no son más que las descripciones de los métodos comunes utilizados para la explotación de vulnerabilidades.

Las entradas de esta conocida lista intentan dar a conocer la perspectiva del atacante y los métodos utilizados para explotar los sistemas. Se generan después de un análisis de los ejemplos de exploits específicos. Estos exploits son presentados como ejemplo de explotación de una vulnerabilidad, o incluso pueden ser propuestos para añadirse en esta lista en caso de no estar registrado.

Al igual que los demás catálogos , CAPEC intenta ofrecer la información necesaria para ayudar a mejorar la seguridad en todo el ciclo de vida de desarrollo de software y también apoyar las necesidades de los desarrolladores. Muchas de las vulnerabilidades que se registran comparten patrones de ataques, por tanto, no suelen generarse entradas en esta lista tan comúnmente como en la de vulnerabilidades. CAPEC cuenta con unas 400 entradas (patrones) actualmente.

Cómo aprovechar la página del CAPEC

En el campo "Search by ID" podemos realizar una búsqueda especifica de un patrón de ataque si conocemos valor sobre el cual fue registrado en esta lista.
En el enlace "Methods of Attack View" el diccionario ofrece una clasificación de los patrones de ataque según los métodos que estos implementen. En la siguiente imagen se puede observar cómo CAPEC clasifica estos ataques y ofrece una vista de directorio en los que se puede ir desplegando cada uno de ellos y observar los distintos patrones.

Por cada patrón, se puede estudiar sus soluciones o mitigaciones comunes, los recursos necesarios, o las habilidades que son necesarias en el atacante para llevarlo a cabo.

En el enlace "Submit Content" se pueden proponer nuevos patrones de ataques para ser registrados en esta lista. Las instrucciones vienen detalladas en la página web. Sin embargo vale la pena mencionar que todo el proceso se basa en rellenar el formulario que nos suministran dentro del enlace con los detalles del ataque. Entre los más relevantes se encuentran:

Precondiciones necesarias.
Métodos del ataque (analysis, brute force, flooding, injection, spoofing, etc).
Conocimientos o habilidades requeridas para poder llevar a cabo este ataque.
Posibles soluciones o mitigaciones.
Debilidades asociadas (CWE-IDs)
Referencias, donde se suele hacer referencia a publicaciones que detallen o corroboren la propuesta del patrón de ataque propuesto.

En el enlace "Documents" se pueden encontrar todos los documentos públicos relacionados con CAPEC.
En el enlace "Search the Site" pueden realizarse búsquedas específicas de patrones de ataques utilizando palabras clave. Esto es muy útil si no se conoce el CAPEC-ID del patrón pero se tiene una idea del nombre o las palabras que pueden estar relacionadas con él.
Y por último, los enlaces "Vulnerabilities (CVE)" y ‘Software Weakness Types (CWE)’ que conectan esta lista con las dos antes explicadas para poder consultarlas en caso de ser necesario.

Las tres listas del MITRE mencionadas están estrechamente vinculadas, es decir, una vulnerabilidad es explotada gracias a una debilidad conseguida en un software, que a su vez ha sido aprovechada a través de un patrón de ataque. Por tanto cada vez que cualquiera de las tres listas recibe una nueva entrada, ésta es considerada, comprobada y estudiada, por lo que muy probablemente se puedan generar o complementar los registros en cualquiera de las otras.

En nuestras siguientes entradas hablaremos de las otras dos siglas relacionadas con el ámbito de las vulnerabilidades: CVSS y CVRF.

* Ocho siglas relacionadas con las vulnerabilidades (I): CVE

Umberto Francesco Schiavo

umberto.schiavo@11paths.com

Hace unas semanas Manuel Fernández, desarrollador y auditor de seguridad en Eleven Paths, encontró unos archivos DS_Store en direcciones URL de Google mientras realizaba pruebas con FaasT. Google premió el descubrimiento, con una mención en su Hall of Fame. También hemos encontrado algunos ficheros con cierta información sensible en servidores de Yahoo!, pero ellos no han respondido a nuestro aviso. ¿Qué encontramos exactamente? y, sobre todo ¿era grave?

Ya sabemos que cuando una empresa o un equipo de auditores realiza un test de intrusión, debe recopilar y atender a todos los detalles que se tienen al alcance, puesto que será la suma de todos esos datos los que pueden marcar la diferencia entre un test con un éxito moderado, o rotundo.

Durante nuestras pruebas con FaasT (para comprobar si es capaz de aportar algo sobre páginas muy expuestas como google.com, Yahoo!, apple.com...) encontramos algunos datos relevantes.

Google.es con ficheros DS_Store colgados en sus servidores y expuestos

Gracias a FaasT, en los servidores del buscador encontramos ficheros .DS_Store expuestos por el servidor web. Un archivo DS_Store puede disponer de rutas internas del equipo del usuario que manipuló la web, fechas y nuevas URLs con las que se puede seguir realizando el test de intrusión.

FaasT identifica este tipo de errores y lo refleja con detalle en su interfaz web. El modelo de pentesting persistente permitirá detectar, entre otras muchas cosas, estos errores de configuración que implican que el nivel de seguridad se rebaje, se retroalimente la auditoría y se abran nuevos caminos de forma que la suma de estos detalles marque el desarrollo de la auditoría, la enriquezca y complete.

Cuando se detectó este detalle en Google, probamos el plugin de DS_Store contra las direcciones URL donde lo detectó y pudo obtener un listado interesante de recursos. En la imagen tendríamos un ejemplo de cómo FaasT visualiza los elementos que puede sacar de un DS_Store encontrado en una URL. En este caso, aplicados a nuestros dominio demofaast.elevenpaths.com y donde se encuentran nuevas rutas a imágenes que se encontraban en el interior del DS_Store.

Ejemplo de cómo se visualizan la información interna de un ficheor DS_Store en FaasT

En el análisis de los DS_Store colgados en Google se obtuvieron los siguientes tipos de elementos:

Más de 40 rutas nuevas, que almacenaban datos sobre el GSA (Google Search Appliance) de Google donde se explica detalladamente cómo está montada la infraestructura, cómo se configuran o datos como documentación de su API interna.
Más de 30 documentos PDF aparentemente no públicos.
Otros ficheros DS_Store.
Otros recursos HTML.

Una vez notificamos a Google, los eliminó rápidamente y nos puso en el Hall o Fame como reconocimiento a la pequeña labor al mejorar su seguridad.

El caso Yahoo

Este caso es mucho más simple. Encontramos ciertos ficheros de SVN con información muy interesante en ellos, dentro de un dominio relativo a la publicidad en Yahoo!. Esta es una captura de lo que podía verse en ambos dominios.

Información sensible en tw.adspecs.yahoo.com

Más información sensible en tw.adspecs.yahoo.com

Fundamentalmente, fueron dos entradas.

* http://tw.adspecs.yahoo.com/tc/adspec_ppt/tw_chi/.svn/entries
* http://tw.adspecs.yahoo.com/tc/adspec_ppt/.svn/entries

En ellos se encontraban enlaces a ficheros cuando menos curiosos, como http://tw.adspecs.yahoo.com/tc/adspec_ppt/tw_chi/SynAd.zip

De la información encontrada, se podían obtener los siguientes datos (probablemente obsoletos, pero siempre interesantes de cara a una auditoría):

usuario ssh de svn.corp.yahoo.com (martinso)
usuario de svn: (martinso)
un dominio interno: svn.corp.yahoo.com
ruta interna: /yahoo/adtech/asia/apac/adspecs/tc/adspec_ppt/tw_chi

Muchos días después de escribir a Yahoo, eliminaron el contenido. Nunca obtuvimos respuesta por su parte.

Pablo González

pablo.gonzalez@11paths.com

A few weeks ago, Manuel Fernández, developer and security auditor in Eleven Paths, found some DS_Store files served by some Google URLs while testing FaasT. Google awarded the discovery with a mention in its Hall of Fame. We have found as well some files with certain sensitive information in Yahoo! servers, but they never answered our call. What did we find exactly? and, was it important?

We already know that when a company or pentesting team is running a pentest, all details available are important. The way they put them all together makes the different between a test with a big success and a moderate one.

During our tests with FaasT (to check if it could find something else in very exposed web pages like google.com, Yahoo!, apple.com...) we found some interesting data.

Google.es with DS_Store available on their servers

Thanks to FaasT, we found lots of .DS_Store files inside the search engine server. A DS_Store file may have internal paths inside, from the system of the user manipulating the web, dates, and new URLs that may be helpful for going further with the pentest.

FaasT identifies this kind of mistakes and shows them in detail inside its web interface. Persistent pentesting will allow to detect, between many other things, this configuration mistakes that implies lowering security level, feedback for the pentest, and open new ways... so adding up all this details empowers and completes the test.

When this leakage was detected in Google, we tried the DS_Store plugin in FaasT against the URL where they were detected, and we got an interesting list of new resources from them. In the figure below, there is an example as how FaasT shows elements found inside a .DS_Store file exposed in an URL. In this case, applied to our domain demofaast.elevenpaths.com and where new paths to PNG files can be found inside .DS_Store file.

Example of how internal information inside in a DS_store file is shown with FaasT interface

When analyzing Google .DS_Store files, we got the following information:

More than 40 new paths, storing data about Google GSA (Google Search Appliance) where the infrastructure, API documentation, or configuration was detailed.
More than 30 new PDF documents, not all of them publicly available.
Some other .DS_Store files.
Some other HTML resources.

Once Google was informed, the files were quickly removed and placed us in its Hall of Fame as a recognition for the little help improving their security.

Yahoo! case

This case is much more simple. We found some SVN files with very interesting information in them, inside a domain related with ads in Yahoo!. This is a snapshot with what we found in different paths inside the domain.

Sensitive information in tw.adspecs.yahoo.com

More sensitive information in tw.adspecs.yahoo.com

Fundamentally, there were two URLs.

* http://tw.adspecs.yahoo.com/tc/adspec_ppt/tw_chi/.svn/entries
* http://tw.adspecs.yahoo.com/tc/adspec_ppt/.svn/entries

Where you could find links to some files, like http://tw.adspecs.yahoo.com/tc/adspec_ppt/tw_chi/SynAd.zip

From the text files themselves, following information was available (maybe obsolete, but interesting in any case for a pentest):

ssh user for svn.corp.yahoo.com (martinso)
svn user: (martinso)
an internal domain: svn.corp.yahoo.com
internal path: /yahoo/adtech/asia/apac/adspecs/tc/adspec_ppt/tw_chi

May days later after notifying Yahoo!, they removed the content. We never had an answer from them.

Pablo González

pablo.gonzalez@11paths.com

We are working hard in Eleven Paths for next Mobile Word Congress in Barcelona, in late February. We have updated our official apps for Android, iPhone and Windows Phone with new features, languages and much more to come. But right now, we really want you as an administrator to try Latch in your website, CMS, platform or webmail system. We have written some detailed guides for administrators, so you can check how easy to install Latch is.

Right now, we have plugins (linked to their GitHub repository) for: Wordpress, Joomla, Redmine, PrestaShop, Drupal 6& 7, .Net Log in, OpenVPN, SSH, RoundCube, SquirrelMail, Moodle...

And we are preparing step by step guides for all of them, so you as an administrator can offer Latch to your users and protect them. Here they are uploaded to SlideShare, but you can download them if you want. More to come soon!

Latch installation guide for Wordpress from elevenpaths

Latch installation guide for Roundcube from elevenpaths

Latch installation guide for PrestaShop from elevenpaths

Latch installation guide for Joomla from elevenpaths

Latch installation guide for Drupal 7 from elevenpaths

Latch installation guide for Drupal 6 from elevenpaths

Eleven Paths, estamos trabajando duro para el próximo Mobile Word Congress en Barcelona, a finales de febrero. Hemos actualizado las apps oficiales de Android, iPhone y Windows Phone con nuevas fucnionalidades, idiomas y mucho más que queda por llegar. Pero ahora mismo, realmente queremos que como administrador, pruebes Latch en tu página web, CMS, plataforma o sistema de correo web. Hemos escrito guías detalladas para administradores, para que puedas comprobar qué sencillo de instalar es Latch.

En estos momentos, disponemos de plugins (enlazados con su respositorio GitHub) para: Wordpress, Joomla, Redmine, PrestaShop, Drupal 6& 7, .Net Log in, OpenVPN, SSH, RoundCube, SquirrelMail, Moodle...

Y estamos preparando guías paso a paso para todos ellos, para que como administrador, se puede ofrecer Latch a los usuarios y protegerlos. Aquí están algunas subidas a SlideShare, pero pueden descargarse si así lo deseas. Pronto tendremos más disponibles

Guía de instalación de Latch para Wordpress from elevenpaths

Guía de instalación de Latch para Roundcube from elevenpaths

Guía de instalación de Latch para PrestaShop from elevenpaths

Guía de instalación de Latch para Joomla from elevenpaths

Guía de instalación de Latch para Drupal 7 from elevenpaths

Guía de instalación de Latch para Drupal 6 from elevenpaths

Google Play, como consecuencia de su política de aceptación de apps, aloja frecuentemente programas falsos (que abusan de marcas y permisos) o malware puro y duro. Este hecho en sí, no es novedad. Pero es interesante no perderle la pista a las tendencias que siguen los atacantes. En estos momentos, se está observando un pequeño bombardeo de apps falsas de Flash Player (que no está oficialmente en Google Play). Además, hemos accedido a un servidor de un atacante y comprobado cuánto ha podido ganar con una de las estafas. Veamos cómo funcionan técnicamente y algunas curiosidades.

Tras varias campañas de apps falsas, juegos e imitadores de Whatsapps toca el turno de Flash Player como reclamo para sus víctimas. Si bien no se han encontrado tantas como en otras ocasiones con juegos y aplicaciones diferentes (hubo un día que los atacantes subieron 30 Whatsapps falsos a Google Play), sí que se está encontrado un goteo constante. Al margen del interés de muchas empresas en exagerar el malware en Android, (que no creemos exagerado), es necesario recordar este tipo de problemas de seguridad. Sobre todo, cuando se está empezando a inculcar la idea de que, si siempre se descargan aplicaciones desde el market oficial, se obtiene una higiénica garantía en Android. Si bien es el mejor sitio para descargar, está lejos de garantizar nada.

Flash para Android

Hace un tiempo, Adobe anunció que dejaría de dar soporte Flash para las nuevas versiones de Android a partir de 4.1. Esto quiere decir que no tendrían la "certificación", no que no funcionase correctamente en estas nuevas versiones (de hecho, funciona). Incluso es posible descargar desde la página oficial de Adobe versiones de Flash. Desde el 15 de agosto de 2012, no se puede encontrar Flash Player en Google Play. Y si se encuentra uno, es o bien de un particular que lo ha colgado (los hay legítimos), alguien que ha tomado prestado el código, empresas legítimas... o un "fake" o una estafa Y de esos nos vamos a encargar.

Algunos ejemplos y curiosidades

Uno de los Flash Player falsos en Google Play

Desde finales de enero, hemos observado diferentes e insistentes atacantes. El 30 enero nos encontramos con un mismo atacante que sube dos versiones falsas de Flash muy diferentes, incluso han sido compiladas en diferentes plataformas (parece que Windows y Mac respectivamente). La primera es especialmente curiosa: pesa solo 57 Kbs. Lo único que hace es preguntar por si se quiere descargar Flash. Entonces acude a un Flash oficial pero colgado como adjunto en el foro xda-developers, y lo instala. Y esto es todo por parte de la aplicación. Mientras, también ha instalado un agresivo paquete de publicidad (Leadbolt).

La segunda parece más profesional. Dice venir de Vietnam, pero en realidad parece estar programada en España. Además, han usado un email robado para dar de alta la cuenta en Google Play. En concreto, la de woodybald@gmail.com. Un hombre de negocios de Nueva York dedicado a la inmobiliaria que ha dado de alta varios dominios con ese correo. Instala dos librerías que bombardearán el móvil con anuncios: Mobclick y Revmob.

Varios Flash falsos mostrados en una búsqueda en Google Play

Al día siguiente lo intenta otro atacante con varios paquetes. Probablemente proveniente de Londres. Este, desde hace tiempo, tiene una técnica muy interesante. Simplemente te deriva la página web y te pide 5 euros por la instalación. Si se paga, proporciona un enlace de descarga, que no es más que el oficial de Adobe, de libre acceso. Lo ha intentado en varias ocasiones con la misma técnica en el pasado. Dispone de un correo muy aparente, que parece oficial de Android: flashplayer@android.com.de.

Se trata de una página colgada en un dominio, normal y corriente. Gracias a la herramienta Cansina de Hispasec, descubrimos dos cosas interesantes:

Que obviamente no es necesario pagar para llegar a la página de descarga... (disponible en la ruta fp/osccs.html). Desde ahí, envía al enlace abierto y público para la descarga oficial de desde Adobe, que hemos referenciado más arriba.
Que mostraba las visitas de la herramienta Webstat abiertamente en otra ruta del servidor. Así hemos podido comprobar cuántas visitas ha recibido

La primera imagen es la que invita a pagar, en /fp/. La imagen de la derecha, la de después de haber pagado.. que está abiertamente en la ruta fp/osccs.html

En el webstat, descubrimos que la página está funcionando desde mediados de enero, internacionalmente (de hecho el país que más la visita es Brasil). Y lo curioso es que en enero, el atacante consiguió nada menos que 25.000 visitas a la página que solicita el pago, y 176 visitas a la que lo confirma. Obviamente esto no tiene por qué signficar 25.000 infectados o 176 víctimas de la estafa. Los datos son un indicio muy importante, no una prueba. Pero si, con cierta cautela, consideramos o conjeturamos arbitrariamente que solo la mitad de esas 176 visitas han llegado pagando los 5 euros correspondientes... El estafador ha podido ganar más de 400 euros en unos 15 días gracias a esta aplicación (pero tiene más que se basan en dominios parecidos...).

Las únicas páginas en el dominio. Arriba las visitas totales a la página que invita al pago. Abajo las que se supone que han accedido al pago con éxito.

Por supuesto, todos los user-agent de visita a la web, corresponden a teléfonos Android.

Por si fuera poco, esta app también bombardea el teléfono con notificaciones push gracias a la compañía de anuncios.. https://parse.com/.

Una "estafa" española

La "app" simplemente redirige a trailers de Youtube

La siguiente, aparecida a principios de febrero, parece totalmente española. Curiosamente, la menos detectada por los motores antivirus en Virustotal. Muestra un diálogo en la pantalla para ver vídeos de Youtube. Nada del otro mundo. Pero antes invita a aceptar una política de seguridad, que está colgada aquí. En ella se hace referencia a una empresa española de "marketing directo", con su CIF, errores de ortografía, erratas, referencia a la ley y declaración de buenas prácticas. Sin embargo, no dice lo que la aplicación hace realmente.

Por supuesto, la aplicación está asociada con el gestor de anuncios TapContext que, obviamente, inutiliza prácticamente el teléfono inundando con publicidad. Pero eso es, "lo de menos" puesto que es la práctica habitual.

Si se examina el código, podemos comprobar que recorre la información de la agenda, incluso la de Whatsapp, y sube a un servidor la información de la víctima. Aquí presentamos algunas partes del código en la app (que aún no hemos estudiado a fondo).

Otra parte del código...

El atacante en este caso no se esconde. Tanto la política de privacidad, como el dominio que recoge los datos recopilados del teléfono, incluso el dominio en el que se muestra el menú de vídeos de Youtube (http://movilapp.es/youmovies/index.html, que a su vez redirige a http://trailersyoutube.inversionis.com)... todos pertenecen a una misma empresa y una misma persona: Santiago Martinez Antequera, que trabaja como consultor de QA. Además el blog inversionis.com es simplemente un blog que copia (con referencia) noticias del conocido Expansion.com con un bot. Parece poco probable que no esté al corriente de la aplicación y el uso que se le está dando, puesto que lleva entre 5.000 y 10.000 descargas desde finales de enero.

La mayoría de las apps mencionadas han sido retiradas (menos la española, que cuenta con otra aplicación plagiada). Hay más modelos de estafas con Flash. La mayoría simplemente descargan el Flash oficial de Adobe, a veces exigiendo un pago a veces no. Estas nos han parecido las más curiosas, puesto que parece que hay varios grupos interesados durante estos días en este reclamo concreto en Google Play.

Sergio de los Santos

ssantos@11paths.com

@ssantosv

There are millions of malicious applets (JAR files) and Android apps (APK files) out there. Have you ever wondered where do they come from? Which country? At least, which is its time zone? In forensics, it may be interesting to check if this malicious app is made in Russia, Brazil, China, India or United States. Let's see how.

The files inside the ZIP files

APK (Android apps) and applets (Java programs) are all the same format: a variation of a zip file. This means they share most of the PKzip specifications. When you zip a file, the "modification time" attribute of each file is stored inside the zip file. If you want to check, just open a zip file with any unzip tool.

The way zip files store files' time is quite funny, and we will talk about it in some other post. The interesting part is that the time they store is the hour and date of the system they are compiled in. There are also files created just when the file is compiled with the system time associated. So, the system time of the creator is stored in files like the manifest (.mf), and some other. But, no "offset" is given with it. So, with this data by itself, we can't tell which is the APK or JAR creator's time zone. A file inside the zip modified or created at 23:45, means nothing by itself. 23:45 in which country?

Modification time in files inside an APK

Signed files and certificates

Some applets are signed, so they can escape from the Java sandbox and attack users. APK files are always signed, because Goolge Play and Android says they have to. When they are signed, a certificate is added inside zip files. This certificate is a PKCS structure in the META-INF folder. Inside there's a RSA or DSA file (between others). Certificates may be self-signed. This is free and attackers do not have to prove to anyone who they are.

Attackers and certificates

Certificate date... "Valid from..."

Attackers hate CA signed certificates, but they love (and they have to use) self signed certificates. Because the can be disposal. They can create a self-signed certificate ad-hoc for an app and never use it again. For example, Eclipse and other platforms helps you creating an ad-hoc certificate when compiling an APK file, as a last step to upload it to Google Play.

Certificates store the date when they were creatd in a field. And here is the trick. They store it in UTC time, no matter what the system time is. Here is a certificate's creation time and date in UTC time in "YYMMDDHHMMSSZ" format. Last Z corresponds to "zulu time" which is UTC or, practically, GMT+0 time zone.

ASN.1 view of a certificate date

As a funny thing, if the certificate contains a date further than 2049, they use generalized time format, which is the basically the same but with four digit year: YYYYMMDDHHMMSSZ.

Putting it all toghether

So we have the system time of the creator, and the GMT+0 time. We just have to assume files and certificate were created almost at the same time to make the math and calculate the time zone offset.

If a manifest or signature file is created at system time 16:00, Jan 1st 2014, and certificate UTC time is 15:00, Jan 1st 2014, assuming they were created at the exact same moment... we can say (unless the attacker changed its system time) that the attacker lives in GMT+1.

UTC Time - ZIPs file... gets the offset and thus, time zone (map from timeanddate.com)

The tool that makes it all for you

We have created a tool that calculates this for you. Just reads a .jar file (apk or applet) and, if signed:

* Will try to extract UTC time from the certificate.

* Will try to read the modification time of the last file created (usually signature file under META-INF folder).

* Will do the math and tell you which time zone the developer lives in, assuming certificate creation and compilation have been done at the very same moment.

Here are some examples:

A fraudulent app from Spain

Malware from U.S.A

Fake app from Hong Kong

This APK is a fake of an Indian app, Teen Patti poker

The tool is available in Python and a compiled C# .NET version. They both may be downloaded from http://elevenpaths.com/downloads/gmtcheck.zip

We encourage you to use it.

Sergio de los Santos

ssantos@11paths.com

@ssantosv

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 almacenanes 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

@ssantosv

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.

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 de 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

En Eleven Paths, seguimos trabajando para hacer que el sistema de pentesting persistenteFaasT 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.

Metadatos: En este blog se ha hablado acerca de la importancia de los metadatos en varias ocasiones. Aparte de que según enuncia el Esquema Nacional de Seguridad, los metadatos deben ser eliminados de los documentos públicos, FaasT analiza todos los ficheros que encuentra en la infraestructura de una organización para extraer información importante y la muestra junto con la ruta del fichero concreto por el que se está filtrando la información.

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

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

@ssantosv

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

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

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

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.

¿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.

Sergio de los Santos

ssantos@11paths.com

@ssantosv

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

@ssantosv

¿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 roba información personal, 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

Sergio de los Santos

ssantos@11paths.com

@ssantosv

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.

Cristóbal Bordiú

cristobal.bordiu@11paths.com

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

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 de, 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.

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.

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"

Sergio de los Santos

ssantos@11paths.com

@ssantosv

Ocho siglas relacionadas con las vulnerabilidades (II): CWE y CAPEC

Fugas de información en Google y Yahoo! (encontradas con FaasT)

Information leakages found in Google and Yahoo! (found with FaasT)

Detailed guides for Latch installation in Wordpress, Joomla, Drupal, PrestaShop and RoundCube

Guías detalladas de instalación de Latch en Wordpress, Joomla, Drupal, PrestaShop y RoundCube

Detectados (muchos) Flash Player falsos en Google Play... y cuánto han ganado con las estafas

New tool: GmtCheck. Where does this Android App or applet come from?

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

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

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

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

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

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

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

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

Ataques contra redes de satélites (I)

Ataques contra redes de satélites (y II)

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

Eleven Paths on "Digital Futures" video series

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