mpgn/poodle-poc🐩 هجوم Poodle (Padding Oracle On Downgraded Legacy Encryption) CVE-2014-3566 🐩
إثبات مفهوم لهجوم Poodle (Padding Oracle On Downgraded Legacy Encryption) :
استغلال رجل في المنتصف يستفيد من تراجع عملاء برامج الإنترنت والأمان إلى 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:
