Publicité en cours de chargement...
Orages de vulnérabilités pour des inondations d’informations
28 août 2018 - 14:04,
Tribune
- Charles Blanc-RolinAu début du mois d’août, le chercheur en sécurité Bob Diachenko a découvert parmi les bases de données Mogodb exposées sur Internet et recensées par le moteur de recherche Shodan (plus de 53 000), une base de données exposant les données de 2 373 764 patients mexicains[1].
La base de données, semblant appartenir à la société Hova Health, une société mexicaine spécialisée dans le secteur de la télémédecine, téléradiologie et le développement de logiciels pour le secteur de la santé, était accessible sans authentification, mais était également modifiable par n’importe qui !
Le critère de sécurité le plus important dans le domaine de la santé ne serait pas l’intégrité ?
Difficile d’assurer l’intégrité des données lorsqu’elles sont modifiables par n’importe quel internaute ! La confidentialité est elle aussi à revoir, par contre côté disponibilité des données, c’est vrai que pour le coup, on ne peut pas dire grand-chose…
Parmi les informations facilement accessibles, on pouvait retrouver : nom, prénom, date de naissance, adresse postale, l’équivalent de notre numéro de sécurité sociale (ou NIR), mais également des informations relatives à l’origine du patient, avec des champs tels que :
Indigène : oui / non
Migrant : oui / non
Ainsi qu’un champ « disability » permettant de définir si le patient est atteint d’un handicap.
Le chercheur souligne dans son article le fait que ce paramétrage par défaut, permettant un libre accès à la base de données a été corrigé en 2013 par l’éditeur. Alors on peut se demander depuis combien de temps cette base de données était accessible ? Si les données qu’elle contient ont été consultées, exfiltrées, modifiées ?
Une vulnérabilité dans OpenSSH, présente depuis 1999
La vulnérabilité CVE-2018-15473 [2] aurait pu passer inaperçue si un chercheur de la société Qualys n’avait pas repéré une modification dans le code source d’OpenSSH [3].
La vulnérabilité présente dans le code existait donc depuis le début de son développement, ce qui veut dire que toutes les versions antérieures à la publication du correctif sont impactées. Tous les serveurs Linux utilisant SSH, mais également de nombreux appareils, tels que des routeurs, firewall, et bien d’autres objets connectés en tout genre sont vulnérables. Le nombre de machines vulnérables est tellement important, qu’il est impossible à quantifier.
Alors, vous allez me dire, qu’en est-il réellement de cette vulnérabilité ?
Cette vulnérabilité repose sur le mécanisme d’authentification par clé publique et permet d’énumérer la liste des utilisateurs existants sur la machine. De quoi simplifier grandement la tâche aux casseurs de mots de passe. La majorité des distributions Linux connues ont déjà intégré le correctif, mais de nombreux appareils et serveurs risque de rester vulnérables pendant de longs mois, voir années… En l’absence de correctif, il est toujours possible de désactiver l’authentification par clé publique pour pallier au problème.
Très rapidement, un exploit de cette vulnérabilité a été rendu public par son auteur Justin Gardner [4], permettant de démontrer la vulnérabilité et de tester la présence d’un utilisateur sur la machine. Son efficacité et sa simplicité d’utilisation sont d’ailleurs assez déconcertantes.
En testant ce script sur Dropbear, une alternative très légère à OpenSSH, utilisée sur des appareils ayant une capacité de stockage extrêmement réduite, j’ai pu constater que lui aussi était vulnérable [5].
Après quelques échanges avec son excellent développeur, l’australien Matt Johnston qui était déjà à l’œuvre sur l’écriture d’un correctif et qui m’a recontacté quelques heures après pour me dire, c’est corrigé ! [6] Je constatais le lendemain, que le patch était déjà disponible dans des distributions telles qu’OpenWrt.
Je crois que l’on peut, une fois encore saluer la réactivité de la communauté open source qui a très rapidement palliée à ce problème.
Ces exemples nous montrent une fois encore que la sécurité de nos SI de santé est une course sans relâche, et que ce n’est pas demain la veille que les RSSI seront au chômage...
[2] https://nvd.nist.gov/vuln/detail/CVE-2018-15473
[3] http://seclists.org/oss-sec/2018/q3/124
[4] https://twitter.com/Rhynorater/status/1031715914197225475/photo/1
https://www.exploit-db.com/exploits/45233/
https://github.com/Rhynorater/CVE-2018-15473-Exploit
[5] https://nvd.nist.gov/vuln/detail/CVE-2018-15599
[6] https://secure.ucc.asn.au/hg/dropbear/rev/5d2d1021ca00
