Modifying Android Apps: A SEC575 Hands-on Exercise, Part 1

By Joshua Wright

Blog1

 Introduction

As a security professional, I’m called on to evaluate the security of Android applications on a regular basis. This evaluation process usually takes on one of two forms:

  • Evaluate app security from an end-user perspective
  • Evaluate app security from a publisher perspective

While there is a lot of overlap between the two processes, the difference effectively boils down to this: whose risk perspective does my customer care about the most?

When an app publisher wants me to evaluate the security of their Android app, I need to determine if the app employs sufficient controls to protect the required app functionality and publisher brand. Often, this requires me to identify critical app components (critical for my customer, such as how they make revenue from the app, or the integrity of the data transmitted by the app), and determine if I can manipulate them in interesting ways.

As a guide, I developed an Application Report Card system to steer an analyst through the application evaluation process. One of these tasks is to manipulate the Android application by modifying the low-level Smali bytecode, removing the intended publisher functionality.

Blog 1a

In my SEC575: Mobile Device Security and Ethical Hacking course, we use a custom application, IsItDown as our evaluation target. In the exercise, participants have to install and run the application to identify the app functionality and constraints, then decompile, modify, reassemble, and re-sign the application so the app can be used without restrictions.

In this 2-part article, we’ll take a peek at the SEC575 hands-on lab exercise for modifying Android apps. In the first part, we’ll take a look at how we can leverage the Apktool utility to decompile an Android app, followed by a quick primer on reading Smali code. In the second part, we’ll generate custom keys to sign the modified application so that it can be used on a virtual or physical Android device, and look at defense techniques.

Feel free to download the IsItDown application and follow along. You’ll also need the following tools for your system:

Evaluate the App

Blog2

After starting a virtual Android device (or connecting your physical Android device over USB), use the adb utility to install the IsItDown.apk application as shown above. Next, run the app and experiment.

IsItDown is a basic IsItDownForJustMeOrForEveryoneElseToo app… except it’s only testing from your mobile device. Frankly, it’s not that useful, but it serves our needs fine.

If you are working from a virtual device, you’ll quickly be disappointed. Not only does IsItDown have an obnoxious banner ad on the bottom of the page, it only teases you with the promise of functionality before it tells you to go away.

Blog3

Our goal here is modify the Android application to allow us to run in the Android Emulator, and to remove that annoying banner ad.

Decompile the App

First, we’ll use Apktool written by Ryszard Wisniewski and Connor Tumbleson to convert the IsItDown.apk file into Smali code. Smali code is a representation of the app code using the Android Dalvik opcodes – essentially an intermediate representation of the code between the original Java source and the processor-specific assembly instructions. Apktool allows us to take the Android APK file, convert it into a Smali source representation that can be modified, and then recompile it back into a new APK file.

Note: The pedantic reader will no doubt be questioning my use of “decompile” as a verb here. Converting an Android APK file to Smali code is not quite decompilation, but it’s not quite disassembly either. It’s somewhere in the middle. I’ll keep using decompilation, since you are getting a high-level representation of the app code in the Smali file, but if you are more comfortable with the decompilation verb, feel free to search+replace this article.

Apktool isn’t so much a hacking tool as it is a mechanism to evaluate Android applications. Sure, people with ill intent can manipulate an application for evil purposes, but it can also be used for Android application troubleshooting, and for the localization (adding local language support) for applications as well. Don’t use it to do evil things, OK? (Ed.: I second that.)

Blog 2a

Make sure you have apktool.jar (renamed from apktool-2.0.0.jar), apktool.bat and IsItDown.apk all in the same directory (or put apktool.jar and apktool.bat in your system PATH somewhere). Next, use apktool.bat to decompile the APK file, as shown here:

Blog 4

Apktool will generate a new directory IsItDown that holds the application resources, AndroidManifest.xml declarations, the original signature information from the developer, and the Smali code itself.

apktool-d-explorer

Modify the App

Browsing to the smali directory, we’ll see a directory structure created for the application package names (e.g. com/willhackforushi/isitdown/). For our simple application, only a handful of Smali files are generated, as shown here:

Blog 3a

Most of these Smali files include auto-generated code, so we don’t have to look through all of them. First, let’s search for a reference to the string “No emulator use permitted.” using the Windows findstr.exe utility:

Blog 4a

Here we see the string is in the MainActivity.smali file. This is unusual; typically, string values will be defined in the res/values/strings.xml file, making it easier to localize the application. Here, the developer just got lazy, and embedded the string directly in the Java source. This makes it a little easier for us to evaluate the Smali code though: simply open the MainActivity.smali file with your favorite editor and skip to the line where the string is defined.

Blog 6

At this point, if you’re not a developer, or have never seen Smali code before, you might be like “WTW? I’m supposed to read this?”. Have no fear! You just need to know a few things about Smali:

  • Smali uses declared registers as placeholders for objects, variables. v0 is a local register, p0 is a parameter register (e.g. something passed to the function/method)
  • Syntax in Smali is always destination, then source
  • Object types are specified with a capital letter at the end of the object or method:
    • V – Void
    • Z – Boolean
    • B – Byte
    • S – Short
    • C – Char
    • I – Int
    • J – Long (64-bits)
    • F – Float
    • D – Double (64-bits)
    • L – Object

A cheat sheet is a useful thing to have as well, that explains common Smali opcodes and their functionality. Here’s one from my SEC575 course!

Blog 8

Finally, the reference maintained by Gabor Paller at http://pallergabor.uw.hu/androidblog/dalvik_opcodes.html is awesome, and frankly, is how I learned to read Smali code. You should bookmark that link!

Looking at that Smali code, there is a lot of stuff we don’t care about. We know that the application shows us an error “Go away” and refuses to run. Logically, before that message is displayed, we should see some code that determines whether or not to display that error. Sure enough, check out line 350:

Blog 9

Line 350 invokes a method calls isEmulator() which returns a Boolean value (see the big “Z” at the end?). The Boolean result is moved to the v13 register, and then the if-eqz opcode  determines if the value is 0 (or “False”). If v13 is equal to 0, then the code jumps to the code_0 block. Otherwise, we get the nasty “No emulator use permitted.” message.

Not so hard, right? Knowing this, we can make a simple change to this code. Consider this small “fix”:

Blog 11See what I did on line 354? I changed if-eqz to if-nez, effectively inverting the test. Now, even though isEmulator() still returns True on emulated devices, the code behaves as if it the device were not an emulator, jumping to the cond_0 block.

This is not completely desirable, since this change would invert the test, and break the functionality for legitimate devices that install the modified IsItDown.apk file. You could modify the isEmulator() method to always return False as another option, but this is what I ended up doing:

Blog 12

On line 354 is the original if-eqz test, and then I added the inverted test immediately afterward. This way, regardless of what the isEmulator() method returns, the code always skips the “No emulator use permitted” message. It’s a little hackish, but it gets the job done. (Ed.: Did Tom Liston teach you that, Josh?)

Next up: removing that banner ad. Banner ads are usually displayed in a WebView object, which is effectively a little tiny web browser in the app. Searching for the string “http:” reveals two references that look like the source of our advertising:

Blog 13

Searching for that same string in the MainActivity.smali and MainActivity$1.smali files reveals code like this:

Blog 14

In this example, line 268 loads the reference to the WebView in the v2 parameter, while line 270 loads the ad URL in the v3 parameter. Line 272 loads the URL content into the WebView. Easy enough to change that behavior:

Blog 15

Simply commenting-out the invoke-virtual opcode that fills the WebView is enough to cause the banner ad to stop loading. Repeat this step for both MainActivity.smali, and MainActivity$1.smali and you’re done!

Concluding Part One

In this first part of our article, we saw how Apktool can be used to decompile an Android application, and looked at the Smali code with a focus on changing the code to overcome Android emulator restrictions and to disable an annoying banner ad. In Part Two we’ll pick up where we left off and re-build the application and sign it with the Java Development Kit utilities so we can run the modified app on an emulated or real Android device. Finally, we’ll address defensive techniques that you can use in your next Android pen test report with suggestions to pass on to Android developers, and briefly discuss how Android testing can also be useful when evaluating iOS targets.

Until next time,

-Josh

 

Upcoming SANS Special Event – 2018 Holiday Hack Challenge

KringleCon

SANS Holiday Hack Challenge – KringleCon 2018

  • Free SANS Online Capture-the-Flag Challenge
  • Our annual gift to the entire Information Security Industry
  • Designed for novice to advanced InfoSec professionals
  • Fun for the whole family!!
  • Build and hone your skills in a fun and festive roleplaying like video game, by the makers of SANS NetWars
  • Learn more: www.kringlecon.com
  • Play previous versions from free 24/7/365: www.holidayhackchallenge.com

Player Feedback!

  • “On to level 4 of the #holidayhackchallenge. Thanks again @edskoudis / @SANSPenTest team.” – @mikehodges
  • “#SANSHolidayHack Confession – I have never used python or scapy before. I got started with both today because of this game! Yay!” – @tww2b
  • “Happiness is watching my 12 yo meet @edskoudis at the end of #SANSHolidayHack quest. Now the gnomes #ProudHackerPapa” – @dnlongen
kringle_02

My Juiced Up WiFi Pineapple Configurator Script

By Chris Crowley

I recently acquired a WiFi Pineapple Mark V to replace my Mark IV, and I’ve got a config script to help folks simplify the config and use of this amazing product.

For those of you unfamiliar with the WiFi Pineapple, it is a wireless attack platform in a box, excellent for penetration testers.  It collects a variety of tools into a pen test specific device, a convenient single portable appliance for all kinds of wonderful Wifi hacks. The ability to impersonate a specific access point (AP) is present, as well as abusing client preferred network lists using Karma. You can do funny things like rick rolling, or nasty delivery of a meterpreterer with every page that the user browses to. There are configurable options to exclude specific devices from testing (a black list), or provide a list of devices that are within scope (a white list, which is a much safer way to ensure you don’t end up attacking a bunch of nearby devices that aren’t in scope of your pen test, which is kind of a big deal if you want to avoid lawsuits and/or jail time).

One guy I know turned on a device in the airport to check to be sure that it was working for a demonstration he was on his way to deliver, and he was frustrated that he wasn’t able to get his client to connect. When he logged in to the console, he realized that the people sitting around him had automatically connected to his device. So, use your Wifi Pineapple with caution!

In this article, I’d like to share a modified WiFi Pineapple configuration script (wp4.sh) that I created, which should really help simplify and improve your configuration.  This script will get your rolling with your WiFiPineapple quickly.

I’m a lazy person, and my tweaked wp4.sh config script is intended to make setup of the networking configuration easier for me by querying the system I’m setting up for reasonable default values. Sure, I could have just modified the script to the defaults for my computer, but that’s not the right fix for the long term. I also optionally redirect http/https traffic to the Burp web application manipulation proxy via iptables.

In this case, my setup is a Linux system wired upstream of the Pineapple. I still like this configuration even though the Mark V now has two wireless antennas (an Atheros b/g/n and a Realtek b/g) that enable binding it to a nearby access point while maintaining the attack capability. I like the wired setup because it lets me observe and manipulate the traffic with my Linux host. (There are a number of cool ways to manipulate traffic on the Pineapple, too, via infusions. Check out the Pineapple Bar on your Pineapple if you haven’t done so lately.)

I threw a few tweaks into my script that I’ll discuss briefly:

*Change 1
I use a system that has a wireless interface that is labeled eth1. The original wp4 script gives me the option to change it from the default but offers a naive default option, so I check for the eth1 interface, or wlan interfaces that are up:

 proposedif=`ip link show | egrep "eth1|wlan[0-9]" | grep UP | cut -f2 -d":" | sed 's/ //g'`

*Change 2
Similarly, I check the IP address of the computer, and offer the actual IP address as the default option on the IP address of the PineappleLAN interface. I don’t check for that interface to be up, because I assume I have connected via a wired connection and I would at least be awake enough to remember to do that. YMMV.

proposedip=`ip addr show $pineapplelan| grep "inet " | sed 's/^ \{1,\}//' | cut -f2 -d" " | cut -f1 -d"/"`

*Change 3
I often want to redirect port 80 and port 443 traffic into the fantastic Burp interception proxy in my testing. I’m a lazy guy, so I give myself the option to do so right within the startup script.

echo -n "Redirect 80/443 to 8080? (y/n) [N]: "
read burp
burp=`echo $burp | cut -c1`
if [[ $burp == 'y' || $burp == 'Y' ]]; then
burp=y #Thanks Samuel Adams
fi

