The beta versions of both operating systems were also released to developers yesterday, but I haven’t seen them yet (and once I do, I’d probably be bound by NDA to not talk much about them). So before I go that route (hopefully later this week!), I thought it would be useful to quickly review some of the items I found potentially significant. I’ll briefly describe the features, then summarize some of the security questions I have at the end. Also, whenever I talk about “Early Reports,” I’m referring to information not specifically announced by Apple, but which have leaked through screenshots and other reports.

OS X “Mavericks”

Though my focus at Intrepidus has generally been on iOS, I do use OS X on a daily basis, and a few items here seemed worthy of mention (plus, they also pertain to iOS).

• Passwords in the Cloud — a secure vault, stored on iCloud, for website logins, credit card numbers, wi-fi passwords, etc. This was cited as using AES-256 encryption, pushed to trusted devices. When used within Safari, it can even auto-suggest random, secure passwords as you create web-based accounts.
• Notifications in the lock screen — when the computer is locked or asleep, notifications (including push notifications) can queue up, and will be displayed to the user the next time they wake up the computer, while the screen is still locked.
• The map application can send directions to an iPhone, but how this works wasn’t explained. My speculation is it’s an iCloud document, just like you can send Passbook passes from Safari directly to your iOS devices.

iOS 7

This was the big change. So big, they repeatedly referred to it as “the biggest change to iOS since the introduction of the iPhone.” Clearly, there have been big changes in the interface design, but also several new features were introduced as well.

• AirDrop — iOS devices can now share information directly with nearby friends over peer-to-peer Wi-Fi. This was introduced in OS X Lion, and doesn’t require actually being on the same Wi-Fi network.
• Notification center on lock screen — similar to the new feature in Mavericks
• Control Center — provides an easy way to toggle features like Wi-Fi, Airplane mode, and Do Not Disturb, by simply swiping up from the bottom of the screen. This also allows quick access to four applications: Flashlight, Timers, Calculator, and Camera.
• Better multitasking — applications may now actually remain in the background, with the operating system using some careful monitoring and management to reduce the cycles they use to the bare minimum. This also provides a facility called “push trigger,” where an application in the background can actually immediately act on data received in a push notification.
• Safari: iCloud keychain and parental controls — I don’t have any idea what the parental controls would do, but if it provides a way to blacklist and/or whitelist websites, this could be somewhat useful in corporate settings. And, of course, the iCloud keychain (described above for Mavericks) is a major new feature.
• App store automatic updates — this is a good/bad thing, in my mind. People certainly want to stop having to do big updates of many apps every week or two…but sometimes a new version of an app may be buggy, and users might not want to upgrade immediately. Also, corporations may want to review apps before they’re updated, to ensure that new features don’t change the risk profile the app poses to their enterprise.
• Activation Lock — this new feature allows a user to configure an iOS device such that if it’s been remotely wiped (because it was lost or stolen), then the device cannot be re-activated until the original iCloud credentials are entered. This should provide some additional deterrence against theft, at least, once the feature becomes widespread and well understood.

These keynotes always focus on only a few features, and there are always several dozen other features that don’t get described in detail. In this case, two screens full of features were shown during the keynote, including several that appear to have relevance to security or corporate users:

• Enterprise single sign on — definitely interesting
• Per-app VPNs — would be very interesting if each app could be assigned to an arbitrary VPN
• Streamline MDM enrollment — no idea what this could mean, since (for the end user) it’s already pretty simple
• App store volume purchase — this has been a complicated endeavor since it was first introduced, so changes here could be significant
• Managed app configuration — this might be similar to application profiles in the OS X profile manager (which are an outgrowth of the old MCX system in pre-Lion OS X)
• Scan to acquire passbook passes — probably built-in QR scanner
• iBeacons — Low Energy Bluetooth location
• Automatic configuration — possibly the aforementioned app configuration
• Barcode scanning — may confirm the passbook assumption
• Data protection by default — finally, all apps may have the additional “encrypted when device is locked” protection

Finally, some interesting bits have already been seen in screenshots on the web:

• Integration of Vimeo and Flickr accounts for share sheets (similar to existing Twitter and Facebook integration)
• Separate iCloud security panel, including integrated two-factor authentication, a separate passcode for the iCloud keychain, and a toggle for “Keychain Recovery” subtitled “Restore passwords if you lose all your devices.”

Outstanding Questions

