SSRF vs AWS Security

Hello everyone...

Just want to mention one attack-vector that is useful against AWS EC2 instances in some configurations. It is not rocket-science, but pretty fun and tell us about AWS Cloud security things and maybe can help us to do hardening. Actually I am talking about boring-sold SSRF vector. So if an attacker can do SSRF in our EC2 with SSRF what he can do?

Sometimes developers like to assign IAM Roles to instances. For example if it is deploy/build server, that needs to create new apps in AWS account or something else, doesn't matter - this just happens 8) And assigning roles to EC2 instances  - easiest way you can do it, because you do not need to think about how to deliver  Access Keys to the instance, how to rotate them and etc. Now back to SSRF...

So we have classic vulnerable App with boring XXE:

And...

Now it's time to remember about AWS meta-data service which is available from any instance. This server return meta-data for EC2 instance that called this API: http://169.254.169.254/latest/meta-data
Let's try:

Ok... so now you can get a  lot of information... but the funniest part - Temporary Access Key and Token for AWS API is also here http://169.254.169.254/latest/meta-data/iam/security-credentials/<ROLE_NAME>...

Wow, 'apache' user got this key... and if you think that by default access with this key limited only from EC2 instance - you wrong. Please feel free to copy this key and use it from any place.

Config:

Trying:



















Now we can do anything that allowed by Policy/Role that assigned to hacked instance.

Let's summarize problems:

1) Anyone can get Access Key: nobody, root, apache... it's not based on OS security.
2) By default this Key works from any IP, not only from instance (but you can try to configure it in Policy at least)
3) You can't revoke this Key. You can remove Policy from the group - yes.
4) You do SSRF in your code, smart-ass!

So this is just  example how SSRF + lack of hardening on AWS account can ruin you life...



Solution for item 2, edit Policies that assigned to Role:

    "Condition": {
        "IpAddress": {
        "aws:SourceIp": "10.90.X.X"
         }
     }

Then you safe:

But in fact not - if box compromised or with the saem SSRF you can makes RESP API calls from the pwned isntance...

As final notes:

1) Check roles that assigned to instances. Less privileges... Better no roles...
2) If you can limit access for this policy by SRC IP -  do it, so only instances with this Role can access API.
BUT remember, if you have SSRF, than attacker can do API calls from tsame instance by same SSRF...
3) Do not code SSRF ;)

P.S. Thanks to Erian Nader from HERE Security team for helping with this material...

P.P.S. And of course, it's not about only SSRF - if instance pwned, then same risks applied. So be careful with Instance's roles!