تم تطوير بروتوكول SSL / TLS في الأصل للمتصفحات ، وأصبح لاحقًا المعيار الفعلي لجميع اتصالات الإنترنت الآمنة. يتم استخدامه الآن للإدارة عن بُعد للبنية التحتية الافتراضية المنتشرة في السحابة ، لنقل تفاصيل مدفوعات العميل من خوادم التجارة الإلكترونية إلى معالجات الدفع مثل PayPal و Amazon ، لإرسال البيانات المحلية إلى التخزين السحابي ، وحفظ المراسلات في برامج المراسلة الفورية ومصادقة الخادم في تطبيقات الهاتف المحمول iOS و Android.

قائمة الحالات التي يتطلب فيها تبادل المعلومات شديدة الحساسية أقصى قدر من الحماية أمر مثير للإعجاب. في هذه المقالة ، سنبحث في كيفية ضمان أمان هذه الاتصالات في الممارسة العملية.

- بروتوكول SSL / TLS: أرادوا الأفضل ...
- ... ولكن اتضح كما هو الحال دائمًا: أمثلة على فشل التحقق من شهادة SSL / TLS
- نقاط الضعف المنطقية لبروتوكول SSL / TLS
- نقاط الضعف الأخرى في تنفيذ بروتوكول SSL / TLS
- السبب الرئيسي لنقاط الضعف في بروتوكول SSL / TLS
- ملعقة من العسل في برميل القطران

بروتوكول SSL / TLS: أردنا الأفضل ...

من الناحية النظرية ، يجب أن يضمن اتصال بروتوكول SSL / TLS الآمن سرية وموثوقية وسلامة اتصالات برنامج العميل والخادم ، حتى في وجود مهاجم متقدم نشط من الشبكة: عندما يتم الاستيلاء على الشبكة بالكامل من قبل العدو ، يتم تسميم DNS ، ونقاط الوصول وأجهزة التوجيه ، ومفاتيح التبديل ويتم التحكم في واي فاي من قبل المهاجم. مهاجم يتحكم ، من بين أشياء أخرى ، في الواجهة الخلفية SSL / TLS. بالإضافة إلى ذلك ، عندما يحاول برنامج العميل الاتصال بخادم شرعي ، يمكن للمهاجم تغيير عنوان شبكة الخادم (على سبيل المثال ، من خلال التسمم DNS) ، وبدلاً من خادم شرعي ، إعادة توجيه العميل إلى خادمه الضار.

يعتمد أمان الاتصالات في مثل هذه الظروف القاسية ، كما تعلمون ، تمامًا على مدى كفاية التحقق من شهادة التشفير التي يقدمها الخادم عند إنشاء الاتصال. بما في ذلك مدى كفاية تنفيذ مجموعة من الأصفار (ciphersuite) ، والتي يستخدمها العميل والخادم عند تبادل البيانات. لكي يكون اتصال SSL / TLS آمنًا تمامًا ، يجب على برنامج العميل ، من بين أشياء أخرى ، التحقق بعناية من:

• شهادة صادرة عن جهة التصديق الحالية ؛
• لم تنته مدة صلاحيتها (أو لم يتم إبطال الشهادة) ؛
• تحتوي قائمة الأسماء المدرجة في الشهادة على المجال الذي تتصل به.

... ولكن اتضح كما هو الحال دائمًا: أمثلة على فشل التحقق من شهادة SSL / TLS

ومع ذلك ، في العديد من التطبيقات والمكتبات ، والتي يعتبر أمان الاتصالات أمرًا بالغ الأهمية ، فإن إجراء التحقق من شهادة SSL / TLS وحتى EV-SSL ، شهادة التحقق الموسعة [4] ، لم تنجح بالكامل. في جميع أنظمة التشغيل الشائعة: Linux و Windows و Android و iOS. من بين البرامج الضعيفة والمكتبات والخدمات الوسيطة ، يمكن تمييز ما يلي [1]:

