IOS Rookit: the sky isn't falling (yet)

Mailman List Mirror (Read Only)
1

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 :slight_smile:

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 :slight_smile:
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 :slight_smile:

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_response09186a0080997783.html
[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.

2

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

3

interesting, thanks for the summary.. until the presentation becomes
available

4

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

5

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

6

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.

7

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*.

8

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? :slight_smile:

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

9

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

10

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.

11

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.

12

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? :slight_smile:

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

13

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

14

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...

15

What you want is cisco hardware that verifies firmware signatures in hardware.

-Dan

16

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. :wink:

17

goemon@anime.net wrote:

18

Of course, how do you know your hardware hasn't been compromised?

http://www.usdoj.gov/opa/pr/2008/February/08_crm_150.html

19

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

20

> 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?