A presentation given by Sebastian 'topo' Muniz from CORE Technologies, given at EUSecWest in London and at PH-Neutral 0x7d8, currently receives some considerable attention from the media. The presentation is titled "Killing the myth of Cisco IOS rootkits: DIK (Da Ios rootKit)". I had the pleasure and privilege to read his accompanying paper and can only hope you had a chance to attend the talk if you happened to be at one of these conferences.
It is however surprising how the media covers this presentation. IOS images, modified on the binary level to allow unprivileged access, are neither new nor extremely hard to do. When I presented on BlackHat Federal 2003 in Washington DC and mentioned backdoored IOS images in the presentation (Slide 12), nobody in the quite Cisco-aware audience showed any indication of surprise. Some time before that presentation, a random hacker had sent me an email with a few bash scripts which would correct any checksum in an IOS image that was patched, just for my entertainment, and mentioned that the scripts took him about half an hour to complete. What topo excels in is the level of platform independence and automatism his rootkit tools achieve. After all, he works in a team of experts on that topic.
The early backdoors in IOS images are a natural consequence of the software being fairly expensive and priced by features. In the same way that people receive a Windows XP Home version with their new PC, but want to run Windows XP Professional or even Vista, people receive an IOS IPonly image but want to support SSH logins instead of Telnet(1) on their routers. Accordingly, people would trade IOS images on the Internet instead of spending money on legitimate copies, especially since they also have to spend the same money on memory extensions for their routers to support the image. With images traded openly, of course attackers modify the image to allow login with a special password. Traded IOS images are an invite to them, as they essentially say: "Whoever downloads this either uses it in the lab or will install it on critical routing infrastructure in their corporation." There is just no other use for an IOS image.
The fact that IOS images are nothing but one single executable without inner security boundaries makes the modification just more powerful. When backdooring a Juniper router in the same way, the attacker has to modify a number of binaries, as Juniper's operating system is based on FreeBSD and therefore has real processes implementing different functionality (login, routing, etc.). It also has a kernel. Now, on IOS, everything is in the same process / address space / memory privilege zone, so a single patch can reach integrity checking code as easily as it can reach login validation code. Oh the other hand, what's the challenge of backdooring Juniper routers? Any adjusted FreeBSD rootkit will do.
What is left is getting the privileged access to the router in the first place. Best practice security in network design, architecture and configuration should prevent that, but there are people who don't follow those and there are vulnerabilities. As noted in other occasions, security functionality seems to be an excellent place to find bugs in. Even SSH, audited to death on other systems, appears to still be a very interesting target on IOS. In this respect, I can understand some of the service provider folks being unhappy about the presentation, as the availability of an IOS rootkit will most certainly rather fuel the interest in writing code execution exploits against IOS, rather than damp it. This is probably one of the reasons the rootkid maker code is not going to be released. Additionally, the heavily increased protections on common operating systems platforms (e.g. Windows Vista), will draw more attention to 1980s style, C written, complex monolithic systems running on critical Internet infrastructure.
All this isn't exactly news. I could have named this entry "I told you so", but that wouldn't really cut it anyway. What rather happened was the ongoing concern of a few people about this whole subject, several years before it was actually presented. When working on the first (and luckily completely replaced) version of the GDB debugging agent for Zynamics BinNavi that allowed runtime debugging of Cisco IOS in a decent reverse engineering tool, I realized that the GDB debugging capabilities would also finally allow the development of an independent forensics tool for Cisco IOS. I discussed this with Gadi Evron, one of the few people that foresaw the issue as well, during the Chaos Communication Congress in 2006.
This was the beginning of the CIR project, which stands for Cisco Information Retrieval or Cisco Incident Response, whatever you like more. CIR is a framework for analyzing IOS memory core dumps, the only solid and complete evidence that can be collected remotely from a router. While the GDB link provides a better (read: less easy to circumvent) interface, network operators do not appreciate driving to every router they manage and using it remotely would be pretty slow. CIR uses the IOS image as a blueprint for the memory map, as the core dumps do not contain any memory mapping information, and also compares static elements from the IOS image to the actual running code in the core dump. A paper and presentation on the technical background of CIR can be found on the Recurity Labs website. One of the simplest features implemented is the comparison of the .text segment between the image and the core dump.
When topo announced the IOS rootkit talk, I was excited that he was willing to provide a backdoored IOS image to me for testing CIR. This is responsible disclosure at its finest hour, as the patched image means little to Cisco Systems but very much to us for testing CIR. After all, detecting your own modifications to an IOS image is kind of silly. From the beginning on, CIR was meant to be provided as a free service to anyone who suspected that their router might have been attacked, backdoored or suffered from a successful or unsuccessful Denial of Service attack using vulnerabilities in IOS. Accordingly, processing was made available online when we barely had the alpha version working and was announced at BlackHat Federal in Washington DC. Since then, we made significant progress on the functional front, but most work went into code quality, dealing with the broken-beyond-recognition ELF files produced by Cisco's build process and making the framework ready to support bigger iron platforms.
Finally, but still before his talk at EUSecWest, topo provided the backdoored image. We fed it into CIR and successfully detected the .text segment modification. However, it only told us that the image was patched and where the patch begun. A quick change of the respective plugin then produced a detailed report that pointed to all modifications in the .text segment. The resulting report can be viewed on CIR Online for those interested in the details. Getting the exact virtual addresses out of the report makes reading the code differences in IDA a piece of cake: you jump to the respective address in the core file and press C. Out comes topo's backdoor, which is a beauty to read in PPC assembly. Felicidades topo!
So, while still in BETA phase, CIR Online seems to actually work. Of course, it also makes the shortcomings of the core dump method obvious: changing the core dumping function in Cisco IOS together with any other backdoor inserted would ruin the collection of evidence and therefore give nothing to process to CIR. This, as mentioned above, could be overcome by physically connecting to the serial console of the router and use the GDB link to obtain the evidence, which again could be prevented by patching the GDB stub in IOS. You end up with the classical race between attacker and forensics person. However, it is a race worth racing if you realize that the bad guys already left the starting line and the dust cloud at the horizon is them speeding away.
Now that some people actually talk about IOS rootkits, interesting tidbits show up. One person asked me if we have tested CIR with the Russian IOS rootkit that was for sale a few years ago. No, we didn't, but good to know that these exist. Additionally, Cisco finally published an updated and much more detailed response, giving instructions on how to detect and/or prevent rootkits with the on-board tools IOS provides. However, some of the instructions are rather humorous, such as transferring images to the router using a secure protocol when your image does not support SSH. On the other hand, they also published a list of MD5 sums of all 12.x images, which is shortly going to be a test CIR performs.
So finally, we seem to have overcome the discussion on if IOS rootkits work or not and approach the age where it's an accepted fact. We also know that, so far, binary and TCL backdoors are detected by CIR. That means we can concentrate on the crash-cause analysis and exploit attempt identification features again. Stay tuned.