SpiderLabs Anterior

Sometimes, The PenTest Gods Shine On You

Settling down for a hacking session usually means lots of hard work and a long grind towards target data. You've got to juggle a large stack of systems and testing constraints, all while learning about the environment from the ground up. You can spend 3 hours trying to land a shell on a box, just to find it gets you nowhere.

However, sometimes a beautiful beam of light shines down from the heavens and opens up a door or two for you (or maybe its just the sun reflecting off of something in my office, either way).

Cracking IKE Mission:Improbable (Part 2)

A couple of weeks ago I posted Part 1 of Cracking IKE, detailing some useful techniques when cracking Aggressive Mode PSK hashes. In that post we saw that a hash is not always ‘crackable’ and additional steps are required in order to find a correct group name or ID. In this post I will be discussing a more recent vulnerability I discovered on the Cisco ASA platform that allows you to do just that.

A Quick Recap

Going back to the previous post we saw that it was possible to enumerate group names by analyzing subtle differences in the response from the ASA firewall, specifically the presence of a DPD (Dead Peer Detection) payload. So by sending requests to the device with a list of potential group names it’s possible to find a valid group name if the ASA software isn’t patched.

What’s New?

So I decided to look for any additional signs that may leak information about the validity of the group name. I did this by analyzing genuine IKE negotiations and sending a variety of different requests, looking for anything that may provide a clue. I eventually noticed that some differences remain even in the latest version of ASA software. Basically, a correct group name elicits four (this can vary depending on the software version) attempts to continue the handshake and an additional encrypted phase 2 packet, while the device will only respond twice to an incorrect group name. This is probably better described in images.

Incorrect group name:

Correct group name:

Demonstration

The differences are quite obvious so to demonstrate I’ve written a proof of concept python script that enumerates the group names using this technique, which can be found here. Although it’s incredibly slow because of the need to wait for the response packets each time a request is made. It requires a wordlist and a target as input, allows the hash type to be specified (MD5 or SHA1) and looks like this:

The group name (or ID) can then be used to capture a genuine hash for cracking using a cracker of your choice, as described in Part 1:

Personally I prefer Hashcat:

How Do I Protect Against This?

Cisco have released software updates to address this issue, further details/updates can be found here and here. Administrators with affected software versions should be aware that this information could be potentially revealed, it is recommended that these updates are applied if your devices are allowing PSK authentication. It is also recommended that default or easily guessable group names should not be used and strong Pre-Shared Keys are a must. The keys should be rotated as often as is practically possible and Aggressive Mode IKE negotiations should be disabled where possible, but of course this is not always a possibility with Remote Access setups. In an ideal world PSK negotiations should be replaced with certificates.

Now What?

Stay tuned for Part 3 which will cover the next steps where Mission:Improbable becomes a reality…

Breaking the Authentication Chain

This little post is going to talk about how authentication goes beyond just usernames and passwords.

Authentication is something we all do, in fact you probably are authenticated by some system somewhere just with the information in your browser right now. By definition, authentication is the steps taken to verify that someone or something is in fact who they claim they are to be. This is traditionally done with passwords, and in more secure environments authentication tokens, certificates, one-time passwords or biometrics can even be utilized to verify you are who you claim to be.

Cracking IKE Mission:Improbable (Part 1)

All too often during pen tests I still find VPN endpoints configured to allow insecure Aggressive Mode handshakes. Fortunately, gaining access to the internal network as a result of this vulnerability remains a fairly complex task. Hopefully this series of posts will clarify this process and demonstrate the risk this type of misconfiguration can pose to a network...

OS Image Wrangling

On most PenTests, alot of research goes into the things you find along the way. You find obscure software and other setups that can be a goldmine if you spend the time to do some research. On a recent test, I came across a FOG Server install. FOG is a open-source cloning setup, much like Norton Ghost. It pulled its images from a NFS share, and I just so happened to be in the /24 that was allowed to access it.

