mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/binary-exploitation/rop-return-oriented-programing/srop
This commit is contained in:
Translator
parent
9abacff6a7
commit
1bef06651e
@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Exemplo de Pwntools
|
||||
## Exemplo Pwntools
|
||||
|
||||
Este exemplo cria o binário vulnerável e o explora. O binário **lê na pilha** e então chama **`sigreturn`**:
|
||||
```python
|
||||
@ -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`. Como **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}}
|
||||
|
||||
@ -6,7 +6,7 @@
|
||||
|
||||
Existem 3 maneiras de indicar o conteúdo de uma página em um iframe:
|
||||
|
||||
- Via `src` indicando uma URL (a URL pode ser de origem cruzada ou mesma origem)
|
||||
- Via `src` indicando uma URL (a URL pode ser de origem cruzada ou da mesma origem)
|
||||
- Via `src` indicando o conteúdo usando o protocolo `data:`
|
||||
- Via `srcdoc` indicando o conteúdo
|
||||
|
||||
@ -81,7 +81,7 @@ No entanto, **apenas os scripts `if1` e `if2` serão executados, mas apenas `if1
|
||||
|
||||
.png>)
|
||||
|
||||
Portanto, é possível **contornar um CSP se você puder fazer upload de um arquivo JS para o servidor e carregá-lo via iframe, mesmo com `script-src 'none'`**. Isso pode **potencialmente ser feito abusando de um endpoint JSONP de mesmo site**.
|
||||
Portanto, é possível **contornar um CSP se você puder fazer upload de um arquivo JS para o servidor e carregá-lo via iframe, mesmo com `script-src 'none'`**. Isso pode **potencialmente ser feito também abusando de um endpoint JSONP de mesmo site**.
|
||||
|
||||
Você pode testar isso com o seguinte cenário onde um cookie é roubado mesmo com `script-src 'none'`. Basta executar o aplicativo e acessá-lo com seu navegador:
|
||||
```python
|
||||
@ -107,7 +107,7 @@ app.run()
|
||||
|
||||
A comunidade de pesquisa continua a descobrir maneiras criativas de abusar de iframes para derrotar políticas restritivas. Abaixo você pode encontrar as técnicas mais notáveis publicadas nos últimos anos:
|
||||
|
||||
* **Exfiltração de dados via dangling-markup / named-iframe (PortSwigger 2023)** – Quando uma aplicação reflete HTML, mas um CSP forte bloqueia a execução de scripts, você ainda pode vazar tokens sensíveis injetando um atributo `<iframe name>` *dangling*. Uma vez que a marcação parcial é analisada, o script do atacante rodando em uma origem separada navega o frame para `about:blank` e lê `window.name`, que agora contém tudo até o próximo caractere de citação (por exemplo, um token CSRF). Como nenhum JavaScript é executado no contexto da vítima, o ataque geralmente evita `script-src 'none'`. Um PoC mínimo é:
|
||||
* **Exfiltração de dados via dangling-markup / named-iframe (PortSwigger 2023)** – Quando uma aplicação reflete HTML, mas um CSP forte bloqueia a execução de scripts, você ainda pode vazar tokens sensíveis injetando um atributo `<iframe name>` *dangling*. Uma vez que a marcação parcial é analisada, o script do atacante em uma origem separada navega o frame para `about:blank` e lê `window.name`, que agora contém tudo até o próximo caractere de citação (por exemplo, um token CSRF). Como nenhum JavaScript é executado no contexto da vítima, o ataque geralmente evita `script-src 'none'`. Um PoC mínimo é:
|
||||
|
||||
```html
|
||||
<!-- Ponto de injeção logo antes de um <script> sensível -->
|
||||
@ -130,12 +130,12 @@ s.nonce = n;
|
||||
top.document.body.appendChild(s);
|
||||
```
|
||||
|
||||
* **Sequestro de form-action (PortSwigger 2024)** – Uma página que omite a diretiva `form-action` pode ter seu formulário de login *re-direcionado* a partir de um iframe injetado ou HTML inline, de modo que gerenciadores de senhas preencham automaticamente e enviem credenciais para um domínio externo, mesmo quando `script-src 'none'` está presente. Sempre complemente `default-src` com `form-action`!
|
||||
* **Sequestro de form-action (PortSwigger 2024)** – Uma página que omite a diretiva `form-action` pode ter seu formulário de login *re-direcionado* de um iframe injetado ou HTML inline, de modo que gerenciadores de senhas preencham automaticamente e enviem credenciais para um domínio externo, mesmo quando `script-src 'none'` está presente. Sempre complemente `default-src` com `form-action`!
|
||||
|
||||
**Notas defensivas (checklist rápido)**
|
||||
**Notas defensivas (checklist rápida)**
|
||||
|
||||
1. Sempre envie *todas* as diretivas CSP que controlam contextos secundários (`form-action`, `frame-src`, `child-src`, `object-src`, etc.).
|
||||
2. Não confie que nonces sejam secretos—use `strict-dynamic` **e** elimine pontos de injeção.
|
||||
2. Não confie que os nonces sejam secretos—use `strict-dynamic` **e** elimine pontos de injeção.
|
||||
3. Quando você precisar incorporar documentos não confiáveis, use `sandbox="allow-scripts allow-same-origin"` **com muito cuidado** (ou sem `allow-same-origin` se você só precisar de isolamento de execução de script).
|
||||
4. Considere uma implantação de defesa em profundidade COOP+COEP; o novo atributo `<iframe credentialless>` (§ abaixo) permite que você faça isso sem quebrar incorporações de terceiros.
|
||||
|
||||
@ -175,12 +175,12 @@ O valor do atributo pode ser deixado vazio (`sandbox=""`) para aplicar todas as
|
||||
```
|
||||
### Iframes sem credenciais
|
||||
|
||||
Como explicado em [este artigo](https://blog.slonser.info/posts/make-self-xss-great-again/), a flag `credentialless` em um iframe é usada para carregar uma página dentro de um iframe sem enviar credenciais na requisição, mantendo a mesma política de origem (SOP) da página carregada no iframe.
|
||||
Como explicado em [este artigo](https://blog.slonser.info/posts/make-self-xss-great-again/), a flag `credentialless` em um iframe é usada para carregar uma página dentro de um iframe sem enviar credenciais na solicitação, mantendo a mesma política de origem (SOP) da página carregada no iframe.
|
||||
|
||||
Desde **o Chrome 110 (fevereiro de 2023), o recurso está habilitado por padrão** e a especificação está sendo padronizada entre os navegadores sob o nome *iframe anônimo*. O MDN descreve como: “um mecanismo para carregar iframes de terceiros em uma nova partição de armazenamento efêmera, de modo que nenhum cookie, localStorage ou IndexedDB seja compartilhado com a origem real”. Consequências para atacantes e defensores:
|
||||
Desde **o Chrome 110 (fevereiro de 2023), o recurso está habilitado por padrão** e a especificação está sendo padronizada entre os navegadores sob o nome *iframe anônimo*. O MDN o descreve como: “um mecanismo para carregar iframes de terceiros em uma nova partição de armazenamento efêmera, de modo que nenhum cookie, localStorage ou IndexedDB seja compartilhado com a origem real”. Consequências para atacantes e defensores:
|
||||
|
||||
* Scripts em diferentes iframes sem credenciais **ainda compartilham a mesma origem de nível superior** e podem interagir livremente via DOM, tornando viáveis ataques de self-XSS em múltiplos iframes (veja PoC abaixo).
|
||||
* Como a rede está **sem credenciais**, qualquer requisição dentro do iframe efetivamente se comporta como uma sessão não autenticada – endpoints protegidos por CSRF geralmente falham, mas páginas públicas que podem vazar via DOM ainda estão em escopo.
|
||||
* Como a rede é **sem credenciais**, qualquer solicitação dentro do iframe efetivamente se comporta como uma sessão não autenticada – endpoints protegidos por CSRF geralmente falham, mas páginas públicas que podem vazar via DOM ainda estão em escopo.
|
||||
* Pop-ups gerados a partir de um iframe sem credenciais recebem um `rel="noopener"` implícito, quebrando alguns fluxos de OAuth.
|
||||
```javascript
|
||||
// PoC: two same-origin credentialless iframes stealing cookies set by a third
|
||||
@ -189,7 +189,7 @@ alert(window.top[2].document.cookie); // read -> foo=bar
|
||||
```
|
||||
- Exemplo de exploração: Self-XSS + CSRF
|
||||
|
||||
Neste ataque, o atacante prepara uma página maliciosa com 2 iframes:
|
||||
Neste ataque, o atacante prepara uma página web maliciosa com 2 iframes:
|
||||
|
||||
- Um iframe que carrega a página da vítima com a flag `credentialless` com um CSRF que aciona um XSS (Imagine um Self-XSS no nome de usuário do usuário):
|
||||
```html
|
||||
@ -209,7 +209,7 @@ document.forms[0].submit();
|
||||
|
||||
- Outro iframe que na verdade tem o usuário logado (sem a flag `credentialless`).
|
||||
|
||||
Então, a partir do XSS, é possível acessar o outro iframe, pois eles têm o mesmo SOP e roubar o cookie, por exemplo, executando:
|
||||
Então, a partir do XSS é possível acessar o outro iframe, pois eles têm o mesmo SOP e roubar o cookie, por exemplo, executando:
|
||||
```javascript
|
||||
alert(window.top[1].document.cookie);
|
||||
```
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user