Application Porno or how to find secrets in mobile applications and take everything out

    In a news feed, I recently discovered a curious study where the guys downloaded and parsed the Android Playmarket, analyzed hundreds of thousands of applications for wired secret tokens and passwords.

    The fact that the result of their work concerned only the analysis of decompiled code for Android, my intention was to write about the research that I conducted a year ago, not only for Android, but also for iOS applications, and which, as a result, turned into a whole online tool , which I will tell at the very end, when its meaning becomes obvious. Part of what was written below was presented at the ZeroNights conference and on the pages of the Hacker magazine. (Since the material was not published online, the editors gave the go-ahead, for publication here). So let's go.

    Goal - Stores


    Much has been written about manual analysis of mobile applications, verification methods have been developed, checklists have been compiled. However, most of these checks concern the user's security: how his data is stored, how it is transmitted, and how it can be accessed using vulnerabilities in the application.

    But why should an attacker dig into how the application works on a specific user's device, if it is possible to try to attack the server side and remove the data of ALL users? How can a mobile application be useful for attacking directly the cloud infrastructure of this application? And how about taking and analyzing thousands or, even better, tens of thousands of applications, checking them for typical bugs - wired tokens, authentication keys, and other secrets?

    Since the link from the introduction is exhaustively written about GooglePlay, then my story, for fun, will be about the App Store, or rather, about iOS applications. How to implement automatic downloading from the AppStore, a topic for a separate large article, I’ll just say that this is an order of magnitude more time-consuming task than a “rocking chair” for Google Play. But with tears, blood, a sniffer and a python, it’s still solved :)

    In articles that address the issue of distribution of iOS applications, they write that:

    • Application is encrypted
    • The application is protected by DRM
    • The application you are installing is attached to the device


    Behind all these statements is the fact that in the distribution package of the application (which is a regular ZIP archive), the compiled code is encrypted with reference to the device. All other content exists in clear text.

    Where to begin ?


    The first thing that comes to mind (authorization tokens, keys, and the like) is the strings and grep tools. This is not suitable for automation. A stupid string search creates such an amount of garbage that requires manual parsing that automation loses all meaning.

    To write an acceptable automatic analysis system, you need to carefully look at what the distribution consists of. Having unpacked distributions for ~ 15,000 applications and discarded deliberate garbage (pictures, audio, video, resources), we get 224,061 files of 1396 types.




    * .m and * .h (source) - this, of course, is interesting, but do not forget about configs, or more precisely, XML-, PList- and SQLite-containers. Accepting this simplification, we construct TOP types of interest to us in popularity. The total number of files interesting to us is 94,452, which is 42% of the original.




    An application that we conventionally call normal consists of:

    • media content: pictures, audio, interface resources;
    • compiled code (which is encrypted)
    • data containers - SQLite, XML, PList, BPlist
    • any trash that got into the distribution for an unknown reason


    Total, the task boils down to two:

    1. Recursively finding various secrets in SQLite, XML, PList
    2. Search for any "unusual" trash and private keys


    Keep this token in secret


    Apparently, for many developers, it is not obvious that the published application becomes public. So, Oauth-tokens of Twitter and other popular services are periodically found. A case in point was an application that collected contacts, photos, geolocation, and deviceID of users and saved them in the Amazon cloud, and yes - using a token wired in one of the PList files. Using this token, it’s easy to merge data for all users and monitor the movement of devices in real time.



    An important circumstance, which for some reason is ignored: libraries that allow flexible management of push notifications (for example, UrbanAirship). In the manuals it is clearly written that in no case the master secret (with which the server part of the application sends push) can not be stored in the application. But master secrets still occur. That is, I can send a notification to all users of the application.



    TEST-DEV


    You should not ignore the various artifacts of the testing and development process, that is, links to debugging interfaces, version control systems, and links to dev environments. This information can be extremely interesting to cybercriminals, since it contains SQL database dumps with real-life users. Developers, as a rule, do not deal with the security of the test environment (leaving, for example, default passwords), while often using real user data for better testing. An outstanding find was a script through which (without authentication) it was possible to send push notifications to all users of the application.



    Tap to enter


    The fact that the distributions come across information about the test environment and information about version control systems is expected. But some things keep surprising:

    • SQLite-based credential services

    • Business Card Application with Client Authentication

    • Private key for signing transactions



    What is this doing here ?!


    The discovery of the content described above is, in principle, understandable, but in applications you can periodically find inexplicable things, for example a PKCS container with a developer’s certificate ... and a private key to it



    Or pieces of PHP code with logins, passwords for the database.



    ... and my favorite is the OpenVPN working client config.



    And also not encrypted private keys of "all grades and colors" (c)



    What except secrets?


    No matter how inherently the issue of licensing was controversial, it found its place here too. Many developers use code in their programs frameworks that are licensed under the GPL, which requires code disclosure. And how the GPL works with paid and free apps on the App Store is a question that could create patent troll space for maneuver.


    Is There an App for That?


    In total, we have thousands of applications in which the described “jambs” are located, but the developers are not particularly in a hurry to do something about it. What is the problem here? On the github there are a lot of all kinds of super-designs for auditing application security, but in order to work with them, the developer needs:

    1. Spend time and energy to figure out for yourself how that works. That is, additional work for which they do not pay
    2. Create and maintain infrastructures.
    3. If there are many applications, then you need a separate specialist for full time, who will do point 1 and point 2


    this creates a situation in which wealthy corporations that are very worried about their brand or financial structures that hold tight to the “gills” by regulators can afford safe development. And the number of unsafe applications is growing.

    The answer to all these factors was the emergence of HackApp , a tool that provides a basic analysis of application security and is developed in accordance with the principles:
    1. The report should not “load” the developer with technical details (such as listings and traces), but clearly and clearly state what needs to be fixed
    2. Should not require investment in infrastructure. (that is, some client-side dedicated resources)
    3. To have an interface for automatic interaction, work with which can be integrated into the process of pre-release application testing, to become, from the point of view of integration into development, yet another testing tool


    Now HackApp exists in 2 versions: basic and Pro (with a paid subscription), but this is a completely different story.

    Also popular now: