✍️ Firecrawl до версии 2.0.1 позволял авторизованным пользователям настраивать вебхуки так, что они могли стучаться в любые внутренние сервисы компании. В результате пользователь мог задать, например:
http://127.0.0.1:2379/
http://metadata.google.internal/computeMetadata/v1/
http://intranet.corp.local/
То есть вместо обычного вебхука на внешний сервис Firecrawl начинал «стучаться» во внутренние ресурсы инфраструктуры — от etcd до облачных метаданных. На практике это значит, что Firecrawl превращается в прокси к приватным сервисам, до которых извне не добраться!
Уязвимость в Firecrawl на первый взгляд выглядит «обычным» SSRF, но есть важный нюанс. Firecrawl - это ML-парсер, изначально задумывавшийся для автоматического сбора и структурирования веб-контента. В нормальной эксплуатации модель обрабатывает текст и данные извне, однако благодаря SSRF-багу этот «умный парсер» превращается в инструмент разведки внутренней инфраструктуры.
🥺 Именно комбинация ML-модуля (обработка входных сайтов) и гибких вебхуков (интеграция с внешними сервисами) делает уязвимость опаснее. И вместо того чтобы парсить публичные сайты, система по просьбе пользователя начинает ходить в приватные ресурсы компании. По сути, ML-компонент становится троянским конём не по своей воле — его инфраструктура используется в атаках на внутренние сервисы, хотя сам по себе ML-код к багу отношения не имеет.
🫨 Вектор атаки
– Атакующий должен иметь авторизованный доступ к Firecrawl (не аноним!).
– После этого он настраивает webhook URL и Firecrawl выполняет запрос от имени своего сервера.
– Возможные последствия - доступ к внутренним API, метаданным облака, сервисам администрирования.
⚠️ tl;dr
До версии
2.0.1 Firecrawl можно было превратить из ML-парсера в прокси для внутренних сервисов — классический SSRF.