mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-31 23:15:48 -08:00
Translated ['.github/pull_request_template.md', 'src/README.md', 'src/pe
This commit is contained in:
Translator
@@ -6,7 +6,7 @@
|
||||
openshift-basic-information.md
|
||||
{{#endref}}
|
||||
|
||||
## Vincoli del Contesto di Sicurezza
|
||||
## Vincoli di Contesto di Sicurezza
|
||||
|
||||
{{#ref}}
|
||||
openshift-scc.md
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# OpenShift - Informazioni di base
|
||||
|
||||
## Kubernetes conoscenze b**asiche** <a href="#a94e" id="a94e"></a>
|
||||
## Conoscenze di base su Kubernetes <a href="#a94e" id="a94e"></a>
|
||||
|
||||
Prima di lavorare con OpenShift, assicurati di essere a tuo agio con l'ambiente Kubernetes. L'intero capitolo su OpenShift presuppone che tu abbia conoscenze pregresse di Kubernetes.
|
||||
Prima di lavorare con OpenShift, assicurati di avere familiarità con l'ambiente Kubernetes. L'intero capitolo su OpenShift presuppone che tu abbia conoscenze pregresse di Kubernetes.
|
||||
|
||||
## OpenShift - Informazioni di base
|
||||
|
||||
@@ -25,9 +25,9 @@ oc login -s=<server> --token=<bearer token>
|
||||
```
|
||||
### **OpenShift - Security Context Constraints** <a href="#a94e" id="a94e"></a>
|
||||
|
||||
In aggiunta alle [risorse RBAC](https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#architecture-additional-concepts-authorization) che controllano cosa può fare un utente, OpenShift Container Platform fornisce _security context constraints_ (SCC) che controllano le azioni che un pod può eseguire e a cosa ha la possibilità di accedere.
|
||||
Oltre alle [risorse RBAC](https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#architecture-additional-concepts-authorization) che controllano cosa può fare un utente, OpenShift Container Platform fornisce _security context constraints_ (SCC) che controllano le azioni che un pod può eseguire e a cosa ha la possibilità di accedere.
|
||||
|
||||
SCC è un oggetto di policy che ha regole speciali che corrispondono all'infrastruttura stessa, a differenza di RBAC che ha regole che corrispondono alla Piattaforma. Aiuta a definire quali funzionalità di controllo accessi Linux il container dovrebbe essere in grado di richiedere/eseguire. Esempio: Linux Capabilities, profili SECCOMP, Montare directory localhost, ecc.
|
||||
SCC è un oggetto di policy che ha regole speciali che corrispondono all'infrastruttura stessa, a differenza di RBAC che ha regole che corrispondono alla piattaforma. Aiuta a definire quali funzionalità di controllo accessi Linux il container dovrebbe essere in grado di richiedere/eseguire. Esempio: Linux Capabilities, profili SECCOMP, Montare directory localhost, ecc.
|
||||
|
||||
{{#ref}}
|
||||
openshift-scc.md
|
||||
|
||||
@@ -2,37 +2,37 @@
|
||||
|
||||
**L'autore originale di questa pagina è** [**Fares**](https://www.linkedin.com/in/fares-siala/)
|
||||
|
||||
Questa pagina fornisce alcuni suggerimenti su come puoi attaccare un'istanza di Jenkins in esecuzione in un cluster Openshift (o Kubernetes)
|
||||
Questa pagina fornisce alcuni suggerimenti su come attaccare un'istanza di Jenkins in esecuzione in un cluster Openshift (o Kubernetes)
|
||||
|
||||
## Disclaimer
|
||||
|
||||
Un'istanza di Jenkins può essere distribuita sia in un cluster Openshift che in un cluster Kubernetes. A seconda del tuo contesto, potresti dover adattare qualsiasi payload, yaml o tecnica mostrata. Per ulteriori informazioni su come attaccare Jenkins, puoi dare un'occhiata a [questa pagina](../../../pentesting-ci-cd/jenkins-security/)
|
||||
|
||||
## Prerequisites
|
||||
## Prerequisiti
|
||||
|
||||
1a. Accesso utente in un'istanza di Jenkins OPPURE 1b. Accesso utente con permesso di scrittura a un repository SCM dove viene attivata una build automatizzata dopo un push/merge
|
||||
|
||||
## How it works
|
||||
## Come funziona
|
||||
|
||||
Fondamentalmente, quasi tutto ciò che avviene dietro le quinte funziona allo stesso modo di un'istanza di Jenkins regolare in esecuzione in una VM. La principale differenza è l'architettura complessiva e come le build vengono gestite all'interno di un cluster openshift (o kubernetes).
|
||||
|
||||
### Builds
|
||||
### Build
|
||||
|
||||
Quando viene attivata una build, viene prima gestita/orchestrata dal nodo master di Jenkins e poi delegata a un agente/schiavo/lavoratore. In questo contesto, il nodo master è solo un normale pod in esecuzione in uno spazio dei nomi (che potrebbe essere diverso da quello in cui vengono eseguiti i lavoratori). Lo stesso vale per i lavoratori/schiavi, tuttavia vengono distrutti una volta che la build è terminata, mentre il master rimane sempre attivo. La tua build viene solitamente eseguita all'interno di un pod, utilizzando un modello di pod predefinito definito dagli amministratori di Jenkins.
|
||||
Quando viene attivata una build, viene prima gestita/orchestrata dal nodo master di Jenkins e poi delegata a un agente/schiavo/lavoratore. In questo contesto, il nodo master è semplicemente un pod regolare in esecuzione in uno spazio dei nomi (che potrebbe essere diverso da quello in cui vengono eseguiti i lavoratori). Lo stesso vale per i lavoratori/schiavi, tuttavia vengono distrutti una volta che la build è terminata, mentre il master rimane sempre attivo. La tua build viene solitamente eseguita all'interno di un pod, utilizzando un modello di pod predefinito definito dagli amministratori di Jenkins.
|
||||
|
||||
### Triggering a build
|
||||
### Attivazione di una build
|
||||
|
||||
Hai diversi modi principali per attivare una build, come:
|
||||
Hai diversi modi principali per attivare una build, come ad esempio:
|
||||
|
||||
1. Hai accesso UI a Jenkins
|
||||
1. Hai accesso all'interfaccia utente di Jenkins
|
||||
|
||||
Un modo molto semplice e conveniente è utilizzare la funzionalità Replay di una build esistente. Ti consente di ripetere una build precedentemente eseguita mentre ti consente di aggiornare lo script groovy. Questo richiede privilegi su una cartella di Jenkins e una pipeline predefinita. Se hai bisogno di essere furtivo, puoi eliminare le tue build attivate se hai abbastanza permessi.
|
||||
Un modo molto semplice e conveniente è utilizzare la funzionalità Replay di una build esistente. Ti consente di ripetere una build precedentemente eseguita mentre ti permette di aggiornare lo script groovy. Questo richiede privilegi su una cartella di Jenkins e una pipeline predefinita. Se hai bisogno di essere furtivo, puoi eliminare le tue build attivate se hai abbastanza permessi.
|
||||
|
||||
2. Hai accesso in scrittura allo SCM e le build automatizzate sono configurate tramite webhook
|
||||
|
||||
Puoi semplicemente modificare uno script di build (come Jenkinsfile), fare commit e push (eventualmente creare una PR se le build vengono attivate solo sui merge delle PR). Tieni presente che questo percorso è molto rumoroso e richiede privilegi elevati per pulire le tue tracce.
|
||||
|
||||
## Jenkins Build Pod YAML override
|
||||
## Override YAML del Pod di Build di Jenkins
|
||||
|
||||
{{#ref}}
|
||||
openshift-jenkins-build-overrides.md
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Jenkins in Openshift - build pod overrides
|
||||
# Jenkins in Openshift - sovrascritture del pod di build
|
||||
|
||||
**L'autore originale di questa pagina è** [**Fares**](https://www.linkedin.com/in/fares-siala/)
|
||||
|
||||
@@ -34,7 +34,7 @@ sh 'mvn -B -ntp clean install'
|
||||
}
|
||||
}
|
||||
```
|
||||
## Alcuni abusi che sfruttano l'override yaml del pod
|
||||
## Alcuni abusi che sfruttano l'override del yaml del pod
|
||||
|
||||
Tuttavia, può essere abusato per utilizzare qualsiasi immagine accessibile come Kali Linux ed eseguire comandi arbitrari utilizzando strumenti preinstallati da quell'immagine.
|
||||
Nell'esempio seguente possiamo esfiltrare il token del serviceaccount del pod in esecuzione.
|
||||
@@ -94,7 +94,7 @@ sh 'env'
|
||||
}
|
||||
}
|
||||
```
|
||||
Esempio per sovrascrivere lo spazio dei nomi del pod
|
||||
Esempio per sovrascrivere il namespace del pod
|
||||
```groovy
|
||||
pipeline {
|
||||
stages {
|
||||
@@ -128,7 +128,7 @@ sh 'env'
|
||||
}
|
||||
}
|
||||
```
|
||||
Un altro esempio che tenta di montare un serviceaccount (che potrebbe avere più permessi rispetto a quello predefinito, che esegue la tua build) in base al suo nome. Potresti dover indovinare o enumerare prima i serviceaccount esistenti.
|
||||
Un altro esempio che tenta di montare un serviceaccount (che potrebbe avere più permessi rispetto a quello predefinito, eseguendo la tua build) in base al suo nome. Potresti dover indovinare o enumerare prima i serviceaccount esistenti.
|
||||
```groovy
|
||||
pipeline {
|
||||
stages {
|
||||
@@ -180,7 +180,7 @@ Puoi scoprire quali comandi oc/kubectl emettere [qui](../openshift-basic-informa
|
||||
|
||||
### Possibili scenari di privesc/pivoting
|
||||
|
||||
Supponiamo che durante la tua valutazione tu abbia scoperto che tutte le build di jenkins vengono eseguite all'interno di uno spazio dei nomi chiamato _worker-ns_. Hai scoperto che un account di servizio predefinito chiamato _default-sa_ è montato sui pod di build, tuttavia non ha molti permessi tranne l'accesso in lettura su alcune risorse, ma sei riuscito a identificare un account di servizio esistente chiamato _master-sa_.
|
||||
Supponiamo che durante la tua valutazione tu abbia scoperto che tutte le build di jenkins vengono eseguite all'interno di uno spazio dei nomi chiamato _worker-ns_. Hai scoperto che un account di servizio predefinito chiamato _default-sa_ è montato sui pod di build, tuttavia non ha molti permessi tranne l'accesso in lettura su alcune risorse, ma sei stato in grado di identificare un account di servizio esistente chiamato _master-sa_.
|
||||
Supponiamo anche che tu abbia il comando oc installato all'interno del container di build in esecuzione.
|
||||
|
||||
Con il seguente script di build puoi prendere il controllo dell'account di servizio _master-sa_ e enumerare ulteriormente.
|
||||
@@ -216,7 +216,7 @@ sh 'oc --token=$token whoami'
|
||||
}
|
||||
}
|
||||
```
|
||||
A seconda del tuo accesso, o devi continuare il tuo attacco dallo script di build o puoi accedere direttamente come questo sa sul cluster in esecuzione:
|
||||
A seconda del tuo accesso, o devi continuare il tuo attacco dallo script di build oppure puoi accedere direttamente come questo sa nel cluster in esecuzione:
|
||||
```bash
|
||||
oc login --token=$token --server=https://apiserver.com:port
|
||||
```
|
||||
@@ -224,7 +224,7 @@ Se questo sa ha abbastanza permessi (come pod/exec), puoi anche prendere il cont
|
||||
```bash
|
||||
oc rsh pod_name -c container_name
|
||||
```
|
||||
In caso il pod del nodo master non sia in esecuzione all'interno dello stesso namespace dei worker, puoi provare attacchi simili mirati al namespace master. Supponiamo che si chiami _jenkins-master_. Tieni presente che il serviceAccount master-sa deve esistere nel namespace _jenkins-master_ (e potrebbe non esistere nel namespace _worker-ns_).
|
||||
Nel caso in cui il pod del nodo master non sia in esecuzione all'interno dello stesso namespace dei worker, puoi provare attacchi simili mirati al namespace master. Supponiamo che si chiami _jenkins-master_. Tieni presente che il serviceAccount master-sa deve esistere nel namespace _jenkins-master_ (e potrebbe non esistere nel namespace _worker-ns_).
|
||||
```groovy
|
||||
pipeline {
|
||||
stages {
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# OpenShift - Privilege Escalation
|
||||
# OpenShift - Escalation dei privilegi
|
||||
|
||||
## Servizio Account Mancante
|
||||
## Account di servizio mancante
|
||||
|
||||
{{#ref}}
|
||||
openshift-missing-service-account.md
|
||||
|
||||
@@ -6,11 +6,11 @@ Capita che il cluster venga distribuito con un modello preconfigurato che impost
|
||||
|
||||
<figure><img src="../../../images/openshift-missing-service-account-image1.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Nel grafico precedente abbiamo ottenuto più AbsentProject, il che significa più progetti che appaiono nei Role Bindings o SCC ma non sono ancora stati creati nel cluster. Nella stessa vena abbiamo anche un AbsentServiceAccount.
|
||||
Nel grafico precedente abbiamo più AbsentProject che significano più progetti che appaiono nei Ruoli Bindings o SCC ma non sono ancora stati creati nel cluster. Nella stessa vena abbiamo anche un AbsentServiceAccount.
|
||||
|
||||
Se possiamo creare un progetto e il SA mancante al suo interno, il SA erediterà il Ruolo o lo SCC che miravano all'AbsentServiceAccount. Questo può portare a un'escursione di privilegi.
|
||||
Se possiamo creare un progetto e il SA mancante al suo interno, il SA erediterà dal Ruolo o dallo SCC che miravano all'AbsentServiceAccount. Questo può portare a un'escursione di privilegi.
|
||||
|
||||
Il seguente esempio mostra un SA mancante a cui è stato concesso il SCC node-exporter:
|
||||
Il seguente esempio mostra un SA mancante a cui è concesso il SCC node-exporter:
|
||||
|
||||
<figure><img src="../../../images/openshift-missing-service-account-image2.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
**L'autore originale di questa pagina è** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
|
||||
|
||||
## Namespace privilegiati
|
||||
## Namespaces Privilegiati
|
||||
|
||||
Per impostazione predefinita, SCC non si applica ai seguenti progetti:
|
||||
|
||||
@@ -13,7 +13,7 @@ Per impostazione predefinita, SCC non si applica ai seguenti progetti:
|
||||
- **openshift-infra**
|
||||
- **openshift**
|
||||
|
||||
Se distribuisci pod all'interno di uno di questi namespace, non verrà applicato alcun SCC, consentendo la distribuzione di pod privilegiati o il montaggio del file system host.
|
||||
Se distribuisci pod all'interno di uno di questi namespaces, non verrà applicato alcun SCC, consentendo la distribuzione di pod privilegiati o il montaggio del file system host.
|
||||
|
||||
## Etichetta del Namespace
|
||||
|
||||
@@ -28,7 +28,7 @@ yes
|
||||
$ oc auth can-i patch namespaces
|
||||
yes
|
||||
```
|
||||
L'etichetta specifica `openshift.io/run-level` consente agli utenti di eludere le SCC per le applicazioni. Secondo la documentazione di RedHat, quando questa etichetta è utilizzata, nessuna SCC è applicata a tutti i pod all'interno di quel namespace, rimuovendo di fatto qualsiasi restrizione.
|
||||
L'etichetta specifica `openshift.io/run-level` consente agli utenti di eludere le SCC per le applicazioni. Secondo la documentazione di RedHat, quando questa etichetta è utilizzata, nessuna SCC è applicata a tutti i pod all'interno di quel namespace, rimuovendo effettivamente qualsiasi restrizione.
|
||||
|
||||
<figure><img src="../../../images/Openshift-RunLevel4.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -86,7 +86,7 @@ volumes:
|
||||
hostPath:
|
||||
path:
|
||||
```
|
||||
Ora è diventato più facile elevare i privilegi per accedere al sistema host e successivamente prendere il controllo dell'intero cluster, guadagnando privilegi 'cluster-admin'. Cerca la parte **Node-Post Exploitation** nella seguente pagina:
|
||||
Ora è diventato più facile elevare i privilegi per accedere al sistema host e successivamente prendere il controllo dell'intero cluster, ottenendo privilegi 'cluster-admin'. Cerca la parte **Node-Post Exploitation** nella seguente pagina:
|
||||
|
||||
{{#ref}}
|
||||
../../kubernetes-security/attacking-kubernetes-from-inside-a-pod.md
|
||||
@@ -96,7 +96,7 @@ Ora è diventato più facile elevare i privilegi per accedere al sistema host e
|
||||
|
||||
Inoltre, in base alla configurazione target, alcune etichette / annotazioni personalizzate possono essere utilizzate nello stesso modo dello scenario di attacco precedente. Anche se non è stato creato per, le etichette potrebbero essere utilizzate per concedere permessi, limitare o meno una risorsa specifica.
|
||||
|
||||
Cerca etichette personalizzate se puoi leggere alcune risorse. Ecco un elenco di risorse interessanti:
|
||||
Cerca di individuare etichette personalizzate se puoi leggere alcune risorse. Ecco un elenco di risorse interessanti:
|
||||
|
||||
- Pod
|
||||
- Deployment
|
||||
@@ -117,7 +117,7 @@ In OpenShift, come dimostrato in precedenza, avere il permesso di distribuire un
|
||||
|
||||
Tuttavia, misure di mitigazione come **Open Policy Agent GateKeeper** possono impedire agli utenti di impostare questa etichetta.
|
||||
|
||||
Per bypassare le regole di GateKeeper e impostare questa etichetta per eseguire un takeover del cluster, **gli attaccanti avrebbero bisogno di identificare metodi alternativi.**
|
||||
Per bypassare le regole di GateKeeper e impostare questa etichetta per eseguire un takeover del cluster, **gli attaccanti dovrebbero identificare metodi alternativi.**
|
||||
|
||||
## Riferimenti
|
||||
|
||||
|
||||
@@ -4,9 +4,9 @@
|
||||
|
||||
### Cos'è tekton
|
||||
|
||||
Secondo la documentazione: _Tekton è un potente e flessibile framework open-source per creare sistemi CI/CD, che consente agli sviluppatori di costruire, testare e distribuire su fornitori di cloud e sistemi on-premise._ Sia Jenkins che Tekton possono essere utilizzati per testare, costruire e distribuire applicazioni, tuttavia Tekton è Cloud Native. 
|
||||
Secondo la documentazione: _Tekton è un potente e flessibile framework open-source per la creazione di sistemi CI/CD, che consente agli sviluppatori di costruire, testare e distribuire su fornitori di cloud e sistemi on-premise._ Sia Jenkins che Tekton possono essere utilizzati per testare, costruire e distribuire applicazioni, tuttavia Tekton è Cloud Native. 
|
||||
|
||||
Con Tekton tutto è rappresentato da file YAML. Gli sviluppatori possono creare Risorse Personalizzate (CR) di tipo `Pipelines` e specificare più `Tasks` in esse che desiderano eseguire. Per eseguire una Pipeline, devono essere create risorse di tipo `PipelineRun`.
|
||||
Con Tekton tutto è rappresentato da file YAML. Gli sviluppatori possono creare Risorse Personalizzate (CR) di tipo `Pipelines` e specificare più `Tasks` in esse che desiderano eseguire. Per eseguire una Pipeline devono essere create risorse di tipo `PipelineRun`.
|
||||
|
||||
Quando tekton è installato, viene creata un'account di servizio (sa) chiamata pipeline in ogni namespace. Quando una Pipeline viene eseguita, verrà generato un pod utilizzando questo sa chiamato `pipeline` per eseguire i task definiti nel file YAML.
|
||||
|
||||
|
||||
@@ -9,8 +9,8 @@ Nel contesto di OpenShift, SCC sta per **Security Context Constraints**. Le Secu
|
||||
Le SCC aiutano gli amministratori a far rispettare le politiche di sicurezza in tutto il cluster, garantendo che i pod funzionino con permessi appropriati e rispettino gli standard di sicurezza organizzativi. Queste restrizioni possono specificare vari aspetti della sicurezza del pod, come:
|
||||
|
||||
1. Capacità Linux: Limitare le capacità disponibili per i container, come la possibilità di eseguire azioni privilegiate.
|
||||
2. Contesto SELinux: Far rispettare i contesti SELinux per i container, che definiscono come i processi interagiscono con le risorse nel sistema.
|
||||
3. File system root di sola lettura: Impedire ai container di modificare file in determinate directory.
|
||||
2. Contesto SELinux: Far rispettare i contesti SELinux per i container, che definiscono come i processi interagiscono con le risorse sul sistema.
|
||||
3. File system root di sola lettura: Prevenire che i container modifichino file in determinate directory.
|
||||
4. Directory e volumi host consentiti: Specificare quali directory e volumi host un pod può montare.
|
||||
5. Esegui come UID/GID: Specificare gli ID utente e gruppo sotto i quali il processo del container viene eseguito.
|
||||
6. Politiche di rete: Controllare l'accesso di rete per i pod, come limitare il traffico in uscita.
|
||||
@@ -21,7 +21,7 @@ Fondamentalmente, ogni volta che viene richiesta una distribuzione di pod, viene
|
||||
|
||||
<figure><img src="../../images/Managing SCCs in OpenShift-1.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Questo ulteriore strato di sicurezza per impostazione predefinita vieta la creazione di pod privilegiati, il montaggio del file system host o l'impostazione di qualsiasi attributo che potrebbe portare a un'escalation di privilegi.
|
||||
Questo ulteriore strato di sicurezza per impostazione predefinita vieta la creazione di pod privilegiati, il montaggio del file system host o l'impostazione di attributi che potrebbero portare a un'escalation di privilegi.
|
||||
|
||||
{{#ref}}
|
||||
../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/pod-escape-privileges.md
|
||||
|
||||
Reference in New Issue
Block a user