Cupfighter.net

I arrived late, but talk hadn’t started unfortunately it did mean standing room only.

FX had a cool feature in his presentation; every slide was accompanied by a BlackHat-O-Meter. Works like the base and acid scale. Corporate suite-and-tie types should stay with slides that have the meter all the way on the top, CISSP should be able to grasp the details of slides that are ranked somewhere in the middle, real Hackers could also grasp bottom of the scale slides.

FX’s first words are comforting, there is not so much real world router ownage going on. Mis-configuration, insider attacks, etc. are much more common.

However, infrastructures are what you want to own, so why don’t we see this more often? Because practical exploits are hard.

There are not much vulnerabilities in routers. In 2008 only 14 vulnerabilities where published for Cisco IOS. Juniper only reported a memory leak and a OpenSSL issue. Nothing was disclosed by Nortel Networks.

Because of the mindset of the people that report these issues, vulnerabilities are often classified as functional issues; e.g. “malformed packet crashes router”

Why are routers often not vulnerable?

• Most routers don’t run network services. If they do, find a new network administrator.
• Those functionalities exposed are pretty secure or too simple to be vulnerable. FX: “RIP is so simple Cisco can’t even fuck it up”
• However if you are in the same multicast domain, the router is in trouble.
• “You should not accept any routing information from unknown hosts.”
• Routers are rarely used as clients.

However, the landscape changes:

• IP v6
• VoIP
• Lawfull interception
• SSL VPN
• Web service routing
• XML-PI
• Web Service Management

All these servers either make the router inspect and manipulate packets (ipv6 has per router headers) or let services run on routers.

Luckily adoption is still slow. Network admins don’t want application level functionality on their devices.

Router Transit vulnerabilities

This is the hackers dream: A vulnerability that gets triggered as and when a packet gets forwarded. However this is hard because routers try to avoid inspecting traffic because it takes CPU cycles. Some traffic must however be inspected like IPv6 and Source Routed packets.

Exploiting a Juniper router is easier then exploiting a Cisco IOS device, because Junos is basically FreeBSD. Exploiting a Cisco Service card is also easier because they also run Linux.

Easy ones: Unix based routers (e.g. ADSL routers, Junipers)

The Hard One: Cisco IOS because it is a single large binary program (ELF) running directly on the main CPU.

Accoording to the Cisco COC website, there are current 272722 different IOS images all with a different memory layout. This makes reliable exploitation very hard. Cisco’s chaotic build process causes more memory entropy then ASLR.

FX showed that using various techniques you can actually execute code on a router using the Rommon router bios code that is still loaded on the router from when it booted up. Rommon is aways loaded in the same location and there are far less versions of Rommon. Plus, nobody ever updates it. Unfortunatly you can only guess the rommon version and not remotely fingerprint it.

So back to the drawing board. Analysis of newer IOS binaries shows that there are similarities between IOS versions so the same exploit might be possible with IOS. Currently the pro’s and con’s of using IOS vs. Rommon are:

Rommon: 30% change of success, cannot be fingerprinted

IOS: approx 15% change of success, can be fingerprinted

But you also need to get away with exploiting a router and inserting shell code without stopping the router. This is hard because the single binary image does not have a pre-emptive scheduler an the memory layout is unknown.

FX showed techniques for this as well, which will involve a second stage loader. This is however still work in progress.

Protection: So what can we do against it?

• Prevent the router from receiving traffic
• Protect protocol update.
• Don’t run stuff on routers.
• Monitor service modules independently.
• Use RANCID to monitor configuration changes
• Configure Core Dumping (http://cir.recurity-labs.com wiki)
• Complain to Cisco and other vendors about stable upgrade paths.

It is scary to think that the best protection we have against Cisco attacks is the security through obscurity created by Cisco’s hampered build process.