Inyección CRLF detectada en urllib3, una popular dependencia de Python

El 18 de abril de 2019 se encontró una vulnerabilidad de inyección CRLF en la popular biblioteca de Python urllib3. urllib3 es un cliente HTTP para Python que incluye funciones valiosas, como seguridad para subprocesos, agrupación de conexiones, verificación de SSL/TLS del lado del cliente y más. Se usa ampliamente en el ecosistema de Python, incluso en requests, otra biblioteca popular. De hecho, más de 500 bibliotecas de código abierto usan urllib3. Si tienes un proyecto de Python, es muy probable que urllib3 esté en tu árbol de dependencias.

Ya agregamos la vulnerabilidad a nuestra base de datos. Si Snyk monitorea tu proyecto y detecta que contiene el paquete vulnerable, ya habrás recibido nuestras alertas habituales. Si no es así, puedes analizar gratis el repositorio de código de tu aplicación para saber si la afecta la versión vulnerable de urllib3.

Si descubres que tu aplicación de Python usa la biblioteca vulnerable, actúa de inmediato y actualízala a la versión corregida más cercana, según la recomendación de Snyk en tu árbol de dependencias.

Vulnerabilidad de inyección CRLF

CRLF significa «Carriage Return, Line Feed» (retorno de carro y avance de línea), un término que indica el fin de una línea. Una inyección CRLF consiste en insertar un fin de línea en la aplicación. En el caso de la vulnerabilidad de urllib3, un atacante que controle el parámetro de dirección de la solicitud podría manipular un encabezado HTTP y luego atacar un servicio interno.

La vulnerabilidad se mencionó por primera vez en un informe del rastreador de errores de Python, que describía un problema similar en las bibliotecas urllib2 y urllib (incluidas, respectivamente, en las bibliotecas estándar de Python 2 y Python 3). El comentarista Alvin Chang (nombre de usuario alvinchang) señaló que también pudo reproducir el exploit en la biblioteca urllib3.

Esto dio lugar a la creación de un reporte en el repositorio de GitHub de urllib3 y se publicó una corrección tanto para la serie de versiones 1.24.x como para la serie 1.25.x.

A continuación se muestra la prueba de concepto de la vulnerabilidad, publicada en el rastreador de errores de Python por el usuario ragdoll y adaptada para la versión de urllib3 por alvinchang.

import urllib3

pool_manager = urllib3.PoolManager()

host = "localhost:7777?a=1 HTTP/1.1\r\nX-injected: header\r\nTEST: 123"
url = "http://" + host + ":8080/test/?test=a"

try:
info = pool_manager.request('GET', url).info()
print(info)
except Exception:
pass

# nc -l localhost 7777
GET /?a=1 HTTP/1.1
X-injected: header
TEST: 123:8080/test/?test=a HTTP/1.1
Host: localhost:7777
Accept-Encoding: identity

En este ejemplo, el servidor nc muestra la solicitud HTTP con el contenido del encabezado manipulado: X-injected:header, lo que indica que la inyección del encabezado HTTP se realizó correctamente.

¿Mi proyecto es vulnerable?

¿Quieres saber si tu proyecto es vulnerable? Crea hoy una cuenta gratuita de Snyk y busca vulnerabilidades en tu proyecto. Snyk te mostrará un informe de todas las vulnerabilidades conocidas en tus dependencias de código abierto, incluida la biblioteca urllib3 si usas una versión afectada.

Es importante tener en cuenta que urllib3 suele ser una dependencia indirecta y que podrías tenerla instalada en tu proyecto sin saberlo. Algunas dependencias directas que usan urllib3 no utilizan las partes vulnerables de la biblioteca. Por ejemplo, actualmente parece que la biblioteca requests (que incluye urllib3 como dependencia) no es vulnerable, pero esto podría no ser así en todos los proyectos que dependen de urllib3. Por eso, conviene averiguar si urllib3 está en tu árbol de dependencias.

¿Cómo protejo mi proyecto?

Si descubres que tu proyecto usa una versión vulnerable de urllib3, te recomendamos actualizarla a la versión 1.24.3 o posterior. Esto también te protegerá de otras vulnerabilidades que se han encontrado en la biblioteca urllib3. También te recomendamos revisar el código para detectar usos de urllib2 o urllib (en proyectos de Python 2 y Python 3, respectivamente). Los exploits de estas vulnerabilidades de las bibliotecas estándar aún no se han corregido, por lo que es importante evaluar tu nivel de exposición revisando el código.