Poodle PoC 🐩 🐩 🐩

إثبات مفهوم لهجوم Poodle (أوراكل الحشو على التشفير القديم المخفَّض) :

استغلال رجل في المنتصف يستفيد من تراجع عملاء برامج الإنترنت والأمان إلى SSL 3.0

يسمح لك هجوم Poodle باسترجاع البيانات المشفرة التي يرسلها عميل إلى خادم إذا كان أمان طبقة النقل المستخدم هو SSLv3. لا يسمح لك باسترجاع المفتاح الخاص المستخدم لتشفير الطلب.

1. 🐩 مفهوم الهجوم 🐩

SSLv3 ووضع تشفير CBC

SSLv3 هو بروتوكول لتشفير/فك تشفير وتأمين بياناتك. في حالتنا، يستخدم وضع التشفير المتسلسل CBC. يتم تقسيم النص الصريح إلى كتل وفقًا لخوارزمية التشفير (AES, DES, 3DES) ويكون الطول مضاعفًا للعدد 8 أو 16. إذا لم يملأ النص الصريح الطول، تتم إضافة حشو في النهاية لإكمال المساحة المفقودة. أنصحك بشدة بفتح صورتي التشفير وفك التشفير لقراءة هذا الملف.

التشفير	فك التشفير
Ci = Ek(Pi ⊕ Ci-1), and C0 = IV	Pi = Dk(Ci) ⊕ Ci-1, and C0 = IV

في الأساس، هذه مجرد عملية XOR بسيطة، ويمكنك أيضًا مشاهدة هذا الفيديو (ليس من إعدادي) https://www.youtube.com/watch?v=0D7OwYp6ZEc.

سيتم تشفير الطلب المرسل عبر HTTPS باستخدام SSLv3 مع AES/DES ووضع CBC. خصوصية SSlv3 مقارنة بـ TLS1.x هي الحشو. في SSLv3، يُملأ الحشو ببايتات عشوائية باستثناء البايت الأخير الذي يساوي طول الحشو.

مثال:

T|E|X|T|0xab|0x10|0x02 حيث 0xab|0x10|0x02 هو الحشو.
T|E|X|T|E|0x5c|0x01 حيث 0x5c|0x01 هو الحشو.

أيضًا يمكن ملء الكتلة الأخيرة بكتلة كاملة من الحشو، بمعنى أن الكتلة الأخيرة يمكن أن تكون مليئة ببايت عشوائي باستثناء البايت الأخير.

T|E|X|T|E|0x5c|0x01|0x3c|0x09|0x5d|0x08|0x04|0x07 حيث |0x5c|0x01|0x3c|0x09|0x5d|0x08|0x04|0x07 هو الحشو، وفقط 0x07 معروف لدى المهاجم. لذا إذا كان المهاجم قادرًا على التأثير في كتلة الحشو، فسيكون قادرًا على معرفة أن البايت الأخير من الكتلة الأخيرة يساوي طول الكتلة.

التأثير على الحشو

يجب أن يكون المهاجم قادرًا على جعل الضحية يرسل الطلبات (باستخدام جافاسكربت عبر استغلال XSS على سبيل المثال). بعدها يمكنه التحكم في المسار والبيانات لكل طلب:

مثال: إضافة بايت "A" إلى مسار الطلب

GET / HTTP/1.1\r\nSECRET COOKIE\r\n\r\n
GET /AAA HTTP/1.1\r\nSECRET COOKIE\r\n\r\nDATA

بهذه التقنية يمكنه التأثير على الحشو.

HMAC

يستخدم SSLv3 أيضًا HMAC للتحقق من سلامة النص الصريح والمصادقة عليه.

رمز مصادقة الرسالة المعتمد على التجزئة بالمفتاح (HMAC) هو نوع محدد من رموز مصادقة الرسائل (MAC) يتضمن دالة تجزئة تشفيرية (ومن هنا جاءت 'H') مع مفتاح تشفير سري.

بفضل هذا، لا يمكن للمهاجم اعتراض الطلب وتعديله ثم إعادة إرساله. إذا واجه الخادم مشكلة، فسيرسل خطأ HMAC.

MAC-then-encrypt

يستخدم بروتوكول SSLv3 الروتين التالي: يستقبل البيانات من العميل، ويفك تشفيرها، ثم يتحقق من السلامة باستخدام HMAC.

MAC-then-Encrypt: لا يوفر أي سلامة على النص المشفر، حيث لا يمكننا معرفة ما إذا كانت الرسالة حقيقية أم مزيفة حتى نقوم بفك تشفيرها. سلامة النص الصريح. إذا كان نظام التشفير قابلًا للتعديل، فقد يكون من الممكن تعديل الرسالة لتظهر صالحة ولديها MAC صالح. هذه نقطة نظرية بالطبع، لأن سر MAC عمليًا > يجب أن يوفر الحماية. هنا، لا يمكن لـ MAC تقديم أي معلومات حول النص الصريح أيضًا، لأنه مشفر.

https://crypto.stackexchange.com/questions/202/should-we-mac-then-encrypt-or-encrypt-then-mac

