عندما تتحدث بعمق عن اختبار الاختراق دائمًا ما تجد مصطلحات كـBlack Box Testing وWhite Box Testing وهناك أيضًا الـGray Box Testing. كل هذه المصطلحات تشير إلى أشياء مختلفة، بعيدًا عن الـGray ستجد الفرق الرئيسي بين الـBBT والـWBT هو أنك أثناء تنفيذ لفحص من نوع BlackBox هو أنك تقوم فيه بمحاكاة عملية الاختراق من طرف المستخدم الخبيث بشكل حرفي. بحيث أنك لا تملك أي معلومات وتبدأ من الصفر من خلال مجهوداتك أنتَ فقط. أما في الـWhiteBox فأنت يكون لديك كل المعلومات عن النظام الذي ستقوم بفحصه. وهذه المعلومات يجب أن تحتوي على كل التفاصيل عن أنظمة التشغيل المستخدمة، معلومات عن تطبيقات الويب المتاحة، أنوع وإصدارات الخدمات، وأي معلومات أخرى يحتاجها مختبر الاختراق لإكمال عمله.

الفرق الأساسي بين الـBlackBox والـWhiteBox هو أن أثناء تنفيذ الـWBT لن تكون قلقًا بشأن أي معلومات مغلوطة أنت تجمعها. لأننا كما نعلم أثناء تنفيذنا لـBBT الأدوات التي نعتمد عليها مثلاً قد تعطينا إصدار خدمة بنسبة 80% صحيح مثلاً. وذلك لأن طريقة عملها تعتمد على التخمين اعتمادًا على طريقة الأداة في جمع المعلومات. أما في الـWBT فأنت لن تواجه هذه المشكلة لأنك لديك معلومات مسبقة عن هذه الأمور.

لن أتحدث عن أيهم أفضل لأنه نقاش يطول شرحه. والنتيجة الأفضل لهذا النقاش، هي أن كل فحصه وله وقته. حسنٌ، ما هي خطوات تنفيذ الـWBT!؟ هل هي تختلف كثيرًا عن الـBBT؟ الإجابة هي، لا! فالخطوات مشابهة بشكل كبير، فأنت أثناء تنفيذك للـBBT لا تملك الكثير من المعلومات وتعتمد على مجهوداتك من أجل جمع أكبر قد من المعلومات. وفي الـWBT أنتَ تملك هذه المعلومات. في كلا الحالتين، أنتَ ستقوم بعملية الفحص. فبعد عملية جمعك للمعلومات أنتَ تبدأ عملية الفحص.

حسنٌ، دعنا نرى كيف نبدأ الـWBT!؟ أول خطوة يجب أن تقوم بها وهي تواصلك مع الموظفين والمستخدمين لخدمات الشركة. يجب أن تضع في اختبارك أن هذه الخطوة قد لا تستطيع تنفيذها لعدة أسباب منها: قد يكون مقر الشركة الذي تريد فحصها بعيدة عنك بمسافة طويلة قد تصل لقارات 🙂

إذن، لماذا تعتبر أول خطوة هي التواصل مع الموظفين والمستخدمين؟ سأعطيك مثال: تخيل معي أنك تريد تنفيذ عملية اختبار اختراق لشركة أساس عملها هو بيع المنتجات بشكل أونلاين مثل موقع أمازون مثلاً. مَنْ برأيك أكثر الأشخاص الذين يتعاملون مع الموقع الإلكتروني الخاص بالشركة؟ بدون تفكير، المستخدمين وهذا أولاً، وثانيًا، الموظفين. هذا ما يجب أن تضعه في اعتبارك. فبالتالي، هم أكثر الأشخاص الذين يملكون فكرة عن طبيعة عمل الموقع وإن كانوا يواجهون مشاكل أثناء تصفحهم اليومي للموقع الإلكتروني. في هذه المرحلة يجب أن تجمع أكبر قدر من المعلومات من الموظفين والمستخدمين (End Users). مصطلح End Users يطلق على مستخدم السلعة الأخير، فالسلعة قد تمر خدمة الشحن وتجار وما إلى ذلك. ولكن المستخدم الأخير لسلعة هو ما نطلق عليه هذا المصطلح. إذن فمرحلة التواصل مع الموظفين والمستخدمين أو العملاء. تعتمد بشكل كبير على جمع أكبر قدر من المعلومات عن أي مشاكل يواجهونها، عن أي معلومات تستطيع إخراجها منهم. حتى لو كانت جمعك لكلمات المرور أثناء مرورك على الموظفين.

بعد هذه المرحلة تأتي لجزء مهم جدًا من عملية الـWBT وهو المعلومات المغلوطة، وقد قلت مسبقًا أنه فرق أساسي بين الـBBT والـWBT. فمن المفترض بعد جمعك للمعلومات من الموظفين والمستخدمين أن تتأكد من صحتها. وهذا واجب عليك لأنك لا تستطيع إيصال معلومات مغلوطة في تقريرك النهائي. أما في الـBBT فأنت لا تستطيع تأكيد هذه المعلومات بنسبة 100% لأنك لا تملك أي معلومات مسبقة تستطيع أن تؤكد صحة بياناتك من خلالها.

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

الخطوة الثانية أو المرحلة الثانية في عملية الـWBT هي جمع المعلومات. أو ما يسمى بالـIntelligence Gathering. المعلومات التي تجمعها في هذه المرحلة هي أما ستجمعها من خلال الموظفين أو المستخدمين أو مهندسين الشبكات.

لا يهم من أين تجمعها ولكن الفرق هنا أننا قلنا مسبقًا قد يكون تنفيذ الخطوة الأولى غير ممكنًا لعدة أسباب منها بُعد المسافة مثلاً ولذلك أنت مضطر لتنفيذ Remote Testing. وفي هذه الحالة يمكنك استخدام أدوات فحص كـNessus أو OpenVas أو Nexpose.

في هذا الجزء من المقال سأقوم بشرح بسيط عن أداة OpenVas لأنها أداة مفتوحة المصدر بالإضافة إلى أنها أداة الفحص الأساسية في نظام كالي. قبل استخدامك لأداة OpenVas أن تحتاج لبعض الخطوات أولاً. وصراحة نظام كالي قام بتسهيل العملية بشكل كبير.

تستطيع الوصول لأداة OpenVas من خلال المسار التالي:

Applications > Kali Linux > Vulnerability Analysis > OpenVas

wb_1

أول خطوة يجب أن تقوم بها هي أن تفتح التيرمنال وتكتب :

wb_2

بعد كتابتك للأمر openvas-mkcert في التيرمنال ستظهر لك نافذة تطلب منك بعد المدخلات والتي سترد عليها بالضغط على زر Enter وذلك لاختيار القيم الافتراضية. حتى تصل لنافذة مشابهة للنافذة السابقة تخبرك بـCongratulations فانت قد نجحت في صنع وثيقة لأداة OpenVas بنجاح.

الخطوة التالية هي أن تقوم بعمل Update لما يسمى بـNVT وهي اختصار لـNetwork Vulnerability Tests. وذلك من خلال القائمة كما في الصورة التالية أو من خلال الأمر openvas-nvt-sync:

wb_3

ستظهر لنا النافذة التالية وسننتظر لبعض الوقت حتى ننتهي من تحميل كل التحديثات اللازمة:

wb_4

بعد هذه الخطوة سنقوم بإنشاء وثيقة مستخدم من خلال الأمر التالي:

wb_5

سنقوم بعدها بإعادة بناء الـDatabase من خلال الأمر التالي:

wb_6

هكذا انتهينا من كل شيء وباقي فقط بدأ عمل الأداة وذلك من خلال الأمر التالي:

wb_7

في الصورة السابقة، نرى أننا بعد كتابتنا للأمر، ما يحدث هو أن الأداة تقوم بعمل Load لكل الـPlugins وذلك ما سيتطلب بعض الوقت.