• How are passwords in the cloud stored, and does anyone else have access to the data (for example, if you forget your key)?
• Can we control what notifications appear on the lock screen? For example, allow Twitter, but disallow mail, while allowing both Twitter and email when the device is unlocked?
• Does AirDrop on iOS introduce any new problems? Can strangers try to push data to you while in public, even if you’re not logged into a public Wi-Fi? Could that lead to a phishing vector (for example, sharing a malicious configuration profile over AirDrop)?
• Can you change the applications available for quick-launch in the Control Center? Early reports indicate that the Control Center may be enabled for use in the lock screen, and if so, how does that affect apps which encrypt their data?
• How much can an application do when woken up by a push trigger? Could an attacker in control of a malicious app and its push server remotely enable the device microphone, for example? Can this be done while the device is locked?
• Can automatic app updates be configured, for example, to wait a week after release prior to being applied? Can the feature be disabled altogether? Or better yet, can certain apps be flagged for manual updating only?
• For activation lock, can the remote geolocation and messaging features of Find My iPhone remain intact even after the device was wiped? Currently, users are faced with a tough choice, whether to wipe the device and give up any chance of locating it again, or leave it trackable, and able to receive messages, but at risk of someone extracting sensitive information from it. It’d be nice if one could wipe the device, but still be able to try to track it down and send “If found, please call me for a reward” messages to the finder.

All in all, there appears to be a great deal of change coming in both OS X, and especially, iOS. This summer will keep us busy exploring all the new features and their security implications, and hopefully the final release will prove to be an improvement in many areas.

Firefox OS has the backing of the Mozilla Foundation and big players like Facebook, Ubuntu Touch has Canonical, Sailfish OS has…the Sailfish Alliance? But if we’re betting on which of these will most likely take off, Tizen has the support of Intel (with McAfee), Samsung, SK Telecom, Vodafone, Huawei, and many others. There are even promises that Samsung will release a high-end Tizen based device in August of this year. So the question is, what’s a “tizen,” and why should I care?

Tizen TL;DR

Environmentally, Tizen is a W3C standards compliant HTML5 based platform run on-top of Linux where their applications (called “widgets” and “web apps”) are developed in HTML5 and JavaScript. (Native applications are also supported, developed in C, and mostly aimed at game developers.) Applications make feature requests to privileged APIs using JavaScript, that maintain your controls over features like contacts, NFC, or the camera.

History

Before I go into security, I just want to point out where Tizen has come from, in case you’ve worked on one of its predecessors before. In 2010, Nokia and Intel announce MeeGo, a Linux, web-based mobile platform. Nokia eventually dropped out of this project and decided to focus on Windows Phone. In 2011, Intel decided to kill MeeGo and make its own platform with the support of the Linux Foundation, called “Tizen”. The Tizen 1.0 SDK was released in 2012 along with a specific flavor designed to be a vehicle dashboard called Tizen IVI. Last month, Tizen released version 2.1 of its platform at its conference in San Francisco along with the announcement of a lot of new supporters that it has snowballed along the way.

Security Model

Tizen has a similar sandbox model to its competitors wherein each application runs segregated from other applications. What’s different in Tizen is how those apps are segregated, and which device component is responsible for enforcement of this sandbox. Each application runs as an instance of the Tizen Web Runtime (WRT) and a Linux Kernel Security Module (“Smack”), controls processes and their interactions with the rest of the operating system based on a set of rules. WRT will be covered in more detail a later post; for the sake of this post, the WRT functions similarly to Dalvik VM instances in Android.

Smack

Smack is where Tizen can potentially make its mark as an innovative, modern, mobile OS, and this feature sets apart this platform from other mobile OS’s right now. If you had never heard of Smack before (like me), you can think of it as a simplified competitor to SELinux which I expect you actually have heard of (hint: it’s enabled but not enforced on the Samsung Galaxy S4). Unlike SELinux, which can have insanely long rule-sets that control how a process interacts with the system, Smack is designed for simplicity.

One of its design metaphors is “Smack Labels,” which take an object like a process or file system location, and designate it with an identifier. During runtime, when an application needs to interact with other objects in the system, those labels are reviewed and checked to see if Label A is allowed to interact with Label B. Every app is given its own Smack Label (similar to an Android UID and GID) and Tizen uses these Smack Labels to control how apps, APIs, device functions, and just about everything sandboxed application on the device interacts with another sandboxed application.

Content Security Framework

There’s a lot of stuff to dive into in the Tizen OS, but I wanted to highlight Tizen’s new Content Security Framework (CSF) introduced in 2.1. If you’ve worked with Android and understand why malware continues to be a threat, you’ll soon notice that one of the problems with anti-malware solutions for the platform is that it’s not possible for them to gain the privileges necessary to properly protect a device. On Tizen, Intel and McAfee have provided a solution to this type of problem, namely this Content Security Framework, which is a security engine that actively looks for malicious activity and is built into the Tizen environment. This engine gives developers the ability to hook into the CSF API and scan applications, device content, and presumably even lower level device functions to let them develop a more empowered malware protection application.

Besides scanning for malware or malicious content, applications which make use of the CSF can also scan URLs used by an application, categorize them, or report back on a domain’s reputation. You might see where this is going — all of this has the aim of letting device administrators set policies of what a device is or isn’t allowed to see, and enforce those policies at a low level.

Had Enough?

There’s too much information to really go through in depth, so I’m just going to cheat and give you some hints for further reading (and an outline for future blog posts). Most of the research right now is based on theories of how an actual Tizen device will be launched and how secure will it be. Hope to talk more about this soon.

• Tizen applications must be signed by 2 signatures – the author and the distributer. The distributer is the marketplace in which the developer is publishing their application.
• Apps can be encrypted and are dynamically decrypted by the WRT instance of that application (as opposed to on boot).
• The Tizen SDK is similar to Android where device access uses something called “SDB” (equivalent to ADB) to access the device filesystem and provide debugging functionality.
• ASLR is fully implemented (at least in the emulator).
• A widget has the ability to set which domains an application is allowed to access (in the form of a whitelist). Developers can even get as specific as setting sub-domains and what types of calls are allowed to be sent to each subdomain.
• The Secure Logging function offers the same control as Android’s BuildConfig.DEBUG value. When an app is packaged for production, logging is automatically removed.
• JavaScript renders inside of widgets and web-apps making XSS vectors very juicy.
• Zypper is used as a built in package management system letting users install apps like SSH, telnet, apache.

1. Grab the APK
2. Run it through apktool/dex2jar/apkanalyser/apkREthingDuJour
3. Look at the files/smali/classes
4. ???
5. Profit!

It’s rare that we find something that breaks that process (I left out the MiTM of traffic, because I’m focusing strictly on the APK analysis for this post).

A recent engagement we did for a customer turned out to be one of those rare finds: an APK that was “weird”. While ethics preclude our talking about a customer’s application specifically, we were able to find other applications in the Google Play store that have the same behavior, and we can use them =)

For this post, we’re going to be looking at the Scottrade Mobile application (you can get the specific APK we used here). To begin with, we fire up the application on the device. A picture of the main activity is shown below:

Nothing unusual so far. We click on the Account icon at the top of the screen, and as expected a login activity is presented:

Fair enough. We click around a bit. Type some random strings into the account number, check the Remember Account No. checkbox, etc. All we’re looking to do right now is make sure that any client side storage options are being exercised – so that when we take a look at what data is persisted by the application, there will be something there.

Having walked through the app a bit, it’s time to check the file  system on the device. In this case, the application data is stored in /data/data/com.konylabs.Scottrade. We grab them using adb pull. Once we have the APK unpacked back into smali and java classes, and the local files on the device have been pulled out for examination, it’s time to move on to seeing how the application works.

The first stop we make is the AndroidManifest.xml file. This file is used by the APK to define the package characteristics – including all permissions used by the app, all the activities and service providers the application creates, etc. Basically this file contains a giant roadmap of the application. Here’s what the manifest for this application looks like:

Hrmm.. our first hint at oddness. There’s not much in this manifest – especially for an application that has as many components as this one does. We already know from walking through the application in run-time that there are many activities present, so how can there only be two defined in the manifest? Looking at the main activity (identified by the <action android:name=”android.intent.action.MAIN” /> intent-filter), we see that it maps back to the .Scottrade class. Since the package name is com.konylabs.Scottrade that means we need to look at the com.konylabs.Scottrade.Scottrade.smali file to examine what’s going on. Here’s what that file contains:

Again, more oddness. We’ve seen the main activity. We know it’s got a lot of stuff going on – stock trade graphs with information presumably obtained from the Internet, various images loaded, etc. In fact, the app looked a whole lot like the usual bunch of webviews strung together. So why aren’t we seeing any of that here?

The answer is in line 2:

.super Lcom/konylabs/android/KonyMain;

