Analysing CVE-2018-13417 for files, hashes and shells.

CVE-2018-13417 was released this August that disclosed an out-of-band XXE vulnerability in the SSDP/UPnP functionality of the XML parsing engine in the popular Vuze Bittorrent client. The latest version, 5.7.6.0 was found to be vulnerable however it’s likely earlier versions are also affected. Exploitation of this vulnerability allows unauthenticated attackers on the same network to read arbitrary files (within the permissions of whatever Vuze is running as) or to start SMB connections which can be used to capture NTLMv1/v2 hashes as well as relay the challenge/response for remote code execution (assuming a privileged user).

Let’s get stuck in…

Our Victim

A Windows 10 Enterprise box with a fresh installation of Vuze. Our victim’s IP is 192.168.1.83.

The Attacker

A Kali box with an IP of 192.168.1.93 running evil-ssdp, a tool that can spoof SSDP replies, create fake UPnP devices and detect XXE vulnerabilities in UPnP enabled applications.

Background & Setup

Whenever Vuze tries to discover other devices on a local network, SSDP sends a UDP multicast packet to 239.255.255.250 on port 1900. This allows Vuze to find UPnP devices. The attacker, however, can reply to these packets using a tool like evil-ssdp, telling the client that they have a shared device called a Device Descriptor.

Vuze then parses the crafted XML content of the Device Descriptor over HTTP (which is normal behaviour for SSDP/UPnP), resulting in potentially files, hashes or shells for the attacker. For this example we’re going to execute an XXE attack that will trigger an SMB connection, allowing us to capture the hash from the challenge/response.

By default evil-ssdp spawns a web server and the Device Descriptor is hosted at the following URL:

http://<Attacker_IP>:8888/ssdp/device-desc.xml

The device-desc.xml path pulls data from the device.xml file in the /tempates/xxe-smb folder shown below and evil-ssdp has already helpfully pre-populated the XXE attack that will invoke an SMB connection for us.

A final test ensures that we are requesting the expected XML data, noting that the $smbServer placeholder now shows our attacking IP address.

All good to go. We fire off evil-ssdp and Responder first, followed by Vuze on our victim’s box, as show below. Within seconds the victim’s NTLMv2 hash is caught by Responder, the victim unaware of anything. evil-ssdp also displays a nice [XXE VULN! ! ! !] warning (because just [XXE VULN] by itself wouldn’t have been dramatic enough ???? ). The attacker can now attempt to crack the hash offline.

Behind The Scenes

Let’s look at the traffic.

The first packet is Vuze multicasting a UDP packet via SSDP and the second packet is evil-ssdp responding, informing the client of the location of the crafted Device Descriptor.

A 3-way TCP handshake is then carried out, after which an HTTP GET request is made by the client for the Device Descriptor.

An SMB connection is then initiated by the client and after negotiating and agreeing the SMB version, the client finally sends the NTLMv2 hash across to the attacker where Responder catches it.

Additional Vectors

Of the “files, hashes and shells” post title we only covered hashes, however the hashes of privileged users (depending on the environment) could be relayed to obtain shells on other local systems if SMB signing is disabled (SMB signing is only enabled out of the box on domain controllers). In addition to this, knowledge of local files on the victim box could allow for data exfiltration via XXE using common XXE PoC code.

evil-ssdp has template files containing pre-written code for data exfiltration as well as phishing setups including, but not limited to Office365, Azure and Bitcoin, so make sure you check it out and add this cool tool to your arsenal. Happy hacking guys!