On May 14th, RiskIQ covered the latest mass compromise of third-party web suppliers by a Magecart group. This initial report focused on seven of these suppliers, the scripts of which were injected with skimmer code, which possibly affected several thousand websites using their services. 

However, the actual scale of this campaign and the number of sites affected is much larger than previously reported. The actors behind these compromises have automated the process of compromising websites with skimmers by actively scanning for misconfigured Amazon S3 buckets. These buckets are un-secure because they are misconfigured, which allows anyone with an Amazon Web Services account to read or write content to them.

RiskIQ has been monitoring the compromise of S3 buckets since the beginning of the campaign, which started in early April 2019. We’ve been working with Amazon and affected parties to address Magecart injections and misconfigured S3 buckets as we observe them.

We wrote the following article to raise awareness around the security policies for Amazon S3 as well as web-skimming attacks in general.

Discovery of Misconfigured Bucket

These actors automatically scan for buckets which are misconfigured to allow anyone to view and edit the files it contains. Once the attackers find a misconfigured bucket, they scan it for any JavaScript file (ending in .js). They then download these JavaScript files, append their skimming code to the bottom, and overwrite the script on the bucket. This technique is possible because of the misconfigured permissions on the S3 bucket, which grants the write permission to anyone.

These attackers have been active in web skimming for a long time using other techniques, but they started compromising unsecured S3 buckets in early April. According to RiskIQ data, the group has managed to compromise a vast collection of S3 buckets to impact well over 17,000 domains. This list includes websites in the top 2,000 of Alexa rankings as well.

The Shotgun Approach: Reach at the Expense of Accuracy

Although the attackers have had lots of success spreading their skimmer code to thousands of websites, they sacrificed targeting in favor of reach. The actors used this technique to cast as wide a net as possible, but many of the compromised scripts do not load on payment pages. If you’ve read our coverage of Magecart in the past, then you know that if the skimming script doesn’t load on a payment page, the actors cannot glean payment data.

However, the ease of compromise that comes from finding public S3 buckets means that even if only a fraction of their skimmer injections returns payment data, it will be worth it; they will have a substantial return on investment.

Perhaps most importantly, the widespread nature of this cyber attack illustrates just how easy it is to compromise a vast quantity of websites at once with scripts stored in misconfigured S3 buckets. Without greater awareness and an increased effort to implement the security controls needed to protect the content stored in these buckets from theft or alteration by malicious attackers, there will be more—and more impactful— cyber attacks using techniques similar to the ones outlined in this blog. 

Note: Amazon’s current protections include: 

1. All buckets are private and protected by default 
2. Warnings directly to the S3 console
3.  Account-level blocking 

S3 Security: More Than a Drop in the Bucket

A lot has been written on security and S3 buckets in the past. However, we feel that it’s essential to again put together the most up-to-date and conclusive advice in this article. Additionally, Amazon has written a general guide of items to check on for maintaining a secure S3 bucket setup titled, “How can I secure the files in my Amazon S3 bucket?”.

Prevention: Access Control

If a customer alters the default behavior of an S3 bucket and requires public access, setting up proper access control is critical. Access control for S3 buckets comes in different layers and options, from Amazon’s IAM (Identity and Access Management) policies, specific bucket policies, or general access control policies. These various policies can be overlayed and stacked depending on the bucket and how you want to set it up.

The type of access control policies you use will depend on whether you are using your bucket for public content or private content:

• Public content is generally world-readable and doesn’t contain sensitive data and is often used to store website content or large file storage that are accessible for everyone. For these, read access should be on.
• Private content is used in the processing or storage of information and is not meant to be public in any form. For these, read access should be off or very limited to specific individuals or processes using access tokens. By default, Amazon launches all S3 buckets as private.

We recommend these three crucial steps for access control to any S3 bucket:

1. Whitelist: Every administrator should very carefully monitor these controls and apply the concept of whitelisting rather than blacklisting, i.e., instead of listing who shouldn’t have access (a lot of people), list who should have access (a few people). Only give access permissions to the processes or individuals who absolutely need them. Review this list periodically to disable unwanted and unneeded access.
   
2. Limit those with write permissions: Never give write permissions to everyone. The cause of the thousands of Magecart compromises we are now observing from S3 buckets is administrators setting the access control to allow anyone to write content to buckets. Even if your bucket has information that anyone can access, it does not mean everyone should be able to modify the content.
3. Block Access: Account administrators can also block public access to prevent anyone in their account from opening a bucket to the public regardless of S3 bucket policy.

Mitigation: Logs, Review & Investigation

A compromised bucket is a painful moment for an organization, but it’s also a pivotal one. Once the compromise comes to light, it is essential to assess the full scope of the incident. While the exact list of questions may differ depending on the type of organization, we recommend first answering these basic questions when performing your investigation:

• What happened?: This question might seem too basic, but starting with a high-level incident description is extremely helpful.
• How did it happen?: Check logs and file modification timestamps, and try to save all this information to get a full picture of what happened and when. here are three ways for customers to enable this logging:
• • 1. https://docs.aws.amazon.com/AmazonS3/latest/dev/cloudtrail-logging.html 
  • 2. https://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.htm
  • 3. Response automated using Lambda: https://www.youtube.com/watch?v=8qQ5Ng-FGB0 
• What is the impact?: Did someone access, remove, or modify files they shouldn’t have, and what was the impact of this? Were processes deteriorated? Was public content affected resulting in theft such as Magecart skimming or other exposure? 

Some compromises might only result in external damage such as to the brand, or no damage at all, but it’s still essential for the security team to get answers. Groups like Magecart are always on the prowl and will be back to compromise you again if you don’t fix your exposures. Next time, the damage could be catastrophic. 

Once these questions are answered, the next step is mitigation. The basics of most, if not all, S3 bucket compromises we observe come down to improper access control. We suggest cleaning out the bucket and performing a new deployment of resources or simply setting up a new bucket. Customers can also enable versioning on their buckets to “roll back” objects to a known good version. As for the policies to secure your bucket, we recommend the following approach:

• Check the data classification. Can it be public or not?
• Do not give everyone write permissions.
• Only provide write permissions to specific users or hosts, and review their need for access periodically.
• Take a whitelist approach with the above items, only explicitly provide write and/or read access.
• Account admins can also enable account level blocks via https://aws.amazon.com/blogs/aws/amazon-s3-block-public-access-another-layer-of-protection-for-your-accounts-and-buckets/

Indicators of Compromise

The actors use a skimmer to exfiltrate payment data to their own servers. The following domains can be used to identify successful theft of information. The stolen data is sent in the form of a fake image that is included from the <baddomain>/img URL path.

One thing to keep in mind, this list is always expanding and won’t contain all the IOCs as the attackers keep registering new ones when we get them taken down with the help of AbuseCH & Shadow Server.

Domain	First seen
ww1-filecloud.com	2019-01-30
font-assets.com	2019-04-22
cdn-c.com	2019-05-13
cdn-imgcloud.com	2019-05-16
wix-cloud.com	2019-05-17
js-cloudhost.com	2019-05-17