La estafa de los Falsos Brokers que van a hacer que te forres con Amazon o Tesla y el Growth Hacking en Twitter con tus apps móviles gratuitas

Si el otro día os hablaba de una pregunta que me entró por mi buzón en MyPublicInbox de cómo una persona estaba siendo monitorizada por que en un descuido alguien consiguió compartirse la ubicación de iPhone por iMessage, hoy os traigo otra estafa de la que me han llegado como alrededor de diez consultas por el mismo buzón. Se trata de la estafa de los falsos brokers que van a hacer que ganes mucho dineros invirtiendo en Amazon, Tesla, u otra empresa similar.

Figura 1: La estafa de los Falsos Brokers que van a hacer que te forres con Amazon o Tesla y el "Growth Hacking" en Twitter con tus apps móviles gratuitas

Mucho se ha hablado de la estafa de los BitCoins, y cómo utilizan la imagen de personas famosos para engañar a las víctimas. Yo me he visto utilizado muchas veces como gancho de esa estafa, y por eso escribí un artículo para que quede claro que "No, Chema Alonso no se está forrando con BitCoins" como dicen las campañas de Malvertising que lanzan en Facebook, Instagram o Twitter. Pero de la que voy a hablaros hoy hay un poco menos de información, y me han llegado ya muchas víctimas contándome su situación.

Figura 2: Ultimo mensaje que me entró por mi buzón en MyPublicInbox

con una nueva víctima de la estafa de los Falsos Brokers.

En definitiva es la misma estafa, pero esta vez hecha con la imagen de Amazon o Tesla o cualquier otra gran compañía que en la cultura popular esté muy metida como exitosa, y me sorprende que no están persiguiéndolo mucho. Entiendo al final que Amazon y Tesla, que son empresas cotizadas en bolsa no pueden estar en contra de lo que dicen las campañas que utilizan. 

Figura 3: El Selector de la Avaricia. Mete 20.000 € que ganarás 102.624 € en dos meses máximo.

O lo que es mismo, mete 20.000 € y en dos meses lo multiplicas por 6.

Es decir, que invertir comprando acciones en esas empresas te puede dar grandes retornos de dinero, pero lo cierto es que lo que prometen estos Falsos Brokers, es directamente falso, y si caes en sus manos no vas a invertir nunca en bolsa, pues son empresas falsas que capturan tu dinero y te sacan todo lo que puedan.

Figura 4: Campañas de publicidad en medios nacionales de gran tirada

Contratan campañas de publicidad y marketing que meten en los principales diarios de los países, como contenido patrocinado, utilizando la imagen de estas compañías. Este es un ejemplo de Amazon en un periódico online nacional en España. Por supuesto, cuando vas a la web, lo que hay son testimonios falsos y datos falsos, utilizando cuentas que no existen.

Figura 5: Testimonios publicados en la web de los falsos brokers

En este ejemplo puedes ver que utilizan una cuenta de Twitter con el testimonio de una persona, pero no es verdad esa cuenta no existe o ha sido eliminada por ser fraudulenta. Siempre es la misma idea. Invertir en malvertising, utilizar testimonios para ganar confianza - como hacen en la estafa de los BitCoins o la estafa de los Hackers para espiar WhatsApp for Hire -, y conseguir el lead para luego trabajarse a la víctima por e-mail o por teléfono, al más puro estilo "Tocomocho".

Figura 6: La cuenta del "Rey Hakim" no existe.

 (¿Has visto el Principe de Zamunda? Cachondos...)

Eso sí, todo es legal, porque son empresas en el otro lado del mundo y en la letra pequeña de los contratos que firmes ya te pone que puedes perderlo todo, que no están obligados a devolverte el dinero, etcétera, etcétera, así que, si no te has leído la letra pequeña no tendrás nada que hacer en ese paraíso fiscal al que vas a enviar tu dinero.

Figura 7: Letra pequeña de la campaña de marketing que ves en la web

Los contratos no los ves en la web, y tendrás que esperar a que ellos, cuando tengan tu información y estén convencidos de que vas a darles el dinero, te los pasarán. El texto que ves en la Figura 7 es de la campaña de marketing que hace otra empresa, separada, de los Falsos Brokers, para curarse también en salud de las denuncias que llegarán.

Falsos Brokers y Growth Hacking

En este otro caso de aquí, de esta misma semana (aún activo) , me llamó la atención que la campaña de malvertising se  hiciera directamente desde una cuenta de Twitter, que además se llama Top Business (13). Cuando la vi, llama la atención que se ha abierto a finales de Junio de 2021 y que solo sigue a 13 cuentas - ninguna de los creadores de esa supuesta empresa - y tenía ya más de mil seguidores.

Figura 8: Campaña de Falsos Brokers por Twitter

Si miramos a quién sigue, está claro que busca posicionarse como una cuenta corporativa, siguiendo al Presidente Biden, a Tesla, a Elon Musk, a Forbes, etcétera. Todo lo que a una víctima le pueda dar el olor de "dinero" o "poder", pero si vemos a los seguidores, la cosa cambia. 

Figura 9: Siguiendo "Dinero" y "Poder"

Entre los followers ay una lista de un montón de personas que estaba seguro de que no seguían esa cuenta por interés propio. Así que busqué a uno de los seguidores para hablar con él y le pregunté directamente si él seguía esa cuenta por algo, ya que me olía cómo habían conseguido los seguidores.

Figura 10: Constatando el Growth Hacking con tokens OAuth

Como era de esperar, la respuesta era clara: No tenía ni idea de cómo la había seguido. Así que, como era evidente, han comprado seguidores a alguna empresa que tiene apps de Twitter con Tokens OAuth capturados por medios de apps móviles.  En su caso, la única app que tenía un token OAuth válido no caducado era Steroload, que se dedica a hacer Growth Hacking para bandas de música, y parece ser que para cualquier postor - incluso Falsos Brokers -.

Figura 11: Apps con Tokens OAuth de Twitter válidos

de la persona forzada a seguir a TopBusiness13

Es decir, te descargas una app gratuita, te piden que te autentiques con Twitter, autorizas la app de Twitter, y se llevan el token OAuth - como explicábamos en el ejemplo de Sappo para Twitter -. Normalmente estas apps gratuitas capturan estos tokens para vender likes, followers, o similares a gente que desea crecer en relevancia en cualquier plataforma - es su negocio - pero una vez que tienen el token OAuth de Twitter, ya pueden hacer lo que quieran, como hacerte seguir a una cuenta fraudulenta para dar confianza a las nuevas víctimas. 

Figura 12: Resumen de las pruebas de seguridad del

Asistente de Seguridad de Twitter en MyPublicInbox.

Esta es una de más de veinte características de fortificación de cuentas Twitter que se recomiendan en el asistente de seguridad de Twitter que hicimos en MyPublicInbox que puede utilizar cualquier usuario de la plataforma. Así que, si no quieres ser parte de este tipo de estafas, revisa qué apps de Twitter tienen tokens OAuth con el que pueden controlar tu cuenta.

Figura 13: Buscando en Tacyt "sospechosos" de capturar tokens OAuth

Alberto se acordaba de haber instalado alguna app de SoundCloud que hacía algo por Twitter, así que decidí irme a mi querido Tacyt y hacer un poco de dorking para localizar apps que tuvieran que ver con SoundCloud y pidieran autorizar tokens de OAuth. Un sencilla búsqueda y aparecieron un par de ellos.

Figura 14: Links de Twitter para capturar tokens OAuth

Como se puede ver, en los enlaces que tienen estas apps se puede ver cómo hacen uso de las APIs de Twitter para autenticar apps de Twitter y capturar los Tokens OAuth. Así que, cuando te bajes una app móvil gratuita, piensa cuál es su posible modelo de negocio.

Conclusión

Nadie da nada por nada. Casi todas las apps móviles tienen un modelo de negocio. Si no sabes cuál es... puede ser malo. Los Tokens OAuth que te piden apps móviles gratuitas son por algo - y puedes acabar siendo parte de algo así -. 

Figura 15: Cómo protegerse de los peligros en Internet
de José Carlos Gallego Cano

Y si un broker puede convertir 20.000 € en 120.000 € en dos meses... ¿para qué gastar dinero en publicidad para hacerte ganar dinero a ti? ¿De verdad?

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Gremlin Botnets: El club de los poetas muertos en la RootedCON 11

En lo que va a de año no es que haya hecho muchas cosas en forma de eventos, que se pueda decir. En total, un par de conferencias, un podcast desde casa y un vídeo que grabé para dejar unas recomendaciones sobre libros de hacking y seguridad informática. Pero os las he traído todas por si son interesantes para vosotros.

Figura 1: Gremlin Botnets: El club de los poetas muertos en la RootedCON 11

El último que os debía era el vídeo de la conferencia sobre Gremlin Botnets que impartí en la RootedCON 11 en Madrid, el jueves 5 de Marzo de 2020, justo antes del confinamiento. Dura poco más de 40 minutos, y la tienes íntegra aquí.

Figura 2: Gremlin Botnets: "El club de los poetas muertos"
En esta charla hablé de las Gremlin Botnets, y tenéis publicados todos los artículos, con todas las explicaciones y la demos en vídeo en la siguiente lista de posts, por si te los quieres leer con calma.

- Gremlin Botnets: El club de los poetas muertos [Parte 1 de 6]
- Gremlin Botnets: El club de los poetas muertos [Parte 2 de 6]
- Gremlin Botnets: El club de los poetas muertos [Parte 3 de 6]
- Gremlin Botnets: El club de los poetas muertos [Parte 4 de 6]
- Gremlin Botnets: El club de los poetas muertos [Parte 5 de 6]
- Gremlin Botnets: El club de los poetas muertos [Parte 6 de 6]

Y ya os dejo por aquí el resto del material de este año, por si se te había escapado la conferencia que di en el Seminario de Ciberseguridad, la entrevista que me hicieron durante la C0r0n4con en el podcasts de "Cosas de Hackers", y el vídeo con los consejos para hackers y recomendaciones de libros de seguridad que os grabé este fin de semana.

Figura 3: Seminario de Ciberseguridad por Chema Alonso

Figura 4: Entrevista a Chema Alonso en "Cosas de Hackers"
por The XXLMan y José Manuel Ávalos Morer

Figura 5: 10 libros recomendados para hackers

Y esto es todo lo que os traigo hoy. Recordad que durante este periodo aún continúa el descuento de 0xWord durante el confinamiento, pero que está a punto de acabar, así que si quieres hacerte con algo de nuestro material, aprovecha ahora. No lo dejes más.

Desde hoy, y durante las próximas dos semanas en @0xWord hemos puesto un descuento de un 10% de descuento con el código YOMEQUEDOENCASA en todos los productos, y hemos rebajado un 5% los VBOOKS (Cursos Virtuales). Por favor, colaboremos con quedarnos todos en casa.

— 0xWORD (@0xWORD) March 16, 2020

Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

Gremlin Botnets: El club de los poetas muertos [Parte 6 de 6]

Y paso a paso llegamos a la última parte de esta serie. Ya hemos visto cómo puede robar fácilmente el control de una Cuenta de Developer de Android de un desarrollador si se caduca la cuenta de correo electrónico asociada a ella. Esto es algo que puede ocurrir por muchas factores, como que la cuenta de e-mail sea abandonada, o el fallezca el desarrollador y nadie elimine sus apps o tome control de ellas "legítimamente".

Figura 60: Gremlin Botnets: El club de los poetas muertos [Parte 6 de 6]

En la prueba que hicimos en la parte anterior de este artículo vimos como habíamos sido capaces de localizar con un test no demasiado grande un total de ocho cuentas de desarrolladores que podíamos controlar al ser capaces de tomar posesión de sus direcciones caducadas de correo electrónico. Pero si evaluamos ahora el impacto que estas cuentas tienen, el resultado es muy grande.

Impacto de la investigación de "los poetas muertos"

Al final, un desarrollador tiene varias apps subidas a Google Play, y cada una de esas apps tiene una base de usuarios que las han instalado. Es decir, una cuenta de desarrollador puede traer miles o cientos de miles de dispositivos móviles que unir a nuestra Gremlin Botnet por medio de convertir una a una todas esas apps en nuevas Gremlin Apps.

Figura 61: Lista de apps afectadas

En nuestro caso, con solo 8 cuentas de desarrollador se podían controlar un total de 35 diferentes apps, todas ellas con un diferente número de instalaciones, como podéis ver en la tabla, llevando a que un atacante se hiciera con una Gremlin Botnet de apps que poder volver maliciosas de una forma sencilla y de un tamaño considerable.

En nuestra investigación, el número total de instalaciones activas de estas apps ascendía a un nada desdeñable número de 4.854.350 descargas, lo que da una clara idea de la magnitud del problema que se puede producir si no se controla la caducidad de las cuentas de correo de los desarrolladores de las apps que tú, como administrador del parque móvil y/o responsable de seguridad de una empresa, no controlas.

Figura 62: Clasificación de los paquetes APK de apps en riesgo

Por supuesto, todos los paquetes de las apps que tienen una cuenta de desarrollador con una dirección de e-mail que cualquiera puede registrar debe levantar una alerta en todos los sistemas de seguridad, por eso en Tacyt, mASAPP y CyberThreats se generan esos reportes de seguridad que, si tienes la gestión de seguridad automatizada con una plataforma tipo SandaS GRC para ver tus indicadores de riesgo, te muestra la situación en tiempo real en cualquier cuadro de mandos.


Figura 63: Control del riesgo digital con SandaS GRC

Por supuesto, el problema, desde el punto de vista de seguridad, es un poco mayor y no nos podemos quedar aquí, ya que si tenemos la cuenta de un desarrollador de una app, probablemente esa aplicación necesitará infraestructura, y puede que también esté en riesgo.

Cuenta de developer, cuenta de infraestructura

Al final, cuando un desarrollador hace una aplicación móvil, probablemente necesite un backend donde almacenar datos. A este backend, que puede ser un servidor en un proveedor de hosting, o un entorno de cloud IaaS o PaaS, tendrá algún nombre de dominio, que seguramente esté registrado a su nombre, etcetera.

Es decir, si tienes una dirección de correo electrónico que pertenece a un desarrollador, probablemente también tengas la cuenta que abre muchos otros servicios de infraestructura que se pueden descubrir simplemente abriendo el código de la app extrayéndolo del APK y viendo a qué servidores se conectan, algo que como sabéis hacemos en Tacyt.

Figura 65: Links extraídos en Tacyt de una app

Por supuesto, una vez descubiertos esos servidores de backend, un atacante puede utilizar esa cuenta para ver si el desarrollador la ha utilizado como identificador del servicio. Algo muy común, pero que no debería haber pasado nunca.

El día que utilizamos la dirección de correo electrónico como identificador de cuentas, convertimos algo que debería ser siempre público (una dirección de mensajería) en algo que no tiene por qué ser público, el id que abre una zona segura en una plataforma. Una de las cosas por las que dije aquello de que el e-mail estaba muerto, ¡larga vida al e-mail!

Tacyt & CARMA: Investigar en el mundo del malware

Como muchas veces hemos contado, en ElevenPaths hacemos muchas investigaciones al respecto del malware, adware, cibercrimen o mejoras de seguridad en el mundo de las apps móviles, y compartimos esas investigaciones con otros centros de formación, organizaciones y empresas. Así, tenemos un programa de colaboración para investigación en Tacyt para evolucionar los sistemas de seguridad del mundo de las apps móviles. Nuestro compañero Sergio de los Santos ha dirigido investigaciones con la Universidad Politécnica de Madrid e IMDEA o con la Universidad Piraeus en Grecia, donde hemos dado acceso a nuestra plataforma a sus equipos de investigación. 

Figura 66: CARMA ofrece muestras de malware en apps para investigadores

Y ahora hemos dado un paso más con el lanzamiento del programa Curated Android Malware APK Set (CARMA), que es un servicio gratuito ofrecido por el área de Innovación y Laboratorio de ElevenPaths. En él se proporciona a los investigadores un conjunto de muestras de malware, adware y otros archivos potencialmente peligrosos recopilados para el sistema operativo Android. Estas muestras tienen un uso exclusivamente destinado a la investigación o estudio académico y está prohibido su uso para cualquier otro fin, lucrativo o no.

Figura 67: Solicitud de participar en el programa CARMA

El fin de estos conjuntos es proporcionar muestras de calidad que puedan ser utilizadas para su análisis en sistemas expertos, Machine Learning aplicado a Ciberseguridad, nuevas ideas usando Inteligencia Artificial o cualquier otro método que permita mejorar la detección futura de este tipo de amenazas.

Figura 68: Tipo, año y tamaños de las muestras que se pueden solicitar

Como se puede ver, en él se ofrece un conjunto de varios Gigabytes de muestras de malware completas en su formato original, no alteradas y clasificadas por año, origen y tipo de amenaza. Desde Google Play y otros markets de aplicaciones, PUP, adware, malware, etcétera, todas ellas clasificadas por años desde 2017, y  donde también hay goodware.

Conclusiones finales y PPTs

El smartphone se ha convertido en el centro de nuestra vida digital personal, y por tanto las apps son parte de nuestro desarrollo persona, profesional y en sociedad. Necesitamos tener un ecosistema seguro de aplicaciones móviles para salvaguardar nuestra vida digital.

Entender los riesgos, las amenazadas y como gestionar esos peligros es fundamental. Las Gremlin Botnets bajo el control de grupos cibercriminales o de ciberespionaje son un riesgo importante para gobiernos y empresas. Las Gremlin Apps son un riesgo para las personas en Internet que pueden ver su vida totalmente comprometida.

Figura 69: Cómo protegerse de los peligros en Internet

En esta investigación solo quisimos poner de manifiesto cómo, si no tomamos precauciones, el poseedor de una Gremlin Botnet puede tener un poder muy peligroso, y por lo tanto todos tenemos que colaborar en su erradicación.

Figura 70: Gremlin Botnets: El club de los poetas muertos

Para terminar os, dejo las diapositivas que utilicé para la presentación de esta charla en RootedCON 2020 subidas a mi SlideShare, donde podéis ver resumido todo este largo artículo de seis partes. Esperamos que esta investigación os haya sido de utilidad y podáis aplicar alguna medida de contención de estos riesgos.

Saludos Malignos!

*********************************************************************************

- Gremlin Botnets: El club de los poetas muertos [Parte 1 de 6]

- Gremlin Botnets: El club de los poetas muertos [Parte 2 de 6]

- Gremlin Botnets: El club de los poetas muertos [Parte 3 de 6]

- Gremlin Botnets: El club de los poetas muertos [Parte 4 de 6]

- Gremlin Botnets: El club de los poetas muertos [Parte 5 de 6]

- Gremlin Botnets: El club de los poetas muertos [Parte 6 de 6]

*********************************************************************************

Autor: Chema Alonso (Contactar con Chema Alonso)

Gremlin Botnets: El club de los poetas muertos [Parte 5 de 6]

Una vez que vimos en funcionando en la cuarta parte de este artículo una Gremlin Botnet en el mundo de los dispositivos móviles Android, tal y como pensamos originalmente en hacer con la FOCA Botnet de la primera parte de esa serie, quedaría ver cómo se puede hacer crecer esta Grenlim Botnet de otra forma. En la segunda parte hablamos de las Gremlin Apps y su crecimiento orgánico y en la tercera parte de cómo se podían comprar apps en el mercado de compra/venta de apps para dispositivos móviles y meterlas dentro de nuestra Gremlin Botnet.

Figura 50: Gremlin Botnets: El club de los poetas muertos [Parte 5 de 6]

Hoy vamos a ver otra aproximación distinta para conseguir un crecimiento inorgánico de las víctimas de nuestra posible Gremlin Botnet mediante el robo de apps. Es decir, mediante el robo de las cuentas de los desarrolladores de apps.

Cómo robar apps para meterlas en la Gremlin Botnet

En la segunda parte de este artículo vimos, al final del mismo, que una aproximación posible para el robo de apps sería infectar los compiladores, tal y como se explica con el malware de XCodeGhost que infectaba las apps en el momento de compilación. También se podría hacer una campaña, como se ha hecho en el pasado, de Phishing o Spear Phishing para robar las credenciales de desarrolladores de Android Developer Console que no tuvieran cuidado - ni un segundo factor en su cuenta Google - para evitar un robo de sus cuentas. Esto también, como hablamos, se hace con las cuentas de GitHub, para infectar el código fuente de apps.

Figura 51: Mensajes de Phishing para robar las cuentas de Android Developer Console

Estas dos aproximaciones son válidas en un esquema de "crecimiento inorgánico" para el cibercrimen, pero durante el año 2015 a nosotros se nos ocurrió realizar una investigación con un enfoque diferente y mucho más silencioso, lo que podía ser utilizado por cibercriminales sin levantar mucho ruido, ya que nadie, como en el caso del robo de una cuenta por phishing iba a reclamar.

Robar las cuentas del "Club de los poetas MUERTOS"

La idea era muy sencilla. Robar las apps de los desarrolladores muertos. Esto es lo que nosotros llamamos el "Club de los Poetas Muertos", pero realmente podríamos decir que se trataba de buscar las cuentas de correo electrónico muertas detrás de las apps que estaban en el market de aplicaciones. Un viejo truco, aplicado al mundo de las aplicaciones móviles publicadas en Google Play.

La idea es bastante sencilla de comprender. Una app la publica un desarrollador de Android para lo que debe tener una cuenta en la plataforma de Google para la publicación de las apps. Esta cuenta puede ser una cuenta de Google, o una cuenta de otra plataforma, ya que se pueden dar de alta desarrolladores en este servicio sin necesidad de tener como identificador una cuenta de Google, algo que hace más universal la creación y publicación de cuentas al ponerle más fácil a los desarrolladores el entorno, pero que genera dos líneas temporales de caducidad.

¿A qué me refiero con dos lineas temporales de caducidad? Pues tan sencillo como que si la cuenta de desarrollador Android es una cuenta de Google, entonces realmente es como si solo hubiera una cuenta, porque cuando caduca la cuenta de Google se mueren todos sus servicios, incluidos los servidos asociados a la plataforma de desarrollo de apps en el market de Google Play.

Pero si el desarrollador se ha abierto una cuenta de Android Developer con una cuenta de correo electrónico de otra plataforma, podría darse el caso de que la cuenta de correo de la otra plataforma se muriese, y la cuenta de la plataforma de Google para desarrolladores de apps siguiera abierta. En ese caso, trayendo a la vida el correo electrónico muerto en otra plataforma de uno de los desarrolladores, podríamos pedir la recuperación de la contraseña de la plataforma de desarrollo de apps y tener control de todas ellas.

Por supuesto, la casuística de qué cuentas de correos electrónicos caducan y de por qué caducan esos buzones de correos puede ser altísima. Simplemente un descuido de un desarrollador o un accidente fortuito del destino, o la muerte del desarrollador, como hemos dicho. Podría ser que nos encontráramos con ese entorno, y decidimos hacer la investigación.

Consiguiendo los correos electrónicos de todos los desarrolladores

Esta podría parecer la parte más complicada de la investigación, pero lo cierto es que para nosotros fue bastante sencillo. Durante el año 2015, como he explicado en la primera parte de este artículo, estábamos trabajando en Tacyt, donde tenemos todas las apps móviles descargadas, abiertas, catalogadas y analizadas. Un Big Data de apps móviles para investigación que usamos en nuestros servicios de Cyber Threats en ElevenPaths para vigilar las amenazas que afectan a nuestros clientes, pero también usamos en mASAPP para vigilar que las apps de un parque de aplicaciones en una empresa no tienen riesgos o son controlados.

Figura 52: Servicio CyberThreats de ElevenPaths

Desde el año 2015 hemos hecho muchas investigaciones con Tacyt que habéis visto publicadas en por este blog, o que hemos publicado en el blog de ElevenPaths, donde seguimos sacando las investigaciones. Sacar la lista de todos los desarrolladores de apps fue tan fácil como lanzar unas consultas a Tacyt y obtener la lista de todas ellas.


Figura 53: Dorking & Pentesting con Tacyt
Una vez que teníamos la lista de todas las direcciones de desarrolladores, la idea era quedarnos con las más propensas a esta desincronización en fechas de caducidad. Para ello, basta con ir viendo cuáles son las políticas de caducidad de cada uno de los dominios más utilizados en el correo electrónico.

Figura 54: Cuanto tarda en caducar una cuenta después del último login

En la tabla que tenéis arriba podéis ver la información pública de cuándo expiran las cuentas después de un periodo de inactividad - sin hacer inicio de sesión en la plataforma - de cada uno de los dominios más populares que encontramos en nuestra plataforma. Como podéis ver, hay algunos que caducan bastante rápidos, como es el caso de AOL Mail o Protonmail.

La verdad es que, aunque tarden lo mismo, que en el caso de Google - nueve meses - no importa si no se ejecutan al mismo tiempo las deshabilitaciones. Es decir, si Google borra la cuenta a los nueve meses y el login es una dirección de e-mail de Hotmail, la posibilidad de que lo hagan al mismo tiempo es tendente a cero.

Buscando los Poetas Muertos

Una vez que teníamos la lista de todos los correos electrónicos, podíamos haber probado con todos los dominios que no fueran de Google, pero decidimos centrarnos en el siguiente más popular con más apps y probar cuántas de esas cuentas estaban caducadas. Así que seleccionamos el domino Outlook/Live/Hotmail de las direcciones de correo electrónico usadas por los desarrolladores que usaban direcciones de e-mail de plataformas de Microsoft, para asegurarnos que no existiera esa sincronización entre la eliminación del buzón de correo y la cuenta de Android Developer.

Figura 55: Probando a crear una cuenta que está viva

Para saber si el buzón de correo electrónico había sido eliminado, simplemente nos pusimos a comprobar si podemos o no crear esa dirección, con solo esa información ya sabemos si el buzón ha muerto o no. No hay más misterio.

Figura 56: Automatizando la petición de creación de la cuenta

Pero para poder comprobar muchas cuentas decidimos automatizar la prueba de direcciones de correo electrónico probando con plataformas de automatización de pruebas y usando una red de Servidores Proxy para evitar el bloqueo de dirección IP. Para ello, bastaba con hacer la petición del formulario anterior con diferentes nombres y revisar la respuesta para ver si la cuenta estaba creada o no.

Figura 57: Respuesta que indica que no está disponible esa cuenta (Está viva)

El resultado final es que, de la muestra de cuentas que probamos - un total de 217 cuentas asociadas a las apps más descargadas que teníamos en Tacyt en las que el desarrollador tenía una cuenta de correo electrónico - encontramos un total de 8 cuentas de e-mail asociadas a desarrolladores se encuentran caducadas y la cuenta de Android Developer seguía activa.

Figura 58: Resultados sobre 217 cuentas Outlook

Comprobar que una vez registrada una cuenta se puede recuperar el control de la cuenta de desarrollador de Android Developer es tan sencillo como solicitar un "Me he olvidado de la contraseña" y ver si nos llega el correo electrónico de recuperación de cuenta, tal y como se puede ver en la imagen siguiente.

Figura 59: Link de recuperación de cuenta

Es decir, en nuestra sencilla prueba, esas 8 cuentas del total de 217, supone un 3,7% de las direcciones de email de desarrolladores. Si extrapolamos linealmente - algo que puede tener muchos matices pero que sirve para hacernos una idea del volumen del problema existente en ese momento - estos resultados al número total de cuentas de desarrolladores, y al conjunto completo de proveedores de correo electrónico no asociados a Google, el número absoluto de cuentas de correo electrónico caducadas que se pueden usar para recuperar cuentas de Android Developer es muy considerable.

Y aún hay más

Tras la medición del número de cuentas de desarrolladores caducadas, realizamos un recuento sobre el impacto, medido en descargas, que tienen solo contando estas 8 cuentas "muertas", en el caso en el que se tomara el control de las mismas con el fin de reemplazar las apps de las que disponen por Grelim Apps que meter en nuestra Gremlin Botnet.

El resultado directo no es desdeñable y el indirecto tampoco, como os contaré en la última parte, pero por ahora cortamos aquí. Por supuesto, no recuperamos ninguna de las cuentas, ni hicimos nada más, y lo reportamos para que se tomaran las medidas pertinentes, pero estamos seguros de que esta situación sigue pasando a día de hoy. Nos vemos en la última parte.

Saludos Malignos!

*********************************************************************************
- Gremlin Botnets: El club de los poetas muertos [Parte 1 de 6]
- Gremlin Botnets: El club de los poetas muertos [Parte 2 de 6]
- Gremlin Botnets: El club de los poetas muertos [Parte 3 de 6]
- Gremlin Botnets: El club de los poetas muertos [Parte 4 de 6]
- Gremlin Botnets: El club de los poetas muertos [Parte 5 de 6]
- Gremlin Botnets: El club de los poetas muertos [Parte 6 de 6]
*********************************************************************************

Autor: Chema Alonso (Contactar con Chema Alonso)

Gremlin Botnets: El club de los poetas muertos [Parte 1 de 6]

Ayer en la RootedCON tuve la oportunidad de compartir con la audiencia una investigación que habíamos realizado en ElevenPaths durante el año 2015 y que en su momento decidí que lo mejor no era publicarla. Hoy en día, cinco años después, con mucho cambiando en el ecosistema, y con mayor concienciación de todo el ecosistema, pensé que era buen momento para compartir todo lo que estudiamos y descubrimos en aquel entonces.

Figura 1: El club de los poetas muertos [Parte 1 de 6]

Es cierto, que mucho de lo que hemos hecho quedó reflejado en pequeños artículos de este blog - pero no la parte final -, más muchos detalles de qué descubrimos que plasmó nuestro compañero en el libro de Malware en Android: Discovering, Reversing & Fonrensics que os recomiendo encarecidamente que os leáis. No, que os estudiéis a fondo, si queréis entender todas este mundo del cibrecrimen en forma de apps móviles para Android, que publicó nuestro compañero Miguel Ángel del Moral - que fue uno de los investigadores del equipo que construyo Tacyt junto a Sergio de los Santos - después de haber realizado todas estas investigaciones.

