Point de terminaison API non protégé sur HAwebsso.nl

Dec 15 2022

ContexteComme certains le savent peut-être, je travaille comme médecin (médecin généraliste) le jour et comme chercheur en sécurité la nuit. L'un de mes objectifs en matière de piratage éthique est d'en apprendre le plus possible afin de pouvoir moi-même auditer des produits, des applications, des sites Web ou des infrastructures de santé.

Preuve de concept, montrant où le point de terminaison a été trouvé et comment il fuit les données utilisateur (censuré dans cette vidéo)

Contexte
Comme certains le savent peut-être, je travaille comme médecin (médecin généraliste) le jour et comme chercheur en sécurité la nuit . L'un de mes objectifs en matière de piratage éthique est d'en apprendre le plus possible afin de pouvoir moi-même auditer des produits, des applications, des sites Web ou des infrastructures de santé. Est-ce vraiment, vraiment sécurisé ? Je ne fais pas confiance aux emblèmes brillants ou aux certificats.

Aujourd'hui, nous allons nous pencher sur la sécurité de la Nederlandse Huisartsen Genootschap (NHG) et de la Landelijke Huisartsen Vereniging (LHV). Ce sont des organisations professionnelles pour les médecins généralistes (GP) aux Pays-Bas. Le NHG établit des normes pour les médecins généralistes et dispense une éducation et une formation, tandis que le LHV représente les intérêts des médecins généralistes et s'efforce d'améliorer la qualité et l'accessibilité des soins primaires. Les deux organisations jouent un rôle important dans le système de santé néerlandais, s'efforçant de garantir que les patients reçoivent des soins de haute qualité de la part de leur médecin généraliste. En ce moment, nous avons 13 000 généralistes aux Pays-Bas.

Recon, par où commencer ?
Et si le NHG et le LHV sont jugés vulnérables, pourrions-nous avoir un impact sur ces 13 000 médecins associés ?

Le NHG et le LHV ont tous deux de nombreuses applications en ligne qui permettent aux médecins de se connecter et d'interagir avec. Par exemple HAweb.nl , une communauté en ligne pour les médecins et richtlijnen.nhg.org qui permet aux médecins d'ajouter leurs notes personnelles aux directives professionnelles.

Aujourd'hui, je commence simplement par cliquer sur le site Web principal de LHV.nl à la recherche de différents sous-domaines et du fonctionnement de la procédure de connexion .

Ce que la plupart des applications LHV et NHG partagent est une méthode d'authentification Single Sign-On (SSO) utilisant le domaine hawebsso.nl . Il apparaît chaque fois que vous essayez d'accéder à une application qui nécessite une autorisation, comme haweb.nl

SSO est une méthode d'authentification qui permet aux utilisateurs d'accéder à plusieurs applications et services avec un seul ensemble d'informations d'identification de connexion . Cela élimine le besoin pour les utilisateurs de mémoriser et de gérer plusieurs ensembles d'informations de connexion, et peut grandement améliorer l'expérience utilisateur et la productivité. Les organisations utilisent souvent l'authentification unique pour rationaliser l'accès à plusieurs systèmes et applications, améliorer la sécurité en réduisant le nombre d'endroits où les informations d'identification des utilisateurs sont stockées et centraliser le contrôle de l'accès aux ressources. De plus, SSO peut être intégré à d'autres fonctionnalités de sécurité, telles que l'authentification multifacteur, pour fournir une couche de protection supplémentaire pour les systèmes et les données sensibles.

