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

CyberMonday en @0xWord y en @ElevenPaths #CiberLunes #CyberMonday

Desde hace algunos años existe el CyberMonday, o el CiberLunes, donde se da una segunda oportunidad vía servicios de e-commerce al famoso BlackFriday. Y nosotros nos hemos sumado desde ElevenPaths y desde 0xWord a la edición de este año.

Figura 1: CyberMonday en 0xWord y en ElevenPaths

En 0xWord venimos sumándonos a esta iniciativa los últimos años, y vamos a tener un descuento del 10% en todos los productos. Es decir, en los Vídeo-Books, en los pósters, cómics, y pegatinas de 0xWord Cómics, en los packs oferta, en el peluche y pendrive de Cálico Electrónico y en todos los libros tanto de lectura en 0xWord Pocket como de 0xWord que forman el Máster de Seguridad.

Hoy es el CyberMonday en 0xWord y tienes un 10% de descuento en todos los productos con el código CYBERMONDAY2018 https://t.co/SOoEwx4fmy pic.twitter.com/M1CIVg7rsh

— 0xWORD (@0xWORD) 26 de noviembre de 2018

Para obtener este descuento debes utilizar el código CYBERMONDAY2018 cuando vayas a finalizar la compra, y automáticamente recibirás un 10% de descuento que podrás utilizar tanto para entrega en tienda como para envío por correo.

Figura3: Master en Ciberseguridad con 0xWord

En ElevenPaths hemos puesto dos productos Online al 50% de su valor, para que puedas disfrutar de ellos a un precio más que asequible. Son mASAPP Online y Faast for WordPress

- mASAPP Online: Este producto permite realizar un análisis de aplicaciones móviles para prevenir ataques de actores maliciosos. De este modo, avisa de comportamientos que realiza la app que pudieran afectar a la reputación del usuario. De forma muy sencilla, se sube un fichero a la aplicación para que esta lo analice y acto seguido, obtienes recomendaciones de medidas correctivas.

Figura 4: mASAPP Online

- Faast for WordPress: WordPress se ha convertido en el CMS de más rápido crecimiento en todo el mundo. Por ello, es una de las plataformas más atacadas, divulgándose sus errores públicamente. Además, el software y la infraestructura utilizada por un sitio WordPress también están sujetos a ataques. Faast for WordPress es una forma simple y cómoda pero efectiva de detectar todos estos errores que son difíciles de rastrear por un administrador.

Figura 5: Faast For WordPress

Estas ofertas solo duran 24 horas y para contratarlos solo debes registrarte en la página de las herramientas mASAPP Online y Faast for WordPress, y suscríbete al producto. Te dejamos aquí los links para que te sea más sencilla la suscripción:

- Contratar mASAPP Online en CyberMonday 

- Contratar Faast For WordPress en CyberMonday

Por supuesto, si deseas contratar el servicio de Faast for WordPress, el complemento ideal es el libro de Máxima Seguridad en WordPress de 0xWord, para que tu CMS esté lo más seguro posible contra los ataques online.

Saludos Malignos!

GMTCheck Online & Rock Appround the clock de @ElevenPaths

En el año 2014, nuestros compañeros del Laboratorio de ElevenPaths publicaron una herramienta que se llamaba GMTCheck. Esta herramienta se construyó para completar la información que la Plataforma de Ciberinteligencia en aplicaciones móviles Tacyt daba a los investigadores fuera mayor. 

Figura 1: GMTCheck Online & Rock Appround the clock

Se trataba de un pequeño "leak" de información en los metadatos de los ficheros de un .apk para Android que permitía saber (y permite) saber la franja horaria en la que se compiló una aplicación concreta.

Figura 2: Descarga GmtCheck de la web de ElevenPaths

En un estudio de malware, esta información puede ser vital para los procesos de atribución, ya que pueden ayudar a conocer las familias, los orígenes del mismo, y descubrir nuevas amenazas aún ocultas por patrones similares, y nosotros lo utilizamos para ayudar a los departamentos de seguridad a tener una visión clara de todas las apps que aprueban en sus listas MDM, por lo que está incluido dentro las funcionalidades del servicio mASAPP Online que monitoriza constantemente todas las apps aprobadas en una empresa y que hemos lanzado recientemente. 

Figura 3: mASAPP Online

Durante este verano, nuestros compañeros descubrieron otro nuevo leak, en este caso por culpa de un bug de la herramienta aapt que se utiliza para empaquetar aplicaciones .apk. Dicha herramienta utiliza una función para calcular el offset de la zona horaria, pero, por un error de programación nunca se inicializa correctamente, por lo que siempre es cero, tal y como se explicó en el artículo del blog de ElevenPaths.

Figura 4: Rock appround the clock 

Con estas dos técnicas, más alguna más utilizada en la investigación del origen del famoso WannaCry, nuestros compañeros hicieron un paper que se llamo "Rock Appround the Clock: Tracking Android malware developers by "AAPT" time zone disclosure bug ... and other hour related tricks" y que llevaron a la DefCON de este año. Aquí un vídeo de un ejemplo de cómo funciona el bug de aapt que se presentó en DefCon.

Figura 5: PoC del bug de AAPT

Ahora, además de tener el paper publicado con toda la información, desde el Laboratorio de ElevenPaths en Málaga y Buenos Aires, han puesto una pequeña web experimental para ayudarte a investigar todos estos bugs o leaks de zona horaria en Applets .Jar o Apps .apk, bajo el nombre de GMTCheck Online.

Figura 6: GMT Check Online de ElevenPaths

Se trata de implementar de forma sencilla todos los trucos que hemos ido utilizando en nuestras investigaciones, y que tan buen resultado han dado a la hora de catalogar la atribución de las familias de malware que vamos descubriendo cada poco en el mundo Android, y que fueron la base de la explicación del libro de "Malware en Android: Discovering, Forensics and Reversing" que publicamos en 0xWord.

Figura 7: Malware en Android: Discovering, Forensics and Reversing

Ese libro fue escrito por Miguel Ángel García del Moral y en el índice podéis ver muchas de las técnicas que usamos en la construcción de estas herramientas que hoy os cuento. Este es uno de los libros que más me enseñó que no conocía y que más disfruté leyendo.

Saludos Malignos!

La app que se volverá maliciosa: Android Apps y los "Permisos declarados nunca utilizados"

El año pasado, en le Security Innovation Day 2016 de Madrid, hablamos por primera vez de Codename: Path 6, la herramienta que habíamos creado para monitorizar las vulnerabilidades en las apps de sistemas iOS y Android de manera continua. El producto continúo creciendo y se acabó convirtiendo en lo que hoy denominamos como mASAPP.

Figura 1: La app que se volverá maliciosa

La idea de funcionamiento es muy sencilla. Se trata de que una organización pueda monitorizar cómo evolucionan las vulnerabilidades de las apps en las que está interesada la empresa a lo largo del tiempo, para descubrir cuando el riesgo de una de estas apps no es aceptable. 

Figura 2: Presentación de Codename: Path6

Una organización puede estar interesada en conocer la seguridad a lo largo del tiempo - de manera persistente - de una app por varios motivos:

1.- Para conocer si las apps que se han publicado con el nombre de la empresa tienen vulnerabilidaes no aceptables y hay que retirarlas y/o actualizarlas. 

2.- Para conocer si las apps que se tienen aprobadas en un MDM no tienen vulnerabililidades lo suficientemente peligrosas como para prohibir su uso dentro de la organización. 

3.- Para que una organización pueda monitorizar la seguridad de apps de terceros que utilizan su marca. 

4.- Para que una empresa que desarrolla apps para terceras empresas, pueda saber si las apps de sus clientes están dentro de un riesgo aceptable.

Para ello, lo que hace el equipo de investigadores de ElevenPaths es mantener una base de datos de vulnerabilidades y debilidades en aplicaciones web que se actualiza constantemente. Así, las apps móviles que están dentro del Big Data de mASAPP son analizadas cada vez que hay una actualización de versión en la app, o cada vez que es actualizada la Knowlege Base. Esto lleva a que el trabajo de monitorizar las apps de tu empresa, o las apps aprobadas en tu MDM sea tan sencillo como seleccionarlas en mASAPP y listo.

Figura 3: Demo de funcionamiento de mASAPP

Entre la lista de vulnerabilidades de la Knowledge Base que se buscan, hay una concreta que yo he localizado en alguna de las apps. Se trata de los "Permisos declarados nunca utilizados", y tienen un riesgo para la seguridad de una organización, que merece la pena tener en cuenta.

La app que se volverá maliciosa... en el futuro

Imaginemos un escenario donde una app con ninguna vulnerabilidad es aprobada por el administrador del sistema MDM (Mobile Device Management). Esta app tienen permisos declarados no utilizados en ella que le permitirían hacer muchas más cosas de las que actualmente está realizando la app. 

Figura 4: Vulnerabilidades en una app detectadas por mASAPP

Mañana esta app es vendida en un market de aplicaciones, como en SelltheApps con el certificado digital para poder firmar actualizaciones de la misma. Al no haber cambio de permisos, la actualización de la app sería automática en los dispositivos Android que así lo tengan configurado.

Figura 5: Apps en venta en SelltheApps

Esto conlleva a que una app que hoy en día no utiliza permisos pueda convertirse en una app con mucha más potencialidad en el futuro, y alguien que compre dicha app podrá hacer una actualización automática de la misma hacia una Gremlin App que robe datos, extraiga mucha más información o similares.

Figura 6: Permisos no utilizados pero declarados detectados en una app con mASAPP

Normalmente estos permisos declarados no utilizados pueden provenir del uso de SDKs de terceros dentro de la app que por defecto, para el uso de todas sus funciones, solicitan una lista completa de permisos. Después, el desarrollador de la app decide utilizar menos. Sin embargo, también puede significar un desarrollador de apps que está buscando una venta de la misma en el futuro al mejor postor, y como sabe que cuantos más permisos tenga, más vale, está decidiendo pedirlos ya por delante.

Es por eso que nosotros en mASAPP, entre la gran cantidad de vulnerabilidades que buscamos, hacemos las dos comprobaciones importantes para este caso con todas las apps:

1.- Saber si la app solicita permisos que no utiliza. 

2.- Saber si la app está en venta en algún sitio de venta de aplicaciones comercial... o "underground".

Así, los administradores pueden tomar decisiones más informadas sobre qué apps deben aprobar y cuáles no, en la lista de apps del MDM.

Saludos Malignos!