HTTPoxy: así co­m­pro­me­ten las brechas de seguridad a las apli­ca­cio­nes CGI

Una gran cantidad de proyectos web recurre a se­r­vi­do­res proxy para mejorar el re­n­di­mie­n­to y la seguridad. Estos prácticos programas funcionan como in­te­r­fa­ces de co­mu­ni­ca­ción entre el cliente y la página web y aligeran la carga del servidor web ha­cié­n­do­se cargo de so­li­ci­tu­des HTTP edi­tá­n­do­las, re­en­viá­n­do­las y re­s­po­n­die­n­do a ellas. Debido a una brecha de seguridad conocida como HTTPoxy, puede que algunos atacantes abusen de esta técnica para robar datos. En ello se ven afectadas las apli­ca­cio­nes que se basan en el estándar CGI (Common Gateway Interface) y que llevan consigo variables co­n­fi­gu­ra­bles, es decir, las llamadas variables de entorno. A partir de las variables co­rre­s­po­n­die­n­tes, algunos programas pueden leer la co­n­fi­gu­ra­ción del proxy, lo que re­pre­se­n­ta un problema en caso de que los cri­mi­na­les manipulen dichos ajustes.

Cuando un servidor web se comunica vía Common Gateway Interface con el cliente de un usuario, el estándar 3875 prevé que los en­ca­be­za­dos de todas las so­li­ci­tu­des HTTP enviadas se guarden como variables de entorno. Estas variables están formadas por el prefijo “HTTP_” y por el nombre del en­ca­be­za­do en ma­yú­s­cu­las. En el caso detallado, se trata del en­ca­be­za­do “Proxy”, que genera la variable HTTP_PROXY de manera au­to­má­ti­ca. Esta se destina, por lo general, a la co­n­fi­gu­ra­ción de los ajustes del proxy. Si la apli­ca­ción CGI localiza o ejecuta una solicitud que comprende HTTP_PROXY, esta se desvía a través del servidor proxy.

Esta ci­r­cu­n­s­ta­n­cia permite que los atacantes pongan en juego su propio servidor proxy y, de esta manera, tengan acceso a in­fo­r­ma­ción co­n­fi­de­n­cial. Para lograrlo, el servidor envía una solicitud HTTP con el en­ca­be­za­do Proxy y un valor co­rre­s­po­n­die­n­te (por ejemplo, la dirección IP del proxy), de modo que las pe­ti­cio­nes futuras de los usuarios, ya sean entrantes o salientes, se desvíen hacia este. En función del escenario elegido, el atacante puede enviar de vuelta y a su antojo sus propios datos o leer en vía directa los datos que introduce el usuario.

La vu­l­ne­ra­bi­li­dad HTTPoxy, cuyo nombre no tiene un si­g­ni­fi­ca­do especial, llamó la atención por primera vez en marzo de 2001. El pro­gra­ma­dor Randal L. Schwartz la descubrió en la bi­blio­te­ca libwww-perl del lenguaje de pro­gra­ma­ción Perl y así se lo tra­n­s­mi­tió a Gisle Aas, el de­sa­rro­lla­dor de dicha bi­blio­te­ca. Este solucionó la brecha de seguridad in­me­dia­ta­me­n­te en la ac­tua­li­za­ción 5.51, mientras que los nombres de las variables a través de los que se controla la co­n­fi­gu­ra­ción del proxy se mo­di­fi­ca­ron en CGI_HTTP_PROXY. Durante el mismo año también salió a la luz la vu­l­ne­ra­bi­li­dad en el programa de tra­n­s­fe­re­n­cia de datos curl, con lo que el de­sa­rro­lla­dor Daniel Stenberg adaptó el software, de modo que en lo sucesivo solo afectara a las variantes http_proxy escritas en minúscula para la de­te­r­mi­na­ción del servidor proxy —de­s­ta­ca­n­do al mismo tiempo que, en general, esto no es su­fi­cie­n­te para los sistemas Microsoft, aunque las versiones actuales de Windows ya no pre­se­n­ta­rían este problema.

Alrededor de una década después, en julio de 2012, el equipo de Ruby se topó con la pro­ble­má­ti­ca HTTPoxy ya olvidada durante la im­ple­me­n­ta­ción de la clase NET::HTTP, una API para los clientes HTTP diseñada para las apli­ca­cio­nes hechas con Ruby. Para evitar el problema, se retira al HTTP_PROXY su estatus de variable estándar. En los años si­guie­n­tes, las apli­ca­cio­nes de servidor web NGINX (2013) y Apache (2015) formaron parte de los casos más famosos en los que los usuarios más pe­r­s­pi­ca­ces in­fo­r­ma­ron a los de­sa­rro­lla­do­res de los posibles riesgos.

