Internet God Mode

Need a Konami code for pwning the Internet? NSA has some. Well more technically everyone has some of them now that they've been leaked by Shadow Brokers.  Firewalls effectively segment your internal networks from the Internet and remote, unauthenticated exploits against them undermine the security models of most organizations.

I've noticed a lot of people on Twitter talking about how they don't care about three year old firewall exploits.  But let's be clear that many of these exploits are still not patched today.  Some pundits have noted that many products targeted by the exploits (e.g. PIX) are not very commonly uses today.  Point taken, but they were much more common three years ago when this tool cache was originally created.  How often do you change the private keys on your VPN? For compatibility reasons, did you roll your PIX private keys forward when you upgraded to an ASA?  If you aren't sure, I would recommend changing your private keys on your VPNs.  It's relatively easy in the scheme of things.

Need to pwn the Internet? Firewall exploits will help...

How should your defensive strategies change when you consider your firewalls to themselves be compromised? I'll cover that in depth in a later post.  But the firewall exploits released to every attacker on the Internet are seriously disturbing.  We should not downplay the significance - even if some products targeted are no longer supported.  Many organizations run unsupported hardware and software.

Two months ago at Rendition Infosec, I worked with a well meaning organization with 10 year old IOS on their routers and 25% of the environment still touting XP and Server 2003.  This is an extreme example, but most organizations have some percentage of unsupported software and hardware for a variety of reasons - usually involving budget.

Finally, it's worth noting that it's highly unlikely that NSA has stood still in its firewall exploit program since this tool cache was stolen in 2013.  In the last three years, it's likely that NSA has researched and acquired other firewall exploits that work against more modern platforms.  I've seen some very dense people (on Twitter and elsewhere) suggesting that if you want to be safe from NSA, just deploy Palo Alto.  They claim this is a good idea because there were no Palo Alto exploits in the dump.  This, like many other comments about the dump, are extremely myopic.  Who knows what NSA has today for firewall exploits and implants?  I certainly do not, but this release will certainly change the way I think about defense in depth.

Cisco downplays SNMP vulnerability exposure

Unless you've been living under a rock this last week, you know that NSA's firewall hacking tools have been stolen and at least a subset of them have been subsequently released.  At least a subset of the tools are are used to exploit and implant malware on devices produced by US companies.  One of those vulnerabilities, an SNMP vulnerability (code named EXTRABACON) affecting Cisco products, has been downplayed in a somewhat disingenuous method by Cisco's security team.

Look, nobody likes to be faced with an 0-day.  And it's an extra huge slap in the face to know that not only did your government discover the vulnerability before you did, but they kept it a secret from you for at least three years.  But slap in the face aside, now that the secret is out there it's time to take responsibility.

Cisco's blog correctly notes that the attacker has to know the community string and must talk to an interface with SNMP enabled.  By default, this is only the management port.  But in the field, very few organizations use this configuration.  Many/most have SNMP enabled on all internal ports, despite best practices.  We often find that SNMP is enabled (at least read only) on the DMZ interface in customer environments.  We advise against this of course, but I want to deal in reality instead of the "this is almost never exploitable" vibe Cisco uses in their blog post.  We have even seen SNMP accessible from the Internet. While that's criminally stupid, it can and does happen.

Cisco's diagram of EXTRABACON exploit scenarios

Cisco says in their narrative "In the example above SNMP is only enabled in the management interface of the Cisco ASA. Subsequently, the attacker must launch the attack from a network residing on that interface. Crafted SNMP traffic coming from any other interface (outside or inside) cannot trigger this vulnerability."  But that relies on the user understanding the example and correctly evaluating whether their environment is identical to the example.

Don't think this is a problem?  One of my Rendition Infosec customers already called to confirm this could only be exploited through the maintenance port.  They read the article and fell for the "in the default configuration..." double speak. The problem is that they don't use the default config so that doesn't matter. An attacker in their network, anywhere in their network, could use this exploit against their ASA.

To the point that the vulnerability requires you to already be in the network, let's talk about that.  So what?  Phishing gets me in the network nearly 100% of the time.  And how long do you need to be in the network using your phishing access to exploit and implant a firewall?  I don't know, but I'm guessing not long.  Once that happens, instead of protecting the organization, the firewall actually becomes a liability.

The firewall is a point through which all traffic in the network flows.  It is not easy to perform incident response on a firewall (e.g. an ASA).  In most cases the firewall itself is directly accessible from the Internet.  The firewall being compromised is also not part of the threat model that most organizations think about.  That obviously needs to change in light of the NSA tool disclosures, but my point is that this is a devastating vulnerability - there is no point in downplaying it.  If I'm in Cisco's shoes, I'd be screaming foul play from the rooftops to my elected representatives.

On cover terms

Cover terms, or "code names" as they are often called serve a very useful purpose in a wide range of operations. Their value in intelligence is undeniable. They are also useful in enterprise incident response (IR). As a consultant, I sometimes find myself needing to take a phone call in less than opportune environments and cover terms for customers and particular incidents help to keep me from disclosing any confidential information.

But there's an art to selecting cover terms for incidents.  A few guidelines I follow are:

• Don't base the term on the name of the client (it's not much of a cover)
• Don't make the cover term the same as the name of the malware used (many different attacker may use variants of the same malware)
• Run your names past your PR department

This last one (involve the PR team) is pretty important, but is rarely done. Experience has taught me to assume that everything will get out to the press eventually. You don't want a funny inside joke name to get out in the press.  What's funny with the appropriate inside context, it probably won't be funny absent any context. That makes your organization look really bad.  Over the years I've seen lots of obscene and questionable cover terms.  In my younger, dumber days I might have even created a few myself. But I know better now.

Why am I bringing this up?  The Equation Group tool leaked files being auctioned have a large number of tool cover terms in it, many of them questionable.  For instance, I can't help but notice the obviously phallic undertone in the large number of BANANA related terms (e.g. EPICBANANA).  Either that or someone maybe just loves bananas.

My personal favorite in the cover term set released has to be BUZZDIRECTION. Whoever snuck that past the cover term censors is a freaking genius at word play. At first glance it looks totally innocent, but try saying it fast once and you can't help but appreciate the adolescent quality it has.  Totally innocent mistake? Given the other phallic references, I highly doubt it.

While others focus on the exploits and tools themselves, I figured I'd focus o this somewhat less obvious implication of the leak - namely that you must assume everything will be leaked eventually. A little care up front can prevent your organization from looking like a beer fueled frat house in the press later.

QUADROOTER - is the sky really falling?

Check Point released a 4 pack of root vulnerabilities in Android at DEFCON.  They named the group of vulnerabilities QUADROOTER, presumably because they are four vulnerabilities that result in root access on Android.  One of the first media articles I read on this actually has the headline "the sky is falling."  Um, lets dial that back three or four notches...

At Rendition Infosec, we deal in realistic risk.  Let's distill out the hype and talk some facts about the vulnerability:

1. It appears to require the user to install a malicious application to exploit anything.
2. The classes of vulnerabilities present are unlikely to remotely exploitable if a user simply views a malicious webpage.

So how would an attacker exploit any of these four vulnerabilities?  Simple: they'd trick a user into installing a malicious application.  Let's hope that the app store is looking for applications exploiting these vulnerabilities at this point.  If not, shame on Google.  If so, the user would have to side load the application as a malicious APK or install it from a rogue app store.  Sure, a vulnerability rooting the phone is bad. But a malicious application can do some pretty bad stuff without rooting your phone.  The sky simply is not falling, despite Chicken Little's best wishes.

On responsible disclosure
I'm not one to debate the merits of responsible disclosure. I have some pretty mixed opinions on this topic.  But when you disclose vulnerabilities on a conference schedule rather than vendor patch schedules you lose the moral high ground.  I am not personally against full disclosure, but just remember this day if/when Check Point says something about someone else's disclosure practices.  The fact is that these vulnerabilities won't be patched until September at the earliest.

On naming vulnerabilities
If you follow the blog, you'll know I've been critical of this practice.  This name is especially confusing since it details four separate vulnerabilities.  Let's hope these all get patched at the same time to avoid creating more confusion. Also the vulnerability name sounds like what you'd name a drone.

It's just a freaking jailbreak
We don't name jailbreaks and write white papers about them. In fact, people laud them so they can break free of Apple's tyrannical grip of their iOS devices. Why are these Android vulnerabilities to be feared and iOS jailbreaks are something to run as quickly as possible before Apple patches it?

Collecting data...
I don't understand for the life of me why Check Point chose to put their white paper behind a data collection wall.

If you are really "just interested in warning the public" don't require people to enter their data to read your paper.  That's a grade A dumb move.  Here's to hoping that data collection wall comes down so more people can easily read the source data about this Android jailbreak.   A Twitter friend shared the link with me (and anyone else who wants to search for it) and I'm sharing it here. Suck it Check Point.

Practice safe apps(?)
Unless you find yourself connecting to app stores other than Google Play Store, downloading apps over insecure wireless, or have been repeatedly tricked into installing malicious apps on your phone, you probably don't need to worry about QUADROOTER.

Final score:
+10 points to Check Point for finding the QUADROOTER vulnerabilities
-1 point for putting up a reigstration wall
-3 points for completely unnecessary hype
-4 points for scaring my mom - she's a technotard who can't read past the hype

Security conferences != dating scene

To my female readers, hold on a minute, I have to say something to my fellow men.  Join me in just in a minute.

<rant>

Men - I think there must be some confusion here about what security conferences are for.  Last time I checked, security conferences were good for a number of things, including:

• Learning about new and exciting advances in the field
• Participating in a CTF
• Damaging your liver
• Meeting new people and reconnecting with old friends

It feels like this should go without saying, but what a security conference is not:

• A meat market
• A quick hookup point
• A match.com meetup

If you follow me on Twitter, you know I attend a lot of security conferences - and I'm a speaker at most the conferences I attend (so I usually see the speaker parties too).  The conferences I attend are all over the map, from Blackhat to DEFCON to various BSides and SANS summits.  The demographics at these conferences vary wildly from hacker types with green hair and poor hygiene (FFS, please follow the 3-2-1 rule) to more professional and polished DFIR types.  

Over the last two years, I'm seeing more women attending conferences.  This is GREAT for me personally - my daughter is almost 10 and is interested in STEM.  She needs role models.  She loves talking to women who are doing "cool computer things."  Even Ray Charles isn't blind enough to claim there's no gender equality gap in infosec - the women coming to these conferences will help close that gap and make the industry better for all of us.

But they'll only do that if they feel safe and accepted.  And I have to say that I am embarrassed at the behavior I see from my male counterparts at these conferences in their treatment of women.  I don't know if it's as a result of more women being at conferences or I've just opened my eyes up to it, but I cannot believe how many seemingly professional guys go from totally cool to total douche in 10 seconds or less.  

Guys, infosec conferences aren't a place to find the love of your life.  Go use an online dating site for that.  Stop mansplaining stuff to women too.  Nobody likes that.  I saw that happen last night at the TiaraCon party.  For those that don't know, this is an event to promote diversity in infosec - making mansplaining there especially ironic.

Don't be touchy

The other thing that I see with a fair degree of regularity are men getting touchy at events - including the speaker events (where I somehow assume things would be somewhat more professional).  I have never had a guy touch me to make a point in a conversation (and good thing, I'd f*%king lose my mind). But I see it all the time at these parties and events.  And I guess some of my brethren are bad at reading people because all of the "stop f%#king touching me" visual queues are there.

At security conferences in the last year I have stepped in (or have been pulled in as an apparently safe person) on way too many occasions to defuse inappropriate and/or aggressive flirting.  I've been asked to walk women back to hotels from parties (including speaker parties) because other attendees were making them feel unsafe.  This has to stop.  If men in infosec don't make women in infosec feel safe, we'll continue with the same problems we have today. 

As we roll into the next two nights of nighttime hacker meetups - I mean drunken DEFCON parties - consider how your actions reflect the industry as a whole.  If your mom would be ashamed of your behavior, go ahead and dial it back a few notches.

</rant>

Women - thanks for hanging in there

Thanks for waiting while I took a minute to talk to my fellow men.  Thank you for your contribution to infosec.  Hang in there - the men who are inappropriately or aggressively flirting, etc. do not represent all of us.  If you ever need someone safe to help you get to a taxi, hotel, etc., look for me and I'll be more than happy to help.  If any of my Rendition Infosec employees are ever inappropriate with you, report it - if they're acting inappropriately they won't be employees anymore.  I don't control anyone else's future, but I'll start with my small slice of the pie and I hope other employers in our industry will do the same.