Exercise 15: Exploiting Insecure Serverless Application APIs

Objective:

Understand how misconfigured APIs in serverless applications can expose backend systems to attackers. Demonstrate how to exploit such APIs and implement best practices for securing serverless application APIs, such as authentication, input validation, and rate-limiting.

Scenario:

You are tasked with assessing the security of a serverless application deployed using AWS Lambda and API Gateway. During the review, you discover misconfigured API endpoints, such as missing authentication or exposed sensitive data. Your goal is to exploit these vulnerabilities and demonstrate how attackers can access backend systems.

Lab Setup:

Prerequisites:

1. AWS account (free-tier works for this lab).
2. Installed tools:
   • Postman (Download Postman).
   • Burp Suite (Download Burp Suite).

Steps to Set Up the Lab:

Deploy a Serverless Application:

Create an AWS Lambda function:

Navigate to Lambda > Create function > Author from scratch.

Function name: insecure-serverless-api.

Runtime: Python 3.x.

Add the following code to simulate an API endpoint:

import json def lambda_handler(event, context): # Simulate sensitive data exposure if event['httpMethod'] == 'GET' and event['path'] == '/sensitive-data': return { 'statusCode': 200, 'body': json.dumps({ 'api_key': '12345-abcdef-67890', 'password': 'SuperSecretPassword' }) } # Simulate processing user input if event['httpMethod'] == 'POST' and event['path'] == '/process-data': data = json.loads(event['body']) return { 'statusCode': 200, 'body': json.dumps({ 'message': f"Processed data: {data['input']}" }) } return { 'statusCode': 404, 'body': json.dumps('Invalid request') }

Deploy the function.

Set Up API Gateway:

Navigate to API Gateway > Create API > HTTP API.

Integrate the API with the Lambda function:

Create a GET method for the /sensitive-data endpoint.

Create a POST method for the /process-data endpoint.

Deploy the API and note the Invoke URL.

Verify API Functionality:

Test the API endpoints using Postman or a browser:

GET https://<api-id>.execute-api.<region>.amazonaws.com/sensitive-data

POST https://<api-id>.execute-api.<region>.amazonaws.com/process-data

Body:

{ "input": "Test Input" }

Exercise: Exploiting the Insecure API

Objective:

Simulate an attacker exploiting misconfigured API endpoints to access sensitive data or trigger unintended behavior.

Access Sensitive Data:

Use Postman to send a GET request to the /sensitive-data endpoint:

GET https://<api-id>.execute-api.<region>.amazonaws.com/sensitive-data

Observe that the API exposes sensitive information, such as API keys and passwords.

Inject Malicious Input:

Use Postman or Burp Suite to send a POST request to the /process-data endpoint with crafted input:

Example payload:

{ "input": "<script>alert('XSS')</script>" }

Verify if the API processes the malicious input without validation.

Test for Rate-Limiting Issues:

Use a script or a tool like Burp Intruder to send multiple requests to the API endpoints.

Observe if the API enforces rate-limiting or blocks excessive requests.

Check for Authentication Bypass:

If the API uses any authentication mechanism (e.g., API keys), attempt to bypass it by:

Removing the authentication header.

Sending requests from different IPs to test restrictions.

Tools Required:

1. AWS Lambda and API Gateway: For setting up the serverless application.
2. Postman: For testing API endpoints.
3. Burp Suite: For manipulating and testing requests.
4. Python or Shell Scripts: For automating requests to test rate-limiting.

Deliverables:

1. Exploit Report:
   • Evidence of accessing sensitive data via the /sensitive-data endpoint.
   • Screenshots showing the processing of malicious input without validation.
   • Logs or observations of excessive API requests to demonstrate rate-limiting issues.
2. Recommendations for Securing APIs:
   • Steps to add authentication, validate inputs, and enforce rate-limiting.

Solution:

Identified Vulnerabilities:

Exposed Sensitive Data: The /sensitive-data endpoint exposed API keys and passwords.

Lack of Input Validation: The /process-data endpoint processed unvalidated input, allowing potential XSS or injection attacks.

No Rate-Limiting: The API allowed excessive requests without throttling.

No Authentication: Endpoints were accessible without any authentication mechanism.

Consequences:

Data Breach: Sensitive data, such as API keys, could be used for unauthorized access to other systems.

Service Exploitation: Attackers could abuse the API for malicious purposes, such as injecting payloads or overloading the system.

Compliance Issues: Exposing sensitive data violates regulations like GDPR or HIPAA.

Prevention Techniques:

Enforce Authentication:

Use API keys, AWS IAM authorization, or Cognito User Pools to restrict access.

Validate Inputs:

Add input validation to the Lambda function to sanitize and validate user inputs.

Example validation in Python:

import re if not re.match("^[a-zA-Z0-9_ ]+$", data['input']): return {'statusCode': 400, 'body': 'Invalid input'}

Implement Rate-Limiting:

Use API Gateway throttling to limit requests per second:

Example: Allow 100 requests per second per user.

Avoid Sensitive Data Exposure:

Do not log or return sensitive data in API responses.

Use environment variables for sensitive values (e.g., AWS Secrets Manager).

Conclusion:

This exercise demonstrates how misconfigured serverless APIs can expose backend systems to attackers. By implementing authentication, input validation, and rate-limiting, organizations can secure serverless application APIs and prevent exploitation.