mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-06-28 01:13:44 -07:00
fix links
This commit is contained in:
Carlos Polop
@@ -43,7 +43,7 @@ From a Red Team point of view, the **first step to compromise an AWS environment
|
||||
- `C:\Users\USERNAME\.aws\credentials`
|
||||
- 3rd parties **breached**
|
||||
- **Internal** Employee
|
||||
- [**Cognito** ](aws-services/aws-cognito-enum/#cognito)credentials
|
||||
- [**Cognito** ](aws-services/aws-cognito-enum/index.html#cognito)credentials
|
||||
|
||||
Or by **compromising an unauthenticated service** exposed:
|
||||
|
||||
@@ -123,7 +123,7 @@ AWS has an astonishing amount of services, in the following page you will find *
|
||||
aws-services/
|
||||
{{#endref}}
|
||||
|
||||
Note that you **don't** need to perform all the work **manually**, below in this post you can find a **section about** [**automatic tools**](./#automated-tools).
|
||||
Note that you **don't** need to perform all the work **manually**, below in this post you can find a **section about** [**automatic tools**](#automated-tools).
|
||||
|
||||
Moreover, in this stage you might discovered **more services exposed to unauthenticated users,** you might be able to exploit them:
|
||||
|
||||
|
||||
+1
-1
@@ -85,7 +85,7 @@ The way to grant **access to over K8s to more AWS IAM users or roles** is using
|
||||
> [!WARNING]
|
||||
> Therefore, anyone with **write access** over the config map **`aws-auth`** will be able to **compromise the whole cluster**.
|
||||
|
||||
For more information about how to **grant extra privileges to IAM roles & users** in the **same or different account** and how to **abuse** this to [**privesc check this page**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/#aws-eks-aws-auth-configmaps).
|
||||
For more information about how to **grant extra privileges to IAM roles & users** in the **same or different account** and how to **abuse** this to [**privesc check this page**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#aws-eks-aws-auth-configmaps).
|
||||
|
||||
Check also[ **this awesome**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **post to learn how the authentication IAM -> Kubernetes work**.
|
||||
|
||||
|
||||
+1
-1
@@ -57,7 +57,7 @@ The `cloudformation:SetStackPolicy` permission can be used to **give yourself `U
|
||||
|
||||
An attacker with permissions to **pass a role and create & execute a ChangeSet** can **create/update a new cloudformation stack abuse the cloudformation service roles** just like with the CreateStack or UpdateStack.
|
||||
|
||||
The following exploit is a **variation of the**[ **CreateStack one**](./#iam-passrole-cloudformation-createstack) using the **ChangeSet permissions** to create a stack.
|
||||
The following exploit is a **variation of the**[ **CreateStack one**](#iam-passrole-cloudformation-createstack) using the **ChangeSet permissions** to create a stack.
|
||||
|
||||
```bash
|
||||
aws cloudformation create-change-set \
|
||||
|
||||
@@ -14,7 +14,7 @@ For more info about Cognito check:
|
||||
|
||||
As Cognito can grant **IAM role credentials** to both **authenticated** an **unauthenticated** **users**, if you locate the **Identity Pool ID** of an application (should be hardcoded on it) you can obtain new credentials and therefore privesc (inside an AWS account where you probably didn't even have any credential previously).
|
||||
|
||||
For more information [**check this page**](../aws-unauthenticated-enum-access/#cognito).
|
||||
For more information [**check this page**](../aws-unauthenticated-enum-access/index.html#cognito).
|
||||
|
||||
**Potential Impact:** Direct privesc to the services role attached to unauth users (and probably to the one attached to auth users).
|
||||
|
||||
@@ -269,7 +269,7 @@ aws cognito-idp create-identity-provider \
|
||||
This is a very common permission by default in roles of Cognito Identity Pools. Even if a wildcard in a permissions always looks bad (specially coming from AWS), the **given permissions aren't super useful from an attackers perspective**.
|
||||
|
||||
This permission allows to read use information of Identity Pools and Identity IDs inside Identity Pools (which isn't sensitive info).\
|
||||
Identity IDs might have [**Datasets**](https://docs.aws.amazon.com/cognitosync/latest/APIReference/API_Dataset.html) assigned to them, which are information of the sessions (AWS define it like a **saved game**). It might be possible that this contain some kind of sensitive information (but the probability is pretty low). You can find in the [**enumeration page**](../aws-services/aws-cognito-enum/) how to access this information.
|
||||
Identity IDs might have [**Datasets**](https://docs.aws.amazon.com/cognitosync/latest/APIReference/API_Dataset.html) assigned to them, which are information of the sessions (AWS define it like a **saved game**). It might be possible that this contain some kind of sensitive information (but the probability is pretty low). You can find in the [**enumeration page**](../aws-services/aws-cognito-enum/index.html) how to access this information.
|
||||
|
||||
An attacker could also use these permissions to **enroll himself to a Cognito stream that publish changes** on these datases or a **lambda that triggers on cognito events**. I haven't seen this being used, and I wouldn't expect sensitive information here, but it isn't impossible.
|
||||
|
||||
|
||||
+1
-1
@@ -13,7 +13,7 @@ For more information check:
|
||||
## From management Account to children accounts
|
||||
|
||||
If you compromise the root/management account, chances are you can compromise all the children accounts.\
|
||||
To [**learn how check this page**](../#compromising-the-organization).
|
||||
To [**learn how check this page**](../index.html#compromising-the-organization).
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
+2
-2
@@ -130,7 +130,7 @@ aws cognito-identity get-credentials-for-identity --identity-id <identity_id> --
|
||||
|
||||
### Enhanced vs Basic Authentication flow
|
||||
|
||||
The previous section followed the **default enhanced authentication flow**. This flow sets a **restrictive** [**session policy**](../../aws-basic-information/#session-policies) to the IAM role session generated. This policy will only allow the session to [**use the services from this list**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services) (even if the role had access to other services).
|
||||
The previous section followed the **default enhanced authentication flow**. This flow sets a **restrictive** [**session policy**](../../aws-basic-information/index.html#session-policies) to the IAM role session generated. This policy will only allow the session to [**use the services from this list**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services) (even if the role had access to other services).
|
||||
|
||||
However, there is a way to bypass this, if the **Identity pool has "Basic (Classic) Flow" enabled**, the user will be able to obtain a session using that flow which **won't have that restrictive session policy**.
|
||||
|
||||
@@ -151,7 +151,7 @@ aws sts assume-role-with-web-identity --role-arn "arn:aws:iam::<acc_id>:role/<ro
|
||||
|
||||
> `An error occurred (InvalidParameterException) when calling the GetOpenIdToken operation: Basic (classic) flow is not enabled, please use enhanced flow.`
|
||||
|
||||
Having a set of IAM credentials you should check [which access you have](../../#whoami) and try to [escalate privileges](../../aws-privilege-escalation/).
|
||||
Having a set of IAM credentials you should check [which access you have](../../index.html#whoami) and try to [escalate privileges](../../aws-privilege-escalation/index.html).
|
||||
|
||||
### Authenticated
|
||||
|
||||
|
||||
@@ -32,7 +32,7 @@ aws lightsail get-key-pairs
|
||||
|
||||
### Analyse Snapshots
|
||||
|
||||
It's possible to generate **instance and relational database snapshots from lightsail**. Therefore you can check those the same way you can check [**EC2 snapshots**](aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/#ebs) and [**RDS snapshots**](aws-relational-database-rds-enum.md#enumeration).
|
||||
It's possible to generate **instance and relational database snapshots from lightsail**. Therefore you can check those the same way you can check [**EC2 snapshots**](aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/index.html#ebs) and [**RDS snapshots**](aws-relational-database-rds-enum.md#enumeration).
|
||||
|
||||
### Metadata
|
||||
|
||||
|
||||
@@ -140,7 +140,7 @@ Using this mechanism, you are able to utilize your own provided keys and use an
|
||||
|
||||
### **Enumeration**
|
||||
|
||||
One of the traditional main ways of compromising AWS orgs start by compromising buckets publicly accesible. **You can find** [**public buckets enumerators in this page**](../aws-unauthenticated-enum-access/#s3-buckets)**.**
|
||||
One of the traditional main ways of compromising AWS orgs start by compromising buckets publicly accesible. **You can find** [**public buckets enumerators in this page**](../aws-unauthenticated-enum-access/index.html#s3-buckets)**.**
|
||||
|
||||
```bash
|
||||
# Get buckets ACLs
|
||||
|
||||
@@ -132,7 +132,7 @@ Get-AzRoleAssignment -SignInName test@corp.onmicrosoft.com # For current user
|
||||
|
||||
### ENtra ID Enumeration
|
||||
|
||||
By default, any user should have **enough permissions to enumerate** things such us, users, groups, roles, service principals... (check [default AzureAD permissions](az-basic-information/#default-user-permissions)).\
|
||||
By default, any user should have **enough permissions to enumerate** things such us, users, groups, roles, service principals... (check [default AzureAD permissions](az-basic-information/index.html#default-user-permissions)).\
|
||||
You can find here a guide:
|
||||
|
||||
{{#ref}}
|
||||
|
||||
@@ -51,7 +51,7 @@ From the **compromised machine to the cloud**:
|
||||
|
||||
From compromising **AD** to compromising the **Cloud** and from compromising the **Cloud to** compromising **AD**:
|
||||
|
||||
- [**Azure AD Connect**](azure-ad-connect-hybrid-identity/)
|
||||
- [**Azure AD Connect**](azure-ad-connect-hybrid-identity/index.html)
|
||||
- **Another way to pivot from could to On-Prem is** [**abusing Intune**](../az-services/intune.md)
|
||||
|
||||
#### [Roadtx](https://github.com/dirkjanm/ROADtools)
|
||||
|
||||
+1
-1
@@ -171,7 +171,7 @@ Set-AzVMDscExtension `
|
||||
|
||||
<summary>Hybrid Runbook Worker</summary>
|
||||
|
||||
This is a VM extension that would allow to execute runbooks in VMs from an automation account. For more information check the [Automation Accounts service](../az-services/az-automation-account/).
|
||||
This is a VM extension that would allow to execute runbooks in VMs from an automation account. For more information check the [Automation Accounts service](../az-services/az-automation-account/index.html).
|
||||
|
||||
</details>
|
||||
|
||||
|
||||
@@ -1015,7 +1015,7 @@ It allows the admin to configure it to **block** attempts when the risk is "Low
|
||||
|
||||
### Entra Password Protection
|
||||
|
||||
Entra Password Protection ([https://portal.azure.com/#view/Microsoft_AAD_ConditionalAccess/PasswordProtectionBlade](https://portal.azure.com/#view/Microsoft_AAD_ConditionalAccess/PasswordProtectionBlade)) is a security feature that **helps prevent the abuse of weak passwords in by locking out accounts when several unsuccessful login attempts happen**.\
|
||||
Entra Password Protection ([https://portal.azure.com/index.html#view/Microsoft_AAD_ConditionalAccess/PasswordProtectionBlade](https://portal.azure.com/#view/Microsoft_AAD_ConditionalAccess/PasswordProtectionBlade)) is a security feature that **helps prevent the abuse of weak passwords in by locking out accounts when several unsuccessful login attempts happen**.\
|
||||
It also allows to **ban a custom password list** that you need to provide.
|
||||
|
||||
It can be **applied both** at the cloud level and on-premises Active Directory.
|
||||
|
||||
@@ -56,12 +56,12 @@ In a **Windows** function using NodeJS the code was located in **`C:\home\site\w
|
||||
|
||||
### **Managed Identities & Metadata**
|
||||
|
||||
Just like [**VMs**](vms/), Functions can have **Managed Identities** of 2 types: System assigned and User assigned.
|
||||
Just like [**VMs**](vms/index.html), Functions can have **Managed Identities** of 2 types: System assigned and User assigned.
|
||||
|
||||
The **system assigned** one will be a managed identity that **only the function** that has it assigned would be able to use, while the **user assigned** managed identities are managed identities that **any other Azure service will be able to use**.
|
||||
|
||||
> [!NOTE]
|
||||
> Just like in [**VMs**](vms/), Functions can have **1 system assigned** managed identity and **several user assigned** ones, so it's always important to try to find all of them if you compromise the function because you might be able to escalate privileges to several managed identities from just one Function.
|
||||
> Just like in [**VMs**](vms/index.html), Functions can have **1 system assigned** managed identity and **several user assigned** ones, so it's always important to try to find all of them if you compromise the function because you might be able to escalate privileges to several managed identities from just one Function.
|
||||
>
|
||||
> If a no system managed identity is used but one or more user managed identities are attached to a function, by default you won’t be able to get any token.
|
||||
|
||||
|
||||
@@ -635,7 +635,7 @@ Set-AzVMDscExtension `
|
||||
|
||||
<summary>Hybrid Runbook Worker</summary>
|
||||
|
||||
This is a VM extension that would allow to execute runbooks in VMs from an automation account. For more information check the [Automation Accounts service](../az-automation-account/).
|
||||
This is a VM extension that would allow to execute runbooks in VMs from an automation account. For more information check the [Automation Accounts service](../az-automation-account/index.html).
|
||||
|
||||
</details>
|
||||
|
||||
|
||||
@@ -26,7 +26,7 @@ In order to audit a GCP environment it's very important to know: which **service
|
||||
From a Red Team point of view, the **first step to compromise a GCP environment** is to manage to obtain some **credentials**. Here you have some ideas on how to do that:
|
||||
|
||||
- **Leaks** in github (or similar) - OSINT
|
||||
- **Social** Engineering (Check the page [**Workspace Security**](../workspace-security/))
|
||||
- **Social** Engineering (Check the page [**Workspace Security**](../workspace-security/index.html))
|
||||
- **Password** reuse (password leaks)
|
||||
- Vulnerabilities in GCP-Hosted Applications
|
||||
- [**Server Side Request Forgery**](https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf) with access to metadata endpoint
|
||||
@@ -115,7 +115,7 @@ GCP has an astonishing amount of services, in the following page you will find *
|
||||
gcp-services/
|
||||
{{#endref}}
|
||||
|
||||
Note that you **don't** need to perform all the work **manually**, below in this post you can find a **section about** [**automatic tools**](./#automatic-tools).
|
||||
Note that you **don't** need to perform all the work **manually**, below in this post you can find a **section about** [**automatic tools**](#automatic-tools).
|
||||
|
||||
Moreover, in this stage you might discovered **more services exposed to unauthenticated users,** you might be able to exploit them:
|
||||
|
||||
|
||||
@@ -81,7 +81,7 @@ https://www.googleapis.com/auth/userinfo.email
|
||||
|
||||
it's interesting to see how this app supports the **`drive`** scope, which could allow a user to escalate from GCP to Workspace if an attacker manages to force the user to generate a token with this scope.
|
||||
|
||||
**Check how to** [**abuse this here**](../gcp-to-workspace-pivoting/#abusing-gcloud)**.**
|
||||
**Check how to** [**abuse this here**](../gcp-to-workspace-pivoting/index.html#abusing-gcloud)**.**
|
||||
|
||||
### Service Accounts
|
||||
|
||||
|
||||
+1
-1
@@ -101,7 +101,7 @@ def injection():
|
||||
|
||||
# Get relevant function names
|
||||
handler_fname = os.environ.get("FUNCTION_TARGET") # Cloud Function env variable indicating the name of the function to habdle requests
|
||||
source_path = os.environ.get("FUNCTION_SOURCE", "./main.py") # Path to the source file of the Cloud Function (./main.py by default)
|
||||
source_path = os.environ.get("FUNCTION_SOURCE", "./main.py") # Path to the source file of the Cloud Function (main.py by default)
|
||||
realpath = os.path.realpath(source_path) # Get full path
|
||||
|
||||
# Get the modules representations
|
||||
|
||||
+1
-1
@@ -133,7 +133,7 @@ The tool [patchy](https://github.com/rek7/patchy) could been used in the past fo
|
||||
|
||||
### Bypass Access Scopes
|
||||
|
||||
Following this link you find some [**ideas to try to bypass access scopes**](../).
|
||||
Following this link you find some [**ideas to try to bypass access scopes**](../index.html).
|
||||
|
||||
### Local Privilege Escalation in GCP Compute instance
|
||||
|
||||
|
||||
@@ -69,7 +69,7 @@ As we are in a GCP environment, you will also be able to **get the nodepool GCP
|
||||
|
||||
### `container.secrets.get` | `container.secrets.list`
|
||||
|
||||
As [**explained in this page**, ](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/#listing-secrets)with these permissions you can **read** the **tokens** of all the **SAs of kubernetes**, so you can escalate to them.
|
||||
As [**explained in this page**, ](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#listing-secrets)with these permissions you can **read** the **tokens** of all the **SAs of kubernetes**, so you can escalate to them.
|
||||
|
||||
### `container.pods.exec`
|
||||
|
||||
@@ -86,7 +86,7 @@ Because of the **name** of the **permission**, it **looks like that it will allo
|
||||
### `container.mutatingWebhookConfigurations.create` | `container.mutatingWebhookConfigurations.update`
|
||||
|
||||
These permissions might allow you to escalate privileges in Kubernetes, but more probably, you could abuse them to **persist in the cluster**.\
|
||||
For more information [**follow this link**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/#malicious-admission-controller).
|
||||
For more information [**follow this link**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#malicious-admission-controller).
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
+5
-5
@@ -36,11 +36,11 @@ Most of the following proposed permissions are **given to the default Compute SA
|
||||
|
||||
Check the following permissions:
|
||||
|
||||
- [**compute.instances.osLogin**](gcp-compute-privesc/#compute.instances.oslogin)
|
||||
- [**compute.instances.osAdminLogin**](gcp-compute-privesc/#compute.instances.osadminlogin)
|
||||
- [**compute.projects.setCommonInstanceMetadata**](gcp-compute-privesc/#compute.projects.setcommoninstancemetadata)
|
||||
- [**compute.instances.setMetadata**](gcp-compute-privesc/#compute.instances.setmetadata)
|
||||
- [**compute.instances.setIamPolicy**](gcp-compute-privesc/#compute.instances.setiampolicy)
|
||||
- [**compute.instances.osLogin**](gcp-compute-privesc/index.html#compute.instances.oslogin)
|
||||
- [**compute.instances.osAdminLogin**](gcp-compute-privesc/index.html#compute.instances.osadminlogin)
|
||||
- [**compute.projects.setCommonInstanceMetadata**](gcp-compute-privesc/index.html#compute.projects.setcommoninstancemetadata)
|
||||
- [**compute.instances.setMetadata**](gcp-compute-privesc/index.html#compute.instances.setmetadata)
|
||||
- [**compute.instances.setIamPolicy**](gcp-compute-privesc/index.html#compute.instances.setiampolicy)
|
||||
|
||||
## Search for Keys in the filesystem
|
||||
|
||||
|
||||
@@ -70,7 +70,7 @@ Even with the admin service enable, it's possible that you get an error enumerat
|
||||
|
||||
## IAM
|
||||
|
||||
Check [**this for basic information about IAM**](../gcp-basic-information/#iam-roles).
|
||||
Check [**this for basic information about IAM**](../gcp-basic-information/index.html#iam-roles).
|
||||
|
||||
### Default Permissions
|
||||
|
||||
|
||||
+1
-1
@@ -11,7 +11,7 @@ Google Workspace's Domain-Wide delegation allows an identity object, either an *
|
||||
Google Workspace allows the creation of two main types of global delegated object identities:
|
||||
|
||||
- **GWS Applications:** Applications from the Workspace Marketplace can be set up as a delegated identity. Before being made available in the marketplace, each Workspace application undergoes a review by Google to minimize potential misuse. While this does not entirely eliminate the risk of abuse, it significantly increases the difficulty for such incidents to occur.
|
||||
- **GCP Service Account:** Learn more about [**GCP Service Accounts here**](../gcp-basic-information/#service-accounts).
|
||||
- **GCP Service Account:** Learn more about [**GCP Service Accounts here**](../gcp-basic-information/index.html#service-accounts).
|
||||
|
||||
### **Domain-Wide Delegation: Under the Hood**
|
||||
|
||||
|
||||
+3
-3
@@ -484,11 +484,11 @@ Principals that can **`update`** or **`patch`** **`pods/ephemeralcontainers`** c
|
||||
|
||||
Principals with any of the verbs `create`, `update` or `patch` over `validatingwebhookconfigurations` or `mutatingwebhookconfigurations` might be able to **create one of such webhookconfigurations** in order to be able to **escalate privileges**.
|
||||
|
||||
For a [`mutatingwebhookconfigurations` example check this section of this post](./#malicious-admission-controller).
|
||||
For a [`mutatingwebhookconfigurations` example check this section of this post](#malicious-admission-controller).
|
||||
|
||||
### Escalate
|
||||
|
||||
As you can read in the next section: [**Built-in Privileged Escalation Prevention**](./#built-in-privileged-escalation-prevention), a principal cannot update neither create roles or clusterroles without having himself those new permissions. Except if he has the **verb `escalate`** over **`roles`** or **`clusterroles`.**\
|
||||
As you can read in the next section: [**Built-in Privileged Escalation Prevention**](#built-in-privileged-escalation-prevention), a principal cannot update neither create roles or clusterroles without having himself those new permissions. Except if he has the **verb `escalate`** over **`roles`** or **`clusterroles`.**\
|
||||
Then he can update/create new roles, clusterroles with better permissions than the ones he has.
|
||||
|
||||
### Nodes proxy
|
||||
@@ -499,7 +499,7 @@ Principals with access to the **`nodes/proxy`** subresource can **execute code o
|
||||
../pentesting-kubernetes-services/kubelet-authentication-and-authorization.md
|
||||
{{#endref}}
|
||||
|
||||
You have an example of how to get [**RCE talking authorized to a Kubelet API here**](../pentesting-kubernetes-services/#kubelet-rce).
|
||||
You have an example of how to get [**RCE talking authorized to a Kubelet API here**](../pentesting-kubernetes-services/index.html#kubelet-rce).
|
||||
|
||||
### Delete pods + unschedulable nodes
|
||||
|
||||
|
||||
@@ -286,7 +286,7 @@ If you are inside the node host you can make it create a **static pod inside its
|
||||
|
||||
In order to create a static pod, the [**docs are a great help**](https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/). You basically need 2 things:
|
||||
|
||||
- Configure the param **`--pod-manifest-path=/etc/kubernetes/manifests`** in the **kubelet service**, or in the **kubelet config** ([**staticPodPath**](https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)) and restart the service
|
||||
- Configure the param **`--pod-manifest-path=/etc/kubernetes/manifests`** in the **kubelet service**, or in the **kubelet config** ([**staticPodPath**](https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/index.html#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)) and restart the service
|
||||
- Create the definition on the **pod definition** in **`/etc/kubernetes/manifests`**
|
||||
|
||||
**Another more stealth way would be to:**
|
||||
@@ -324,7 +324,7 @@ spec:
|
||||
### Delete pods + unschedulable nodes
|
||||
|
||||
If an attacker has **compromised a node** and he can **delete pods** from other nodes and **make other nodes not able to execute pods**, the pods will be rerun in the compromised node and he will be able to **steal the tokens** run in them.\
|
||||
For [**more info follow this links**](abusing-roles-clusterroles-in-kubernetes/#delete-pods-+-unschedulable-nodes).
|
||||
For [**more info follow this links**](abusing-roles-clusterroles-in-kubernetes/index.html#delete-pods-+-unschedulable-nodes).
|
||||
|
||||
## Automatic Tools
|
||||
|
||||
|
||||
+1
-1
@@ -36,7 +36,7 @@ In the template of a **Role** or a **ClusterRole** you will need to indicate the
|
||||
|
||||
### Rules Verbs
|
||||
|
||||
(_This info was taken from_ [_**the docs**_](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb))
|
||||
(_This info was taken from_ [_**the docs**_](https://kubernetes.io/docs/reference/access-authn-authz/authorization/index.html#determine-the-request-verb))
|
||||
|
||||
| HTTP verb | request verb |
|
||||
| --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
|
||||
@@ -6,7 +6,7 @@ This page gives some pointers onto how you can attack a Jenkins instance running
|
||||
|
||||
## Disclaimer
|
||||
|
||||
A Jenkins instance can be deployed in both Openshift or Kubernetes cluster. Depending in your context, you may need to adapt any shown payload, yaml or technique. For more information about attacking Jenkins you can have a look at [this page](../../../pentesting-ci-cd/jenkins-security/)
|
||||
A Jenkins instance can be deployed in both Openshift or Kubernetes cluster. Depending in your context, you may need to adapt any shown payload, yaml or technique. For more information about attacking Jenkins you can have a look at [this page](../../../pentesting-ci-cd/jenkins-security/index.html)
|
||||
|
||||
## Prerequisites
|
||||
|
||||
|
||||
Reference in New Issue
Block a user