Include
Use your server exploitation skills to take control of a web app. - by 1337rce and l000g1c
The following post by 0xb0b is licensed under CC BY 4.0
Recon
We start with a Nmap scan and have eight open ports. Among them SSH on 22, as well as other email service related ports and two out of the row ports 4000 and, 50000.
A default script and service scan reveals that there are web services on ports 4000 and, 50000. A Node.js is running on 4000 and an Apache httpd 2.4.41 on 50000. We also see a host mail.filepath.lab.
We use Gobuster to enumerate the directories, but in the meantime we don't find anything interesting on port 4000.
When visiting the index page on port 4000 we find a login form. We can log in with guest:guest.
Before we continue with port 4000, we enumerate the directories on port, 50000. Here we see phpmyadmin as directory. We extend our scan with ending to php using -x .php, but leave it at that for now.
When we visit the index page, we see that we are dealing with the SysMon app, behind whose login the first flag should be located.
We visit the login page, try guest:guest and some other default credentials, even though this would be far too easy, and are unsuccessful.
From Prototype Pollution To SSRF
We move back to the review app on port 4000 and use the suggested credentials guest:guest.
We successfully log in and are able to inspect our profiles and others.
We can view our profile and recommend activities. When you create an activity, it will be attached. If we change the key value of an activity that we have attached, its value changes and is not reattached. The value values are placed in quotation marks. A sanitization takes place.
The first idea was to work with server side includes, but this was not successful - just because of the name of the room. But while playing around with the ID, I noticed that we had made the profiles inaccessible and after restarting the machine and taking another look, something very obvious I noticed. The isAdmin value is set to false. Even if the values are sanitized and the values are set in quotation marks, try to set it to true.
After setting the isAdmin value to true through recommending an activity, two new links in the header appear API and Settings. This is called Prototype Pollution. Prototype pollution is a security vulnerability where we can manipilate an object's prototype, thereby injecting malicious properties that can propagate to all instances of that object. This can lead to unauthorized access or modification of data, enabling various attacks such as denial of service or remote code execution.
By visiting the /admin/api page reveals to us the internal API endpoints of which one of them discloses the credentials for the SysMon app. Those weren't visible in the Nmap scan, so we have to find a way to make a request through the application, for example.
Next we head to /admin/settings and see we could update the banner image by providing a URL. This begs almost for a try of SSRF. Server-Side Request Forgery (SSRF) is a vulnerability where an attacker tricks a server into making unauthorized requests to internal or external systems. Let's see if we can access the internal API endpoints.
Check out the follwing:
We try the first one http://127.0.0.1:5000/internal-api...
... And get base64 encoded JSON data as a result.
Passing it to CyberChef to decode it, we get the exact same response like in the example of /admin/api.
Next, we make a request to http://127.0.0.1:5000/getAllAdmins101099991...
And are able to retrieve the credentials for the SysMon App.
After logging in...
...We get redirected to dashboard.php and find the first flag.
From LFI To RCE
Upon closer inspection via Burp Suite and the source of the site, we see that the profile image gets loaded via /profile.php?img=profile.png.
We may be able to exploit it using Local File Inclusion (LFI) that allows us to include files on a server, potentially exposing sensitive data or executing arbitrary code.
We use the fuzzer FFuF to efficiently try out a large number of LFI payloads. We use the Jhaddix LFI list. Don't forget the phpsessid to include, since the profile.php page is only available for logged-in users. After a short time, we have a hit with ....//....//....//....//....//....//....//....//....//etc/passwd.
We can read /etc/passwd. The question for the second flag is about a hidden file in /var/www/html, but we are not able to enumerate the contents of directories with just LFI. So a webshell will probably be necessary. There are all kinds of ways that could be tested, my favorite one is LFI through php filters. Others like including the php session cookie and manipulating its cotent, but those didn't work. A good resource on that topic can be found here:
Another way could be by log file poisoning. Log file poisoning is a technique where we inject malicious input into log files, which can later be executed as code when the logs are processed or viewed. This can lead to Remote Code Execution (RCE) if the malicious input is executed by the system or application reading the logs.
We need to try various log file locations like /var/log/apache2/access.log. Some can be found here:
This can also be a valuable tool to try, but wasn't in the attempt of the challenge:
Log Poisoning Through Mail
Since so many services related to mail are present we try to posing the logs of the mail server.
The other attempt depicts on poisoning the email log instead of the auth.log, but wasn't successful. The following resources were used:
We could assume that the web app is running as www-data.
We connect to the open SMTP service on port 25 and craft and submit a mail and try to find it in the log files. With VRFY www-data@localhost we can confirm that the user is present.
We then should be able to find the mail log somewhere here: /var/mail/<user>, but neither of the resources in mind lead to anything.
After some more research we could determine the location /var/log/mail.log. This holds the log of our mail attempt.
We see that the sender of the mail gets reflected.
Let's try to craft a mail with the sender containing the payload. SMTP issues a bad sender address. But maybe this will get logged.
In the log, we can see that our sender address is incomplete. It might have worked, cause the PHP code gets evaluated.
We try to list the files in the current directory and find the second flag inside that text file.
Log Poisoning Through SSH
After some further manual attempts, /var/log/auth.log seems promising since it logs also the tried SSH connections. If we are able to craft a malicious payload as the username, we could inject PHP code the log and get it executed. This was the first attempt of solving the machine.
We log in as an arbitrary user with some creds.
And see the result of an invalid login attempt with our username reflected.
Next, we try to log in with a PHP web shell, but ssh fails us here.
To circumvent it, we can either write a script or just use hydra.
After having planted the PHP web shell via the username, we are able to use it by including /var/log/auth.log and move through the system...
...And are able to retrieve the second flag.
Bonus: Initial Foothold + Privilege Escalation
Like in Bypass https://0xb0b.gitbook.io/writeups/tryhackme/2024/bypass, we can make use of CVE-2024-1086!
This is an exploit that we shouldn't underestimate.
First we craft a reverse shell to get an initial foothold. We are using revshell.com.
This will be the command to use with either of the LFI2RCE options we have:
We are dealing with the kernel 5.15.0-1055.
The POC of CVE-2024-1086 is a promising one. We compile the following and bring that to the machine.
After compiling the exploit, bringing it to the machine and executing it, we become root.
Further Considerations
We have been able to detect protoype pollution on endpoint 4000. After looking at the app.js, PP2RCE could also be possible. Unfortunately, I have not been able to make any progress on this at the moment.
Hacktricks offers extensive resources here:
Last updated
Was this helpful?