July 27, 2010

Introducing the App Genome Project


Click to enlarge infographic

The App Genome Project

This week at the Black Hat Security Conference, Lookout will unveil the App Genome Project, which is the largest mobile application dataset ever created. In an ongoing effort to map and study mobile applications, the App Genome Project was created to identify security threats in the wild and provide insight into how applications are accessing personal data, as well as other phone resources. Lookout founders John Hering and Kevin Mahaffey initiated the App Genome project to understand what mobile applications are doing and use that information to more quickly identify potential security threats.

Early Findings

Early findings show differences in the sensitive data that is being accessed by Android and iPhone applications, as well as a proliferation of third party code in applications across both platforms.  Stats include:

  • 29% of free applications on Android have the capability to access a user’s location, compared with 33% of free applications on iPhone
  • Nearly twice as many free applications have the capability to access user’s contact data on iPhone (14%) as compared to Android (8%)
  • 47% of free Android apps include third party code, while that number is 23% on iPhone*

* Examples of third party code includes code that enables mobile ads to be served and analytic tracking for developers.

New Security Vulnerabilities

Lookout will also be announcing new security vulnerabilities including Mobile Data Leakage,which occurs when developers inadvertently expose sensitive data in application logs in a way that makes it accessible to malicious applications. In one instance of this vulnerability, Android was releasing user location data into logs in a way that made it accessible to other applications. That vulnerability has been addressed by Google and is fixed in all versions of Android, v.2.2 and beyond.

This vulnerability and others point to the need for developers to be more aware of best practices for accessing, transmitting and storing users’ personal data. In addition, consumers need to be aware of the permissions that mobile applications request and how that personal data is being used in the application.

More detailed information on the App Genome project and more detail on vulnerabilities will be discussed in their two dedicated sessions at Black Hat this week. They will also be providing recommendations for OEM’s, carriers and developers on how to improve security across the mobile ecosystem.

  1. TheReviewer says:

    crazy how apps make or break the Apple OS and Apple treats their developers like crap

  2. RB says:

    This is technically impossible on an iPhone… The way iOS is built prevents this.

  3. John says:

    I’m very interested to know how secure Blackberry apps are. Our company uses these devices because they’re supposed to be ‘safe’, but how sure can you be when users are allowed to install 3rd party apps??

  4. […] blijkt uit onderzoek van Lookout waarover verschillende Amerikaanse media […]

  5. Ben says:

    So out of all those apps, how many of those sends your personal information to china?

  6. Feroz Yacoob says:

    I hope Lookout will incorporate this vital information into there existing app available on Android.

  7. aNONyMoosE says:

    WebOS isn’t included in this… what does that mean?

  8. […] disclose that the information would be sent to a third-party. Lookout found the app as part of its App Genome Project, an ambitious project to track the behavior of 300,000 […]

  9. Ben says:

    WebOS is not included because it’s too minor.

    They only include iOS to sugar coat Android’s Jackeey Wallpaper app that send user’s personal information to China.

  10. “Nearly twice as many free applications have the capability to access user’s contact data on iPhone (14%) as compared to Android (8%)”

    How do you determine that an iPhone “has the capability to access user’s contact data”? Unlike Android, there is no explicit permission bit that is set that the user is warned about–any iPhone app can access the Address Book Database without requiring a specific permission bit to be set. So, in theory 100% of all iPhone apps can access the user’s contact data.

    So how do you determine this 14% number? In other words, what additional criteria are you using to say if an iPhone app may verses won’t access the data? Are you somehow scanning the code to find instructions which invoke the Address Book Database UI? Or are you using some other criteria?

    I also find the metrics for Android a little sketchy. Just because you ask for a permission bit doesn’t mean you’re using the full capabilities flagged by that permission bit, right? I mean, isn’t this the equivalent of saying that because knives kill people, and half the country owns a knife, half the country could be murderers?

  11. kevin says:


    We use similar, but slightly different techniques to analyze Android and iPhone applications due to their different respective application frameworks. We presented our full methodology at the Blackhat security conference (the full slides will be public soon), but I’ll give a brief summary.

    On Android, we used a combination of permissions and static analysis (using custom-built tools that examine Android executables) to determine what capabilities each application has. On iPhone, we determined application capabilities by analyzing the Mach-O load commands and symbol tables in application binaries. We specifically looked at which APIs each application references, what classes/methods/instance-variables each application implements, and which frameworks each application references.

    It’s important to remember that the data that we’re releasing shows the aggregate usage of particular sensitive capabilities. Simply because an application accesses sensitive capabilities, doesn’t mean it’s bad. Our goal with this research is to help make people aware of the capabilities of mobile apps so that they can be vigilant while downloading.

    Hope this helps clarify.


  12. uli says:

    * Examples of third party code includes code that enables mobile ads to be served and analytic tracking for developers.

    So that number (47% of Android apps include 3rd-party code, vs 23% iPhone apps) doesn’t tell us anything since those libs could just as well be compression libraries, crypto, image analysis, whatever.

    Do you have a more detailed break-down in the BH talk?

  13. anonymus says:

    an app from ios can not get to that data.

  14. Jim Teece says:

    The phone is assumed trusted by the end user because the mfr refuses to apply the same visual protocol that we have trained everyone to look for in every browser. The lack of a simple lock icon in a universal location next to the bars would let me know if and when something is secure.

    The encryption is assumed as is the app intelligence. I think that someday your genome project will be used to autobrand a tested app, secure by default. Like a def con rating.

    Up the level for each infraction.

    1 ssl
    2 logs
    3 black box Apis

    Ninja badge worthy?

  15. So nice I just became the fan of your site and noted on my bookmarks, thanks.

  16. Stan says:

    Genau das habe ich auch gehört. Die Apps, die eigentlich das Arbeiten und Surfen erleichtern sollen, haben scheinbar die Seuche am Hals, denn zahlreiche Apps spionieren den Nutzer aus und übertragen nicht nur Daten zum Surfverhalten sondern öffnen eröffnen auch andere Möglichkeiten für Hacker.

  17. Wim T says:

    volgens mij komt het nog steeds voor dat als je free app installeer dat je ook gegevens vrij geef.

Leave a comment