Securing mobile applications
In this interview, Dan Cornell, Principal of Denim Group, talks about the most common pitfalls of securing mobile applications, discusses the challenges involved in performing a detailed mobile application security assessment, and illustrates what future threats we can expect down the road.
What are the most common pitfalls when it comes to securing mobile applications? What best practices should companies follow in order to avoid them?
We recently released statistics from a subset of our mobile application assessments at RSA Conference 2014. Based on the data we found, the biggest problems we see are handling data at rest, handling data in transit and designing in bad trust decisions.
One of the biggest problems is that applications store sensitive data on mobile devices and that data is then up for compromise if the device should fall into malicious hands. This can happen when a device is lost or stolen as well as devices that are purchased second-hand that unfortunately have not been wiped of content. The underlying point is that app developers do not know and have no control over what users are going to do with their devices, creating the need for developers to plan ahead to protect their users. Unfortunately, few development teams do this.
Handling data in transit is another area where app developers run into problems. Just as there are issues with sensitive data being stored on devices, we also see sensitive data communicated from the device to back-end services with little or insufficient protection. Mobile devices have a tendency to connect to a lot of untrusted networks where a variety of different classes of attackers may be able to observe traffic.
Finally, far too many mobile applications do a bad job of making trust decisions. This is most frequently found when developers fail to enforce even simple authorization controls for the web services that support mobile applications. Faulty trust decisions can also be found in a myriad of other situations when the interactions between the components of the mobile application have not been thoroughly examined.
Mobile apps need to be developed with the expectation that users are going to jailbreak or root the device and unintentionally install apps that are malicious. Because of this, security-critical decisions should not be made on the device or – if they are – those decisions need to be re-checked on the server side.
As for best practices, data classification is critical. Organizations need to be able to articulate the different types of data to be used by mobile applications. Specific guidelines then need to be provided on how different data types should be handled. Do you really want to let every developer individually decide whether or not it is OK to store a user’s password on the phone? Do you want developers rolling their own “protection” schemes to obfuscate data stored on device? Of course not – these decisions need to be made by organizations and communicated to developers to implement. Risk managers that fail to do this should expect the pandemonium that ensues.
Threat modeling is another technique that can pay huge dividends when creating mobile applications. With traditional web-based applications, the threat model is simple – the ” bad guys” live outside the firewall and you need to make sure that your security-critical decisions are made inside the firewall. With mobile apps – and more complicated web applications, for that matter – you have code running on the mobile device, untrusted third-party services as well as supporting corporate web services. By incorporating threat modeling techniques, you can more easily lay out the components in the system and define how they interact. Once teams overlay this structure and the associated data flows with the trust boundaries, they can start to identify potentially dangerous architectural and design decisions. By employing even simple threat modeling sessions, a large proportion of really dangerous, really expensive mistakes can be more easily avoided.
Developer training is another practice that will help avoid the introduction of security issues into mobile applications. As with data classification, it is unfair to expect developers to do the right thing if they do not know what the right thing to do is. The problem is that many developers working on mobile apps are working on their first mobile development project. They are often struggling with questions like “how do I get the button to appear on the screen where I want it.” When grappling with fundamental issues like that, it is unreasonable to expect these same developers to also focus on crafting secure architectural and application design that takes advantage of platform-specific security features when that app is implemented.
Even if you have set policies, created threat models and provided education to your development teams, you still need to look at the security of what you’ve created. Mobile application assessments can help to identify the security issues in each app so that these vulnerabilities can be remediated – hopefully before the apps containing them make their way into app stores. Obviously, it is preferable to avoid introducing vulnerabilities and weaknesses to mobile apps in the first place, but all these proactive measures are important steps to take to confirm and test the applications to make sure critical vulnerabilities do not already exist in the application’s code.
What are the challenges involved in performing a detailed mobile application security assessment?
Mobile application assessments are challenging because non-trivial apps have several components – code running on the device, third-party services and enterprise services that support the application. Security vulnerabilities can exist in any of these components as well as in the interactions between these components. From a scoping standpoint, it is important to know what needs to be assessed.
In addition, the tools needed to conduct mobile application security assessments are less mature than the tools that already exist for web application security testing. Static analysis tools have been updated to add rules for on-device code, but these rules often need to be tuned to focus on the most important results. Granted, this is not just a problem for static analysis of mobile code, but it is something to keep in mind. In addition, dynamic scanning tools for testing web services are not yet as mature as web application-focused directed fuzzing tools. Some vendors are making progress in this area, but the state of the industry is such that teams doing mobile app assessments need to plan to spend the time necessary to manually filter scanner results as well as perform manual testing. This can get time-consuming and costly.
Finally, communicating the results of a mobile app security assessment can be challenging. As mentioned above, there are multiple components to consider and vulnerabilities often creep in because of the interactions between components. In addition, exploit scenarios for mobile app vulnerabilities can be more complicated. These subtleties must be captured when reporting vulnerabilities and the challenges associated with executing a successful exploit must be explained if the report is going to effectively characterize the risk associated with a vulnerability. Risk managers require this so they can make informed decisions about whether to 1) fix a vulnerability to address the risk, or 2) take some countermeasure to decrease the risk, or 3) to simply leave the vulnerability in the system and accept the risk.
What are the most dangerous attacks targeting mobile applications today?
The most serious attacks we are seeing are actually targeting the web services that support mobile applications. These are tremendously attractive to attackers for a number of reasons. For example, the attack and exploit scenario are relatively straightforward. An attacker can disassemble a target mobile application and by watching the application’s network traffic through a proxy, they can discover what are the supporting services as well as the protocol used to communicate. At this point, the attacker has enough information in order to attack the service directly. We see a lot of web services supporting mobile applications that have only seen traffic from the “approved” mobile clients. It is when these web services are faced with malicious or adversarial traffic that it is revealed that there are no protections built into these web services and they cannot adequately stand up to an attack.
The impact of these direct attacks is varied. For example, many web services do not perform proper input validation or output encoding resulting in server-side SQL injection attacks or services that can be used for reflected XSS attacks. We also see a lot of web services that fail to require authentication for access or fail to enforce authorization for inbound requests. As a result, these attacks can result in data being compromised on a massive scale.
It makes sense why attacks against web services would be attractive when compared to the vulnerabilities on the device itself. Vulnerabilities found in code running on the mobile device can be challenging to exploit en masse. Often those vulnerabilities require a target to install a malicious application from an attacker or require the attacker to gain access to a user’s device. These scenarios certainly occur, but are hard to reliably engineer at high volumes. Server-based vulnerabilities have the potential to compromise large volumes of data. In addition, they can be exploited remotely.
With IoT on the horizon, BYOD is starting to feel like history. What new threats do you expect organizations to see 10 years from now?
In short, I think we’re going to see “more.” We will see more devices collecting more data and more types of data, and that data will be communicated over even more channels. The big shift with mobile applications versus web applications was that all of a sudden you had code running on an untrusted device talking over new networks. Over the next 10 years, the “IoT” will make this the rule rather than the exception.
Let’s look at the types of data being communicated. Right now, everyone can pretty much agree that credit card numbers are data that should be protected. If someone gets access to a credit card number, they can use those numbers to cause financial gain for themselves and that gain will have an adverse impact on others. However, the compromise of a credit card number has a relatively fleeting impact. Once a fraud is detected, the card number is immediately invalidated decreasing its value as the ability to use it for gain expires. However, health data represents a more nuanced scenario. If a malicious user has access to an individual’s HIV status, that may or may not be something that can be exploited for financial gain, but that status information – at least a status of “positive” – is not something anyone has the ability to change so the impact of the breach is not reversible. As the IoT marches along and connects more devices, there will be a lot more data communicated and poor system design and construction will leave this data open to compromise.
Also as more data becomes available, I think we will see a lot more emphasis by attackers looking to capitalize on collecting data from multiple sources. One impact of the Snowden leaks has been an increased sensitivity to the collection of metadata – raising concerns about the correlation of multiple data points to draw conclusions. With the proliferation of connected devices and the introduction of new types of sensors, this opens the door to compromises whose impact may not be immediately obvious. As we have seen, just getting organizations to implement data classification based on how individual classes of data should be treated has been difficult enough. It will be an order of magnitude more difficult to get organizations to make meaningful progress toward addressing risks stemming from metadata correlation.