مؤخرًا ، أثناء التحقق من أمان موارد الويب الخاصة بالبنك ، وجدنا ثغرة أمنية في خادم البريد Exim 4.89 ، مما قد يؤدي إلى تنفيذ التعليمات البرمجية عن بُعد. تُعرف الثغرة الأمنية CVE-2018-6789. باستخدام ثغرة PoC ، حصلنا على Reverse Shell على الجهاز البعيد ثم الوصول إلى موقع البنك على الويب.
بطبيعة الحال ، تساءلنا لماذا أصبح هذا الاستغلال للضعف ممكنًا.
من أين أتت CVE-2018-6789؟
باختصار ، تعود الثغرة الأمنية إلى خطأ في حساب طول المخزن المؤقت في دالة base64.c: b64decode التي يستخدمها Exim. يمكنك قراءة المزيد عن هذا هنا (باللغة الإنجليزية).
إذا أدخلت سلسلة ذات طول خاص ، يمكنك الكتابة فوق بايت واحد من المعلومات ، وباستخدام إجراءات بسيطة ، يمكنك تغيير أوامر الخادم ، وبالتالي تنفيذ تعليمات برمجية عشوائية (RCE).
يخصص Exim مخزنًا مؤقتًا 3 * (len / 4) +1 بايت للاحتفاظ بالبيانات التي تم فك تشفيرها. ومع ذلك ، إذا تم تغذية سلسلة base64 غير صحيحة لإدخال الدالة ، على سبيل المثال ، 4n + 3 طويلة ، فسيخصص Exim 3n + 1 بايت للمخزن المؤقت. ولكن في نفس الوقت ستكتب 3n + 2 بايت من البيانات في المخزن المؤقت. يؤدي هذا إلى الكتابة فوق بايت واحد في الكومة.
يوفر Exim store_malloc_3 و store_free_3 ، وهما عبارة عن أغلفة للوظائف malloc والوظائف المجانية من Glibc. يخصص Glibc كتلة كبيرة من البيانات ، ثم يخزن البيانات الوصفية الخاصة به في أول 0x10 بايت ويعيد مؤشرًا إلى الذاكرة حيث يمكن للمستخدم كتابة بياناته. هذا ما يبدو عليه:
البيانات الوصفية تتضمن حجم الكتلة السابقة (الموجودة في الذاكرة أعلاه) ، وحجم الكتلة الحالية ، وبعض العلامات. تُستخدم البتات الثلاث الأولى من الحجم لتخزين الأعلام. في المثال ، يشير الحجم 0x81 إلى أن القطعة الحالية هي 0x80 بايت وأن القطعة السابقة قيد الاستخدام بالفعل.
يتم وضع الكتل المحررة ، بمجرد استخدامها بواسطة Exim ، في قائمة مرتبطة بشكل مضاعف. يحافظ Glibc عليه من خلال الأعلام ويدمج الأجزاء المحررة المتجاورة في جزء أكبر لتجنب التجزئة. لكل طلب تخصيص ذاكرة ، يفحص Glibc هذه الأجزاء بترتيب FIFO ويعيد استخدامها.
لتحسين الأداء ، يستخدم Exim الوظيفة الإضافية الخاصة به لإدارة الذاكرة ؛ يعتمد على هيكل المتجر. الميزة الرئيسية لـ storeblock هي أن حجم كل منها لا يقل عن 0x2000 بايت ، مما يصبح قيدًا على الاستغلال. لاحظ أن storeblock هو أيضًا حظر البيانات. هذا ما يبدو عليه في الذاكرة:
الأوامر التي يدعمها خادم البريد لتنظيم البيانات في الكومة:
- EHLO hostname. EHLO hostname sender_host_name. , store_free store_malloc .
- . , , Exim .
- AUTH. Exim base64 . , store_get (). store_get().
- Reset EHLO/HELO, MAIL, RCPT. , Exim smtp_reset. store_reset , « ». , storeblock- store_get .
من أجل استخدام تجاوز كتلة الذاكرة المؤقتة أحادية البايت ، يجب أن نكون قادرين على تحرير كتلة البيانات الموجودة ضمن سلسلة base64 التي تم فك تشفيرها. Sender_host_name مناسب لهذا.
من الضروري تشكيل الكومة بطريقة تترك كتلة البيانات خالية فوق الكتلة التي تحتوي على اسم المضيف.
للقيام بذلك ، تحتاج إلى:
1. وضع كتلة كبيرة في سلة غير مرتبة. بادئ ذي بدء ، نرسل رسالة EHLO باسم مضيف كبير الحجم بحيث تخصص وتحرر جزءًا من الطول 0x6060 في حاوية غير مرتبة.
2. حدد المتجر الأول. ثم نرسل أمرًا غير معروف لاستدعاء store_get () وتخصيص كتلة المتجر داخل القطعة المحررة.
3. حدد الكتلة الثانية وحرر الأولى. نرسل EHLO لاستلام الكتلة الثانية. يتم تحرير الكتلة الأولى بالتسلسل بسبب smtp_reset الذي تم استدعاؤه بعد اكتمال EHLO.
بمجرد تحضير الكومة ، يمكننا استخدامها للكتابة فوق حجم الكتلة الأصلي. نقوم بتعديل 0x2021 إلى 0x20f1 ، مما يوسع الكتلة قليلاً.
4. إرسال بيانات base64 وتجاوز 1 بايت على الكومة. قم بتشغيل الأمر AUTH لإرسال بيانات base64.
5. إنشاء وإرسال سلسلة ذات حجم مناسب. نظرًا لأننا قمنا بتوسيع كتلة البيانات ، فإن بداية الجزء التالي ستقع الآن في مكان ما بالداخل. الآن نحن بحاجة إلى إصلاحه من أجل اجتياز فحص سلامة Glibc. نحن نرسل سلسلة base64 أخرى هنا.
6. حرر الكتلة الموسعة. للتحكم في محتوى الكتلة الموسعة ، نحتاج إلى تحرير الكتلة أولاً ، لأننا لا نستطيع تعديلها مباشرةً. وهذا يعني أنه يتعين علينا إرسال رسالة EHLO جديدة لتحرير اسم المضيف القديم. ومع ذلك ، تستدعي معالجة الأمر EHLO smtp_reset عند التنفيذ الناجح. يمكن أن يؤدي هذا إلى مقاطعة البرنامج أو الإنهاء غير الطبيعي. لتجنب ذلك ، نرسل اسم مضيف غير صالح مثل a +.
7. اكتب المؤشر التالي لقالب المخزن المتداخل.
بعد تحرير القطعة ، يمكننا الحصول عليها بالمصادقة والكتابة فوق جزء من كتلة المتجر المتداخلة. هنا نستخدم تقنية تسمى "التسجيل الجزئي". هذا يسمح لنا بتغيير المؤشر دون كسر ASLR. لقد قمنا بتغيير المؤشر التالي جزئيًا إلى كتلة تحتوي على خطوط ACL. يتم تحديد خطوط ACL بواسطة مجموعة من globals ، مثل uschar * acl_smtp_helo ؛
تتم تهيئة هذه المؤشرات في بداية عملية Exim وتعيينها وفقًا للتكوين. على سبيل المثال ، إذا كان التكوين يحتوي على السطر acl_smtp_mail = acl_check_mail ، فإن مؤشر acl_smtp_mail يشير إلى سطر acl_check_mail.
في كل مرة يتلقى فيها الخادم أمر "MAIL FROM" ، يقوم Exim بإجراء فحص ACL ، والذي يقوم أولاً بتوسيع acl_check_mail. عند التوسيع ، إذا واجه Exim السطر $ {run {cmd}} ، فسيحاول تنفيذ الأمر cmd ، بحيث يمكن للمهاجم البعيد الحصول على التعليمات البرمجية لتنفيذه.
8. إعادة تعيين كتلة المتجر والحصول على مخزن يحتوي على قائمة التحكم بالوصول (ACL). كتلة ACL موجودة الآن على blockchain. سيتم تحريره بعد الانتهاء من smtp_reset () ، ومن ثم يمكننا استعادته مرة أخرى بتخصيص بضع كتل.
9. الكتابة فوق خطوط ACL وتشغيل فحص ACL. أخيرًا ، نعيد كتابة الكتلة الكاملة التي تحتوي على خطوط ACL. نرسل الآن أوامر مثل EHLO و MAIL و RCPT لتشغيل فحص ACL.
بالمناسبة ، تم تسهيل استغلال الثغرة الأمنية بواسطة ASLR المعطل لسبب غير معروف لنا.
ما هي المشاكل التي واجهها العميل؟
الأول هو عدم وجود إدارة التحديث. نظرًا لحقيقة استخدام الإصدار القديم من Exim ، كان من الممكن تنظيم حل وسط للنظام. لتجنب هذا الأمر ، نوصي بتنظيم الفحص المنتظم وتثبيت تحديثات الأمان على مكونات البنية الأساسية للمعلومات.
نوصي بالتحقق من الأمان الجديد والتحديثات الهامة مرة واحدة على الأقل في الشهر. للتحقق من وجود تحديثات ، من الأفضل استخدام المواقع / القوائم البريدية لمصنعي المعدات أو المعلومات من المستودعات.
كما افتقر البنك إلى عملية إدارة الثغرات ، ولهذا السبب لم يتم اكتشاف الثغرة في الوقت المناسب. إن استخدام أدوات فحص الثغرات الأمنية المتخصصة - على سبيل المثال ، OpenVAS ، و Nessus ، و xSpider ، وما إلى ذلك - من شأنه أن يساعد في تصحيح الموقف ، كما أن اختبار الاختراق المنتظم ومراقبة توقيت التخلص من الثغرات الأمنية سيساعد أيضًا.
وأخيرا وليس آخرا. افتقر البنك إلى عملية إدارة التغيير. تم إجراء كافة التغييرات بواسطة المسؤولين في بيئة الإنتاج. وبالتالي ، لم يتحكم أحد أو يراقب ذلك. أدى ذلك إلى حقيقة أنه تم تعطيل ASLR على الخادم.
انتاج |
أدت العديد من الانتهاكات التي لا علاقة لها على ما يبدو إلى اختراق موقع البنك. يمكن استخدام هذا من قبل المجرمين ، على سبيل المثال ، لتغيير التفاصيل المصرفية إلى بياناتهم الخاصة.
القصة انتهت بشكل جيد. بعد التسوية ، أبلغنا العميل على الفور بالموقف. قام البنك على وجه السرعة بتحديث خادم Exim إلى الإصدار الحالي ، والذي لم تعد الثغرة الأمنية ذات صلة به. ومع ذلك ، إذا تم التعرف على الثغرة الأمنية ليس أثناء اختبار الاختراق ، ولكن من قبل مهاجمين حقيقيين ، فقد تكون النتيجة مختلفة.