Extplorer
Last updated
Last updated
Source: Proving Grounds OS: Linux Community Rating: Intermediate
I started with autorecon as usual, which revealed two open ports on the target:
SSH (22)
HTTP (80)
When I opened the HTTP service, I was greeted with a WordPress configuration page. I tried to go through the setup process but couldn’t get past the database credentials (I just realized that the machine doesn’t have internet access, so my connection string pointed to an online database I’d set up using free tools was useless)
The automated fuzzer that ran with autorecon didn’t show anything interesting either. It wasn’t until I ran dirb on the target that I found something noteworthy: a directory named filemanager.
Upon visiting the filemanager, I was met with a login page. I tried the default credentials, and admin:admin worked like a charm.
Once inside, I discovered I could upload files without restriction. Since WordPress was installed on the machine, I leveraged this by uploading a shell and accessing it via (wp-content):
After uploading the shell, I had a working foothold on the target. I ran linpeas.sh to check for privilege escalation methods, but nothing immediately stood out.
I was nearly ready to give up when I noticed another user, dora. While browsing the filemanager, I found a hash associated with dora. I cracked the hash using John the Ripper and quickly obtained the password: doraemon.
I attempted to SSH into the target using the user dora, but SSH only accepted public key authentication. Fortunately, since I already had a shell from the file upload, I simply switched to the dora user within my session.
Running linpeas.sh again revealed that I was a member of the disk group. After some online digging, I learned that membership in this group can allow access to files that are normally off-limits.
To start, I started by checking the disk space summary in human-readable format with:
This helped me identify the partition where the root (/) directory is mounted (in this case, /dev/mapper/ubuntu--vg-ubuntu--lv). I then launched debugfs on that partition:
Using this privilege, I was able to read sensitive information, including the flag, without having to escalate to root directly which I did but then I still wanted to actually escalate.
An article I found online mentioned that this method might allow you to read the root's SSH private keys and use them to login. In our case, root didn’t have any SSH keys, and attempts to copy keys to the root’s .ssh folder (using cp or mv) were unsuccessful.
Not ready to give up, I looked for another way and since I can read any file, I could read the root's shadow file and then crack the root password. This method worked, and I eventually obtained the root password: explorer.
File Upload Exploitation: A vulnerable file manager that allowed unrestricted file uploads provided the initial foothold.
User Enumeration: Discovering another user (dora) can open alternative paths when I couldn't find in the initial user.
Group Privileges: Being part of the disk group enabled access to sensitive files, which was then used to privilege escalate.
Multiple Privilege Escalation Methods: If one method (like trying to use debugfs to access SSH keys) fails, it’s important to explore alternative approaches such as reading and cracking the shadow file.
