مقال: كيفية تنفيذ White Box Testing

عندما تتحدث بعمق عن اختبار الاختراق دائمًا ما تجد مصطلحات كـ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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

OMP Service is Down

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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