Cordian – Offensive IT

Machine: Earth
Target IP: 10.1.1.8
Attacker IP: 10.1.1.7
Difficulty: Easy
Goal: Get root access
Link: https://www.vulnhub.com/entry/the-planets-earth,755/

As usual we start with a Nmap scan to identify open ports on the target system. To do this we use the parameters -sC to scan for with default scripts as well as -sV to enumerate active services.

This gives us the extra information that there are host names within the SSL certificate as shown in figure 1.

When we access the web server on port 80 we get an 404 response back while on 443 we see a Fedora test page as the Nmap scan both already indicated.

Since we already know about the host names of the target machine from figure 1 we can add them into the hosts file of our attacker machine /etc/hosts and access the webpage now over earth.local on port 443. Furthermore we can verify that there is also an interface answering requests for terratest.earth.local – the second name extracted from figure 1.

From earth.local we are able to send messages but when submitting a message it is getting encrypted or encoded. Furthermore we have access to three old messages that have been sent before. For now it seems like there is no way of knowing what was sent before and that we have to look for hints on how to decode or decrypt the messages.

To find more information we can use a tool called wfuzz to search for hidden web directories as shown in figure 4.

4. Using wfuzz to search for hidden directories of the web server

Using the –hw parameter we can exclude false positive findings and discover that there is a directory called /admin on earth.local where we are prompted with a login that requires a username and a password.

After trying some common username and password combinations like “admin, admin” or “admin, password” and also a quick verification if the login might be vulnerable to SQL injection attacks we keep on searching for new directories. When looking closely at the second hostname that we know of we will find a robots.txt entry on terratest.earth.local.

6. Content for terratest.earth.local/robots.txt

The last entry within the robots.txt file looks interesting. Since it shows /testingnotes.* we can test some common file endings and have a hit on /testingnotes.txt.

7. terratest.earth.local/testingnotes.txt

The content of testingnotes.txt exposes a username and another file called testdata.txt which was used as a key for the encryption of the messages that we have seen in figure 3.

8. Content for /testdata.txt used as key for encrypting messages

With the knowledge of the encryption cipher, the encrypted message and the key that was used we can try to decrypt the messages from figure 3. After playing around with the format (Hexcode) we are able to decrypt at least one message with the key provided within /testdata.txt – however it is is not really clear on what to do with the decrypted message itself.

9. Using gchq.github.io/CyberChef/ to decrypt the messages

After taking a shot at some wild guesses on what to do with the decoded message we are able to use it as password with the earlier identified username from /testingnotes.txt on earth.local/admin. This gives us access to an edit field that executes the provided input on a CLI of the target system.

10. CLI access over 443 – after login on /admin

When trying to access a remote source the input does not get executed and we are prompted with an error message. However when we do not enter any IP the system is able to connect to external resources as shown in figure 11. It might be the case that there is only a filter that searches for IPs used in the input provided by the user.

11. Remote connections do work without an IP

Playing around with the CLI input we discover that we can not change directories and ware not allowed to create a file in the current directory – however we can write into the /tmp directory.
We can verify this by using commands like the following

echo “test”> /tmp/asd.txt
cat /tmp/asd.txt

which prints out the string test.

For the command
ls /var/www/html

we get an answer. This allows us to list the web server root directory
/var/www/html/terratest.earth.local/. Unfortunately the permissions are all set to root so we can not write anything there.

Since it looks like we are not able to place any file with shell code on the target system and execute it over the web server we try to encode our commands with base64 to hide the usage of IPs and to create a direct connection from the target system back to the attacking machine.

12. Running echo base64string | base64 -d | bash over the web server CLI to get the base64 payload executed

Once we have access on the box we can search for the typical privilege escalation mechanisms like scheduled tasks, bad configurations, old software versions and other topics.

When searching for SUID binaries we find a strange looking binary called reset_root.

13. Finding an interesting binary called reset_root

When executing the binary on the target system itself it starts but it looks like it is missing some requirements and thus stops before resetting the root password.

To look deeper inside the binary itself we copy it over to our attacking machine.

