|
1 چکیده فنی
سرورهای HP دارای یک ماژول مدیریتی به نام iLO مخفف Integrated Lights-Out هستند که به محض اتصال کابل برق روشن شده و یک سیستم عامل کامل اختصاصی را بارگذاری می‌کند. این ماژول با خاموش کردن سرور باز هم به کار خود ادامه می‌دهد و دارای دسترسی کاملی به کل سفت‌افزار، سخت‌افزار، نرم‌افزار و سیستم‌عامل سرور است و علاوه بر مدیریت سخت‌افزار سرور، به ادمین اجازه می‌دهد از راه دور سرور را روشن و خاموش نموده، به کنسول آن دسترسی داشته و حتی سیستم عامل روی آن نصب نماید.
دسترسی فوق‌العاده بالای این ماژول (بالاتر از هر سطح دسترسی در سیستم عامل)، احاطه کامل آن به سخت‌افزار، دور بودن از چشم ادمین و عمومی نبودن دانش و ابزارهای لازم برای بررسی و محافظت از آن، و ثابت بودن و عدم تغییر آن حتی با تغییر سیستم عامل، و به خصوص همواره روشن بودن دائمی خصوصیاتی هستند که این ماژول را به مثابه بهشتی برای نفوذگران و گروه‌های APT جهت پنهان نمودن بدافزار می‌گرداند.
ما در این گزارش به تحلیل یک نهان‌افزار کشف شده در محیط عملیاتی می‌پردازیم که خود را درون iLO پنهان می‌کند، با آپگرید سفت‌افزار قابل حذف نیست، و می‌تواند مدتها از چشم‌ها پنهان بماند. این بدافزار مدتی است در حال استفاده توسط نفوذگران می‌باشد و ما در حال بررسی عملکرد آنها بوده‌ایم. تا جایی که ما اطلاع داریم، این اولین گزارش از کشف بدافزاری واقعی در این سفت‌افزار در دنیا می‌باشد.
از آنجایی که پرداختن به تحلیل این بدافزار، نیازمند دانشی از معماری سفت‌افزار HP iLO می‌باشد، در این سند ابتدا اندکی درباره معماری HP و نقاط آسیب‌پذیر آن پرداخته شده است. سپس در بخش بعدی به تحلیل بدافزار کشف شده و ماژول‌های مختلف آن می‌پردازیم. در نهایت و در بخش آخر، به راهکارهای بررسی آلودگی و محافظت در برابر آن خواهیم پرداخت.
در کنار این گزارش، ابزارهایی جهت دامپ گیری و بررسی آلودگی سرورها توسعه داده شده است که در آینده نزدیک در اختیار عموم متخصصین قرار می‌گیرد. امیدواریم این گزارش نقطه شروعی برای توجه عمومی بیشتر به سفت‌افزارها و ایجاد راهکارهای محافظت از آنها باشد.
1.1 نکات کلیدی گزارش
- پنل مدیریتی iLO سرورهای HP محل امنی برای بدافزارها به شمار می‌رود که پس از آلودگی قابل تشخیص یا پاکسازی به روش‌های متعارف نیست.
- دسترسی به iLO و آلوده کردن آن، غیر از اینکه از طریق پورت شبکه iLO امکان‌پذیر است، از طریق داشتن دسترسی مدیر سیستم یا روت به سیستم عامل هاست نیز امکان‌پذیر است. یعنی در صورتیکه نفوذگر به کاربر admin ویندوز یا root سیستم عامل نصب شده روی سرور دسترسی داشته باشد، می‌تواند با iLO ارتباط برقرار کرده و در صورت آسیب‌پذیر بودن آن را آلوده نماید.
- تحقیقات انجام شده در طول سالیان گذشته، آسیب‌پذیری‌های متعددی را در HP iLO نشان داده‌اند که موجب ارائه وصله و تغییرات معماری از طرف سازنده شده است.
- در نسخه‌های iLO4 و قبلتر که در سرورهای G9 و ماقبل استفاده می‌شوند، مکانیزم بوت امن با داشتن کلید ریشه معتمد در سخت‌افزار وجود نداشته و سفت‌افزار این نسخه‌ها توسط بدافزار قابل تغییر و آلوده شدن می‌باشد.
- حتی در صورت به‌روزرسانی iLO به آخرین نسخه مربوطه که آسیب‌پذیری شناخته شده‌ای نداشته باشد، باز هم امکان دانگرید آن به نسخه‌های پایین‌تر آسیب‌پذیر وجود دارد. این موضوع در کلیه سرورهای HP وجود داشته و فقط در سری G10 به شرط فعال نمودن یک تنظیم غیرپیش‌فرض قابل جلوگیری مي‌باشد. در سایر سرورها، امکان جلوگیری از دانگرید و آلوده شدن سرور وجود ندارد.
- با توجه به موارد فوق، حتی قطع کردن کابل شبکه iLO یا آپگرید نمودن آن به آخرین نسخه جهت جلوگیری از آلودگی بدافزاری کافی نمی‌باشد.
- از سال 2020 گروه تحلیل بدافزار شرکت امن پرداز نهان‌افزاری را کشف کرده‌اند که یک ماژول بدافزاری با نام Implant.ARM.iLOBleed.a را به سفت‌افزار iLO اضافه می‌کند و تعدادی از ماژول‌های اصلی سفت افزار را نیز تغییر می‌دهد. به این ترتیب امکان به‌روزرسانی سفت افزار از بین می‌رود و دسترسی‌هایی به سخت‌افزار سرور ایجاد می‌شود که یکی از نتایج آن حذف کامل اطلاعات موجود روی دیسک‌های سرور است.
- ابزار بررسی صحت HP iLO توسط امن‌پرداز به زودی به صورت عمومی منتشر شده و در دسترس عموم قرار می‌گیرد.
1.2 علائم آلودگی
اگر چه معمولا در علائم آلودگی مواردی مانند هش و … بیان می‌شود، در دسترس نبودن ابزار dump سفت‌افزار iLO انتشار این نوع علائم آلودگی را بی‌فایده می‌کند. به علاوه در صورت دسترسی به این ابزار، استفاده از راهبرد لیست سفید یعنی مقایسه دامپ تهیه شده با مجموعه‌ی محدود سفت‌افزارهای اصیل HP کاری ساده‌تر و موثرتر می‌باشد.
اما اگر می‌خواهید بدانید که سرور شما آلوده شده است یا خیر، یک راه تشخیص ساده برای آلودگی وجود دارد:
همانگونه که بیان شد، این بدافزار جهت حفظ استتار و ماندگاری خود بعد از آپگرید سفت‌افزار، این عملیات را شبیه‌سازی می‌کند. اگر چه بدافزار تلاش می‌کند که با برداشتن شماره نسخه سفت‌افزار آپگرید شده و نمایش آن در محل‌های مختلف منجمله صفحه اصلی لاگین iLO، روند آپگرید را موفق جلوه بدهد، اما یک نکته وجود دارد: شرکت HP در رابط کاربری iLO تغییرات چشمگیری داده است. بنابراین تشخیص یک سفت‌افزار نادرست به سادگی با چشم ممکن است.
در شکل 1 می‌توانید مقایسه دو صفحه لاگین واقعی و جعلی (آلوده شده توسط بدافزار) را مشاهده کنید. هر دو صفحه اعلام می‌کنند که iLO نسخه ۲.۵۵ هستند اما صفحه لاگین آلوده، در واقع صفحه لاگین مربوط به iLO قدیمی ۲.۳۰ می‌باشد و فقط شماره نسخه آن توسط بدافزار جعل شده است.
شکل 1 – مقایسه صفحه لاگین جعلی (آلوده به بدافزار) با لاگین واقعی iLO
البته مانند هر علامت آلودگی و IOC دیگری، می‌شود انتظار داشت که بدافزارنویسان راهی برای تغییر این علامت و پنهان کردن آن بیابند. اما تا آن زمان، این روش ساده و موثری برای تشخیص بدافزار بدون نیاز به هیچ گونه ابزاری می‌باشد.
2 فناوری HP iLO
شرکت HP فناوری iLO را برای مدیریت این سیستم‌ها در اختیار کاربرانی که به عنوان مدیر سیستم فعالیت می‌کنند ارائه کرده است. این فناوری به مدیران سیستم اجازه می‌دهد تا به صورت ریموت و از راه دور با استفاده از یک واسط شبکه، به مشخصه‌های گوناگونی از سیستم تحت مدیریت خود دسترسی داشته باشند از جمله:
- مدیریت توان مصرفی
- دسترسی به کنسول سیستم از راه دور
- نصب CD/DVD Image از راه دور
- رصد و کنترل بسیاری از شاخص‌های سخت افزاری و نرم افزاری سیستم از راه دور
شرکت HP برای نسل‌های گوناگون سروهای خود در سال‌های اخیر نسخه‌های متنوعی از سفت افزار iLO را ارائه کرده است که جدول 1 این نسخه‌ها را نمایش می‌دهد.
جدول 1- نسخه‌های سفت‌افزار iLO برای نسل‌های گوناگون سرورهای HP
| سری سفت افزار iLO | نسل سرور HP ProLiant | آخرین نسخه سفت افزار ارائه شده |
| iLO | نسل 2 و 3 و 4 و نسل 6 (زیر سری 300) | 1.96- آوریل 2014 |
| iLO 2 | نسل 5 و 6 (بالای سری 300) | 2.33- مارس 2018 |
| iLO 3 | نسل 7 | 1.93- آگوست 2020 |
| iLO 4 | نسل 8 و 9 | 2.75- آگوست 2020 |
| iLO 5 | نسل 10 | 2.30- سپتامبر 2020 |
به دلیل حوزه اختیارات و عملکرد حساس این واسط سفت افزاری در تمام خانواده‌های سرور، سناریوهای گوناگونی برای حمله به این واسط قابل تصور است. از جمله این حملات، دستیابی به رمز عبور واسط مدیریتی، کشف و به‌کارگیری آسیب‌پذیری‌های امنیتی و همچنین فلش کردن سفت افزار آلوده به جای سفت افزار اصلی روی سرور است.
در سال‌های اخیر مجموعه‌ای از مطالعات با هدف شناخت آسیب‌پذیری‌های امنیتی واسط مدیریتی iLO سرورهای HP انجام گرفته است [1][2][3]. این مطالعات در نهایت منجر به کشف تعدادی آسیب‌پذیری با درجه خطر بالا و متوسط شده است. متأسفانه انتشار عمومی این آسیب‌پذیری‌ها و نمونه‌های کد برای اثبات این آسیب‌پذیری‌ها سبب شده است تا در چند سال اخیر، افراد یا گروه‌های مهاجم با استفاده از این آسیب‌پذیری‌ها، به زیرساخت شبکه برخی از سازمان‌ها که از سرورهای HP به منظور مدیریت شبکه‌های سازمانی خود استفاده می‌کنند حملاتی انجام دهند.
2.1 معماری سخت‌افزاری iLO
از دیدگاه سخت افزاری، iLO به صورت مجتمع در کنار بورد اصلی سیستم تعبیه شده است و شامل موارد زیر است [2]:
- پردازنده ARM با معماری GLP/Sabine
- حافظه فلش برای ذخیره‌سازی سفت‌افزار
- حافظه RAM اختصاصی
- واسط شبکه اختصاصی
- مجموعه‌ای از درگاه‌های سخت‌افزاری برای ارتباط با بخش‌های کنترلی
شکل 2- شماتیک سخت‌افزاری iLO
شکل 2 شماتیک سخت‌افزاری iLO را نمایش می‌دهد. همانطور که در این شکل قابل مشاهده است، پردازنده ARM به واسط PCI-Express به پل جنوبی و از طریق آن به پردازنده اصلی سرور متصل می‌شود. همچنین iLO به صورت مستقیم می‌تواند با CMOS نیز ارتباط برقرار کند. این نوع از ارتباط برای تنظیم متغیرهایی چون Boot Order است که از طریق واسط مدیریتی iLO این امر را امکان‌پذیر می‌کند.
2.1.1 پردازنده iLO
پردازنده مورد استفاده در iLO از سری پردازندههای نسل هفتم و هشتم ARM هستند. این پردازنده‌ها در کنار قدرت پردازش خوبی که دارند از سری تراشه‌های بسیار کم مصرف محسوب می‌شوند. این امر کمک می‌کند تا در حالتی که سرور در حالت انتظار قرار دارد بدون مصرف زیاد انرژی و جریان بیش از اندازه بتواند واسط مدیریتی را در اختیار مدیر شبکه قرار دهد.
2.1.2 حافظه‌های جانبی
پردازنده iLO می‌تواند با حافظه‌های متفاوتی در ارتباط باشد. به طور خاص، دو مورد از این تراشه‌ها در این بخش مورد بررسی قرار گرفته‌اند. نخست تراشه اصلی این سیستم است که بر روی آن سفت‌افزار iLO قرار دارد و هنگام بالا آمدن iLO، این سفت‌افزار بارگذاری می‌شود.
مورد دوم حافظه تراشه‌ای است که از آن با عنوان iLO NAND Flash یاد می‌شود که به عنوان حافظه جانبی سیستم در اختیار سیستم‌عامل iLO قرار دارد. پس از بارگذاری، سیستم‌عامل iLO با کمک این حافظه می‌تواند به ذخیره فایل‌هایی از قبیل تاریخچه رخدادهای سیستم بپردازد. همچنین این حافظه محل ذخیره برنامه‌هایی است که توسط سیستم عامل iLO اجرا می‌شوند.
2.1.3 ارتباط iLO با سرور
فناوری iLO به عنوان یک واحد مدیریت و کنترل سرور، به تمامی اجزاء سخت افزاری سرور از قبیل حافظه، پردازنده، درگاه‌های ورودی و خروجی و دیسک سخت دسترسی مستقیم دارد. همچنین پردازنده اصلی سرور نیز iLO را به عنوان یک ماژول PCI شناسایی می‌کند و می‌توان با آن ارتباط برقرار کند.
2.2 ساختار سفت‌افزار iLO
سفت‌افزار iLO به صورت یک فایل باینری درون حافظه فلش SPI (اغلب با اندازه 16 مگابایت) ذخیره شده است. همانطور که در شکل 3 دیده می‌شود، این سفت افزار از 3 بخش اصلی Boot loader، هسته سیستم عامل (Kernel) و بخش ماژول‌ها تشکیل شده است. از این 3 بخش، تنها بخش Boot loader به صورت رمزگذاری نشده است و دو بخش دیگر رمزگذاری شده و فشرده (با الگوریتم LZMA) و دارای امضاء امنیتی هستند. تمامی محتوای سفت افزار iLO به صورت کدهای کامپایل شده C با معماری ARM است.
شکل 3- ساختار درونی سفت‌افزار iLO
از دیدگاه نرم افزاری، iLO سرویس‌های گوناگونی مانند Web Server و SSH Server را برای مدیران سرورها ارائه می‌کند. در واقع iLO به منزله یک سیستم‌عامل کامل است که به محض اتصال سیستم به برق، حتی در شرایطی که هاست سرور خاموش است بالا می‌آید و سرویس‌های خود را در دسترس قرار می‌دهد.
در زمان بوت شدن iLO، قبل از اجرای هر بخش (هسته سیستم عامل و ماژول‌های اجرایی)، بخش قبل باید امضای آن را صحت‌سنجی نماید تا اجازه اجرا به آن داده شود. به این ترتیب، بخش Boot Loader مسئول صحت سنجی امضاء، استخراج از وضعیت فشرده و بارگذاری بخش Kernel خواهد بود. همچنین بخش Kernel مسئول صحت‌سنجی امضاء، استخراج از وضعیت فشرده و بارگذاری ماژول‌های اجرایی خواهد بود.
سیستم عامل مورد استفاده در بخش سفت افزار iLO یک سیستم عامل بی‌درنگ به نام Integrity است که توسط شرکت Green Hills Software توسعه داده شده است و مسئول اجرای وظایف موجود در ناحیه کاربر است. ناحیه کاربر در واقع یک فایل باینری ELF با معماری ARM است که توسط شرکت HP توسعه یافته و پک شده است. این فایل دارای ماژول‌های متنوعی است هر یک دارای وظیفه خاصی هستند. هر وظیفه به‌صورت یک پردازه با فضای حافظه مجازی اختصاصی و مجموعه‌ای از ریسمان‌های پردازشی است که در ناحیه کاربر اجرا می‌شود. در بخش‌های بعد این مستند عملکرد، برخی از مهمترین ماژول‌های iLO تشریح خواهد شد.
2.3 ماژول‌های iLO
شکل 4 تعدادی از ماژول‌های User Land در سفت‌افزار iLO 4 را نشان می‌دهد. در ادامه این بخش، عملکرد تعدادی از مهمترین ماژول‌ها تشریح می‌شوند.
شکل 4- تعدادی از ماژول‌های User Land در سفت‌افزار iLO 4
2.3.1 ماژول Web Server: ارائه واسط مدیریتی وب
ماژول Web Server وظیفه ارائه واسط مدیریتی iLO در قالب سرویس وب را بر عهده دارد. این ماژول دارای بخش‌هایی نظیر واسط وب، یک واسط برنامه نویسی XML، یک واسط برنامه نویسی Redfish، و یک کنسول کنترل از راه دور است.
اتصال به ماژول Web Server می‌تواند از نوع HTTP و یا HTTPS باشد. این ماژول دارای چهار ریسمان پردازشی است که هر ریسمان مسئول اداره و پاسخگویی به یکی از اتصالاتی است که با ماژول ایجاد می‌شوند. هر درخواست اتصال به صورت خط به خط مورد پردازش قرار می‌گیرد و محتوای آن تجزیه و تحلیل می‌شود و در صورت صحت احراز هویت و سطح دسترسی آن، پاسخ مورد نظر ارائه می‌شود. اگرچه تقریبا دسترسی به تمامی صفحات وب نیاز به احراز هویت کاربر دارد، اما برخی از داده‌ها در قالب XML بدون طی کردن فرآیند احراز هویت قابل دسترسی هستند.
2.3.2 ماژول CHIF: ارتباط با پردازنده سرور
ماژول CHIF یکی از ماژول‌های موجود در iLO است که وظیفه ارتباط با بخش‌های پردازنده و حافظه سرور و انتقال پیام میان iLO و سیستم عامل میزبان را بر عهده دارد. به طور خلاصه می‌توان وظایف این ماژول را به شرح زیر لیست کرد [3]:
- انتظار برای دریافت پیام از سمت سرور
- ارسال پیام دریافتی به واحد پردازش پیام (Command Handler) متناسب با پیام
- ارسال پیام‌های خاص به سایر ماژول‌های مرتبط با پیام
عملیات انتقال و پردازش پیام‌ها در این ماژول به‌طور پیش فرض هیچگونه فرآیند احراز هویتی را طی نمی‌کند.
2.3.3 ماژول FUM: به‌روزرسانی سفت‌افزار iLO
وظیفه اصلی ماژول FUM به‌روزرسانی سفت‌افزار iLO است. این وظیفه از سه طریق امکان‌پذیر است:
- از طریق واسط مدیریتی HP Intelligent Provisioning
- با استفاده از سیستم عامل میزبان نصب شده روی سرور و با دسترسی به واسط PCI-E
- از راه دور و از طریق واسط مدیریتی واسط وب iLO
ماژول FUM عملیات به‌روزرسانی سفت افزار را در 5 مرحله انجام می‌دهد که شامل مراحل زیر است [3]:
1. فایل سفت افزار جدید از طریق هاست سرور و یا ماژول Web Server دریافت می‌شود.
2. فایل سفت افزار جدید به ماژول FUM ارسال می‌شود.
3. ماژول FUM فایل سفت افزار جدید را از جهت صحت امضاء و جامعیت بررسی و اعتبار سنجی می‌کند.
4. ماژول FUM از هسته سیستم عامل نیز می‌خواهد تا صحت فایل سفت افزار جدید را اعتبار سنجی کند.
5. ماژول FUM از ماژول SPI درخواست می‌کند تا فایل سفت افزار جدید را روی حافظه فلش SPI برنامه ریزی نماید.
شکل 5- فرآیند به‌روزرسانی سفت‌افزار iLO توسط ماژول FUM
در این فرآیند، صحت سنجی جامعیت سفت افزار از طریق بررسی صحت امضاء دیجتال فایل سفت افزار انجام می‌گیرد تا ماژولی به سفت افزار اصیل که توسط شرکت HP ارائه شده است افزوده یا کاسته نشود. نکته مهم این است که در فرآیند به‌روز رسانی سفت افزار، امکان به‌روزرسانی به نسخه پایین‌تر سفت افزار وجود دارد.
2.3.4 ماژول SPI: دسترسی به حافظه فلش
وظیفه اصلی این ماژول، ارتباط با حافظه فلش SPI حاوی سفت‌افزار iLO و سفت‌افزار BIOS سرور است. از طریق این ماژول، عملیات خواندن، نوشتن و پاک کردن حافظه‌های فلش حاوی سفت‌افزار انجام می‌شود. همانطور که قبلاً نیز اشاره شد، بخش‌نهایی عملیات به‌روز رسانی سفت‌افزار iLO از طریق این ماژول انجام می‌شود.
2.3.5 ماژول ConAppCli: سرویس کنسول
این ماژول وظیفه ارائه سرویس واسط کاربری خط فرمان دریافت فرمان‌های کاربر و مدیر سرور را بر عهده دارد. این فرمان‌ها می‌توانند از نوع روشن/خاموش کردن iLO، مدیریت کاربران، مدیریت توان مصرفی، مشاهده رخدادهای سیستم و .. باشد.
2.3.6 ماژول SSH: خط فرمان از راه دور
سفت افزار iLO علاوه بر واسط وب، با استفاده از ماژول SSH سرویس shell رمز شده را در اختیار کاربر قرار می‌دهد و کاربر می‌تواند از طریق پورت 22 با سفت افزار ارتباط برقرار نماید و مجموعه‌ای از فرمان‌ها را اجرا نماید.
2.3.7 ماژول Health: سرویس رصد صحت اجزاء سیستم و ثبت رخدادها
وظیفه این ماژول، بررسی دوره‌ای وضعیت مشخصات سیستم و ثبت رخدادهای سرور است. مشخصات سیستم شامل دمای کاری، سرعت فن‌ها، وضعیت منبع تغذیه، وضعت حافظه‌های سیستم، شبکه، پردازنده‌ها و … است.
2.3.8 ماژول BlackBox: جعبه سیاه سیستم
این ماژول به منزله جعبه سیاه سرور عمل می‌کند و بسیاری از اطلاعات و رخدادهای حساس و حیاتی سیستم که توسط ماژول Health ثبت می‌شوند، توسط این ماژول به صورت روزانه در قالب یک فایل فشرده ذخیره می‌شوند.
2.3.9 سایر ماژول‌ها
علاوه بر ماژول‌های ذکر شده در بخش‌های قبل، سفت افزار iLO دارای ماژول‌های متنوع دیگری است که هریک در بخش UserLand دارای وظیفه مشخصی هستند. ماژول‌هایی مانند SNMP و SNTP و SVCSiLO وظایف مدیریت سیستم و شبکه را بر عهده دارند و ماژول‌هایی مانند USB، GPIO، I2C دسترسی کنترلی iLO به بخش‌های سخت افزاری سرور را فراهم می‌کنند.
3 تحلیل نهان‌افزار Implant.ARM.iLOBleed.a
در این بخش به تحلیل فنی نهان‌افزار کشف شده در سفت‌افزار HP iLO می‌پردازیم.
زمانیکه تیم تحلیل امن‌پرداز این بدافزار را کشف نمود، مهاجمان تصمیم به تخریب اطلاعات دیسک‌های سرور و از بین بردن کامل آن گرفته بودند. جالب اینجاست که مهاجمین به یکبار تخریب اکتفا نکرده، و بدافزار را برای اجرای مکرر تخریب در بازه‌های زمانی تنظیم کرده بودند. به این ترتیب بعد از هر بار راه‌اندازی سرور با سیستم عامل جدید، پس از مدتی مجددا کل هاردها تخریب می‌گردید. اما این بدافزار برخلاف سایر بدافزارهای Wiper که صرفا به تخریب اطلاعات می‌پردازند، به قصد یکبار اجرا و ضربه زدن ایجاد نشده است.
یکی از قابلیت‌های مهم این بدافزار، دستکاری روال آپگرید سفت‌افزار iLO می‌باشد، به این نحو که در صورتی که مدیر شبکه تلاش کند سفت‌افزار iLO را به به نسخه جدیدی ارتقا دهد، بدافزار ضمن جلوگیری از انجام روال آپگرید، تغییر نسخه را شبیه‌سازی می‌کند. به این منظور علاوه بر آنکه روال آپگرید در ظاهر اجرا شده و پیام انجام موفقیت‌آمیز آن نمایش داده می‌شود، حتی شماره نسخه سفت‌افزار نیز در ظاهر کنسول وب و سایر مکان‌ها افزایش پیدا می‌کند، در حالیکه در واقع هیچگونه آپگریدی انجام نشده است.
همین مساله به تنهایی نشان می‌دهد که هدف از تولید آن، ایجاد یک بدافزار با حداکثر مانایی و مخفی ماندن از کلیه مکانیزم‌های شناخته شده امنیتی می‌باشد. بدافزاری که با پنهان شدن در یکی از پرقدرت‌ترین منابع پردازشی که همواره نیز روشن است، قابلیت انجام هر دستوری از طرف مهاجمین را داشته باشد، بدون اینکه هرگز کشف گردد.
طبیعتا هزینه صرف شده برای چنین حمله‌ای آن را در دسته APTها قرار می‌دهد. اما استفاده از چنین بدافزار قدرتمند و پرهزینه‌ای برای کاری مانند تخریب اطلاعات که احتمال کشف بدافزار را افزایش می‌دهد، به نظر یک اشتباه فاحش از سمت این گروه می‌باشد.
سایر نکات فنی درباره این بدافزار را در بخش‌های آتی مطالعه می‌فرمایید.
3.1 ابزار تهیه رونوشت از سفت‌افزار
اولین گام برای بررسی آلودگی سفت‌افزار، تهیه رونوشت یا اصطلاحا دامپ کامل از سفت‌افزار جهت بررسی می‌باشد.
متاسفانه شرکت HP ابزار یا روشی را جهت بررسی و خواندن سفت‌افزار iLO ارائه نکرده است. به همین منظور تهیه یک ابزار جهت دامپ سفت‌افزار در دستور کار قرار گرفت که نهایتا به صورت ابزار Padvish iLO Scanner در دو نسخه تکامل پیدا کرد:
1.پویش از داخل سیستم عامل میزبان: همانطور که بیان شد، سخت‌افزار iLO به عنوان یک کارت PCI-Express از طریق پردازنده اصلی و سیستم عامل نصب شده روی سیستم قابل دسترسی می‌باشد. البته شرکت HP نیز ابزاری با نام flash_ilo جهت نوشتن و به‌روزرسانی سفت‌افزار به نسخه‌های جدید برای سیستم‌عامل‌های مختلف ارائه داده است، اما ابزار مذکور تنها امکان نوشتن سفت‌افزار را فراهم کرده و اجازه خواندن سفت‌افزار قبلی را نمی‌دهد. به همین منظور و بر پایه دانش به دست آمده در حوزه iLO، ابزاری جهت خواندن سفت‌افزار و تهیه دامپ از آن توسعه دادیم.
2.پویش از طریق پورت iLO: از آنجاکه پویش از طریق سیستم عامل میزبان ممکن است همواره میسر نبوده و انجام آن روی سرورهای عملیاتی و یا در حجم انبوه برای مدیران شبکه دشوار باشد، روش دیگری جهت پویش سفت‌افزار مدنظر قرار گرفت. این نسخه از پویشگر از طریق استفاده از یکی از آسیب‌پذیری‌های شناخته شده روی iLO و با اجرای کد از راه دور، امکان تهیه دامپ را فراهم می‌کند. به علت استفاده از آسیب‌پذیری، دریافت دامپ در این نسخه فقط از سفت افزار سرورهای HP iLO4 با بازه نسخه سفت افزار 2.30 تا 2.50 وجود دارد.
3.2 تحلیل سفت‌افزار آلوده
پس از تهیه رونوشت از سفت‌افزار یک سرور، باید آن را با نسخه‌های سفت‌افزار اصلی مقایسه نمود. بدافزار Implant.ARM.iLOBleed.a بر اساس نسخه ۲.۳۰ سفت‌افزار iLO توسعه داده شده است. بر همین اساس تفاوت بین این نسخه آلوده را با نسخه اصلی در (شکل 6) مشاهده می‌کنید.
شکل 6- اختلاف امضاء سفت‌افزار: (بالا) رونوشت سیستم؛ (پایین) نسخه اصلی ارائه شده توسط شرکت HP
در یک بررسی دقیقتر، اجزاء هر دو سفت‌افزار در سطح فایل سیستم و ماژول‌ها نیز مقایسه شدند که نتایج این مقایسه در جدول 2 قابل مشاهده است.
جدول 2- مقایسه امضاهای ماژول‌های سفت‌افزار سیستم مورد حمله با نسخه اصلی
| Difference (Bytes) |
(MD5 (Infected | (MD5 (Original | Module Name |
|
| 15.625MB | 4f8417af3a6f75780e09c5792397a05f | 98af47cb8cacb25abd333d8a1a752c6b | hpimage.bin |
|
| 0 | 8433650ef98fd8790877e6616c02b66c | 8433650ef98fd8790877e6616c02b66c | hpimage.hdr | – |
| 0 | ae22d82a3e954ecf911b834463dbfbbe | ae22d82a3e954ecf911b834463dbfbbe | bootloader.hdr | |
| 5B | 1fdb4270665177ecb1c9708039bab934 | 20ff78c6604563c27b6f9c75775c9306 | bootloader.bin | |
| 2B | 7df3b258ca3c12f0f8de77469456e25d | e1b1244fead44f73efb7b559e9d719c9 | kernel_main.hdr | |
| 12B | 9ab97c5b03664da18ab1f775dc11c200 | bacc259ea63785607faf2dab6939a2db | kernel_main.bin | |
| 2B | 7df3b258ca3c12f0f8de77469456e25d | e1b1244fead44f73efb7b559e9d719c9 | kernel_recovery.hdr | |
| 12B | 9ab97c5b03664da18ab1f775dc11c200 | bacc259ea63785607faf2dab6939a2db | kernel_recovery.bin | |
| 2B | 64d0143d638885745b241796268eb0b2 | 7db6ebd698fa4862cfde68a546e9a75b | ELF.hdr | |
| 15.625MB | bdeeab3994ec5d0b93d961148a6b712d | d16fee481f78ad0275dd29ed271582aa | ELF.bin | |
طبق اطلاعات این جدول، از کل ماژول‌های تشکیل دهنده hpimage.bin، تنها دو بخش سرآیند hpimage و سرآیند bootloader یکسان هستند. در سایر بخش‌ها تفاوت امضاء نشان‌دهنده وجود اختلاف میان دو فایل در این بخش‌ها است. همچنین می‌توان مشاهده کرد که بخش عمده تغییرات مربوط به ماژول ELF.bin می‌باشد، در حالیکه سایر ماژول‌ها فقط ۲ تا ۱۲ بایت تغییر داشته‌اند.
3.2.1 مانایی بدافزار در بوت
یکی از دغدغه‌های توسعه‌دهندگان هر نوع بدافزار، آلوده ماندن سیستم پس از قرار گرفتن بدافزار در سیستم است.
همانطور که در بخش ساختار سفت‌افزار iLO بیان شد، در فرآیند راه اندازی iLO ماژول bootloader وظیفه اعتبارسنجی امضای هسته سیستم عامل را برعهده داشته، و هسته سیستم نیز وظیفه اعتبارسنجی امضای ماژول‌ها را بر عهده دارد. بنابراین، در صورتی که فرد مهاجم بخواهد در سفت افزار iLO درب پشتی ایجاد کند، علاوه بر قرار دادن درب‌پشتی که اصولا در فایل ELF.bin انجام می‌گیرد، لازم است مکانیزم اعتبارسنجی هسته سیستم عامل، و به تبع آن مکانیزم اعتبار سنجی bootloader را از کار بیاندازد.
شکل 7- دور زدن فرآیند اعتبار سنجی امضاء هسته سسیتم‌عامل و بخش ماژول‌های iLO
شکل 7 روند دور زدن فرآیند اعتبار سنجی امضاء هسته سیستم‌عامل و بخش ماژول‌های iLO را به طور خلاصه نشان می‌دهد [2]. پس از استخراج سه بخش اصلی bootloader.bin، kernel.bin و ELF.bin از طریق مهندسی معکوس، آدرس توابعی که در دو بخش bootloader و kernel عملیات بررسی و اعتبار سنجی امضاء را انجام می‌دهند جستجو و با دستور NOP جایگزین می‌شوند. در مرحله آخر فایل‌های تغییر یافته در کنار یکدیگر تجمیع شوند تا یک فایل کامل با فرمت HP Image را تشکیل دهند و فایل ایجاد شده در حافظه فلش SPI نوشته می‌شود. پس از یک راه اندازی مجدد، می توان مشاهده نمود که سفت‌افزار آلوده به درب پشتی بدون مشکل بارگزاری می‌شود.
3.2.2 بررسی سطح ماژول
3.2.2.1 بخش Boot Loader
طبق اطلاعات مندرج در جدول 2 اختلاف میان دو بخش Boot Loader 5 بایت است که تحلیل جزئی‌تر آن نشان می‌دهد که این اختلاف ناشی از تغییر تابع مسئول اعتبارسنجی امضاء بخش kernel و غیرفعال (NOP) کردن این فرآیند است (شکل 8).
شکل 8- غیرفعال کردن بخش اعتبارسنجی امضاء امضاء در بخش Bootloader
3.2.2.2 بخش Kernel
طبق اطلاعات مندرج در جدول 2 اختلاف میان دو بخش کرنل 12 بایت است که تحلیل جزئی‌تر آن نشان می‌دهد که این اختلاف ناشی از تغییر تابع مسئول اعتبارسنجی امضاء بخش userland (از طریق coprocessor) و غیرفعال (NOP) کردن این فرآیند در 3 مکان است (شکل 9).
شکل 9- غیرفعال شدن بخش اعتبارسنجی امضاء بخش userland در بخش Kernel
3.2.2.3 بخش UserLand
استخراج بخش User Land سفت افزار iLO و مقایسه محتوای آن با نسخه 2.30 اصلی ارائه شده توسط شرکت HP نشان‌دهنده حذف یک فایل (sectionInfo) و افزوده شدن یک ماژول جدید (با نام newELF به صورت 17 بخش مجزا) به بخش User Land است (شکل 10). علاوه بر اضافه شدن ماژول‌های جدید بدافزار، تعدادی از ماژول‌های موجود در نسخه اصلی نیز تغییر کرده‌اند.
شکل 10- فایل‌های تغییریافته در سفت‌افزار سیستم آلوده
در این بخش مقایسه‌ای بین ماژول‌های نسخه اصلی و ماژول‌های تغییریافته در این بدافزار انجام گرفته است که نتایج آن در جدول 3 به صورت کامل قابل مشاهده است.
جدول 3- مقایسه نسخه iLO دارای NewELF با نسخه اصلی
| New Op | Old Op | Function | Offset | File Name |
| BL | MOV | sub_10070 | 0x280 | Chif.ELF.text |
| BL | ADD | sub_19BD0 | 0x9c28 | Chif.ELF.text |
| BL | SUB | sub_10210 | 0x218 | Webserver.ELF.text |
| BL | BL | sub_3AEC4 | 0x2af80 | Webserver.ELF.text |
| BL | BL | sub_3AEC4 | 0x2b024 | Webserver.ELF.text |
| BL | MOV | sub_152AC | 0x5840 | Health.ELF.text |
| BL | MOV | sub_47B1C | 0x37b30 | Health.ELF.text |
| BL | BLNE | sub_13B68 | 0x4324 | Fum.ELF.text |
| BL | MOV | sub_13B68 | 0x43b8 | Fum.ELF.text |
| BL | BL | sub_13B68 | 0x4400 | Fum.ELF.text |
| BL | MOV | sub_14720 | 0x4738 | Fum.ELF.text |
| BL | SUB | sub_109A4 | 0x9ac | Json_dsp.ELF.text |
| BL | BL | sub_19F48 | 0xa564 | Json_dsp.ELF.text |
| BL | BL | sub_73190 | 0x6324c | Json_dsp.ELF.text |
| BL | BL | sub_73190 | 0x632f0 | Json_dsp.ELF.text |
| BL | MOV | sub_114EC | 0x1578 | SvcsiLO.ELF.text |
| BL | BL | sub_14300 | 0x4310 | SvcsiLO.ELF.text |
| BL | MOV | sub_1F378 | 0xf388 | SvcsiLO.ELF.text |
3.2.3 بررسی فایل‌های ایجاد شده توسط بدافزار
بدافزار Implant.ARM.iLOBleed.a در داخل NAND Flash که فضای کاری و حافظه جانبی قابل خواندن نوشتن iLO است، 3 فایل ایجاد می‌کند. به نظر می‌رسد که مسیر و حتی نام این فایل‌ها از طریق یک Configurator قابل تنظیم بوده است. در نسخه بدافزار موجود، این سه فایل با نام‌های lifesignal.bin، schedule.bin و fakefwdata.bin وجود دارند (جدول 4).
جدول 4- سه فایل استفاده شده در بدافزار
| نام فایل | مسیر ذخیره | ماژول‌های مرتبط |
| lifesignal.bin | i:\vol0\logs\lifesignal.bin | Chif.tool – NewELF.ELF |
| schedule.bin | i:\vol0\logs\schedule.bin | NewELF |
| fakefwdata.bin | i:\vol0\logs\fakefwdata.bin | Fum.tool – NewELF.ELF |
در صورتی که مدیر سیستم تلاش کند نسخه سفت‌افزار سرور خود را ارتقا دهد، بدافزار ضمن جلوگیری و شبیه‌سازی عملیات ارتقای سفت‌افزار جهت فریب مدیر سیستم، در فایل fakefwdata.bin اطلاعات این عملیات را درج می‌کند.
بررسی فایل schedule.bin در کنار سایر بخش‌های بدافزار نشان می‌دهد که درون این فایل دو عدد 4 بایتی قرار دارد که بدافزار از محتوای آن برای برنامه ریزی حذف محتوای دیسک‌های سخت سرور استفاده می‌کند. عدد 4 بایتی اول بیانگر شمارنده‌ای است که به یک مقدار اولیه مقداردهی می‌شود و سپس با هر بار اجرای فرآیند حذف اطلاعات دیسک، یک واحد از آن کم می‌شود تا به صفر برسد. عدد دوم نیز بیانگر تاریخ اجرای فرآیند پاکسازی دیسک است (شکل 11).
شکل 11- اشاره فایل schedule.bin به تاریخ به‌روزرسانی سفت‌افزار
3.2.4 تحلیل ماژول newELF
این ماژول یک ELF کامل است که به انتهای Boottable اضافه شده و تعداد پردازه‌های آن را نیز به اندازه یک واحد افزایش داده است. این ELF همانند سایر ELFهای این سفت‌افزار، از چند بخش اساسی تشکیل شده است. اولین بخش آن NewELF.ELF.Initial.text است که برخلاف سایر ELFها خالی از محتوا نیست و در داخل آن کدهایی وجود دارد. با بررسی دقیقتر می‌توان دریافت که این بخش شباهت بسیار زیادی به ConAppCLI.ELF.text دارد که یکی از بخش‌های اصلی سفت‌افزار iLO است. در جدول 5 مقایسه‌ای کلی بین این دو ماژول صورت گرفته است که تفاوت آنها را نشان می‌دهد. این شباهت‌ها نشان می‌دهد که ساختار پایه بدافزار Implant.ARM.iLOBleed.a مبتنی بر توابع ماژول ConAppCLi است.
جدول 5- مقایسه بین ConAppCLI.ELF.text و NewELF.ELF.Initial.text
| NewELF.ELF.Initial.text Opcode | ConAppCli.ELF.text Opode | Function | Offset |
| STMFD | STMFD | sub_10070 | 0x74 |
| SUB | SUB | sub_10070 | 0x7c |
| LDMDB | LDR | sub_10070 | 0x80 |
| Add Zero Buffer | – | End of Old File | 0x91c78 |
بخش دیگر و اساسی بدافزار، بخش NewELF.ELF.text است. شکل 12 تابع اصلی اجرا کننده بدافزار را نشان می‌دهد. یکی از وظایف اصلی این تابع، مقداردهی یک ساختار داده است که پارامترهای اصلی اجرای عملیات بدافزار را تعیین می‌کند و بخشی از آن در شکل 13 نشان داده شده است. در ابتدای این تابع آدرس فایل schedule.bin در یک متغیر کپی شده و اشاره‌گر این آدرس در آدرس 0x0c ساختار داده کپی می‌شود.
شکل 12- تابع اصلی اجراکننده بدافزار
در ادامه، در تابع دیگری با نام initOperationConfigFiles، وضعیت فایل‌های مورد نیاز بدافزار بررسی می‌شود. در این تابع در ابتدا فایل lifesignal.bin ساخته می‌شود و سپس بنا به شرایط عملیات، در مورد فایل schedule.bin تصمیم‌گیری می‌شود؛ به این صورت که اگر فایل schedule.bin وجود داشته باشد و ساختار معتبری داشته باشد، محتوای آن در آدرس‌های 0 تا 0x07 ساختار داده کپی می‌شود و در فایل lifesignal.bin مقدار 0x3 نوشته می‌شود. در صورت عدم وجود این فایل در آدرس مربوطه، این فایل ایجاد می‌شود و با مقادیر اولیه پر می‌شود. پس از آن نیز ساختار داده به صورت کامل پر می‌شود. در شرایطی که فایل schedule.bin دارای ساختار نامعتبری باشد، در فایل lifesignal.bin مقدار 0x9 نوشته می‌شود.
شکل 13- ساختار داده پارامترهای عملیاتی بدافزار
همانطور که قبلا تشریح شد، فایل schedule.bin از دو عدد 4 بایتی تشکیل شده است. در ابتدای عملیات، در تابع initOperationConfigFiles عدد شمارنده به مقدار بیشینه ممکن این شمارنده (آدرس 0x24 ساختار داده) و عدد تاریخ نیز بر روی ساعت و روز مورد نظر اجرای فرمان تنظیم می‌شود. در یک نمونه تحلیل شده از این بدافزار، مقدار بیشنیه تکرار عملیات روی 0x2 و در نمونه دیگر روی 0x3e8 (معادل 1000 مرتبه) تنظیم شده است.
پس از بررسی مناسب بودن شرایط اجرای عملیات تخریب، عملیات در تابع startPeriodicOperation آغاز می‌شود (شکل 14). وظیفه این تابع در مرحله اول، ایجاد و پرکردن آرایه‌ای از ساختار داده عملیات با طول بیشینه مقدار اجرای عملیات است. هریک از این ساختار داده‌ها با مقادیر گوناگون زمان اجرای عملیات مقداردهی می‌شود. این مقداردهی به این صورت است که بدافزار مضارب گوناگون دوره تناوب اجرای عملیات (مثلا 12 ساعت) را به یک زمان انتظار اولیه (مثلاً 36 ساعت) اضافه می‌کند و این مقدار را در آدرس 0x1C هریک از ساختار داده‌ها ثبت می‌کند. در این صورت، عملیات پس از طی زمان انتظار (36 ساعت) از زمان ثبت شده در فایل schedule.bin آغاز می‌شود و در هر دوره تناوب تکرار می‌شود. در نهایت تابع startWipeOperation فراخوانی می‌شود که عملیات تخریب دیسک را انجام می‌دهد.
شکل 14- بدنه تابع startPeriodicOperation
تابع startWipeOperation در یک حلقه عملیات تخریب را انجام می‌دهد این تابع در شکل 15 نشان داده شده است. در ابتدای این حلقه، تابعی به نام GetAndValidateOperationParameters صحت پارامترهای عملیات را بررسی می‌کند و تعداد عملیات باقی مانده را محاسبه می‌کند. در حقیقت تعداد عملیات انجام شده در متغیری به نام SuccessfulOperationCount استخراج می‌شود و بررسی می‌شود که عدد بدست آمده از بیشینه مقدار شمارنده بیشتر نباشد.
شکل 15- بدنه تابع startWipeOperation
تابع بعدی تابع WaitForNextOperationTarget است که محتوای آن در شکل 16 به نمایش درآمده است. وظیفه این تابع، ایجاد انتظار در حلقه اصلی تا زمان رسیدن به زمان اجرای عملیات بعد است. در زمان مقرر، این تابع از حلقه خارج خود شده و حلقه اصلی عملیات به کار خود ادامه می‌دهد.
شکل 16- بدنه تابع WaitForNextOperationTarget
در قسمت بعدی حلقه اصلی عملیات wipeDisk انجام می‌شود و دیسک سرور به صورت کامل پاکسازی می‌شود و اطلاعات آن حذف می‌شود. پس از اتمام عملیات تخریب، فایل schedule.bin توسط تابع DecrementOperationCount به‌روزرسانی شده و یک عدد از شمارنده آن کم می‌شود. بدنه تابع DecrementOperationCount در شکل 17 نشان داده شده است.
شکل 17- بدنه تابع DecrementOperationCount
3.2.5 تحلیل ماژول‌های ابزاری
ماژول‌های ابزاری در این بدافزار به این دلیل در سفت‌افزار گنجانده شده‌اند که اختلالاتی را در کارکرد آن برنامه‌ها ایجاد کنند. البته گاهی نیز این امر به صورت اختلال دیده نمی‌شود بلکه عملی را خارج از عملکرد واقعی آن برنامه انجام می‌دهند. این بدافزار در حالت کلی 6 ماژول ابزاری دارد که در زیر لیست شده‌اند:
جدول 6- ماژول‌های ابزاری بدافزار
| نام ماژول | شرح |
| .chif.tools | تغییر کانال تبادل پیام میان iLO و سرور |
| .fum.tools | دور زدن فرآیند به‌روز رسانی سفت‌افزار به منظور ابقاء سفت‌افزار آلوده |
| .webserver.tools | تغییر واسط وب مدیریتی برای نمایش اطلاعات نامعتبر نسخه سفت‌افزار iLO |
| .health.tools | تغییر ماژول ثبت رخدادهای سرور برای غیرفعال‌سازی ثبت رخدادهای مربوط به عملکرد بدافزار |
| .svcsiLO.tools | تغییر بخش چند نخی هسته سیستم‌عامل iLO |
| .json_dsp.tools | نامشخص |
4 جمع‌بندی مطالب
امنیت سفت‌افزار در سال‌های اخیر به عنوان یک موضوع مهم در امنیت فناوری اطلاعات مطرح می‌شود که در عمل توجه کافی به آن نمی‌شود. به دلیل امکانات و سطح دسترسی بالایی که ابزار مدیریتی HP iLO در اختیار دارد، نیازمند روش‌های محافظتی ویژه‌ای می‌باشد. متاسفانه نبود ابزارها و اطلاعات کافی و اختصاصی بودن محیط iLO باعث می‌شود بسیاری از محققین امنیت در بررسی این سیستم‌ها دست بسته باشند. بدتر از آن، با وجود اینکه پژوهش‌های منتشر شده توسط محققین امنیت در گذشته امکان‌پذیری قرارگیری بدافزار فرضی در این سفت‌افزار را بررسی کرده بود [2]، همچنان راهکاری جهت کشف آلودگی و رفع آن در صورت اتفاق به صورت عمومی ارائه نشده است.
نکته مهم دیگر وجود راه‌های دسترسی و آلوده نمودن iLO هم از طریق شبکه و هم از طریق سیستم عامل میزبان می‌باشد. این مساله به این معناست که حتی با قطع کامل کابل شبکه iLO، باز هم امکان آلوده شدن و قرارگیری بدافزار در آن وجود دارد. جالب اینجاست که هیچ راهکاری برای خاموش نمودن یا غیرفعال نمودن کامل iLO در مواردی که نیازی به آن نیست نیز دیده نشده است.
این موضوعات ضرورت انجام اقدامات امنیتی پیشگیرانه جهت ارتقاء سطح امنیت سفت‌افزار مانند به‌روزرسانی به آخرین نسخه ارائه‌شده توسط سازنده، تغییر دوره‌ای رمزعبور کاربران و جداسازی شبکه iLO از شبکه عملیاتی و در نهایت پایش دوره‌ای وضعیت سفت‌افزار از منظر پارامترهای امنیتی و آلودگی‌های احتمالی بیش از پیش اهمیت دارد.
4.1 راهکارهای پیشنهادی حفاظت iLO
- عدم اتصال واسط شبکه iLO به شبکه عملیاتی و اختصاص یک شبکه کاملا مجزا
- به‌روز رسانی دوره‌ای نسخه سفت‌افزار iLO به آخرین نسخه رسمی ارائه شده توسط شرکت HP
- غیر فعال نمودن امکان دانگرید و انجام تنظیمات امنیتی iLO روی سرورهای نسل دهم HP
- استفاده از تجهیزات امنیتی دفاع در عمق جهت کاهش ریسک و کشف نفوذها قبل از رسیدن به iLO
- استفاده دوره‌ای از ابزار پویشگر iLO پادویش به منظور کشف آسیب‌پذیری‌ها، بدافزارها و درب‌های پشتی احتمالی در نسخه کنونی سفت‌افزار iLO سرور
5 مراجع
[1] F. Périgaud, A. Gazet, and J. Czarny, “Subverting your server through its BMC: the HPE iLO4 case,” Recon, 2018.
[2] F. Périgaud, A. Gazet, and J. Czarny, “Backdooring your server through its BMC: the HPE iLO4 case,” SSTIC, 2018.
[3] F. Périgaud, A. Gazet, and J. Czarny, “Turning your BMC into a revolving door,” ZeroNights, 2018.