In the previous blog, I detailed a great starting point for mobile application testing— the AppUse framework—and highlighted its greatest pros and cons. This tool, created by AppSec-Labs, combines many additional tools to perform static and dynamic analysis of an application and the smartphone device that it runs.
Remember, please only use the tools and methods discussed on systems that you own and have the right to access.
Application Permissions: Read What the App Requires
Taking a more in-depth look at the permissions allowed by Zynga, we find that many of them can be used to cause excessive harm or to obtain considerable amounts of user data. This app requires permissions to view Wi-Fi connections, view network connections, run at startup, use accounts on this device, control vibration, and modify or delete the contents of your USB storage. Keep in mind that these are permissions for a free chess app.
There are many more permissions required, but I wanted to highlight the mentioned permissions specifically as they are considered to be most often abused and allow for user data to be taken (for non-malicious applications).
By combining these permissions in malicious applications, malware can be downloaded onto a phone or a user’s information can be stolen directly. Truly malicious applications can use these permissions to identify and join an open network to drain battery life and communicate externally, all without the user’s knowledge.
Previously, I observed that my PII was sent to Zynga’s servers in cleartext. Additionally, my Facebook information was sent despite opting out of any Facebook services. This blog will take a closer look at what is being collected and how those permissions are being used.
I understand that these permissions can be used to cause harm, but that does not mean that they are causing harm. For example, this application has an entirely legitimate reason to access my contacts as I reach out to my friends and invite them to play chess with me.
The important aspect is how the data is used. To gain a full understanding of what is being done to allow this game to work, the source code should be reviewed to identify how the application runs.
How to Analyze the Source Code and What to Look For
AppUse has a dashboard that includes many of the tools necessary. Below, I loaded the app’s APK file and selected the JD-gui tool in the UI.
JD-Gui converts the bundled APK file to a more readable Java format. Selecting this tool brings up a new screen with the source code grouped by classes. Viewing the source code that defines the ads that are being served to my client, a suspicious class was present, AAXParameter$GeolocationParameter.class. This was suspicious to me because of all of the permissions required, nowhere was it stated that geolocation information was being collected. Within the readable code, it can be determined that my device’s longitude and latitude are tracked, and the functionality is present to send this to the ad delivery server.
Some other classes to note are within the com.zynga.sdk.installtracker, specifically InstallTracker and InstallTracker$1.
InstallTracker contains the code to store the PII information that is ultimately delivered to Zynga’s servers, as identified in the previous post.
InstallTracker$1 makes suspicious calls that appear to be mapping the network that the device is connected to.
The decompile tool, Luyten, functions in a similar manner to JD-gui as it converts the APK into dex format and then to a readable jar.
Analyzing a Live Application
Another great tool within AppUse give the functionality to dynamically test a given application is ReFrameworker. In my case, I was unable to get ReFrameworker to recognize my rooted device attached to it or push its necessary jar files onto the device. However, the following steps worked on an emulated device to dynamically test the sample app in a controlled environment.
Launch a new emulator from the AppUse dashboard by going to Android Device > Launch Emulator. Once the emulator is ready, go to ReFrameworker > Enable ReFrameworker to import the necessary jar files onto the emulator.
Use the ReFrameworker dashboard to select the type of information you will automatically modify upon intercepting. The options highlighted in green have been configured and enabled. For example, anytime an application calls the function to access the device’s ID (IMEI), the value sent in the request will be changed to “NotMyRealID.”
The tool can also be calibrated with hooks that notify the user when critical directories are being accessed. In this manner users can be alerted as to where and how a given app is accessing information associated with contacts, the external sd card, or stored pictures.
Using the tools included in this penetration testing framework, a full understanding of mobile applications can be achieved. Analyzing source code statically or listening to requests and responses sent between client and server is limited. By combining the tools available, AppUse makes mobile app testing considerably easier in that it draws connections between potentially harmful behavior and functions that are being executed.
