diff --git a/cloudsplaining/output/dist/js/chunk-56fa57a3.js b/cloudsplaining/output/dist/js/chunk-56fa57a3.js new file mode 100644 index 00000000..538610ff --- /dev/null +++ b/cloudsplaining/output/dist/js/chunk-56fa57a3.js @@ -0,0 +1,2 @@ +(window["webpackJsonp"]=window["webpackJsonp"]||[]).push([["chunk-56fa57a3"],{"97a1":function(e,t,a){"use strict";a.r(t);var i=function(){var e=this,t=e.$createElement,a=e._self._c||t;return a("b-tab",["default"===e.appendices_content?a("div",[a("Glossary")],1):a("div",{domProps:{innerHTML:e._s(e.appendices_content)}})])},s=[],o=function(){var e=this,t=e.$createElement,a=e._self._c||t;return a("div",{staticStyle:{"text-align":"justify"}},[a("h3",{attrs:{id:"overview"}},[e._v("Glossary")]),a("p",[a("span",{domProps:{innerHTML:e._s(e.glossary)}})]),a("br"),a("br")])},n=[],r=a("fa5b"),c=a.n(r),l=a("d4cd")({html:!0,linkify:!0,typographer:!0});const d=l.render(c.a);var h={name:"Glossary",computed:{glossary(){return d}}},p=h,m=a("2877"),u=Object(m["a"])(p,o,n,!1,null,"1c16e608",null),f=u.exports,g={components:{Glossary:f},data(){return{appendices_content:appendices_content}}},y=g,A=Object(m["a"])(y,i,s,!1,null,null,null);t["default"]=A.exports},fa5b:function(e,t){var a='
The impact the risk would have on an organization if such a vulnerability were successfully exploited is rated according to criteria listed below. Note that these ratings are based on NIST 800-30 impact definitions.
These policies allow a combination of IAM actions that allow a principal with these permissions to escalate their privileges - for example, by creating an access key for another IAM user, or modifying their own permissions. This research was pioneered by Spencer Gietzen at Rhino Security Labs. Remediation Guidance can be found here.
Resource Exposure actions allow modification of Permissions to resource-based policies or otherwise can expose AWS resources to the public via similar actions that can lead to resource exposure - for example, the ability to modify AWS Resource Access Manager.
Infrastructure Modification describes IAM actions with "modify" capabilities, and can therefore lead to Resource Hijacking, unauthorized creation of Infrastructure, Backdoor creation, and/or modification of existing resources which can result in downtime.
Policies with Data Exfiltration potential allow certain read-only IAM actions without resource constraints, such as s3:GetObject
, ssm:GetParameter*
, or secretsmanager:GetSecretValue
. Unrestricted s3:GetObject
permissions has a long history of customer data leaks. ssm:GetParameter*
and secretsmanager:GetSecretValue
are both used to access secrets. rds:CopyDBSnapshot
and rds:CreateDBSnapshot
can be used to exfiltrate RDS database contents.
"Service Wildcard" is an unofficial way of referring to IAM policy statements that grant access to ALL actions under a service - like s3:*
. Prioritizing the remediation of policies with this characteristic can help to efficiently reduce the total count of high risk issues in the Cloudsplaining report.
Credentials Exposure actions return credentials as part of the API response , such as ecr:GetAuthorizationToken
, iam:UpdateAccessKey
, and others. The full list is below.
IAM Roles can be assumed by AWS Compute Services (such as EC2, ECS, EKS, or Lambda) can present greater risk than user-defined roles, especially if the AWS Compute service is on an instance that is directly or indirectly exposed to the internet. Flagging these roles is particularly useful to penetration testers (or attackers) under certain scenarios. For example, if an attacker obtains privileges to execute ssm:SendCommand and there are privileged EC2 instances with the SSM agent installed, they can effectively have the privileges of those EC2 instances. Remote Code Execution via AWS Systems Manager Agent was already a known escalation/exploitation path, but Cloudsplaining can make the process of identifying theses cases easier.
A JSON policy document in which you define the principals that you trust to assume the role. A role trust policy is a required resource-based policy that is attached to a role in IAM. The principals that you can specify in the trust policy include users, roles, accounts, and services.
This definition was taken from the AWS Documentation here.
An entity in AWS that can perform actions and access resources. A principal can be an AWS account root user, an IAM user, or a role.
An IAM identity that you can create in your account that has specific permissions. An IAM role has some similarities to an IAM user. Roles and users are both AWS identities with permissions policies that determine what the identity can and cannot do in AWS. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it. Also, a role does not have standard long-term credentials such as a password or access keys associated with it. Instead, when you assume a role, it provides you with temporary security credentials for your role session.
We are particularly interested in roles used for compute services - i.e., Compute Service Roles.
This definition was taken from the AWS Documentation here.
There are two types of Managed Policies: AWS-managed policies and Customer-managed policies. They are described below.
Criteria for selecting Managed Policies versus Inline policies can be found in the AWS documentation here.
AWS documentation on Customer-managed policies can be found here.
The following diagram illustrates customer managed policies. Each policy is an entity in IAM with its own Amazon Resource Name (ARN) that includes the policy name. Notice that the same policy can be attached to multiple principal entities—for example, the same DynamoDB-books-app policy is attached to two different IAM roles.
An AWS managed policy is a standalone policy that is created and administered by AWS. Standalone policy means that the policy has its own Amazon Resource Name (ARN) that includes the policy name. For example, arn:aws:iam::aws:policy/IAMReadOnlyAccess
is an AWS managed policy.
AWS documentation on AWS-managed policies can be found here.
The following diagram (taken from the AWS documentation) illustrates AWS managed policies. The diagram shows three AWS managed policies: AdministratorAccess, PowerUserAccess, and AWSCloudTrailReadOnlyAccess. Notice that a single AWS managed policy can be attached to principal entities in different AWS accounts, and to different principal entities in a single AWS account.
An inline policy is a policy that's embedded in an IAM identity (a user, group, or role). That is, the policy is an inherent part of the identity. You can create a policy and embed it in a identity, either when you create the identity or later.
AWS documentation on inline policies can be found here.
The following diagram illustrates inline policies. Each policy is an inherent part of the user, group, or role. Notice that two roles include the same policy (the DynamoDB-books-app policy), but they are not sharing a single policy; each role has its own copy of the policy.
Inline policies are useful if you want to maintain a strict one-to-one relationship between a policy and the identity that it's applied to. For example, you want to be sure that the permissions in a policy are not inadvertently assigned to an identity other than the one they're intended for. When you use an inline policy, the permissions in the policy cannot be inadvertently attached to the wrong identity. In addition, when you use the AWS Management Console to delete that identity, the policies embedded in the identity are deleted as well. That's because they are part of the principal entity.
';e.exports=a}}]); +//# sourceMappingURL=chunk-56fa57a3.js.map \ No newline at end of file diff --git a/cloudsplaining/output/dist/js/chunk-5e001255.js b/cloudsplaining/output/dist/js/chunk-5e001255.js new file mode 100644 index 00000000..fdd91104 --- /dev/null +++ b/cloudsplaining/output/dist/js/chunk-5e001255.js @@ -0,0 +1,2 @@ +(window["webpackJsonp"]=window["webpackJsonp"]||[]).push([["chunk-5e001255"],{"0c96":function(e,i){var t='After you've rewritten your IAM policy, we suggest two options for validating that it will pass Cloudsplaining and alleviate any remaining concerns:
scan-policy-file
command, which scans a single JSON policy file instead of the entire AWS Account's Authorization details.You can validate that your remediated policy passes Cloudsplaining by running the following command:
cloudsplaining scan-policy-file --input-file policy.json --exclusions-file exclusions.yml
When there are no more results, it passes!
parliament is an AWS IAM linting library. It reviews policies looking for problems such as:
This library duplicates (and adds to!) much of the functionality in the web console page when reviewing IAM policies in the browser.
You can use Parliament to scan your IAM policy by visiting the Web Page! https://parliament.summitroute.com/
';e.exports=t},"303b":function(e,i,t){"use strict";t.r(i);var o=function(){var e=this,i=e.$createElement,t=e._self._c||i;return t("b-tab",["default"===e.guidance_content?t("div",[t("Guidance")],1):t("div",{domProps:{innerHTML:e._s(e.guidance_content)}})])},s=[],n=function(){var e=this,i=e.$createElement,t=e._self._c||i;return t("div",{staticStyle:{"text-align":"justify"}},[t("h3",{attrs:{id:"triage-guidance"}},[e._v("Triaging")]),t("p",[t("span",{domProps:{innerHTML:e._s(e.triageGuidance)}})]),t("br"),t("br"),t("h3",{attrs:{id:"remediation-guidance"}},[e._v("Remediation")]),t("p",[t("span",{domProps:{innerHTML:e._s(e.remediationGuidance)}})]),t("br"),t("br"),t("h3",{attrs:{id:"validation-guidance"}},[e._v("Validation")]),t("p",[t("span",{domProps:{innerHTML:e._s(e.validationText)}})]),t("br"),t("br")])},a=[],r=t("dd2f"),l=t.n(r),c=t("5a07"),u=t.n(c),d=t("a91e"),p=t.n(d),h=t("0c96"),g=t.n(h),m=t("d4cd")({html:!0,linkify:!0,typographer:!0});const f=m.render(l.a),y=m.render(u.a),w=m.render(p.a),v=m.render(g.a);var b={name:"Guidance",computed:{overview(){return f},triageGuidance(){return y},remediationGuidance(){return w},validationText(){return v}}},A=b,x=t("2877"),k=Object(x["a"])(A,n,a,!1,null,"54f1a057",null),S=k.exports,M={components:{Guidance:S},data(){return{guidance_content:guidance_content}}},I=M,P=Object(x["a"])(I,o,s,!1,null,null,null);i["default"]=P.exports},"5a07":function(e,i){var t='It's essential to understand the context behind the findings that the report generates. Understanding the context behind the findings aids the assessor in triaging the results accurately.
This report generates findings on Policies that do not leverage resource constraints and identifies some attributes to help prioritize which ones to address - such as Privilege Escalation, Resource Exposure, and Data Exfiltration. These results help you to identify your IAM threat landscape and reduce blast radius. In the event of credential compromise, you can prevent an attacker from exploiting the risks mentioned above, in addition to preventing mass deletion, destruction, or modification of existing infrastructure.
However, this tool does not attempt to understand the context behind everything in your AWS account. It's possible to understand the context behind some of these things programmatically - whether the policy is applied to an instance profile, whether the policy is attached, whether inline IAM policies are in use, and whether or not AWS Managed Policies are in use. Only you know the context behind the design of your AWS infrastructure and the IAM strategy.
For example, an AWS Lambda policy used as a simple service checking the configuration of AWS infrastructure might be a good use case for resource constraints. Conversely, perhaps you applied the AdministratorAccess AWS-managed policy to an Instance Profile so that an EC2 instance can run Terraform to provision AWS resources via Infrastructure as Code. In the second example, the role is extremely permissive by design - and a tool can't automatically understand that context.
As such, the tool aims to:
To recap: you've followed these steps to generate this report:
cloudsplaining download --profile default --output default-account-details.json
cloudsplaining create-exclusions-file --output-file exclusions.yml
cloudsplaining scan --input-file default-account-details.json --exclusions-file exclusions.yml
An assessor can follow this general workflow:
When you ask the service/account owner team to fill out the Triage CSV worksheet, you can use some text like the following:
As part of our security assessment, our team ran Cloudsplaining on your AWS account. Cloudsplaining maps out the IAM risk landscape in a report, identifies where resource ARN constraints are not in use, and identifies other risks in IAM policies like Privilege Escalation, Data Exfiltration, and Resource Exposure/Permissions management. Remediating these issues, where applicable, will help to limit the blast radius in the case of compromised AWS credentials. We request that you review the HTML report and fill out the "Justification" field in the Triage worksheet. Based on the corresponding details in the HTML report, provide either (1) A justification on why the result is a False Positive, or (2) Identify that it is a legitimate finding.
When triaging your results, consider some of the factors listed below as you identify False Positives vs. legitimate findings. There are some scenarios where "Resource": "*"
access is by design and is therefore a false positive. This section covers some of the common scenarios.
Infrastructure Creation roles:
IAM roles that create infrastructure via Infrastructure as Code Technologies (for example, Terraform or CloudFormation) require high permission levels to provision AWS infrastructure. These will usually be false positives. When you see these instances, make sure that these roles are adequately protected. For instance, make sure that roles within the AWS account are not able to assume this role or affect its configuration in any way. Additionally, consider restricting the trust policy so that a set of explicitly stated IAM principals are the only ones who can assume that role. Take special care to audit instances of sts:AssumeRole
within this AWS account.
System roles vs. User Roles: System roles - IAM Roles applied to compute services, such as EC2 Instance Profiles, ECS Task Execution roles, or Lambda Task Execution roles - should almost always leverage resource ARN constraints for actions that perform "Write" actions. Exceptions to this could include Infrastructure provisioning or other edge cases.
Conversely, user roles will almost always be used against *
resources for the sake of convenience, innovation, and avoiding overly restrictive limitations. In the user role scenario, consider:
iam:*
)Organization-specific results
For example, perhaps you allow kms:Decrypt for * resources (by design) in your organization for one reason or another. Cloudsplaining flags this as a result. However, there are mitigating controls in place. Firstly, you leverage strict resource-based KMS key policies to lock down all KMS keys, explicitly stating individual IAM principals that are allowed to use them. Secondly, you provision all KMS keys with CloudFormation or Terraform, so you are confident that this pattern is consistent across all KMS keys in your AWS accounts. Therefore, kms:Decrypt
to *
resources is not a finding you are concerned about. In this case, you decide it is acceptable to exclude kms:Decrypt
from your results.
Conditions Logic:
This tool does not evaluate IAM Conditions logic. If your policies use wildcard resources but restrict according to condition keys, then it's possible this is a false positive. However, you might want to double-check the accuracy of the conditions logic in those IAM policies. While IAM conditions can be extremely powerful, implementation is also prone to human error. We suggest leveraging Parliament by Duo Labs (courtesy of Scott Piper), to lint your policies for accuracy - especially when IAM conditions are in use.
logs:CreateLogGroup
and logs:PutLogEvent
:
Depending on how your organization approaches CloudWatch Logs Agent configuration, IAM, and CloudWatch Logs Group naming conventions, it is sometimes near-impossible to prevent cross-contamination of logs or Log Injection to the Log Streams from other instance IDs. Cross-Contamination of CloudWatch Logs is an issue of its own that is definitely beyond the scope of this document - but consider this as a potential limitation by AWS when trying to identify a remediation plan.
After you have identified the False Positives, add the False Positive criteria to your custom Cloudsplaining exclusions file. The False Positives generally fall into one of two categories:
To make the exclusions file, create a YAML file that we will use to list out exclusions with the create-exclusions-file
command.
cloudsplaining create-exclusions-file\n
This will generate a file titled exclusions.yml
in your current directory.
The default exclusions file contains these contents:
# Policy names to exclude from evaluation\n# Suggestion: Add policies here that are known to be overly permissive by design, after you run the initial report.\npolicies:\n - "AWSServiceRoleFor*"\n - "*ServiceRolePolicy"\n - "*ServiceLinkedRolePolicy"\n - "AdministratorAccess" # Otherwise, this will take a long time\n - "service-role*"\n - "aws-service-role*"\n# Don't evaluate these roles, users, or groups as part of the evaluation\nroles:\n - "service-role*"\n - "aws-service-role*"\nusers:\n - ""\ngroups:\n - ""\n# Read-only actions to include in the results, such as s3:GetObject\n# By default, it includes Actions that could lead to Data Exfiltration\ninclude-actions:\n - "s3:GetObject"\n - "ssm:GetParameter"\n - "ssm:GetParameters"\n - "ssm:GetParametersByPath"\n - "secretsmanager:GetSecretValue"\n# Write actions to include from the results, such as kms:Decrypt\nexclude-actions:\n - ""\n
Add whatever values you want to the above depending on your organization's context.
Under policies
, list the path of policy names that you want to exclude.
If you want to exclude a role titled MyRole
, list MyRole
or MyR*
in the roles
list.
You can follow the same approach for users
and groups
list.
Now, run the scan to generate a new Cloudsplaining report that considers your exclusions criteria. This way, you are working with a report version that consists of True Positives only.
cloudsplaining scan --input-file default.json --exclusions-file exclusions.yml\n
You can now proceed to the Remediation stage.
';e.exports=t},a91e:function(e,i){var t='Depending on the existing workload of the engineering team addressing your concerns, the team might ask to address high priority items first rather than addressing all items, especially if the report is quite large. In this scenario, consider instructing the team to address High Priority Risks and the usage of AWS-Managed Policies first.
High priority risks:
These include Privilege Escalation, Data Exfiltration, and Potential Resource Exposure/Permissions management. This report highlights each finding that has these high priority risks.
Moving from AWS Managed Policies over to custom policies:
AWS managed policies always include access to *
resources because AWS provides these same policies universally to all customer accounts. If this report flags any AWS-managed policies, it means that the account/service owner team will not only have to implement resource constraints - they will have to create a custom IAM policy to do so. To limit this work, it is best to migrate away from the root cause of the problem - using AWS managed policies.
You can then queue the work for remediating the other Customer-managed policies that do not have the High-Priority Risks attributes. Implementing resource ARN constraints for True Positives is still important, since overly permissive "Write" actions can cause modification or deletion of AWS resources by a bad actor with compromised credentials, resulting in downtime.
We suggest two options for remediating each finding:
For guidance on how to use Policy Sentry, please see the documentation here. This is highly suggested - within 10 minutes of learning the tool, creating a secure IAM policy becomes a matter of:
policy_sentry create-template --output-file crud.yml --template-type crud
policy_sentry write-policy --input-file crud.yml
For guidance on how to write secure IAM Policies by hand, see the tutorial here. Just be aware - you'll spend a lot of time looking at the AWS Documentation on IAM Actions, Resources, and Condition Keys, which can become quite tedious and time-consuming.
';e.exports=t},dd2f:function(e,i){var t='This report contains the security assessment results from Cloudsplaining, which maps out the IAM risk landscape in a report, identifies where resource ARN constraints are not used, and identifies other risks in IAM policies like Privilege Escalation, Resource Exposure, Infrastructure Modification, and Data Exfiltration. Remediating these issues, where necessary, will help to limit the blast radius in the case of compromised AWS credentials.
';e.exports=t}}]); +//# sourceMappingURL=chunk-5e001255.js.map \ No newline at end of file diff --git a/cloudsplaining/output/dist/js/index.js b/cloudsplaining/output/dist/js/index.js index 294f4af9..9917f0b8 100644 --- a/cloudsplaining/output/dist/js/index.js +++ b/cloudsplaining/output/dist/js/index.js @@ -1,4 +1,4 @@ -(function(e){var t={};function a(o){if(t[o])return t[o].exports;var s=t[o]={i:o,l:!1,exports:{}};return e[o].call(s.exports,s,s.exports,a),s.l=!0,s.exports}a.m=e,a.c=t,a.d=function(e,t,o){a.o(e,t)||Object.defineProperty(e,t,{enumerable:!0,get:o})},a.r=function(e){"undefined"!==typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})},a.t=function(e,t){if(1&t&&(e=a(e)),8&t)return e;if(4&t&&"object"===typeof e&&e&&e.__esModule)return e;var o=Object.create(null);if(a.r(o),Object.defineProperty(o,"default",{enumerable:!0,value:e}),2&t&&"string"!=typeof e)for(var s in e)a.d(o,s,function(t){return e[t]}.bind(null,s));return o},a.n=function(e){var t=e&&e.__esModule?function(){return e["default"]}:function(){return e};return a.d(t,"a",t),t},a.o=function(e,t){return Object.prototype.hasOwnProperty.call(e,t)},a.p="",a(a.s=0)})({0:function(e,t,a){e.exports=a("5a00")},"0068":function(e,t,a){"use strict";function o(e){return Object.prototype.toString.call(e)}function s(e){return"[object String]"===o(e)}var i=Object.prototype.hasOwnProperty;function n(e,t){return i.call(e,t)}function r(e){var t=Array.prototype.slice.call(arguments,1);return t.forEach((function(t){if(t){if("object"!==typeof t)throw new TypeError(t+"must be object");Object.keys(t).forEach((function(a){e[a]=t[a]}))}})),e}function c(e,t,a){return[].concat(e.slice(0,t),a,e.slice(t+1))}function l(e){return!(e>=55296&&e<=57343)&&(!(e>=64976&&e<=65007)&&(65535!==(65535&e)&&65534!==(65535&e)&&(!(e>=0&&e<=8)&&(11!==e&&(!(e>=14&&e<=31)&&(!(e>=127&&e<=159)&&!(e>1114111)))))))}function h(e){if(e>65535){e-=65536;var t=55296+(e>>10),a=56320+(1023&e);return String.fromCharCode(t,a)}return String.fromCharCode(e)}var d=/\\([!"#$%&'()*+,\-.\/:;<=>?@[\\\]^_`{|}~])/g,m=/&([a-z#][a-z0-9]{1,31});/gi,p=new RegExp(d.source+"|"+m.source,"gi"),u=/^#((?:x[a-f0-9]{1,8}|[0-9]{1,8}))$/i,f=a("bd68");function g(e,t){var a;return n(f,t)?f[t]:35===t.charCodeAt(0)&&u.test(t)&&(a="x"===t[1].toLowerCase()?parseInt(t.slice(2),16):parseInt(t.slice(1),10),l(a))?h(a):e}function v(e){return e.indexOf("\\")<0?e:e.replace(d,"$1")}function A(e){return e.indexOf("\\")<0&&e.indexOf("&")<0?e:e.replace(p,(function(e,t,a){return t||g(e,a)}))}var P=/[&<>"]/,b=/[&<>"]/g,y={"&":"&","<":"<",">":">",'"':"""};function w(e){return y[e]}function I(e){return P.test(e)?e.replace(b,w):e}var z=/[.?*+^$[\]\\(){}|-]/g;function C(e){return e.replace(z,"\\$&")}function D(e){switch(e){case 9:case 32:return!0}return!1}function R(e){if(e>=8192&&e<=8202)return!0;switch(e){case 9:case 10:case 11:case 12:case 13:case 32:case 160:case 5760:case 8239:case 8287:case 12288:return!0}return!1}var S=a("7ca0");function _(e){return S.test(e)}function k(e){switch(e){case 33:case 34:case 35:case 36:case 37:case 38:case 39:case 40:case 41:case 42:case 43:case 44:case 45:case 46:case 47:case 58:case 59:case 60:case 61:case 62:case 63:case 64:case 91:case 92:case 93:case 94:case 95:case 96:case 123:case 124:case 125:case 126:return!0;default:return!1}}function M(e){return e=e.trim().replace(/\s+/g," "),"Ṿ"==="ẞ".toLowerCase()&&(e=e.replace(/ẞ/g,"ß")),e.toLowerCase().toUpperCase()}t.lib={},t.lib.mdurl=a("d8a6"),t.lib.ucmicro=a("d5d1"),t.assign=r,t.isString=s,t.has=n,t.unescapeMd=v,t.unescapeAll=A,t.isValidEntityCode=l,t.fromCodePoint=h,t.escapeHtml=I,t.arrayReplaceAt=c,t.isSpace=D,t.isWhiteSpace=R,t.isMdAsciiPunct=k,t.isPunctChar=_,t.escapeRE=C,t.normalizeReference=M},"04f8":function(e,t,a){"use strict";var o=a("1212"),s=a("d039"),i=a("cfe9"),n=i.String;e.exports=!!Object.getOwnPropertySymbols&&!s((function(){var e=Symbol("symbol detection");return!n(e)||!(Object(e)instanceof Symbol)||!Symbol.sham&&o&&o<41}))},"06cf":function(e,t,a){"use strict";var o=a("83ab"),s=a("c65b"),i=a("d1e7"),n=a("5c6c"),r=a("fc6a"),c=a("a04b"),l=a("1a2d"),h=a("0cfb"),d=Object.getOwnPropertyDescriptor;t.f=o?d:function(e,t){if(e=r(e),t=c(t),h)try{return d(e,t)}catch(a){}if(l(e,t))return n(!s(i.f,e,t),e[t])}},"0758":function(e,t,a){"use strict";var o=a("0068").isSpace;e.exports=function(e,t,a,s){var i,n,r,c,l=e.bMarks[t]+e.tShift[t],h=e.eMarks[t];if(e.sCount[t]-e.blkIndent>=4)return!1;if(i=e.src.charCodeAt(l),35!==i||l>=h)return!1;n=1,i=e.src.charCodeAt(++l);while(35===i&&lIf your IAM policy does require access to those actions, you should provide an explanation. Example requirements include:
*
resources because human users assume this role. We have restricted the access levels appropriate to what the user needs.*
resources, but the statement enforces least privilege via IAM condition statements.While other edge cases and justifications exist, the above items are the most common justifications. For information on Common False Positive Scenarios, see the documentation here.
';e.exports=a},"08ae":function(e,t,a){"use strict";var o=a("0068"),s=a("565b"),i=a("7cc2"),n=a("a915"),r=a("7696"),c=a("4cb4"),l=a("fbcd"),h=a("d8a6"),d=a("9d88"),m={default:a("8a31"),zero:a("1caa"),commonmark:a("428d")},p=/^(vbscript|javascript|file|data):/,u=/^data:image\/(gif|png|jpeg|webp);/;function f(e){var t=e.trim().toLowerCase();return!p.test(t)||!!u.test(t)}var g=["http:","https:","mailto:"];function v(e){var t=h.parse(e,!0);if(t.hostname&&(!t.protocol||g.indexOf(t.protocol)>=0))try{t.hostname=d.toASCII(t.hostname)}catch(a){}return h.encode(h.format(t))}function A(e){var t=h.parse(e,!0);if(t.hostname&&(!t.protocol||g.indexOf(t.protocol)>=0))try{t.hostname=d.toUnicode(t.hostname)}catch(a){}return h.decode(h.format(t),h.decode.defaultChars+"%")}function P(e,t){if(!(this instanceof P))return new P(e,t);t||o.isString(e)||(t=e||{},e="default"),this.inline=new c,this.block=new r,this.core=new n,this.renderer=new i,this.linkify=new l,this.validateLink=f,this.normalizeLink=v,this.normalizeLinkText=A,this.utils=o,this.helpers=o.assign({},s),this.options={},this.configure(e),t&&this.set(t)}P.prototype.set=function(e){return o.assign(this.options,e),this},P.prototype.configure=function(e){var t,a=this;if(o.isString(e)&&(t=e,e=m[t],!e))throw new Error('Wrong `markdown-it` preset "'+t+'", check name');if(!e)throw new Error("Wrong `markdown-it` preset, can't be empty");return e.options&&a.set(e.options),e.components&&Object.keys(e.components).forEach((function(t){e.components[t].rules&&a[t].ruler.enableOnly(e.components[t].rules),e.components[t].rules2&&a[t].ruler2.enableOnly(e.components[t].rules2)})),this},P.prototype.enable=function(e,t){var a=[];Array.isArray(e)||(e=[e]),["core","block","inline"].forEach((function(t){a=a.concat(this[t].ruler.enable(e,!0))}),this),a=a.concat(this.inline.ruler2.enable(e,!0));var o=e.filter((function(e){return a.indexOf(e)<0}));if(o.length&&!t)throw new Error("MarkdownIt. Failed to enable unknown rule(s): "+o);return this},P.prototype.disable=function(e,t){var a=[];Array.isArray(e)||(e=[e]),["core","block","inline"].forEach((function(t){a=a.concat(this[t].ruler.disable(e,!0))}),this),a=a.concat(this.inline.ruler2.disable(e,!0));var o=e.filter((function(e){return a.indexOf(e)<0}));if(o.length&&!t)throw new Error("MarkdownIt. Failed to disable unknown rule(s): "+o);return this},P.prototype.use=function(e){var t=[this].concat(Array.prototype.slice.call(arguments,1));return e.apply(e,t),this},P.prototype.parse=function(e,t){if("string"!==typeof e)throw new Error("Input data should be a String");var a=new this.core.State(e,this,t);return this.core.process(a),a.tokens},P.prototype.render=function(e,t){return t=t||{},this.renderer.render(this.parse(e,t),this.options,t)},P.prototype.parseInline=function(e,t){var a=new this.core.State(e,this,t);return a.inlineMode=!0,this.core.process(a),a.tokens},P.prototype.renderInline=function(e,t){return t=t||{},this.renderer.render(this.parseInline(e,t),this.options,t)},e.exports=P},"096b":function(e,t,a){"use strict";function o(e,t,a){this.type=e,this.tag=t,this.attrs=null,this.map=null,this.nesting=a,this.level=0,this.children=null,this.content="",this.markup="",this.info="",this.meta=null,this.block=!1,this.hidden=!1}o.prototype.attrIndex=function(e){var t,a,o;if(!this.attrs)return-1;for(t=this.attrs,a=0,o=t.length;aThis policy contains actions that could lead to Credentials Exposure. These actions return credentials as part of the API response, such as ecr:GetAuthorizationToken
, iam:UpdateAccessKey
, and others. The full list is maintained here.
This policy allows "Infrastructure Modification" actions. Infrastructure Modification describes IAM actions with "modify" capabilities, and can therefore lead to Resource Hijacking, unauthorized creation of Infrastructure, Backdoor creation, and/or modification of existing resources which can result in downtime. For example, ec2:AuthorizeSecurityGroupIngress
grants the permission to add one or more inbound rules to a security group; malicious usage of this IAM action could potentially lead to downtime or unintentional exposure of compute resources.
If your IAM policy does require access to those actions, you should provide an explanation. Example requirements include:
*
resources because human users assume this role. We have restricted the access levels appropriate to what the user needs.*
resources, but the statement enforces least privilege via IAM condition statements.While other edge cases and justifications exist, the above items are the most common justifications. For information on Common False Positive Scenarios, see the documentation here.
';e.exports=a},"08ae":function(e,t,a){"use strict";var o=a("0068"),s=a("565b"),i=a("7cc2"),n=a("a915"),r=a("7696"),c=a("4cb4"),l=a("fbcd"),h=a("d8a6"),d=a("9d88"),m={default:a("8a31"),zero:a("1caa"),commonmark:a("428d")},p=/^(vbscript|javascript|file|data):/,u=/^data:image\/(gif|png|jpeg|webp);/;function f(e){var t=e.trim().toLowerCase();return!p.test(t)||!!u.test(t)}var g=["http:","https:","mailto:"];function v(e){var t=h.parse(e,!0);if(t.hostname&&(!t.protocol||g.indexOf(t.protocol)>=0))try{t.hostname=d.toASCII(t.hostname)}catch(a){}return h.encode(h.format(t))}function A(e){var t=h.parse(e,!0);if(t.hostname&&(!t.protocol||g.indexOf(t.protocol)>=0))try{t.hostname=d.toUnicode(t.hostname)}catch(a){}return h.decode(h.format(t),h.decode.defaultChars+"%")}function P(e,t){if(!(this instanceof P))return new P(e,t);t||o.isString(e)||(t=e||{},e="default"),this.inline=new c,this.block=new r,this.core=new n,this.renderer=new i,this.linkify=new l,this.validateLink=f,this.normalizeLink=v,this.normalizeLinkText=A,this.utils=o,this.helpers=o.assign({},s),this.options={},this.configure(e),t&&this.set(t)}P.prototype.set=function(e){return o.assign(this.options,e),this},P.prototype.configure=function(e){var t,a=this;if(o.isString(e)&&(t=e,e=m[t],!e))throw new Error('Wrong `markdown-it` preset "'+t+'", check name');if(!e)throw new Error("Wrong `markdown-it` preset, can't be empty");return e.options&&a.set(e.options),e.components&&Object.keys(e.components).forEach((function(t){e.components[t].rules&&a[t].ruler.enableOnly(e.components[t].rules),e.components[t].rules2&&a[t].ruler2.enableOnly(e.components[t].rules2)})),this},P.prototype.enable=function(e,t){var a=[];Array.isArray(e)||(e=[e]),["core","block","inline"].forEach((function(t){a=a.concat(this[t].ruler.enable(e,!0))}),this),a=a.concat(this.inline.ruler2.enable(e,!0));var o=e.filter((function(e){return a.indexOf(e)<0}));if(o.length&&!t)throw new Error("MarkdownIt. Failed to enable unknown rule(s): "+o);return this},P.prototype.disable=function(e,t){var a=[];Array.isArray(e)||(e=[e]),["core","block","inline"].forEach((function(t){a=a.concat(this[t].ruler.disable(e,!0))}),this),a=a.concat(this.inline.ruler2.disable(e,!0));var o=e.filter((function(e){return a.indexOf(e)<0}));if(o.length&&!t)throw new Error("MarkdownIt. Failed to disable unknown rule(s): "+o);return this},P.prototype.use=function(e){var t=[this].concat(Array.prototype.slice.call(arguments,1));return e.apply(e,t),this},P.prototype.parse=function(e,t){if("string"!==typeof e)throw new Error("Input data should be a String");var a=new this.core.State(e,this,t);return this.core.process(a),a.tokens},P.prototype.render=function(e,t){return t=t||{},this.renderer.render(this.parse(e,t),this.options,t)},P.prototype.parseInline=function(e,t){var a=new this.core.State(e,this,t);return a.inlineMode=!0,this.core.process(a),a.tokens},P.prototype.renderInline=function(e,t){return t=t||{},this.renderer.render(this.parseInline(e,t),this.options,t)},e.exports=P},"096b":function(e,t,a){"use strict";function o(e,t,a){this.type=e,this.tag=t,this.attrs=null,this.map=null,this.nesting=a,this.level=0,this.children=null,this.content="",this.markup="",this.info="",this.meta=null,this.block=!1,this.hidden=!1}o.prototype.attrIndex=function(e){var t,a,o;if(!this.attrs)return-1;for(t=this.attrs,a=0,o=t.length;aThis policy contains actions that could lead to Credentials Exposure. These actions return credentials as part of the API response, such as ecr:GetAuthorizationToken
, iam:UpdateAccessKey
, and others. The full list is maintained here.
This policy allows "Infrastructure Modification" actions. Infrastructure Modification describes IAM actions with "modify" capabilities, and can therefore lead to Resource Hijacking, unauthorized creation of Infrastructure, Backdoor creation, and/or modification of existing resources which can result in downtime. For example, ec2:AuthorizeSecurityGroupIngress
grants the permission to add one or more inbound rules to a security group; malicious usage of this IAM action could potentially lead to downtime or unintentional exposure of compute resources.