Cloud related vulnerabilities patched by IBM and Apache
Apache and IBM patched a critical vulnerability that allows hackers to replace a company's serverless code with their own malicious code. The vulnerability left open a hole in IBM's serverless Cloud Functions platform, exposing customer data. Once the malicious code is injected, the bad code could be used in extracting confidential customer data such as passwords or credit-card numbers, modifying or deleting data, mining cryptocurrencies or launching a DDoS attack.
The vulnerability was found in Apache OpenWhisk, the open-source serverless platform that IBM uses to run cloud functions. IBM has patched the issue, but implementations at other vendors could also be flawed. Serverless computing is a cloud computing model where cloud providers dynamically allocate machine resources. It comes from the fact that the server management and capacity planning decisions are completely hidden from the developer or operator. Most of the underlying platform is hidden from the user and it is good thing from a security point of view since it means no need for OS patching. Security teams will now need to shift their focus to permissions, application libraries as well as their dependencies and data security. Any information disclosure related to this type of vulnerability can be secured to by limiting the permissions granted to the compromised functions.
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. If the serverless function is insecure, it could be hijacked by a hacker to remotely execute malicious code, the hacker can overwrite the source code of a vulnerable function which is being executed in a runtime container. All a hacker has to do is to be able to force a function to launch an HTTP request to the localhost of the container over port 8080. According to a whitepaper, ths can be done in may ways including exploiting a remote-code execution vulnerability, exploiting a serverside Node.JS scripting flaw, exploiting unsafe use of eval() in different relevant runtime languages or exploiting an SSRF vulnerability in the action's logic. After doing so, it is possible to modify 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 disappears. It does this inside a "container" like Docker, though as a user of serverless, you don't see the container or all the infrastructure. Sometimes, the system will keep the container around for a few seconds if it predicts that it will be going to run the same function again, for speed and convenience. In that case, the serverless function becomes the hacked function running the malicious code, and it keeps the container alive so that the malicious code can keep running. Once a hacker manages to overwrite or modify the code, the modified code can then perform other actions, such as accessing sensitive data during subsequent executions within that function. This hack is in preparation for more attacks. Once the malicious code is running, it has the permissions of the original serverless code. So when a real user comes and runs a function that uses their name, credit card and address, the malicious 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.
Apache has released a patch, and other users of Apache OpenWhisk should update to the latest version. Research efforts into serverless security discovered the critical vulnerability in an OpenWhisk runtime and reported it directly to the Apache OpenWhisk team. OpenWhisk is a new project that is under active development. It isn't unexpected that an issues like this was discovered. These types of discoveries are essential to the development of open-source projects. Fortunately, the vulnerability was responsibly disclosed and quickly fixed by OpenWhisk contributors. Anyone considering using a serverless architecture should understand and accept the security concerns involved. Traditional controls such as an IDS/IPS may not be applicable to such an architecture.