Author: Pedro Henrique Lima
In this post, a technical sequence of exploiting an error-based SQL injection in a web application will be detailed, which resulted in the total compromise of a domain in the Active Directory (AD) of a healthcare organization during a red team exercise assessment.
Context
Before discussing the exploitation, it is crucial to understand the context of the vulnerable web application, its functionality, and the need for the platform to be exposed to the internet.
Generally, the application was responsible for organizing and storing various workflows related to user access and management in the organization’s infrastructure.
Theoretically, only one workflow should be available online for company employees, allowing users to perform the password recovery/change process.
When accessing the application, users are redirected to the password reset workflow, where there was an input for the Active Directory domain-based username.
Due to the business logic of the application, it appears not to require prior authentication. However, behind the scenes, the application automatically authenticates with an anonymous user who only has permission for the password reset workflow, which can be noticed in the browser’s cookie storage:
Because this page is exposed to the internet and interacts with the client’s AD, a more in-depth analysis was justified.
During a thorough analysis of the scripts loaded by the application, an endpoint with a parameter performing a query was found:
Exploiting an error-based SQL Injection
The endpoint in question was vulnerable to Error-Based SQL Injection, as shown below:
Briefly, an error-based SQL Injection is a technique where application flaws are exploited to execute arbitrary SQL commands, obtaining sensitive information through error messages returned by the database.
After the initial analysis of the tables and databases on the server, a table named “User” was found. As the name suggests, this table stored user information, including an access key, encrypted passwords, email, name, phone number, etc:
In a typical scenario, applications usually have an authentication flow using a login and password. However, upon reading the application documentation, it was stated that if the environment uses SSO authentication, an Access Key is required to access the data:
Due to user access limitations, logging in through the application’s UI was not possible, as regardless of the URL accessed on the platform, users are immediately redirected to the password reset workflow.
Referring to the information in this public documentation, an endpoint responsible for login was identified, which returned a session cookie for the application requiring a username and password.
No information is given regarding using the access key as a password, but it doesn’t hurt to try, right?
The login attempt is successful, and the session cookie is returned, as the documentation mentions.
To access the application’s interface with the respective user, manual cookie modification is required:
After changing the cookie value, it is necessary to access another page that does not force the anonymous user’s pre-login. For this, it was found in the application documentation an endpoint for workflow configuration/management:
Consequently, with the new session cookie (containing privileged access), any workflow present in the application can be accessed:
Later, it was identified that the same environment is mirrored for internal access only, blocking any external access:
Creating a Workflow
The workflow pipeline that adds a new user to the AD has several steps requiring third-party approval. To ensure practicality and, primarily, prevent detection due to malicious movement, after analyzing and studying the scripts through the workflow manager, a workflow was created for adding users to the AD without needing third-party approval:
During the user inclusion process created by Blaze Information Security, a fictitious test user named Rayssa Real was registered:
Following the registration flow, the following log was generated, indicating that the user was created successfully:
Due to the integration of the web application with Active Directory, it was not surprising to find an endpoint that allowed the execution of PowerShell commands from the AD module. Therefore, it was possible to verify the existence of the newly created user:
This endpoint was limited to only a few commands, allowing only the viewing of information about the domain and its users without directly editing any information.
Initially, it is expected that the user changes the password upon first login. The standard password change flow was considered, but as shown below, MFA through a phone and manager approval are required:
Again, in order to avoid drawing the blue team’s attention, a password change process workflow was created without steps requiring third-party dependencies and MFA:
Accessing this flow, it was possible to change the user’s password without needing a phone, bypassing the MFA requirement:
The password was then changed, and now we have the credentials to access the AD. With this access, we also gained the ability to connect to the organization’s VPN and, consequently, its internal network. During the user creation process, one of the explicit steps automatically included the new user in the VPN access group.
With a new Windows virtual machine and possessing the VPN client used by the institution, it was possible to log in with the newly created AD account. As seen below, we are already on the internal network:
An indication of internal network access is that now the internal workflow page can be accessed, which was not accessible via the external network:
Obtaining Domain Admin
After a quick enumeration, the main domain controller was also identified:
Upon reflecting on the level of authorization we have on the workflow platform, the possibility of creating users and changing their passwords opens the possibility of managing user groups in the AD.
As shown below, there is a workflow named “Manage group members (user)”:
The workflow form had some HTML fields with style set to “display: none”, making these fields invisible in the interface. One of these fields was crucial as it should contain the DN (Distinguished Name) of the group to which we wanted to add the user.
The Distinguished Name (DN) is responsible for being a unique identifier in the AD, describing the object’s location in the directory structure.
After removing the div attribute, a new input field appeared in the form:
In the DN field, four extra characters were added at the end of the string. This was necessary because the application was not parsing correctly, resulting in a string position error. To circumvent this problem, these four characters with no significant value were inserted:
After sending the request to add the user to the Domain Admins group, the integrated PowerShell endpoint with the Active Directory (AD) module was used to confirm that our user now belongs to the Domain Admin group:
It was also possible to check the users belonging to the Domain Admins group through the virtual machine’s PowerShell:
With the Domain Controller in hand, logging in to the workstation via RDP using the user Rayssa’s credentials (DRTxxxxx) was possible:
Below, it is possible to see the list of domain-joined assets that could be remotely accessed, including surgical center stations, cameras, user machines, and other connected medical devices:
Additionally, images of hospital beds and patient records were accessed:
