At Defcon 22 we presented several improvements in wifi rogue access point attacks. We entitled the talk "Manna from heaven" and released the MANA toolkit. I'll be doing two blog entries. The first will describe the improvements made at a wifi layer, and the second will cover the network credential interception stuff. If you just want the goodies, you can get them at the end of this entry for the price of scrolling down.
This work is about rogue access points, by which we mean a wireless access point that mimics real ones in an attempt to get users to connect to it. The initial work on this was done in 2004 by Dino dai Zovi and Shaun Macaulay. They realised that the way wifi devices probe for wireless networks that they've "remembered" happens without authentication, and that if a malicious access point merely responds to these directed probes, it can trick wireless clients into connecting to it. They called this a KARMA attack.
Additionally, Josh Wright and Brad Antoniewicz in 2008 worked out that if you man in the middle the EAP authentication on secured networks, you could crack that hash and gain access to the network yourself. They implemented this in freeradius-wpe (wireless pwnage edition).
However, KARMA attacks no longer work well, and we wanted to know why. Also, the WPE stuff seemed ripe for use in rogue access points rather than just for gaining access to the original network. This is what we implemented.
Changes in Probing
After a significant amount of time poring over radio captures of the ways in which various devices probed, and informed by our previous work on Snoopy, we realised two things. The first is that modern devices, particularly mobile ones, won't listen to directed probe responses for open, non-hidden networks if that AP didn't also/first respond to a broadcast probe. What this means is that our rogue access point needs to implement the same. However, the challenge is, what do we respond to the broadcast probe *with*?
To overcome that, we took the existing KARMA functionality built by Digininja, ported it to the latest version of hostapd and extended it to store a view of the "remembered networks" (aka the Preferred Network List (PNL)) for each device it sees. Then when hostapd-mana sees a broadcast probe from that device, it will respond with a directed probe response for each network hostapd-mana knows to be in that device's PNL. This is based on our finding, that wifi clients don't have a problem with a single BSSID (i.e. AP MAC address) to have several ESSIDs (aka SSID aka network name).
Practically, suppose there are two devices, one probing for a network foo, and the other probing for two networks bar and baz. When device1 sends a broadcast probe, hostapd-mana will respond with a directed probe response for foo to device1. Likewise when device2 sends a broadcast probe, hostapd-mana will respond with two directed probe responses to device 2, one for bar and one for baz. In addition, the "normal" KARMA functionality of responding to directed probes will also occur. Practically, we found this significantly improved the effectiveness of our rogue AP.
iOS and hidden networks
iOS presented an interesting challenge to us when it came to hidden networks. A hidden network is one configured not to broadcast its ESSID in either its beacons or broadcast probe response. Practically, the only way a client device can know if the hidden network it has remembered is nearby is by constantly sending out directed probes for the network. This is why hidden networks aren't a very good design, as their clients need to spew their names out all over the place. However, when observing iOS devices, while they could join a hidden network just fine, they seemed to not probe for it most of the time. This had us constructing faraday cages, checking other factors like BSSID and geolocation to no avail. Until we realised that iOS will not probe for any hidden networks in its PNL, unless there is at least one hidden network nearby. So, if you'd like to maximise your rogue'ing, make sure you have a hidden network nearby. It doesn't even need to be a real network; use a mifi, use airbase-ng or just create another hostapd network.
Limits in probing
Modern mobile devices probe for networks on their PNL *significantly* less than laptops or older devices do. In an ideal world, manufacturers would change the implementation to never probe for open network, and only wait for a response to a broadcast, effectively limiting these attacks to requiring pre-knowledge, common networks or being performed in the vicinity of the actual network. Actually, a patch was pushed to wpa_supplicant to limit the stupid probing behaviour Android does in low power mode a few months ago, this will make it into Android proper sometime soon. Also, iOS has significantly reduced how often it probes.
There are two ways to work around this. The first is manual; go for a common network. The rise of city-wide wifi projects makes this somewhat easy. Or if you're going for a corporate network, just do some recon and name one of your access points after that. But, we wanted to make things work better than that. The default behaviour of hostapd-mana is to build up a view of each devices PNL and only respond to broadcasts with networks specific to that device. However, we can remove that limitation and build a global PNL, and respond to each broadcast with every network every device has probed for. We call this loud mode, and it's configurable in the hostapd-mana config. This relies on the fact that many devices, particularly laptops and older mobile devices still probe for networks a lot. It also relies on the fact that many devices have networks in common (have they been in the same city, same airport, same conference, same company, same pocket etc.). This works *very* well in less crowded areas, and you'll get a much higher number of devices connecting.
However, in busy areas, or if your antenna is large enough, you'll quickly exceed the capacity for your average wifi device to respond fast enough to all of the devices, and as the number of response probes grows exponentially with each new device, even in quiet areas over time, this problem crops up (but didn't on stage at Defcon miraculously). So, it's *good enough* for now, but needs an in-kernel or in-firmware implementation with some network ageing to scale a bit better (one of the many opportunities for extending this work if you're up for some open source contribution).
Auto Crack 'n Add
freeradius-wpe is great, it provides a nice way to grab EAP hashes for clients that don't validate certificates presented via EAP's that implement SSL (PEAP, EAP-GTC, PEAL-TTLS). However, the patches are for freeradius v1 and, much like the KARMA patches for hostapd, have aged. But, hostapd contains a radius server, and so we could port the freeradius-wpe work to that, something we based off some initial but incomplete patches by Brad Antoniewicz. So hostapd-mana will also let you grab EAP hashes without needing another tool.
However, the KARMA attacks only work against open wifi networks. EAP networks are increasingly common (especially corporate ones) and we wanted to be able to have a go at getting devices probing for those to connect to our rogue AP. To do this, we modified hostapd-mana to always accept any EAP hash, but send it off for cracking. It simply writes these to a file, from which the simple python tool crackapd (included) will grab it and send it off to another process for cracking. Currently, we use asleap (also by Josh) and the rockyou password list, but these can all be easily modified. For example, to use CloudCracker and its incredibly optimised MS-CHAPv2 cracking setup.
The net result is pretty great for simple EAP hashes. The device will try and connect, and fail as we don't know enough to do the challenge response right. But after the hash is cracked, when it retries to connect (something a device will keep doing) it will succeed (and you'll have your first creds). For simple hashes, this is transparent to the user. Of course, very complex hashes will only work if you crack them in time. Worst case scenario, you leave with hashes.
So that's what we built into hostapd-mana. You get improved KARMA attacks, a modern hostapd version, an integrated hash stealer, and the possibility of rogue'ing some EAP networks. You can get the full toolkit at MANA toolkit on GitHub or our hostapd-mana at hostapd-mana on GitHub.
The next blog entry will cover what we did once we got a device to connect.
The Defcon talk:
The supporting slide deck with more information:
The final toolkit: MANA toolkit on GitHub You can also get this on Kali with "apt-get install mana-toolkit"
The modified hostapd (for hackers or people who want to build their own setup): hostapd-mana on GitHub
This blog post is about the process we went through trying to better interpret the masses of scan results that automated vulnerability scanners and centralised logging systems produce. A good example of the value in getting actionable items out of this data is the recent Target compromise. Their scanning solutions detected the threat that lead to their compromise, but no humans intervened. It's suspected that too many security alerts were being generated on a regular basis to act upon.
The goal of our experiment was to steer away from the usual data interrogation questions of "What are the top N vulnerabilities my scanner has flagged with a high threat?" towards questions like "For how many of my vulnerabilities do public exploits exist?". Near the end of this exercise we stumbled across this BSides talk "Stop Fixing All The Things". Theses researchers took a similar view-point: "As security practitioners, we care about which vulnerabilities matter". Their blog post and video are definitely worth having a look at.
At SensePost we have a Managed Vulnerability Scanning service (MVS). It incorporates numerous scanning agents (e.g. Nessus, Nmap, Netsparker and a few others), and exposes an API to interact with the results. This was our starting point to explore threat related data. We could then couple this data with remote data sources (e.g. CVE data, exploit-db.com data).
We chose to use Maltego to explore the data as it's an incredibly powerful data exploration and visualisation tool, and writing transforms is straight forward. If you'd like to know more about Maltego here are some useful references:
It's also worth noting that for the demonstrations that follow we've obscured our clients' names by applying a salted 'human readable hash' to their names. A side effect is that you'll notice some rather humorous entries in the images and videos that follow.
Jumping into the interesting results, these are some of the tasks that we can perform:
In summary, building 'clever tools' that allow you to combine human insight can be powerful. An experiences analyst with the ability to ask the right questions, and building tools that allows answers to be easily extracted, yields actionable tasks in less time. We're going to start using this approach internally to find new ways to explore the vulnerability data sets of our scanning clients and see how it goes.
In the future, we're working on incorporating other data sources (e.g. LogRhythm, Skybox). We're also upgrading our MVS API - you'll notice a lot of the Maltego queries are cumbersome and slow due to its current linear exploration approach.
The source code for the API, the somewhat PoC Maltego transforms, and the MVS (BroadView) API can be downloaded from our GitHub page, and the MVS API from here. You'll need a paid subscription to incorporate the exploit-db.com data, but it's an initiative definitely worth supporting with a very fair pricing model. They do put significant effort in correlating CVEs. See this page for more information.
Do get in touch with us (or comment below) if you'd like to know more about the technical details, chat about the API (or expand on it), if this is a solution you'd like to deploy, or if you'd just like to say "Hi".
The course has undergone the full reloaded treatment, with our trainers pouring new tips, tricks and skills into the course, along with incorporating feedback from previous students.
The training introduces all the core skills required to test applications across the major mobile platforms, particularly:
For a full break-down of the course structure check-out our BlackHat training page (https://www.blackhat.com/us-14/training/hacking-by-numbers-reloaded-mobile-bootcamp.html)
Your trainers will be Etienne (@kamp_staaldraad) and Jurgens, both crazy about mobile security and have executed numerous killshots on all the major mobile platforms.
- Etienne and Jurgens -
Wireless hacking, you say?
You may think wireless hacking is nothing new, and you may think it's just not that relevant or exciting. Come along to our BlackHat Wireless Bootcamp course and we'll show you different! We'll teach you the fundamentals every wireless hacker needs to know, but then move onto the really exciting, cutting edge stuff.
Cutting edge WiFi hacking, you say?
At SensePost we really enjoy wireless hacking - mostly because it gets us good results in terms of compromising our targets! With our years of experience in this area we've written our own tools, as well as refined others. In this course we'll reveal new techniques and tools (can you smell 0day?) that we'll hopefully be presenting at the conference, and give you exclusive hands on training with our very own Snoopy framework (a distributed, tracking, data interception, and profiling framework). Two lucky students who capture our CTFs will also go home with pre-built Snoopy drone. Every student will also get their own Alfa WiFi card to take home, as well as the latest Snoopy pre-release (Snoopy will run fine on your laptop too).
Here's an exact break down of what to expect from this course:
• Wi-Fi theory and background
• Breaking WEP
• Breaking WPA PSK
• Man in the middle attacks for WPA MGT (new attack vectors)
• Breaking WPS
• Wi-Fi Router back doors
• Rogue Access Points attack scenarios (new attack vectors)
• Exclusive Snoopy training
Who should attend?
Anyone interested in WiFi security. The course is relevant for both attackers and defenders (it'll let you put your defense into context). Students should have some technical ability in Linux, and understand networking fundamentals, but this is a bootcamp level course.
Dominic (@singe) and Glenn (@glennzw) will be your instructors. They're both avid wireless hackers, and never leave home without a high gain antenna and an Alfa card! They're looking forward to training you. You can find the sign-up page here.
-Glenn & Dominic
December sees SensePost presenting Hacking by Numbers: Mobile at BlackHat West Coast Trainings. This course was first presented at BlackHat Vegas 2013 and 44Con 2013, growing in popularity and content with each iteration. For more information continue reading below or visit https://blackhat.com/wc-13/training/Hacking-by-Numbers-Mobile.html.
The mobile environment has seen immense growth and has subsequently seen organisations racing to be the first to market with the next best app. The rapid increase in mobile popularity and the speed at which developers are forced to produce new applications has resulted in an ecosystem full of security vulnerabilities. As more organisations are moving from web applications to mobile applications, penetration testers are required to adapt their testing methodology to keep pace with the changing platforms. Mobile applications developers have been lulled into a false sense of security due to the belief that "the platform will take care of the security". The Hacking by Numbers: Mobile course aims to help both penetration testers and mobile applications developers to find and understand common security vulnerabilities on a wide range of mobile platforms. The course teaches a mobile application security testing methodology that can easily be applied to mobile applications on Android, iOS, Blackberry and Windows Mobile.
Rather than focus on a specific mobile platform or a set of testing tools, the Hacking by Numbers Mobile course covers the following:
Lab exercises include:
Looking forward to seeing you all in Seattle!