On August 13, a previously unknown organization named the “Shadow Brokers” released files claiming to be tools used by the hacking organization named the “Equation Group”. Kaspersky dubbed this name for the organization in February of 2015, when they released a report about one of the most sophisticated hacking organizations they had ever seen. Though Kaspersky has never attributed the Equation Group to the United States National Security Agency itself, the security community at large has found various similarities between their findings and previously leaked documents attributed to the NSA.
The files released by the Shadow Brokers date back to 2013, and appear to be actual tools used by the Equation Group itself. The leaked files represent zero-day exploits and software implants for several popular firewall vendors, allowing the Equation Group to gain a foothold within an organization through the very devices meant to protect them.
After performing our own analysis, as well as researching various open source and social media outlets about the Shadow Brokers leak, we have summarized the various exploits and techniques used to show what an enterprise should do to protect itself. Even if these specific examples do not work on the devices in your own network, there are several security best practices everyone can learn from. There is no question software vulnerabilities and misconfigurations will continue to be a problem, even in security solutions. Proper network and security architecture decisions, as well as common best practices, can help minimize the risk against these types of attacks.
Exploits and Implants
The Equation Group leak contains several zero-day exploits for various firewall vendors outlined in the table below. In most cases, the goal of these exploits was to gain privileged access and remote code execution on a firewall. Once a firewall had been exploited, the Equation Group installed backdoors using various software “implants.” The leak contained code or reference to implants for various firewall vendors such as Cisco, Juniper, Fortinet, Huawei, and TopSec. These implants, with odd sounding names such as BANANAGLEE and BLASTING, typically allowed backdoor access to the firewall and in some cases were made persistent by modifying the BIOS, the lowest software layer of the firewall. Once they had persistent access, various modules were included within the implants to perform different tasks on the firewall. For example, one module called the “Profiler” allowed the Equation Group to capture raw packets of the traffic passing through the firewall. Tools like DURABLENAPKIN and SECONDDATE allowed the attackers to inject arbitrary packets within the network, redirecting web requests and leading to “man in the middle”-style attacks within the enterprise network. As it turns out, SECONDDATE was referenced in several recently published leaked documents from 2013.
|Exploit Name||Description||CVE||Affected Vendor|
|EXTRABACON||SNMP Remote Code Execution Vulnerability and Authentication Bypass||CVE-2016-6366||Cisco (advisory)|
|EPICBANANA||CLI Vulnerability Resulting in Privilege Escalation and Code Execution||CVE-2016-6367||Cisco (advisory)|
|BENIGNCERTAIN||Remote IKE Vulnerability Leading to VPN Key Extraction||N/A||Cisco PIX (response)|
|FALSEMOREL||Deduction of Firewall Enable Password||N/A||Cisco PIX|
|EGREGIOUSBLUNDER||Authentication Cookie Parser Vulnerability Leading to Remote Code Execution||CVE-2016-6909||Fortinet (advisory)|
|ESCALATEPLOWMAN||Ifconfig CLI Command Injection Vulnerability||CVE-2016-7089||WatchGuard RapidStream (advisory)|
|ELIGIBLECANDIDATE||Web-Based Exploit Against Cookie Handling Leading to Remote Code Execution||N/A||TopSec|
|ELIGIBLEBOMSHELL||Remote Code Execution via HTTP Cookie Injection Vulnerability||N/A||TopSec|
|ELIGIBLEBACHELOR||Unknown Exploit Against Port TCP/4000||N/A||TopSec|
|ELIGIBLECONTESTANT||Authentication Cookie Parser Vulnerability Leading to Remote Code Execution||N/A||TopSec|
One of the most interesting exploits, BENIGNCERTAIN, is a remote exploit allowing an attacker to send maliciously crafted packets to Cisco PIX devices on port UDP/500 (IKE-VPN), which leads to the extraction of private VPN keys. Not only would this potentially allow decryption of VPN traffic, but also VPN access to the internal network of a target.
Though this is not documented in the leak itself, we believe the various exploits were most likely used together in order to gain privileged access to a firewall. For example, the BENIGNCERTAIN exploit allows an attacker to remotely obtain a VPN credential and access an internal enterprise network using this VPN key. Once inside the internal network, EXTRABACON can be used against the (typically internal) SNMP interface to access the firewall through SSH or Telnet without entering a valid username or password. The attacker still requires the “enable” password to perform most privileged tasks, which leads to the FALSEMOREL exploit, allowing the attacker to deduce the enable password by knowing only the hash of the enable password. In this case, the attacker could have used three different exploits to obtain privileged access to the firewall and can proceed to maintain persistent access through the installation of a persistent backdoor.
Traffic Increases Due to Release
Level 3 Threat Research Labs has been monitoring traffic increases potentially related to the Shadow Brokers leak. In general, as security researchers have released their findings about the various exploits, we have seen increases in traffic and scanning on the various ports mentioned in the released files.
The EXTRABACON exploit requires access to SNMP, which typically uses port UDP/161 by default for inbound connections. The graphic above shows traffic within our network for port UDP/161 began increasing on the date of the Shadow Brokers release and peaked when a blog post was released demoing the exploit itself. We believe the traffic increase is due to scanning or exploitation attempts on devices with port UDP/161 open on their publically facing interface. In fact, a security researcher saw exploitation attempts soon after deploying Cisco’s IPS signature around the same time. The small spike on August 23 most likely corresponds to a public announcement that the exploit was ported to a newer Cisco ASA firewall version.
One of the tools frequently referenced and included in the file dump is NOPEN. NOPEN appears to be a post-exploitation tool used to create an encrypted tunnel (using redirection to hide the source) from the attacker to the target device with shell access. Security researchers, and our own analysis of one of the leaked files, shows the NOPEN server uses a default port TCP/32754 on the target device if no argument is supplied. We saw a large 549 percent increase in traffic, most likely scanning activity, around August 16, when this information was heavily publicized.
ELIGIBLEBACHELOR exploits a previously undisclosed vulnerability on port TCP/4000 for TopSec firewalls. Researchers began discussing this exploit on August 15, and we see a corresponding 230 percent increase in TCP SYN traffic on August 17. Interestingly enough, we do not see a significant increase in general port TCP/4000 traffic, though the number of packets are slightly higher around August 17. If most port TCP/4000 traffic is related to enterprise networks protected by TopSec firewalls, the cyclical nature of the packet counts would make sense. The days corresponding to small packet counts are Saturdays and Sundays, when employees are most likely not working.
Detailed information about the BENIGNCERTAIN exploit and VPN key extraction technique was reported on August 18. Around August 20, we see a 25 percent increase in traffic targeting port UDP/500, the default port for the IKE VPN service in Cisco PIX firewalls. On the graph you can also notice a small increase in traffic, approximately 5 percent, around the initial time of the Shadow Brokers release.
Due to the fact the EGREGIOUSBLUNDER, ELIGIBLECANDIDATE, ELIGIBLEBOMBSHELL and ELIGIBLECONTESTANT all exploited web-based vulnerabilities, we decided to determine if there was an increase in scanning activity on HTTP port TCP/80. In the graph above, we measured the number of packets with only a TCP SYN flag to see if there has been an increase in scanning activity. We see a large increase of SYN packets for HTTP between August 15 and 17, during the initial publicity for these attacks. We believe the previous spike on August 11 corresponds to an unrelated announcement about a TCP traffic hijacking vulnerability in Linux.
Throughout the past few weeks, several affected firewall vendors have released advisories acknowledging the released exploits and implants. Below, we summarize what has been disclosed so far for each vendor.
EXTRABACON, EPICBANANA, BENIGNCERTAIN, and FALSEMOREL all target Cisco PIX firewalls which are considered end-of-life and no longer supported by Cisco. Shodan queries (1, 2) show hundreds of thousands of PIX firewalls may still be in use, even though they reached end-of-life in 2009. Any organization using hardware which is no longer updated and considered end-of-life should migrate to new hardware or appliances.
Cisco reported both EXTRABACON and EPICBANANA affect some versions of more recent Cisco ASA firewalls. Though the latest targeted ASA version in the leaked exploit was 8.4.4, a security research group Silent Signal actually ported the EXTRABACON exploit to a Cisco ASA 9.2.4. Please see Cisco’s two advisories (EXTRABACON advisory, EPICBANANA advisory) to understand which versions of Cisco ASAs are vulnerable and what software release you should upgrade to. In general, software on these types of devices should always be updated and kept current with the latest releases. Cisco also released Snort and IPS signatures to detect the SNMP-based attack.
Based on Fortinet’s advisory, the vulnerability exploited by EGREGIOUSBLUNDER was originally discovered back in 2012. FortiGate products should be upgraded to release 5.x where the vulnerability has previously been patched. Models not compatible with this release should upgrade to 4.3.9.
In their own discussion of the exploits, WatchGuard states the ESCALATEPLOWMAN exploit targeted RapidStream firewalls, a company they acquired in 2002. The vulnerability from RapidStream did not carry over to WatchGuard appliances due to differences in operating systems. As companies phase out their older products, it is imperative to migrate to newer technologies.
Though none of the released exploits targeted Juniper products, some of the implants did target ScreenOS for NetScreen firewalls. Juniper released this statement of confirmation.
Though most of these exploits date back to 2013 and may not affect current generation devices, analyzing the Shadow Brokers leak provides us with many insights about advanced threat actors, and proves proper security practice and architectures can help prevent some of these types of attacks.
- Management interfaces should never be exposed to the internet or general internal networks. In many cases, these exploits targeted interfaces which should only be exposed on a management network. In general, management networks should be isolated as much as possible, potentially having different management networks for different device types or regions. Access to the management network should require strong authentication, such as multi-factor authentication.
- Devices should only allow access to the management interfaces (SSH, Telnet, HTTP, etc.), from specific trusted IPs or hosts. Access to these machines should require strong authentication and follow the principle of least privilege. Ideally, hosts which have access to the management network should not have outbound access to other networks, especially the internet.
- Always change device defaults as specified by your vendors’ best practices or setup guides. For example, the EXTRABACON exploit required the attacker to know the SNMP community string, which acts like a password to restrict access to SNMP data on the device. Cisco’s best practice for firewalls guide explains how a strong community string of various character types should be chosen. The exploit was configured to try the default community string, which in many cases probably worked due to poor configuration. It is also recommended that the latest version of SNMP is used (version 3), as previous versions transmitted the community string in the clear.
- Expose the least amount of services possible for devices, hosts, appliances, etc. For example, if you do not need SNMP, SSH, Telnet, etc. – disable them. If your administrators typically use CLI tools to manage a device, disable the GUI or HTTP versions, as these services typically have a larger attack surface. When adding a new host/device to the network, understand what services are open to which networks and disable or restrict access to those that are not needed globally.
- Before purchasing a product, ensure you understand how long that product may be updated and supported via security patches. Have a plan to update/refresh the product when it reaches end-of-life and is no longer supported.
- Continuously monitor security vulnerability reports and advisories for software and devices in your network. Understand what may affect you and ensure that software and devices are up to date. If a patch may break compatibility with something else within your network or environment, make sure you understand the risk regarding not updating, and monitor unpatched environments especially carefully for threats.
- When vulnerabilities are made public, vendors or open source tools may release IPS signatures prior to a patch being available. Traffic should be monitored using these signatures in order to detect exploitation attempts before a patch is released.
- Understand which devices or hosts within your enterprise are internet-facing, and run services or software that is internet accessible. Monitor inbound traffic for scanners and attempts to exploit vulnerabilities, and ensure these hosts are always patched and up to date. If possible, try to limit the amount of hosts and services that are generically accessible via the internet.
Advanced targeted attacks can exploit zero-day vulnerabilities against any device type, even closed-source security tools meant to protect your network. Proper network segmentation techniques, best practices, and understanding the attack surface across your enterprise and deployed services will help reduce risk to your network.