mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-02-05 03:16:37 -08:00
Translated ['src/pentesting-cloud/azure-security/az-services/az-cosmosDB
This commit is contained in:
Translator
@@ -398,7 +398,8 @@
|
||||
- [Az - Enumeration Tools](pentesting-cloud/azure-security/az-enumeration-tools.md)
|
||||
- [Az - Unauthenticated Enum & Initial Entry](pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/README.md)
|
||||
- [Az - OAuth Apps Phishing](pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-oauth-apps-phishing.md)
|
||||
- [Az - VMs Unath](pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-vms-unath.md)
|
||||
- [Az - Storage Unath](pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-storage-unauth.md)
|
||||
- [Az - VMs Unath](pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-vms-unauth.md)
|
||||
- [Az - Device Code Authentication Phishing](pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-device-code-authentication-phishing.md)
|
||||
- [Az - Password Spraying](pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying.md)
|
||||
- [Az - Services](pentesting-cloud/azure-security/az-services/README.md)
|
||||
|
||||
@@ -1,37 +0,0 @@
|
||||
# Az - VMs Unath
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Máquinas Virtuais
|
||||
|
||||
Para mais informações sobre Máquinas Virtuais do Azure, consulte:
|
||||
|
||||
{{#ref}}
|
||||
../az-services/vms/
|
||||
{{#endref}}
|
||||
|
||||
### Serviço vulnerável exposto
|
||||
|
||||
Um serviço de rede que é vulnerável a algum RCE.
|
||||
|
||||
### Imagens de Galeria Públicas
|
||||
|
||||
Uma imagem pública pode conter segredos dentro dela:
|
||||
```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']"
|
||||
```
|
||||
### Extensões Públicas
|
||||
|
||||
Isso seria mais estranho, mas não impossível. Uma grande empresa pode colocar uma extensão com dados sensíveis dentro dela:
|
||||
```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}}
|
||||
@@ -1,4 +1,4 @@
|
||||
# Abusing Roles/ClusterRoles in Kubernetes
|
||||
# Abusando de Roles/ClusterRoles no Kubernetes
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -11,7 +11,7 @@ Referindo-se à arte de obter **acesso a um principal diferente** dentro do clus
|
||||
|
||||
- Ser capaz de **impersonar** outros usuários/grupos/SAs com melhores privilégios dentro do cluster kubernetes ou para nuvens externas
|
||||
- Ser capaz de **criar/patch/exec pods** onde você pode **encontrar ou anexar SAs** com melhores privilégios dentro do cluster kubernetes ou para nuvens externas
|
||||
- Ser capaz de **ler segredos** já que os tokens dos SAs são armazenados como segredos
|
||||
- Ser capaz de **ler segredos** já que os tokens SAs são armazenados como segredos
|
||||
- Ser capaz de **escapar para o nó** a partir de um contêiner, onde você pode roubar todos os segredos dos contêineres em execução no nó, as credenciais do nó e as permissões do nó dentro da nuvem em que está sendo executado (se houver)
|
||||
- Uma quinta técnica que merece menção é a capacidade de **executar port-forward** em um pod, pois você pode ser capaz de acessar recursos interessantes dentro desse pod.
|
||||
|
||||
@@ -76,9 +76,9 @@ hostNetwork: true
|
||||
|
||||
O seguinte indica todos os privilégios que um contêiner pode ter:
|
||||
|
||||
- **Acesso privilegiado** (desabilitando proteções e configurando capacidades)
|
||||
- **Desabilitar namespaces hostIPC e hostPid** que podem ajudar a escalar privilégios
|
||||
- **Desabilitar o namespace hostNetwork**, dando acesso para roubar privilégios de nuvem dos nós e melhor acesso às redes
|
||||
- **Acesso privilegiado** (desativando proteções e configurando capacidades)
|
||||
- **Desativar namespaces hostIPC e hostPid** que podem ajudar a escalar privilégios
|
||||
- **Desativar o namespace hostNetwork**, dando acesso para roubar privilégios de nuvem dos nós e melhor acesso às redes
|
||||
- **Montar hosts / dentro do contêiner**
|
||||
```yaml:super_privs.yaml
|
||||
apiVersion: v1
|
||||
@@ -219,7 +219,7 @@ kubectl logs escaper --tail=2
|
||||
failed to get parse function: unsupported log format: "systemd-resolve:*:::::::\n"
|
||||
# Keep incrementing tail to exfiltrate the whole file
|
||||
```
|
||||
- Se o atacante controla qualquer principal com as **permissões para ler `nodes/log`**, ele pode simplesmente criar um **symlink** em `/host-mounted/var/log/sym` para `/` e ao **acessar `https://<gateway>:10250/logs/sym/` ele listará o sistema de arquivos raiz** do host (alterar o symlink pode fornecer acesso a arquivos).
|
||||
- Se o atacante controla qualquer principal com as **permissões para ler `nodes/log`**, ele pode simplesmente criar um **symlink** em `/host-mounted/var/log/sym` para `/` e ao **acessar `https://<gateway>:10250/logs/sym/` ele listará o sistema de arquivos root** do host (alterar o symlink pode fornecer acesso a arquivos).
|
||||
```bash
|
||||
curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://172.17.0.1:10250/logs/sym/'
|
||||
<a href="bin">bin</a>
|
||||
@@ -424,7 +424,7 @@ verbs:
|
||||
```
|
||||
Então, com o novo CSR do nó aprovado, você pode **abusar** das permissões especiais dos nós para **roubar segredos** e **escalar privilégios**.
|
||||
|
||||
Em [**este post**](https://www.4armed.com/blog/hacking-kubelet-on-gke/) e [**neste aqui**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/), a configuração do GKE K8s TLS Bootstrap é configurada com **assinatura automática** e é abusada para gerar credenciais de um novo nó K8s e, em seguida, abusar delas para escalar privilégios ao roubar segredos.\
|
||||
Em [**este post**](https://www.4armed.com/blog/hacking-kubelet-on-gke/) e [**neste aqui**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/), a configuração do GKE K8s TLS Bootstrap é configurada com **assinatura automática** e é abusada para gerar credenciais de um novo nó K8s e, em seguida, abusar delas para escalar privilégios roubando segredos.\
|
||||
Se você **tiver os privilégios mencionados, poderá fazer a mesma coisa**. Note que o primeiro exemplo contorna o erro que impede um novo nó de acessar segredos dentro de contêineres porque um **nó só pode acessar os segredos dos contêineres montados nele.**
|
||||
|
||||
A maneira de contornar isso é apenas **criar credenciais de nó para o nome do nó onde o contêiner com os segredos interessantes está montado** (mas apenas verifique como fazer isso no primeiro post):
|
||||
@@ -484,10 +484,10 @@ groups:
|
||||
Existem **2 maneiras de atribuir permissões K8s a principais do GCP**. Em qualquer caso, o principal também precisa da permissão **`container.clusters.get`** para poder obter credenciais para acessar o cluster, ou você precisará **gerar seu próprio arquivo de configuração kubectl** (siga o próximo link).
|
||||
|
||||
> [!WARNING]
|
||||
> Ao se comunicar com o endpoint da API K8s, o **token de autenticação do GCP será enviado**. Então, o GCP, através do endpoint da API K8s, primeiro **verificará se o principal** (por e-mail) **tem algum acesso dentro do cluster**, depois verificará se ele tem **acesso via GCP IAM**.\
|
||||
> Se **qualquer** um desses for **verdadeiro**, ele será **respondido**. Se **não**, um **erro** sugerindo dar **permissões via GCP IAM** será apresentado.
|
||||
> Ao falar com o endpoint da API K8s, o **token de autenticação do GCP será enviado**. Então, o GCP, através do endpoint da API K8s, primeiro **verificará se o principal** (por e-mail) **tem algum acesso dentro do cluster**, depois verificará se ele tem **acesso via GCP IAM**.\
|
||||
> Se **qualquer** um desses for **verdade**, ele será **respondido**. Se **não**, um **erro** sugerindo dar **permissões via GCP IAM** será fornecido.
|
||||
|
||||
Então, o primeiro método é usar **GCP IAM**, as permissões K8s têm suas **permissões equivalentes no GCP IAM**, e se o principal as tiver, poderá usá-las.
|
||||
Então, o primeiro método é usar **GCP IAM**, as permissões K8s têm suas **permissões equivalentes do GCP IAM**, e se o principal as tiver, poderá usá-las.
|
||||
|
||||
{{#ref}}
|
||||
../../gcp-security/gcp-privilege-escalation/gcp-container-privesc.md
|
||||
@@ -497,11 +497,11 @@ O segundo método é **atribuir permissões K8s dentro do cluster** identificand
|
||||
|
||||
### Criar token de serviceaccounts
|
||||
|
||||
Principais que podem **criar TokenRequests** (`serviceaccounts/token`) ao se comunicar com o endpoint da API K8s SAs (informações de [**aqui**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/token_request.rego)).
|
||||
Principais que podem **criar TokenRequests** (`serviceaccounts/token`) ao falar com o endpoint da API K8s SAs (informações de [**aqui**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/token_request.rego)).
|
||||
|
||||
### ephemeralcontainers
|
||||
|
||||
Principais que podem **`atualizar`** ou **`patch`** **`pods/ephemeralcontainers`** podem obter **execução de código em outros pods**, e potencialmente **sair** para seu nó adicionando um contêiner efêmero com um securityContext privilegiado.
|
||||
Principais que podem **`atualizar`** ou **`patch`** **`pods/ephemeralcontainers`** podem ganhar **execução de código em outros pods**, e potencialmente **sair** para seu nó adicionando um contêiner efêmero com um securityContext privilegiado.
|
||||
|
||||
### ValidatingWebhookConfigurations ou MutatingWebhookConfigurations
|
||||
|
||||
@@ -512,7 +512,7 @@ Para um [exemplo de `mutatingwebhookconfigurations`, confira esta seção deste
|
||||
### Escalar
|
||||
|
||||
Como você pode ler na próxima seção: [**Prevenção de Escalação de Privilégios Integrada**](#built-in-privileged-escalation-prevention), um principal não pode atualizar nem criar roles ou clusterroles sem ter ele mesmo essas novas permissões. Exceto se ele tiver o **verbo `escalate`** sobre **`roles`** ou **`clusterroles`**.\
|
||||
Então ele pode atualizar/criar novas roles, clusterroles com permissões melhores do que as que possui.
|
||||
Então ele pode atualizar/criar novas roles, clusterroles com melhores permissões do que as que possui.
|
||||
|
||||
### Proxy de nós
|
||||
|
||||
@@ -539,7 +539,7 @@ kubectl delete pods -n kube-system <privileged_pod_name>
|
||||
```
|
||||
### Status dos serviços (CVE-2020-8554)
|
||||
|
||||
Principais que podem **modificar** **`services/status`** podem definir o campo `status.loadBalancer.ingress.ip` para explorar o **CVE-2020-8554 não corrigido** e lançar **ataques MiTM contra o clus**ter. A maioria das mitig ações para o CVE-2020-8554 apenas previne serviços ExternalIP (de acordo com [**isso**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/modify_service_status_cve_2020_8554.rego)).
|
||||
Principais que podem **modificar** **`services/status`** podem definir o campo `status.loadBalancer.ingress.ip` para explorar a **CVE-2020-8554 não corrigida** e lançar **ataques MiTM contra o clus**ter. A maioria das mitig ações para a CVE-2020-8554 apenas previne serviços ExternalIP (de acordo com [**isso**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/modify_service_status_cve_2020_8554.rego)).
|
||||
|
||||
### Status de Nós e Pods
|
||||
|
||||
@@ -549,7 +549,7 @@ Principais com permissões de **`update`** ou **`patch`** sobre `nodes/status` o
|
||||
|
||||
Kubernetes possui um [mecanismo integrado](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) para prevenir a escalada de privilégios.
|
||||
|
||||
Este sistema garante que **os usuários não podem elevar seus privilégios modificando funções ou vinculações de funções**. A aplicação desta regra ocorre no nível da API, fornecendo uma salvaguarda mesmo quando o autorizer RBAC está inativo.
|
||||
Este sistema garante que **os usuários não podem elevar seus privilégios modificando funções ou vinculações de funções**. A aplicação desta regra ocorre no nível da API, fornecendo uma proteção mesmo quando o autorizar RBAC está inativo.
|
||||
|
||||
A regra estipula que um **usuário só pode criar ou atualizar uma função se possuir todas as permissões que a função compreende**. Além disso, o escopo das permissões existentes do usuário deve alinhar-se com o da função que ele está tentando criar ou modificar: seja em todo o cluster para ClusterRoles ou restrito ao mesmo namespace (ou em todo o cluster) para Roles.
|
||||
|
||||
@@ -638,7 +638,7 @@ Então, implante um novo pod:
|
||||
kubectl run nginx --image nginx
|
||||
kubectl get po -w
|
||||
```
|
||||
Quando você vê o erro `ErrImagePull`, verifique o nome da imagem com uma das consultas:
|
||||
Quando você pode ver o erro `ErrImagePull`, verifique o nome da imagem com uma das consultas:
|
||||
```bash
|
||||
kubectl get po nginx -o=jsonpath='{.spec.containers[].image}{"\n"}'
|
||||
kubectl describe po nginx | grep "Image: "
|
||||
@@ -649,7 +649,7 @@ Como você pode ver na imagem acima, tentamos executar a imagem `nginx`, mas a i
|
||||
|
||||
#### Technicalities <a href="#heading-technicalities" id="heading-technicalities"></a>
|
||||
|
||||
O script `./deploy.sh` estabelece um controlador de admissão de webhook mutável, que modifica as solicitações para a API do Kubernetes conforme especificado em suas linhas de configuração, influenciando os resultados observados:
|
||||
O script `./deploy.sh` estabelece um controlador de admissão de webhook mutável, que modifica as solicitações à API do Kubernetes conforme especificado em suas linhas de configuração, influenciando os resultados observados:
|
||||
```
|
||||
patches = append(patches, patchOperation{
|
||||
Op: "replace",
|
||||
@@ -676,7 +676,7 @@ O trecho acima substitui a primeira imagem do contêiner em cada pod por `rewant
|
||||
|
||||
- **Inclusão Seletiva**: Certifique-se de que apenas os usuários necessários estejam incluídos em RoleBindings ou ClusterRoleBindings. Audite regularmente e remova usuários irrelevantes para manter a segurança rigorosa.
|
||||
|
||||
### **Papéis Específicos de Namespace em vez de Papéis de Cluster**
|
||||
### **Papéis Específicos de Namespace Sobre Papéis de Cluster**
|
||||
|
||||
- **Papéis vs. ClusterRoles**: Prefira usar Roles e RoleBindings para permissões específicas de namespace em vez de ClusterRoles e ClusterRoleBindings, que se aplicam em todo o cluster. Essa abordagem oferece um controle mais fino e limita o escopo das permissões.
|
||||
|
||||
|
||||
@@ -94,7 +94,7 @@ GET /apis/apps/v1/watch/deployments [DEPRECATED]
|
||||
Eles abrem uma conexão de streaming que retorna o manifesto completo de um Deployment sempre que ele muda (ou quando um novo é criado).
|
||||
|
||||
> [!CAUTION]
|
||||
> Os seguintes comandos `kubectl` indicam apenas como listar os objetos. Se você quiser acessar os dados, precisa usar `describe` em vez de `get`.
|
||||
> Os seguintes comandos `kubectl` indicam apenas como listar os objetos. Se você quiser acessar os dados, precisa usar `describe` em vez de `get`
|
||||
|
||||
### Usando curl
|
||||
|
||||
@@ -328,7 +328,7 @@ kurl -v https://$APISERVER/api/v1/namespaces/<namespace>/pods/
|
||||
|
||||
### Obter Serviços
|
||||
|
||||
Os **serviços** do Kubernetes são usados para **expor um serviço em uma porta e IP específicos** (que atuarão como balanceador de carga para os pods que estão realmente oferecendo o serviço). Isso é interessante para saber onde você pode encontrar outros serviços para tentar atacar.
|
||||
Kubernetes **services** são usados para **expor um serviço em uma porta e IP específicos** (que atuarão como balanceador de carga para os pods que estão realmente oferecendo o serviço). Isso é interessante para saber onde você pode encontrar outros serviços para tentar atacar.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -473,7 +473,7 @@ kubectl get pod <name> [-n <namespace>] -o yaml
|
||||
>
|
||||
> `k get nodes --show-labels`
|
||||
>
|
||||
> Comumente, kubernetes.io/hostname e node-role.kubernetes.io/master são bons rótulos para selecionar.
|
||||
> Comumente, kubernetes.io/hostname e node-role.kubernetes.io/master são bons rótulos para seleção.
|
||||
|
||||
Então você cria seu arquivo attack.yaml
|
||||
```yaml
|
||||
|
||||
Reference in New Issue
Block a user