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:

_method=patch&authenticity_token=ARS04mXoJP74ElbHc-g9B2VkViqX1m48TbuQL0B6NSqeVNd22UNTYbBFm3TN_cGfCH3rFwSSAr-j9S5Y7eFtnw&user%5Bemail%5D=testuser%40gmail.com&commit=Change%20email

• The response returned confirmed=false. I then modified the request by appending: &user%5Bconfirmed=truemaking the full body:

_method=patch&authenticity_token=ARS04mXoJP74ElbHc-g9B2VkViqX1m48TbuQL0B6NSqeVNd22UNTYbBFm3TN_cGfCH3rFwSSAr-j9S5Y7eFtnw&user%5Bemail%5D=testuser%40gmail.com&commit=Change%20email&user%5Bconfirmed=true

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.1This 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

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.

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.