The first of the talks I attended was "Hacking AWS" by Daniel Grzelak, head of security at Atlassian. This one was a little bit over my head, as I'm not too familiar with AWS, so I'll try to reproduce the information as best I can. Please don't take anything I write as a direct quote from the speaker - if something sounds wrong, it's probably because I misheard / misunderstood. Also, a lot of the stuff he talked about has been scripted, so it's a fairly fast process.
He started by saying that when most people talk about hacking AWS, they usually mean looking through public git repos for AWS access keys and then spinning up a heap of EC2 instances to mine bitcoin.
1: Reconnaissance
How do you find targets? Look at the Amazon partner network, which lists a bunch of companies who use AWS! If they have documentation online, you can look through that and see if anyone has left something like an account number in there.
Most accounts will have the following URL pattern:
https://[account number].signin.aws.amazon.com
So you can use a tool like VirusTotal to scan through a list of account numbers and see which ones have a live sign-in AWS address.
The next step is to find a list of principals. AWS has a policy validation engine, which you can use to check if a principal exists. Depending on which principals are present, you may be able to work out which services they're using, as they'll tend to use the default principal name for that service.
One thing that AWS used to do was have an AuthenticatedUsers group, which wasn't just authenticated users for your account, it was any authenticated user in AWS! Fortunately, AWS no longer allows you to use the AuthenticatedUsers group, but that doesn't mean the stuff that was created before they changed that isn't still there. There are some S3 buckets floating around in AWS that have read-write access to anybody who has an AWS account.
2: Compromise
People leave their access keys all over the place: email, Slack channels, IRC, Confluence. If you can get access to this, then you're in.
There's an API call getCallerIdentity() which cannot be disabled and can be used to verify keys.
You can also register an S3 bucket with a legit looking name, and then host a webserver on it (because you can do that apparently) serving people a phishing page to gather their credentials.
He explained the concept of "dangling domains", which is where someone has created a DNS entry for their bucket. When they wanted to change that, rather than deleting the DNS entry, they deleted the bucket, so if you know the name of the original bucket, and manage to register it for yourself in time, you can take advantage of the old DNS entry and phish people in that way.
If you can get a webapp to access /latest/meta-data/iam/security-credentials you can also get credentials, because the meta-data service is used to handle validation.
You can also try a confused deputy attack.
(Note: the bad guy in this pic would be you, and the you in the pic would be your target)
Say your target happens to use some kind of service, and sets up a role in their AWS account for the service to use in order to get access to some data. If you (the attacker) manage to guess the name of the role, and your target didn't change the default external ID (which is used as a "password") then you can provide that name and password to the service as well. The service will use that role-name to access your target's data, effectively giving you access to it.
3: Logging
To hide your access, you can delete logs, move them somewhere else, or encrypt them and an encrypt-only key. If you're really sneaky, you can set up a lambda log handler that deletes logs as soon as they're created, which is sneaky because the lambda is so fast, it'll run faster than any log monitoring software, so it's less likely to be detected.
4: Exploration
List all the roles and groups
aws iam get-account-authorization-details
Find out where the company is located, potentially also including physical locations
aws ec2 describe-route-tables
Look at their support tickets - this one is great, because they may have included passwords in there, or if you manage to get write access to their support tickets, you can raise one of your own - perhaps to get the support team to create an account for you!
aws support describe-cases --include resolved cases
5: Elevation
We want to assume some of the roles we've found. Resources and users normally need policies saying they can access each other (i.e. resource says it can be accessed by me, and I say I can access the resource), but for resources and users on the same account, the permissions are additive. So if there's a user that has access to nothing, but a resource says anyone can access it, then the user can access it.
Look for passwords in cloud formation stack definition files. Some people will put passwords in their EC2 tasks.
aws ec2 describe-instance-attribute
Temp S3 bucket logins can also be found in the logs, so if you get to one in time, you may be able to use it to log into an S3 bucket.
Queues are a great place to inject malicious payloads, as the information used from a queue is often assumed to be safe.
#cloud-boothook
This executes every time an environment starts up, not just the first time it's created, so it's a great place to try and sneak your own things into.
6. Persistance (i.e. how to keep the door open for you to come back)
aws sts get-session-token --duration-seconds 129600
Creates a token that expires after a loooooooooooong time. You can't list these tokens, and the only way to get rid of them is to issue a command that kills all sessions created before a certain time - which will mean killing off legitimate sessions, too.
You could create your own user with an access key, but it's better to add your access key to other users.
Take all existing roles and add a policy that allows you to assume any role.
Modify all security groups to get access to all ports.
Use lambdas. They can run CLI calls without authentication. Or you can use one to recreate deleted users (he showed a funny one that would create two new users every time one of his created users was deleted). The great thing about lambdas is that they're very low key. A lot of attacks are usually detected when the account owner discovers a spike in their bill (usually due to EC2 instances being used to mine bitcoin), but the first million lambda calls are free, so it's really unlikely that your malicious lambda script is going to be detected.
7. Exfiltration (getting the data out)
Can copy data from one bucket to another using the AWS API.
Can create a replica RDS instance and set up a new root password.
AWS snowball - it's a service Amazon provides where you give them the name of an S3 bucket, and they will send you a physical copy!!!
------------------
As I mentioned the talk was a little bit over my head, but it was really interesting to see some of the ways in which you can get into someone's AWS account, and what you can do once you're in.
No comments:
Post a Comment