آسیب‎پذیری امنیتی ManageEngine ADManager 6.6

سلام ، امشب مطلع شدم یک باگ ارتقای سطح دسترسی در یکی از محبوب‌ترین پلتفرم‌های مدیریت اکتیودیرکتوری  (ADManager Plus) نسخه ۶.۶ گزارش شده که در ادامه به توضیحاتی در این خصوص خواهم پرداخت
لازم است بدانید که ساعاتی پیش از نرم افزار ADManager این آسیب‌پذیری کشف شده و وجود کرک برای نسخه های مختلف این خانواده، این نرم‎افزار را به یکی از نرم افزارهای محبوب بسیاری از مدیران شبکه تبدیل کرده است.

شرح آسیب پذیری ManageEngine ADManager 6.6

در این آسیب‎پذیری به یک کاربر (Authenticated) این امکان را می دهد که به سطح دسترسی NT AUTHORITY\SYSTEM (تا نسخه 6.6) دسترسی پیدا کند.
در توضیحات فنی ارائه شده عنوان شده است محل نصب (پیشفرض) این نرم افزار دارای چندین دیرکتوری با تنظیمات امنیتی پایین است (دیرکتوری های Bin، Lib، Tools) که دسترسی کامل را به گروه Authenticated Users  الحاق کرده است و از آنجایی که گروه Authenticated Users به گونه ای نیست که کاربران اضافه و یا حذف شوند، هر کاربری که به سیستم لاگین کند (یوزر Domain یا Local) جزء گروه Authenticated Users خواهد بود  و قادر به تغییر محتوای داخل دیرکتوری های فوق خواهد بود. در دیرکتوری اساسی bin چندین فایل مهم وجود دارد که محققان با رصد کردن دو فایل در حین شروع فعالیت این نرم افزار به نتایج جالبی رسیدند که با توجه به ماهیت این پردازه‌ها (با هدف مدیریت اکتیودیرکتوری حتما باید با سطح دسترسی Administrator اجرا شود) دلیلی وجود ندارد که توسط تمامی کاربرانی که اعتبارسنجی موفق دارند، قابل دسترس باشد.

پیشنهاد میکنم توضیحات جالب و دقیق ادامه مطلب به زبان انگلیسی و همچنین تصاویر مربوطه را مشاهده کنید و در صورتی که از نسخه آسیب پذیر استفاده میکنید سریعا به‌روزرسانی اون رو انجام بدید و توصیه اکید میکنیم که از کرک استفاده نکنید.

شرح آسیب و روش اجرا به زبان اصلی

During a recent review of the ADManager Plus software offered by Zoho, we were able to identify a ‘chva vulnerability which would allow authenticated users to escalate to NT AUTHORITY\SYSTEM in versions up to and including 6.6 (build 6657).

The Cause of the Vulnerability

After completing the installation, the software can be found in C:\ManageEngine\ADManager Plus, assuming the default location is not changed. Within this directory are several directories with weak security settings. The affected directories are:

• bin
• lib
• tools

The issue affecting these directories is that they are created with full control assigned to the Authenticated Users group:

The Authenticated Users group in Windows is not a typical group in which users can be added or removed. If an account authenticates with the system, be it a local account or domain account, it will be deemed to be part of the Authenticated Usersgroup. The built-in accounts such as LOCAL SERVICE do not get included in this group, as they are accounts without a password that do not require authentication.

By assigning full control to Authenticated Users, any user that is logged in is capable of modifying the contents of the aforementioned directories. The bin directory is of significance, as the entry point of the software is found in this directory, along with several other core executables.

An example of two files being accessed during startup can be seen in the screenshot of procmon below:

As the nature of the software requires administrator privileges, due to it serving the purpose of managing an active directory environment, there is no reason to provide write access to all authenticated users. This misconfiguration is particularly dangerous due to the previously touched upon point – the software requires administrator level access. The ManageEngine ADManager Plus service is by default installed to launch using the local system account:

Exploitation

To exploit this vulnerability, one of the core files used by ADManager in the bin directory needs to be modified or replaced to execute a payload that will elevate one’s privileges. As previously mentioned, one must be in the context of an authenticated user, in this example, we will start as a low privilege user aptly named lowpriv:

It was previously noted that when the service starts, the wrapper.exe and admanager.exe files are both accessed. Whilst it is possible to backdoor these files, they cannot be overwritten whilst the service is running. Instead, an alternative file must be found which either:

• Is not persistently running after startup
• Can be modified whilst being executed

Running procmon again and looking at the results show several other files being accessed during startup – in particular, ChangeJRE.bat. As this is a batch script, even if this script continues to execute throughout the lifetime of the process, it can still be modified in place.

The purpose of this file appears to be to upgrade several files if newer versions are present. For example, if a file is present in lib/nativenamed ntlmauth.dll_new, the ntlmauth.dll file will be deleted and replaced with ntlmauth.dll_new. Although this mechanism can be abused, it would mean creating a DLL that is compatible with the previous one; there is much simpler way to utilise this file.

By adding an extra line to the batch file, we can make it run another executable. Rather than just launching the executable directly, it should ideally be launched using start. This will make the executable launch in a non-blocking manner and allow ChangeJRE.bat to continue executing seamlessly:

The highlighted change in the above screenshot will launch C:\ManageEngine\ADManager Plus\bin\privesc.exe alongside ChangeJRE.bat. In this case, we created privesc.exe using msfvenom:

With a payload ready and the backdoored batch file, all that is left to do is upload them and wait:

After initiating a reboot on the server, the previous session (running as lowpriv) drops, and a new session is initiated as the server comes back up; this time running as NT AUTHORITY\SYSTEM:

Looking at the task list after acquiring the SYSTEM shell also confirms that the modification made to ChangeJRE.bat is not blocking execution; meaning that ADManager Plus will continue to function as normal:

Timeline

• 2018-11-15: Vulnerability identified in build 6653
• 2019-01-31: Vendor contacted via their bug bounty program
• 2019-01-31: Acknowledgement from vendor and investigation opened
• 2019-04-15: Vulnerability confirmed to be in the latest build (6657)
• 2019-02-28: Update released to fix vulnerability
• 2019-04-15: Public disclosure