AWS Configuration Issues Lead To Exposure Of 5 Million Records

Researchers reported on Tuesday that Amazon Web Services System Manager (SSM) misconfigurations led to the potential exposure of more than 5 million documents with personally identifiable information and credit card transactions on more than 3,000 SSM documents.

In a blog, Check Point researchers said they have worked with AWS Security to provide customers with the necessary information to help them resolve any configuration issues with the SSMs.   

AWS SSM documents contain the operations that an AWS systems manager performs on a company’s cloud assets. SSM documents are private by default, but developers can share them with other AWS accounts or publicly.

In analyzing the SSM documents, the Check Point researchers found that the misconfigurations took place because developers did not follow the proper parameters of usage as defined in the AWS best practices.

According to the researchers, 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. An SSM document can provide an attacker an initial foothold into the victim’s environment and sometimes even grant a view into the account’s deployment processes, resources, and backup procedures.

Here are four steps the researchers says security teams can take to configure SSM documents safely:

• Follow the parameters set by AWS. Don’t make information such as activation keys, user names, and emails in clear text, but only with parameters.
• Remain vigilant of the information the company posts to a public SSM. document. Even if it seems minor, it could offer information to an attacker.
• Do not share deploy processes and backup procedures.
• Review any AWS resources included in the SSM document to ensure the configurations are secure.

Enterprises have limited visibility into their cloud infrastructure causing situations like this to occur, said Erkang Zheng, founder and CEO of JupiterOne.

“This is similar to the frequent disclosure of S3 buckets, available publicly with no encryption, that happened throughout 2019 and 2020,” Zheng said. “Knowing what cyber assets exist at a given moment in time is difficult because of the ephemeral nature of cloud infrastructure. Enterprises require continuous monitoring of their cyber assets to deliver the vigilance required to stop these accidental disclosures from happening in the future.”

Hank Schless, senior manager, security solutions at Lookout, added that the emergence of advent of cloud access security brokers (CASBs) has helped companies gain deeper visibility into the interactions between cloud service users and the applications they access. Even so, Schless said traditional CASB tools lack the necessary capabilities to keep up with the evolution of cloud infrastructure and how cyber criminals are carrying out their attacks. 

“A modern CASB will let the organization ingest files of any type and automatically scan them for sensitive content, keys, and other sensitive details,” Schless explained. “Depending on the results of that scan, the system can then apply permission policies, encrypt the file, or block out sensitive information. This level of granularity is absolutely necessary for companies that want to secure something as important as SSM documentation. These documents have information that can provide access to even larger sensitive datasets, which could make a data leak involving SSMs detrimental to the future of any organization.”