Difference between revisions of "OWASP Serverless Goat"

Introduction

OWASP ServerlessGoat is a deliberately insecure realistic AWS Lambda serverless application, maintained by OWASP. You can install WebGoat, learn about the vulnerabilities, how to exploit them, and how to remediate each issue. The project also includes documentation explaining the issues and how they should be remediated with best-practices.

As serverless adoption is expected to continue growing and reach new audiences, we see the importance of education on topics such as how to build robust, secure and reliable AWS Lambda serverless applications. This project will expose developers and security practitioners to basic serverless security concepts, risks, attacks and mitigation best-practices.

There were a few key principles that we wanted to follow when designing this demo vulnerable application:

• Make the project open source and free for everyone to use
• Simple and straightforward deployment
• Demonstrate as many serverless security bad practices as possible (we will keep adding more issues, but also hope to see community contributions)
• Design the application to be realistic, and include common 'bad-practices', rather than forcing it to be vulnerable artificially

Given these key principles, we chose to develop and package the application an AWS SAM application that's available for deployment through the AWS Serverless Application Repository - however, this meant that we had to use the supported SAM policy templates. While this decision imposes some limitations on what capabilities were available for us, it presented two important benefits:

• The application uses "default" serverless application repository permissions, making it more realistic
• The deployment doesn't create custom IAM roles or resource policies

Details

The application is a service which receives a URL to a Word document (with a .doc extension - Office 97-2004), and will reply with an HTML page containing the extracted text.

The vulnerabilities that are included are:

• Event-data injection, leading to OS command injection (SAS-01)
• Improper exception handling and verbose error messages (SAS-10), leading to sensitive information disclosure
• Insecure Serverless Deployment Configuration, leading to S3 bucket data exposure (SAS-03)
• Over-privileged function permissions & roles, leading to data leakage of information stored in a DynamoDB table (SAS-04)
• Inadequate function monitoring and logging (SAS-05) - the application doesn't properly log application layer attacks and errors (can be demonstrated through CloudWatch/CloudTrail)
• Insecure 3rd Party Dependencies (SAS-06) - can be detected by scanning the project with an OSS scanning tool
• Application layer Denial of Service (SAS-08), which can be easily demonstrated
• An undisclosed *critical* issue, as a bonus!

Licensing

The OWASP ServerlessGoat project is free for use. You can redistribute it and/or modify it under the terms of the link GNU Affero General Public License 3.0 as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

Deployment

ServerlessGoat is a simple AWS Lambda application, which serves as a MS-Word .doc file to plain text converter service. It receives a URL to a .doc file as input, and will return the text inside the document back to the API caller. ​ The application is packaged and published for deployment through the AWS Serverless Application Repository. ​ Steps for deployment:

1. Make sure you are logged into your AWS account
2. Click on the following link: AWS Serverless Application Repository
3. Click 'Deploy'
4. Click 'Deploy' (again)
5. Wait until you see the message 'Your application has been deployed'
6. Click on 'View CloudFormation Stack'
7. Under 'Outputs' you will find the URL for the application (WebsiteURL) ​

Roadmap

• 18-December-2018: Initial release. Collect feedback from the public (done)
• 1-January-2019: Beta release with additional features.
• 15-January: v1.0 official launch

Project Sponsors

The project was initially developed by PureSec:

Cheat Sheet

Note: you can find a full walkthrough (with spoilers of course) in the LESSONS.md file in the Git repo

The following security issues exist in the application: ​

• Event-data injection, leading to OS command injection (SAS-01)
• Users can invoke the API with a document_url parameter value containing Linux OS commands. E.g. ; ls -LF
• Improper exception handling and verbose error messages (SAS-10), leading to sensitive information disclosure
• For example, invoking the API without the required parameter will return a verbose stack trace/exception
• Insecure Serverless Deployment Configuration (SAS-03)
• Publicly open S3 bucket (its name can be discovered from the subdomain/prefix of the URL)
• The parameter document_url is not defined as a 'required' parameter in API gateway and can be ommitted
• Over-privileged function permissions & roles, leading to data leakage of information stored in a DynamoDB table (SAS-04)
• The function has CRUD permissions on the Dynamo table, which can be abused for reading sensitive data, or manipulating data
• The function has FullAccess policy on the S3 bucket, leading to data tampering and data leakage, etc.
• Inadequate function monitoring and logging (SAS-05) - the application doesn't properly log application layer attacks and errors (can be demonstrated thro\ugh CloudWatch/CloudTrail)
• Insecure 3rd Party Dependencies (SAS-06) - can be detected by scanning the project with an OSS scanning tool
• The vulnerable package is node-uuid
• Application layer Denial of Service (SAS-08), which can be easily demonstrated
• An attacker may invoke the API recursively multiple times, essentially spawning enough instances to reach the function's reserved capacity limit (which is set to 5). Recursive invocation can be done by invoking the API with itself as the `document_url` parameter (URL-encoded), which by itself calls itself (double-URL encoded), etc. (x5 times).
• An undisclosed critical issue, as a bonus! ​

Getting Involved

You do not have to be a security expert or a programmer to contribute. Contact the Project Leader(s) to get involved, we welcome any type of suggestions and comments.

Project Resources

Deployment via the AWS Serverless App Repository

Project Leader

Ory Segal , PureSec (email)

Project Mailing List

TBD

Github Repo

Project GitHub

Classifications