Latch no solo es una aplicación que sirve para abrir y cerrar un pestillo, sino que va mucho más allá. Puede usarse como un Segundo Factor de Autenticación si lo ponemos asociado al login de usuario como en el plugin de WordPress, Moodle, SSH o PrestaShop y si lo tuneas puede ser usado en un esquema de 4-Eyes Verification. Puede ser usado en soluciones como Segundo Factor de Autorización, para permitir o no permitir operaciones en un determinado sistema, como se puede ver en el caso de WordPress in Paranoid Mode - esta tarde Eleven Paths Talk Gratuito sobre este tema - o como lo puedes probar en Nevele Bank con las operaciones bancarias o con tu cuenta de CajaMar si eres cliente. También puedes usarlo en un esquema de 2-Keys Activation tal y como se usaba en la hucha controlada por biometría y Latch o para proteger el acceso a ficheros seguros.
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.
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:
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.
Si el Latch estuviera cerrado, se vería otro tipo de información preparada, como esta:
Y aquí vemos un ejemplo preparado de un SQL Injection con el Latch cerrado.
Mostramos ahora el registro de Logs de lo que está haciendo. Hemos descubierto que el atacante hizo un ataque de SQL Injection para obtener información sobre los presupuestos de PEPITO, y ahora deberíamos investigar cómo lo ha hecho. ¿Será por un CSRF como en el caso de la base de datos atacada desde el iPad del jefe?
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.
Autor: Borja Pintos
 |
| 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ónWebSi 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.
- 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.
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 |
Mostramos ahora el registro de Logs de lo que está haciendo. Hemos descubierto que el atacante hizo un ataque de SQL Injection para obtener información sobre los presupuestos de PEPITO, y ahora deberíamos investigar cómo lo ha hecho. ¿Será por un CSRF como en el caso de la base de datos atacada desde el iPad del jefe?
 |
| 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.
Autor: Borja Pintos
me queda la duda de por qué estaría cerrado el latch si lo que me robaron fue la sesión (o sea, yo abrí el latch al conectarme legítimamente y alguien más se me coló, ¿es así la idea?).
ResponderEliminar