Days ago, a mysterious online group called Shadow Brokers claims to have stolen US “cyber weapons” from a hacking team called Equation Group. These “cyber weapons” contain about a dozen vulnerabilities which are believed to be exploits used by the National Security Agency (NSA). In this blog, I will analyze the shellcode from the Cisco exploit and show its behind-the-scenes behavior.
Shellcode is a piece of code which gets executed after a vulnerability is exploited. It is the actual instructions attackers want to run on the victim’s machine. Shellcode here comes from the Cisco SNMP exploit (CVE-2016-6366). Under this leaked exploit of Cisco ASA, there is a folder containing the shellcodes for all listed versions. The version used in this blog is 8.2.1.
“bfa5a5a5a5b8d8a5a5a531f8bba5a581ac31fbb9a5b5a5a531f9baa2a5a5a531fa cd80eb14bff00e240931c9b104fcf3a4e90c0000005eebece8f8ffffff31c040c3” + “bfa5a5a5a5b8d8a5a5a531f8bba575a3ad31fbb9a5b5a5a531f9baa2a5a5a531 facd80eb14bf10d7060831c9b104fcf3a4e90c0000005eebece8f8ffffff31c040c3c3”
These hex values are very hard to read so we need to disassemble them into assembly language. The second line is shown below.
On Linux system (Cisco ASA is based on Linux), int 0x80 indicates a system call with the arguments stored in eax,ebx,ecx,edx. In the second line of the shellcode, the section from offset 0x0 to 0x21 makes a system call with eax=0x7d,ebx= 0x806d000,ecx=0x 1000,edx= 0x7. When making a system call, eax is used to point which system call is being called. 0x7d in Linux is the system call “sys_mprotect”.
“sys_mprotect” changes protection for the calling process’s memory page. In this case, the shellcode changes the permission of the process address 0x806d000+0x1000 to 0x7 which is RWX.
The rest of this shellcode simply writes hex string “31C040C3” to the address 0x806d710. This address has been set writable by the system call “sys_mprotect”. There is one small trick at offset 0x39 which is a call instruction. Call instruction will push the address of next instruction (31C040C3’s address in this case) into ESP. Then the shellcode pops that address into ESI which is used later. This trick enables the attackers to do a “memcpy” without knowing the source address.
The first line of the shellcode writes hex string “31C040C3” onto the address 0x9240ef0. My guess is that line 1 of the shellcode can be used to encrypt line 2 to bypass IDS detection. In my test even after setting all of line 1 to nop (no operation) the exploit worked perfectly.
Bypassing IDS Detection When Changing Permissions
I have seen a lot of IDS detection rules like “content:”|bf a5 a5 a5 a5 b8 d8 a5 a5 a5 31 f8 bb a5|”. This kind of IDS rules tries to match the “sys_mprotect” part but this won’t work at all. Attackers have unlimited ways to set eax to 0x7d. For example XOR 0x7d with 0x00 is 0x7d or just mov eax,0x7d. In fact, I don’t think pattern-based IDSes will catch the exploit because attackers can change all the hex values to another completely different content, achieving the same effect.
Every version of CISCO ASA’s firmware has a similar address to 0x806d710. It’s 0x806dd30 on version 8.3.1 and 0x8083890 on version 8.4.1. I call these addresses “the magic bytes”.
The Magic Bytes
What’s the magic part of these “magic bytes”? First of all, as mentioned in our earlier ThreatPROTECT blog post, they enable attackers to log in with any username and password with the highest privilege level.
This is typical of other known exploits allegedly created by the NSA, and indicates the same organization may have created this. It’s very similar to the Juniper ScreenOS backdoor last year. The backdoor password “<<< %s(un=’%s’) = %u” allows attackers to log into the device with any username. But our “magic bytes” is far better than that.
Cisco provides an administrator client tool called Cisco ASDM. This tool is used to monitor Cisco ASA devices with a very good GUI. By using this tool, administrators can monitor how many people are currently on the system and what access method, like SSH or ASDM, they are using.
As you can see in the screenshot there is currently one connection beside this ASDM session under the “Currently Connected Secure Shell Session”. The tool will give out the client’s IP address, username and SID.
After the “magic bytes” is set, anyone can log in with any username and password. Can the administrator monitor this and know someone is hacking the device?
I bet you can see some of the magic part of “magic bytes” now because the answer is no — the user of this exploit is “magically” invisible to ASDM.
The Cisco provided tool also has another feature which can let administrators track how many SSH/Telnet request the device received and accepted.
If the attackers set the “magic bytes” and ssh to the device, the administrator should see this event at least.
Well, actually the administrator doesn’t because of the “magic bytes.”
After I logged out from ssh and restored the “magic bytes,” there are no authentication requests recorded in the admin console. It’s as if no one logged in. Other features of the ASDM client work properly when the “magic bytes” are set, but not the logs. Not only that, but you can’t enable the logging after the “magic bytes” is set. That level of stealthiness is a hallmark of alleged NSA exploits.
I don’t think attackers need a better address in Cisco firmware than these “magic bytes” — there’s no need to remember the hardcoded long password like in Juniper ScreenOS, and this is completely untraceable. It made their job much easier after Cisco accidentally put so many features in one location. When people are talking about the buffer overflow 0 day, I think we need to worry more about these magic bytes because setting these magic bytes will be the first thing they want to do after exploiting the next Cisco vulnerability.
Cisco has released a patch for the ASA 0-day exposed by the Shadow Brokers leaks. That will fix the SNMP 0-day attack vector. But behind the scenes, I don’t know if they also fixed these “magic bytes.” Without a working vulnerability there is no easy way to trigger the ‘magic bytes’ which stops logging of ssh and telnet sessions along with other monitoring features.