Exploit Available for Cisco IOS Vulnerability

GNUman writes "Cisco's IOS vulnerability, posted by Slashdot and CERT, has now a published exploit available, as reported recently by CERT. While there are some some articles claiming that the Internet survived a major flaw, maybe with a publicly available exploit could script kiddies start creating havock?. jerw134 wanted to start a pool to find out when the exploit would be publicly available, here's the answer."

Re:Great...

[NerveGas]

The patch is extremely easy to come by. Do a "sh ver" on your router, and send the output to [e-mail], and ask for an updated IOS. They'll likely be back to you within an hour or so.

steve

Re:Tell me why

[jht]

Gee, I just had to call TAC up and give them the serial number to get in (our router doesn't have a service contract). Within an hour, I had a callback from the engineer who was given my case and an e-mail in my inbox looking for the specific info needed (the version of IOS I was running and the exact name of the binary - all produced by "sh ver").

After I got him the info, it was only a few minutes before the patch link was sent to me for download. The whole thing was done before lunch today - and that's for a little piss-ant customer with no service contract and a single router.

I think that's about as simple as it needs to be, personally. There's different versions of IOS for different devices, and all sorts of supported code revisions to deal with - it's not like Windows where you have a core version and service packs/hotfixes you may or may not have applied in random combination. Typically, if you have a Cisco router and it's working you'll only want to apply the minimum possible fix to the specific version you're running. So it's a pretty darned complex upgrade matrix. I, for one, am perfectly happy to let TAC guide me through it.

Protocol Independent Multicast?

[jkc120]

If I'm reading this page [cisco.com] correctly, the protocol type of the packet that causes the problem appears to be the PIM protocol:

grep 103 /etc/protocols
pim 103 PIM # Protocol Independent Multicast

Re:hmm, and suddenly today roadrunner is dog-slow.

[Elminst]

Today?
RR in upstate NY has bee dog-ass slow for 2 days straight now... despite the "network status" page being filled with "area down for cable maintenance/upgrades" for 3 days.
Oh look.. it says there's nothing wrong in my area.. bullshit!

Re:Protocol Independent Multicast?

[XenoPhage]

Actually, it's 4 protocols ... 53, 55, 77, and 103.. Any one of these can kill the interface.

I've already posted a lot of information regarding this on the Nanog list.. but the "exploit" that has been release (shadowchode) isn't required to exploit this bug .. hping can do this just as easily..

Re:Where is the Exploit ?

[grokBoy]

You can find the original exploit here [netsys.com].

enormous ddos potential - patch right away!

[Brian Ristuccia]

Imagine your typical packet kiddie running dozens of instances of the following pseudocode on his farm of a few hundred trojaned boxes:

while (1) {

$x = random(255);
$y = random(255);
$z = random(255);
@hops = traceroute("$x.$y.$z.1");
for $hopnum (5..@#hops) { # don't kill nearby routers
system("shadowchode", $hops[$hopnum], 255 - $hopnum);

}

}

If you haven't patched already - do it now.

Re:Exploits et al.,

[slamb]

Umm, apparently some moderators don't realize this is a troll. The things he is talking about aren't even remotely relevant to this exploit, which is at a much lower level. And it's not even consistent:

In this post, he said:

Other simple techniques like removing all interpreted languages (java, Visual Basic, c# etc.) and replacing them with low level compiled code (C, of course) has generated speed increases upwards of 25% and also increase the security of the site as a side effect.

Writing websites in C is generally a very bad idea. It does horrible things to the security - introduces buffer overflow problems. And the speed increase, when it even exists (Java's performance is better than most people think), is not worth the extra programmer time.

In an older post [slashdot.org], he said:

Lets face it, all one has to do is take a quick look at the demand for certain skill sets on the net to get a pretty good feel for what's relevant today and I'm not sure c++ is anywhere on that radar screen. Most of my work as of late has been all Java and c#, with some legacy C programming done (on low level systems only of course, nobody would pay someone by the hour to have app level work done in C these days)

...so, apparently, he mostly uses the interpreted languages he just dissed stupidly.

The rest of the post is just stupid buzzwords:

For instance I was able to reduce the load time of a very well known and heavily traveled Fortune 500 website by moving all the graphics to black and white only, as they load on an average of Olog(n) faster than color graphics (where n is the number of pixels in the color graphic) thusly improving their UHCRF (unique hit customer retention factor) ratio by 35%!! I won't brag about the $10,000 bonus check I received from hitting that benchmark... heh.

More colors = more information = more time to download, but that O(log n) is stupid and wrong. And the other stuff is even more gibberish. This exploit has nothing to do with web applications, anyway.

MOD PARENT DOWN

[Penguinshit]

Relax. This news has been going around the various vulnerability mailing lists for over a week now. Slashdot is late to the party (rightfully so).

The discoverer notified Cisco and everyone else, but held back on the exploit code until Cisco had a chance to work on it. Now that the word is out as well as the patch, don't waste time here when you should be patching your CATs (or looking for a new job).

sheesh.

Re:Importance of shaming they who published the ex

[Penguinshit]

You don't read a lot, do you (or don't read the correct mailing lists)? The notification regarding this exploit went out some time ago. The discoverer worked with Cisco, releasing a notification regarding the exploit and some general information regarding cause and severity.

THEY HELD BACK ON THE EXPLOIT CODE UNTIL CISCO COULD DEVISE A PATCH.

Larger customers (ISPs, etc.) were taken care of in advance of the general public notification. Independent parties were no doubt already working on their own exploit code. It's quite common to release the patch and the exploit code at the same time; in fact, some parties prefer to release 0-Day exploit code... let's just be glad these particular folks didn't.

Here is the exploit the article is talking about

[saint10]

A big middle finger to all of the idiots that don't belive in full disclosure:

Cisco IOS Exploit [idefense.com]

You can also easily create the exploit using hping2.

Re:Great...

[Pii]

Most Cisco code updates do not require TAC intervention, or email swapping. This is an isolated case.

Also, I haven't had to mail TAC yet for any of the routers (30, and counting) I've had to upgrade. My new code has been available throught the traditional channel (Cisco's Software Center).

People that are having to mail the TAC are doing so because they have no support contract (thus, no access to the Cisco Software Center), or because the code for their specific platform doesn't appear to be available through the Software center.

Source for shadowcode Exploit

[pope1]

In case you want to test this on your own routers (worked against my 1005.. sadly :P)

Heres a link [chiyocon.com] to the source in b64 format, you can extract it with:

openssl base64 -d -in cisco.txt -out cisco.tgz

Happy testing!

The fix...

[robpoe]

The following access list is specifically designed to block attack traffic. Note that the attack traffic can include spoofed source addresses. This access list should be applied to all interfaces of the device, and should include topology-specific filters. This could include filtering routing protocol traffic, management protocols, and traffic destined for the internal network. Protocol 103 is Protocol Independent Multicast (PIM), which is a commonly deployed application in multicast networks.

Interfaces with PIM enabled have not been found to be vulnerable to exploit traffic with protocol
103; PIM traffic may be permitted to those select devices.

access-list 101 deny 53 any any
access-list 101 deny 55 any any
access-list 101 deny 77 any any
access-list 101 deny 103 any any
!--- insert any other previously applied ACL entries here
!--- you must permit other protocols through to allow normal
!--- traffic -- previously defined permit lists will work
!--- or you may use the permit ip any any shown here
access-list 101 permit ip any any

Re:updates

[Pii]

If your enterprise is such that you have a few hundred routers, then I'd certainly hope that you'd have ponied up for Cisco Works, which would then allow you to push out the upgrades in an automated manner.

Of course, there are also freely available perl and expect scripts out there that would allow you to do the same thing.

Re:Great...

[NerveGas]

You have either a bizarre definition of the phrase "extremely easy" or very little perspective on how easy it is to patch many other products.

I sent one email, and in return, got all of the IOS versions that I needed for my routers. I'd definitely say that was "extremely easy".

Maybe you mean that I can just tell Linus what kind of computer I have, and he'll send me over a tarball of 2.4.21, pre-configured with the options I'd like?

you don't have to email somebody and wait an hour to get the exploit

If you have a CCO account, then you don't have to wait an hour, you log in and pick it up. Super-mega-fabuloso-easy.

steve

Re:Great...

[NerveGas]

There are various channels from which to get the IOS. If you have a CCO account and know which version you want/need, you just log in and download it. There are also other ways of getting it, but as a "last-ditch" (or "too-lazy") method, you can email their support group directly.

steve

Re:Contact your network company

[pyite]

Yes, and some people do not apply ACLs to their core networks due to the fact that cores are supposed to be extremely fast. In this case, an update can be said to be needed.

Re:Great...

[Pii]

That'd be great, 'cept there are about 30 different version of code that run on any given router platform, at each release level.

You have a Cisco 2610...

What Feature pack?

• ENTERPRISE PLUS
• ENTERPRISE PLUS IPSEC 3DES
• ENTERPRISE PLUS IPSEC 56
• ENTERPRISE/FW/IDS PLUS IPSEC 3DES
• ENTERPRISE/FW/IDS PLUS IPSEC 56
• ENTERPRISE/SNASW PLUS
• ENTERPRISE/SNASW PLUS IPSEC 3DES
• ENTERPRISE/SNASW PLUS IPSEC 56
• IP
• IP PLUS
• IP PLUS IPSEC 3DES
• IP PLUS IPSEC 56
• IP/FW/IDS
• IP/FW/IDS PLUS IPSEC 3DES
• IP/FW/IDS PLUS IPSEC 56
• IP/H323
• IP/IPX/AT/DEC
• IP/IPX/AT/DEC PLUS
• IP/IPX/AT/DEC/FW/IDS PLUS
• REMOTE ACCESS SERVER

That's just the available images for the 2610, 12.1(20)...

Re:Contact your network company

[dirvish]

The suggested ACL settings break fast switching...so ACL is not the best solution for many.

Re:I dont get it.....

[Anonymous Coward]

They refer to protocol 53 (swipe), not port 53 (domain).

Re:Contact your network company

[Florian Weimer]

Yes, and some people do not apply ACLs to their core networks due to the fact that cores are supposed to be extremely fast. In this case, an update can be said to be needed.

Huh? It's cheaper to drop a packet at the process switching level than to actually forward it to the process that implements the corresponding service.

We are talking about packets targeted at the router, and filters for them are not necessarily in the forwarding path (they can be implemented there to protect the main CPU(s) from DDOS attacks, of course). For forwarded packets, you are correct that this is problematic on core routers, e.g. very few GSR linecards support more than a few dozen ACL entries per interface, some do not support any filters at all.

Re:Contact your network company

[Florian Weimer]

The suggested ACL settings break fast switching...so ACL is not the best solution for many.

I'm not sure what you are talking about. "Fast switching" is an obsolete Cisco marketing. Maybe this is an accident and you allude to the possibility that filters decrease forwarding performance. However, quite a lot Cisco routers support either wirespeed ACLs or specific ACLs for traffic directed at the router (which do not impact forwarding performance).

Re:Contact your network company

[dirvish]

No, fast switching is alive and well:

http://www.cisco.com/en/US/products/sw/iosswrel/ps 1831/products_configuration_guide_chapter09186a008 00ca6c8.html">http://www.cisco.com/en/US/products/ sw/iosswrel/ps1831/products_configuration_guide_ch apter09186a00800ca6c8.html [cisco.com]

http://www.networkcomputing.com/902/902sp2.html [networkcomputing.com]

http://www.cisco.com/univercd/cc/td/doc/product/so ftware/ios121/121cgcr/switch_c/xcprt1/xcdipsp.htm [cisco.com]

http://www.faqs.org/faqs/cisco-networking-faq/sect ion-20.html [faqs.org]

Re:Great...

[doogles]

Anyone else gone through hell today trying to get the patch from Cisco?

ftp://user:[e-mail]/cisco/ios/