### and

if [[ $burp == 'y' ]]; then
## HTTP TRAFFIC
iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to
-port 8080
## HTTPS TRAFFIC
iptables -t nat -A PREROUTING -p tcp --destination-port 443 -j REDIRECT --t
o-port 8080
## CHECK FOR BURP
pgrep -fl burp 2>&1 > /dev/null || echo "Are you sure burp suite is running
?\nOr maybe you intend to use something else. I didn't check for that."
fi

If I say “Y” the script will set my iptables rules to redirect client requests for HTTP and HTTPS connections into my burp suite.

I typically use this sort of setup to inspect the connections coming from a device. This is useful for application assessments, as well as profiling client (the person) behavior. In the screenshot below case, I’ve used my Pineapple to grab traffic from a wireless client operated by a coffee snob looking for excellent espresso drinks.

Of course, this will blow up on HTTPS connections because of cert mismatches.  In the SANS SEC575 course on Mobile Device Security and Penetration Testing, we talk about some strategies for dealing with SSL certificate mismatches, including using the SSLStrip module that is built into WiFiPineapple via the Pineapple Bar addons section.

*Change 4
I was surprised when I checked my firewall the first time I ran the original wp4.sh to see that all the rules had been flushed!  Yikes!  So, I added a little warning to myself and a reminder that the firewall rules had all been flushed, and I would need to restart the firewall to put the default rules back.

echo "iptables chains and rules cleared - your shields have been dropped"

### and

echo "Remember to run service iptables restart when you're done!"
echo "iptables chains and rules were cleared"
echo ""
echo "service iptables restart"

Putting all these changes together inside the whole wp4.sh script, here’s are the results, suitable for copying and pasting:

#!/bin/bash
#define variables

echo "$(tput setaf 1)  _       ___ _______    ____  _                              __   "
echo " | |     / (_) ____(_)  / __ \\(_)___  ___  ____ _____  ____  / /__ "
echo " | | /| / / / /_  / /  / /_/ / / __ \/ _ \/ __ '/ __ \/ __ \/ / _ \\"
echo " | |/ |/ / / __/ / /  / ____/ / / / /  __/ /_/ / /_/ / /_/ / /  __/"
echo " |__/|__/_/_/   /_/  /_/   /_/_/ /_/\___/\__,_/ .___/ .___/_/\___/ "
echo " $(tput sgr0) OWN the Network                            $(tput setaf 1)/_/   /_/$(tput sgr0)       v2.1"
echo ""

echo -n "Pineapple Netmask [255.255.255.0]: "
read pineapplenetmask
if [[ $pineapplenetmask == '' ]]; then
pineapplenetmask=255.255.255.0 #Default netmask for /24 network
fi

echo -n "Pineapple Network [172.16.42.0/24]: "
read pineapplenet
if [[ $pineapplenet == '' ]]; then
pineapplenet=172.16.42.0/24 # Pineapple network. Default is 172.16.42.0/24
fi

echo -n "Interface between PC and Pineapple [eth0]: "
read pineapplelan
if [[ $pineapplelan == '' ]]; then
pineapplelan=eth0 # Interface of ethernet cable directly connected to Pineapple
fi

And here’s a script that just does the NAT firewall:

#!/bin/bash

## CHECK FOR ROOT
wai=`whoami`

if [[ "$wai" != "root" ]]
then
	echo "

You need to be uid 0. Re-run as:

sudo $0
"
	exit
fi

## SET SYSTEM TO PREROUTING IP PACKETS
echo "1" > /proc/sys/net/ipv4/ip_forward

## HTTP TRAFFIC
iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 8080

## HTTPS TRAFFIC
iptables -t nat -A PREROUTING -p tcp --destination-port 443 -j REDIRECT --to-port 8080

## CHECK FOR BURP
pgrep -fl burp 2>&1 > /dev/null || echo "Are you sure burp suite is running?\nOr maybe you intend to use something else. I didn't check for that."

One last thing I needed to do on the Mark_V itself is to update the route.

