Using Feroxbuster, no additional directories or pages were discovered. The only available page is the login.php, confirming that the server is running PHP and that this page handles the login functionality.
┌──(kali㉿kali)-[~/Desktop/THM/Lookup]
└─$ feroxbuster -u http://lookup.thm/ -w /usr/share/wordlists/dirb/big.txt
___ ___ __ __ __ __ __ ___
|__ |__ |__) |__) | / ` / \ \_/ | | \ |__
| |___ | \ | \ | \__, \__/ / \ | |__/ |___
by Ben "epi" Risher 🤓 ver: 2.10.3
───────────────────────────┬──────────────────────
🎯 Target Url │ http://lookup.thm/
🚀 Threads │ 50
📖 Wordlist │ /usr/share/wordlists/dirb/big.txt
👌 Status Codes │ All Status Codes!
💥 Timeout (secs) │ 7
🦡 User-Agent │ feroxbuster/2.10.3
💉 Config File │ /etc/feroxbuster/ferox-config.toml
🔎 Extract Links │ true
🏁 HTTP methods │ [GET]
🔃 Recursion Depth │ 4
🎉 New Version Available │ https://github.com/epi052/feroxbuster/releases/latest
───────────────────────────┴──────────────────────
🏁 Press [ENTER] to use the Scan Management Menu™
──────────────────────────────────────────────────
403 GET 9l 28w 275c Auto-filtering found 404-like response and created new filter; toggle off with --dont-filter
404 GET 9l 31w 272c Auto-filtering found 404-like response and created new filter; toggle off with --dont-filter
200 GET 50l 84w 687c http://lookup.thm/styles.css
200 GET 1l 0w 1c http://lookup.thm/login.php
200 GET 26l 50w 719c http://lookup.thm/
[####################] - 68s 20471/20471 0s found:3 errors:0
[####################] - 67s 20469/20469 305/s http://lookup.thm/
To begin, we intercept a login request to analyze its structure for potential brute-forcing using tools like SQLMap or Hydra. However, standard SQL injection payloads prove to be ineffective. When incorrect credentials are entered, the response is a generic error message stating that either the username or password is incorrect. At first glance, this eliminates the possibility of enumerating usernames or passwords directly.
We proceed by testing a list of SQL login bypass payloads referenced from HackTricks at hacktricks.xyz. These payloads are designed to exploit potential vulnerabilities in the login mechanism. By systematically applying them, we aim to identify if any bypasses work to gain unauthorized access to the application.
Unfortunately, none of the tested payloads proved effective, and SQLMap failed to identify any exploitable vulnerabilities. However, when using the username "admin," we noticed a different response size compared to other attempts. This behavior suggests that "admin" might be a valid username, worth investigating further.
We proceed to fuzz potential passwords for the user "admin" and discover a match. The response size for this particular password differs from the others, similar to the behavior observed during payload fuzzing earlier. This indicates that the correct password for "admin" may have been identified.
When attempting to log in with the identified password for the user "admin," we still receive the generic response previously mentioned, indicating that either the username or password is incorrect.
When we try a different password, the response explicitly states that the password is incorrect. This behavior is unusual. It suggests that the previously discovered password might be valid but is being tested against the wrong user account. Perhaps the system provides feedback for a valid password entered for an invalid username.
To investigate further, we proceed with fuzzing for potential usernames using the xato-net-10-million-usernames.txt list. During the process, we discover a user that returns a 302 status code when tested with the previously identified password. This confirms that we have successfully found a valid credential pair.
After successfully logging in with the valid credentials (jose:REDACTED), we notice that the login request takes some time. We intercept the request and follow the redirection, which leads us to a new URL: files.lookup.thm. This indicates that we have been redirected to a different page, possibly related to the file system or some resources.
We add this to our/etc/hosts file and log in again.
The redirected page reveals elFinder, an open-source web-based file manager, granting us potential access to files within the application for further exploitation.
Initial Access
We see it is the Version 2.1.47.
After some research, we discover an exploit for a command injection vulnerability.
We identify a command injection vulnerability in the PHP connector of elFinder versions <= 2.1.47.
After searching for an exploit, we find that Metasploit has a ready-made exploit for the same CVE. Using it, we successfully gained a shell as the www-data user.
We will use our own shell since we cannot read the files because we are not root
We upgrade our shell using the commands provided in the following resource.
During enumeration, both manually and with LinPEAS, we discover the user think. In their home directory, we find a potentially valuable file named .passwords, but we currently don't have permission to read it.
The LinPEAS output, we are able to spot an unknown SUID binary pwm owned by root.
Running the command reveals that the system checks the user ID to locate the corresponding .passwords file in the user's home directory. This suggests that the file might be part of a password manager for storing user credentials.
www-data@lookup:/home/think$/usr/sbin/pwm[!] Running 'id' command to extract the username and user ID (UID)[!] ID: www-data[-] File /home/www-data/.passwords not foundwww-data@lookup:/home/think$
We copy the file to the web root folder to download it to our machine and analyze it.
By quickly inspecting the output using strings, we identify that the mechanism for extracting the username seems to rely on the id command. This could be the method used to map the user to their respective .passwords file.
We create a simple bash script named id that mimics the output of the original id command. We then place this script in /tmp/id and make it executable, allowing us to potentially bypass the original id command's behavior.
echo '#!/bin/bash' > id
echo 'echo "uid=1000(think) gid=1000(think) groups=1000(think)"' >> id
chmod +x id
Next, we prepend /tmp to our PATH variable, ensuring that the system will look for binaries in the /tmp directory first when executing commands like id. This allows us to control the behavior of commands that would otherwise use the system's default binaries.
export PATH=/tmp:$PATH
Now, after running /usr/sbin/pwm, we successfully retrieve the contents of the .passwords file. Among the listed passwords, one stands out as particularly noteworthy, and we decide to focus on it for further exploitation.
We could attempt to brute-force the SSH login using Hydra, targeting the SSH service with the identified username and password list.
hydra-l'think'-Ppass.txtlookup.thmssh
We use the discovered password to switch to the user "think" using su and successfully read the first flag located in the user's home directory.
Privilege Escalation
With the password in hand, we run sudo -l and discover that the user is permitted to use the look command with root privileges. The look command performs a dictionary lookup and displays lines from a sorted list of words that start with a specified prefix.
think@lookup:~$sudo-l[sudo] password for think: MatchingDefaultsentriesforthinkonlookup:env_reset,mail_badpass,secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/binUserthinkmayrunthefollowingcommandsonlookup: (ALL) /usr/bin/lookthink@lookup:~$
On GTFObins, we find that we can exploit it to read any file as root by using sudo. This allows us to bypass permission restrictions and access files that are otherwise restricted.
We store the contents of the SSH key on our local machine and adjust its permissions to ensure it can be used for SSH authentication. This allows us to securely connect to the root account on the target machine.
Next, we use it to log in as root and find the final flag in the root home directory.
