Tomer Tropper
ADSelfService Plus Playground | Abusing Functionalities
What is ADSelfService Plus?
ADSelfService Plus software is a self-service password management and single sign-on solution for Active Directory environments and cloud applications, provided by the ManageEngine company.
The primary solutions proposed by ADSelfService Plus focus on two perspectives:
IT department:
- Enforce a strong password policy for the active directory environment and its associated services.
- Implement an advanced layer of authentication methods, e.g., YubiKey authentication and 2FA for active directory endpoint connections and associated services.
- Avoid getting involved with end-user profile problems such as modifying their passwords and personal details.
End users:
- Easily unlock their active directory accounts and reset their password without any interaction with the IT department
- Manage their domain account’s personal information
How ADSelfService meets us in our daily activities?
As part of an external assessment, we look for low-hanging fruits that could help us achieve initial access in the organization’s network and start our lateral movement in the organization’s domain environment. Thus, we began by scanning the public-facing assets associated with the organization. Moving through the scanning results, we found the ADSelfService portal login page.
Optimistically, we decided to try multiple variations of known default credentials.
On the first try, we used the “admin:admin” user name and password aaaaaaaaaaaaaaand initial access to the portal as the system’s administrative account was established. Easy!😊.
From this point on, we had complete control over the organization’s Active Directory. We could enable users, assign them to high privileged domain groups such as the “Domain Admins” group, change existing users’ passwords, and act as the organization’s system administrator. However, these actions could have raised alerts and revealed our newly obtained administrative connection.
Thus, we decided to do offline research about the system and search for the available attack vectors based on the application’s functionalities that we could silently abuse. We discovered an option to notify the end-users about performing the following actions in the application portal:
- A self-service password reset
- A self-service account unlock
- Change password
- Enroll with ADSelfService Plus
- Self-directory updates
Each notification’s template can be crafted using the built-in ADSelfService “Macros.”
For example, this is the default notification provided by ADSelfService when resetting a password:
However, we think that sending the user’s password in clear text format in the notification is not appropriate as system administrators may have access to the user’s mailbox, or this message may be logged in many places during the sending process, etc.
In addition to the above functionality, system administrators may be notified of user activities in the application by enabling the “Notify Admin/Manager” feature. Amazing!
Will it allow sending clear text passwords to administrators as well? Interesting…
Notify Admin/Manager
So, at first, we enabled this feature and tried to send the same reset password notification as sent to the end-users. However, we received the following error message when saving the template:
“Mail content should not contain %password% macro.” Unlucky ☹
Is there any other field that allows clear text passwords to be sent? Maybe the notification’s subject??
So then, in a second attempt, we used the %password% macro again, but this time we used it in the notification’s subject. This time the template was saved successfully!!
OK, what’s next? Will the system administrator receive the clear text password when a successful reset password attempt occurs?
Then, we have reset our user’s password, and the email notification has arrived with the user’s password in a clear text format in the notification’s subject!!!!
We quickly entered the organization’s ADSelfService portal using the application’s local “Admin” user credentials. Next, we added our email address to the “Notify Admin” mailing list and modified the notification message’s template using the %password% macro in its subject.
From this point, all we had to do was wait for the organization’s credentials to arrive in our mailbox.
We captured multiple user passwords during the assessment and used them to authenticate to their VPN client. These actions provided us with our initial access and lateral movement actions in the organization’s domain network. By the time the assessment ended, we had successfully captured 20 percent of the organization’s passwords.
To perform password retrieval, take the following steps:
- Authenticate as the admin account
- Navigate to the “Configuration” tab ->“Security Center” ->“Anti-Hacking System” ->“Email Notification Upon Password Self-Service”
Then in the open window, access the “Notify Admin/Manager” tab and enter your email address into the “Email ID” parameter. Then, modify the mail subject and add the “%sAMAccountName% macro to obtain the domain account name and the %password% macro to obtain its password in clear text format, and save the form. These macros are defined as part of the ADSelfService Plus system.
Again, it’s important to mention that the %password% macro must be specified in the email subject.
From this point onward, every successful account password reset attempt will be sent to your mail address with the account’s newly changed password in clear text format.
Remote code execution by design?
Digging further into the application’s functionalities, we encountered the Password Sync feature.
This feature allows the execution of a defined script upon user’s password reset, and users successful unlock attempts.
Sound interesting, right?
An attacker may abuse this functionality to execute their scripts on the ADSelfService hosted server. The scripts will be executed when a successful password reset or account unlock attempt occurs. As a result, the attacker creates a persistence point on a high privileged server in the organization’s domain environment.
How to prevent such scenarios from occurring
- Make sure to separate the application’s administrative login page from the end-user’s page
- Permit access to this panel from a specific machine in a restricted VLAN only
- Change the default password of the local “admin” account after the installation has been completed to a complex password that cannot be easily brute forced.
For any questions or clerification feel free to contact Cilynx Cyber Team at our contact us page.
