How to expose flaws in custom-built mobile apps

As enterprises develop more custom applications -- many of them mobile apps as part of a mobile-first strategy -- in-house developers are increasingly at risk of unwittingly using open-source code rife with vulnerabilities.

Developing custom apps allows a business to differentiate itself from competitors by offering customers, whether internal users or consumers, a better mobile experience.

Thinkstock

Unlike traditional software development, mobile applications add layers of complexity, particularly when companies create server-side web APIs or client-side native rich clients. That's also true when integrating software across other applications and systems.

Not only can underlying weaknesses and vulnerabilities be carried over from the web application space, but there are new concerns about the secure storage of sensitive data at rest on a device.

"Subject matter expertise in mobile application design, development, and security is often more limited when compared with traditional application design, and it splinters further based on mobile platforms," said Michael Isbitski, a research director at Gartner.

Applications today are rarely coded from scratch, particularly when the software is created outside a company's development and operations units. Developers typically go to online libraries for open-source components -- chunks of code that act as building blocks -- to assemble custom mobile applications.

Vulnerabilities abound in free, open-source components

The problem is open-source code is not necessarily vetted and its use can expose corporations and their customers to vulnerabilities. That was the case with Heartbleed, a vulnerability discovered in the OpenSSL library in 2014.

Heartbleed had a widespread impact across not just apps but also operating systems (desktop and mobile), network equipment and embedded systems.

"It also still persists in some cases, which could be due to technical limitations on updating the relevant component or neglect on the part of admins," Isbitski said.

Other more recently published vulnerabilities include those in Apache Struts, an open-source web development framework for Java web applications and Node.js, a popular JavaScript run-time environment. If exploited, Isbitski said, the Node.js vulnerability could result in a denial of service (DoS) condition for the affected application.

"The issue here is that people roll the dice with what they find online all the time -- and when it happens in a business, the dicey software can find its way into supporting important corporate systems very quickly," said Sean Pike, program vice president of IDC's Security Products Group.

While DDoS attacks can be devastating to a business, other attacks can be flat-out life threatening. As more hospital networks and medical devices such as pace makers and embedded insulin dispensers are wirelessly connected, the ability to uncover and protect against vulnerabilities takes on grave importance.

Last month, the U.S. government's Health Care Industry Cybersecurity Task Force released a report on how to improve cybersecurity. The report recommended better  transparency in both medical device manufacturing and software development to mitigate security vulnerabilities.

The recommendation is especially timely given last month's reporting of 8,000 known security vulnerabilities across four pacemaker programming machines.

Whether commercial off-the-shelf software (COTS) or open-source components are less secure is still a point of contention among security experts.

Developers get open-source components from large online repositories typically organized by coding language: Java, Python, Ruby, for instance. And open-source code may be better scrutinized and vetted because of the fact it's open,  esulting in fewer issues for a completed application.

But development contributions  can sometimes be limited due to its "free" use or a lack of financial investment, Isbitski pointed out. COTS is closed and proprietary by design, which buys a level of obfuscation against attackers. But skilled attackers can find ways to reverse engineer commercial code to uncover weaknesses or vulnerabilities.

"A significant percentage of modern application development makes use of open-source components," Isbitski said. "Open-source re-use can save development cycles in creation of new software or hardware. It can also be a boon for secure coding, since developers can make use of standardized components where security and trusted functions are baked in."

Last year, IDC predicted application security would be a top concern for IT managers; while the issue is gaining interest, it has not become as prominent as the research organization thought.

"It hasn't materialized yet. Some of that, I think, is directly tied to IoT," Pike said. "I think more IoT failures because of bad code will increase the awareness."

Still, companies are clearly jumping on the mobile app development bandwagon as a way to improve business. The number of enterprises building custom mobile apps -- many of them simple apps designed to handle business processes -- rose significantly in 2016, according to Gartner's annual study of mobile app development platforms.

Too few vulnerability checks

