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.
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.
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.