> For the complete documentation index, see [llms.txt](https://0xb0b.gitbook.io/writeups/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://0xb0b.gitbook.io/writeups/tryhackme/2024/lookup.md).

# Lookup

{% embed url="<https://tryhackme.com/r/room/lookup>" %}

The following post by 0xb0b is licensed under [CC BY 4.0<img src="https://mirrors.creativecommons.org/presskit/icons/cc.svg?ref=chooser-v1" alt="" data-size="line"><img src="https://mirrors.creativecommons.org/presskit/icons/by.svg?ref=chooser-v1" alt="" data-size="line">](http://creativecommons.org/licenses/by/4.0/?ref=chooser-v1)

***

## Recon

We start with a Nmap scan and find two open ports. On port `22` we have SSH, and on port `80` we have an Apache httpd `2.4.41` web server.

<figure><img src="/files/cR6qMuRY4I9AislthjjG" alt=""><figcaption></figcaption></figure>

The index page reveals a login page.

<figure><img src="/files/vdVPtwCXcCrA81Cn6hiU" alt=""><figcaption></figcaption></figure>

Further directories and pages could not be found by using Feroxbuster. Only that it is a PHP server, with the login.php page that is used for the login.

<figure><img src="/files/fRjcKKUMKzCbxMokBTBd" alt=""><figcaption></figcaption></figure>

## Web Access

First of all, we intercept a login request to see how it is structured in order to brute-force logins using SQLMap or Hydra, for example. Standard SQL Injection payloads were unsuccessful. If an incorrect entry is made, we only see a generic response that either the username or password is incorrect. At first glance, no password or username enumeration seems possible.

<figure><img src="/files/eaZrQ5TAZnWleEfUPsLI" alt=""><figcaption></figcaption></figure>

We continue with a list of SQL Login Bypass payloads referenced at hacktricks.xyz. We had previously used the same in the Injectics room.

{% embed url="<https://github.com/HackTricks-wiki/hacktricks/blob/master/pentesting-web/login-bypass/sql-login-bypass.md>" %}

Unfortunately, this did not produce any functioning payloads. SQLMap did not produce anything either. For the user `admin`, we get a different response size than for the other payloads. Perhaps this is a valid user.

{% code overflow="wrap" %}

```
ffuf -w bypass.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
```

{% endcode %}

<figure><img src="/files/qLGaEEEEahrBE4LVrQJ8" alt=""><figcaption></figcaption></figure>

We are now fuzzing for possible passwords for the user `admin`. And have a hit. The response size is different here than for others. Like earlier with our payload fuzzing.

{% code overflow="wrap" %}

```
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
```

{% endcode %}

<figure><img src="/files/04bTTUCOI3KHfmMUkt5e" alt=""><figcaption></figcaption></figure>

If we use the password for the user admin, we get the generic answer as mentioned earlier.

<figure><img src="/files/CDwJLBKvRanK8RRGUoGQ" alt=""><figcaption></figcaption></figure>

If we enter a different password, we are informed that the password is incorrect. That's strange. Maybe we get feedback for the correct password for the wrong user with our found password from before.

<figure><img src="/files/GR2C7UY2YAYfe4SEgMi3" alt=""><figcaption></figcaption></figure>

So, let's fuzz for other users and use the `xato-net-10-million-usernames.txt`. And we find a user who provides a `302` status code for the previously found password. We have found a credential pair.

{% code overflow="wrap" %}

```
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=REDACTED' -H "Content-Type: application/x-www-form-urlencoded; charset=UTF-8"  -fw 8
```

{% endcode %}

<figure><img src="/files/4XJM0xdgXHLPmJ2jK73s" alt=""><figcaption></figcaption></figure>

The login takes some time. We intercept the login request with the correct login credentials, `jose:REDACTED` for checking, and follow the redirection. We see that it is redirected to `files.lookup.thm.`

<figure><img src="/files/8UAe680T7R5gP5c61cHf" alt=""><figcaption></figcaption></figure>

We add this to our`/etc/hosts` file and log in again.

<figure><img src="/files/JhTtqdYlytoLueWjh7lA" alt=""><figcaption></figcaption></figure>

We see something like a file manager. It is elFinder, an open-source file manager for web applications that allows users to manage files and directories.

<figure><img src="/files/oDc7ubwDd8BO70fM1E5j" alt=""><figcaption></figcaption></figure>

## Shell as www-data

We see it is the Version `2.1.47`.

<figure><img src="/files/1Q7kPgvAZfIafU2WIrnh" alt=""><figcaption></figcaption></figure>

With a little research we find an exploit to a command injection vulnerability.

{% embed url="<https://github.com/Studio-42/elFinder/issues/2868>" %}

elFinder <= 2.1.47 - Command Injection vulnerability in the PHP connector.

{% embed url="<https://www.exploit-db.com/exploits/46481>" %}

This exploit requires `Python 2.7` and accesses the `connect.minimal.php` to upload files. We test if it is reachable without a login, since the exploits available do not handle any authentication. But we do not need to adapt the script. The endpoint to `connect.minimal.php` is reachable without authentication.

The vulnerability lies in the filename, which allows commands to be injected. The exploit creates a PHP web shell into the upload directory while uploading an arbitrary image.

<figure><img src="/files/BQm88rTuqUOvmFQhjYAk" alt=""><figcaption></figcaption></figure>

The exploits require and JPG, so we chose any.

<figure><img src="/files/uxFk8qh4DldlASmkeMLQ" alt=""><figcaption></figcaption></figure>

Next, we need to run the exploit with the correct URL. The endpoint is vulnerable; we have a pseudoshell.

```
python2.7 elfinder.py http://files.lookup.thm/elFinder/
```

<figure><img src="/files/PMD4VgjsXx6fSbwLIfBG" alt=""><figcaption></figcaption></figure>

Now we create a payload to establish an interactive shell. For this, we use revshell.com. We chose the `nc mkfifo` one and URL encode the payload since we have a web shell.

<figure><img src="/files/6fMdehsFjH5keBwyGSs1" alt=""><figcaption></figcaption></figure>

We set up a listener on our desired port and run the payload.

<figure><img src="/files/kP99lLObbNDh8qFGmoKb" alt=""><figcaption></figcaption></figure>

We get a connection back and are `www-data`. Next, we upgrade our shell using the commands provided in the following resource.

{% embed url="<https://0xffsec.com/handbook/shells/full-tty/>" %}

<figure><img src="/files/XEjYtxrH0wuQWQHXudt5" alt=""><figcaption></figcaption></figure>

## Shell as think

While enumerating the target manually and with LinPEAS we find the user `think`, where we are able to list the files in the home directory of the user. There is a possible valuable file present here, the `.passwords`, which we aren't allowed to read... yet.

<figure><img src="/files/4U4x02HllqVHe5KA6cbS" alt=""><figcaption></figcaption></figure>

In the LinPEAS output, we are able to spot an unknown SUID binary `pwm` owned by `root`.

<figure><img src="/files/zgVDRsd7J1ZfviqgfhGS" alt=""><figcaption></figcaption></figure>

Running it reveals that it checks the `id`, from which the current user is derived, and then used to locate the `.password` file of that user in the home directory. So it might be some sort of a password manager.

<figure><img src="/files/n45R46UJtN0Fnug0SMV5" alt=""><figcaption></figcaption></figure>

We copy the file to the web root folder to download it to our machine and analyze it.

<figure><img src="/files/YJtndo3Eamhu6lmxRic5" alt=""><figcaption></figcaption></figure>

```
http://lookup.thm/pwm
```

<figure><img src="/files/RFmJw0ODmrZ22zUvjDq6" alt=""><figcaption></figcaption></figure>

With a quick look using `strings`, we see the mechanism by which the username is extracted from and output that might be the `id` command.

<figure><img src="/files/faVJFGniPzizxILudLIX" alt=""><figcaption></figcaption></figure>

The path is then complemented with the extracted username.&#x20;

<figure><img src="/files/axMHc7TOoCiMjNPp39i5" alt=""><figcaption></figcaption></figure>

Next, we analyze the binary using BinaryNinja. Here we set the language to pseudo c first. In the main function, we see that `data_204e` might hold the path to the id command.

<figure><img src="/files/bqH8Y4cg4kIxQ9QKtWPS" alt=""><figcaption></figcaption></figure>

By clicking on the variable `data_204e`, we see that it stored just `id`. So a relative path, not an absolute path, is used. Which makes it possible to point to a different id executable using the `PATH` environment variable to fool the binary that we are the user `think`.

<figure><img src="/files/QM5tUL7GecD3cU5Nxp5E" alt=""><figcaption></figcaption></figure>

For this, we create a simple bash script called `id`, that mimics the output of the original `id` command and place it into `/tmp/id` and make it executable.

```
echo '#!/bin/bash' > id
echo 'echo "uid=1000(think) gid=1000(think) groups=1000(think)"' >> id
chmod +x id

```

<figure><img src="/files/UwQhRFM2yGT3be94fj4B" alt=""><figcaption></figcaption></figure>

Next we prepend `/tmp` to our `PATH` variable so that binary is looked up first there when any binary like `id` is called.

```
 export PATH=/tmp:$PATH
```

Now after running `/usr/sbin/pwm` we get the contents of `.passwords`. We could now  try each of the passwords, but one stands out. &#x20;

<figure><img src="/files/bkCRCp0uxdN9IrPTEoBD" alt=""><figcaption></figcaption></figure>

Alternatively, we could try to brute-force the ssh log in using Hydra:

```
hydra -l think -P .passwords lookup.thm ssh
```

<figure><img src="/files/jF5x4xTOu5Xiwzvyko7B" alt=""><figcaption></figcaption></figure>

We use the found password to switch to the user `think` using `su` and are able to read the first flag in the user's home directory.

<figure><img src="/files/jlNKfjhWcFnLMLaHsqpD" alt=""><figcaption></figcaption></figure>

## Shell as root

Equipped with the password, we are able to run `sudo -l`. We see that the user is able to use look with `sudo` permissions for the `root` user. The binary `look` performs a dictionary lookup to display lines from a sorted list of words that begin with a specified prefix.

<figure><img src="/files/HsGhqYarjay3SM6hGpy4" alt=""><figcaption></figcaption></figure>

Looking up that binary at GTFObins we are able to actually read any files as `root` using `sudo`.

{% embed url="<https://gtfobins.github.io/gtfobins/look/#sudo>" %}

<figure><img src="/files/FtPC1OMda1OxM8Yau8X2" alt=""><figcaption></figcaption></figure>

We try to read the private ssh key of the root user located at `/root/.ssh/id_rsa` using the following commands displayed at GTFOBins. We are able to read the ssh key.

```
LFILE=/root/.ssh/id_rsa
sudo /usr/bin/look '' "$LFILE"
```

<figure><img src="/files/hFShVYosNvp3NBzPauaL" alt=""><figcaption></figcaption></figure>

We store the contents of the SSH key on our machine and adjust the permission to be able to use it.

<figure><img src="/files/AvCMrBwuO8MNgrncITbH" alt=""><figcaption></figcaption></figure>

Next, we use it to log in as `root` and find the final flag in the root home directory.

<figure><img src="/files/vhnWuB502zUC7Hu5gFQL" alt=""><figcaption></figcaption></figure>
