A critical privilege-escalation vulnerability (CVE-2018-1002105) has been uncovered in the Kubernetes open-source container software, which is a fixture in much of today’s cloud infrastructure. It could allow an attacker unfettered, remote access for stealing data or crashing production applications.
It marks one of the first serious problems found in Kubernetes, and it’s a whopper, with a CVSS score of 9.8. A hacker can send specially crafted requests to establish a connection through the Kubernetes API server, where the issue exists, to any attached backend servers (such as aggregated API servers and “kubelets,” which are small building-block modules responsible for what’s running on any specific machine). Once that connection is established, there’s no check on the ability to send arbitrary requests directly to those backends, because the requests will be automatically authenticated with the Kubernetes API server’s TLS credentials used to set up the initial connection, according to the advisory issued on Monday.
The issue is particularly concerning thanks to the sheer scale of the vulnerable surface. Kubernetes is the de facto standard in Linux container orchestration; it makes it possible to orchestrate containerized applications together in the cloud, enabling composite services comprised of hundreds, or even thousands, of “simpler” services. These orchestrated applications are often easier to manage, more nimble and more straightforward to maintain than traditional applications. But, this architecture also means that with malicious access to one vulnerable API server, all of those sub-services are laid open for compromise.
Thus, an attacker can gain deep access to cloud infrastructure, to carry out any number of nefarious actions, including data heists, installing malware, espionage and recon, or changing up production workloads for sabotage purposes.
“The Kubernetes vulnerability is a huge deal, even more so when you think about its scale of exposure,” Sumo Logic CSO George Gerchow told us via email. “What makes Kubernetes great is its fundamental speed, orchestration, automation and scale. All of those qualities become an instant detriment when a security issue arises as they rapidly extend the reach of the attack.”
Kubernetes has issued updates to address the flaw (v1.10.11, v1.11.5 and v1.12.3); individual distros will need to issue their own updates. Red Hat has upgraded its OpenShift Container Platform (patched versions here); and users should visit the security tracker pages for Debian and SUSE distributions for up-to-date information on the availability of a Kubernetes patch on these platforms.
“We were surprised by its scope and the fact this wasn’t discovered earlier,” said Wei Lien Dang, vice president of products at StackRox, told Threatpost. “This vulnerability has existed in every version of Kubernetes since v1.0. But Kubernetes is complex software with a large code base, which can lead, to some extent, to various security issues. That the fix is so simple – just 37 lines of code – speaks to the maturity and high quality of the Kubernetes codebase. Our greatest concerns are that it is difficult to detect when this vulnerability is being exploited and that everyone using Kubernetes is potentially affected.”
The news comes as container security is just starting to pop onto the radar screen for most organizations. Even as companies move to embrace cloud deployments and containers, most organizations with such deployments don’t feel prepared to adequately secure cloud-native applications.
In a recent survey from StackRox, for instance, more than a third of organizations worry that their security strategies don’t adequately address container security. An additional 15 percent believe their strategies don’t take seriously enough the threat to containers and, specifically, Kubernetes deployments.
Gerchow noted, “Any well-versed security professional would expect [container flaws] to happen, as emerging technology is notoriously known to treat security as an afterthought. Looking at it from a bigger picture, this is another example of how development and security teams need to work together through DevSecOps to establish guardrails and best practices while maintaining agility. Most organizations lack visibility into the proper security and configuration of not just its containers, but the CI/CD pipeline as a whole.”
Andrew van der Stock, senior principal consultant at Synopsys, noted that, as in many tech segments, security has not necessarily kept up with technical innovation within the internet economy in general, with the API aspect of the vulnerability worth noting as well.
“APIs can be difficult to test by traditional security testing tools and approaches, and to a certain extent, the security industry has not kept up, primarily because most are not developers themselves,” he said via email. “As a whole, security industry needs to shift left, adopt the same tooling as developers, and write unit and integration tests that fully exercise APIs, particularly those that have the potential to alter the state of an application or extract bulk personal information.”
He added that given the pervasiveness of APIs in today’s enterprise IT infrastructure, securing them should be top-of-mind.
“APIs make the friction of doing business much less,” he said. “We expect to see continued explosive growth of APIs – modern responsive apps, mobile apps and B2B use cases are tremendously popular. However, whilst there are new risks to APIs not covered by previous applications, application security is near universal and still is incredibly relevant going into 2019. Securing APIs should be the focus of every organization that uses them.”
API flaws have been making headlines recently; just before Thanksgiving, for instance, vulnerabilities in the websites for U.S. Postal Service and Amazon showed up to remind us of the dangers of shopping season; both hinged on improper API use.
