AthleTechz- Getting the Industry Back In Shape

First blog post in a while. It's been an insanely busy year, which is a GOOD thing. Business is good, the OWASP Mobile Security Project is finally progressing at a healthy pace, and the world didn't end as predicted.

The majority of us that work in the IT field sit at a desk for extended periods of time every day. Whether it's security, development, or network administration, we generally spend a lot of time at a desk or sitting during meetings. As a result of being so sedentary and combined with the long stressful hours many of us work, there's a higher likelihood that we will pack on the pounds as the years progress.

As for myself, I left the military in the earlier part of the previous decade at a lean 6', 190 pounds. When I got married in 2007. I climbed to about 220 pounds. By 2010, I hit 245. Like many other guys that get married and add a few pounds, I started to make excuses. "I work a lot"...."It's because I eat at night"...."I can't eat healthy on the road"....and the list goes on. Since we moved to the DC area not too long before getting married, I didn't know many people outside of the IT industry. Most of the people I met through work were also techies, and also spent lots of time doing more of the same. While I once had people to play a pickup basketball game with, or head out for a run with, I no longer had the same network of active friends.

Anyone in the security consulting industry knows that work can be brutal. Long hours, tight deadlines for deliverables, crazy swing shift hours (can't test in production during working hours!), and "get it done now" requests by customers can make it challenging to live a normal and predictable lifestyle. As a result, we are sometimes forced to take shortcuts. On the road and juggling multiple tasks? Grab something quick to eat and head back to the hotel to do MORE work. Have to squeeze out an unexpected incident response task because a client was breached? You have to skip that Saturday morning hike you were looking forward to.

I lived this lifestyle for a few years. However, a few things changed in 2011. First, I made friends with some locals in the techie community that are into fitness and healthy living, just like I once was. My best friend from the military days moved to the area, giving me even more of a kick in the ass. It awoke "the old me" and got me back into working out consistently. By working out consistently, other things fell into place. I started eating better. I started sleeping more. And oddly enough, my time management skills improved. Not only do I think clearly these days, I feel better than I have in years and get more done every day. I'm still about 30 pounds from where I once was, but this is certainly a step in the right direction. Before the Spring of 2012, I should be back to where I was while in the military, in the best shape of my life.

The latest numbers suggest that nearly half of America will be obese by 2030. http://www.huffingtonpost.com/2011/08/28/half-america-obese-2030_n_937906.html . If this study was only targeted towards the IT field, my instincts tell me that this number would be much higher. Visit a security conference or look around your own office, and I guarantee you that we are probably already there in terms of 50% obesity. Combined with the long hours we work, this is shaving years off of our lives.

After considering my own personal situation and the factors that contributed to me getting out of shape, I thought it would be a great idea to create a group for techies to motivate each other to stay fit. You don't have to be a world-class athlete, just a techie that understands the pains of our field and wants to exercise more.

http://www.meetup.com/AthleTechz/

The long-term vision is for this group to spawn off leagues for playing sports like softball, football, or even volleyball. Maybe even some running groups that meet 2-3 times a week. I want people to be selfish and suggest the things THEY enjoy, with the goal of finding someone else that also shares that same desire to partake in the same activity. Post a meetup for bowling, golfing, ultimate frisbee, skiing, or whatever YOU enjoy. If you find a few others that also enjoy it and it encourages you to get away from the keyboard for a few hours to burn some calories, then this group has fulfilled its purpose.

Our first meetup is a hike on September 17. I chose a trail that isn't extremely brutal, but scenic and long enough to be both enjoyable and mildly challenging. I'm also trying to organize a flag football game at the beginning of October.

A few other friends have suggested ideas that they'll post as meetups in October and beyond. Hopefully people use this as not only a chance to get fit, but for a great way to do professional networking across niches and outside of our comfort zones. Network administrators and Java developers don't always get together, but within this group they would have an opportunity to co-exist in harmony!

I really hope this group gets some momentum behind it. This is something the industry needs...much more than new certifications and acronyms next to our names =)

-Jack

