انفجر عالم التقنية الجمعة, ال20 من اكتوبر بخبر هجوم كسر تشفير MITM(man in the middle) على خادم jabber.ru / xmpp.ru, اكبر خادم روسي في شبكة XMPP الغير مركزية.
هجوم MITM هو هجوم بهدف كسر تشفير النقل TLS, عبر وجود جهاز يفك التشفير بين المستخدم و الخادم الاساسي.
في هذه الحالة كان الهجوم عبر Transperent proxy (بروكسي لا يقوم بتعديل اي شيء) مع شهادة Let’s encrypt أُصدرت عبر التجاوب مع الاختبارات على نفس عنوان IP الخادم الاصلي.
وهكذا اصبح لدى المُخترق شهادة معتمدة على نفس العنوان(domain) يتصل بها المستخدمين, ثم يفك التشفير ويتنصت على الاتصالات على منفذ 5222 المستخدم لاتصالات STARTTLS لXMPP عبر البروكسي ثم يكمل الاتصال الى الخادم دون ان ينتبه المدير لأي تغيير.
يذكر ان فقط منفذ 5222 هو المتأثر, منافذ اخرى مثل منفذ 5223 المستخدم ل XMPP TLS تعمل بشكل طبيعي.
منفذ 5223
الاختراق كان على خادمين في المانيا من شركة استضافة Hetzner و شركة Linode, والمتوقع انهم كانو مجبرين قانونيا على تطبيق هذا الاجراء.
يذكر ان هذا الخادم معروف في مجتمعات الاختراق.
أكتشاف الهجوم
أُكتشف عندما انتهت الشهادة الخبيثة ولم يتم تجديدها تلقائيا.
حاول مدير الخادم ان يبحث عن مصدر المشكلة, لكن بعد التعمق قليلا, اتضح ان الشهادة المنتهية لم تصدر من الخادم اساسا, وان الشهادة داخل الخادم مجدده دون اي اشكالية, أي ان الخطا كان من شركة الاستضافة, التي لم تقم بتجديد الشهادة الخبيثة.
التحقيق بالحادثة
يذكر ان بسجلات نواة لينكس, ان تم فصل كرت الشبكة لمده 19 ثانية يوم 18 يوليو
[Tue Jul 18 12:58:29 2023] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Down
[Tue Jul 18 12:58:48 2023] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
و وظيفة خادم Linode هي ان يكون عنوان مختلف لتمرير الاتصالات لخادم Hetzner, و أُكتشف ان الاتصالات بين الخادمين تعمل بشكل صحيح, لكن عند الاتصال من خارج يتم اعتراض الاتصال كما حصل في Hetzner.
من المفروض ان تكون مدة الاختراق حول 6 شهور, مع تاكيد 3 شهور, وهي مدة الشهادة الاخيرة من Let’s encrypt.
أكتشاف الهجوم بطريقة افضل
في حالة هذا الهجوم, هو أُكتشف فقط بسبب خطأ تقني من شركة الاستضافة, هل هو مقصود ام لا لا نعلم, لكن بدونه, على الاغلب لن يتم اكتشافة.
هناك ادوات تساعد بهذا:
- Certificate Transparency logs
سجل عام للشهادات المصدرة من قبل ال CAs, ممكن ان تتبع منه الشهادات المصدره لعنوانك.
للاسف لا توجد اداوت جيدة لها, تقوم بفلترة تلقائيه للشهادات التي اصدرتها انت وشهادات اخرى.
- جدولة فحص للتحقق من الشهادة المستخدمة
الخيار الاخر يدوي اكثر, لكنه فعال ايضا, بحيث تجعل خادم اخر يقارن بين الشهادة داخل خادمك والشهادة المستخدمة عند العامة
لكن هناك مشاكل هنا, اهمها ان سجل اصدار الشهادات اختياري ولا توجد به كل الشهادات المصدرة.
صحيح ان المتصفحات اصبحت ترفض الشهادات الغير مسجله, لكن تطبيقات اخرى مثل تطبيقات محادثة XMPP اغلبها لن يتحقق اذا الشهادة سُجلت ام لا.
اما بالنسبة للطريقة الثانية, فقد يصبح الهجوم يستهدف مستخدمين محددين, ولن يظهر في الفحص التلقائي للشهادة.
منع اصدار شهادات خبيثة على العناوين
اهم شيء في هذا الهجوم هي كيفية حصولهم على شهادة موثوقة للعنوان من Let’s encrypt, دون الحاجة للضغط على اي جهه اخرى لاصدار شهادة دون توثيق.
الحل في هذه الحاله هو معيار rfc8657 الذي يضيف نوع جديد من سجلات DNS باسم CAA, يسمح هذا السجل بتحديد اي CA ممكن ان يصدر الشهادة, وحتى يمكن تحديد اي حساب يمكن ان يصدر شهادات لعنوانك, وبما انه يستخدم DNS, للتاكد ان الرد صحيح وليس متلاعب به, المعيار يستوجب تفعيل DNSSEC.
الحساب موثق بمفتاح خاص موجود على الخادم, فاصدار شهادة عبر اعتراض الاتصالات وتقديم ردود لانشاء شهادة لن يكون كاف, بحيث سيحتاجون ان يصلو لمفتاح الحساب داخل الخادم.
لكن هناك ايضا نقاط ضعف هنا:
- اذا اعطيت مفتاح dnssec الخاص لاستضافة DNS, فيمكن ان يتم الضغط عليها لتعطي للتلاعب بالسجل و اعطاء رد خبيث
يذكر انه يمكن استضافة DNSSEC zone دون الحاجه لاعطاء مفتاح التشفير لاي جهه اخرى
-
يمكن ان تضغط هذه الجهات على مقدمين تسجيل العناوين لتغيير مفاتيح dnssec المستخدمة للعنوان, لكن هذه احتمالية ضئيلة لان هذه العملية سهله الاكتشاف.
-
الضغط على الCA نفسة ليصدر شهادة موثقه دون اتباعة للمعايير الامنية المحددة
-
CAs اخرى قد تصدر شهادات دون ان تطبق اخر المعايير الامنية
وهذا اكثر خطر ممكن, لان بلا شك احد منهم لن يطبق اخر المعايير بشكل صحيح.
ولا يُنسى طبعا, اذا لديهم الخادم ولديهم دافع كافي, يمكن استخراج مفاتيح التشفير من داخله سواء عبر قرائه التخزين اذا لم يكن مشفر, او عبر قرائة الرام.
الحل الافضل
استخدم تشفير كامل, الرابح الواضح هنا بلا شك هم مستخدمين التشفير الكامل OMEMO في بروتوكول XMPP
https://en.wikipedia.org/wiki/OMEMO
