hacktricks/pentesting-web/oauth-to-account-takeover.md

OAuth para Assumir o Controle da Conta

Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras maneiras de apoiar o HackTricks:

• Se você deseja ver sua empresa anunciada no HackTricks ou baixar o HackTricks em PDF Confira os PLANOS DE ASSINATURA!
• Adquira o swag oficial PEASS & HackTricks
• Descubra A Família PEASS, nossa coleção exclusiva de NFTs
• Junte-se ao 💬 grupo Discord ou ao grupo telegram ou siga-nos no Twitter 🐦 @carlospolopm.
• Compartilhe seus truques de hacking enviando PRs para os repositórios HackTricks e HackTricks Cloud.

{% embed url="https://websec.nl/" %}

Informações Básicas

OAuth oferece várias versões, com insights fundamentais acessíveis em documentação do OAuth 2.0. Esta discussão se concentra principalmente no amplamente utilizado tipo de concessão de código de autorização OAuth 2.0, fornecendo um framework de autorização que permite que um aplicativo acesse ou execute ações na conta de um usuário em outro aplicativo (o servidor de autorização).

Considere um site hipotético https://exemplo.com, projetado para mostrar todas as suas postagens em redes sociais, incluindo as privadas. Para alcançar isso, é utilizado o OAuth 2.0. https://exemplo.com solicitará sua permissão para acessar suas postagens em redes sociais. Consequentemente, uma tela de consentimento aparecerá em https://redesocial.com, detalhando as permissões solicitadas e o desenvolvedor fazendo a solicitação. Após sua autorização, https://exemplo.com ganha a capacidade de acessar suas postagens em seu nome.

É essencial compreender os seguintes componentes dentro do framework do OAuth 2.0:

• dono do recurso: Você, como usuário/entidade, autoriza o acesso ao seu recurso, como suas postagens em redes sociais.
• servidor de recursos: O servidor que gerencia solicitações autenticadas após o aplicativo ter obtido um token de acesso em nome do dono do recurso, por exemplo, https://redesocial.com.
• aplicativo cliente: O aplicativo que busca autorização do dono do recurso, como https://exemplo.com.
• servidor de autorização: O servidor que emite tokens de acesso para o aplicativo cliente após a autenticação bem-sucedida do dono do recurso e a obtenção de autorização, por exemplo, https://redesocial.com.
• client_id: Um identificador público e único para o aplicativo.
• client_secret: Uma chave confidencial, conhecida apenas pelo aplicativo e pelo servidor de autorização, usada para gerar tokens de acesso.
• response_type: Um valor que especifica o tipo de token solicitado, como código.
• escopo: O nível de acesso que o aplicativo cliente está solicitando do dono do recurso.
• redirect_uri: A URL para a qual o usuário é redirecionado após a autorização. Isso geralmente deve estar alinhado com a URL de redirecionamento pré-registrada.
• state: Um parâmetro para manter dados durante o redirecionamento do usuário para e do servidor de autorização. Sua singularidade é crítica para servir como um mecanismo de proteção CSRF.
• grant_type: Um parâmetro que indica o tipo de concessão e o tipo de token a ser retornado.
• código: O código de autorização do servidor de autorização, usado em conjunto com client_id e client_secret pelo aplicativo cliente para adquirir um token de acesso.
• access_token: O token que o aplicativo cliente usa para solicitações de API em nome do dono do recurso.
• refresh_token: Permite que o aplicativo obtenha um novo token de acesso sem solicitar novamente a permissão do usuário.

Fluxo

O fluxo real do OAuth procede da seguinte forma:

1. Você navega até https://exemplo.com e seleciona o botão "Integrar com Redes Sociais".
2. O site então envia uma solicitação para https://redesocial.com pedindo sua autorização para permitir que o aplicativo de https://exemplo.com acesse suas postagens. A solicitação é estruturada da seguinte forma:

https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123

3. Em seguida, você é apresentado com uma página de consentimento.

4. Após a sua aprovação, a Rede Social envia uma resposta para o redirect_uri com os parâmetros code e state:

https://example.com?code=uniqueCode123&state=randomString123

5. https://example.com utiliza este código, 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 às quais você consentiu:

POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}

6. Finalmente, o processo é concluído quando https://example.com utiliza seu access_token para fazer uma chamada de API para as Redes Sociais para acessar

Vulnerabilidades

Open redirect_uri

O redirect_uri é crucial para a segurança em implementações de OAuth e OpenID, pois direciona para onde os dados sensíveis, como códigos de autorização, são enviados pós-autorização. Se mal configurado, poderia permitir que atacantes redirecionassem essas solicitações para servidores maliciosos, possibilitando a tomada de controle da conta.

As técnicas de exploração variam com base na lógica de validação do servidor de autorização. Podem variar desde a correspondência estrita de caminhos até a aceitação de qualquer URL dentro do domínio ou subdiretório especificado. Métodos comuns de exploração incluem redirecionamentos abertos, travessia de caminho, exploração de regex fracos e injeção de HTML para roubo de token.

Além do redirect_uri, outros parâmetros do OAuth e OpenID como client_uri, policy_uri, tos_uri e initiate_login_uri também são suscetíveis a ataques de redirecionamento. Esses parâmetros são opcionais e seu suporte varia entre os servidores.

Para aqueles visando um servidor OpenID, o ponto de descoberta (**.well-known/openid-configuration**) frequentemente lista detalhes valiosos de configuração como registration_endpoint, request_uri_parameter_supported e "require_request_uri_registration. Esses detalhes podem auxiliar na identificação do ponto de registro e outras especificidades de configuração do servidor.

XSS na implementação de redirecionamento

Conforme mencionado neste relatório de recompensa por bugs https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html, pode ser possível que a URL de redirecionamento esteja sendo refletida na resposta do servidor após o usuário se autenticar, sendo vulnerável a XSS. Payload possível para teste:

https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>

CSRF - Manipulação inadequada do parâmetro de estado

Nas implementações do OAuth, o uso indevido ou omissão do parâmetro state pode aumentar significativamente o risco de ataques de Cross-Site Request Forgery (CSRF). Essa vulnerabilidade surge quando o parâmetro state é não utilizado, usado como um valor estático ou não validado corretamente, permitindo que os atacantes ignorem as proteções 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 tomadas de controle de conta. 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 de 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 tratamento adequado e a validação do parâmetro state são cruciais para proteger contra CSRF e garantir a segurança do fluxo do OAuth.

Pré Tomada de Conta

1. Sem Verificação de Email na Criação de Conta: Os atacantes podem criar antecipadamente uma conta usando o email da vítima. Se a vítima posteriormente usar um serviço de terceiros para fazer login, a aplicação pode inadvertidamente vincular essa conta de terceiros à conta pré-criada do atacante, resultando em acesso não autorizado.

2. Explorando a Verificação de Email Laxa do OAuth: Os atacantes podem explorar serviços OAuth que não verificam emails se registrando com seu serviço e depois alterando o email da conta para o da vítima. Este método também apresenta riscos de acesso não autorizado à conta, semelhante ao primeiro cenário, mas por meio de um vetor de ataque diferente.

Divulgação de Segredos

Identificar e proteger os 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 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, por meio de engenharia social, os atacantes poderiam escalar privilégios adicionando escopos adicionais à autorização do OAuth, explorando ainda mais o status confiável da aplicação.

Bruteforce do Client Secret

Você pode tentar fazer bruteforce no client_secret de um provedor de serviços com o provedor de identidade para tentar roubar contas.
A solicitação para o BF pode se parecer com:

POST /token HTTP/1.1
content-type: application/x-www-form-urlencoded
host: 10.10.10.10:3000
content-length: 135
Connection: close

code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=authorization_code&client_id=public_client_id&client_secret=[bruteforce]

Cabeçalho Referer vazando Código + Estado

Uma vez que o cliente tenha o código e estado, se estiver refletido dentro do cabeçalho Referer quando ele navegar para uma página diferente, então está vulnerável.

Token de Acesso Armazenado no Histórico do Navegador

Vá para o histórico do navegador e verifique se o token de acesso está salvo lá.

Código de Autorização Eterno

O código de autorização deve existir apenas por algum tempo para limitar a janela de tempo em que um atacante pode roubá-lo e usá-lo.

Token de Autorização/Atualização não vinculado ao cliente

Se você conseguir obter o código de autorização e usá-lo com um cliente diferente, então pode assumir o controle de outras contas.

Caminhos Felizes, XSS, Iframes e Mensagens Post para vazar códigos e valores de estado

Confira este post

AWS Cognito

Neste relatório de recompensa por bugs: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ você pode ver que o token que o AWS Cognito devolve ao usuário pode ter permissões suficientes para sobrescrever os dados do usuário. Portanto, se você puder alterar o e-mail do usuário por um e-mail de usuário diferente, você pode assumir outras contas.

# Read info of the user
aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...]

# Change email address
aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ[...] --user-attributes Name=email,Value=imaginary@flickr.com
{
"CodeDeliveryDetailsList": [
{
"Destination": "i***@f***.com",
"DeliveryMedium": "EMAIL",
"AttributeName": "email"
}
]
}

Abusando de tokens de outros aplicativos

Como mencionado neste artigo, os fluxos do 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 fazer login com o Facebook (por exemplo) em seu próprio aplicativo. Em seguida, uma vez que uma vítima faz login com o Facebook no aplicativo do atacante, o atacante poderia obter o token OAuth do usuário fornecido ao seu aplicativo e usá-lo para fazer login no aplicativo OAuth da vítima usando o token de usuário da vítima.

{% hint style="danger" %} Portanto, se o atacante conseguir fazer com que o usuário acesse seu próprio aplicativo OAuth, ele poderá assumir o controle da conta da vítima em aplicativos que esperam um token e não verificam se o token foi concedido ao ID de seu aplicativo. {% endhint %}

Dois links e cookie

De acordo com este artigo, era possível fazer com que uma vítima abrisse uma página com um returnUrl apontando para o host do atacante. Essas informações seriam armazenadas em um cookie (RU) e em uma etapa posterior, o prompt perguntaria ao usuário se ele deseja conceder acesso a esse host do atacante.

Para contornar esse prompt, era possível abrir uma guia para iniciar o fluxo OAuth que definiria esse cookie RU usando o returnUrl, fechar a guia antes que o prompt fosse exibido e abrir uma nova guia sem esse valor. Em seguida, o prompt não informará sobre o host do atacante, mas o cookie será definido para ele, então o token será enviado para o host do atacante na redireção.

Parâmetros SSRFs

Confira esta pesquisa para mais detalhes sobre essa 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 explorados.

Pontos-chave:

• O Registro Dinâmico de Clientes geralmente é 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 segue as especificações estabelecidas em 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: Um URL para o logotipo do aplicativo cliente que pode ser buscado pelo servidor, desencadeando SSRF ou levando a XSS se o URL for manipulado incorretamente.
• jwks_uri: Um URL para o documento JWK do cliente, que se for maliciosamente elaborado, pode fazer com que o servidor faça solicitações de saída para um servidor controlado pelo atacante.
• sector_identifier_uri: Faz referência a um array JSON de redirect_uris, que o servidor pode buscar, criando uma oportunidade de SSRF.
• request_uris: Lista URIs de solicitação permitidos para o cliente, que podem ser explorados se o servidor buscar esses URIs no início do processo de autorização.

Estratégia de exploração:

• O SSRF pode ser acionado registrando um novo cliente com URLs maliciosos 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 controlado pelo atacante pode facilitar o SSRF durante a fase de autorização.