HackTheBox – BountyHunter

Welcome to another post with the write-up of the HackTheBox machine “BugHunter”. This machine was interesting because the initial access requires te exploitation of a common web vulnerability and the privilege escalation phase involved the analysis of a vulnerable python code.

Initial enumeration

As usual, we started with the enumeration of the available services using Nmap:

There are more nmap commands we would execute, although with this simple execution we obtain all the information we need to proceed with the enumeration.

We access the HTTP server in port 80 and the following content is displayed:

After enumerate a little bit the web, we find the link “Portal” that has a hyperlink to “/log_submit.php”.

Accessing the admin panel

We intercept the request in “log_submit.php” with a intermediate proxy and we see a base64 encoded data that correspond to this XML format.

<?xml version="1.0" encoding="ISO-8859-1"?>

A simple test revealed that there is a lack of validation in the backend that led us to exploit a XXE vulnerability.

<?xml version="1.0" encoding="ISO-8859-1"?>
   <!DOCTYPE foo [<!ENTITY example SYSTEM "/etc/passwd"> ]>

The previous request forces the server to include the content of the /etc/passwd file in the response. The XXE vulnerability is aiming the server XML parser which, badly configured, allows the attacker to include external entities and, therefore, read internal files from the server.

With the capability to read local files, the next step is to find juicy data that may be utilized to break into the server. After read the identified files until now, nothing interesting was found.

Finally, we launched a gobuster with the .php extension. The reason is the fact that, a web server using PHP normally will store the credentials to connect to different services (Databases, external APIs, etc…) inside PHP config files.

The ‘db.php’ file is found and, after read the contents we found some credentials:

Since the ‘/etc/passwd’ file was read, we know which users exist in the server. Trying the credentials, finally we access through SSH with the user ‘developer’.

Privilege escalation

The first we do when we get access to the server is to check for some well known miss configurations / insecure permissions that usually can be abused to escalate the privileges to ‘root’.

In this case, the actual configuration allows the user ‘development’ to execute a python script with SUDO, this means this execution is elevated and it is performed with ‘root’ permissions.

The contents of the affected script is below, after analyzing it we see a clear “entry point” to code execute (which will be of course with ‘root’ privileges due to the SUID), that’s the ‘eval’ in the line 45.

At this point it’s quite clear which is the path to the privilege escalation. If we can execute the python native command ‘eval’ with arbitrary arguments, we could surely execute commands as ‘root’. In this link is all explained.

Okay, so let’s see what we have to do to arrive to this ‘eval’ and execute code. The ‘stacktrace’ would have the following appearance:

call function 'main'
call function 'evalute'
    iterate in the lines of 'ticketFile'
    if  line 0 startswith '# Skytrain Inc'   and
        line 1 startswith '## Ticket to '    and
        line 2 startswith '__Ticket Code:__' and 
        line 3 startswith '**11'             
    evaluate the x.replace('**','') as python code

If we put all these conditions in a file, the result is something like this one:

# Skytrain Inc
## Ticket to 
__Ticket Code:__
**11+1 == __import__('os').system('/bin/bash')

Creating this file and indicating it in the prompt when we execute the python script, a new ‘bash’ with elevated privileges is created and we get maximum permissions.

Posted on