La bonne nouvelle est que si nous piratons le SSO, nous aurons accès à tout. La mauvaise nouvelle que la plupart des systèmes SSO utilisés sont des logiciels fortement testés au combat (n'hésitez pas à échanger good newset bad newsdans cette phrase).

Bonne chance pour briser un service SSO éprouvé au combat.

La page de connexion du système SSO utilisé par le LHV & NHG

Bonus
Une bonne astuce pour voir rapidement la portée possible du système SSO est de vérifier les points de terminaison OpenID , essayez de visiterhttps://hawebsso.nl/.well-known/openid-configuration

Le système SSO contient des données utilisateur intéressantes (appelées revendications dans OpenID). De plus, il prend en charge de nombreuses portées différentes. Par exemple, il a la portée 'HAWeb_SSO_Scope_WaarneemApp' qui donne accès à WaarneemApp (un outil utilisé pour échanger des quarts de travail entre médecins).

Une autre chose que je vérifie rapidement est si j'obtiens des indices sur le système qui s'exécute derrière le SSO. Je regarde les en-têtes de réponse de cette requête HTTP :

Le SSO fonctionne sur Microsoft IIS/10.0. Aucune allusion au logiciel utilisé ici.

Jusqu'ici tout va bien, rien de spécial.

Qu'en est-il du code source de la page de connexion ?

La page de connexion fait référence à un fichier Javascript nommé admin.js

L'étape suivante consiste à jeter un œil au code source de la page de connexion. Y a-t-il des indices sur le système utilisé pour le SSO ou voyons-nous autre chose d'étrange ?

Admin.js
Comme nous pouvons le voir, la page de connexion charge différents fichiers javascript, certains pour ajouter des fonctionnalités au formulaire de connexion. Aucun des fichiers ne contient d'indices sur le système réel utilisé, il se peut que ce frontal SSO soit personnalisé ; il s'enroule autour d'un système back-end SSO alimenté par ASP.

Cependant, l'un des fichiers chargés a attiré mon attention : admin.js. Chaque fois que nous voyons le mot « admin », nous sommes impatients d'en savoir plus à ce sujet.

Une partie du code source à l'intérieur du admin.jsfichier :

$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();

Comme je suis l'un des médecins généralistes avec une connexion SSO, je pourrais me connecter et atteindre ce point de terminaison.

Oups. Le point de terminaison renvoie toutes les données de l'utilisateur actuellement connecté. Y compris un hachage de mot de passe.

Le point de terminaison ne vérifie pas correctement qui le demande et renvoie toutes nos informations utilisateur . Y compris l'e-mail, le nom complet, le hachage du mot de passe et certains détails d'adhésion.

Que se passe-t-il si nous atteignons le même point de terminaison et échangeons le /adminavec un ID, comme nous pouvons le voir, j'ai l'ID 2027. Voyons ce qui se passe si nous essayons de taper ID 15000: https://hawebsso.nl/api/v1/user/15000

L'ID utilisateur 15000 existe, tous les détails du compte sont partagés avec nous, y compris le mot de passe.

Nous avons maintenant montré l'impact de ce point de terminaison, il divulgue tous les détails des utilisateurs des personnes inscrites au service SSO hawebsso.nl

En termes techniques, nous appelons ce type de bogue un IDOR ; Références d'objet directes non sécurisées .

Le point de terminaison /api/v1/user/1est un point de terminaison générique qui pourrait être facilement découvert par des pirates. On pourrait utiliser des listes de mots pour forcer brutalement les points de terminaison sur un actif comme celui-ci, un bon exemple est Assetnote.io leurs listes de mots partagées . La liste de motshttps://wordlists-cdn.assetnote.io/data/automated/httparchive_apiroutes_2020_11_20.txtcontient ce point de terminaison spécifique avec un ID qui renverrait un hit.

Un exemple d'entrée de liste de mots qui donnerait un résultat

Une autre approche que le pirate pourrait adopter consiste à analyser tous les fichiers javascript utilisés pour les terminaux. Par exemple , LinkFinder le fait pour vous.

Aucune authentification requise
Nous avons maintenant montré qu'un point de terminaison spécifique divulgue les détails de l'utilisateur, mais nécessite-t-il une authentification. Pourrait-on atteindre ce point de terminaison sans être connecté ?

Ouvrez le même point de terminaison en mode incognito du navigateur. Aucun cookie n'est défini, je ne suis pas connecté. Tous les détails de l'utilisateur sont renvoyés.

La réponse est oui. Ce point de terminaison ne nécessite aucune connexion. En termes techniques, nous avons maintenant un autre bogue, Missing Authentication for Critical Function . L'ouverture du point de terminaison dans un navigateur sans être connecté nous renvoie tous les détails de l'utilisateur.

Preuve de concept que le terminal fonctionne sans être connecté (données confidentielles censurées).

Hachage du mot de passe, comment le casser ?
Nous avons maintenant le hachage du mot de passe. L'utilisation de hachages de mot de passe réduit l'impact d'une fuite de données, car il faudrait d'abord casser le hachage pour récupérer le mot de passe. Dans le passé, les hachages de mot de passe comme MD5 étaient facilement cassés en utilisant quelque chose comme Rainbow Tables ; des listes de tous les hachages possibles, qui sont calculés à l'avance pour déchiffrer le hachage.

De nos jours, cela est résolu en utilisant des algorithmes de hachage plus sécurisés et en incluant des sels.

En changeant mon mot de passe par le même mot de passe que j'avais, je pouvais confirmer qu'un nouveau hachage unique était généré. Quelque chose qui nous donne un indice que les tables arc-en-ciel pourraient ne pas fonctionner ici (par exemple si elles incluent un sel unique par utilisateur).

Pour tester, j'ai utilisé le hachage suivant pour craquer (pas de soucis, c'est mon propre hachage, avec un mot de passe factice):em1EijmR7gmSA0NC2fbbl488pWDpX6YEfPtU4BNRsu01VX9VZFRuvSBAPaaIwVe5KC0enebMfwJC1AGZVNFbRsZ+7Pa7hj718HfKfIolp/5rDgsp/52UOqawXrNGHgwCHYsd+S0gG4K+ba3zjsjg5cVXCpIrqvlJbO45DkPqZ+B/REWhOmkBdRdie76z9oWk1qp7LFa9l/4Z3TtCgucS+m0Sl66mYcWwafRZkAas5a5z15v9iweiZK4WyEbkmUFQDgAqXMAsljftoJxSP0QN/BbXUtAm0wENIGvt7PPTg7dGxdUoySbUFpmnzm/eTeCcgbEpsJhb3bwAulMVl0F3

