Include
Use your server exploitation skills to take control of a web app.
Last updated
Use your server exploitation skills to take control of a web app.
Last updated
This work by Manav G Krishna is licensed under CC BY-NC 4.0
Machine IP: 10.10.147.179
Hosts file entry: echo '10.10.147.179 include.thm' | sudo tee -a /etc/hosts
Nmap Scan:
From the scan we can see that port 4000 and 50000 have web services running on them and also there is a host named mail.filepath.lab.
Checking out port 4000:
We can now do some directory busting:
Command:
The /signin path is the same as the root of the website.
Now let us check out 50000.
Checking out port 50000:
We have a Login page too:
We can go ahead and directory bust this site:
Command:
At the moment we are on the /login.php, we also have a /dashboard.php & a /profile.php that we would be able to access once we manage to login to the SysMon portal. There is a /uploads & a /templates path too.
The /uploads path:
The /templates path:
There is nothing interesting in these paths.
We can now go back to exploring port 4000:
We can check out our profile by clicking on View Profile.
We have an entry that says: isAdmin: false and also we have an option to recommend an activity:
Now we can try to set the isAdmin to true by recomending it is an activity:
Upon clicking on Recommend Activity we notice these changes:
The isAdmin value is now set to true, which means we have made ourselves an admin. Doing so also gave us two new options on the website that wasn't there before by default, that is API & Settings.
What we did here is Prototype Pollution. Prototype Pollution is a critical vulnerability that can allow attackers to manipulate an application's JavaScript objects and properties, leading to serious security issues such as unauthorized access to data, privilege escalation, and even remote code execution.
In this case from the Nmap Scan we know that the server running on port 4000, is Node.js. So the server-side code running on the application is obviously JavaScript. If user inputs are directly merged into objects without sanitization, it leads to modification of prototypes and this is what we did above.
Checking out the API option:
We are presented with an API Dashboard and it says a GET request to this endpoint: http://127.0.0.1:5000/getAllAdmins101099991 will give us a response like this:
We get the SysMon portal password and it says the username is administrator. Once we get the password we would be able to login to the portal on port 50000:
But the request has to be sent to the machine's localhost on port 5000.
Let us now check out the Settings option:
It lets us update the banner image.
We can now try putting this as the URL: http://127.0.0.1:5000/getAllAdmins101099991 to see what we are presented with post clicking on Update Banner Image:
It gave us this base64 encoded string:
Decoding it:
Command:
We have now got the SysMonAppPassword.
What we just did is nothing but SSRF. Server-Side Request Forgery (SSRF) is a vulnerability where an attacker can make a server-side application send requests to an unintended location. This can lead to fetching the internal resources which is typically inaccessible from outside the server’s internal network, potentially exposing sensitive information.
In this case we were able to reach out to those API endpoints via an external input.
Logging in to the portal on port 50000:
The first flag can be found here. We are on the /dashboard.php endpoint now.
From the initial directory busting that we did for the 50000 port, we also had a /profile.php endpoint. Let us start by checking out the source code of the dashboard page:
The /profile.php endpoint is being referred to in the source code.
We can now check it out:
The URL:
There is a parameter named img. By looking at this the first thing that comes to our mind is LFI (Local File Inclusion).
We can try to automate the process of exploiting the vulnerability by using wfuzz.
The wordlist that we will be using:
This is a really common and famous wordlist that gives us valid hits in most of the cases.
Using wfuzz to find LFI:
Command:
Switches explanation:
Since the site we are fuzzing is behind a login, using the cookie in the wfuzz command plays a crucial role as this is how the server knows that the requests coming from the tool are authenticated.
To fetch the cookie we can Inspect the page and under Storage is where we find it:
The tool injects payloads at the position where the FUZZ keyword is placed.
And we have got successful hits, a few of them are:
The moment we see different values in the Lines, Words & the Chars columns, that is how we know the payload is valid.
One out of the bunch of valid payloads:
Let us give this a try:
The URL:
It worked!!
Now since we have LFI, this can be converted to an RCE (Remote Code Execution)
LFI to RCE:
Method 1: LFI to RCE via Log Poisoning
A blog that we can check out:
Common log files in Linux:
The /var/log/auth.log log file is used by various authentication services, including SSH.
Logs related to SSH activities, such as session starts, stops, authentication attempts etc., will be logged.
We can now traverse to the log file:
The payload:
The URL:
Now we can try to make fake attempts to login via SSH and this should be getting logged in the auth.log file:
It is indeed getting logged as expected.
Now, we can try to insert a PHP payload as the user in the SSH command. This too, should get logged just like the fake SSH logins we did earlier with the user test.
The payload:
Command:
Unfortunately this doesn't work as this has been patched in the latest versions of SSH. We get the error: remote username contains invalid characters.
Note:
I had come across a question asked in Stack Overflow based on the above error and an answer mentioned that we could use Hydra to perform the poisoning successfully.
Using Hydra to achieve RCE via the SSH protocol:
The logic here too remains the same as above, we can insert a PHP payload as the value for the -l switch of Hydra which is nothing but the login username and since we are are using it against the SSH service, that too will get logged in the auth.log file and this would lead to RCE.
Command:
Now let us check out the log file:
It has been logged.
Now we should have RCE, running ifconfig:
The URL:
It worked!!
Method 2: LFI to RCE via MAIL (SMTP):
Common log files in Linux:
Since we have SMTP open, we can send a mail to test if it is getting logged. It should be getting logged as all email related activities are logged in the /var/log/mail.log file.
The payload:
The URL:
Manual Exploitation:
We can send a test email by connecting to port 25 (SMTP):
And indeed it is getting logged as expected:
Now we can put a PHP payload in mail from/rcpt to and this would get logged too, which would lead to RCE:
We get this error: 501 5.1.7 Bad sender address syntax.
But let us check if it got logged:
And it did get logged.
Using ifconfig to check if RCE works:
The URL:
It did work and we have got the output of the ifconfig command. Now we can run ls -la and we will be able to see the second flag and the same can be cat ed out via the webshell itself.
Use - cat 505eb0fb8a9f32853b4d955e1f9123ea.txt:
Using swaks tool to send the mail to achieve RCE:
Note:
I will be showing this post terminating the machine. This way we are making sure we start on a fresh machine and by doing so the webshell that we got from manual exploitation, won't even be in the picture. Make sure to update the hosts file entry with the new IP.
We now have nothing logged in the /var/log/mail.log:
Now we can use swaks:
Command:
Checking the log file:
It has got logged.
Now onto the RCE yet again:
We have got the output of ifconfig.
We can also use this PHP payload to get RCE via SMTP:
The payload:
Using a reverse shell in the webshell:
Command:
Setting up a listener on port 443:
The URL:
We indeed get the connection.
Now we can upgrade the shell a little by running this:
Command:
Privilege Escalation via CVE-2024-1086 (Optional):
The kernel on the machine is 5.15.0-1055-aws.
Command:
The machine is most likely vulnerable.
Downloading the exploit from the Releases section in GitHub:
Sending it to the target machine post setting up a python server:
Command:
Setting it as an executable and running it:
We are root.
Room solved!!
