It is a machine now “retired”, from which I got the user and system flags some months ago (October 2021) when it was still active.
Initial disclaimer: do not consider these steps as 100% correct or the best one available. Pretty sure that it would have been possible to get the solution faster and with a different approach. That said, I think it’s important to see the tentatives and logic applied, besides the tools used. This is important when looking back at possible errors and ways to improve, especially when starting.
Let’s do the initial recon with a machine scan via Nmap, in order to see which ports / services are exposed:
nmap -T4 -p- -A 10.10.11.100
Some additional scans using different tools:
ffuf, nothing particularly interesting
nikto, a possible interesting reference to further look into
OSVDB-3093: /db.php: This might be interesting... has been seen in web logs from an unknown scanner.
dirbuster, also here among the different resources we found the “db.php” file
dirb, nothing particularly interesting
Let’s continue trying to browse the website in order to understand what the published web application consists of.
- address http://10.10.11.100/
- using Burp (+ plugin FoxyProxy) to record traffic and find possible clues
- the contact form appears to be “fake” considering the inserted data are not sent.
Following the link to the portal http://10.10.11.100/portal.php we get access to the “real” web application. A ticketing system to submit bugs.
Trying to insert some test data it appears that the classic database operations are performed (or simulated).
Files found via Burp or using the network tab in Firefox:
bountylog.js apparently containing the code used to send data via an Ajax request (XMLHttpRequest)
tracker_diRbPr00f314.php causing the possible form data manipulation and results returned
Moving from the original content (not encoded) of the data field, we might want to try an attack XXE (XML External Entity) as possible entry point.
The idea is to do some tests with snippets that try to read local files, like the classic /etc/passwd.
From here, we can try to read the previously mentioned db.php file that we discovered at the beginning. It is very likely that it contains interesting information, such as login credentials. But since we are trying to read a .php file, we have to use a slightly different strategy by adopting a little trick as described here.
Remembering that the machine also exposes an SSH service, we can try to connect using development as a user account, that is the most “sensible” one retrieved from the passwd file. In view of the “classic” problem of password reuse, we will try to connect using the password we just found.
Continuing quickly with the analysis of the home folder and in addition to the contents of the contract.txt file, let’s try to discover if the user development is in the list of sudoers. We also try to understand what commands it can possibly execute without the need for authentication.
Looking for further possible entry points to attempt a privilege escalation we use a tool called LinPEAS. This script searches the system for various ways to obtain a priv-esc, checking the logs, list of installed applications and so on. We use a simple Python command to start a minimal web server on our machine and transfer it to the compromised machine (from which we will use wget).
python3 -m http.server 80
It’s clear that we must focus on the ticketValidator.py file which can be run with administrator privileges. From a quick analysis of the script Python code it seems that the possible “weak point” is the use of the eval () function without particular checks. So let’s try to run the program while also checking invalid tickets, in order to have a more precise idea of what the script does.
We can try to “build” a fake ticket that allows us to execute a very simple ls command able to list the contents of the root home directory. Simply using the and operator and Boolean logic.
Finally, let’s get the System flag to complete the machine takeover!
- perform an initial scan with Nmap (and possibly Nikto) is a good practice;
- perform “dirbusting” with more than one tool (i.e ffuf,dirb,dirbuster);
- browse “manually” the website and take notes of what it does and happens. Burp Suite (log history, scope restriction) is a great help;
- remember to check the OWASP top 10: this time we exploited an XXE vulnerability;
- the tabs Proxy and Repeater in Burp Suite are essentials during the testing operations;
- remember the encode/decode of payloads. Sometimes more than one algorithm is used (i.e UURLEncode + Base64);
- once in the system, always remember which user is running the commands and the possible usage of relative/absolute paths;
- remember the “human” factor in password reuse;
- remember to check the most common folders, even the temp ones;
- “sudo -l” command is essential in many situations;
- LinPEAS is a great tool but you must learn to read its report and be careful to possible false flags;
- knowing a bit of Python is a plus (i.e. eval() and __import__)
Analyzing the results obtained from the initial enumeration, I did not pay too much attention to the README.txt file that I checked only later. This could have already given me some interesting indications on how to move around. Its content was indeed quite self-explanatory:
Tasks: [ ] Disable 'test' account on portal and switch to hashed password. Disable nopass. [X] Write tracker submit script [ ] Connect tracker submit script to the database [X] Fix developer group permissions
References, links and more
- XXE attack:
- Privilege Escalation:
- eval() method and more :
- Pentest cheatsheet: https://github.com/savenas/cheatSheatForPentest
- Online tools: