Even though cloud security is a top priority for many companies today, cloud breaches are alarmingly common. It seems that no matter how many businesses get hacked, some companies are not learning from others’ mistakes.
There are many ways to fall victim to a cloud attack. A serious competitor might stop at nothing to gain an advantage over you. A hacker might try to extort you. Or, a disgruntled employee who believes they were terminated unfairly and knows your cloud infrastructure inside and out might see a perfect opportunity to cause harm to your business. Because business secrets are so sensitive and compliance policies are getting stricter by the day, a small gap in your cloud security can expose your company to serious threats.
This article will look at three cloud breaches that have occurred recently, examining both what happened and how those breaches could have been prevented by appropriate security measures.
AWS Server Breached by a Hacker Group
Earlier this year, a group managed to hack into an AWS server owned by an unnamed business. The hackers gained full access to an EC2 instance and installed a rootkit (a set of software that is used to provide access to machines) on it. This allowed them to remotely control the affected server. Ultimately, hackers used this compromised machine to send themselves sensitive information from inside the target’s AWS cloud environment.
Usually, this kind of breach happens when there is a flaw in the firewall system resulting in a “gap” that can be used to gain access to a server. AWS provides various firewalls that protect your traffic both on the network and on the application layer. In addition, services like WAF, Security Groups (SG), and Network Access Control Lists (NACL) can provide additional security. But, a company’s overall security still needs to be completely airtight or a skilled hacker can access your environment and cause a lot of harm to the business by stealing or destroying data. Even though AWS provides these services, you still need to configure them properly. In this particular case, however, the firewall was not the issue. Instead, the security software company Sophos has claimed that this breach was effectuated by a customized version of a trojan—a malware designed to look like legitimate software that is meant to circumvent defenses and provide access. Even with the proper firewalls in place, it’s possible that your EC2 backup instances could still be hacked using this trojan.
Whether this is actually true or not is unknown. Regardless, there are steps you can take to limit further access and subsequent damage when an AWS server is compromised. The most important one is to make sure that your internal network is properly segregated. Levels of trust and privilege should exist between various servers, and only the bare minimum access should be granted.
Bharat Interface Money User Data Exposed
In April of 2020, the data of 7 million Bharat Interface Money (BHIM) mobile app users were exposed to the internet. The breach revealed sensitive personal information, including photos, financial details, proofs of residence, and bank records. This left millions of people in India susceptible to fraud.
After a short investigation, it was determined that the breach was made possible by a misconfigured S3 bucket—one that was publicly available. This bucket contained a CSV file listing the various businesses who had signed up to use BHIM along with their UPI (Unified Payment Interface) ID numbers. Because UPI is the instant, real-time payment system that facilitates interbank transactions in India, these ID numbers are incredibly valuable and can be easily abused by hackers.
Misconfigured buckets, like this one, were actually quite common in the past. Creating a bucket takes less than a minute, and few people stop to make sure that their bucket’s configurations are properly set up. Originally, all of AWS’ buckets were publicly accessible by default. Inexperienced team members frequently created needed resources without checking their configurations. This oversight left a lot of open buckets out there ready to be looted.
For this reason, AWS changed these settings. Now, all buckets are created to be private, and additional steps need to be taken to open them up to the world. Of course, while this step prevents this particular issue from happening again, this is not the only type of misconfiguration. It is, therefore, of utmost importance that the employees who set up your AWS environment are familiar with the cloud and its architecture.
Capital One Breach
In July of 2019, an individual managed to obtain the personal information (social security numbers and bank account numbers) of more than 100 million Capital One Financial Corporation clients. This was a massive hack, and the fact that it happened to a giant banking corporation—the kind in which security is expected to be at the highest level—raised eyebrows.
The attack was made possible by using a server-side request forgery (SSRF) vulnerability. After the hacker got access to the instance, they collected the AWS programmatic key from the instance metadata and obtained permissions to access the private S3 buckets from which the data was stolen.
You can’t always protect access to your cloud servers. But, you can ensure that an attack causes as little damage as possible. In this particular case, the damage occured because the instance had access to S3 buckets with lots of personal data. It’s important to consider how many permissions should be granted to any one server. If, for example, you need a server to read data from a particular S3 bucket, only read permissions should be given, and only for that bucket. You should not grant additional permissions, like write permissions (which can be used to delete your data), and that server should definitely not have access to other buckets. These restrictions just might save you, even if you’re hit by a serious hack.
This was just a sampling of (reported!), recent attacks
We examined just three different situations in which improperly configured resources on AWS led to serious vulnerabilities that were exploited for malicious purposes, but there are plenty more. These are not rare occurrences; attacks like these happen daily and are increasing at an alarming rate, and we are only seeing reported cases. Only attacks on major companies tend to make headlines, if that, so we only see a very small part of the picture, while many companies do not report on these attacks at all. Significant numbers of smaller companies have been seriously affected or even put out of business by these kinds of hacks and choose not to go public.
When working with AWS or any other public cloud service, make sure you know what you’re doing. Either hire an experienced team or educate yourself by getting an AWS certification. Hiring an outside consultant can also be of great help. It’s up to you to ensure the security of your company, and, with it, the continuity of your business.
More in cloud security:
Amazon VPC: The Foundation of AWS Cloud Security
Amazon Inspector and CloudTrail: a Holistic Approach to Security and Compliance Requirements
N2WS AWS S3 Replication – Using N2WS S3 Replication to Synchronize Your Crucial Data
