Introduction

In August 2016 a near-complete exploit kit targeting all major firewall manufacturers was released by a group known as the ShadowBrokers. This exploit kit has been widely attributed as belonging to a group in the NSA known as the Tailored Access Operations Unit (also commonly referred to as "The Equation Group”). There has been plenty of research on pieces of this exploit kit, but very little on the full exploit chain. We were interested in studying some of the command and control traffic used by this exploit kit for emulation in BreakingPoint. On the way, we figured out how a lot of the puzzle pieces fit together. What follows are our findings on how this kit gains persistent control of a Cisco firewall. We also identify some of the missing pieces that were not previously available.

Step 1: EXTRABACON

The first step is to gain access to the Firewall. EXTRABACON ( CVE-2016-6366 ) leverages an overflow in the SNMP daemon on the Cisco ASA and PIX firewalls. The exploit enables and disables the password-checking functions of the firewall. By removing the password, access can now be granted to the firewall to any remote user. The exploit code targets only certain ASA versions, but it is relatively easy to readjust the exploit for other versions of software. Here's what it looks like in action:

Img1. Cisco ASA getting BACON-ed.

It worked flawlessly with our ASA. We did not modify the code to test the PIX, but based on Cisco's advisory, the flaw exists on that platform as well.

Step 2: EPICBANANA

Once you have set the password to nothing, EPICBANANA (CVE-2016-6367) is the next tool of choice. EPICBANANA exploits a local command line buffer overflow. It plants command and control shellcode into the PIX/ASA firewall. Each vulnerable version has two shellcode types contained in the exploit package; one is a "test message" NOP sled, the other is referenced as "BM".

NOP

When the nop option is used, the shellcode is simply a large section of NOPs (\x90) followed by an interrupt request. This shellcode makes the console print out the message “!!! SUCCESS !!!”.

Img2: Shellcode printing out !!! Success !!!

BM

When specifying the BM payload option, the script goes through a similar set of operations. However, instead of seeing a success message print out on the console of the target, it simply logs that a buffer overflow occurred. On the attacker side the script sends an escape code \x10 and checks to see if the response is the string mtu. If it is, it reports back that the exploit has worked successfully.

Img3: Shellcode loading BM module

Img4: Checks in exploit code for return values from shellcode injection

We tested this local exploit on both our Cisco ASA and PIX. Both appeared to be exploited correctly without issue for both the NOP and BM payloads. Interestingly, EPICBANANA has been labeled as a privilege escalation exploit and vulnerability, although as we will see below, the exploit code allows much more than enable access to occur.

Step 3: BANALRIDE ("BRIDE") and BANALMONKEY

But then the questions become "What did BM do?" "What does BM stand for?" Looking at some documentation in Firewall/SCRIPTS/EPBA. script, we see that we should be able to use a tool called bride to connect to our firewall and load BANANAGLEE:

Img5: Instructions on EPICBANANA

These instructions show the connection between EPICBANANA, BANALRIDE, and BANANAGLEE. We should be able to communicate with our firewall using BANALRIDE after sending the EPICBANANA exploit, which will then allow us to load BANAGLEE implant code. We first attempted to use BANALRIDE with our ASA firewall, but never managed to elicit a response from the firewall. However, a few weeks later, we found an old Cisco PIX we had in QA. Using the same steps again we managed to get a response from the firewall:

Img6: Using BRIDE

SUCCESS! We have basic CnC packets for examination! The first packet seen is the 'listening post' (aka: the attacker) sending out a 21-byte UDP packet to the firewall when command 1 is executed. If you are playing along at home and see no packets being generated, it is likely that /dev/urandom entropy is low. Bang on the keyboard for a while, and you should get a packet generated.

The first CnC packet looks like this:

Img7: Command and Control Initial Send

This first byte is always 0xA8. That leaves 20 bytes of payload. Those bytes are always "random" with each request. The response to the challenge is the follow 17 bytes:

Img8: Command and Control response

The first byte of the response is always 0xA9, which is followed by 16 bytes of random payload.

Considering the console output and 128-bit number, the two packets are most likely sending 128-bit keys to each other using Diffie-Hellman. The additional 4 bytes sent by the CnC listening post to the firewall might be a checksum, nonce, salt, or some other crypto element. Further communication appears to be encrypted completely including the control codes, as no data is repetitious after the initial exchange.

If you are interested in examining the command and control traffic yourself, but don't want to run any exploit code (or don't have the necessary exploitable firewall) you can get this PCAP. It has a connection initialization, downloads 24 bytes of memory located at 0x05e26490 on the PIX, and then disconnects gracefully. The DH key printed out in this example was c4524cf9ca8d15b38926883a8e7784d9.

Some interesting features observed from the command and control data:

Open to scanning/replay attacks The payload generated by BANALRIDE can be played back with netcat to get a response from the firewall The response from implanted firewall is different to the same request. This implies a changing key on firewall.



