WPA Injection and Decryption in SILICA

Recently I've been in a position to speak with a lot of SILICA customers and get some feedback on the tool and how it's being used.  Of course I love to hear the compliments of how SILICA has made the life of the wireless penetration tester much easier but I was most surprised to find out how SILICA is not being used. Let me familiarize you with some of my new favorite features of SILICA.

As Dave pointed out in a previous post SILICA now has the ability to inject into WPA encrypted traffic in 3 different ways:

• Client-side Injection - inject a client-side exploit into the target's browser.
• Custom Injection - inject a custom payload of your choice!
• Browser Auto-Complete Attack - pull saved passwords directly out of the browser. 

The most common responses that I get regarding injecting into WPA encrypted traffic is "it can't be done" and "the algorithm was designed to prevent that!".  As I have come to find out the security industry doesn't believe anything it hears - only what it sees with its own eyes (this was a lesson learned after being rushed by all the Apple fans when I released the details of the Apple ARP disclosure at INFILTRATE 2012).

The main thing to understand when injecting into WPA is the difference between anti-replay and anti-injection mechanisms.  When breaking WEP you have the ability to "replay" a packet that will illicit a response from the wireless AP each of which containing a small piece of a statistical puzzle that will eventually allow an attacker to derive the key.  WPA version 1 was designed to be a band-aid to the broken WEP algorithm (it's safe to think of it as an upgrade to WEP).  The industry's answer to the chaos and panic was to create an algorithm that was still compatible with the WEP devices but prevented a repeat of the same crypto errors.  But in the end - the only thing that was truly prevented was replay - not injection.

The one side effect to injecting into WPA traffic is that the AP will kick the target off the network for a short period of time - this is your only obstacle when injecting into a target device but the device will soon reconnect with your injection still in the browser/application ready to continue where it left off.

The ability to inject into a target's WPA traffic opens an attack vector as most users think they are protected on a WPA network.  The effects can be can be devastating.  What happens when you modify a patient's bloodtype in the medical industry, add/remove a 0 to a financial transaction or randomly insert dialogs from Quentin Tarantino movies into corporate emails?  The problem is actually quite serious.

Even if you are feeling generous and choose not to ruin or severely complicate lives with SILICA you can at least setup a custom phishing attack with the Custom Injection mode to harvest user names, passwords, PINs and tokens (just modify /su/Resouces/custom-injection.html to fit your needs).  SILICA will inject the contents of custom-injection.html into the target's browser - the rest is left up to your imagination.

I have never been on a wireless penetration test in which I was not able to get a WPA key in one way or another.  The truth is a WPA Pre-Shared Key (PSK) is usually common knowledge among employees and contractors alike.  You don't need to crack the key all the time as most people are willing to hand it over (or you can use the FakeAP attack in SILICA to break into a wireless device and pull the key off in plaintext).  When you have the key SILICA will do the rest to expose everything almost as if the data is traversing the network without any wireless encryption at all.

It goes without saying that if you have the ability to encrypt and inject into a target's browser then you also have the ability to decrypt a target's traffic as well.  Data is a valuable target - whether it be personal employee or proprietary data, network traffic or intellectual property.  Once you have the decrypted data all of this can be at your fingertips.  The quickest way to decrypt traffic using SILICA is to enter into Passive Session Hijacking mode.  This mode is typically used to hijack web sessions but it will also decrypt all WPA traffic for all clients on the network provided SILICA collects each of their handshakes (which it will do for you automatically).  SILICA will spawn Wireshark on a named pipe to which it will send all decrypted traffic for your viewing pleasure (eventually you will be able to run the collected traffic though STALKER.  You're welcome.).  

This is the point at which your wireless penetration test truly begins.

Getting lists of exploits

We get a few questions each month on how to generate lists of exploits. There's a few ways:

• Visit exploitlist.immunityinc.com. Here you can look at some of the CANVAS Exploit Packs as well, and generate an XML with names and descriptions and so forth. We try to keep it updated, but it generally lags a bit. It's used most often by our partners in Vulnerability Assessment to rank vulnerabilities.
• Use ./canvasengine.py -e or ./canvasengine.py -D to generate .csv .xml or .txt . This is current as of whatever version of CANVAS you have installed and will include your CANVAS Exploit Packs. (a.k.a., this is how we create exploitlist.immunityinc.com) .

Of course, if you have any other questions, please contact us at support@immunityinc.com or for sales questions admin@immunityinc.com !

Vulnerability Assessment versus Exploitation

The release of SWARM has occasioned a few questions (on ArsTechnica, for example) that we wanted to address - in particular: What is the difference between SWARM and tools like Nessus.

One of the underlying technologies behind SWARM is Immunity's CANVAS exploitation engine. CANVAS scans and exploits small groups of hosts and then further penetrates into networks via MOSDEF, a Python C compiler.

Exploitation in this case means running buffer overflows, PHP include attacks, brute force attempts, or other techniques that will get the user a foothold on the remote machine to execute commands. The advantage here is that once you've broken into a machine, you know for a fact that it is vulnerable - not only is it definitively unpatched, but CANVAS will have shown that any secondary protective measures (Firewalls, IPS, IDS, HIPS, AV, etc.) were bypassed.

Vulnerability assessment tools (such as Nessus, OpenVAS, Qualys, etc.) have a different technique, which is largely based on light touches, plus a huge database of known vulnerabilities that match certain banner strings or protocol responses. This, while extremely fast, generates very high numbers of false positives. To supplement this, most vulnerability assessment tools offer a mode where you can, as an enterprise, give them an authenticated user and password and they will remotely log into your machines and look at files and registry keys directly. However, this does not adequately test for secondary protective measures such as AV or firewall rules.

The balance is simple: When testing a small number of hosts, any false negative is painful and you may find that vulnerability assessment tools will give you the most leads possible for your follow-on investigations. Often, these leads are followed up with an exploitation tool like CANVAS (Immunity sells a popular bundle with CANVAS and Nessus together at a discount). Here at Immunity we call this process "Vulnerability Verification".

For testing millions of hosts, as SWARM does, any false positive percentage is completely unacceptable. There simply isn't time for any human to post-process the results to narrow down what is really vulnerable and what is not.

There are, of course, many many other differences in the two kinds of technologies. But we wanted to clarify at least the difference in goals. Of course, if you have any questions on SWARM, or want to see a WebEx demo, please email us at admin@immunityinc.com.

SWARM

So I have a lot to say about SWARM, which we are finally talking about today. But first, two quick movies which you should watch.

This first movie is the actual SWARM engine user interface. Network conditions are something you discover at runtime and hence, SWARM performance optimizations are configurable at runtime.

This next movie is the SWARM data mining user interface.

Now that you've seen those, come by the BlackHat booth and the team will explain things in more detail.  Needless to say we're really excited to finally be showing this to the public! If you're a large corporation and you need answers about your network NOW rather than "at some point in the future" then we think you'll appreciate this level of scalable network situational awareness.

Please email any comments/requests to admin@immunityinc.com or visit www.immunityinc.com for more information.

CANVAS Reporting

CANVAS has great reporting finally

In the video above you can see the dramatically great reporting engine we've now integrated into CANVAS, which will be released in the next version.

This will soon be integrated into SILICA as well, probably in the next release, although no promises as the team is also working on STALKER integration and getting a few other minor features done (for example, FakeAP improvements).

And of course, we have a new product coming out that we're going to be demoing at BlackHat at our booth. See you there!

SILICA WPS Feature

So a few weeks ago I ran the WPS attack against one of our test AP's. I started it up, it auto-detected the safest delays and off it went. And went. And went.

Several days later it noticed the AP had started having some issues, so it stopped before it crashed it. This was "nice" but hardly the result I was looking for. It did, however, get the WPS info from the AP, meaning I had its exact version. I noticed that I also happened to have that version in the Info tab in SILICA.

SILICA WPS Information Tab - extremely useful information!

On a whim I restarted it, after manually configuring it to use the Linksys E3200 information. 42 minutes later, I had the WPA passphrase and the WPS pin. THAT was what I was looking for.

You'll notice the new version of SILICA does this for you automatically. If you want the old behavior, you need to go into Preferences and uncheck it. But by default it "does the right thing" and you should be getting many more passphrases now from the SILICA WPS attack.

The WPS Preferences Window lets you choose to do things manually
or just let SILICA make all the right decisions.

Thanks for reading! Please let us know if it works better for you now!