سنقوم بإنشاء مستخدم جديد اسمه iSecur1ty بصلاحيات Admin من خلال الأمر التالي:

wb_8

المستخدم الذي قمنا بإنشاءه في الصورة السابقة هو المستخدم الذي سيملك صلاحيات الأدمن ولكنني لا أحتاج في عمل البرنامج ولذلك سأقوم بإنشاء مستخدم عادي من خلال الأمر التالي:

wb_9

كخطوة أخيرة سأقوم بتحديد البورتات التي أريد أن تعمل عليها الأداة والواجهة الخاصة بالأداة وذلك من خلال الأوامر التالية:

 wb_10

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

فالأوامر التي ستحتاجها فقط في كل استخدام هي:

openvas-nvt-sync
openvasad
openvasmd –rebuild
openvasmd –buckup
openvasmd -p 9390 -a 127.0.0.1
openvasad -a 127.0.0.1 -p 9393
gsad –http-only –listen=127.0.0.1 -p 9392

الآن قم بفتح المتصفح الخاص بك والدخول إلى العنوان التالي:

wb_11

إن واجهت مشكلة في إدخال اسم المستخدم وكلمة المرور وظهرت لك رسالة تقول لك:

OMP Service is Down

اذهب إلى التيرمنال وقم بإدخال الأمر التالي:

wb_12

بعد ذلك سترى هذه الواجهة:wb_13

كما نرى في الصورة السابقة نرى أكثر من قائمة وكل منها يتيح لك العديد من الوظائف:
Scan Management: هذه القائمة تتيح لك التعامل مع وظائف الفحص الجاري حاليًا، والفحوصات المنتهية، وتعديل المهام، والملاحظات وما إلى ذلك.
Asset Management: توفر لك معلومات عن الـHosts.
SecInfo Management: تتيح لك الدخول إلى قاعدة البيانات الخاصة بالـCVE والـNVT.
Configuration: هذه القائمة توفر معلومات عن الأهداف، وإعدادات الفحص، والنتبيهات ومواعيد الفحص وما إلى ذلك.
Extra: توفر لك سلة المهملات، وبعض الإعدادات.
Administration: قائمة الإدارة وتتيح لك بعض الوظائف الخاصة بالأدمن كإضافة مستخدم جديد وما إلى ذلك.
Help: تتيح لك معلومات مساعدة عن كل ما تستطيع فعله بواجهة Greenbone.
بما أننا ناقشنا الآن واجهة Greenbone، دعنا نتحدث عن كيفية تنفيذ فحص على نظام ويندوز كمثال.
من قائمة Configuration، قم باختيار Targets، ولإضافة هدف جديد قم بالضغط على الأيقونة الموضحة في الصورة التالية:

wb_14

ستظهر لنا النافذة التالية :

wb_15

بعد إضافة البيانات والضغط على Create Target ستجد أن هناك هدف جديد تم إضافته لقائمة الـTargets. سنذهب لقائمة Scan Management ونختار New Task لتظهر لنا هذه النافذة:

wb_16

بعد إضافة البيانات والضغط على Create Task، سنجد أنها ظهرت في النافذة الرئيسية للواجهة كما في الصورة التالية:

wb_17

لنبدأ الفحص يجب أن نضغط على أيقونة السهم الموضحة في الصورة السابقة.

wb_18

نرى في الصورة السابقة، أن الفحص ما زال مستمرًا، يمكننا أن نتابع تقدمه من خلال الضغط على الأيقونة الموضحة في الصورة السابقة.
يمكنك الاطلاع على التفاصيل من خلال الضغط على الأيقونة الموضحة في الصورة التالية:

wb_19

في الصورة التالية نرى تفاصيل عن عملية الفحص:

wb_20

نرى في الصورة السابقة، أن عدد الثغرات عالية الخطورة إلى 35 ثغرة، والثغرات متوسطة الخطورة إلى 45، والثغرات المنخفضة الخطورة إلى 10 ثغرات. ويمكننا الدخول إلى التفاصيل الخاصة بالثغرات بالضغط على الأيقونة الموضحة في الصورة السابقة.

