mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/generic-methodologies-and-resources/external-recon-meth
This commit is contained in:
Translator
parent
9070490603
commit
162bdf00d3
@ -2,18 +2,13 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
Agora que construímos a lista de ativos do nosso escopo, é hora de procurar algumas frutas baixas de OSINT.
|
||||
|
||||
### Plataformas que já pesquisaram por leaks
|
||||
|
||||
- [https://trufflesecurity.com/blog/introducing-forager/](https://trufflesecurity.com/blog/introducing-forager/)
|
||||
|
||||
### Vazamentos de chaves de API no github
|
||||
### Ferramentas para encontrar segredos em repositórios git e sistema de arquivos
|
||||
|
||||
- [https://github.com/dxa4481/truffleHog](https://github.com/dxa4481/truffleHog)
|
||||
- [https://github.com/gitleaks/gitleaks](https://github.com/gitleaks/gitleaks)
|
||||
- [https://github.com/praetorian-inc/noseyparker](https://github.com/praetorian-inc/noseyparker)
|
||||
- [https://github.com/GitGuardian/ggshield](https://github.com/GitGuardian/ggshield)
|
||||
- [https://github.com/JaimePolop/RExpository](https://github.com/JaimePolop/RExpository)
|
||||
- [https://github.com/Yelp/detect-secrets](https://github.com/Yelp/detect-secrets)
|
||||
- [https://github.com/hisxo/gitGraber](https://github.com/hisxo/gitGraber)
|
||||
- [https://github.com/eth0izzle/shhgit](https://github.com/eth0izzle/shhgit)
|
||||
|
||||
@ -44,7 +44,7 @@ https://socialmedia.com/auth
|
||||
```
|
||||
https://example.com?code=uniqueCode123&state=randomString123
|
||||
```
|
||||
5. https://example.com utiliza este `code`, juntamente com seu `client_id` e `client_secret`, para fazer uma solicitação do lado do servidor para obter um `access_token` em seu nome, permitindo o acesso às permissões que você consentiu:
|
||||
5. https://example.com utiliza este `code`, junto com seu `client_id` e `client_secret`, para fazer uma solicitação do lado do servidor para obter um `access_token` em seu nome, permitindo o acesso às permissões que você consentiu:
|
||||
```
|
||||
POST /oauth/access_token
|
||||
Host: socialmedia.com
|
||||
@ -72,28 +72,28 @@ https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</scrip
|
||||
```
|
||||
### CSRF - Manipulação inadequada do parâmetro de estado <a href="#bda5" id="bda5"></a>
|
||||
|
||||
Em implementações de OAuth, o uso indevido ou a omissão do **`state` parameter** pode aumentar significativamente o risco de ataques de **Cross-Site Request Forgery (CSRF)**. Essa vulnerabilidade surge quando o parâmetro `state` é **não utilizado, utilizado como um valor estático ou não validado corretamente**, permitindo que atacantes contornem as proteções contra CSRF.
|
||||
Em implementações de OAuth, o uso indevido ou a omissão do **`state` parameter** pode aumentar significativamente o risco de ataques de **Cross-Site Request Forgery (CSRF)**. Essa vulnerabilidade surge quando o parâmetro `state` é **não utilizado, utilizado como um valor estático ou não validado corretamente ou associado à sessão do usuário** durante o login, permitindo que atacantes contornem as proteções contra CSRF.
|
||||
|
||||
Os atacantes podem explorar isso interceptando o processo de autorização para vincular sua conta à conta de uma vítima, levando a possíveis **assumptions de conta**. Isso é especialmente crítico em aplicações onde o OAuth é utilizado para **fins de autenticação**.
|
||||
Os atacantes podem explorar isso interceptando o processo de autorização para vincular sua conta à conta de uma vítima, levando a potenciais **assumptions de conta** ao fazer um usuário logar com um fluxo oauth quase finalizado pertencente ao atacante. Isso é especialmente crítico em aplicações onde o OAuth é usado para **fins de autenticação**.
|
||||
|
||||
Exemplos do mundo real dessa vulnerabilidade foram documentados em vários **desafios CTF** e **plataformas de hacking**, destacando suas implicações práticas. O problema também se estende a integrações com serviços de terceiros como **Slack**, **Stripe** e **PayPal**, onde os atacantes podem redirecionar notificações ou pagamentos para suas contas.
|
||||
|
||||
O manuseio e a validação adequados do **`state` parameter** são cruciais para proteger contra CSRF e garantir o fluxo do OAuth.
|
||||
O manuseio e a validação adequados do **`state` parameter** são cruciais para proteger contra CSRF e garantir o fluxo OAuth.
|
||||
|
||||
### Pré Assunção de Conta <a href="#ebe4" id="ebe4"></a>
|
||||
### Pré Assumir Conta <a href="#ebe4" id="ebe4"></a>
|
||||
|
||||
1. **Sem Verificação de Email na Criação da Conta**: Os atacantes podem criar proativamente uma conta usando o email da vítima. Se a vítima usar um serviço de terceiros para login, a aplicação pode inadvertidamente vincular essa conta de terceiros à conta pré-criada do atacante, levando ao acesso não autorizado.
|
||||
2. **Explorando a Verificação de Email Lax do OAuth**: Os atacantes podem explorar serviços de OAuth que não verificam emails registrando-se com seu serviço e, em seguida, alterando o email da conta para o da vítima. Esse método também arrisca o acesso não autorizado à conta, semelhante ao primeiro cenário, mas através de um vetor de ataque diferente.
|
||||
2. **Explorando a Verificação de Email Laxa do OAuth**: Os atacantes podem explorar serviços de OAuth que não verificam emails registrando-se com seu serviço e, em seguida, alterando o email da conta para o da vítima. Esse método também arrisca o acesso não autorizado à conta, semelhante ao primeiro cenário, mas através de um vetor de ataque diferente.
|
||||
|
||||
### Divulgação de Segredos <a href="#e177" id="e177"></a>
|
||||
|
||||
Identificar e proteger parâmetros secretos do OAuth é crucial. Enquanto o **`client_id`** pode ser divulgado com segurança, revelar o **`client_secret`** apresenta riscos significativos. Se o `client_secret` for comprometido, os atacantes podem explorar a identidade e a confiança da aplicação para **roubar `access_tokens` de usuários** e informações privadas.
|
||||
Identificar e proteger parâmetros secretos do OAuth é crucial. Enquanto o **`client_id`** pode ser divulgado com segurança, revelar o **`client_secret`** apresenta riscos significativos. Se o `client_secret` for comprometido, os atacantes podem explorar a identidade e a confiança da aplicação para **roubar `access_tokens`** de usuários e informações privadas.
|
||||
|
||||
Uma vulnerabilidade comum surge quando as aplicações lidam erroneamente com a troca do `code` de autorização por um `access_token` no lado do cliente em vez do lado do servidor. Esse erro leva à exposição do `client_secret`, permitindo que os atacantes gerem `access_tokens` sob a aparência da aplicação. Além disso, através de engenharia social, os atacantes poderiam escalar privilégios adicionando escopos adicionais à autorização do OAuth, explorando ainda mais o status de confiança da aplicação.
|
||||
Uma vulnerabilidade comum surge quando as aplicações lidam erroneamente com a troca do `code` de autorização por um `access_token` no lado do cliente em vez do lado do servidor. Esse erro leva à exposição do `client_secret`, permitindo que os atacantes gerem `access_tokens` sob a aparência da aplicação. Além disso, através de engenharia social, os atacantes poderiam escalar privilégios adicionando escopos adicionais à autorização OAuth, explorando ainda mais o status de confiança da aplicação.
|
||||
|
||||
### Bruteforce do Client Secret
|
||||
### Força Bruta do Client Secret
|
||||
|
||||
Você pode tentar **bruteforçar o client_secret** de um provedor de serviços com o provedor de identidade para tentar roubar contas.\
|
||||
Você pode tentar **forçar a senha do client_secret** de um provedor de serviços com o provedor de identidade para tentar roubar contas.\
|
||||
A solicitação para BF pode parecer semelhante a:
|
||||
```
|
||||
POST /token HTTP/1.1
|
||||
@ -120,7 +120,7 @@ O **código de autorização deve viver apenas por algum tempo para limitar a ja
|
||||
|
||||
Se você conseguir obter o **código de autorização e usá-lo com um cliente diferente, então você pode assumir outras contas**.
|
||||
|
||||
### Caminhos Felizes, XSS, Iframes & Post Messages para vazar valores de código & estado
|
||||
### Caminhos Felizes, XSS, Iframes & Mensagens Post para vazar valores de código & estado
|
||||
|
||||
[**Verifique este post**](https://labs.detectify.com/writeups/account-hijacking-using-dirty-dancing-in-sign-in-oauth-flows/#gadget-2-xss-on-sandbox-third-party-domain-that-gets-the-url)
|
||||
|
||||
@ -153,18 +153,18 @@ https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-unauthenticat
|
||||
|
||||
Como [**mencionado neste artigo**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts), fluxos OAuth que esperam receber o **token** (e não um código) podem ser vulneráveis se não verificarem se o token pertence ao aplicativo.
|
||||
|
||||
Isso ocorre porque um **atacante** poderia criar um **aplicativo que suporta OAuth e login com Facebook** (por exemplo) em seu próprio aplicativo. Então, uma vez que uma vítima faça login com Facebook no **aplicativo do atacante**, o atacante poderia obter o **token OAuth do usuário dado ao seu aplicativo e usá-lo para fazer login no aplicativo OAuth da vítima usando o token do usuário da vítima**.
|
||||
Isso ocorre porque um **atacante** pode criar uma **aplicação que suporta OAuth e login com Facebook** (por exemplo) em sua própria aplicação. Então, uma vez que uma vítima faça login com Facebook na **aplicação do atacante**, o atacante pode obter o **token OAuth do usuário dado à sua aplicação e usá-lo para fazer login na aplicação OAuth da vítima usando o token do usuário da vítima**.
|
||||
|
||||
> [!CAUTION]
|
||||
> Portanto, se o atacante conseguir fazer com que o usuário acesse seu próprio aplicativo OAuth, ele poderá assumir a conta da vítima em aplicativos que esperam um token e não verificam se o token foi concedido ao ID do seu aplicativo.
|
||||
> Portanto, se o atacante conseguir fazer com que o usuário acesse sua própria aplicação OAuth, ele poderá assumir a conta da vítima em aplicações que esperam um token e não verificam se o token foi concedido ao ID do seu aplicativo.
|
||||
|
||||
### Dois links & cookie <a href="#bda5" id="bda5"></a>
|
||||
|
||||
De acordo com [**este artigo**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f), era possível fazer com que uma vítima abrisse uma página com um **returnUrl** apontando para o host do atacante. Essa informação seria **armazenada em um cookie (RU)** e em um **passo posterior** o **prompt** **perguntaria** ao **usuário** se ele deseja conceder acesso ao host do atacante.
|
||||
De acordo com [**este artigo**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f), era possível fazer uma vítima abrir uma página com um **returnUrl** apontando para o host do atacante. Essa informação seria **armazenada em um cookie (RU)** e em um **passo posterior** o **prompt** **perguntaria** ao **usuário** se ele deseja dar acesso a esse host do atacante.
|
||||
|
||||
Para contornar esse prompt, era possível abrir uma aba para iniciar o **fluxo Oauth** que definiria esse cookie RU usando o **returnUrl**, fechar a aba antes que o prompt fosse exibido e abrir uma nova aba sem esse valor. Assim, o **prompt não informaria sobre o host do atacante**, mas o cookie seria definido para ele, então o **token seria enviado para o host do atacante** na redireção.
|
||||
Para contornar esse prompt, era possível abrir uma aba para iniciar o **fluxo Oauth** que configuraria esse cookie RU usando o **returnUrl**, fechar a aba antes que o prompt fosse exibido e abrir uma nova aba sem esse valor. Assim, o **prompt não informaria sobre o host do atacante**, mas o cookie seria configurado para ele, então o **token seria enviado para o host do atacante** na redireção.
|
||||
|
||||
### Bypass de Interação com o Prompt <a href="#bda5" id="bda5"></a>
|
||||
### Bypass de Interação do Prompt <a href="#bda5" id="bda5"></a>
|
||||
|
||||
Como explicado em [**este vídeo**](https://www.youtube.com/watch?v=n9x7_J_a_7Q), algumas implementações de OAuth permitem indicar o parâmetro **`prompt`** GET como None (**`&prompt=none`**) para **evitar que os usuários sejam solicitados a confirmar** o acesso concedido em um prompt na web se já estiverem logados na plataforma.
|
||||
|
||||
@ -187,37 +187,59 @@ Este [**post de blog**](https://blog.voorivex.team/oauth-non-happy-path-to-ato)
|
||||
|
||||
1. A vítima acessa a página da web do atacante
|
||||
2. A vítima abre o link malicioso e um opener inicia o fluxo OAuth do Google com `response_type=id_token,code&prompt=none` como parâmetros adicionais usando como **referenciador o site do atacante**.
|
||||
3. No opener, após o provedor autorizar a vítima, ele a envia de volta para o valor do parâmetro `redirect_uri` (web da vítima) com código 30X que ainda mantém o site do atacante no referer.
|
||||
3. No opener, após o provedor autorizar a vítima, ele os envia de volta para o valor do parâmetro `redirect_uri` (web da vítima) com código 30X que ainda mantém o site do atacante no referer.
|
||||
4. O **site da vítima aciona o redirecionamento aberto com base no referenciador**, redirecionando o usuário da vítima para o site do atacante, como o **`respose_type`** era **`id_token,code`**, o código será enviado de volta ao atacante no **fragmento** da URL, permitindo que ele assuma a conta do usuário via Google no site da vítima.
|
||||
|
||||
### Parâmetros SSRFs <a href="#bda5" id="bda5"></a>
|
||||
|
||||
[**Verifique esta pesquisa**](https://portswigger.net/research/hidden-oauth-attack-vectors) **Para mais detalhes sobre esta técnica.**
|
||||
|
||||
O Registro Dinâmico de Clientes no OAuth serve como um vetor menos óbvio, mas crítico para vulnerabilidades de segurança, especificamente para ataques de **Server-Side Request Forgery (SSRF)**. Este endpoint permite que servidores OAuth recebam detalhes sobre aplicativos clientes, incluindo URLs sensíveis que podem ser exploradas.
|
||||
O Registro Dinâmico de Clientes no OAuth serve como um vetor menos óbvio, mas crítico, para vulnerabilidades de segurança, especificamente para ataques de **Server-Side Request Forgery (SSRF)**. Este endpoint permite que servidores OAuth recebam detalhes sobre aplicações clientes, incluindo URLs sensíveis que podem ser exploradas.
|
||||
|
||||
**Pontos Chave:**
|
||||
|
||||
- O **Registro Dinâmico de Clientes** é frequentemente mapeado para `/register` e aceita detalhes como `client_name`, `client_secret`, `redirect_uris` e URLs para logotipos ou Conjuntos de Chaves Web JSON (JWKs) via solicitações POST.
|
||||
- Este recurso adere às especificações estabelecidas em **RFC7591** e **OpenID Connect Registration 1.0**, que incluem parâmetros potencialmente vulneráveis a SSRF.
|
||||
- O processo de registro pode inadvertidamente expor servidores a SSRF de várias maneiras:
|
||||
- **`logo_uri`**: Uma URL para o logotipo do aplicativo cliente que pode ser buscada pelo servidor, acionando SSRF ou levando a XSS se a URL for mal manipulada.
|
||||
- **`jwks_uri`**: Uma URL para o documento JWK do cliente, que se maliciosamente elaborado, pode fazer com que o servidor faça solicitações externas a um servidor controlado pelo atacante.
|
||||
- O **Registro Dinâmico de Clientes** é frequentemente mapeado para `/register` e aceita detalhes como `client_name`, `client_secret`, `redirect_uris` e URLs para logotipos ou Conjuntos de Chaves Web JSON (JWKs) via requisições POST.
|
||||
- Este recurso adere às especificações estabelecidas na **RFC7591** e **OpenID Connect Registration 1.0**, que incluem parâmetros potencialmente vulneráveis ao SSRF.
|
||||
- O processo de registro pode inadvertidamente expor servidores ao SSRF de várias maneiras:
|
||||
- **`logo_uri`**: Uma URL para o logotipo da aplicação cliente que pode ser buscada pelo servidor, acionando SSRF ou levando a XSS se a URL for mal manipulada.
|
||||
- **`jwks_uri`**: Uma URL para o documento JWK do cliente, que se maliciosamente elaborado, pode fazer com que o servidor faça requisições externas para um servidor controlado pelo atacante.
|
||||
- **`sector_identifier_uri`**: Referencia um array JSON de `redirect_uris`, que o servidor pode buscar, criando uma oportunidade de SSRF.
|
||||
- **`request_uris`**: Lista as URIs de solicitação permitidas para o cliente, que podem ser exploradas se o servidor buscar essas URIs no início do processo de autorização.
|
||||
- **`request_uris`**: Lista as URIs de requisição permitidas para o cliente, que podem ser exploradas se o servidor buscar essas URIs no início do processo de autorização.
|
||||
|
||||
**Estratégia de Exploração:**
|
||||
|
||||
- SSRF pode ser acionado registrando um novo cliente com URLs maliciosas em parâmetros como `logo_uri`, `jwks_uri` ou `sector_identifier_uri`.
|
||||
- Embora a exploração direta via `request_uris` possa ser mitigada por controles de lista branca, fornecer um `request_uri` pré-registrado e controlado pelo atacante pode facilitar SSRF durante a fase de autorização.
|
||||
- O SSRF pode ser acionado registrando um novo cliente com URLs maliciosas em parâmetros como `logo_uri`, `jwks_uri` ou `sector_identifier_uri`.
|
||||
- Embora a exploração direta via `request_uris` possa ser mitigada por controles de lista branca, fornecer um `request_uri` pré-registrado e controlado pelo atacante pode facilitar o SSRF durante a fase de autorização.
|
||||
|
||||
## Condições de Corrida dos provedores OAuth
|
||||
|
||||
Se a plataforma que você está testando é um provedor OAuth [**leia isso para testar possíveis Condições de Corrida**](race-condition.md).
|
||||
|
||||
## Ataque de Reivindicações Mutáveis
|
||||
|
||||
No OAuth, o campo sub identifica exclusivamente um usuário, mas seu formato varia de acordo com o Servidor de Autorização. Para padronizar a identificação do usuário, alguns clientes usam e-mails ou identificadores de usuário. No entanto, isso é arriscado porque:
|
||||
|
||||
- Alguns Servidores de Autorização não garantem que essas propriedades (como e-mail) permaneçam imutáveis.
|
||||
- Em certas implementações—como **"Login com Microsoft"**—o cliente depende do campo de e-mail, que é **controlado pelo usuário no Entra ID** e não verificado.
|
||||
- Um atacante pode explorar isso criando sua própria organização Azure AD (por exemplo, doyensectestorg) e usá-la para realizar um login no Microsoft.
|
||||
- Embora o Object ID (armazenado em sub) seja imutável e seguro, a dependência de um campo de e-mail mutável pode permitir uma tomada de conta (por exemplo, sequestrando uma conta como victim@gmail.com).
|
||||
|
||||
## Ataque de Confusão de Cliente
|
||||
|
||||
Em um **Ataque de Confusão de Cliente**, uma aplicação que usa o Fluxo Implícito do OAuth falha em verificar se o token de acesso final é especificamente gerado para seu próprio ID de Cliente. Um atacante configura um site público que usa o Fluxo Implícito do OAuth do Google, enganando milhares de usuários para fazer login e, assim, coletando tokens de acesso destinados ao site do atacante. Se esses usuários também tiverem contas em outro site vulnerável que não valida o ID do Cliente do token, o atacante pode reutilizar os tokens coletados para se passar pelas vítimas e assumir suas contas.
|
||||
|
||||
## Ataque de Atualização de Escopo
|
||||
|
||||
O tipo **Authorization Code Grant** envolve comunicação segura de servidor para servidor para transmitir dados do usuário. No entanto, se o **Servidor de Autorização** confiar implicitamente em um parâmetro de escopo na Solicitação de Token de Acesso (um parâmetro não definido na RFC), uma aplicação maliciosa poderia atualizar os privilégios de um código de autorização solicitando um escopo mais alto. Após o **Token de Acesso** ser gerado, o **Servidor de Recursos** deve verificá-lo: para tokens JWT, isso envolve verificar a assinatura JWT e extrair dados como client_id e scope, enquanto para tokens de string aleatória, o servidor deve consultar o Servidor de Autorização para recuperar os detalhes do token.
|
||||
|
||||
## Sequestro de Esquema de Redirecionamento
|
||||
|
||||
Em implementações móveis de OAuth, os aplicativos usam **esquemas URI personalizados** para receber redirecionamentos com Códigos de Autorização. No entanto, porque vários aplicativos podem registrar o mesmo esquema em um dispositivo, a suposição de que apenas o cliente legítimo controla o URI de redirecionamento é violada. No Android, por exemplo, um URI de Intent como `com.example.app://` oauth é capturado com base no esquema e filtros opcionais definidos no intent-filter de um aplicativo. Como a resolução de intent do Android pode ser ampla—especialmente se apenas o esquema for especificado—um atacante pode registrar um aplicativo malicioso com um intent filter cuidadosamente elaborado para sequestrar o código de autorização. Isso pode **permitir uma tomada de conta** seja através da interação do usuário (quando vários aplicativos são elegíveis para lidar com a intent) ou por meio de técnicas de bypass que exploram filtros excessivamente específicos, conforme detalhado pelo fluxograma de avaliação da Ostorlab.
|
||||
|
||||
## Referências
|
||||
|
||||
- [**https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1**](https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1)
|
||||
- [**https://portswigger.net/research/hidden-oauth-attack-vectors**](https://portswigger.net/research/hidden-oauth-attack-vectors)
|
||||
- [**https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html**](https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@ -27,9 +27,9 @@ Essa vulnerabilidade na verdade vem de uma vulnerabilidade que um pesquisador en
|
||||
|
||||
## Injeção de Emoji
|
||||
|
||||
Back-ends se comportam de forma estranha quando **recebem emojis**. Isso aconteceu em [**este relato**](https://medium.com/@fpatrik/how-i-found-an-xss-vulnerability-via-using-emojis-7ad72de49209) onde o pesquisador conseguiu realizar um XSS com um payload como: `💋img src=x onerror=alert(document.domain)//💛`
|
||||
Back-ends se comportam de forma estranha quando **recebem emojis**. Isso aconteceu em [**este relato**](https://medium.com/@fpatrik/how-i-found-an-xss-vulnerability-via-using-emojis-7ad72de49209) onde o pesquisador conseguiu alcançar um XSS com um payload como: `💋img src=x onerror=alert(document.domain)//💛`
|
||||
|
||||
Neste caso, o erro foi que o servidor, após remover os caracteres maliciosos, **converteu a string UTF-8 de Windows-1252 para UTF-8** (basicamente, a codificação de entrada e a conversão de codificação não coincidiram). Então, isso não dá um < apropriado, apenas um unicode estranho: `‹`\
|
||||
Neste caso, o erro foi que o servidor, após remover os caracteres maliciosos, **converteu a string UTF-8 de Windows-1252 para UTF-8** (basicamente, a codificação de entrada e a conversão de codificação não coincidiram). Então, isso não dá um < adequado, apenas um unicode estranho: `‹`\
|
||||
``Então, eles pegaram essa saída e **converteram novamente agora de UTF-8 para ASCII**. Isso **normalizou** o `‹` para `<`, assim é como a exploração poderia funcionar nesse sistema.\
|
||||
Isso é o que aconteceu:
|
||||
```php
|
||||
@ -42,9 +42,23 @@ $str = iconv("UTF-8", "ASCII//TRANSLIT", $str);
|
||||
|
||||
echo "String: " . $str;
|
||||
```
|
||||
Listas de Emoji:
|
||||
Emoji lists:
|
||||
|
||||
- [https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv](https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv)
|
||||
- [https://unicode.org/emoji/charts-14.0/full-emoji-list.html](https://unicode.org/emoji/charts-14.0/full-emoji-list.html)
|
||||
|
||||
## Windows Melhor Ajuste/Pior Ajuste
|
||||
|
||||
Como explicado em **[este ótimo post](https://blog.orange.tw/posts/2025-01-worstfit-unveiling-hidden-transformers-in-windows-ansi/)**, o Windows possui um recurso chamado **Melhor Ajuste** que irá **substituir caracteres unicode** que não podem ser exibidos em modo ASCII por um semelhante. Isso pode levar a **comportamentos inesperados** quando o backend está **esperando um caractere específico** mas recebe um diferente.
|
||||
|
||||
É possível encontrar caracteres de melhor ajuste em **[https://worst.fit/mapping/](https://worst.fit/mapping/)**.
|
||||
|
||||
Como o Windows geralmente converte strings unicode em strings ascii como uma das últimas partes da execução (geralmente indo de uma API com sufixo "W" para uma API com sufixo "A" como `GetEnvironmentVariableA` e `GetEnvironmentVariableW`), isso permitiria que atacantes contornassem proteções enviando caracteres unicode que seriam convertidos por último em caracteres ASCII que realizariam ações inesperadas.
|
||||
|
||||
No post do blog, são propostos métodos para contornar vulnerabilidades corrigidas usando uma **lista negra de caracteres**, explorar **traversais de caminho** usando [caracteres mapeados para “/“ (0x2F)](https://worst.fit/mapping/#to%3A0x2f) e [caracteres mapeados para “\“ (0x5C)](https://worst.fit/mapping/#to%3A0x5c) ou até mesmo contornar proteções de escape de shell como `escapeshellarg` do PHP ou `subprocess.run` do Python usando uma lista, isso foi feito, por exemplo, usando **aspas duplas em largura total (U+FF02)** em vez de aspas duplas, de modo que no final o que parecia ser 1 argumento foi transformado em 2 argumentos.
|
||||
|
||||
**Note que para um aplicativo ser vulnerável, ele precisa usar APIs do Windows "W" mas acabar chamando uma API do Windows "A", então o "Melhor ajuste" da string unicode é criado.**
|
||||
|
||||
**Várias vulnerabilidades descobertas não serão corrigidas, pois as pessoas não concordam sobre quem deve corrigir esse problema.**
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user