The first day of the Black Hat conference briefings came to an end and in retrospect, it was far from bland. From Professor Angell’s esoteric keynote speech touching on how the combination of computers and human activity systems can spawn systemic risk, to a Palace 1 conference room packed wall-to-wall with eager ears ready to listen to Dan Kaminsky deliver his briefing for DNS titled “DNS Goodness.”
In fact, the room was packed so much that an organizer dryly announced over the PA system: “Speakers in parallel talks, you can’t skip your talks even though nobody is going to be there.” It was a good briefing, but it was two other entirely separate briefings that stole the show for me, by a huge margin actually. Neither of these briefings received an abnormal amount of limelight, but both of them involved appliances that are very commonly used in inter- and intra-network infrastructure. The briefings “Cisco IOS Shellcodes and Backdoors” by Gyan Chawdhary and Varun Uppal and “Viral Infections in Cisco IOS” by Sebastian Muniz of Core Security were not only excellent, but also served well to clearly demonstrate that Cisco IOS shellcodes, backdoors, and viral persistent-type infections are clearly feasible.
I mean, even four years ago we knew that these memory corruption for remote code execution attacks against IOS were somewhat feasible. For some (myself included, I’m sad to say), they were feasible in a contrived epic take-over-the-Internet-world movie plot sort of way. Although somewhat realistic, the attacks still seemed like they’d be too arcane for anybody to invest the time to research, especially when there were so many other easier Windows RPC vulnerabilities to exploit. With any closed project, it takes time as layers of obscurity are stripped away before common attacks are plausible.
With the foundation of research performed by Felix Lindner (FX) and Michael Lynn, among others, it seems that Cisco IOS exploitation research is evolving to a very accessible point, especially with the addition of “Cisco IOS Shellcodes and Backdoors” and the excellent “Viral Infections in Cisco IOS” briefings. Perhaps it is accessible enough for individuals or groups with malicious intent to begin leveraging remotely exploitable memory corruption vulnerabilities in Cisco IOS, if the potential reward is high enough, of course. I don’t think that’s an outlandish claim. Or maybe that’s just how I perceive these events. Most of these devices are situated at our network perimeters beyond a lot of the security appliances that are designed to protect against malicious remote attacks.
But what about all of those appliances on the Internet that have not been patched in years or that are running IOS versions that are no longer supported? I can’t imagine that everybody keeps their Cisco appliance firmware current. But even if a person or group with malicious intent can write a generic and reliable exploit for an older remotely exploitable memory corruption vulnerability, they still need to write a complex payload that is designed to analyze the flat memory space of Cisco IOS, hook several critical functions, and then find ways to remain persistent. Some tricks on how this could be done were revealed in both of the Cisco IOS talks that I mentioned previously.
I think that whatever your perspective is on the current risk of in-the-wild Cisco IOS exploitation, you might agree that there needs to at least be an increase in open discussion on how we should respond to or mitigate what seems to be a growing potential of malicious code finding its way onto our embedded network devices.