For six weeks in early 2015, AFNetworking, a popular networking library featured in about 100,000 mobile apps, had a serious flaw. The developers had inadvertently broken the digital certificate validation for Secure Sockets Layer (SSL) encryption, the foundation of communications security on the web. As a result, any mobile app using the library opened up its users to a simple man-in-the-middle attack: an attacker on the same network—in the same coffee shop or perhaps even on the same airplane—could decrypt and read the targeted traffic.
Although the vulnerability was discovered and patched in about six weeks, about 1,000 applications incorporated the vulnerable code and needed to be patched. Dan Cornell, chief technology officer of the secure software consultancy Denim Group, said that getting mobile developers to patch their software, distribute the patches, and then convince users to update their software is not a smooth process.
"If you want to release a new version of the web application, you can push code out to all your servers," Cornell says. "But if you want to update a mobile application, you have to make a new build, submit it to the app store, wait for app store to accept it, and then wait for users to update their device, which you have no control over."
The incident highlights why mobile app developers need to pay more attention to security, Cornell says.
When haste leads to mobile app security waste
The Denim Group is one of the companies gathering data on the mistakes mobile app developers make—mistakes that can give an attacker a way to compromise a user's mobile device. In an analysis of 61 mobile applications submitted by its clients, mainly in the financial industry, Denim Group found that all applications had at least one serious vulnerability, and some had more than 10.
The three main categories of software weaknesses were data leakage by the app, mistakes in implementing authentication, and database injection vulnerabilities on the backend servers supplying data to the mobile application.
These are not new vulnerabilities. When the rush to create mobile apps started, a new cadre of developers—many unseasoned—jumped into the developer game. As a result, common security mistakes have continued, says Daniel Miessler, head of security research for HP Fortify on Demand. "When the mobile boom started, the seasoned web developers who had gone to class and had to deal with bad security issues were not the ones, for the most part, becoming mobile developers," Miessler says.
In addition, the differences between mobile platforms and more traditional computer systems mean that coding and software architecture mistakes manifest themselves slightly differently on mobile platforms. Here are the top four:
1. Failing to properly encrypt
From failing to scramble password files to mistakes in dealing with digital certificates, encryption's complexity can make it difficult for developers to handle correctly. In its list of the top 10 mobile threats, application security firm Veracode includes four classes of coding mobile-app vulnerabilities, each with an aspect related to encryption (other threats are all from malicious or suspect applications). The vulnerabilities are sensitive data leakage, unsafe data storage, unsafe data transmission, and hardcoded passwords and keys.
"It is not easy to do encryption properly on a mobile device," says Theodora Titonis, vice president of mobile for Veracode. "Key management is difficult, for example, when you are looking at a mobile environment that requires a connection to a server to function."
Developers have to deal with encryption for data storage but for communications, requiring strictly secure key management without degrading the user experience. In addition, many developers wrong-headedly attempt to bake their own encryption functionality.
"A lot of it comes down to the value of the data being manipulated by these applications," says Denim Group's Cornell. "What code and data needs to exist on the device and what code and data is stored on the servers."
2. Trusting third-party libraries
To speed development and incorporate other developers' expertise into their own application, many programmers use third-party libraries. Yet including other developers' code creates a number of problems. Unwanted functionality is often included in the code library. In one case, HP Fortify analyzed an application that had been designed to connect to a single, secure server, but instead found it communicating with 13 different Internet addresses. To blame were third-party frameworks that were sending data to other servers.
In its rankings of unsafe functionality of mobile applications, mobile-application management firm Appthority found that more than three-quarters of paid apps on iOS and Android had risky behaviors. "A lot of times we see developers that don't know what is in their apps," says Domingo Guerra, president and founder of Appthority.
Another major problem with third-party libraries is that they add a new avenue for vulnerabilities. In the case of AFNetworking, for example, SourceDNA found that another SSL flaw in the library had propagated to more than 25,000 applications. Keeping track of the security fixes in every library included in a mobile application can be daunting.
Finally, many developers look to ad libraries to earn additional revenue from their application. But most ad libraries leak information about the user to the advertising network. Others are borderline malicious or allow a vector for attackers to get onto the mobile device, says Denim's Cornell.
"Ad networks are kind of scary," he said. "You are pulling a lot of arbitrary, weird content down."
3. Trusting communications
A major source of insecurity arises when developers design the server side of a mobile application to implicitly trust communications from the client and vice versa. On the server side, this class of vulnerabilities manifests itself as insecure web and mobile application programming interfaces, or APIs.
The security issue is a problem for the devices as well. When security firm FireEye analyzed more than seven million iOS and Android applications, the company found that nearly a third of Android apps used a way of displaying web pages that left the mobile app vulnerable to attack. The JavaScript-binding-over-HTTP vulnerability allowed attackers to hijack the traffic being sent to the mobile device and execute code on the device.
"In addition to what the app is doing, it is communicating with its backend," said Adrian Mettler, a development engineer on FireEye's mobile team. "The apps can place a lot of trust in the information they are getting from the server."
Correctly handling and checking certificates is another major issue. In the AFNetworking library, for example, the incorrect handling of SSL certificates in the more than 25,000 applications allowed an attacker to eavesdrop on the user's communications, as long as they had any valid certificate.
4. Lacking security processes
Another common problem for developers is the lack of a secure development lifecycle, which builds security testing and code review into development. Security focused development is extremely important for mobile devices, because of the delays baked into the development cycle for mobile applications—where code not only has to be written and compiled but also submitted to a third party for vetting.
Patch management and deployment is also extremely important and often overlooked, particularly when third-party frameworks and libraries make the process more complex. Many of the largest developers quickly update their software with new versions of third-party libraries, but of the more than 25,000 applications using a vulnerable version of the AFNetworking library, the majority still aren't updated.
"A lot of people still haven't patched, even now," SourceDNA's Lawson said. "When you look at the scan results you can see that they are still using the old library."
Most of the security problems plaguing mobile apps boil down to developers' lack of knowledge about the security impact of certain development decisions. The cure for the disease is to instill a culture of security into the programmers writing the code. Developers that fail to encrypt, blindly trust third-party libraries, lack an attacker mentality and do not build security into there development process will be the most likely to find their software under attack.
Keep learning
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed fast on the state of app sec testing with TechBeacon's Guide. Plus: Get Gartner's 2021 Magic Quadrant for AST.
Get a handle on the app sec tools landscape with TechBeacon's Guide to Application Security Tools 2021.
Download the free The Forrester Wave for Static Application Security Testing. Plus: Learn how a SAST-DAST combo can boost your security in this Webinar.
Understand the five reasons why API security needs access management.
Learn how to build an app sec strategy for the next decade, and spend a day in the life of an application security developer.
Build a modern app sec foundation with TechBeacon's Guide.
