Vous êtes dans : Accueil > Actualités > E-Santé >

Cryptolockers : état des lieux et plans de protection

Cédric Cartau, MARDI 18 OCTOBRE 2016

Je suis positivement inquiet sur l’évolution de la menace que représentent les cryptolockers, pas tant par le fait qu’il n’existe aucun moyen fiable de s’en protéger à 100 % (ce qui était le cas des « zero days » et qui n’est pas nouveau), mais surtout parce qu’il semblerait que nous n’en soyons qu’à la version 1.0 du grand foutoir. Rien ne m’agace plus d’ailleurs que de croiser, sur un colloque ou un stand de fournisseur, un responsable commercial m’annonçant avec fierté que son produit à lui éradique les cryptos sous prétexte qu’il fait de l’analyse comportementale.

Cela en dit long, non pas sur les menaces, mais sur la connaissance qu’en ont certains industriels. Les outils de type Sandboxing, dont on nous avait annoncé il y a peu l’efficacité parfaite, sont contournables pour qui veut s’en donner la peine, et le comportemental, il y a dix ans que tous les pure players de la lutte antimalware en font. État des lieux sans concessions ; les établissements de santé ont un peu de travail…

Les premières versions apparues dans le monde de la santé chiffraient les répertoires des disques durs locaux des PC. Dans un monde parfait, toutes les données sont stockées soit dans des SGBDR (donc sur des serveurs), soit sur des répertoires partagés (encore sur des serveurs). Le seul impact est donc la perte des données privées des agents, pas de quoi fouetter un chat. Quoi que : qui peut garantir qu’aucun utilisateur n’a installé d’applications sensibles au fin fond d’un laboratoire, hébergeant des données critiques, dans une base Access locale ? Personne. 

Puis sont arrivées les versions chiffrant les partages de fichiers réseau : là on rigole tout de suite beaucoup moins, la seule contre-mesure consiste à s’assurer que les sauvegardes sont à jour. Un CHU a été attaqué la semaine dernière, et mon confrère RSSI est persuadé que la cochonnerie qu’il a attrapée a scanné les partages selon les chemins UNC : en d’autres termes, tous les partages de fichiers sont vulnérables, et pas seulement ceux qui ont été mappés avec un lecteur sur le poste de travail. On devine sans problème la suite : les prochains cryptolockers seront capables d’attaquer les SGBDR Oracle ou autres (OK, OK, il faut un mot de passe, mais la plupart des bases ont conservé des comptes d’accès par défaut – vous voulez parier ?) et bien entendu les systèmes de sauvegarde. Et là, votre serviteur RSSI ressent un coup de froid lui descendre le long de l’échine, car cela rappelle étrangement la saison 1 de Mr. Robot[1].

Cela étant, deux catégories de mesures doivent être déployées ou a minima instruites, et sans tarder : les mesures périmétriques et les mesures internes. Il existe trois vecteurs d’attaque : la messagerie, les flux Web et les clés USB – pour information, le vecteur le plus commun aujourd’hui est le flux Web, en particulier la consultation par les agents de leur messagerie Webmail pendant leur temps de pause, piège terrible. Ci-dessous, une liste à la Prévert des mesures techniques à déployer et/ou à instruire, classées en deux groupes (celles à mettre en place tout de suite, et celles à garder en cas d’attaque massive). Y a du boulot !

Mesures concernant le flux de messagerie entrant

À mettre en place en priorité :

  • antispam à signature et à réputation, AV à signature, AV comportemental ;
  • blocage des PJ comportant une macro (les .docm et les .xlsm).

À mettre en place ultérieurement ou en cas d’attaque :

  • blocage des extensions susceptibles de comporter une macro (les .doc, les .xls et les .pdf) ;
  • système de conversion automatique des pièces jointes dans un format sans macro.

Mesures de protection concernant les flux Web

À mettre en place en priorité :

  • blocage des sites par réputation ;
  • inspection des flux Web par AV à signature et AV comportemental ;
  • Blocage des liens directs vers des pièces jointes bureautiques, a minima celles susceptibles d’embarquer des macros.

À mettre en place ultérieurement ou en cas d’attaque :

  • blocage des Webmails.

 Protection locale du PC

À mettre en place ultérieurement ou en cas d’attaque :

  • blocage des pièces jointes et des documents comportant une macro en provenance d’un périphérique de masse ;
  • blocage des périphériques de masse externe.

 Protection interne du LAN

  • déploiement d’AV à signature et comportementaux sur les serveurs, si ce n’est pas déjà fait ;
  • audit des comptes d’accès AD, verrouillage de tous les comptes par défaut ;
  • audit des comptes d’accès aux SGBDR, verrouillage de tous les comptes par défaut ;
  • audit des comptes d’accès au serveur de sauvegarde, verrouillage de tous les comptes par défaut ;
  • fermeture des services fichiers sur les serveurs AD ;
  • fermeture des services fichiers sur les serveurs SGBDR ;
  • fermeture des services fichiers sur les serveurs de sauvegarde ;
  • mise en place de firewalls inter-VLAN pour la protection des serveurs, filtrage des flux, en particulier les ports de service fichiers ;
  • mise en place de communications signées interserveurs par certificat 802.1x ;
  • mise en place d’outils d’analyse centralisée des traces multisources (DNS, AD, firewall, etc.) avec analyse heuristique afin de détecter des APT en mode silencieux ou les malwares en cours de déploiement (ITrust développe ce type d’outils, pour Noël j’en veux un au pied du sapin) ;
  • déploiement dans la DMZ d’outils automatisés de conversion des pièces jointes bureautiques dans un format neutre sans macro.

Hauts les cœurs, c’est bientôt les vacances !

[1]   Ne comptez pas sur moi pour spoiler, regardez-la.

#ad#rssi