Securing serverless data from cryptomining malware like Denonia

AWS Lambda recently saw its first specifically-targeted threat with the Denonia malware. Although the impact of this attack was low, now is the time for companies to ask themselves how safe their serverless applications are, and how they can prepare for a future attack. 

Securing serverless apps requires a different approach from traditional monoliths or containerized applications. With this first malware attack, we have an opportunity to evaluate what the unique considerations are when protecting serverless environments and how we can take these into account to harden our approach to serverless security. 

How is my serverless application vulnerable?

Serverless architecture is inherently more secure in a number of ways. With serverless, cloud providers are responsible for handling the heavy lifting of patching and securing infrastructure. Just like with optimizing the allocation of compute resources, cloud providers are far better than us at securing infrastructure, so relying on them is a safe bet. You’re still responsible for securing your code and all the resources and components that make up your serverless system, but offloading much of the configurations and infrastructure management to the platforms allows you to focus all of your attention on a smaller area. Additionally, serverless functions are typically short-lived, complicating matters for would-be attackers by giving them just a small window to break in.

On the other hand, the distributed and dynamic nature of serverless makes it difficult to spot threats and fix them quickly — especially as tech stacks grow. With the various tools and services used to develop, test and deploy serverless applications, these environments become even more opaque. Developers are left to comb through enormous amounts of trace data, logs and metrics to understand their applications. With so many interconnected resources, but limited visibility, it’s difficult to identify and troubleshoot security issues quickly and efficiently.

Serverless architectures are event-driven, triggered by sources like an API call or a new upload to an AWS S3 bucket or a database change. A single application can have many functions with different event sources, and for every function invoked, data is consumed, making your code vulnerable to malicious users. As code moves through your pipelines, from one service to another, new entry points are created for malware to manipulate its path. Attacks can more likely happen before data gets into an S3 bucket or DynamoDB, so while encrypting your data is always a best practice, it’s important to take other steps to limit the vulnerabilities in your application.  

Harden your access controls

Misconfigured access controls and permissions are where your serverless application can be most vulnerable. This was the case with the Denonia attackers, who according to AWS gained access by fraudulently obtaining account credentials. Lambda functions need to be protected with strict access controls and privileges to help reduce the attack surface of your serverless applications. Serverless architecture, made up of small microservices, can benefit from the principle of least privilege, where you set strict permissions and policies for a function that limit access to only the necessary users and resources it needs. 

Keep code on its course 

One of the ways that malware can hurt your serverless applications is by redirecting code in ways that the developer did not intend. For instance, malware like Denonia could manipulate your code to utilize your compute power for mining cryptocurrency. The automated, nearly infinite scalability of serverless — which is beneficial under normal circumstances — means that your environment will automatically scale, spinning up additional Lambda function instances which can in turn be compromised and hacked. You end up paying for all the resources the malware uses to carry out its attack.

We can’t always predict how a threat will play out, but we can learn from how malware like Denonia behaves and take some steps to ensure that our code executes exactly as it’s supposed to. Setting reasonable hard limits on activities like autoscaling is crucial for ensuring you don’t get a nasty surprise when the next cloud bill arrives. Alerts should also be put in place to notify you when you’re approaching the max, or when a Lambda tries to access something it shouldn’t, so you can catch malicious activity in its tracks and remediate it quickly. 

Get the full serverless story 

Traditional monitoring strategies — which only focus on tracking resource utilization metrics like CPU and memory, or have blind spots when it comes to managed and third-party services — leave a big gap when it comes to securing serverless apps. As your application grows and your attack surface becomes larger, relying on raw metrics and logs for monitoring serverless environments will only get you so far. Soon, there will be too many services and resources generating data to figure out where your code took a wrong turn, and your system could be exploited before you notice.

Securing serverless architecture calls for more comprehensive visibility into how functions, services and resources interact. Distributed tracing is critical for helping you understand the scope of the damage, how the malicious user entered and what they saw. This method allows you to follow the chain of events of an application’s request handling, from the event trigger to the Lambda function to managed services, to find the source of risk or attack in real time.

Serverless security going forward

Serverless computing’s many benefits have accelerated its adoption in recent years, and it is now relied on by a significant portion of all developers. The appearance of malware specifically targeting serverless infrastructure is yet another sign that serverless has come of age. A specific instance of malware doesn’t pose an acute risk to serverless applications, but it does highlight a new kind of threat that is especially pertinent to serverless architecture. This is a great opportunity for all of us to take a moment to review our serverless environments and ensure that best practices are followed to keep our users’ data and our resources safe.

Erez Berkner is the CEO and co-founder of Lumigo.