It is very common to find Amazon S3 buckets misconfigured. We found one in a pen test this week.
We find them frequently. The most common things we see with S3 buckets is that people leave them open to the world and don’t encrypt them. The one we found this week also let us delete and write files.
Something cool about using a tool like JASP is that it will not only detect the kinds of settings we’re about to go deeper on, but it will also check them every day and alert you if something changes. Finally, you should be able to go look at reports to determine when the bucket first showed up with that config (though ideally you could get that from CloudTrail too).
Why encrypt S3 drives?
Since we’re in a shared file system in AWS, even though we expect AWS to prevent anyone from ever being able to read raw disk attached to any system we run in our account, because there could be shared host systems or infrastructure, we need to take extra precautions to make sure the data we write isn’t mistakenly available to another tenant. This is also why we advise encrypting any other data storage as well. Fundamentally, if a rogue user were able to identify a problem and break out of their guest instance to read raw disk, I don’t want them to know what I have. If I encrypt the disk, they shouldn’t be able to.
Thinking about permissions for S3 drives
Sometimes S3 drives are used to host files like images, videos or web content. In that case, you need the files to be readable to be able to use the service the way you want. In that event, we would recommend double checking that the directory is not listable. In general, we don’t want directories to be listable. We would also recommend using different buckets if you intend to have some files be readable and others not be. Finally, and this sounds obvious when we say it like this, but if the intent is for people to be able to read the files, don’t let them write or delete them!
Other times we have S3 buckets that are more like file sharing drives. We want a limited group of people to be able to read those buckets. Of course, we also want a limited number of people to be able to write or delete in those buckets as well.
A couple of things related to S3 and logging. First, your cloudtrail logs that get stored in S3 should not be publicly readable. Second, access to any non web files should probably have access logging going to cloudtrail. That will come in handy if you ever need to know who did read that file.
These are just some examples of things that JASP can identify for you related to S3 buckets. However you choose to manage your environment, you may want to implement some sort of automatic check.