Vulnerabilidade crítica no BankID sueco expõe dados do usuário

O BankID sueco é uma forma de identificação digital usada pela maioria, senão por todos os residentes suecos, para autenticação em vários serviços, tais como: provedores de Internet, serviços bancários on-line, sites de apostas e, especialmente, sites governamentais.

Morando na Suécia e com a mentalidade hacker sempre fervilhando em meu cérebro, decidi que seria um campo muito interessante para fazer pesquisas em segurança.

Neste post apresentarei uma nova vulnerabilidade que encontrei presente na maioria dos provedores de serviços suecos devido a uma implementação insegura do protocolo de autenticação do BankID.

Abordarei brevemente como funciona esse protocolo, como é uma configuração vulnerável, como explorá-la, como remediá-la e, no final, o que esses tipos de ataques significam para a implementação geral de eIDs.

O protocolo de autenticação BankID

BankID é um serviço que se instala no dispositivo do usuário e é obtido mediante solicitação a um banco sueco, desde que você possua um persunnumer sueco, um código fiscal pessoal. O aplicativo é instalado no dispositivo do usuário e conectado ao seu código fiscal, vinculando essencialmente sua identidade a tal aplicativo. Muitas vezes, é assim que os sistemas de identificação eletrônica funcionam: um terceiro autorizado e confiável pelo governo distribui um software que está vinculado a um indivíduo específico e, em seguida, os serviços se integram ao fornecedor desse software para permitir que seus usuários se autentiquem em seus plataforma, um modelo de confiança compartilhada que permite que os serviços autentiquem facilmente as pessoas.

O BankID não é diferente e fornece documentação para tais serviços, que doravante serão denominados Relying Party (RP), para que possam integrar facilmente seu fluxo de autenticação com o BankID. https://www.bankid.com/en/utvecklare/guider/teknisk-integrationsguide/rp-introduktion .

Com o BankID dois fluxos principais são usados para autenticar um usuário:

• Autenticar no mesmo dispositivo

• Autenticar em outro dispositivo

  
  

Iremos revisitar esses dois em breve, no entanto, ambos os fluxos começam com o RP enviando uma solicitação à API do BankID para iniciar um pedido de autenticação. Nesta pós-requisição o RP deve especificar o parâmetro endUserIp , que contém o IP do usuário que está tentando efetuar login, isso será importante posteriormente no relatório.

O endpoint da API /auth responderá com algo assim:

 HTTP/1.1 200 OK Content-Type: application/json { "orderRef":"131daac9-16c6-4618-beb0-365768f37288", "autoStartToken":"7c40b5c9-fa74-49cf-b98c-bfe651f9a7c6", "qrStartToken":"67df3917-fa0d-44e5-b327-edcc928297f8", "qrStartSecret":"d28db9a7-4cde-429e-a983-359be676944c" }

• orderRef é um identificador que o RP pode usar no endpoint /collect para verificar o status de autenticação e posteriormente buscar as informações do usuário necessárias daquela pessoa
• autoStartToken é um token usado pelo RP para criar um link direto que, quando clicado, abrirá o aplicativo BankID e solicitará que o usuário se autentique ( isso será muito importante )

qrStartToken e qrStartSecret serão abordados abaixo, mas não são estritamente importantes para a pesquisa de segurança realizada.

Além do IP do usuário, um RP pode especificar mais parâmetros para o pedido de autenticação, incluindo texto a ser exibido na aplicação BankID e requisitos de autenticação .

Dentre os requisitos de autenticação, os que este post focará são as chamadas políticas de certificados , que permitem ao RP comunicar ao BankID qual dos dois fluxos foi escolhido pelo usuário.

Autenticação no mesmo dispositivo

Quando um usuário opta por ser autenticado usando BankID no mesmo dispositivo, o RP usa o autoStartToken para criar um link direto semelhante a: bankid:///?autostarttoken=7c40b5c9-fa74-49cf-b98c-bfe651f9a7c6&redirect=https://service.com/login . Esse link direto é então capturado pelo sistema operacional do usuário e entregue ao aplicativo BankID.

Ao investigar esse fluxo, uma vulnerabilidade de Open Redirect foi encontrada, pois não há validação do parâmetro redirect por parte do BankID. Explicarei por que esse bug adicional torna o ataque de sequestro de sessão ainda mais poderoso posteriormente.

Autenticação em outro dispositivo

Quando um usuário opta por ser autenticado usando BankID em outro dispositivo, o RP usa qrStartToken e qrStartSecret para gerar um código QR dinâmico (buscando os dados do próximo quadro do endpoint /collect acima mencionado) que pode ser verificado pelo usuário usando seu Mobile BankID aplicativo.

Políticas de Certificado

Estes DEVEM ser especificados pelo RP ao iniciar um pedido de autenticação, eles permitem que o BankID rejeite uma tentativa de autenticação se o fluxo não corresponder, a fim de mitigar o phishing. Por exemplo, se o utilizador escolher “autenticação no mesmo dispositivo”, o RP deverá comunicar isso ao BankID para que se a autenticação for tentada num Mobile BankID e/ou utilizando o código QR, a aplicação possa rejeitar isso.

