Apache, IBM Patch Critical Cloud Vulnerability

top feature image

Apache, IBM Patch Critical Cloud Vulnerability

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.

Apache OpenWhisk executes these 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.”

Leave a Reply

Your email address will not be published. Required fields are marked *