Hace unos meses os hablamos de HoneyBadger, un proyecto centrado en las técnicas de engaño o "decepción" - del inglés Deception Techniques - que busca crear dispositivos falsos que no existen en una red para detectar y/o contraatacar a posibles atacantes que se hayan colado en tu red. El objetivo es configurar manzanas envenenadas dentro de una red ("Poison Apples") en una red que no deben tocarse, porque si las tocas algo malo te va a pasar.
De esto os habló en el artículo de "HoneyBadger: Cómo proteger tu red con dispositivos falsos" nuestro compañero Guillermo Peñarando Sánchez, que está en el equipo de Ideas Locas trabajando en estos proyectos de pre-innovación que construimos en Telefónica para generar ideas, probar conceptos, desarrollar patentes, etcétera. Antes de ver la charla, aquí tenéis una demo de cómo funciona la herramienta.
Si quieres aprender cómo trabajar con este proyecto, hacerlo tuyo, evolucionarlo, mejorarlo y sacarle partido, puedes verte esta charla que hemos publicado en vídeo. Lo mejor de los proyectos de código abierto de estos proyectos es que tú decides cómo ha de ser en el futuro aportando cambios y transformaciones.
Como siempre os digo, tener ideas es molón, pero esta va de ejecutarlas, de hacer "delivery", de probar un proyecto, otro, cambiarlo, darle una vuelta, y luego, ya conectarás los puntos que has ido construyendo con algo más grande, así que, si tienes una idea hazla... aunque sea una idea loca - como hacemos nosotros -, que todas las ideas buenas fueron una locura en algún momento.
Vamos a contaros una de esas Microhistorias que tanto nos gustan donde esta vez se mezcla hacking, programadores extremos (ahora veréis por qué) y el viaje a la Luna. El programa Apolo fue un hito tecnológico único, que provocó el avance de la Ciencia en varios campos como la química, aeronáutica, medicina y por supuesto también la Informática. Esta es una de esas historias no tan conocida que nos hacen ver que hubo también otros héroes aparte de los astronautas que se jugaron la vida por la Humanidad. Recuerda que puedes encontrar historias como esta en nuestro libro “Microhistorias: Anéctodas y Curiosidades de la Informática”:
Figura 1: Don Eyles, el programador que utilizó el arte del engaño para hackear el Apolo 14 y salvar la misión
Después del desafortunado incidente en la misión del Apolo 13, poco más de un año después (acordaros del famoso “Houston, tenemos un problema”), EEUU no podía volver a permitirse otro fallo o el resto de la misión sería cancelada (aún quedaban al menos cuatro o cinco viajes más programados). De hecho, después del fracaso del Apolo 13 (en el que afortunadamente los astronautas pudieron volver sanos y salvos), esta misión del Apolo 14 estuvo a punto de ser cancelada.
Afortunadamente, al final obtuvo luz verde y el cohete Saturno V despegó desde el Centro Espacial Kennedy el 31 de enero de 1971. Los astronautas elegidos para esta misión fueron Alan B. Shephard, Edgar D. Mitchell y Stuart A. Roosa.
Aunque el lanzamiento y viaje a la Luna del Apolo 14 se ejecutó sin problemas, escasamente a tres horas del alunizaje, el equipo de control de tierra recibió de la cabina del módulo lunar la señal de que la secuencia de abortar se había activado. Después que los astronautas (Alan Shepard y Edgar Mitchell, que eran los que iban en el módulo de descenso o LM bautizado como “Antares”) confirmaron que ellos no habían pulsado el botón de abortar misión, control en tierra les pidió a estos que dieran un “golpecito” (así, tal y como suena) al panel donde se encontraba el indicador de dicha acción de abortar.
Cuando lo hicieron, la señal se apagó, pero poco más tarde volvió a aparecer. Estaba claro que había algún tipo de problema con el indicador, probablemente un mal contacto provocado por algún trocito de metal desprendido de alguna parte por culpa de las vibraciones de la nave.
El objetivo del botón de abortar tenía como objetivo desprender el LM en caso de que algo fuera mal durante el alunizaje. Pulsando éste, se activaría una secuencia que mandaría la nave de nuevo a una órbita segura, obviamente abortando el alunizaje. En esta fase del viaje no tenía ningún efecto, pero si dicha señal se activara de forma automática durante la fase de descenso, mandaría la nave de nuevo a la órbita lunar, sin que la tripulación pudiera hacer nada.
Es decir, si el software del módulo lunar detectaba durante esa fase que se este indicador se había activado, se procedería a abortar la misión. Los astronautas estarían a salvo, pero la misión fracasaría, y esto como ya hemos comentado antes, era algo que la NASA no se podría permitir después del fracaso del Apolo XIII.
Había que hacer algo con ese indicador, ya que había muchas probabilidades que éste se activara accidentalmente durante la fase de alunizaje y abortara la misión sin haber realmente un problema real. Era la 1:00 am cuando a Don Eyles le notificaron del problema en su oficina, cerca de la habitación donde se estaba monitorizando la misión. Eyles era uno de los ingenieros que había trabajado en el software del módulo lunar en el equipo de Margaret Hamilton.
De hecho, había escrito la mayoría del código del alunizaje, incluyendo aquel que monitorizaba el indicador de abortar por lo tanto era el más apropiado para solucionar el problema. Para ello, tenía que encontrar la manera que el software del módulo lunar ignorara dicha señal durante la crítica fase de alunizaje. Así, tal y como suena con todo el riesgo que esto conlleva.
Fue entonces cuando Don Eyles junto a Bruce McCoy, que era quién le había dado la noticia a Eyles y también era ingeniero de software de la misión, fueron a una habitación cercana donde tenían el listado del código fuente exacto que se ejecutaba en el módulo lunar. En esos tiempos no existían Github ni StackOverflow :) así que la única fuente de información era una copia del código fuente impreso en papel, el cual era una mezcla de código máquina y ensamblador. Cogieron un lápiz y papel, se pusieron las gafas y comenzaron a repasar el código a toda prisa, era una tarea contrarreloj.
Entonces, a Don Eyles se lo ocurrió que, para poder solucionar el problema lo mejor era hacer creer al módulo lunar que el proceso para abortar ya estaba activo. Técnicamente era engañar a su propio software para que ignorara las señales que enviaba este indicador. Aunque parecía una locura, si esta acción se realizaba en el momento preciso, el impacto sería mínimo y no pondría en riesgo a la misión.
Es decir, el motor todavía se encendería a tiempo para el alunizaje y los astronautas, en caso de emergencia, podrían activarlo de forma manual. Esto de “hacer creer…” en el mundo del hacking se conoce como una técnica de engaño (en inglés, “deception”) la cual tiene como base la ingeniería social, pero también es utilizada para engañar en el mundo de la informática. Nuestro amigo Kevin Mitnick tiene todo un libro dedicado a ello.
Por ejemplo, algo parecido fue lo que usó Stuxnet para hacer creer a los sistemas que monitorizaban los centrifugadores de gas usados para la creación de uranio, que todo marchaba bien, mientras que otra parte del espécimen se encargaba de atacarlos causando su mal funcionamiento. De hecho, el objetivo era acelerar estas centrifugadoras a velocidades por encima de la permitida hasta que terminaban dejando de funcionar, y en alguna ocasión parece que incluso llegaron a explotar.
Figura 8:
Vídeo de Don Eyles explicando el código fuente del código lunar
Después de crear el programa para realizar este bypass y realizar un par de intentos en el simulador que tenían en tierra, a tan sólo 10 minutos de quedarse sin tiempo, ya tenían listo el código que engañaría al ordenador del módulo lunar. Este finalmente fue aprobado y se preparó para ser enviado por radio a la tripulación.
El resultado final aún requeriría que los astronautas ejecutaran un procedimiento en el terminal DSKY - Display/Keyboard de abordo, que resultaría en escribir las instrucciones en el teclado del DSKY, el cual constaba 61 pulsaciones, y además de ello, también tendrían que realizar un par de pasos más, esta vez manuales con otros instrumentos para terminar el proceso.
Vamos a detenernos un momento en este punto para repasar la situación extrema a la que se enfrenta Eyles y su equipo. Imaginaros la gran la cantidad de vectores de error que podían suceder en cualquier momento y las consecuencias desastrosas que podrían acarrear. Primero tuvo que programar todo el código sin un sólo fallo en tiempo récord para poder tenerlo a tiempo antes de la ventana de alunizaje (lo consiguió a sólo 10 minutos de no haber vuelta atrás, tal y como hemos comentado antes).
Después, había que enviarlo por radio al módulo lunar para que un astronauta (en este caso Allan Shepard) lo tecleara a mano, comando por comando sin cometer tampoco ningún error en las pulsaciones. Cada pulsación del teclado tendría que ser muy precisa, ya que estaban programando directamente en la memoria del ordenador de abordo durante una misión real. Un error, y las consecuencias podrían ser desastrosas.
Afortunadamente, Alan Shepard no cometió ningún error en las pulsaciones, el código funcionó perfectamente y no hubo ningún error el proceso manual. Así que finalmente, el 5 de febrero de 1971 a las 9:18 UTC el módulo Antares alunizó sin problemas en la zona de Fra Mauro en la Luna para continuar con la misión. El 9 de febrero finalmente la tripulación amerizó sana y salva a las 21:00 UTC terminado con éxito la misión del Apolo 14. Don Eyles continuó trabajando en la NASA durante varios años más contribuyendo a que el resto de las misiones Apolo fuera un éxito total.
Y esto es todo, así que la próxima vez que te sientas bajo presión cuando estés programando, piensa en lo que tuvo que pasar el bueno de Eyles ;)
Desde hace poco menos de un año, nuestro ex-compañero y amigo David Barroso (@lostinsecurity), se embarcó en una aventura empresarial para montar una startup de contra-inteligencia. A la start-up, que lanzó junto a dos compañeros más, la bautizó con el nombre de CounterCraft y comenzó el duro camino de emprender para desarrollar su tecnología en un espacio que aún necesita mucho desarrollo en el mercado.
Figura 1: CounterCraft: una startup de contra-inteligencia española
El objetivo de la compañía es automatizar un producto que permita a las empresas ser capaces de detectar a los adversarios que hay dentro de sus sistemas por medio de un conjunto de herramientas que van desde señuelos, automatismos para deception kits, sistemas honeypot o "poisoned apples" que permita saber cuando alguien está haciendo algo que no debería y poder localizarlo cuanto antes, al mismo tiempo que se aprende de su comportamiento de forma sistémica y gestionada.
No hay mucho más que decir por ahora, ya que la compañía no ha querido ir públicamente con demostraciones tecnológicas abiertas a todo el público o explicaciones más detalladas, pero lo cierto es que con las conversaciones privadas y los due diligence técnicos que se han hecho, la empresa ha conseguido levanta ya 1 Millón de € de fondos de inversión de capital semilla, tal y como recoge TechCruch.
A día de hoy se encuentra en la incubadora de WayraMadrid, como ha explicado el artículo de El Mundo de esta semana, y ha conseguido el apoyo de Adara, un VC que se ha unido junto a Telefónica Open Future_ y Orza para invertir en esta start-up de contra-inteligencia española que está levantando tanta expectación. Enhorabuena a todo el equipo.
Figura 1: Configurar una HoneyPot en tu aplicación web con Latch
Se puede usar en sistemas operativos OS X, Windows, Linux o en el mundo IoT y tras ver los concursos de ideas, seguro que se te ocurren nuevas a ti. A mí se me ocurrió montar un entorno de Deception o una HoneyPot para saber lo que hacen los malos en la zona privada de mi plataforma si un día aparece un bug o son capaces de saltarse las protecciones de mi aplicación web. Y no, no hace falta nada adicional. Dejadme que os lo cuente.
Figura 2: Cómo usar Latch en la web de Cajamar
Si un atacante es capaz de obtener unas credenciales robadas por medio de un ataque de Spear Phishing y sabe que son válidas, puede intentar acceder al sitio correspondiente. Si el sitio tiene un un 2FA o el atacante intuye que puede haber un Latch, esto no será suficiente, pero puede ser que aún así quizás no se rinda tan fácilmente e intente otros métodos para acceder al sistema sin tener que pasar por el login de la aplicación web.
Una base de datos HoneyPot con Latch
Como ya sabéis, con Latch el atacante solo tiene un intento de acceder con las credenciales correctas, ya que el sistema avisa al usuario de que intentaron acceder y/o accedieron con sus credenciales en el sitio protegido. Pero veamos ahora un ejemplo exagerado de lo que podremos conseguir con Latch usando la potencia del interruptor en que se convierte. Si no te has visto alguna de las charlas de Chema Alonso sobre esto, deberías hacerlo. Aquí una que recoge todos los escenarios descritos.
Figura 3: Protección empresarial contra insiders que roban identidades locales
Imaginemos que a pesar de tener el Latch cerrado, la aplicación lo deja entrar porque el atacante no ha usado las credenciales, sino que ha sido capaz de robar una cookie de sesión y hacer un Session Hijacking o ha logrado acceso por medio de una password de aplicación o incluso porque la web permite acceso basado en tokens OAuth como en los ataques de Sappo y RansomCloud. Proteger las cookies contra un ataque de hijacking, los accesos vía Application Password o mediante Tokens OAuth no es algo que se proteja con un 2FA o un Latch puesto en el proceso de login y podría darse un caso en el que el atacante encontrara la forma de llegar a la información y los datos de la parte interna de una aplicación web.
Ahora vamos a cambiar el chip y utilizar Latch de forma más holística dentro de la aplicación, para que sirva no únicamente para bloquear o dejar acceder en el proceso de login, si no que además cambie completamente los datos de la aplicación usando el pestillo para indicar al sistema qué opción debe tomar: La pastilla azul o La pastilla roja. Es decir, el camino de la información falsa o el camino de la información real.
Bien, ahora creo que ya sabéis por dónde voy.
Figura 4: Configuración de aplicación Latch para montar el HoneyPot
Cuando Latch esté cerrado, la aplicación estará siempre conectada a la base de datos con la información falsa. Por otro lado, si el Latch está abierto y se inicia sesión, las conexiones a la base de de datos antes de ejecutar los comandos SQL se harán entonces con la base de datos verdadera, obteniendo así la información real. En resumen el pseudocodigo sería algo como:
- Comprobar estado de Latch de AplicaciónWeb - Si está abierto conectar a base de datos con información real. - Si está cerrado conectar a base de datos HoneyPot - Ejecutar consulta SQL con acceso a datos - Cerrar conexión.
Si un atacante logra robar una sesión y tenemos el Latch cerrado, caerá en la aplicación HoneyPot, y revisando los logs de actividad podremos a posteriori ver cuales son sus intenciones y conocer cómo consiguió el acceso. Tal vez fue un Session Hijacking, tal vez un ataque de CSRF porque no se cerró bien la sesión pero sí el Latch, tal vez un ataque de red... Pero en todos los casos contra la base de datos HoneyPot.
Una pequeña PoC
Veamos ahora una pequeña PoC, de una aplicación donde podremos ver los proyectos de los responsables de una empresa con sus presupuestos (cualquier parecido con la realidad es pura coincidencia). Así es como se ve con el Latch abierto, es decir, información verdadera.
Figura 5: Datos reales a los que se accede con Latch abierto
Si el Latch estuviera cerrado, se vería otro tipo de información preparada, como esta:
Figura 6: Datos que aparecen en la base de datos HoneyPot
Y aquí vemos un ejemplo preparado de un SQL Injection con el Latch cerrado.
Figura 7: Ataque de SQL Injection a la web con la Base de datos HoneyPot
Figura 8: Log de acciones de ataque en la HoneyPot
Evidentemente si en la aplicación con la información falsa existe este fallo, lo habrá igualmente con la información real, y además ha sido descubierto dicho bug por un atacante, pero sin arriesgar la información legítima. Ahora podemos arreglarlo lo antes posible para que no vuelva a suceder. Evidentemente una aplicación de empresa debe estar lo suficientemente probada y no dejar en mano de los atacantes descubrir los fallos, pero... las cosas pasan.
En este ejemplo vimos un uso adicional de Latch, no solo de permitir o prohibir el paso, si no de tomar una opción u otra en función de un estado. Esto no solo se aplica en bases de datos, podríamos usarlo para cambiar el tráfico de un host a otro, y tener muchas opciones más si utilizamos la granularidad de las operaciones. Otro caso útil podría ser el login de una web. ¿Por que mostrarlo si podemos bloquear con Latch tan siquiera la publicación del formulario de login? El límite lo pone nuestra imaginación y las ganas de programar. Te recomiendo que leas el artículo de cómo cocinar una aplicación PHP con Latch que explica paso a paso cómo se puede meter Latch en cualquiera aplicación web que tengas.
Los metadatos de un documento se pueden modificar, al igual que el banner de un servidor web o la versión de un servidor DNS (como hacen los chicos de RedHat). De hecho, para ocultar la información a las técnicas de fingerprinting básicas, esos datos se modifican para intentar engañar a los usuarios menos experimentados. Sin embargo, cuando se hace un pentesting, los datos importantes se revisan y confirman manualmente para detectar las técnicas de deception y sacar la información correcta.
Así, cuando se lee el banner de un servidor web, si algo suena raro con él, se le pasa una herramienta de fingerprinting al servidor que evalúe el tipo de respuesta, el orden de la misma, y el comportamiento ante determinadas situaciones para poder garantizar la versión del servidor web.
Manipulación de metadatos
Con los metadatos la manipulación es igualmente posible. Cuando en el año 2008 pensamos en para qué podría ser útil modificar los metadatos se nos ocurrierron varios escenarios posibles:
- Antiforensics: Alguien que quisiera incriminar a otra persona haciendo creer que el documento lo había escrito otro para engañara a un analista forense en una investigación.
- Metadata HoneyPot: Alguien que quisiera detectar si se estaban utilizando los metadatos para atacar su sitio, es decir, el artículo que publicamos en el congreso IADIS 2008 sobre Metadata Honeypot - ya os lo publicaré por aquí, que nunca lo hice y solo os dejé la referencia al mismo -.
- Imagen corporativa: por supuesto, para lo que lo usamos en MetaShield Protector y OOMetaextactor, es decir, quitar todos los datos sensibles y establecer valores en metadatos que sean corporativos, como poner el nombre de la compañía,
Sin embargo, intentar manipular los metadatos para engañar a un usuario en un proceso de pentesting es más bien inútil. De hecho, ya nos encontramos con este problema en la primera versión de la FOCA, allá por el año 2008, en el que nos preocupaba no el encontrar datos manipulados, sino inútiles por ser documentos incorporados a la web del proceso de pentesting que habían llegado allí por casualidad, por ejemplo unas diapositivas de una presentación de un ponente invitado a unas conferencias. En ese caso, los metadatos serán de la red donde trabaje el speaker y no de la web que publica el documento, por lo tanto había que quitarlo del proyecto.
Para solucionar este problema, añadimos, en la primera versión de FOCA una herramienta para el traceo de metadatos. Es decir, cuando se hace el análisis de metadatos, averiguar de qué documento proviene ese metadato. Si la cosa suena "rara" o "manipulada" o simplemente es inútil, basta con abrir el documento (botón derecho desde FOCA) revisarlo, y si no es válido, es decir, es falso o ha sido manipulado, eliminarlo con el botón derecho de la lista de documentos y volver a analizar el sitio. Esto está publicado en el primer manual de la FOCA de aquel año.
Para ello, cuando aparece un metadato, con el botón derecho se accede a la opción de "documentos donde aparece este valor", que lleva al documento del que procede el metadato. Así el auditor puede revisar bien el documento, y descartarlo si fuera falso.
Figura 1: Opciones de traceo de origen de metadato
Ahora bien, si una empresa tiene 2.000 documentos y quiere protegerse de FOCA... ¿alguien cree que es útil manipular un documento y dejar los 1.999 con datos reales? Si lo hiciera sería de necios, ya que estaría dejando datos públicos de su empresa en Internet por engañar a FOCA. Además, si solo hay un documento con información sensible, el analista haría una revisión manual y concienzuda para saber si es falsa o no esa info.
Es por eso que las empresas utilizan plantillas de valores corporativos, con soluciones como MetaShield Protector, que cambia todos los metadatos, pero no para engañar a un pentester, sino directamente para proteger la imagen de la compañía.
Indicio o Prueba
Hay que tener presente que un metadato, un fichero de log en formato txt, un banner de un servidor web, o incluso el valor devuelto por un registro de un DNS son todos indicios, ya que pueden haber sido manipulados para pretender engañar al auditor. Es por eso que no pueden ser tomados como pruebas. Un log que no esté firmado digitalmente y que refleje que una dirección IP se conectó a un servidor a una determinada hora no es una prueba irrefutable, pero sí un indicio que debe ser investigado.
En el caso de los metadatos sucede lo mismo, una fuga de información que diga que un usuario manipuló un documento en una hora y lugar es un indicio que debe ser investigado, llegando a realizar un análisis forense del equipo donde trabaja habitualmente el usuario, etc... Al final, los peritos determinarán si ese dato ha podido ser manipulado o no, y su opinión hará que ese dato tenga más o menos valor.
Sin embargo, en un proceso de pentesting, para un auditor da igual si es un indicio o una prueba. Si se encuentra una dirección IP en un documento, se prueba, se analiza, y se mira a ver si puede ser utilizada para atacar el sitio. ¿Que no se puede porque el dato es antiguo o ha sido manipulado? Pues mala suerte, a por otro posible camino de entrada en la red.
¿Se pueden manipular los metadatos de los documentos? Evidentemente, como los valores de un log, o las cabeceras de un mensaje de correo electrónico. ¿Eso quiere decir que sean inútiles para un proceso de pentesting? No. De hecho estamos hablando de una de las fugas de información más importantes de muchas empresas, con lo que es muy fácil sacar información jugosa de objetivos de pentesting. ¿Es probable que alguien haya manipulado un metadato en un documento? La probabilidad es muy baja en un proceso de pentesting de una web con 300 documentos, pero por supuesto, toda información extraída por FOCA siempre debe ser contrastada, como se hace con la info que devuelve cualquier scanner de seguridad.
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 
