Mon, 23 Feb 2015

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.

Introduction

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.

Conclusion

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.

Thu, 19 Jun 2014

Friday the 13th seemed like as good a date as any to release Snoopy 2.0 (aka snoopy-ng). For those in a rush, you can download the source from GitHub, follow the README.md file, and ask for help on this mailing list. For those who want a bit more information, keep reading.

What is Snoopy?

Snoopy is a distributed, sensor, data collection, interception, analysis, and visualization framework. It is written in a modular format, allowing for the collection of arbitrary signals from various devices via Python plugins.

It was originally released as a PoC at 44Con 2012, but this version is a complete re-write, is 99% Python, modular, and just feels better. The 'modularity' is possibly the most important improvement, for reasons which will become apparent shortly.

Tell me more!

We've presented our ongoing work with snoopy at a bunchofconferences under the title 'The Machines that Betrayed Their Masters'. The general synopsis of this research is that we all carry devices with us that emit wireless signals that could be used to:

Uniquely identify the device / collection of devices

Discover information about the owner (you!)

This new version of snoopy extends this into other areas of RFID such as; Wi-Fi, Bluetooth, GSM, NFC, RFID, ZigBee, etc. The modular design allows each of these to be implemented as a python module. If you can write Python code to interface with a tech, you can slot it into a snoopy-ng plugin.

We've also made it much easier to run Snoopy by itself, rather than requiring a server to sync to as the previous version did. However, Snoopy is still a distributed framework and allows the deployment of numerous Snoopy devices over some large area, having them all sync their data back to one central server (or numerous hops through multiple devices and/or servers). We've been working on other protocols for data synchronisation too - such as XBee. The diagram below illustrates one possible setup:

OK - but how do I use it?

I thought you'd never ask! It's fairly straight forward.

Hardware Requirements

Snoopy should run on most modern computers capable of running Linux, with the appropriate physical adapters for the protocols you're interested in. We've tested it on:

Laptop

Nokia N900 (with some effort)

Raspberry Pi (SnooPi!)

BeagleBone Black (BeagleSnoop!)

In terms of hardware peripherals, we've been experimenting with the following:

Technology

Hardware

Range

Wi-Fi

AWUS 036H

100m

Bluetooth

Ubertooth

50m

ZigBee

Digi Xbee

1km to 80kms

GSM

RTL2832U SDR

35kms

RFID

RFidler

15cm

NFC

ACR122U

10cm

The distances can be increased with appropriate antennas. More on that in a later blog post.

Software Requirements

Essentially a Linux environment is required, but of more importance are the dependencies. These are mostly Python packages. We've tested Snoopy on Kali 1.x, and Ubuntu 12.04 LTS. We managed to get it working on Maemo (N900) too. We're investigating getting it running on OpenWRT/ddWRT. Please let us know if you have success.

Data Visualization

Maltego is the preferred tool to perform visualisation, and where the beauty of Snoopy is revealed. See the README.md for instructions on how to use it.

I heard Snoopy can fly?

You heard right! Well, almost right. He's more of a passenger on a UAV:

There sure is a lot of stunt hacking in the media these days, with people taking existing hacks and duct-taping them to a cheap drone for media attention. We were concerned to see stories on snoopy airborne take on some of this as the message worked its way though the media. What's the benefit of having Snoopy airborne, then? We can think of a few reasons:

Speed: We can canvas a large area very quickly (many square kilometres)

TTL (Tag, Track, Locate): It's possible to search for a known signature, and follow it

We're exploring the aerial route a whole lot. Look out for our DefCon talk in August for more details.

Commercial Use

The license under which Snoopy is released forbids gaining financially from its use (see LICENSE.txt). We have a separate license available for commercial use, which includes extra functionality such as:

Syncing data via XBee

Advanced plugins

Extra/custom transforms

Web interface

Prebuilt drones

Get in contact (glenn@sensepost.com / research@sensepost.com) if you'd like to engage with us.

Fri, 13 Jun 2014

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:

So far our API is able to query a database populated from CVE XML files and data from www.exploit-db.com (they were kind enough to give us access to their CVE inclusive data set). It's a standalone Python program that pulls down the XML files, populates a local database, and then exposes a REST API. We're working on incorporating other sources - threat feeds, other logging/scanning systems. Let us know if you have any ideas. Here's the API in action:

Parsing CVE XML data and exposing REST API

Querying a CVE. We see 4 public exploits are available.

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:

Show me all hosts that have a critical vulnerability within the last 30 days

Clicking the links in the above scenarios will display a screenshot of a solution. Additionally, two video demonstrations with dialog are below.

Retrieving all recent vulnerabilities for a client 'Bravo Tango', and checking one of them to see if there's public exploit code available.

Exploring which clients/hosts have which ports open

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".

Fri, 7 Feb 2014

