Forem: Johannes Späth

Is your AWS Account vulnerable to the newest attack presented at Black Hat 2021?

Johannes Späth — Wed, 01 Sep 2021 16:54:33 +0000

Running confused deputy attacks exploiting the AWS Serverless Application Repository

Early this month at Black Hat USA 2021, researchers from Wiz.io presented a new confused deputy attack that allows an attacker to access data within your AWS account. Using to coarsely set IAM permissions when publishing an application within the AWS Serverless Application Repository (SAR), an attacker can acquire arbitrary data from the S3 bucket that is used for hosting the application's artifacts. In this article, we explain the vulnerability, showcase an actual exploit and explain how to fix the vulnerability in your account. If you are publishing an application using SAR, we recommend double-checking your permissions.

SAR is a platform that allows developers to publish and share SAM applications across AWS accounts. These applications can then be deployed standalone or easily be integrated into existing SAM applications.

Publishing an application to SAR is straightforward. As an author, one has to pack the underlying application code, templates, license, and readme files in a S3 bucket, create an entry in the SAR and attach a policy to the bucket that grants SAR access to the bucket.

The S3 policy allows SAR to read all objects stored in the specified S3 bucket. In their documentation, AWS initially proposed to attach the following IAM policy to the bucket:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service":  "serverlessrepo.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<your-bucket-name>/*",
        }
    ]
}

What's the problem with this policy? It does not restrict the account on which's behalf SAR is allowed to access the bucket! While no account other than the owner of the SAR application can actually change the application's setup in SAR, every account can exploit SAR to query objects and data from an S3 bucket with such a BucketPolicy.

This allows attackers to extract sensitive data like source code, hardcoded credentials, or configuration files that were never meant to be accessible by others. Even worse, if the bucket is used for more than hosting the packed SAR application, which, by the way, is an antipattern itself, attackers can acquire this data too!

Exploiting the Vulnerability

To showcase the exploit, we prepared a SAR application setup of our Serverless-Goat-Java implementation. Serverless-Goat was originally developed in JavaScript by OWASP and is an intentionally vulnerable serverless application. We published Serverless-Goat-Java into the AWS SAR for security training purposes.

With the following template, we deploy an AWS CloudFormation stack with the required bucket and policy to host a SAR app:

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31

Resources:
  ServerlessGoatPackages:
      Type: AWS::S3::Bucket
      Properties:
        BucketName: "serverless-goat-packages"

  ServerlessGoatPackagesPolicy:
    Type: 'AWS::S3::BucketPolicy'
    Properties:
      Bucket: !Ref ServerlessGoatPackages
      PolicyDocument:
        Version: 2012-10-17
        Statement:
          - Sid: ServerlessRepoAccess
            Action:
              - 's3:GetObject'
            Effect: Allow
            Resource: !Sub "arn:aws:s3:::${ServerlessGoatPackages}/*"
            Principal: 
              Service: "serverlessrepo.amazonaws.com"

Afterward, we pack our Serverless-Goat-Java application, upload it into the newly created bucket, and create a new SAR application in the SAR.

As you can see, the application is bound to the account 028938425188 and can only be modified by it. Let's call the account hosting the vulnerable app Alice.

To test our exploit, we need another SAR application in a different account on which's behalf we can query objects from our ill-configured bucket. Let's call it account Eve. For the sake of ease, we just deployed Serverless-Goat-Java again, but to account Eve:

Let’s see how we can exploit it!

Now that our setup is complete, we can try to use SAR to query data from account Alice's bucket and set it as a configuration for account Eve's SAR app.

Therefore, we instruct SAR to set the Readme file of account Eve's app to an arbitrary file from account Alice:

Looking again at the app in the SAR, SAR displays the following Readme in account Eve's app:

Phew, we are evil! 😈 We just stole the authors license file! Let's try another one:

This time around, the acquired information is much more interesting:

Of course, this is only dummy information for the sake of this demonstration. 😊

As you saw, the exploit is very easy once you know about it. The application's ID is public, only the bucket and file names have to be guessed by an attacker. This might sound hard to do!? Well, as we all know, security by obscurity doesn't work too well, so let's strive for a proper fix!

Fixing the Vulnerability

The fix is even more straightforward than the exploit! We need to make sure that our bucket used for hosting the SAR app is only accessible by the account that actually publishes the app.

Therefore, we have to modify our BucketPolicy to contain a condition that checks the AWS account which tries to instruct SAR to access the bucket:

  SampleBucketPolicy:
    Type: 'AWS::S3::BucketPolicy'
    Properties:
      Bucket: !Ref ServerlessGoatPackages
      PolicyDocument:
        Version: 2012-10-17
        Statement:
          - Sid: ServerlessRepoAccess
            Action:
              - 's3:GetObject'
            Effect: Allow
            Resource: !Sub "arn:aws:s3:::${ServerlessGoatPackages}/*"
            Principal:
              Service: "serverlessrepo.amazonaws.com"
            Condition:
              StringEquals:
                "aws:SourceAccount": "AWS::AccountId"

Indeed, AWS added the new condition expression right after the vulnerability was disclosed to them and updated their documentation accordingly. However, owners of the SAR applications need to update their S3 bucket policies, otherwise the respective AWS accounts remaining vulnerable.

After re-deploying our stack with the fixed policy, we observe the following when trying the exploit again:

Awesome! Now SAR can only modify account Alice's app on the behalf of account Alice! 🛡

Note: We changed the policy back after showcasing the fix, so you can try the exploit yourself easily with our SAR application!

Fixing the vulnerability is one thing. But how to find it in the first place?

We develop CodeShield to help developers and security teams finding and
fixing vulnerabilities in cloud-native applications. CodeShield can also help you to find Buckets that are vulnerable to the depicted confused deputy attack in your CloudFormation stacks and template files. Check it out and try CodeShield yourself!

Stay tuned if you are using Terraform or haven't set up your SAR buckets via a CloudFormation stack. We are currently extending CodeShield to be able to scan whole AWS accounts independently of stacks or templates. If you want to get notified when whole account scanning is ready, drop us a mail!

About the Authors

Manuel Benz is co-founder of CodeShield, a novel context-aware cloud security tool focusing on in-depth program analysis of microservice architectures. Prior to the start-up, Manuel worked as a researcher on combinations of static and dynamic program analysis for vulnerability detection at the Secure Software Engineering group at Paderborn University. Manuel is still actively maintaining the Soot static program analysis framework for Java.

Johannes Späth is an AWS Community Builder and a co-founder of CodeShield. Johannes completed his Ph.D. in static program analysis. In his dissertation, he invented a new algorithm for data-flow analysis which allows automated detection of security vulnerabilities.

Automated Vulnerability Prioritization in the Context of the Cloud

Johannes Späth — Mon, 09 Aug 2021 15:09:27 +0000

More and more companies are moving their workloads to the cloud - and for a good reason: it reduces the cost and the associated risk in comparison to running and maintaining the solutions themselves. Clearly, the shift to the cloud does not come for free. There are three points in particular that many companies are struggling with: Technical complexity, maintaining security, and ensuring compliance (Palo Alto, The State of Cloud-Native Security 2020).

Technical complexity arises from the fact that “moving to the cloud” means adopting new technology and does not mean deploying legacy software on resources provided by the Cloud Service Provider (CSP). To make use of the cost benefits, the software also needs to be adopted to cloud-native technologies (i.e. it should be provisioned using modern cloud-native technologies such as Kubernetes, CloudFormation, Terraform, or Serverless.) Only cloud-native technologies are able to make full use of the on-demand payment models that CSP promises. For more details see a post by one of my colleagues..

In this post our focus lies on the second of the abovementioned most critical challenge when moving to the cloud: maintaining security. Security itself, also prior to the cloud era, has been a challenge for many companies, as expertise in the area is rare.

Within the cloud security remains a challenge, as software is released even faster. With the "Shared Responsibility" security model that large cloud providers apply, part of the security responsibility is taken care of by the cloud provider. (for instance, physical hardware security, OS, and network security). New challenges that companies need to handle are a) secure configuration of the cloud account (setting minimal IAM permissions) and b) secure application level (i.e. address CVEs in third-party libraries and vulnerabilities in the own code).

Luckily, we have a large set of tools that help us detect security vulnerabilities as well as cloud misconfigurations. Unfortunately, with a large set of tools, the set of potential warnings easily reach between 100s and 1.000s that experts and developers need to navigate through and prioritize. This raises the question:

How do Companies Currently Prioritize Security Vulnerabilities?

A common way to prioritize security vulnerabilities is to prioritize them based on the scores that are pre-assigned by the underlying security tools, e.g., tools that perform software composition analysis (SCA) or software application security testings (SAST). Each security issue is assigned a score, mostly following the classification of easy, medium, high, and critical. SCA tools typically report the CVSS score associated with each CVE. The CVSS score is assigned by CVE Number Authorities (for instance GitHub) at the time when the vulnerability is reported. The score is assigned based on the information available to the authority at the time of the report. The score is rarely updated later on when more information is available. But this information clearly lacks context: the context of your application, your business, and the impact it may have on your application.

Best practice for Prioritizing Security Vulnerabilities

With 100s to 1.000s of findings that security teams have to navigate, the severity score is only a first indication for prioritization. Companies have to bear in mind that severity alone does not map the company risk associated with each vulnerability. The risk can clearly significantly differ from the default suggested CVSS score. Even a low severity vulnerability can have a severe impact on one’s own application. A low vulnerability may serve as an entry point for an attacker to navigate through the software.

So what is the business risk associated with a vulnerability? Well, it depends…Vulnerability assessment suggests that the business risk of a vulnerability depends on four parameters (Figure 1):

Figure 1: Security Risk is a combination of Vulnerability Score, Threat Context, Asset Exposure, and Business Impact

Vulnerability Severity Score: CVSS score given by code scanning tools (SCA, SAST,…) or other severity score provided by tools.

Threat Context: Additional meta-information about the vulnerability: How often has this vulnerability been exploited elsewhere? Is there an exploit publicly available? Have other companies been hacked because of this vulnerability?

Business Impact: Given that the vulnerability is exploited, which assets can be leaked? And what is the business value associated with these assets?

Asset Exposure: Is the affected component/resource containing the vulnerability publicly reachable? How complicated is it for an attacker to reach the affected resource that contains the vulnerability?

The good news is that with cloud-native determining asset exposure as well as automatically estimating the business impact is possible. And here is how:

How can we Automatically Assess the Asset Exposure?

By shifting to cloud-native software, infrastructure provisioning is becoming more automated and standardized in the form of Infrastructure-as-Code. Infrastructure-as-code is version-controlled alongside the application, which also means we can automatically analyze the code and derive additional application semantic from it.

See the diagram below (Figure 2) which depicts a CloudFormation template of a cloud-native application visualized in the form of a data-flow diagram. Highlighted in red is one cloud resource (an AWS Lambda called OrderGetFunction) which contains a vulnerability. Additionally, you see a graph that contains potential attack paths from different APIGateway methods within the infrastructure leading to the vulnerability. All paths end in the affected resource and start in different API endpoints (AWS ApiGatewayApi resources). Given the paths, one can decide and estimate the impact the vulnerability has on your application. Is the resource externally reachable at all?

Figure 2: Potential attack paths in a cloud-native application (the red node contains a vulnerability)

In the given case, you can see that the affected resource containing the vulnerability is reachable via several API gateway methods. For all paths, however, there are two hops in the infrastructure necessary as there are AWS Lambda nodes inbetween. An attacker must therefore craft an exploit to reach across two resources.

If you want to prioritize your security workload and automatically assess your cloud security infrastructure, at CodeShield we are happy to help.

About the Author

Johannes Späth is an AWS Community Builder and a co-founder of CodeShield, a context-aware cloud-native security tool. CodeShield allows you to automatically visualize your cloud environment. Sign up with GitHub to connect your AWS account. Johannes completed his Ph.D. in static program analysis. In his dissertation, he invented a new algorithm for data-flow analysis which allows automated detection of security vulnerabilities.

The Myth of False Positives in Static Application Security Testing

Johannes Späth — Tue, 20 Oct 2020 08:55:30 +0000

Static application security testing tools are notorious for presenting false positives, i.e., incorrect warnings. In this article, we explain the myth behind false positives and discuss two types of false positives - and which of those future SAST tools must solve.

The idea behind Static Application Security Testing (SAST) is flawless - theoretically.

SAST allows you to detect security vulnerabilities early on in the development phase. The focus lies on the word early. SAST analyzes your software's source code during development - long before testing, deployment and release of your software. Any vulnerability detected during development saves money during the proceeding development iterations and reduces the risk of an attack. - So far the theoretical side.

Now the practical side- legacy SAST tools are notorious for presenting false positives, i.e., spurious warnings that are not actionable. Developers and security analysts using SAST tools are typically forced to wade through endless lists of warnings. They evaluate and rank the findings one-by-one - until eventually at some point, the warnings are ignored.

The idea behind SAST tools is to trace data-flows along all execution paths of the program. Typically, SAST traces data-flow connections between so-called "sources" (method invocations that load user input) and "sinks" (method invocations that execute security critical functionality based on user input).

Example

SQL injection of a web application is the classic textbook example. The source is typically a method that receives the GET or POST parameters of a HTTP request. In the case of the Spring Application, any controller method annotated by @GetMapping, e.g.,

@GetMapping("/{userName}")
public User getUserByName(@PathVariable String username){...}

The sink is a method that executes a SQL query without properly sanitizing the parameters. For instance, the method executeQuery in the code below

...
String sql = "SELECT id FROM users WHERE username='" + username + "'"
Connection connection = dataSource.getConnection();
ResultSet result = c.createStatement().executeQuery(sql);

where the string variable sql is a concatenated query string that contains the user input userName from the request. Obviously, using the user input directly in the SQL statement renders a serious SQL injection vulnerability. This, for example, allows an attacker to circumvent the user authentication by providing a properly crafted SQL statement as username input, e.g., "'user' OR 1=1" which leads to the statement "SELECT id FROM users WHERE username='user' OR 1=1'" being executed. No matter what the username is, due to the "OR 1=1" part, the execution of the statement returns the first user of the users table, which often is the administrator user.

The Two Types of False Positives

During the static analysis the analyzed program is never executed. Therefore, the analysis engine needs to model potential program behavior during execution. This includes modeling the call stack, branch conditions and execution environments (hereafter context). The engine has to make (frequently conservative) assumptions about the path the data actually takes.

For instance, a data-flow engine needs to decide which concrete method implementation an interface invocation resolves to at runtime, the analysis needs to argue which branch will be executed and the analysis needs to reason about code locations that are at all reachable given the execution environment.

All those assumptions are encoded into the engine and lead to different types of false positives. However, we argue, there are two types of false positives: technical and contextual ones.

Technical False Positives

Technical false positives are inherited from properties of the underlying data-flow engine. Typical examples are context-sensitive, flow-sensitive, and field-sensitive analyses.
Context-sensitive analyses model the call stack, flow-sensitive analyses model the order of control-flow and field-sensitive analyses statically model the object-oriented programming style: objects referencing other objects using (im)mutable fields or class members.
Modern analysis engines, at least state-of-the-art research tools, address and handle all those details and are mostly false positive free - at least from a technical perspective.

Contextual False Positives

However, if you speak to developers and security analysts about SAST tools, you will frequently hear them saying:

It is not possible to perform a SQL injection attack at this code location. The method will only be executed from within our own infrastructure. An attacker cannot execute this part of the program.

This command injection is a false positive. The injection is only possible if the DEBUG_MODE flag is set. In our production environment, we do not set the environment variable DEBUG_MODE and the code is never executed.

For most SAST users, none of the above mentioned technical false positives (originating from context-sensitive, flow-sensitive, field-sensitive) come directly to mind when speaking about false positives. The two false positives mentioned in the quotes above also have one thing in common, the developer and analyst know more than the data-flow engine can derive from the pure software's source code.

A challenge that a next-generation SAST tool needs to cope with.

Contextual False Negatives

While the world speaks about SAST solution's false positives, SAST is also prone to false negatives. However, false negatives are invisible to the user, no-one - but the attacker and, if (s)he notices the attack, your CISO- cares.

A vulnerability which many SAST solutions fail to detect is a vulnerability that involves several components, for instance, a database. SAST solutions fall short on modeling data being stored in one cell of the database and being loaded at a different location within the program. If the database flow is part of a potential security vulnerability, the SAST tool will either miss the critical data-flow and not report the vulnerability, or alternatively, the tool will need to heavily over-approximate and mark every cell of the database as potentially manipulated.

Analyzing data-flows across several components is an even bigger issue in today's micro-service cloud architectures, where functionality is split among multiple separate services. Due to the missing context, legacy SAST tools are no longer able to properly model data-flow between those services and, again, are prone to either miss some vulnerabilities or over-approximate heavily.

Therefore, SAST tool vendors mostly decide to be "ok" with contextual false negatives. In that way, they avoid many contextual false positives wherever content of the database or data from another micro-service reaches a security-critical operation within the code.

About

Johannes Späth is a co-founder of CodeShield, a novel static security testing tool focusing on in-depth program analysis of open-source dependencies. Prior to the start-up, Johannes completed his PhD in static program analysis where he designed and implemented new algorithms for data-flow and pointer analysis, analyses that are necessary for automated detection of security vulnerabilities.