OWASP Summit Mobile Security Working Session

While I unfortunately won't be in attendance next week in Portugal, I highly encourage anyone with an interest in mobile application security (or application security in general) to participate in the Summit remotely. More information on registering to participate is available on the OWASP wiki here. Believe me, I'd LOVE to be in Portugal vice stuck on the east coast right now, but our current workload simply won't allow me to escape next week.

There are plenty of other tracks to check out as well. Naturally, as I'm the co-lead of the OWASP Mobile Security Project this session is of extreme interest to me. The session is being chaired by Mike Zusman (the other co-lead of the OWASP Mobile Security Project) and David Campbell.

As for me, I will definitely be participating remotely. Some of the sharpest guys (and gals) in the industry will be locked away for nearly a week to drive initiatives that will shape the future of how we approach mobile application security going forward. We threw together a VERY rough draft of what a Top 10 Mobile Risks and Top 10 Mobile Controls list might look like, but in reality we aren't there yet. This was the product of a few brainstorming sessions between a few of us.

If you are interested in contributing to the project going forward, please get in touch with either myself or Mike. Our contact information is listed on the wiki page. There is a TON of work to be done at this point, so we really need as much help as possible to tackle our initiatives. I'd also recommend joining the mailing list as well to stay current on mobile application security trends and to exchange ideas with the experts.

-Jack

Scary, Scary Mobile Banking

Short post to demonstrate really bad mobile payment sample code provided by Mastercard.

For a great tutorial on how to N-O-T develop a mobile payment application, take a look at the sample code provided by Mastercard here. For more Mastercard Open API goodness, check these examples out here and here.

In this snippet from the sample code, they are providing a placeholder for hardcoding your companyID and companyPassword in plaintext string format:

final double amount = Float.valueOf(amountInput.getText().toString());

final String currency = "USD";

final String companyId = "your-company-id-here";

final String companyPassword = "your-company-password-here";

final String messageId = "your-message-id-here";

final String settlementId = "your-settlement-id-here";

final String cardHolderName = cardHolderNameInput.getText().toString();

final String accountNumber = cardNumberInput.getText().toString();

final String expiryMonth = expirationMonthInput.getText().toString();

final String expiryYear = expirationYearInput.getText().toString();

And below, we append this to our request and send!!

request.append("<MerchantIdentity>");

request.append("<CompanyId>");

request.append(companyId);

request.append("</CompanyId>");

request.append("<CompanyPassword>");

request.append(companyPassword);

request.append("</CompanyPassword>");

request.append("</MerchantIdentity>");

Hardcoding your credentials is NEVER (I repeat, NEVER) a good idea. Please don't do this. Your companyID and companyPassword are used for both processing payments, and processing refunds. Fully decompiling an Android application is extremely trivial, as demonstrated here. There are also applications floating around that allow 1-click rooting. You don't have to be an uber elite expert to do this stuff.

What concerns me most is the de-centralization of highly sensitive information. This is a bigtime mobile trend. If you are writing code like this and giving 50 employees an Android phone or tablet, what is the likelihood that at least 1 of them will end up getting lost at some point? What is the likelihood that at least one of those devices will get owned at some point? What is the likelihood that a malicious employee would take this information and rob your company blind? Pretty high, in my opinion.

In a perfect world, this type of architecture would involve a very simple upstream web service and web server where the credentials could be stored in a secure way. The web service would ask for the credit card information, and THAT'S IT. There's less of a risk of data leakage with one target instead of 50.

There are lots of very important design aspects to consider when rolling out this type of capability. If you are in the business of losing money, then copy and paste this code and begin processing mobile payments. And don't even consider putting something like this in the Android market because I will find it ;)

-Jack

Dangers of Rooting Your Mobile Device

Many people root or 'jailbreak' their Android and iOS devices in order to gain access to features limited by the security models of each respective platform. In exchange for added capabilities, these people are essentially accepting (with or without their knowledge) the fact that they've removed pretty much all security protections from their environment. This post will provide an overview of how the Android security model works, and detail some of the dangers of using a rooted environment. We will use Android as our platform of choice.

