BEAST-PoC (هجوم النص الصريح المختار)

يركز إثبات المفهوم هذا على التشفير الكامن وراء هجوم BEAST (استغلال المتصفح ضد SSL/TLS) الذي قدمه Thai Duong و Juliano Rizzo في 23 سبتمبر 2011. هذا هجوم نص صريح مختار ويتيح لك استرجاع معلومات حساسة إذا كان أمان طبقة النقل المستخدم هو TLS1.0 أو SSLv3. يمكن العثور على إثبات المفهوم الأصلي هنا: Here come the Ninjas

ملاحظة: هذا أيضًا تنفيذ للثغرة التي اكتشفها في الأصل Phillip Rogaway. اُكتشفت في عام 2002، ولم يُطرح أي استغلال حتى BEAST في عام 2011. لقد عرف OpenSSL بالفعل المشكلة ولهذا قاموا بتحديث TLS1.0 إلى TLS1.1 في أبريل 2006.

2 إن IV الخاص بـ CBC لكل سجل باستثناء السجل الأول هو آخر كتلة نص مشفر من السجل السابق. وبالتالي فإن التشفير ليس آمنًا ضد المهاجمين الذين يمكنهم اختيار النصوص الصريحة بشكل تكيفي;

كن BEAST

1. SSLv3/TLS1.0 ووضع تشفير CBC

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

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

سأقدم IV في النقطة التالية. تذكر أن كل هذه الخصائص ستساعدنا في تنفيذ هجومنا.

2. علم التشفير

عندما نستخدم CBC نحتاج إلى متجه تهيئة يُسمى IV. هذا IV عشوائي (أو ثابت) لكن في أي حال يجب ألا يكون قابلاً للتنبؤ من قبل أي شخص. في TLS1.0 وSSLv3 يكون أول IV في الطلب عشوائيًا، حسنًا. لكن لكسب بعض الوقت وعدم توليد IV عشوائي جديد في كل مرة، استخدم تنفيذ TLS1.0 وSSLv3 آخر كتلة من النص المشفر السابق كـ IV. بعبارة أخرى، أصبح IV قابلاً للتخمين الآن. سنفترض أن طول كل كتلة سيكون 8 (DES) وأن المهاجم يملك MiTM لاسترجاع كل النص المشفر.

مثال:

C₀ | C_... | C_i-1 | C_i | C_i+1 |C_n

الآن الجزء المثير للاهتمام، هذه هي الخطوات التشفيرية المختلفة للهجوم لاسترجاع بايت واحد:

• أولاً نرسل طلبًا يُسمى C² للحصول على آخر كتلة من النص المشفر، أي IV التالي للطلب الثاني
• هذا هجوم نص صريح مختار، لذا يمكن للمهاجم إرسال هذه الرسالة bbbbbbbTHIS_IS_A_SECRET_COOKIE عبر الضحية.

يمكنك ملاحظة سبعة b قبل الكوكيز السرية. إذا كان طول الكتلة 8، نحتاج إلى دفع 7 بايتات معروفة. هذه المعلومة مهمة جدًا، فالمهاجم يعرف أول 7 بايتات من الكتلة الأولى.

ولكن لماذا؟ هذا يتيح لنا فقط 256 احتمالًا للعثور على بايت واحد وليس 256^8 للعثور على 8 بايتات!

الآن يرسل الضحية الطلب وسيُشفَّر على النحو التالي:

C₀ | C₁ | C₂ | C₃ | C₄

حيث C₀ = E_k(IV ⊕ bbbbbbbT) = E_k(C²_n ⊕ bbbbbbbT)

• يريد المهاجم استرجاع المعلومات في الكتلة C₀ C₁, C₂ ... إنه يحتاج دائمًا إلى الكتلة السابقة
• يُرسَل طلب ثالث بعد بناء كتلة خاصة P'₀. سيُشفَّر أول كتلة على النحو التالي: C'₀ = E_k(P'₀ ⊕ IV') بما أن هذا هجوم نص صريح مختار، يمكن للمهاجم بناء كتلة P'₀ على النحو التالي:

P'₀ = C²_n ⊕ C₄ ⊕ bbbbbbbX

العنصر الوحيد غير المعروف هو X، وهناك 256 احتمالًا لذا سيجرّب 256 حرفًا كحد أقصى. يُرسَل الطلب ويُشفَّر على النحو التالي:

C'₀ = E_k(P'₀ ⊕ IV')
C'₀ = E_k(C²_n ⊕ C₄ ⊕ bbbbbbbX ⊕ IV') أو C₄ ⊕ IV' = 0
C'₀ = E_k(C²_n ⊕ bbbbbbbX)
C'₀ = E_k(IV ⊕ bbbbbbbX)

الآن يقارن: C'₀ مع C₀، إذا كانا متساويين، فقد وجد للتو البايت X في الموضع 8. إذا لم يتطابق، يعيد المحاولة بحرف آخر ويقارن مجددًا، وهكذا.

الآن لدينا بايت واحد، ويمكننا الحصول على بايت آخر عبر إزاحة الطلب السابق بمقدار واحد إلى اليسار: bbbbbbTHIS_IS_A_SECRET_COOKIE. لديه الآن ستة b ونعرف أيضًا T، إذن لدينا حرف واحد غير معروف. نبني P'₀ جديدًا = C₀ ⊕ C₄ ⊕ bbbbbbTX، وهكذا...

ملاحظة: طريقة أخرى باستخدام طلبين فقط هي تعيين أول كتلة من النص الصريح واستخدام هذه المعلومات في عمليات XOR الثلاث. لم نعد بحاجة إلى آخر كتلة من C². C₁ = E_k(C₀ ⊕ bbbbbbbT) ثم P'₀ = C₀ ⊕ C₄ ⊕ bbbbbbbX. كما يحتاج إلى مقارنة C'₀ مع C₁. هذه طريقة أخرى للقيام بذلك، يمكنك ملاحظة أنني في PoC قمت بترميز الاحتمالين :)

يمكننا الآن استرجاع كل الأحرف!

التشغيل

python BEAST-poc.py

الهجوم

لا يمكن للمهاجم استخدام بروتوكول HTTP لأن الكتلة الأولى ستُملأ بـ GET / HTTP/1.1\r\n.

... لا يمكنه التحكم في البايتات الأولى من كل طلب لأنها دائمًا ما تكون سلسلة ثابتة مثل GET / أو POST /، وما إلى ذلك. وبدلاً من ذلك يمكنه استخدام socket.

كما يحتاج إلى حقن بعض جافاسكربت في صفحة خبيثة. يجب أن يكون الضحية متصلاً بهذه الصفحة وأن يبقى فيها حتى اكتمال الهجوم. هذا هجوم نص صريح مختار، لذا يمكن للمهاجم إرسال عبر كود الجافاسكربت أي نص صريح يريده واعتراض النتيجة عبر رجل في المنتصف (Man in The Middle). هذا مخطط الهجوم:

يتطلب هذا الهجوم شروطًا مهمة ليكون ناجحًا (TLS1.0 أو ما هو أدنى، وضع تشفير CBC، MiTM، جافاسكربت خبيث). لكن Thai Duong و Juliano Rizzo أثبتا أنه ممكن وعرّضا استغلالهما بسرقة كوكيز من موقع Paypal.

كل شيء أصبح مُصلَحًا الآن، واحتمال تنفيذ هذا الهجوم ضئيل.

المساهم

mpgn

التراخيص

رخصة MIT

المراجع

• http://netifera.com/research/beast/beast_DRAFT_0621.pdf
• http://www.bortzmeyer.org/beast-tls.html
• http://fr.slideshare.net/danrlde/20120418-luedtke-ssltlscbcbeast
• http://crypto.stackexchange.com/questions/5094/is-aes-in-cbc-mode-secure-if-a-known-and-or-fixed-iv-is-used
• http://security.stackexchange.com/questions/18505/is-beast-really-fixed-in-all-modern-browsers
• https://defuse.ca/cbcmodeiv.htm
• http://stackoverflow.com/questions/22644392/chrome-websockets-cors-policy