Figura 2: Malware en Android: Discovering, Reversing & Forensics

Pero como sabéis, a mí me gusta explicar de dónde viene todo, ya que las "ideas felices" no surgen por casualidad, y se trata de ir dar creando muchos puntos con cosas que vas haciendo hasta que un día, años después, eres capaz de juntarlos hacia atrás. Y esta es la historia de esta investigación, donde se unieron muchos puntos hasta acabar en lo que compartimos ayer en la RootedCON.

1.- La FOCA es una Botnet en el año 2010 y usa esteganografía

A finales del año 2010, después de haber dado ya la vuelta al mundo varias veces hablando de nuestra querida FOCA, y de que hubiera ya cientos de miles de instalaciones de nuestra app en sistemas Windows de todo el mundo, se me ocurrió hacer una inocentada el día 28 de Diciembre, como suelo hacer para ver si pillo a alguno "Despistao".  La inocentada fue, nada más y nada menos, que la FOCA era Botnet, y tuvo su aquel.

Figura 3: La FOCA es una botnet

Lo cierto es que FOCA tenía una función de Call-Back Home que nos permitía saber quién la tenía instalada en su equipo. No es que la pusiéramos a propósito, y lo cierto es que nunca utilizamos esos datos, pero si alguien usaba la FOCA versión gratuita, nuestra herramienta se conectaba a nuestros servidores y descargaba un anuncio de nuestros servicios en Informática 64. Era una forma de monetizar de alguna forma el trabajo y esfuerzo que pusimos a esta herramienta.

Figura 4: Supuesto canal encubierto con la publicidad

Con estos anuncios nosotros podíamos saber desde qué dirección IP nos estaba llegando la solicitud, y por tanto, información de "más o menos" quién estaba utilizando nuestra herramienta. No, no os asustéis, como os digo no nos importó nunca eso, y nos valía con saber que el gran Kevin Mitnick fuera uno de los embajadores más entusiastas de nuestra FOCA, y poner algunos anuncios para promocionar nuestros servicios.

Figura 5: Idea de controlar una FOCA Botnet

Pero para ese día se me ocurrió la idea de hacer creer a la gente que en las imágenes de los anuncios habíamos metido comandos ocultos para realizar operaciones en los equipos en los que estaba instalada la FOCA. Es decir, para convertir cualquiera o todas las FOCAs a la vez, en una herramienta para controlar los equipos instalados.

Figura 6: Esteganografía en la web

La idea de usar un canal de esteganografía en este escenario ficticio no llegó por casualidad. Había asistido a conferencias de Jordi Serra y de Alfonso Muñoz por aquella época y ellos estaban trabajando tanto en nuevos "Cover-Chanels" usando Esteganografía cómo en nuevos métodos de Estegonálisis, y me tenían entusiasmado con la potencia que ofrecía esto en el mundo del malware y el cibercrimen. Os dejo una charla que dio en el año 2008 (¡hace 12 años!) el gran Alfonso Muñoz en un evento que hicimos en Informática 64 sobre estos temas y que estimuló estas idea.

Figura 7: Esteganografía y Estegoanálisis

De hecho, conseguí que entre los dos hicieran un texto sobre ello que tenéis en 0xWord, y años más tarde Alfonso Muñoz hizo un estudio en ElevenPaths sobre las imágenes utilizadas en las apps móviles para poder tener una visión de qué grado de posibilidades existían de que se usaran las técnicas de comunicación con esteganografía en imágenes de una forma similar al panel de control de la FOCA Botnet.

Figura 8: Estegoanálisis de 1.5 M imágenes en APKs

Utilizando diferentes métodos de estegonálisis, y utilizando las imágenes que era posible extraer de nuestra plataforma de ciberinteligencia Tacyt que contenía todas las APKs abiertas y disponibles, los resultados que ofreció es que era posible que existieran comunicaciones de este tipo en ciertas apps, pero, como os imagináis, de difícil detección sin un estegoanálisis y reversing más profundo.

2.- El cibercrimen y las Gremlin Apps en Android

Durante los años 2014 y 2015, periodo donde hicimos toda la investigación y desarrollo de la plataforma Tacyt - que daría luego soporte a la solución para gestión de la seguridad de las apps en empresas mASAPP -, el mundo del cibercrimen estuvo bastante activo, y vimos muchas campañas de apps maliciosas con modelos de negocios muy claros basados en Fake Antivirus, Click Fraud, en SMS Premiums (SMSers) , campañas de Black ASO (Shuabang), Adware, e incluso en Dialers (JSDialers).

Figura 9: Apps usadas en la campaña de JSDialers

Utilizando Tacyt nosotros hicimos muchas investigaciones de las que os fui hablando por aquí. Algunas con mucho impacto. En los artículos enlazados tenéis muchas referencias del tipo de apps que vimos en aquellos tiempos, y os he dejado una charla que hice en aquel tiempo en Argentina donde utilizaba Tacyt para explicar cómo se puede usar este Big Data para encontrar a los cibercriminales,


Figura 10: Investigar cibercriminales en Android con Tacyt

Investigar a los cibercriminales por medio de parámetros tan curiosos como los API Keys nos permitía localizar a los grupos a pesar de que estos cambiaran las apps, y vimos entonces cómo comenzaban a utilizar lo que se llamó Gremlin Apps.

Figura 11: Una app normal que será maliciosa como el Cute the Rope Christmas

Es decir, apps que al principio son apps no maliciosas y más tarde, debido a un estímulo externo, se convierten en maliciosas. En este caso se podemos ver que una app turca era para algo distinto, y cuando se activó la campaña pasó a ser del Cut the Rope Christmas. Por supuesto, maliciosa.

Figura 12: Se volvió un Gremlin malo

Por supuesto, el riesgo a la hora de instalar una app, no es solo que el desarrollador sea malvado desde el origen y haya hecho algo que parezca goodware al principio pero que se va a volver malware. Puede suceder algo mucho más sistemático en el mundo del cibercrimen, como que se dediquen a comprar apps en venta, y el código cambie de las manos de un desarrollador que no tiene intenciones maliciosas a las manos de un cibercriminal. Pero eso lo vemos en la siguiente parte.

Saludos Malignos!

*********************************************************************************
- Gremlin Botnets: El club de los poetas muertos [Parte 1 de 6]
- Gremlin Botnets: El club de los poetas muertos [Parte 2 de 6]
- Gremlin Botnets: El club de los poetas muertos [Parte 3 de 6]
- Gremlin Botnets: El club de los poetas muertos [Parte 4 de 6]
- Gremlin Botnets: El club de los poetas muertos [Parte 5 de 6]
- Gremlin Botnets: El club de los poetas muertos [Parte 6 de 6]
*********************************************************************************

Autor: Chema Alonso (Contactar con Chema Alonso)

mASAPP CI: Cómo Integrar el análisis de vulnerabilidades en el ciclo de desarrollo seguro en las apps móviles que creas

Si has seguido este blog durante los últimos años, o has estado en el mundo de la ciberseguridad siguiendo las noticias que más nos han alertado en estos tiempos, sabrás que las apps en los markets oficiales de Google Play o App Store no son siempre trigo limpio, y los equipos de seguridad tanto de Apple, como de Google, como de la comunidad de ciberseguridad formada por researches y empresas como ElevenPaths han estado aportando conocimiento constantemente para luchar contra estas amenazas.

Figura 1: mASAPP CI: Cómo Integrar el análisis de vulnerabilidades
en el ciclo de desarrollo seguro en las apps móviles que creas

Si extendemos el número de markets, y llevamos a otros markets no oficiales de Google y Apple donde también se publican apps que son consumidas por personas y, como no, los propios empleados de empresas que llevan sus terminales personales en iniciativas BYOD.

- API Keys: Seguir el rastro a los "adwares" de Android con Tacyt
- Apps en Apps: Ficheros APK y EXE en apps de Android
- Dorking & Pentesting con Tacyt: Dominios, IPs y Puertos

- Dorking & Pentesting con Tacyt: Las P@ssw0rds

- Dorking & Pentesting con Tacyt: Las APIs de terceros
- JSDialers: Apps para Android "made in Spain" que llaman a números de pago "806" en Google Play

Para analizar esto, hace tiempo comenzamos a construir nuestra plataforma Tacyt de análisis de apps en markets oficiales y no oficiales, y podéis leer muchos artículos en este blog sobre ella - os dejo algunos enlazados -, además de tener un resumen de lo que se puede hacer en la charla que hizo Chema Alonso en Argentina hace ya muchos años.

Figura 2: Chema Alonso hablando de Tacyt en Argentina

Mucho del conocimiento en análisis de malware, lo plasmó uno de los ingenieros e investigadores que estuvo trabajando en la construcción de Tacyt, y que publicó en este libro de 0xWord de "Malware en Android: Discovering, Reversing & Forensics", donde habla del ciclo completo de ciberinteligencia en el mundo de apps maliciosas para el sistema operativo de Google.

Figura 3: Malware en Android: Discovering, Reversing & Forensics

Mucho ha avanzado la plataforma Tacyt - que tuvo de Codename el famoso Path 5 - en estos años, y sobre ella construimos mASAPP - también conocida como Codename Path 6 -, pero las amenazas siguen estando en los markets. Realizando una serie de consultas en nuestra herramienta de ciberinteligencia, Tacyt, podemos ver lo siguiente.

Figura 4: Buscando apps añadidas en un día concreto con más de 2 vulnerabilidades "High"

En la imagen anterior, se puede ver que, en un día concreto, fueron añadidas casi 500 aplicaciones con más de dos vulnerabilidades de nivel de criticidad alta a uno de los markets de apps más utilizados.

Figura 5: Consulta para ver cuántas apps tienen 1 o más vulnerabilidades críticas
con más de 1 Millón de descargas

Esta consulta, que recoge que existen más de 23.000 apps descargadas más de 1 millón de veces cada una con más de una vulnerabilidad con Criticidad High, demuestra que incluso los grandes pueden cometer errores lanzando apps inseguras a los entornos productivos, como hemos visto en el pasado con muchas empresas de renombre.

El mensaje que queremos transmitir es claro, la seguridad debe ser una preocupación en el desarrollo de apps tanto en las más grandes empresas como en desarrolladores independientes, pero también en la aprobación de apps que pueden ser instaladas en el parque de dispositivos móviles de tu empresa. ¿Cómo garantizas que una app que se va a instalar un empleado tuyo es segura o no? Lo suyo es que pudieras consultar la seguridad de esa app cada vez que se vaya a instalar.

Figura 6: Libro de SecDevOps de 0xWord

Pero... ¿cómo garantizas que tus propias apps no están inyectado problemas en tus clientes o empleados. Es decir, si yo hago apps, ¿cómo sé que no estoy haciendo algo mal? Evidentemente los desarrolladores están formados en seguridad, pero no pueden saber todo, por eso existen los equipos de seguridad, y los procesos de SecDevOps que ayudan a controlar y auditar la seguridad en todo momento.

En los dos casos, en el caso de querer validar que una app es segura para instalarse en el parque de nuestros dispositivos móviles integrando las políticas de seguridad dentro del SMDM de la compañía, como en el ciclo de desarrollo seguro de apps, el contar con Tacyt como plataforma de información o análisis es una buena ayuda. 

Figura 7: mASAPP Online

Y ¿cómo integro el conocimiento y el motor de análisis de seguridad de apps que tiene Tacyt en el ciclo de desarrollo continuo de mi empresas. Pues todo, tiene solución, y si esta es fácil y se puede automatizar, ¡mucho mejor! Para ello creamos tiempo atrás mASAPP  y su versión mASAPP Online - el famosos Codename Path 6 - que son productos de ElevenPaths que se encargan de realizar análisis de vulnerabilidades y comportamientos de las aplicaciones móviles y es una herramienta de trabajo para los administradores de seguridad que pueden:

a) Monitorizar que las apps que desarrollamos no tienen nuevas vulnerabilidades descubiertas y forzar una actualización al equipo de desarrollo, usando mASAPP Online.

b) Analizar la seguridad de las apps que aprueba el SMDM para decidir qué se puede instalar y qué no se puede en los terminales móviles de la empresa, y hacerlo de forma continua que las apps pueden volverse maliciosas, usando mASAPP.

Estas potentes herramientas, nos ofrecerán un exhaustivo análisis de la seguridad de las apps que desarrollamos e instalamos y permiten su utilización vía consola web, que puedes ver en este vídeo, pero también puede ser utilizado mediante API remota, lo que permite infinitas posibilidades de integración.

Figura 8: mASAPP de ElevenPaths

Y ahora vamos a ver cómo podemos integrar mASAPP Online en el ciclo de desarrollo de las apps de nuestra empresa para que sea un simple "check" más a la hora del ciclo SecDevOps de nuestro proceso de creación de tecnología. Y usaremos mSAPP CI.

mASAPP CI

mASAPP CI es una herramienta de código abierto, cuyo código se puede consultar en GitHub y que se puede descargar desde PyPI, surgida con el objetivo de incorporar la seguridad al ciclo de desarrollo de aplicaciones móviles de manera automatizada. mASAPP CI es la combinación de dos utilidades:

• masappcli: Comando hecho en Python que se podrá instalar con tan solo la ejecución de la siguiente sentencia en un entorno con el sistema de gestión de paquetes PIP correctamente configurado: pip install masappcli. 

Esta herramienta utiliza el API de mASAPP para el análisis de las aplicaciones y las compara en base a unos estándares que el usuario haya fijado. En caso de que estos estándares se superen en la aplicación analizada, masappcli imprimirá un error. El desarrollador puede fijar dos tipos de estándares:

◦ Máximo nivel de riesgo para su app, que será un valor numérico decimal entre 0 y 10. 

◦ Número máximo de vulnerabilidades y comportamientos desglosados por nivel de riesgo.

• masappstage: Plantilla pensada para su utilización como un stage dentro de un pipeline de Jenkins que controlará masappcli para analizar la aplicación generada por el usuario. Nota: Se admiten colaboraciones para ampliar la cobertura de masappstage a otras herramientas de integración continua :) .

Cómo implantar mASAPP CI

Paso 1: Obtén tus credenciales del API de mASAPP Online. Si no tienes una cuenta todavía, podrás registrarte en la plataforma y mediante un pago seguro vía PayPal obtendrás acceso al análisis de aplicaciones de mASAPP Online. Una vez completado tu registro y pago en mASAPP Online, en la sección de “Clientes API” encontrarás el identificador del cliente (API_KEY) y el secreto del mismo (API_SECRET).

Figura 9: Registro y funcionamiento de mASAPP Online

Paso 2: Crear o seleccionar un pipeline en nuestra instancia de Jenkins donde queremos que el análisis se realice.

Paso 3: Configurar las variables de Jenkins que requiere masappstage:

• mASAPP_CI: Esta variable de tipo “Elección”, tendrá cuatro posibles valores. Cada una de las distintas opciones suponen un tipo de ejecución de mASAPP CI:

o Ejecución estándar y ejecución estándar detallada: La ejecución estándar recibirá como entrada un JSON que contendrá el número máximo de vulnerabilidades y comportamientos desglosados por nivel de riesgo aceptados para la aplicación analizada. En el caso en que estas expectativas no se cumplan, el script devolverá un error. La diferencia entre la ejecución normal y la detallada reside en el nivel de detalle de la salida de la ejecución del script. 

Figura 10: Configuración de mASAPP CI en Jenkins

o Ejecución por nivel de riesgo y ejecución por nivel de riesgo detallada: Se introducirá un número decimal de 0 a 10 que representará el nivel máximo de riesgo aceptado para la aplicación analizada. En caso de que el nivel de riesgo que mASAPP estime para la app supere el que acabamos de definir, obtendremos un error.

• MASAPP_KEY y MASAPP_SECRET: Las credenciales del API de mASAPP se almacenarán en estas variables que recomendamos almacenar de forma segura mediante el tipo de variable “Secret text” que nos ofrece Jenkins.

Figura 11: Configuración de KEY y SECRET

• MAXIMUM: El valor de esta variable dependerá del tipo de ejecución que utilicemos.

o En el caso de la ejecución estándar y la ejecución estándar detallada, esta variable debe ser el JSON mencionado anteriormente. Un ejemplo de este JSON sería el añadido en la siguiente imagen: 

Figura 12: Configuración de variable MAXIMUM

o En el caso de que la ejecución sea por nivel de riesgo, bastará con que el valor de esta variable sea un número decimal entre 0 y 10.

Figura 13: Límite establecido a 5.9

Tras la configuración de las variables habremos configurado un job que tendrá la siguiente pinta en su vista de ejecución:

Figura 14: Job en Jenkins creado

Paso 4: Copia el contenido de masappstage en tu pipeline en la sección de definición de la configuración de tu pipeline tal y como se puede apreciar en la siguiente captura:

Figura 15: Configuración del pipeline

Paso 5: ¡Casi todo listo! Tan solo tendrás que añadir la ruta en la que se encontrará tu aplicación dentro del nodo de Jenkins en el que estás trabajando en el script que copiaste en el Paso 4. Esto lo realizarás sustituyendo “[APPLICATION_PATH]” por el valor de la ruta de la app que quieres analizar.

Paso 6: Para concluir, realiza los arreglos y retoques particulares que pueda necesitar tu nodo, como por ejemplo la instalación de Python o la implementación de notificaciones con los resultados de la ejecución.

Funcionamiento de Jenkins integrado con mASSAP Online usando mASAPP CI

En la imagen puedes ver una notificación de correo electrónico procedente de un job de Jenkins que hemos configurado siguiendo los seis pasos anteriores. En esta ejecución hemos seleccionado la ejecución estándar (no detallada) de mASAPP CI.

Figura 16: Aviso de vulnerabilidades descubiertas.

Aplicar Defensa en Profundidad dentro de los procesos de Fortificación consiste en poner todas las medidas de seguridad que sea posible en todas las fases del ciclo de vida de un sistema. Automatizar las pruebas y descubrir los problemas lo antes posible es una obligación de cualquier arquitecto de software y CISO de una compañía.

Autor: Álvaro López-Gil, Quality & Security Assurance en ElevenPaths & CDCO