It's SSL Story Time with SILICA

The latest release of SILICA has extended its fake AP service impersonation attacks to support the stealing of passwords from secure protocols such as HTTPS, SMTPS, POP3S, IMAPS and also supports the interception of CRAM-MD5 password hashes in a way that can be easily cracked.

But of course you are thinking to yourself "But Mark, in order for that to work the victim would need to accept a counterfeit SSL certificate before any of the traffic could be decrypted! Of course nobody is going to accept your fake certificate!".  This has lead me to believe that some of you would think that the following is a true story:

A guy was driving to a really important meeting (the kind of meeting that would literally change his life for the better) but he noticed a sign on the only road that led to the meeting saying "You probably should not go down this road because someone could be trying to take advantage of you in uncommon and unlikely ways".  So he didn't.  And he missed his meeting.  He won at life.

Now admit that the above scenario would never actually happen as we are brave, curious, and sometimes an incurably idiotic species and consider the true outcome of the story above where he says

"Screw it - I've seen this sign in the past and nothing bad has happened to me.  I'm going to this meeting." and drove to the meeting without a care in the world.

The same is true when presenting a victim with a fake SSL certificate.  MOST ARE GOING TO ACCEPT IT, whether your choose to believe it or not.  In fact, we have calculated a 90% acceptance rate of SILICA's fake SSL certificates (that are generated on-the-fly to appear as legitimate as possible) coming from the domains that are being impersonated.

The truth is that passwords just completely flood into SILICA now from all targeted protocols as if it's a new popular trend. In fact it's borderline ridiculous.  Phones are the worst.  Like a well-trained dog your phone is eager to log in and fetch your daily life and place it at your feet.  This is good for convenience but bad for security.  As soon as an attacker becomes the access point to which your phone automatically connects the attacker almost immediately harvests web site passwords, social networking application passwords and email service passwords.  The following is a screenshot of SILICA stealing passwords (out from under SSL-enabled protocols).

Facebook, Twitter, Hotmail and Gmail account passwords intercepted in SSL traffic during a controlled phishing attacked using SILICA.

Here is a practical example of an attack - you open your iPad and you want to check your Gmail account.  So you open your email client like normal but this time you are presented with a popup message that looks like this:

90% of people will click "Continue" to get what they came for and give SILICA the passwords.

If you click "Continue" (which 90% of you will) then SILICA gets the username and password of your  Gmail account.  This is why it doesn't matter if someone clicks "Cancel" - because 90% of the victims have already given up the goods.

SILICA, Two-factor Authentication and Twitter Account Takeover

Phishing is a very effective method of stealing passwords as humans are typically the easiest service to enumerate them from.  I wrote a small extension to SILICA's phishing engine that demonstrates how to successfully take over a Twitter account even when two-factor authentication is enabled.  Hopefully this will help remove the false sense of security from your minds this is the magic solution to prevent account takeovers.

The victim user in this case will log into Twitter as normal, receive an SMS on the phone associated with the account with the legitimate token and unknowingly give them both to SILICA that will be displayed in the interface like so:

Using SILICA to successfully phish for a legitimate Twitter two-factor authentication token.

It's that easy.  Two-factor authentication just adds one more step to the entire phishing process.  Keep in mind that two-factor authentication is only meant to mitigate authentication attacks where the attacker has access to the password but not the token - it does nothing to protect the session after successful authentication has already taken place.  The new features of SILICA have the capability of taking advantage of both of these scenarios (as an example).  If it can work on Twitter then it can work on the applications that you encounter during your penetration tests.

Also keep in mind that two-factor authentication will not prevent attackers from taking over your account if they are already on your machine, in your browser or on your network.

Conclusion

In reality the Internet does not run on protocols that were built with security in mind.  Security is usually an afterthought after someone takes advantage and a band-aid is needed.  The protocols that you use to get your web traffic and mail are no different.

And what's worse - the protocols that attempt to secure you are still at your mercy - you are given the choice to [sometimes unknowingly] disable all security mechanisms with an innocent looking popup message that just asks you to "Continue" or with an annoying browser warning that says "blah blah maybe you shouldn't click ok blah blah blah NOW CLICK OK TO GET WHAT YOU CAME FOR".

Author

Mark Wuergler

You can bother him here: @MarkWuergler

WPS Attack Detection and Reaction

For those of us in the security industry we are well aware that reactions to attacks can take vendors a long time to develop and deploy a preventative measure.  This is especially true with embedded devices that have no auto-update feature and/or are completely forgotten about once they are up and running on the network.

As a refresher in December of 2011 an attack was published that targeted a weakness in the Wi-Fi Protected Setup (WPS) protocol that demonstrates how to significantly decrease the amount of attempts needed to derive a valid WPS PIN during a brute force attack.  This attack leaves most routers that have WPS enabled vulnerable to an attack that will allow an attacker to learn the WPA Pre-Shared Key (PSK) or WEP key as well as gain access to more configuration information.

Click here to see a video of an attack against WPS using SILICA.

Most routers are still vulnerable to this attack today because there is no easy way to disable WPS in the router's configuration interface (a regular user is not going to go through the trouble of modifying firmware) and not very many people/organizations are very good about checking for and updating new firmware.  I should probably also mention the probability that most people that use or administer a wireless router are completely oblivious to the fact that there is such a weakness in WPS and don't disable it even if they can (after all it is a protocol meant to provide a convenient method to the admin and network users).

Even though it usually takes a long time for vendors to respond to this kind of attack we have recently seen a change in Netgear's firmware that actually addresses the security weakness.  Take a look at the following section taken from a Netgear R6300 web interface:

This is the first vendor response that I have seen for the WPS PIN attack.  After 3 failed attempts the feature is disabled and you get the following message next to the feature configuration: 

 

This obviously does offer another avenue of attack in the tune of a not-so-exciting denial of service (DoS) making it easy for an attacker to turn off WPS all together.

