Mitigación de la vulnerabilidad HTTPoxy con NGINX

El 18 de julio de 2016, se anunció una vulnerabilidad denominada 'HTTPoxy', que afecta a algunas aplicações web del lado del servidor que se ejecutan en entornos CGI o similares a CGI, como algunas configuraciones FastCGI. Los lenguajes que hasta ahora se sabe que están afectados incluyen PHP, Python y Go.

Se han asignado varios CVE que cubren lenguajes específicos e implementaciones de CGI:

• Servidor HTTP Apache (CVE-2016-5387)
• Apache Tomcat (CVE-2016-5388)
• Ir (CVE-2016-5386)
• PHP (CVE-2016-5385)

Hay un nuevo sitio web que describe la vulnerabilidad , una nota de vulnerabilidad de CERT y una descripción del descubrimiento de la vulnerabilidad . Hay información adicional en el sitio web personal de Dominic Scheirlinck , un desarrollador web de código abierto en Vend.

Esta publicación describe la vulnerabilidad y explica cómo usar NGINX o NGINX Plus para evitar los intentos de explotarla en sus servidores.

La vulnerabilidad existe debido a un conflicto de espacios de nombres. Una interfaz CGI o similar a FastCGI establece variables de entorno basadas en parámetros de solicitud HTTP, y estas pueden anular las variables internas que se utilizan para configurar la aplicação.

Actualmente, la única explotación conocida de esta vulnerabilidad afecta a aplicações web que se ejecutan en entornos CGI y similares a CGI que utilizan ciertas bibliotecas de cliente HTTP para realizar solicitudes HTTP a otros servicios. En este caso, los atacantes pueden potencialmente redirigir las solicitudes internas generadas por la aplicação a un servidor de su elección y así capturar cualquier dato secreto contenido en las solicitudes, como se muestra a continuación.

Puede utilizar NGINX o NGINX Plus para identificar y derrotar los intentos de explotar esta vulnerabilidad. Hacerlo proporciona una forma eficaz de prevenir cualquier ataque, lo que le da tiempo para auditar y actualizar cualquier código afectado.

Cómo se explota la vulnerabilidad HTTPoxy

Para entender cómo funciona esta vulnerabilidad (y cómo proteger su sitio) es necesario comprender cómo las interfaces CGI y similares establecen variables de entorno y cómo algunas bibliotecas de aplicação se configuran mediante variables de entorno.

1 – Las interfaces CGI y similares a CGI definen variables de entorno denominadas HTTP_*

Muchas plataformas de aplicação web utilizan interfaces CGI o similares a CGI para conectar aplicações a un servidor web. Estas interfaces convierten los encabezados de una solicitud HTTP en variables de entorno con el prefijo HTTP_ . Una aplicação puede luego buscar el valor de los encabezados de solicitud (como User-Agent ) inspeccionando su entorno.

Un cliente puede crear variables de entorno arbitrarias (comenzando con HTTP_ ) en el entorno de la aplicación enviando solicitudes con el encabezado apropiado. Por ejemplo, el encabezado de solicitud Foo: bar se convierte en la variable de entorno HTTP_FOO=bar .

Algunas plataformas proporcionan una capa de abstracción que oculta las variables de entorno, como la variable global $_SERVER de PHP. Sin embargo, estas abstracciones se basan en la práctica estándar de CGI y FastCGI de establecer variables de entorno.

Por ejemplo, cuando se ejecuta en modo FastCGI, una aplicação PHP puede determinar el encabezado User-Agent de una solicitud de la siguiente manera:

// Ambos métodos devuelven el mismo resultado$useragent = getenv( 'HTTP_USER_AGENT' );
$useragent = $_SERVER['HTTP_USER_AGENT'];

2 – Algunas bibliotecas de aplicação se configuran a partir de variables de entorno

