mirror of
https://github.com/carlospolop/hacktricks
synced 2025-02-17 14:38:27 +00:00
Translated ['pentesting-web/race-condition.md'] to pt
This commit is contained in:
Translator
parent
139475edb3
commit
859d9c4056
1 changed files with 23 additions and 23 deletions
|
|
@ -37,8 +37,8 @@ Mas, usando a técnica de '**sincronização do último byte**' do HTTP/1.1, é
|
|||
|
||||
Para **pré-enviar a maior parte de cada solicitação**:
|
||||
|
||||
* Se a solicitação não tem corpo, envie todos os cabeçalhos, mas não defina a flag END\_STREAM. Retenha um quadro de dados vazio com END\_STREAM definido.
|
||||
* Se a solicitação tem um corpo, envie os cabeçalhos e todos os dados do corpo exceto o último byte. Retenha um quadro de dados contendo o último byte.
|
||||
* Se a solicitação não tem corpo, envie todos os cabeçalhos, mas não defina a flag END\_STREAM. Retenha um quadro de dados vazio com a flag END\_STREAM definida.
|
||||
* Se a solicitação tem um corpo, envie os cabeçalhos e todos os dados do corpo exceto o último byte e a flag END\_STREAM. Retenha um quadro de dados contendo o último byte.
|
||||
|
||||
Em seguida, **prepare-se para enviar os quadros finais**:
|
||||
|
||||
|
|
@ -136,8 +136,8 @@ engine.openGate(currentAttempt)
|
|||
* Também está disponível no **Repeater** através da nova opção '**Enviar grupo em paralelo**' no Burp Suite.
|
||||
* Para **limit-overrun**, você poderia simplesmente adicionar **o mesmo pedido 50 vezes** no grupo.
|
||||
* Para **aquecimento de conexão**, você poderia **adicionar** no **início** do **grupo** alguns **pedidos** para alguma parte não estática do servidor web.
|
||||
* Para **atrasar** o processo **entre** o processamento de **um pedido e outro** em etapas de 2 subestados, você poderia **adicionar pedidos extras entre** ambos os pedidos.
|
||||
* Para um RC de **vários pontos finais**, você poderia começar enviando o **pedido** que **vai para o estado oculto** e depois **50 pedidos** logo após ele que **exploram o estado oculto**.
|
||||
* Para **atrasar** o processo **entre** o processamento **de um pedido e outro** em 2 etapas de subestados, você poderia **adicionar pedidos extras entre** ambos os pedidos.
|
||||
* Para um RC **multi-endpoint**, você poderia começar enviando o **pedido** que **vai para o estado oculto** e depois **50 pedidos** logo após ele que **exploram o estado oculto**.
|
||||
|
||||
<figure><img src="../.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
|
|
@ -146,7 +146,7 @@ engine.openGate(currentAttempt)
|
|||
Antes da pesquisa anterior, estes eram alguns payloads usados que apenas tentavam enviar os pacotes o mais rápido possível para causar um RC.
|
||||
|
||||
* **Repeater:** Verifique os exemplos da seção anterior.
|
||||
* **Intruder**: Envie o **pedido** para o **Intruder**, defina o **número de threads** para **30** dentro do **menu Opções e,** selecione como payload **Null payloads** e gere **30.**
|
||||
* **Intruder**: Envie o **pedido** para o **Intruder**, defina o **número de threads** para **30** dentro do menu **Opções e,** selecione como payload **Null payloads** e gere **30.**
|
||||
* **Turbo Intruder**
|
||||
```python
|
||||
def queueRequests(target, wordlists):
|
||||
|
|
@ -198,7 +198,7 @@ asyncio.run(main())
|
|||
|
||||
### Excedente de limite / TOCTOU
|
||||
|
||||
Este é o tipo mais básico de condição de corrida onde **vulnerabilidades** que **aparecem** em locais que **limitam o número de vezes que você pode realizar uma ação**. Como usar o mesmo código de desconto em uma loja online várias vezes. Um exemplo muito fácil pode ser encontrado neste [**relatório**](https://medium.com/@pravinponnusamy/race-condition-vulnerability-found-in-bug-bounty-program-573260454c43) ou neste [**bug**](https://hackerone.com/reports/759247)**.**
|
||||
Este é o tipo mais básico de condição de corrida onde **vulnerabilidades** que **aparecem** em locais que **limitam o número de vezes que você pode realizar uma ação**. Como usar o mesmo código de desconto várias vezes em uma loja online. Um exemplo muito fácil pode ser encontrado neste [**relatório**](https://medium.com/@pravinponnusamy/race-condition-vulnerability-found-in-bug-bounty-program-573260454c43) ou neste [**bug**](https://hackerone.com/reports/759247)**.**
|
||||
|
||||
Existem muitas variações desse tipo de ataque, incluindo:
|
||||
|
||||
|
|
@ -210,19 +210,19 @@ Existem muitas variações desse tipo de ataque, incluindo:
|
|||
|
||||
### **Subestados ocultos**
|
||||
|
||||
Outras RC mais complicadas explorarão **subestados no estado da máquina** que poderiam permitir a um atacante **abusar** de estados aos quais ele **nunca deveria ter acesso**, mas existe uma **pequena janela** para o atacante acessá-lo.
|
||||
Outros RC mais complicados explorarão **subestados no estado da máquina** que podem permitir que um atacante **abuse** de estados aos quais ele **nunca deveria ter acesso**, mas existe uma **pequena janela** para o atacante acessá-lo.
|
||||
|
||||
1. **Prever potenciais subestados ocultos e interessantes**
|
||||
1. **Prever subestados ocultos e interessantes**
|
||||
|
||||
O primeiro passo é identificar todos os endpoints que escrevem nele ou leem dados dele e, em seguida, usam esses dados para algo importante. Por exemplo, usuários podem ser armazenados em uma tabela de banco de dados que é modificada por registro, edições de perfil, iniciação de reset de senha e conclusão de reset de senha.
|
||||
O primeiro passo é identificar todos os endpoints que escrevem nele ou leem dados dele e, em seguida, usam esses dados para algo importante. Por exemplo, usuários podem ser armazenados em uma tabela de banco de dados que é modificada por registro, edições de perfil, iniciação de redefinição de senha e conclusão de redefinição de senha.
|
||||
|
||||
Podemos usar três perguntas-chave para descartar endpoints que provavelmente não causarão colisões. Para cada objeto e os endpoints associados, pergunte:
|
||||
|
||||
* **Como o estado é armazenado?**
|
||||
|
||||
Dados armazenados em uma estrutura de dados persistente do lado do servidor são ideais para exploração. Alguns endpoints armazenam seu estado inteiramente do lado do cliente, como resets de senha que funcionam enviando um JWT por e-mail - esses podem ser ignorados com segurança.
|
||||
Dados armazenados em uma estrutura de dados persistente do lado do servidor são ideais para exploração. Alguns endpoints armazenam seu estado inteiramente do lado do cliente, como redefinições de senha que funcionam enviando um JWT por e-mail - esses podem ser ignorados com segurança.
|
||||
|
||||
Aplicações frequentemente armazenam algum estado na sessão do usuário. Esses geralmente são um tanto protegidos contra subestados - mais sobre isso mais tarde.
|
||||
Aplicações geralmente armazenam algum estado na sessão do usuário. Esses geralmente são um tanto protegidos contra subestados - mais sobre isso mais tarde.
|
||||
|
||||
* **Estamos editando ou acrescentando?**
|
||||
|
||||
|
|
@ -230,7 +230,7 @@ Operações que editam dados existentes (como alterar o e-mail principal de uma
|
|||
|
||||
* **Em que a operação é baseada?**
|
||||
|
||||
A maioria dos endpoints opera em um registro específico, que é procurado usando uma 'chave', como um nome de usuário, token de reset de senha ou nome de arquivo. Para um ataque bem-sucedido, precisamos de duas operações que usem a mesma chave. Por exemplo, imagine duas implementações plausíveis de reset de senha:
|
||||
A maioria dos endpoints opera em um registro específico, que é procurado usando uma 'chave', como um nome de usuário, token de redefinição de senha ou nome de arquivo. Para um ataque bem-sucedido, precisamos de duas operações que usem a mesma chave. Por exemplo, imagine duas implementações plausíveis de redefinição de senha:
|
||||
|
||||
<figure><img src="../.gitbook/assets/image (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
|
|
@ -238,11 +238,11 @@ A maioria dos endpoints opera em um registro específico, que é procurado usand
|
|||
|
||||
Neste ponto, é hora de **lançar alguns ataques RC** sobre os endpoints potencialmente interessantes para tentar encontrar resultados inesperados em comparação com os regulares. **Qualquer desvio da resposta esperada**, como uma mudança em uma ou mais respostas, ou um efeito secundário como conteúdos de e-mail diferentes ou uma mudança visível na sua sessão, pode ser uma pista indicando que algo está errado.
|
||||
|
||||
3. **Comprovar o conceito**
|
||||
3. **Provar o conceito**
|
||||
|
||||
O passo final é **comprovar o conceito e transformá-lo em um ataque viável**.
|
||||
O passo final é **provar o conceito e transformá-lo em um ataque viável**.
|
||||
|
||||
Quando você envia um lote de solicitações, pode descobrir que um par de solicitações iniciais dispara um estado final vulnerável, mas solicitações posteriores sobrescrevem/invalidam isso e o estado final é inexplorável. Neste cenário, você vai querer eliminar todas as solicitações desnecessárias - duas devem ser suficientes para explorar a maioria das vulnerabilidades. No entanto, reduzir para duas solicitações tornará o ataque mais sensível ao tempo, então você pode precisar tentar o ataque várias vezes ou automatizá-lo.
|
||||
Quando você envia um lote de solicitações, pode descobrir que um par de solicitações iniciais desencadeia um estado final vulnerável, mas solicitações posteriores sobrescrevem/invalidam isso e o estado final é inexplorável. Neste cenário, você vai querer eliminar todas as solicitações desnecessárias - duas devem ser suficientes para explorar a maioria das vulnerabilidades. No entanto, reduzir para duas solicitações tornará o ataque mais sensível ao tempo, então você pode precisar tentar o ataque várias vezes ou automatizá-lo.
|
||||
|
||||
### Ataques Sensíveis ao Tempo
|
||||
|
||||
|
|
@ -250,10 +250,10 @@ Quando você envia um lote de solicitações, pode descobrir que um par de solic
|
|||
|
||||
Um exemplo é quando **timestamps de alta resolução são usados em vez de strings aleatórias criptograficamente** seguras para gerar tokens de segurança.
|
||||
|
||||
Considere um **token de reset de senha que é randomizado apenas usando um timestamp**. Neste caso, pode ser possível **disparar dois resets de senha para dois usuários diferentes**, que usam o **mesmo token**. Tudo o que você precisa fazer é cronometrar as solicitações para que elas gerem o mesmo timestamp.
|
||||
Considere um **token de redefinição de senha que é randomizado apenas usando um timestamp**. Neste caso, pode ser possível **acionar duas redefinições de senha para dois usuários diferentes**, que usam o **mesmo token**. Tudo o que você precisa fazer é cronometrar as solicitações para que elas gerem o mesmo timestamp.
|
||||
|
||||
{% hint style="warning" %}
|
||||
Para confirmar, por exemplo, a situação anterior, você poderia simplesmente pedir **2 tokens de reset de senha ao mesmo tempo** (usando ataque de pacote único) e verificar se eles são **os mesmos**.
|
||||
Para confirmar, por exemplo, a situação anterior, você poderia simplesmente pedir **2 tokens de redefinição de senha ao mesmo tempo** (usando ataque de pacote único) e verificar se eles são **iguais**.
|
||||
{% endhint %}
|
||||
|
||||
Confira o [**exemplo neste laboratório**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-exploiting-time-sensitive-vulnerabilities).
|
||||
|
|
@ -270,13 +270,13 @@ A ideia é **verificar um endereço de e-mail e alterá-lo para um diferente ao
|
|||
|
||||
### Mudar e-mail para 2 endereços de e-mail baseados em Cookie
|
||||
|
||||
De acordo com [**este relato**](https://portswigger.net/research/smashing-the-state-machine) o Gitlab era vulnerável a uma tomada deste modo porque poderia **enviar** o **token de verificação de e-mail de um e-mail para o outro e-mail**.
|
||||
De acordo com [**este relato**](https://portswigger.net/research/smashing-the-state-machine) o Gitlab era vulnerável a uma tomada de controle dessa maneira porque poderia **enviar** o **token de verificação de e-mail de um e-mail para o outro e-mail**.
|
||||
|
||||
Você também pode conferir [**este laboratório**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-single-endpoint) para aprender sobre isso.
|
||||
|
||||
### Estados ocultos do banco de dados / Bypass de confirmação
|
||||
|
||||
Se **2 escritas diferentes** são usadas para **adicionar** **informações** dentro de um **banco de dados**, existe uma pequena porção de tempo onde **apenas os primeiros dados foram escritos** no banco de dados. Por exemplo, ao criar um usuário, o **nome de usuário** e **senha** podem ser **escritos** e **então o token** para confirmar a nova conta é escrito. Isso significa que por um pequeno tempo o **token para confirmar uma conta é nulo**.
|
||||
Se **2 escritas diferentes** são usadas para **adicionar** **informações** dentro de um **banco de dados**, existe uma pequena porção de tempo onde **apenas os primeiros dados foram escritos** no banco de dados. Por exemplo, ao criar um usuário, o **nome de usuário** e **senha** podem ser **escritos** e **depois o token** para confirmar a conta recém-criada é escrito. Isso significa que por um pequeno tempo o **token para confirmar uma conta é nulo**.
|
||||
|
||||
Portanto, **registrar uma conta e enviar várias solicitações com um token vazio** (`token=` ou `token[]=` ou qualquer outra variação) para confirmar a conta imediatamente poderia permitir **confirmar uma conta** onde você não controla o e-mail.
|
||||
|
||||
|
|
@ -284,7 +284,7 @@ Confira [**este laboratório**](https://portswigger.net/web-security/race-condit
|
|||
|
||||
### Bypass de 2FA
|
||||
|
||||
O seguinte pseudo-código demonstra como um site poderia ser vulnerável a uma variação de ataque de corrida deste tipo:
|
||||
O seguinte pseudo-código demonstra como um site poderia ser vulnerável a uma variação de ataque de corrida dessa forma:
|
||||
```python
|
||||
session['userid'] = user.userid
|
||||
if user.mfa_enabled:
|
||||
|
|
@ -301,7 +301,7 @@ Até aqui, apenas um login comum com google/linkedin/github... onde você é apr
|
|||
|
||||
#### Condição de Corrida em `authorization_code`
|
||||
|
||||
O **problema** aparece quando você **aceita** e automaticamente envia um **`authorization_code`** para a aplicação maliciosa. Então, essa **aplicação abusa de uma Condição de Corrida no provedor de serviço OAuth para gerar mais de um AT/RT** (_Token de Autenticação/Token de Atualização_) a partir do **`authorization_code`** para sua conta. Basicamente, ela abusará do fato de você ter aceitado a aplicação acessar seus dados para **criar várias contas**. Então, se você **parar de permitir que a aplicação acesse seus dados, um par de AT/RT será deletado, mas os outros ainda serão válidos**.
|
||||
O **problema** aparece quando você **aceita** e automaticamente envia um **`authorization_code`** para a aplicação maliciosa. Então, essa **aplicação abusa de uma Condição de Corrida no provedor de serviço OAuth para gerar mais de um AT/RT** (_Token de Autenticação/Token de Atualização_) a partir do **`authorization_code`** para sua conta. Basicamente, ela abusará do fato de você ter aceitado a aplicação para acessar seus dados para **criar várias contas**. Então, se você **parar de permitir que a aplicação acesse seus dados, um par de AT/RT será deletado, mas os outros ainda serão válidos**.
|
||||
|
||||
#### Condição de Corrida em `Refresh Token`
|
||||
|
||||
|
|
@ -327,7 +327,7 @@ Outras formas de apoiar o HackTricks:
|
|||
|
||||
* Se você quer ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
|
||||
* Adquira o [**material oficial PEASS & HackTricks**](https://peass.creator-spring.com)
|
||||
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção de [**NFTs exclusivos**](https://opensea.io/collection/the-peass-family)
|
||||
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
|
||||
* **Junte-se ao grupo** 💬 [**Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga-me** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
|
||||
* **Compartilhe suas dicas de hacking enviando PRs para os repositórios** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) no github.
|
||||
|
||||
|
|
@ -336,7 +336,7 @@ Outras formas de apoiar o HackTricks:
|
|||
<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
\
|
||||
Use [**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks) para construir e **automatizar fluxos de trabalho** com as ferramentas comunitárias **mais avançadas** do mundo.\
|
||||
Use [**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks) para construir e **automatizar fluxos de trabalho** com facilidade, alimentados pelas **ferramentas comunitárias mais avançadas**.\
|
||||
Obtenha Acesso Hoje:
|
||||
|
||||
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue