When implementing Cisco Wireless network infrastructure Enno and Daniel got the impression that, security wise, these systems smell.

First part of the presentation focuses on what a typical implementation looks like.

There are three generations:
1.    Structured Wireless-Aware Networks (SWAN)
2.    Based on managed APs and LWAPP (After acquiring Airport)
3.    Cisco Unified Wireless Network

The talk focuses on generation one and three.

The are a couple of attack paths: traffic in transit, cryptographics and against components.

First up is SWAN. It mainly runs on WLCCP protocol messages, this protocol is proprietary, so the patents are needed to discover the inner workings and the deviations from the patent.

The key management is arranged by Cisco’s proprietary key management framework called Cisco Centralized Key Management (CCKM). This framework allows the key material for clients from one access point to the other.

One of the properties of the protocol is the selection of the WDS Masters that controls all communication between the APs.
He communication  between the APs is authenticated by means of LEAP. The security of LEAP is debatable at best. And Cisco’s fix, deriving two additional keys based on the first key is debatable too.

Management interfaces are the Achilles’ heel of many systems.

So what do you need for a practical attack against APs? If you can get to the AP’s management interface, you can identify it by identifying WLCCP speakers, sniff the intra AP traffic and crack the LEAP secret. Then you can evict the WDS master if necessary.

Daniel next demoed the attack. He used Loki to sniff the backbone interface to identify the WDS master. Loki can now be used to create a new WDS master but inserting a new WDS master. The master priority is configurable up to 254, but the protocol can handle a value to 255, so you can always win this election.
Next Loki can be used to brute force the detected WDS password and the revealed password can be used to derive the additional security keys.

Even though there are some parts of the crypto space that smells, Enno and Daniel where not able to find practical exploits here.

Management interfaces however are another story.

SNMP is a good friend, especially if people forget to reset their community strings. The SNMP interface does not allow you to reset passwords of existing users, but it does allow you to create administrative users.

The web interface of Cisco WLAN management tooling is web based, with all the classical web based attacks like Cross Site Scripting.

Enno demoed a web based attack. Intercepting a request to the web based interface with burpsuite and rewriting the request he was able to trigger a buffer overflow in the wireless management appliance. This makes you wander what would happen if you run a fuzzer against it.

Key points to take away:
•    “Enterprise WLAN solutions” might be complex beasts
•    There many be not so obvious vulnerabilities
•    Use common sense when deploying
•    The problems outlined are not Cisco specific

The majority of problems are based on management interface. They should never be publicly exposed.

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.

Slowloris (name after the slow moving primates is a httpd DoS tool written by RSnake of ha.ckers. It works by tying up the httpd worker processes by slowly sending more and more headers of an httpd request.

Nkiller2 is a TCP/IP DoS attack tool which was published in issue 66 of Phrack magazine. It works by tying up httpd worker processes by requesting a file then stalling, mimicking the behavior of a client with full TCP/IP receive buffers.

Cisco CSS is a load balancer produced by Cisco.

In nearly all of the infrastructures built by my employer Schuberg Philis, the web servers are located behind a load balancer. In most cases a Cisco CSS. Because some of our customers were worried, I set out together with my colleague Gert Kremer to see if having a CSS load balancer in front of the web server provides any protection.

Slowloris

First we just had to try and find out what Slowloris did with an unprotected Apache server. The first video shows what happens when you run slowloris against a webserver. The window on the top left shows the number of apache processes, the top right window shows the scoreboard. This shows what the http processes are actually doing. The bottom window shows the slowloris output.

Slowloris vs Apache (No load balancer)

Click here to view the embedded video.

When slowloris is using 100 sockets, you can see 100 httpd workers in state “R”, meaning it is reading requests. The same is the case when running with 200 and 250 sockets. When running with 300 sockets the apache worker processes pool is exhausted and the web server can no longer service requests.

Slowloris vs Apache behind a Cisco CSS load balancer

Click here to view the embedded video.

Slowloris is running against the webserver with 3000 sockets (should be more then enough). As you can see on the top two windows the load balancer does not forward any of the incomplete requests to the webserver. We have stress tested the loadbancer up to 10,000 sockets and it had no effect on the loadbancer.

NKiller

Nkiller vs Apache (No load balancer)

Click here to view the embedded video.

In the video we see for windows. Top left and right show the number of apache processes and the apache dashboard. The middle window displays the NKiller output and the bottom window TCPdump.

When NKiller starts we see the it exhausts the httpd workers processes by putting them in a state where they are hanging while writing their reply back to the client.
Nkiller vs Apache behind a CSS load balancer

Click here to view the embedded video.

When NKiller was used against a server protected by a Cisco CSS load balancer the packets received from the load balancer do not match the expections of the Nkiller tool and the tool crashed producing a segmentation fault.