mpgn/poodle-poc🐩 هجوم بادل (Padding Oracle On Downgraded Legacy Encryption) CVE-2014-3566 🐩
إثبات مفهوم لهجوم Poodle (أوراكل الحشو على التشفير القديم المخفَّض) :
استغلال رجل في المنتصف يستفيد من تراجع عملاء برامج الإنترنت والأمان إلى SSL 3.0
يسمح لك هجوم Poodle باسترجاع البيانات المشفرة التي يرسلها عميل إلى خادم إذا كان أمان طبقة النقل المستخدم هو SSLv3. لا يسمح لك باسترجاع المفتاح الخاص المستخدم لتشفير الطلب.
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
بهذه التقنية يمكنه التأثير على الحشو.
يستخدم SSLv3 أيضًا HMAC للتحقق من سلامة النص الصريح والمصادقة عليه.
رمز مصادقة الرسالة المعتمد على التجزئة بالمفتاح (HMAC) هو نوع محدد من رموز مصادقة الرسائل (MAC) يتضمن دالة تجزئة تشفيرية (ومن هنا جاءت 'H') مع مفتاح تشفير سري.
بفضل هذا، لا يمكن للمهاجم اعتراض الطلب وتعديله ثم إعادة إرساله. إذا واجه الخادم مشكلة، فسيرسل خطأ HMAC.
يستخدم بروتوكول SSLv3 الروتين التالي: يستقبل البيانات من العميل، ويفك تشفيرها، ثم يتحقق من السلامة باستخدام HMAC.
MAC-then-Encrypt: لا يوفر أي سلامة على النص المشفر، حيث لا يمكننا معرفة ما إذا كانت الرسالة حقيقية أم مزيفة حتى نقوم بفك تشفيرها. سلامة النص الصريح. إذا كان نظام التشفير قابلًا للتعديل، فقد يكون من الممكن تعديل الرسالة لتظهر صالحة ولديها MAC صالح. هذه نقطة نظرية بالطبع، لأن سر MAC عمليًا > يجب أن يوفر الحماية. هنا، لا يمكن لـ MAC تقديم أي معلومات حول النص الصريح أيضًا، لأنه مشفر.
https://crypto.stackexchange.com/questions/202/should-we-mac-then-encrypt-or-encrypt-then-mac
هذا يعني أنه يمكننا تعديل النص المشفر دون أن يعلم الخادم بذلك. هذا رائع، حقًا :)
أولاً، يجب أن تكون الكتلة الأخيرة ممتلئة بالحشو، وكما رأينا سابقًا، يستخدم المهاجم مسار الطلب ويتحقق من طول الطلب.
بما أن الكتلة الأخيرة باستثناء البايت الأخير مليئة بالبايتات العشوائية، يمكنه استبدال هذه الكتلة الأخيرة Cn بالكتلة التي يريد فك تشفيرها Ci. يتم إرسال الطلب المعدل إلى الخادم.
الخادم:
باستبدال الكتلة الأخيرة، يغيّر المهاجم أيضًا البايت الأخير من الكتلة الأخيرة (طول الحشو). هناك احتمال 1/256 أن يكون البايت الأخير المستبدل في كتلة الحشو هو نفسه الأصلي، وفي هذه الحالة لن يكون هناك خطأ حشو، ويمكن للمهاجم استخدام عملية XOR هذه لاسترجاع البايت الأخير من الكتلة Ci باتباع العملية التالية:
Pn = Dk(Cn) ⊕ Cn-1
Pn = Dk(Ci) ⊕ Cn-1
Pn = Dk(Ci) ⊕ Cn-1
xxxxxxx7 = Dk(Ci) ⊕ Cn-1
Dk(Ci) = xxxxxxx7 ⊕ Cn-1
Pi ⊕ Ci-1 = xxxxxxx7 ⊕ Cn-1
Pi = Ci-1 ⊕ xxxxxxx7 ⊕ Cn-1
(xxxxxxx7 أو xxxxxxx15 وx بايت عشوائي)
يمكن استرجاع البايت الأخير من الكتلة Pi[7] = Ci-1[7] ⊕ xxxxxxx7 ⊕ Cn-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 |
على الرغم من أن مواصفات TLS تتطلب من الخوادم التحقق من الحشو، إلا أن بعض التطبيقات تفشل في التحقق منه بشكل صحيح، مما يجعل بعض الخوادم عرضة لهجوم POODLE حتى لو عطلت SSL 3.0
TLS آمن عادةً ضد Poodle، لكن بعض التطبيقات لا تتحقق من الحشو، وكأننا نستخدم SSLv3، ولهذا فإن بعض إصدارات TLS معرضة للخطر.
يوجد ثلاثة ملفات في هذا المستودع:
يستكشف إثبات المفهوم هذا التشفير الكامن وراء الهجوم. يسمح لنا هذا الملف بفهم كيفية عمل الهجوم بطريقة بسيطة.
python3 poodle-poc.py
الملف parallelization-poodle.py هو مشروع، وفكرة :) تحقق من https://github.com/mpgn/poodle-PoC/issues/1
python3 parallelization-poodle.py
هذا هو الاستغلال الحقيقي. مفيد جدًا إذا أردت تقديم إثبات مفهوم حول هجوم Poodle لعميل أثناء اختبار الاختراق إذا كان يستخدم خادمًا ومتصفحًا قديمين. فقط ضع عنوان IP للوكيل الخبيث في إعدادات المتصفح مع المنفذ الصحيح، وسيتولى الوكيل الباقي.
المتطلبات:
security.tls.version.min: 0 على سبيل المثال. بدلاً من ذلك، إذا كان العميل يستخدم TLS أيضًا، يمكنك فرض خفض الإصدار.
💀 إذا توافرت لديك هذه المتطلبات الأساسية، يمكنك بدء الهجوم 💀:
خياران متاحان لهذا الاستغلال:
$> echo 1 > /proc/sys/net/ipv4/ip_forward
$> iptables -i vmnet1 -t nat -A PREROUTING -p tcp --dport 1337 -j REDIRECT --to-ports 1337
arpspoof أو ettercap أو bettercap لتنفيذ هجوم انتحال ARP$> bettercap -iface vmnet1
net.show
set arp.spoof.internal true
arp.spoof on
⋊> ~/T/poodle-Poc on master ⨯ python3 poodle-exploit.py -h 13:10:24
usage: poodle-exploit.py [-h] [--start-block START_BLOCK]
[--stop-block STOP_BLOCK] [--simpleProxy SIMPLEPROXY]
proxy port server rport
Poodle Exploit by @mpgn_x64
positional arguments:
proxy ip of the proxy
port port of the proxy
server ip of the remote server
rport port of the remote server
optional arguments:
-h, --help show this help message and exit
--start-block START_BLOCK
start the attack at this block
--stop-block STOP_BLOCK
stop the attack at this block
--simpleProxy SIMPLEPROXY
Direct proxy, no ARP spoofing attack
$> python3 poodle-exploit.py 192.168.13.1 4443 192.168.13.133 443 --start-block 46 --stop-block 50
اختيار كتلة: إذا لم تحدد خيار الكتلة، سيتم فك تشفير جميع الكتل ولكن قد يستغرق ذلك وقتًا طويلاً. أنصحك بشدة أن 'تعرف' كيف سيتم تنسيق الطلب واستخدم السكربت request-splitter.py لمعرفة الكتلة التي تريد فك تشفيرها (يفضل كتلة الكوكيز! :)
ثم أدخل كود جافاسكربت الخبيث (poodle.js) في الموقع الإلكتروني المعرض للخطر باستخدام XSS على سبيل المثال. قم بتشغيل سكربت بايثون واكتب help, ثم search, وأخيرًا active. خلال ذلك الوقت، ستحتاج فقط إلى تفاعلين مع الجافاسكربت (أمرا search و active).
تحديث 01/04/2018: تمت إضافة خيار خفض الإصدار إلى الاستغلال. عندما يكتشف الاستغلال بروتوكول TLS، أدخل الأمر downgrade لخفض الإصدار إلى SSLv3.0.
كيف يعمل؟ أثناء المصافحة (بعد hello client)، يرسل الاستغلال handshake_failure 15030000020228 ثم يجب على المتصفح إعادة إرسال hello client مع SSLv3.0 كبروتوكول افتراضي. تم اختباره على كروم الإصدار 15 لكنه لا يعمل على فايرفوكس (أعتقد أنه لا يدعم إعادة التفاوض على البروتوكول)، تحقق من #4
فيديو كامل للاستغلال:
Asciinema:
