The document discusses 7 ways that Android applications can be vulnerable, including intent hijacking, intent spoofing, sticky broadcast tampering, insecure storage of data, insecure network communication, SQL injection, and allowing applications to have promiscuous privileges. It provides descriptions and examples of each vulnerability and recommends ways to address the security issues, such as using explicit intents that require permissions, securing data storage, and limiting application privileges. The goal is to help developers avoid introducing vulnerabilities that could allow attackers to compromise user data or alter application behavior.
Smartphones as pocket PCs and extend the desktop experienceThe desktop has migrated to the smartphone. Everyday desktop activities such as browsing, searching and consuming entertainment is now done on smartphones.Almost 70% use applications to extend their phone’s functionality
Smartphones have become the go-to computing device for both productivity and entertainment alike.Smart phones have become a combination of a Rolodex, PDA, camera, photo album, wallet, game controller, pager, camcorder, television, barcode scanner, GPS device, PC, FM radio, MP3 player, newspaper, book, calculator … in addition to your communication device.
It wasn’t long ago that being on the cutting edge of business meant having a website where customers could purchase your products, but that quickly changed. Soon, it wasn’t enough just to have an eCommerce presence: you had to offer an interactive and engaging customer experience (see Web 2.0). Now the standard has shifted once again: in order to truly compete in the modern economy, your business needs to have a mobile storefront on smart phones and tablets. Without this mobile presence, you’ll lose business to competitors who have them.
Step one for addressing quality is focusing on application fundamentals. For every IT project, every new application rollout, application change or upgrade, you and your customer need to answer some basic questions: Will the application work in production? Will it scale and perform well under load? And will it be secure? To mitigate business risk, the answer to all three questions has to be “Yes.” HP quality, performance and security testing solutions make it easy to manage the quality management process from start to finish by providing the right tools to verify functionality from the end-user perspective, optimize performance by testing and diagnosing issues under emulated production loads and validate security.
Mobile applications rely on all of these elements. We have a server a client device a full time internet connection a custom operating system as well as a local database. These elements comprise a mobile system. Some of them are similar to the challenges of the past and some of them present new challenges unique to mobile
The client server model is nothing new. Mobile apps are an extension of RIA applications, in general we are dealing with highly customized UI’s for input of data. The general attack surface of this model is the same as always, the server. The server is likely a legacy web application that surfaced new APIs or used existing APIs to serve the new client. There is nothing fundamentally different about this
Step one for addressing quality is focusing on application fundamentals. For every IT project, every new application rollout, application change or upgrade, you and your customer need to answer some basic questions: Will the application work in production? Will it scale and perform well under load? And will it be secure? To mitigate business risk, the answer to all three questions has to be “Yes.” HP quality, performance and security testing solutions make it easy to manage the quality management process from start to finish by providing the right tools to verify functionality from the end-user perspective, optimize performance by testing and diagnosing issues under emulated production loads and validate security.
I’ll talk about the first 4 vulnerabilities: 3 Communications related vulns. And Insecure storageAnd Katrina will discuss insecure network communication, SQL injection, and overprivileged apps
Let’s take the IMDb app for example. This app has a feature where the user can get the showtimes for movies in the area. To do this, the app has a component, Showtime Search, that sends information and requests to the component, Results UI, which then updates the user’s screen. <click> The display will either update with the latest showtimes or return that there are no shows available.
This is an example of what the user might see when the message is sent. The user sees a list of the movie showtimes in the area.
The problem is that the IMDb is sending an Implicit intent to be resolved by the system - which means it can potentially be seen by any application. All a malicious app needs to do is declare that it can handle the same action as the Intent and it may receive the Intent.In the case of the IMDb app, the attacker can find that the user is 1) using the IMDb app and 2) looking for showtimes. If the Intent contains any additional data, the attacker can also steal that.Sidenote: Another example is a bus application that gives the user information on where the bus is and when it will arrive. In that app, an attacker can eavesdrop on the bus request and determine the user’s location. This is a clear privacy violation.
This attack exploits a vulnerability on the receiving side. The problem is that the developer is publically exposing the receiving component. To be able to receive the implicit Intent, the receiver component is also made public to all applications. This means that any application can send messages to the component either explicitly or implicitly. And thus it is vulnerable to an intent spoofing attack.In the IMDb example, a malicious app could inject an Intent into the results UI by sending an implicit or explicit Intent. If the malicious application sends the NoLocationError action, the receiver would report that no showtimes were found.
Instead of seeing a display like the one on the left (the showtimes of movies in the error), the user would see no information (on the right), resulting in a denial of service.Bus app: Going back to the bus application, an attacker can inject fake bus information into a vulnerable bus component, potentially making the user wait for a bus that never arrives.
Like the typical unauthorized intent receipt problem- malicious receipt could leak sensitive databut special in two ways Can be sent to all receivers -> can’t be limited by permissions -> accessible to any receiver, including malicious receivers Persists. And is expected to persist, but can be removed by malicious app
Like the typical unauthorized intent receipt problem- malicious receipt could leak sensitive databut special in two ways Can be sent to all receivers -> can’t be limited by permissions -> accessible to any receiver, including malicious receivers Persists. And is expected to persist, but can be removed by malicious app
3. Even if new owner (or old owner) does a factory reset, it does not wipe the SC card.
Using wireshark, we sniffed http packets coming from the phone. We can see text and location in this example. BAD.
Using wireshark, we sniffed http packets coming from the phone. We can see text and location in this example. BAD.
Especially alarming because in a regular web app you can set a preference to use https, but in mobile app, you can’t.
Warning: SQL Lite methods vulnerable to full SQL injection include delete, execSQL, rawQuery, update, updateWithNoConflict
They may request a permission that sounds relevant to what they are doing. (When registering for an “android.net.wifi.STATE_CHANGE” Intent, they may unnecessarily request the ACCESS_WIFI_STATE permission. Will have an example later.)They may leave a permission in for testing and forget to delete it. (Or change the design to no longer require that permission and forget to delete it)They may confuse using a protected service with invoking another application to use that service (example later)Due to lack of specificity in Android documentation, some turn to message codes or code snippets. Unfortunately, we have seen some of these incorrectly assert that a permission is required.In a class with getters and setters, it may be that only the setters need permissions. However, we have seen developers add permission when only using the getters.
An application sends an Intent to the Camera application asking it to take a pictureA developer may mistakenly add the “android.permission.CAMERA” permissionIt is the Camera application that this permission not the calling applicationIn this exampleApp1 is sending an Intent to ask the Camera app to take a picture. It is the camera application that needs the permission, not App1.