En 2016, el equipo de seguridad de la empresa de de­sa­rro­lla­do­res Vend puso de ma­ni­fie­s­to que la vu­l­ne­ra­bi­li­dad HTTPoxy, aun 15 años después de que saliera a la luz, todavía co­n­s­ti­tuía un riesgo para PHP y otros lenguajes de pro­gra­ma­ción, así como en bi­blio­te­cas, siempre y cuando esta se usara en co­m­bi­na­ción con CGI o con un entorno en tiempo de ejecución equi­pa­ra­ble con variables co­n­fi­gu­ra­bles. Muchas apli­ca­cio­nes afectadas que permiten la uti­li­za­ción de HTTPoxy fueron cla­si­fi­ca­das como es­pe­ci­fi­ca­cio­nes oficiales para las brechas de seguridad, lo que se conoce como CVE (Common Vu­l­ne­ra­bi­li­ties and Exposures o, en español, ex­po­si­cio­nes y vu­l­ne­ra­bi­li­da­des comunes):

• CVE-2016-5385: PHP
• CVE-2016-5386: Go CVE-2016-5387: Apache HTTP Server
• CVE-2016-5388: Apache Tomcat
• CVE-2016-6286: spiffy-cgi-handlers for CHICKEN
• CVE-2016-6287: CHICKEN’s http-client
• CVE-2016-1000104: mod_fcgi
• CVE-2016-1000105: Nginx cgi script
• CVE-2016-1000107: Erlang inets
• CVE-2016-1000108: YAWS
• CVE-2016-1000109: HHVM FastCGI
• CVE-2016-1000110: Python CGIHa­n­d­ler
• CVE-2016-1000111: Python Twisted
• CVE-2016-1000212: lighttpd

In­de­pe­n­die­n­te­me­n­te de si gestionas un servidor web propio o no, HTTPoxy plantea riesgos desde el momento que te internas en la World Wide Web. En caso de que el servicio web visitado se desvíe de manera no deseada a través de so­li­ci­tu­des HTTP externas, la co­n­se­cue­n­cia puede ser que tus datos pasen a manos des­ho­ne­s­tas. Para que disminuya el riesgo de pérdida de datos, es pre­fe­ri­ble optar por páginas web pro­te­gi­das a través de un ce­r­ti­fi­ca­do TLS/SSL y tra­n­s­mi­tir in­fo­r­ma­ción cifrada. En este sentido sigue siendo posible re­di­re­c­cio­nar los datos a través de un proxy falso, y es que los cri­mi­na­les obtienen muy pocos be­ne­fi­cios o, en el mejor de los casos, ninguno de estos datos pro­te­gi­dos. Para los gestores de las páginas web propias, es im­pre­s­ci­n­di­ble hoy en día hacer uso del ce­r­ti­fi­ca­do HTTPS. Sin embargo, siempre está la opción de evitar HTTPoxy si­m­ple­me­n­te eli­mi­na­n­do la vu­l­ne­ra­bi­li­dad. Puesto que el en­ca­be­za­do Proxy no se aferra ni a un estándar de la IETF (Internet En­gi­nee­ri­ng Task Force) ni está re­gi­s­tra­do como en­ca­be­za­do oficial en la IANA (Internet Assigned Numbers Authority), se puede in­te­r­ce­p­tar sin ninguna objeción antes de que alcance a tu apli­ca­ción web. Los clientes HTTP es­tá­n­da­res y los se­r­vi­do­res no envían ningún paquete de datos que contenga dicho en­ca­be­za­do. En principio, además del cifrado del in­te­r­ca­m­bio de datos en HTTP, puedes recurrir a dos po­si­bi­li­da­des para que las so­li­ci­tu­des pe­li­gro­sas se mantengan alejadas de tu proyecto web:

1. Puedes filtrar el en­ca­be­za­do Proxy de todos los paquetes entrantes.
2. Puedes bloquear de manera au­to­má­ti­ca todos los paquetes entrantes que contengan un en­ca­be­za­do Proxy.

La primera variante está mucho más extendida que la segunda y puede llevarse a cabo con ayuda del software habitual para se­r­vi­do­res web, se­r­vi­do­res proxy y el balance de carga. A co­n­ti­nua­ción te pre­se­n­ta­mos in­fo­r­ma­ción sobre cómo se puede extraer el en­ca­be­za­do po­te­n­cia­l­me­n­te peligroso con ayuda de apli­ca­cio­nes de se­r­vi­do­res web como Apache y NGINX o con el software de se­r­vi­do­res proxy HAProxy en di­fe­re­n­tes di­s­tri­bu­cio­nes Linux.

Evitar HTTPoxy con Apache

Por defecto, el software libre Apache está instalado en todas las di­s­tri­bu­cio­nes Linux y para muchos sigue siendo hasta ahora la primera opción cuando se trata de gestionar los se­r­vi­do­res web propios. El co­m­po­ne­n­te esencial del programa es, entre otros, el módulo mod_headers, que permite filtrar el en­ca­be­za­do Proxy de todas las so­li­ci­tu­des HTTPS entrantes. El modus operandi revela algunas di­fe­re­n­cias entre las di­s­tri­bu­cio­nes.

Ubuntu y Debian:

El primer paso consiste en activar el módulo con el siguiente comando:

Abre el archivo de co­n­fi­gu­ra­ción central de Apache con un editor. A este respecto se re­co­mie­n­da nano, la he­rra­mie­n­ta de líneas de comandos utilizada en el ejemplo:

Amplía este archivo con la siguiente entrada al final:

Tras haber guardado el archivo, activa la pro­te­c­ción contra HTTPoxy cargando el archivo de co­n­fi­gu­ra­ción es­pe­ci­fi­ca­do mediante el script a2enconf y reinicia el servidor:

CentOS y Fedora:

Si utilizas una versión de las di­s­tri­bu­cio­nes de Linux CentOS o Fedora, el módulo mod_headers suele estar activado por defecto, por lo que puedes saltarte este paso y abrir di­re­c­ta­me­n­te el archivo de co­n­fi­gu­ra­ción:

Al final de este debes incluir la entrada nueva:

Por último, guarda los cambios y reinicia el servidor Apache:

Cómo eliminar variables HTTP_PROXY con NGINX

NGINX es una co­n­so­li­da­da apli­ca­ción de servidor web que goza de una po­pu­la­ri­dad cada vez mayor. Con ayuda del software open source solo se necesitan unos pasos para proteger las apli­ca­cio­nes CGI que se ejecutan en el servidor o entre el cliente y el servidor de las brechas de seguridad conocidas como HTTPoxy.

Ubuntu y Debian:

No­r­ma­l­me­n­te, los pa­rá­me­tros FastCGI (FastCGI es una op­ti­mi­za­ción del estándar CGI) en Ubuntu y Debian están incluidos en los archivos fastcgi_params o fastcgi.conf cuando se configura un proxy FastCGI con NGINX. En ambos archivos se puede colocar el en­ca­be­za­do Proxy en las so­li­ci­tu­des HTTP. Utiliza para ello las si­guie­n­tes líneas de comandos:

Podrás filtrar el en­ca­be­za­do siempre y cuando utilices NGINX como proxy HTTP co­n­ve­n­cio­nal. Para ello, introduce la regla co­rre­s­po­n­die­n­te en el archivo proxy_params, en el que se es­pe­ci­fi­can los pa­rá­me­tros para el servidor proxy:

Por último, se reinicia NGINX con el siguiente comando:

CentOS y Fedora:

El pro­ce­di­mie­n­to para eliminar el peligro del HTTPoxy para los proxys FastCGI, que se pueden gestionar con CentOS o Fedora, no se di­fe­re­n­cia del método necesario para los sistemas Ubuntu y Debian. Puesto que los ajustes en NGINX también se definen para estas di­s­tri­bu­cio­nes o en el archivo fastcgi_params o en fastcgi.conf, elimina el en­ca­be­za­do Proxy con el comando pre­via­me­n­te definido:

Para proteger proxys inusuales en Fedora y CentOS, hay que ga­ra­n­ti­zar que el en­ca­be­za­do está bloqueado en todos aquellos lugares en los que NGINX ejecuta la directiva proxy_pass. Para averiguar dónde se puede aplicar, se puede recurrir a los servicios del comando grep:

A co­n­ti­nua­ción, recibirás una lista de los archivos de texto en los que se tiene que ejecutar la directiva, donde la entrega tiene el aspecto del siguiente ejemplo:

En este caso, se es­ta­ble­ce­ría proxy_pass en el archivo de co­n­fi­gu­ra­ción de NGINX. Se tiene que completar la entrada co­rre­s­po­n­die­n­te en nginx.conf de la siguiente manera:

El último paso consiste en reiniciar el servidor:

¿Cómo puedes proteger tu servidor HAProxy de HTTPoxy?

Si se tra­n­s­mi­ten so­li­ci­tu­des HTTP a través de un servidor HAProxy hacia tu proyecto web, puedes eliminar el en­ca­be­za­do Proxy antes de que el proxy envíe las so­li­ci­tu­des. El pro­ce­di­mie­n­to es el mismo para las di­fe­re­n­tes di­s­tri­bu­cio­nes de Linux. Lo primero es abrir el archivo de co­n­fi­gu­ra­ción central de la apli­ca­ción del proxy con el siguiente comando:

De esta manera se abre el archivo haproxy.cfg con nano, el editor de líneas de comando utilizado arriba. Si en la in­s­ta­la­ción has indicado un di­re­c­to­rio al­te­r­na­ti­vo para HAProxy, es necesario que adaptes el comando co­rre­s­po­n­die­n­te. En el archivo abierto puedes integrar una directiva de so­li­ci­tu­des HTTP para las tres secciones “frontend”, “backend” y “listen” y dicha directiva elimina el en­ca­be­za­do indeseado. El resultado es el siguiente:

Guarda los cambios y reinicia el servicio HAProxy:

Para hacer uso del servicio, solo es necesario incluir el URL de la apli­ca­ción web que tiene que ser analizada en el campo de entrada y hacer clic en “Test”.