Each application installed in Android runs as a separate user in its own process space. Every application user has its own User ID (UID), and this configuration is designed to only allow that application to access associated files and databases. While it is possible to grant external applications the ability to access some of this information through Content Providers and by signing multiple applications with the same certificate, the default configuration does not allow it. The Android security documentation on the developer website has an excellent overview of how permissions are assigned to applications: http://developer.android.com/guide/topics/security/security.html

Android permissions such as the ability to read SMS messages, install packages, access GPS coordinates, and many more must be declared at the time of installation within the Android Manifest file. When a user installs an application, the requested features in the Manifest file are displayed to the user. If they agree that they want to allow the application to do something potentially dangerous such as make phone calls on their behalf or track their location, the application is installed with those rights granted to the code. Group IDs (GIDs) are assigned to each permission, and the application's UID is then placed into the respective group required to use the feature. If an application attempts to call an API feature that they have not been granted explicit access to, a security exception is thrown. This model is in place to prevent an arbitrary application from using dangerous features without a user's explicit consent, although most users really don't care about the permissions an application requests anyway.

As anyone with even a beginner's knowledge of Linux would expect, running as root gives you complete control to do pretty much whatever you want. Assuming a phone is rooted, there is no limit the amount of evil a malicious app can perform. For many years, we've preached the virtues of"least privilege" access. An administrator should NEVER browse the web using a highly privileged account. Likewise, those of us Linux and OSX users use a regular account for daily activities, while using 'sudo' to perform something sensitive such as changing system settings or installing software.

The code below can be used by an application to test whether or not it is running on a rooted device. If it fails, you know that root access is not possible without an additional exploit. If you are developing highly sensitive mobile business applications within your organization, this type of check may be useful to track down users who are exposing your information in really dangerous ways. It can also be used by malicious applications to determine if it is running as root, which allows the application to do really bad things, or download additional code that can do really bad things. This extremely simple code can be called within the main Activity at startup. You'll need to import java.lang.Runtime to do this:

public boolean isRoot (View v) {

try

{

Runtime cmd = Runtime.getRuntime();

cmd.exec("su");

CharSequence result = "You are root";

Context context = getApplicationContext();

Toast toast = Toast.makeText(context, result, 10);

toast.show();

return true;

}

catch (Throwable t)

{

CharSequence result = "You are not root.";

Context context = getApplicationContext();

Toast toast = Toast.makeText(context, result, 10);

toast.show();

return false;

}

}

So assuming that we are playing with a rooted device, what can we REALLY do with this power? Lots of things, such as:

• Trojan other legitimate applications
• Wipe a device
• Read all files and databases
• Install other applications
• Exfiltrate data
• Install reverse shells
• Log keystrokes
• Enable a user's microphone
• Access GPS
• Read and send SMS messages
• Make phone calls
• And much, much more

You may be asking yourself,"but don't you need to be granted the explicit right to do so?" Recall that these permissions are declared within the Manifest file for each application, and are defined within the /etc/permissions/platform.xml file as well. As root, you have the ability to read and write to both of these files. You can edit platform.xml directly, and as root you'll have the ability to remove a package and re-install a trojaned version with your own permissions (and code). As a malicious application author, a rooted phone is your best friend. There is no need to compromise the device because the owner has already done this for you.

I'm working on some particularly nasty proof of concept applications that demonstrate some of the more malicious things someone can do to a rooted device, or really mobile devices in general. Debating whether to release it or save it for Shmoocon and Blackhat DC :-)

Storing Data On Mobile Devices The Wrong Way

Storing sensitive data such as credentials in plain text is a bad idea, especially for mobile applications. Mobile devices certainly have a much greater likelihood of being lost than a desktop computer or server. As a good developer, you owe it to your users to protect their information at all costs.

