PHP, Python y otras aplicaciones de sitios web exponen una vulnerabilidad de proxy remoto: httpoxy

[Shenzhen] Yuanchuanghui: 17.26, el salón de fiestas te está esperando”.

Esta es una vulnerabilidad dirigida a aplicaciones CGI en PHP, Go, Python y otros lenguajes.

httpoxy es el nombre de una familia de vulnerabilidades que afectan a las aplicaciones que se ejecutan en forma CGI o similar a CGI. En pocas palabras, es un problema de conflicto de espacio de nombres.

RFC 3875 (CGI) define cómo Proxycompletar directamente las variables de entorno desde el encabezado de la solicitud HTTPHTTP_PROXY
HTTP_PROXYEs una variable de entorno comúnmente utilizada para configurar agentes salientes.

Esta falla permite ataques remotos. Si está ejecutando un programa PHP o CGI, ¡debe bloquear el encabezado Proxy inmediatamente! ¡inmediatamente! Consulte a continuación para obtener instrucciones específicas. httpoxy es una vulnerabilidad de la aplicación web del lado del servidor. Si no implementa este código en el lado del servidor, no debe preocuparse.

¿Qué pasa si mi aplicación web tiene esta vulnerabilidad?

Cuando un cliente HTTP que explota esta vulnerabilidad realiza una solicitud, puede:

Solicitudes de proxy a otras URL a través de su aplicación web
Solicite directamente a su servidor que abra la dirección remota y el puerto especificados
Desperdicia los recursos del servidor y accede a recursos específicos para los atacantes.

La vulnerabilidad httpoxy es muy fácil de explotar. Con suerte, el personal de seguridad escaneará esta vulnerabilidad lo antes posible y la solucionará rápidamente.

¿Cuáles se ven afectados?

Pueden existir vulnerabilidades de seguridad en las siguientes situaciones:

El código se ejecuta en un contexto CGI, que HTTP_PROXYse convierte en una variable de entorno real o simulada.
Un HTTP_PROXYcliente HTTP confiable que admite la funcionalidad de proxy
El cliente iniciará una solicitud HTTP (o HTTPS) dentro de la solicitud.

Las siguientes situaciones son entornos donde se ha encontrado este defecto:

idioma	ambiente	cliente HTTP
PHP	php-fpm mod_php	Tragar 4+ Artax
Pitón	wsgiref.handlers.CGIHandler retorcido.web.twcgi.CGIScript	peticiones
Ir	net/http/cgi	red/http

Ciertamente, hay muchos lenguajes y entornos en los que no hemos identificado defectos.

PHP

La existencia de la falla depende del código de su aplicación y de la biblioteca PHP, pero el impacto parece ser muy generalizado.
Siempre que se utilice una biblioteca con esta falla en el proceso de procesamiento de solicitudes de los usuarios, es posible que se explote.
Si usa una biblioteca con esta falla, la falla afecta cualquier versión de PHP.
- Incluso puede afectar entornos de ejecución de PHP alternativos, como HHVM implementado en modo FastCGI.
Está confirmado que bibliotecas como Guzzle y Artax están afectadas, y puede que haya muchas más bibliotecas que también se vean afectadas.
- Guzzle 4.0.0rc2 y versiones posteriores se ven afectadas, Guzzle 3 y versiones inferiores no se ven afectadas
- Otros ejemplos incluyen la clase de utilidad StreamContextBuilder de Composer.

Por ejemplo, si usa el módulo Guzzle 6 en Drupal para iniciar solicitudes salientes (como solicitar una API meteorológica), las solicitudes iniciadas por el módulo tendrán este defecto httpoxy.

Pitón

El código Python sólo es defectuoso cuando se implementa en modo CGI. En términos generales, el código defectuoso utiliza wsgiref.handlers.CGIHandlerun controlador CGI .
- Las aplicaciones web Python implementadas de forma normal no se ven afectadas (la mayoría de las personas usan WSGI o FastCGI, estos dos no se ven afectados), por lo que hay muchas menos aplicaciones Python afectadas que PHP.
- wsgi no se ve afectado porque os.environ no está contaminado por datos CGI
Se debe confiar en la biblioteca de solicitudes defectuosas y utilizarla os.environ['HTTP_PROXY'], y no realiza verificación de contenido.

Ir

El código Go debe implementarse bajo CGI para verse afectado. El código generalmente afectado utilizará net/http/cgiel paquete.
- Al igual que Python, esta no es la forma habitual de implementar Go como aplicación web. Por lo que son muy pocos los casos de verse afectados.
- En comparación, el paquete de Go net/http/fcgino establece variables de entorno reales, por lo que no se ve afectado.
net/httpEs necesario confiar en la versión defectuosa y utilizarla en solicitudes salientes HTTP_PROXY, sin verificación de contenido.

Arréglalo ahora

ProxyLa mejor solución es bloquear los encabezados de solicitud antes de que ataquen su aplicación . Es fácil y seguro.

