در این سند، آسیبپذیری Symbolic Link Following در سطح میزبان که در پیادهسازی هایپروایزر Oracle VirtualBox وجود دارد، مورد بررسی قرار میگیرد. سوءاستفاده از این آسیبپذیری به مهاجم امکان ارتقا دسترسی محلی (Local Privilege Escalation) را میدهد. در واقع مهاجم امکان ارتقا دسترسی خود را از یک کاربر عادی (Low-Privileged) به کاربر سطح بالا (SYSTEM) را خواهد داشت. باید این دقت را به عمل آورد که این آسیبپذیری Guest-To-Host Escape[1] نیست، بلکه با فرض اینکه مهاجم یک کاربر عادی در سیستمی باشد که VirtualBox را نصب کرده باشد، وی میتواند از آسیبپذیری مذکور ( که در نحوه عملکرد سرویس VBoxSDS ایجاد شده است) برای ارتقا به کاربر ادمین استفاده کند.
در ابتدا، مروری کلی بر VirtualBox به عنوان یک هایپروایزر ارائه میشود و جایگاه این آسیبپذیری در معماری آن مشخص میگردد. سپس، سرویس VBoxSDS بعنوان مولفه آسیبپذیر معرفی شده و عملکرد آن بوسیله Procmon مورد تحلیل قرار میگیرد و آسیبپذیری مشخص میگردد. سپس نحوه سوءاستفاده از آسیبپذیری و ایجاد Symbolic Link Following و در نهایت نحوه اکسپلویت آسیبپذیری شرح داده میشود.
آسیب پذیری مذکور تنها روی سیستم های ویندوزی (بعنوان میزبان) و تا نسخه 7.0.16 ویرچوال باکس وجود داشته و قابل استفاده است.
لازم به ذکر است که تکهکدهای ارائهشده در این سند دارای حذفیات هدفمند هستند و صرفاً شامل بخشهای مهم و مرتبط با موضوع میباشند. برای مشاهده کد منبع کامل، به لینک ضمیمهشده مراجعه کنید[2].
هایپروایزرها
در دنیای مجازیسازی، هایپروایزرها[3] نقش کلیدی در اجرای همزمان چندین سیستمعامل روی یک سختافزار مشترک ایفا میکنند. این فناوری به کاربران و سازمانها امکان میدهد تا از منابع سختافزاری خود بهصورت بهینه استفاده کرده و سیستمهای ایزوله و مستقل را بر روی یک بستر فیزیکی اجرا کنند.
هایپروایزر Virtualbox
محصول نرمافزاری Oracle VirtualBox یکی از هایپروایزرهای متنباز و رایگان است که برای معماریهای x86/x86-64 و AMD64 توسعه یافته و امکان ایجاد و مدیریت چندین ماشین مجازی (VM) را در سیستمعاملهای مختلف فراهم میکند.
به دلیل گستردگی استفاده از VirtualBox در محیطهای تحقیقاتی، توسعه نرمافزار و حتی برخی کاربردهای سازمانی، امنیت آن از اهمیت ویژهای برخوردار است. وجود آسیبپذیریهای امنیتی در این هایپروایزر میتواند به مهاجمان اجازه دهد تا از محیط مجازی فرار کرده و کنترل سیستم میزبان را در دست بگیرند، که یکی از تهدیدات جدی در حوزه امنیت مجازیسازی محسوب میشود.
در این مقاله، یک آسیب پذیری موجود در سرویس VBoxSDS شرح داده میشود. این سرویس یک مؤلفه تحت اجراء سیستم میزبان است که در مسیری عمومی[4]، اقدام به ساخت پوشهای کرده و عملیات های DELETE و MOVE را به ازای تعدادی از فایلها بدون بررسیهای لازم برای جلوگیری از Link Following انجام میدهد. این ضعف در نهایت موجب پدید آمدن آسیبپذیری مورد بحث در این سند شده است. در ادامه، ابتدا با VirtualBox و نحوه کلی عملکرد آن به عنوان یک هایپروایزر آشنا شده، سپس به تحلیل دقیق این آسیبپذیری و روشهای سوءاستفاده از آن خواهیم پرداخت.
نگاهی بر خواص یک هایپروایزر
هایپروایزر که با نامهای فراناظر، ناظر ارشد و شبیهساز نیز شناخته میشود، نوعی نرمافزار است که امکان ایجاد و اجرای ماشینهای مجازی (VM) را فراهم میکند. در یک محیط مجازیسازی، میتوان دو بخش اصلی را در نظر گرفت:
- ماشین میزبان[5]: سیستمی که هایپروایزر روی آن اجرا شده و بستر لازم برای ایجاد و مدیریت ماشینهای مجازی را فراهم میکند.
- ماشین مهمان[6]: یک سیستمعامل مجازی که تحت نظارت هایپروایزر اجرا میشود و وابسته به منابع اختصاصیافته از ماشین میزبان است.
به بیان ساده، ماشین میزبان روی سختافزار فیزیکی اجرا میشود، در حالی که ماشین مهمان یک محیط مجازی است که بهواسطه هایپروایزر ایجاد و مدیریت میشود.
ویژگیهای کلیدی هایپروایزر
یک هایپروایزر استاندارد باید سه ویژگی مهم را در مدیریت ماشینهای مجازی رعایت کند:
- تقلید از رفتار سختافزار واقعی: ماشین مجازی باید در برابر عملیات و درخواستهای مختلف، رفتاری مشابه با یک سختافزار واقعی داشته باشد.
- کنترل کامل منابع توسط ماشین میزبان: هایپروایزر باید دسترسی ماشین مهمان به منابع سختافزاری را مدیریت کرده و از هرگونه دسترسی غیرمجاز جلوگیری کند.
- حداقل دخالت ماشین میزبان در اجرای دستورات ماشین مهمان: از نظر آماری، درصد بیشتری از دستورات ماشین مهمان باید مستقیماً اجرا شوند، بدون اینکه نیاز به مداخله مستقیم هایپروایزر باشد.
دستهبندی هایپروایزرها
هایپروایزرها بهطور کلی به دو دسته Bare Metal و Hosted تقسیم میشوند و در تصویر 1 میتوان ساختار کلی آنها را مشاهده کرد.
همانطور که در تصویر 1 قابل مشاهده است، گونه اول هایپروایزرها بدون وابستگی به یک سیستمعامل میزبان روی سختافزار نصب و پیکربندی میشوند، ولی گونه دوم به یک سیستمعامل میزبان (Host OS) وابستگی دارند.
هایپروایزر نوع 1 (Native/Bare-Metal Hypervisor)
این نوع هایپروایزر بهطور مستقیم روی سختافزار فیزیکی نصب میشود و سیستمعامل میزبان ندارد. نمونههایی از هایپروایزرهای نوع 1 عبارتند از:
- Microsoft Hyper-V
- VMware ESXi
- KVM
- Xen
به دلیل ارتباط مستقیم با سختافزار، این نوع هایپروایزرها عملکرد بهتری دارند و در محیطهای دیتاسنتر و سازمانی پرکاربرد هستند.
هایپروایزر نوع 2 (Hosted Hypervisor)
این نوع هایپروایزرها روی یک سیستمعامل میزبان اجرا میشوند و از منابع آن برای ایجاد و مدیریت ماشینهای مجازی استفاده میکنند. نمونههایی از هایپروایزرهای نوع 2 عبارتند از:
- Oracle VirtualBox
- VMware Workstation
- Parallels Desktop
محصول VirtualBox یکی از معروفترین هایپروایزرهای نوع 2 است. این نوع هایپروایزرها معمولاً در محیطهای تست و توسعه نرمافزار به شکل گسترده استفاده میشوند.
سرویس VBoxSDS در VirtualBox
این سرویس مخفف VirtualBox System Directory Service بوده و هدف آن، اطمینان از این است که به ازای هر کاربر درحال استفاده از VirtualBox روی سیستم ویندوزی، فقط یک آبجکت CLSID_VirtualBox فعال است. CLSID[7] شناسه منحصربفردی برای آبجکت COM است. وظیفه این سرویس اطمینان از فعال بودن سرور COM به ازای هر کاربری است که از VirtualBox استفاده میکند.
این سرویس یک پوشه در مسیر C:\ProgramData\VirtualBox برای لاگ کردن رویدادها میسازد. حین ساخت این پوشه، هیچ ACL[8] خاصی تعیین نمیشود و در نتیجه حالت پیشفرض اعمال میشود، که این یعنی پوشه VirtualBox مفاد امنیتی پوشه بالاتر از خود، ProgramData را به ارث خواهد برد؛ از آنجایی که هر کاربری (از جمله کاربر Unprivileged) امکان ساخت فایل و پوشه را در مسیر ProgramData دارد، بنابراین طبق نکته اشاره شده این نوع کاربر نیز امکان ساخت فایل در پوشه VirtualBox را نیز خواهد داشت.
سرویس VBoxSDS بعنوان یک سرویس User-Land پس از نصب VirtualBox ایجاد میشود. نحوه ایجاد این سرویس را میتوانید در خط 372 از فایل src/VBox/Main/src-global/win/VBoxSDS.cpp در کدمنبع Virtual Box مشاهده کنید (تصویر 2).
سرویس از نوع DEMAND_START است، به این معنا که برای فعال شدن نیاز است که کاربری با استفاده از تابع StartService آنرا اجرا کند؛ در ادامه خواهیم دید که روشن کردن و همچنین کرش عمدی سرویس جزئی از فرآیند اکسپلویت است.
لازم به ذکر است که مولفه VBoxSDS اقدام به ساخت یک COM Service نیز میکند. در ادامه خواهیم دید که تنها راه فعالسازی سرویس VBoxSDS از طریق همین COM Server خواهد بود.
لینکها در ویندوز
در ویندوز سه مکانیزم اصلی برای لینک فایلها و پوشهها وجود دارد: لینک سخت[9]، Junction Point و Windows Shortcut. لینک سخت با همین نام در سیستم های شبه-یونیکسی است. به همین صورت Shortcut در سیستمهای شبه-یونیکسی با نام Soft Link شناخته میشود.
برای لینک پوشهها (Directory) مکانیزم خاصی به نام Junction Point تعریف شده است که امکان لینک یک دایرکتوری به دایرکتوری یا ولوم (Volume) دیگر را فراهم میسازد.
لینک سخت (Hard Link)
تحت مکانیزم لینک سخت، میتوان از یک فایل روی دیسک با یک inode [10]، چندین نمونه[11] با inode مشابه روی فایل سیستم ایجاد کرد (مثلا هر یک با نام متفاوت یا مسیر متفاوت).
- باید توجه داشت که Hard Link در سیستمهای ویندوزی تنها برای فایلها استفاده میشود و برای پوشهها بلااستفاده است.
- برای اینکه بتوان دو فایل را به یکدیگر Hard Linkکرد لازم است که این دو فایل در یک ولوم حضور داشته باشند.
Junction Point
Junction Point این امکان را میدهد که یک دایرکتوری به دایرکتوری یا ولوم دیگر اشاره کند. این مکانیزم تنها برای دایرکتوری ها کاربردی است و تنها روی NTFS 5 به بعد پشتیبانی شده و از Reparse Point[12] در این نسخهها استفاده میکند.
ریسکهای مرتبط با Junction Point
دو نوع ریسک در خصوص Junction Point در صورت عدم رعایت ملاحظات امنیتی وجود دارد:
- اگر فرضا یک سرویس با سطح دسترسی بالا یک فایل یا پوشهای را در یک مسیر عمومی که مهاجم به آن دسترسی داشته باشد (مثل C:\Temp یا در موضوع مورد بحث، مسیر C:\ProgramData\VirtualBox) را مورد استفاده قرار دهد، مهاجم میتواند از پیش یک Junction Point دقیقا در همان مسیر مورد استفاده سرویس قرار دهد تا سرویس فایلی را در مسیر دلخواه مهاجم باز کند. در واقع مهاجم میتواند موجب دسترسی به فایلی ناخواسته توسط سرویس شود و امنیت سرویس را به خطر بیندازد (به عبارت دیگر Unintentional File Access اتفاق بیافتد).
- امکان رخداد Race Condition[13]
در آسیبپذیری مورد بحث در این سند دقیقا حالت اول رخ داده است؛ یعنی مهاجم با ساخت یک Junction Point در زمان و مکان مناسب موجب Arbitrary File Move و Arbitrary File Delete میشود.
تحلیل عملکرد VBoxSDS
در تصویر 6 عملیاتهای انجام شده توسط سرویس VBoxSDS در پوشه C:\ProgramData\VirtualBox با استفاده از ابزار Procmon مشخص شده است:
همانطور که در تصویر 6 قابل مشاهده است، سرویس VBoxSDS ابتدا پوشه C:\ProgramData\VirtualBox ساخته و سپس فایلهای لاگ (VBoxSDS.log.*) را درون آن میسازد.
همانطور که در تصویر 7 قابل مشاهده است، حین ساخت پوشه VirtualBox، سرویس VBoxSDS صریحا هیچ مفاد امنیتی بهطور صریح تنظیم نمیکند و در نتیجه حالت پیشفرض اعمال شده و این دایرکتوری مفاد پوشه ProgramData را به ارث خواهد بود.
تحلیل عملیاتهای VBoxSDS نشان میدهد که این پروسه به صورت Recursive اقدام به تغییر نام و جابجایی فایل ها در مسیر C:\ProgramData\VirtualBox میکند:
همانطور که در تصویر 8 قابل مشاهده است، فایل VBoxSDS.log به VBoxSDS.log.1 تغییر نام یافته است. بطور مشابه همین عملیات برای تبدیل از فایل VBoxSDS.log.1 به VBoxSDS.log.2، از VBoxSDS.log.2 به VBoxSDS.log.3 انجام میشود و این روال تغییر نام صعودی در نهایت با تغییر نام VBoxSDS.log.9 به VBoxSDS.log.10 پایان میابد.
سرویس VBoxSDS در نهایت اقدام به حذف فایل VBoxSDS.log.10 خواهد کرد که اطلاعات عملیات آن در تصویر 9 قابل مشاهده است.
مهاجم میتواند از عملیاتهای فوق به نفع خود استفاده کند. کافی است پیش از File Move یا File Delete بجای فایلهایی که سرویس جابجا یا حذف میکند، یک لینک به مسیر دلخواه خود ساخت تا به این صورت سرویس وادار به دسترسی به فایل های خارج از مسیر C:\ProgramData\VirtualBox شود. در بخش توضیحات مبنی بر نحوه اکسپلویت این روند توضیح داده خواهد شد.
شرحی بر آسیب پذیری Arbitrary File Access
بعضا یک اپلیکیشن برای انجام یک عملیات مشخص (مثلا برای خواندن لاگها، ضبط اطلاعات کاربری و …)، محدوده دسترسی خود را در فایل سیستم به مسیر و پوشه خاصی محدود میکند. درواقع هدف طراح/برنامهنویس این بوده که اپلیکیشن به هیچ وجه به مسیری خارج از مسیر تعیین شده دسترسی پیدا نکند و آنچه که خواسته شده در همان مسیر مقرر شده انجام پذیرد.
آنچه که میتواند موجب ایجاد حفره در این رویکرد شود، استفاده از مسیرهای عمومی (مسیرهایی که کاربر عادی میتواند به آن دسترسی پیدا کند) و عدم چک فایل/دایرکتوری برای جلوگیری از Link Following است. بعنوان مثال اپلیکیشنی از مسیر C:\Temp برای ذخیرهسازی موقت اطلاعات استفاده میکند. این مسیر توسط کاربران Unprivileged (سطح دسترسی پایین) قابل دسترسی است و آنها امکان ساخت فایل در این مسیر را خواهند داشت. اگر فرضا مهاجم بتواند پیشبینی کند که اپلیکیشن وارد چه مسیری میشود، چه فایلی را در این مسیر میسازد، جابجا میکند یا حذف میکند، وی میتواند پیش از انجام یکی از عملیاتهای مذکور اقدام به ساخت لینک در همان مسیر بکند و متعاقبا موجب ایجاد Arbitrary File Access و هدایت اپلیکیشن به سمت مسیر مدنظر خود شود[14]. این قضیه پتانسیل بالا سواستفاده و اکسپلویت و در نهایت ارتقا دسترسی را خواهد داشت.
چه چیزی موجب آسیب پذیری VBoxSDS شده است ؟
با توجه به آنچه در بخشهای تحلیل عملکرد سرویس VBoxSDS و بررسی ماهیت آسیبپذیری Arbitrary File Access ارائه شد، میتوان دلایل اصلی بروز این آسیبپذیری در VBoxSDS را در دو مورد زیر خلاصه کرد:
- سرویس VBoxSDS برای ذخیرهسازی فایلهای لاگ خود از مسیری عمومی (قابل دسترسی برای تمامی کاربران) استفاده کرده است. از آنجا که این مسیر برای همه کاربران قابل تغییر است، هر کاربر میتواند آن را به مسیر دلخواه خود لینک کند. در نتیجه، زمانی که سرویس قصد استفاده از لاگها را دارد، مهاجم میتواند آن را به مسیر دلخواه خود هدایت کند. این وضعیت میتواند خطرناک باشد، زیرا یک کاربر عادی قادر خواهد بود سرویس را وادار به انجام عملیاتهایی در مسیرهایی خاص، با سطح دسترسی بالا کند. برای جلوگیری از چنین سناریویی، ضروری بود که سرویس VBoxSDS مسیر ذخیرهسازی لاگها را بهطور ایمن پیکربندی کند. بهطور مشخص، مسیر C:\ProgramData\VirtualBox بدون تعریف صریح مجوزهای امنیتی (Explicit DACL) ایجاد شده است. در نتیجه، این مسیر مجوزهای امنیتی دایرکتوری والد خود یعنی ProgramData را به ارث میبرد، که آن نیز بهصورت عمومی قابل دسترسی است. البته فایلهایی که سرویس VBoxSDS در این مسیر ایجاد میکند، مستقیماً توسط کاربران قابل تغییر نیستند؛ اما اگر پیش از ایجاد این فایلها، این پوشه حذف شده و مهاجم بلافاصله لینکهای مورد نظر خود را در آن جای دهد، امکان پیادهسازی حملهی Link Following فراهم خواهد شد.
- اگر سرویسی بخواهد از فایلهای موجود در یک مسیر خاص و محدود استفاده کند، باید اطمینان حاصل کند که Link Following رخ نمیدهد و مسیر دسترسی به فایلها به مسیرهای مخرب هدایت نمیشود. بهویژه در شرایطی که اپلیکیشن به یک مسیر عمومی (قابل تغییر توسط کاربران) دسترسی پیدا میکند، بررسی صحت مسیرها ضروری است. به بیان دقیقتر، پیش از انجام هرگونه عملیات بر روی فایلها، باید اطمینان حاصل شود که فایل مورد نظر و همچنین پوشههایی که به آن منتهی میشوند، به مکان دیگری لینک نشدهاند. سرویس VBoxSDS این بررسی را هنگام دسترسی به فایلهای لاگ انجام نداده است.
نحوه سواستفاده و بررسی اکسپلویت
اشاره شد که آسیب پذیری Arbitrary File Move/Delete در نتیجه استفاده از مسیر عمومی برای ذخیره اطلاعات لاگ و عدم چک آنها برای جلوگیری از Symbolic Link Following ایجاد میشود. در ادامه مرحله به مرحله کد اکسپلویت[15] شرح داده شده و در نهایت به سراغ کامپایل و اجرا مستقیم آن خواهیم رفت.
شایان ذکر است که برای آسیبپذیری در اصل دو نوع اکسپلویت وجود دارد، یک نوع آسیبپذیری را هنگام انجام عملیات Delete توسط سرویس و دیگری آسیبپذیری را هنگام عملیات Move اکسپلویت میکند. رویکردی که این دو دنبال میکنند و آنچه که اکسپلویت میکنند یکسان است و صرفا در جزییات عملیاتهای متاخر، متفاوت هستند. در این سند تنها حالت اکسپلویت با Move شرح داده میشود.
شرح نحوه عملکرد اکسپلویت در هنگام عملیات Move
به صورت کلی برای اجرا کد پیلود و ارتقا دسترسی، اکسپلویت با استفاده از آسیبپذیری Arbitrary File Move اقدام به قرار دادن یک DLL در مسیر C:\Windows\System32 میکند. در ادامه مراحل اکسپلویت شدن آسیبپذیری آورده شده است:
1. اکسپلویت به عنوان اولین ورودی خود (argv[1]) آدرس DLL که مهاجم قصد قراردادن آن در C:\Windows\System32 را دارد دریافت میکند.
2. ابتدا برای انجام برخی از فرآیندهای سیستمی و یک عملیات پردازش رشته نیاز است که سه تابع سیستمی ایمپورت[16] شوند. به جهت جلوگیری از تشخیص استفاده از این سه تابع سیستمی توسط نرمافزارهای امنیتی (با استفاده از تکنیک API Hooking)، این عمل با بارگذاری مستقیم کتابخانه NTDLL و استخراج آدرس توابع مدنظر از آن حاصل میشود[17]. در کدمنبع اکسپلویت، تابع loadapis() وظیفه استخراج آدرس سه تابع (NtCreateFile، NtSetInformationFile و RtlInitUnicodeString) را برعهده دارد.
کتابخانه ntdll.dll در فضا پروسه اکسپلویت بارگذاری شده، سپس آدرس مجازی سه تابع مورد استفاده در اکسپلویت استخراج میشود.
3. اکسپلویت بررسی میکند که آیا VirtualBox درحال اجرا است یا خیر؟ اگر پاسخ مثبت باشد، اکسپلویت تلاش میکند که پروسه مربوطه را ببندد و سپس ادامه کار اکسپلویت در پیش گرفته بشود.
در صورتی که VirtualBox در حال اجرا باشد اکسپلویت تلاش میکند که آن را ببندد.
4. پوشه C:\explt_bait ساخته میشود که در ادامه جزیی از مرحله ایجاد Link Following و ایجاد یک DLL در مسیر C:\Windows\System32 خواهد بود.
5. فایل log.11 ساخته شده وoplock[18] روی آن تنظیم شود؛ اگر این oplock توسط سرویس استفاده شود (به اصطلاح trigger شود)، یک مسیر callback (تابع cb1 در اکسپلویت) فراخوانی شده که در آن پوشه VBoxSDS.log ایجاد میشود. هدف از ایجاد این پوشه کرش کردن سرویس VBoxSDS در هنگامی است که به پوشه VBoxSDS.log دسترسی میگیرد. تصویر 13 تنظیم oplock و تصویر 14 مسیری که پس از تریگر شدن دنبال میشود را مشخص کرده است.
6. از طریق بکارگیری COM Server که از قبل توسط سرویس ساخته شده، اکسپلویت موجب اجرا شدن سرویس VBoxSDS میشود (به آخرین خط در تصویر 10 دقت شود). این عملیات توسط تابع runSDS انجام میشود (تصویر 15). این آبجکت با شناسه 74AB5FFE-8726-4435-AA7E-876D705BCBA5در سیستم تعریف میشود.
7. اکسپلویت پس از اطمینان از خالی بودن پوشه C:\ProgramData\VirtualBox (با ایجاد کرشهای متوالی این سرویس)، پوشه log را از این مسیر حذف میکند. سپس فایل DLL که بعنوان ورودی به اکسپلویت داده شده بود را در مسیر C:\ProgramData\VirtualBox و بعد همین فایل را در C:\explt_bait\VBoxSDS.log.9کپی میکند(تصویر 16).
تا به اینجا کار موفق شدیم با اجرا و سپس کرش سرویس VBoxSDS موجب ایجاد مسیر C:\ProgramData\VirtualBox شده، سپس آن را پاکسازی کنیم و در نهایت فایل DLL را با نام VBoxSDS.log.9 درون آن قرار دهیم. اگر سرویس دوباره راه اندازی شود، بجای آنکه با پوشه خالی مواجه شود با فایل VBoxSDS.log.9 مواجه خواهد شد که نه یک فایل عادی بلکه DLL مهاجم است که در ادامه باید در مسیر C:\Windows\System32 با نام مناسبی قرار بگیرد.
8. سرویس VBoxSDS بار دیگر توسط اکسپلویت در یک ترد مجزا استارت میشود (خط 343). باید توجه داشت که اینسری برخلاف دفعات قبل مقدار 1 بعنوان پارامتر تابع runSDS داده شده است که موجب ایجاد یک وقفه 2 ثانیهای پیش از آغاز سرویس میشود. این وقفه برای این است که اکسپلویت پیش از اجرا سرویس بتواند یک oplock روی فایل log.9 تنظیم کند (تصویر 17).
9. در این مرحله یک oplock روی log.9 (که اکنون همان فایل DLL باشد) تنظیم میشود و هنگامی سرویس به oplock دسترسی گیرد و oplockتریگر شود یک Junction Point از مسیر C:\ProgramData\VirtualBox به C:\Windows\System32 ایجاد خواهد شد. مطابق آنچه در بخش تحلیل رفتار VBoxSDS متوجه شدیم، این سرویس فایل VBoxSDS.log.9 را به VBoxSDS.log.10 تغییر نام میدهد. از آنجایی که اکنون مسیر C:\ProgramData\VirtualBox به C:\Windows\System32 لینک شده است، فایل VBoxSDS.log.9 (که فایل DLL مهاجم باشد) پس از عملیات Move به مسیر C:\Windows\System32\VBoxSDS.log.10 انتقال میابد.
10. اکسپلویت منتظر میماند که قفل روی فایل log.9 برای آخرین بار تریگر شود (که در این لحظه VBoxSDS.log.9 به VBoxSDS.log.10 تغییر نام مییابد). در نهایت اکسپلویت بررسی میکند که آیا فایل C:\Windows\System32\VBoxSDS.log.10 وجود دارد یا خیر؟ اگر پاسخ مثبت باشد یعنی موفق شدیم DLL خود را به System32 منتقل کنیم (تصویر 18).
پس از اینکه انتقال DLL تایید شد، تابع GetPrinterDrivers() فراخوانی میشود که سعی در بارگذاری DLL و ارتقا سطح دسترسی دارد.
11. اکنون که DLL مهاجم در مسیر مناسب قرار گرفت، وقت آن است که توسط یک اپلیکیشن Privileged بارگذاری شده و اجرا شود. برای اینکار میتواند راهکارهای مختلفی وجود داشته باشد؛ آنچه که در اکسپلویت مورد بحث استفاده شده است، استفاده از Printer Driverها است (تصویر 19). در این اکسپلویت به ازای هر درایور سعی شده که با اضافه کردن یک پرینتر جدید و در نهایت پیکربندی آن بوسیله SetPrinterDataEx کتابخانه مهاجم بارگذاری شود (تصویر 20).
نحوه انجام عملی اکسپلویت
کد اکسپلویت را میتوان از طریق لینک ضمیمه شده[19] دانلود کرد. سپس مراحل زیر طی شود:
- فایل solution یکی از پوشههای VirtualBoxLPE_Del و VirtualBoxLPE_Moveرا توسط VisualStudio باز کرده و کامپایل گرفته شود. البته میتوان از اجراییهای از پیش کامپایل شده در سطح اینترنت نیز استفاده کرد (که به دلایل امنیتی پیشنهاد نمیشود).
- نیاز است که یک فایل DLL ایجاد کنیم که پس از بارگذاری در فضا یک پروسه Privileged کد مارا اجرا کرده و موجب ارتقا دسترسی شود. این میتواند یک کد ساده برای باز کردن یک پنجره Powershell یا CMD باشد، یا مستقیما خواسته مهاجم را بدون باز کردن شل با کاربر SYSTEM انجام دهد.
- اکسپلویت توسط یک کاربر عادی اجرا شود و آدرس DLL که در مرحله قبلی تولید شد به عنوان اولین آرگمان داده شود.
راهکارهای جلوگیری از آسیبپذیری
برای جلوگیری از بهرهبرداری از این آسیبپذیری، راهکارهای زیر پیشنهاد میشوند:
- از مسیرهای عمومی و بدون پیکربندی صریح امنیتی تحت هیچ شرایطی استفاده نشود: باید اطمینان حاصل شود که هر مسیر که یک سرویس سطح بالا استفاده میکند، توسط کاربران عادی قابل تغییر و هدایت نباشد. در غیر این صورت ریسک ایجاد Arbitrary File Access و ایجاد تغییرات دلخواه و متعاقبا ارتقا دسترسی وجود خواهد داشت. مسیرهایی مثل C:\Windows\Temp یا C:\ProgramData توسط همگان قابل دسترسی است و حتی اگر اپلیکیشنی زیرشاخه انحصاری خود را تحت این مسیرها میسازد باید حتما پیکربندی امنیتی لازم را برای زیرشاخه خود انجام دهد.
- برای جلوگیری از Link Following ویژگیهای فایل/پوشه مورد دسترسی بررسی شود: پیش از اینکه سرویس از فایل یا مسیری استفاده کند (با این فرض که کاربران عادی به آن دسترسی دارند) برای جلوگیری از دنبال کردن لینک (Link Following) و خروج از محدوده ، حتما ویژگیهای مسیر مورد دسترسی بررسی شود تا اگر فایل یا پوشه از نوع لینک بودند روند استفاده از آن متوقف شود.
نتیجهگیری
آسیبپذیری مورد بررسی در این مقاله مربوط به مولفه VBoxSDS در هایپروایزر VirtualBox است که در سمت میزبان اجرا میشود و میتواند موجب ارتقا دسترسی در سطح میزبان شود. این آسیبپذیری موجب Arbitrary File Move/Delete (حذف یا انتقال فایل به مسیر دلخواه) میشود و بدلیل استفاده از مسیری نامناسب برای ذخیره سازی لاگها، عدم پیکربندی صحیح پوشه حامل آنها و انجام عملیاتهای Move/Delete بدون انجام بررسیهای پیشگیرانه ایجاد شده است. مشکل در اینجا بود که اگر تمهیدات مذکور چیده نمیشد، مهاجم امکان ایجاد لینک و در نهایت Junction Point از پوشه لاگ به مسیر C:\Windows\System32 و متعاقبا انتقال کتابخانه دلخواه خود به این مسیر و ارتقا سطح دسترسی را پیدا میکرد.
پاورقی:
[1] آسیبپذیری که موجب ارتقاع سطح دسترسی از سیستم مهمان به سیستم میزبان شود
[2]https://download.virtualbox.org/virtualbox/7.0.14/VirtualBox-7.0.14.tar.bz2
https://github.com/mansk1es/CVE-2024-21111/tree/main/VirtualBoxLPE_del
[3] Hypervisors
[4] مسیری که توسط همه کاربران قابل دسترسی باشد، که شامل کاربران معمولی (Unprivileged Users) نیز میشود
[5] Host Machine
[6] Guest Machine
[7] Class ID
[8] یک Access Control List، لیستی از ورودیهای ACE (Access Control Entry) است که هر یک دسترسی خاصی را به ازای یک SID (شناساگر امنیتیِ به اصطلاح principle (مثلا یک کاربر)) تعیین میکند. به صورت کلی دو نوع ACL داریم که یکی DACL که برای کنترل دسترسی به آبجکت استفاده میشود و دیگری SACL است که برای دیباگ و System Audit آبجکتها استفاده میشود.
[9] Hard Link
[10] به زبان ساده، inode یک فایل در واقع شناسه منحصربهفرد آن فایل در فایلسیستم است.
[11] Instance
[12] فعال بودن ویژگی Reparse Point به ازای یک فایل یا دایرکتوری در ویندوز به منزله فعالسازی مسیری در درایور فایل سیستم برای پردازش اضافی فایل است. برای اینکه Junction Point قابل استفاده باشد، نیاز است که این قابلیت توسط فایل سیستم پشتیبانی شود. از NTFS 5 به بعد Reparse Point و درنتیجه Junction Point پشتیبانی میشود.
[13] موقعیتی است که دو یا چند مولفه بطور همزمان در حال فعالیت روی منبعی مشترک/یکسان باشند و این فرآیند موجب زیان شود. در حوزه کشف آسیبپذیری این رقابت میتواند موجب ایجاد حالت TOCTOU (Time-Of-Check-Time-Of-Use) شود، به این معنا که مهاجم میتواند مابین لحظه چک وضعیت منبع (Time-Of-Check) و استفاده از منبع (Time-Of-Use) وضعیت آن منبع را تغییر دهد و هر ضابطهای که در لحظه چک (Time-Of-Check)، از قبل بررسی شده را، دور بزند.
[14] مثلا با فرض اینکه اپلیکیشن مجوز کافی را داشته باشد، مهاجم آن را به سمت مسیر C:\Windows\System32 هدایت کند و اجرایی و کتابخانههای مدنظر خود را جایگزین کند.
[15] https://github.com/mansk1es/CVE-2024-21111/tree/main/VirtualBoxLPE_move
[16] Import
[17] درواقع اکسپلویت از چندین تابع سیستمی استفاده میکند و تنها محدود به این سه تابع نیست، ولی از آنجایی که این سه تابع به احتمال بیشتری مورد حساسیت قرار میگیرد، به همین دلیل مستقیما از NTDLL ایمپورت میشوند.
[18] Opportunistic Lock یا به اختصار oplock فرایندی است که باعث قفل شدن یک فایل تا پایان انجام پروسهای که به آن فایل دسترسی گرفته میشود. در زمانی که oplock بر روی یک فایل فعال است، پروسهای بجز پروسهای که به آن فایل دسترسی گرفته، نمیتواند به فایل دسترسی داشته باشد.