هذا يعني أنه يمكننا تعديل النص المشفر دون أن يعلم الخادم بذلك. هذا رائع، حقًا :)

2. 🔑 التشفير 🔑

أولاً، يجب أن تكون الكتلة الأخيرة ممتلئة بالحشو، وكما رأينا سابقًا، يستخدم المهاجم مسار الطلب ويتحقق من طول الطلب.

• يحفظ طول التشفير الأصلي
• يضيف بايتًا واحدًا إلى المسار ويتحقق من الطول.
  • إذا لم يتغير الطول، يضيف بايتًا آخر وهكذا.
  • وإلا: يتغير طول الطلب المشفر، فيعرف أن الكتلة الأخيرة ممتلئة بالحشو.

بما أن الكتلة الأخيرة باستثناء البايت الأخير مليئة بالبايتات العشوائية، يمكنه استبدال هذه الكتلة الأخيرة C_n بالكتلة التي يريد فك تشفيرها C_i. يتم إرسال الطلب المعدل إلى الخادم.

الخادم:

• يزيل الحشو وفقًا لطول البايت الأخير
• يستخرج HMAC من الطلب = HMAC
• يستخرج النص الصريح
• يقارن hmac(plaintext) مع HMAC
  • إذا تساويا => حشو جيد
  • وإلا => حشو سيئ

باستبدال الكتلة الأخيرة، يغيّر المهاجم أيضًا البايت الأخير من الكتلة الأخيرة (طول الحشو). هناك احتمال 1/256 أن يكون البايت الأخير المستبدل في كتلة الحشو هو نفسه الأصلي، وفي هذه الحالة لن يكون هناك خطأ حشو، ويمكن للمهاجم استخدام عملية XOR هذه لاسترجاع البايت الأخير من الكتلة C_i باتباع العملية التالية:

P_n = D_k(C_n) ⊕ C_n-1
P_n = D_k(C_i) ⊕ C_n-1
P_n = D_k(C_i) ⊕ C_n-1
xxxxxxx7 = D_k(C_i) ⊕ C_n-1
D_k(C_i) = xxxxxxx7 ⊕ C_n-1
P_i ⊕ C_i-1 = xxxxxxx7 ⊕ C_n-1
P_i = C_i-1 ⊕ xxxxxxx7 ⊕ C_n-1

(xxxxxxx7 أو xxxxxxx15 وx بايت عشوائي)

يمكن استرجاع البايت الأخير من الكتلة P_i[7] = C_i-1[7] ⊕ xxxxxxx7 ⊕ C_n-1[7] في حالة خطأ الحشو، يحتاج المهاجم إلى إغلاق جلسة SSL للقيام بمصافحة جديدة (مفتاح AES جديد) والحصول على تشفير جديد ثم استبدال الكتلة الأخيرة وما إلى ذلك (عمومًا يلزم أكثر من 300 مصافحة).

بمجرد استرجاع بايت واحد، سيحصل على جميع البايتات الأخرى في الكتلة بإضافة بايت إلى المسار وإزالة بايت واحد من البيانات:

الطلب لاسترجاع البايتات E,I,K,O
GET /a SECRET_COOKIE dataazerty PADDING_7
GET /aa SECRET_COOKIE dataazert PADDING_7
GET /aaa SECRET_COOKIE dataazer PADDING_7
GET /aaaa SECRET_COOKIE dataaze PADDING_7

حول TLS1.0

على الرغم من أن مواصفات TLS تتطلب من الخوادم التحقق من الحشو، إلا أن بعض التطبيقات تفشل في التحقق منه بشكل صحيح، مما يجعل بعض الخوادم عرضة لهجوم POODLE حتى لو عطلت SSL 3.0

TLS آمن عادةً ضد Poodle، لكن بعض التطبيقات لا تتحقق من الحشو، وكأننا نستخدم SSLv3، ولهذا فإن بعض إصدارات TLS معرضة للخطر.

3. 💥 ابدأ الهجوم 💥

يوجد ثلاثة ملفات في هذا المستودع:

• poodle-poc.py -> إثبات مفهوم لا يتطلب أي متطلبات مسبقة
• parallelization-poodle.py -> إثبات مفهوم آخر لكن باستخدام التوازي (سريع حقًا)
• poodle-exploit.py -> استغلال لسيناريو حالة حقيقية

1. ملف poodle-poc.py

يستكشف إثبات المفهوم هذا التشفير الكامن وراء الهجوم. يسمح لنا هذا الملف بفهم كيفية عمل الهجوم بطريقة بسيطة.

python3 poodle-poc.py

2. ملف poodle-poc.py

الملف parallelization-poodle.py هو مشروع، وفكرة :) تحقق من https://github.com/mpgn/poodle-PoC/issues/1

python3 parallelization-poodle.py

3. ملف poodle-exploit.py

هذا هو الاستغلال الحقيقي. مفيد جدًا إذا أردت تقديم إثبات مفهوم حول هجوم Poodle لعميل أثناء اختبار الاختراق إذا كان يستخدم خادمًا ومتصفحًا قديمين. فقط ضع عنوان IP للوكيل الخبيث في إعدادات المتصفح مع المنفذ الصحيح، وسيتولى الوكيل الباقي.