Today we’re proud to release the third volume of our semi-annual State of Software Security report. This edition incorporates data from 4,835 applications analyzed via our cloud-based platform over the past 18 months. After lots of number crunching and a fair amount of head scratching, we’ve unearthed some intriguing findings that reflect the progress (or lack thereof) being made in securing the world’s software.

Not convinced yet? Here are a few of the data points I found particularly interesting:

• Over the past 8 quarters, the prevalence of SQL Injection (% of web apps affected) has decreased slightly, but XSS has remained flat.
• Security products perform worse than most other software suppliers in terms of acceptable security quality on first submission.
• Over half of developers who take our Application Security Fundamentals exam receive a grade of C or lower.
• Security quality scores are similar for companies across all revenue brackets, and there is no discernible difference between public and private companies.

And there’s a lot more where that came from. Plus histograms, whisker plots, linear regressions, and more! Download the full report to get all the juicy details, then come back here and tell us what you think. Enjoy!

Veracode Security Solutions

Security Threat Guides

The blog post we made earlier this week entitled, Mobile Apps Invading Your Privacy, gives detail around the information being requested by the advertisement libraries embedded inside a popular online radio application. There have been a number of great posts and comments that got us thinking more about the issues and the types of data being requested.

First off we want to thank some people who commented about the Pandora application not having permission to actually access the GPS on the device. Below are the Manifest permissions for the version of Pandora currently in the Google Application Marketplace:

• Full Internet Access
• Create Bluetooth Connections
• Read Contact Data
• Add or Modify Calendar Data and Send Emails to Guests
• Read Phone State and Identity
• Modify Global System Settings
• Prevent Device from Sleeping
• Bluetooth Administration
• Change Wifi State
• Change Network Connectivity

As you can see, GPS access is NOT included in that list. There was an error in the original post we made stating that some of the library code was requesting permissions from the Google system for GPS access, and as the commenter pointed out, that is incorrect. The code snippet we posted is only checking whether the parent application, Pandora in this case, has permission to access the GPS. If the parent does not have permission, the accessing of GPS data can’t occur.

However, the overarching theme of the original post is still valid. If Pandora had required GPS access for a legitimate reason, the embedded advertisement library would have been able to request the GPS data and send it off device. As we mentioned in the original post, there is a chance that Pandora has no idea what the embedded advertising library actually does, simply taking it from the advertising partner and embedding it into their application.

To further illustrate this point, we downloaded a few more applications that use some of the same advertising libraries. In particular, we found AdMob (the code snippets we outlined on the previous post) embedded into the free CBS News Android application and the TVDotCom application. Both of these applications have GPS coarse and fine permissions allowed within their application manifest. They don’t have some of the other permissions required to send certain data, but in these cases the advertising code will fail silently. Essentially, the advertising libraries use the parent application as an enabler, taking advantage of whichever permissions happen to be available. It also seems revelant to note that AdMob was acquired by Google in May 2010.

The current model where permissions are granted to applications combined with the way 3rd party libraries such as mobile ad network libraries request many different types of information sets up a situation where the ad network will get the information if the application needs it to operate.

Veracode Security Solutions

Security Threat Guides

Background

An article in the Wall Street Journal, dated April 5, 2011, disclosed that Federal prosecutors in New Jersey are investigating numerous smart phone application manufacturers for allegedly, illegally obtaining and distributing personal private information to third party advertisement groups. The allegations state that mobile applications are gathering data such as GPS location, device identifiers, gender, and even user age without proper notice or authorization from the end user. The Journal tested 101 applications and found that 56 of them transmitted the device unique identifier off the device, while 47 transmitted the phone’s location. Five of the tested applications leaked personal information such as user gender and age.

Analysis

The folks at the Veracode research team decided to spend a bit of our time today breaking apart one of the accused applications to see what could be found within the code. Given what was written in the Journal article, we thought it would be most interesting to take an in-depth look through the Pandora application for the Android platform. A quote from the article states the following about the Pandora application:

In Pandora’s case, both the Android and iPhone versions of its app transmitted information about a user’s age, gender, and location, as well as unique identifiers for the phone, to various advertising networks. Pandora gathers the age and gender information when a user registers for the service.

