[April 8: We've added some more information in a follow-up post]


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.


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(); 
        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.


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

Tyler Shields is a Senior Researcher for the Veracode Research Lab whose responsibilities include understanding and examining interesting and relevant security and attack methods for integration into the Veracode product offerings. He also keeps track of new developments from other computer science and information security researchers to ensure that Veracode technologies are always kept in line with the most recent security advancements.

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.




contact menu