Penetration Test Summary ReportAVP-####: [SERVICE NAME]Submission date: DATE | Version: 1.yPrepared for:Wesley Snell, Jr. Sr. ManagerAWS Security – AppSecwessnell@amazon.comPrepared by:Coalfire Systems, Inc.<Name><Title>Table of Contents TOC \o "1-4" \h \z \u Executive Summary PAGEREF _Toc197509203 \h 5Project Overview & Objectives PAGEREF _Toc197509204 \h 5Scope and Attack Scenarios PAGEREF _Toc197509205 \h 5Assumption and Constraints PAGEREF _Toc197509206 \h 5Findings Summary PAGEREF _Toc197509207 \h 6Mandatory Test Cases (MTCs) PAGEREF _Toc197509208 \h 7MTC 1: Basic IAM Permissions Verification PAGEREF _Toc197509209 \h 7MTC 1A: Explicit Allow PAGEREF _Toc197509210 \h 7MTC 1B: Explicit Deny PAGEREF _Toc197509211 \h 7MTC 1C: Implicit Deny PAGEREF _Toc197509212 \h 8MTC 2: PassRole Permissions PAGEREF _Toc197509213 \h 8MTC 2A: Explicit Allow PAGEREF _Toc197509214 \h 9MTC 2B: Explicit Deny PAGEREF _Toc197509215 \h 9MTC 2C: Implicit Deny PAGEREF _Toc197509216 \h 10MTC 3: Passrole Confused Deputy PAGEREF _Toc197509217 \h 10MTC 3A: Confused Deputy PAGEREF _Toc197509218 \h 10MTC 4: Resource Policy Constraints PAGEREF _Toc197509219 \h 11MTC 4A: Explicit Allow in Resource Policy and Empty Principal Policy PAGEREF _Toc197509220 \h 11MTC 4B: Wildcard Allow and Explicit Deny in Resource Policy, Empty Principal Policy PAGEREF _Toc197509221 \h 12MTC 4C: Empty Resource Policy, Empty Principal Policy PAGEREF _Toc197509222 \h 12MTC 4D: Empty Resource Policy, Explicit Allow in Principal Policy PAGEREF _Toc197509223 \h 13MTC 4E: Explicit Allow in Resource Policy, Explicit Deny in Principal Policy PAGEREF _Toc197509224 \h 13MTC 4F: Confused Deputy Key Enforcement PAGEREF _Toc197509225 \h 14MTC 4G: Confused Deputy Key Validation PAGEREF _Toc197509226 \h 14MTC 5: Resource-Level Permissions PAGEREF _Toc197509227 \h 15MTC 5A: Explicit Allow Rule for an Action on a Different Resource PAGEREF _Toc197509228 \h 15MTC 5B: Explicit Allow Rule for an Action on the Target Resource PAGEREF _Toc197509229 \h 15MTC 5C: Wildcard Allow with Explicit Deny for the Target Resource PAGEREF _Toc197509230 \h 15MTC 5D: SDF Adherence PAGEREF _Toc197509231 \h 18MTC 6: Principle of Least Privilege and SLR Audit PAGEREF _Toc197509232 \h 19MTC 6A: Adherence to the Principle of Least Privilege PAGEREF _Toc197509233 \h 19MTC 7: Resource Policy Escalation PAGEREF _Toc197509234 \h 19MTC 7A: Resource Policy Allowing Access to the Resource It’s Attached to PAGEREF _Toc197509235 \h 20MTC 7B: Resource Policy Allowing Access to a Different Resource PAGEREF _Toc197509236 \h 20MTC 7C: Resource Policy Allowing Access to a Resource Belonging to a Different Service PAGEREF _Toc197509237 \h 20MTC 8: Confused Deputy PAGEREF _Toc197509238 \h 21MTC 8A-B: Quality Assurance PAGEREF _Toc197509239 \h 21MTC 8C: Pass a Resource from Another Account with a Policy Allowing the Principal PAGEREF _Toc197509240 \h 21MTC 8D: Pass a Resource that Belongs to Another Account PAGEREF _Toc197509241 \h 22MTC 8E: Shorthand Identifier and ARN Check PAGEREF _Toc197509242 \h 22MTC 9: Customer S3 Buckets Interaction PAGEREF _Toc197509243 \h 23MTC 9A: Specify an S3 Bucket the User Has Access to PAGEREF _Toc197509244 \h 23MTC 9B: Specify an S3 Bucket in the Same Account the User Does Not Have Access to PAGEREF _Toc197509245 \h 23MTC 9C: Specify an S3 Bucket in Another Account that the User Should Have Access to PAGEREF _Toc197509246 \h 24MTC 9D: Specify an S3 Bucket in Another Account that the User Should Not Have Access to PAGEREF _Toc197509247 \h 25MTC 9E: Bucket Sniping PAGEREF _Toc197509248 \h 25MTC 9F: Bucket Monopoly PAGEREF _Toc197509249 \h 26MTC 10: IAM IP Address Conditionals PAGEREF _Toc197509250 \h 26MTC 10A: Allowing Correct IP Address PAGEREF _Toc197509251 \h 27MTC 10B: Requiring Localhost IP Address PAGEREF _Toc197509252 \h 28MTC 10C: Spoofing Headers to Bypass Requiring Localhost IP Address PAGEREF _Toc197509253 \h 28MTC 10D: Spoofing Headers to Bypass Not Localhost IP Address PAGEREF _Toc197509254 \h 31MTC 10E: Not Allowing Caller IP Address PAGEREF _Toc197509255 \h 31MTC 11: HTTP Protocol Handling PAGEREF _Toc197509256 \h 34MTC 11A: Protocol Switching PAGEREF _Toc197509257 \h 34MTC 11B: HTTP Request Smuggling PAGEREF _Toc197509258 \h 35MTC 12: Nmap Scan PAGEREF _Toc197509259 \h 38MTC 12A: Nmap Scan PAGEREF _Toc197509260 \h 38MTC 13: AWS Organizations Integrations PAGEREF _Toc197509261 \h 39MTC 13A: Data Aggregation PAGEREF _Toc197509262 \h 39MTC 13B: Delegated Admin Permissions Revoking PAGEREF _Toc197509263 \h 40MTC 13C: SNS Notifications Organizational Integration PAGEREF _Toc197509264 \h 41MTC 13D: SCP Adherence PAGEREF _Toc197509265 \h 41MTC 13E: Organizational Linked Accounts Authorization PAGEREF _Toc197509266 \h 42MTC 13F: Organizational Structure Authorization PAGEREF _Toc197509267 \h 42MTC 13G: Service Cleanup PAGEREF _Toc197509268 \h 43MTC 13H: SNS Notifications Duplicates PAGEREF _Toc197509269 \h 44MTC 13I: Admin-Only Actions Authorization Control PAGEREF _Toc197509270 \h 44MTC 14: Tag-Based Access Control PAGEREF _Toc197509271 \h 44MTC 14A: ResourceTag Explicit Allow PAGEREF _Toc197509272 \h 44MTC 14B: ResourceTag Explicit Deny PAGEREF _Toc197509273 \h 45MTC 14C: RequestTag Explicit Allow PAGEREF _Toc197509274 \h 47MTC 14D: RequestTag Explicit Deny PAGEREF _Toc197509275 \h 48MTC 14E: Tagkey Explicit Allow PAGEREF _Toc197509276 \h 49MTC 14F: Tagkey Explicit Deny PAGEREF _Toc197509277 \h 49MTC 14G: Tag-On-Create Resource Tagging Permissions PAGEREF _Toc197509278 \h 50MTC 14H: Service-Specific Condition Keys Explicit Allow PAGEREF _Toc197509279 \h 52MTC 14I: Service-Specific Condition Keys Explicit Deny PAGEREF _Toc197509280 \h 52MTC 14J: Tag Based Race Conditions PAGEREF _Toc197509281 \h 53MTC 14K: Tag-On-Create Support PAGEREF _Toc197509282 \h 54MTC 14L: ResourceTag Mutation Without TagResource API PAGEREF _Toc197509283 \h 55Attack Scenario Test Results PAGEREF _Toc197509284 \h 56TLS Versions PAGEREF _Toc197509285 \h 56API Fuzzing PAGEREF _Toc197509286 \h 57Custom Authorization and Authentication Testing PAGEREF _Toc197509287 \h 59Authentication PAGEREF _Toc197509288 \h 59Removing all authentication tokens: PAGEREF _Toc197509289 \h 59Inserting corrupt authentication token values: PAGEREF _Toc197509290 \h 59Providing expired authentication tokens: PAGEREF _Toc197509291 \h 59Attempting authentication with an unexpected mechanism (not Sigv4) PAGEREF _Toc197509292 \h 59Authorization PAGEREF _Toc197509293 \h 59Account Config Review PAGEREF _Toc197509294 \h 60Code Review PAGEREF _Toc197509295 \h 63Denial-of-Service PAGEREF _Toc197509296 \h 64Slow Header Testing PAGEREF _Toc197509297 \h 64Slow Body Testing PAGEREF _Toc197509298 \h 64Slow Read Testing PAGEREF _Toc197509299 \h 65Range Attack Testing PAGEREF _Toc197509300 \h 66Threat Model PAGEREF _Toc197509301 \h 68Log Review PAGEREF _Toc197509302 \h 69Logging Standards PAGEREF _Toc197509303 \h 69Missing or Insufficient Logging PAGEREF _Toc197509304 \h 69Logs Contained Sensitive Data PAGEREF _Toc197509305 \h 70Logging Misconfigurations PAGEREF _Toc197509306 \h 71CR/LF Injections PAGEREF _Toc197509307 \h 71Overriding Server-Side Parameters in Logs PAGEREF _Toc197509308 \h 72Client-Side Log Review PAGEREF _Toc197509309 \h 75UI PAGEREF _Toc197509310 \h 76Authentication PAGEREF _Toc197509311 \h 76Removing all authentication tokens: PAGEREF _Toc197509312 \h 76Inserting corrupt authentication token values: PAGEREF _Toc197509313 \h 76Providing expired authentication tokens: PAGEREF _Toc197509314 \h 77INSERT OTHER ATTACK TYPES AS APPLICABLE PAGEREF _Toc197509315 \h 77Mandatory Test Cases (Authorization) PAGEREF _Toc197509316 \h 77Injection Attacks PAGEREF _Toc197509317 \h 77Click-jacking PAGEREF _Toc197509318 \h 77Cross-Origin Resource Sharing (CORS) PAGEREF _Toc197509319 \h 77Content-Security-Policy (CSP) PAGEREF _Toc197509320 \h 77Server-side Request Forgery (SSRF) PAGEREF _Toc197509321 \h 77Cross-site Request Forgery (CSRF) PAGEREF _Toc197509322 \h 77ETC. ETC. ETC. PAGEREF _Toc197509323 \h 77[Explicit Checks] PAGEREF _Toc197509324 \h 78Test Environment Special Setup PAGEREF _Toc197509325 \h 79Executive SummaryProject Overview & ObjectivesCoalfire was engaged during the period of DATE through DATE to perform third party independent security testing for Amazon Web Services (AWS). The security testing included penetration tests against the defined client systems to proactively discover flaws, weaknesses, and vulnerabilities. Testing for this project was done in accordance with Information Security Best Practices. The objective of this service was to identify and safely exploit vulnerabilities that could lead to critical infrastructure service interruption, destruction of facilities, or compromise of sensitive systems and data. By providing details on successful attack scenarios and specific remediation guidance, Coalfire’s intent is to help AWS protect its business-critical systems, networks, applications, and data.Scope and Attack ScenariosThe following table provides a synopsis of targets that were within scope of this engagement.InventoryConsole Endpoints[Application URLs]API Endpoints[API URLs]Source-Codehttps://code.amazon.com/TODOhttps://code.amazon.com/TODOService Accounts[Add Account ID]Table ES-2: The penetration testing included the following attack scenarios:ScopeItemSubItemScopeItemSubItemScopeItemSubItemAssumption and ConstraintsThis section lists any issues regarding the test plan and/or scope. The intent here is to offer the reader (who could be a pentest auditor, a service team member, a developer, really anyone) a description and reasoning for any discrepancies in the test plan/scope and the actual testing. E.g. Coalfire was not able to test the Flux Capacitor, as the account here rested in production. This issue was cleared with the AppSec Reviewer and service team and tested by the in-house pentest team.E.g., Coalfire could not test the API Cheeseburger because this API was not ready for testing. This will need to be tested in the future. As such, this scope item was removed from scope, and this issue was cleared with both the Service Team and the AppSec Reviewer.E.g., Initial access to the API Tacomaker was not ready for testing, but an extension was approved by the AppSec engineer and AWS POM. As such the scope item Test Taste the API was completed. IMPORTANT!: These constraints should not be a surprise to the AppSec Reviewer or the service team. Make sure you have discussed these with both prior to the readout call. Finally, if there are no Testing Constraints, provide a simple statement such as: There were no constraints to the provided test scope. As such, Coalfire was able to cover the scope in its entirety.Findings SummaryPlease refer to Pentest Manager (PTM) for details on individual findings (https://ptm.pentest.appsec.aws.dev/engagement/[id]?tab=findings-tab)Delete This ColumnSeverityTitleAffected ResourcesREMOVE COL FOR LINKSTART_PASTE_HEREMandatory Test Cases (MTCs)For each of the in-scope service components Coalfire performed authorization testing according to the guidelines provided by AWS IT Security - AppSec - Security Verification and Validation Team (SVVT) - Program Operations and Management (POM). The narrative below is a representative sample showing the methodology of how the service was tested.MTC 1: Basic IAM Permissions VerificationService did not use IAM permissions.MTC 1A: Explicit AllowMTC 1A: Explicit AllowCoalfire first configured a basic allow policy for quality assurance:{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Action": "service:*","Resource": "*"}]}[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs.Correct allow response: OR Incorrect deny response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs.Correct allow response: OR Incorrect deny response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Repeat all applicable API callsMTC 1B: Explicit DenyMTC 1B: Explicit DenyCoalfire next tested the APIs with an IAM policy to explicitly deny a request.{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Action": "*","Resource": "*"},{"Effect": "Deny","Action":"service:*","Resource": "*"}]}[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs.Correct deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Repeat all applicable API callsMTC 1C: Implicit DenyMTC 1C: Implicit DenyCoalfire called the API with an IAM principal containing an implicit deny policy.{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Action": ["internal-non-existant:NoRealActionGranted"],"Resource": "*"}]}[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs.Correct deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Repeat all applicable API callsMTC 2: PassRole PermissionsService did not pass roles.MTC 2A: Explicit AllowMTC 2A: Explicit AllowCoalfire created an IAM policy with an explicit PassRole permission to the IAM role created for the service. A separate policy was used to grant access to the service actions and any needed dependencies.{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Action": ["iam:GetRole","iam:PassRole"],"Resource": "arn:aws:iam:: 123456789012:role/AVP-####-MTC02-Role"}]}[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs. Be sure to show the same-account explicitly allowed role in the request.Correct allow response: OR Incorrect deny response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Repeat all applicable API calls and passable rolesMTC 2B: Explicit DenyMTC 2B: Explicit DenyCoalfire next created an IAM policy with an explicit deny for the role in PassRole.{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Action": ["iam:GetRole","iam:PassRole"],"Resource": "*"},{"Effect": "Deny","Action": ["iam:GetRole","iam:PassRole"],"Resource": "arn:aws:iam:: 123456789012:role/AVP-####-MTC02-Role"} ]}[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs. Be sure to show the same-account explicitly denied role in the request.Correct deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Repeat all applicable API calls and passable rolesMTC 2C: Implicit DenyMTC 2C: Implicit DenyFinally, Coalfire attached a policy allowing service actions, but not any PassRole permissions.{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Action": ["service:*"],"Resource": "*"}]}[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs. Show in-same-account but not allowed role in the request.Correct deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Repeat all applicable API calls and passable rolesMTC 3: Passrole Confused DeputyService did not pass roles.MTC 3A: Confused DeputyMTC 3A: Confused DeputyCoalfire called the API using an IAM principal with the “AdministratorAccess” policy. This allowed the caller to pass any role within their own account. The service was tested for each call type (UI and API) by providing input resources that targeted another customer’s account. The other customer account (target victim) did not specify any allow policies for the attacker.Service APIs were called using a role belonging to the victim account.[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs. Show cross-account role of the victim role.Correct deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Repeat all applicable API calls and passable rolesCoalfire also tested variations of input identifiers and ARNs by changing the encoding or case sensitivity of the input values.[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs. Show cross-account role of the victim role.Correct deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.MTC 4: Resource Policy ConstraintsNone of the resources created by the service supported resource policies.ORService did not create any resources.MTC 4A: Explicit Allow in Resource Policy and Empty Principal PolicyMTC 4A: Explicit Allow in Resource Policy and Empty Principal PolicyFirst, Coalfire utilized an IAM principal with no policies attached. The following resource policy was attached to the resource.Resource policy:{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Action": "service:*","Principal": {"AWS": ["arn:aws:iam::111122223333:[user/role]/mtc"]},"Resource": "arn:aws:service:::"}]}[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs. Show resource being tested.Correct allow response: OR Incorrect deny response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Repeat all applicable API calls and then again repeat for all applicable resources.MTC 4B: Wildcard Allow and Explicit Deny in Resource Policy, Empty Principal PolicyMTC 4B: Wildcard Allow and Explicit Deny in Resource Policy, Empty Principal PolicyNext, Coalfire utilized a resource policy with a wildcard allow and an explicit deny. IAM principal policy had no policies or permissions attached. The following resource policy was attached to the resource.Resource Policy:{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Action": "service:*","Principal": "*","Resource": "arn:aws:service:::"},{"Effect": "Deny","Action": "service:*","Principal": {"AWS": ["arn:aws:iam::111122223333:[user/role]/mtc"]},"Resource": "arn:aws:service:::"}]}[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs. Show resource being tested.Correct deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Repeat all applicable API calls and then again repeat for all applicable resources.Coalfire also tested variations of input identifiers and ARNS.MTC 4C: Empty Resource Policy, Empty Principal PolicyMTC 4C: Empty Resource Policy, Empty Principal PolicyCoalfire then utilized a blank resource policy and an IAM principal with no permissions granted.[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs. Show resource being tested.Correct deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Repeat all applicable API calls and then again repeat for all applicable resources.Coalfire also tested variations of input identifiers and ARNS.[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs. Show resource being tested.Correct deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.MTC 4D: Empty Resource Policy, Explicit Allow in Principal PolicyMTC 4D: Empty Resource Policy, Explicit Allow in Principal PolicyEmpty resource policy and explicit allow principal policy was tested and documented in MTC 5B.MTC 4E: Explicit Allow in Resource Policy, Explicit Deny in Principal PolicyMTC 4E: Explicit Allow in Resource Policy, Explicit Deny in Principal PolicyLastly, Coalfire utilized a resource policy with an explicit allow and a principal policy with an explicit deny.The follow policy was attached to the resource:{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Principal": {"AWS": ["arn:aws:iam::111122223333:[user/role]/mtc"]},"Resource": "arn:aws:service:::"}]}The following policy was attached to the IAM principal:{"Version": "2012-10-17","Statement": [{"Effect": "Deny","Action": "service:action","Resource": "aws:arn:service:::"}]}[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs.aws srv create-foo-bar \--region us-west-4 \--endpoint-url https://gamma.srv.us-west-4.amazonaws.dev \--name MyFooBar \--resource ResourceCorrect deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Coalfire also tested variations of input identifiers and ARNS.[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs.aws srv create-foo-bar \--region us-west-4 \--endpoint-url https://gamma.srv.us-west-4.amazonaws.dev \--name MyFooBar \--resource ResourceCorrect deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.MTC 4F: Confused Deputy Key EnforcementMTC 4F: Confused Deputy Key EnforcementTODO – test as per https://w.amazon.com/bin/view/AWS_IT_Security/AWS_Pentester_Onboarding/MTC_Index/MTC_4/MTC 4G: Confused Deputy Key ValidationMTC 4G: Confused Deputy Key ValidationTODO – test as per https://w.amazon.com/bin/view/AWS_IT_Security/AWS_Pentester_Onboarding/MTC_Index/MTC_4/MTC 5: Resource-Level PermissionsService did not support resource-level permissions.MTC 5A: Explicit Allow Rule for an Action on a Different ResourceMTC 5A: Explicit Allow Rule for an Action on a Different ResourceCoalfire created and attached the following IAM policy that allowed access to a specific resource:{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Action": "service:*","Resource": "ResourceA"}]}Coalfire then called the APIs on a resource not listed in the above policy.[APIName] call against [ParameterName] resource:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs. Show resource not in the policy AKA ResourceB.Correct deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Repeat all applicable resources and then again repeat for all applicable API calls.MTC 5B: Explicit Allow Rule for an Action on the Target ResourceMTC 5B: Explicit Allow Rule for an Action on the Target ResourceNext, Coalfire utilized the principal policy from MTC 5A to call the allowed resource.[APIName] call against [ParameterName] resource:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs. Show resource listed in the policy.Correct allow response: OR Incorrect deny response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Repeat all applicable API calls and then again repeat for all applicable resources.MTC 5C: Wildcard Allow with Explicit Deny for the Target ResourceMTC 5C: Wildcard Allow with Explicit Deny for the Target ResourceCoalfire called the APIs with an IAM policy containing a wildcard allow but explicit deny for the resource:{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Action": "service:*","Resource": "*"},{"Effect": "Deny","Action": "service:*","Resource": "ResourceA"}]}[APIName] call against [ParameterName] resource:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs. Show denied resource from policy.Correct deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Repeat all applicable API calls and then again repeat for all applicable resources.MTC 5C: Wildcard VariationsVariation 1: Policy with wildcard resource identifier:{"Version": "2012-10-17","Statement":[{"Effect": "Allow","Action": "service:*","Resource": "*"},{"Effect": "Deny","Action": "service:*","Resource": "arn:aws:service:*:123456789012:resource-type/*"}]}All APIs were called. A sample is shown below:[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs.Correct deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Variation 2: Policy with wildcard resource type:{"Version": "2012-10-17","Statement":[{"Effect": "Allow","Action": "service:*","Resource": "*"},{"Effect": "Deny","Action": "service:*","Resource": "arn:aws:service:*:123456789012:*/resource-identifier"}]}[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs.Correct deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Variation 3: Policy with wildcard resource type and resource identifier:{"Version": "2012-10-17","Statement":[{"Effect": "Allow","Action": "service:*","Resource": "*"},{"Effect": "Deny","Action": "service:*","Resource": "arn:aws:service:*:123456789012:*/*"}]}[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs.Correct deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Variation 4: Policy with wildcard resource path:{"Version": "2012-10-17","Statement":[{"Effect": "Allow","Action": "service:*","Resource": "*"},{"Effect": "Deny","Action": "service:*","Resource": "arn:aws:service:*:123456789012:resource-type/*/*"}]}[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs.Correct deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.MTC 5C: ARN and ID MutationsCoalfire also tested variations of input identifiers and ARNS.[APIName] call against [ParameterName] resource with variation in name:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs.Correct deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.List of short identifiers and ARN variations tested:Insert the list you used showing both short ids and ARNs fuzzed. Even if the API was not designed to accept a short-id (or ARN) try to force them anyway to bypass auth.MTC 5D: SDF AdherenceMTC 5D: SDF AdherenceFrom the AWS Pentesters Playbook – “MTC 5: Testing Guidance” - Mandatory Test Cases Testing Guidance:Note: Service Description File (SDF) is a JSON file that documents the public authorization strategy of your service…The SDF describes how customers can create policies to control access to your service. The file includes general information for your service, and details about the actions, resources, and condition keys and their relationship to each other.https://w.amazon.com/bin/view/AWSAuth/AccessManagement/Service_Description_File/#Why_are_inaccurate_SDFs_treated_as_a_security_issue.3FThe in-scope service was not yet public modifications of an exiting public endpoint.The service team provided the following SDF JSON:Pasted copy of the SDF JSONOr if too long a link to a static copy of it at the time analyzedCoalfire reviewed the SDF and observed INSERT_A_VULN_YOU_SAW_HERE.Coalfire attempted an exploit of this issue by using the following customer-defined IAM policy:Pasted copy of the custom IAM policyThe following API request was made using credentials of an unauthorized user to the resource:Pasted copy of Burp HTTP request or aws cli callThe result was an unexpected action on the resource bypassing the authorization:Pasted copy of Burp HTTP response or aws cli call outputThe service team indicated that no SDF JSON was yet available. Coalfire therefore was only able to reference documentation provided by the service team for information of the supported IAM policy options:TODO_INSERT_QUIP_LINK_HERETODO_SAVE_PDF_COPY_OF_ANY_DOCS_TO_WORKDOCSTesting of the authorization controls using the documentation provided was already performed in the other MTC sections of this report.The service team had no SDF JSON or IAM policy documentation. Coalfire performed testing of authorization controls using the methodologies documented in the other MTC sections of this report.MTC 6: Principle of Least Privilege and SLR AuditService did not create any roles or policies on behalf of the customer.MTC 6A: Adherence to the Principle of Least PrivilegeMTC 6A: Adherence to the Principle of Least PrivilegeThe service automatically created the following IAM service-linked roles in the customer’s account:arn:aws:iam:::role/aws-service-role/serviceInternalCodeNameCoalfire reviewed those IAM roles and policies created on behalf of the customer.<place the policy JSON here>Coalfire also reviewed the following service-specific IAM policies for the principle of least privilege:Correct scoping down of “Actions” and “Resources”The policies reviewed did not grant any excessive permission and were deemed to follow security best practice.MTC 7: Resource Policy EscalationNone of the resources created by the service supported resource policies attached to the resource.MTC 7A: Resource Policy Allowing Access to the Resource It’s Attached toMTC 7A: Resource Policy Allowing Access to the Resource It’s Attached toPer REF _Ref128858702 \h MTC 4A: Explicit allow in resource policy and empty principal policy. Coalfire already verified that calling a resource with an explicit allow policy behaved as expected.MTC 7B: Resource Policy Allowing Access to a Different ResourceMTC 7B: Resource Policy Allowing Access to a Different ResourceCoalfire attached the following policy to ResourceA allowing access to ResourceB:{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Principal": "*","Resource": "arn:aws:service:::ResourceB"}]}The APIs were then called against ResourceB with an empty principal policy.[APIName] call against [ParameterName] resource:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs. Show ResourceB that was allowed in the resource policy.Correct deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.MTC 7C: Resource Policy Allowing Access to a Resource Belonging to a Different ServiceMTC 7C: Resource Policy Allowing Access to a Resource Belonging to a Different ServiceCoalfire attached the following policy to the ResourceName allowing access to an S3 bucket. No IAM principal permissions were granted.{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Principal": "*","Resource": "arn:aws:s3:::bucketname"}]}Utilizing an empty principal policy, the listed S3 bucket was called:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs. This should be an s3 API call or whatever service you decided to test against.Correct deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.MTC 8: Confused DeputyThe service did not support resource identifiers.ORService did not create resources.MTC 8A-B: Quality AssuranceMTC 8A-B: Quality AssurancePer REF _Ref128901887 \h MTC 5B: Explicit allow rule for an action on the target resource, testing of passing a resource this principal has access to was already performed. Additionally, testing of passing a resource in the same account that an IAM principal does not have Allow permission to was already performed in REF _Ref128902093 \h MTC 5A: Explicit allow rule for an action on a different resource.MTC 8C: Pass a Resource from Another Account with a Policy Allowing the PrincipalMTC 8C: Pass a Resource from Another Account with a Policy Allowing the PrincipalThe service did not support resource policies.Coalfire created a resource in accountA, and attached the following resource policy to it:{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Principal": {"AWS": ["arn:aws:iam::accountB:[user/role]/mtc"]},"Resource": "arn:aws:service:::Resource"}]}Coalfire then called the APIs from AccountB with an empty principal policy to interact with resource.[APIName] call against [ParameterName] resource:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs. Show Resource that was allowed in the resource policy.Correct allow response: OR Incorrect deny response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Repeat all applicable API calls and then again repeat for all applicable resources.MTC 8D: Pass a Resource that Belongs to Another AccountMTC 8D: Pass a Resource that Belongs to Another AccountAn IAM principal from a customer account was granted full admin permission. The service was tested for each call type by providing input resources that targeted another customer’s account. The other customer account (target victim) did not specify any allow policies for the attacker.APIs were called with cross-account resource identifier/ARN.[APIName] call against [ParameterName] resource:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs. Show victim resource.Correct deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Repeat all applicable API calls and then again repeat for all applicable resources.Coalfire also tested variations of input identifiers and ARNS.[APIName] call against [ParameterName] resource:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs. Show victim resource.Correct deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.MTC 8E: Shorthand Identifier and ARN CheckMTC 8E: Shorthand Identifier and ARN CheckService did not support shorthand identifier/ARN.Coalfire used the same AdministratorAccess policy from MTC 8D to call the API. The input parameters for resources that supported short IDS or ARNs were called with a varying list of fuzzed values against resources that belong to another account (confused deputy) which did not grant the caller cross-account permission.[APIName] call against [ParameterName] resource:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs. Show denied resource with shorthand identifier.Correct deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Repeat all applicable API calls and then again repeat for all applicable resources.The list of fuzzed ARNs or IDs used:Paste list here from arn-fuzz.pyMTC 9: Customer S3 Buckets InteractionService did not use customer provided S3 buckets.MTC 9A: Specify an S3 Bucket the User Has Access toMTC 9A: Specify an S3 Bucket the User Has Access toCoalfire first set up an S3 bucket in the user account with proper permissions for quality assurance. The following principal policy was used:{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Action": "service:*","Resource": "*"},{"Effect": "Allow","Action": "s3:*","Resource": ["arn:aws:s3:::S3bucket","arn:aws:s3:::S3bucket/*"]}]}No S3 bucket policies were used.[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs.Correct allow response: OR Incorrect deny response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Repeat for all applicable S3 bucket interactions and API calls MTC 9B: Specify an S3 Bucket in the Same Account the User Does Not Have Access toMTC 9B: Specify an S3 Bucket in the Same Account the User Does Not Have Access toCoalfire then set up an S3 bucket in the user account without permissions granted. The following principal policy was used:{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Action": "service:*","Resource": "*"}]}[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs.Correct deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Repeat for all applicable S3 bucket interactions and API calls MTC 9C: Specify an S3 Bucket in Another Account that the User Should Have Access toMTC 9C: Specify an S3 Bucket in Another Account that the User Should Have Access toService did not support cross-account S3 bucket access and denied the requests.Another S3 bucket was set up in accountB with an S3 bucket policy granting access to the user in accountA. The following bucket policy was used:{"Version": "2012-10-17","Statement": [{"Principal": {"AWS": ["arn:aws:iam::AccountA:[role/user]/name"]}, "Effect": "Allow", "Action": "s3:*", "Resource": ["arn:aws:s3:::S3bucket","arn:aws:s3:::S3bucket/*"]}]}The following principal policy was utilized:{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Action": "service:*","Resource": "*"},{"Effect":"Allow","Action":"s3:*","Resource": ["arn:aws:s3:::S3bucket","arn:aws:s3:::S3bucket/*"]}]}[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs. Show allowed S3 bucket.Correct allow response: OR Incorrect deny response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Repeat for all applicable S3 bucket interactions and API calls MTC 9D: Specify an S3 Bucket in Another Account that the User Should Not Have Access toMTC 9D: Specify an S3 Bucket in Another Account that the User Should Not Have Access toNext, the same S3 bucket in accountB was used. However, this time the bucket did not have any policies granting access to principals in accountA. No bucket policy was defined, the following principal policy was utilized:{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Action": "service:*","Resource": "*"},{"Effect":"Allow","Action":"S3","Resource": ["arn:aws:::VictimS3Bucket""arn:aws:::VictimS3Bucket/*"]}]}[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs. Show victim bucket.Correct deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Repeat for all applicable S3 bucket interactions and API calls MTC 9E: Bucket SnipingMTC 9E: Bucket SnipingService did not run prolonged actions.Since the service periodically ran actions against customer s3 buckets, the possibility of s3 bucket sniping was tested against. Coalfire initially created an S3 bucket in accountA, started a prolonged task that reads/writes to that bucket, deleted the bucket from accountA, and recreated it with the same name in accountB. No bucket policy was defined and the user making the calls was granted full admin permissions.Coalfire then monitored that S3 bucket for any unexpected read or writes. [No unexpected user data was read/written to the S3 bucket. | The ownership of the S3 bucket was not verified correctly by the service, and the service interacted with the sniped bucket.]Malicious sniped S3 bucket with stolen user dataOrService failing to read/write to bucket if possible MTC 9F: Bucket MonopolyMTC 9F: Bucket MonopolyService did not use S3 bucketsCoalfire reviewed the service CDK and service code for any S3 bucket creation that could use a predictable naming pattern. This included code that was used in the deployment of the service as well as code that created S3 buckets on behalf of the user. An attacker who could guess the naming pattern could create an S3 bucket they own and control in an attempt to illicitly receive (or control) customer data or service inputs.The following code was found to create predictable S3 buckets:https://code.amazon.com/packages/INSERTHERE/src/--/mycode.phphttps://code.amazon.com/packages/INSERTHERE/src/--/mycode.phpCoalfire observed the following S3 buckets in the environment resulting from predictable names and vulnerable to Bucket Monopoly:arn:aws:s3::123456789012:servicebucket-us-central-7-123456789012arn:aws:s3::123456789012:servicebucket-CDK-us-central-2-123456789012An additional parameter in the AWS S3 API allowed for restricting the expected bucket owner to the same account as the caller. The service did not require feature support of cross-account buckets.Coalfire did not observe the ExpectedBucketOwner parameter security control in the S3 API calls. An example of a verified S3 API call in the service code:https://code.amazon.com/packages/INSERTHERE/src/--/code-that-calls-s3.cppINSERT CODE EXAMPLE HERE FROM CODE.AMAZON.COMMTC 10: IAM IP Address ConditionalsThe service APIs did not support customer defined IAM policies.MTC 10A: Allowing Correct IP AddressMTC 10A: Allowing Correct IP AddressCoalfire configured an IAM policy to allow the remote client IP address to call the API (any IP not in 127.0.0.1/8 or ::/16 loopback ranges):{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "*" ], "Resource": "*", "Condition": { "IpAddress": { "aws:SourceIp": [ "1.0.0.0/8", "2.0.0.0/7", "4.0.0.0/6", "8.0.0.0/5", "16.0.0.0/4", "32.0.0.0/3", "64.0.0.0/3", "96.0.0.0/4", "112.0.0.0/5", "120.0.0.0/6", "124.0.0.0/7", "126.0.0.0/8", "128.0.0.0/1", "1::/16", "2::/15", "4::/14", "8::/13", "10::/12", "20::/11", "40::/10", "80::/9", "100::/8", "200::/7", "400::/6", "800::/5", "1000::/4", "2000::/3", "4000::/2", "8000::/1" ] } } } ]}[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs.Correct allowed response: OR Incorrect deny response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.MTC 10B: Requiring Localhost IP AddressMTC 10B: Requiring Localhost IP AddressCoalfire configured an IAM policy to require a localhost IP address to call the APIs:{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "*" ], "Resource": "*", "Condition": { "IpAddress": { "aws:SourceIp": [ "127.0.0.1", "::1" ] } } } ]}[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs.Correct deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.MTC 10C: Spoofing Headers to Bypass Requiring Localhost IP AddressMTC 10C: Spoofing Headers to Bypass Requiring Localhost IP AddressCoalfire configured an IAM policy to require a localhost IP address to call the APIs:{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "*" ], "Resource": "*", "Condition": { "IpAddress": { "aws:SourceIp": [ "127.0.0.1", "::1" ] } } } ]}The APIs were called with variations of the X-Forwarded-For header in the request.[APIName] API call for IPv4:INSERT YOUR HTTP REQUEST from Burp here showing all the inputs including the X-Forwarded-For Header: Show the X-Forwarded-For: 127.0.0.1 header.Correct deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.[APIName] API call for IPv6:INSERT YOUR HTTP REQUEST from Burp here showing all the inputs including the X-Forwarded-For Header: Show the X-Forwarded-For: ::1 header.Correct deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Coalfire also attempted the following variant HTTP spoofing headers:X-Forwarded-For: 127.0.0.1X-Forwarded-For: 127.0.0.1,127.0.0.1,10.0.0.0,127.0.0.1,127.0.0.1X-Amzn-Remote-IP: 127.0.0.1X-Originating-IP: 127.0.0.1X-Remote-IP: 127.0.0.1X-Remote-Addr: 127.0.0.1X-Client-IP: 127.0.0.1X-Forwarded-Host: 127.0.0.1From: 127.0.0.1Referer: 127.0.0.1X-Original-URL: 127.0.0.1X-Wap-Profile: 127.0.0.1Profile: 127.0.0.1X-Arbitrary: 127.0.0.1X-HTTP-DestinationURL: 127.0.0.1X-Forwarded-Proto: 127.0.0.1Origin: 127.0.0.1X-Forwarded-Server: 127.0.0.1X-Host: 127.0.0.1Proxy-Host: 127.0.0.1Destination: 127.0.0.1Proxy: 127.0.0.1Via: 127.0.0.1True-Client-IP: 127.0.0.1Client-IP: 127.0.0.1X-Real-IP: 127.0.0.1CF-Connecting_IP: 127.0.0.1Forwarded: 127.0.0.1X-Forwarded-Scheme: 127.0.0.1X-Cluster-Client-I: 127.0.0.1X-Forwarded-For abcd: 127.0.0.1X-Forwarded-For abcd: 127.0.0.1,127.0.0.1,10.0.0.0,127.0.0.1,127.0.0.1X-Originating-IP abcd: 127.0.0.1X-Remote-IP abcd: 127.0.0.1X-Remote-Addr abcd: 127.0.0.1X-Client-IP abcd: 127.0.0.1X-Forwarded-Host abcd: 127.0.0.1 X-Forwarded-For: 127.0.0.1 X-Forwarded-For: 127.0.0.1,127.0.0.1,10.0.0.0,127.0.0.1,127.0.0.1 X-Originating-IP: 127.0.0.1 X-Remote-IP: 127.0.0.1 X-Remote-Addr: 127.0.0.1 X-Client-IP: 127.0.0.1 X-Forwarded-Host: 127.0.0.1X-Forwarded-For: ::1X-Forwarded-For: ::1,::1,::1,::1,127.0.0.1X-Amzn-Remote-IP: ::1X-Originating-IP: ::1X-Remote-IP: ::1X-Remote-Addr: ::1X-Client-IP: ::1X-Forwarded-Host: ::1From: ::1Referer: ::1X-Original-URL: ::1X-Wap-Profile: ::1Profile: ::1X-Arbitrary: ::1X-HTTP-DestinationURL: ::1X-Forwarded-Proto: ::1Origin: ::1X-Forwarded-Server: ::1X-Host: ::1Proxy-Host: ::1Destination: ::1Proxy: ::1Via: ::1True-Client-IP: ::1Client-IP: ::1X-Real-IP: ::1CF-Connecting_IP: ::1Forwarded: ::1X-Forwarded-Scheme: ::1X-Cluster-Client-I: ::1X-Forwarded-For abcd: ::1X-Forwarded-For abcd: ::1,::1,::1,::1,127.0.0.1X-Originating-IP abcd: ::1X-Remote-IP abcd: ::1X-Remote-Addr abcd: ::1X-Client-IP abcd: ::1X-Forwarded-Host abcd: ::1 X-Forwarded-For: ::1 X-Forwarded-For: ::1,::1,::1,::1 X-Originating-IP: ::1 X-Remote-IP: ::1 X-Remote-Addr: ::1 X-Client-IP: ::1 X-Forwarded-Host: ::1MTC 10D: Spoofing Headers to Bypass Not Localhost IP AddressMTC 10D: Spoofing Headers to Bypass Not Localhost IP AddressCoalfire tested the negative condition with the following policy:{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "*" ], "Resource": "*", "Condition": { "NotIpAddress": { "aws:SourceIp": [ "127.0.0.1", "::1" ] } } } ]}[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here showing all the inputs including some variations of the following headers:Make sure you use all the same variants as in MTC10CCorrect allowed response: OR Incorrect deny response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.MTC 10E: Not Allowing Caller IP AddressMTC 10E: Not Allowing Caller IP AddressCoalfire configured an IAM policy to exclude the remote client IP address to call the API (any IP not in 127.0.0.1/8 or ::/16 loopback ranges):{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "*" ], "Resource": "*", "Condition": { "NotIpAddress": { "aws:SourceIp": [ "1.0.0.0/8", "2.0.0.0/7", "4.0.0.0/6", "8.0.0.0/5", "16.0.0.0/4", "32.0.0.0/3", "64.0.0.0/3", "96.0.0.0/4", "112.0.0.0/5", "120.0.0.0/6", "124.0.0.0/7", "126.0.0.0/8", "128.0.0.0/1", "1::/16", "2::/15", "4::/14", "8::/13", "10::/12", "20::/11", "40::/10", "80::/9", "100::/8", "200::/7", "400::/6", "800::/5", "1000::/4", "2000::/3", "4000::/2", "8000::/1" ] } } } ]}The following variations were used:X-Forwarded-For: 192.0.2.100X-Forwarded-For: 192.0.2.100,192.0.2.100,10.0.0.0,192.0.2.100,192.0.2.100X-Amzn-Remote-IP: 192.0.2.100X-Originating-IP: 192.0.2.100X-Remote-IP: 192.0.2.100X-Remote-Addr: 192.0.2.100X-Client-IP: 192.0.2.100X-Forwarded-Host: 192.0.2.100From: 192.0.2.100Referer: 192.0.2.100X-Original-URL: 192.0.2.100X-Wap-Profile: 192.0.2.100Profile: 192.0.2.100X-Arbitrary: 192.0.2.100X-HTTP-DestinationURL: 192.0.2.100X-Forwarded-Proto: 192.0.2.100Origin: 192.0.2.100X-Forwarded-Server: 192.0.2.100X-Host: 192.0.2.100Proxy-Host: 192.0.2.100Destination: 192.0.2.100Proxy: 192.0.2.100Via: 192.0.2.100True-Client-IP: 192.0.2.100Client-IP: 192.0.2.100X-Real-IP: 192.0.2.100CF-Connecting_IP: 192.0.2.100Forwarded: 192.0.2.100X-Forwarded-Scheme: 192.0.2.100X-Cluster-Client-I: 192.0.2.100X-Forwarded-For abcd: 192.0.2.100X-Forwarded-For abcd: 192.0.2.100,192.0.2.100,10.0.0.0,192.0.2.100,192.0.2.100X-Originating-IP abcd: 192.0.2.100X-Remote-IP abcd: 192.0.2.100X-Remote-Addr abcd: 192.0.2.100X-Client-IP abcd: 192.0.2.100X-Forwarded-Host abcd: 192.0.2.100 X-Forwarded-For: 192.0.2.100 X-Forwarded-For: 192.0.2.100,192.0.2.100,10.0.0.0,192.0.2.100,192.0.2.100 X-Originating-IP: 192.0.2.100 X-Remote-IP: 192.0.2.100 X-Remote-Addr: 192.0.2.100 X-Client-IP: 192.0.2.100 X-Forwarded-Host: 192.0.2.100X-Forwarded-For: 1337:c0de:4:11feX-Forwarded-For: 1337:c0de:4:11fe,1337:c0de:4:11fe,10.0.0.0,1337:c0de:4:11fe,1337:c0de:4:11feX-Amzn-Remote-IP: 1337:c0de:4:11feX-Originating-IP: 1337:c0de:4:11feX-Remote-IP: 1337:c0de:4:11feX-Remote-Addr: 1337:c0de:4:11feX-Client-IP: 1337:c0de:4:11feX-Forwarded-Host: 1337:c0de:4:11feFrom: 1337:c0de:4:11feReferer: 1337:c0de:4:11feX-Original-URL: 1337:c0de:4:11feX-Wap-Profile: 1337:c0de:4:11feProfile: 1337:c0de:4:11feX-Arbitrary: 1337:c0de:4:11feX-HTTP-DestinationURL: 1337:c0de:4:11feX-Forwarded-Proto: 1337:c0de:4:11feOrigin: 1337:c0de:4:11feX-Forwarded-Server: 1337:c0de:4:11feX-Host: 1337:c0de:4:11feProxy-Host: 1337:c0de:4:11feDestination: 1337:c0de:4:11feProxy: 1337:c0de:4:11feVia: 1337:c0de:4:11feTrue-Client-IP: 1337:c0de:4:11feClient-IP: 1337:c0de:4:11feX-Real-IP: 1337:c0de:4:11feCF-Connecting_IP: 1337:c0de:4:11feForwarded: 1337:c0de:4:11feX-Forwarded-Scheme: 1337:c0de:4:11feX-Cluster-Client-I: 1337:c0de:4:11feX-Forwarded-For abcd: 1337:c0de:4:11feX-Forwarded-For abcd: 1337:c0de:4:11fe,1337:c0de:4:11fe,10.0.0.0,1337:c0de:4:11fe,1337:c0de:4:11feX-Originating-IP abcd: 1337:c0de:4:11feX-Remote-IP abcd: 1337:c0de:4:11feX-Remote-Addr abcd: 1337:c0de:4:11feX-Client-IP abcd: 1337:c0de:4:11feX-Forwarded-Host abcd: 1337:c0de:4:11fe X-Forwarded-For: 1337:c0de:4:11fe X-Forwarded-For: 1337:c0de:4:11fe,1337:c0de:4:11fe,10.0.0.0,1337:c0de:4:11fe,1337:c0de:4:11fe X-Originating-IP: 1337:c0de:4:11fe X-Remote-IP: 1337:c0de:4:11fe X-Remote-Addr: 1337:c0de:4:11fe X-Client-IP: 1337:c0de:4:11fe X-Forwarded-Host: 1337:c0de:4:11fe[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here showing all the inputs including some variations of the following headers:Make sure you included all the variant headers aboveCorrect deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.MTC 11: HTTP Protocol HandlingMTC 11A: Protocol SwitchingMTC 11A: Protocol SwitchingIf a service mishandles a protocol switching request, it can result in misinterpretation of input values. This can allow for attacks such as injection or cross-site scripting that would normally be filtered and blocked. Testing consisted of sending the upgrade headers in a request to see if the service supported it. If it did, then vulnerability tests were performed by changing the request to contain an unexpected encoding during an upgrade request (e.g. URL parameters encoded as JSON inside a WebSockets upgrade call).Burp suite Repeater Inspector set to HTTP 1 modeThe malicious headers injected into the request:INSERT YOUR HTTP REQUEST from Burp here showing all the inputs and the following headers:Connection: UpgradeUpgrade: WebSocket, foo/2, h2c, h2, http/2Sec-WebSocket-Key: Y29hbGZpcmU=Upgrade attack resulted in a standard response (attack ignored):INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Another variant with HTTP/2 Cleartext (h2c) was also tested:INSERT YOUR HTTP REQUEST from Burp here showing all the inputs and the following headers:Upgrade: h2cHTTP2-Settings: YEL8U6YI2gRiwXAGTdmnUeMsConnection: Upgrade, HTTP2-SettingsA normal response was observed indicating that the service ignored the malicious HTTP request:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.MTC 11B: HTTP Request SmugglingMTC 11B: HTTP Request SmugglingTesting for HTTP smuggling was performed using an authenticated request to the application fed into Burp Suite Professional, which ran several variant content lengths and encoding tests to the endpoint.Burp Suite Professional – HTTP Request Smuggler testsThe service, both API and UI endpoint, were found to not be vulnerable to HTTP smuggling.Burp suite HTTP smuggler reported no findingsThe expected error message was observed indicating no smuggling vulnerabilityThe 502 response was consistent with expected protocol specification behavior.RFC7230 Section 3.3.3MTC 12: Nmap ScanService did not have any public endpoints to scan.MTC 12A: Nmap ScanMTC 12: Nmap ScanScanning was performed from an EC2 instance in a separate VPC in a separate (Coalfire) AWS account using public routable IP addresses.The following endpoints were scanned:api.gamma.amazon.comconsole.gamma.amazon.comThe following endpoints did not have public routes from a customer perspective (Internet) and were thus not scanned:api.beta.amazon.devcontrolpane.zeta.amazon.devResolution of endpoints from an external (Internet) perspective:nslookup target.endpoint.name.xxx<your command output showing IP addresses found go here>Resolution of endpoints from the Amazon network with VPN:nslookup target.endpoint.name.xxx<your command output showing IP addresses found go here>The AWS accounts owned by the service were provided for account configuration review. The Isengard ReadOnly role was used to query all public IP addresses from the EC2 network interfaces and included in scanning:aws ec2 describe-network-interfaces –output text –query 'NetworkInterfaces[].[Association.PublicIp,Ipv6Addresses]' | grep -v NoneThe list of IP addresses from the accounts:198.51.100.102203.0.113.982001:db8:3333:4444:5555:6666:7777:8888Run the endpoint scanner tool providing it the FQDNs, the IP addresses from name resolution, and the IP addresses from the EC2 interfaces as the targets. Even though name resolution is performed, we still need FQDNs for the testssl.sh scans that are conducted.Coalfire only observed the expected service ports accessible.<paste in output results from nmap for TCP & UDP here, plain text or screenshot is fine>MTC 13: AWS Organizations IntegrationsService did not integrate with AWS organizations.MTC 13A: Data AggregationMTC 13A: Data AggregationService did not aggregate data from member accounts.Coalfire enrolled a member account into an AWS Organization. The service supported integration with AWS Organizations and integrated data from all member accounts into it.From the management account Coalfire verified that the member account data was visible:Service UI rendering data of the member accountThe member account was removed from the AWS Organization. Coalfire verified that no new logging or service data appeared accessible in the management account after the removal:Service UI no longer showing new data from the removed member accountMTC 13B: Delegated Admin Permissions RevokingMTC 13B: Delegated Admin Pemission RevokingService did not support delegated admins.Coalfire delegated an admin account to the service and ensured the admin account principals were able to call the service APIs. Coalfire then revoked the delegated admin permissions and attempted to call the service APIs once more.Delegating a service admin API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs. Show Successful delegation:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs.Correct allow response: OR Incorrect deny response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Repeat all other admin-only API calls below.Coalfire then revoked the admin delegation from the principal and called the same APIs again.Deregistering service admin API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs. Show Successful deregistration:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs.Correct deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.MTC 13C: SNS Notifications Organizational IntegrationMTC 13C: SNS Notifications Organizational IntegrationService did not support SNS integrations.TODOMTC 13D: SCP AdherenceMTC 13D: SCP AdherenceDefault Allow for SCP:Testing utilized the default SCP policy arn:aws:organizations::aws:policy/service_control_policy/p-FullAWSAccess. This policy was applied and tested in a member account joined to an AWS Organization:{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "*", "Resource": "*" } ]}Each in-scope API was tested using an IAM principal with full admin permissions combined with the SCP policy in the member account for quality assurance. A sample is shown below.[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs.Correct allow response: OR Incorrect deny response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs.Correct allow response: OR Incorrect deny response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Explicit Deny for SCP:For the next scenario, testing utilized a custom SCP policy. This policy was applied to the organization’s root and the service was called from a member account joined to an AWS Organization.{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Action": "*","Resource": "*"},{"Effect": "Deny","Action": "srv:*","Resource": "*"}]}Each in-scope API was tested using an IAM principal with full admin permissions.[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs.Correct deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Organization management account deny:Lastly, Coalfire ensured that the SCP deny policy did not apply to the organization management account. The same deny SCP was attached to the org root. All APIs were called from the organization administrator account with a full admin principal.[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs.Correct allow response: OR Incorrect deny response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.MTC 13E: Organizational Linked Accounts AuthorizationMTC 13E: Organizational Linked Accounts AuthorizationService did not have management-only actions.Show tests hereMTC 13F: Organizational Structure AuthorizationMTC 13F: Organizational Structure AuthorizationCoalfire ensured that only delegated admins were able to view the organization’s structure and members.The delegated admin account attempted to describe the organization structure.INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs.aws organizations describe-organizational-unit \ -- organizational-unit-id myOrgCustomerId --region us-west-4 \ --endpoint-url https://gamma.srv.us-west-4.amazonaws.devCorrect allow response: OR Incorrect deny response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Another non-admin member account was used to describe the organization structure.[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs.aws organizations describe-organizational-unit \ -- organizational-unit-id myOrgCustomerId --region us-west-4 \ --endpoint-url https://gamma.srv.us-west-4.amazonaws.devCorrect deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.MTC 13G: Service CleanupMTC 13G: Service CleanupService did not have any clean up tasks.Coalfire disabled the AWS organizations integration with the service and ensured clean up tasks ran properly.Disabling service integrationCleaned up resourcesMTC 13H: SNS Notifications DuplicatesMTC 13H: SNS Notifications DuplicatesService did not support SNS integrations.TODOMTC 13I: Admin-Only Actions Authorization ControlMTC 13I: Admin-Only Actions Authorization ControlService did not have any admin-only actions.Since the service has admin-only actions, Coalfire attempted to call admin-only actions from a non-admin member.[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs.Correct deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.MTC 14: Tag-Based Access ControlService did not support Tag-based Access Control.MTC 14A: ResourceTag Explicit AllowMTC 14A: Explicit Allow with ResourceTag in the policy and Resource is tagged with the same tag specified in the policy (should work).Service did not support resource tagging.Coalfire first created and tagged ResourceA, then used the following policy to test ResourceTag explicit allows:{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Action": "*","Resource": "*","Condition": {"StringEquals": {"aws:ResourceTag/Key": "Value"}}}]}Coalfire then called all APIs interacting with the tagged resource with the correct tag.[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs.Correct allow response: OR Incorrect deny response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs.Correct allow response: OR Incorrect deny response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Repeat all applicable API callsMTC 14B: ResourceTag Explicit DenyMTC 14B: Explicit Deny with ResourceTag in the policy and Resource is tagged with the same tag specified in the policy (should not work)Service did not support resource tagging.Coalfire created and tagged ResourceA, then used the following policy to test ResourceTag explicit allows:{"Version": "2012-10-17","Statement": [{"Effect":"Allow","Action":"*","Resource":"*"},{"Effect": "Deny","Action": "service:*","Resource": "*","Condition": {"StringEquals": {"aws:ResourceTag/Key": "Value"}}}]}Coalfire then called all APIs interacting with the deny tagged resource.[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs.Correct deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Repeat other APIs with direct resource inputs (List/Delete/Get/Update/etc.).Coalfire also tested for “Explicit Deny with ResourceTag in the policy and Auxiliary Resource is tagged with the same tag specified in the policy (should not work)” for APIs that accepted other existing resource ids/arns in the input:CreateTypeZettaResource had these inputs:ZettaName - the name of the new resource being createdEpsilonId - the id or arn of the resource that already existsauxiliary dependent resource inputAuxiliary Input Test Setup:Created an EpsilionResourceUsing CreateTypeEpsilionResourceAdded the tag pair testTagName=testTagValue to the existing resource aboveSetup an IAM policy to deny the use of that resource by its tag{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "*", "Resource": "*" }, { "Effect": "Deny", "Action": [ "srv:CreateTypeZettaResource" ], "Resource": "arn:aws:srv:*:*:epsilion/*", "Condition": { "StringEquals": { "aws:ResourceTag/testTagName": "testTagValue" } } } ]}Called the srv:CreateTypeZettaResource API passing in the tags testTagName=testTagValueThe expected result was an explicit deny[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs including passing the tag testTagName=testTagValue.Correct deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Repeat for any other APIs with auxiliary resource inputs.MTC 14C: RequestTag Explicit AllowMTC 14C: Explicit Allow with RequestTag in the policy (should only work for the specified Tag).Service did not support resource tagging.ORService did not support RequestTagsCoalfire created the following policy and attached it to the test principal:{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Action": "*","Resource": "*","Condition": {"StringEquals": {"aws:RequestTag/testTagName": "Value"}}}]}Coalfire then called the APIs to create resources with the tag in the policy.[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs. SHOW THE TAG-ON-CREATE TAG THAT IS IN THE POLICYCorrect allow response: OR Incorrect deny response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs. SHOW THE TAG-ON-CREATE TAG THAT IS IN THE POLICYCorrect allow response: OR Incorrect deny response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Repeat all applicable API callsMTC 14D: RequestTag Explicit DenyMTC 14D: Explicit Deny with RequestTag in the policy (should not work for the specified Tag)Service did not support resource tagging.ORService did not support RequestTagsCoalfire created the following policy and attached it to the test principal:{"Version": "2012-10-17","Statement": [{"Effect":"Allow","Action":"*","Resource":"*"},{"Effect": "Deny","Action": "service:*","Resource": "*","Condition": {"StringEquals": {"aws:RequestTag/testTagName": "Value "}}}]}Coalfire then called the APIs to create resources with the tag in the policy.[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs. SHOW THE TAG-ON-CREATE TAG THAT IS IN THE POLICYCorrect deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs. SHOW THE TAG-ON-CREATE TAG THAT IS IN THE POLICYCorrect deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Repeat all applicable API callsMTC 14E: Tagkey Explicit AllowMTC 14E: Explicit Allow with TagKeys in the policy (should only work for the specified Tag Key Names).Service did not support resource taggingThe following policy was created:{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Action": "*","Resource": "*","Condition": {"ForAnyValue:StringEquals": {"aws:TagKeys": ["Key"]}}}]}Coalfire then tagged the resource with the key in the policy and an arbitrary value.[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs.Correct allow response: OR Incorrect deny response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs.Correct allow response: OR Incorrect deny response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Repeat all applicable API callsMTC 14F: Tagkey Explicit DenyMTC 14F: Explicit Deny with TagKeys in the policy (should not work for the specified Tag Key Names)Service did not support resource tagging.The following policy was created:{"Version": "2012-10-17","Statement": [{"Effect":"Allow","Action":"*","Resource":"*"},{"Effect": "Deny","Action": "service:*","Resource": "*","Condition": {"ForAnyValue:StringEquals": {"aws:TagKeys":["Key"]}}}]}Coalfire then tagged the resource with the key in the policy and an arbitrary value.[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs.Correct deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs.Correct deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Repeat all applicable API callsMTC 14G: Tag-On-Create Resource Tagging Permissions MTC 14G: Explicit or Implicit Deny on TagResource action with Explicit Allow on Create operation (should not work if tags are passed in the request)Service did not have resources to tag.ORService did not support tag-on-create.Coalfire used the following policy that allowed the principal to call the Create API, but denied the creation with a certain tag:{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Action": "service:Create*","Resource": "*"},{"Effect": "Deny","Action": "service:TagResource","Resource": "*"}]}The Create APIs were then called with an arbitrary tag:[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs. SHOW ANY ARBITRARY TAG IN THE CREATE API CALLCorrect deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Coalfire also tested a variant test case for “Explicit Deny on TagResource action by aws:ResourceTag with Explicit Allow on Create operation”CreateTypeZettaResource had these inputs:ZettaName - the name of the new resource being createdTest Setup:Setup an IAM policy to deny the use of the TagResource API:{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "*", "Resource": "*" }, { "Effect": "Deny", "Action": [ "srv:TagResource" ], "Resource": "arn:aws:srv:*:*:zetta/*", "Condition": { "StringEquals": { "aws:ResourceTag/testTagName": "testTagValue" } } } ]}Called the srv:CreateTypeZettaResource API passing in the tags testTagName=testTagValueThe expected result was an explicit deny due to the TagResource operation being denied.[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs. SHOW THE TAG PAIR IN THE CREATE API CALLCorrect deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.MTC 14H: Service-Specific Condition Keys Explicit AllowMTC 14H: Explicit Allow with Service-Specific condition keys in the policy (should work for the supported condition keys of the API action)Service did not have any custom condition keys.The service supported the following additional condition keys:IsMemberOfIsOwnerOfThe following policy was used:{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Action": "*","Resource": "*","Condition": {"StringEquals":{"IsMemberOf": "Example"}}}]}Coalfire called the APIs with condition keys that should be allowed.[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs.Correct allow response: OR Incorrect deny response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Repeat for all applicable APIs and again, repeat for all applicable condition keys.MTC 14I: Service-Specific Condition Keys Explicit DenyMTC 14I: Explicit Deny with Service-Specific condition keys in the policy (should not work for the supported condition keys of the API action)Service did not have any custom condition keys.The service supported the following additional condition keys:IsMemberOfIsOwnerOfThe following policy was used:{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Action": "*","Resource": "*"},{"Effect": "Deny","Action": "service:*","Resource": "*","Condition": {"StringEquals":{"IsMemberOf": "Example"}}}]}Coalfire called the APIs with condition keys that should be denied.[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs.Correct deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Repeat for all applicable APIs and again, repeat for all applicable condition keys.MTC 14J: Tag Based Race ConditionsMTC 14J: Ensure that there are no timing vulnerabilities related with resource deletion and taggingService did not support resource tagging.For the scenario:Coalfire created and tagged a resourceUsing a fully permissive IAM policyThe resource was then deleted and quickly recreated without a tagUsing a fully permissive IAM policyThe following policy was used next:{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Action": "*","Resource": "*","Condition": {"StringEquals": {"aws:ResourceTag/Key": "Value"}}}]}The APIs were quickly called to interact with the newly created, untagged resource.The expected result should be an implicit deny[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs.Correct deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.MTC 14K: Tag-On-Create SupportMTC 14K: Ensure Tag-On-Create is supportedService did not support resource tagging.Coalfire ensured all the Create* APIs and the UI creation page supported tagging on create.[Create] API with tag-on-create parameter:Make sure to show the tag-on-create parameters[List/Describe] API showing resource contained the tags…<Tags>…UI Create page with tag-on-createUI list page showing tags on newly created resourceMTC 14L: ResourceTag Mutation Without TagResource APIMTC 14L: Ensure Tags can only be mutated through TagResourceCoalfire attempted to mutate the resource tags by adding the Create tagging body to other API calls.The “AdministratorAccess” managed policy was attached to the principal for this test.[APIName] API call:INSERT YOUR HTTP REQUEST from Burp here or your complete AWS CLI call showing all the inputs. SHOW THE TAG MANIPULATION FROM THE NON-CREATE APIsCorrect deny response: OR Incorrect allow response:INSERT YOUR HTTP RESPONSE from Burp here or your terminal output from the AWS CLI call with the response.Attack Scenario Test ResultsTLS VersionsCoalfire verified that AWS guidelines for TLS protocol and ciphers were adhered to for each endpoint.TLS 1.0 was verified as disabled found enabled for the following endpoints:endpoint1.gamma.a2z.comendpoint2.gamma.a2z.comendpoint3-ui.gamma.a2z.comTLS 1.1 was verified as disabled found enabled for the following endpoints:endpoint1.gamma.a2z.comendpoint2.gamma.a2z.comendpoint3-ui.gamma.a2z.comTLS 1.2 was verified as enabled found missing for the following endpoints:endpoint1.gamma.a2z.comendpoint2.gamma.a2z.comendpoint3-ui.gamma.a2z.comTLS 1.3 was verified as enabled found missing misconfigured and did not follow AWS standards for the following endpoints:endpoint1.gamma.a2z.comendpoint2.gamma.a2z.comendpoint3-ui.gamma.a2z.comSSLv3 was discovered configured insecurely on the following endpoints:endpoint1.gamma.a2z.comendpoint2.gamma.a2z.comendpoint3-ui.gamma.a2z.comScanning of the endpoints was performed using the tool “testssl.sh” (latest version from testssl GitHub - https://testssl.sh/) from an EC2 instance.Sample command and output from one of the endpoint scans:API Fuzzing Fuzzing is the act of sending unexpected and random data to an input to discover potential issues by observing the way certain characters are handled. Targets were selected and attacked using Burp Suite’s Intruder functionality. The list of malicious inputs was hand-crafted by Coalfire to look for OWASP Top 10 common vulnerabilities, such as cross-site scripting, injection, buffer overflows, integer overflows, command injection, and Unicode mishandling.Payload of fuzzing inputsIntruder target exampleSample <parameter name> fuzzing outputCustom Authorization and Authentication TestingThe service application under test did not use customer-definable IAM policies for authorization; therefore, custom business logic authentication and authorization testing were performed.This was set up by creating a principal with administrator level access in the application and another principal without privileged access.AuthenticationThe consultant confirmed that the service properly enforced identity verification of the user. This was performed by modifying the authentication tokens between the client and the remote endpoint using the Burp Suite Professional tool. Below is a sample of the test methodology:Removing all authentication tokens:TODO HTTP REQUESTThe expected response:TODO 401 or 403Inserting corrupt authentication token values:TODO HTTP REQUESTThe expected result:TODO 401 or 403Providing expired authentication tokens:TODO HTTP REQUESTThe expected response:TODO 401 or 403Attempting authentication with an unexpected mechanism (not Sigv4)TODO show request with the wrong authN typeAuthorization: Basic YWRtaW46YWRtaW4=The expected response:TODO 401 or 403Authorization<insert more testing here>Account Config ReviewCoalfire utilized Isengard ReadOnly roles provided by the service team to the AWS-owned accounts where the service code was executed. The tool Scout Suite was used to audit the security configuration settings of the various AWS services in the accounts.Coalfire reviewed the Scout Suite report correlating AWS Security Known Issues:https://w.amazon.com/bin/view/AWS_IT_Security/AppSec/VAPT/Technical_Guides/Known_Issues/As well as the Severity Rankings (SI Analysis)https://w.amazon.com/bin/view/AWS_IT_Security/Gondor/Threat_Modeling/Security_Invariants/Analyses/The data gathered from these tools was then reviewed to remove items that were not considered security issues or negatively impact customer data.AWS Security’s Known Issues wiki pageAWS Security’s SI Analyses wiki pageReview of S3 bucketsObserved only deployment bucketsObserved only default EC2 security groups with no usageCoalfire observed that an IAM user existed in the account with unrotated API security keys.Unmanaged API security keysInsert captionInsert captionCode ReviewCoalfire performed a code review of the commit links provided. This began with checking for outdated or vulnerable dependencies. Some dependencies had newer versions available, though were not associated with common vulnerabilities and exposures (CVEs):PackagePackagePackageThere were also dependencies identified to be vulnerable to particular CVEs or tagged as security recalled. The vulnerable dependencies were recorded as a finding.<<EXAMPLE RUN AND OUTPUT OF TOOL FLAGGING VULN DEPENDENCIES>>Coalfire also searched the repository files in scope for the code review for common vulnerabilities such as SQL injection or insecure deserialization issues.<<EXAMPLE RUN AND OUTPUT OF TOOL PERFORMING SCAInclude run and output from Coalfire tools that ran grep or other searches of the code>>Furthermore, Coalfire manually reviewed the changes made.Screen of Code Review (CR) diffDenial-of-Service Coalfire attempted a DoS of the API endpoint for the evaluation service APIs using the publicly available tool slowhttptesthttps://github.com/shekyan/slowhttptest - The latest version of slowhttptest was downloaded, compiled, and installed for testing.A separate EC2 instance was used to attack the endpoint while a legit client connection from an independent system and IP address validated whether the service was impacted or not.Slow Header Testingslowhttptest -H -c 2000 -i 55 -r 1000 -s 8192 -t POST -o ./slow_head_1 -x 10 -p 3 -u https://xxxxxx.amazonaws.com/slowhttptest -H -c 5000 -i 55 -r 2500 -s 8192 -t POST -o ./slow_head_2 -x 10 -p 3 -u https://xxxxxx.amazonaws.com/slowhttptest -H -c 10000 -i 55 -r 5000 -s 8192 -t POST -o ./slow_head_3 -x 10 -p 3 -u https://xxxxxx.amazonaws.com/slowhttptest -H -c 20000 -i 55 -r 5000 -s 8192 -t POST -o ./slow_head_4 -x 10 -p 3 -u https://xxxxxx.amazonaws.com/Slow Header TestingSlow Body Testingslowhttptest -B -c 2000 -i 55 -r 1000 -s 8192 -t POST -o ./slow_body_1 -x 10 -p 3 -g -u https://xxxxxx.amazonaws.com/slowhttptest -B -c 5000 -i 55 -r 2500 -s 8192 -t POST -o ./slow_body_2 -x 10 -p 3 -g -u https://xxxxxx.amazonaws.com/slowhttptest -B -c 10000 -i 55 -r 5000 -s 8192 -t POST -o ./slow_body_3 -x 10 -p 3 -g -u https://xxxxxx.amazonaws.com/slowhttptest -B -c 20000 -i 55 -r 5000 -s 8192 -t POST -o ./slow_body_4 -x 10 -p 3 -g -u https://xxxxxx.amazonaws.com/Slow Body TestingSlow Read Testingslowhttptest -X -c 2000 -i 55 -r 1000 -s 8192 -t POST -o ./slow_read_1 -x 10 -p 3 -g -u https://xxxxxx.amazonaws.com/slowhttptest -X -c 5000 -i 55 -r 2500 -s 8192 -t POST -o ./slow_read_2 -x 10 -p 3 -g -u https://xxxxxx.amazonaws.com/slowhttptest -X -c 10000 -i 55 -r 5000 -s 8192 -t POST -o ./slow_read_3 -x 10 -p 3 -g -u https://xxxxxx.amazonaws.com/slowhttptest -X -c 20000 -i 55 -r 5000 -s 8192 -t POST -o ./slow_read_4 -x 10 -p 3 -g -u https://xxxxxx.amazonaws.com/Slow Read TestingRange Attack Testingslowhttptest -R -c 2000 -i 55 -r 1000 -s 8192 -t POST -o ./range_attack_1 -x 10 -p 3 -g -u https://xxxxxx.amazonaws.com/slowhttptest -R -c 5000 -i 55 -r 2500 -s 8192 -t POST -o ./range_attack_2 -x 10 -p 3 -g -u https://xxxxxx.amazonaws.com/slowhttptest -R -c 10000 -i 55 -r 5000 -s 8192 -t POST -o ./range_attack_3 -x 10 -p 3 -g -u https://xxxxxx.amazonaws.com/slowhttptest -R -c 20000 -i 55 -r 5000 -s 8192 -t POST -o ./range_attack_4 -x 10 -p 3 -g -u https://xxxxxx.amazonaws.com/Range Attack TestingCoalfire verified the availability of the service by performing legitimate client calls and usage from a separate network while the DoS test was running. No impact to the service was observed. The service became unavailable during the attack indicating a successful denial-of-service.IF YOU HAD ANY ERRORS DOCUMENT AND SCREENSHOT THEM HEREThreat ModelCoalfire performed a Threat model review to verify that the mitigations listed were adequate.Threat model document “TITLEHERE” (QUIPLINKHERE)The application returned a verbose error message, thus not adhering to the following mitigation.Inconsistent mitigation itemCoalfire encountered unhandled exceptions during the fuzzing of functionality.Insert captionCoalfire identified several keys without rotation enabled.Insert captionCoalfire was also able to verify that the service team can respond to a security incident. The service team reached out to verify malicious traffic was originating from our test cases.Service team communication about a security incident triggered during from Coalfire testingLog ReviewLogging StandardsCoalfire reviewed the CloudWatch logs of accounts that house the services being tested to ensure they meet the secure logging standards of AWS. Coalfire obtained service/application log data from Timber by having the service team filter data from the testing account during a specific timeframe. This log data was then provided to Coalfire in a S3 bucket for offline review.This log review included verifying no secrets, cryptography keys, and customer information was added to logs in addition to confirming that the logs provided sufficient detail to conduct a forensic investigation.https://www.aristotle.a2z.com/recommendations/44 Missing or Insufficient LoggingCoalfire obtained request identifiers from HTTP response headers of the in-scope API calls and confirmed log entries appeared for each request ID. Coalfire searched the service logs for the identifiers to confirm log entries are written for the API actions.The following request IDs were used for verification of logging:ListWidget – REQUEST_IDCreateWidget – REQUEST_ID DescribeWidget – REQUEST_IDUpdateWidget – REQUEST_IDDeleteWidget – REQUEST_IDCoalfire used the LogReviewer tool perform log validation of the request IDs.$ python3 main.py --config <logReviewerConfigFile> --lrtc 1 --requestids-file <RequestIDsFile>LogReviewer Searching Logs for Request IDsAlternatively, CloudWatch Logs Insights may be queried.CloudWatch filters:fields @timestamp, @message| filter @message like /REQUEST_ID/| sort @timestamp desc| limit 2000Positive/Negative Results for Request IDsLogs Contained Sensitive DataCoalfire used the LogReviewer tool to review logs for the presence of sensitive data.$ python3 main.py --config <logReviewerConfigFile> --lrtc 2 --requestids-file <RequestIDsFile>LogReviewer Searching Logs for Sensitive DataAlternatively, CloudWatch Logs Insights may be queried.CloudWatch filters:fields @timestamp, @message| filter @message like / JSESSIONID|Cookie|Cookies|password|passphrase|credentials|keypair|cognito|X-Amz-Algorithm.*X-Amz-Credential.*Signature|(?<!X-Amz-Security-)(?<!idempotency)(?<!idempotency.)\b(Token|Tokens)\b(?!.*expired)|amzn_sso|sso_token|X-CLIENT-IDTOKEN|client_secret|eyJ([a-zA-Z0-9_=]+)\.([a-zA-Z0-9_=]+)\.([a-zA-Z0-9_\-\+=]*)|aws_secret_access_key|secretAccessKey.*([a-zA-Z0-9+/]{40})|AWS_SECRET_KEY|-----BEGIN\sCERTIFICATE-----|clientCert|ServerCert|session-Token|sessionToken|session_token|AWS_SESSION_TOKEN|EncryptedSecret|FasCredentials|Authorization:\s(Bearer|Basic)|private_key|ssh_key|rsa_private_key|dsa_private_key|ecdsa_private_key|pgp_private_key|id_rsa|id_dsa|id_ecdsa|id_ed25519|OAuth|oauth_token|oauth-token|oauthtoken|secrets_manager|kms_key|dockerconfig|kubectl|kubeconfig|dockerhub_token|GITHUB_TOKEN|GITLAB_TOKEN|terraform_token|grafana_api_key|zookeeper_super_digest|database_password|database_secret|slack_api_token|jenkins_credential|rabbitmq_default_pass|FasToken|FasKey|x-api-key|fasSecurityToken|fasSecretKey|access_token|accesstoken|access-token|authorization_token|authorizationtoken|AwsV4AuthorizationScheme|IAM\.GetSAMLProvider|Credential.*SignedHeaders.*Signature|(-?(\d\.\d+),\s?){10,}/| sort @timestamp descPositive/Negative Results for Sensitive DataLogging MisconfigurationsCoalfire used the LogReviewer tool to review logs for appropriate logging levels and log retention.$ python3 main.py --config <logReviewerConfigFile> --lrtc 3 --requestids-file <RequestIDsFile>LogReviewer Searching Logs for Data Retention Configurations and Debug LogsAlternatively, CloudWatch Logs Insights may be queried.CloudWatch filters:fields @timestamp, @message| filter @message like /\[DEBUG\]/ or @message like /\[TRACE\]/| sort @timestamp desc| limit 2000Positive/Negative Results for MisconfigurationsCR/LF InjectionsDuring API and UI testing, Coalfire attempted various CR/LF injections in order to split and malform the logs. This could lead to a single log being recorded as two or more if the injected characters are not properly escaped and sanitized.Coalfire used the LogReviewer tool to review logs for presence of CR/LF injection within logs.$ python3 main.py --config <logReviewerConfigFile> --lrtc 4 --requestids-file <RequestIDsFile>LogReviewer Searching Logs for CR/LF Injection in LogsAlternatively, CloudWatch Logs Insights may be queried.CloudWatch filters:fields @timestamp, @message| filter @message like /log_injection_after/| sort @timestamp desc| limit 2000Positive/Negative Results for CR/LF InjectionsExample Rendered CR/LF InjectionsOverriding Server-Side Parameters in LogsDuring API and UI testing, Coalfire attempted various injection methods including but not limited to request ID header injection and X-Forwarded-For headers. These injection strings were searched for through the logs.Scenario 1: Request ID Header PollutionCoalfire tested the ability to influence request IDs in requests by sending canary values in the X-Amzn-Request-Id HTTP request headers. Coalfire then reviewed the logs in CloudWatch Insights for the presence of those canary values.Coalfire used the LogReviewer tool to review logs for presence of request ID pollution within logs.$ python3 main.py --config <logReviewerConfigFile> --lrtc 5 --requestids-file <RequestIDsFile> --lrtc5-payload <optional_injection_payload, optional_injection_payload>LogReviewer Searching Logs for Overridden Request IDsCloudWatch filters:fields @timestamp, @message| filter @message like /request_header_injection|optional_injection_payloads/| sort @timestamp desc| limit 2000Positive/Negative Results for Request Header PollutionsExample Rendered Request Header PollutionsScenario 2: IP Header PollutionCoalfire tested the ability to influence the source IP addresses logged in requests by sending canary values in headers such as the X-Forwarded-For HTTP request headers. Coalfire reviewed the logs in CloudWatch Insights for the presence of those canary values. A sample list of request headers attempted:From: 127.8.8.1Referer: 127.8.8.1X-Original-URL: 127.8.8.1X-Wap-Profile: 127.8.8.1Profile: 127.8.8.1X-Arbitrary: 127.8.8.1X-HTTP-DestinationURL: 127.8.8.1X-Forwarded-Proto: 127.8.8.1Origin: 127.8.8.1X-Forwarded-Host: 127.8.8.1X-Forwarded-Server: 127.8.8.1X-Host: 127.8.8.1Proxy-Host: 127.8.8.1Destination: 127.8.8.1Proxy: 127.8.8.1Via: 127.8.8.1X-Forwarded-For: 127.8.8.1True-Client-IP: 127.8.8.1Client-IP: 127.8.8.1X-Client-IP: 127.8.8.1X-Real-IP: 127.8.8.1X-Originating-IP: 127.8.8.1CF-Connecting_IP: 127.8.8.1Forwarded: 127.8.8.1X-Forwarded-Scheme: 127.8.8.1X-Remote-IP: 127.8.8.1X-Cluster-Client-I: 127.8.8.1X-Remote-Addr: 127.8.8.1Coalfire used the LogReviewer tool to review logs for presence of IP header pollution in logs.$ python3 main.py --config <logReviewerConfigFile> --lrtc 5 --requestids-file <RequestIDsFile>LogReviewer Searching Logs for Overridden IP HeadersAlternatively, CloudWatch Logs Insights may be queried.Cloudwatch filters:fields @timestamp, @message| filter @message like /127\.8\.8\./| sort @timestamp desc| limit 2000Positive/Negative Results for IP Header PollutionsExample Rendered IP Header Pollutions (specify appended or replaced source IPs)The canary values were appended to the requests; however, they did not replace the existing real IP address information.Client-Side Log ReviewCoalfire reviewed the CloudTrail log events in the simulated customer (Coalfire Isengard) AWS account to:Validate the calls by the customer’s client to the service generated log eventsEnsure that no sensitive information was recorded in log eventsCredentialsService-side runtime environment detailsScreenshot of CloudTrail entries reviewedUIConsultants proxied a browser to the Burp Suite testing tool and visited each in-scope UI page/element, capturing the requests within the tool. These requests were modified to facilitate malicious input fuzzing, authorization, and other security tests per the OWASP Top 10 best practices.Screenshot of the UIScreenshot of the UI page INSERTHEREScreenshot of the UI page INSERTHEREScreenshot of the UI page INSERTHEREAuthenticationThe consultant confirmed that the application front-end pages and backend controllers properly enforced identity verification of the user. This was performed by modifying the authentication tokens between the client and the remote endpoint using the Burp Suite tool.Removing all authentication tokens:INSERT YOUR HTTP REQUEST&RESPONSE HEREInserting corrupt authentication token values:INSERT YOUR HTTP REQUEST&RESPONSE HEREProviding expired authentication tokens:INSERT YOUR HTTP REQUEST&RESPONSE HEREINSERT OTHER ATTACK TYPES AS APPLICABLEINSERT YOUR HTTP REQUEST&RESPONSE HEREExamples: brute force, password reset bypassMandatory Test Cases (Authorization)Authorization testing was conducted using the same IAM policies, roles, and test cases as found in the Mandatory Test Cases (MTCs) section. according to the custom authorization logic of the application.<<INSERT PROOF OF EACH AUTHZ TEST HERE>>Injection Attacks<<INSERT WORK EVIDENCE HERE of xss, sqli, etc.>>Click-jacking<<INSERT WORK EVIDENCE HERE>>Cross-Origin Resource Sharing (CORS)<<INSERT WORK EVIDENCE HERE>>Content-Security-Policy (CSP)<<INSERT WORK EVIDENCE HERE>>Server-side Request Forgery (SSRF)<<INSERT WORK EVIDENCE HERE>>Cross-site Request Forgery (CSRF)<<INSERT WORK EVIDENCE HERE>>ETC. ETC. ETC.<<INSERT WORK EVIDENCE HERE>>[Explicit Checks]Add in any additional items not covered in the previous sections. Insert captionTest Environment Special SetupProvide any additional information that may be useful to Appsec or the service team. Remove if not needed.Insert caption