Overview
We have recently identified several vulnerable HTTP requests that allow attackers to capture access keys and session tokens for a web application’s AWS infrastructure. Attackers could use these keys and tokens to access back-end IOT endpoints and CloudWatch instances to execute commands. This blog was developed to raise awareness on common design flaws in a web application’s relationship with its back-end AWS infrastructure.
Access Keys, Session Tokens and Design Flaws
AWS endpoints typically require access keys, namely an API key and API secret, as well as a session token in order to access their API. External users interacting with your AWS infrastructure via web browser, client application, mobile app, or an interactive command-line tool may be provided with temporary API keys and session tokens. These temporary access keys are often shared with external users in order to upload device-side logs to the application’s CloudWatch instance.
The process of uploading client-side logs begins when an AWS IoT device sends MQTT messages containing formatted log files to an AWS IOT topic. An AWS IoT rule monitors the message topic and sends the log files to CloudWatch. As we will later explore in the article, some web-applications will provide temporary access keys and session tokens for an AWS IOT endpoint and the CloudWatch instance used by the backend AWS infrastructure.
In many cases external attackers can capture temporary access keys and session tokens in clear text. They can be used to interact with the application’s CloudWatch instance and IOT endpoint. Even if these access keys have been assigned according to the principal of least privilege, attackers can still use them to upload false logs to the CloudWatch instance or send MQTT messages to the application’s IOT endpoint. Uploading false logs to the web app’s CloudWatch instance directly tampers with the integrity the application’s CloudWatch data. Attackers could use this to interfere with forensic investigations. Processing MQTT messages and CloudWatch logs has an associated cost for the team maintaining the corresponding AWS infrastructure. Attackers wishing to inflict financial damage would be able to send a large volume of MQTT messages to IOT endpoints or upload a large quantity of false logs.
Identifying and Exploiting Vulnerable HTTP Requests
This class of vulnerability was identified in a peer-to-peer screen web application built on top of AWS cloud infrastructure. In analyzing the HTTP requests sent to the application, two unique endpoints were found: ‘/createsession’ and ‘/cloudwatchupload’. When a request was sent to the ‘/createsession’, the web application responded with access keys and session tokens corresponding to an AWS IOT endpoint, as seen in Figure 1 below. These keys were successfully used to send MQTT messages to the AWS IOT endpoint.
Figure 1: Requesting the ‘/createsession’ endpoint to receive access keys (accessKey & secretKey) and a session token (sessionId).
When the screen sharing session was terminated a request was sent to the ‘/cloudwatchupload’ endpoint which contained a separate set of access tokens, a session token and a CloudWatch log in JSON format. It can be seen in Figure 2 below. The access keys and session token were used to upload logs to CloudWatch.
Figure 2: Capturing CloudWatch access keys and session ids in an HTTP request.
These two HTTP requests are congruent with common methods for uploading methods client-side logs to AWS.
Remediation
API keys, API secrets, or session tokens belonging to a backend service should never be sent to an external party. Sensitive information, such as CloudWatch logs, should be sent to an internal server accessible only to the web application. The data that normally would be submitted directly to the AWS endpoint should be sent to the internal server, validated, sanitized if necessary, and forwarded to its intended location. This approach has the added benefit of allowing for other security controls such as centralized auditing, logging, and rate limiting.
Conclusion
In this article, we discussed some of the dangers inherent to requesting backend AWS infrastructure via external web applications. Given the increasing prevalence of cloud in web application development we wanted to highlight the risk and vulnerabilities associated with common design flaws. We have also provided some additional resources for those looking to learn more about these vulnerabilities and how they can be exploited.
