Introduction

About a month ago, a group called the Shadow Brokers claimed to have stolen a number of cyber espionage tools from the Equation Group. They made a number of the files available to prove the validity of their claim and are attempting to auction the remaining tools. Since then, a number of researchers have analyzed the files and determined that a number of zero day vulnerabilities could be exploited by some of the tools. A summary of some of the research results can be seen here.

This blog post provides an analysis of a pair of executables located in the TOOLS directory: false.exe and morel.exe. The executables appear to be complimentary because a single documentation file within the free file dump explains how to use both executables. false.exe appears to be an executable that can be used to gather information and morel.exe allows the end user to send commands to the remote device.

Please note: I don’t have access to a Cisco Pix, so I wasn’t able to verify the use of either executable using a Cisco device. Instead, I tried to develop a server (in python) that would simulate a Cisco device. During the analysis of the executables, it became pretty clear that the network traffic between the Pix and the client executables was encrypted. I was able to use WinDbg and IDA Pro to reverse engineer the encryption algorithm that was used to communicate with morel.exe. What follows are the results of the analysis.

Documentation

Some documentation for the pair of executables is provided in SCRIPTS/FalseMorel.txt of the Shadow Broker free tar file. The documentation includes the following at the top of the file:

1. Allows deduction of enable password from data freely offered by the firewall.
2. Allows privileged level access, knowing only the hash of the enable password.

Although the documentation states that the enable password can be deduced from data offered by the firewall, the documentation does not describe how to deduce the password or how the data is obtained. I’ll talk about this a little later in this post.

The documentation also states that privileged level access is possible if the hash of the enable password is known.  However, it does not describe how to obtain the hash of the enable password. Since the enable password hash is passed to morel.exe as a command line parameter, the documentation implies that morel.exe is the program that can be used to gain privileged level access to the device.

Finally, the documentation implies that a vulnerable device must accept connections on TCP port 1467. I wasn’t able to find any documentation about this port, so I’m not sure if a Cisco device must be configured to run a specific service in order for the Pix to accept connections on this port. The python server that I wrote uses port 1467 as the listening port even though I wasn’t able to determine why a Cisco device would be listening on this port.

false.exe

false.exe requires an ip address and port as arguments. For example, the command shown below can be used to run false.exe with a target host at IP address 192.168.1.1 and a target TCP port of 1467:

false.exe 192.168.1.1 1467

When the above command is executed, false.exe connects to port 1467, reads the packet payload that is sent by the Cisco device, and then closes the TCP connection. It then repeats this two more times (connects to port 1467, reads packet, then closes TCP connection). The payload is printed to the console in hex format. The help documentation for the executable implies that the enable password will be available in the payload that is read, although I have no way of verifying this. The documentation file does not go into detail about how to determine where the enable password is located within the payload from the 3 TCP sessions.

The figure below shows a packet capture of the traffic generated by false.exe. The target host was running a python script to simulate a Cisco device with a service listening on TCP port 1467. The host at IP address 192.168.1.3 is the host running false.exe, and IP address 192.168.1.1 is the host that simulates the Cisco device. Note that there are three separate TCP sessions in the packet capture. If you look closely, you’ll also see data being sent from the simulated Cisco device, but no data being sent from the host running false.exe.

false.exe displays the information received from the TCP sessions in hexadecimal format, as shown in the figure below.

Since false.exe appears to be the information gathering program of the pair, the information provided by the Cisco device may be the information required to “deduce” the enable password. However, since I don’t have access to a Cisco Pix, I wasn’t able to get much further in the analysis of how false.exe could be used to deduce the password.

morel.exe

If the end user knows the enable password hash of the Cisco device, he/she can use morel.exe to gain privileged access to the device. An example usage of morel.exe is shown below:

morel.exe -d 500 enable_hash 192.168.1.1 1467

morel.exe basically creates a command shell. It decrypts the payload received from the Cisco device, and allows the end user to type in a plain text command. The command input by the end user is then encrypted using the same algorithm that was used to decrypt the payload received from the remote device. The enable password hash is required because it is used to encrypt the traffic between the Cisco device and the morel.exe client.

The enable password hash must be 16 bytes in length. If not, morel.exe will display a cryptic error message.

morel.exe encryption

When morel.exe is executed, the Cisco device responds with a payload in the following format:

| 4 byte header | 4 byte seed | 4 byte payload length | encrypted payload |

The 4 byte header can be further broken down as shown below:

| 0xc0 | 0x00 | seq number | 0x00 |

Note that the values at offsets 0, 1, and 3 appear to be hard coded values. The value at offset 2 is a sequence number. If the entire encrypted payload cannot fit into a single packet, the seq number appears to be incremented in each packet.

When the packet is received by the client running morel.exe, the following steps are performed to decrypt the payload:

• A 22 byte plaintext string is created by concatenating the following:

4 byte seed + 16 byte enable password hash + 0xc0 +  1 byte sequence number

• The md5 hash is computed on the above string
• Each byte in the payload is xor’ed with the computed MD5 hash:

plaintext[0] = encrypted_payload[0] ^ md5[0]
plaintext[1] = encrypted_payload[1] ^ md5[1] 
plaintext[2] = encrypted_payload[2] ^ md5[2]
…
plaintext[15] = encrypted_payload[15] ^ md5[15]

• If the payload is longer than 16 bytes, the MD5 hash that is used to compute the next 16 bytes is recomputed using the following string:

4 byte seed + 16 byte enable password hash + 0xc0 + 1 byte sequence number + md5 hash used to encrypt/decrypt previous block

Running morel.exe

The python script that was used to simulate a Cisco Pix was configured to use an enabled password hash of “abcdabcdabcdabcd”, a seed value of “seed”, and to send a command prompt of cisco pix> to the morel.exe client. The packet capture below shows the encrypted payload sent by the python script. Note that the string “cisco pix>” does not appear in the payload.

Even though the payload was encrypted, the command window used to run morel.exe shows the decrypted prompt, cisco pix>.

The command “sho ver” was typed as a command at the cisco pix> prompt. After the command was entered, seven ^ symbols were displayed, one at a time. For some reason, each letter in the command was transmitted in a separate network packet. The ^ symbol was displayed as the packets were transmitted. Note that there were eight network packets transmitted because a newline character was sent in addition to the seven letters in “sho ver”.

Once the command completes, the python server resends the “cisco pix>” prompt, and the prompt is displayed on the client. Presumably, if connected to an actual Cisco device, the Cisco device would execute the command and transmit a response to the client. morel.exe would then decrypt the response and display it.

Each of the network packets sent by morel.exe contains 13 bytes of data. Recall from the section above describing morel’s encryption that a 4 byte header + a 4 byte seed + 4 byte payload length was sent in addition to the encrypted payload. Therefore, each packet contains 13 bytes. Although no figure is provided, the 1 byte payload sent in each packet was encrypted.

The script that simulates the Cisco device will echo the decrypted command once it receives a newline character. The output after receiving the “sho ver” command is shown below.

One final curious thing about morel.exe: when trying to send the full Cisco command “show version” an error occurred. So, there may be some sort of limit to the length of commands that can be sent with this executable.

Revisiting the Information Provided By false.exe

Recall that the encryption algorithm computes the MD5 hash of the following string:

4 byte seed + 16 byte enable password hash + 0xc0 + 1 byte sequence number

The seed value occupies the 4 bytes starting at offset 4 of the initial payload received from the server. This seed is probably randomly generated each time a TCP session is established. The hash of this string is then used as a byte stream to encrypt the payload sent to and from the server.

If the seed is randomly generated, it may offer a clue as to why false.exe creates 3 separate TCP sessions and dumps the output for each session. The payload that is received by false.exe is described as a “banner” in the FalseMorel documentation. The “banner” is probably the same for each TCP session that is established with the Cisco device. But, if a different seed is used for each TCP session, the encrypted payload will be different for each session. At this point, we have the same payload encrypted using three different keys. We know the seed and the sequence number used to generate the key because they are provided unencrypted as part of the payload. But, we do not know the enable password hash because it is not transmitted.

Unfortunately, I’m not an expert in crypto attacks, so at this point I’m a bit stumped. I’m not sure if its possible to use this information, along with knowledge of the encryption algorithm to deduce anything meaningful from the data produced by false,exe.

Conclusion

Since I don’t have access to a Cisco Pix, there are a lot of holes in the analysis of these two executables. However, since a python script could be used to communicate with morel.exe, it looks like at least the algorithm used to encrypt traffic generated by this service has been deciphered. A copy of the script that was used is shown in the figures below.