How an attacker got data from the Cloud using CVE-2021-40438

Blog written by: Thomas van Ruitenbeek & Patrick de Brouwer


In a recent security incident, attackers managed to obtain an enormous amount of personal information that should not be accessible in the way it was obtained. The data was stored in an Amazon S3 bucket, which is a cloud object storage resource. S3 is short for “Simple Storage Service” and is offered by Amazon Web Services (AWS).

Data within this resource can be accessed by a securely generated access token that should only be known between the application and data bucket but could be obtained by the attackers after abusing a vulnerability that is known as CVE-2021-40438.

This article describes the exploit and attack method that was used during this security incident. As for privacy concerns, the parties that were involved in this incident are not named within the article and the content is purely focused on the attack.


The vulnerability
The vulnerability that is known as CVE-2021-40438 concerns a Server-Side Request Forgery (SSRF) flaw that was found in an optional module for Apache known as mod_proxy. This module implements a proxy, gateway or cache for the Apache web server and allows for proxying capability between several different protocols. Specifically, the vulnerability was discovered in Apache version 2.4.48.

Server-Side Request Forgery (SSRF)
The flaw allows a remote, unauthenticated attacker to make the web server forward requests to an arbitrary server. This allows the attacker to obtain, modify or delete resources on other services that may be behind a security system such as a firewall and inaccessible otherwise. The impact of this flaw varies based on what services and resources are presented on the network which the web server has connectivity to.

The vulnerability becomes a threat if the Apache web server is configured to use the mod_proxy module. The snippet below is an example of a configuration that is known to allow this vulnerability to work.

<VirtualHost *:80>
ProxyPass /test http://localhost:8000/"
ProxyPassReverse /test http://localhost:8000/"

The example configuration above can be placed in an active VHost configuration within the “sites-enabled” directory of Apache. As per this example, the resource /test is defined.

The vulnerability allows an attacker to insert an additional resource, which is then forwarded by the web server that is vulnerable for this attack method. It operates by appending the phrase “?unix:” and an additional 7701 characters within a legitimate request.

$ curl "$(python3 -c 'print("A"*7701, end="")')|<URL>" -Lksq

The example request above makes use of the curl and python3 commands, usually accessible on a linux system if both applications are installed. A web request is made towards and the preconfigured /test-resource, with the ?unix: parameter added. Then, using a terminal-based command to insert output of an additional command, Python is used to print the additional required 7701 characters. Near the end of the command, the value of can be replaced with the URL that is to be forwarded to, by the vulnerable web server.

When abused correctly, this can allow the attacker to access metadata services which should normally only be accessible by the application or administrators.

Metadata Services
A metadata service supplies information to services deployed on servers in the cloud. By default, network services can connect and obtain sensitive information like access credentials. If the role that is assigned to the network service has enough permissions set, an attacker could use this level of access to obtain credentials that are stored within these resources and compromise the cloud network.

In the case of the attack that this article is based on, attackers managed to successfully obtain the access tokens for the S3 bucket that stored all the sensitive information that was stolen.

As per the vulnerability and incident this article is based on, Northwave has performed some additional research and has used the following code to verify the existence of the vulnerability:

$ curl "https://victim/?unix:$(python3 -c 'print("A"*7701, end="")')|" -Lksq

The request above is the same as the previous example shown in the details section, except that in this example the URL has been replaced by a metadata service URL that is used to

obtain the security credentials for an IAM role named ServiceRole. This results in the following output:

"Code" : "Success",
"LastUpdated" : "2021-10-28T07:08:32Z",
"Type" : "AWS-HMAC",
"AccessKeyId" : "ASIA...REDACTED...",
"SecretAccessKey" : "SECRET_REDACTED",
"Expiration" : "2021-10-28T13:33:19Z"

As shown in the output above, successful exploitation results in security credentials being exposed to the attacker, allowing them to reuse this information and obtain access to all resources that these credentials have access to.


To summarize the attack scenario: Attackers can perform a malicious request to the vulnerable Apache web server, allowing them to obtain credentials from an additional, restricted resource. The credentials can then be used to obtain all information that the original resource (thus: application) has access to.


The exact timestamp of the discovery of this vulnerability remains unknown, but the CVE was registered[1] on 2 September 2021. The vulnerability was discovered by the Apache HTTP Security team while analysing CVE-2021-36160, a vulnerability that can cause the mod_proxy_uwsgi module to read above the allocated memory and result in a crash (Denial of Service).

The mitigating patch was released for Apache version 2.4.49 on 16 September 2021. Amazon had released an update[2] on 15 October 2021, which is near to a month after the discovery.

On 20 October, five days after Amazon had released the update, the attack took place.


Incidents like this are a perfect example to demonstrate the necessity of defense in depth strategies. By being dependent on Amazon to release updates and the impacted company not immediately applying the patches, an attack window of around 35 days was open in which the attackers could strike.

Not only is patch management important, because there are always risks of software containing security bugs. However, the fact that the attackers managed to obtain the credentials and gain access to the data that was stored in the S3 bucket, could have been detected. The company could then have acted earlier to prevent the data from being accessed.