Se dice que es seguro porque Proxyel encabezado de la solicitud no está definido por el IETF y no figura en el registro de encabezados de mensajes de la IANA . Esto indica que el uso de este encabezado no es estándar y ni siquiera se usa ad hoc.
Los clientes y servidores HTTP que cumplen con los estándares nunca deben leer ni enviar este encabezado
Puede eliminar este encabezado de la solicitud o bloquear solicitudes usándolo por completo.
Puede solucionar este problema usted mismo si upstream no lanza un parche
- Verificar las solicitudes HTTP a medida que llegan puede corregir muchas aplicaciones defectuosas a la vez
- Selección de aplicaciones detrás de servidores proxy inversos y firewalls de aplicaciones ProxyLos encabezados de solicitud son seguros

La forma de bloquear Proxylos encabezados de solicitud depende de su configuración. La forma más sencilla es bloquear este encabezado en el firewall de su aplicación web o directamente en Apache y Nginx. Aquí hay algunos consejos sobre cómo hacer esto:

Nginx/FastCGI

Utilice la siguiente declaración para bloquear los encabezados de solicitud pasados a PHP-FPM y PHP-PM. Esta declaración se puede colocar en fastcgi.conf o fastcgi_param (según el archivo de configuración que utilice):

fastcgi_param HTTP_PROXY "";

PHP tiene defectos en el modo FastCGI (pero la mayoría de los demás lenguajes que usan Nginx FastCGI no se ven afectados).

apache

Para conocer el alcance específico del impacto en Apache, así como en otros proyectos de software de Apache, como Tomcat, se recomienda consultar el anuncio oficial de la Apache Software Foundation . Aquí hay algunos mensajes clave:

Si utiliza el servidor HTTP Apache mod_cgipara ejecutar scripts escritos en Go o Python, se verán afectados (donde HTTP_PROXYlas variables de entorno son "reales"). Dado que mod_phpse utiliza en scripts PHP, este defecto también existe.

Si utiliza el módulo mod_headers , puede desarmar Proxylos encabezados de solicitud antes de seguir procesando la solicitud con la siguiente configuración:

RequestHeader unset Proxy early

Si usa el módulo mod_security , puede usar una SecRuleregla para rechazar Proxysolicitudes con encabezados de solicitud. Aquí hay un ejemplo, asegúrese de que SecRuleEngineesté activado. Puedes ajustarlo según tu propia situación.

SecRule &REQUEST_HEADERS:Proxy "@gt 0" "id:1000005,log,deny,msg:'httpoxy denied'"

Finalmente, si utiliza Apache Traffic Server, éste no se ve afectado. Sin embargo, puede usarlo para eliminar el encabezado de solicitud de Proxy y proteger otros servicios detrás de él. Consulte la guía de ASF para obtener más detalles .

HAProxy

Elimine el encabezado de la solicitud mediante la siguiente configuración:

http-request del-header Proxy

Barniz

Para cancelar este encabezado, colóquelo en la sección vcl_recv existente:

sub vcl_recv {
    [...]
    unset req.http.proxy;
    [...]
}

OpenBSD retransmitido

Utilice la siguiente declaración para eliminar este encabezado. Ponlo dentro de un filtro existente:

http protocol httpfilter {
    match request header remove "Proxy"
}

lighttpd（<= 1.4.40）

Rebota Proxysolicitudes que contienen encabezados.

Cree un /path/to/deny-proxy.luaarchivo y hágalo de solo lectura para lighttpd con el siguiente contenido:

if (lighty.request["Proxy"] == nil) then return 0 else return 403 end

Modifique lighttpd.confpara cargar mod_magnetel módulo y ejecute el código lua anterior:

server.modules += ( "mod_magnet" )
magnet.attract-raw-url-to = ( "/path/to/deny-proxy.lua" )

lighttpd2 (en desarrollo)

ProxyQuite los encabezados de las solicitudes . Agregue la siguiente declaración lighttpd.conf:

req_header.remove "Proxy";

La corrección de PHP del lado del cliente no tiene ningún efecto

No existen soluciones del lado del usuario para resolver la falla, así que no se moleste:

El uso unset($_SERVER['HTTP_PROXY'])no afectará getenv()el valor devuelto, por lo que es inútil
El uso putenv('HTTP_PROXY=')no tiene ningún efecto (putenv solo puede afectar los valores de las variables de entorno reales, no los encabezados de solicitud)

Historia de httpoxi

La vulnerabilidad se descubrió por primera vez hace 15 años.

En marzo de 2001, Randal L. Schwartz descubrió este defecto en libwww-perl y lo solucionó.

En abril de 2001, Cris Bailiff descubrió este defecto en el rizo y lo solucionó.

La falla fue descubierta por Akira Tanaka del equipo Ruby en julio de 2012 en la implementación Net::HTTPdeHTTP_PROXY

La falla se mencionó en la lista de correo de nginx en noviembre de 2013. El descubridor Jonathan Matthews no estaba tan seguro, pero resulta que tenía razón.

Stefan Fritsch lo mencionó en febrero de 2015 en la lista de correo httpd-dev de Apache.

La falla fue descubierta por Scott Geary del equipo de seguridad de Vend en julio de 2016 y afecta a muchos lenguajes de programación y bibliotecas modernos como PHP.

Entonces, esta falla ha estado latente durante muchos años, y muchas personas han descubierto su existencia en diferentes aspectos, pero no han considerado su impacto en otros lenguajes y bibliotecas. Los investigadores de seguridad han creado un sitio web específicamente para este propósito: https://httpoxy.org/ donde puede obtener más información.