Latch Cloud TOTP versus Google Authenticator

Cuando hablamos de un Segundo Factor de Autenticación, los tokens TOTP (Time One-Time Password) son unos de los más populares. Servicios tan populares como Google, Microsoft, Dropbox o Facebook tienen la posibilidad de configurar una protección extra de la cuenta añadiendo una verificación del código TOTP que el usuario tiene configurado. Hoy os quiero hablar de Latch Cloud TOTP que es otra de las novedades de las que hablamos en el pasado Security Innovation Day 2016 y de cuáles son los detalles y el pensamiento que nos ha llevado a crearlo. Que nadie piense que esto es un "combate" ni nada parecido a ver qué solución es mejor, sino solo una explicación de cuáles son los detalles que de Google Authenticator que nos hicieron crear Latch Cloud TOTP.

Figura 1: Latch Cloud TOTP vs. Google Authenticator

La idea del TOTP es tan sencilla como que un algoritmo, con la misma semilla de parametrización, genera en el lado del servidor y en el lado del cliente un código dependiente del tiempo. Es decir, en el lado del servidor y en el lado del cliente, cada cierto tiempo, se genera el mismo número - el mismo token -. Cuando un usuario va a realizar un proceso de login, primero debe proveer correctamente el usuario y la contraseña, y después de que se verifique que esta es correcta, se debe proporcionar el valor TOTP correcto.

Figura 2: Demo de Latch Cloud TOTP en Dropbox con Latch para iPhone y Lath para Apple Watch

La herramienta más popular para gestionar los tokens TOTP es Google Authenticator, y es válida para usar en servicios como Google, Microsoft, Dropbox o Facebook. Basta con configurar esta protección en tu cuenta y utilizar Google Authenticator para capturar el código QR que transmite la semilla al algoritmo TOTP que generará el código TOTP constantemente.

TOTP en Google Authenticator

Durante mucho tiempo hemos estado jugando con los códigos TOTP de Google Authenticator, y hemos estado haciendo muchas pruebas que paso a contaros, porque creo que son relevantes para entender por qué decidimos hacer un Cloud TOTP en Latch.

1) No garantiza un único dispositivo: Cuando estás configurando un código TOTP en el cliente de Google Authenticator u otro similar, realmente al servidor no se le avisa de en cuantas apps se ha capturado la semilla. Es decir, podrías generar en la misma app de Google Authenticator 4 entradas con la misma semilla y al mismo tiempo copiar en cuatro dispositivos con Google Authenticator la misma semilla, y al mismo tiempo en otras apps. 

2) La semilla se podía robar del backup: Antiguamente, cuando se hacía un backup del sistema operativo, de este se podían sacar los ficheros de las semillas y conseguir regenerar el algoritmo correcto para tener los TOTP en cualquier otro dispositivo. Esto tenía un lado positivo y un lado negativo. 

El lado positivo es que podrías migrar de tu iPhone 6 a tu iPhone 6S todo un backup, y las entradas de Google Authenticator seguían intactas, lo que era una ventaja si se te había perdido el terminal o te lo habían robado, por lo que si tenías el backup podrías recuperar tu Google Authenticator con todas las entradas. 

Figura 3: Robar semillas TOTP de bakup de iOS

El lado negativo es que alguien podría extraer del backup tus ficheros de Google Authenticator y recrear en una app controlada por él tus valores y tener los TOTPs de todas tus cuentas. Además, para que este ataque fuera un poco más sencillo, se unen dos debilidades que pueden aprovecharse que os describo en los puntos 3 y 4.

3) En Google Authenticator se indica el usuario: En cualquiera de las entradas de los TOTP se puede leer con claridad la cuenta de correo a la que está asociada esa entrada TOTP, lo que pone bastante fácil saber a quién hay que robarle la contraseña. De hecho, lo más fácil era hacerse con el backup de Google Authenticator, ver cuáles eran las semillas de los algoritmos TOTP que se habían robado, y hacerles un ataque de phishing a esos para robarles el último factor que hacía falta - la password -.

Figura 4: En cualquier Google Authenticator se ven los tokens TOTP y los usuarios

4) En Google no implementan correctamente las alertas TOTP: Como ya he dicho en otras ocasiones, si te roban la password en Google y entran en tu cuenta, saltaría la verificación del token TOTP, pero no queda ninguna alerta de seguridad en el log si no se intenta poner ningún token, por lo que al atacante no se le detecta a la primera. En el caso de Microsoft, esto se implementa mejor.

