Story continued from Page 1
Do you think that we will start seeing more advisories from independent researchers addressing Cisco devices?
I certainly hope so. I also hope that they will at least try to talk to PSIRT [link] before releasing the information. There are some good people in PSIRT who need the support from the outside, due to little support from the inside.
Looking at your slides from a previous BlackHat/DEFCON, it's clear that you already exploited Cisco devices successfully. What was your method?
It's pretty much the same thing as Michael's. Exploitation of a vulnerability to execute arbitrary code always happens in three steps: triggering the vulnerability, getting code execution and writing code to do something. Triggering the vulnerability is obviously always different and depend[s] on the bug. The strategy for getting code execution with Cisco IOS heap overflows is the same as with many other heap overflows: overwrite the inline management information and have the victim memory management work with your data. This is what Michael Lynn and myself did. The difference is, that he overwrote less data and therefore got a better (more stable) code execution. Also, as I already mentioned, his third stage (the code) was different.
What were the differences between Lynn's and your approach?
[My approach] was three years earlier, much less stable and carried code that replaced the router's configuration or, in the later versions, patched the router's running image to get command line access.
Were you able to get a working shell (VTY) too?
The later shellcodes disabled the password checking, so any password would be valid, but [I] did not export a new VTY as Lynn apparently did.
Why didn't you try to get a VTY with your shellcode too? Did you think it was impossible because of the IOS design?
There were several aspects to it. One was, that I didn't know much about the IOS socket communication at the time I wrote the first exploit. The second was, that often port 23 is filtered by the device you are trying to take over, so you need to replace the configuration anyway. I guess I considered the config replacing code to be more reliable. Come to think of it, I also concentrated on the code execution a lot more than on the code.
Did your method leave any traces on the device?
A replaced configuration on the device could be considered a trace :)
It seems that some european teenagers were likely responsible for the IOS source code theft around May 2004. Until today we haven't heard of any new exploit to get a shell, or any rootkit used against IOS. Do you think it's because nobody used the source code to develop these, or because working with the source code you could become an invisible ghost on Cisco routers?
You don't need the source to become an invisible ghost on routers. I think the code is quite large and from what I have seen posted, it's not very nice code either. So I guess nobody actually sits down and reads the code. Even when you['ve] got the code, without at least one actual device, writing exploits and backdoors is hard if not impossible. Most people simply don't have a Cisco.
Doesn't IOS include any forensic or integrity tools?
There is nothing you would call [a] forensic or integrity tool. The images are protected by several interlocking checksums, but these were reverse engineered and cracked by a fellow hacker in a matter of hours. If someone took over your router, there is little you can do in terms of forensics. If the attacker changed the configuration, you may find it in the NVRAM. For everything else, the router must still be running. Then, you can see logged in users or go as far as inspecting the memory as hex dump. But I would say that for an average CCIE it's hard to spot an attacker on a router.
Is there any method that administrators should use to verify IOS image integrity and spot backdoors?
Have the image on known-to-be-good storage and compare the SHA-1 hashes with the image you are loading to the router via network.
On your slides for BlackHat Federal 2003, I read that someone told you that he was able to place a backdoor on IOS. Can you share any info about that?
It's actually pretty easy, as I have presented at Defcon 11 in the runtime image patching code. Of course you can do the same thing with an image, recalculate and replace the already mentioned checksums and give it to someone. That has been done in the past and since few people have valid CCO accounts to download their images directly from Cisco, it's easy to convince someone to install your backdoored image. Cisco should make all IOS images freely available. This would increase their hardware sales and improve security, since people would no longer need to actually pay for SSH support. Before the recent CCO compromise, everyone used someone else's account. But now, most people don't have an account to use anymore, including myself.
Does this big number of different IOS images work as a sort of protection against worms and automatic tools?
As much as still having a number of Windows 95 and 98 machines protects from the next Windows worm. No, the different CPU architectures used and the range of platforms is the biggest thing preventing automatic tools.
Lynn said that "Cisco plans to abstract the architecture of the router operating system in the future, which could have a side effect of making a single attack work against all routers. Rather then knowing the various memory addresses, or offsets, needed to compromise systems, a single offset could work". Is this a dangerous path?
Yes and no. It will simplify exploit development for sure, but it will also enable users to actually patch IOS and not replace entire images. It will also enable them to add security features to already rolled out routers. So it's a two-edged sword. Unless Cisco is going to load a JVM on their routers, the different CPU architectures are going to stay. But it will certainly open up a number of new vectors. Think loadable kernel module backdoors for IOS.
However there still is the big problem of patching. Lynn said "How do you ship the patch when the network won't be up so you can distribute it? Are you going to mail out a CD? But there's no CD drive." Any idea?
The issue is bigger than that. Cisco['s] IOS is not patched. You REPLACE the operating system with a new one. That's like flashing your PC BIOS. And more often than not, the configuration does not work anymore with the new version, or a routing protocol is broken or your special line card is not correctly supported. And remotely updating an IOS version is not a smart idea anyway.