Loly

Last updated 2 months ago

Source: Proving Grounds OS: Linux Community Rating: Hard

Enumeration & Reconnaissance

I started off with autorecon on Loly, which revealed that HTTP (port 80) was the only service up.

With just one open port and it being HTTP, I ran fuzzers in the background while manually checking the site.

The robots.txt yielded nothing, and the default nginx page was all I saw at first. I was at a loss for a while untill the fuzzer uncovered a the directory: /wordpress/.
After discovering the /wordpress/ path, I started exploring the site.
I needed to add the hostname loly.lc to my /etc/hosts as well.
I started running wpscan against the target and I found the WordPress user loly.
I launched a brute force attack using wpscan, and while it was running, I also searched for vulnerable plugins but that was blocked way.

The bruteforce attack eventually revealed the password for the user loly to be fernando.

With the credentials in hand, I logged into the WordPress admin panel. I then began looking for ways to escalate my foothold, specifically any editable PHP files or file upload functionalities that might let me drop a shell.
I noticed the adrotate plugin which had a file upload function, it imposed restrictions (accepting only jpg, jpeg, gif, png, svg, html, js, and zip files, with a 512Kb size limit). However, it automatically extracted zip files and removed the original archive. This rendered the file extension validation basically useless.

I created a custom payload, zipped it, and uploaded it through adrotate. Once the zip was extracted, I could access my shell via: http://loly.lc/wordpress/wp-content/banners/shell.php
I upgraded the shell to an interactive one using Python and then started exploring.

Once I had a shell, I ran linpeas.sh to check for privilege escalation vectors. The tool revealed that the kernel version (kernel-4.4.0-31-generic) was vulnerable.
I started trying out several known CVEs, but I couldn't compile any of my payloads, I kept getting the error: gcc: error trying to exec 'cc1': execvp: No such file or directory
It turned out I had to switch to the OS user loly. The WordPress password (fernando) differed from the operating system’s password. However, the correct OS password matched the database password that's stored in the wp-config file. lolyisabeautifulgirl.
I then switched the users and kept experimenting with multiple payloads until the exploit from 45010.c on searchsploit worked, giving me root access.

Exploiting File Upload Vulnerabilities: The file extension validation was rendered useless because the zip extraction bypasses the placed restrictions.
Credential Management: Always check config files and make sure to try found credentials on different services, there will most likely be reuse on different services.
Kernel Vulnerabilities: The outdated kernel version was a gateway for privilege escalation.

Last updated 2 months ago

Source: Proving Grounds OS: Linux Community Rating: Hard

I started off with autorecon on Loly, which revealed that HTTP (port 80) was the only service up.

With just one open port and it being HTTP, I ran fuzzers in the background while manually checking the site.

The robots.txt yielded nothing, and the default nginx page was all I saw at first. I was at a loss for a while untill the fuzzer uncovered a the directory: /wordpress/.
After discovering the /wordpress/ path, I started exploring the site.
I needed to add the hostname loly.lc to my /etc/hosts as well.
I started running wpscan against the target and I found the WordPress user loly.
I launched a brute force attack using wpscan, and while it was running, I also searched for vulnerable plugins but that was blocked way.

The bruteforce attack eventually revealed the password for the user loly to be fernando.

With the credentials in hand, I logged into the WordPress admin panel. I then began looking for ways to escalate my foothold, specifically any editable PHP files or file upload functionalities that might let me drop a shell.
I noticed the adrotate plugin which had a file upload function, it imposed restrictions (accepting only jpg, jpeg, gif, png, svg, html, js, and zip files, with a 512Kb size limit). However, it automatically extracted zip files and removed the original archive. This rendered the file extension validation basically useless.

I created a custom payload, zipped it, and uploaded it through adrotate. Once the zip was extracted, I could access my shell via: http://loly.lc/wordpress/wp-content/banners/shell.php
I upgraded the shell to an interactive one using Python and then started exploring.

Once I had a shell, I ran linpeas.sh to check for privilege escalation vectors. The tool revealed that the kernel version (kernel-4.4.0-31-generic) was vulnerable.
I started trying out several known CVEs, but I couldn't compile any of my payloads, I kept getting the error: gcc: error trying to exec 'cc1': execvp: No such file or directory
It turned out I had to switch to the OS user loly. The WordPress password (fernando) differed from the operating system’s password. However, the correct OS password matched the database password that's stored in the wp-config file. lolyisabeautifulgirl.
I then switched the users and kept experimenting with multiple payloads until the exploit from 45010.c on searchsploit worked, giving me root access.

Exploiting File Upload Vulnerabilities: The file extension validation was rendered useless because the zip extraction bypasses the placed restrictions.
Credential Management: Always check config files and make sure to try found credentials on different services, there will most likely be reuse on different services.
Kernel Vulnerabilities: The outdated kernel version was a gateway for privilege escalation.