Figura 5: En el log de Google no queda que se ha puesto correctamente la password
y no se ha introducido ningún token TOTP durante la verificación en dos pasos.

5) Ahora no migra de un terminal a otro: Para fortificar las semillas, en Google Authenticator ahora, estas se cifran en el keychain con una clave del dispositivo, por lo que es posible recuperar las semillas si y solo si es en el mismo dispositivo. Esto es un problema serio si has perdido el terminal, porque entonces solo te salvarán las Recovery Keys que se obtienen cuando se configura la protección TOTP o si tienes también puesto el número de teléfono, por el SMS (lo que vuelve a convertir el SMS en el primer factor de autenticación). Dependiendo del servicio, se podrían utilizar otros mecanismos como en el caso de Google que se permiten las llaves, los click-OK o los códigos impresos, pero no es lo habitual para todos los servicios protegidos con servicios TOTP, ni además son muy populares en su uso.

6) No protección local de Google Authenticator: En Google Authenticator, si alguien tiene acceso al terminal y abre la app, puede ver los valores de los tokens y a qué cuentas pertenecen porque no hay forma de ponerle una password a nivel de aplicación, tal y como se ve en la Figura 4.

Cloud TOTP en Latch

Sabiendo cómo funciona bien Google Authenticator, decidimos hacer una implementación que funcionara de manera distinta usando Latch a la que hemos llamado Cloud TOTP, que tiene las siguientes características:

1) Asociada a tu cuenta Latch: Cuando se pone un token TOTP en Google Authenticator, este se almacena en uno o varios dispositivos y - ahora - no puede salir de ahí, pero al servidor no se le garantiza ni que se haya puesto en un terminal concreto ni que se haya puesto solo en uno. En este caso, cambiamos el paradigma y lo ponemos en una cuenta de Latch que puede ser abierta en cualquier dispositivo móvil siempre que tengas tu cuenta de Latch (no asociada a tu cuenta protegida con el token TOTP)

2) Sin identificar nombre de cuenta asociada: Aunque en la primera versión utilizamos el mismo funcionamiento de Google Authenticator y mostrabamos la cuenta de usuario, hemos decidido que se pueda renombrar durante el proceso de configuración y después, para que en lugar de poner micuenta@google.com pueda poner algo genérico como "Mi cuenta de Google" o "Mi cuenta de Dropbox", con lo que se disasocia en Latch Cloud TOTP el valor del token del valor de la cuenta y del valor de la contraseña.

Figura 6: El token no se muestra hasta que no se solicita. Queda en el log

3) Con log de acceso al código: Hemos decidido que en Latch Cloud TOTP, el valor del token no se muestre nada más que durante un instante. Para eso el token TOTP de cualquier semilla estará oculto y se deberá solicitar su muestra. Esto implica que se generará una entrada en el log de Latch que el usuario podrá consultar en el futuro para saber si desde esa app, en un momento concreto, se mostró o no se mostró el código TOTP. No evita las malas implementaciones del servidor, pero sí que permite guardar información que podría ser útil en un posible análisis de logs cruzado con los datos del servidor.

4) Protección de acceso local a Latch: Además de que el código TOTP de una cuenta no se muestra por defecto y debe solicitarse manualemente, dejando un rastro en el log, la app de Latch tiene dos protecciones: Una primera la autenticación contra el servidor, y una segunda la autenticación a nivel de app (integrada con Touch ID en iPhone e iOS). Esto hace que, aunque se tenga el terminal desbloqueado en un descuido, no se pueda acceder a ella sin poner la password o pasar una autenticación biométrica vía Touch ID.

Figura 7: La app de Latch se protege en local con autenticación y por Touch ID en iOS

Con esta aproximación de Latch Cloud TOTP lo que hemos buscado es cubrir un hueco en el uso de tokens TOTP. Dotamos al sistema de una mayor flexibilidad al permitir que los tokens se puedan recuperar desde cualquier dispositivo, y añadimos mayores opciones de seguridad en aspectos como el acceso local vía descuido, la asociación de token TOTP a nombre de cuenta o el control de los tokens TOTP que se entregan, ya que no es un proceso continuo sino discreto bajo demanda que deja rastro en el log.

Figura 8: Cloud TOTP y Latches en la misma app de seguridad

Ahora está disponible en la nueva versión de Latch para Android, y en breve estará disponible en la nueva versión de Latch para iOS. Poco a poco os iré contando por aquí como sacarle provecho a todas las características de este Cloud TOTP en diferentes servicios y entornos. Y lo mejor es que puedes tener en una sola app tanto tus tokens TOTP como tus cuentas protegidas por Latch.

Saludos Malignos!

Documental "El cazador de cerebros: La vida después del móvil"

Hoy domingo, víspera de la Noche de Halloween, os voy a dejar algo fácil de procesar. Se trata del programa "El Cazador de Cerebros: Más allá del móvil", que emitieron la semana pasada en La 2. Se trata de un programa que intenta hablar sobre el smartphone de hoy en día y cómo será el smartphone del futuro.

Figura 1: Documental "El cazador de cerebros: La vida después del móvil"

En el programa participamos Nuria Oliver, Lluis Torner, Frank Hoppens, Iñaki Berenger y yo. El objetivo es charlar sobre qué es el smartphone hoy en día y qué podemos esperar en un futuro cercano, tratándose temas de usabilidad, de seguridad, de investigación científica como el grafeno, o sus utilidades.

  Figura 2:El Cazador de cerebros - La vida después del móvil

El programa está presentado por Pere Estupinyà y mantiene un estilo narrativo muy fácil de llevar y entender haciendo uso de sus habilidades con las letras, así que seguro que os entretiene la media hora que dura. 

Saludos Malignos!

Voluntechies: Colabora para "curar" niños con Realidad Virtual

Como muchos de vosotros que me estáis leyendo ahora, tal vez con el café del sábado, desde la cama o en alguna fase del proceso de asearse, la vida me ha regalado más de lo que podía pedir. Dos niñas preciosas que me manipulan y mangonean todo lo que quieren, a las que he bautizado como Hacker y Survivor. Si eres de los que eres padre o madre, ya sabes que vienen con poderes mágicos de serie. Basta con que te sonrían y el cansancio desaparece o que abran los ojos mucho cuando se sorprenden con algo para que el mundo se llene de colores y recibas una descarga de adrenalina por todo el cuerpo.

Figura 1:VolunTechies. Colabora para "curar" nivños con Realidad Virtual

Son terribles. Esos bichos pequeñajos te ownean y te ponen bajo un ransomware tu corazón. Sus alegrías multiplican tu felicidad por cien y sus penas te hacen sufrir infinito. Yo aún recuerdo el momento en que me di cuenta que había dejado de ser el root de mi alma cuando mi Hacker me dijo con cuatro años “Papi, eres mi favorito” al tiempo que me acariciaba la barba. Pwned! Como os sucede a muchos de vosotros, hackers. Que aunque tengáis el firewall up & running, luego coincidimos en las tiendas comprando disfraces de Elsa & Anna, toallas de Minnie, tazas de Peppa Pig o Mickey, y encargando muñecos de Chase por Amazon para que nuestr@s padawans sonrían con maldad cuando los reciben.

Hacker me roba el gorro y se lo pone mientras grita, y Survivor me rompe todas las cosas y me “obliga” a estar dibujando monstruos todo el día para colorearlos después. Me configuran las tareas de mi cron. Me buscan por mis papeles los dibujos de No Lusers que tenga hechos para poder “pintar papás”. No hay una folder en mi vida donde no sean System. Bueno, ya sabes como es si eres papá o mamá o tienes la suerte de tener uno de estos mini humanos rondando alrededor de tu vida. No hace falta que te lo cuente mucho, porque entonces te lo imaginas, o lo vives igual que yo.

Como se me dan bien estos bichos – hacer lo que ellos manden, quiero decir - y me conozco las canciones y los personajes de moda entre los seres de estas edades, en el Día Internacional del Voluntariado en Telefónica, decidí apuntarme a estar una tarde jugando con niñ@s que se encontraban en casas de acogida…. Y fue genial.

Voluntechies: Voluntarios Tecnológicos

Solo fue un ratito de mi tiempo, jugando con ellos y ellas a los bolos. Por mera práctica - al final de lo que más tengo experiencia es con las féminas de estas edades - solo tuve que dejar que me mangonearan unas horas las niñas de mi equipo, que se subieran a burro encima mía, que me tiraran un poco del pelo, ayudarles a empujar la bola por el tobogán o subiéndoles a ver si había pájaros en el cielo. Solo invertir un poco de velocidad dividido por espacio que me hizo más feliz a mí que a todos ellos, sin duda.