• مكتبة Java EC2 من Amazon وكافة عملاء الواجهة المستندة إلى مجموعة النظراء مبنية على أساسها.
• SDK الخاصة بتداول Amazon's و PayPal ، المسؤولة عن تسليم تفاصيل الدفع من المواقع (التي يتم فيها نشر البنية التحتية للتجارة عبر الإنترنت) إلى بوابات الدفع.
• "السلال" المدمجة ، مثل osCommerce و ZenCart و Ubercart و PrestaShop ، والتي لا تتحقق من صحة الشهادات على الإطلاق.
• شفرة AdMob المستخدمة بواسطة برنامج الجوّال لعرض إعلانات المحتوى.
• مكونات الواجهة الأمامية ElephantDrive و FilesAnywhere ، المسؤولة عن التفاعل مع التخزين السحابي.
• مكتبة Pusher Android وجميع البرامج التي تستخدم Pusher API للتحكم في المراسلة الفورية (على سبيل المثال ، GitHub's Gaug.es).
• Apache HttpClient (الإصدار 3.x) ؛ اباتشي ليبكلود وجميع اتصالات العميل بخوادم Apache ActiveMQ ، إلخ.
• خدمات الوسيطة Java SOAP ، بما في ذلك Apache Axis و Axis 2 و Codehaus XFire ؛ وكذلك جميع البرامج التي بنيت على أساس هذه الخدمات الوسيطة.
• أدوات تحميل موازنة التحميل المرنة
• تنفيذ Weberknecht من WebSockets.
• بالإضافة إلى جميع برامج الأجهزة المحمولة المبنية على أساس خدمات المكتبات والبرامج الوسيطة المذكورة أعلاه (لفهم ما هي خدمات الوسيطة ، انظر الشكل 1) ؛ بما في ذلك عميل iOS لمزود خدمة استضافة Rackspace.

الشكل 1. ما هي خدمات الوسيطة

بالإضافة إلى ذلك ، في [2] يتم سرد أكثر من مائة من تطبيقات الهاتف المحمول الضعيفة (انظر الشكل 2). بما في ذلك: Google Cloud Messaging من Android ، كلمات مرور مركز أعمال Angie ، عميل شبكة AT&T العالمية ، CapitalOne Spark Pay ، Cisco OnPlus (الوصول عن بُعد) ، الدعم الفني من Cisco ، Cisco Webex ، Cisco WebEx Passwords ، Dominos Pizza ، التجارة الإلكترونية ، Freelancer و Google Earth و Huntington Mobile (Bank) و Intuit Tax Online Accountant و iTunes Connect و Microsoft Skype و Oracle Now و Pinterest و SafeNet (عميل VPN) و SouthWest Airlines و Uber و US Bank - Access Online و WesternUnion و WordPress و Yahoo! المالية ، ياهو! البريد.

الشكل 2. مجموعة صغيرة من قائمة التطبيقات النقالة الضعيفة

نقاط الضعف المنطقية SSL / TLS

اتصالات SSL / TLS لكل هذا والعديد من البرامج الأخرى عرضة لمجموعة واسعة من هجمات MiTM. في الوقت نفسه ، يمكن تنفيذ هجوم MiTM ، غالبًا حتى بدون تزوير الشهادات وبدون سرقة المفاتيح الخاصة التي توقع الخوادم بها شهاداتهم. يمكن تنفيذ هجوم MiTM ببساطة عن طريق استغلال الثغرات المنطقية الموجودة في إجراءات التحقق من شهادة SSL / TLS على جانب برنامج العميل. نتيجة لذلك ، يمكن لمهاجم MiTM ، على سبيل المثال ، جمع الرموز المميزة وأرقام بطاقات الائتمان والأسماء والعناوين ، إلخ. - من أي تاجر يستخدم تطبيقات الويب الضعيفة لمعالجة الدفع.

بائعي البرامج المحمولة الذين يستخدمون نموذج شفرة AdMob لربط تطبيقاتهم بحساب AdMob معرضون أيضًا للخطر - حيث يسمحون للمهاجمين بالحصول على بيانات الاعتماد والوصول إلى جميع خدمات Google الخاصة به. على سبيل المثال ، بسبب التحقق غير الصحيح من الشهادات في برامج المراسلة مثل Trillian و AIM ، يمكن لمهاجم MiTM سرقة بيانات اعتماد تسجيل الدخول لجميع خدمات Google (بما في ذلك Gmail) و Yahoo! وكذلك لخدمات Windows Live (بما في ذلك SkyDrive). تتضمن نقاط الضعف الأخرى التي تؤثر على برنامج الويب الحديث بخلاف المتصفح: استخدام تعبيرات منتظمة غير صحيحة عند مقارنة اسم مضيف ؛ تجاهل نتائج التحقق من صحة الشهادة ؛ الاغلاق العرضي أو المتعمد للتحقق. [1]

نقاط الضعف الأخرى في تنفيذ بروتوكول SSL / TLS

وبالطبع ، يجب ألا ننسى أنه حتى في حالة عدم وجود أخطاء منطقية في تنفيذ بروتوكول SSL / TLS (ما لم يكن بالطبع شخص آخر يؤمن بذلك) ، يمكن التحايل على الحماية بسرقة مفتاح خاص [12] ، باستخدام 0day- يستغل لأشياء مثل لوحات المفاتيح والمتصفحات وأنظمة التشغيل والأدوات المساعدة والبرامج الثابتة [3] ؛ عن طريق تسوية توجيه BGP [10] ؛ أو مهاجمة SSL / TLS على الأجهزة (انظر الشكل 3) [8] و / أو البرامج الجانبية [9].

الشكل 3. هجوم SSL على تجاوز الأجهزة

بالإضافة إلى ذلك ، يمكن للمهاجمين تنفيذ هجمات MiTM غير مرئية عملياً ، وإساءة استخدام آلية التخزين المؤقت لجلسة SSL / TLS المطبقة في فئة SSLSessionCache. تتحقق هذه الآلية من صلاحية الشهادات فقط عند الاتصال الأولي ؛ كما أنه غير قادر على إلغاء جلسة اتصال بشكل صحيح بعد حذف الشهادات من الجهاز. بالإضافة إلى ذلك ، بعد إعادة تشغيل جهاز Android (من خلال خيارات "إعادة التشغيل" أو "إيقاف التشغيل") ، يمكنك الاستمرار في رؤية حركة المرور المشفرة لبعض التطبيقات التي لم تبدأ بعد إعادة التشغيل ، ولكنها عملت قبل إعادة التشغيل. هكذا على سبيل المثال مع خرائط جوجل يحدث. في [2] ، يتم شرح كيف يمكن للمهاجمين ، بفضل عيوب التخزين المؤقت هذه ، تعيين "الشهادات غير المرئية" وإزالتها بشفافية للمستخدم ، ثم إنشاء اتصال شبكة مع أي تطبيق.

الشكل 4. بأثر رجعي من تشفير الضعيفة

تتضمن نقاط الضعف الشائعة الأخرى في تنفيذ بروتوكول SSL / TLS تشفيرًا ضعيفًا (انظر الشكل 4) [5] ، إعادة استخدام GCM (وضع Galois / Counter ؛ مواجهة مع مصادقة Galois) [6] ، خدعة باستخدام CNG (CryptoAPI-NG ) في Schannel (انظر الشكل 5) [7] ، تحقق غير صحيح من سلسلة الثقة [2] ، تحقق غير صحيح من اسم المضيف [11].

الشكل 5. CNG خدعة: سحب الأسرار من Schannel

التحقق غير صحيح من سلسلة الثقة هو موقف يقبل فيه تطبيق الويب تمامًا أي شهادة تشير إلى اسم المضيف الصحيح ، دون التحقق من مرجع الشهادة الذي تم التوقيع عليه. يسمح لك هذا باعتراض وفك تشفير كلمات المرور و / أو أرقام بطاقات الائتمان. وفي بعض الحالات ، قم بحقنة الكود الضار. في برنامج Android ، تخترق هذه الثغرة الأمنية ، على سبيل المثال ، عند إنشاء واجهة مخصصة X509TrustManger تتجاهل استثناءات CertificateException. أو عندما يقوم مطور برامج بإدراج مكالمة إلى طريقة SslErrorHandler.proceed () في رمز مكون WebViews. [2]

التحقق من صحة اسم المضيف هو موقف عندما يقبل تطبيق ويب شهادة دون التأكد من أن المضيف الذي جاءت منه هذه الشهادة مدرج في قائمة المضيفين الموثوق بهم. في برنامج Android ، تخترق هذه الثغرة الأمنية ، على سبيل المثال ، عند إنشاء واجهة HostnameVerifier ، والتي تُرجع TRUE تحت أي ظرف من الظروف. أو عندما يقوم مطور برامج بإدراج مكالمة إلى طريقة SslErrorHandler.proceed () في رمز مكون WebViews. [2]

السبب الجذري للثغرات الأمنية في بروتوكول SSL / TLS

السبب الجذري للغالبية العظمى من هذه الثغرات هو تصميم API الرهيب لمكتبات SSL / TLS (بما في ذلك JSSE و OpenSSL و GnuTLS). بالإضافة إلى التصميم الفظيع بنفس القدر لمكتبات نقل البيانات (مثل cURL و Apache HttpClient و urllib) ، كل منها عبارة عن مجمّع عالي المستوى لمكتبات SSL / TLS. ناهيك عن خدمات الوسيطة (مثل Apache Axis أو Axis 2 أو Codehaus XFire) ، والتي تعد غلافًا من المستوى الأعلى ، والتي تزيد من "كرة الثلج" للتصميم الرهيب أكثر. بدلاً من إجراء حوار مع مطور التطبيقات (غالبًا ما يكون بعيدًا عن برمجة النظام) بلغة يفهمها (من حيث السرية والمصادقة) ، المستخرجة من التفاصيل ذات المستوى المنخفض لتنفيذ بروتوكول SSL / TLS ، تفريغ واجهات برمجة التطبيقات هذه مجموعة من معلمات SSL / TLS ذات المستوى المنخفض على الشخص الفقير غير مفهومة له. أنها تتطلب برامج عالية المستوى لفضح خيارات المستوى المنخفض بشكل صحيح ؛ تنفذ وظائف التحقق من اسم المضيف وتهتم بتفسير القيم التي يتم إرجاعها بواسطة العمليات ذات المستوى المنخفض.

نتيجة لذلك ، يستخدم مطورو التطبيقات واجهة برمجة تطبيقات SSL / TLS بشكل غير صحيح: فهم يخطئون في تفسير تنوع المعلمات والخيارات والآثار الجانبية وقيم الإرجاع الخاصة بهم. على سبيل المثال [1]:

• تحاول مكتبة PHP الخاصة بخدمة المدفوعات المرنة من Amazon تمكين التحقق من صحة اسم المضيف من خلال تعيين المعلمة CURLOPT_SSL_VERIFYHOST على TRUE (في مكتبة cURL). ومع ذلك ، القيمة الافتراضية الصحيحة لهذه المعلمة هي 2؛ إذا قمت بتعيينها قيمة TRUE ، فإن هذه المعلمة غير مرئية للمطور الذي تم تعيين القيمة 1 له ، وهكذا. تم التحقق من الشهادة.
• مكتبة PHP PayPal Payments Standard - حصلت على نفس الخطأ ؛ علاوة على ذلك ، في الوقت الذي تم فيه تحديث التطبيق السابق والضعيف (على سبيل المثال ، تمت إزالة خطأ واحد ، تمت إضافة خطأ آخر).
• مثال آخر هو Lynx ، متصفح موجه نحو النص. يتحقق من الشهادات الموقعة ذاتياً - ولكن فقط إذا كانت دالة التحقق من شهادة GnuTLS تُرجع قيمة سالبة. ومع ذلك ، ترجع هذه الدالة 0 لبعض الأخطاء. بما في ذلك في الحالات التي يتم فيها توقيع الشهادات من قبل هيئة غير موثوق بها. وبسبب هذا ، سلسلة الثقة في الوشق مكسورة.

بالإضافة إلى ذلك ، غالبًا ما يسيء مطورو التطبيقات فهم نوع الأمان الذي تضمنه مكتبة SSL / TLS معينة. لذلك ، في البرية يمكن أن تواجه حالات سريرية عندما في التطبيقات التي تحتاج بشكل أساسي إلى اتصالات آمنة (على سبيل المثال ، التفاعل مع معالج الدفع) ، يتم استخدام مكتبة SSL / TLS التي لا تحقق شهادات SSL / TLS على الإطلاق. الحالات الأكثر جدوى ، لكن الأكثر خطورة هي عندما يقوم مطور أي من طبقات البرمجيات الوسيطة بتعطيل الإجراء للتحقق من شهادات SSL / TLS بصمت (يمكنه القيام بذلك ، على سبيل المثال ، لاختبار النظام ، وبعد الاختبار تنسى إعادة تمكينه). في الوقت نفسه ، من المؤكد أن رمز البرنامج عالي المستوى الذي يستخدم هذه الطبقة الوسيطة هو التأكد من إجراء التحقق من الشهادة. وهكذا غالبًا ما يتم إخفاء أخطاء SSL / TLS في أعماق طبقة أو عدة طبقات وسيطة من المكتبات في وقت واحد - مما يجعل من المستحيل تقريبًا اكتشاف هذه المشكلة.

على سبيل المثال ، في JSSE (Java Secure Socket Extension) ، واجهة SSLSocketFactory API الموسعة تتخطى بصمت التحقق من اسم المضيف إذا تم تعيين حقل "الخوارزمية" في عميل SSL على NULL أو على سلسلة فارغة ، وليس إلى HTTPS. على الرغم من ذكر هذه الحقيقة في الدليل المرجعي JSSE ، فإن العديد من تطبيقات بروتوكول SSL Java تستخدم SSLSocketFactory دون إجراء التحقق من صحة اسم المضيف ...

ملعقة من العسل في برميل من القطران

وبالتالي ، في الواقع ، اتضح أنه في معظم برامج الويب الحديثة بخلاف المتصفح ، فإن التحقق من شهادات SSL / TLS إما تم تعطيله أو تنفيذه بشكل غير صحيح. يوضح الشكل 7 تصنيف نقاط الضعف الحالية لبروتوكول SSL / TLS. بعض من هذه الثغرات الأمنية ، ولكن ليس كلها ، تم وصفها و / أو ذكرها أعلاه. يمكنك التعرف على نقاط الضعف المذكورة ولكن غير الموصوفة من خلال قراءة المواد المدرجة في المراجع.

الشكل 6. تصنيف نقاط الضعف ذات الصلة SSL / TLS

حسنًا ، من أجل إضافة ملعقة عسل إلى برميل القطران ، تجدر الإشارة إلى أنه في [1] تم وصفه بالتفصيل / بطريقة مفهومة / شعبية / بكفاءة كيفية تنفيذ SSL ، مع الإشارة إلى RFC. لم نتوصل أبدًا إلى وصف أفضل ، والذي سيكون دقيقًا تقنيًا وفي نفس الوقت مفهومًا. أيضًا في [1] ، يتم تحليل مكتبات SSL الأكثر شيوعًا ، مع تصنيفها وفقًا لمستوى التجريد (المستوى المنخفض / المستوى العالي). كل ذلك مع المخططات والخوارزميات موجزة في رمز الزائفة. يتم وصف نقاط الضعف لمنتجات محددة بالتفصيل ، مع رموز رمز الخطأ والخطأ. لذلك إذا كان لدى شخص ما فجأة رغبة في إنشاء مثل هذا التطبيق لإطار عمل طبقة المقابس الآمنة / طبقة النقل الآمنة (SSL / TLS) ، والذي سيكون استثناءً للقول "إنهم أرادوا الأفضل ، لكن اتضح كما هو الحال دائمًا" ، [1] بداية مثالية لذلك.