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).
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.
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:
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.
Stay tuned for Part 3 which will cover the next steps where Mission:Improbable becomes a reality…
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.
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...
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!"
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:
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.”
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.