I use this set up for application assessment, client activity inspection, and client content manipulation, simplifying and streamlining my pen test work. I recently had my Pineapple Mark V on when some friends came over to my house. They quickly commented on the cert mismatches, and were surprised at the content replacement they saw. So, don’t try this at home. Well, actually, the correct way to work on this at home and in your pen testing is to use the client whitelist feature of the Karma configuration to specifically include those devices which are appropriate for your testing.

There you have it.  Enjoy pen testing with the Pineapple!

-Chris Crowley

@CCrowMontance 

Wireless Tips, Tricks and Resources

[Editor’s Note: We’re continuing our series on useful tips and tricks for different kinds of pen testing, based on the SANS Pen Test Poster.  In this installment, Mr. Larry “Hax0r the Matrix” Pesce covers some great tips, ideas, and resources for wireless penetration tests.  Great stuff!

Earlier in this series, we covered:

John Strand’s tips on network penetration testing
Steve Sims’ tips on exploit development
Josh Wright’s tips on mobile device penetration testing

–Ed.]

By Larry Pesce

Methodology Tips

  • Recon – Channel hopping with Kismet is your best friend while performing recon. It is passive (silent) and will cycle through all of the available wireless channels supported by the wireless driver. Be mindful that while the wireless card is channel hopping, it misses all of the activity on the channels where it is not tuned.
  • Scanning – Channel hopping is great for discovery, as it will eventually tell us about every wireless network in the environment but sometimes we need to just focus on one channel to gain more information about the network. Locking your wireless card to a specific channel can be helpful in uncloaking a hidden network, capturing WPA-PSK 4-way handshake or more packets for further exploitation (such as WEP). Having TWO (or more) wireless cards allow one to channel hop and perform discovery, while the locked cards can gather more information for additional attacks in a more directed manner.
  • Exploitation – Exploitation comes in many forms in wireless networks; weak enterprise encryption, mis-configured authentication configuration, direct client attacks through ad-hoc connections. The best place for exploitation occurs at the weakest link; often the places where corporate assets go when outside of the enterprise environment: a local coffee shop, hotel, or even employee homes where open wireless networks may be de rigueur. These are great places to attack clients directly and observe plaintext traffic that can be leveraged for additional attacks against the enterprise.
  • Post-Exploitation – While exploitation often relies on leveraging a wireless vulnerability or mis-configuration, one can leverage compromised systems to gain information about additional wireless networks, and perhaps even participate in those already in the system’s preferred network list; use what you’ve gained access to in order to push further!
  • Misc (Reporting) – How do you get all of that information from the test into a format that makes sense as part of a vulnerability report? This will take some massaging, but output from tools (such as Kismet capture files and XML output) can often be leveraged within other standard tools to help illustrate risk. One example would be to utilize Kismet’s XML output to generate graphs based on observed wireless network configurations. One could also leverage other tools in new ways, such as leveraging the GISKismet database to query discovered network configurations.  (http://www.haxorthematrix.com/2012/ 12/how-i-use-giskismet-for-more-than- mapping.html) GISKismet, Joshua D. Abraham – http://giskismet.org 

Must-Have Tools

Software

  • Kismet – The best passive wireless discovery and analysis tool that will find all of the Wifi networks supported by the selected adapter (even cloaked/hidden networks). It is extensible through a plug-in architecture to support attacks, and additional wireless discovery, such as Bluetooth, Zigbee, DECT and others. Linux and OSX only. By Kismet, Mike Kershaw http://www.kismetwireless.net
  • Wireshark – A packet capture and analysis tool that is continually updated to improve protocol dissectors to translate the raw captures to human-readable format. Supports 802.11, 802.15.4, DECT and many other common wireless protocols. Supported on Linux, Windows and OSX. By Wireshark, Riverbed Technology, & Gerald Combs http://www.wireshark.org
  • Aircrack-ng suite – A “swiss-army” collection of tools from WEP and WPA cracking, packet capture decrypting, packet capture relationship analysis, and tunnel building tools supported under Linux, Windows and OSX. By Aircrack-ng, Thomas d’Otreppe http://www.aircrack-ng.org
  • Netmon – If you absolutely must capture in monitor mode under Windows, this is your huckleberry. In fact, it is the only huckleberry in town under Vista/7/8. By Netmon, Microsoft Corporation http://www.microsoft.com/en-us/download/details.aspx?id=4865
  • Kali Linux – Need some other wireless or other penetration testing tool? Chances are that the developers of Kali Linux (the successor to Backtrack 5) have gone through the trouble of making it work for you in this preconfigured penetration testing LiveCD/VM. By Kali Linux, Offensive Security http://www.kali.org/downloads
  • Scapy – Want to take your wireless testing to the next level by fuzzing all manner of protocols? Use Scapy with python to craft your own packets from scratch. Linux only. By Scapy, Philippe Biond http://www.secdev.org/projects/scapy

Hardware

*These tools are available on a commercial (cost) basis.

Great Resources for Staying Current

Associated SANS Courses

SEC617: Wireless Ethical Hacking, Penetration Testing, and Defenses www.sans.org/sec617

–Larry Pesce

Mobile Device Tips, Tricks and Resources

By Josh Wright

[In this third installation of tips originally included in the Ultimate SANS Pen Test Poster, we’ll turn to Josh Wright’s tips for mobile device penetration testing.  Josh shares some really useful insights here, as well as recommendations for tools (software and hardware) and resources for keeping current.  Nice stuff!

Click these links for the first two articles in this series:
John Strand’s tips on network penetration testing
Steve Sims’ tips on exploit development
–Ed.]

Methodology Tips

  • Recon – Identify the types of mobile devices used in the target environment, and the applications used. Consider using social networking data (“Posted with Tweetie for iOS”), e-mail headers (“X-Mailer: iPhone Mail (10B143)”) or Satori fingerprints for insider or public network/hotspot attacks.
  • Scanning – For local mobile device attacks, identify the wireless networks sought by the mobile device by inspecting network probes. Commonly weak network names such as “attwifi” and “linksys” are easy targets to impersonate and lure a victim into a hostile network.
  • Exploitation – Use man-in-the-middle attacks to intercept and inspect network protocols. Use traffic insertion attacks to deliver client-side exploits to vulnerable devices, or manipulate captured traffic to exploit supporting back-end mobile application servers. If you have physical possession of a device, bypass device passcode use by physically connecting the device to an attack workstation to root or jailbreak the device, exposing the filesystem data.
  • Post-Exploitation – Inspect commonly sensitive data areas on mobile devices for information such as the Notes, SMS, and browser history databases. Look for stored passwords in third-party applications, and for opportunities to extract saved passwords from keychain storage. If it is within  scope, consider adding a backdoor to the mobile device and returning to the end-user, giving you remote access to trusted networks.

Must-Have Tools: Software

  • Android Emulator and SDK Tools – The Android Emulator is almost as good as having real Android hardware since it can be used to run and assess Android applications. Pen testers can install the Android Emulator and the associated SDK tools for use in evaluating Android applications, and for attacking “stolen” Android devices. By Google http://developer.android.com/sdk
  • Plist Editor for Windows – The Plist Editor for Windows makes it easy to view and search binary or ASCII preference list files from compromised Apple iOS devices. Pen testers can use the Plist Editor for Windows to extract data from iOS built-in or third-party applications and harvest credentials or other sensitive data from numerous weak applications. By VOWSoft, Ltd.
    http://www.icopybot.com/plist-editor.htm
  • SQLiteSpy – SQLiteSpy reads, searches, and converts SQLite database files used on iOS and Android devices. Pen Testers can inspect the compromised contact, GPS history, browser history, SMS messages and more with SQLiteSpy. By Ralf Junker http://www.yunqa.de/delphi/doku.php/products/sqlitespy/index
  • Elcomsoft Phone Password Breaker* – EPPB is used to brute- force passwords on Apple iTunes backups, BlackBerry backups, and to bypass BlackBerry lock screen passcodes. Pen testers can use EPPB to decrypt and extract Apple and BlackBerry backup data from compromised hosts, and to bypass the passcode selection on BlackBerry devices. By Elcomsoft http://www.elcomsoft.com/eppb.html
  • iPhone Data Protection Tools – The iDPT suite creates an alternate iOS boot environment, allowing pen testers to brute-force PIN- based passcodes on older iPhone, iPod Touch and iPad devices.  By Jonathan Zdziarski and a community of contributing developers http://code.google.com/p/iphone-dataprotection
  • Redsn0w – Redsn0w is an all-purpose iOS jailbreaking tool for iOS 5 devices. If device theft is in the scope of the mobile device pen test, the pen tester can jailbreak and access confidential data on stolen devices using Redsn0w. By iPhone Dev Team http://www.redsn0w.us
  • Satori – Satori is a multi-faceted passive operating system fingerprinting tool, combining results from over 25 different protocols for precise results. Pen testers can use Satori to monitor LAN or WLAN traffic and identify the mobile devices that are present to target. By Eric Kollmann  http://chatteronthewire.org 
  • Burp Suite* – Burp Suite is commonly used for web application assessments, but it also makes a powerful HTTP/S network manipulation tool when combined with a man-in-the-middle attack. Pen testers can use Burp Suite to exploit HTTP-based mobile applications with server-side and client- side injection attacks. By PortSwigger, Ltd. http://portswigger.net/burp
  • Ettercap – Ettercap is a powerful man-in-the-middle tool, adding powerful network traffic manipulation and plugin functionality to exploit downstream devices. Pen testers can use Ettercap to capture plaintext passwords, intercept SSL traffic, and manipulate DNS name resolution on mobile devices. By Alberto Ornaghi, Marco Valleri, Emilio Escobar, and Eric Milam  http://ettercap.github.com/ettercap
  • Mercury Framework – The Mercury Framework is an Android security testing platform using a client/server architecture with plugin support for dynamic exploit delivery. Pen testers can use Mercury to evaluate the threat of malware on an Android platform, developing or leveraging available exploits to take advantage of Android platform vulnerabilities.  By Daniel Bradberry https://github.com/mwrlabs/mercury
  • iPhone Configuration Utility – The iPCU tool from Apple provides a set of iOS device management features for small organizations, creating XML profiles that can be installed on iOS devices to specify wireless networks, platform settings, certificate trust, and more. Pen testers can use iPCU to create malicious profiles, adding the attacker as a new trusted root CA as part of a phishing assessment. By Apple Corporation http://www.apple.com/support/iphone/enterprise

Must-Have Tools: Hardware

  • Google Nexus* – The Google Nexus is the perfect hardware for experimenting with Android attacks with WiFi, Bluetooth, and NFC wireless capabilities. As a “Google Experience” device, the Nexus also receives software updates to stay current with new Android OS features.  By Google http://www.google.com/nexus
  • iPad Mini* – A lower-cost alternative to an iPad or an unsubsidized iPhone, the iPad Mini runs all iOS applications. After jailbreaking the iPad Mini, pen testers can install and target vulnerable applications, or test the impact of attacks before delivering them to the production target environment. By Apple Corporation http://www.apple.com/ipad-mini 

* These tools are available on a commercial (cost) basis.

Great Resources for Staying Current

Twitter@pod2g |@lookout| @pof | @pentesttips | @joswr1ght

Associated SANS Courses

SEC575: Mobile Device Security and Ethical Hacking   www.sans.org/sec575    
–Josh Wright
Counter Hack

Special Request: Wireless Client Sniffing with Scapy

[Editor comment: Dude! A Scapy article by Josh Wright that can help us stay in scope and follow rules of engagement in a pen test? What’s not to like?  :)  –Ed.]

By Joshua Wright

I participate on the Scapy mailing list, helping out with questions where I am able. Recently, I saw a question that piqued my interest:
“What I’m looking to do is identify the MAC addresses of client devices without actually sniffing any packets containing actual data relating to website content, email content etc. […] Are there any packets I could look at that would contain the MAC of client devices but not contain any online usage data as outlined?”

If we want to investigate the presence of wireless client devices but want to avoid capturing any data frames, we can focus on management frames. WiFi networks use management frames to establish a connection to the network, disconnect from the network, and more. Three management frames are easily distinguishable as being sent by client devices only:

– Probe Request Frames
– Association Request Frames
– Reassociation Request Frames

Using Scapy, it is easy to write a little Python that checks for the IEEE 802.11 type field to determine if a frame is a management frame, then examine the subtype field to determine if it is one of the three only sent by client devices.

First, we need to put a wireless card interface into monitor mode, as shown:

root@bt:~# airmon-ng start wlan0
Interface      Chipset        Driver
wlan0          Ralink RT2870/3070 rt2800usb - [phy0]
                           (monitor mode enabled on mon0)

With the mon0 interface receiving packets in monitor mode, we can run the following Scapy script. I’ve added a lot of comments in the script to help explain what is happening.

#!/usr/bin/env python
# The previous line ensures that this script is run under the context
# of the Python interpreter. Next, import the Scapy functions:
from scapy.all import *
# Define the interface name that we will be sniffing from, you can
# change this if needed.
interface = "mon0"
# Next, declare a Python list to keep track of client MAC addresses
# that we have already seen so we only print the address once per client.
observedclients = []
# The sniffmgmt() function is called each time Scapy receives a packet
# (we'll tell Scapy to use this function below with the sniff() function).
# The packet that was sniffed is passed as the function argument, "p".
def sniffmgmt(p):
    # Define our tuple (an immutable list) of the 3 management frame
    # subtypes sent exclusively by clients. I got this list from Wireshark.
    stamgmtstypes = (0, 2, 4)
    # Make sure the packet has the Scapy Dot11 layer present
    if p.haslayer(Dot11):
        # Check to make sure this is a management frame (type=0) and that
        # the subtype is one of our management frame subtypes indicating a
        # a wireless client
        if p.type == 0 and p.subtype in stamgmtstypes:
            # We only want to print the MAC address of the client if it
            # hasn't already been observed. Check our list and if the
            # client address isn't present, print the address and then add
            # it to our list.
            if p.addr2 not in observedclients:
                print p.addr2
                observedclients.append(p.addr2)