This slightly changes the game (and by slightly I mean not very much).  It used to be that identifying that WPS is enabled was all an attacker needed to determine if the AP was vulnerable to this attack (no major or minor versions to check before launching the attack - it's kind of the same feeling you get when you are pentesting a ColdFusion server/application; it doesn't matter the version you just know it's vulnerable). 

The WPS bug and attack are not going anywhere for a long time but it's interesting to see the proactive actions of vendors hoping for an eventual extinction.  I will keep you posted if I see any similar trends.

Updating the SILICA Virtual Machine

We have been asked a few times if the SILICA virtual machine can be updated. While this is mainly a general Ubuntu Linux question it can affect the usability of SILICA. Before getting into any details it is important to understand how the updating mechanism of Ubuntu works, more specifically how the updating process can affect the operational part of SILICA.

SILICA leverages Ubuntu 12.04 LTS 64bit and is supplied as a virtual machine.

The core operating system consists of a few components such as:

• Applications
• Kernel
• Drivers
• Firmware

A lot of sub-categorizing could be done in the above list but this simplified for the purpose of this post. The components we care about are the kernel, drivers and firmware. If any of those are updated this could result into an unexpected behavior of the software. Having said that a lot of users may wish to update their applications which is a big portion of the operating system and that includes packages such as the web-browser, editors and the X-environment.

Before explaining how a user may want to proceed into updating the operating system, I would like to mention that it is a good idea at this point to use the snapshot feature of VMware. This will keep a good state of the virtual machine and you will allow reverting back to the original easy, if something goes wrong. In free versions of VMware such as player this feature may not be available so you can just copy the entire virtual machine in a separate folder in your drive as a backup.

Since we have a safe way to recover our original image it is now safe to go ahead and explain how one may want to update the operating system. As mentioned above some of the packages which are of importance are the firmware, kernel and drivers. In this case we will utilize an Ubuntu tool called apt-mark which will help us prevent accidental updates of the system.

In particular we can issue the command:

apt-mark hold linux-firmware

This will mark the package linux-firmware as hold which means it will not be updated in the next system upgrade. This package may have other dependencies so this may prevent other packages of being updated, the good news is that you do not have to worry about this since Ubuntu handles it for you.

Next we need to verify that the command succeeded by executing:

dpkg --get-selections linux-firmware

That should return something like 'hold' next to the package name, which means it has successfully completed. A similar process should be followed for the rest of the packages such as the kernel files, the drivers and any other packages the user wishes to preserve. Using dpkg -l |grep 'package-name' may help identify anything of interest. For example finding the kernel package the user can issue: dpkg -l |grep -i kernel and that will return a list of kernel packages that can be preserved. One does not have to mark them all as hold. Ubuntu will protect the rest of the packages because of the dependency checking mechanism.

Finally performing a system upgrade is as simple as running apt-get upgrade. The user can also specifically update a package such as a web browser using apt-get install package-name.

The reason we do not update the kernel, driver and firmware is beyond the scope of this post but I will be glad to get into more details if someone is interested.

Resolving Hostapd issues in the new SILICA VM

[Editor's Note]

There are a lot of layers in SILICA - from the VM's hypervisor, to the Linux kernel, to the firmware and card itself. And, of course, there's SILICA (which is a pure-Python program, as you know). We often get requests to enable SILICA to run on "any card" but we've found that not having control of all parts of the stack leads to very difficult to diagnose issues - things you can't have in the wild as you are in the middle of a penetration test. Below, Alex describes in gruesome detail the process of fixing one such bug...

Resolving Hostapd issues in the new SILICA VM

Recently we moved SILICA into a new virtual machine that is based on Ubuntu 12.04. With a little bit of fine tuning SILICA is running great. However I noticed that our fake access point / impersonation wasn't working as expected. Our code leverages the hostapd daemon that allows you to create a software AP.

My first thought was that there was some kind of problem with the version of hostapd so I started by trying to update the Ubuntu version of hostapd. After a few attempts I got it to compile with the right config file and it was up and running. The problem was that for some mysterious reason the access point that I had created was not broadcasting any beacon packets. So that took me to my second thought of trying to downgrade the version of hostapd to the latest stable 0.7.3 at the time. I was previously trying 1.0. A few minutes later after compiling all the dependencies I still had the same results; no beacon packets were being sent out.

Looking a bit deeper into the issue I started checking my configuration file to see if there was some misconfiguration or change between the versions. I did notice that hostapd was utilizing a driver which was a layer of communication with the host operating systems driver. After trying different options I did not get anywhere but at this point I started thinking that there may be more to it than just a user space daemon not functioning properly. My thought was to see what will happen if I was to use the old carl9170 SILICA driver but it didn't work.

I promptly downloaded the compat-wireless drivers that matched the old version and I was up and running with a freshly built driver code base. The card was identified and loaded fine and most of the basic functionality was working and everything seemed to be back to normal so I loaded up SILICA to see if the issue was still there. I created a fake AP like I did earlier and waited on Wireshark to see if there any broadcast packets being sent out but the issue was still there. At this point I was completely lost so I decided to take up the issue with other people to see if someone else had any ideas.

After asking around a few of the kernel wireless developers and giving them a lot of dmesg outputs in Pastebin I was told that there may be some incompatibility between my card and the driver version I was using and to try and update to the latest compat-wireless. So I updated to the latest compat-wireless even though I already knew at this point that this was system related and not hostapd related.

The problem was still there no matter what version or configuration I tried.

So being left with my last resort I decided there was nothing left to do but to dive into the driver code base and see what is really happening (unfortunately). A few hours later and a lot of printk's I realized that the code that exposes the access point mode lived inside the firmware and if the firmware did not support that then the driver will give you access to all the other features but that. Luckily the firmware for carl9170 is open source and I already had the latest git checked out on my system. I went through the build configuration and I enabled some features and cross-compiled the code. The driver handles the uploading into the device so I quickly reloaded the kernel module.

At this point I had a fresh firmware that I had built from the git running on my wireless card. I loaded up SILICA again and started the Fake AP option. A minute later I started to see beacons being broadcasted from my card! I loaded an attack just to make sure everything still worked and the feature was fully functional and that succeeded. I did a quick run through the entire feature set of SILICA and everything works as expected. So there it was - a new firmware solved the problem.

The new update of SILICA is going to automatically replace the old firmware.

STALKER - Analyzing [Your] Wireless Data

At INFILTRATE 2012 I gave a presentation entitled Secrets In Your Pocket: Analysis of [Your] Wireless Data[1].  I discussed many ways that you or your target can be stalked, profiled and forced to disclose personal information.

Most people tend to store information disclosures away in the cerebral junk drawer where other useless knowledge is archived.  "So what?" is the typical response I get when I discuss personal data disclosures, "What can you do with it?"

That's a great question.

STALKER is a tool that I wrote to reconstruct all captured traffic (wired or wireless alike) and parse out all of the "interesting" information disclosures.  It goes beyond just grabbing passwords and emails out of the air as it attempts to build a complete profile of your target(s).  You would be amazed at how much data you can collect in 15 minutes.

Here is a list of the most obvious and interesting data that can be collected with STALKER.

• Name(s)
• Email addresses
• Phone numbers
• Billing/Home address
• Passwords
• Emails
• User names/Screen names
• User-Agent strings
• Wireless networking probes (Beacons/SSIDs)
• DNS requests
• Host names
• Weblinks
• Search queries
• and so much more!

But what I want to focus on are the not-so-obvious information disclosures and how they can be used against you or your target.

ARP Disclosures and GPS Coordinates

At INFILTRATE I released details of a feature of Apple products (iPhones, iPads, Macbooks, etc) that leaks the MAC addresses of the last 3 wireless access points that the device has connected to (lots of Apple fans yelled at me after this.  Feel free to continue yelling at @MarkWuergler).  What does this mean?  It means that your target's device is disclosing where the target lives, works and plays to everywhere within wireless range.  STALKER keeps track of all of this for you and even plots the target's preferred access points on a map.

The blue marker on the above map represents the location of the wireless access point that a target device has connected to and the red marker represents where the actual device was seen by STALKER.  Over the course of a few days this map is populated with all the frequented locations of the target.  

Reconstructed Files

If you target is downloading/uploading files then STALKER will put them back together and lovingly save them on the hard drive for you.  It doesn't matter what the file type is - as long as STALKER can see it - you'll have it.  View web pages as the target viewed them, view their documents, listen to their music and to their VoIP phone calls.  

I will warn you though - there are just some things that can't be unseen (I will leave this to your own imaginations).

Emails and Chats

“Integrity is doing the right thing, even when no one is watching.” - C.S. Lewis

Most people are always on their best behavior ... until they start to share private messages.  Criminal behavior is evident, true personalities and intentions surface and the completely unimaginable take place in digital conversations.  All of which you can browse easily in the STALKER inbox.

Piece by Piece - Building a Profile One Disclosure at a Time

One thing that I look for on penetration tests that I conduct is how to turn a small, seemingly unimportant bit of data into more meaningful data.  For example, a userid from a website could be used to turn into a person's name -> name into email address -> email address into phone number -> phone number into home address -> etc, etc, etc.  STALKER is capable of automating this for you so you don't have to worry about making the connections yourself.  You're welcome.    

Forced Information Disclosures

SILICA can be used to actually force a target user to interact with the applications and services that will disclose the most information about them in the fastest time possible using its Custom Injection module.  This mode will inject custom content into the browser of the target (this can be hidden or obvious depending on your needs).  Typically this is used to actually compromise the wireless device (which is a topic for an entirely new blog post) but it can also be used to aggressively collect the kind of data that you want to feed to STALKER.

Practical Uses

There are many potential audiences for STALKER.  Here are a few that come to mind: 

1. Those that immediately understand the risks associated with information disclosures.  This is usually the category that victims fall into.
2. Those who have something to protect.  This is the category that governments and corporations fall into.
3. Those that are tracking and investigating individuals.  This is the category that law enforcement falls into.
4. Those that are proactive about security.  If your personal or corporate wireless device's traffic is run through STALKER and anything of interest shows up then you have a leak that needs to be plugged (before it can be abused).
5. Social engineering.  If employees are profiled by STALKER the likelihood of a successful social engineering attack increase dramatically (as STALKER may contain information that can help answer security questions to validate identity).

Threats

Anybody with a wireless card has the ability to collect highly sensitive data on you and those that are associated with your organizations.  Let STALKER show you what you are giving away to your attackers before your credit score, lawyers or CNN have a chance.

Disclaimer

Don't talk about this program to girls you just met.  And under no circumstances make the same mistake as I did and tell them that you wrote the program ...

[1] Secrets in Your Pocket: Analysis of [Your] Wireless Data (Prezi or watch the Video)

Author

Mark Wuergler

Twitter: @MarkWuergler

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.