By adopting the serverless infrastructure we eliminate the need to develop a server to manage our applications - this also means that we pass some of the security responsibilities to the infrastructure vendor such as AWS, Azure or Google Cloud.
Wow! Passing some of the security responsibilities to one of the big cloud vendors, that must be really safe - you might be thinking. In some ways YES, in other ways NO. Because of all the rapid development going on in the devops world its now even more important to write secure code because serverless is still vulnerable to old attacks such as; cross-site scripting, command/SQL injection, security misconfigurations, broken access control and many more.
Interested? Continue reading below and I will explain some of the different attack vectors and how to some extend prevent them.
Attack vectors for injections in traditional applications are usually done like this: The attacker in some way shape or form are able to input parameters in to your database and by doing this they are able to control or manipulate the data.
When protecting serverless infrastructure from these kind of attacks you really need to know what functions are being used within the environment. Because often
some part of the serverless application are using different functions such as; S3 buckets, blob storage and other storages, stream data processing and different databases from which an attacker could take advantage of.
How to prevent this?
- Never trust, pass or make any assumptions regarding input and its validity from any resource.
- Use a safe APIs.
- Use a “whitelist” input validation.
- Identify trusted sources and resources and whitelist them.
- Run functions with the least privilege as you are doing when setting up IAM.
When running serverless functions you actually run stateless compute containers. This means that there is not (like in the old days) one machine to control - rather hundreds of functions running on small containers (computers).
As an attacker you will always try to find resources within the environment that is hidden or forgotten - so like in any normal infrastructure build, it is always important to have control of your environment and the different flows.
How to prevent this?
- External facing resources should require authentication.
- Always use different types of IAM controls which is usually provided by the vendor.
- Use authentication between internal resources.
Using Components with known vulnerabilities
So you have a deadline, you need to develop a function really fast - this usually happens and I don’t mind having a fast paced mindset when developing stuff. What also usually happens is that the developer use a 3rd-party tool or library with vulnerabilities.
This method could almost be compared to some kind of poisoning of your environment,
could be ARP, DNS poisoning of some sorts - however - the attacker doesn’t have to do anything to poison the environment, because you have already helped them.
How to prevent?
- Continuously monitoring of your dependencies and their versions.
- ALWAYS use official sources.
- Threat-Hunting capabilities - monitor new CVEs and NVDs.
- Scan your environment for known vulnerabilities.
Of course there are many more ways for an attacker to hi-jack your environment but following these steps will help you create a more secure posture. As always in a cybersecurity realm it is very important to educate and raise the security awareness within your company.
As I once read somewhere; “if you get your employees to think about security for 1%, you have come a long way”.
If you are interested to talk about fun things like, SIEM, vulnerability scans, code analysing/ review or penetration tests - don’t hesitate to contact Enfo Cybersecurity.
Enfo Cybersecurity Team