Una aplicação web compleja extrae funcionalidad de bibliotecas externas. Por ejemplo, a veces las aplicações necesitan realizar solicitudes HTTP a otros servicios (de manera similar a los microservicios) y pueden usar una de las bibliotecas de terceros comunes para hacerlo. Estas bibliotecas a menudo admiten una función llamada Proxy HTTP , que es un servidor intermediario utilizado para retransmitir la solicitud HTTP.

Una forma sencilla de configurar una biblioteca como esta es definir la configuración a través de variables de entorno. La biblioteca PHP Guzzle, ampliamente utilizada, está configurada en parte por una variable de entorno llamada HTTP_PROXY , que se establece en la dirección de un servidor proxy. Si HTTP_PROXY se configura de esta manera, la biblioteca retransmite todas las solicitudes HTTP que genera a la dirección del servidor proxy. El paquete net/http de Go y el módulo Solicitudes de Python también confían e interpretan la variable de entorno HTTP_PROXY de la misma manera.

3 – La naturaleza de la vulnerabilidad

Las bibliotecas descritas en el elemento 2 no fueron diseñadas teniendo en mente interfaces CGI o similares a CGI, y la variable de entorno HTTP_PROXY en la que confían se superpone con el espacio de nombres HTTP_ utilizado por las interfaces CGI y FastCGI como se analiza en el elemento 1.

Al establecer el valor de la variable de entorno HTTP_PROXY en una dirección de su propia elección, los atacantes pueden redirigir y capturar solicitudes HTTP internas generadas por la aplicação. Estas solicitudes pueden contener información confidencial, como claves de autenticación y datos privados, y pueden revelar información sobre API y puntos finales adicionales que pueden explotarse.

Un atacante puede hacer esto enviando una solicitud con un encabezado Proxy , y la interfaz CGI o FastCGI crea obedientemente una variable de entorno llamada HTTP_PROXY para esa invocación de la aplicação. Tenga en cuenta que solo las solicitudes que contienen el encabezado Proxy falso se ven afectadas directamente.

Derrotando el ataque usando NGINX y NGINX Plus

La vulnerabilidad HTTPoxy no afecta directamente a NGINX, pero NGINX y NGINX Plus pueden usarse para detener ataques basados en esta vulnerabilidad.

Cómo comunicarse con una aplicação FastCGI ascendente

Puede utilizar NGINX para “desinfectar” la entrada a la aplicação configurando el parámetro HTTP_PROXY FastCGI en la cadena vacía. Esto elimina el parámetro por completo de la solicitud FastCGI:

fastcgi_param HTTP_PROXY "";

Equilibrio de carga y proxy del tráfico HTTP

Al enviar solicitudes HTTP a una aplicação ascendente, es recomendable configurar cualquier encabezado Proxy como una cadena vacía, en caso de que la aplicação ascendente se esté ejecutando en una plataforma vulnerable:

proxy_set_header Proxy "";

Detectar intentos de explotar la vulnerabilidad

Un proxy no es un encabezado HTTP estándar , por lo que cualquier solicitud que contenga este encabezado puede considerarse sospechosa. Puede utilizar NGINX o NGINX Plus para registrar estas solicitudes sospechosas en un registro de acceso dedicado, aquí llamado badactor.log :

# Definir el formato 'proxylog' en el contexto http{}:log_format proxylog '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'"$http_proxy"';

# Registrar solicitudes con un encabezado Proxy usando el formato 'proxylog'
access_log /var/log/nginx/badactor.log proxylog if=$http_proxy;

Nota : En el contexto de configuración donde coloca esta directiva access_log , anula cualquier registro de acceso definido en un nivel superior en la configuración de NGINX.

Mantenerse seguro

NGINX y NGINX Plus proporcionan una forma efectiva de monitorear y derrotar el ataque HTTPoxy. Utilice las técnicas descritas anteriormente para proteger su aplicação mientras audita, actualiza y prueba su código para eliminar la vulnerabilidad.

Si tiene alguna pregunta, comente esta publicación o, si es suscriptor de NGINX Plus, no dude en ponerse en contacto con nuestro equipo de soporte para obtener ayuda.