This tutorial will show you how to check an Android device to determine if sensitive information is being blatantly stored in the clear. If you are professionally testing an Android application, you should be closely examining what the application stores on the device in its data directory as well as in other places such as system logs and sqlite databases. We'll be using ADB to browse the file system and take a closer look at some of the files present on the device. We will also use the sqlite3 utility included with the Android SDK to examine a client-side database. Our victim application will the popular Evernote app, which has been written for pretty much every mobile platform in existence.

Assuming Evernote is installed to either a physical device or to a virtual device running in the Android Emulator, we'll use ADB to browse to the directory where the application stores its information. The application stores this information under /data/data/com.evernote.

Jack@Android_Fun =>>> ./adb shell
# cd /data/data/com.evernote
# ls
cache
databases
shared_prefs
lib

Let's examine the contents of the "shared_prefs" directory. Many applications use a similar directory structure, so you should always look for this stuff in the /data/data/com.whateverapp directory. The file "com.evernote_preferences.xml" is where application-specific information is stored for Evernote. Outputting the contents of this file gives us the following:

# cd shared_prefs
# ls
com.evernote_preferences.xml
# cat com.evernote_preferences.xml
<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
<string name="serviceHost"><string name="username">happy_gilmore</string>
<boolean name="ACCOUNT_CHECKED" value="true" />
<string name="password">MyPassword123</string>
<int name="servicePort" value="0" />
<boolean name="NotifyUploadStatus" value="true" />
</map>
#

Whoa!! That sure looks like a password to me. Right there in the clear. Rule #1 of mobile development: NEVER DO THIS!! If you absolutely must store credentials on the device, it should be hashed (and salted) using a secure hashing algorithm such as SHA-2. Never, ever do this. Your users deserve better.

The sqlite3 utility included with the Android SDK allows you to work with the client sqlite databases that many applications use to store client-side information. The following command output shows you how to open a database, list tables, and execute a simple "select" statement:

Jack@Android_Fun =>>> ./adb shell
# cd /data/data/com.evernote
# ls
cache
databases
shared_prefs
lib
# cd databases
# ls
Evernote.db
webviewCache.db
webview.db
# sqlite3 Evernote.db
SQLite version 3.6.22
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> .tables
android_metadata note_tag resource_attrs tags_table
data_cache_state note_thumbnails resources
error_log_table notebooks saved_searches
note_attrs notes search_history
sqlite> select * from notes;
65f00f4b-676b-4f45-a9d0-2dcbf5bc1bc2|d7aede0e-ec5d-4ab8-8670-5070d5c0a35e|My Banking Information|289|1?j?4????s|1286304619000|1286304825000|0|1|4|1|5|0|0|0
8ea7f9c7-30b0-4112-98d3-4d78b81e79d5|d7aede0e-ec5d-4ab8-8670-5070d5c0a35e|My Personal Information|321|”??^?A??FdJ|1286305164000|1286305164000|0|1|7|1|5|0|0|1
sqlite>

Take the time to do your due diligence to ensure that these very simple to prevent issues don't manifest themselves. While you may think you've caught every instance of where data may be potentially be exposed, taking a close look at the application in use may prove otherwise.

Gaining unauthorized physical access to a mobile device is a very real threat. Even if a user password protects their device, gaining access to data is as easy as plugging the phone in and attaching it to ADB. Also never assume that the user's device won't be rooted (or jailbroken for iOS devices), effectively negating most of the built-in "protection". All it takes is a single malicious application to be installed on a rooted device for this information to be easily extracted.

We have only begun to scratch the surface of the vulnerabilities present within mobile platforms. While you cannot protect against the unknown, minimizing the surface for potential issues by writing code that addresses issues we DO know about today is the only way to ensure your applications withstand the test of time.

As an eye opener, take a look at every application installed on your mobile device. I guarantee you that at least one application (likely many more) is exposing your information in a similar and insecure fashion.

Reversing Android Apps 101

First blog post in a long time, so I figured I should start back off with something I've been getting a lot of questions about lately, which is how to get started with learning more about Android application security.

I think the absolute best way to understand what's going on is to start looking at real world applications. This tutorial will show you how to download an Android application and convert it back into a format that we prefer, which is its original Java code. Hopefully this will be the first tutorial of many, so be sure to check back from time to time.

