Picture the scene, your company has decided to use AWS to host their new green field application. You think to yourself:
“Great news! I’ve wanted to use AWS for a while now and here’s my chance.”
But as the buzz starts to wear off, you have to start asking real questions about how to host your application in the cloud and you naturally start thinking about security. After all you’re hosting your application on somebody else’s computers right?!
Can AWS Be Hacked? In short, the security responsibility is divided in ownership between the customer and the AWS team. Where AWS will impose strict standards to ensure physical infrastructure is kept secure. However customers are responsible for managing OS patches and firewalls.
Basically this means that AWS puts a chunk of the responsibility for securing a product in the hands of their customers. This makes sense when you think about it.
Otherwise AWS would be culpable every time a customers security is breached!
If you keep reading I’ll show you how hackers would try breach AWS security and a few simple tricks to avoid it
Ok what do I mean by this? It’s important to understand the difference between a hack to an individual AWS account and a hack to AWS as a whole.
Put simply, AWS provides services to clients. Each of those clients has 1 or more accounts. The client is responsible for ensuring the security of the account.
When a hacker breaches the security of one of these accounts this is known as a account hack.
This is where AWS as a whole is breached. This would be for instance where a hacker is able to successfully breach the underlying infrastructure that exists to support all its customers.
To this date and the best of my knowledge this kind of breach has never happened and for good reason too. Because if such a security breach were to occur, AWS’s customers confidence in their cloud provider could be undermined.
Ok so now you know what the difference between the types of hacks are. Let’s take a look at a few notable hacks of AWS clients in recent years.
A quick reminder, these are account hacks and not AWS infrastructure breaches.
Tesla cars are laptops on wheels. Features such as semi autonomous driving mean they rely massively on data and machine learning.
As such they use AWS as their cloud provider to capture and process this data. In early 2018 a cyber security startup called RedLock discovered a hack in Tesla AWS cloud which allowed them to Tesla proprietary data around things like vehicle servicing, the telemetry from Tesla cars and mapping data.
RedLock discovered an AWS user account that has no password attached to it. As such the hackers gained access to the account and sensitive company data.
Why it was later revealed that this account was only a developer account and not attached to live customer data it still highlights the danger of hackers gaining access to customers data. You can only imagine the havoc someone or a group with malevolent intentions could do.
So in the tesla example, the hackers simply logged in to account that didn’t have a password. A simple oversight that is easily rectified. Where as with Uber their breach was a tad more overt.
Allow me to elaborate…
In a very public breach Uber had to notify 57 million of its customers that their data had been breached. Worse was the fact that they were only notified some time after the fact. Since it emerged that Uber had paid the hackers $100,000 dollars in order to keep the breach quiet.
It gets worse when the cause of the hack was exposed as Uber developers publishing the access keys to their AWS account on GitHub!
Hackers have automatic scraping tools that scan github accounts for markers that indicate developers have unintentionally uploaded their AWS access keys.
Typically hackers will then do one of 2 things.
- Launch hundreds of VMs and mine cryptocurrency.
- Steal valuable data and either sell it on the black market or sell it back to the company it has taken it from.
I alluded to this in the previous section but thought it worth going into a little more detail about the particulars of this method of attack.
Essentially developers would embed the access keys and tokens to their user accounts in the code they were working on and check this into a publically viewable source repository such as Github.
The reasons behind why a development team might do this could be many. But the usual explanations are that they are in the early stages of a project and did it for convenience. Or simply it was a genuine mistake and somehow got past a code review.
Hackers then scan through tens of thousands of GIThub projects search for these mistakes. Looking for keywords like ‘access key’ & ’token’. When they find them they then attempt to connect to those accounts.
Access key example: 23478207027842073230762374023
If its successful then you’ve been hacked.
You may be thinking you’re tech savvy and wouldn’t fall foul of one of these scams. But they are getting more and more sophisticated as time goes on. It only takes a moment of weakness where you drop your guard and all of a sudden you’ve given away your details.
Don’t underestimate these scams.
Compounded on this on the fact that AWS can be fairly liberal with their sending of emails then it’s easy to see that when sent on mass, it’s likely that a small percentage of people will fall for it.
You’ll be directed to a very convincing website that looks like AWS but definitely isn’t AWS. Then you’ll be asked to reset your password or something along those lines. As which point you enter your password and username and they have you.
While I can’t speak from personal experience when it comes to getting refunds for hacks. I have experienced going through the support process for inadvertently provisioning resources by accident. Detailed in AWS support plan – a detailed explanation and comparison of what they offer.
In that particular case, I was successfully refunded even though it was my mistake in the first place. So AWS can be quite forgiving. However my advice would be not to risk it and just ensure that you follow common sense rules for securing your AWS accounts.
While it’s not the best idea to dwell on just what the intent of a nefarious hacker might want from you. It’s probably wise to at least understand at a high level what their motivations might be.
Ultimately they want to profit from the activity, so money is primarily their motivating factor. Unless of course its some rogue government intent on learning secrets, which is a whole different matter altogether.
So can a hacker profit from your account?
You data can be valuable. Not only to you but also other parties.
In the first instance, the hackers may try and sell you back your own data. This makes sense since it’s likely that your data will be most valuable to you.
A recent example of this was found in the British NHS where hackers encrypted hospital data and demanded money for the data to be released. This was however not AWS hosted.
Ec2 instances run at the heart of AWS and they are essentially virtual machines. With this compute power hackers can exploit your account to mine things such as cryptocurrency.
While this wouldn’t produce results with a single instance. When you consider that hackers could provision potentially thousands of Ec2 instances all mining currency in unison 24/7. Your security breach might only be discovered after a few days.
But in that time the hackers could of potentially racked up a huge bill on your account. Especially if they are provisioning expensive high performance Ec2 instances with large amounts of ram and CPU cores.
Now that I’ve sufficiently scared the wits out of you we might as well look at some simple ways to secure your account and prevent hacks and help secure your account.
Most of these recommendations are fairly straight forward and can be implemented immediately.
MFA short for Multi Factor Authentication, would have prevented in both cases the examples described above of Tesla and the Uber breach.
So what is it?
Essentially it means you require 2 methods or authentication to confirm you are who you say you are. This can be your normal username and password, plus a unique code text via text message or an app that supports 2 factor such as google authenticator.
This means that even if your details were leaked you would be safe as the hacker wouldn’t have the unique access code.
I’ll be including a section about MFA in my upcoming totally free course on passing the architect associate exam. Check out the course section for more details.
Another option is to monitor when users are logged in and get notified when unusual activity is detected.
For instance you could monitor when sudden CPU spikes occurs. Or when billing limits are reached.
If something like this did happen you’d be notified via email and could act accordingly.
Finally there’s plenty of common sense best practices you can follow and teach your team to reduce your exposure to these sorts of attacks.
- AWS lets you rotate your access keys, do the on a regular basis
- Store your keys in the AWS KMS service
- Put policies in place not to email keys between employees.
- Delete the access keys for your ROOT account
- Code reviews when checking code into source control
- Enable strong password standards on your IAM console
- Use a password manager for storing your passwords
It’s easy to read all this and think negatively and run for the hills.
Managed correctly AWS accounts can be EXTREMELY secure. It’s just a matter of following best practice and the result will be a system that you can be confident to build your next killer app upon.
I hope this have been useful, there’s a lot of extra info out there on AWS and cloud security. If you have any other questions around security in the cloud let me know in the comments below and I’ll post a new article addressing them in the future!