Source/Destination IP/ports do not impact communication Using netcat to replay the payload above with different source/destination ports still generated a response They might be filtered by firewall policy before being 'handled' by the exploit code Examples in the leak suggest sending/receiving over UDP port 500, but this is probably used to mask the data as IPSec traffic

Five-minute timeout Sending a replayed challenge request only created a response once every five minutes There is a clean "close connection" ability in BRIDE, which allowed immediate reconnection

Packet sizes are predictable for initial handshakes Set your IDS signatures to stun 21 Byte request with \xA8 as first byte 17 Byte response with \xA9 as first byte



Step 4: Implanting BANANAGLEE

It appears that the implant management code (config_implant) was not leaked. It unfortunately seems to be a crucial step to build the BANANAGLEE implant code to be injected with BANALRIDE:

Img9: config_implant is mentioned in a lot of places

The assumption is that config_implant will build a device-specific binary implant to provide command and control capabilities for your Cisco ASA/PIX and Juniper SRX firewalls. It also looks like config_implant keys the implant code to be mission specific, so that it will not respond to other attempts to communicate. Some of the implant modules for BANANAGLEE are included. Many of them are located at /Fire wall/BANANAGLEE/BG2200/Install/LP/Modules/PIX. In it are a variety of ".mod" files that contain XML attributes describing what each module supports.

For example, here are the contents of BBALL_AM29FA-2201.mod:

Img10: Example of a BANANAGLEE module

List of modules available

Here is a full list of available modules for use with BANANAGLEE:

BBALL_*.mod: Read and Write to Firewall's BIOS

BCANDY-2201.mod: Start a console session

BFLEA-2201.mod: Read and Write to Flash Memory

BMASSACRE-2201.mod: Packet Toolkit. Control Firewall rules table, copy packets to a third destinations

BPATROL-2201.mod: Packet Capture

BPIE-2201.mod: IPv4 Profiler

IVL-5000-6-2201.mod: Unknown

SecondDate-2211.mod: Unknown

Step 5: Persist with JETPLOW and SCREAMPLOW

From studying the NSA ANT catalogue, BANANAGLEE, if implanted, is only temporary (a reboot clears it). If a user wants to make the implant permanent, they need to install JETPLOW or SCREAMPLOW. The steps to install SCREAMPLOW are listed in /Firewall/SCRIPTS/screamplow-INSTALL.txt.

Img11: Using the Listening Post

We need to use the lp command (which is located in many places) with a key file. Luckily, a key file was left in the dump, located at /FIREWALL/BANANAGLEE/BG2100/Install/JP/temp.key. Using this key allows us to cause the listening post code to send out packets for analysis.

Running the following command, gets us into the lp binary:

Img12: Listening Post available commands

And when we run option 1 (Open Session with firewall), we get packets that look like this:

Img13: Listening Post packets produce no response

44 Bytes of seemingly meaningless gibberish and no response from our FW. It appears that the BANANAGLEE loading step with a keyed image is crucial to leverage JETPLOW and advanced Listening Post toolkits.

What Were Those Code Words Again?

Trying to remember all of the code words that are in use can be difficult, so I came up with this handy reference guide:

EXTRABACON

Vulnerability Exploited: SNMP Buffer Overflow.

What it does: Turns command line password on or off.

EPICBANANA

Vulnerability Exploited: Local Buffer Overflow on command line.

What it does: Embeds BANALMONKEY command and control code.

BANALMONKEY

Vulnerability Exploited: None.

What it does: Provides raw memory access and secondary stage loading.

BANALRIDE

Vulnerability Exploited: None.

What it does: Communicates with BANALMONKEY. Provides mechanism for loading BANANAGLEE or other payloads.

BANANAGLEE

Vulnerability Exploited: None.

What it does: Advanced command and control code to operate firewalls. Redirection of traffic, duplication of traffic, filtering.

JETPLOW

Vulnerability Exploited: None.

What it does: Provides persistent BANANAGLEE between reboots.

And the exploit chain:

EXTRABACON (REMOVE PASSWORD) EPIC BANANA (LOADS) BANALMONKEY (CONTROLLED BY) BANALRIDE (INSTALLS) BANANAGLEE (PERSISTED BY) JETPLOW (CONTROL)

How Do I Test My Defenses?

Now that the kit is leaked, access to it is available widely. We've already included the exploits as strikes when they were released last month, so your IPS and firewall testing with BreakingPoint should have coverage. We are currently working on a complete simulation of this exploit chain. This can be used for cyber range readiness testing, IPS testing, netflow analysis tools, etc. We'll cover as much of the command and control traffic as we can, along with the exploits gaining access. Look for them soon in one of the next ATI updates.

Leverage Subscription Service to Stay Ahead of Attacks

The Ixia BreakingPoint Application and Threat Intelligence (ATI) Subscription provides bi-weekly updates of the latest application protocols and attacks for use with Ixia platforms.