This evening we were featured on Channel 4's DataBaby segment (link to follow). Channel 4 bought several second hand mobile phones that had been "wiped" (or rather reset to factory default) from various shops. Our challenge was to recover enough data from these seemingly empty phones to identify the previous owners.

After a long night of mobile forensics analysis, we had recovered personal data from almost every phone we had been provided with. This information included:

Browsing history

Cookies (e.g. email and Facebook)

Contacts

SMS messages

Photographs

Address information

Personal documents

It would have been theoretically possible to use the cookies to impersonate the users - i.e. log in as the previous owners. We opted not to do this, as it was crossing an ethical line.

What's the lesson here?

Be very careful when selling your phone. It's fairly trivial to recover large amounts of data from mobile phones - and the tools to do so are freely available.

How can I protect myself?

This will depend on what type of phone you have, and specifically whether the data is encrypted, and if it is, if the key is recoverable. Unencrypted phones were easy game.

iPhone devices encrypt their data by default, which makes it hard (almost impossible) to recover data after performing a factory reset. There are some attacks against iPhones older than 4s which may have more success.

Android devices by default have no encryption, which means that somebody (like us) could easily recover large amounts of supposedly deleted data. It's a good idea to keep your phone encrypted.

Both Windows phone 8 and BlackBerry allow optional encryption to be configured, but this is not enabled by default. Windows phone 7 does not support encryption of the core filesystem.

If you have an existing phone that you're about to sell we'd recommend you encrypt the phone twice after resetting it to factory default (once to destroy your data, the second time to destroy the key used for the first round).

Mon, 20 Jan 2014

Aah, January, a month where resolutions usually flare out spectacularly before we get back to the couch in February. We'd like to help you along your way with a reverse engineering challenge put together by Siavosh as an introduction to reversing, and a bit of fun.

The Setup

This simple reversing challenge should take 4-10+ hours to complete, depending on your previous experience. The goal was to create an interactive challenge that takes you through different areas of the reverse engineering process, such as file format reverse engineering, behavioural and disassembly analysis.

Once you reached the final levels, you might need to spend some time understanding x86 assembly or spend some time refreshing it depending on your level. To help out, Siavosh created a crash course tutorial in x86 assembly for our malware workshop at 44con last year, and you can download that over here.

The zip file containing the reversing challenge and additional bytecode binaries could be found here.

Send your solution(s) to challenge at sensepost.com

The Scenario

You've been called into ACME Banks global headquarters to investigate a breach. It appears Evilgroup has managed to breach a server and deploy their own executable on it (EvilGroupVM.exe). The executable is software that accepts bytecode files and executes them, similar to how the Java Virtual Machine functions. Using this technique, Evilgroup hopes they can evade detection by antivirus software. Their OPSEC failure meant that both the virtual machine executable and several bytecode files were left behind after the cleanup script ran and it's your job to work out the instruction set of EvilGroupVM.exe.

Disclaimer: When using the term "virtual machine" we mean something like the Java Virtual Machine. A software based architecture that you can write programs for. This particular architecture, EvilGroupVM.exe, has nine instructions whose operation code (opcode) you need to find through binary reverse engineering.

The tools you will require are:

A hex editor (any will do)

A disassembler like IDA (the free version for Windows will work if you don't have a registered copy)

A debugger, Olly or WinDBG on Windows, Gnu GDB or EDB on Linux https://www.gnu.org/software/gdb/

Basic Usage: Unzip the reverseme folder, open a command line and cd to it. Depending on operating system, type

For example, to run the helloworld bytecode file on Windows, you would type:

EvilGroupVM.exe helloworld

IMPORTANT: Note that the EvilGroupVM.exe architecture has debugging capabilities enabled. This means, it has one instruction that shows you the thread context of a binary when it is hit. Once you start developing your own bytecode binaries, it is possible to debug them (but you need to find the debug instruction/opcode first).

The outcome of this exercise should include the following key structures in your report:

A description of the binary file format. For example:

What does the bytecode file header look like?

What determines where execution will start once the bytecode is loaded in the VM?

Does the architecture contain other parts of memory (like a stack) where it can store data and operate on them?

The instruction set including their impact on the runtime memory. You should:

Find all instructions that the EvilGroupVM.exe accepts

Analyse each of them and understand how they make changes to the runtime memory of the bytecodes thread

Write a proof of concept self modifying bytecode file that prints your name to the screen. The binary must be self modifying, that is, you may not use the "print_char" instruction directly, rather, the binary must modify itself if it wants to make use of "print_char".

For the advanced challenge, if you have the ability and time, send us back a C file that, when compiled, will give an almost exact match compared to EvilGroupVM (Ubuntu Linux) or EvilGroupVM.exe (Windows). Focus on getting pointer arithmetic and data structures correct.

In case you missed it earlier, the zip file containing the reversing challenge and additional bytecode binaries could be found here.