diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 6172b28d3..d05776c71 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -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) diff --git a/src/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-vms-unath.md b/src/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-vms-unath.md deleted file mode 100644 index fd4994a9e..000000000 --- a/src/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-vms-unath.md +++ /dev/null @@ -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}} diff --git a/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md b/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md index 2b697cc63..89a410d16 100644 --- a/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md +++ b/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.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://: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://: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/' bin @@ -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 ``` ### 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 -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. diff --git a/src/pentesting-cloud/kubernetes-security/kubernetes-enumeration.md b/src/pentesting-cloud/kubernetes-security/kubernetes-enumeration.md index afd28dcff..db5fd8f38 100644 --- a/src/pentesting-cloud/kubernetes-security/kubernetes-enumeration.md +++ b/src/pentesting-cloud/kubernetes-security/kubernetes-enumeration.md @@ -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//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 [-n ] -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