We often hear about misconfigured Amazon S3 buckets exposing sensitive business and customer data, but there’s another present danger: Magecart attackers have been exploiting them to inject payment card skimming scripts into websites.
The problem with unsecured Amazon S3 buckets
“Amazon Simple Storage Service (S3) provides the ability to store and serve static content from Amazon’s cloud. Businesses use S3 to store server backups, company documents, web logs, and publicly visible content such as web site images and PDF documents,” Will Vandevanter, Security Researcher at Rapid7, explains.
Files within S3 are organized into “buckets”, which get assigned and can be accessed through a predictable URL. If a bucket is public and no access controls have been set up, anyone with an Amazon Web Services account can read or write content to them.
(By default, all newly created S3 buckets are configured to be private.)
Magecart’s new approach
According to RiskIQ researchers, a Magecart group has been automatically scanning Amazon S3 for unsecured buckets since early April 2019.
Since they started, they have managed to compromise a huge number of S3 buckets, impacting over 17,000 domains, including some websites in Alexa’s top 2,000 most visited sites.
“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. 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,” RiskIQ’s Yonathan Klijnsma pointed out.
“Perhaps most importantly, the widespread nature of this attack illustrates just how easy it is to compromise a vast quantity of websites at once with scripts stored in misconfigured S3 buckets.”
Advice for admins: Prevention and mitigation
Klijnsma advised Amazon S3 users to secure their buckets and files by using several mechanisms for access control (whitelisting, limiting write permissions, blocking access) and to check whether their buckets have already been compromised by checking logs and file modification timestamps.
RiskIQ has provided a list of malicious domains to which the stolen payment data is sent to, but noted that it’s sure to expand as new domains are detected.
Those whose buckets have been compromised should first secure them and then clean them, or set up new, secured ones.
“Customers can also enable versioning on their buckets to “roll back” objects to a known good version,” Klijnsma says, and advises administrators to check out Amazon’s guide for securing S3 buckets and files stored in them.