Além disso, uma vez concluída a autenticação, o RP pode buscar o ipAddress que foi usado para abrir a aplicação do BankID a partir do endpoint da API /collect . Isso DEVE então ser verificado em relação ao endereço IP do usuário no RP caso ele tenha escolhido “autenticação no mesmo dispositivo”.

As políticas de certificado, juntamente com o ipAddress DEVEM ser usadas para garantir que o fluxo de autenticação não possa ser adulterado.

No entanto, enquanto essas medidas de segurança estão em vigor, o BankID não consegue descrever a importância delas e não as implementa corretamente, mesmo no exemplo de implementação fornecido! https://github.com/BankID/SampleCode

O bug de fixação de sessão

Então, o que acontece quando este protocolo não é implementado de forma segura?

Quando vi pela primeira vez o link direto bankid:/// estava navegando nos formulários de inscrição na universidade, que podem ser acessados fazendo login com o BankID. A princípio pensei: o que acontece se eu enviar esse deep link para alguém? Então enviei para um amigo meu que clicou nele, e para minha surpresa depois que ele abriu o BankID, eu tinha na minha frente todas as suas inscrições universitárias!

Foi quando comecei a pesquisar a API do BankID, implementei meu próprio RP e aprendi tudo o que acabei de descrever.

Após algumas semanas de pesquisa, desenvolvi um script que automatizava a captura do link direto bankid:/// para mais de 30 RPs, o script iniciaria um servidor web e criaria um caminho para cada serviço, quando um usuário visitasse o link para um serviço específico, o script buscaria um novo link e redirecionaria o usuário para ele. Isso faria com que o dispositivo do usuário abrisse o aplicativo BankID e, após a autenticação, eu seria autenticado no lugar deles.

Consegui fazer isso porque:

• Os RPs não enviaram as políticas de certificado para o BankID, possibilitando que eu buscasse um link direto e o retransmitisse para um aplicativo Mobile BankID

• Os RPs não compararam o endereço IP que solicitou o link com o endereço IP que completou a autenticação

• Os RPs forneceram o link mesmo quando a opção “autenticar em outro dispositivo” foi escolhida

  
  

O que levou à vulnerabilidade de fixação de sessão.

O ataque

Vamos imaginar um serviço vulnerável chamado AmazingSevice AB, eles implementaram o fluxo BankID seguindo o código de exemplo fornecido e estão hospedando tal implementação em https://amazingservice.se/login/bankid .

Um agente de ameaça está interessado nos dados do usuário armazenados na AmazingSevice AB e tem sua vítima à vista. Ele simplesmente teria que automatizar a captura do link bankid:/// , hospedá-lo em seu servidor e, em seguida, enviar o link para seu servidor malicioso para suas vítimas. Depois de escolher sua preferência de entrega de phishing (SMS, e-mail, etc.), ele incorporará o link na mensagem se passando por AmazingSevice AB e solicitando que a vítima faça login.

Tal invasão de conta envolve muito pouca engenharia social porque, assim que a vítima clica no link, ela é imediatamente solicitada a abrir o BankID, deixando o “território desconhecido” do site do invasor para uma interface muito mais familiar, o BankID. Além disso, a solicitação de autenticação que a vítima veria no aplicativo BankID é solicitada pela AmazingSevice AB, impossibilitando a detecção de comportamento fraudulento.

Depois que a vítima se autentica, a sessão do invasor é autenticada na conta da vítima, a vítima pode ser enganada ainda mais explorando a vulnerabilidade Open Redirect presente no BankID, permitindo ao invasor especificar o parâmetro redirect como https://amazingservice.se/login/bankid . Isso levaria a vítima a ser redirecionada para o site legítimo do serviço, deixando-a simplesmente pensando que a autenticação não foi bem-sucedida.

Demonstração

Não pude usar uma das empresas para as quais relatei, por motivos óbvios, então, em vez disso, a demonstração mostra que o serviço de demonstração do BankID é vulnerável a isso!

No canto direito está a visão da vítima recebendo o link, aqui é simulada visitando o site do invasor. Assim que a vítima visita o link, o servidor do invasor abre o navegador headless e extrai o link bankid:/// que é então retransmitido para o telefone da vítima. No aplicativo do BankID, você pode ver “Test av BankID”, que é a origem legítima do site de demonstração do BankID. Além disso, no início do vídeo, uma VPN é ativada para verificar se nenhuma verificação de endereço IP está sendo realizada durante a autenticação. Ao final, é possível perceber que no laptop do atacante ele está logado como vítima (Johan Johansson).

O impacto

