# Boolean
**Source**: Proving Grounds\
**OS**: Linux\
**Community Rating**: Very Hard
## **Enumeration & Reconnaissance**
* I started with autorecon and found these open ports:
* **SSH (22)**
* **HTTP (80)**
* HTTP (33017)
## **Service Analysis**
* I began with HTTP (80). The page presented both a login and registration function. After trying SQL injection, default credentials, and random passwords with no luck on the login, I moved to registration.
Boolean Login
* I created a new user and attempted to log in, but received an account confirmation message:
Account Confirmation
* There was an edit button on the confirmation page that might be a useful path. I checked HTTP (33017), but it simply displayed: "This port is reserved for potential future development should we decide to change our tech stack."
HTTP (33017)
## **Gaining Initial Access**
* I went back to the edit function on the account confirmation page. Using Burp Suite, I examined the request body which contained:
{% code overflow="wrap" fullWidth="true" %}
```http
_method=patch&authenticity_token=ARS04mXoJP74ElbHc-g9B2VkViqX1m48TbuQL0B6NSqeVNd22UNTYbBFm3TN_cGfCH3rFwSSAr-j9S5Y7eFtnw&user%5Bemail%5D=testuser%40gmail.com&commit=Change%20email
```
{% endcode %}
* The response returned `confirmed=false`. I then modified the request by appending: `&user%5Bconfirmed=true`making the full body:
{% code overflow="wrap" fullWidth="true" %}
```
_method=patch&authenticity_token=ARS04mXoJP74ElbHc-g9B2VkViqX1m48TbuQL0B6NSqeVNd22UNTYbBFm3TN_cGfCH3rFwSSAr-j9S5Y7eFtnw&user%5Bemail%5D=testuser%40gmail.com&commit=Change%20email&user%5Bconfirmed=true
```
{% endcode %}
Account Confirmation Bypass
* That worked, I gained access to the web system. Inside, I discovered a file manager, which suggested potential for LFI/RFI exploitation.
* I uploaded a file and observed the URL included: "`http://192.168.192.231/?cwd=&file=image.jpg&download=true`" Assuming `cwd` stands for current working directory, I attempted LFI by visiting: `http://192.168.192.231/?cwd=../../../../../../../../`
* This led me to the root directory. Then, I checked the passwd file but found nothing useful, so I then looked for an .ssh directory. Since **SSH (22)** was open,
Passwd File
* I discovered an .ssh directory under user **remi**’s home. Inside, I found multiple keys, including one for root. I downloaded them and attempted to access the system, but was prompted for the root password. Trying the other keys yielded the same result.
SSH Keys
* I then uploaded a new key as **authorized\_keys** into the .ssh directory and logged in as remi, that worked!
SSH Access
## Privilege Escalation
* Once in, I tried to use the root key from inside by running: `ssh -i root root@127.0.0.1`This attempt failed with:`Received disconnect from 127.0.0.1 port 22:2: Too many authentication failures. Disconnected from 127.0.0.1 port 22`
* I then retried with: `ssh -o IdentityAgent=none -i root root@127.0.0.1`
* This time, it worked, I was in as root.
Root Access
{% hint style="info" %}
The error occurred because the SSH client was offering too many keys (from both the specified key and the SSH agent), exceeding the server's allowed attempts. Using the `-o IdentityAgent=none` option forced the client to use only the specified key.
{% endhint %}
## **Lessons Learned**
* Account confirmation mechanisms can sometimes be bypassed by manipulating request parameters.
* A hidden file manager may expose LFI vulnerabilities; using them to navigate to sensitive directories (like .ssh) is crucial.
* When pre-existing SSH keys don’t grant access, uploading a new authorized key can be an effective workaround.
* Understanding SSH client behavior, such as the impact of multiple keys, can save time; using `-o IdentityAgent=none` ensures only the intended key is used.