# With the sniffmgmt() function complete, we can invoke the Scapy sniff()
# function, pointing to the monitor mode interface, and telling Scapy to call
# the sniffmgmt() function for each packet received. Easy!
sniff(iface=interface, prn=sniffmgmt)

Next, we simply run the script:

# python client-nodata-enum.py
WARNING: No route found for IPv6 destination :: (no default route?)
88:c6:63:fa:de:d9
00:26:b0:75:ef:f5
00:1f:3a:4f:a2:be
58:1f:aa:ba:77:fe
0c:74:c2:5e:25:11
60:33:4b:f0:43:34
f4:0b:93:04:b5:d9
90:4c:e5:60:61:2e
8c:58:77:90:a0:da
00:21:5c:7e:70:c3
From here, lots of opportunities become available. For example, we could disconnect each client from the network by adding the following line after the print statement:
sendp(RadioTap()/Dot11(type=0,subtype=12,addr1=p.addr2,addr2=p.addr3,addr3=p.addr3)/Dot11Deauth())

We might do this in a penetration test to gently disconnect each user from the network once while capturing the activity to observe the EAP types in use (since clients reconnect automatically, this will typically have little impact to the network, but it’s a good idea to ensure your customer is prepared for a potential outage if clients do not reconnect gracefully).

I’m not sure why the original request wanted to obtain a list of client MAC addresses without looking at data frames, but it’s a simple task with Scapy. In SANS SEC617: Wireless Ethical Hacking, Penetration Testing, and Defenses, we spend a good amount of time on Scapy with an emphasis on wireless fuzzing, while the Advanced Penetration Testing SEC660 course leverages Scapy for a number of wired-side attack techniques.
You can grab the script in this module, without comments, from my website at http://www.willhackforsushi.com/code/client-nodata-enum.py.
-Josh

 

Upcoming SANS Special Event – 2018 Holiday Hack Challenge

KringleCon

SANS Holiday Hack Challenge – KringleCon 2018

  • Free SANS Online Capture-the-Flag Challenge
  • Our annual gift to the entire Information Security Industry
  • Designed for novice to advanced InfoSec professionals
  • Fun for the whole family!!
  • Build and hone your skills in a fun and festive roleplaying like video game, by the makers of SANS NetWars
  • Learn more: www.kringlecon.com
  • Play previous versions from free 24/7/365: www.holidayhackchallenge.com

Player Feedback!

  • “On to level 4 of the #holidayhackchallenge. Thanks again @edskoudis / @SANSPenTest team.” – @mikehodges
  • “#SANSHolidayHack Confession – I have never used python or scapy before. I got started with both today because of this game! Yay!” – @tww2b
  • “Happiness is watching my 12 yo meet @edskoudis at the end of #SANSHolidayHack quest. Now the gnomes #ProudHackerPapa” – @dnlongen
kringle_02