Après avoir piraté pendant un certain temps, vous pouvez identifier la plupart des types de hachage simplement en le regardant, tout comme les maladies de la peau.

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

Cependant, ici, je n'ai aucune idée de l'algorithme de hachage utilisé. Après avoir contacté l'un de mes collègues hackers éthiques, on m'a dit que cela ressemblait à une chaîne encodée en base64 , décodée, elle faisait exactement 255 octets de long.

La sortie de l'écho | base64 — décoder | wc-c

Sachant de notre reconnaissance que ASP est en cours d'exécution sur le serveur, nous pourrions obtenir plus d'indices dans la documentation fournie par Microsoft :https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity

Plus tard, j'ai trouvé ce blog (5 ans) sur les différents algorithmes de hachagehttps://andrewlock.net/exploring-the-asp-net-core-identity-passwordhasher/et j'ai trouvé l'article suivant intéressant :ASP.NET Core Identity Version 3: PBKDF2 with HMAC-SHA256, 128-bit salt, 256-bit subkey, 10000 iterations

Cela me donne un indice que ASP utilise, prêt à l'emploi, un algorithme de hachage approprié, que je ne pourrais pas facilement déchiffrer pour le moment. Une discussion intéressante sur PBKDF2 et l'avenir peut être lue ici .

Pour l'instant, j'ai renoncé à casser ces hachages.

Cependant, j'aimerais en savoir plus sur les lecteurs de ce blog, êtes-vous capable de déchiffrer mon hachage ? Si oui, faites-moi savoir comment vous feriez cela. Le premier à le casser gagnera mon rare autocollant à paillettes brillantes et d'autres objets uniques ! Ce monde est tout au sujet des autocollants comme vous le savez.

