The flaws in the container technology, CVE-2019-16276 and CVE-2019-11253, are simple to exploit.
A pair of bugs in the Kubernetes open-source cloud container software can be “highly dangerous” under some Kubernetes configurations, according to researchers.
The flaws, CVE-2019-16276 and CVE-2019-11253, have been patched in Kubernetes builds 1.14.8, 1.15.5 and 1.16.2.
Exploitation of the first issue, CVE-2019-16276, is “very simple,” according to Ariel Zelivansky and Aviv Sasson at Palo Alto Networks – and could allow an attacker to bypass authentication controls to access a container.
According to the bug report, the high-severity flaw, is a HTTP protocol violation in the Go language’s standard HTTP library, which is called net/http. The library is used for parsing HTTP requests.
This issue arises because in the HTTP specification, no whitespace is allowed in the request headers. The Palo Alto researchers noted in a posting on Wednesday that “HTTP requests are comprised of a field-name, followed by a colon, then its value…no whitespace is allowed between the header’s field-name and colon….the net/http library interpreted headers with this whitespace the same as valid headers, in violation of the HTTP RFC.”
The real-world effect of the bug becomes clear when you consider that the Kubernetes API server can be used for authentication and access control – as Palo Alto researchers pointed out, it can be “configured to work with an Authenticating Proxy and identify users through request headers.”
Source: Palo Alto Networks
Thanks to the bug, the proxy could ignore invalid headers and forward them to the Go server anyway, which would interpret these headers as valid. So, attackers could exploit the bug to authenticate as any user by crafting an invalid header that would go through to the server.
Palo Alto provided an example: “An attacker may send the following request to the proxy: ‘X-Remote-User : admin.’ If the proxy is designed to filter X-Remote-User headers but doesn’t recognize the header because it’s invalid and forwards it to the Kubernetes API server [anyway], the attacker would successfully pass the API request with the roles of the ‘admin’ user.”
Those using Kubernetes with an authenticating proxy should update to Go 1.12.10, which patches the issue, as soon as possible, as well as upgrading their Kubernetes builds, the researchers advised.
The second vulnerability, CVE-2019-11253, renders the Kubernetes API server vulnerable to a denial-of-service attack, according to the bug report. The attack can be aimed at the YAML/JSON parsing function with a method called “YAML/JSON bombing,” according to Zelivansky and Sasson, who rank the bug as high-severity.
YAML and JSON are a data-serialization languages commonly used for configuration files and in applications where data is being stored or transmitted. The idea behind YAML/JSON bombing is to crash the YAML parser in the Kubernetes API server by exponentially loading it with references, which authorized users can do by sending high volumes of malicious YAML or JSON payloads.
“Although it may be brought up depending on its restart policy and restart limit, the attacker may abuse the attack and deliver it continuously,” the researchers explained. “We recommend reviewing each role given to users, pods or anonymous users to determine if it is required, especially if it allows sending POST requests with a YAML file.”
Zelivansky and Sasson noted that this particular bug actually resides in the YAML parser library itself, which is a third-party piece of code incorporated into Kubernetes.
“Fortunately, another patch was written to resolve this problem at the go-yaml library level, preventing this attack in other projects that rely on its code,” they noted.
Affected users should upgrade to prevent attack, particularly given that cloud container technologies, which have become fixtures in much of today’s cloud infrastructure, are increasingly on cybercriminals’ radar. Earlier this week for instance, the “Graboid” worm was found infecting more than 2,000 unsecured Docker Engine (Community Edition) hosts, looking to mine the Monero cryptocurrency.
This isn’t the first flaw found in Kubernetes – last year a critical privilege-escalation vulnerability (CVE-2018-1002105) was uncovered that could allow an attacker unfettered, remote access for stealing data or crashing production applications.
Connor Gilbert, senior product manager at StackRox, told Threatpost that the discovery of more vulnerabilities underscores the need to pay particular attention to securing this threat surface.
“When you run containers, you absolutely must secure your control plane API surface,” he said. “Docker, Kubernetes, and similar tools are extraordinarily powerful, so it is critical to secure their API servers. Recent vulnerabilities in Kubernetes highlight just how important it is to have a multi-layered security approach, including authentication, authorization, network firewalls and ongoing monitoring.”
It’s also wise to remember that containers make it tough for legacy security systems to peer inside to scan for malicious activity, according to James Condon, director of research at Lacework.
“When it comes to containers, traditional endpoint solutions may or may not flag malicious files and activity,” he told Threatpost. “This could be due to the container’s isolated file system or that the malicious files may appear clean when code functionality is split across multiple files. Therefore, it is important to scan images pre-deploy, only use images you trust, utilize a runtime solution that has proper container visibility, and implement network security monitoring.