cryptolok/aslrayLinux ELF x32/x64 استغلال تجاوز ASLR وDEP/NX مع رش المكدس (stack-spraying)
أداة استغلال لتجاوز ASLR و DEP/NX على لينكس ELF x32/x64 مع رش المكدس
الخصائص:
التبعيات:
القيود:
ربما سمعت عن هجوم Heap Spraying؟ حسنًا، Stack Spraying مشابه، لكنه كان يُعتبر غير عملي في معظم الحالات، خاصة ASLR على x86-64.
عملي سيثبت العكس.
بالنسبة لـ 32 بت، هناك 2^32 (4,294,967,296) عنوانًا نظريًا، ومع ذلك، سيسمح النواة بالتحكم في حوالي نصف البتات فقط (2^(32/2) = 65,536) للتنفيذ في ذاكرة افتراضية، مما يعني أنه إذا تحكمنا في أكثر من 50,000 حرف في المكدس، فسنكون شبه متأكدين من الوصول إلى شيل كودنا، بغض النظر عن العنوان، بفضل إعادة التوجيه وإعادة الترجمة من النواة. وفقًا لاختباراتي، حتى 100 أو 10 أحرف تكفي إذا كانت الدالة المستدعاة لا تحتوي على إنشاءات متغيرات أخرى، مما سيسمح بهجوم من نوع ROP.
يمكن تحقيق ذلك باستخدام متغيرات الصدفة، والتي ليست محدودة حقًا بطول معين، لكن الحد العملي هو حوالي مئة ألف، وإلا فإنها ستشبع TTY.
لذا، من أجل الاستغلال بنجاح مع أي شيل كود، نحتاج إلى وضع NOP sled بعد الشيل كود في متغير صدفة ثم استغلال الثنائي بعنوان عشوائي. لاحظ أن NOP sled ليس ضروريًا، هذا فقط لتعميم الاستغلال.
في نظام 64 بت، الوضع مختلف، لكن ليس كثيرًا كما اكتشفت.
بالطبع، لن تضطر إلى تغطية جميع الاحتمالات 2^64، في الواقع، يسمح النواة بـ 48 بت فقط، بالإضافة إلى أن جزءًا منها يمكن التنبؤ به وثابت، مما يتركنا مع حوالي 2^(4x8+5) (137,438,953,472) احتمالًا.
لقد ذكرت حد حجم متغيرات الصدفة، ولكن هناك أيضًا حد للعدد، والذي يبدو أنه حوالي 10، مما يسمح لنا بتخزين شيل كود بحجم 1,000,000 حرف، مما يتركنا مع بضعة عشرات الآلاف من الاحتمالات التي يمكن اختبارها بسرعة وبشكل تلقائي. هذه المرة، ستحتاج إلى القوة العمياء واستخدام NOP-sleds لجعل الأمور أسرع.
مع ذلك، يمكن تجاوز ASLR على كل من 32 و64 بت بسهولة في دقائق معدودة وببضعة أسطر من الصدفة...
أما DEP/NX، فيمكن تجاوزها على x32 باستخدام تقنية return-to-libc من خلال دمجها مع دراسات إحصائية لأنظمة التشغيل المختلفة، وبشكل أكثر تحديدًا، حدود وتطبيقات ASLR الخاصة بها، مما قد يؤدي إلى استغلال ناجح لسببين. الأول هو أن ASLR ليس عشوائيًا جدًا في اختياره ويحتوي على بعض الثوابت والانتروبيا الضعيفة (يسهل تخمين عنوان libC ولكل نظام تشغيل ثوابته الخاصة). الثاني هو رش وسيط shell لـ libC في البيئة (يسهل العثور عليه وتمريره إلى libC).
في الختام، DEP/NX على 32 بت يضعف بسبب ASLR.
يمكن العثور على وصف أكثر تفصيلاً في إصدار Hakin9-12-14.
إذا كنت قد استغلت على الأقل تجاوز سعة مخزن مؤقت في حياتك، يمكنك التخطي، لكن فقط في حالة:
apt install gcc libc6-dev-i386 || kill -9 $$
chmod u+x ASLRay.sh
sudo gcc -z execstack test.c -o test
sudo gcc -m32 -z execstack test.c -o test32
sudo chmod +s test test32
source ASLRay.sh test32 1024
source ASLRay.sh test 1024
source ASLRay.sh test 1024 \x31\x80...your_shellcode_here
sudo gcc -m32 test.c -o test32x
sudo chmod +s test test32
source ASLRay.sh test32x 1024
لإثبات أن NOP-sled ليس ضروريًا لـ Debian x32:
!!! تحذير !!! سيؤدي هذا إلى تعديل ملف /etc/passwd وتغيير أذونات /etc/shadow، يُنصح بالتنفيذ على آلة افتراضية
chmod u+x PoC.sh
source PoC.sh
grep ALI /etc/passwd
إذا لم يعمل بعد، فقط أضف بعض NOPs (\x90) في البداية.
لإثبات أن حتى متغير البيئة ليس ضروريًا لـ Debian x32:
chmod u+x PoC2.sh
source PoC2.sh
وبالتالي يمكنك فقط وضع شيل كودك في متغير وإعطاء عناوين عشوائية للسجلات للحصول على شيل مع ASLR، هذا لأن السياق المحدد حيث تحتوي الدالة على متغير واحد فقط سيتم إعادة كتابته، لذا سيتم دفع المكدس إلى EIP فقط مع شيل كودنا، وهو أشبه بهجوم ROP.
بالنسبة لـ Arch/Ubuntu، ستحتاج أيضًا إلى تعطيل حماية تجاوز المكدس وقد تستغرق القوة العمياء وقتًا أطول (تأخير في التنفيذ، ربما بسبب استدعاء brk(NULL/0) أو/و canary):
sudo gcc -z execstack -fno-stack-protector test.c -o test
sudo gcc -m32 -z execstack -fno-stack-protector test.c -o test32
sudo gcc -m32 -fno-stack-protector test.c -o test32x
في Debian 10، تم تصحيح هذه المشكلة جزئيًا، ولا سيما بسبب AppArmor.
اعتمد دائمًا على حمايات متعددة وليس على حماية واحدة.
نحتاج إلى آليات أمان نظام جديدة.
"من حيث نقف، يبدو المطر عشوائيًا. لو كان بإمكاننا الوقوف في مكان آخر، لرأينا النظام فيه."
توني هيلرمان، Coyote Waits