IOS Rookit: the sky isn't falling (yet)
I finally got to see Topo's presentation this week-end at PH-Neutral and discuss it with him and FX. Given that the slides aren't online yet [1], that Core hasn't published Topo's technical paper on their website [2] yet either, and that I'm done replying to direct inquiries about it [3], here's a summary of the IOS rootkit saga and its impact on the Service Provider community (from my point of view :) Topo spent a lot of time (and if you ever loaded an IOS image in IDA you know what I'm talking about) analyzing strings and functions in IOS. In his proof of concept he located the code doing the password check and adds a trampoline to his backdoor code (by saving paramaters, glueing the two codes together, doing the "new" password check and returning properly to the main code path). Nice lesson on 101 hooking on IOS. The (oversimplified) modus operandi is pretty straight forward: take an image, decompress it, have his tool locate the function and later patch it, add his code by overwriting large strings, (re)compress the image and (re)calculate/fix the checksums. Pretty neat. The fact that he doesn't do basic binary patching makes the approach portable and not architecture, version or feature set specific. This image then needs to be uploaded to the router and the device need to be reloaded. This backdoor is persistent (vs the old backdoor trick using the TCL shell [4] which wasn't - or if you want to turn it into a non-volatile one it was easy to detect as in clear text in the startup/running configuration). An alternative approach is to use gdb on the router (and combine it with a TCL script to make it easier) and patch on the fly. This is non-persistent, but some people don't wan't to leave traces as large as an IOS image behind :) Or another alternative approach: network boot the router via TFTP. At the end of the day this is nothing new from a rootkit technology point of view, but it's in the IOS/router world. He deserves credit to actually have researched this in deep and managed to make it work (it's much more difficult to achieve this on a mostly undocumented and large binary than on common OSes). Respect. What's the best way to actually test this when you don't have the HW you ask ? Dynamips [9] is the answer. As long as the rootkit isn't too advanced and e.g. also hooks the write/copy functions (e.g. an attacker could store the image diff on the system and play a "proper" memory dump or proper IOS back when you write core/copy to TFTP) then FX's CIR[7] is the forensics tool of choice. On platforms where the IOS image is stored on an external flash card forensics may be easier. Here's [8] a "screenshot" of CIR vs Topo. So what's the impact today ? Topo's proof of concept doesn't bypass ACLs (rACLs, VTY ACLs), AAA, etc [yet], requires enable rights, a new image and a reload (or enable only if you do gdb-on-the-fly patching). In summary it's "noisy" and unless you bought the router on an auction site and/or download IOS from "alternative" sources) you should notice (or probably deserve to get owned :) See the Cisco PSIRT response for best current practices on securing routers [10] and my old forensics presentation [3]. In the past FX [5] and Mike Lynn [6] proved that code execution is doable. This is a different approach. Can it be combined ? Probably. It is much more complex ? Yes. Is it going to be architecture specific ? Probably. Future developments ? I'm surprised people still focus on the IOS side of things and don't attack the bootrom code as it's smaller and usually never changed unless you bring in some new/unsupported hardware/features. IOS-XR is probably going to become a target too as it makes some of these things easier [11] but code signing may have to be broken/bypassed first. This has been done on other devices, so it's just one more layer to attack. An alternative rootkit ? Privilege level 16 used by the Lawful Intercept [12] feature could be abused to do some of this too. Or the other way around: use a "patched" IOS to keep an eye on Law Enforcement's operations on the router as privilege level 15 doesn't allow it and the only alternative is to sniff the traffic export. I've probably missed some stuff (and got some stuff wrong), but this summary became way too long already and it's late. Feedback welcome! [1] Dragos should post them soon here: http://www.eusecwest.com/ [2] Watch http://www.coresecurity.com/?module=ContentMod&action=news&id=papers [3] Google "IOS rootkit" used to return the presentation below as first hit "Cisco Router Forensics" - http://www.securite.org/presentations/secip/ [4] http://seclists.org/bugtraq/2007/Nov/0384.html [5] http://www.phenoelit-us.org/ultimaratio/index.html http://www.milw0rm.com/exploits/77 [6] http://cryptome.org/lynn-cisco.pdf [7] http://cir.recurity.com/ [8] http://www.securite.org/nico/XP/CIRvsTopo.jpg [9] http://www.ipflow.utc.fr/index.php/Cisco_7200_Simulator [10] http://www.cisco.com/en/US/products/products_security_response09186a00809977... [11] http://lists.darklab.org/pipermail/darklab/2005-August/000029.html [12] http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/lawf_int.html Nico. -- Nicolas FISCHBACH Senior Manager - Network Engineering/Security - COLT Telecom e:(nico@securite.org) w:<http://www.securite.org/nico/>
An alternative rootkit ? Privilege level 16 used by the Lawful Intercept [12] feature could be abused to do some of this too. Or the other way around: use a "patched" IOS to keep an eye on Law Enforcement's >operations on the router as privilege level 15 doesn't allow it and the only alternative is to sniff the traffic export.
The combination of rootkits and specially privileged Lawful Intercept functions is a very dangerous one. This was precisely what was exploited in the now-legendary and still unsolved Vodafone Greece hack. Alex
On Tue, May 27, 2008 at 8:42 AM, Alexander Harrowell <a.harrowell@gmail.com> wrote:
An alternative rootkit ? Privilege level 16 used by the Lawful Intercept [12] feature could be abused to do some of this too. Or the other way around: use a "patched" IOS to keep an eye on Law Enforcement's >operations on the router as privilege level 15 doesn't allow it and the only alternative is to sniff the traffic export.
The combination of rootkits and specially privileged Lawful Intercept functions is a very dangerous one. This was precisely what was exploited in the now-legendary and still unsolved Vodafone Greece hack.
to be clear though, the LI functions on cisco are audit-able (assuming the ios is still cisco not patched/hacked) you just have to snmp-v3 to audit the activities... which most mediation devices have to do because the settings don't get committed to config so upon system reload they have to be re-set to baseline again. -Chris
On May 27, 2008, at 8:42 AM, Alexander Harrowell wrote:
An alternative rootkit ? Privilege level 16 used by the Lawful Intercept [12] feature could be abused to do some of this too. Or the other way around: use a "patched" IOS to keep an eye on Law Enforcement's
operations on the router as privilege level 15 doesn't allow it and the only alternative is to sniff the traffic export.
The combination of rootkits and specially privileged Lawful Intercept functions is a very dangerous one. This was precisely what was exploited in the now-legendary and still unsolved Vodafone Greece hack.
Perhaps the above should be simplified. Running a hacked/modded IOS version is a dangerous prospect. This seems like such a non-event because what is the exploit path to load the image? There needs to be a primary exploit to load the malware image. *yawn* - Jared
On Tue, 27 May 2008, Jared Mauch wrote:
On May 27, 2008, at 8:42 AM, Alexander Harrowell wrote:
An alternative rootkit ? Privilege level 16 used by the Lawful Intercept [12] feature could be abused to do some of this too. Or the other way around: use a "patched" IOS to keep an eye on Law Enforcement's
operations on the router as privilege level 15 doesn't allow it and the only alternative is to sniff the traffic export.
The combination of rootkits and specially privileged Lawful Intercept functions is a very dangerous one. This was precisely what was exploited in the now-legendary and still unsolved Vodafone Greece hack.
Perhaps the above should be simplified.
Running a hacked/modded IOS version is a dangerous prospect.
This seems like such a non-event because what is the exploit path to load the image? There needs to be a primary exploit to load the malware image.
*yawn*
I guess we will wait for the next one before waking up, than.
- Jared
Gadi.
On Tue, 27 May 2008 11:02:32 CDT, Gadi Evron said:
On Tue, 27 May 2008, Jared Mauch wrote:
*yawn*
I guess we will wait for the next one before waking up, than.
No Gadi. What Jared is saying is that there are exactly *ZERO* routers (for some infinitesimally small value of zero) that will get rootkitted that weren't *already* vulnerable to the stuff that Lynn talked about three years ago. There's basically 2 classes of Cisco routers out there: 1) Ones managed by Jared and similarly clued people, who can quite rightfully yawn because the specter of "IOS rootkits" changes nothing in their actual threat model - they put stuff in place 3 years ago to mitigate "Lynn-style IOS pwnage", and it will stop this just as well. Move along, nothing to see. 2) Ones managed by unclued people. And quite frankly, if Lynn didn't wake them up 3 years ago, this isn't going to wake them up either. Move along, nothing new to see here either. "60% of routers run by bozos who shouldn't have enable. Film at 11". *yawn*.
On Tue, May 27, 2008, Valdis.Kletnieks@vt.edu wrote:
There's basically 2 classes of Cisco routers out there:
1) Ones managed by Jared and similarly clued people, who can quite rightfully yawn because the specter of "IOS rootkits" changes nothing in their actual threat model - they put stuff in place 3 years ago to mitigate "Lynn-style IOS pwnage", and it will stop this just as well. Move along, nothing to see.
2) Ones managed by unclued people. And quite frankly, if Lynn didn't wake them up 3 years ago, this isn't going to wake them up either. Move along, nothing new to see here either.
"60% of routers run by bozos who shouldn't have enable. Film at 11".
Bloody network people, always assuming their network security stops at their router. So nowthat someone's done the hard lifting to backdoor an IOS binary, and I'm assuming you all either upgrade by downloading from the cisco.com website or maintain a set of your own images somewhere, all one needs to do is insert themselves into -that- path and you're screwed. Hijacking prefixes isn't hard. That was presented at the same security conference. Cracking a UNIX/Windows management/FTP/TFTP host isn't impossible - how many large networks have their server infrastructure run by different people to their network infrastructure? Lots and lots? :) Sure, its not all fire and brimstone, but the bar -was- dropped a little, and somehow you need to make sure that the IOS thats sitting on your network management site is indeed the IOS that you put there in the first place.. Adrian
On Tue, May 27, 2008 at 11:13 AM, Adrian Chadd <adrian@creative.net.au> wrote:
Bloody network people, always assuming their network security stops at their router.
So nowthat someone's done the hard lifting to backdoor an IOS binary, and I'm assuming you all either upgrade by downloading from the cisco.com website or maintain a set of your own images somewhere, all one needs to do is insert themselves into -that- path and you're screwed.
Hijacking prefixes isn't hard. That was presented at the same security conference.
Cracking a UNIX/Windows management/FTP/TFTP host isn't impossible - how many large networks have their server infrastructure run by different people to their network infrastructure? Lots and lots? :)
Sure, its not all fire and brimstone, but the bar -was- dropped a little, and somehow you need to make sure that the IOS thats sitting on your network management site is indeed the IOS that you put there in the first place..
Like MD5 File Validation? - "MD5 values are now made available on Cisco.com for all Cisco IOS software images for comparison against local system image values." ~Chris
Adrian
-- Chris Grundemann www.linkedin.com/in/cgrundemann
On Tue, May 27, 2008, Chris Grundemann wrote:
Sure, its not all fire and brimstone, but the bar -was- dropped a little, and somehow you need to make sure that the IOS thats sitting on your network management site is indeed the IOS that you put there in the first place..
Like MD5 File Validation? - "MD5 values are now made available on Cisco.com for all Cisco IOS software images for comparison against local system image values."
Yes, but the only thing the router checks iirc is the old-style checksum, and not some oob provided md5 hash? And if you can exploit the management box itself, you can load your own MD5 hash in. This is all the sort of stuff that public key crypto and chains of trust were meant to solve, IIRC.. Adrian
On Tue, 27 May 2008 11:24:19 MDT, Chris Grundemann said:
Like MD5 File Validation? - "MD5 values are now made available on Cisco.com for all Cisco IOS software images for comparison against local system image values."
That does wonders for catching a corruption in the FTP that wasn't caught by the relatively weak TCP checksumming. But if the attacker has the wherewithal to cause a modified file to be downloaded (either by replacing it on the real server, or getting you to visit a fake server), they can also present you with a webpage that has an MD5 hash that matches the modified file. Now, if they provided a PGP signature of the file, done with a key that I have reason to trust, *that* raises the bar significantly...
On Tue, 27 May 2008, Valdis.Kletnieks@vt.edu wrote:
On Tue, 27 May 2008 11:24:19 MDT, Chris Grundemann said:
Like MD5 File Validation? - "MD5 values are now made available on Cisco.com for all Cisco IOS software images for comparison against local system image values." That does wonders for catching a corruption in the FTP that wasn't caught by the relatively weak TCP checksumming. But if the attacker has the wherewithal to cause a modified file to be downloaded (either by replacing it on the real server, or getting you to visit a fake server), they can also present you with a webpage that has an MD5 hash that matches the modified file. Now, if they provided a PGP signature of the file, done with a key that I have reason to trust, *that* raises the bar significantly...
What you want is cisco hardware that verifies firmware signatures in hardware. -Dan
On Tue, 27 May 2008 10:47:08 PDT, goemon@anime.net said:
What you want is cisco hardware that verifies firmware signatures in hardware.
Yes, but that requires new hardware. Understanding the security risk in accepting an unsigned MD5 signature from the same place that you accepted the file from is a wetware issue. Granted, at many shops hardware upgrades are easier than wetware upgrades. ;)
goemon@anime.net wrote:
On Tue, 27 May 2008, Valdis.Kletnieks@vt.edu wrote:
Like MD5 File Validation? - "MD5 values are now made available on Cisco.com for all Cisco IOS software images for comparison against local system image values." That does wonders for catching a corruption in the FTP that wasn't caught by the relatively weak TCP checksumming. But if the attacker has the wherewithal to cause a modified file to be downloaded (either by replacing it on the real server, or getting you to visit a fake server), they can also present you with a webpage that has an MD5 hash that matches the modified file. Now, if they provided a PGP signature of the file, done with a key
On Tue, 27 May 2008 11:24:19 MDT, Chris Grundemann said: that I have reason to trust, *that* raises the bar significantly...
What you want is cisco hardware that verifies firmware signatures in hardware.
-Dan
Why not TPM? Sign every binary on the device, encrypt & sign the headers. The entire device runs in a hypervisor. Everything must be approved by Cisco. Let's make routers even more blackboxish and require vendor certification for every little thing. I don't know about you, but I don't want layers of DRM and crap ontop of my router when I'm still wondering about idiots leaving tftpds open. :-/ -- +1.925.202.9485 Sargun Dhillon deCarta sdhillon@decarta.com www.decarta.com
On Tue, 27 May 2008, goemon@anime.net wrote:
What you want is cisco hardware that verifies firmware signatures in hardware.
Of course, how do you know your hardware hasn't been compromised? http://www.usdoj.gov/opa/pr/2008/February/08_crm_150.html
On Tue, 27 May 2008, Sean Donelan wrote:
On Tue, 27 May 2008, goemon@anime.net wrote:
What you want is cisco hardware that verifies firmware signatures in hardware. Of course, how do you know your hardware hasn't been compromised? http://www.usdoj.gov/opa/pr/2008/February/08_crm_150.html
Are you buying directly from cisco or from resellers? If you are getting counterfeit hardware directly from cisco then I guess we have real problems. -Dan
On Tue, 27 May 2008, goemon@anime.net wrote:
Are you buying directly from cisco or from resellers? If you are getting counterfeit hardware directly from cisco then I guess we have real problems.
According to the FBI presentation, which may not be a reliable source for this topic, Cisco has very few "direct" customers. Even if you think you are ordering "direct" from Cisco, e.g. www.cisco.com, the order seems to get forwarded to several primary Cisco resellers and the hardware shipped via a reseller. Even most resellers buy their Cisco products from a primary reseller or a secondary reseller, not direct from Cisco. The FBI presentation did note that a few US Cisco customers, such as some unnamed large US telcos and unnamed intelligence agencies, do order and ship directly from Cisco.
Date: Tue, 27 May 2008 15:46:34 -0400 (EDT) From: Sean Donelan <sean@donelan.com>
On Tue, 27 May 2008, goemon@anime.net wrote:
Are you buying directly from cisco or from resellers? If you are getting counterfeit hardware directly from cisco then I guess we have real problems.
According to the FBI presentation, which may not be a reliable source for this topic, Cisco has very few "direct" customers.
Even if you think you are ordering "direct" from Cisco, e.g. www.cisco.com, the order seems to get forwarded to several primary Cisco resellers and the hardware shipped via a reseller. Even most resellers buy their Cisco products from a primary reseller or a secondary reseller, not direct from Cisco.
The FBI presentation did note that a few US Cisco customers, such as some unnamed large US telcos and unnamed intelligence agencies, do order and ship directly from Cisco.
A lot of folks order from a reseller and Cisco ships directly. This is true for many section 8a resellers when selling to organizations under those purchasing mandates...anyone spending federal $$$. I suspect some states have similar requirements. (Section 8a gives preference to small, minority owned, and disadvantaged businesses.) In any case, the reseller never sees this equipment. I am unclear on how common this is in the non-8a part of the world, but I suspect a lot of folks get their stuff direct from Cisco (or Juniper, for that matter), even though they buy from a reseller, if they are buying bigger boxes that small resellers are unlikely to stock. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Like MD5 File Validation? - "MD5 values are now made available on Cisco.com for all Cisco IOS software images for comparison against local system image values."
I would expect a real exploit to try to match Cisco's MD5 hashes. By all means, check those hashes after you download them but I would suggest calculating a hash using an alternate algorithm for later checking. --Michael Dillon
On Tue, 27 May 2008 19:49:21 BST, michael.dillon@bt.com said:
Like MD5 File Validation? - "MD5 values are now made=20 available on Cisco.com for all Cisco IOS software images for=20 comparison against local system image values."
I would expect a real exploit to try to match Cisco's MD5 hashes.
Although there is a known attack against MD5 that will generate two plaintexts with the same (unpredictable) hash, there is as yet no known way significantly better than brute force to generate a file which hashes to a given hash. On the other hand, there have been multiple cases where vandals have replaced a file on a download site, and updated the webpage to reflect the new MD5 hash. If you were an attacker, which would you go with: 1) The brute-force attack which will require hundreds of thousands of CPU-years. 2) The super-secret attack that causes a collision to a given hash that none of the crypto experts know about yet. 3) 'md5sum trojan_ios.bin' and cut-n-paste that into the web page.
By all means, check those hashes after you download them but I would suggest calculating a hash using an alternate algorithm for later checking.
You missed the point - if the *FILE* you downloaded from a webpage is suspect, why do you trust the MD5sum that *the same webpage* says is correct?
Perhaps Cisco and friends should take to periodically printing MD5 checksums in full page ads in the New York Times or similar? Maybe not impossible for an attacker to replicate, but it certainly does raise the bar :) On Tue, May 27, 2008 at 3:07 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Tue, 27 May 2008 19:49:21 BST, michael.dillon@bt.com said:
Like MD5 File Validation? - "MD5 values are now made=20 available on Cisco.com for all Cisco IOS software images for=20 comparison against local system image values."
I would expect a real exploit to try to match Cisco's MD5 hashes.
Although there is a known attack against MD5 that will generate two plaintexts with the same (unpredictable) hash, there is as yet no known way significantly better than brute force to generate a file which hashes to a given hash. On the other hand, there have been multiple cases where vandals have replaced a file on a download site, and updated the webpage to reflect the new MD5 hash.
If you were an attacker, which would you go with:
1) The brute-force attack which will require hundreds of thousands of CPU-years.
2) The super-secret attack that causes a collision to a given hash that none of the crypto experts know about yet.
3) 'md5sum trojan_ios.bin' and cut-n-paste that into the web page.
By all means, check those hashes after you download them but I would suggest calculating a hash using an alternate algorithm for later checking.
You missed the point - if the *FILE* you downloaded from a webpage is suspect, why do you trust the MD5sum that *the same webpage* says is correct?
If you were an attacker, which would you go with:
1) The brute-force attack which will require hundreds of thousands of CPU-years.
In this case an attacker would definitely go with this option. Since they can't change most of the IOS bytes because they contain IOS and the exploit, they would definitely run a brute force attack on the remaining bytes. Granted, the chances of success are slim, but these are people who are used to playing the odds even if they lose most of the time.
3) 'md5sum trojan_ios.bin' and cut-n-paste that into the web page.
One would hope that Cisco is taking measures to protect against that.
You missed the point - if the *FILE* you downloaded from a webpage is suspect, why do you trust the MD5sum that *the same webpage* says is correct?
I wasn't thinking of any old web page but one that belongs to a trusted vendor and which requires some kind of authentication before you can get to the file. In any case, the whole issue ca be bypassed using CDs or using a PGP chain of trust. --Michael Dillon
On Tue, 27 May 2008 20:45:11 BST, michael.dillon@bt.com said:
1) The brute-force attack which will require hundreds of thousands of CPU-years.
Millions. Not thousands. See below.
In this case an attacker would definitely go with this option. Since they can't change most of the IOS bytes because they contain IOS and the exploit, they would definitely run a brute force attack on the remaining bytes. Granted, the chances of success are slim, but these are people who are used to playing the odds even if they lose most of the time.
I think you're thinking of the known collision attack against MD5, where you start off with two plaintexts of your choice, and by suitable manipulation of a smallish (on the order of 256 bytes) section of each, you can get the two files to have the same MD5sum. Unfortunately, you have zero control over what the output MD5sum is. There's a known method for doing this that will do it in about 8 hours on a 1.6Ghz computer: http://cryptography.hyperlink.cz/md5/MD5_collisions.pdf In contrast, a "pre-image" attack (finding a plaintext that will hash to a given MD5 hash) is still a bunch of work - this 2004 paper by Kelsey and Schneier (http://eprint.iacr.org/2004/304.pdf) shows how to, for a 128-bit hash and (for instance) a 1 gigabyte file, to compute a second-preimage attack in (roughly) 2**105 rather than the expected 2**128 (n=128 and k=24, for those of you playing along at home). So let's see - if you had a billion CPUs in your botnet, and each one could go at a billion to the second, you still need 2**69 seconds or 449,235,776,528,695 years. Not bad - only 10,000 times the amount of time this planet has been around, so yeah, that's the way they'll attack all right. (If somebody knows a *better* pre-image attack, please fill me in. I know there's a few other crypto-heads out there...)
So let's see - if you had a billion CPUs in your botnet, and each one could go at a billion to the second, you still need 2**69 seconds or 449,235,776,528,695 years. Not bad - only 10,000 times the amount of time this planet has been around, so yeah, that's the way they'll attack all right.
I didn't say that. I said that they are starting with an IOS image in which there are some small number of bytes which they can possibly change and still have a functional image. So it is likely that they will brute force that by computing an MD5 hash on all variations of those few bytes. It's like winning the lottery, you only *NEED* to buy one ticket. No matter how slim the chances are of bad guys winning that lottery, it is no excuse for ignoring the possibility that an MD5 hash check may not be proof that you have an original image. And lets not get into all the other possibilities such as an insider who corrupts your database in which you safely store the MD5 hashes. There is no magic bullet, only various security layers which reduce the odds of an exploit in your network in a similar way to how multiple routers and multiple paths can increase your network's uptime to very nearly 100%. --Michael Dillon
On Wed, 28 May 2008 10:37:05 +0100 <michael.dillon@bt.com> wrote:
So let's see - if you had a billion CPUs in your botnet, and each one could go at a billion to the second, you still need 2**69 seconds or 449,235,776,528,695 years. Not bad - only 10,000 times the amount of time this planet has been around, so yeah, that's the way they'll attack all right.
I didn't say that. I said that they are starting with an IOS image in which there are some small number of bytes which they can possibly change and still have a functional image. So it is likely that they will brute force that by computing an MD5 hash on all variations of those few bytes. It's like winning the lottery, you only *NEED* to buy one ticket. No matter how slim the chances are of bad guys winning that lottery, it is no excuse for ignoring the possibility that an MD5 hash check may not be proof that you have an original image.
Did you even look at Valdis' arithmetic? It *won't work*. It isn't "likely" that they'll try anything with that low a chance of success. As for "no matter how slim the chances" -- if you want to have even a vague chance of succeeding before Sol turns into a red giant, you're going to have to devote enormous resources to the project. (Actually, I don't think you can succeed even then, not by brute force -- there aren't a "small number of bytes" that can be changed, you can introduce "random" "typographical" errors in error messages for the SNA stack or some such, and if you're doing a brute force pre-image attack on MD5 any bit is as good as any other.) Let's put it purely in economic terms: which is a better way to invest your effort, building a machine (or botnet) with many billions of processors and still having no plausible chance of winning, or -- as you yourself suggest -- getting the HVAC contract for the data center. Or putting back doors in the chips. Or bribing or blackmailing coders. Or breaking into the vault where Cisco keeps its master RSA key. Or funding a vast research effort on cracking MD5 before it's replaced by SHA-512. Or *something* even vaguely sane, because brute-forcing MD5 isn't physically possible. --Steve Bellovin, http://www.cs.columbia.edu/~smb
On Thu, 29 May 2008, Steven M. Bellovin wrote:
On Wed, 28 May 2008 10:37:05 +0100 <michael.dillon@bt.com> wrote:
So let's see - if you had a billion CPUs in your botnet, and each one could go at a billion to the second, you still need 2**69 seconds or 449,235,776,528,695 years. Not bad - only 10,000 times the amount of time this planet has been around, so yeah, that's the way they'll attack all right.
I didn't say that. I said that they are starting with an IOS image in which there are some small number of bytes which they can possibly change and still have a functional image. So it is likely that they will brute force that by computing an MD5 hash on all variations of those few bytes. It's like winning the lottery, you only *NEED* to buy one ticket. No matter how slim the chances are of bad guys winning that lottery, it is no excuse for ignoring the possibility that an MD5 hash check may not be proof that you have an original image.
Did you even look at Valdis' arithmetic? It *won't work*. It isn't "likely" that they'll try anything with that low a chance of success. As for "no matter how slim the chances" -- if you want to have even a vague chance of succeeding before Sol turns into a red giant, you're going to have to devote enormous resources to the project. (Actually, I don't think you can succeed even then, not by brute force -- there aren't a "small number of bytes" that can be changed, you can introduce "random" "typographical" errors in error messages for the SNA stack or some such, and if you're doing a brute force pre-image attack on MD5 any bit is as good as any other.) Let's put it purely in economic terms: which is a better way to invest your effort, building a machine (or botnet) with many billions of processors and still having no plausible chance of winning, or -- as you yourself suggest -- getting the HVAC contract for the data center. Or putting back doors in the chips. Or bribing or blackmailing coders. Or breaking into the vault where Cisco keeps its master RSA key. Or funding a vast research effort on cracking MD5 before it's replaced by SHA-512. Or *something* even vaguely sane, because brute-forcing MD5 isn't physically possible.
I don't understand how this disucssion got to breaking MD5 to begin with? The whole point was that the results will be manipulated due to the rootkit messing with the test, no? Gadi.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
The conversation shifted to breaking MD5 because it was mentioned that one way to prevent the installation of cracked IOS images was to include some sort of DRM or trusted computing chip in new hardware, and have Cisco sign their IOS images (supposedly even the boot EEPROM). This wouldn't be DRM in the sense of DVD's, where they don't want everyone to be able to decode the disk, so must come up with some scheme where they provide the decryption key that is itself decrypted with a private key which all of the DVD players have the public key for, hence could be relatively easily broken (just extract the public key from the player, which was what was done for HD-DVD. In other words, attacking the crypto scheme instead of the algorithm. Cisco would presumably want everyone to be able to read the file, just sign it with their private key. So how do you sign an IOS image? Most crypto schemes work by generating a MD5 hash of the data, and then signing the MD5 hash, not signing the whole IOS image, which would be encrypting the whole thing. Decrypting an IOS image sized data block with the RSA algorithm would presumably take too long, so just the hash is signed. If the signed hash matches the hash you compute when loading the image it's a good image, so the boot ROM would load the code. Once loaded, it would check the signature (of the hash) on any new boot ROM loaded so that attackers could not use that vector. For what it's worth, encrypting the whole file is still not normally done by encrypting with the RSA public key of the destination. Rather, another symmetric protocol is used, such as 3DES or IDEA or something, and they key for that protocol is encrypted with RSA. The private key in this case would be located... on the new Cisco hardware. So, much like breaking HD-DVD crypto scheme this could be broken also. However, I don't think it is the goal to encrypt the IOS code, just ensure that it is valid code from Cisco, so an appropriate hash should do just fine. So the only easy way to attack this is the MD5 hash. We have a know plaintext (the IOS code) and the hash. It is not trivial to be able to make changes in the code and maintain the same hash value, but there has been at least limited success in doing so. If they can change the code and fiddle with the help text in some obscure feature no one regularly uses and generate the same hash then viola, access. That's how we got onto breaking MD5. However, if there is a known vulnerability, to however few people, in IOS where there is a buffer overflow or something else where remote code can be executed, this presumably could overwrite the IOS code running on the box and bypass the code-checking hardware. It may not be possible to replace the boot ROM, because presumably the new hardware would check the ROM code hash before loading it and also presumably the ROM code does not have quite as much text messages that can be changed to generate the same hash value, thereby bypassing the security checks. So in this scenario rooted IOS would only exist transiently; a reboot would load the known good code again (or brick the box if "bad" ROMMON were burned). Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS Senior Network Engineer Coleman Technologies, Inc. 954-298-1697
-----Original Message----- From: Gadi Evron [mailto:ge@linuxbox.org] Sent: Thursday, May 29, 2008 12:21 AM To: Steven M. Bellovin Cc: nanog@nanog.org Subject: Re: IOS Rookit: the sky isn't falling (yet)
On Wed, 28 May 2008 10:37:05 +0100 <michael.dillon@bt.com> wrote:
So let's see - if you had a billion CPUs in your botnet, and each one could go at a billion to the second, you still need 2**69 seconds or 449,235,776,528,695 years. Not bad - only 10,000 times the amount of time this planet has been around, so yeah, that's the way they'll attack all right.
I didn't say that. I said that they are starting with an IOS image in which there are some small number of bytes which they can
change and still have a functional image. So it is likely that they will brute force that by computing an MD5 hash on all variations of those few bytes. It's like winning the lottery, you only *NEED* to buy one ticket. No matter how slim the chances are of bad guys winning that lottery, it is no excuse for ignoring the possibility that an MD5 hash check may not be proof that you have an original image.
Did you even look at Valdis' arithmetic? It *won't work*. It isn't "likely" that they'll try anything with that low a chance of success. As for "no matter how slim the chances" -- if you want to have even a vague chance of succeeding before Sol turns into a red giant, you're going to have to devote enormous resources to the project. (Actually, I don't think you can succeed even then, not by brute force -- there aren't a "small number of bytes" that can be changed, you can introduce "random" "typographical" errors in error messages for the SNA stack or some such, and if you're doing a brute force pre-image attack on MD5 any bit is as good as any other.) Let's put it purely in economic terms: which is a better way to invest your effort, building a machine (or botnet) with many billions of processors and still having no
On Thu, 29 May 2008, Steven M. Bellovin wrote: possibly plausible
chance of winning, or -- as you yourself suggest -- getting the HVAC contract for the data center. Or putting back doors in the chips. Or bribing or blackmailing coders. Or breaking into the vault where Cisco keeps its master RSA key. Or funding a vast research effort on cracking MD5 before it's replaced by SHA-512. Or *something* even vaguely sane, because brute-forcing MD5 isn't physically possible.
I don't understand how this disucssion got to breaking MD5 to begin with? The whole point was that the results will be manipulated due to the rootkit messing with the test, no?
Gadi.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 29 May 2008, Fred Reimer wrote:
plaintext (the IOS code) and the hash. It is not trivial to be able to make changes in the code and maintain the same hash value, but there has been at least limited success in doing so.
Has there? My understanding is that constructing a new image to match an existing MD5 checksum (vs. constructing two new images with matching MD5 checksums) was still not feasible. Did I miss something?
It may not be possible to replace the boot ROM, because presumably the new hardware would check the ROM code hash before loading it and also presumably the ROM code does not have quite as much text messages that can be changed to generate the same hash value, thereby bypassing the security checks.
This may be an obvious question, but given that the code which verifies an IOS image would (presumably) be part of the boot ROM, where would you put the code which verifies the boot ROM? What does it mean to say `the hardware' should check the boot ROM? - -- Jim Wise jwise@draga.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (NetBSD) iD8DBQFIPrGtq/KRbT0KwbwRArN+AJ0QTuytahkUluOYpCHQ9jw94gNWFQCfTQ5c 2V0w8OO3EnCnJvb3lYh1+sQ= =o9Ro -----END PGP SIGNATURE-----
On May 29, 2008, at 9:37 AM, Jim Wise wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 29 May 2008, Fred Reimer wrote:
plaintext (the IOS code) and the hash. It is not trivial to be able to make changes in the code and maintain the same hash value, but there has been at least limited success in doing so.
Has there? My understanding is that constructing a new image to match an existing MD5 checksum (vs. constructing two new images with matching MD5 checksums) was still not feasible. Did I miss something?
I think the point here is that most (read: average) consumers don't verify the md5/sha1/gpg/pgp signatures of the binaries they run. If that was the case, we wouldn't have problems quite as bad as we do today.
It may not be possible to replace the boot ROM, because presumably the new hardware would check the ROM code hash before loading it and also presumably the ROM code does not have quite as much text messages that can be changed to generate the same hash value, thereby bypassing the security checks.
This may be an obvious question, but given that the code which verifies an IOS image would (presumably) be part of the boot ROM, where would you put the code which verifies the boot ROM? What does it mean to say `the hardware' should check the boot ROM?
I agree with you here. Cisco even ships methods to do a field-upgrade of the rommon on a variety of platforms and linecards. There are numerous challenges when talking about how to prevent these types of updates. I could imagine a case where you leverage the current 'phlashing' stuff to "brick" your router rommon so it won't boot. Once again it gets to the how do you obtain an exploit path to perform these actions on the device? I always have said physical access = "root". Perhaps the path is that oob modem? You need to think about these things, but unless you have a mission dealing with state secrets or your corporate IP (not the protocol) guys treat everything like it is (eg: pharmaceutical companies), you're likely to not notice the router in the closet has a 2 year old bogon filter list installed. - Jared
The code would presumably be run upon boot from a non-flashable source, which would run the boot ROM code through a check on the crypto chip and only execute it if it passed. You would not put the code that checks the boot ROM on the boot ROM. The new crypto chip would presumably have the initial boot code, which would only be designed to check the boot ROM signature and nothing else so presumably would never need to be replaced and hence would be designed to be non-flashable. Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS Senior Network Engineer Coleman Technologies, Inc. 954-298-1697
-----Original Message----- From: Jared Mauch [mailto:jared@puck.nether.net] Sent: Thursday, May 29, 2008 9:48 AM To: Jim Wise Cc: Fred Reimer; nanog@nanog.org Subject: Re: IOS Rookit: the sky isn't falling (yet)
On May 29, 2008, at 9:37 AM, Jim Wise wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 29 May 2008, Fred Reimer wrote:
plaintext (the IOS code) and the hash. It is not trivial to be able to make changes in the code and maintain the same hash value, but there has been at least limited success in doing so.
Has there? My understanding is that constructing a new image to match an existing MD5 checksum (vs. constructing two new images with matching MD5 checksums) was still not feasible. Did I miss something?
I think the point here is that most (read: average) consumers don't verify the md5/sha1/gpg/pgp signatures of the binaries they run. If that was the case, we wouldn't have problems quite as bad as we do today.
It may not be possible to replace the boot ROM, because presumably the new hardware would check the ROM code hash before loading it and also presumably the ROM code does not have quite as much text messages that can be changed to generate the same hash value, thereby bypassing the security checks.
This may be an obvious question, but given that the code which verifies an IOS image would (presumably) be part of the boot ROM, where would you put the code which verifies the boot ROM? What does it mean to say `the hardware' should check the boot ROM?
I agree with you here. Cisco even ships methods to do a field-upgrade of the rommon on a variety of platforms and linecards. There are numerous challenges when talking about how to prevent these types of updates. I could imagine a case where you leverage the current 'phlashing' stuff to "brick" your router rommon so it won't boot. Once again it gets to the how do you obtain an exploit path to perform these actions on the device? I always have said physical access = "root". Perhaps the path is that oob modem? You need to think about these things, but unless you have a mission dealing with state secrets or your corporate IP (not the protocol) guys treat everything like it is (eg: pharmaceutical companies), you're likely to not notice the router in the closet has a 2 year old bogon filter list installed.
- Jared
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 29 May 2008, Fred Reimer wrote:
The code would presumably be run upon boot from a non-flashable source, which would run the boot ROM code through a check on the crypto chip and only execute it if it passed. You would not put the code that checks the boot ROM on the boot ROM. The new crypto chip would presumably have the initial boot code, which would only be designed to check the boot ROM signature and nothing else so presumably would never need to be replaced and hence would be designed to be non-flashable.
Doesn't this just push the chicken-and-egg problem up the chain one step? The ROMMON would be flashable (among other reasons) because the key used to sign IOS releases should change over the years -- gaining length as cycles get cheaper, being replaced periodically to prevent use of the same key for too long, and perhaps being revoked if it should ever be compromised. If the ROMMON is itself to be verified by a prior, non-flashable ROM, then all the same arguments would call for making its key-list updatable -- and given the time-in-service seen by many such devices, any weakness in that key list would be around for quite some time. - -- Jim Wise jwise@draga.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (NetBSD) iD8DBQFIPsdRq/KRbT0KwbwRAkcmAJ4xOBtANHOc+C/fzL+7PvgWnjp76ACfSGUw 43+1Pq3xWS4MagWzdetZ0ws= =62gJ -----END PGP SIGNATURE-----
New keys, to be stored on the crypto chip, would presumably be delivered in a separately signed package using a master key that would not change (embedded within the chip). Maybe Cisco even doesn't have this key, and would need to send a revocation or new public key to be stored on the chip to the chip manufacturer, who would sign it with the master private key and which then could be delivered in a software update to the system. There are many possibilities, and no crypto scheme is foolproof. That much has been proven. But no, you would not make the on-chip EEPROM of the crypto chip "flashable" in the normal meaning of the word. You would send the chip a pointer to a buffer that contains a signed update key, and the chip itself would verify that signature and only then program the updated key(s). My intention was not to turn nanog into a crypto forum. I'd be much more interested in any unique methods that people use to harden their systems that have not already been widely distributed through vendor or industry best practices. Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS Senior Network Engineer Coleman Technologies, Inc. 954-298-1697
-----Original Message----- From: Jim Wise [mailto:jwise@draga.com] Sent: Thursday, May 29, 2008 11:10 AM To: Fred Reimer Cc: Jared Mauch; nanog@nanog.org Subject: RE: IOS Rookit: the sky isn't falling (yet)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 29 May 2008, Fred Reimer wrote:
The code would presumably be run upon boot from a non-flashable source, which would run the boot ROM code through a check on the crypto chip and only execute it if it passed. You would not put the code that checks the boot ROM on the boot ROM. The new crypto chip would presumably have the initial boot code, which would only be designed to check the boot ROM signature and nothing else so presumably would never need to be replaced and hence would be designed to be non-flashable.
Doesn't this just push the chicken-and-egg problem up the chain one step? The ROMMON would be flashable (among other reasons) because the key used to sign IOS releases should change over the years -- gaining length as cycles get cheaper, being replaced periodically to prevent use of the same key for too long, and perhaps being revoked if it should ever be compromised.
If the ROMMON is itself to be verified by a prior, non-flashable ROM, then all the same arguments would call for making its key-list updatable -- and given the time-in-service seen by many such devices, any weakness in that key list would be around for quite some time.
- -- Jim Wise jwise@draga.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (NetBSD)
iD8DBQFIPsdRq/KRbT0KwbwRAkcmAJ4xOBtANHOc+C/fzL+7PvgWnjp76ACfSGUw 43+1Pq3xWS4MagWzdetZ0ws= =62gJ -----END PGP SIGNATURE-----
here's the slides if anyone hasn't seen http://seclists.org/fulldisclosure/2008/May/att-0668/EuSecWest_presentation_... On Thu, May 29, 2008 at 11:27 AM, Fred Reimer <freimer@ctiusa.com> wrote:
New keys, to be stored on the crypto chip, would presumably be delivered in a separately signed package using a master key that would not change (embedded within the chip). Maybe Cisco even doesn't have this key, and would need to send a revocation or new public key to be stored on the chip to the chip manufacturer, who would sign it with the master private key and which then could be delivered in a software update to the system. There are many possibilities, and no crypto scheme is foolproof. That much has been proven. But no, you would not make the on-chip EEPROM of the crypto chip "flashable" in the normal meaning of the word. You would send the chip a pointer to a buffer that contains a signed update key, and the chip itself would verify that signature and only then program the updated key(s).
My intention was not to turn nanog into a crypto forum. I'd be much more interested in any unique methods that people use to harden their systems that have not already been widely distributed through vendor or industry best practices.
Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS Senior Network Engineer Coleman Technologies, Inc. 954-298-1697
-----Original Message----- From: Jim Wise [mailto:jwise@draga.com] Sent: Thursday, May 29, 2008 11:10 AM To: Fred Reimer Cc: Jared Mauch; nanog@nanog.org Subject: RE: IOS Rookit: the sky isn't falling (yet)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 29 May 2008, Fred Reimer wrote:
The code would presumably be run upon boot from a non-flashable source, which would run the boot ROM code through a check on the crypto chip and only execute it if it passed. You would not put the code that checks the boot ROM on the boot ROM. The new crypto chip would presumably have the initial boot code, which would only be designed to check the boot ROM signature and nothing else so presumably would never need to be replaced and hence would be designed to be non-flashable.
Doesn't this just push the chicken-and-egg problem up the chain one step? The ROMMON would be flashable (among other reasons) because the key used to sign IOS releases should change over the years -- gaining length as cycles get cheaper, being replaced periodically to prevent use of the same key for too long, and perhaps being revoked if it should ever be compromised.
If the ROMMON is itself to be verified by a prior, non-flashable ROM, then all the same arguments would call for making its key-list updatable -- and given the time-in-service seen by many such devices, any weakness in that key list would be around for quite some time.
- -- Jim Wise jwise@draga.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (NetBSD)
iD8DBQFIPsdRq/KRbT0KwbwRAkcmAJ4xOBtANHOc+C/fzL+7PvgWnjp76ACfSGUw 43+1Pq3xWS4MagWzdetZ0ws= =62gJ -----END PGP SIGNATURE-----
On Thu, 29 May 2008 09:18:07 -0400 "Fred Reimer" <freimer@ctiusa.com> wrote:
So the only easy way to attack this is the MD5 hash. We have a know plaintext (the IOS code) and the hash. It is not trivial to be able to make changes in the code and maintain the same hash value, but there has been at least limited success in doing so.
No there has not. There has been considerable success at creating *collisions*; if you don't have a collaborator inside Cisco's build team, that does you no good in this case. There has been *no* success at preimage attacks, which is what we're talking about here. (Aside: I'm on record as saying I wouldn't be surprised if preimage attacks were developed soon by the cryptanalytic community, since people are paying so much more attention to hash functions now, but that hasn't happened yet.) If you do have a collaborator, there is a conceivable attack. Use the collision attack -- that is, the ability to simultaneously produce two files with the same hash -- to generate a genuine IOS image that is nevertheless susceptible to being replaced by a corrupted one. It's a delicate process, though, since even a 1-bit change will completely change the hash output and ruin the collision. You're much better off having your collaborator simply install a back door for you -- and it almost certainly won't be found. See http://www.eecs.berkeley.edu/Pubs/TechRpts/2007/EECS-2007-136.html or Chapter 8 of http://zesty.ca/pubs/yee-phd.pdf --Steve Bellovin, http://www.cs.columbia.edu/~smb
This is not a crypto form, so we shouldn't get deep into the MD5 collision debate, but I didn't say HOW there has been limited success. Sorry if the wording of my message was not clear and implied that all you would need were the plaintext and the hash. Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS Senior Network Engineer Coleman Technologies, Inc. 954-298-1697
-----Original Message----- From: Steven M. Bellovin [mailto:smb@cs.columbia.edu] Sent: Thursday, May 29, 2008 9:43 AM To: Fred Reimer Cc: Gadi Evron; nanog@nanog.org Subject: Re: IOS Rookit: the sky isn't falling (yet)
On Thu, 29 May 2008 09:18:07 -0400 "Fred Reimer" <freimer@ctiusa.com> wrote:
So the only easy way to attack this is the MD5 hash. We have a know plaintext (the IOS code) and the hash. It is not trivial to be able to make changes in the code and maintain the same hash value, but there has been at least limited success in doing so.
No there has not. There has been considerable success at creating *collisions*; if you don't have a collaborator inside Cisco's build team, that does you no good in this case. There has been *no* success at preimage attacks, which is what we're talking about here. (Aside: I'm on record as saying I wouldn't be surprised if preimage attacks were developed soon by the cryptanalytic community, since people are paying so much more attention to hash functions now, but that hasn't happened yet.)
If you do have a collaborator, there is a conceivable attack. Use the collision attack -- that is, the ability to simultaneously produce two files with the same hash -- to generate a genuine IOS image that is nevertheless susceptible to being replaced by a corrupted one. It's a delicate process, though, since even a 1-bit change will completely change the hash output and ruin the collision. You're much better off having your collaborator simply install a back door for you -- and it almost certainly won't be found. See http://www.eecs.berkeley.edu/Pubs/TechRpts/2007/EECS-2007-136.html or Chapter 8 of http://zesty.ca/pubs/yee-phd.pdf
--Steve Bellovin, http://www.cs.columbia.edu/~smb
On Tue, 27 May 2008 Valdis.Kletnieks@vt.edu wrote:
On Tue, 27 May 2008 11:02:32 CDT, Gadi Evron said:
On Tue, 27 May 2008, Jared Mauch wrote:
*yawn*
I guess we will wait for the next one before waking up, than.
No Gadi. What Jared is saying is that there are exactly *ZERO* routers (for some infinitesimally small value of zero) that will get rootkitted that weren't *already* vulnerable to the stuff that Lynn talked about three years ago.
There's basically 2 classes of Cisco routers out there:
1) Ones managed by Jared and similarly clued people, who can quite rightfully yawn because the specter of "IOS rootkits" changes nothing in their actual threat model - they put stuff in place 3 years ago to mitigate "Lynn-style IOS pwnage", and it will stop this just as well. Move along, nothing to see.
2) Ones managed by unclued people. And quite frankly, if Lynn didn't wake them up 3 years ago, this isn't going to wake them up either. Move along, nothing new to see here either.
"60% of routers run by bozos who shouldn't have enable. Film at 11".
*yawn*.
My bad. Sorry Jared.
On Tue, 27 May 2008, Gadi Evron wrote:
Perhaps the above should be simplified.
Running a hacked/modded IOS version is a dangerous prospect.
This seems like such a non-event because what is the exploit path to load the image? There needs to be a primary exploit to load the malware image.
*yawn*
I guess we will wait for the next one before waking up, than.
If you let people load unauthorized images on your equipment, you probably have bigger problems than potential rootkits. It may be a better use of resources to prevent people from installing unauthorized images on your hardware versus debating all the things an unauthorized image could do after it is installed. Other things you could install rootkits on, if you can load unauthorized images on the device: Anything with a CPU and loadable images. Even old fashion printing presses are vulnerable to the old fashion version of a rootkit. If you could replace the printing press plates with unauthorized plates, you could change what the printing press printed. Modifying printing plates is the easy part, getting the unauthorized printing plates on the printing press is the trick.
On Tue, 27 May 2008, Sean Donelan wrote:
On Tue, 27 May 2008, Gadi Evron wrote:
Perhaps the above should be simplified.
Running a hacked/modded IOS version is a dangerous prospect.
This seems like such a non-event because what is the exploit path to load the image? There needs to be a primary exploit to load the malware image.
*yawn*
I guess we will wait for the next one before waking up, than.
If you let people load unauthorized images on your equipment, you probably have bigger problems than potential rootkits. It may be a better use of resources to prevent people from installing unauthorized images on your hardware versus debating all the things an unauthorized image could do after it is installed.
Other things you could install rootkits on, if you can load unauthorized images on the device:
Anything with a CPU and loadable images.
Even old fashion printing presses are vulnerable to the old fashion version of a rootkit. If you could replace the printing press plates with unauthorized plates, you could change what the printing press printed. Modifying printing plates is the easy part, getting the unauthorized printing plates on the printing press is the trick.
Sean, you are right. My point is that these things exist and we should not limit our assessment to what's available in presentations, which is the current rootkit. The next one and the ones after that is what matters. Gadi.
On May 27, 2008, at 12:02 PM, Gadi Evron wrote:
On Tue, 27 May 2008, Jared Mauch wrote:
On May 27, 2008, at 8:42 AM, Alexander Harrowell wrote:
operations on the router as privilege level 15 doesn't allow it and the only alternative is to sniff the traffic export. The combination of rootkits and specially privileged Lawful Intercept functions is a very dangerous one. This was precisely what was exploited in
An alternative rootkit ? Privilege level 16 used by the Lawful Intercept [12] feature could be abused to do some of this too. Or the other way around: use a "patched" IOS to keep an eye on Law Enforcement's the now-legendary and still unsolved Vodafone Greece hack.
Perhaps the above should be simplified.
Running a hacked/modded IOS version is a dangerous prospect.
This seems like such a non-event because what is the exploit path to load the image? There needs to be a primary exploit to load the malware image.
*yawn*
I guess we will wait for the next one before waking up, than.
You seem to be missing the point and I'm concerned that wasting my time attempting to educate you and others on this topic is fruitless, but I will attempt the impossible. Surely you should insure your devices are secured and audit their security. Attack vectors change over time. This case is easily mitigated against if Cisco shipped signed binaries and the platform performed this validation. That's not something unique, but something that is unavailable today. I state again: Running any random code will certainly put you at risk, this continues to be the case for routers in the same way as it is for the millions of infected PCs. I await information on the remote router exploit path and the mitigation strategy you allude to in your above bait. Without compromising the router in the first place, either physically by swapping the image media (hard drive, flash of varying varieties) or remotely with some unnamed and perhaps unfound 0-day exploit, the strategy outlined in this thread is not a viable one. Anyone following a set of "sane" practices, (watching those flash/disk inserted/removed messages in your syslogs and doing image validation will help mitigate the risk). There's alternate cases that have not been outlined here that could prove to be more problematic and cause you to do some incident response but I will not outline those in this public forum.
On Tue, 27 May 2008, Jared Mauch wrote:
On May 27, 2008, at 12:02 PM, Gadi Evron wrote:
On Tue, 27 May 2008, Jared Mauch wrote:
On May 27, 2008, at 8:42 AM, Alexander Harrowell wrote:
operations on the router as privilege level 15 doesn't allow it and the only alternative is to sniff the traffic export. The combination of rootkits and specially privileged Lawful Intercept functions is a very dangerous one. This was precisely what was exploited in
An alternative rootkit ? Privilege level 16 used by the Lawful Intercept [12] feature could be abused to do some of this too. Or the other way around: use a "patched" IOS to keep an eye on Law Enforcement's the now-legendary and still unsolved Vodafone Greece hack.
Perhaps the above should be simplified.
Running a hacked/modded IOS version is a dangerous prospect.
This seems like such a non-event because what is the exploit path to load the image? There needs to be a primary exploit to load the malware image.
*yawn*
I guess we will wait for the next one before waking up, than.
You seem to be missing the point and I'm concerned that wasting my time attempting to educate you and others on this topic is fruitless, but I will attempt the impossible.
Surely you should insure your devices are secured and audit their security. Attack vectors change over time. This case is easily mitigated against if Cisco shipped signed binaries and the platform performed this validation. That's not something unique, but something that is unavailable today.
Then you'd use the memory or manipulate the validation. It's a cat and mouse game the same as any other. I disagree with you there, although these are certainly good steps for Cisco to take.
I state again: Running any random code will certainly put you at risk, this continues to be the case for routers in the same way as it is for the millions of infected PCs.
I await information on the remote router exploit path and the mitigation strategy you allude to in your above bait. Without compromising the router in the first place, either physically by swapping the image media (hard drive, flash of varying varieties) or remotely with some unnamed and perhaps unfound 0-day exploit, the strategy outlined in this thread is not a viable one.
I allude to nothing, Jared.
Anyone following a set of "sane" practices, (watching those flash/disk inserted/removed messages in your syslogs and doing image validation will help mitigate the risk). There's alternate cases that have not been outlined here that could prove to be more problematic and cause you to do some incident response but I will not outline those in this public forum.
Thanks for clarifying these points. I am concerned about how far current methods can take an operator trying to detect badness. Gadi.
This seems like such a non-event because what is the exploit path to load the image? There needs to be a primary exploit to load the malware image.
Hmmm. Get a job servicing/installing data centre HVAC systems, wait until you get called out to a mostly empty data center, lift some floor tiles or change a flash with tongs through a wire cage, or whatever. Maybe make some "fog" in the room to block the security cameras while you do your work. Maybe bribe the security guard to look the other way, or just bribe the NOC employees. There are hundreds of ways for a primary exploit to happen. The Internet data center may not be the primary target of the people who try these things, i.e. Cisco's main customer base is the enterprise, not the ISP. The fact is that there are more and more reasons why someone would go to all the trouble of exploiting one or two routers in this way. Do you have the processes and systems to demonstrate that it has not happened already? --Michael Dillon
interesting, thanks for the summary.. until the presentation becomes available On Tue, May 27, 2008 at 3:03 AM, Nicolas FISCHBACH <nicolist@securite.org> wrote:
I finally got to see Topo's presentation this week-end at PH-Neutral and discuss it with him and FX.
Given that the slides aren't online yet [1], that Core hasn't published Topo's technical paper on their website [2] yet either, and that I'm done replying to direct inquiries about it [3], here's a summary of the IOS rootkit saga and its impact on the Service Provider community (from my point of view :)
Topo spent a lot of time (and if you ever loaded an IOS image in IDA you know what I'm talking about) analyzing strings and functions in IOS. In his proof of concept he located the code doing the password check and adds a trampoline to his backdoor code (by saving paramaters, glueing the two codes together, doing the "new" password check and returning properly to the main code path). Nice lesson on 101 hooking on IOS.
The (oversimplified) modus operandi is pretty straight forward: take an image, decompress it, have his tool locate the function and later patch it, add his code by overwriting large strings, (re)compress the image and (re)calculate/fix the checksums. Pretty neat. The fact that he doesn't do basic binary patching makes the approach portable and not architecture, version or feature set specific.
This image then needs to be uploaded to the router and the device need to be reloaded. This backdoor is persistent (vs the old backdoor trick using the TCL shell [4] which wasn't - or if you want to turn it into a non-volatile one it was easy to detect as in clear text in the startup/running configuration).
An alternative approach is to use gdb on the router (and combine it with a TCL script to make it easier) and patch on the fly. This is non-persistent, but some people don't wan't to leave traces as large as an IOS image behind :) Or another alternative approach: network boot the router via TFTP.
At the end of the day this is nothing new from a rootkit technology point of view, but it's in the IOS/router world. He deserves credit to actually have researched this in deep and managed to make it work (it's much more difficult to achieve this on a mostly undocumented and large binary than on common OSes). Respect.
What's the best way to actually test this when you don't have the HW you ask ? Dynamips [9] is the answer.
As long as the rootkit isn't too advanced and e.g. also hooks the write/copy functions (e.g. an attacker could store the image diff on the system and play a "proper" memory dump or proper IOS back when you write core/copy to TFTP) then FX's CIR[7] is the forensics tool of choice. On platforms where the IOS image is stored on an external flash card forensics may be easier.
Here's [8] a "screenshot" of CIR vs Topo.
So what's the impact today ? Topo's proof of concept doesn't bypass ACLs (rACLs, VTY ACLs), AAA, etc [yet], requires enable rights, a new image and a reload (or enable only if you do gdb-on-the-fly patching). In summary it's "noisy" and unless you bought the router on an auction site and/or download IOS from "alternative" sources) you should notice (or probably deserve to get owned :)
See the Cisco PSIRT response for best current practices on securing routers [10] and my old forensics presentation [3].
In the past FX [5] and Mike Lynn [6] proved that code execution is doable. This is a different approach. Can it be combined ? Probably. It is much more complex ? Yes. Is it going to be architecture specific ? Probably.
Future developments ? I'm surprised people still focus on the IOS side of things and don't attack the bootrom code as it's smaller and usually never changed unless you bring in some new/unsupported hardware/features. IOS-XR is probably going to become a target too as it makes some of these things easier [11] but code signing may have to be broken/bypassed first. This has been done on other devices, so it's just one more layer to attack.
An alternative rootkit ? Privilege level 16 used by the Lawful Intercept [12] feature could be abused to do some of this too. Or the other way around: use a "patched" IOS to keep an eye on Law Enforcement's operations on the router as privilege level 15 doesn't allow it and the only alternative is to sniff the traffic export.
I've probably missed some stuff (and got some stuff wrong), but this summary became way too long already and it's late. Feedback welcome!
[1] Dragos should post them soon here: http://www.eusecwest.com/ [2] Watch http://www.coresecurity.com/?module=ContentMod&action=news&id=papers [3] Google "IOS rootkit" used to return the presentation below as first hit "Cisco Router Forensics" - http://www.securite.org/presentations/secip/ [4] http://seclists.org/bugtraq/2007/Nov/0384.html [5] http://www.phenoelit-us.org/ultimaratio/index.html http://www.milw0rm.com/exploits/77 [6] http://cryptome.org/lynn-cisco.pdf [7] http://cir.recurity.com/ [8] http://www.securite.org/nico/XP/CIRvsTopo.jpg [9] http://www.ipflow.utc.fr/index.php/Cisco_7200_Simulator [10]
http://www.cisco.com/en/US/products/products_security_response09186a00809977... [11] http://lists.darklab.org/pipermail/darklab/2005-August/000029.html [12] http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/lawf_int.html
Nico. -- Nicolas FISCHBACH Senior Manager - Network Engineering/Security - COLT Telecom e:(nico@securite.org) w:<http://www.securite.org/nico/>
participants (18)
-
Adrian Chadd -
Alexander Harrowell -
Chris Grundemann -
Christian -
Christopher Morrow -
Dorn Hetzel -
Fred Reimer -
Gadi Evron -
goemon＠anime.net -
Jared Mauch -
Jim Wise -
Kevin Oberman -
michael.dillon＠bt.com -
Nicolas FISCHBACH -
Sargun Dhillon -
Sean Donelan -
Steven M. Bellovin -
Valdis.Kletnieks＠vt.edu