mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-30 22:50:43 -08:00
Translated ['src/pentesting-cloud/azure-security/az-services/az-cosmosDB
This commit is contained in:
Translator
@@ -17,7 +17,7 @@ Learn & practice GCP Hacking: <img src="../../../.gitbook/assets/image (2) (1).p
|
||||
|
||||
## Azure CosmosDB
|
||||
|
||||
**Azure Cosmos DB** è un **database NoSQL, relazionale e vettoriale completamente gestito** che offre tempi di risposta nell'ordine di un millisecondo, scalabilità automatica e disponibilità supportata da SLA con sicurezza di livello enterprise. Consente uno sviluppo più rapido delle app attraverso la distribuzione dei dati multi-regione "chiavi in mano", API open-source, SDK per linguaggi popolari e funzionalità di database AI come il supporto vettoriale integrato e l'integrazione senza soluzione di continuità con Azure AI.
|
||||
**Azure Cosmos DB** è un **database NoSQL, relazionale e vettoriale completamente gestito** che offre tempi di risposta nell'ordine di un millisecondo, scalabilità automatica e disponibilità supportata da SLA con sicurezza di livello enterprise. Consente uno sviluppo più rapido delle app attraverso la distribuzione dei dati multi-regione "turnkey", API open-source, SDK per linguaggi popolari e funzionalità di database AI come il supporto vettoriale integrato e l'integrazione senza soluzione di continuità con Azure AI.
|
||||
|
||||
Azure Cosmos DB fornisce più API di database per modellare i dati del mondo reale utilizzando modelli di dati documentali, relazionali, chiave-valore, grafico e a colonne, essendo queste API NoSQL, MongoDB, PostgreSQL, Cassandra, Gremlin e Table.
|
||||
|
||||
@@ -33,7 +33,7 @@ https://<Account-Name>.documents.azure.com:443/
|
||||
{% endcode %}
|
||||
|
||||
#### Database
|
||||
All'interno di un account, puoi creare uno o più database, che fungono da raggruppamenti logici di contenitori. Un database agisce come un confine per la gestione delle risorse e i permessi degli utenti. I database possono condividere la capacità di throughput provisionata tra i loro contenitori o allocare throughput dedicato a contenitori individuali.
|
||||
All'interno di un account, puoi creare uno o più database, che fungono da raggruppamenti logici di contenitori. Un database agisce come un confine per la gestione delle risorse e dei permessi degli utenti. I database possono condividere la capacità di throughput provisionato tra i loro contenitori o allocare throughput dedicato a contenitori individuali.
|
||||
|
||||
#### Contenitori
|
||||
L'unità fondamentale di archiviazione dei dati è il contenitore, che contiene documenti JSON ed è automaticamente indicizzato per query efficienti. I contenitori sono elastici e scalabili e distribuiti su partizioni, che sono determinate da una chiave di partizione definita dall'utente. La chiave di partizione è fondamentale per garantire prestazioni ottimali e una distribuzione uniforme dei dati. Ad esempio, un contenitore potrebbe memorizzare dati dei clienti, con "customerId" come chiave di partizione.
|
||||
@@ -173,7 +173,7 @@ print(item)
|
||||
```
|
||||
{% endcode %}
|
||||
|
||||
Un altro modo per stabilire una connessione è utilizzare il **DefaultAzureCredential()**. È sufficiente effettuare il login (az login) con l'account che ha i permessi e eseguirlo. In questo caso deve essere effettuata un'assegnazione di ruolo, dando i permessi necessari (vedi per mor)
|
||||
Un altro modo per stabilire una connessione è utilizzare il **DefaultAzureCredential()**. È sufficiente effettuare il login (az login) con l'account che ha i permessi ed eseguirlo. In questo caso deve essere effettuata un'assegnazione di ruolo, dando i permessi necessari (vedi per mor)
|
||||
|
||||
{% code overflow="wrap" %}
|
||||
```python
|
||||
@@ -364,7 +364,7 @@ Impara e pratica il hacking GCP: <img src="../../../.gitbook/assets/image (2) (1
|
||||
|
||||
* Controlla i [**piani di abbonamento**](https://github.com/sponsors/carlospolop)!
|
||||
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Condividi trucchi di hacking inviando PR ai** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos su github.
|
||||
* **Condividi trucchi di hacking inviando PR ai** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos di github.
|
||||
|
||||
</details>
|
||||
{% endhint %}
|
||||
|
||||
@@ -1,37 +0,0 @@
|
||||
# Az - VMs Unath
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Macchine Virtuali
|
||||
|
||||
Per ulteriori informazioni sulle Macchine Virtuali di Azure, controlla:
|
||||
|
||||
{{#ref}}
|
||||
../az-services/vms/
|
||||
{{#endref}}
|
||||
|
||||
### Servizio vulnerabile esposto
|
||||
|
||||
Un servizio di rete che è vulnerabile a qualche RCE.
|
||||
|
||||
### Immagini della Galleria Pubblica
|
||||
|
||||
Un'immagine pubblica potrebbe contenere segreti al suo interno:
|
||||
```bash
|
||||
# List all community galleries
|
||||
az sig list-community --output table
|
||||
|
||||
# Search by publisherUri
|
||||
az sig list-community --output json --query "[?communityMetadata.publisherUri=='https://3nets.io']"
|
||||
```
|
||||
### Estensioni Pubbliche
|
||||
|
||||
Questo sarebbe più strano ma non impossibile. Una grande azienda potrebbe inserire un'estensione con dati sensibili al suo interno:
|
||||
```bash
|
||||
# It takes some mins to run
|
||||
az vm extension image list --output table
|
||||
|
||||
# Get extensions by publisher
|
||||
az vm extension image list --publisher "Site24x7" --output table
|
||||
```
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
@@ -7,7 +7,7 @@ Ricorda che puoi ottenere tutte le risorse supportate con `kubectl api-resources
|
||||
|
||||
## **Privilege Escalation**
|
||||
|
||||
Si riferisce all'arte di ottenere **accesso a un diverso principale** all'interno del cluster **con privilegi diversi** (all'interno del cluster kubernetes o a cloud esterni) rispetto a quelli che già possiedi. In Kubernetes ci sono fondamentalmente **4 tecniche principali per escalare i privilegi**:
|
||||
Si riferisce all'arte di ottenere **accesso a un diverso principale** all'interno del cluster **con privilegi diversi** (all'interno del cluster kubernetes o a cloud esterni) rispetto a quelli che già possiedi; in Kubernetes ci sono fondamentalmente **4 tecniche principali per escalare i privilegi**:
|
||||
|
||||
- Essere in grado di **impersonare** altri utenti/gruppi/SAs con privilegi migliori all'interno del cluster kubernetes o a cloud esterni
|
||||
- Essere in grado di **creare/patchare/eseguire pod** dove puoi **trovare o allegare SAs** con privilegi migliori all'interno del cluster kubernetes o a cloud esterni
|
||||
@@ -17,7 +17,7 @@ Si riferisce all'arte di ottenere **accesso a un diverso principale** all'intern
|
||||
|
||||
### Access Any Resource or Verb (Wildcard)
|
||||
|
||||
Il **wildcard (\*) concede permessi su qualsiasi risorsa con qualsiasi verbo**. È usato dagli amministratori. All'interno di un ClusterRole questo significa che un attaccante potrebbe abusare di anynamespace nel cluster
|
||||
Il **wildcard (\*) concede permesso su qualsiasi risorsa con qualsiasi verbo**. È usato dagli amministratori. All'interno di un ClusterRole questo significa che un attaccante potrebbe abusare di anynamespace nel cluster
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
@@ -33,9 +33,9 @@ verbs: ["*"]
|
||||
|
||||
In RBAC, alcune autorizzazioni comportano rischi significativi:
|
||||
|
||||
1. **`create`:** Concede la possibilità di creare qualsiasi risorsa del cluster, rischiando un'escalation di privilegi.
|
||||
2. **`list`:** Consente di elencare tutte le risorse, potenzialmente causando la fuga di dati sensibili.
|
||||
3. **`get`:** Permette di accedere ai segreti degli account di servizio, rappresentando una minaccia per la sicurezza.
|
||||
1. **`create`:** Concede la possibilità di creare qualsiasi risorsa del cluster, rischiando un'escalation dei privilegi.
|
||||
2. **`list`:** Consente di elencare tutte le risorse, potenzialmente rivelando dati sensibili.
|
||||
3. **`get`:** Permette di accedere ai segreti degli account di servizio, costituendo una minaccia per la sicurezza.
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
@@ -49,7 +49,7 @@ verbs: ["create", "list", "get"]
|
||||
```
|
||||
### Pod Create - Steal Token
|
||||
|
||||
Un attaccante con i permessi per creare un pod potrebbe allegare un Service Account privilegiato nel pod e rubare il token per impersonare il Service Account. In effetti, aumentando i privilegi.
|
||||
Un attaccante con i permessi per creare un pod potrebbe allegare un Service Account privilegiato nel pod e rubare il token per impersonare il Service Account. Efficacemente elevando i privilegi.
|
||||
|
||||
Esempio di un pod che ruberà il token del Service Account `bootstrap-signer` e lo invierà all'attaccante:
|
||||
```yaml
|
||||
@@ -136,7 +136,7 @@ Probabilmente vuoi essere **più furtivo**, nelle pagine seguenti puoi vedere a
|
||||
- **hostNetwork**
|
||||
- **hostIPC**
|
||||
|
||||
_Puoi trovare esempi di come creare/abuse le configurazioni dei pod privilegiati precedenti in_ [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods)
|
||||
_Puoi trovare esempi di come creare/abuse le configurazioni di pod privilegiati precedenti in_ [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods)
|
||||
|
||||
### Pod Create - Move to cloud
|
||||
|
||||
@@ -295,9 +295,9 @@ name: task-pv-storage-vol
|
||||
```
|
||||
### **Impersonare account privilegiati**
|
||||
|
||||
Con un privilegio di [**impersonificazione dell'utente**](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation), un attaccante potrebbe impersonare un account privilegiato.
|
||||
Con un privilegio di [**impersonificazione utente**](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation), un attaccante potrebbe impersonare un account privilegiato.
|
||||
|
||||
Basta utilizzare il parametro `--as=<username>` nel comando `kubectl` per impersonare un utente, o `--as-group=<group>` per impersonare un gruppo:
|
||||
Basta usare il parametro `--as=<username>` nel comando `kubectl` per impersonare un utente, o `--as-group=<group>` per impersonare un gruppo:
|
||||
```bash
|
||||
kubectl get pods --as=system:serviceaccount:kube-system:default
|
||||
kubectl get secrets --as=null --as-group=system:masters
|
||||
@@ -383,7 +383,7 @@ Nota che se ti è permesso creare e leggere segreti in un certo namespace, il se
|
||||
|
||||
Mentre un attaccante in possesso di un token con permessi di lettura richiede il nome esatto del segreto per utilizzarlo, a differenza del privilegio più ampio di _**elencare i segreti**_, ci sono ancora vulnerabilità. Gli account di servizio predefiniti nel sistema possono essere enumerati, ciascuno associato a un segreto. Questi segreti hanno una struttura di nome: un prefisso statico seguito da un token alfanumerico casuale di cinque caratteri (escludendo alcuni caratteri) secondo il [codice sorgente](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83).
|
||||
|
||||
Il token è generato da un set limitato di 27 caratteri (`bcdfghjklmnpqrstvwxz2456789`), piuttosto che dall'intero intervallo alfanumerico. Questa limitazione riduce il numero totale di combinazioni possibili a 14.348.907 (27^5). Di conseguenza, un attaccante potrebbe eseguire un attacco di forza bruta per dedurre il token in poche ore, portando potenzialmente a un'escalation dei privilegi accedendo a account di servizio sensibili.
|
||||
Il token è generato da un set limitato di 27 caratteri (`bcdfghjklmnpqrstvwxz2456789`), piuttosto che dall'intero intervallo alfanumerico. Questa limitazione riduce il numero totale di combinazioni possibili a 14.348.907 (27^5). Di conseguenza, un attaccante potrebbe ragionevolmente eseguire un attacco di forza bruta per dedurre il token in poche ore, potenzialmente portando a un'escalation dei privilegi accedendo a account di servizio sensibili.
|
||||
|
||||
### Richieste di Firma del Certificato
|
||||
|
||||
@@ -433,7 +433,7 @@ Il modo per bypassare questo è semplicemente **creare una credenziale del nodo
|
||||
```
|
||||
### AWS EKS aws-auth configmaps
|
||||
|
||||
I principi che possono modificare **`configmaps`** nello spazio dei nomi kube-system sui cluster EKS (devono essere in AWS) possono ottenere privilegi di amministratore del cluster sovrascrivendo il **configmap** **aws-auth**.\
|
||||
I principi che possono modificare **`configmaps`** nello spazio dei nomi kube-system su cluster EKS (devono essere in AWS) possono ottenere privilegi di amministratore del cluster sovrascrivendo il **configmap** **aws-auth**.\
|
||||
I verbi necessari sono **`update`** e **`patch`**, o **`create`** se il configmap non è stato creato:
|
||||
```bash
|
||||
# Check if config map exists
|
||||
@@ -485,7 +485,7 @@ Ci sono **2 modi per assegnare permessi K8s ai principi GCP**. In ogni caso, il
|
||||
|
||||
> [!WARNING]
|
||||
> Quando si parla con l'endpoint API K8s, il **token di autenticazione GCP verrà inviato**. Poi, GCP, attraverso l'endpoint API K8s, controllerà prima **se il principio** (per email) **ha accesso all'interno del cluster**, poi controllerà se ha **accesso tramite GCP IAM**.\
|
||||
> Se **qualcuno** di questi è **vero**, riceverà una **risposta**. Se **no**, verrà fornito un **errore** che suggerisce di dare **permessi tramite GCP IAM**.
|
||||
> Se **qualcuna** di queste è **vera**, riceverà una **risposta**. Se **no**, verrà fornito un **errore** che suggerisce di dare **permessi tramite GCP IAM**.
|
||||
|
||||
Quindi, il primo metodo è utilizzare **GCP IAM**, i permessi K8s hanno i loro **permessi equivalenti GCP IAM**, e se il principio li ha, potrà usarli.
|
||||
|
||||
@@ -497,7 +497,7 @@ Il secondo metodo è **assegnare permessi K8s all'interno del cluster** identifi
|
||||
|
||||
### Create serviceaccounts token
|
||||
|
||||
Principi che possono **creare TokenRequests** (`serviceaccounts/token`) quando parlano con l'endpoint API K8s SAs (info da [**qui**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/token_request.rego)).
|
||||
Principi che possono **creare TokenRequests** (`serviceaccounts/token`) Quando si parla con l'endpoint API K8s SAs (info da [**qui**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/token_request.rego)).
|
||||
|
||||
### ephemeralcontainers
|
||||
|
||||
@@ -543,7 +543,7 @@ I principi che possono **modificare** **`services/status`** possono impostare il
|
||||
|
||||
### Stato dei nodi e dei pod
|
||||
|
||||
I principi con permessi **`update`** o **`patch`** su `nodes/status` o `pods/status`, potrebbero modificare le etichette per influenzare i vincoli di pianificazione applicati.
|
||||
I principi con permessi **`update`** o **`patch`** su `nodes/status` o `pods/status` potrebbero modificare le etichette per influenzare i vincoli di pianificazione applicati.
|
||||
|
||||
## Prevenzione dell'Escalation dei Privilegi Integrata
|
||||
|
||||
@@ -567,7 +567,7 @@ Il privilegio di creare Rolebindings consente a un utente di **associare ruoli a
|
||||
|
||||
### App proxy Sidecar
|
||||
|
||||
Per impostazione predefinita non c'è alcuna crittografia nella comunicazione tra i pod. Autenticazione reciproca, bidirezionale, da pod a pod.
|
||||
Per impostazione predefinita non c'è alcuna crittografia nella comunicazione tra i pod. Autenticazione reciproca, bidirezionale, pod a pod.
|
||||
|
||||
#### Crea un'app proxy Sidecar <a href="#create-a-sidecar-proxy-app" id="create-a-sidecar-proxy-app"></a>
|
||||
|
||||
|
||||
@@ -94,7 +94,7 @@ GET /apis/apps/v1/watch/deployments [DEPRECATED]
|
||||
Aprono una connessione streaming che ti restituisce il manifesto completo di un Deployment ogni volta che cambia (o quando ne viene creato uno nuovo).
|
||||
|
||||
> [!CAUTION]
|
||||
> I seguenti comandi `kubectl` indicano solo come elencare gli oggetti. Se desideri accedere ai dati, devi usare `describe` invece di `get`.
|
||||
> I seguenti comandi `kubectl` indicano solo come elencare gli oggetti. Se desideri accedere ai dati, devi usare `describe` invece di `get`
|
||||
|
||||
### Utilizzando curl
|
||||
|
||||
@@ -119,9 +119,9 @@ Per impostazione predefinita, l'APISERVER comunica con lo schema `https://`
|
||||
```bash
|
||||
alias k='kubectl --token=$TOKEN --server=https://$APISERVER --insecure-skip-tls-verify=true [--all-namespaces]' # Use --all-namespaces to always search in all namespaces
|
||||
```
|
||||
> se non c'è `https://` nell'URL, potresti ricevere un errore come Bad Request.
|
||||
> se non c'è `https://` nell'url, potresti ricevere un errore come Bad Request.
|
||||
|
||||
Puoi trovare un [**foglio di trucchi ufficiale di kubectl qui**](https://kubernetes.io/docs/reference/kubectl/cheatsheet/). L'obiettivo delle sezioni seguenti è presentare in modo ordinato diverse opzioni per enumerare e comprendere il nuovo K8s a cui hai ottenuto accesso.
|
||||
Puoi trovare un [**foglio di riferimento ufficiale di kubectl qui**](https://kubernetes.io/docs/reference/kubectl/cheatsheet/). L'obiettivo delle sezioni seguenti è presentare in modo ordinato diverse opzioni per enumerare e comprendere il nuovo K8s a cui hai ottenuto accesso.
|
||||
|
||||
Per trovare la richiesta HTTP che `kubectl` invia, puoi usare il parametro `-v=8`
|
||||
|
||||
@@ -309,7 +309,7 @@ kurl -v https://$APISERVER/api/v1/namespaces/<namespace>/deployments/
|
||||
|
||||
### Ottieni Pods
|
||||
|
||||
I Pods sono i **contenitori** che verranno **eseguiti**.
|
||||
I Pods sono i **contenitori** effettivi che verranno **eseguiti**.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -365,7 +365,7 @@ kurl -v https://$APISERVER/api/v1/nodes/
|
||||
|
||||
### Ottieni DaemonSets
|
||||
|
||||
**DaeamonSets** consente di garantire che un **pod specifico sia in esecuzione in tutti i nodi** del cluster (o in quelli selezionati). Se elimini il DaemonSet, i pod gestiti da esso verranno anch'essi rimossi.
|
||||
**DaeamonSets** consente di garantire che un **pod specifico sia in esecuzione in tutti i nodi** del cluster (o in quelli selezionati). Se elimini il DaemonSet, i pod gestiti da esso verranno rimossi.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -429,7 +429,7 @@ k get CiliumClusterwideNetworkPolicies
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
### Ottieni tutto / Tutto
|
||||
### Ottieni Tutto / Tutti
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -449,7 +449,7 @@ k get all --all-namespaces -l='app.kubernetes.io/managed-by=Helm'
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
### **Ottieni i consumi dei Pod**
|
||||
### **Ottieni i consumi dei Pods**
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -465,7 +465,7 @@ Visto che il piano di controllo di Kubernetes espone un'API REST-ful, puoi crear
|
||||
|
||||
### Uscire dal pod
|
||||
|
||||
Se sei in grado di creare nuovi pod, potresti essere in grado di uscire da essi verso il nodo. Per farlo, devi creare un nuovo pod utilizzando un file yaml, passare al pod creato e poi chroot nel sistema del nodo. Puoi utilizzare pod già esistenti come riferimento per il file yaml poiché mostrano immagini e percorsi esistenti.
|
||||
Se sei in grado di creare nuovi pod, potresti essere in grado di uscire da essi verso il nodo. Per farlo, devi creare un nuovo pod utilizzando un file yaml, passare al pod creato e poi chroot nel sistema del nodo. Puoi usare pod già esistenti come riferimento per il file yaml poiché mostrano immagini e percorsi esistenti.
|
||||
```bash
|
||||
kubectl get pod <name> [-n <namespace>] -o yaml
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user