I hope this post can be of use to developers as well, in order to better understand that the code they allow to be distributed on mobile devices can easily be decompiled. If you are storing hardcoded credentials or reference other things you don't want the user (or bad guys) to know about, you should re-evaluate that design choice.

My disclaimer is that this should not be used for malicious purposes, etc etc and all of the other stuff no one will likely listen to.

To get started, you will need these applications on your box:

-Android SDK
-dex2jar
-apktool (JAR and dependencies)
-JD (or a similar Java decompiler)

The first step is to download the Android SDK (Software Development Kit). You will rely on this heavily when testing applications and interacting with Android devices. There are many useful utilities bundled with it including Android Debug Bridge (ADB) and the emulator.

The next step is to download an interesting application to rip open. Most of us are Twitter fans, so why don't we take a look at the Twitter application for Android?

At this point, you have 2 choices:

-Download it to your physical Android device
-Download it to a virtual device running in the Android emulator

By default, the virtual devices available using the emulator that comes with the Android SDK do not have the Google Market application installed. You can either 1) spend time finding ways around this or 2) install an image that has the software pre-loaded. Here is an excellent tutorial on how to go that route, although you may want to use a more up to date image than the ones referenced. They use older versions of Android.

Android Emulator Tutorial

Assuming you have either plugged your phone in or started an Android virtual machine, in the tools folder of the Android SDK folder, you'll find several utilities incuding ADB. I recommend familiarizing yourself with it, as you will use it almost constantly if you are working with the Android platform.

ADB allows us to do many things including connect to the device and have shell access. We first need to figure out where the application we downloaded is stored. Under the /data/app/ directory, we will find all of the APK files for applications we've downloaded. Under /system/app is all of the applications included with your Android distribution. For this tutorial, we are concerned with /data/app as this is where our Twitter application will be located.



Now that we know what we want to download, we need to transfer the file to our local system for further analysis. This can be achieved also by using ADB.

We will not be using the shell this time, but rather the "pull" command which allows us to select and retrieve files from the Android device. The general format for this command is: adb pull apk_file destination_directory



Now that we have the APK file, we'll need to unzip it. The APK is simply in standard ZIP format, so any of your existing ZIP compatible utilities will work.

After unzipping the APK file, there are two things you should be primarily concerned with at this point: looking at the manifest file, and getting the .DEX file into a more desirable format to work with. The manifest contains juicy information like permissions, intent filters, and lots more. If you aren't familiar with the manifest file and how its used with Android applications, I highly recommend reading the documentation on the Android development site:

Manifest Intro

If you try to open the AndroidManifest.xml file that was just unzipped, you'll find that it isn't in plain text. We'll use apktool at this point to convert it into a format we are comfortable with. We'll use apktool to decode the entire APK, and then the manifest file should be much easier on the eyes:



After running apktool, this is what the AndroidManifest.xml file should look like when viewed in a text editor or Eclipse:



The classes.dex file in the originally unzipped APK file is the crown jewel here. It contains all of the application's code, but in the Dalvik Executable format.

There are tools such as dedexer and apktool that will convert .DEX into smali assembly format, but again we are concerned with looking at the Java code. We can use dex2jar to achieve this:

dex2jar.bat path_to_classes.dex

Once we've run dex2jar, there will be a classes.dex.dex2jar.jar file in the folder where the original .DEX file was located. Simply unzip this JAR file. Upon unzipping it, we see a bunch of .class files.



Nothing to worry about, this is familiar territory at this point. Simply use your favorite Java decompiler to convert from bytecode to easily readable code.



We now have complete access to the entire client application. In the tutorials to come, I'll show you some things you should be paying close attention to when reviewing or designing an Android application.

GoDaddy XSS

Just a quick poll. Contacting them directly didn't work, blasting them on Twitter didn't get their PR people to respond, and releasing it to the masses will only cause innocent people to be exploited. I guess all we can do is take guesses at how long it will take them to pull their heads out of their asses.

-Jack