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"?>
<bugreport>
<title>abc</title>
<cwe>abc</cwe>
<cvss>abc</cvss>
<reward>abc</reward>
</bugreport>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"> ]>
<bugreport>
<title>&example;</title>
<cwe>abc</cwe>
<cvss>abc</cvss>
<reward>abc</reward>
</bugreport>
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 codeIf 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.