Conclusion
Nous avons trouvé une fuite de données concernant tous les e-mails et mots de passe utilisés par les médecins généralistes aux Pays-Bas. Ce point de terminaison n'était pas protégé et ne nécessitait aucune autorisation. Comme il s'agit d'un chemin générique, il pourrait être facilement deviné par les pirates. De plus, la référence à ce point de terminaison était cachée dans le admin.jsfichier inclus sur la page de connexion, des outils comme LinkFinder auraient informé tout pirate informatique de ce point de terminaison spécifique.

Discussion
Le LHV a publié une politique de divulgation responsable sur son site Web qui m'a permis de faire cette recherche :https://www.lhv.nl/cvd-coordinated-vulnerability-disclosure/Ce qui est un excellent exemple de la façon de soutenir les pirates éthiques.

En outre, ils tentent d'améliorer la sécurité globale des soins de santé primaires en élaborant des directives sur la manière de gérer les fuites de données . Récemment, ils ont publié à ce sujet dans l'un des magazines lus par les médecins généralistes :https://www.syntheshis.nu/wp-content/uploads/2022/12/Synth-2022-03-Totaal.pdf(Néerlandais, page 22). Les membres associés peuvent consulter cette directive :https://www.lhv.nl/product/praktijkwijzer-informatiebeveiliging/

Cependant, ce serait formidable si tout le monde pouvait accéder à ce document , plus nous partageons, mieux nous sommes en mesure de lutter contre les risques. Dans les soins de santé primaires, je travaille avec des étudiants, des gestionnaires de données et de nombreuses personnes qui ne sont pas membres du LHV ; si je pouvais facilement partager ces documents qui aideraient (je préfère ne pas partager de PDF obsolètes).

Une autre chose importante est d' ajouter la politique de divulgation responsable sur chaque actif en ligne . Par exemple, hawebsso.nl n'inclut aucune référence. De plus, le site Web NHG.org (utilisant le SSO) ne partage aucune politique de divulgation responsable en ligne . Une bonne chose serait de publier cette politique dès que possible, et de mettre tout le monde travaillant chez NHG à l'aise avec cette bonne pratique ; voirhttps://www.ncsc.nl/onderwerpen/cvd-beleid/cvd-beleid-opstellenapprendre comment procéder en tant qu'organisation.

Une bonne protection contre les fuites de données comme celles-ci est l'authentification à double facteur (2FA), HAwebsso.nl le prend en charge, mais il n'est pas activé par défaut. Ma recommandation est de l'activer afin de rendre plus difficile pour les attaquants l'accès à votre compte chaque fois que votre mot de passe a été divulgué. Il est également important de ne pas réutiliser les mots de passe, comme le montre ce rapport lorsqu'ils sont divulgués (et piratés), ils pourraient être utilisés de manière abusive sur d'autres services ; bourrage d'informations d'identification .

Comment pourrions-nous éviter des bugs comme celui-ci ?
Ce bogue a existé pendant environ 3 ans, c'est donc beaucoup de temps pour le découvrir.

Il existe différentes façons d'aborder cette question. L'un est au niveau de la gestion ; obtenir des certifications et adopter les normes de l'industrie.

Normes industrielles De
nos jours, nous avons différentes normes industrielles internationales (par exemple ISO 27001 ) ou nationales (par exemple NEN 7510 ) qui décrivent comment gérer la sécurité de l'information. Un excellent moyen d'intégrer de bonnes pratiques de sécurité de l'information dans votre organisation. Mettez-le en œuvre, demandez à un auditeur de s'assurer que tout est correctement mis en œuvre et le marketing peut partager la bonne nouvelle que vous êtes en sécurité.

"Monsieur, nous sommes certifiés ISO 27001, nous sommes super sécurisés" - Chaque service commercial

Les certificats sont bons, mais ne vous protègent pas du piratage.