Once we have the binary on our local system we can take a closer look at it by using a tool called ltrace. It intercepts and records dynamic library calls which are called by the executed process and the signals which are received by that process. It can also intercept and print the system calls executed by the program. ltrace shows parameters of invoked functions and system calls (link).

15. Checking the reset_root binary to identify possible requirements for the code to run

Since the program is checking for the existence of three files as shown in figure 15 we use the following commands on the target system over our existing remote shell.

touch /dev/shm/kHgTFI5G
touch /dev/shm/Zw7bV9U5
touch /tmp/kcM0Wewe

Afterwards we are able to run the reset_root binary on the target machine and since all requirements are in place the code gets executed and the root password gets reset. With this we are able to get root privileges.

Once gained access to a system there are multiple ways to achieve persistence. Using things like scheduled tasks, placing binaries into the windows startup folder or using the Run directory within the Registry are easy to use, but have the downside of being easily detected. Another method to achieve persistence (and sometimes even privilege escalation) is to use DLL Hijacking which is harder to find by an analyst or AV, since it is dependent on something else that is running on the system and has a lot more variables on where the malicious code could be located on an endpoint.

But how to find processes that are vulnerable to DLL Hijacking?

One common way to identify processes that might be vulnerable to DLL Hijacking is to use Process Monitor by Sysinternals (ProcMon) and to search for processes that are trying to read .dll files which they are not able to find.

To make this easier filters can be applied like:

Path contains .dll
Operation equals CreateFile
Result equals NAME NOT FOUND

1. Using ProcMon with filters to identify possible vulnerable processes

Every time a process calls a .dll it tries to locate it by searching in the current working directory. If not found there, depending on the process, it will search for that file inside all entries of the PATH variable (cmd.exe /c echo %PATH%).

In case a process tries to locate a .dll and it is not able to find it, there is a chance to provide a .dll inside the working directory of the process or within a location of the PATH variable so that the process uses the custom .dll.

Sometimes a process will find the intended .dll eventually within a later entry of the PATH variable. If it is possible to write to any directory displayed inside the PATH variable before the entry with the intended file (or the current working directory of the process) the custom .dll can be placed there and would be used by the process due to the decreasing priority of entries within the PATH variable.

But there are also .dll files that can not be hijacked. One example are the so called Known DLLs, since they will always be loaded out of the system32 directory. Some of them can be found within the Registry as shown below.

The downside of using plain DLL Hijacking is that if the process that calls the .dll needs the content to function properly, it can become stuck or error out since it is no longer calling the functions within the correct .dll. This could be enough to give away that there is something malicious going on.

One way to prevent this is to use DLL Proxying – where the custom created .dll would proxy any function calls that are not implemented inside the custom .dll to the original intended dll. This way the process wont lose its needed functions and wont become stuck or error out as easily.
More about this can be found for example here.

After identifying a possible vulnerable process – as shown in figure 1 – it is time to place a custom .dll. For testing purposes the below code can be used to create a .dll file that displays a simple error message box.

#include <windows.h>

BOOL WINAPI
DllMain (HANDLE hDll, DWORD dwReason, LPVOID lpReserved)
{
   switch (dwReason)
   {
      case DLL_PROCESS_ATTACH:
         MessageBox(NULL,”DLL executed”,”This could be Malware!”,MB_ICONERROR | MB_OK);
      break;
   }
return TRUE;
}

3. Use the above code stored inside a .c file and build the .dll

Another example could be to use Msfvenom to create a .dll file with a meterpreter payload. After building the .dll file it can then be stored on the target system.

4. Place the CRYPTSP.dll file (name & location from 1st image)

Afterwards the process needs to be triggered to call on the .dll file. In this case a simple startup of the application is all that is needed.

5. Run the hijacked process / trigger the .dll call

The process starts and tries to read the CRYPTSP.dll as shown in the first image – but this time it actually loads the custom made .dll file. While this .dll is for testing purposes only, the application stops loading until the error message box gets closed. In a real world scenario the malicious process would of course just be executed in the background without notice of the end user.

6. After closing the message box – NPP is running normally

Tested with Notepad++ version 8.1.9.

Author: Cordian

VulnHub – Earth

Exploring DLL-Hijacking