Cisco buffer overflow vulnerability with remote code execution | Hacker News Reader

Cisco buffer overflow vulnerability with remote code execution

tools.cisco.com

111 pointssilenteh20 comments

Here a nice explanation of the vulnerability: https://blog.exodusintel.com/2016/02/10/firewall-hacking/

There is also a Snort signature to detect attempts to exploit this vulnerability.

Cisco was also rushed to release the fix, as all of the new builds are tagged 'interim' and warn users that they have bugs and stability problems that will be fixed later. Most notably, several issues with ASA Clustering were found in the new builds. So you're damned if you do, damned if you don't.

Edit...this is wrong-> It's specific to Cisco ASA firewalls with a version level < 9.1(7), which was released in January of 2015.

Edit: Gelob, below, is right. There's a really unfortunate "read more" link that hides the important bits on Cisco's documentation and caused my confusion.

That isn't true. There are versions of 9.2.x, 9.3.x etc that are vulnerable per the documentation. 9.1.7 is the only firmware released before this was announced (jan 18th) that contains a fix. Every other software version is vulnerable and requires an upgrade.

Given the tendency for large enterprises to not upgrade unless there is time to do a full regression test, and then to prioritize creating new features over system maintenance, I wouldn't assume that means that there aren't quite a few of those still out there.

People who have firewall needs and no skills hire people who know what Cisco products are, get someone to implement an ASA for them, and then it sits for years without any software updates. Maybe a rule update every now and then, but definitely no software updates.

Perhaps most do but I see a different trend these days. "The network" is a lot more important now since so many things are cloud-based.

Our networking group automated a deployment for the fix and contacted everyone that has ever bought an ASA from our company and updated them. We have ~400 ASAs across the country still have < 50 to go. There are still a few stragglers and the older ASAs need a bit more TLC.

Many of those clients have a maintenance agreement with us that includes these sorts of things and changes. All of them were updated and tested within 24 hours.

We did the same thing for the Juniper exploits (albeit we only had a handful).

EDIT: typos

I can think of at least 8 of my clients (between 500 and 15000 employees, with probably 100 ASAs total) still on ASA version 8, much less 9. For some, the more critical in infrastructure, the less they want to update.

Here's an overview of devices that are running IKE on the Internet at the moment: https://www.shodan.io/report/h2Naw1fd

As someone who used to work at Cisco, I'm not surprised. Everything is coded in C, and there are memory leaks all over the place because releases are made before most of these bugs are fixed.

> Note: Only traffic directed to the affected system can be used to exploit this vulnerability.

I'm confused, how else would the system be compromised, by directing traffic at the moon?

Running an EOL ASA in colo on v8.2. Have been holding out due to the post-v8.2 changes to NAT. Looks like you need a SmartNET contract to get the fix, unfortunate, many legacy devices will left vulnerable as a result.

Well, there goes the weekend...

You don't need a SmartNET contract, but...

We own affected hardware and don't have a support contract. It took me about four hours working my way through Cisco customer and tech support to get updated. Now that the interim patch is applied (complete with bugs mentioned elsewhere in this thread?), it doesn't sound like we'll easily be able to get a bug-free update at a later date. So while we're hopefully safe, we might not be stable.

Early on in the process (after 2-3 email iterations) their customer support called me to say we weren't eligible for a fix because we didn't have a support contract. I'd mentioned in my initial request that we had no contract but also pointed out that the advisory said we didn't need one. I had also provided a link to the advisory in my initial request, so that should not have been an issue. I was then told my request was "very confusing".

Once I finally convinced them we were allowed the update and verified the serial number of our hardware, I was thankfully forward on to tech support. They then checked our firmware version and I was supplied with a patch download URL quite quickly. The actual download was hampered in several ways by their poor website (registration required, browser autocomplete and cut and paste caused their JS validation to fail, and I couldn't get it to work with any browser other than IE). Once I finally had the patch, it applied without issue.

In short - the patch process was long, frustrating, complex, and as a small business owner makes me never want to ever, ever deal with Cisco products again.

Just called Cisco TAC and am heading down the same road shortly ;-)

I'm going to renew SmartNET not for this particular vulnerability but for simply getting over the NAT hump from to 8.2 to 8.3 (and whatever other gotchas have come up between 8.2 and latest 9.x). Cisco TAC has been pretty awesome in the past, definitely don't trust myself to navigate the upgrade path in production.

That's why us Cisco guys get paid the big bucks. :)

P.S. There's also a public, super-duper secret FTP server you can log into with your shiny new Cisco credentials. If it's still around, that is, I fortunately haven't had to grab any images in a long time (yay for junior network guys).

It does seem that Cisco will provide updates if customers don't have a valid SmartNET contract. From the vulnerability disclosure:

> Customers Without Service Contracts > Customers who purchase directly from Cisco but do not hold a Cisco service contract and customers who make purchases through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should obtain upgrades by contacting the Cisco Technical Assistance Center (TAC): http://www.cisco.com/en/US/support/tsd_cisco_worldwide_conta... > Customers should have the product serial number available and be prepared to provide the URL of this advisory as evidence of entitlement to a free upgrade.

Thanks, I missed that, just followed:

> Products > Security > Firewalls > Adaptive Security Appliances (ASA) > ASA 5500-X Series Firewalls > <your Cisco ASA model> > Software on Chassis > Adaptive Security Appliance (ASA) Software

and was prompted that an active service contract is required. Not that I'm opposed, it's the first thing I'll do prior to upgrading (since 8.2 to 8.3 migration looks non-trivial due to NAT changes, and have no clue what has transpired between 8.3. and 9.1).

Of course this is obviously a sign to just upgrade the hardware and get off the EOL train.

They mean just what they said: "traffic directed TO the affected system" (emphasis mine).

If you're not used to dealing with routers on a regular basis, that may not make sense.

Then you realize that there's also traffic passing through the system (i.e., being forwarded).

Basically, the key difference is that only UDP packets with a destination IP address belonging to the firewall can trigger the vulnerability. UDP packets with a destination IP address belonging to something else (e.g., a server behind the firewall) that simply pass through the router will not trigger it.

Does that help clarify it a bit?

I think they're suggesting that someone snooping the encrypted traffic coming from the ASA couldn't leverage this vulnerability for easier decryption. (i.e. this is an active, not passive vulnerability).

That's probably clear when they say it allows RCE, but who knows.

exactly, to the moon. the good news here is, that the bug does not get triggert by forwarding/inspecting Ike traffic.

hope this removes the confusion

Rackspace pushed this update to all their clients last night, as they have seen this attack against some of their infrastructure...

Reply on news.ycombinator.com