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


---

# 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://0xb0b.gitbook.io/writeups/tryhackme/2024/lookup.md?ask=<question>
```

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.
