Endpoint API desprotegido em HAwebsso.nl

Dec 15 2022

Histórico Como alguns devem saber, trabalho como médico (clínico geral) durante o dia e como pesquisador de segurança à noite. Um dos meus objetivos no hacking ético é aprender o máximo possível para poder auditar a mim mesmo produtos, aplicativos, sites ou infraestrutura de saúde.

Prova de conceito, mostrando onde o endpoint foi encontrado e como ele vaza os dados do usuário (censurado neste vídeo)

Histórico
Como alguns devem saber, trabalho como médico (clínico geral) durante o dia e como pesquisador de segurança à noite . Um dos meus objetivos no hacking ético é aprender o máximo possível para poder auditar a mim mesmo produtos, aplicativos, sites ou infraestrutura de saúde. É realmente, realmente, seguro? Não confio em emblemas ou certificados brilhantes.

Hoje vamos dar uma olhada na segurança do Nederlandse Huisartsen Genootschap (NHG) e do Landelijke Huisartsen Vereniging (LHV). Essas são organizações profissionais para clínicos gerais (GP) na Holanda. O NHG estabelece padrões para os GPs e fornece educação e treinamento, enquanto o LHV representa os interesses dos GPs e trabalha para melhorar a qualidade e acessibilidade dos cuidados primários. Ambas as organizações desempenham papéis importantes no sistema de saúde holandês, trabalhando para garantir que os pacientes recebam cuidados de alta qualidade de seus médicos de família. No momento, temos 13 mil GPs na Holanda.

Recon, por onde começar?
E se o NHG e o LHV forem considerados vulneráveis, poderíamos impactar esses 13 mil médicos associados?

O NHG e o LHV têm muitos aplicativos on-line que permitem que os médicos façam login e interajam. Por exemplo HAweb.nl , uma comunidade online para médicos e richtlijnen.nhg.org que permite aos médicos adicionar suas notas pessoais às diretrizes profissionais.

Hoje eu apenas começo clicando no site principal do LHV.nl procurando por diferentes subdomínios e como o procedimento de login funciona .

O que a maioria dos aplicativos LHV e NHG compartilham é um método de autenticação Single Sign-On (SSO) usando o domínio hawebsso.nl . Ele aparece sempre que você tenta acessar algum aplicativo que precisa de autorização, como haweb.nl

SSO é um método de autenticação que permite aos usuários acessar vários aplicativos e serviços com um único conjunto de credenciais de login . Isso elimina a necessidade de os usuários se lembrarem e gerenciarem vários conjuntos de informações de login e pode melhorar muito a experiência e a produtividade do usuário. As organizações costumam usar o SSO para simplificar o acesso a vários sistemas e aplicativos, melhorar a segurança reduzindo o número de locais onde as credenciais do usuário são armazenadas e centralizar o controle sobre o acesso aos recursos. Além disso, o SSO pode ser integrado a outros recursos de segurança, como autenticação multifator, para fornecer uma camada adicional de proteção para sistemas e dados confidenciais.

A boa notícia é que, se hackearmos o SSO, teremos acesso a tudo. A má notícia é que a maioria dos sistemas SSO usados são peças de software fortemente testadas em batalha (sinta-se à vontade para trocar good newse bad newsnesta frase).

Boa sorte quebrando um serviço SSO comprovado em batalha.

A página de login do sistema SSO usado pelo LHV & NHG

Bônus
Um bom truque para ver rapidamente o possível escopo do sistema SSO é verificar os endpoints do OpenID , tente visitarhttps://hawebsso.nl/.well-known/openid-configuration

O sistema SSO contém dados interessantes do usuário (chamados de declarações no OpenID). Além disso, suporta muitos escopos diferentes. Por exemplo tem o escopo 'HAWeb_SSO_Scope_WaarneemApp' que dá acesso ao WaarneemApp (ferramenta utilizada para troca de turnos entre médicos).

Outra coisa que verifico rapidamente é se recebo alguma dica sobre qual sistema está sendo executado por trás do SSO. Eu olho para os cabeçalhos de resposta desta solicitação HTTP:

O SSO é executado no Microsoft IIS/10.0. Nenhuma dica para o software usado aqui.

Até aí tudo bem, nada de especial.

E quanto ao código-fonte da página de login?

A página de login faz referência a um arquivo Javascript chamado admin.js

O próximo passo é dar uma olhada no código-fonte da página de login. Há alguma pista sobre o sistema que está sendo usado para o SSO ou vemos mais alguma coisa estranha?

Admin.js
Como podemos ver, a página de login está carregando diferentes arquivos javascript, alguns para adicionar funcionalidade ao formulário de login. Nenhum dos arquivos vaza dicas sobre o sistema real usado, pode ser que esse front-end SSO seja personalizado; está envolvendo um sistema de back-end SSO alimentado por ASP.

No entanto, um dos arquivos carregados chamou minha atenção: admin.js. Sempre que vemos a palavra 'admin' ficamos ansiosos para saber mais sobre ela.

Parte do código-fonte dentro do admin.jsarquivo:

$scope.GetAdmin = function () {
        return $http({
            method: 'GET',
            url: '/api/v1/user/admin',
        }).then(function (response) {
            $scope.adminUser = response.data;
            if ($scope.adminUser.roles != null && $scope.adminUser.roles.length > 0) {
                var roles = $scope.adminUser.roles.split(",");
                $scope.permissions = {
                    admin_level_1: roles.indexOf("Admin_level_1") > -1,
                    admin_level_2: roles.indexOf("Admin_level_2") > -1,
                    allow_edit: roles.indexOf("Admin_allow_edit") > -1,
                    allow_merge: roles.indexOf("Admin_allow_merge") > -1,
                    allow_activate: roles.indexOf("Admin_allow_activate") > -1,
                    allow_deactivate: roles.indexOf("Admin_allow_deactivate") > -1,
                    allow_make_admin: roles.indexOf("Admin_level_1") > -1,
                    allow_deactivate_admin: roles.indexOf("Admin_level_1") > -1,
                    show_field_id: roles.indexOf("Admin_show_field_id") > -1,
                    show_field_firstname: roles.indexOf("Admin_show_field_firstname") > -1,
                    show_field_insertion: roles.indexOf("Admin_show_field_insertion") > -1,
                    show_field_lastname: roles.indexOf("Admin_show_field_lastname") > -1,
                    show_field_lhv_id: roles.indexOf("Admin_show_field_lhv_id") > -1,
                    show_field_nhg_id: roles.indexOf("Admin_show_field_nhg_id") > -1,
                    show_field_emailaddress: roles.indexOf("Admin_show_field_emailaddress") > -1,
                    show_field_cat_override: roles.indexOf("Admin_show_field_cat_override") > -1,
                    congres_admin: roles.indexOf("Admin_congres") > -1
                };
            }
        }).catch(function (response) {
            $scope.addMessage(response.data, response.status, response.status == 200 ? "success" : "error");
        });
    }
    
    $scope.GetAdmin();

Como sou um dos GPs com login SSO, posso fazer login e acessar esse endpoint.

Opa. O terminal retorna todos os dados do usuário conectado no momento. Incluindo um hash de senha.

O endpoint não verifica adequadamente quem o solicita e retorna todas as nossas informações de usuário . Incluindo e-mail, nome completo, hash de senha e alguns detalhes de associação.

E se atingirmos o mesmo endpoint e trocarmos /adminpor um ID, como podemos ver, eu tenho o ID 2027. Vamos ver o que acontece se tentarmos acertar o ID 15000: https://hawebsso.nl/api/v1/user/15000

O ID de usuário 15000 existe, todos os detalhes da conta são compartilhados conosco, incluindo a senha.

Agora mostramos o impacto desse endpoint, ele vaza todos os detalhes do usuário de pessoas inscritas no serviço SSO hawebsso.nl

Em termos técnicos, chamamos esse tipo de bug de IDOR ; Referências de objeto direto inseguras .

O endpoint /api/v1/user/1é um endpoint genérico que pode ser facilmente descoberto por hackers. Pode-se usar listas de palavras para endpoints de força bruta em um ativo como este, um bom exemplo é o Assetnote.io, suas listas de palavras compartilhadas . a lista de palavrashttps://wordlists-cdn.assetnote.io/data/automated/httparchive_apiroutes_2020_11_20.txtcontém esse ponto de extremidade específico com um ID que retornaria uma ocorrência.

Um exemplo de uma entrada de lista de palavras que daria um hit

Outra abordagem que o hacker pode adotar é verificar todos os arquivos javascript usados em busca de endpoints. Por exemplo , o LinkFinder faz isso para você.

Nenhuma autenticação necessária
Agora mostramos que um endpoint específico vaza os detalhes do usuário, mas requer autenticação. Alguém poderia atingir esse endpoint sem estar logado?

Abra o mesmo endpoint no modo anônimo do navegador. Nenhum cookie foi definido, não estou logado. Todos os detalhes do usuário são retornados.

A resposta é sim. Este endpoint não requer nenhum login. Em termos técnicos, agora temos outro bug, Missing Authentication for Critical Function . Abrir o endpoint em um navegador sem estar logado nos retorna todos os detalhes do usuário.

Prova de conceito de que o endpoint funciona sem estar logado (dados confidenciais censurados).

Hash de senha, como quebrá-lo?
Agora temos o hash da senha. O uso de hashes de senha reduz o impacto de um vazamento de dados, pois seria necessário quebrar o hash primeiro para recuperar a senha. No passado, hashes de senha como MD5 eram facilmente quebrados usando algo como Rainbow Tables ; listas de todos os hashes possíveis, que são calculados antecipadamente para quebrar o hash.

Hoje em dia, isso é resolvido usando algoritmos de hash mais seguros e incluindo sais.

Ao alterar minha senha para a mesma senha que eu tinha, pude confirmar que um novo hash exclusivo foi gerado. Algo que nos dá uma pista de que as Rainbow Tables podem não estar funcionando aqui (por exemplo, se incluírem um salt exclusivo por usuário).

Para testar, usei o seguinte hash para crackear (não se preocupe, é meu próprio hash, com uma senha fictícia):em1EijmR7gmSA0NC2fbbl488pWDpX6YEfPtU4BNRsu01VX9VZFRuvSBAPaaIwVe5KC0enebMfwJC1AGZVNFbRsZ+7Pa7hj718HfKfIolp/5rDgsp/52UOqawXrNGHgwCHYsd+S0gG4K+ba3zjsjg5cVXCpIrqvlJbO45DkPqZ+B/REWhOmkBdRdie76z9oWk1qp7LFa9l/4Z3TtCgucS+m0Sl66mYcWwafRZkAas5a5z15v9iweiZK4WyEbkmUFQDgAqXMAsljftoJxSP0QN/BbXUtAm0wENIGvt7PPTg7dGxdUoySbUFpmnzm/eTeCcgbEpsJhb3bwAulMVl0F3

Depois de hackear por um tempo, você pode identificar a maioria dos tipos de hash apenas olhando para ele, assim como as doenças de pele.

098f6bcd4621d373cade4e832627b4f6 - MD5 5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8 - SHA-256 $2y$12$xyq65gSoKygKl5kxKYDbjeTocAh8BcbuprbohD.kkX0PZr73pH5LC - Bcrypt

No entanto, aqui não tenho ideia de qual algoritmo de hash é usado. Depois de entrar em contato com um de meus colegas hackers éticos, disseram-me que parecia uma string codificada em base64 , decodificada com exatamente 255 bytes de comprimento.

A saída de eco | base64 — decodificar | wc-c

Sabendo de nosso reconhecimento que o ASP está sendo executado no servidor, podemos obter mais pistas da documentação fornecida pela Microsoft:https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity

Mais tarde, encontrei este blog (5 anos) sobre os diferentes algoritmos de hashhttps://andrewlock.net/exploring-the-asp-net-core-identity-passwordhasher/e achei a seguinte peça interessante:ASP.NET Core Identity Version 3: PBKDF2 with HMAC-SHA256, 128-bit salt, 256-bit subkey, 10000 iterations

Isso me dá uma dica de que o ASP usa, pronto para uso, um algoritmo de hash adequado, que eu não poderia decifrar facilmente no momento. Algumas discussões interessantes sobre PBKDF2 e o futuro podem ser lidas aqui .

Por enquanto desisti de quebrar esses hashes.

No entanto, eu adoraria aprender mais com os leitores deste blog, você consegue quebrar meu hash? Se assim for, deixe-me saber como você faria isso. O primeiro a quebrá-lo ganhará meu raro adesivo brilhante e alguns outros brindes exclusivos! Este mundo é todo sobre adesivos, como você sabe.

Conclusão
Encontramos um vazamento de dados sobre todos os e-mails e hashes de senha usados por GPs na Holanda. Este endpoint estava desprotegido e não exigia nenhuma autorização. Como é um caminho genérico, pode ser facilmente adivinhado por hackers. Além disso, a referência a esse endpoint estava oculta no admin.jsarquivo incluído na página de login, ferramentas como o LinkFinder teriam informado qualquer hacker de varredura desse endpoint específico.

Discussão
O LHV publicou uma política de divulgação responsável em seu site que me permitiu fazer esta pesquisa:https://www.lhv.nl/cvd-coordinated-vulnerability-disclosure/O que é um ótimo exemplo de como apoiar hackers éticos.

Além disso, eles tentam melhorar a segurança geral na atenção primária à saúde, desenvolvendo diretrizes sobre como lidar com vazamentos de dados . Recentemente eles publicaram sobre isso em uma das revistas lidas pelos GPs:https://www.syntheshis.nu/wp-content/uploads/2022/12/Synth-2022-03-Totaal.pdf(Holandês, página 22). Os membros associados podem visualizar esta diretriz:https://www.lhv.nl/product/praktijkwijzer-informatiebeveiliging/

No entanto, seria ótimo se todos pudessem acessar este documento , quanto mais compartilharmos, melhor poderemos combater os riscos. Na atenção básica eu trabalho com alunos, gestores de dados e muita gente que não é LHV; se eu pudesse compartilhar facilmente esses documentos que ajudariam (prefiro não compartilhar PDFs desatualizados).

Outra coisa importante é adicionar a política de divulgação responsável em todos os ativos online . Por exemplo hawebsso.nl não inclui nenhuma referência. Além disso, o site NHG.org (usando o SSO) não está compartilhando nenhuma política de divulgação responsável online . Uma coisa boa seria publicar esta política o mais rápido possível e deixar todos que trabalham na NHG confortáveis com esta boa prática; Vejohttps://www.ncsc.nl/onderwerpen/cvd-beleid/cvd-beleid-opstellenaprender como proceder como uma organização.

Uma boa proteção contra vazamentos de dados como esses é a autenticação de fator duplo (2FA), HAwebsso.nl oferece suporte a isso, mas não é ativado por padrão. Minha recomendação é ativar isso para dificultar o acesso de invasores à sua conta sempre que sua senha vazar. Também é importante não reutilizar senhas, como mostrado neste relatório quando vazadas (e quebradas) podem ser abusadas em outros serviços; enchimento de credenciais .

Como poderíamos evitar bugs como este?
Esse bug existiu por cerca de 3 anos, então é muito tempo para descobri-lo.

Existem diferentes maneiras de abordar esta questão. Um está no nível gerencial; obtenha certificações e adote os padrões da indústria.

Padrões da indústria
Atualmente, temos diferentes padrões internacionais da indústria (ou seja, ISO 27001 ) ou padrões nacionais (ou seja, NEN 7510 ) que descrevem como gerenciar a segurança da informação. Uma ótima maneira de incorporar algumas boas práticas de segurança da informação em sua organização. Implemente-o, peça a um auditor que verifique se tudo foi implementado corretamente e o marketing pode compartilhar as boas notícias de que você está seguro.

