Hoy
traemos a la palestra una vulnerabilidad genérica que afecta a varias
implementaciones del protocolo CGI y que permite, de manera trivial, forzar al servidor a usar un proxy controlado
por un atacante.
 |
| ¡nombre, logo y web! |
¿En qué consiste?
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".
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.
¿A qué afecta?
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 tiempo
y 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 Apache
HTTP 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.
Prueba de concepto y más información
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.
Más información:
httpoxy
The CERT vulnerability note - VU#797896
CGI web servers assign Proxy header values from
client requests to internal HTTP_PROXY environment variables
Red Hat advisory
HTTPoxy - CGI "HTTP_PROXY" variable
name clash
Apache Software Foundation Projects and
"httpoxy" CERT VU#797896
Microsoft advisory KB3179800
IIS CGI HTTP_PROXY header requests may be
redirected
Mitigating the HTTPoxy Vulnerability with NGINX
Drupal Core - Highly Critical - Injection -
SA-CORE-2016-003
David García
