Lookup
Test your enumeration skills on this boot-to-root machine. - by josemlwdf
Last updated
Test your enumeration skills on this boot-to-root machine. - by josemlwdf
Last updated
The following post by 0xb0b is licensed under CC BY 4.0
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.
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.
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.
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.
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.
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.
We see it is the Version 2.1.47.
With a little research we find an exploit to a command injection vulnerability.
elFinder <= 2.1.47 - Command Injection vulnerability in the PHP connector.
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.
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.
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.
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.
Next we prepend /tmp to our PATH variable so that binary is looked up first there when any binary like id is called.
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:
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.
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.
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.
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.
