Apache and IBM have patched a critical vulnerability that allows attackers to replace a company’s serverless code with their own malicious script.
Once running, the bad code could then be used for a range of nefarious tasks, including extracting confidential customer data such as passwords or credit-card numbers, modifying or deleting data, mining cryptocurrencies or launching a DDoS attack.
The vulnerability (seen in action in this video), originally discovered by researchers at PureSec, was found in Apache OpenWhisk, the open-source serverless platform that IBM uses to run cloud functions. IBM has patched the issue, but other implementations at other vendors could also be flawed.
Serverless computing is a cloud-computing execution model in which cloud providers dynamically allocate machine resources; the name comes from the fact that the actual server management and capacity-planning decisions are completely hidden from the developer or operator.
“With serverless, most of the underlying platform is obscured from the user and this is a major positive from a security perspective as it means no more OS patching,” said Matt Chiodi, vice president of cloud security at RedLock, via email. “However, security teams now need to shift their focus to permissions, application libraries (as well as their dependencies) and data security. Any type of information disclosure related to this type of vulnerability can be mitigated to a certain extent by limiting the permissions granted to the compromised function.”
Apache OpenWhisk executes serverless functions in response to events with rapid auto-scaling. It provides a programming model to create functions as cloud-native event handlers, and executes the functions automatically, inside runtime containers, as the events occur.
The PureSec threat research team demonstrated how, if the serverless function is itself insecure and could be hijacked by an attacker to remotely execute injected code, the attacker may overwrite the source code of a vulnerable function which is being executed in a runtime container.
An attacker first needs to be able to force a function to launch an HTTP request to the localhost of the container over port 8080 to be successful – which can be achieved in a multitude of ways. According to a whitepaper released Tuesday on the weakness, these include: exploiting a remote-code execution vulnerability in the action’s logic; exploiting a server-side Node.JS cross-site scripting flaw; exploiting unsafe use of eval() in different relevant runtime languages; or exploiting an SSRF vulnerability in the action’s logic.
From there, it’s possible to influence subsequent executions of the same function in the same container.
“Usually, a serverless function pops into existence, runs the code it needs to run, and then vanishes forever,” a PureSec spokesperson told Threatpost. “It does this inside a ‘container’ like (in this case) Docker, though as a user of serverless you don’t see the container or all the techie infrastructure stuff.”
PureSec added, “sometimes, the system will keep the container around for a few seconds if it’s going to run the same function again, for speed and convenience. In this case, the serverless function is the hacked function running the hacker’s code, and it keeps the container alive so that the hacked code can keep doing its thing.”
The upshot is that an attacker that manages to overwrite or modify the code of the serverless function can then perform further actions, such as accessing sensitive data during subsequent executions within that function.
“This attack is the vector for more attacks; once the attacker’s code is running, it has the permissions of the original serverless code,” the spokesperson said. “So when a real user comes and invokes a function that maybe uses their name, credit card and address, the hacked code could intercept and email it to someone. If a function is used to access user data from a database or file storage, then the hacked function could steal or modify it.”
This is the first publicly-disclosed vulnerability in a serverless platform (tracked as CVE-2018-11756 and CVE-2018-11757).
PureSec disclosed and notified both Apache and IBM privately. Apache has also released a patch, and other users of Apache OpenWhisk should update to the latest version immediately.
“As part of our continuous research efforts into serverless security, our team discovered this function mutability in an OpenWhisk runtime and upon verifying it, reported it directly to the Apache OpenWhisk team,” said Ory Segal, CTO and co-founder at PureSec, in a media statement. “We were extremely pleased and impressed with the promptness of the Apache OpenWhisk team, which took this issue very seriously.”
James Lerud, head of the behavioral research team at Verodin, said via email that those using serverless approaches should be aware of what they’re getting into.
“OpenWhisk is a fairly new project that is under active development; it doesn’t surprise me that an issue like this was discovered. These types of discoveries are essential to the healthy development of open-source projects. Fortunately, the vulnerability was responsibly disclosed by the Puresec Team and quickly fixed by OpenWhisk contributors. Anyone considering using a ‘serverless’ architecture should fully understand and accept the security concerns involved; many traditional controls such as an IDS/IPS may not be applicable to such an architecture.”
