A credit card skimming crime syndicate is dippping into misconfigured Amazon Web Services (AWS) S3 (simple storage service) buckets to pilfer credit card data, RiskIQ security researchers said in a recent report.
In some ways, it’s surprising that the Magecart cartel or other bad actors took so long to capitalize on AWS S3 configuration errors, which for the past two years have left open one door after another to unsecured data. According to RiskIQ, the attackers have been actively skimming for a long time with other techniques but in early April they began homing in on unsecured AWS S3 buckets mostly at e-commerce sites with the singular purpose to heist bank card credentials.
No one knows how many buckets are out there primed for compromise but staggering is the descriptor that comes to mind.
According to the report, the Magecart actors are deploying a “spray and pray” tactic, forgoing targeted attacks for mass exposure, similar to what spammers relied on for years. There’s a catch: If the skimming script doesn’t load on a payment page, the actors can’t lift payment data, RiskIQ threat researcher Jonathan Klijnsma said. Because many of the compromised scripts don’t load, the gang’s goal is to snare enough sites that do process credit cards.
“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,” Klijnsma said. “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— attacks.”
RiskIQ said it is working with Amazon and the victims to address the skimmer injections and misconfigured S3 instances as they observe them. In May, Amazon posted a checklist of items to maintain a secure S3 bucket.
The security specialist offered up some suggestions for AWS S3 bucket security:
- Apply whitelisting rather than blacklisting (list a few people who should have access): Only give access permissions to the processes or individuals who absolutely need them.
- Limit those with write permissions. Never give write permissions to everyone.
- 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.
- Assess the full scope of the incident. Find out what happened, how did it happen, and what’s the impact? Check logs and file modification timestamps, and try to save all this information to get a full picture of what happened and when. Did someone access, remove, or modify files they shouldn’t have, and what was the impact?
- Most S3 bucket compromises boil down to improper access control. Clean out the bucket and perform a new deployment of resources or simply set up a new bucket, RiskIQ recommends.
“Groups like Magecart are always on the prowl and will be back to compromise you again if you don’t fix your exposures,” Klijnsma said.