PC is an Easy HackTheBox machine.
- Foothold: SQL injection in gRPC endpoint
- Root: pyLoad CVE on loopback interface
Port Scan
I started with an nmap scan after adding pc.htb to /etc/hosts:
There seems to only be two services running, one is OpenSSH, and nmap couldn’t identify the second one on 50051.
gRPC
A quick Google search revealed that 50051 might be the default port for gRPC, and a brief discussion with Bing Chat led me to grpcurl, which is a cURL-like tool for gRPC.
The server doesn’t use SSL, so I’ve added -plaintext. There seems to only be one user-defined service running called SimpleApp.
Let’s see if we could login with some default credentials, like admin:admin:
That seems to have worked, but we only get back an ID. Let’s see if we could call getInfo to retrieve more info about admin.
Although it’s not specified in the protobuf format, getInfo also requires a token header, but we’ve never gotten a token from anywhere. This step frustrated me quite a bit. After looking at the vague hints on the HTB forum, I was directed to the help message of grpcurl, and I thought maybe adding -v (verbose) could be helpful.
And indeed it was helpful. Who knew that there are response trailers that are never displayed by default? Guess I should’ve tried more options before looking for hints. With this token we can now login…
… or not. Maybe someone else requested a token a little later than me, which invalidated mine? From the error message, we also learned that the backend is running on Python (“TypeError”, “NoneType”, etc), and likely also a database. The programmer did a bad job of error handling, since he/she didn’t consider the case of a SQL query returning 0 record. Let’s try regenerating a token.
Well, this time it worked, but we don’t really get any information, even if we supposedly logged in using the admin credentials. At this point I was thinking if we could somehow extract more information out of the database.
Foothold via SQLi
I fiddled around a bit more and discovered that the id parameter is indeed vulnerable to SQL injection using a sleep payload for SQLite, which I found on HackTricks. The getInfo request with the SQL code takes a few seconds longer to complete, which is a clear sign of vulnerability.
Oops
I noticed that at the time I took the screenshot, the VPN was probably down. The sleep payload definitely works though. Pretend this didn’t happen since I don’t want to go back and do it again…
Knowing that the id parameter is injectable, the only problem now is how to dump the database. The gRPC service doesn’t display any data, which limits us to time-based blind attacks. Sqlmap usually only works with HTTP requests, so we have to somehow make gRPC work over HTTP. I don’t think this particular service is configured to support HTTP, rather it just talks in Protobuf. After doing some research online, I was inspired to use an HTTP web frontend for grpcurl called grpcui, which means I could transform gRPC traffic to an HTTP request. Alternatively, I could script a basic web server that accepts some query parameter, and pass that directly to the grpcurl command, which also would’ve worked with sqlmap, but I didn’t feel like reinventing the wheel.
Following the same syntax as grpcui:
Let’s the get parameters filled out on the gRPC web UI, and enable the browser proxy (I’m using FoxyProxy) plus Burp’s Proxy intercept switch:
We now get this in the Proxy page, which we can copy and save to request.txt for use with sqlmap:
Launching sqlmap…
…and we find some user credentials:
Root via pyLoad CVE
After logging into SSH with the credentials, I’m greeted with some files other players left in the home directory, which I just borrowed. I ran the linpeas.sh that was conveniently lying around. There’s no obvious privesc attack vector, but there does seem to be another web service running on the loopback interface:
We could use SSH local port forwarding to get a look at the service:
The home page (now available on my VM at localhost:8000) looks like this:
An obvious first thing to do is look for public exploits, so I looked up pyLoad on exploit-db:
After running searchsploit -m 51532 and fixing the shebang line:
The chmod didn’t seem to work:
I decided to just run the exploit manually, which gave me root:
Overall, I think the difficult part of the machine is familiarizing myself with the gRPC service, and learning to adapt an old tool (sqlmap) to a new environment. The privesc part isn’t too difficult compared to the foothold.