Fuzzing for Domain Admin

Last week Enrique Nissim of Core Security published an article called Analysis of a Remote Code Execution Vulnerability on Fortinet Single Sign On.  Lately I’ve been using Deva Vu Security’s excellent Peach Fuzzer to find vulnerabilities, and I wanted to see how easy this would be to reproduce.

First, I installed Wireshark, Windbg, Peach 3 and FSSO 4.3.143 onto a Windows 2008 R2 server VM.  While Windows 2008 R2 is 64-bit only, FSSO is always 32-bit, which should make writing the exploit simpler.  Next, I loaded up a FortiGate VM and configured FSSO according to the documentation.  All Fortinet products can be downloaded and trialed for 14-days which makes vulnerability hunting a breeze, although you will have to set up an account first.

As indicated by Enrique’s article, FSSO communicates via TCP port 8000.  A Wireshark capture shows the structure of the hello packet:


The capture shows the packet format as follows:

  • A packet header, comprised of 32-bit big endian size field of the whole payload including the size field, a tag value of 80, and a type value of 06.  These tag and type value correspond to a hello packet.
  • TLV-like structures, with the same size, tag, type and value structures.
  • TLVs for version, serial number and an MD5 authentication hash.

Peach fuzzer uses XML to describe how to fuzz a target.  The portion of the XML that describes the packet format is the data model.  Other sections include a state model, which describes stateful protocols (we’re only fuzzing the hello packet), an agent, which describes how to instrument the target, and a test, which describes how to interface with the target.  The full Peach Pit can be found on github.

Running the Peach Pit is simple.  I’ve installed Peach into the directory c:\peach on the Windows 2008 R2 VM.  You can start fuzzing by copying the Pit to the peach directory and running “peach.exe fsso.xml”.

After only 41 fuzz runs, I obtained the following crash:

(13f8.e54): Access violation - code c0000005 (first chance)
eax=fffffffe ebx=00000658 ecx=75e898da edx=1c781104 esi=ffffffff edi=1c7e2ce8
eip=41414141 esp=1cbbfe1c ebp=00000000 iopl=0         nv up ei pl nz ac pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010216
41414141 ??              ???

Textbook stack buffer overflow.  To make the situation worse, two modules in the FSSO service do not use ASLR:


So we know we can get 0x41414141, and we know we have at least two modules that do not have ASLR enabled, and one of them contains address values with no nulls, which is perfect for a ROP chain.

FSSO usually runs as domain administrator.  If we’re able to exploit this service we effectively have control over the entire network.  While Fortinet might not be a common household name like Cisco or Microsoft, Fortinet has sold over a million firewalls and FSSO is widely deployed.  It is also quite likely that there are other vulnerabilities in this service, such as the DCAgent protocol running on UDP port 8002 (which is also enabled by default).  Next week I’ll demonstrate how to build a working Metasploit module for this vulnerability, and we’ll try some fuzzing of the DCAgent protocol.

Universal Plug and Fuzz

Earlier this week I bought a Belkin Netcam HD web camera.  It’s probably the most insecure device I ever tested, or even heard about. With the firmware that comes pre-loaded, the telnet service is wide open as root. There’s also an undocumented web interface. The default password is admin:admin, and it’s hard coded.  This means that regardless of how the user sets the device up, an attacker can simply browse to /apcam/apcam/jsstream.asp and watch the video stream.

These issues were reported to Belkin and are fixed in the latest firmware. In the new firmware release, the web administration pages are gone and telnet is disabled. There may be some vulnerabilities left there, but I decided to look at another vector instead: Universal Plug and Play. Belkin WeMo devices are controlled by UPnP, and it appears that the Netcam supports the full WeMo UPnP API.  This makes the attack surface fairly large and manual fuzzing a bit cumbersome.

UFuzzlogoWith that in mind, I’ve created a new UPnP enumeration and fuzzing framework, called UFuzz (Universal Plug and Fuzz). Since the readme in the github repo is pretty short, this seems like a good time to see how UFuzz works.

In order to fuzz the Belkin Netcam, simply configure the device to connect to your wireless network, and issue the follow command to start UFuzz:

./ufuzz -u -v 4

The -u option starts UPnP mode, and the “-v 4” option changes the verbosity to TRACE. This allows us to see the requests and response summaries during fuzzing.

When UFuzz starts, it will broadcast an MSEARCH via UDP to discover all of the devices on the subnet. It will then download and parse of the XML service description files. Next, template requests will be created for each service accessible via UPnP. It’s a bit dumb right now, so it just uses “1” as the default value for each parameter (though you’re welcome to make it smarter).

Finally, it iterates through each parameter using different fuzz values to produce a fault. A fault in UFuzz can be excessive time delay, as is the case for command injection and blind SQL injection payloads, or the target can be instrumented via telnet, serial or syslog to detect exploitable crashes.  Some example modules have been included for telnet and serial monitors.

I should mention that UFuzz isn’t just a one trick pony. It can also fuzz Burp proxy logs. This raises the obvious question — Why not just use Burp to detect these issues? Burp is a fantastic web security scanner, but it doesn’t detect a lot of issues specific to embedded systems. For example, if I send a long string of A’s to a specific parameter, it could cause a buffer overflow in the HTTP server or another binary that the HTTP server calls. The server might even answer with a “200 OK” in certain scenarios. By instrumenting the system, we can check logs or serial output for strings like “SIGSEGV” and log appropriately.

In the time it’s taken to write the above paragraphs, UFuzz has found another bug in the Belkin Netcam:

[2014-04-04T16:13:43-07:00 EVENT DETECTED] cmd injection - possible cmd injection - "`ping -c 10`": delay 9.18

Turns out that’s not a false positive. You can try it out yourself with this Metasploit module. I should also mention — it’s quite possible this affects all Belkin WeMo devices. If someone has a WeMo switch, please try it and let me know.

Until next time, happy bug hunting!