“Senhor, somos certificados pela ISO 27001, somos superseguros” — Todos os departamentos de vendas

Os certificados são bons, mas não protegem você de ser hackeado.

Como veremos hoje, nenhuma certificação impedirá que você seja hackeado. No entanto, isso não significa que não devemos fazer isso. Cada forma estruturada de melhorar a segurança é algo que vale a pena implementar.

Consultores de pen-test versus hackers éticos
Outra abordagem é realizar testes de penetração regulares; contrate uma empresa e peça para hackear você. Esse bug é bastante direto e é provável que seja detectado em um teste de penetração.

No entanto, esses testes de penetração geralmente acontecem em períodos específicos de tempo, não é um processo contínuo. Portanto, quaisquer novos bugs nos ativos lançados entre os testes de penetração podem passar despercebidos.

Uma solução para isso poderia ser criar uma comunidade de hackers éticos, usando plataformas de recompensas por bugs (como HackerOne ou BugCrowd ) e começar a investir em hackers éticos que encontram bugs em seus ativos. Temos ótimos exemplos de como criar comunidades na Holanda: Hack the Hague .

Modelagem de ameaças
Sou um grande fã do método INCLUDESNODIRT.com ; reúna um grupo de pessoas (ou seja, desenvolvedor, hacker ético, GP, proprietário do produto e oficial de privacidade), preencha o questionário e faça um brainstorm por 20 minutos. Sempre que você introduzir novos ativos, adicionar funcionalidade a um aplicativo ou fazer alterações em sua organização (ou seja, fusões e aquisições). Neste exemplo, alguém se perguntaria: “A nova funcionalidade de administrador adicionada ao hawebsso.nl está devidamente protegida contra acesso não autorizado? Se sim, explique como.”

Modelagem de ameaças para assistência médica digital

Ainda não vi o método sendo usado em produção, mas adoraria ouvir histórias de outras pessoas que já o implementaram. O que podemos aprender com isso e está realmente funcionando?

Transparência é confiança
Desde o início até o final deste relatório de bug específico, o oficial de privacidade da LHV respondeu muito bem aos meus e-mails. Ele frequentemente me enviava atualizações, o que me ajuda a ter confiança de que o impacto do bug é compreendido por todas as partes interessadas e está sendo corrigido rapidamente. Ele fez um ótimo trabalho e é um exemplo para os outros como lidar com um relatório como este, obrigado!

Em qualquer organização, transparência é confiança. Se se trata de vazamentos de dados, temos bons fluxogramas que nos ajudam a proceder e informar de forma transparente os usuários finais (como poder publicar blogs como este).

Este relatório mostra o poder da multidão, a transparência e uma política de divulgação adequada permite que todos os hackers éticos do mundo o ajudem a ficar mais seguro. Você pode aplicar esse modelo de multidão a todos os outros níveis da sua organização e alcançar seus objetivos mais rapidamente.

No final, todos nós queremos uma atenção primária à saúde melhor e mais segura amanhã e aprender com os erros cometidos no passado.

Linha
do tempo 04–12–2022 — Encontrou o bug, relatou-o ao responsável pela privacidade do LHV por e-mail
05–12–2022 — Resposta do responsável pela privacidade para confirmar o bug
06–12–2022 — Atualização do responsável pela privacidade
08–12–2022 — Atualização do oficial de privacidade: bug existe há 3 anos (desde o final de 2019), sem sinais de abuso nos logs dos últimos 2 anos
11–12–2022 — Escreveu este blog
12–12–2022 — Enviou rascunho deste blog para oficial de privacidade por e-mail
12–12–2022 — LHV & NHG informaram todos os membros sobre o vazamento de dados por e-mail; membros solicitados para redefinir sua senha.
13–12–2022 — LHV sugeriu algumas pequenas alterações
14–12–2022 — Blog publicado