> For the complete documentation index, see [llms.txt](https://kayra.gitbook.io/hackerkayra/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kayra.gitbook.io/hackerkayra/write-ups/proving-grounds-boxes/linux/boolean.md). # 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.

* I created a new user and attempted to log in, but received an account confirmation message:

* 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."

## **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 %}

* 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,

* 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.

* I then uploaded a new key as **authorized\_keys** into the .ssh directory and logged in as remi, that worked!

## 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.

{% 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.