TryHackMe Lookup Boot2Root — Writeup
Welcome back to my write-up! Today, I’ll walk you through a detailed, step-by-step guide on how I tackled the “LookUp” challenge on TryHackMe. As a new player on THM, I’m excited to share my learning journey, strategies, and insights with you all. Whether you’re a beginner like me or a seasoned pro, I hope this guide helps you understand my approach and perhaps pick up a few tips along the way. Let’s dive in!
Reconnaissance
First, I took a look at the webpage of the challenge, when I open it in the browser, it’s service unavailable but redirected to a domain lookup.thm I guess we need to add this domain to our /etc/hosts file to access the webpage. After adding it, and refresh the site, we will see a login form
At this point, we don’t have much information since we didn’t do anything yet. So let’s start hacking this!
I will scan the open ports of the machine to identify potential entry-points using nmap:
I attempted to brute-force the subdirectories using Gobuster, but unfortunately, it didn’t reveal anything useful that could help us obtain the credentials for the login page. Despite exploring potential hidden paths, the results came up empty. This means we need to pivot our approach and consider other techniques or tools to uncover the information we need. Persistence is key, so let’s dive deeper into alternative strategies.
When I try to fill the username and password prompt with some common usernames and passwords like admin:password123, etc. I noticed something here, take a close look at the errors when I typed admin.
When I typed some dummy username
Did you spot the difference? When I entered “admin,” the system only indicated that the password was incorrect, without mentioning the username. However, when I tried other dummy usernames, the error message included the username as well. This suggests that admin is a valid username.
At this point, we can create a program that will bruteforce only the username. For sure, there’s another user here except admin.
import requests
import threading
import time
TARGET_URL = "http://lookup.thm/login.php"
USERNAMES_FILE_PATH = "/usr/share/seclists/Usernames/Names/names.txt"
def read_usernames(file_path):
try:
with open(file_path, "r") as file:
usernames = [line.strip() for line in file if line.strip()]
return usernames
except FileNotFoundError:
print(f"[!] Error: The file {file_path} does not exist.")
return []
def brute_force(username):
payload = {
"username": username,
"password": "kuroshiro" # Fixed password
}
try:
response = requests.post(TARGET_URL, data=payload)
if "Wrong password" in response.text:
print(f"[+] Valid Username Found: {username}")
except requests.RequestException as e:
pass
def threaded_bruteforce(usernames):
threads = []
for username in usernames:
thread = threading.Thread(target=brute_force, args=(username,))
threads.append(thread)
thread.start()
time.sleep(0.01)
for thread in threads:
thread.join()
if __name__ == "__main__":
print("[+] Attempting BruteForce...")
usernames = read_usernames(USERNAMES_FILE_PATH)
if usernames:
threaded_bruteforce(usernames)
else:
print("[!] No usernames to process.")This Python script performs a bruteforce attack on a login page by testing multiple usernames (from a file) with a fixed password using threading for faster execution. It reads usernames from a specified file and sends POST requests to the target URL, where each thread attempts to log in with a different username. If the response contains “Wrong password”, it indicates the username is valid, and a message is printed. The script creates threads to run the login attempts concurrently, speeding up the process, and includes small delays to control the flow and avoid overwhelming the server.
When we run it, it gives us 2 users
The other user is Jose. At this point, we can now use Hydra to bruteforce the password, but the first step is always to manually test common passwords before attempting automated bruteforce.
And my luck works!!! The password of jose is password123!!! Told ya!
Here, we have some sort of file manager here named Elfinder, with a txt files, containing some sort of password. Maybe we can use these credentials later.
Upon exploring the file manager, I found the version of the Elfinder here
2. Exploitation
There could be an exploit for this, such as Remote Code Execution (RCE). To investigate further, I used Searchsploit to search for potential exploits related to this version of Elfinder.
And there it is, there’s an RCE for this! We can now fire up our metasploit!
We will use the index 4 for our exploitation.
Just set the RHOSTS with the Subdomain of the Elfinder and the LHOST with your tunnel IP.
We can now launch our exploit!
Now that we have a Meterpreter session, type shell to access a basic command shell. However, to make it more interactive, we need to spawn a TTY shell after entering the basic shell. This will allow us to run commands more effectively and interact with the system in a more user-friendly manner.
I navigated to the /home directory and found a user named think. After entering the think user's directory, I listed all its files and discovered that the user.txt file contains the user flag. However, the file is only readable by the think user, so we cannot access it unless we are logged in as think.
We will scan now for SUID binaries that we can execute to gain some privilege: find / -type f -perm -04000 2>/dev/null
After executing the command, I noticed an unusual binary located at /usr/sbin/pwm. This is not a default binary in Linux, which makes it suspicious. It could potentially be a custom or malicious binary, so it’s worth investigating further to understand its purpose and see if it might be exploitable.
When we execute it, this is the output
It seems that this binary executes the id command, which returns the user information, then extracts the username from the output. After that, it stores the username in a file located at /home/<username>/.passwords. The binary likely performs some action with this file or the extracted username, potentially for further automation or exploitation.
If the id command is not specified with its full path, it will be located and executed based on the directories listed in the PATH environment variable. This means the binary could potentially execute a different version of the id command (or a malicious version) if the PATH variable is manipulated or if there is a user-modified id binary in one of the directories included in the PATH. This could be leveraged for privilege escalation.
To trick the program into executing a different id command that outputs the think username, we can create a custom id command, such as a script that returns the desired username. Then, modify the PATH environment variable to prioritize the directory containing this custom command over the system directories. For example, you could add a directory like /tmp/custom_id to the PATH, ensuring that your custom id is executed when the program calls id. This will cause the program to extract the think username and potentially use it for further actions.
Now we can create the program and store it in /tmp
After that, change the permission of the id file in /tmp to executable: chmod +x id
Let’s rerun the program
As you can see here, it returns the ID to think and prints a lot of possible passwords, now we can bruteforce the user think here since we have these possible passwords that user think might use.
As you can see here, I bruteforce the user think with Hydra and we now got the password!! Now let’s login as think through SSH.
We’re in!!!
3. Privilege Escalation
Upon checking think’s sudo privileges for potential root escalation, we see that think can use the look command.
I checked the GTFobins to see if we can use look to escalate privilege.
Looks like we can use this binary to access files on the system, and since we can execute it as root, we have the ability to read any file on the system.
The most effective way is to use the root’s private key of ssh. But honestly, we can access the root flag using this but we need to be root user!!!!!! To fully pwned the system!!!
As you can see here, it returns the private key of the root user. We can copy this to our attacker machine and save it to id_rsa file. and set the permission to 000 to avoid permission errors during login.
After that we can now login as root through SSH using that private key!
We are now the root user!!!
We’ve successfully completed the Lookup CTF!!!!
Conclusion
This challenge primarily focuses on enumeration, as it requires identifying vulnerabilities, system configurations, and hidden resources to exploit. The key to success lies in carefully examining system behaviors, directories, and binaries to uncover potential attack vectors. By thoroughly analyzing the environment, such as manipulating the PATH variable or investigating unusual binaries, we can gain access to critical information. Overall, this exercise emphasizes the importance of attention to detail and methodical exploration when performing penetration testing or security assessments.
Last updated