Codename “Path6”: ¿Sabes cuántas apps móviles hay en tu empresa y cuál es su seguridad ahora?

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.

Figura 3: Credenciales LDAP hardcodeadas en una app para Android

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.

Figura 5: Conferencia de Dorking & Pentesting con Tacyt

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:

o Haciendo un análisis estático del código de la app
o Haciendo un análisis de la app de forma dinámica
o Analizando la seguridad del backend con nuestros plugins de Faast

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.

Saludos Malignos!