Is the deployment secure from outside threat?

[Yogesh Patel]

I am wondering about the situation that someone can try to scan and find application urls for AWS Goat deployment and then through Privilege escalation get Admin account rights on my AWS tenant. I just want to understand if this deployment would be safe from outside threat.
PS - I am quite new to Cloud Security and I think your project has nailed it. Its exactly what I was looking for breaking into Cloud Security . Thank you.

[Jeswin Mathai]

AWSGoat, upon deployment, provides a web application URL, and further enumeration/exploitation can be done from the web app. An external attacker/user will not have direct access to this URL. Therefore, they would have to depend upon guesswork, dictionary attack, and brute forcing.

Overall, AWSGoat has three entry points:

• API Gateway (URL consists of a 10-character randomly generated ID, Stage Name, Resource Name)
• S3 Buckets (Bucket name consists of specific strings suffixed with the AWS account ID, which is a 12-digit number)
• EC2 Instance (Only supports key-based authentication, and although the SSH key is available on this GitHub repository, the username is uncommon)

Attackers constantly scan service-specific AWS endpoints/IP addresses (looking for misconfiguration and vulnerable applications). In the case of AWSGoat, due to the naming conventions and randomness, it would be extremely difficult to identify the entry point on guesswork alone.

The difficulty would decrease if the attacker targets AWSGoat-specific deployments, i.e., including our naming convention into wordlists, targetting instances with our specific username and SSH keys, etc. Still, the likeliness of finding an AWSGoat entry point is less.

AWSGoat and other vulnerable by-design projects are assumed to be deployed on an account that does not contain sensitive information. Attackers assuming the same won't target such specific deployments (because they would end up wasting computation power that otherwise would have been used on a high-value target)

There is also a possibility that users accidentally leak sensitive information. E.g., while writing a blog, a screenshot might reveal an active URL. Similarly, a recorded video might reveal visited URLs, paving the path for a compromise. With all vulnerable projects, we must be cautious and destroy the deployment when not in use.

In the case of AWS, I would recommend setting up one dedicated account for experimentation and similar deployments. It will reduce the blast radius significantly. One of the easiest approaches is mentioned below:

• Create an AWS Organization
• Create an AWS Account inside the organization
• Use the newly created account.

The member account can be created with an alias of your primary email. For e.g, if you have an AWS account with the email [e-mail], you can use an alias such as [e-mail], [e-mail], etc.

From a user security standpoint, we do have plans for introducing IP-based restrictions and alerting in future updates.

I hope this helps! Please let me know if you have any questions.