Created by ch4p
Software used: nmap, burp, netcat
As always, nmap first.
So basically ssh,http and https.
Visiting http and https gives us a boring “Just installed” page. Dirbuster gives us nothing. So lets take a look at the SSL-certs.
One e-mail found. Might become handy later.
Two new hostnames found, one which seems very interesting. So for easy access I added them to my /etc/hosts file.
A login page. Tried a couple of default user/password combination. Nothing. No software name found, so login page looks homemade. Maybe SQL-injection will do the trick?
I configured the browser to use my burp proxy intercept. Playing around with the variables and some pretty standard SQL-injection. I found that only the email variable was open for SQL-injection.
And we are in.
Looking around on the site gave me a OpenVPN Config Generator under the “Tools”-page. The generator has one input(not visible here) which ask for a IP. After submitting the IP is inserted into the displayed config-text. Playing around with it showed that the generator was using the preg_replace regex function in php. This can be bad(and good for me), since it can open up for command injection. This article describes it:
Most modifiers are quite harmless and let you do things like case-insensitive and multi-line searches, however one modifier, “e” will cause PHP to execute the result of the preg_replace() operation as PHP code. Let me just restate:
Setting the e regex modifier will cause PHP to execute the replacement value as code.
Why does PHP have this option? I have no idea, and it’s actually been deprecated in later revisions (PHP >= 5.5.0) because of its recklessly insecure nature. Many people are still using PHP 5.2 or moving onto PHP 5.3, and even when deprecated the option will still work (it’ll generate a warning at a log level turned off by default), so the issue will be around for a while yet.
So we have to insert a /e in order to exploit this. Using burp to catch the POST data and modifying the data and added a %2Fe does this(%2F is a URL-encoded forward slash). I decided to grab a php-reverse-shell and place it on the webserver in the folder /vendor which I knew existed.
The intercepted command ready for forwarding.
I also needed to provide the php-reverse-shell file from my workstation.
And I needed to ready netcat for the reverse shell before I visited https://admin-portal.europacorp.htb/vendor/re2.php. When I visited the URL the reverse-shell connected back and I got my shell as the “www-data” user.
The www-data user was enough to get the user flag. But not enough for the root flag.
Looking around for setuid files and other typical exploitable files I found that cron runs a script as root every minute.
The script is a PHP-script that clears the accesslog. Furthermore it executes /var/www/cmd/logcleared.sh which doesn’t exists.
Since cron runs the PHP-script as root the logcleared.sh will also run as root. Knowing that it was easy to see how that could be exploited. I created the logcleared.sh set it to copy the flag to /tmp and change its permissions to make it readable.
And made logcleared.sh executable.
And then there was a root flag!