Over the past few years we have seen plenty of news about data being stolen from misconfigured Amazon S3 buckets and other cloud based services. Now attackers are figuring out ways to further abuse these systems beyond simply stealing data.
Magecart, a threat actor group involved in a large amount of attacks, has a currently active campaign targeting S3 hosted sites; the attack infected these sites with malicious javascript that steals customer’s credit card data.
Their attack methodology involves specifically looking for buckets that have write permissions enabled for everyone. When one of these buckets is found, it looks for javascript in the bucket – increasing the likelihood that it’s being used to host a site, or serving assets for a site hosted elsewhere. Javascript files are then edited by the attacker and the Magecart malicious javascript is injected into it.
The javascript runs in the customer’s browser, looks for specific forms, and sends that data to another server when it is submitted. Without detailing this further, as there are many other good breakdowns of exactly what this attack entails that are available. The key take away here will be what can you do to make sure a site you have isn’t hosting this code.
Many of the buckets subject to this attack were exposed to the public on purpose, since they are hosting content that should be publicly available. The issue here is that the buckets were given permissions that were too elevated for their function – specifically read/write everyone, instead of read everyone.
Amazon seems to have taken some steps to alleviate the problem recently; when creating new buckets, the wizard is more detailed and explicit about bucket permissions. In the past, permissions depended on the knowledge level of the person implementing them. However, it can still be confusing if you are not familiar with the terminology, or you have not taken a deep dive into the documentation.
I believe some misconfigurations are caused by confusion about permission options as well as logic of how these permissions are applied. If you are doing anything with configuring policies and ACLs in AWS, please read over the Policy Evaluation Logic documentation, it will greatly aid in configuring your environment correctly.
Additionally, since this attack is hitting any found javascript in S3 buckets, there’s a chance that your site is using one of these files by loading it from an external domain – even though you are not using AWS at all.
What can you do about this? There’s an argument here that ideally you shouldn’t use any externally hosted javascript because you have no direct control over it, and it can change at any time. This isn’t going to happen though, certainly not overnight. Fortunately some new features have been making it into browsers that allow you to specify the hash of the external resource file in your HTML source, so the browser can make sure it got an untampered file. Great news also that almost every modern browser supports this feature.
I hope this helps you understand a little more about this threat and how to mitigate it. If you have any questions, or need help with this issue, or AWS security in general, please contact us at info@microsolved.com.