The Need to Protect Public AWS SSM Documents – What the Research Shows

AWS Systems Manager automates operational tasks across AWS resources by creating SSM documents. The SSM documents, created in JSON or YAML, contain the operations that an AWS Systems Manager will perform on the cloud assets. By default, SSM documents are private, but can be configured to be shared with other AWS accounts or publicly. AWS provides best practices for shared SSM documents.

The Check Point CloudGuard Research team analyzed SSM documents configured by their owners to be shared publicly. The research team discovered that some basic misconceptions of the service had occurred, along with a lack of proper parameters usage (as defined in AWS best practices). As presented in this report, a misconfigured public SSM document can give an attacker valuable information about the account’s internal resources and operations. This not only serves as a basis for social engineering attacks, but can lead to the exposure of additional resources. The SSM document can provide an initial foothold into the victim’s environment and sometimes even grant an attacker a view into the account’s deployment processes, resources, and backup procedures.

During this research, CPR detected several SSM documents that led to the discovery of over five million Personally Identifiable Information (PII) records and credit card transactions for several companies. In total, Check Point researchers discovered over 3,000 public SSM documents that were potentially related to this trend.  CPR worked with AWS Security to provide customers with the necessary guidelines to help make their business information more secure.

Remove Sensitive Information

Let’s start with an example of an SSM document that contains activation-keys and the corresponding customer-keys. Whether it is in and SSM document or source code, information such as usernames, passwords, or access keys should never be hardcoded. If these values are required within an SSM document, AWS recommends that you use and reference the Systems Manager Parameter Store within your document. As seen below, we were able to detect several public SSM documents with hardcoded credentials within the SSM content.

Figure 1: Example of an SSM document that contains activation-keys and the corresponding customer-keys

Figure 2: CPR detect several public SSM documents with hardcoded credentials within the SSM content

Remove Extraneous Information

When an attacker evaluates a target, even non-sensitive information can be useful. As SSM documents contain a summary of the infrastructure and its operations, it can be a useful source of intelligence, even if the SSM document does not contain any hard coded secrets.
For example, the SSM document below contains an AWS IAM username. The inclusion of the IAM user does not create a security risk in and of itself. However, an attacker may still be able to leverage it to their advantage.

Figure 3 – SSM document containing an AWS IAM username – an attacker can take advantage of this.

The username is in the format of an email address and can be the start for an Open Source Intelligence (OSINT) investigation. An attacker may discover information about this IAM user such as his profession, city, country, and his employer. This kind of detailed information can be used as a starting point for a Social Engineering or Spear Phishing attack.
When you prepare an SSM document for public use, remove information that seems innocent but can be helpful to attackers – anything that will assist in a social engineering attack or abuse of misconfigured cloud resources.

Another example of sharing extraneous information below:

Figure 4: Sharing extraneous information

The SSM Document lists the ECR endpoint resource name related to that AWS account (first section outlined in green). Within ECR, there might be docker images. If an attacker can access the container registry, he can access these images. Notice that the username is in plain text (after “-u” flag) and the password is abstracted through the use of parameters (-p {{login}}). This means that the attacker only needs to guess or brute force the password to access the container registry (in this case, the ECR endpoint is publicly available). The user should have used parameters for not just the password, but for the username and ECR endpoint as well. While sharing a resource ARN is not a security issue, it’s best to avoid it.

Text/Descriptions may Contain Sensitive Information

Resource names are usually related to their tasks. While sharing a resource name is not usually a security issue, its best practice to avoid it. For example, if you name an EC2 as “Access_to_DB”, this alerts an attacker that this is a very valuable resource.

Figure 5: This document description comes with the phrase “Connect Payer-Account” which might alert attackers on an opportunity

In the above example, there is a document description with the phrase “Connect Payer-Account.” Just like with resource names, any text or description included in the public document might alert an attacker to an opportunity. The combination of the appealing description and the S3 bucket shown below would be enough for most attackers to focus their efforts on this document.

Keep Backup Procedures Private

The most valuable piece of information an attacker can gain from a public SSM document may be procedures related to deployment and backups in the AWS account. The flow presented below is one instance of unwanted data exposure. Note – the screenshot is of a lab environment:

Figure 6: Screenshot of lab environment

In the above SSM document, we saw a backup process that seemed to be running every hour. The process downloads a file from an S3 bucket and executes it locally. Let’s try to download it:

Figure 7: Downloaded file from an S3 bucket

Once again, the ExtractTool.jar contained a high volume of files. However, after an analysis of this content, we were able to detect a backup script named “backup.sh”.

Analyzing it revealed this sync command:

Figure 8: Revealed sync command

After we counted the found S3 bucket, we were able to find the backup’s content.
This exposed several DB backups and each backup’s size is more than 1Gb (containing tens of thousands of PII records).

Figure 9: Exposed database backup

Conclusion

The sharing of SSM documents can be very useful in a work environment. However, customers should be aware of how an attacker can use the information within the SSM document to stage an attack that can result in data exposure. To prevent the creation of a public SSM document at the account level, use the newly released Block Public Access for SSM Documents. Check Point Research provides the following guidelines to companies who plan to use public SSM documents:

1. Usage of parameters is essential. Information such as activation keys, user names, emails etc. should not be in clear text, but only with parameters.
2. Remain vigilant of the information you are posting to a public SSM document. Even if it seems minor, it could provide information for an attacker.
3. Do not share deploy processes and backup procedures
4. Review any AWS resources included in the SSM document to ensure their configurations are secure.