Three-Quarters of Enterprise Applications Have at Least One Vulnerability

Security firm Veracode has released its annual report on the state of software security and it paints a bleak picture: 77 percent of enterprise applications assessed for the first time had at least one vulnerability and 88 percent of Java applications had at least one vulnerability inherited from a third-party open-source component.

The report’s findings strengthen what other researchers have warned over the past month: Vulnerability management and patching failures are common in enterprise environments and more data breaches like the one at Equifax, which resulted from a flaw left unpatched in Apache Struts, could happen at any time.

Veracode’s report is based on the results of some 400,000 security assessments performed over 12 months—from April 2016 to March 2017—on applications belonging to more than 1,400 companies.

The most prevalent type of vulnerability identified was information leakage, affecting 66 percent of the scanned applications. This was followed by cryptographic weaknesses, code quality issues, CRLF injection, directory traversal, insecure credentials management, cross-site scripting, insufficient input validation, SQL injection and insecure encapsulation or deserialization.

By comparing how the scanned applications improved between scans, Veracode found that on average developers are fixing only around 19 percent of vulnerabilities. The fix rate was somewhat higher for high-risk and critical flaws, at 37 percent.

“When you look at the time it took to close flaws by severity, the highest vulnerabilities were not necessarily closed the most quickly,” the company said in the report. “Very high severity flaws tended to take the longest to close, with 62 percent of closed very high severity flaws taking longer than 90 days to close, 72 percent taking longer than 46 days to close, and 76 percent taking longer than 30 days to close.”

The conclusion is that only 14 percent of very high severity flaws are closed in 30 days or less, which is concerning since the typical patching window that companies have between when vulnerabilities are publicly disclosed and when they start being exploited in real-world attacks, is much smaller than that.

For example, the researchers who found a critical deserialization vulnerability in the Apache Struts REST plug-in last month intentionally held back from publishing proof-of-concept exploit code to give users sufficient time to deploy the available patch. The strategy didn’t really work and by the next day other people figured out the flaw and contributed an exploit for it to the Metasploit framework. A day after that researchers from Cisco Talos began seeing attacks in the wild targeting the vulnerability.

When it comes to Veracode’s findings regarding Java-based applications, not only did 88 percent of them had at least one component-based vulnerability, but 53 percent were using versions of Apache Commons Collections that were vulnerable to a critical and widely publicized deserialization flaw patched in 2015.

In the weeks following the March 2016 attacks that targeted the Struts flaw behind the Equifax breach, Veracode’s scans showed that 68 percent of Java applications were using a vulnerable version of the framework.

“Development teams aren’t going to stop using components–nor should they,” said Chris Wysopal, the CTO of Veracode. “But when an exploit becomes available, time is of the essence.”

“We’ve now seen quite a few breaches as a result of vulnerable components and unless companies start taking this threat more seriously, and using tools to monitor component usage, I predict the problem will intensify,” he said.

But developers are not the only ones failing to keep track of flaws in the components they use. Some IT operations teams are also falling behind on patches.

This year the Veracode team decided to also test the web servers where their customers’ internet-facing applications were running. They found that 19 percent of publicly accessible apps were hosted on web server versions released over a decade ago and that 25 percent of them were running on servers that had at least one known vulnerability with a CVSS score of 6 or higher.

“Additionally, over a quarter of all sites responded with some sort of redirect, potentially indicating the use of shadow IT or sloppy IT practices,” the Veracode team said.

Attackers Scan Websites Looking for SSH Keys

WordPress security firm Wordfence has seen a recent spike in web scans for SSH keys. This could indicate an effort by attackers to take advantage of mistakes made by developers where they’ve accidentally uploaded their private SSH keys to their websites.

SSH keys are not only used for authenticating to servers over SSH, but also over SFTP (SSH File Transfer Protocol). There are multiple ways in which webmasters could expose their SSH keys, including by accidentally committing them source code repositories or production apps using a version control system such as Git.

Such mistakes might be common enough to convince some attackers that it’s worth the effort to search for publicly accessible SSH keys on web servers. After all, these keys could allow them to later compromise those servers or the websites they host. The scans observed by Wordfence searched for keys in various directory paths, including /root/.

“We think this increase of activity may indicate that an attacker is having some success scanning for private keys and has decided to increase their efforts,” the company’s researchers said in a blog post. “This may indicate a common bug or operational mistake that is being made by WordPress site owners, by which private keys are being accidentally made public.”

Lucian Constantin

Lucian has been covering computer security and the hacker culture for almost a decade, his work appearing in many technology publications including PCWorld, Computerworld, Network World, CIO, CSO, Forbes and The Inquirer. He has a bachelor’s degree in political science, but has been passionate about computers and cybersecurity from an early age. Before he chose a career in journalism, Lucian worked as a system and network administrator. He enjoys attending security conferences and delving into interesting research papers. You can reach him at lucian@constantinsecurity.com or @lconstantin on Twitter. For encrypted email, his PGP key’s fingerprint is: 7A66 4901 5CDA 844E 8C6D 04D5 2BB4 6332 FC52 6D42

lucian-constantin has 46 posts and counting.See all posts by lucian-constantin