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.
Figura 1: mASSAP: Controla en tiempo real la seguridad de las apps móviles
El proyecto se construyó sobre la base de Tacyt [Codename Path5] y recibió el Codename Path6, con el que lo presentamos en el pasado Security Innovation Day 2016 en Madrid, con unos casos de uso muy claros, y aún si tener asignado su nombre.
Figura 2: Presentación de Path6 en el Security Innovation Day 2016
Con el paso del tiempo, el producto se hizo mayor y paso de la fase de alpha, a beta, y de beta a versión final con el nombre de "mASAPP" y pudimos verlo en acción en el Security Day 2017, donde nuestro compañero Víctor Mundilla lo presentó.
Figura 3: ¿Qué fue de Path6? Hola mASAPP
Hoy en día el producto ya cuenta con muchos clientes, y lo contamos tal y como se ve en el siguiente vídeo promocional de mASAP.
Figura 4: Vídeo promocional de mASSAP
Pero queríamos dar un paso más y que los técnicos pudieran entender los detalles del mismo, así que hemos hecho una ElevenPaths Talk especial que acaba de ser publicada, y que os dejo por aquí para que podáis ver en detalle su funcionamiento y sus últimas novedades.
Si estás en el departamento de seguridad o de IT de tu empresa te voy a hacer una pregunta muy sencilla que debes contestarte antes de continuar leyendo este artículo. La pregunta es tan fácil como "¿Sabes cuántas apps móviles tiene tu empresa publicadas?". Probablemente piensas que a priori las conoces todas, pero lo cierto es que si te paras a reflexionar sobre ella verás que es mucho más capciosa la interjección de lo que parece.
Figura 1: Codename "Path 6" ¿Sabes cuántas apps móviles hay en tu empresas y cuál es su seguridad ahora?
En un primer momento puede que hayas pensado en la app principal de tu organización. Es normal, porque es la que todo el mundo conoce. Tal vez luego has pensado en otras que también conoces mientras ibas sumando, pero... ¿realmente estás seguro de que conoces todas y cada una de las que puede que alguien de tu organización haya publicado en algún momento de la historia de los smartphone?
Yaapp: Yet Another App
Lo cierto es que haciendo este mismo ejercicio en empresas de tamaño mediano o grande el resultado es muy revelador. Sucede que algunas veces las apps han sido creadas por departamentos que han decidido tener autonomía propia en la construcción de la app. Sucede que a veces ha sido un empleado utilizando un correo electrónico personal el que ha publicado la app generando hasta un problema de seguridad. Sucede que a veces ha sido un departamento que ha contratado a una agencia y ésta ha usado su propio canal - por ejemplo para hacer una app de un evento -. Sucede que incluso haya apps que no sean tuyas pero que un empleado ha hecho y publicado con su cuenta de correo corporativa, o lo que es peor, sucede que alguien está usando tu marca y tu nombre desde fuera de tu empresa.
Hoy hacer una app le parece una buena idea a casi cualquier persona. La estratega Yaapp (Yet-another-app) está demasiado de moda entre los departamentos de negocio y comunicación. Y esas apps se publican.... y se quedan ahí. El problema es que hay que atacar la seguridad de las aplicaciones móviles en diferentes etapas. Vamos a hacer un pequeño recorrido por la vida de las apps.
Fase 1: ¡¡¡Hemos hecho una app!!
Lo ideal sería que antes de llegar a este bonito momento en que un departamento dice esta frase, los equipos de seguridad hubieran podido incidir en las recomendaciones de desarrollo de código seguro. Que los programadores tuvieran guías de estilo de seguridad, que el código pasara por una verificación en cuatro ojos y que los equipos de QA la batieran con tests de funcionamiento y seguridad antes de que esta app llegara a los territorios de los equipos de IT o de Seguridad.
Figura 2: OASP Top Ten Mobile Risks
Sería conveniente que ninguno de los fallos más comunes catalogados por OWASP Top Ten Mobile Risks en el desarrollo de las aplicaciones móviles estuviera comprobado y requeté comprobado para no tener ningún susto. Que no hubiera almacenamiento de credenciales en local, que no se hubiera hardcodeado ningún usuario y contraseña en el código, que se hubiera revisado la no publicación de certificados, etcétera.
Sea como fuere la suerte de lo que se haya podido hacer internamente con los equipos de desarrollo, antes de publicarse una app debe pasar por una auditoría de seguridad, que llamaremos Auditoría Inicial de Seguridad. Ésta debería ser condición sine qua nom dentro del proceso de publicación y debería ser detonante para detener la publicación de una app o continuar. Por desgracia, visto lo que hemos visto en los artículos que os escribí de Dorking & Pentesting con Tacyt, la mayoría de las apps no pasa por alguna suerte de Auditoría de Seguridad Inicial.
Esto es aún más divertido si tenemos en cuenta que generalmente las apps son normalmente hermanos gemelos, ya que si se hace una app esta debe de estar publicada para Android y para iOS, cuanto menos, lo que hace que cada app de negocio se convierta en dos apps técnicas, lo que obliga a que se deban hacer dos Auditorías de Seguridad Iniciales, una por cada app, ya que aunque hermanas, no son exactamente iguales por la idiosincrasia de cada sistema operativo y los fallos pueden aparecer en una versión y no en la otra.
Figura 4: Conferencia sobre seguridad en apps móviles con Tacyt
Por último, y no por ello baladí, hay que tener presente en el momento de tomar la mala decisión de darle al botón de publicar sin haber pasado por una de estas auditorías, que una vez publicada, está publicada para siempre y al alcance de cualquiera que se la descargue o haya descargado en algún momento del que estuvo publicada. Por lo tanto, si hay alguna de información esta va a permanecer para siempre, así que más te vale estar seguro cuando le des al botón de publicar.
Fase 2: ¡Tenemos una app publicada!
La segunda fase de este proceso es cuando la app está publicada. Y si en la Fase 1 fallan muchas, en esta segunda fallan casi todas. Si eres usuario de alguna de las aplicaciones para móviles en tu smartphone, verás que cada poco tiempo se actualizan las apps más populares. Las “mainstream”. Son aplicaciones que están añadiendo funcionalidades, pero también están corrigiendo fallos de seguridad, actualizando librerías que a su vez han sido actualizadas con nuevas funciones o a las que han aplicado algún parche de seguridad.
Pero además, también se va actualizando el sistema operativo, con nuevas librerías, con nuevas funcionalidades o con parches de seguridad para fallos que se van descubriendo.
Al final, día a día el escenario tecnológico cambia. Las funcionalidades cambian, los fallos de seguridad se van descubriendo y es necesario monitorizar si tu app se ve afectado por alguno de esos cambios. No sólo si deja de funcionar alguna característica de tu app en alguna versión del sistema operativo, si hay cambios en las APIs de backend que usa, si es marcada como maliciosa por un antimalware o si sufre un ataque de BlackASO.
Además de todas esas cosas, que por supuesto hay que hacer, también hay que monitorizar si ahora mismo, si hoy, si mañana, si pasado mañana o al día siguiente, la app se ve afectada por algún fallo de seguridad, para saber si hay que actualizar las librerías sobre la que se construye y hacer una nueva complicación o si es necesario meterle mano al código para hacer un parche y publicar una versión parcheada.
Los fallos de seguridad se van descubriendo día a día. Se publican en conferencias, listas de correo, bases de datos de bugs o directamente en los documentos de “release notes” de las librerías. Y, como no podía ser de otra manera, pueden llegar a afectar al código de tu app, a los servidores de backend que usa tu app o a las librerías con que la que tu app se ha construido. Y debes revisarlo constantemente. De manera persistente.
Fase 3: Shadow Apps ¿Tenemos una app?
Lo más divertido acontece cuando en el día a día del trabajo descubrimos que tenemos más apps de las que pensábamos. Apps que se han colado directamente en los markets y que contienen información de webservices internos, o de servidores de backend, rutas locales a nuestra infraestructura en DMZ y/o hasta credenciales perdidas.
Figura 6: Links en apps con usuarios y contraseñas
Las Shadow Apps pueden ser un auténtico problema en las organizaciones, pues no sólo raramente tienen algo de mantenimiento periódico, sino que en la mayoría de las ocasiones nadie se acuerda ni de que se publicaron. La app de un evento en el año 2014, la app que se hizo para una promoción de marketing, o para un concurso, o para vaya-usted-a-saber-qué (Vease estrategia Yaapp “Yet Another App”).
Figura 7: Lista de apps relacionadas con Movistar & Telefónica
Las apps deben morir cuando dejen de estar mantenidas. Deben hincar la rodilla en tierra cual soldado vencido y ser retiradas al histórico tecnológico de la compañía, pero no deben estar disponibles en los markets al alcance de cualquiera pues pueden suponer un serio riesgo de seguridad, de reputación o de ambas cosas que algunas son ingratas bombas de relojería para los equipos de seguridad.
Codename: Path 6
Con todas estas ideas en mente, yo lleva tiempo detrás de poder crear una herramienta que se aprovechara de la base de datos que crea Tacyt con las apps móviles y la utilizara para ayudar a monitorizar la seguridad de las apps. Y así nació el proyecto – aún sin nombre – pero con Codename: Path 6.
Figura 8: Codename Project: Path 6
Hasta el momento de la creación de Path 6 habíamos utilizado de esta forma Tacyt. Es decir, desde el laboratorio de ElevenPaths se habían buscado todas las apps presentes y pasadas – es decir, las publicadas actualmente y las que se han borrado ya – y se habían analizado los fallos de seguridad para hacer un informe de seguridad puntual o periódico a un cliente.
Figura 9: Dashboard principal para la gestión de la seguridad de las apps
Con Path 6 hemos dado una vuelta a la idea y hemos creado una plataforma que de manera automática permite a una empresa hacer lo siguiente:
- Localizar apps: Se hace mediante un sistema de búsquedas en los diferentes markets y/o usando la base de datos de Tacyt, para encontrar todas las que podrían ser de la organización. Para ello, Path 6 lleva un motor de autodiscovery utilizando reglas creadas automáticamente, en base a términos que va a aprendiendo, a firmas de certificados, a dominios de correo, etcétera. Este mecanismo de autodiscovery le permite al sistema ofrecer posibles apps de la organización, pero también se pueden buscar manualmente apps.
Figura 10: Gestión de reglas de Autodiscovery en Path 6
- Gestión de versiones: Una vez localizadas las apps, el sistema permite gestionar los binarios de las mismas a lo largo del tiempo, teniendo en cuenta que pueden incluso subirse las versiones antes de que vayan a ser subidas al market, ayudando a localizar fallos antes incluso de publicarlas.
- Búsqueda de vulnerabilidades: Desde la plataforma, el sistema busca las vulnerabilidades en las apps en base a un sistema de plugins que se van creando continuamente. Con este sistema, la seguridad e una app se revisa desde tres posibles puntos de vista:
Figura 11: Configuración del análisis de seguridad para una app provisionada
- Análisis Persistente: Como no podía ser de otra forma, la visión de la evolución de la seguridad de forma persistente es nuestra visión de cómo debe gestionarse la seguridad. Cada día se analiza la seguridad de la app con los nuevos plugins, se comprueba si hay nuevas versiones de librerías o si se han publicado nuevos bugs que afectan a las apps. De esta forma el equipo de seguridad puede llevar día a día la evolución de la seguridad de cada app de la organización para decidir la despublicación de una app o la publicación de una nueva versión.
Figura 12: Búsqueda contínua de vulnerabilidades en apps provisionadas
Y esto es lo que tuve el placer de presentar en el último Security Innovation Day 2016. En esta charla puedes ver cómo funciona Path 6 para monitorizar todas las apps.
Figura 13: Presentación de Path 6 en Security Innovation Day 2016
Al final, la seguridad de una aplicación web, de una red de una empresa, o de una aplicación móvil exige gestionar día a día su seguridad. Es un proceso de cíclico de gestionar la evolución de los riesgos para mantener la seguridad dentro de unos parámetros aceptables. Nuestra visión es que la auditoría de las apps móviles debe hacerse de manera persistente diariamente.
Path6 y el MDM de tu empresa
Por supuesto, si has seguido con atención este proceso, lo más seguro es que te hayas dado cuenta de Path6 tiene una funcionalidad única para la gestión de la seguridad de tus dispositivos móviles. La gracia es que este proceso de seguridad que tú haces para tus apps lo puedes hacer para las apps aprobadas en tu plataforma MDM (Mobile Device Management) lo que te ayudaría a dejar de aprobar una app u otra en función de su seguridad.
Basta con que hagas la lista de apps aprobadas en tu MDM y que mantengas la evolución de la seguridad de las mismas para, en el caso de que una de ellas tenga un fallo de seguridad que supere el riesgo aceptable de tu organización – por guardar información sensible de tus empleados de forma insegura o por enviarla sin cifrar o por lo que sea, puedas bloquear su uso. Al final, la información de seguridad continua es algo que te ayuda a tomar mejores decisiones.
Ya han pasado diez días desde que tuvo lugar nuestro Security Innovation Day 2016, y aunque os he ido contando algunas cosas, todavía queda por repasar un largo trecho. Os he hablado de la compra de Shadow, de la inversión en CounterCraft, del lanzamiento de SealSign BioSignature para iPad Pro, o de Latch AntiRansomware, pero aún queda mucho más de lo que os iré hablando poco a poco, como las nuevas alianzas que hemos hecho con BitSigh, Palo Alto Autofocus y Elastica de BlueCoat/Symantec o el nuevo programa de partners de ElevenPaths. Pero ya habrá tiempo.
Figura 1: Ya puedes ver el Security Innovation Day 2016 en YouTube
Mientras tanto, como ya están los vídeos, si no quieres esperar a que te lo vaya desgranando, puedes verte las sesiones y ver algunas de las cosas que os iré contando en los próximos días, como los detalles de Path 6, el funcionamiento del nuevo concepto de Cloud TOTP que hemos metido en Latch, la nueva versión de MetaShield Clean Up Online o el hack de Paper Key que bien podría ser un proyecto ganador para el nuevo Latch Plugin Contest.
Figura 2: Bienvenida al Security Innovation Day
También, como podéis ver en la bienvenida, hay un vídeo que hicimos por los tres años (ya y medio) de vida de ElevenPaths. En la siguiente parte podéis ver la demo completa de Shadow, para saber cómo funciona la herramienta para descubrir quién filtro los documentos de tu organización.
Figura 3: KeyNote por Chema Alonso y Pedro Pablo Pérez
En mi sesión, que es la que viene a continuación, hablo de Paper Key, Latch Cloud TOTP, Latch AntiRansomware, MetaShield Clean-up online y de Path 6, además de que os explicamos algunas de las soluciones que construimos con nuestras tecnologías.
Figura 6: Presentación de soluciones y nuevos productos. Path 6
En la penúltima sesión del día nos centramos en los servicios de ciberseguridad, con las integraciones de Palo Alto Autofocus, BlueCoat Elastica y BitSight dentro de nuestros servicios CyberThreats y SandaS para el gobierno de la seguridad.
Figura 7: Cuatro ojos ven más que dos
La última sesión del día fue para nuestro invitado especial, Hugh Thompson, flamante CTO de Symantec que nos vino a hablar, con mucho humor, de cómo funciona la innovación en seguridad informática.
Figura 8: Innovación en seguridad informática
Y este ha sido el evento completo. Si te ves las charlas, probablemente leas más detalles de ciertas partes en el futuro por este blog. Yo personalmente estoy muy orgulloso de lo que hacen mis compañeros en ElevenPaths, así que espero que disfrutes todas y cada una de las demos y vídeos que preparamos para este cuarto Security Innovation Day. Nosotros ya estamos trabajando para el siguiente.
Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso 3DAIS
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