O bug de fixação de sessão leva ao controle de conta com 1 clique em qualquer aplicativo que use o Swedish BankID como provedor de autenticação e tenha implementado incorretamente (ou não) políticas de certificado e verificações ipAddress . Isto é muito grave porque muitas vezes os serviços que utilizam o BankID para autenticar os seus utilizadores têm acesso a dados e ações bastante sensíveis. Mais de 30 aplicativos foram considerados vulneráveis a esse ataque, e o maior número possível foi contatado, resultando em 11 relatórios de recompensas de bugs aceitos nas principais plataformas.

Um dos serviços para os quais relatei esta vulnerabilidade conseguiu me colocar em contato com o CSIRT nacional da Suécia, devido à extensão e gravidade do problema. As palestras acabaram de começar, então se você quiser ficar atualizado, siga-me no Twitter (X) @m4st3rspl1nt3r

Correção

Se você está procurando um exemplo de como é uma implementação segura da API BankID RP, criei uma que você pode usar como uma biblioteca Golang ou personalizar e implantar como um microsserviço. Você pode achar aquilo aqui .

Resposta do BankID

A maioria dos serviços afectados, especialmente aqueles com BBPs e VDPs, foram bastante receptivos e rápidos na resposta ao meu relatório. No entanto, a resposta do BankID foi um pouco diferente. No único e-mail que recebi depois de contatá-los diversas vezes por meio de vários canais, eles explicaram que estavam cientes do problema, mas que achavam que não havia muito que pudesse ser feito a respeito, a fim de manter a “facilidade de integração” para os RPs. A mitigação planejada, que infelizmente ainda requer alterações por parte dos RPs, foi comunicada a mim (mas por algum motivo não foi encontrada em nenhum lugar da documentação) como:

Um requisito adicional que o RP poderá definir é o Risco. Isto definirá o nível de risco aceitável para a transação. Se o risco da transação for superior ao limite exigido a transação será bloqueada “BAIXO” - aceitar apenas ordens de baixo risco “MODERADO” - aceitar ordens de risco baixo e moderado Se isto estiver definido. Realizaremos, entre outras coisas, a verificação de IP do nosso lado, se for fornecida pela RP. Outros parâmetros de risco que serão monitorados pelo risco, se fornecidos, são ReferDomain, userAgent e deviceIdentifier.

Além disso, um plano para corrigir a vulnerabilidade do Open Redirect também está em vigor.

Minha opinião pessoal sobre isso é que se você desenvolver e operar um provedor de autenticação tão crítico e altamente adotado, que é frequentemente usado para proteger informações muito confidenciais do usuário, você deve documentar adequadamente seus mecanismos de segurança para que os RPs possam integrá-los com segurança. Recursos de segurança opcionais são completamente inúteis, se um desenvolvedor puder economizar tempo não implementando certos recursos/parâmetros, isso é o que acontecerá e não podemos culpar o lado do RP. O BankID deve fazer o possível para transferir o máximo de recursos antifraude e de segurança para o seu lado para manter a “facilidade de integração”, mas também certificar-se de documentar adequadamente quaisquer recursos de segurança adicionais que o RP seja obrigado a implementar; nota sobre obrigatório , não opcional.

Empresa privada em perigo público

Para mim, esta vulnerabilidade é um exemplo que mostra os perigos de permitir que uma empresa privada tenha o controlo total de um sistema que é crítico para a população de um país. A razão pela qual acredito que isso seja mais sério do que apenas mais uma vulnerabilidade em uma empresa de software é que o BankID é algo usado por mais de 8,5 milhões de residentes suecos, é usado para fazer login em seu banco, seguradora, fornecedor de eletricidade e outras plataformas confidenciais que têm consequências no mundo real.

Se alguém encontrar um roubo de conta no Facebook, você poderá perder algumas fotos. Se alguém encontrar uma vulnerabilidade no provedor de eID do seu país (geralmente privado), as repercussões na vida de alguém podem ser inimagináveis.

Cada vez mais países europeus estão a adoptar identidades electrónicas e a UE está a planear lançar uma identidade electrónica própria da UE nos próximos anos (pode ler mais sobre isto aqui ).

A minha esperança é que os reguladores pressionem para que os fornecedores de identidade electrónica sejam inteiramente desenvolvidos e controlados por instituições públicas, possivelmente com a exigência de que tais sistemas sejam de código aberto e auditados regularmente em busca de falhas de segurança.

Como podemos aceitar com segurança softwares tão críticos em nossa sociedade se eles são desenvolvidos por uma empresa privada?

Mais pesquisa

Embora o tópico principal desta postagem do blog tenha sido o ataque de fixação de sessão ao BankID, descobri que muitos outros provedores de autenticação/identificação foram projetados com a mesma falha. Uma nova classe de vulnerabilidade pode ser encontrada em provedores que exigem o uso de outro dispositivo (geralmente um telefone celular) para completar o fluxo de autenticação.

A pesquisa está em andamento e em breve espero divulgar mais descobertas e uma ferramenta na qual venho trabalhando que possa ser usada para automatizar e explorar essas vulnerabilidades. Fique atento ao meu próximo tópico Fixação de sessão por design – Pesadelos de autenticação entre dispositivos

Até então, hackeie o planeta!