GLOBAL BATTLE - KIDS TO SAVE THE WORLD SERIES (Explore #4) a CC, non-commercial, no derived works image from JOHN CORVERA's flickr photostream

This talk is a follow up of Felix’ talk at Black Hat Europe which I blogged about earlier here (http://www.cupfighter.net/index.php/2010/04/blackhateu-fx/) marking the release of the tool BlitzAbleiter.

One of the new point highlighted is that his work is not just of interest to normal users that are running flash content, but also to corporations that serve pre-compiled flash advertisements that they do not want to be infected with malware or other unwanted behaviour.
For the release of Blitzableiter Felix has chosen to integrate with NoScript. If you have the latest version of NoScript, you allready have BlitzAbleiter.
Next Felix actually demoed BlitzAbleiter by using it to stop some in the wild Flash exploits.

I managed to speak to Felix in a more informal setting later and he pointed out that there are two major differences between BlitzAbleiter as presented in Barcelona and the current version. BlitzAbleiter now support both the version 1 and version 2 Flash virtual machines. Besides that the code quality of the tool is now at such a level that it is actually a usable tool that can be released to the public.

The name BlitzAbleiter is the German word for lightning rod, because it has the potential to turn harfull Flash into harmless tunder.

The first part of his presentation explained why routers are interesting targets (they are in the core), but also why routers are not actually exploited that much. One of the reasons is that the attack surface of router is quite small because routers don’t expose that much services to a truly remote attacker and are rarely used as clients.

The exception to the rule is “cisco-sa-20070124-crafted-ip-option” which is a remotely exploitable bug that causes a stack overflow on the router. Since “nobody ever updates router software” this vulnerability is still very much alive.

But routers need to support more and more, like IPv6, VoIP, XML configuration interface, luckily most services off.

Writing exploits for Cisco IOS is hard because it is not a real OS, but a single ELF binary. It is not based on a real OS we know hoe to exploit. Its only option to recover from a critical fault is a full reboot.

Another thing that makes exploitation hard is the memory layout. It is different from each single IOS version that it out there, and there are quite a few, currently there are over 270,000 different IOS images known by Cisco and you cannot get the version number remotely.

Best bet for getting a reliable return address for router exploitation is Rommon, the routers bios which loads the IOS and then remains in memory. It is at a fix address and there are big pools of the same versions present on the internet.

Unlike his talk at BlackHat Felix actually showed how the crafted ip option exploit can be used to get working reliable exploit. But since IOS is not an OS you need to get away with it without killing the router. If the stack is not completely overwritten, the return registers remain in tack and thus can be used to reliably return. His method has one drawback, in order for it to work, you need to know the version, but it is not remotely identifiable.

As an alternative there are code similarities in IOS images, but this still has problems.

Felix also made progress on shell code, he showed code that would cause the password evaluation function to always return true.

How do you protect your router?
•    Have faith.
•    Don’t allow people to talk to your router
•    Protect your routing protocols
•    Don’t run services on routers
•    Treat your service cards as the linux machines they are

Running Rancid helps, modification of the data structures show up here.

Turn crash dumping on, this will make sure you keep evidence of any attacks.

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.