رتبها

سوف نتناول اليوم موضوع
Linux x64 buffer overflow
تحتاج في هذا الشرح مبدئيًا :
⁃gdb debugger
⁃يا حبذا لو كان مع peda extension
- تطفي الـ ASLR
⁃قهوه + حلى
⁃كل خلية عصبيه تتواجد بجمجمتك
ملاحظه؛ اذا قفل مخك وقف قراءة وخذ لك بريك وارجع بعدين اقرا من جديد

ملاحظه ثانيه؛ راح استطرد بالكلام واقول شغلات ممكن ما تضرك اذا ما عرفتها ولا تنفعك حيل في البفر اوفر فلو فف عشان كذا بحط على التغريده الي احس انها مو مهمه بالشرح علامة * وطوفها اذا ودك

كوني انسان احط المعلومات بتسلسل قصصي عشان افهم السالفه كامله، ببدا من اول ما يصحى الكمبيوتر ( يشتغل (boot)) الى ان يتم اختراقه عن طريق ثغرة البفر اوفر فلو، وبما ان الخرق الامني يصير بالـ Main Memory(RAM) بنركز على الرام

*بالبداية اول ما يشتغل الكمبيوتر ويسوي boot يكون بالـ Main Memory(RAM) فوق اعلى شي (بداية الرام) الـ OS وكل ما يحتاجه عشان يستمر بالتشغيل، بعدين يصير داخل الرام غرف او اماكن شاغره للـ Processes وهذي الغرف اول ما يشتغل برنامج ( process) ويصير بالـ CPU تنحجز له غرفه هنا بالرام

*زين داخل الغرفه شنو فيه ؟ داخله stack و heap و data section و text section، الي يهمنا منهم هو الستاك
الستاك كل ما تحجز فيه بفر (او خنسميه كوب) يكون الزيادة باتجاه الاسفل ( كل ما تحجز كوب يصير تحت الكوب الي انحجز او انوضع قبله )

ولكن ولكن ولكن طريقة تعبئة الكوب هذا بالداتا من تحت لفوق وهذا منطقي جيب كوب ماي وحط فيه قطره ماي راح تلقى ان القطره هذي مكانها صار باسفل الكوب وكل ما زدت الماي قام يطلع الماي فوق باتجاه سطح الكوب

زين بعد ما شرحنا البيئة المحيطه، خنقول ان عندنا هذا السورس كود لبرنامج، يقوم بالبداية باستدعاء func() والي بدورها تاخذ من اليوزر input والي المفترض يكون اسمه وبعدين يطبع welcome وinput تبع اليوزر

طيب، نلاحظ لمن نوصل للفنقشن func حنا كأننا نحجز كوب بالستاك بحجم ١٠٠ بايت باسم buffer والي راح يكون مخزن للـ user input، طيب هنا السوال وش يصير لو حطينا داخل البفر بايتات اكثر من ١٠٠ بايت ؟ بيصير اوفر فلو للبفر وهذا محور حديثنا

مثل ما تشوف بالصوره تحت ان البفر لا طفح او لا صار له اوفر فلو بب يكمل تعبئة ب مكان الـ rbp register والـ return address، واذا قدرنا نملي خانة الـ return address بادرس على كيفنا بكذا حنا نقدر نتحكم بتشغيل البرنامج ونقدر نغير مسار تشغيل البرنامج ونخليه يعطينا RCE

الان نبدا الشغل العملي كك
Basic x64 Linux Buffer Overflow
نقدر نجيب الـ RCE عن طريق الخطوات التاليه؛
1⁃ crash the program
2⁃ find the pattern
3⁃ shellcode inject attack
ملاحظة؛ لا تخوفكم الاسماء ترى بسيطين مره

1- crash the program
هذي اول خطوه عشان نعرف هل فيه بفر اوفر فلو بالبرنامج ولا لا، هدفنا في هذي الخطوه اننا نطلع الايرور segmentation fault والي معناه ان البرنامج قاعد يأشر على عنوان ذاكره خاطئ او ان العنوان مو موجود بالذاكره اصلاً

