Site WWW de Laurent Bloch
Slogan du site

ISSN 2271-3905
Cliquez ici si vous voulez visiter mon autre site, orienté vers des sujets moins techniques.

Pour recevoir (au plus une fois par semaine) les nouveautés de ce site, indiquez ici votre adresse électronique :

Forum de l’article

Hôpitaux et collectivités territoriales particulièrement visés

modération a priori

Ce forum est modéré a priori : votre contribution n’apparaîtra qu’après avoir été validée par un administrateur du site.

Qui êtes-vous ?
Votre message

Pour créer des paragraphes, laissez simplement des lignes vides.

Lien hypertexte

(Si votre message se réfère à un article publié sur le Web, ou à une page fournissant plus d’informations, vous pouvez indiquer ci-après le titre de la page et son adresse.)

Rappel de la discussion
Hôpitaux et collectivités territoriales particulièrement visés
Fred Brouard (alias SQLpro) - le 3 janvier 2023

Travaillant dans le domaine des bases de données, et en tant qu’expert, je ne suis pas étonné de voir que les hôpitaux sont de plus en plus la cible d’attaque. Je suis, en revanche, persuadé qu’il ne s’agit pas de viser délibérément les hôpitaux, mais de manière plus simple viser les SI fragiles... En effet, l’état et quelques ayatollah du libre incite à utiliser les outils du libre plutôt que de payer de fort couteuses licences aux éditeurs. Si cela se conçoit assez bien pour des logiciels très fortement distribués et implanté, comme les OS (dont Linux est l’exemple presque parfait...), il n’en va pas de même dès que ces logiciels sont plus verticaux et plus critique qu’un simple système d’exploitation. Dans le domaine qui est le mien, je vois assez couramment l’utilisation de SGBD libre comme MySQL / MariaDB ou PostGreSQL dont la sécurité est d’une faiblesse extrême : pas de protection des fichiers, chiffrement cosmétique, droits d’accès de style "open bar...".

En ce qui concerne la protection des fichiers, Microsoft SQL Server verrouille de manière exclusive et permanente tous les fichiers de toutes les bases (y compris le journal de transaction), rendant impossible leur chiffrement à titre de ransomware, ce qu’aucun autre SGBD ne fait actuellement, et pour les SGBD comme PostGreSQL ou MySQL cela s’avérerait impossible vu la multitude des fichiers à verrouiller (trop de ressources, sachant que chaque table c’est de nombreux fichiers...).

En ce qui concerne le chiffrement la plupart des SGBDR libre ne permettent pas un chiffrement interne salé et impose que la clé figure d’une manière ou d’une autre dans le code... Autant laisser les clés sur sa voiture en espérant qu’elle ne soit pas volée... et dans un SGBDR comme SQL Server il est possible de faire du chiffrement de bout en bout y compris en exécution en mémoire (enclave mémoire sécurisées)... Une des vieilles technique pour obtenir des informations étant de "flasher" la mémoire à la manière d’un dump pour avoir accès au code exécuctable...

Lors des installations certains SGBDR comme MySQL / MariaDB sont installés par défaut avec l’utilisateur root sous Linux... Et le niveaux de gestion des privilège est souvent très limité et très souvent inutilisé...

Pour information, nous avons eu plusieurs clients dont les bases de données ont été chiffrées avec demande de rançons, sauf celles de SQL Server...

Hôpitaux et collectivités territoriales particulièrement visés
Christophe Renard - le 8 janvier 2023

Le choix Libre/Propriétaire, ce ne semble pas déterminant en terme de vulnérabilités. Dans les applications les plus souvent compromises on rencontre Citrix, Sharepoint, Exchange, mais aussi les serveurs VPN autant que des CMS libres. La raison de leur ciblage est que ce sont des applications exposées sur Internet, plutot que libres ou pas (et pour la plupart, des applications complexes à mettre à jour sans casser la prod).

Pour ce qui est de processus de base de données sous Linux tournant en root, ce n’est plus le cas dans les installations packagées avec la distribution depuis des années sur toutes les distributions communes. Ce n’est pas non plus recommandé ni par Postgresql ni par MariaDB et est symptôme d’une mauvaise intégration.

Sous Windows, la fonction d’ouverture de fichier de Win32/Win64 (CreateFile) verrouille le fichier ouverte par défaut. Sous POSIX, son équivalent (open) ne le fait pas. Donc, effectivement on peut effacer des fichiers ouverts et non verrouillés sous les Unix et plus rarement sous Windows, simplement parce-que le verrouillage est moins fréquent.
En revanche, les attaquants compétents le savent. C’est pourquoi, ils deviennent administrateurs du SI (Admin du domaine Active Directory) et éteignent les processus gênants juste avant le lancer le chiffrement. Parmis ces processus, on trouve tous les services d’infrastructure, mais aussi les machines virtuelles, et évidemment les antivirus. De ce fait, sauf échec d’extinction de fichier, les fichiers de base de données sont bien chiffrés sous Windows.

Enfin, le chiffrement des données ne protège que peu des attaques d’extorsion par piratage préalable du système d’information :
1. le chiffrement de disque est contourné car se sont des machines démarrées qui sont piratées.
2. le chiffrement de base est contourné car la base est démarrée et l’attaquant peu dumper le contenu interactivement avec les outils d’administration.
3. le chiffrement au niveau des champs, si les clés étaient protégées par un secret utilisateur pourrait protéger d’une extraction de masse. Mais c’est un mécanisme lourd et rare de mise en oeuvre.

Dans les 3 derniers cas, les clés de déchiffrement existent de toute façon certainement sur le système soit dans un fichier de configuration, clé de registre, ou stockage de secret de Windows. Cette présence est généralement nécessaire au (re)démarrage automatique des services. Les attaquants étant administrateurs pourront y accéder. On peu aussi observer que les outils pour dumper la mémoire vive et en extraire les secrets sont matures et bien rodés. C’est même un exercice courant dans les concours de CTF.

Je peux attester du chiffrement des bases SQLServer dans toutes les interventions de réponse à incident sur rançongiciel que j’ai traité ces dernières années ou le SI de l’entreprise était lourdement impacté (et il en a avoir trop).

On rencontre effectivement dans le bas de gamme de l’extorsion, des attaquants incompétents qui chiffrent sans pirater correctement au préalable. Mais les attaques aux impacts lourds, qui arrêtent un hôpital et rapportent des dizaines de millions aux pirates, se heurtent bien plus aux pratiques d’administration qu’au choix d’un logiciel ou un autre, quel qu’en soit l’éditeur, libre ou pas.

Derniers commentaires

Une illustration de la concurrence monopolistique
Attention : les GPU sont très forts en produits scalaires, (en multiplication de matrices par (...)

Python
"on dit plutôt maintenant développeurs" ... Il y a (au moins) deux expressions qui (...)

À la Commission de développement de l’informatique du Ministère des Finances
Article tout aussi instructif que plaisant à lire. On pensera aussi à "Comédies Françaises", (...)

À la Commission de développement de l’informatique du Ministère des Finances
Dans le style qui t’est caractéristique, j’avoue que j’ai bien aimé ! J’ai même eu l’occasion (...)

Informatique confidentielle
La clé pour comprendre est peut-être qu’il s’agit ici de "machine virtuelle" et non de (...)