يوميات مقالات تعليقات تعليقات خارجية
 
السلام عليكم، أهلا بك في صفحتي الشخصية... الساعة الآن 10:08 PM دقيقة بتوقيت الرياض
 
 

تحديث: كان هناك قطعة ناقصة في المقال لم أنتبه لها، و تم تعديل المقال.

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

على ايه حال، الزين ما يكمل دائما، و صدمني خلال النقاشات أن هذا المستشار لا يعرف ما هي الفزرز Fuzzers و لم يسمع ابدا بالمصطلح و لا يعرف كيف يستغل الهاكرز الثغرات الأمنية security holes، و لم  يسمع كذلك بالـ shell coding فأكتشفت انها موضوع يعرفها المبرمجين أكثر من متخصصي أمن المعلومات.

المهم، بحث في المواقع العربية و لم أجد إلا قليل حول هذا الموضوع، لذلك في هذا الموضوع سنتحدث عن الأخطاء البرمجية التي تسبب ثغرات أمنية و عن الفزرز Fuzzers و كيف يقوم الهاكرز بكتابة الفيروسات و الدود Worms التي تنتشر حول العالم في غضون ساعات لتضرب ملايين الأجهزة في يوم واحد، و كذلك التي يستغلها الهاكر الأذكياء في التحكم بالأجهزة و سرق البيانات و كلمات السر و التجسس.

الأخطاء البرمجية الخطيرة Buffer overflow
 يوجد نوعية من الأخطاء البرمجية التي يرتكبها المبرمجين و تسبب مخاطر أمنية، هذه الأخطاء تسمى buffer overflow، و هي ترتكز بشكل أساسي في مشاكل استخدام الذاكرة، سواء كانت في ستاك Stack (مكدس باللغة العربية) او الهيب Heap، و يمكن توضيحها لمبرمجي السي بالكود التالي:

void main()
{
	char buff[50];
	int j=0;
	while (1)
	{
		int i = getc();
		if (i == '\n') 
			break;
		buff[j] = (char)i;
		j++;
	}
}

هل تستطيع أخي القاريء ان ترى الخطأ البرمجي في الكود السابق؟

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

الخطأ ببساطة هو ان حجم المصفوفة buff يبلغ 50 حرفاً، و تكرر الـ while يقرأ  ما يدخله المستخدم إلى ما لا نهاية حتى يدخل المستخدم Enter و يتوقف حفظ المدخلات في المصفوفة، المشكل هو ماذا لو أدخل المستخدم أكثر من 50 حرفاً، ماذا سيحدث؟.

المتغيرات التي تعرف بالشكل السابق تحفظ في الستاك stack (مكدس باللغة العربية) و يمكن تمثيل الجزء السابق في الذاكرة كالتالي:


المكان المحدد للمصفوفة buff.

و كما هو معروف، فالستاك stack ينزل من الأعلى إلى الأسفل، بمعنى أن بدايته في العنوان العلوي high address حتى العنوان السفلي، أو بكلام آخر، لو كانت الذاكرة تبدا من الصفر إلى ألف، فالستاك يبدأ  من ثلاثمائة على سبيل المثال، و ينزل إلى 280 و 250 حسب عدد المتغيرات الداخلية local variables.

و المشكلة بشكل أدق، هي في عنوان الرجوع Return Address للدالة التي قامت بمناداة الفنكوشة main، فلو أدخل المستخدم أكثر من 50 حرفاً فهذا يعني ان الحرف رقم 51 إلى 54 (4 بايت، حسب نظام العنواين في المعالج) سيلعبون دور لم يصمم لهم (وهو دور عنوان الرجوع Return Address)، فالقيمة التي سيدخلها المستخدم سيأخذها البرنامج خلال التنفيذ على أنها عنوان لفنكوشة أخرى في الذاكرة، حيث كما يعلم مبرمجي السي و السي++ (و مبرمجي الاسمبلي بشكل خاص)، فإن لكل فنكوشة في الستاك Stack (المكدس) سجل يسمى Activation Record و يبدأ بعنوان الدالة التي قامت بمناداتها، و الفنكوشة main بالطبع هي أول دالة يتم مناداتها في البرنامج، و لكن يوجد قبلها دالة وضعها المترجم compiler و عنوانها في الشكل السابق هو 0xA004، و لو قام هاكر محترف بتسجيل عنوان معين بشكل يسمح لكود خاص به بالتنفيذ، سيكون لدينا ما تسميه مايكروسفت Remote Code Exection، أي إمكانية إدخال كود تنفيذي ليس له علاقة بالبرنامج الأصلي.

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

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

و بالمناسبة، هذا الخطأ هو الشيء الذي استغلته سبب دودة Blaster الشهيرة، و هي التي استغلها Code Red، والكثير الكثير من الفيروسات الشهيرة.


الشيل كود Shell Coding

 أعتقد ان التساؤل الذي يدور في رأس كل مبرمج الان هو كيف يكون الخطأ السابق بهذه الدرجة من الخطورة؟ بمعنى ماذا يمكن ان يحدث لو اصبح في برنامجي stack overflow او heap overflow؟، الجواب هو أنه يمكن كتابة شيء اسمه shell code، و هو كود خبيث يرسل كما لو انه مدخلات عادية normal input و لكن في الحقيقة هو كود برمجي بصيغة machine code، يتم التحضير له بكتابة كود سي عادي ثم ترجمته، و بعد ذلك يقوم الهاكر بعملية disassebmly و الحصول على لغة الآلة machine code كتسلسل بالبايتات و يحولها إلى صيغة الهيكس Hex، و يستخدمها كمدخل في البرنامج :).

لكن ان  تتخيل عزيزي القارئ برنامج مثل IIS يستقبل طلبات من الزوار بصيغة HTTP Request و يقوم بقراءتها و تنفيذها، ماذا لو كان في كود قراءة HTTP Request خطأ استخدام في الذاكرة buffer overflow كالسابق؟ يمكن أن يقوم الهاكر بإرسال HTTP Request خبيث، مصمم بحيث يحتوي على شيل كود shell code في بعض أجزاءه حتى يتم يتنفذها في خادم الويب IIS بدون استئذان.

سؤال آخر، متى تكون هذه الأخطاء شديدة الخطورة؟، الجواب هو عندما يكون البرنامج يستقبل مدخلاته من الشبكة، بكلام آخر في التطبيقات الشبكية Network Application.


اكتشاف الأخطاء Fuzzers

الان عرفنا ما هو الخطأ البرمجي الذي يسبب الثغرات الأمنية، و كيف يتم استغلالها، تبقى لنا السؤال الأصعب، و هو كيف يتم اكتشاف هذه الأخطاء في البداية؟، الجواب بكل بساطة عن طريق أدوات للأختبار تسمى الفزرز Fuzzers، حيث تقوم هذه البرامج بإنتاج بيانات خاطئة لكي تسبب ان الخادم ينهار crash، فإذا كان هذا الإنهيار بسبب وصول خاطيء للذاكرة access violation، فهذا بالتأكيد رائحة شديدة التركيز لخطأ buffer overflow.

ايضا من الطرق المشهورة في هذا المجال هو استخدام الرقع الأمنية security patches في اكتشاف هذه الأخطاء، حيث يعمد الهاكرز إلى المقارنة بين الملفات التنفيذية قبل الرقعة و بعدها binary diff، و بهذه الطريقة يكتشفون الجزئية في البرنامج التي تقوم الرقعة بإصلاحها، و هكذا يكتشف الهاكرز ثغرة أمنية جديدة يمكن استغلالها.

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


كتب مفيدة حول نفس الموضوع

مقالات مفيدة حول الموضوع


تقبلوا تحياتي....

نشر بتاريخ Thursday, March 20, 2008 5:37 AM

التعليقات

# re: فن استغلال الثغرات الأمنية Mohannad 3/21/2008 3:10 AM

فعلاً خطأ بسيط لا تلقي له بال وتكون عواقبه وخيمة

الله يعطيك العافية يا أستاذ حسام ، مقال جميل جدا كعادتك

ولو كان في مثال عملي راح يكون شي جميل << يفكر يصير هكر ههههه


# re: فن استغلال الثغرات الأمنية فيصل 4/6/2008 1:40 AM

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


# re: فن استغلال الثغرات الأمنية حرباز ( باسم ) 4/16/2008 6:48 AM

ماشاء الله عليك حسام ،،
شرح وافي رهيب جداً جداً

تمنيت اني لم اعرف الBufferover flow حتى الآن حتى اقراها من شرحك ،،

ياخي انت رهيب

خصوصاً مصطلحاتك العربيه خخخخخخخخخخخخخخخخخخخخخ


تسلم الايادي وتكفى ارجع اكتب كثير لو اي حرف

:$
تحياتي ،، ثقب


# re: فن استغلال الثغرات الأمنية حسام المقحم 5/2/2008 3:17 PM

شكرا لكم جميعا على المرور...
(F)

تحياتي...


# re: فن استغلال الثغرات الأمنية reema 5/19/2008 2:34 PM

رااااائع !

لو أنّ الكل يشرح كما تشرح لما كان لدي صعوبة في الفهم!


العنوان  
الإسم  
الموقع
التعليق   
نص الصورة:
 • التصفح
 » RSS
 

 • المقالات

 » ASP.NET










 • الأرشيف





















 • اليوميات












 • الصور



جميع الحقوق محفوظة،
حسام المقحم 2006م