flaws2.cloud (Level 1)
Level 1 (http://level1.flaws2.cloud/)
a) We are provided with a form that intakes digits only. Upon checking we came to know that validation is being performed only on the client side using javascript. This can be verified by viewing the HTML source of the page. Method validateForm() is performing this validation.
b) We can bypass this check just by modifying the HTML. We need to remove the “onsubmit” event listener from the form. OR you can directly intercept the valid form request in the burp suite.
c) Now if we try to pass characters that are not digits, we will get an error with debugging data including AWS Secrets.
d) Configuring the credentials in aws cli-
aws sts get-caller-identity --profile test
e) Enumerating permissions of our creds-
./bf-aws-permissions.sh -p test -r us-east-1Tried all the allowed permissions but didn’t find anything interesting.
f) Checking the wapplyzer we came to know that this is indeed an s3 bucket.
aws --profile test s3 ls level1.flaws2.cloud
aws --profile test s3 cp s3://level1.flaws2.cloud/secret-ppxVFdwV4DDtZm8vbQRvhxL8mE6wxNco.html /tmp/html
http://level2-g9785tw8478k4awxtbox9kk3c5ka8iiz.flaws2.cloud/Lesson learned (Source - challenge 2)
Whereas EC2 instances obtain the credentials for their IAM roles from the metadata service at 169.254.169.254 (as you learned in flaws.cloud Level 5), AWS Lambda obtains those credentials from environmental variables. Often developers will dump environmental variables when error conditions occur in order to help them debug problems. This is dangerous as sensitive information can sometimes be found in environmental variables.
Another problem is the IAM role had privileges to list the contents of a bucket that wasn’t needed for its operation. The best practice is to follow a Least Privilege strategy by giving services only the minimal privileges in their IAM policies that they need to accomplish their purpose. AWS CloudTrail logs can help identify past usage (leveraged by Duo Security’s CloudTracker) or AWS Access Advisor (leveraged by Netflix’s RepoKid).
Finally, you shouldn’t rely on input validation to happen only on the client side or at some point upstream from your code. AWS applications, especially serverless, are composed of many building blocks all chained together. Developers sometimes assume that something upstream has already performed input validation. In this case, the client data was validated by Javascript which could be bypassed and then passed into API Gateway and finally to Lambda. Applications are often more complex than that, and these architectures can change over time, possibly breaking assumptions about where validation is supposed to occur.
Thanks for reading!! Please give your feedback.
