# Lookup {% embed url="" %} The following post by 0xb0b is licensed under [CC BY 4.0

](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.

The index page reveals a login page.

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.

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

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="" %} 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 %}

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 %}

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

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.

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 %}

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

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

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.

## Shell as www-data We see it is the Version `2.1.47`.

With a little research we find an exploit to a command injection vulnerability. {% embed url="" %} elFinder <= 2.1.47 - Command Injection vulnerability in the PHP connector. {% embed url="" %} 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.

The exploits require and JPG, so we chose any.

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

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.

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

We get a connection back and are `www-data`. Next, we upgrade our shell using the commands provided in the following resource. {% embed url="" %}

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

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

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.

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

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

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.

The path is then complemented with the extracted username.

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.

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

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

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.

Alternatively, we could try to brute-force the ssh log in using Hydra: ``` hydra -l think -P .passwords lookup.thm ssh ```

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.

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

Looking up that binary at GTFObins we are able to actually read any files as `root` using `sudo`. {% embed url="" %}

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

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

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