New Year, New Data, Same Mistakes: Passwords

Like a late-arriving christmas, one of the gifts of the new year is the release of SpiderLabs’ annual white paper, the Global Security Report.  As a supplement to this year's report, we’re going to share some highlights of the corporate password study section. This section is always near and dear to our hearts as passwords play vital roles in just about every aspect of security, not to mention are a fascinating insight into the human mind.

"Why  do this study year after year?", you might ask. "Aren’t passwords dead? I totally read that in some magazine article!"

Fraud, Passwords, and Pwnage on the Interwebz

This past weekend I was lucky enough to attend Microsoft’s BlueHat Conference in Redmond WA and Security B-Sides Seattle.  The combination of some of those talks succeeded in keeping some persistent issues alive in the hopes of finding a solution.  We live in a world dominated by the Internet and rapidly changing technology.  Most people regularly use at least some form of social media online whether it’s Facebook, Twitter, Reddit, etc., and it’s accessed and updated from a home computer, tablet device, or smartphone.  And while the Information Security world is far more cognizant of what transpires online your average user really isn’t.  And it’s sad to think they either don’t care, or have a “it will never happen to me” attitude.  I’m not sure how much of my online life is made up of paranoia, anti-social behavior, or just that I feel what I do is none of anyone’s business but my own.  I don’t have a real Facebook account, I have a “sock puppet” account. I have a twitter account, but if you look at it, it’s all angry rants.  I try to minimize my web footprint as much as possible, but I love my email accounts.  Yes, that’s right -plural.  All are different user names, with different email services.  Each is associated with various logins to different services on the Internet.   So what about the average user? 

Oops, I pwned your router - Part Two

In the last blog post, "Opps I pwned your router Part One", I talked about some of poor security that went into the basic embedded router operating systems.  In this post, I will flush out in more detail how one can go about reverse engineering these devices, what tools worked for me, and some of the results that I was able to get to.  Hint: Having root on your hardware is good for me, bad for you.

This is Customer Premises Equipment (CPE) device that provides end users with Internet access.  Thus only the head end systems should have access, more specifically the end user should not.

  So first lets talk about some of vectors I used to attack this embedded device:

1. SNMP
2. Telnet
3. JTAG Header
4. Web Server & CGI binary

Hey, I just met you, and this is crazy, but here's my hashes, so hack me maybe?

Those familiar with password cracking know that KoreLogic’s rule set for John the Ripper has become the de facto standard for password cracking.

However, as with anything technology related, the rules are slightly starting to show their age, specifically with rules designed to take into account years.  So, I decided to take on the task of making a few modifications to the rule set, this includes updating them to take into account the current and prior year, but also reworking some of the rules to eliminate some redundancy.

While updating the various rule sets is fine and dandy, but what about taking it a step further and rearranging the order in which they’re applied?  Running the complete KoreLogic rule set takes a lot of time, especially when running them against a respectable dictionary and salted hashes (NTLMv2, Crypt, etc...)  When you have limited time during a pentest this can be fairly problematic - you want to utilize the rules that will net you the greatest amount of success in the shortest amount of time, leaving the less successful rules as “Hail Mary passes.”

Exploiting Users By Non-technical Means; or, “S*** Users Do”

Numerous technical articles emerge each day about the latest vulnerabilities, flaws, exploits, and whatnot.  That’s great and all (who hasn’t simultaneously groaned and cheered when they find an MS08-067 exploitable machine on a pentest, 4+ years after the vulnerability was documented?), but why bother going to all the trouble when users often give you all the ammo you need to successfully compromise your targets?

In this post, I’d like to cover some of the terrible, awful things users do that help pentesters in their duties (and the bad guys as well).  They may not be the sole reason for compromises, but they can greatly accelerate them in an environment where pure technical machismo would be left out in the cold.  Let’s begin, using some (terribly named) characters.