The use of cloud-based solutions, business applications and other online services is greater than ever before. As organizations increasingly turn to SalesForce, Slack and GitHub, just to name a few, it’s critically important that they manage and protect a user’s multiple accounts to avoid unnecessary security risk.
Identity and access management (IAM) solutions can help simplify authentication, but they must be secured – just like domain controllers need to be locked down. If an IAM solution is compromised, the network will be compromised as well.
This blog provides a technical overview of IAM and the risks associated when IAM on-premises agents are not properly secured. It also explores security recommendations and mitigation to keep IAM solutions safe.
IAM Overview
People often think of an IAM solution as a single sign-on (SSO) solution, which is understandable because SSO is a main feature of IAM. The SSO functionality allows a user to login to the organization’s IAM homepage once, displaying all the applications the user has access to, as shown in the illustration below (figure 1). When the user then clicks on the desired app, they are quickly redirected to the application without needing to provide any credentials.
Figure 1 – A typical IAM’s user portal
IAM as an SSO Solution
With the rapid adoption of cloud solutions and services, IT and security teams have a record numbers of accounts to manage and monitor. Similarly, users – or employees – have many different credentials to remember. This reality forces users to either remember many different passwords or use the same set of credentials for multiple applications. Using the same set of credentials is, of course, a very bad practice that may lead to the compromise of all apps and associated data once one password is compromised.
Identity providers (IdP) eliminate the need for multiple user accounts. Identity provider services like the ones provided by Google and Facebook are trusted by applications to provide proof of identity, eliminating the need for creating new user accounts for each application.
So why isn’t Active Directory (AD,) the de-facto IdP for enterprises, enough for organizations? The reason is that cloud services and application do not necessarily have a network connection to AD. Even if they did, such setup might expose the domain.
To solve this problem, organizations use IAM solutions as an IdP. To act as an IdP, the IAM solution must either have a user database of its own or synchronize with an existing user database – an AD, for example. The simplest way is to connect the IAM to an existing users database (the AD) by installing agents in their on-premises environment.
In that case, the “kingdom” is expanding, as precious user data and passwords are shared with the IAM solution. We may say that IAM solutions act like a read-only cloud domain controller (RODC).
Some IAM solutions also can act as a read-write DC using an option called provisioning. Hence, the users created by the IAM will be created in the domain. This is done by installing on-prem agents that synchronize the AD and the cloud-based IAM solution.
SSO isn’t an IAM’s only functionality, however.
IAM as a Universal Directory
The IAM solution can also be used as a universal directory since it can integrate and manage all of the organization accounts from various directories. For organizations with multiple user directories, an IAM solution can be a real life saver as it allows the business to manage all users with one tool – the IAM admin dashboard.
IAM provides a way to update user information, create new users, change users passwords and more. We can think of an IAM as an AD on steroids. For example, multiple sources for users such as HR systems, Office 365 and AD can integrated and be managed by the IAM.
IAM as an Access Management Tool
IAM solutions are not just an extension to AD. IAM enables the “right” individuals to access the “right” resources at the “right” time and for the “right” reasons.
Hence, this is not only about authentication, but also about authorization. Administrators can configure user access to applications integrated with IAM using the admin dashboard.
IAM and Multi-Factor Authentication
IAM solutions are an extension to our kingdom. As such, security controls must be deployed to protect this extension.
One of the most efficient security controls is multi-factor authentication (MFA). Some IAM solutions have their own MFA implementations and most, if not all solutions, have integrations with different MFA solutions – like DUO, RSA SecurID and Google Authenticator.
MFA is not a bulletproof mitigation, but it certainly can eliminate many attack vectors, some of which we explore in detail later in this post.
IAM Technical Architecture
This section covers the technical details of the IAM solution architecture. If you are familiar with the technical details, feel free to skip to the weaponization section [link].
It’s important to consider two aspects. The first one is the integration between the IAM solution and AD; The second one is the implementation of SSO for domain users to the IAM user portal.
Every IAM vendor implements these integrations differently. One widely used vendor, for example, has two agents for each functionality – integration with user directory and SSO. Another popular vendor has one agent to handle both functionalities.
The integration between the IAM solution and AD is accomplished by the synchronization of AD LDAP data to the IAM cloud-based servers. To allow that, a domain user is created for the IAM solution during the installation process of the on-prem IAM agent – the IAM’s asset that is installed in the domain.
Depending on the vendor decision, the on-prem agent uses various methods to send the data to the IAM cloud-based server. These include API key or single sign-on for web services (SSWS) token. These tokens are used by the IAM cloud server to authenticate the communicating on-prem agent. The data sent to the cloud server is transferred over HTTPS. The configuration of that communication is often defined in the configuration file located in the installation folder.
Here is an example of a common on-prem agent’s API calls used to communicate with the cloud side of an IAM service:
- READ_LDAP – Read LDAP data from the AD and send it to the IAM server.
- USER_AUTH – Validate user credentials when the user tries to connect the IAM.
Deeper examination of the communication between the on-prem agent and the cloud side of the IAM service reveals the agent’s workflow for the API calls mentioned above. For example, USER_AUTH procedure works as follows:
- The user browses the IAM homepage and is redirected to a login form.
- The on-prem agent frequently queries the IAM cloud server for its next actions, using an API call that is called “next_action.” The agent’s next action, after a user provided his domain credentials into the IAM login page, is to perform “USER_AUTH” procedure. The IAM cloud server will send the on-prem agent a SWSS token (with the user’s credentials) that should be validated.
- The agent validates the user credentials against the AD and sends back an action result, which can be a success result code if the credentials are valid or failure otherwise.
Figure 2 – An example for USER_AUTH request.
Another agent workflow is the SSO workflow, allowing users passwordless access based on their network identity. As we mentioned before, some IAM solutions have another agent for this purpose, sometimes called an SSO (Integrated Windows Authentication) IWA Agent. This agent is a web application that is often installed on an on-prem IIS server and, during the installation process, a new certificate is installed on it with a private key.
A user will be redirected to the SSO agent when the desktop SSO feature is enabled. After the redirect, the user will be challenged with an NTLM or a Kerberos challenge to validate domain credentials as every domain server does. If the challenge is accomplished successfully, the agent will generate an SSO token and sign it with the private key using the newly installed on-prem IAM’s certificate. Now the user is redirected back to the IAM webpage with the access to the user portal.
Weaponization: Attack Vectors on IAM Solutions
From the last section, we know that the on-prem agents are the ones that integrate between AD and the IAM cloud-based server. As a system administrator, we know that AD should be secured according to best practices. Otherwise, the domain will be vulnerable to attacks.
The IAM vendor secures the IAM cloud-based server side and we assume it is hardened and secured. But, what do we actually know about the security of the on-prem servers where the IAM’s agents are installed? We can consider the agents as a pipeline that connects the IAM service’s cloud side and the on-prem infrastructure (as shown in figure 3). From an attacker perspective, it might be the weakest link in a possible attack scenario.
Figure 3 – An illustration for the IAM’s agents and the sensitive data flow.
One of the main purposes of an attacker is to escalate privileges in order to gain a better foothold in the domain. They can do this by targeting shadow admins, which are standard domain users with special privileged permissions. For example, a user with a reset password permission over a domain admin, could reset the password of the domain admin and compromise it.
In fact, in one of our specific examinations of the IAM solution installation process, we revealed a shadow admin user created with reset password permission. This user seems to be a standard user in the domain users group used to read AD LDAP data only, as the provisioning options not yet enabled (to check for shadow admins we used the ACLight tool, developed by CyberArk Labs.)
Now it is time to focus on the attack vectors an attacker could execute by leveraging the agents we mentioned earlier. As we already know, the on-prem agents are the ones to receive user credentials and handle user authentication when a user provides his credentials via the IAM’s login form. Looking into these agents and the authentication process, we identified two attack vectors: dumping the passwords of users connecting to the IAM portal and creating a skeleton key, which is an injection of a hidden master password.
After an IAM solution is infected with a skeleton key, the attacker can impersonate every user in the organization, and achieve his malicious goal. To execute these vectors, an attacker has two options: to patch the agent’s binaries (one of the IAM’s EXEs or DLLs) or pretend to be the connector service, using the API key or token to authorize against IAM server. Both of these attack vectors require local user privileges on the on-prem servers where the IAM’s agents are installed.
IAM Weaknesses
As part of our research, we discovered that one IAM vendor didn’t obfuscate its code and didn’t validate DLL’s signatures before loading them. Therefore, patching the IAM solution’s on-prem binaries was a simple task. With this attacking technique, attackers could patch the binaries to allow them to use a hardcoded password for all domain users, skip the credentials validation process against the AD and login to the IAM homepage. It is also worth mentioning that they might be blocked by an MFA that is configured, which will prevent the attackers from logging-in to the IAM portal. The attackers could also patch the binaries, allowing the extraction of credentials processed by the agent for validation. This could eventually allow the attacker to access the credentials of all the users that log into the IAM solution, including privileged credentials. The same attack vectors could also be executed outside the domain environment, by having the API key or token of the agent used to send or receive data to and from the IAM server.
In another IAM vendor, we found that a directory token, which is a UID for the agent, is stored in the registry and in a log file in plain text. Using that directory token, attackers could extract the API key for the IAM server using a simple HTTP GET request (see figure 4).
A different IAM vendor stores tokens in a configuration file, encrypted with DPAPI, which can be decrypted by any user with non-privileged access to the agent on-prem server.
Figure 4 – HTTP GET request with directory token
To carry out an attack on the SSO agent, an attacker will need to get the signing key for the SSO token generated by it. In the case of a specific IAM vendor’s SSO agent, an attacker will need to gain access to the IIS on-prem server on which the on-prem agent is installed and extract the certificate with its private key. If an attacker manages to do so, the attacker could login with every domain user to the IAM’s portal and thus to all integrated business applications. That said, multi-factor authentication would be another boundary for the attacker, protecting against unauthorized access.
Mitigation
Beside the known recommendation of enabling MFA, here are the crucial mitigation steps that can prevent the compromise of the IAM solution.
- Protect the on-prem servers where the IAM’s agents are installed. This is the most important mitigation measure. If the attacker cannot get access to the IAM’s on-prem servers, he cannot proceed with the attacks researched above. The IAM servers should be secured with privileged access security mechanisms. For instance,
- Remove admin rights for users that log on to the on-prem IAM servers. Users with admin rights can perform the attack vectors mentioned above. The fewer the users with admin rights, the smaller the attack surface.
- Implement application control to prevent the running of non-legitimate software on IAM on-prem servers. Application control will protect binaries and their configuration files from being changed.
- Protect credentials/certificate stores on the servers. Secure the certificate used to sign the IAM’s SSO token.
- Manage, secure and control administrative access to the IAM on-prem agents:
- Manage accounts with privileged access to the IAM agents’ servers.
- Isolate/control/monitor access to the IAM agents’ servers.
Conclusion
IAM solutions allows organizations to ease the burden on IT teams by centralizing access management to application and services and on users who want to only have to remember one password to access applications and services. They’re important tools that deliver plentiful benefits.
Because IAM solutions integrate with the core of the organization and handle very sensitive data, they must be considered as tier 0 assets – just like our known DCs – and should be secured and protected as such.