Our first step was to analyze the application using the Veracode platform. We followed up the automated static analysis with a manual analysis of the compiled dex code. The results were fairly interesting. The Pandora for Android application appears to be integrated with a number of advertising libraries. Specifically we found FIVE (yes that’s FIVE!) advertisement libraries compiled into the application: AdMarvel, AdMob, comScore (SecureStudies), Google.Ads, and Medialets. Looking even closer, we analyzed each of the modules to determine the type of data they access.

The first library we decided to break apart was the AdMarvel and AdMob libraries. The AdMarvel library references the AdMob library fairly significantly. AdMob in particular accesses the GPS location, application package name, and application version information. Additionally there were variable references within the ad library that appear to transmit the user’s birthday, gender, and postal code information. The code snippets below are taken from a decompilation of the AdMob library where GPS locations are being gathered. As you can see in the code, the library requests permissions for both COARSE_LOCATION, and FINE_LOCATION data:

public static Location getCoordinates(Context unknown)
{
.... SNIP ....
        String str1 = "android.permission.ACCESS_COARSE_LOCATION";
        int m = unknown.checkCallingOrSelfPermission(str1);
.... SNIP ....
        String str2 = "android.permission.ACCESS_FINE_LOCATION";
        int n = unknown.checkCallingOrSelfPermission(str2);

We can also see where the library actually attempts to capture GPS location information on a continuous looping mechanism:

        int i4 = Log.d("AdMobSDK", "Trying to get locations from GPS.");
        localObject2 = (LocationManager)unknown.getSystemService("location");
        if (localObject2 == null) break label428;
        Criteria localCriteria = new Criteria();
        localCriteria.setAccuracy(1);
        localCriteria.setCostAllowed(0);
        localObject3 = ((LocationManager)localObject2).getBestProvider(localCriteria, 1);
.... SNIP ....
        int i5 = Log.d("AdMobSDK", "Cannot access user's location.  Permissions are not set.");
.... SNIP ....
        int i6 = Log.d("AdMobSDK", "No location providers are available.  Ads will not be geotargeted.");
.... SNIP ....
        if (Log.isLoggable("AdMobSDK", 3)) int i7 = Log.d("AdMobSDK", "Location provider setup successfully.");
        AdManager.1 local1 = new AdManager.1((LocationManager)localObject2);
        Looper localLooper = unknown.getMainLooper();
        ((LocationManager)localObject2).requestLocationUpdates((String)localObject3, 0L, 0.0F, local1, localLooper);

We also saw references to the user’s gender:

        Object localObject = k; Gender localGender1 = Gender.MALE;
        if (localObject == localGender1)
       {
            localObject = "m";
       } while (true) {
      return localObject;

      Gender localGender2 = k;
      Gender localGender3 = Gender.FEMALE;
      if (localGender2 == localGender3) { localObject = "f"; continue; }
      localObject = null;

And of course, access of the infamous Android ID value (android_id):

      if (f == null) { Object localObject1 = unknown.getContentResolver();
      localObject2 = localObject1;
      localObject1 = Settings.Secure.getString((ContentResolver)localObject2, "android_id");

The analysis into the remaining libraries resulted in even more of the same. The SecureStudies library accesses the android_id and directly sends a hash of the data to http://b.scorecardresearch.com while the Medialets library accesses the device’s GPS location, bearing, altitude, android_id, connection status, network information, device brand, model, release revision, and current IP address.

Conclusion

So what does this mean to the end user? It means your personal information is being transmitted to advertising agencies in mass quantities. As more and more “free” applications attempt to monetize their offerings, we will likely see more of your personal information being shuttled out to marketing and advertising data aggregation firms. The application developers may not even be aware of the privacy violations they are introducing by using third party advertising libraries. They may merely think they are getting $x per ad impression, not that the ad library is leaking significant information about the user.

In isolation some of this data is uninteresting, but when compiled into a single unifying picture, it can provide significant insight into a persons life. Consider for a moment that your current location is being tracked while you are at your home, office, or significant other’s house. Couple that with your gender and age and then with your geolocated IP address. When all that is placed into a single basket, it’s pretty easy to determine who someone is, what they do for a living, who they associate with, and any number of other traits about them. I don’t know about you, but that feels a little Orwellian to me.

Veracode Security Solutions

Security Threat Guides