As we all know from the Target data breach fiasco, a security breach can have adverse effect on the company’s reputation and client base. Not to mention the exorbitant costs that could be incurred to deal with a security breach once it happens (Target ended up paying a staggering 252 million dollars to deal with the data security break; source). If there is one thing we learned from the Target disaster is how important it is for any company to follow mobile app (or web) security best practices.
The mobile world is prone to security vulnerabilities at every single layer: network, hardware, operating system, and application. At the highest level, any company that has a mobile app presence can be exposed to either malicious functionalities or architecture / business logic vulnerabilities that could be exploited. In addition, from a security point of view, our mobile apps run in an incredibly hostile environment. The app may be under constant attack and time is on the attackers’ side.
Since they were released, the Open Web Application Security Project (OWASP) recommendations for mobile app security have become the norm as the standard guidelines for building and releasing mobile apps that are safe and secure for both customers and enterprises. As such, in this article, I will briefly go over the Top Ten Mobile Risks as defined by OWASP by explaining the security issues, providing examples of security violations and highlighting strategies to mitigate the risks.
Note that we will go over these mobile specific security issues in the same order as laid out by OWASP which is based on the frequency/criticality of these risks in both the iOS and Android ecosystems as of 2016. These issues are platform agnostic and focus on areas of risk than on specific app vulnerabilities.
M1: Weak Server Side Controls
Ironically, the most prevalent security risk currently experienced by mobile applications has nothing to do with the app itself or the ecosystem on which it is built. Or, as OWASP describes it, weak server controls cover “almost everything that a mobile application can do badly that does not take place on the phone.” (source). The most common reason why applications are actually hacked is because backend APIs and platforms are not secure.
The way hackers exploit this weakness is by sending inputs and data through your fields inside the app in an attempt to break into your server. This means that from a strategic point of view every time your application actually sends data to your server you need to have checks and balances at the server side that will automatically check and sanitize the information being passed to the database.
This is such a common issue that OWASP has come up with twenty recommendations and created two top ten projects which you can reference on how to secure the backend serving your application. They are named OWASP Web Top Ten and Cloud Top Ten projects.
M2: Insecure Data Storage
In simplest terms, developers sometimes store information on the client side (the customer’s phone) assuming the customer won’t be able to access that information.
What also has caught developers off guard is that when phones are stolen they often get into the hands of people looking to steal information that they can use to defraud users. And if you store that info on the client side then it becomes available for third parties
Some of the data previously stolen because mobile apps implemented poor security measures include passwords and credit card tokens, cookies, personal information (address, social security number, full name), credit cards.
Lastly, most of the people who sell their phones on online marketplaces like Ebay rarely bother to sanitize their devices (return them to factory settings and wiping the smartphones clean of apps and data). That means the new buyers often don’t always get just the second hand phone in the mail but sometimes the unexpected gift of some other person’s personal data.
OWASP has reported seeing data stored insecurely in XML data files, cookies stores, SD Card or Log files.
M3 Insufficient Transport Layer Protection
Most applications are built in such a way that information is exchanged between the application and the back end servers (duh) in a client-server relationship. This is how data travels across systems:
When developers cut corners and do not encrypt data correctly prior to transmission from the device, as this information travels across the network and to the server, skilled hackers can easily access sensitive data thought to be kept confidential. An example of this issue would be if while using my mobile banking app a hacker could intercept my social security number entered for identity verification because the information was not properly encrypted.
As OWASP tested hundreds of applications, they found out that many applications do not even use the most rudimentary encryption when they transmit data; or, when they do use it, data is at best weakly encrypted. The impact on not encrypting data correctly is that hackers can either steal confidential data or tamper with data in transit. The best way to avoid this issue is by encrypting all data leaving the customer’s device especially data that is carried over wi-fi and carrier networks.
M4 Unintended Data Leakage
Unintended data leakages refer to Operating System (iOS vs Android) specific issues that can cause information leakages. Some of the common examples are personal identifiable information stored in logging software, data points sent to third party software (think of an ad capturing and sending the GPS location on a user), siphoning data to temp directories on the OS or keystroke logging. The best way to prevent this is with the proper software development process. Specifically, peer reviews on the code.
In my own experience I’ve had to deal with a fire drill of this nature when a mobile app I worked on accidentally started collecting credit card information and adding them to the performance monitoring logs collected from the app. Of course, none of the developers consciously tried to collect data from our users but once the performance logs were launched to production a mistake was mad which resulted in personal information being stored.
The obvious tips on how to deal with this is to never log credentials on system logs. Another countermeasure I’ve seen recently with every banking app I use is to not allow me to take a screenshot inside the app which shows personal information about my account. Additionally, third party libraries used on the app should be carefully analyzed before being used to ensure the type of data they collect does not contain any information that could lead to privacy violations. In my example above, what we failed to do was carefully debug the app before release to ensure that files we added didn’t accidentally start collecting personal information from the user.
M5 Poor Authorization and Authentication
The problem statement is simple: every mobile app’s back end server needs to ensure that the users trying to access the app is exactly who they claim to be. (source) Imagine if a mobile app offered the ability to store a password in perpetuity, especially on the client side, and the phone was stolen. Someone else can use your phone and make money transfers to a bank account of their choosing.
At its core, this is probably the most common problem impacting the largest majority of applications. Once a user has authenticated for the first time with the backend, the app assumes that since the user logged in on a trusted device (their personal device), they never need to do it again. And that’s where this vulnerability comes into place especially when hackers can spoof the session id and then authenticate as any users they want to a specific application. This issue appears to be especially prevalent on the Android side. (source)
One very recent example of this type of vulnerability I noticed was with the newly redesigned PayPal application. Whereas PayPal uses two level authentication (device ID and PIN), it prompts users to reuse the PIN number set up for the phone to login into PayPal. Whereas it is certainly convenient for me as a user, from a security point of view, PayPal’s two level authentication has been reduced it to one.
M6 Broken Cryptography
If I reverse engineer an app (and this is a common approach hackers take), there shouldn’t be anything in the code that will allow a hacker to find encryptions keys that will allow them to hijack either a client’s app or the back-end server. Embedded keys and passwords within an app is all too common and incredibly dangerous. “Security by obscurity” is not security. It has been reported again and again (source) that mobile app developers often use little to no encryption or simple obfuscation which are improper methods to secure data.
The most common example of broken cryptography is when developers – in an effort to complete a project in a short period of time – adds hard coded keys in the course code which can then be exploited by hackers reverse engineering an app. Cryptography is generally very difficult to implement so people should use best practices and industry standard cryptographic algorithms.
OWASP also reports that the creation and use of custom encryption protocols is a practice that is prone to creating application level vulnerabilities. For more information on this topic you can read this in-depth article. (source)
M7 Client Side Injection
Client side injection refers to the vulnerability through which apps allow various inputs without input validations. If a hacker is able to detect a lack of validation on the app or the server side they can force “a context switch and the framework reinterprets the data as executable code” according to OWASP. (source).
The best example of this type of vulnerability is from a friend of mine who is a hacker. For over six months he played a popular game which allowed for in app purchases that would give him extra powers to advance to the next level. Since he’s a geek and he was annoyed with the app’s performance he reverse engineered the app trying to figure out why the app’s performance was incredibly poor (or at least that as the reason he told me). In the process, he found a vulnerability in the code of the mobile game which allowed him to load a simple text based attack to release powers to himself without paying for them.
Whereas this is a fairly harmless attack (only the app’s creators lost money in the process), imagine the type of damage that could be done when a user can simply change the logic of an app through his inputs. Despite its common nature, this mobile vulnerability is actually quite easy to address. This article explains the fix very eloquently: “identify the sources of input and validate that user/application supplied data is being subject to input validation, disallowing code injection.” (source)
M8 Security Decisions via Untrusted Inputs
If Amazon’s website were not secure, you could get free shipping by hacking into their app and identifying yourself as a prime member even if you did not pay the $99.99 annual membership fee. That’s the gist of this vulnerability. More broadly, developers add various permission levels into the same code base. So depending on the user type, some people see more functionality, others see less. If a hacker is good enough, he or she can intercept the web service call made to properly identify the user permission and tamper with this parameter.
Given the fact that this is the eight most popular vulnerability issue with mobile apps today, it would be safe to assume that there are lots of hackers out there who are enjoying app functionalities that are reserved for paying customers without paying a single dime.
M9 Improper Session Handling
As most people know or suspect, mobile apps use session cookies to allow for an uninterrupted use of an application. In other words, when you authenticate, most apps send you a session cookie to your mobile app. Now you can return to the app as you please without having to re-authenticate. The web services send the session cookie to the mobile app. Cookies allow mobile apps to use web services without having to login again. This can all happen behind the scene if the app securely stored the user’s logon credentials. There are a couple of ways cookie based sessions are not dealt with correctly.
First, and the most dangerous, is when the session cookie is not encrypted so that a hacker can intercept it during a handshake between the app and the backend server. This would allow the hacker to impersonate the user and login to the server without submitting a token to the backend server. This vulnerability can lead to fraud and information theft (social security numbers and other personal identifiable information).
Second, this developer (source) mentions that another common improper session handling is when a user attempts to logout of an app but the server does not sever the session cookie.
Both scenarios are pretty easy to avoid by setting session timeout parameters on the server side, enabling secure flags at the cookie level to avoid interception of the cookie by hackers and by making that sessions are stopped at the server side when a user logs out of the application. And if you want to go the extra mile, you can put a protocol in place that can revoke a cookie token if a user reports a phone lost or stolen. You can read more about this topic here)
M10 Lack of Binary Protections
Last but not least is the issue of binary protections. We talked about my friend who reverse engineered an app and found a way to inject code that allowed him to get paid benefits for free. Binary protections are put in place with the expectation that someone will try to reverse engineer an app in order to make it perform functions other than the expected ones.
Through code obfuscation, developers can slow down users from reverse engineering their apps but not entirely eliminate the risk. The biggest threat of a lack of binary protection is that it allows the hacker to be exposed to the intellectual property of the app and even certain sensitive business logic that can be leveraged against the company that released the original app.
Mobile App Security Vulnerabilities and Cyber Attacks are getting worse
Whereas eight years ago when mobile became a “thing” companies were more worried about the rush to market than security issues, nowadays the evidence that app security must become a priority for any company is clear. According to one report, 100% of the top paid Android apps have been hacked along with 56% of the top iOS apps. Similarly, 73% of the top free Android apps have been hacked and 53% of the top free iOS apps faced the same predicament. (source). In 2015, there were an estimated 16 million devices infected by malicious software stealing personal identifiable information from users and spying on unsuspecting users. (source). To make things worse, 11 % of all banking apps in the world (40,000 out of 350,000) contained malware or suspicious binaries in their code (source)
And things are only getting worse. A 2016 Security report from McAfee shows that in the last 3 years, the number of mobile malware attacks has increased by 700% from 200,000 new attacks per quarter in 2013 to more than 1,6 million new attacks last quarter alone.
And to really make things even worse, United States is the second highest ranked country in the world in terms of security vulnerabilities / malware attacks on mobile devices, only outranked by India.
These statistics show a dire picture of the state of vulnerability of our mobile devices and applications. In addition, there is clearly a significant negative financial impact for companies experiencing security breaches. A 2015 report from IBM on the “Cost of Data Breach study” shows that the average cost per incident is hovering around 3.8 million dollars for large enterprises, a 23% increase from 2013. Source
However, a 2016 report by ARXAN Technologies Inc. shows that 87% of mobile executives believe their mobile apps are secure. Is that the reality? The same report shows it is not. Out of 126 mobile apps monitored by ARXAN for the study in the US, UK, Germany and Japan, a staggering 90% of the apps failed to pass the test for at least 2 of the 10 Mobile Risks.
The question is how should companies tackle the increasingly common security threats that can plague their mobile applications? At a minimum, every company should follow the principles, methodologies and security tips put in place by the Open Web Application Security Project (OWASP) – the online community that has defined the standards for web and mobile application security. A 2015 IBM report entitled “The State of Mobile Insecurity” shows that 40% of IT Departments interviewed for the study stated that their organizations closely monitor the Top Ten Mobile Security Risks defined by OWASP. (Source).
However, the same report shows that companies are finding it increasingly difficult to closely monitor and test their mobile apps for each of these security vulnerabilities. The graph below compares the OWASP security threats detected by ARXAN for all the apps tested (with percentage of apps that failed to pass the test) and the IBM survey showing the difficulty companies have in adhering to these security practices.
Summary Top 10 – Mobile App Security Best Practices
As we can see from this list of issues, there are lots of ways a company can be targeted by hackers attempting to exploit weaknesses in how the application is built. Some are certainly more dangerous than others but any security strategy should be aligned, as much as possible with these vulnerabilities. We recognize that the particularities of your business can open us the possibility that there are other risks you’re exposed to that are not covered here. But as a general rule, establishing security processes that will cover these ten vulnerabilities will be a great start.