In 2015, about 60% of organizations were engaged in mobile app development. Last year, that number jumped to about 73%, according to the study. One of the largest repositories of popular Java open-source code components, the Maven Central Repository, found 1-in-15 downloads had a known vulnerability last year.

"There probably aren't enough checks happening in software development today to understand what's being used and does it have a known vulnerability in it," said Derek Weeks, vice president and DevOps advocate for Sonatype, which manages the Maven Central Repository.

The repository stores two million, unique open-source Java components and serves roughly 10 million developers worldwide. Last year, Sonatype served 52 billion download requests from the repository, up sharply from 31 billion download requests in 2015.

"So there's a significant increase in consumption year over year of the component downloads," Weeks said. "There are only about 10 million Java developers on the planet, so when you're seeing billions upon billions of download requests, there's significant consumption. And, that extends into other languages as well. Python, has billions of downloads per year.

"It's not that consumption is bad; it's only when consumption of bad things is happening that we need to be more aware," Weeks added.

A software bill of materials

So how do you know if you're using bad components? One effort being pushed by software developers and other organizations is for the federal government to require a software bill of materials, similar to a list of ingredients in pre-packaged foods. Instead of food ingredients, a software bill of materials would list all software components.

The bill of materials typically includes a list any known vulnerabilities that come in the form of Common Vulnerabilities and Exposure identifications as well as the pertinent open-source licenses.

"If you create list of those [flaws], then you can assess those for known security vulnerabilities," Weeks said. "There are tools on the market, both commercial and open-source, that allow you to analyze your applications to identify the components in them and tell you if they have any known security vulnerabilities in them. If they do, then you have to determine if you're going to fix those before shipping them to customers, or make them aware of a known security vulnerability."

Sonatype

Along with managing the Maven Central Repository, Sonatype offers an application health check service that allows organizations to see what components are in an open-source app and check for known vulnerabilities. The free service is similar to the Open Web Application Security Project (OWASP).

A variety of software composition analysis (SCA) tools are offered by Black Duck Software, Flexera Software, Synopsys, Veracode and WhiteSource Software. The SCA tools commonly use the federal government's National Vulnerability Database as a data source for exposing the known vulnerabilities.

"SCA can be used as a form of supply chain attestation, so a user or purchaser of software can verify what is contained within," Isbitski said. "It also has use within early stages of a software development life cycle, helping to identify vulnerable components, as a developer might introduce a vulnerable open-source library into the codebase without realizing. Some SCA tools will recommend alternative components or upgraded versions where the vulnerabilities have been corrected."

Other free, open-source tools for scanning and detecting known vulnerabilities include the OWASP Dependency Check, retire.js, and the Node Security Platform Live. Retire.js and Node Security Platform Live are focused on JavaScript or Node.js component analysis.

How a bill of materials works

A traditional application has about 100 open-source components. Even if those 100 components are deemed safe today, vulnerabilities may be discovered in the future.

Among those pushing for a software bill of materials is the Health Care Industry Cybersecurity Task Force; it recommended that healthcare organizations create a software inventory of open source and proprietary components used in apps to identify any security, licensing and quality problems.

"Having a bill of materials is key for organizations to manage their assets because they must first understand what they have on their systems before determining whether these technologies are impacted by a given threat or vulnerability," the Task Force  report said.

More transparency enables healthcare providers to assess the risk of medical devices on their networks, confirm that components are assessed against the same cybersecurity baseline requirements as the medical device, and implement mitigation strategies when patches are not available.

The report notes that while this practice is important, it has not yet been widely adopted.

"The pace of most open-source software development is rapid, with features being updated, added or removed regularly," Isbitski said. "There is already a large range of open-source software at a developer's disposal, which gets compounded as components are branched or forked. This results in a huge spectrum of components and versions to keep tabs on. Without the aid of tooling, it can be extremely difficult to validate open-source components upfront and over time as issues are uncovered."