Yuzi download

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.

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

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

Esta semana hemos tenido un nuevo caso de vulnerabilidad mediática. HTTPoxy fue detectada por primera vez hace 15 años, por lo que no podemos decir que sea nueva, pero sí que es hoy cuando parece que se ha tomado realmente en serio. El problema es profundo, ya que se encuentra en librerías de código que son utilizadas para realizar peticiones HTTP dentro de una aplicación web. En el caso de que se viera afectada la aplicación por esta vulnerabilidad HTTPoxy todas las conexiones que realice podrían ser espiadas y modificadas.

Figura 1: Cómo explotar httpoxy en una aplicación PHP vulnerable

HTTPoxy ha retomado el escenario a través de aplicaciones basadas en CGI, escritas en PHP - como en el caso del famoso bug CVE-2012-1823 que tantos problemas generó, Python o Go. Han habilitado un Github dónde podemos encontrar diferentes pruebas de concepto, las cuales utilizan docker para montarlas, por lo que simplifica el escenario y aplicaciones a instalar.

Figura 2: GitHub con las PoC de HTTPoxy

La vulnerabilidad reside en cómo se procesan las cabeceras Proxy. En el año 2001, el fallo fue identificado en curl, en el año 2012 en Ruby y en el año 2013 en Nginx. Esta vez les ha tocado el turno a los lenguajes PHP, Python y Go. La vulnerabilidad tiene un CVSS, en base score, de 8,1. Para mayor detalle se puede encontrar más información en los siguientes CVE:

• CVE-2016-5385, correspondiente a PHP.
• CVE-2016-5386, correspondiente a Go.
• CVE-2016-5387, correspondiente a Apache HTTP Server.
• CVE-2016-1000110, correspondiente a Python.

¿Cómo funciona?

Cuando un atacante quiere explotar la vulnerabilidad necesita forzar que las aplicaciones web del servidor se crean que el header que obtienen con valor Proxy es la nueva dirección del servidor al que se tienen que conectar para enviar todas las conexiones HTTP. En otras palabras, es un abuso de la cabecera Proxy. Todo esto es provocado por un conflicto de nombres. En otras palabras, si nosotros como clientes malintencionados del servidor enviamos una cabecera “Proxy”, puede suceder que algunas implementaciones CGI creen una variable de entorno HTTP_PROXY, lo cual provoca que se anule la variable real que tiene el mismo nombre. Por esta razón decimos que la vulnerabilidad, realmente, es un conflicto de nombres que genera una sobreescritura del valor original - que podría ser null -.

Figura 3: Esquema de explotación de bug de HTTPoxy

Entonces, si sobrescribimos la variable de entorno HTTP_PROXY por una dirección bajo nuestro control podremos colocarnos en medio de la comunicación del servidor y cualquier punto con el que se comunique. Es decir, estamos realizando un Man in the Middle remoto. ¿Qué podemos hacer? En al PoC viene una pequeña demostración del robo de un Secret de una API, es decir, se muestra como se modifica el Proxy del servidor web en remoto y se consigue redirigir las peticiones que hace el servidor contra una API y capturamos el “secreto”.


Figura 4: BlackHat 2012 "Owning Bad Guys {and mafia} using JavaScript Botnets"
Aunque hemos hecho solo la captura del secreto los ataques de man in the middle vía Proxy permiten hacer de todo, como ya hicimos en la época de Informática64 con el trabajo de "Owning Bad Guys {and mafia} using JavaScript Botnets" en donde aprovechamos un servidor Proxy para infectar máquinas y crear una JavaScript Botnet o en el caso de Evil FOCA, donde se hacen ataques basados en las variables de Web Proxy Auto Discovery para hacer ataques de SSLStrip. Si estás en medio, puedes hacer todo lo que quieras.

Nuestra PoC de HTTPoxy para automatizar Faast

Mi compañero Ioseba Palop y yo montamos un entorno para probar esto y, posteriormente, añadir un plugin en nuestro sistema de pentesting persistente Faast para detectar esta vulnerabilidad. Como se dijo anteriormente utilizaremos docker para tener los contenedores de lo necesario. Para instalar docker solo tenemos que ejecutar:

apt-get install docker docker.io

Una vez lo tengamos instalado, debemos construir el dock. Para ello descargamos el código de la PoC de HTTPoxy desde Github. Una vez tengamos descargado el código ejecutamos docker build -t fpm-guzzle-proxy, tal y como se puede ver en la imagen.

Figura 5: Build de docker con la PoC de HTTPoxy

Después se descarga y crea el dock debemos ejecutarlo. Para ello utilizamos la instrucción:

docker run -d -p 80:80 –name fpm-test-instance fpm-guzzle-proxy

La sentencia -p 80:80 nos indica el puerto externo de docker y con qué puerto interno se mapea, en ambos casos es el puerto 80. El resultado tras la ejecución se puede ver en la siguiente imagen.

Figura 6: Ejecución de la PoC sobre Docker

Ya tenemos el entorno vulnerable montado, por lo que vamos utilizar la herramienta curl para generar una petición al servidor web y aplicación montada. La instrucción es:

curl -H ‘Proxy: [ip]:[puerto]’ [ip del servidor]

Es muy sencillo de entender lo que estamos haciendo. Nosotros somos el cliente y le estamos diciendo al servidor web que el Proxy es el que nos interese. Si la aplicación web es vulnerable ocurrirá lo comentado anteriormente, se sobrescribe la variable de entorno y cuando el servidor web realice peticiones la enviará al Proxy, es decir, a nosotros en este caso.

Figura 7: Ejecución con curl de la sobrescritura de la cabecera Proxy

Para poder entender que todo esto está funcionando, hemos habilitado un netcat en el puerto 12345, que coincide con la dirección y puerto dónde le dijimos al servidor vulnerable que estaría su Proxy. Como se puede ver en la imagen nos llega una petición POST dirigida a Facebook y que envía algo “secreto”.

Figura 8: Captura del secret en el servidor Proxy malicioso

Hemos modificado el código del cliente PHP que utiliza el servidor vulnerable, ya que como podéis ver en la imagen en los datos que se envían por POST aparece el parámetro ‘secret’. Para realmente ver los datos del POST, debemos cambiar el parámetro ‘secret’ por ‘body’, y posteriormente construir el dock y ejecutarlo de nuevo. Es un pequeño bug que tiene la prueba de concepto.

Figura 9: Modificación del código PHP de la PoC

La mitigación es obligada si eres vulnerable a HTTPoxy. Para llevar a cabo la mitigación se debe bloquear el uso de la cabecera Proxy cuanto antes. Como se ha visto es realmente sencillo caer en esta vulnerabilidad y el impacto y potencial de ésta es muy alto afectando a dos dimensiones de la seguridad como son la confidencialidad y la integridad de la información.

Autores: Ioseba Palop & Pablo González