public class Scottrade extends KonyMain {
    // code goes here

And if we look at the Scottrade.class file in JD-GUI, we see that’s exactly what happens (and in fact, not much else at all):

So, where does KonyMain live? It’s at com.konylabs.android.KonyMain.smali. That file is a whopping 5166 lines long! Using dex2jar on Windows 7, and JDK version 7, the KonyMain class file only has a single line of: // INTERNAL ERROR //

However, using dex2jar on Linux, with JDK version 6, we get a successful decompilation:

Again, this file is pretty huge, and not terribly helpful. At this point, it seems like we should look at what Kony Labs is. Turning to Google, we see that they are a mobile application company, and offer products that provide a framework for developers such that they can take code they write, and deploy it across multiple mobile platforms. So, what that means for us as reverse engineers is: we need to figure out how the Kony Labs framework is designed. Unfortunately, their application is not open source, nor is a  trial available. While looking for further information we ran across this site, explaining a bit about the Kony architecture. Specifically:

KonyOne, claims it does everything. Their Eclipse-based cross-platform IDE studio helps the creation of a single code base programmed in the Lua programming language (like JavaScript) from which Kony generates native code in 7 OSs OR HTML5 OR WAP/WML browser apps.

Hmm. That’s interesting. So, it would seem that Kony takes application code written by mobile developers, and throws it all into a Lua wrapper of some kind. Armed with that information, we started looking harder at the structure of the APK, and the files stored in the device file system.

First off, we looked at the device file system structure:

We see the usual things: cache for webviews, shared_prefs, databases. But files is odd. Looking in there, we see 3 files:

dsAcceptDecline.kds
dsAppVersion.kds
dsShowStreaming.kds

$ file *
dsAcceptDecline.kds: Java serialization data, version 5
dsAppVersion.kds: Java serialization data, version 5
dsShowStreaming.kds: Java serialization data, version 5

Hrmm… OK. Ignore that for the moment, let’s see what else there is to find. Going back to the unpacked APK directory we obtained using APKTool, let’s check out the usual spots:

• Anything good in /res/values/strings.xml?
  Nope: 
• How about /assets?
  Aha! Something interesting here:

Knowing that Kony wraps everything up in a Lua wrapper, that konyappluabytecode.o.mp3 file looks somewhat suspect. Let’s take a look at the file header and see what it has to say:

As guessed: this is not your usual MP3 file at all! It’s a LUA bytecode dump! Here’s where things start getting really interesting.

It turns out, that the entire Android “application” is actually stored inside the konyappluabytecode.o.mp3 file. Running strings on that file shows evidence of this:

Unfortunately, the Lua bytecode isn’t readable natively, because it’s bytecode. Some  looking around revealed a few tools that can be used to disassemble Lua code, but the one that worked best for us was ChunkSpy. This handy tool is actually a Lua script, that can be used to convert binary Lua bytecode back into a verbose listing, similar to what you would expect to see in a standard binary debugger. Running the konyappluabytecode.o.mp3 file through ChunkSpy was simple enough, once we installed lua 5.1 onto a Linux system. The usage is shown below:

For our bytecode, all we had to do was run the following command:

ChunkSpy.lua -o out.txt konyappluabytecode.o.mp3

Where things went from there is the subject of another post, coming soon…

These two issues were brought together last summer, at the Black Hat Arsenal, when Hubert Seiwert (@hubert3) presented a tool called iSniff GPS. The tool was described in more detail at Syscan in Singapore just a couple of weeks ago, but finally came to my attention in a tweet Wednesday night pointing me to SC Magazine (Australia).

Intrigued, I spent some time yesterday installing the iSniff tool and putting it through its paces, and have a few thoughts I’d like to share.

You can easily map access points by name using queries to the WiGLE database.

The iSniff GPS tool contains two main components: A sniffer, and a GUI. The sniffer watches for leaked ARP packets, identifies the BSSIDs they’re probing for, and fetches information about them from Apple. The web-based GUI (built on Django) shows you the devices that have been “noticed” on the local network, and lists networks those devices have visited. When a probed network was matched in Apple’s database, a link will also take you to a visualization of all the data Apple has on file regarding that access point’s location.

After installing the tool, I took an old access point, connected my laptop directly to it, and joined a few iOS devices to see what happened. The tool was definitely working as designed — devices immediately appeared in the list, along with a list of BSSIDs each client probed for. Clicking on each client in the list displays a detail screen with latitude and longitude for each network BSSID found in the Apple DB, and a link to display the information on a map. Another tab pivots the data, listing it by network (with the relevant clients next to each), while other tabs offer direct mapping of selected BSSIDs and even searching and mapping of the wigle.net SSID database.

Clients detected, and the APs they queried for (anonymized, obviously).

Interestingly enough, none of the access points the devices queried were in Apple’s database. The access point at work was found in the WiGLE DB (listed both by name and BSSID), but not in the Apple DB. My home access point didn’t show up in either database, despite having several iOS devices connecting on a daily basis, not to mention multiple visiting family members most of whom have iOS devices as well. [Note: Not entirely correct, see update below.]

However, another network in the building did show up in Apple’s DB, and I was also able to accurately geolocate several access points near our sister company (iSEC Partners) in Manhattan. Perhaps there hasn’t been enough traffic by our building in the year since we moved in? We just haven’t been reported frequently enough to be included in the database?

The red dot is where Apple thinks the AP is (it’s actually just inside the adjacent building)

That’d be a great theory, except that the BSSID for the access point I was testing with also appeared in the Apple DB. That seemed really odd, since this AP is almost never on, and when it is, it’s rarely for more than a few days at a stretch, and almost never accessed by anything other than my own devices. Occasionally it’ll be set up as “attwifi” for testing, and I’ll get a few people in doctors’ offices connecting (and enjoying free internet access), but that’s probably no more than a dozen devices, all told, ever. Finally, the AP gets brought to the beach every year (and lots of people use it there) but that’s obviously a totally different location, and even then, not more than a couple dozen additional devices. And again, only for a week.

So why is an access point, active 24×7 for over a year, not in the database, and another one, in use for maybe 3 or 4 weeks total time over the same year (and one of those weeks in a different state), not in the database? There’s definitely some odd criteria in play here that I haven’t yet been able to guess at.

What does all this mean? It’s clear that the Apple BSSID database has real utility: It helps devices quickly, and more accurately, determine exactly where they are. There might be a way that Apple could restrict how queries are performed on the database, but it’s possible that would be difficult to do effectively. And of course, Apple isn’t the only entity maintaining such a database. Trying to keep your AP information out of a publicly-accessible database just isn’t going to happen.

On the other hand, the leakage of the BSSID data when a device joins another network is a little harder to justify. What exactly is the utility the user gets from this? A faster recognition by the device that it’s on a network it knows? What services benefit from this, and to what degree? It may well be acting in accordance with RFC 4436, but that doesn’t necessarily make it right (and very few, if any, Android devices exhibit the same behavior).

Ultimately, the real question is whether the daily benefit to the end user outweighs the risk that the location of their home, or school, or workplace, might be disclosed to an eavesdropper at a coffee shop. Which, in a strict risk analysis, probably falls far short of requiring elimination of the leakage. Perhaps it could be mitigated with a user preference setting, but this problem is pretty esoteric even for information security researchers, and I suspect clearly describing the problem (and its implications) to the average user in the space of a few lines on a preference pane would be flat-out impossible.

At any rate, this is a very interesting demonstration of fusing publicly-accessible data from multiple sources to gain information not otherwise explicitly revealed. And that in itself definitely makes the iSniff GPS tool worth checking out.

Quick Update, 5/13/2013: I was out of town over the weekend, but now have done a little more checking, based on Hubert’s comments below and on Twitter.

Turns out, of the two networks at work (open/guest and closed/employees), one of the guest BSSIDs is in Apple’s DB, but none of the closed BSSIDs are, which still seems odd to me. Of four neighboring business’ BSSIDs checked, all four are in Apple’s DB. And I looked again for my home AP, and it was in there — I’d been querying the wrong MAC address.

So the AppleDB is a little more complete than I’d thought, though there’s still something keeping our main work net from showing up.

And I also verified that the ARP queries being sent out by iOS devices upon joining the network are not for our local APs, but for the router / DNS server (which are both the same here). So for places where the router / DNS is also the Wi-Fi access point (many, many places), the ARP disclosure can lead to geolocation via Apple’s DB. But where the Wi-Fi and router / DNS are split to multiple devices, it’s a bit harder to find.

Weak admin controls
While a router’s webapp isn’t a fully internet-exposed attack surface, it isn’t ideal if sharing your hotspot with someone you think you can trust leads to a total compromise of your data. Most hotspots have an admin password — we like to see a different password for the admin interface and for WPA. Otherwise, what’s the point of an admin interface? <oprah>You get admin, and you get admin, and….</oprah> Once the passwords are different, it shouldn’t be easy to bypass the password prompt altogether. Here is a great example. Researcher Dustin Schultz found that an unprivileged user can access the WiFi password and administrative settings by adding a ‘/’ to the end of any URL. We’ve seen this take many forms, and allow anything from faking the admin cookie to disclosure of the actual admin password.

Common web-app vulns
The router’s web interface is private, right? Right? Unfortunately, Cross-Site Request Forgery (CSRF) attacks can originate from outside the network, and ultimately send data on your behalf. If you are logged in as the administrative user, CSRF can be used to change access point security, administrative passwords, or execute denial-of-service (DoS) attacks. CSRF attacks have been well-documented, and the OWASP site has plenty of examples and remediations, the most basic of which is to include anti-CSRF tokens with every request. This allows the webserver to verify that the request is coming from the actual page, not from a pre-crafted static request which is embedded in a website.

WiFi Protected Setup
Many modern routers STILL have Wifi-Protected Setup (WPS) enabled by default. The purpose of WPS is to allow users to connect to the Access Point using an 8-digit WPS PIN instead of a WPA(2) network key. Unfortunately, a very public design flaw in the protocol allows the PIN to be brute forced because it is sent and verified 4 digits at a time. This results in the router giving out the WPA key for the network. Lucky for us, some routers do have an option to disable WPS. Unlucky for us, some of those routers respond to WPS protocol requests even after WPS has been disabled. To mitigate the problem, OEMs should make sure that users have an option to disable WPS and that the device does not respond to requests after it’s disabled.

We’ll be publishing some more issues next week, including command injection, UPnP, and DNS rebinding!

Cheers,
Max and Rohan

Tools

To get started we need something that can read and write NFC tags. Sorry, iPhone users, but the easiest way to do this as I see it is to use an Android device and a few choice apps:

NXP NFC TagInfo

Does exactly what its name implies. It gives you info on an NFC tag. This includes any kind of ASCII characters inside of the NDEF storage container or a hex representation of the values if that’s your thing. This is step 1 when it comes to learning about the content that’s on an NFC tag. Play store link.

NXP NFC Tag Writer

NXP’s tag writer will read, write, and copy tags. When I say copy, I mean it will copy the NDEF format. That’s the content that’s normally on an NFC tag. Hard coded values like the UID can’t be changed (unless you know where to get sketchy NFC tags and even then you need a libNFC-based tool to interface with it). Play store link.

NFC Developer

This is where the fun happens. This app allows you to design just about any NDEF formatted NFC tag you want. The nice part of this is if there is an application implementing a weird custom format, you can create it. It’s made by Thomas Skjolberg who apparently has a whole workshop on the subject that gets you started with NFC on Android.

Used in partnership with the ndefeditor.com site, the app lets you generate just about any NFC tag you can think of and then record it to a tag. Or you can use the Eclipse Plugin  that does the same thing inside of Eclipse. Very useful.

Create a new tag in Eclipse by going to New>Other>NDEF File

Fill the file with whatever contents you want or whatever the application can handle. This may be a specific MIME type like below or a Android Application Resource (AAR)… or many other things for that matter.

Once you’re done, it’ll create a QR code for you that you can scan with the NFC Developer application installed on your device.

You’ll now be able to load your custom NDEF message onto an NFC tag of your choice.

Link

Tags

If you’re using Android, you don’t necessarily need to write your content to physical tags. It’s possible to manually create intents that look like the device is receiving an NFC tag. But since we’re talking about testing any NFC function on *any* platform, you’ll need to pick up some NFC tags. The NFC protocol itself supports a “card emulation” mode where you could theoretically turn your Android phone into a simple NFC tag, but from what I understand, it’s either extremely hard to do or impossible right now because it’s based on the NFC secure element that is manufacturer specific. If someone wants to enlighten me on that, please feel free.

You’ll want a variety of tag types. The main difference you’ll be concerned about here is just the amount of storage. The Mifare 4K have a reasonably large storage capacity and can still deliver the data in the same way that a Mifare Classic (1K). Maybe there’s a situation where you’ll need a special tag type but I haven’t run into that yet. Either way, here’s a random link to some tags. 

Bad Code:

Lets take a look at some example code for Android that we’re trying to exploit. This is a portion of code that is reading an NFC tag, and saving to a file name based on that input. You can see that the value of “strfile1″ is whatever the first NDEF record is. What happens if that payload was something like “../databases/superimportantcontent.db”.  Even worse, the app looks at the second value of the NDEF record for the content to write to.

Parcelable[] rawMsgs = intent.getParcelableArrayExtra(
        NfcAdapter.EXTRA_NDEF_MESSAGES);
NdefMessage msg = (NdefMessage) rawMsgs[0];
String payload = new String(msg.getRecords()[0].getPayload());

String strfile1 = getApplicationContext().getFilesDir().getAbsolutePath() + payload ; //is this bad? :)
File f1 = new File(strfile1);
FileWriter filewriter = new FileWriter(f1);
BufferedWriter out = new BufferedWriter(filewriter);
out.write(msg.getRecords()[1].getPayload());
out.close();

Happy hacking.

This is the tricky bit: Create a configuration profile that disables Safari, disables installation of applications, even disables iCloud backups, and adds a “READ ME” web page to the user’s home screen. Put a password on the profile, so the user has to enter the password in order to remove it. Now, you just need to convince the user to install the profile, and you can do that simply through email or SMS phishing. Once they install it, half their expected functionality suddenly goes away, and if they tap on the “READ ME” page, they’ll see the instructions as to how to pay ransom to receive the password to remove the profile. Win! (well, not for the user).

Now, fortunately, there are a couple of flags that (might) alert the user that something odd is happening. First, in the initial profile installation screen, is the list of contents, which includes “Profile Removal Password.” Similarly, tapping on “More Details” clarifies that this is a locked profile. Of course, if the email introducing the profile was written well enough, then the user might already expect and accept this. Hopefully we can train them not to. Also, if the user has a passcode on their device, then they have to enter their passcode as well, so it won’t simply install without the user noticing.

But what if they ignore all the warnings, and install the profile anyway? Well, all might not yet be lost. Turns out, the removal password is included in the profile, in plaintext. The attacker could choose to encrypt the profile, but to do that they need a public key from the target device, which might not be so easily acquired. So, assuming the profile is not encrypted, just pull down the .mobileconfig file from the original phishing email, open it up, and find the password.

Of course, the attacker could get really tricky, and serve up a file with a different password each time, placing some kind of key into the ransom notice (“Pay me $35 to remove this profile. Use the word ‘ostrich’ when you send me your bitcoins”) and then that key would be used to derive the actual removal password. If this is the case, then each time you hit the page you’d get something different, and so you wouldn’t be able to recover the correct password. In that case, the only real way to remove it is either to pay the ransom, or, if the device is jailbroken, get in and remove the profile directly from the filesystem.

In iOS 6.x, a new feature was introduced that can prevent the user from installing profiles. This feature is only available in Supervised Mode (via the Configurator application), however, and so isn’t of much use to the general population.

Want to hear more about configuration profiles and keeping your iOS devices secure? Come to my talk at SOURCE Boston next Thursday!

Thus I created this simple class file I can drop into the root of any application (yes, this is not as good as a real debugger using JDWP, but sometimes doing things quick and dirty gets the job done quicker for me). I wanted to stay with Android log utility syntax, but simplified a few things. I overloaded the logging object’s “d” method so that it could take just about any variable type I was dealing with. One handy example of this is a byte arrays (which is often what we find decryption keys stored in). The wrapper in IGLogger will convert the byte array into a hex string and dump that to the logs. All you need to add is one statement to the code. If “v0″ contained a byte array we wanted printed out, just drop this line of code.
invoke-static {v0}, Liglogger;->d([B)I
Since “iglogger.smali” is in the root of the recompiled APK, we can statically invoke it from any other class in the project. In this case, we need to tell the “d” method v0 is a byte array “[B" and sticking with the standard Android logging utility class, we're returning an Integer (although I've thought about just making that a Void... I never check it). You may notice we're not passing a log Tag variable with this statement. IGLogger supports that if you want, but we've added a trick to IGLogger that I find works pretty well. In IGLogger, we'll create a new Throwable object, get the getStackTrace method to find out the last class and method we were in, and put that in our log Tag. If the APK is not obfuscated, this will even include a line number. This same trick allows for a very simple "hey, I got here and this is how" stack trace method to be dumped by placing this one line of code anywhere.
invoke-static {}, Liglogger;->d()I
You might have heard a lot of us here are fans of Virtuous Ten Studio for working with smali. I have a bunch of these IGLogger print statements in  Extras->Smali->CodeSnippets. Makes it really simple to just click and drop in a log statement.

But that wasn’t good enough for Niko here when we had a massively huge app that was obfuscated. He talked me into automating the process of logging out each class and method that was entered so we could watch the logs and know what code paths were being taken. I ended up rolling this into a Python script I had written to “fix strings” in decompiled Android apps. You are probably aware that proper Android apps will have their strings placed into XML files so that it’s easier to internationalize the application. While this might be nice for developers, it means when we’re reversing an application, we may end up with some strange hex value instead of a readable string. “FixStrings.py” would loop through the decompiled code and add these strings back in as a comment tag when ever they showed up in the smali code. Your mileage may vary with how well this works, but in some apps, it helped us find things easier.

Adding on to that code base, I started to include some code to automatically add IGLogger statements around things I thought could be interesting. This includes a log statement after the “prologue” of any method. Also, any time we see two strings being compared, we’ll log both strings (this is always fun for watching a password being checked or when the app pulls up device info to see if it’s running on the right hardware). We plan to add a few more things for dumping Intent messages and URLs, but this is a start for now.

This of course will make the app run hella slow, fill up logcat, and in some cases break the application. I’ve tried to avoid that last one as best I can for now, but it is possible this script will massacre an APK so badly it will be unrunnable. If you run into that issue, you can turn off the lines that will add these automatic logging statements to the code (ie, JonestownThisAPK = False).

The last thing we added to the Python script was some searches to pull out info we may find interesting when assessing an APK file. We dump this into a file called “apk-ig-info.txt” and review it after decompiling the APK. Again, this is something we’re continuing to refine. You can find the code on the Intrepidus Group github repo:

https://github.com/intrepidusgroup/IGLogger

https://github.com/intrepidusgroup/APKSmash

https://play.google.com/store/apps/details?id=com.intrepidusgroup.learner

So, you’ve got everything installed and running. At this point you have two options – take the easiest way and hit the walkthrough or try to dig through the lessons yourself. I intended for the walkthrough to serve as a helper thing, but if you’d like to just use it to run through the whole thing, sure, that’s an option, too. The link to the walkthrough is provided at the end of this post.

In if you want to do it yourself but are not sure where to start, here’s a few general tips:

1. You will end up using Android SDK / Android monitor (monitor.bat) very heavily. I am guessing that by now you have that installed on your system anyway.

2. Use dex2jar (http://code.google.com/p/dex2jar/) to convert APK’s Dalvik executables (*.dex) into their Java representation – since the code is not obfuscated, this will really help you understand the logic of the lessons.

3. Apktool (http://code.google.com/p/dex2jar/) – this command-line utility lets you decompile APKs and recompile them back. You’ll definitely need this on a few occasions.

4. Jarsigner – comes with Java SDK, is necessary to install an app on an Android device. Read here about signing of APKs: http://developer.android.com/tools/publishing/app-signing.html

5. Virtuous Ten Studio (http://www.virtuous-ten-studio.com/) – Smali IDE, complete with syntax highlighting / automatic signing / APK upload. Awesomeness redefined. If you want to bypass 3) and 4) and not have to deal with it, go the VTS way. That said, I’d still recommend familiarizing yourself with the command line versions of the tools – just so that you understand better what’s happening behing the scenes.

6. Some knowledge of Java is definitely helpful for quick completion of challenges.

7. “adb shell pm list packages” gets you the list of packages installed on the phone. IG Learner is one of them.

Now, let’s go to some specific tips per lesson:

1. Lesson 1. This one is pretty self-explanatory. If you start the Android monitor and look at the log output,  you’ll see the answer to the challenge. Easy as that.

2. Lesson 2. Convert the APK into Java and try to figure out the filename that’s being created. Another hint: default directory for Android app file storage is /data/data/<packagename>/files.

3. You can figure out what the URI scheme is just by looking at the lesson screen and requesting a URI. Now try to look through decompiled code (Either Smali or the Java representation) to figure out what the lesson is expecting. Also, pay attention to extra activities in the app.

4. You should use a local proxy to intercept application traffic (Burp Suite maybe?) Keep in mind that you can’t man in the middle SSL traffic unless the SSL certificate presented by the remote server is verified. And for that (at least, for Lesson 4) you need to update your trusted CA store with the signing certificate of your local proxy. Once you export that certificate (there are multiple ways to do it, using Internet Exporer’s certificate export wizard is one of them), you should be able to import into into the trusted CA store by placing it in the root of /sdcard and importing it through the Android’s Trusted Credentials menu.

5. This lesson is a bit trickier. For one of the ways to solve this, I suggest looking through the Smali code and finding the pin for https://www.intrepidusgroup.com SSL certificate that you can get by running Moxie Marlinspike’s pin.py script on our certificate. Then you can replace this with your own intercepting proxy certificate’s pin, recompile the app, and push it back to the phone. You’re good to go.

6. Hard-coded keys are awful. Seriously. When you’re playing around with symmetric encryption as you’re trying to find the correct value of the encrypted string, make sure that you convert that to Base64 for readable output. The logging facilities are there to help you.
The encryption can be done in less than 10 lines of Java code. If you’re struggling with that, check out our GitHub repository for a helper Java class.

7. Content providers are advertised in the Manifest. Mercury (http://labs.mwrinfosecurity.com/tools/2012/03/16/mercury/) is a great framework that lets you easily query those providers. This should be enough to successfully complete the challenge.

8. I’d recommend starting with decompilation of the app and looking at the Lesson8Activity. This may give you an idea of what the Intent handler is expecting. From there you can either download the Lesson8Aux app from the Play Store (https://play.google.com/store/apps/details?id=com.intrepidusgroup.lesson8auxapp), decompile it, modify it to throw the correct Intent to the application, or just use the “am” command to do just the same. Whichever is easier for you is fine, but I recommend going the auxiliary app way just to gain some more practice exercises decompiling and recompiling Smali code.

Oh, and yeah, the walkthrough (Huge thanks to our intern Nitin for putting it together!). Here it is:

walkthrough

Be sure to check out our talks, too. Roman Faynberg will be presenting Armor For Your Android Apps, Saturday at 3:00, a discussion of Android vulnerabilities, with plenty of real-life examples and hair-raising war stories, as well as tips and best practices to avoid such problems in development. There’s even a HackMe-type app to help demonstrate some of the problems.

At exactly the same time (sorry, we couldn’t control it!), David Schuetz will be presenting on Protecting Sensitive Data on iOS Devices. His talk will try to cut through some of the technical mumbo-jumbo and present best practices for configuration, management, and application develoment on iPads and iPhones, with a goal to making it easy to explain to management-types.

We’re also hiring! Current openings for [testers | consultants | ninjas | pirates] (sorry, no open positions for samurai or lumberjacks). If you’re interested, chat with one of us at the con, or send us an email at careers@intrepidusgroup.com.

So if you’re going to be at ShmooCon, stop us in the halls and have a chat. We can’t wait to see you!