On July 19, Twilio was the victim of a hacking attack that made headlines. An attacker uploaded malicious code to an SDK that Twilio maintains. The injected exploit made a victim’s browser load code that was possibly intended to steal information from them as they shopped online.
Three days after the attack Twilio released an Incident Report outlining the cause. While one might imagine a misguided genius or rogue nation state to be the cause, it was in reality much more mundane—a misconfigured AWS S3 bucket.
The bucket was intended to be read only but was accidentally changed to read/write in 2015. Yes, you read that correctly. This code has been sitting exposed in S3 for 4 years, and Twilio was unaware of this fact! While surprising, this is all too common.
So far in 2020, Test Double has found misconfigured storage buckets that allowed unauthorized access in two separate DevOps audits.
OK, but how do you examine your buckets?
So how do you ensure your company’s name isn’t in the news tomorrow for this type of breach? Well, it is actually fairly straightforward. You just have to put in the effort.
The first step is to review all your current cloud storage buckets.
Make sure that bucket permissions follow the Principle of Least Privilege (PoLP). If you have a large number of buckets, you might opt to use a scanner. While they cannot tell you whether you have granted too much permission, they can at least tell you which ones are open to the public. There are many open source scanners available. Search to find one you are comfortable with based on your skill set.
Once you are sure that your buckets are currently protected, the next step is to ensure ongoing protection.
Ideally, you would now turn to Compliance as Code (CaC) to regularly test your infrastructure. Chef’s InSpec is a great tool for this. You can use it to test for common security (mis)configurations in most cloud providers. If you have the resources and capabilities available, instituting Compliance as Code is a highly recommended complement to your Infrastructure as Code (IaC) pipeline.
Regardless of whether you take that step, you should definitely set up monitoring to make sure the permissions on your S3 buckets remain as you intend. In AWS this means setting up a CloudWatch Alarm on changes to bucket permissions. Here are instructions on doing that in the AWS console.
Once CloudWatch Alarms are configured, make sure you have a policy in place on how you will respond when the alarm is triggered. Furthermore, make sure your team is aware of the policy and trained on it.
Finally, set up a recurring event on your calendar to manually review bucket permissions as you did in the first step. Also, review the response policy and all the CloudWatch alarms to validate to whom they are being sent. It is not going to do you any good if an alarm triggers at 2 AM and sends a text to an ex-employee’s phone.
While there are a few steps involved here, overall this is fairly simple to implement and well worth the effort if the downside means getting hacked. In today’s environment, losing confidential or sensitive information is not only costly financially but also in terms of lost client trust.
Don’t be a topic on the next cyber security news cycle, take the time to audit your infrastructure today!
