Part 1: User Impersonation
Background
Adaptive Adaptive Authentication is a powerful feature of the WSO2 Identity Server that enables the execution of TypeScript code during authentication. Its main purpose is to provide a convenient means of customizing and extending the authentication process and functionality without the need to develop and deploy Java artifacts. Authentication is a powerful feature of the WSO2 Identity Server that allows us to run TypeScript code during authentication. The intended purpose is to provide an easy way to customize and extend the authentication process and functionality without developing and deploying Java artifacts.
The scripts are defined at the service provider level and can leverage Function Libraries, which are chunks of reusable code. NOTE: All code was tested on Ellucian Ethos Identity 5.10.8, which is built on WSO2 Identity Server 5.10.
User Impersonation Script
In the WSO2 Identity Server, the authentication process is split into two operations:
- Identity proofing – the user provides information to validate and authenticate their identity
- ex: username and password
- Claim Resolution
- Ex: roles, department, etc.
After the user has successfully authenticated, the user object is populated.
Through JavaScript API calls, we can read and write the user object.
Changing the username on the user object is trivial after the authentication step succeeds.
The new username ‘jdoe’ is then used to resolve claims (attributes) for the session, and the user is sent along to the service provider with a session and claims for the ‘jdoe’ account.
The service provider receives no indication that anything abnormal has happened during the authentication process.
This is a simple policy, and it would swap the username for every login, which would be very noticeable and undesirable.
A more discreet solution would be to trigger the account change only when a specific account logs in:
Parse the username from step 1, check the value, and then change the account.
The script reloads dynamically so the username can be swapped systematically to switch between different accounts.
Taking it to another level, we can leverage the ‘getCookieValue’ function to retrieve the desired username from a ‘magic’ cookie:
Preventative Measures
- Limit access to the Carbon Console
- Leverage built-in IP filters
- Defense-in-depth: leverage any additional layers of filtering available (WAF)
- Maintain secure credentials for the Carbon Console
- Use the REST or SOAP Service Provider APIs to routinely export Service Provider configurations and check for changes or malicious adaptive authentication code.
- Use advanced log analysis to identify username changes within a session by correlating the claims and session ID data.
Summary
Adaptive authentication is an extremely powerful feature that can be abused by a rouge administrator or a malicious actor to impersonate users and access accounts.
This type of attack would be extremely difficult to detect since it won’t generate errors on the IdP or SP and is not obvious in the Carbon Console user interface when a policy has been defined.
Stay tuned for Part 2 – Abusing Adaptive Authentication: Enumeration and Data Exfiltration.