wb_21

نرى في الصورة السابقة أننا يمكننا تحميل التقرير بأكثر من إعداد، ومن أهم الأمور في الأداة أننا التقارير الخاصة بالأداة متوافقة مع العديد من الأدوات الأخرى مثل Metaploit وNessus وnmap.
بعد انتهائنا من عملية الفحص سأقوم بعمل Import للتقرير داخل مشروع الميتاسبلويت.

wb_22

ولنرى الـHosts المسجلة في التقرير سنقوم بكتابة أمر Hosts لتظهر لنا النتيجة التالية:

wb_23

نلاحظ في الصورة السابقة أن الأمر يظهر أكثر من Host مع أنني اثناء قيامي بالفحص في أداة OpenVas قمت بعمل فحص على IP واحد وهو 192.168.56.103 وذلك قد يكون لعدة أسباب وهي أنك ربما قمت بتسجيل Hosts في قاعدة البيانات سابقًا، أو أنها Hosts من تقرير سابق.

لحل هذه المشكلة سأقوم باستخدام الأمر workspace وهو الذي سيتيح صنع منطقة أخرى للعمل، وبعدها سأقوم بعمل Import مجددًا للتقرير داخل الـWorkspace التي قمت بإنشائها.

wb_24

سأبحث الآن في قاعدة البيانات عن ثغرة خاصة مثلاً بالبورت 3389:

wb_25

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

wb_26

سنراجع التقرير لنرى أي هذه الثغرات له استغلال جاهز وذلك من خلال البحث في قاعدة بيانات الميتاسبلويت أو في مواقع خاصة باستغلالات الثغرات مثل Exploit-db.
هذه المرحلة تعتبر تمهيدًا للمرحلة التالية وهي Gaining Access والتي ستقوم فيها بعملية الاختراق من خلال استغلال إحدى الثغرات المكتشفة. إن لم تجد استغلالات جاهزة لهذه الثغرات يجب عليك أن تقوم بكتابة استغلال خاص بك لهذه الثغرات.
نأتي الآن لمرحلة الـGaining Access والتي سنقوم فيها باستغلال أكبر قد من الثغرات، فاستغلالك لثغرة واحدة لا تكفي، والحصول على أكبر صلاحيات ممكنة من خلال استغلالك للثغرات.

لدينا العديد من الثغرات للاختيار من بينها، ولكن من الصعب العثور على استغلالات للثغرات الخاصة بالبورت 80، لذلك كمثال على هذه المرحلة سأقوم باستغلال أكثر الثغرات شهرة وهي الثغرة الموجودة في خدمة الـSMB:

wb_27

سأقوم بنقل الـMeterpreter Shell الخاص بي لـProcess أكثر استقرارًا ويمكننا فعل ذلك من خلال الأمر migrate، واختيار رقم الـProcess المراد نقل الـShell إليها.

wb_28

قمت في الصورة السابقة بنقل الـShell وبعد ذلك استخدمت أمر getsystem لإعطاءه صلاحيات من نوع System-Level.
بعد نجاحنا في استغلال أكبر قد من الثغرات المتاحة، نأتي الآن إلى المرحلة قبل الأخيرة وهي مرحلة Covering Tracks، يجب التوضيح أن هذه المرحلة وخاصةً في عملية اختبار الاختراق من نوع WBT قد تكون غير ضرورية. فهذا يعتمد على اتفاقك مع العميل. ولكن لكي يكون المقال الخاص بنا شاملاً فسأقوم بذكر طريقتين من أجل هذه المرحلة.
من الإضافات المتاحة في مشروع الميتاسبوليت والمميزة جدًا ومفضلة إليّ بشكل شخصي هي إضافة الـTimeStomp وهي إضافة تقوم بتعديل ما يسمى بالـMACE. وهي اختصار لـModified، Accessed، Created، Entry Modified.

wb_29

كما نرى في الصورة السابقة، هذا مثال على ما يسمى بالـMACE مع إن قيمة الـEntry Modified غير ظاهرة في الصورة السابقة إلا أنها موجودة في البيانات الخاصة به والتي يمكن استخراجها بأدوات محددة. حسنٌ، دعنا نرى الآن لو قمت بفتح الملف مجددًا وأدخلت بيانات جديدة، ماذا سيحدث لهذه القيم السابقة.

wb_30

نرى أن قيمة Accessed، وقيمة Modified قد تم تغييرها، لأنني قمت بفتح الملف والتعديل عليه.

حسنٌ، دعنا نتخيل هذا السيناريو الذي نقوم فيه بتعديل ملف محدد على النظام الذي قمنا باختراقه، وخوفًا من أن يتم اكتشاف عملية الاختراق سنقوم باستخدام إضافة TimeStomp من أجل إعادة هذه القيم إلى القيم السابقة لعملية التعديل عليها.

wb_31

wb_32

كما نرى في الصورة السابقة، لقد قمت بتغيير القيم الثلاثة المراد تغييرهم لنفس القيم السابقة وهذا سيؤجل على الأقل عملية اكتشاف الاختراق 🙂

wb_33

نرى في الصورة السابقة وتأكيد على نجاح الأمر أن القيم بالفعل عادت إلى القيم القديمة الخاصة بها.
الطريقة الثانية المفيدة في مرحلة Covering Tracks، هي أن حركاتك تتسجل في الـEvent Logs ويمكننا استغلال الميتاسبلويت في حذف هذه السجلات كما هو موضح في الطريقة التالية:

wb_34

كما نرى في الصورة السابقة يوجد العديد وأكثر من ذلك في الـEvent Logs، ليست كلها أنتَ السبب فيها بالطبع، ولكن هذا يعتمد على تحركاتك في النظام.
دعنا نستخدم الميتاسبلويت الآن في حذفها.

wb_35

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

wb_36

بعد ذلك سأقم بفتح أداة Magic Tree ويمكنكم الوصول إليها من خلال المسار التالي:

Applications > Kali Linux > Reporting Tools > Evidence Management > MagicTree

بعد أن نقوم بفتح الأداة، ومن قائمة File سنقوم باختيار Open ونقوم باختيار ملف الـXML الخاص بنا ليظهر لنا بعدها بهذا الشكل:

wb_37

لصنع التقرير الآن الأمر سهل جدًا، وهو أن تذهب لقائمة Report وتقوم باختيار Generate Report، ستظهر لك نافذة جديدة يمكنك الاختيار من بين أكثر من Template وذلك بالضغط على Browse واختيار الـTemplate المناسب لك. ملاحظة مهمة جدًا وهي أنك يجب أن تملك على الأقل LibreOffice لكي تستطيع صنع تقرير باستخدام MagicTree لأنها تستخدمها أثناء عملية التقرير. بعد الضغط على Generate ستجد أن التقرير يفتح بشكل تلاقي في الـLibreOffice أو أي برنامج أخر تستخدمه. وإن لم يكن لديك أي برنامج للخدمات المكتبية مثل LibreOffice فستظهر لك رسالة خطأ.

wb_38

كما نرى في الصورة السابقة، هذا مثال على التقرير الذي تنتجه أداة MagicTree.
يمكنك استخدام كبديل لأداة Magic Tree لإنتاج التقارير أداة مثل Dradis أو OWASP Report Generator.
أعتقد ان بهذا نكون انتهينا من هذا المقال المتعب 🙁 ولكن الممتع في نفس الوقت 🙂
الخلاصة:
لقد قمنا في هذا المقال بشرح خطوات تنفيذ White Box Testing وشرحنا خطواته بشكل عملي. الكثير الكثير يحدث أثناء لتنفيذك لاختبار الاختراق. لذلك كن مستعدًا مع ترسانة الأسلحة الخاصة بك xD
أتمنى أن تستفيدوا من المقال وآسف إن قصرت. وسأراكم في مقالات أخرى إن شاء الله.