When doing wireless assessments, I end up generating a ton of different scripts for various things that I thought it would be worth sharing. I'm going to try write some of them up. This is the first one on decrypting WPA/2 PSK traffic. The second will cover some tricks/scripts for rogue access-points. If you are keen on learn further techniques or advancing your wifi hacking knowledge/capability as a whole, please check out the course Hacking by Numbers: Unplugged, I'll be teaching at BlackHat Las Vegas soon.
When hackers find a WPA/2 network using a pre-shared key, the first thing they try and do most times, is to capture enough of the 4-way handshake to attempt to brute force the pairwise master key (PMK, or just the pre-shared key PSK). But, this often takes a very long time. If you employ other routes to find the key (say a client-side compromise) that can still take some time. Once you have the key, you can of course associate to the network and perform your layer 2 hackery. However, if you had been capturing traffic from the beginning, you would now be in a position to decrypt that traffic for analysis, rather than having to waste time by only starting your capture now. You can use the airdecap-ng tool from the aircrack-ng suite to do this:
airdecap-ng -b <BSSID of target network> -e <ESSID of target network> -p <WPA passphrase> <input pcap file>
However, because the WPA 4-way handshake generates a unique temporary key (pairwise temporal key PTK) every time a station associates, you need to have captured the two bits of random data shared between the station and the AP (the authenticator nonce and supplicant nonce) for that handshake to be able to initialise your crypto with the same data. What this means, is that if you didn't capture a handshake for the start of a WPA/2 session, then you won't be able to decrypt the traffic, even if you have the key.
So, the trick is to de-auth all users from the AP and start capturing right at the beginning. This can be done quite simply using aireplay-ng:
aireplay-ng --deauth=5 -e <ESSID>
Although, broadcast de-auth's aren't always as successful as a targeted one, where you spoof a directed deauth packet claiming to come from the AP and targeting a specific station. I often use airodump-ng to dump a list of associated stations to a csv file (with --output-format csv), then use some grep/cut-fu to excise their MAC addresses. I then pass that to aireplay-ng with:
cat <list of associated station MACs>.txt | xargs -n1 -I% aireplay-ng --deauth=5 -e <ESSID> -c % mon0
This tends to work a bit better, as I've seen some devices which appear to ignore a broadcast de-auth. This will make sure you capture the handshake so airdecap can decrypt the traffic you capture. Any further legitimate disconnects and re-auths will be captured by you, so you shouldn't need to run the de-auth again.
Taking inspiration from Vlad's post I've been playing around with alternate means of viewing traffic/data generated by Android apps.
The technique that has given me most joy is memory analysis. Each application on android is run in the Dalvik VM and is allocated it's own heap space. Android being android, free and open, numerous ways of dumping the contents of the application heap exist. There's even a method for it in the android.os.Debug library: android.os.Debug.dumpHprofData(String filename). You can also cause a heap dump by issuing the kill command:
kill -10 <pid number>
1.) Open DDMS in Eclipse and attach your device/emulator
* Set your DDMS "HPROF action" option to "Open in Eclipse" - this ensures that the dump file gets converted to standard java hprof format and not the Android version of hprof. This allows you to open the hpof file in any java memory viewer.
* To convert a android hprof file to java hprof use the hprof converter found in the android-sdk/platform-tools directory: hprof-conv <infile> <outfile>
2.) Dump hprof data
Once DDMS has done it's magic you'll have a window pop up with the memory contents for your viewing pleasure. You'll immediately see that the applications UI objects and other base classes are in the first part of the file. Scrolling through you will start seeing the values of variables stored in memory. To get to the interesting stuff we can use the command-line.
3.) strings and grep the .hprof file (easy stuff)
To demonstrate the usefulness of memory analysis lets look at two finance orientated apps.
The first application is a mobile wallet application that allows customers to easily pay for services without having to carry cash around. Typically one would do some static analysis of the application and then when it comes to dynamic analysis you would use a proxy such as Mallory or Burp to view the network traffic. In this case it wasn't possible to do this as the application employed certificate pinning and any attempt to man in the middle the connection caused the application to exit with a "no network connection" error.
So what does memory analysis have to do with network traffic? As it turns out, a lot. Below is a sample of the data extracted from memory:
And there we have it, the user login captured along with the username and password in the clear. Through some creative strings and grep we can extract a lot of very detailed information. This includes credit card information, user tokens and products being purchased. Despite not being able to alter data in the network stream, it is still easy to view what data is being sent, all this without worrying about intercepting traffic or decrypting the HTTPS stream.
A second example application examined was a banking app. After spending some time using the app and then doing a dump of the hprof, we used strings and grep (and some known data) we could easily see what is being stored in memory.
strings /tmp/android43208542802109.hprof | grep '92xxxxxx'
And there we go, a fully "decrypted" JSON response containing lots of interesting information. Grep'ing around yields other interesting values, though I haven't managed to find the login PIN yet (a good thing I guess).
Next step? Find a way to cause a memory dump in the banking app using another app on the phone, extract the necessary values and steal the banking session, profit.
Memory analysis provides an interesting alternate means of finding data within applications, as well as allowing analysts to decipher how the application operates. The benefits are numerous as the application "does all the work" and there is no need to intercept traffic or figure out the decryption routines used.
On a recent engagement, we were tasked with trying to gain access to the network via a phishing attack (specifically phishing only). In preparation for the attack, I wanted to see what software they were running, to see if Vlad and I could target them in a more intelligent fashion. As this technique worked well, I thought this was a neat trick worth sharing.
First off the approach was to perform some footprinting to see if I could find their likely Internet breakout. While I found the likely range (it had their mail server in it) I couldn't find the exact IP they were being NAT'ed to. Not wanting to stop there, I tried out Vlad's Skype IP disclosure trick, which worked like a charm. What's cool about this approach is that it gives you both the internal and external IP of the user (so you can confirm they are connected to their internal network if you have another internal IP leak). You don't even need to be "friends", you can just search for people who list the company in their details, or do some more advanced OSINT to find Skype IDs of employees.
Once I had that IP, I went on a hunt for web logs that had been indexed by a search engine, that contained hits from that IP. My thinking was that I run into indexed Apache or IIS logs fairly often when googling for IPs or the like, so maybe some of these contained the external NAT IP of the target organisation. It took a fair bit of search term fiddling, but in the end I found 14 unique hits from their organisation semi-complete with User Agent information (some were partially obscured).
This provided me with the following stats:
Win XP 8
Win 7 32 3
Win 7 64 3
IE 8 8
IE 6 3
IE 7 1
IE 9 1
Win 7 IE 8 4
Win XP IE 8 4
Win XP IE 6 3
Win 7 IE 9 1
Win XP IE 7 1
Anecdotally, and to give the story an ending, it turned out that BlackHole and Metasploit's Browser AutoPwn were a bust, even our customised stuff got nailed by Forefront when the stager tried to inject it's payload at runtime, but an internal tool we use for launching modified meterpreter payloads worked like a charm (although, periodically died on Win7 64bit, so I'd recommend using reverse-http, you can restart sessions, and firing up a backup session to restart the other with).
We blogged a little while back about the Snoopy demonstration given at 44Con London. A similar talk was given at ZaCon in South Africa. Whilst we've been promising a release for a while now, we wanted to make sure all the components were functioning as expected and easy to use. After an army of hundreds had tested it (ok, just a few), you may now obtain a copy of Snoopy from here. Below are some instructions on getting it running (check out the README file from the installer for additional info).
Remind me what Snoopy is?
Snoopy is a distributed tracking, data interception, and profiling framework.
-Ubuntu 12.04 LTS 32bit online server
-One or more Linux based client devices with internet connectivity and a WiFi device supporting injection drivers. We'd recommend the Nokia N900.
-A copy of Maltego Radium
After obtaining a copy from github run the install.sh script. You will be prompted to enter a username to use for Snoopy (default is 'woodstock') and to supply your public IP address. This is depicted below:
This installation will take around 3-5 minutes. At the end of the installation you will be presented with a randomly generated password for the web interface login. Remember it. You may now run the server component with the command snoopy, and you will be presented with the server main menu, as depicted below.
Selecting the 'Manage drone configuration packs' menu option will allow you to create custom installation packs for all of your drone devices. You will be presented with download links for these packs, such that you can download the software to your drones.
From your drone device download and extract the file from given link. Run setup_linux.sh or setup_n900.sh depending on your drone.
All collected probe data gets uploaded to the Snoopy server every 30 seconds. All associated clients have their internet routed through the server over OpenVPN. If you so desire, you can explore the MySQL database 'snoopy' to see this raw data. Graphical data exploration is more fun though.
In the Snoopy server menu select 'Configure server options' > 'List Maltego transform URLs'. This will give URLs to download Maltego Snoopy entities and machines, as well as a list of TDS transform URLs. You will need to download and add the entities and machines to your local Maltego installation, and add the transform URLs to your Maltego TDS account (https://cetas.paterva.com/tds). This is depicted below.
We can explore data my dragging the 'Snoopy' entity onto the canvas. This entity has two useful properties - 'start_time' and 'end_time'. If these are left blank Snoopy will run in 'real time' mode - that is to say displaying data from the last 5 minutes (variable can be set in server configuration menu). This time value will be 'inherited' by entities created from this point. The transforms should be obvious to explore, but below are some examples (further examples were in the original blog post).
I shall write a separate blog post detailing all the transforms. For now, enjoy playing around.
You can access the web interface via http://yoursnoopyserver:5000/. You can write your own data exploration plugins. Check the Appendix of the README file for more info on that.
Organising our yearly training event at Blackhat in Las Vegas is no mean feat. With well over two hundred students to prepare for, the size of Caesars Palace to contend with (last year, we, on average, walked 35 kilometers in distance just inside the hotel) and the manic environment, it's a stressful environment.
There are many Blackhat helpers running about, but none like Mr Brad 'the Nurse' Smith. Brad would always be there popping his head into our rooms, making sure us plakkers had what we needed, when we needed it and always with that trademark smile. Armed with his two-way radios (almost like a western gun-slinger in the way he was able to whip them off and put them into action in seconds), he knew who to call and where to get it. This video from Toolswatch, shot at his last Blackhat, summed up his enthusiasm:
Needless to say, our Blackhat Las Vegas experience was often made possible with a few key individuals helping us and Brad was one of them. A rather apt quote from Gert was:
Brad's health has suffered in recent years and he missed Blackhat this year, due to a stroke. No more gunslinger walking the corridors and his absence was notable. Brad's health has since deteriorated after having surgery on his skull and Nina's recently made the hard decision to have all medications stopped and feeding tube turned off with the exception of pain medications as needed.He is the guy that got shit sorted *full stop*
Our thoughts are with Brad's family and Nina right now in this hard hour. Brad, you will be missed by the crazy South Africans (and other nationalities!) at SensePost. Thanks for all your help over the past many years.