Comme nous le verrons aujourd'hui, aucune certification ne vous empêchera de vous faire pirater. Cependant, cela ne signifie pas que nous ne devrions pas le faire. Chaque manière structurée d'améliorer la sécurité vaut la peine d'être mise en œuvre.

Consultants en test d'intrusion versus hackers éthiques
Une autre approche consiste à effectuer des tests d'intrusion réguliers ; engagez une entreprise et demandez-leur de vous pirater. Ce bogue est assez simple et il est probable qu'il soit détecté lors d'un test de stylet.

Cependant, ces tests de stylo se produisent souvent dans des périodes de temps spécifiques, ce n'est pas un processus continu. Ainsi, tout nouveau bogue dans les actifs publiés entre les tests de stylet pourrait passer inaperçu.

Une solution à cela pourrait être de créer une communauté de hackers éthiques, en utilisant des plateformes de bug bounty (comme HackerOne ou BugCrowd ) et de commencer à investir dans des hackers éthiques qui trouvent des bugs dans vos actifs. Nous avons d'excellents exemples de création de communautés aux Pays-Bas : Hack the Hague .

Modélisation des menaces
Je suis un grand fan de la méthode INCLUDESNODIRT.com ; rassemblez un groupe de personnes (c'est-à-dire un développeur, un hacker éthique, un médecin généraliste, un propriétaire de produit et un responsable de la confidentialité), remplissez le questionnaire et faites un remue-méninges pendant 20 minutes. Chaque fois que vous introduisez de nouveaux actifs, ajoutez des fonctionnalités à une application ou modifiez votre organisation (par exemple, fusions et acquisitions). Dans cet exemple, on se demanderait : « La nouvelle fonctionnalité d'administration ajoutée à hawebsso.nl est-elle correctement protégée contre tout accès non autorisé ? Si oui, expliquez comment.

Modélisation des menaces pour les soins de santé numériques

Je n'ai pas encore vu la méthode utilisée en production, mais j'aimerais entendre les histoires d'autres personnes qui l'ont déjà mise en œuvre. Que pourrions-nous en apprendre et est-ce que ça marche vraiment ?

La transparence est synonyme de confiance
Du début jusqu'à la fin de ce rapport de bogue spécifique, le responsable de la confidentialité de LHV a été très réactif à mes e-mails. Il m'a fréquemment envoyé des mises à jour, ce qui m'aide à avoir l'assurance que l'impact du bogue est compris par toutes les parties prenantes et qu'il est corrigé rapidement. Il a fait un excellent travail et est un exemple pour les autres comment gérer un rapport comme celui-ci, merci !

Dans toute organisation, la transparence est synonyme de confiance. S'il s'agit de fuites de données, nous avons de bons organigrammes qui nous aident à procéder et à informer de manière transparente les utilisateurs finaux (comme pouvoir publier des blogs comme celui-ci).

Ce rapport montre le pouvoir de la foule, la transparence et une politique de divulgation appropriée permettent à tous les pirates éthiques du monde de vous aider à renforcer votre sécurité. Vous pouvez appliquer ce modèle de foule à tous les autres niveaux de votre organisation et atteindre vos objectifs plus rapidement.

En fin de compte, nous voulons tous demain des soins de santé primaires meilleurs et plus sûrs, et tirer les leçons des erreurs commises dans le passé.

Chronologie
12/04/2022 — Trouvé le bogue, l'a signalé au responsable de la confidentialité de LHV par e-mail
12/05/2022 — Réponse du responsable de la confidentialité pour confirmer le bogue
12/06/2022 — Mise à jour du responsable de la confidentialité
12/08/2022 — Mise à jour du responsable de la confidentialité : le
bogue
existe depuis 3 ans (depuis fin 2019), aucun signe d'abus dans les journaux des 2 dernières années responsable de la confidentialité par e-mail
12–12–2022 — LHV & NHG ont informé tous les membres de la fuite de données par e-mail ; a demandé aux membres de réinitialiser leur mot de passe.
13–12–2022 — LHV a suggéré quelques modifications mineures
14–12–2022 — Blog publié