For the past few decades, Cisco has been playing an important role in the IT industry with its technology and innovation. Ranging from everyday network devices found in the mere sight of average mortals, all the way to enterprise networking solutions - all of it is made by Cisco.
Even though their products standalone (individual units of hardware) don’t bring in the majority of their income, they do profit largely through additional services, license sales, cloud and data center solutions, and IoT technologies. Having said that, it is evident that Cisco primarily focuses on large enterprises and institutions responsible for public infrastructure as their main market niche.
Considering the demands of these environments’ infrastructure in terms of reliability, Cisco pays close attention to eventual bugs and issues on its systems, because, at this level of responsibility, the magnitude of the consequences in case of a bad turn of events could almost be catastrophic for Cisco’s clients, as well as Cisco’s reputation.
Although they probably are the best in the game, they aren’t immune to mistakes. One of these “mistakes” was publicly unveiled on August 15, 2016, when a group of hackers under the name “The Shadow Brokers” leaked a large number of NSA’s hacking tools.
The NSA’s Effect On Cyber-Security
According to multiple sources, The Shadow Brokers have obtained these tools from the “Equation Group”, that’s a well-known threat actor. Their targets are mostly located in countries that are perceived as hostile by the US. Consequences of their activity have been detected in over 42 countries including Russia, Pakistan, Afghanistan, Iran, and Syria. This reinforces the allegation of them being tied to the NSA’s Tailored Access Operations unit.
Have in mind that the documents leaked by Edward Snowden in 2013 support the claim that NSA had been engaging in efforts to weaken encryption standards and insert backdoors into cryptographic systems. Considering that the NSA is (in)famous for forcing equipment manufacturers to keep their products’ security only good enough to keep out everyone but themselves, it wouldn’t be too far-fetched to doubt the fact that Cisco was unaware of this flaw.
Unrelated to Cisco, but still important for this context is the revelation of a backdoor in Juniper Networks' ScreenOS software, used in their networking devices. In 2015, Juniper announced the discovery of unauthorized code that introduced vulnerabilities in their devices, potentially compromising security and encryption.
One Juniper employee had also claimed that the NSA had backdoor access to some of their products for almost a decade before finally reporting it to them once the product had reached its end-of-life and became fully obsolete. Apparently, the flaw was initially introduced into the design by the NSA during the development process somehow.
Additionally, the NSA's involvement in the development and promotion of the Dual_EC_DRBG cryptographic algorithm even after it was known to be vulnerable raised concerns about their methods, which didn’t help them even a bit in terms of getting out of the spotlight.
Because of these events, approaching this vulnerability with an attitude of “innocent until proven guilty” would be a little too naive. We cannot prove that the NSA was involved in this or that Cisco had known about it prior to the official disclosure, but considering that history tends to repeat itself, we definitely shouldn’t rule it out.
Following the leak of the NSA's hacking tools by "The Shadow Brokers," it was only a matter of time before skilled adversaries started capitalizing on the vulnerabilities exposed in various network devices.
CVE-2016-6415 (also referred to as CSCvb29204 or CSCvb36055 in Cisco’s database) is a security flaw that could potentially allow unauthenticated remote attackers to retrieve the memory content and get their hands on confidential data, helping them gain the credentials to the network.
This high-risk vulnerability emerged in 2016, affecting multiple products running Cisco IOS, Cisco IOS XE, and Cisco IOS XR. These products belong to a family of networking operating systems that are used by Cisco’s network infrastructure devices.
The problematic component of these systems is the handling of IKEv1 (Internet Key Exchange v1) packet processing.
IKEv1 is a protocol used for establishing secure communication channels and negotiating security parameters in IPsec (Internet Protocol Security) VPNs. It is an integral part of the IPsec protocol suite and is responsible for the authentication and the negotiation of cryptographic keys between two parties.
There are several binaries used by BENIGNCERTAIN that were leaked from the NSA, playing an important role in exploiting CVE-2016-6414:
- bc-genpkt - used to generate a vulnerability triggering IKEv1 packet
- bc-id - used for sending the packet
- bc-parser - used for parsing the response
A short demo of these binaries has been published on Twitter by Mustafa Al-Bassam, a trust-minimization engineer and a security researcher, confirming that the exploit is more than a proof-of-concept and nicknaming the exploit “PIXPocket”, after the hardware it was targeting.
By combining these tools, it’s possible to make the PIX dump its VPN RSA keys from RAM.
The vulnerability registered as CVE-2016-6415 affects multiple versions of Cisco IOS, Cisco IOS XE, and Cisco IOS XR software. The specific affected versions may vary, and it is recommended to consult Cisco's official security advisory for the most up-to-date information, where they have listed these versions of IOS XR as vulnerable:
For Cisco IOS and IOS XE is not precisely known which versions are vulnerable to BENIGNCERTAIN, but Cisco has released a tool that has the purpose of determining which security advisories apply to your product.
It’s known that Cisco’s PIX 6.x is affected by CVE-2016-6415 and that the issue has been resolved in PIX 7.0 and later versions of the appliance.
There is one thing that challenges the above statement, which is the claim by Cisco that these products are still vulnerable to BENIGNCERTAIN when configured to use IKEv1 and IKEv2. It is unclear if the PIX 7.0 configured to use IKE is still vulnerable or not.
Knowing that would help us determine if the vulnerability happened due to a design flaw, bad programming practice, or poor implementation.
One good thing in all of this is that even though the list of vulnerable configurations is long, it seems that the exploit does need some tweaking in order to dump the VPN credentials from some devices. This is probably due to the fact that the memory is allocated differently throughout different firmware and hardware versions and/or variants, meaning that at least you won’t get hacked by a script kiddie.
Subscribe to be updated on the new content!