Embedded Malware in Mobile Applications Blog
Mobile is ripe for attack, as many people only associate cyber threats with their PCs and neglect even basic security precautions on their mobile devices. Under the Public Safety Canada Cyber Security Cooperation Program (CSCP) TwelveDot created a standardized methodology to qualitatively identify malware and vulnerabilities in mobile applications.
Given the risk of exposure to both consumers and businesses we needed to ensure that Canadians are protected from embedded malware while using mobile applications. This included the development of a standard method for mobile application developers to ensure their apps are tested and validated to minimum security levels for usage not only in Canada but globally. This methodology provides users with an easy to use grading system to determine if they are accepting of the risk of using the application.
GCAM and why a standardized method is important…
TwelveDot successfully developed a methodology to test mobile application security. This is a formalized methodology known as General Code Assessment Methodology (GCAM) which can identify, categorize and report on malware and application weaknesses for resolution by the vendor/developer.
There is a need to move towards a mobile application security standard. There are no current standards for mobile application security. Most mobile applications do not even pass basic security tests. Some organizations have mobile application security tests such as dynamic and static code analysis but these only validate the code and does not encompass mobile application behaviour nor the interaction between mobile applications, their users, cloud services and 3rd parties.
Using the GCAM methodology, we were able to identify mobile applications that indicate signs of bad coding practice and poor application design. These factors were used to derive a calculation that can be used to determine an application grade. This grade clearly indicates to a user the potential risk of security and privacy exposure.
For the data captures, a Man-In-The-Middle (MITM) proxy was used to intercept and decrypt secure network sessions and we used Wire Shark to capture all the network session traffic. The network traffic shows, from a security perspective, how someone with intent could use fingerprinting techniques to target a device/user.
The applications were selected from both the Apple and Google Play app stores. We did not focus on other app stores due to lack of source control over the posted apps. We wanted to focus on applications that users and business would use everyday. Applications can be broken down into two major categories, free and paid applications. We have selected applications from both major categories.
The applications are then further broken down as shown in the categories below.
App Store Categories:
Food & Drink
Health & Fitness
News & Video
There is a general trend, from the analysis of the tested mobile applications, for someone with intent to use advanced techniques to target a device or user. Security and privacy is not a primary concern when designing/coding mobile applications, and many developers do not have the necessary skills for these considerations at design time. Larger more established organizations with more resources (time and money) such as Google and Facebook, generally have better coded and designed applications, where as the smaller less process mature organizations demonstrate less skill in developing secure mobile applications. However, the larger organizations also attempt to exploit user data by creating malware and using vulnerabilities built-in to their applications. This can be demonstrated by the fact that analytic engines collect user data and behaviours without user knowledge. These include API’s and SDKs from Google, Yahoo, and Amazon. These engines are included in the majority of applications given that they are free and easy to integrate for developers.
Figure 1 iOS Embedded Malware
Figure 2 Android Embedded Malware
Our tests show that the SDKs and API’s that developers implement are not just Apple or Google APIs but 3rd party APIs that may not be securely tested or validated but just added in. Over 40% of the applications we tested contained embedded 3rd party SDK/API’s.
3rd party libraries in the SDK’s have known vulnerabilities but the majority of mobile applications have not been tested against these known vulnerabilities. Many developers don’t even now the risk of using these 3rd party APIs nor do they evaluation the source code for origin.
The vast majority of library flaws remain undiscovered and typical Java applications are likely to include at least one vulnerable library.
3rd party libraries in the SDK’s have known vulnerabilities as can be seen in the CVE database but the majority of mobile applications have not been tested against the known vulnerabilities. Nor do the developers of these libraries report the vulnerabilities to the developers.
Sample SDK Vulnerability
- A vulnerability in the OpenSSL ssl3_get_key_exchange function could allow a remote attacker to downgrade the security of certain TLS connections. An OpenSSL client accepts the use of an RSA temporary key in a non-export RSA key exchange ciphersuite. This could allow a remote attacker using man-in-the-middle techniques to facilitate brute-force decryption of TLS/SSL traffic between vulnerable clients and servers. This vulnerability is also known as the FREAK attack.
Analytic engines are the largest threat vector in mobile environments.
These engines collect a variety of data from account names to country codes to browser versions. Data is even collected when the user is offline and saved to persistent storage on the device and forwarded on to the server during the next session. The data is retained for months if not years and the user is never advised of the storage length or uses of the data being collected. In many instances the companies that offer these services will typically sell this data to marketing companies looking to directly target advertising to these users.
An example of a popular analytic engine can be seen below in Figure 2. It shows the network traffic timestamp of the Crashlytics engine at work. Crashlytics is a popular analytic engine and it was prevalent in the applications we tested.
Figure 2 Network traffic timestamp of crashlytics data being transferred
Data found in application directories with compiled data to be sent to crashlytic analytic server.
Figure 3 – Crashlytics directory created by app on device
Looking at the directory structure pictured above (Figure 3), one can see that the data is grouped according to its processing status. The engine will process data it deems valid to send back to the server. Sendable data, data being processed, data that is prepared to send and invalid data. This data is also processed offline and can be sent back once a network connection has been established.
Fake apps mimic the actual applications they are supposed to replace. They are easily found on third party app download sites, websites and official app stores including Google Play. While outside the scope of our security testing users need to be aware these apps are prevalent and pose significant exposure risk when used.
Fake apps are available in every app category from Business to Games, Finance and Weather. These apps are not harmless copycats, they are intended to be malicious and include embedded malware.
Applications can be downloaded directly from the developer’s site. They can also be downloaded from 3rd party sites. There are thousands of sites that offer application files available for download.
Herein lies the problem. The 3rd party sites are not secure. They do not ensure the apps are secure or free from malware/vulnerabilities. Moreover some of the sites are purpose built venues for malware/vulnerabilities to be introduced to users. These sites actually repackage the application with embedded malware/vulnerabilities. The files are then unwittingly downloaded by users and installed. The user’s device is now compromised.
Cloud Services are used by a majority of the mobile applications tested. Approximately 80% of the apps tested use cloud services. The main players in this are Amazon and Google.
Sample test results from the DropBox application in iOS show both Amazon and Google Cloud services in use. Google cloud services uses Google cloud endpoints, so it can determine user location, locate nearby stores, and then provide the user relevant offers and recommendations. These usage patterns build on the users’ already growing user profile created for each and every user of these services. Many users are not aware of the metadata being collected on them at this point and once they do it is too late to remove your fingerprint.
What can you do to ensure your apps are safe?
Users and businesses need to assess risks, determine threats and mitigate threats. These threats include, threats to data, threats to availability and system integrity.
- Always research the publisher/developer of the app. For iOS apps a user can look at the details tab of the mobile app in the Apple App Store and look at the information about the app and search the publisher/developer.
- Read application reviews. Check around to see what others are saying ( macworld.com, pcworld.com, androidtapp.com)
- Always check application permissions (a simple calculator app should not need access to personal information) For iOS open the Settings app and scroll down to the list of apps at the very bottom. Tap an app and you’ll see the permissions it wants. You can enable or disable individual permissions for specific apps from here. For Android apps select Menu>Settings>Applications>Manage Applications. Then choose an app and scroll to the bottom and it shows you the list of permissions.
- Avoid installing Android Package files ( APK’s ) directly to your device. If you use the Google Play site to install apps then you should be ok. However if you download .apk files from developer sites or third party sites and install the .apk , then you are putting yourself at higher risk. Sideloading is the process of loading an .apk file directly to your device. Not all manufacturers support Google Play on their devices. Also regional restrictions imposed by Google Play may prevent you from loading an app. In order to install an .apk file you will need to enable unknown sources which allows the installation of apps from sources other than Google Play. But be forewarned do not allow apps extra permissions for the majority of these will most likely contain malware.
- Install an antivirus app on your phone. Lookout is a quality mobile security app that is available for both iOS and Android.
There is also a comprehensive list of steps developers need to address to ensure mobile application security but that is for another day…another blog.
Full report on Embedded Malware in Mobile Applications available please contact us.