How AWS Misconception Resulted in Detection of 5 Million Personal Records

Highlights

• Check Point Research (CPR) identified a trend of user’s misconception of service on AWS system manager, resulting in personal records detection
• 5 million personally identifiable information (PII) records and credit card transactions revealed by CPR
• Check Point Research worked closely with AWS Security to provide companies with the needed information to properly configure their systems and secure their stored data
• New AWS feature helps companies avoid mistakenly exposing AWS Systems Manager (SSM) documents

Overview

CPR was able to detect personal records in Amazon Web Services (AWS). By analyzing and enumerating public AWS Systems Manager (SSM) documents, CPR retrieved over five million personally identifiable information records and credit card transactions of companies, including a global sportswear manufacturer.

AWS Systems Manager provides the ability to automate operational tasks across AWS resources by creating SSM documents. An SSM document defines the actions that Systems Manager performs on their managed instances. Due to an increased rate of cloud migrations and deployments, CPR analyzed SSM documents and found a trend of misconceptions on the parameters of what should be shared within such documents.

These misconceptions, and a lack of proper parameters usage (as defined in AWS best practices), mistakenly exposed data records with millions of personally identifiable information (PII records) and credit card transactions. This information was stored on cloud services of several companies, including a global leading sportswear manufacturer.

A misconfigured public SSM document might provide an attacker with valuable information about an account’s internal resources and operations. This not only serves as a good basis for social engineering attacks, but can also show additional resources being misconfigured. This can provide an initial foothold into the victim’s environment, potentially granting 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 5 million Personally identifiable information (PII) records and credit cards transactions for several companies. Overall, researchers discovered more than 3k public SSM documents that were potentially related to this trend. Check Point Research worked closely with AWS Security to provide the identified companies with information to properly configure their assets and secure their documents and information. Furthermore, a new AWS feature helps companies avoid sharing such documents on cloud instances.

Securing SSM Public Documents – Do’s and Don’ts

During this research, Check Point detected several public SSM documents with hardcoded credentials within the SSM itself. Information such as usernames, passwords or access keys should never be hardcoded. If these values are required within an SSM document, AWS recommends using the Systems Manager Parameter Store and referencing these parameters within your document.

Usernames do not belong within an SSM document

When an attacker evaluated a target, easily accessible information might be useful to them as they prepare an attack. As SSM documents contain a summary of the infrastructure and its operations, they can be a useful source of intelligence, even if the SSM document does not contain any hard coded secrets.

The username in the format of an email address could be the seed for an Open Source Intelligence (OSINT) investigation. An attacker may discover information about this Identity and Access Management (IAM) user, such as their profession, city, country, and their employer. This kind of detailed information can be a good starting point for aSocial Engineering or Spear Phishing attack.

When preparing an SSM document for use in public, it is prudent to remove information that seems insignificant, but can be helpful for attackers. Beyond the IAM users’ usernames in the form of email addresses, this can be anything that assists in a social engineering attack or abuse of misconfigured cloud resources.

Descriptions may be Sensitive Information

While sharing the resource’s name is not a security issue, it is a security best practice to avoid it. As an example, if you name an EC2 as “Access_to_DB”, this will alert any attacker to focus efforts there as the name implies it is a very valuable resource.

In the above example, you see a description of the document 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.

Conclusion

The sharing of SSM documents can be useful in a work environment. However, companies 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. CPR 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.

Modern cloud deployments can be tremendously complex and typically span multiple clouds. Check Point CloudGuard provides unified cloud native security for all assets and workloads, giving you the confidence to automate security, prevent threats, and manage posture –everywhere- across your multi-cloud environments.