وهذا متوقع كون اننا نبي نملي البفر بداتا عشوائية لين تطفح من البفر وتروح تغير خانة الـ return address ولمن تصير الداتا العشوائيه بهالخانه يعتبرها الـ cpu انها ادرس ( عنوان بالذاكره ) وبعدين لمن يروح لهالعنوان العشوائي هذا يقول " شنو قاعد تضحك علي انت ؟" ويزعل ويطلع ايرور

2- find the pattern
بعد ما عرفنا ان فيه بفر اوفر فلو نحتاج الحين نعرف بعد كم بايت نحطه نقدر نسوي override ( نغير )
الـ return address ؟
نشغل الـ gdb debugger
- نسوي pattern بحجم ٣٠٠ بايت ( بنفس العدد الي سوينا للبرنامج كراش فيه )
- نشغل البرنامج ونحط الـ pattern
ك user input

بعد ما صار كراش للبرنامج ناخذ القيمة الي موجوده بالـ rbp ونشوف بعد كم بايت قدرنا نسوي override للـ rbp وبعدين نزود 8 ويصير هذا العدد الي نحتاجه عشان نسوي override للـ return address
طلع لنا نحتاج 112 bytes عشان نوصل لل rbp
فف يعني نحتاج 120 bytes عشان نوصل
للـ return address

عشان نتاكد من كلامنا، نملي الـ user input بب 120 bytes وبعدين نحط لنا ادرس تجريبي متعارف عليه
عادةً الناس تملي الـ user input بب Aـات والـ return address بب 4 Bـات مع 4 Fـات مثل الصوره تحت
- طبعت كلامنا الي فوق بملف اسمه check
- حطيت الملف كك user input

3- shellcode injection
اما الان وقد تاكدنا اننا ماشين صح وكل شي عرفناه بخصوص البفر، ما علينا الا اننا نحط شل كود ونخلي الـ return address يأشر عليه وبووم ناخذ شل

بعد ما طلع لنا الخطا بالخطوه السابقه، ما علينا الا اننا نقول للديبقر، اعرض لنا 30 bytes من البايتات الموجوده $rsp ناقص منها عدد بايتات البفر 120 bytes عشان نرجع لاول داتا دخلناها بالبفر
سوال شاطح؛ ليه نعرض 30 bytes ؟
الجواب؛ تقدر تعرض اي عدد تبيه بس انا اشوف 30 bytes كافيه

تعرض 30 bytes ابتدائاً من $rsp -120، هذا شي مناسب وكافي ولكن عشان ارضي الوسواس الي فيني دايماً ارجع الى قبل اول داتا حطيناها بكم بايت زياده
بكذا عرفنا ان الادرس
0x7fffffffdc60 مناسب لوضع الشل كود حقنا

طبعاً الاكسبلويت حقنا بيكون كذا
نحط عدد من الـ NOPs ( انا متعود احط 30 ) بعدين الشل كود بعدين داتا الين ما يصير مجموع الـ NOPs والشل كود والداتا الباقيه = 120 بعدين نحط الادرس الي لقيتاه بالصوره فوق

طبعاً الـ NOPs هي instractions ما تسوي شي نحطها قبل الشل كود عشان نضمن ان لو الـ return address تقدم بايت او تاخر بايت فف هو راح يسقط على الـ NOPs والي بدورها تصير نفس الزحليقه تزحلق الـ CPU الين ما يوصل الـ shellcode
اما بخصوص الشل كود تقدر تسويه بب msfvenom وتقدر تجيبه من النت

لمن نجرب الاكسبلويت خارج الديبقر يعطينا ايرور وهذا لان الادرسات (العنواين) داخل الديبقر قد تختلف عن خارج الديبقر
فالي نسويه
-نسوي dump لملف core عن الخطا نفس الصوره
- ندخل ال core بالديبقر
- نعرض ال rsp-120
- نغير الادرس القديم بالي لقيناه جديد

زين نلاحظ بالصوره الي فوق ان البرنامج عطانا شل وطلع بسرعه " كانك يابو زيد ما غزيت"
عشان نحل المشكله هذي نستخدم ال cat trick والي هي اننا نسوي امر كات بدون ما نعطيه اي ملف وكذا يصير الـ cpu واقف وباثناء وقوفه حنا اصلاً نقدر نستخدم الشل وبكذا راح يشتغل وما يطلع على طول