El número de personas que se animó at participar en esta iniciativa fue alto, así que había compañeros que también estaban por allí. Compis de otras áreas que también compartieron risas y energía con los niños. Fue allí donde conocí otra iniciativa de mano de uno de ellos que tiene que ver con el voluntariado y la tecnología, de la que quiero hablaros hoy. Se llama Voluntechies.

Figura 2: Proyecto Voluntechies

Voluntechies es una asociación de voluntarios que apuesta por introducir las nuevas tecnologías para ayudar a los niños y niñas hospitalizados por medio de la realidad virtual. Se trata de hacer que esos seres pequeñajos que están pasando por dificultades en un momento de su vida puedan cambiar un poco esos ratos grises por un poco de color gracias a las posibilidades que ofrece la realidad virtual.

Figura 3: Misión de Voluntechies

Gracias a talleres con los principales HMD (Head-Mounted Display) del mercado como HTC Vive u Oculus, los Voluntechies no sólo entretienen durante un rato a los niños/as sino que les dan una herramienta para que ellos mismos puedan evadirse y transportarse a lugares lejanos con unas sencillas Google Cardboard y el smartphone de sus padres.

Figura 4: A punto de salir del hospital a otros mundos con HTC Vive

Se trata de hacer que estos niños puedan visitar lugares bonitos, divertidos o extraños cambiando el plano de su realidad diaria en el hospital por una realidad que durante el proceso de realización de una nueva prueba médica les permita estar viajando por el espacio, jugando con Chase, o interactuando con otros niños o niñas en su propio mundo. Es una asociación sin ánimo de lucro, de personas que están convencidas de que hay gran cantidad de techies que están dispuestos a pasar unas horas de su fin de semana con aquellos que más lo necesitan, acompañándoles en un paseo por la playa, una sesión de surf en Hawaii o subiendo el Himalaya.

Figura 5: Google CardBoard de Voluntechies

A día de hoy trabajan con los principales hospitales de la Comunidad de Madrid y están buscando más locos que crean que la tecnología puede servir para algo tan positivo como conseguir que una habitación blanca de hospital se llene del arcoíris con la sonrisa de un niño que visita un mundo paralelo cuando le van a hacer una prueba médica. Si os interesa ser parte de esta locura, queréis saber más sobre esta iniciativa, o queréis ayudar, puedes visitar su página web (http://www.voluntechies.org).

Figura 6: Vídeo del proyecto Voluntechies

Por supuesto, para colaborar podéis uniros a construir esos mundos, podéis apuntaros a estar en los talleres o podéis difundir el proyecto para que llegue a todos los voluntechies que haya por ahí. Y si estás en el momento de hacer un proyecto de fin de carrera, de fin de maestría o estás buscando un proyecto con el que aprender y colaborar con algún compañero, es también una buena inciativa para ponerse como reto personal. Aprender y ayudar al mismo tiempo.

Figura 7: ¿En el hospital o en la Sabana?

Al final, como siempre que se hace algo así, no hay nada como lo que vas a sacar tú de la experiencia de ver a uno de estos bichos contentos. Una carcajada suya, como sucede en Monstruos S.A., tiene mucha más energía para tu vida que nada más en el mundo.

Saludos Malignos!

Ataques DDoS con amplificación vía CLDAP (Connection-less LDAP) en la botnet Mirai

Como supongo que la mayoría de vosotros sabéis, el ataque de DDOS de la semana pasada fue realizado con la botnet Miari. Multitud de dispositivos controlados remotamente para atacar un único objetivo y hacer que la potencia sea tal que no pueda dar servicio. Pero para generar tal cantidad de tráfico - se habla de picos de 1.2 TBps - no basta con controlar muchos dispositivos, sino de amplificar todo lo que se pueda la generación de tráfico.

Figura 1: Ataques DDoS con amplificación vía CLDAP (Connection-less LDAP) en la botnet Mirai

Supongamos un equipo conectado en una casa particular con una línea de comunicaciones de 1MB que forma parte de la botnet. A priori, parece lógico pensar que este equipo puede aportar hasta un máximo de 1MB en el ataque total de la red, pero los atacantes, desde hace tiempo, utilizan técnicas de amplificación para conseguir que este dispositivo infectado genere mucho más tráfico que ese MB. Y aquí es donde la empresa Corero Network Security dice que Mirari utilizó un nuevo 0day en el protocolo CLDAP para conseguir este efecto.

Ataques de amplificación

Los ataques de amplificación no son nuevos, y podemos irnos muchos años atrás para ver cómo funcionaba el Ataque del Pitufo (Smurf Attack) y entender el proceso. Básicamente, todos los ataques de amplificación se basan en buscar una conexión de Internet de gran potencia (mucho más de 1MB) que ante una petición de tamaño X genere una respuesta de tamaño Y, donde el tamaño de Y es mayor que el de X. Se dice que la respuesta entonces está amplificada en un factor K > 1 tal que Y= K* X.

Figura 2: El ataque Smurft hacía amplificación con paquetes ICMP enviados a direcciones broadcast

Cuanto mayor sea el factor K, mayor tráfico se conseguirá con un bot en una conexión de 1MB. Supongamos que ante una petición DNS un atacante, con enviar una petición de 20 bytes consigue una respuesta de 80 bytes. En ese caso estaríamos hablando de una petición que consigue un factor de amplificación 4, con lo que un equipo controlado detrás de una conexión de 1MB sería capaz de conseguir un total de 4MB de tráfico de respuesta.

Figura 3: Ejemplo de un ataque simple de DNS amplification

El objetivo de los ataques de amplificación es conseguir que ese tráfico generado desde el servidor no sea enviado al equipo que originó la petición - en este caso el bot detrás de la conexión de 1 MB - sino que acabe en el servidor que se quiere atacar. Para eso, hay que conseguir hacer un ataque de spoofing - o suplantación de dirección IP - y para ello lo más sencillo es que se haga con servicios que funcionen sobre el protocolo UDP.

Por supuesto, en el pasado hemos visto ataques de spoofing sobre protocolo TCP, pero estos deben realizar la negociación de la conexión a ciegas, y la existencia de algoritmos robustos de generación de los números de secuencia TCP dificultan estos ataques - amen de protección en dispositivos de red que tienen sistemas de alerta contra este tipo de ataques -.

Un 0day de CLDAP (Connection-Less LDAP)

A lo largo de la historia hemos visto muchos tipos de ataques de amplificación. Ataques de DNS amplification como se utilizaron en el ataque de Spamhaus o de NTP amplification - además del ataque del pitufo citado anteriormente -. Ahora, según parece, hay un 0day que podría afectar al protocolo CLDAP.

Figura 4: Servidores usados en ataque DDoS de 400 GBps con NTP amplication en 2014

Según la empresa Corero Network Security, entre el tráfico detectado en el ataque de Mirai a Dyn se detectó mucho tráfico de respuestas CLDAP, lo que apunta a que se ha descubierto un 0day que permite hacer una amplificación con estas peticiones suplantando la dirección de origen de la petición CLDAP. Esto es así porque el protocolo CLDAP permite realizar conexiones UDP a los árboles LDAP, lo que facilita el proceso de suplantación.

El protocolo CLDAP puede estar habilitado en tus árboles LDAP e incluso Active Directory de Microsoft soporta este tipo de conexiones para acelerar los procesos de consulta a los objetos del árbol LDAP que da soporte a AD.

Figura 5: MS-CLDAP en Active Directory

En el libro de Hacking Web Technologies, yo le dediqué todo un extenso capítulo a los ataques a servidores LDAP y cómo protegerse de ellos, pero no hacía por supuesto ninguna referencia a este posible 0day. Ahora que es público, lógicamente, si tienes servicios LDAP abiertos a Internet, debes mirar si tu servidor soporta conexiones vía UDP de tipo CLDAP, porque entonces puedes ser parte de los ataques como elemento amplificación.

Saludos Malignos!

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!

Descarga el libro gratuito de "Seguridad en Redes"

Se acaba de publicar este nuevo libro gratuito denominado “Seguridad en Redes”. Esta obra presenta un enfoque eminentemente técnico de la experiencia de varios años de trabajo en grandes redes en las áreas de “Planificación y Operación de red”, “Seguridad de redes y TI” y “Auditoría de seguridad”, que podríamos afirmar, son los pilares fundamentales de toda red. Los prólogos de este libro están escritos por Chema Alonso y Antonio Castro Lechtaler, que como todos conocemos, son dos referentes internacionales en Redes y Seguridad.

Figura 1: Descarga el libro gratuito de "Seguridad en Redes"

El autor soy yo, Alejandro Corletti Estrada, que después de la publicación del libro “Seguridad por Niveles” en el año 2011  que alcanzó las 100.000 descargas, nuevamente me animé a crear esta obra para difusión y descarga gratuita para cualquier uso docente, quedando prohibida toda acción y/o actividad comercial o lucrativa, como así también su derivación y/o modificación sin autorización expresa del autor. Aquí tienes el prólogo que Chema Alonso escribió para este libro.

Ser un hacker y no un profesional 

Quiere el destino que escriba este prólogo solo un par de días después de que tuviera lugar el, hasta ahora, ataque de denegación de servicio distribuida más grande que se recuerda. Con una potencia de hasta 1.2 Terabits por segundo la botnet Mirai ha conseguido marcar el record en tráfico generado para hacer un ataque contra un objetivo concreto.

Corremos tiempos beligerantes en las redes de comunicaciones en los que los cibercriminales han encontrado en ellas un medio para perpetrar sus ataques con cierta percepción de impunidad al ocultarse en la distancia de países remotos con leyes no adaptadas que dejan que se escapen como polvo en los dedos.

Proteger este activo tan preciado que la tecnología nos ha dado es responsabilidad de todos. Desde el dueño de una impresora en su casa hasta el administrador de una pequeña red de equipos en una empresa pasando, lógico está, por los grandes proveedores de servicios en Internet. Cada fallo de seguridad en esta vasta y creciente red de redes puede ser utilizado por un adversario para conseguir una ventaja en un ataque y así, como hemos visto en el ataque que citaba al principio, la botnet Mirai se ha aprovechado de dispositivos como impresoras, routers, switches o cámaras de vigilancia mal configuradas, con bugs conocidos o contraseñas por defecto, para conseguir un número tal de equipos infectados que una empresa como DYN, que da soporte a una parte importante de los servicios DNS de Internet, no pueda contenerla.

Conocer nuestras redes, los rincones más pequeños y escorados de las mismas, para evitar que el eslabón más débil de esta cadena sea un dispositivo que forma parte del Shadow IT o el Shadow IoT de nuestra organización es fundamental. Pero más lo es conocer cómo funcionan y mantener la seguridad del mismo a lo largo del tiempo.

Decía la definición que hace el Internet Engineering Task Force en su RFC 1983 titulado Internet User’ Glossary que un Hacker es:

A person who delights in having an intimate understanding of the internal workings of a system, computers and computer networks in particular. The term is often misused in a pejorative context, where "cracker" would be the correct term. 

Y es así lo que necesitamos todos que seas en tu red. Un auténtico hacker que tenga un conocimiento íntimo de cómo funciona tu red. Cuáles son los protocolos que están circulando por ellas, cómo están configurados, cómo se pueden mejorar y cuáles son los rastros que deben levantar una alerta en tus mecanismos de detección para saber que algo está pasando por ellas que no debiera.

Debes conocer todo lo que puedas tu red de comunicaciones. Saber cómo siente, piensa y respira cada poro de ella. Cada router, cada switch, cada firewall, cada equipo que envía o recibe tráfico por el medio que sea, por el protocolo que sea, por la aplicación que sea. Es tu red y debes conocerla como si la hubieras construido tú, debes ser el hacker de tu red y aprender de ella día a día.

En mi vida profesional, ya más larga de lo que me gustaría para poder disfrutar más de los muchos momentos que me toquen por venir aún, me he topado con una gran cantidad de informáticos que realmente no adoraban esta profesión. Profesionales que lo eran porque trabajaban de esto, pero que por falta de pasión y dedicación a conocer lo que tenían entre manos no deberían tener ese título.

Los que de verdad amamos este trabajo no escatimamos esfuerzos en aprender más día a día de lo que tenemos entre manos, en conocer aquello que desconocemos, en disfrutar del trabajo que nos llevó a meternos en esta afición que se convirtió en profesión.

Llegados a este punto debes hacerte a ti mismo esta pregunta. Debes preguntarte qué tipo de profesional quieres ser. Uno de esos que lo es por la tarjeta y la posición laboral o uno de esos que aprende todo lo que puede porque es un hacker que adora la tecnología. Decide tú. Tú manejas tu tiempo, tu vida, tus esfuerzos y tu carrera profesional. Hoy, y ahora, es el momento de que aprendas un poco más para que mañana puedas aprender un poco más sobre lo ya aprendido. Sé un hacker y no un trabajador de la informática.

Aprende todo lo que puedas y haz que tu trabajo sea tu pasión y que tu pasión sea tu trabajo. Solo así podrás ocuparte correctamente de la seguridad de tus redes.

Chema Alonso

El objetivo de esta obra es poder compartir conocimientos para que el nivel de seguridad de nuestras arquitecturas de red pueda mejorarse. El libro comienza con una detallada descripción de la historia y evolución de las redes, como punto de partida y pilar básico para ir abordando las diferentes estrategias y procesos. El texto presenta al detalle los dispositivos que forman el verdadero corazón mundial de la red fija y móvil.

Figura 2: Arquitecturas de redes para mitigar ataques DDoS 

Poco a poco sigue abordando los niveles de Switching y Routing desde un enfoque práctico y con ejemplos vigentes en las diferentes configuraciones y el empleo de los protocolos de red. Uno de los aspectos que más destacan de la obra, es la experiencia que intento transmitir por medio del uso de herramientas, comandos y programas que no pueden ser dejados de lado en el día a día de la seguridad de estas infraestructuras.

Figura 3: WireShark para analizar tráfico de red

Trata con suficiente grado de detalle los aspectos de seguridad que deben reunir los CPDs o centrales dónde se aloja el equipamiento de red. Y, como no podía ser de otra forma, el autor otra vez nos propone una importante cantidad de ejemplos prácticos en el empleo de comandos y herramientas, que tal cual menciona Chema Alonso en su prólogo, son la forma en la que operará todo hacker sobre nuestras redes y sistemas. Por lo tanto desde el punto de vista de los responsables de las mismas, deben conocerlas, saber emplearlas y sacarles provecho, previamente a que lo haga un intruso. Por supuesto, si quieres conocer más de tu adversario debes conocer cuáles son los ataques que hacen en redes IPv4 &IPv6.

Figura 4:  Libro gratuito de Seguridad en Redes

Las versiones impresas de esta obra - estas sí son de pago - se distribuyen únicamente en España y se pueden solicitar a través de la cuenta  de correo info@darFe.es.  Si quieres descargar una copia, puedes hacerlo en esta URL "Libro Seguridad en Redes" y aquí lo tienes subido a SlideShare.

Autor: Alejandro Corletti Estrada
Doctor en Ingeniería y ex-jefe de redes del Ejército argentino

Cómo convertirse en root en un GNU/Linux explotando el bug de DirtyCOW

La semana pasada se publicó un exploit que se aprovecha de una vulnerabilidad para lograr ejecutar código en un contexto privilegiado. DirtyCOW es una vulnerabilidad de condición de carrera que puede provocar la ejecución de código y lograr una escalada de privilegios en un kernel de Linux. Afecta a todas las versiones del sistema operativo y podemos encontrar un mayor nivel de detalle en su CVE-2016-5196. Además, DirtyCOW va camino de vulnerabilidad mediática, por lo que tiene su propio sitio web y su propia imagen.

Figura 1: Cómo convertirse en root en un GNU/Linux explotando el bug de DirtyCOW

¿En qué consiste la vulnerabilidad? Realmente es una condición de carrera que se encontró en la forma en la que el subsistema de memoria del kernel de Linux gestiona COW, Copy-On-Write. En otras palabras, un usuario local sin privilegios podría utilizar esta vulnerabilidad para escribir y tener acceso a partes del sistema que son de otros usuarios, incluido el root. En el instante que se puede acceder a la escritura a partes pertenecientes a root, se puede escribir código que, al ser ejecutado, por ejemplo, con setuid, permiten ejecutar código con dicha identidad consiguiendo la escalada de privilegio.

Figura 2: Copy-on-Write en la Wikipedia

Como curiosidad hay que decir que la vulnerabilidad ha estado presente durante muchos años, desde la versión 2.6.22 del kernel de Linux, la cual fue liberada allá por el año 2007. Incluso el propio Linus Torvalds comentó en su día que la vulnerabilidad existía, pero todo era de forma teórica y no se conocía la forma de explotar. De hecho se dejó porque el parche que se había previsto afectaba al funcionamiento de Linux en los equipos IBM S390. Hoy día, ya tenemos un exploit público que se aprovecha de la vulnerabilidad para lograr ejecutar código con privilegio, y lograr la escalada.

Figura 3: Exploit para DirtyCOW que usaremos en la PoC

Para verificar que mi sistema es vulnerable o no a esta vulnerabilidad podemos ejecutar la siguiente instrucción en un terminal: uname -a. Si la versión del kernel está entre la 2.6.22 y la 3.9, tendremos un problema. El exploit público está preparado para arquitecturas x86 y x64, solo hay que descomentar la parte que no nos interesa.

Figura 4: Comprobación de versión del Kernel de Linux vulnerable a DirtyCOW

En exploit-db encontramos una de las pruebas de concepto de las varias que hay en Internet sobre el exploit. Para nuestra prueba de concepto utilizaremos la que hemos visto en exploit-db, pero os recomendamos que echéis un ojo a las distintas pruebas de concepto que se han ido publicando en Internet. En Github, se ha montado un repositorio sobre todas las pruebas de concepto.

Figura 5: Repositorio en GitHub para las PoCs de DirtyCOW

Una vez descargado el exploit, vamos a editar el exploit para, en función de nuestra arquitectura, amoldarlo a las necesidades. Si estamos en un sistema x86, debemos comentar el payload generado con msfvenom de Metasploit para x64, y si nos encontramos en un sistema x64, sería justamente al revés.

PoC: Escalando privilegios con DirtyCOW

Una vez tengamos claro esto, debemos compilar el exploit escrito en Lenguaje C. Para ello ejecutamos la siguiente instrucción gcc [exploit.c] -o [exploit binario] -pthread. Esto llevará a cabo la compilación del exploit y lo tendremos disponible.

Figura 6: Configuración del exploit de DirtyCOW para nuestra arquitectura

Si pensamos en el hardening de servidores GNY/Linux tenemos que pensar que tener disponible el compilador en un servidor o máquina dónde no se lleven a cabo este tipo de tareas no es una buena práctica de seguridad. Imaginemos que en un servidor disponemos de gcc u otros compiladores, estamos dando un arma a los atacantes, que hayan llegado hasta aquí.

Figura 7: Ejecución del exploit de elevación de privilegios gracias a DirtyCOW

Una vez compilado, lanzamos el binario y podremos ver que el exploit tiene éxito. En el momento que tiene éxito, disponemos de una sesión como root en la máquina local. Lógicamente, este tipo de escaladas de privilegios, pueden ir ligadas con un ataque previo remoto, en el que un atacante o un auditor consigue acceso al sistema, para posteriormente lograr la escalada de privilegio. No sería extraño ver en poco tiempo este exploit migrado al famoso framework de explotación Metasploit.

Figura 8: Vídeo de la explotación de DirtyCOW

Por último, os dejamos el video sobre la explotación local de la vulnerabilidad en un sistema Ubuntu 14.04. Existen ramas en el kernel de Linux que ya están parcheadas, que no son vulnerables a DirtyCOW, por lo que recomendamos a todos los equipos de IT que verifiquen que sus versiones de kernel de los sistemas Linux no sean vulnerables. Este es un claro ejemplo de cómo explotar vulnerabilidades en Linux, así que analízalo que se entiende muy fácil.


Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”

Libro de Hacking iOS: iPhone & iPad (2ª Edición) diponible en @0xWord

Desde que se acabara la primera edición del libro de Hacking iOS: iPhone & iPad, hemos estado trabajando en actualizar los contenidos de este texto para incluir en él todos los cambios, nuevas técnicas de hacking y vulnerabilidades incluidas en las diferentes versiones del sistema operativo y los diferentes dispositivos. Ahora, después de probar con iPhone 7 e iOS 10 los últimos detalles, hemos terminado este proceso y ya está disponible en 0xWord la 2ª Edición del libro de Hacking iOS: iPhone & iPad.

Figura 1: Nuevo Libro de Hacking iOS: iPhone & iPad (2ª Edición) disponible en 0xWord

En este texto se explican desde los ataques locales al dispositivo para sacar información de él, con técnicas de abuso de Siri, NAND Mirroring o extracción de datos de los elementos físicos (carcasa, SIM, bandeja), hasta los ataques vía red de comunicaciones 2G/3G o WiFi, pasando por ataques en redes locales para hacer un man in the middle, funcionamiento de los ataques con troyanos, las herramientas para la realización del jailbreak y procesos forenses o las técnicas de phishing adaptadas a terminales iPhone o iPad.

Figura 2: Libro de Hacking iOS: iPhone & iPad 2ª Edición

Por si quieres ver el contenido en detalle, tienes disponible el índice de este libro para que veas todos los temas que se tratan en las más de 300 páginas que conglomeran el texto final de esta nueva edición del libro de Hacking iOS: iPhone & iPad.

Figura 2: Hacking iOS: iPhone & iPad (2º Edición)

El libro ya ha venido de la encuadernación, por lo que su disponibilidad es casi inmediata en España y en latinoamérica estará disponible a través de los distribuidores en un plazo corto de tiempo, por lo que podrás tenerlo pronto a partir de que lo reserves.

Saludos Malignos!