How to secure serverless apps and how they are hacked

Serverless applications, also known as cloud functions, perform very specific tasks and exist for mere seconds. This makes them more efficient when it comes to getting the most out of your cloud environments and keeping costs down.

However, as with any new technologies, the security implications of this new paradigm are yet to be fully explored or understood. “Many folks still think that serverless is magic and that someone else is responsible for securing their code,” says Ory Segal, CTO and co-founder of PureSec. “That’s far from the truth.” But it is possible to harden serverless applications and apply security best practices to reduce the likelihood of compromise.

How to hack serverless functions

The servers still exist, of course, but the functions are abstracted and aren’t tied to any one piece of infrastructure. The fact that a server contains your function’s source code and at least one other hostd the temporary containers executing your functions means security should be taken seriously.

“Serverless functions are simply pieces of code which are executed by the cloud provider when a certain event triggers,” says Segal. “As such, they can suffer from application layer vulnerabilities just like any other software.”

A study into the most common security risks in serverless architecture found that one in five serverless applications on GitHub contain critical security vulnerabilities. So far, no major attacks where serverless functions have been compromised have been reported. However, there is strong interest within the security research community, some of whom think targeted attacks are happening but merely going under the radar.

“People are exploiting serverless functions in the wild, especially in the open-source space where it’s really easy to see where the vulnerabilities are in the code,” Mozilla security engineer Andrew Krug said in a Black Hat presentation earlier this year.

In July 2018, PureSec revealed a vulnerability in Apache Openwhisk, the open-source serverless computing platform that underpins IBM’s Cloud Functions offering. The vulnerability allowed an attacker to overwrite the source code and change function logic. The Apache Foundation has issued a patch. 

PureSec also recently demonstrated an attack that took advantage of auto-scaling in serverless to turn a single vulnerable function in to a massive cryptocurrency mining farm. During tests the company was able to get the mining functions to scale up to the platform’s limit of concurrence. Such an attack could potentially lead to massive fees come the end of the billing period; the report estimates as much as $120,000 per month due to the extra computing resources cryptocurrency mining consumes at the victim’s expense.

“The most common attack scenario is event-data injection, in which an attacker injects malicious data, which is then used by the function during the event trigger,” says PureSec’s Segal. “Such malicious data can abuse application layer vulnerabilities such as SQL injection, command injection, local file inclusion, data leakage and so forth. Such attacks will manipulate the business logic of the function.”

During July’s OWASP AppSec conference in London, Checkmarx’s Shimi Eshkenazi and Amit Ashbel demonstrated a code injection attack that could “cross-contaminate” functions in the same application, overcoming persistence challenges. During the presentation, the team showed a demo where they were able to access function code via a code injection, download that function code, modify it, and then infect other functions through the original viral function.

“You’re going to get cross-contamination that sits in an endless loop that will inject all other functions and get out of control,” said Eshkenazi. “The only way to get out of this situation would be to restore all the functions to the original source, but all of them, without forgetting any one.” 

What are the security benefits of serverless computing?

Despite the potential for compromise, there are some security benefits to serverless functions. They are isolated, less persistent, read-only, and often have little or no privilege to escalate, making them harder targets compared to other types of code. As functions generally have less responsibility and access to data than your typical monolithic application, the immediate scope of damage is smaller.

“The fact that the functions are running in their own environment reduces the potential damage, and the fact that nothing is stored so the function is removed, deleted, disposed after running, also prevents stored injections,” Checkmarx’s Cyber Security Evangelist Amit Ashbel said the OWASP AppSec conference. “Because if you inject something it’s deleted [after the function ends], the function is new and clean. [It] should be much more secure.”

The fact that functions are provided as a service by the major cloud providers offers an extra level of security. While the coding and configuration of the actual function is up to you, the likes of AWS and Azure will ensure that the underlying hardware is secure and patched, the functions themselves will be updated regularly, and the scale of these providers means denial of service attacks are easier to cope with.

However, in the same way that misconfigured S3 buckets have led to many headlines around data leakage, so too misconfigured serverless apps can lead to problems such as to data leakage.

“Lambda’s defaults are very good. The issues here are the defaults that are being introduced by popular serverless frameworks, and they tend to blow IAM [identity and access management] permissions wide open,” said Mozilla’s Krug. 

How to secure serverless functions

Serverless technology is still in its nascent stage, and that is reflected in security practices around the technology. Serverless.com’s survey found debugging, monitoring and testing were the biggest challenges around serverless applications, while a PureSec survey found that 35 percent of companies have no security guidelines or tools for securing their serverless code. Forty-eight percent of organizations in the study were unhappy with the level of security visibility they had into their serverless applications. That figure rises dramatically when the company has more than 50 functions, suggesting a problem with security at scale.

“Traditional application layer protections, such as web application firewalls and endpoint protection solutions, are unsuitable for serverless architectures and cannot be deployed given the lack of underlying infrastructure or access to the network/operating systems,” says Segal. “While security testing methodologies and tools for serverless are still pretty much non-existent.”

Despite this, organizations can follow some best practices to improve the secure posture of their serverless applications and functions. Follow these five application security best practices:

1. Design and develop with security in mind and use threat modelling to understand your risks. Perform static code analysis and penetration testing to detect vulnerabilities. Validate event data input by using safe APIs that either sanitize or validate user input and scan incoming HTTP/HTTPS traffic to the serverless application
2. Ensure your identity and access management (IAM) roles and permissions are configured correctly so that functions can only be accessed by what needs to access them. Give your functions only as much privilege as they need to perform their tasks. If a function only needs to read, ensure its permissions are read-only.
3. Put as little sensitive data into the function’s source code as possible. Ensure all data is encrypted. Likewise ensure your authentication methods are robust and use the FaaS provider’s where possible. Assess these regularly. “If you wouldn’t write sensitive data in your code on the server,” says Checkmarx’s Eshkenazi, “you should not write sensitive data in the serverless code since it could be exfiltrated and attacked.”
4. Understand how to develop serverless applications properly. Poorly developed auto-scaling functions can drag on resources. Auth0 has a functions as a service (FaaS) platform, Webtask.io, and Auth0 VP Tomasz Janczuk, says it is common to see situations where it looks like the platform is suffering from denial of service attacks that are actually usually down due to user error. Examples include inefficiently designed functions attempting to allocate very large amounts of memory, trying to write huge files to the file system, or blocking the CPU because of never-ending loops.
5. Make sure you have granular security visibility and insights on your serverless applications. Monitoring is particularly important, especially as you increase the number of functions. Monitor API authentications attempts, changes to functions’ configurations, permissions, or triggers, execution timeouts or limits reached. “Whether the application is traditional, containerized or serverless, the security of the entire delivery stack must be continually monitored,” says Tim Mackey, senior technical evangelist at Black Duck by Synopsys. “As applications are decomposed into functions deployed in serverless models, the potential attack surface for these applications increases and each function should be considered as a distinct deliverable subject to a full security review.”