scenario/sqs_flag_shop

[3iuy-prog]

This is the SQS_FLAG_SHOP scenario, may be the last scenario for our team.

In this scenario, attacker manipulates its own data in the DB by sending an inappropriate message to AWS SQS.

1. The attacker accesses the web page and identifies the features first.
2. The attacker checks the privileges it has.
3. Find the web source code. By analyzing the source code, the attacker checks the format of message sent to the SQS service.
4. Assume the the sending message role about SQS service.
5. The attacker, who possesses the necessary permissions, sends a forged message to the SQS service queue.
6. Check the changed assets, purchase FLAG and check the secret-string.

Any comments are welcome. Thank you. :)

[andrew-aiken]

Created a discord thread for easier communication

[Hosim33]

Thank you for suggesting what needs to be fixed. We've made some changes to fix that it takes time to destroy scenarios. If there's anything else to fix, please let us know!

[andrew-aiken]

Few things

• The lambda does not have access to the EC2 with the change to whitelisting, this could be fixed by reversing the SG change in 3ab49c877c3454cb45659d71a786fc8cf0c7501d
• depends_on = [aws_vpc.cg-vpc] can be removed from the lambda section
• CloudWatch log group does not get removed /aws/lambda/lambda_function

[Hosim33]

We've fixed the few things. Thank you.

[andrew-aiken]

• I think you have the wrong CloudWatch log group name it should be /aws/lambda/lambda_function not cg-cloudwatch-log-group
• In the vpc.tf file it creates two network endpoints (interfaces) are they used by anything?

[Hosim33]

I deleted the vpc endpoint and modified the log gruop name to reflect your advice. Thank you.

[jdearmas]

This pull request was merged manually at 1049b19