Author’s update on Sept. 18, 2015: An earlier publication of this article indicated that SYNful Knock relied on a vulnerability of Cisco IOS. FireEye and Cisco indicate that this can only be exploited by physical access, discovery of the administrative password, or use of a default password. Cisco has published this guidance on detecting and removing the implant from affected hardware.
The security research firm FireEye announced September 15, 2015 that a major vulnerability in Cisco IOS called SYNful Knock allows attackers to gain control of enterprise-grade routers, allowing attackers to monitor all network communication, and provide an easier means to infect other network devices.
At the time of release, there are 14 currently known infected routers across India, Mexico, Philippines, and Ukraine. The known affected router models include the Cisco 1841, 2811, and 3825 routers, all of which are products that are no longer sold by Cisco. In an interview with Reuters, FireEye CEO Dave DeWalt indicated that based on the logs from affected routers, the attacks have been ongoing for “at least a year.”
According to FireEye, the similarities in core functionality and IOS software indicate that other router models are likely vulnerable to this exploit.
How this vulnerability works
According to the bulletin published by FireEye:
The implant consists of a modified Cisco IOS image that allows the attacker to load different functional modules from the anonymity of the internet. The implant also provides unrestricted access using a secret backdoor password. Each of the modules are enabled via the HTTP protocol (not HTTPS), using a specifically crafted TCP packets sent to the routers interface. The packets have a nonstandard sequence and corresponding acknowledgment numbers. The modules can manifest themselves as independent executable code or hooks within the routers IOS that provide functionality similar to the backdoor password. The backdoor password provides access to the router through the console and Telnet.
The implant persists on reboot, but the modules loaded by the attackers only exist in RAM, and therefore are wiped following a reboot. Affected routers retain the core functionality of the routers, making the existence of infected systems difficult to notice.
In FireEye’s bulletin about the vulnerability, this is how it breaks down the modifications to the Cisco IOS binary into these four aspects:
- Modify the translation lookaside buffer (TLB) Read/Write attributes
- Modify a legitimate IOS function to call and initialize the malware
- Overwrite legitimate protocol handling functions with malicious code
- Overwrite strings referenced by legitimate functions with strings used by the malware
How to detect and patch vulnerable systems
In Cisco’s post about the vulnerability, the company stated it has added a Snort rule to detect affected systems. Considering the purpose and placement of routers on the network, it is advisable to check devices connected to networks in which this vulnerability has been exploited for further intrusion.
The modules loaded by the implant do not persist after a reboot. For forensics purposes, collecting the modules requires a core dump. FireEye indicated that detailed instructions on how to detect the implant are forthcoming.
As the vulnerability persists across reboots, the only available option is to flash the router with the newest Cisco IOS image available for the device to ensure the complete removal of the implant.
Who is responsible for this attack?
Persistent attacks on enterprise-grade routers have heretofore been mostly theoretical problems, as the usage of and security protections in these devices differ greatly from routers intended for home users, which have been found to have vendor-induced vulnerabilities.
In an interview with Reuters, DeWalt declined to speculate on specific sources of the attack, but noted that “[This] feat is only able to be obtained by a handful of nation-state actors.” Reuters names the intelligence services of Britain, China, Israel, Russia, and the US as possessing the technical ability to orchestrate such an attack.
What’s your view?
Is your organization using any of the Cisco products that have been identified as vulnerable to this exploit? What is your policy on decommissioning hardware that is nearing the end of vendor support? Share your thoughts in the comments.