Posted by Ashley Stone on June 9, 2017
Software vulnerabilities exist despite the industry’s best efforts. It doesn’t matter if it is open source or custom code. It’s software, and it is going to have vulnerabilities. Knowing this, security professionals want to keep track of new vulnerabilities. There are a variety of ways to do so, but the most reliable methods will include feeds or reports from reputable sources.
When consuming these feeds, it’s important to prioritize issues. You probably don’t want to act on every vulnerability, even if you had the resources to do so. The different risk profiles for different classes of applications will dictate which you address first, and which you elect to ignore as having acceptable risk.
A popular method for prioritizing vulnerabilities uses the Common Vulnerability Scoring System (CVSS); a standardized scoring process devised by NIST. A CVSS score is assigned to each vulnerability in the National Vulnerability Database, and the scoring tool is publicly available so organisations can score issues as well. It’s a useful way to triage security patching, understand whether the vector of attack is even applicable, and prioritize work on projects to limit disruption. VULDB, who describe themselves as the “number 1 vulnerability database worldwide” published 8,322 vulnerabilities in 2016, more than twice as many as NVD. Roughly 3.5% of these were determined to be high risk per the CVSS score.
So, what exactly makes a high risk vulnerability? The Heartbleed vulnerability in OpenSSL, to take a well-known example, could be used by attackers to steal private information, leading companies like Amazon, Reddit and Github to ask users to update their passwords and/or encryption certificates for affected services. This had massive knock-on effects, requiring websites to regenerate SSL certificates. This sounds like a high risk to me.
Netcraft estimated over 500,000 SSL certificates were affected along with embedded hardware devices, such as Juniper routers, which are used in vital Internet infrastructure. Despite this, Heartbleed was scored at only a 5.0 by NVD. This is likely because the level of compromised confidentiality was limited to what was in the component’s memory at the time, and because an attacker couldn’t choose which details to extract. This vulnerability alone would not allow an attacker to directly compromise the entire component, execute arbitrary code, or affect its availability. A high risk vulnerability on the other hand is typically capable of doing all of these directly.
Our story begins with Ninka, a small, command line, open-source tool for performing license identification in source code. Originally conceived through a research project, Ninka is intended to be used in an automated fashion, scanning with no user interaction and generating numerous plain text files for manual inspection by the user. It should be noted that this tool does not run as a web application or network service. A series of vulnerability reports and fixes were posted online with varying information regarding the tool, which was picked up by Black Duck Security Research. Then we began our investigation.
According to the NVD, the vulnerability (CVE-2017-7239) may allow attackers to obtain sensitive information, manipulate scan results, or cause denial of service through a crafted filename. The CVSS scoring from NVD was 9.8, or critical, and categorized the vulnerability as a data processing error (a class of weaknesses that includes improper input validation and improper encoding or escaping of output). This indicates that the vulnerability can be exploited over the network, a fact which appears to have been sourced from Security Focus. Meanwhile on VULDB the vulnerability has been scored as medium, but the exploit is described to be a privilege escalation. The CVSS scoring indicates the attack vector is from an adjacent network with:
This is unusual because once privilege escalation has been obtained, it usually results in total compromise. These reports failed to sufficiently describe exactly what the issue was, lacked sufficient technical details and conflicted with one another..
These issues prompted the Black Duck Security Research Team look more closely at the vulnerability. The CVSS scoring provided by organisations did not match up to how the tool is used or interacted with, or the types of vulnerabilities being described.
We discovered that Ninka becomes vulnerable to command injection (where commands to the system can be embedded) with the use of a specially crafted filename, making it possible to execute scripted payloads running under the full privileges of the user running the tool. The vulnerable code resides in a method used to execute additional scripts to perform source-code analysis. Filenames are not correctly escaped, and therefore it is possible to execute commands.
Command injection is a very powerful tool for the attacker. An attacker can leverage these conditions within Ninka to execute system commands. Hidden scripts can be embedded in source files that execute command injections when scanned. These command injections could then execute a script interpreter like Bash or Perl to run a payload that could be stored either locally or remotely. This payload could then steal or modify data depending on access controls and the privileges of the executing user. Privilege escalation through further exploitation is also possible given the increased attack surface available to the attacker.
Exploitation is also further facilitated by the fact that there are many locations and methods to hide content. An attacker could hide both command injections and payloads inside files marked as hidden on the file system (a user would not typically see these files). Furthermore, when automating the processing of sources to be scanned, these tools typically do not ignore hidden files by default and offer a practical, stealthy attack vector.
Our CVSS scoring, which would be rated as ‘high’ on VULDB or ‘critical’ on NVD (base scores), shows the attack vector is actually local. The confidentiality, integrity and availability of Ninka could be completely affected. The fact that this vulnerability is capable of going beyond the component meant our vulnerability scoring also reflected the changed scope of exploitation.
In short, someone could produce a malicious set of files to be scanned. The malicious files would be capable of executing code that could fully compromise not only Ninka, but everything else the user running the tool has access to. To compare this to Heartbleed, an attacker would not only be able to compromise confidential information, but the confidential information of their choosing. They might even install a Remote Access Tool (RAT) and further compromise the system. With the use of a RAT, compromising other connected systems may be possible as opportunities arise for the attacker.
Accurately classifying a vulnerability is important, because different classes of vulnerabilities result in different technical impacts. Understanding whether a particular vulnerability may be used in a DDoS attack versus an attack that may allow privilege escalation or the ability to read data will help determine which vulnerabilities are most urgent for each application in your inventory.
Many companies depend on accurate scoring of vulnerabilities to understand whether the vector of attack is even feasible, prioritize work on projects and limit disruption to be effective. Our examination of the Ninka vulnerability begs the question: how many of those published vulnerabilities are scored correctly?
Get the latest Software Integrity news, thought leadership, and more.