لم أقم منذ فترة طويلة في مجال تكنولوجيا المعلومات ، لكنني في الآونة الأخيرة انجرفت في موضوع الأمن السيبراني. مهنة البنتستر مثيرة للاهتمام بشكل خاص. أثناء التصفح ، رأيت مقالًا رائعًا "كيف سمحت لنا قاعدة البيانات سيئة التكوين بامتلاك سحابة كاملة تضم أكثر من 25 ألف مضيف" بواسطة Security Shenanigans. ترجمة كلا الجزأين ولفت انتباهك.
المقدمة
في هذه المقالة ، ستتعلم كيف تمكنا من إجراء اتصال sqlmap مباشر بقاعدة البيانات باستخدام BMC / IPMI للتغلب على عميل كبير.
خلفية
قبل عامين ، تلقى فريقنا مهمة: إجراء اختبار اختراق البنية التحتية على شبكة Openstack. وهي تتألف من حوالي 2000 خادم فعلي استضافت أكثر من 25000 جهاز افتراضي. بدأنا عملنا على شبكة فرعية صغيرة مع وجود قيود على مقدار حركة المرور الصادرة. بعد إجراء فحص سريع ، لم يتمكن Nmap من العثور على أي ثغرات واضحة يمكن استغلالها. لذلك ، بدأنا في دراسة الخدمات المتاحة لنا. من بينها ، وجدنا خادم PostgreSQL أعزل مستضاف على خادم تطوير. بعد إنشاء قائمة كلمات مخصصة مع العديد من مشتقات اسم الشركة ، تمكنا من التسلل إلى النظام باستخدام بيانات بسيطة نسبيًا من الحساب. كان اسم المستخدم Postgres ، وكلمة المرور كانت "admin".
بعد ذلك ، قررنا استخدامsqlmap . تم تصميم هذه الأداة لاستخدام حقن SQL ، ولكنها يمكن أن توفر لك أيضًا العديد من الخيارات عند إنشاء اتصال قاعدة بيانات مباشر (عندما يكون لديك بيانات الاعتماد الخاصة بك). أحد هذه الخيارات هو تشغيل shell command على قاعدة البيانات في الإنتاج.
بعد اختبار الغلاف ، قررنا إنشاء حمولة مخصصة (حمولة) من أجل الحصول على اتصال عكسي. سيسمح لك ذلك بالعمل بشكل أكثر راحة.
قمنا ببناء الحمولة باستخدام msfvenom. كانت الحمولة في هذه الحالة عبارة عن غلاف TCP عكسي لجهاز Linux x64. في الصورة السابقة ، يمكنك أن ترى أننا بحاجة إلى اختيار بنية قاعدة البيانات.
تجميع الحمولة باستخدام msfvenom
ميزة هذه الحمولة هي أنه يمكن استخدامها لإعادة الاتصال باستخدام Netcat البسيط. تتطلب معظم الحمولات الأخرى شيئًا مثل Metasploit (اختر استغلال / متعدد / معالج) لنفس المهام.
بعد تشغيل الحمولة باستخدام غلاف sqlmap ، حصلنا على اتصالنا بالخادم.
بدء تشغيل Payload - الاتصال الخلفي
واختبار الوصول
استخدام أجهزة BMC
عندما تقوم بإجراء اختبار اختراق البنية التحتية وتهدد جهازًا في قطاع شبكة جديد ، يجب عليك إعادة الفحص لمعرفة ما إذا كان هناك أي شيء جديد في الظهور. سمحت لنا قاعدة البيانات هذه بالاتصال بالشبكة السحابية للشركة ، بما في ذلك معظم الأجهزة الافتراضية والمضيفين. كنا سعداء جدًا بنتائج الفحص الجديد حيث وجدنا العديد من أجهزة BMC.
واحد من ثلاثة أجهزة BMC
يعد BMC (وحدة التحكم في إدارة اللوحة الأساسية ، معالج الخدمة) جهازًا مضمنًا تفضيليًا متصل بالخادم الرئيسي الذي يوفر المراقبة والتحكم خارج النطاق. يعمل بشكل مستقل عن وحدة المعالجة المركزية و BIOS ونظام التشغيل. لا يمكن أن تؤثر الأخطاء التي تحدث في أي من هذه العناصر على تشغيله. يحتوي المتحكم الدقيق على المعالج والذاكرة وواجهة الشبكة الخاصة به ، لذا فهو متاح حتى إذا تم إيقاف تشغيل الخادم نفسه. لدى جميع موردي المعدات الرئيسيين BMCs محددة لمنتجاتهم:
- ديل DRAC
- IBM IMM
- HP iLO
- Supermicro IPMI
هناك مصطلح آخر تحتاج إلى التعرف عليه ، وهو IPMI (واجهة إدارة النظام الأساسي الذكي) ، وهو في الأساس البروتوكول الذي تستخدمه للتواصل مع هذه الأجهزة. والغرض منه هو مراقبة وإدارة أجهزة الخادم ، بغض النظر عن نظام التشغيل ، حتى عند إيقاف تشغيل الخادم ولكن متصل بمصدر طاقة.
دعنا نقول فقط أن IPMI هو أحد أكثر البروتوكولات غير الآمنة التي يمكنك العثور عليها. لإعطائك فكرة ، تم تصميم IPMI 2.0 بطريقة يمكنك من خلالها طلب تجزئة مخصصة مباشرة من الخادم أثناء خطوة المصادقة. توجد ثغرة أخرى عندما تطلب الإذن في وضع "التشفير 0" ، والذي سيسمح لك بتسجيل الدخول بأي كلمة مرور.
IPMI كتلة بنية
الأجهزة BMC التي قد تجدها عادة ما تكون محمية بشكل سيئ، لأنها هي نوع الجهاز الذي تم تكوينه مرة واحدة، في مرحلة تجميع مركز البيانات، ومن ثم استخدامها فقط عندما يكون الملقم غير متوفرة عن طريق الوسائل التقليدية.
تمكنا من المصادقة بسهولة على بعض الأجهزة التي تم تمكين التشفير 0 فيها .
هنا يمكنك معرفة كيفية تسجيل الدخول بكلمة مرور عشوائية. انتبه إلى الجزء "-C 0".
تم تسجيل الدخول بنجاح إلى الجهاز باستخدام كلمة مرور عشوائية
معلومات الشبكة للجهاز
حتى إذا لم يتم تمكين التشفير 0 على بعض الأجهزة ، فلا يزال لديك طرق أخرى لتسجيل الدخول. أشهر نوعين هما إما استخدام بيانات الاعتماد الافتراضية (التي لا يحاول مسؤولو النظام تغييرها عادةً) أو استغلال ثغرة أمنية في الكشف عن التجزئة (ثم كسر التجزئة). يجب أن يتم هذا الأخير لمعظم الأجهزة.
أزواج اسم المستخدم / كلمة المرور الافتراضية العادية لمعظم المستخدمين
قائمة بالكلمات التي تحتوي على تجزئات المستخدمين التي نطلبها من الخادم
توسيع التجزئة المخصصة باستخدام metasploit
نحصل على الفور على بيانات حول التجزئات النموذجية
بعد استعراض جميع التجزئة ، بدأنا في كسرها.
اختراق التجزئات الأولى
في دقيقتين وصلنا إلى حوالي 600 BMC.
تجزئة 609 تم تصدعها بنجاح
كان هناك جهازان من HP ILO لم نتمكن من كسرهما. لحسن الحظ بالنسبة لنا ، فإن HP iLO 4 1.00 حتى 2.50 لديه أيضًا تجاوز للمصادقة. يتيح لك ذلك إنشاء حساب مسؤول عبر تجاوز سعة المخزن المؤقت في رأس اتصال HTTP الذي تتم معالجته بواسطة خادم الويب. يستخدم الاستغلال هذا للحصول على امتياز الوصول إلى بقية واجهة برمجة التطبيقات ، والتي بدورها تمنحك الإذن لإنشاء حسابات.
باستخدام CVE-2017-12542
بعد هذه الخطوات ، حصلنا على سيطرة كاملة على 90٪ من أجهزة BMC الخاصة بالشركة. إذا كنت قد قرأت عن أجهزة BMC ، فأنت تعلم الآن أنها تسمح لك بما يلي:
- مراقب
- اعادة التشغيل
- أعد التثبيت
- KVM (افتراضي)
الأجهزة المتصلة. هذا رائع وكل شيء ، لكنهم يحاكيون فقط الوصول الفعلي إلى الخادم ، وما زلت بحاجة إلى الدخول. نعم ، يمكنك العبث بإيقاف تشغيل الأجهزة ، لكننا اعتقدنا أن ذلك لم يكن كافيًا ، لذلك واصلنا الحفر.
تتمثل إحدى الطرق الأكثر شيوعًا لاختراق الأجهزة التي لها عنوان فعلي في إعادة تشغيلها والتحكم في التشغيل التلقائي لقذيفة الجذر. يمكنك القيام بذلك على أنظمة Unix و Mac و Windows.
تكمن صعوبة هذا الأسلوب في أن كل خادم يستضيف عادةً حوالي 2000 مضيف ظاهري. لذلك ، كنا بحاجة إلى العثور على خادم غير مستخدم. كانت الخطة هي إيقاف تشغيله (أو بدء تشغيله إذا كان قد تم إيقافه بالفعل) وتعديل التشغيل التلقائي لمنحنا حق الوصول إلى الجذر. بعد ذلك ، أردنا أن ننظر في التكوين للعثور على أي أخطاء / حمولات من شأنها أن تسمح لنا بخرق الخوادم الأخرى أيضًا.
يتيح لك Openstack الاستعلام عن البنية التحتية المحلية والاستعلام عن معلمات محددة. أحدها هو حالة الجهاز الظاهري ، والتي تم تعريفها في حالة هذه الشركة المحلية على أنها توفر VM (القائمة البيضاء / السوداء لاستقبال حركة المرور) + حالة التشغيل (بدء / تعطيل).
كنا بحاجة إلى العثور على خادم مدرج في القائمة السوداء (لم تكن حالة العمل مهمة) ووجدنا واحدًا لا يعمل بسبب مشاكل القرص. لحسن الحظ ، تمكنا من التمهيد ، ولكن انتهى الأمر ببعض أجزاء نظام الملفات في وضع القراءة فقط.
طلب Openstack لخادم قرصنة مناسب
بمجرد العثور عليه ، قمنا بتسجيل الدخول باستخدام بيانات الاعتماد التي وجدناها مسبقًا.
استخدام عمليات الوصول التي تم الحصول عليها مسبقًا
الوصول إلى واجهة KVM
تحاكي واجهة KVM الاتصال المباشر بالخادم من خلال BMC. في التمهيد ، تحتاج إلى تعديل التحميل التلقائي لـ Grub والإضافة
ro init = / bin / bashإلى السطر المناسب للتمهيد في غلاف الجذر... عادةً ما يتم استخدام علامة القراءة / الكتابة (rw) ، لكن كان علينا استخدام علامة القراءة فقط (ro) لمنع أي مشاكل في القرص الفاشل.
تحرير قائمة اليرقة
بعد تسجيل الدخول ، قمنا بفحص واجهات الشبكة لاختبار الاتصال بالخادم. كما ترى ، يعرض ifconfig أكثر من 10 واجهات نشطة.
بعد قضاء بعض الوقت في تحليل بنية الشبكة وفهم مكاننا ، بدأنا في دراسة الخادم.
في غضون دقيقتين ، وجدنا حلًا وسطًا مع bash_history (أحد أفضل مصادر المعلومات القيمة التي يمكنك العثور عليها على جهاز Linux)
أوراق اعتماد novadb في bash_history
بالنسبة لأولئك غير المعتادين على بنية Openstack ، فإن Nova هي قاعدة بيانات إدارية تخزن المعلومات الإدارية للسحابة بأكملها ، مثل الشهادات والحصص وأسماء المثيلات والبيانات الوصفية ومعلومات أكثر أهمية .
التحقق من بيانات الاعتماد
بعد تسجيل الدخول ، تحققنا من وصول المسؤول باستخدام Grants_MySQL.
بعد القيام بذلك ، يمكننا رؤية الهيكل الداخلي لـ NovaDB.
الجداول في قاعدة بيانات Novadb
بالنظر إلى المعلومات حول VM ، يمكننا رؤية حوالي 34 ألف جهاز. ومع ذلك ، كان حوالي ثلثهم غير متوفر / لا يعمل. يمكن رؤية المبلغ الدقيق في إدخال السطر float_ips.
اسمحوا لي أن أشرح سبب أهمية هذه البيانات من قاعدة البيانات.
إذا كنت ترغب في إغلاق الشركة بأكملها ، يمكنك إغلاق كل خادم افتراضي من خلال واجهة BMC. لن يعملوا حتى يعيد مسؤول النظام الأمور مرة أخرى.
يمكنك كتابة البرامج الضارة الخاصة بك لإصابة جميع الخوادم ، ولكن النشر الشامل عبر قنوات BMC ليس بالأمر السهل (تذكر أنه كان علينا بدء خادم غير مستخدم لتحرير Grub autorun قبل الوصول إليه).
ومع ذلك ، من خلال الوصول إلى NovaDB ، يمكنك ببساطة إتلاف قاعدة البيانات وستتوقف بيئة السحابة بأكملها عن العمل. حتى لو افترضنا أن مسؤول النظام كان ذكيًا بما يكفي لإلقاء نظرة سريعة على قاعدة البيانات ، فإن استكشاف أخطاء قاعدة البيانات التالفة وإصلاحها أكثر صعوبة من استكشاف أخطاء قاعدة البيانات المفقودة.
أيضًا ، يمكن لمسؤول النظام اكتشاف وجود خطأ ما والكتابة فوق كل شيء بأحدث نسخة احتياطية ، أليس كذلك؟ لقد فكرنا أيضًا في ذلك. هذا هو السبب في أننا مضينا قدما واختراقنا النسخ الاحتياطية.
في البداية حاولنا الاستعلام عن قاعدة البيانات الرئيسية بشيء مثل
SELECT * FROM information_schema.PROCESSLIST AS p WHERE p.COMMAND = 'Binlog Dump'; ، لكن الشركة استخدمت حل النسخ الاحتياطي الخاص بها والذي كان يعمل بشكل غير منتظم ولم يستخدم مخطط رئيسي / تابع. لذلك واصلنا فحص الشبكات الفرعية المجاورة فقط للعثور على قواعد البيانات الاحتياطية التي تعمل على نفس المنفذ مثل المنفذ الرئيسي.
كيف تمكنا من العثور على النسخ الاحتياطية
لقد تحققنا من إمكانية استخدام بيانات الاعتماد الحالية ، وبطبيعة الحال ، توصلنا إليها .
التحقق من الوصول إلى نسخة احتياطية
باستخدام النسخ الاحتياطية الخاصة بنا ، تمكنا من إثبات الاختراق الكامل للبنية التحتية الافتراضية ، بالإضافة إلى طريقة لإنهاء العمليات في دقائق.
أرغب دائمًا في إنهاء المراجعة / التقرير بكتابة الحلول الممكنة للمشكلات التي تم العثور عليها. علاوة على ذلك ، كان هناك الكثير منهم ، على سبيل المثال:
- إعادة استخدام أوراق الاعتماد
- لا يوجد تقسيم للشبكة
- كلمات مرور عادية
- بنية احتياطية غير آمنة
- البرامج الثابتة التي عفا عليها الزمن
كانت إحدى المشكلات المهمة التي لم يكن من السهل إصلاحها هي العيوب الموجودة في بروتوكول IPMI.
سيكون الحل الأكثر نجاحًا هو وضع الخوادم الممكّنة لـ BMC على قطاع شبكة مختلف بقائمة عناوين IP محدودة وخاضعة للتحكم. هذا ما فعلته هذه الشركة في النهاية.
أتمنى أن تكون قد استمتعت بقصتنا. بقدر ما استمتعنا بتعلم هذا الموضوع.