Nuestros amigos de ESET han publicado una investigación en la que han alertado al equipo de seguridad de Google Play de la existencia de una app, muy instalado por los usuarios, que se ha vuelto maliciosa. Es decir, una Gremlin App & Gremlin Botnet que ha pasado de ser un Gizmo cariñoso y amigable a convertirse en MogWai. En este caso la app se llama iRecorder.
Esta app, que es una herramienta que permite grabar la pantalla de los sistemas operativos Android es muy popular, y tenía una valoración en Google Play de 4.2. Durante mucho tiempo no ha tenido ninguna función maliciosa, pero, como sucede con el negocio de las Gremlin Apps & Gremlin Botnets, alguien ha decidido convertirla en una botnet para espiar a los usuarios.
Muchos de los detalles qué descubrimos con este estudio los plasmó nuestro compañero en el libro de Malware en Android: Discovering, Reversing & Fonrensics que os recomiendo encarecidamente que 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.
El mundo de las Gremlin Apps y las Gremlin Botnets es algo con lo que llevamos viviendo más de una década, y por eso, son tan importantes los equipos de seguridad de Google Play & App Store y los procesos de revisión. Que una app lleve siendo buena mucho tiempo no quiera decir que lo vaya a ser siempre, y cualquier día cambia de dueño y....
El contenido en español lo tenéis en el artículo que publiqué hace algún tiempo, por si queréis seguir el hilo de la charla leyéndolo: "Gremlin Apps y Gremlin Botnets". Además, esta charla, que inicialmente di en la RootedCON de hace algún tiempo, la he dado también en Español actualizada hace no mucho, pero aún no la tengo. Cuando la tenga, os la publicaré, por supuesto.
Os dejo subidas a Slideshare el archivo PDF con las diapositivas que utilicé durante la charla, que aunque no tiene los vídeos incluidos, te puede permitir seguir mejor la charla a tu ritmo y manera. Aquí las tienes.
Pues nada, queda por tanto inaugurado el año 2022 en "El lado del mal", lo que hace que sea el año 17 de escritura en este blog, que además tiene su aniversario en unos días, a mediados de mes, donde habrá mucho que celebrar.
Una de las cosas de las que he hablado muchas veces en el mundo de las apps para iOS y Android, es el uso de permisos de forma oportunista. Es decir, si una app pide permiso para acceder al carrete de las fotos, le tienes que dar acceso a todo el carrete sí o sí. Eso quiere decir que si una app te convence de que necesita acceso al carrete y tú eres capaz de comprender que lo necesita y se lo das, le tienes que dar permiso a toda las fotos.
Figura 1: iOS 14 en iPhone y la granularidad de los permisos a tus fotos para que no te roben las más "privadas": Casi bien, pero le falta un poquito
Pero, ¿qué pasa si esa app se convierte en una Germlin App y hace un uso oportunista de ese permiso? De esto hablé en el artículo - y la charla - de las Gremlin Botnets, donde os contaba como en el mercado de las apps en venta que se usan para ciberespionaje lo que vale es el número de usuarios que tiene, qué tipo de usuarios tiene, y cuáles son los permisos de esa app.
Figura 2: Gremlin Botnets "El club de los poetas muertos"
Si una app para hacer retoques de belleza en fotos tiene acceso a tu carrete de fotos, tiene acceso a todas tus fotos. Todas. Y si se vuelve maliciosa, se podrá llevar todas tus fotos. Hasta las ocultas. Hasta las de sexting. Es más, podría descargar un algoritmo que detecte donde haya gente desnuda en las fotos y llevarse solo aquellas en las que estés sin ropa.
Solo necesita hacer uso de ese permiso que le diste de acceso al carrete de fotos. Con este sistema de permisos, garantizar eso de "lo que pasa en tu iPhone se queda en tu iPhone" no es nada sencillo, y es conocido por la mayoría de apps que se ha utilizado para hackear a los usuarios de iOS (iPhone & iPad) espiándoles lo que hacen en sus dispositivos. Uso de permisos oportunistas.
Apple, en la última versión de iOS 14 ha seguido metiendo opciones de privacidad, como los iconos de acceso a la cámara y micrófono, y también ha hecho más granulares los permisos de acceso al carrete de fotos, y está bien, porque ahora puedes seleccionar a qué fotos le das acceso a una app, limitando el acceso al resto de ellas. Esto, por supuesto, reduce la superficie de exposición y es bueno. Además, por defecto le ha quitado el acceso a todas las apps al carrete, así que conscientemente debes volver a dárselo tú, pero le ha faltado rematar.
Figura 5: Se puede dar acceso selectivo a fotos en el carrete
En concreto, en el tema de las fotos, hay muchas apps que se usan para retocar fotos - aunque sean maliciosas como el caso que ponía yo de ejemplo de apps de filtros de belleza que pudieran ser utilizadas en una Gremlin Botnet - así que el usuario, antes de entrar en la app debe volver a configurar el permiso para que la app tenga posibilidad de acceder a la foto que quiere retocar en ese momento.
Figura 6: Se puede entrar en un álbum, pero solo para seleccionar fotos
Esto no es muy usable, y estoy convencido de que la mayoría de las personas acabará por darle permiso a todo el carrete a las apps, lo que hará que parezca que el permiso granular no es algo que necesite la gente, cuando es que está mal implementado en términos de UX. Y eso es lo que hay que arreglar. Creo que Apple debería añadir la opción de permitir dar acceso a un álbum cuando se hace la selección granular de fotografías, algo que no está ahora.
De esta forma, cuando alguien configura el perfil granular para su Instagram, su app de filtros de belleza, su WhatsApp, o su lo que sea, puede darle acceso al álbum y catalogar cada foto en uno de ellos. Así, para el usuario será más fácil gestionar la granularidad de accesos y no acabará - como van a hacer la mayoría de usuarios - por darle permiso a todo el carrete otra vez a todas las apps. Veremos si hay suerte en el futuro.
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.
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.
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 cloudIaaS 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.
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.
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.
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.
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.
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.
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
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.
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 ServidoresProxy 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 8cuentas "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.
Con lo visto hasta el momento, ya tenemos todo lo necesario para hacer una demostración de cómo puede funcionar un Gremlin Botnet. Nos vamos a centrar en un caso concreto, creando una app para Android que utilice los diferentes permisos posibles para sacar información de quién está utilizando este dispositivo, usando el número de teléfono, la cuenta Twitter o la cuenta de correo electrónico del dispositivo como identificador principal.
Figura 37: Gremlin Botnets: El club de los poetas muertos (4 de 6)
Como vamos a ver, es un ejemplo de cómo usar un "Crecimiento Orgánico", es decir, mediante la creación de una app propia que va a ser lo más silenciosa posible en todo el proceso, por lo que usaremos esteganografía y cifrado para enviar los comandos y recibir los datos entre la Gremlin App y la el C&C de la Botnet.
Quiz App
El gancho que hemos elegido es un pequeño juego. Los juegos son unas de las apps más descargadas por padres despreocupados que buscan entretenimiento gratis para sus pequeños, permitiendo que estas apps soliciten muchos permisos y se lleven sus datos - muchos datos - para pagar el uso de dichos servicios de entretenimiento. Nosotros vamos a hacer una Gremlin App de las que para descubrir habrá que hacer un buen reversing, como se explica en el libro de Malware en Android: Discovering, Reversing & Forensic.
En nuestro caso hemos elegido un sencillo juego de preguntas para solicitar al usuario que nos diga qué le gusta más. En cada petición cargamos dos imágenes de cosas similares para hacerle al usuario decidir quién gana. Bastante sencillo de entender.
Figura 39: Se muestran dos imágenes y se debe escoger una. !Siempre Cálico Electrónico!
Por el camino, tenemos una imagen - el banner de Quiz App - que también es una imagen y vamos a ir recargando cada cierto tiempo. Pero es en esta imagen donde vamos a elegir qué app es la que queremos que se vuelva maliciosa. Es decir, vamos a seleccionar qué app se va a volver una GremlinApp.
Como podéis ver, en esta PoC, hemos puesto tres tipos de datos que buscamos poder sacar del dispositivo, como son el número de teléfono, la dirección de correo electrónico o al cuenta Twitter. No necesitamos saber todo, se trata de que activemos la app por medio de un identificador que sí que hayamos sido capaces de extraer. Esta info la vamos a ver en el panel de control de la lista de dispositivos en nuestra Gremlin Botnet.
Figura 40: Desde el C&C marcamos una Gremlin App a activar
Por supuesto, dentro de nuestra Gremlin Botnet el resto de las apps continuará teniendo un comportamiento normal y el juego seguirá siendo un juego que no hace nada mal. Como se puede ver en la imagen siguiente, para indicar qué app se debe volver maliciosa usamos esteganografía que metemos dentro de la imagen del banner. En este servicio se puede ver el código que está inyectado en cada petición.
Figura 41: Comandos ocultos por esteganografía en la imagen
Como se puede apreciar en la imagen anterior hay tres comandos que son "Contacts", "Location" y "Photos" para decidir qué queremos que nos envíe del dispositivo en que se encuentra instalada la Gremlin App. Para ello, tenemos en el panel de control la lista de dispositivos con sus identificadores - a partir de los cuales podremos hacer todo el proceso de OSINT explicado anteriormente. Por ejemplo, ene esta demo tenemos estos dos terminales infectados por nuestra Gremlin App durmiente en modo Zombie.
Figura 42: C&C de nuestra Gremlin Botnet con la lista de dispositivos con nuestra Gremlin App
Elegido uno de ellos, podemos enviarle un comando concreto, como en este caso que hemos solicitado de este dispositivo la lista de contactos dados de alta. Estos se irán enviando en cada iteración con la Gremlin App que se ha vuelto maliciosa usando el intercambio de imágenes y la petición de las misma con parámetros GET que realmente llevan la información robada del dispositivo.
Figura 43: Solicitando la lista de contactos de este dispositivo
Este comando inyectará en la imagen de cabecera de nuestro juego el número de teléfono (o la dirección de e-mail que también lo tenemos) en la Gremlin Botnet, y todas las apps mirarán en esa imagen, para extraer los datos con esteganografía y así saber si le toca a cada una volverse maliciosa o no. En este ejemplo hemos activado uno de los dos dispositivos para que nos de la lista de contactos, y como se puede ver, el terminal afectado muestra un menaje que hemos puesto para que se entienda mejor la demo. Es decir, hemos activado ese dispositivo. Tan sencillo como esto.
Figura 44: Gremlin App activada para que envíe los contactos
Lo que iremos recibiendo en el servidor, poco a poco, será la lista de contactos que se encuentran en ese dispositivo. Para ello se aprovechará cada petición de una nueva imagen para ir enviando al servidor los datos en parámetros GET cifrados como si fueran parte de la petición de la imagen. Un sencillo truco para no levantar muchas sospechas en un posible análisis de tráfico de la red.
Figura 45: Lista de contactos en el C&C recibidos por la Gremlin App
Y lo mismo podremos hacer, activando otro dispositivo, en este caso para solicitar la lista de fotografías en el carrete. El usuario confió en esta app para acceder al carrete pensando que era fundamental para el funcionamiento de la app - como así decimos nosotros - y por lo tanto, podremos activar este comando remotamente en otra Gremlin App.
Figura 46: Activando el robo de fotos del carrete del disositivo
En este caos vemos que se vuelve una Gremlin App la otra instalación de nuestra app, ya que hemos cambiado el target a un nuevo identificador, que ha sido incluido en el banner de cabecera junto con un nuevo comando. Así, se vuelve maliciosa la otra app de nuestra Gremlin Botnet.
Figura 47: Ahora activamos otra Gremlin App
Y lo que iremos recibiendo ahora en nuestro panel de control será ahora la lista de fotografías que tenemos en el carrete de ese dispositivo controlado por nuestra Gremlin App. Así de sencillo, y así de peligroso.
Figura 48: Todas las fotos de ese dispositivo en nuestro C&C
Para que podáis ver la demo completa, os dejamos este vídeo que hemos preparado que realiza esta mismo demostración en poco más de dos minutos para que podáis ver lo fácil y rápido que es activar y desactivar una Gremlin App en una Gremlin Botnet.
Figura 49: Gremlin Botnet: Activando Gremlin Apps
Como podéis ver, cualquier app que instales en tu dispositivo puede hacer un uso malicioso de los permisos en modo APT, seleccionando el objetivo en base a la información que tiene de él. Así que ten mucho cuidado con lo que instalas.
No se vayan todavía, aún hay más
En las dos próximas partes vamos a ver como, apps que fueron pensadas para nunca ser maliciosas pueden también ser maliciosas si caen en malas manos con malas artes. Nos vemos en la siguiente parte.
Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
