¿Colega, dónde está mi Proxy?

¡nombre, logo y web!

Los autores han decidido llamarla httpoxy (en un futuro habrá asignaturas en las universidades dedicadas a nombrar vulnerabilidades), un juego de palabras con las palabras “proxy” y “poxy“.

La explicación es tremendamente sencilla. Cuando el servidor atiende las peticiones de los clientes (navegadores) le pasa la petición completa al script o ejecutable que hace de CGI, cabeceras incluidas. Al procesar las cabeceras del cliente si se encuentra una cabecera denominada “Proxy” cogerá el valor y lo pondrá como valor de la variable de entorno del servidor “HTTP_PROXY“.

Es típico de CGI funcionar así. A cada cabecera del cliente le antepone el “HTTP_” y la cambia a mayúsculas. No es un defecto que ocurra por procesar cierto valor, simplemente es una colisión de nombres ya que HTTP_PROXY se usa en otros contextos independientes de CGI.

El problema con esta variable de entorno es que le estamos diciendo a todos los procesos, que le hagan caso y la tengan en su entorno, que envíen todas las peticiones HTTP a través de ese proxy.

De este modo, lo que estamos es manipulando al servidor vía CGI para forzar el uso de un proxy. Si tenemos controlado el proxy nos llegarán las respuestas del servidor, con lo que podemos hacer un hombre en el medio con todo el tráfico en texto claro (no, no funcionaría con el tráfico cifrado) o simplemente ralentizar las respuestas para degradar el servicio.

Bien. Tranquilidad. Si tu servidor no sirve un entorno CGI no hay de que preocuparse, en principio. Esto solo afecta a CGI, que es un autentico vestigio de otros tiempos en los que la gente hablaba por teléfonos que residían en pequeños habitáculos puestos en la calle a cambio de insertarles monedas de metal.

Tampoco afecta a FastCGI, alternativa “más moderna” que no usa variables de entorno para comunicar al proceso receptor los valores de las peticiones de los clientes.

Ahora bien, si el entorno del servidor da soporte a CGI la cosa cambia. Como sabemos, CGI es soportado por cualquier lenguaje que se ejecute en el servidor. Incluso llegaron a existir CGIs corriendo sobre bash (en serio, no es broma) o binarios en C (recordad, ¡teléfonos en la calle!) atendiendo peticiones HTTP. Pues bien, algunos lenguajes ya parchearon esta vulnerabilidad hace tiempoy de manera independiente, como Ruby o Perl, pero no todos… hasta que la vulnerabilidad volvió a cobrar protagonismo.

En algo así como un revival, alguien se dio cuenta de que lo que parchearon en algunos lenguajes y herramientas se podía reproducir en otros lenguajes, como por ejemplo PHP (¿Sorprendido?), Python y el recién llegado Go. Además se han parcheado los servidores ApacheHTTP Server y Apache Tomcat para evitar que esto ocurra. Es de esperar que otros lenguajes y herramientas se unan y saquen los oportunos parches ya que este fallo es un error de diseño y por lo tanto transversal a todo el bestiario de librerías, implementaciones y herramientas que usen CGI.

Por cierto si estabas a punto de dejar de leer pensando que no afecta a Microsoft IIS, sí que afecta en cierto modo, como por ejemplo derivado del uso de la librería cURL, tal y como comentan en la nota enlazada.

Los autores nos han dejado un legado para la posteridad en forma de página web con su logo y dominio, como viene siendo costumbre, aquí.

No es recomendable hacer una prueba de concepto en entornos de producción, ya que si funciona todo el tráfico HTTP saliente del servidor se dirigirá al proxy indicado por la petición manipulada, pero si se insiste los autores han dejado código en un repositorio de GitHub.

David García