Archives de catégorie : A retravailler

Rootkit

Un rootkit (en français : « outil de dissimulation d’activité »1) est un type de programme (ou d’ensemble de programmes ou d’objets exécutables) dont le but est d’obtenir et de maintenir un accès frauduleux (ou non autorisé) aux ressources d’une machine, de la manière la plus furtive et indétectable possible.

Le terme peut désigner à la fois la technique de dissimulation ou son implémentation (c’est-à-dire un ensemble particulier d’objets informatiques mettant en œuvre cette technique).

Historique

Le phénomène n’est pas nouveau : des programmes manipulant les logs système, tout en se dissimulant des commandes donnant des informations sur les utilisateurs (telles que who, w, ou last), sont apparus en 1989{{Lien web | url = http://www.sans.org/reading_room/whitepapers/honors/linux_kernel_rootkits_protecting_the_systems_1500?show=1500.php&cat=honors | titre = Linux kernel rootkits: protecting the system’s « Ring-Zero » | date = mars 2004 | éditeur = SANS Institute }} ; les premiers rootkits sur Linux et Solaris ont été rencontrés au début des années 19902 et ont été répertoriés en tant que tels en octobre 1994. Le projet chkrootkit, dédié au développement d’un outil de détection de rootkits pour les plateformes Solaris et HP-UX, a été démarré en 1997.

Il existe des rootkits pour la plupart des systèmes d’exploitation. En 2002, Securityfocus constatait déjà des évolutions et des progrès en matière de rootkit pour les plate-formes Windows. Un des premiers rootkits pour Mac OS X (WeaponX) est apparu en novembre 20043.

Certains rootkits peuvent être légitimes, pour permettre aux administrateurs de reprendre le contrôle d’une machine défaillante, pour suivre un ordinateur ayant été volé4, ou dans des outils comme Daemon Tools ou Alcohol 120%5. Mais aujourd’hui le terme n’évoque quasiment plus que des outils à finalité malveillante.

Mode opératoire

Contamination

La première phase d’action d’un rootkit consiste à chercher un accès au système, sans forcément que celui-ci soit un accès privilégié (ou en mode administrateur). La contamination d’un système peut avoir lieu de différentes façons, en utilisant les techniques habituelles des programmes malveillants. Les moyens les plus courants sont :

  • utilisation des techniques virales : un rootkit n’est pas un virus à proprement parler, mais il peut se transmettre par les techniques utilisées par les virus, notamment par un [[Cheval_de_Troie_(informatique)|cheval de Troie]]. Un virus peut avoir pour objet de répandre des rootkits sur les machines infectées (a contrario, un virus peut aussi utiliser les techniques de rootkits pour parfaire sa dissimulation) ;
  • mise en œuvre d’un [[Exploit_(informatique)|exploit]], c’est-à-dire l’exploitation d’une vulnérabilité de sécurité, à n’importe quel niveau du système : application, système d’exploitation, BIOS, etc. Cette mise en œuvre peut être le fait d’un virus, mais elle résulte aussi souvent de botnets qui réalisent des scans de machines pour identifier les failles et exploiter celles qui sont utiles à l’attaque ;
  • attaque par force brute, afin de profiter de la faiblesse des mots de passe de certains utilisateurs, et obtenir ainsi un accès au système.

Modification du système et dissimulation

Une fois la contamination effectuée et l’accès obtenu, la phase suivante du mode opératoire consiste en l’installation de l’ensemble des objets et outils nécessaires au rootkit. Il s’agit des objets permettant la mise en place de la charge utile du rootkit, s’ils n’ont pas pu être installés durant la phase de contamination, ainsi que les outils et les modifications nécessaires à la dissimulation.

Mise en place de la charge utile

Un [[botnet

permet d’avoir un accès sur des centaines de machines.]]

La charge utile est la partie active du rootkit (et de tout programme malveillant en général), dont le rôle est d’accomplir la (ou les) tâche(s) assignée au système. La charge utile permet d’avoir accès aux ressources de la machine infectée, et notamment :

  • CPU, pour décoder des mots de passe ou plus généralement pour effectuer des calculs distribués à des fins malveillantes ;
  • serveur de messagerie, pour envoyer des mails (pourriel ou spam) en quantité ;
  • ressources réseaux, pour servir de base de lancement pour des attaques diverses (déni de service, exploits) ou pour sniffer l’activité réseau ;
  • pilotes de périphériques, pour installer des enregistreurs de frappe ou keyloggers (par exemple) ;
  • accès à d’autres machines, par rebond ;
  • prise de contrôle total de la machine (par exemple en remplaçant le procédé de connexion, comme /bin/login sous Linux).

Certains rootkits sont utilisés pour l’exploitation de botnets, la machine infectée devenant alors une machine zombie, comme par exemple pour le botnet Srizbi6.

Dissimulation

Le rootkit cherchera également à « dissimuler » son activité. Ce procédé de dissimulation permet évidemment de minimiser le risque de découverte du rootkit, afin de profiter le plus longtemps possible de l’accès frauduleux. Une des caractéristiques principales d’un rootkit est donc sa faculté à se dissimuler, alors qu’un virus cherche principalement à se répandre, ces deux fonctions étant parfois jumelées pour une efficacité supérieure. Selon les cas, plusieurs méthodes peuvent être employées et combinées :

  • en ouvrant des portes dérobées, afin de pérenniser l’accès au système et permettre le contrôle de la machine, l’installation de la charge utile, etc27 ;
  • en cachant des processus informatiques ou des fichiers ; sous Windows, une technique consiste à modifier certaines clés de la base de registre ; sous Linux, on peut par exemple modifier les fichiers /usr/include/proc.h (processus à masquer) ou /usr/include/file.h (fichiers à masquer) ;
  • en remplaçant certains exécutables ou certaines librairies par des programmes malveillants et des chevaux de Troie, contrôlables à distance ;
  • en obtenant des droits supérieurs (par élévation des privilèges), afin de désactiver les mécanismes de défense ou pour agir sur des objets de haut niveau de privilèges ;
  • en utilisant des techniques de type « {{lang|en|Stealth by Design}} » (littéralement « furtif par conception »)8, à savoir implémenter à l’intérieur du rootkit des fonctions système afin de ne pas avoir à appeler les fonctions standards du système d’exploitation et ainsi éviter l’enregistrement d’événements système suspects ;
  • en détournant certains appels aux tables de travail utilisées par le système{{pdf}} {{Lien web |url=http://www.security-labs.org/fred/docs/sstic07-rk-article.pdf|titre=De l’invisibilité des rootkits : application sous Linux|auteur=E. Lacombe, F. Raynal, V. Nicomette|éditeur=CNRS-LAAS/Sogeti ESEC}} par [[Hook (informatique)|hooking]] ;
  • en effaçant physiquement toute trace d’activité, notamment dans les journaux de logs système, etc.

Niveau de privilège

Bien que le terme a souvent désigné des outils ayant la faculté à obtenir un niveau de privilège de type administrateur (utilisateur root) sur les systèmes Unix et Linux, un rootkit ne cherche pas obligatoirement à obtenir un tel accès sur une machine (par [[Élévation_des_privilèges|élévation de privilège]]), et ne nécessite pas non plus d’accès administrateur pour s’installer, fonctionner et se dissimuler9. Le programme malveillant Haxdoor10, même s’il était un rootkit du type noyau11 pour parfaire sa dissimulation, écoutait les communications sous Windows en mode utilisateur12 afin de tenter de capturer des identifiants avant cryptage, en interceptant les API de haut niveau.

Cependant, l'[[Élévation_des_privilèges|élévation de privilège]] est souvent nécessaire pour que le camouflage soit efficace : le rootkit peut utiliser certains [[Exploit_(informatique)|exploits]] afin de parfaire sa dissimulation en opérant à un niveau de privilège très élevé, pour atteindre des bibliothèques du système, des éléments du noyau, pour désactiver les défenses du système, etc.

Types

Il existe cinq types principaux de rootkits selon leur cible : les kits de niveau micrologiciel, hyperviseur, noyau, bibliothèque et applicatif.

Niveau micrologiciel/hardware

Il est possible d’installer des rootkits directement au niveau du micrologiciel (ou {{lang|en|firmware}}). De nombreux produits proposent désormais des mémoires flash, ce qui peut être utilisé pour implanter durablement du code13, en détournant par exemple l’usage d’un module de persistance souvent implanté dans le BIOS de certains systèmes.

Un outil légitime utilise d’ailleurs cette technique : LoJack, d’AbsolutSoftware4, qu’on trouve sur des ordinateurs portables car il permet ainsi de suivre un ordinateur à l’insu de l’utilisateur (en cas de vol). Ce code peut « survivre » à un changement de disque dur voire à un flashage du BIOS14 si le module de persistance est présent et actif. Tout périphérique disposant d’un tel type de mémoire est donc potentiellement vulnérable.

Une piste évoquée pour contrer ce genre de rootkit serait d’interdire l’écriture du BIOS (grâce à un cavalier sur la carte-mère ou par l’emploi d’un mot de passe) ou d’utiliser des EFI à la place du BIOS15, mais cette méthode reste à tester et à confirmer16.

Niveau hyperviseur

Ce type de rootkit se comporte comme un hyperviseur classique (de niveau 1) : après s’être installé et avoir modifié la séquence de démarrage, pour être lancé en tant qu’hyperviseur de la machine infectée au démarrage. Le système d’exploitation original se retrouve alors être un hôte (invité) du rootkit, lequel peut alors intercepter tout appel matériel. Il devient quasiment impossible à détecter depuis le système original.

Une étude conjointe de chercheurs de l’université du Michigan et de Microsoft ont démontré la possibilité d’un tel type de rootkit, qu’ils ont baptisé « {{lang|en|virtual-machine based rootkit}} » (VMBR)17. Ils ont pu l’installer sur un système Windows XP et sur un système Linux. Les parades proposées sont la sécurisation du boot, le démarrage à partir d’un média vérifié et contrôlé (réseau, CD-ROM, clé USB, etc) ou l’emploi d’un moniteur de machine virtuelle sécurisé.

Niveau noyau

Certains rootkits arrivent à s’implanter dans les couches du noyau du système d’exploitation soit dans le noyau lui-même, soit dans des objets exécutés avec un niveau de privilèges équivalent au système, ce qui est le cas pour certains pilotes de périphériques.

Sous Linux, il s’agit souvent de modules pouvant être chargés au niveau du noyau (modules de noyau chargeables, ou {{lang|en|loadable kernel modules}}), sous Windows de pilotes informatiques. Avec un tel niveau de privilèges, la détection et l’éradication du rootkit n’est souvent possible que de manière externe au système en redémarrant (en bootant) depuis un système sain, installé sur CD, sur une clé USB ou par réseau.

Ce type de rootkit est dangereux à la fois parce qu’il a acquis des privilèges élevés (il est alors plus facile de leurrer un logiciel de protection), mais aussi par les instabilités qu’il peut causer sur le système infecté comme cela a été le cas lors de la correction de la vulnérabilité MS10-01518, où des [[Écran_bleu_de_la_mort|écrans bleus]] sont apparus en raison d’un conflit entre cette correction et le fonctionnement du rootkit Alureon19.

Niveau bibliothèque

À ce niveau, le rootkit détourne l’utilisation de bibliothèques légitimes du système d’exploitation. Plusieurs techniques peuvent être utilisées :

  • en patchant un objet d’une bibliothèque, c’est-à-dire en ajoutant du code à l’objet en question ;
  • en détournant l’appel d’un objet (« hooking »), ce qui revient à appeler une autre fonction puis à revenir à la fonction initiale ;
  • en remplaçant des appels système par une version spécifique, ce qui correspond à remplacer l’appel système initial par du code malveillant.

Ce type de rootkit est assez fréquent, mais il est aussi le plus facile à contrer, notamment par un contrôle d’intégrité des fichiers essentiels en surveillant leur empreinte grâce à une fonction de hachage, par détection de signature du programme malveillant, ou par exemple par examen des {{lang|en|hooks}} par des outils comme unhide sous Linux ou HijackThis sous Windows.

Niveau applicatif

Un rootkit applicatif implante des programmes malveillants de type [[Cheval_de_Troie_(informatique)|cheval de Troie]], au niveau utilisateur. Ces programmes prennent la place de programmes légitimes ou en modifient le comportement, afin de prendre le contrôle des ressources accessibles par ces programmes.

Exemples

Rootkits Sony

À deux reprises, Sony a été confronté à la présence masquée de rootkits dans ses produits : dans ses clés usb biométriques20 et dans son composant de gestion numérique des droits (DRM)2122 présent notamment sur ses CD audio. Ce rootkit possède lui-même des failles qui peuvent être exploitées.

Ces affaires ont fait un tort important à Sony, aussi bien pour sa respectabilité que financièrement. Dans plusieurs pays, Sony a été poursuivi en justice et obligé de reprendre les CD contenant un rootkit et de dédommager les clients23.

Voir aussi : [[:en:Sony BMG CD copy protection scandal|Sony BMG CD copy protection scandal]].

Exploitation de la vulnérabilité de LPRng

Le CERTA (Centre d’Expertise Gouvernemental de Réponse et de Traitement des Attaques informatiques) a publié, dans une note d’information, l’analyse d’une attaque ayant permis d’installer un rootkit (non identifié), n’utilisant à l’origine qu’une seule faille (répertoriée CERTA-2000-AVI-08724) qui aurait pu être stoppée soit par la mise-à-jour du système, soit par le blocage d’un port spécifique grâce à un pare-feu25.

Cette attaque a été menée en moins de deux minutes. L’attaquant a identifié la vulnérabilité, puis envoyé une requête spécialement formée sur le port 515 (qui était le port exposé de cette vulnérabilité) pour permettre l’exécution d’un code arbitraire à distance. Ce code, nommé « SEClpd », a permis d’ouvrir un port en écoute (tcp/3879) sur lequel le pirate est venu se connecter pour déposer une archive (nommée rk.tgz, qui contenait un rootkit) avant de la décompresser et de lancer le script d’installation.

Ce script a fermé certains services, installé des [[Cheval_de_Troie_(informatique)|chevaux de Troie]], caché des processus, envoyé un fichier contenant les mots de passe du système par mail, et il a même été jusqu’à corriger la faille qui a été exploitée, afin qu’un autre pirate ne vienne pas prendre le contrôle de la machine.

Prévention

Moyens de détection

La mise en œuvre de la détection peut parfois demander un examen du système ou d’un périphérique suspect en mode « inactif » (démarrage à partir d’un système de secours ou d’un système réputé sain), selon le type de rootkit. Les moyens de détection peuvent être :

Le calcul régulier des empreintes de fichiers sensibles permet de détecter une modification inattendue.
  • contrôle de l’intégrité des fichiers : on cherche à détecter toutes modifications des fichiers sensibles (bibliothèques, commandes systèmes, etc)8 en vérifiant régulièrement leur intégrité, en calculant pour chacun d’eux leur empreinte : toute modification inattendue de cette somme indiquera une modification du fichier et une contamination potentielle. Cela demande cependant une analyse car tout système subit aussi des modifications légitimes (comme lors des mises-à-jour du système) ; idéalement, l’outil de contrôle aura la possibilité d’accéder à une base de référence de ces sommes de contrôles, qui variera donc en fonction du système et des versions utilisées (comme rkhunter, par exemple) ;
  • détection de leur signature spécifique : il s’agit du procédé classique d’analyse de signature, comme cela se fait pour les virus. On cherche à retrouver dans le système la trace d’une infection, soit directement (signature des objets du rootkit), soit par le vecteur d’infection (virus utilisé par le rootkit)8 ;
Le hooking consiste à détourner un appel de fonction légitime par un autre qui contient du code malveillant.
  • analyse des appels systèmes : cette technique consiste à analyser la table des appels système, les tables d’interruption (ou Interrupt Descriptor Table)2627 et de manière générale les tables de travail utilisées par le système par des outils comme HijackThis qui permettent de voir si ces appels sont détournés ou non, par exemple en comparant ce qui est chargé en mémoire avec les données brutes de bas niveau (ce qui est écrit sur le disque) ;
  • analyse des flux réseau anormaux : cette analyse28 permet de détecter une surcharge ou une utilisation de ports logiciels inhabituels qui peut être observée à partir de la contamination de la machine, grâce aux traces issues d’un pare-feu ou grâce à un outil spécialisé. Il est également possible de faire une recherche des ports logiciels ouverts et de la comparer à ce que connaît le système, avec des outils d’investigation comme unhide-tcp. Toute différence peut être considérée comme anormale. Il existe cependant des moyens de dissimulation réseau, comme de la stéganographie ou l’utilisation de canaux cachés, qui rend la détection directe impossible, et seule une analyse statistique peut éventuellement répondre à cette difficulté29 ;
  • analyse des logs système : ce type d’analyse30 automatisée s’appuie sur le principe de corrélation, avec des outils de type HIDS qui disposent de règles paramétrables31 pour distinguer les événements anormaux et mettre en relation des événements systèmes distincts, sans rapport apparent ou différés dans le temps ;
  • analyse de la charge système : une surveillance continue peut mettre en évidence un surcharge, à partir de la contamination de la machine. Il s’agit essentiellement d’une analyse statistique de la charge habituelle d’une machine, comme le nombre de mails sortants ou la charge CPU. Toute modification (en surcharge) sans cause apparente est suspecte, mais cela demandera une analyse complémentaire pour écarter toute cause légitime (mise-à-jour du système, installation de logiciels, etc).
  • recherche d’objets cachés, tels que des processus informatiques, des clés de registre, des fichiers, etc. Des outils comme unhide sous Linux réalisent cette tâche pour les processus. Sous Windows, des outils comme RootkitRevealer recherchent les fichiers cachés en listant les fichiers via l’API normale de Windows puis en comparant cette liste à une lecture physique du disque ; tout fichier caché (à l’exception des fichiers légitimes connus de Windows, tels que les fichiers métadata de NTFS comme $MFT ou $Secure) est alors suspect32.

Moyens de protection et de prévention

Les moyens de détection peuvent également servir à la prévention, même si celle-ci sera toujours postérieure à la contamination. D’autres mesures en amont peuvent limiter l’installation d’un rootkit33 :

  • correction des failles par mise-à-jour de l’OS : cela permet de réduire la surface d’exposition du système en éliminant le temps où une faille est présente sur le système34 et dans les applications30, afin de prévenir les [[Exploit_(informatique)|exploits]] pouvant être utilisés pour la contamination ;
  • utilisation d’un pare-feu : cela fait partie des bonnes pratiques dans le domaine de la sécurité informatique, et se révèle efficace dans le cas des rootkits273034 car cela empêche des communications inattendues (téléchargements de logiciel, dialogue avec un centre de contrôle et de commande d’un botnet, etc.) dont ont besoin les rootkits ;
  • utilisation d’outil de prévention de type HIPS : ces outils30, de type logiciel ou appliance, répondent dès qu’une alerte est suspectée, en bloquant des ports ou en interdisant la communication avec une source (adresse IP) douteuse, ou toute autre action appropriée. La détection sera d’autant meilleure que l’outil utilisé sera externe au système examiné, puisque certains rootkit peuvent atteindre des parties de très bas niveau dans le système, jusqu’au BIOS même. Un des avantages de ces outils est l’automatisation des tâches de surveillance8 ;
  • contrôle d’intégrité des fichiers : des outils spécialisés existent pour remplir cette tâche, et peuvent produire des alertes lors de modifications inattendues. Cependant, ce contrôle à lui seul seul est insuffisant si d’autres mesures préventives ne sont pas mises en œuvre, si aucune réponse du système n’est déclenchée, ou si ces différences ne sont pas analysées. Les HIPS/HIDS, ainsi que certains outils anti-rootkits comme rkhunter peuvent interpréter ces contrôles via une base de sommes de contrôle (pour des versions connues de systèmes d’exploitation) ou par corrélation ;
attaque par force brute

.]]

  • renforcement de la robustesse des mots de passe : il s’agit là encore d’une des bonnes pratiques de sécurité informatique, qui éliminera une des sources principales de contamination. Des éléments d’authentification triviaux sont des portes ouvertes pour tous type d’attaque informatique ;
  • démarrage du système à partir d’une image saine : le démarrage à partir d’une image saine, contrôlée et réputée valide du système d’exploitation, via un support fixe (comme un LiveCD, une clé USB) ou par réseau, permet de s’assurer que les éléments logiciels principaux du système ne sont pas compromis, puisqu’à chaque redémarrage de la machine concernée, une version valide de ces objets est chargée. Un système corrompu serait donc remis en état au redémarrage (sauf dans le cas de rootkit ayant infecté le BIOS, qui ne sera lui pas rechargé automatiquement) ;
  • moyens de protection habituels : {{citation étrangère |lang=en |Do everything so that attacker doesn’t get into your system}}29. Tous les moyens habituels et classiques de protection d’un système informatique sont utiles, tels que [[Durcissement_(informatique)|durcissement du système]]27, filtrages applicatifs (type mod_security), utilisation de programmes antivirus2734 pour minimiser la surface d’attaque et surveiller en permanence les anomalies et tentatives de contamination, sont bien sûr à mettre en œuvre pour éviter la contamination du système et l’exposition aux [[Exploit (informatique)|exploits]].

Windows 10

Microsoft a travaillé pour rendre l’installation de rootkits plus difficile. Leur travail a porté ses fruits, mais être mieux protégé ne signifie pas être totalement protégé, car un malware (Zacinlo) présent à 90%35 sur des machines Windows a réussi à assurer sa persistance grâce à un rootkit.

Outils et programmes de détection

Bien que les rootkits existent depuis un certain temps, l’industrie de la sécurité informatique ne les a pris en compte (en masse) que récemment, les virus puis les chevaux de Troie accaparant l’attention des éditeurs. Il existe cependant quelques programmes de détection et de prévention spécifiques à Windows, tels que Sophos Anti-Rootkit, ou AVG Anti-Rootkit. Sous Linux, on peut citer rkhunter et chkrootkit ; plusieurs projets open-source existent sur Freshmeat et Sourceforge.net.

Aujourd’hui, il reste difficile de trouver des outils spécifiques de lutte contre les rootkits, mais heureusement leur détection et leur prévention sont de plus en plus intégrées dans les HIPS et même dans les anti-virus classiques, lesquels sont de plus en plus obligés de se transformer en suites de sécurité pour faire face à la diversité des menaces ; ils proposent en effet de plus en plus souvent des protections contre les rootkits, comme Avast, AVG 8.0 ou Microsoft Security Essentials.

Liens externes

{{Portage}}

Ransomware

Un ransomware (ou rançongiciel) est un programme malveillant qui bloque l’accès à votre poste ou à vos données, en réclamant une rançon pour le débloquer. La plupart du temps, les données du poste sont chiffrées (données locales mais aussi les données des partages réseaux). 

Le déchiffrement est impossible, et les pirates ne redonnent pas nécessairement l’accès aux données, même en payant la rançon, souvent par manque de compétence.

En pratique

Comment éviter d’être touché ?

Ce programme malveillant se propage via des mails contenant soit un fichier exécutable dans une archive, soit un lien vers un site web compromis. La vigilance reste de mise : n’ouvrez jamais des pièces-jointes de mails douteux, et ne cliquez jamais sur des fichiers exécutables (.exe, .scr, .cab…), même si le mail semble provenir d’un expéditeur connu.

Par ailleurs, une bonne pratique est de réaliser régulièrement des sauvegardes de ses données importantes, autant à titre professionnel qu’à titre personnel. 

Quelle réaction si j’ai ouvert une pièce-jointe suspecte ?

Tout d’abord, sachez qu’il ne sert en général à rien de payer la rançon : les pirates ne proposent que très rarement un service après vente…

Les seules actions à entreprendre sont de contacter immédiatement votre correspondant sécurité (si vous êtes en entreprise) et d’éteindre votre poste immédiatement pour arrêter le processus de chiffrement et limiter les dégâts, surtout si vous n’avez pas de sauvegarde.

Par ailleurs, il est conseillé de ne pas rallumer le PC ni de se connecter à sa session (dans le cas des utilisateurs Citrix) avant que la désinfection ne soit confirmée.

Creusons

Regardons ce qui s’est passé du côté de deux grandes affaires récentes.

WannaCrypt et NotPetya

Tout d’abord un grand bravo et un grand merci aux Shadow Brokers : pour avoir (officiellement) voulu empêcher la NSA de nous espionner (en révélant leurs outils), ils nous empêchent juste d’utiliser nos ordis. On dirait du Wikileaks ou des Anonymous…  

Ces empaffés sont loin de connaître le principe de responsible disclosure, même s’il est vrai que les outils qu’ils ont mis au jour utilisaient des failles corrigées par Microsoft, mais force est de constater que la mise-à-jour des systèmes informatiques est une discipline difficile, et qu’il est à peu près certain qu’une faille même corrigée peut être exploitée encore longtemps ! Leur seule excuse est qu’ils sont peut-être liés à des acteurs russes1 ou autres, dont l’intérêt est au contraire de perturber le plus possible les systèmes d’informations étrangers (et la NSA du même coup).

Premier bilan

Des dizaines de milliers d’ordinateurs contaminés2 par WannaCrypt ! Moi je dis : chapeau. Ces publications sont une aubaine pour les perturbateurs de tout poil (cybercriminels, états, groupe d’intérêts divers)3.

Cyberattaque

On a parlé dans les media de cyberattaque. Mais ça n’est pas parce que les dégâts sont visibles et parfois importants que nous sommes face à une vraie cyberattaque. Ici, on s’approche plus de la pêche à la ligne que dans la salve de roquettes : on balance un  hameçon et on regarde ce qu’on accroche au fil du temps. On est plus confronté à une cyberdéfaillance ou une cyberinfection qu’à une cyberattaque : l’ampleur des dégâts est proportionnelle à la négligence des services IT qui tardent à faire passer les mises-à-jour de sécurité ou à migrer sur des produits maintenus. Maintenant, les causes profondes peuvent être diverses (le budget IT étant sujet à tellement de contraintes…).

Et ensuite ?

Après, peu importe qui est derrière l’attaque (bien que ce mot soit galvaudé et hors de propos, cf. les propos de Jean-Marc Manach4, bien que je sois habituellement méfiant de ce qui vient de Slate.fr) : n’importe qui peut être derrière5, et c’est bien le problème. Il va falloir vivre avec cet héritage de la NSA et de toutes les agences de renseignements du monde dont une cible majeure est désormais nos ordinateurs ; enfin, les ordinateurs des méchants, mais les programmes malveillants ne font pas la différence, et si ces derniers tombent dans des mains criminelles ou inexpérimentées, le scenario de WannaCry se reproduira.

Il faudra redoubler d’attention lors des sauvegardes afin de ne pas sauvegarder les fichiers chiffrés ! Ou sinon s’assurer qu’une gestion de version conservera les versions précédentes, accessibles à l’utilisateur légitime. Microsoft a intégré une protection6 contre le chiffrement non souhaité dans ses solutions Office 365/OneDrive et Outlook. Reste que j’aimerai bien que Microsoft mette également une solution de chiffrement souhaité.

Quand à NotPetya, arrivé dans la foulée, d’autres éléments tendent à nous faire penser que l’apparence est trompeuse et qu’il s’agirait plutôt d’une véritable attaque informatique camouflée en ransomware ! Chiffrer des données sans garder aucun trace de la clé de chiffrement constitue un très bon moyen d’effacer ces données7, et donc potentiellement toutes les traces d’une activité illégale.

Voilà l’occasion de rappeler que l’attribution d’une attaque est souvent difficile.

Faut pas payer mais pourtant…

En 2019, les attaquants se sont rendus compte qu’une entreprise était bien plus disposée à payer pour récupérer ses données, car il est souvent plus facile de le faire en payant la rançon qu’en restaurant à partir de sauvegardes (on a vu en pratique que cela peut prendre plusieurs semaines). Exemples : Baltimore, Cognac

Ainsi, deux fois plus d’entreprises (40% en 2019 contre 19% en 2018) touchées par un ransomware on payé la rançon pour récupérer leurs données. Un signal très positif pour les cybercriminels… De son côté le FBI estime que 140 millions de dollars de rançon8 ont été versés en six ans.

Après, on peut aussi prendre une assurance couvrant ce risque, mais certaines d’entre elles conseillent, lorsque le sinistre se produit, de… payer la rançon ! Car cela coûte moins cher que de remettre en état le SI, et donc l’assureur aura moins d’argent à débourser en remboursant l’équivalent de la rançon… C’est du joli !

Voir aussi :

Des exemples à ne pas suivre

Voilà ce qui arrive quand on paye : ça recommence ! Une fois la rançon payée pour éviter la divulgation, que vont faire les pirates qui s’ennuie ? Ils vont redemander une rançon… Ca peut durer longtemps.

Les recommandations du FBI

De plus en plus sollicité sur le sujet, le FBI a émis les recommandations suivantes :

  • Ne pas payer !
  • Avoir des sauvegardes hors-ligne de ses données essentielles (et plus) ;
  • Avoir des copies des données essentielles en ligne dans le cloud (NDLA : chiffrées) ou sur un disque externe (un peu redondant avec la précédente, mais on peut interpréter cela comme « avoir plusieurs jeux de sauvegardes sur différents supports ») ;
  • Sécuriser ses sauvegardes, en les rendant inaccessibles aux intrus (au moins interdire les modifications et l’effacement) ;
  • Avoir un antivirus sur chaque terminal (çà ne mange pas de pain) ;
  • N’utiliser que des réseaux sûrs et maîtrisés (facile à dire !), imposer les VPN pour les connexions externes, éviter les Wifi publics ;
  • Utiliser une authentification renforcée (au moins deux facteurs robustes) ;
  • Mettre-à-jour les postes et applications (NDLA : et les infras) avec les correctifs de sécurité ASAP.

A bien y regarder, ce sont les conseils de base pour tout système informatique, quelle que soit la menace.

Sources

DNS

Le protocole DNS permet de connaître l’adresse réelle d’un serveur web. Plus précisément cela transforme le nom de domaine inclus dans une URL (adresse symbolique du genre https://secu.si) en adresse technique (adresse IP).

Pour cela, de très nombreux serveurs se répartissent la tâche sur toute la planète web. Pour des raisons d’efficacité, nous nous retrouvons souvent connectés directement à un serveur géré par notre fournisseur d’accès internet. Rien de bien fameux, sauf que les fournisseurs d’accès gardent souvent des traces, pour leur usage propre ou parce qu’on leur demande1.

Continuer la lecture

Microservices

L’architecture en microservices est une approche intéressante dans la construction de systèmes d’informations, en particulier sur des infrastructures cloud où ce type d’architecture s’adapte naturellement. Cependant, cela reste un choix d’architecture, dans la filiation du SOA, avec des cas d’usage plus ou moins adaptés1.

En premier lieu, construire une architecture en microservices implique de choisir un niveau de granularité (de finesse) des services, qui n’obéit à aucune règle prédéfinie : on propose généralement d’avoir un service par fonctionnalité, mais plus le service est gros, plus on se rapproche d’une application monolithique, et à l’inverse plus le service est fin, plus la complexité induite peut être importante. Il faut donc que le service (ou la fonctionnalité) soit suffisamment indépendante du reste mais pas trop complexe non plus.

La transition entre l’architecture monolithique des applications des années 90 et les applications à base de microservices actuelles. © PWC via JDN

Ensuite on les fait communiquer et interagir, soit par des API REST, soit par des échanges asynchrones. Ces derniers sont peu évoluées, mais robustes : leur but n’est pas d’ajouter des fonctionnalités mais uniquement d’assurer un échange fiable de messages et d’informations entre plusieurs services, justement en n’ayant que peu ou pas de couplage ou de friction.

Enfin, on orchestre ces services, en les déployant, en les monitorant, etc. Souvent, l’organisation DevOps est adaptée à cette architecture, en institutionnalisant l’indépendance des équipes et donc des services composants le système final. L’équipe DevOps doit en théorie être responsable de son service, y compris de son suivi en production, mais certains éléments comme la sécurité du service et la sécurité globale du système sont difficiles à positionner dans ce contexte.

Le passage à une architecture en microservices est l’occasion d’adopter une organisation de type DevOps. Ca manque toutefois un peu de sécurité, non ? © Adrian Cockcroft / Slideshare via JDN

Facebook

Facebook mérite à lui tout seul toute notre attention et toutes nos critiques. Vu la position dominante du réseau social, et son pouvoir d’influence, il devrait être irréprochable et il ne l’est pas. Un peu comme YouTube, d’ailleurs, quand on y pense.

Pire que les autres ?

La vie privée est (encore) un droit.

La vie privée est (encore un peu) un droit.

Je ne crois pas que FB soit pire que les autres, mais comme je le dis en introduction, vu sa position et la quantité de données personnelles qu’il charrie, la moindre erreur a des conséquences colossales. Cela dit, le business de FB est celui des données (très) personnelles, et pour attirer un maximum d’utilisateurs, il doit en collecter un maximum de façon à répondre à leur curiosité.

Un bug et ses conséquences

Prenons un exemple concret. En mai 20181, suite à une erreur lors d’un test interne, Facebook a modifié les paramètres de confidentialité de 14 millions d’utilisateurs. Le tir n’a été corrigé que plusieurs jours plus tard.

Trop tard

Comme souvent en informatique, Facebook a commis l’erreur inexcusable de ne penser aux conséquences de son activité que bien trop tard, alors que le site était déjà lancé et que le nombre d’utilisateurs dépassait l’imagination de ses concepteurs. Facebook a été créé en 2004, et ce n’est qu’en 2018 qu’il commence à se dire qu’il n’a peut-être pas bien pris en compte tous les enjeux de son activité, principalement sur la vie privée des utilisateurs, mais aussi sur l’influence qu’il peut avoir y compris sur des élections.

Notons.

  • L’application Facebook sur Android récupère des SMS et des données sur les appels (ArsTechnica)
  • Les données d’utilisateurs Facebook détournées (Digital Journal)
  • Deux milliards de comptes compromis par Cambridge Analytica (Hacker News)
  • Communiqué Facebook sur les données collectées (Facebook)
  • Analyse NextInpact sur une fuite de données concernant 50 millions d’utilisaterus (NextInpact)
  • Récupération de données sans même avoir de compte ! (The Register)

L’aveu

Je prends ça comme un aveu d’impuissance mais aussi d’incompétence : Mark Zuckerberg en appelle aux gouvernements pour l’aider à réguler le contenu des réseaux sociaux, dont le sien2. Trop fort : on fait des conneries, on a trop d’influence et on ne sait pas le gérer, donc faites-le pour nous.

Quelques fuites de données

Le coup du mot de passe

Un « incident » qui en dit long : mars 2019, on apprend que Facebook stockait des centaines de millions de mots de passe… en clair3 ! Il apparaît qu’il s’agit d’une erreur similaire à ce qu’ont pu connaître Twitter et Github4, à savoir des logs contenant le mot de passe en clair.

Est-ce volontaire ?

Je serai tenté de dire oui, mais sans aucune preuve. Il semble qu’ils aient déjà tellement de moyens de récupérer d’informations sur les utilisateurs qu’ils n’ont peut-être pas besoin de ça. Par contre, ça ne va pas les aider en cette période de tentative de reconquérir la confiance des utilisateurs…

Relativisons

Le problème ne touche que l’application Facebook Lite. Donc uniquement quelques centaines de millions d’utilisateurs, et non pas le milliard++ d’inscrits. Et ça ne date que de 2012. Et les logs n’étaient pas accessibles depuis l’extérieur.

La défense périmétrique est, on le sait, infranchissable…

146 Go

Rien de moins ! Et stocké sur des buckets s3 en clair ! Vu en avril 20195, on est presque dans un cas d’école. Ce qu’on comprend dans cette affaire, c’est que des tiers ont accès à une quantité impressionnantes de données sur les utilisateurs Facebook, et donc que pour espérer un peu de sécurité sur FB, il faudrait à la fois que FB réduise la quantité (et le type) de données accessibles aux tiers (ce qui serait contraire à leur modèle économique) et que les tiers en question soient eux aussi plus fiables. Autant dire que ça n’arrivera jamais.

Plus d’infos sur le site d’UpGuard.

Autres « bugs »

  • Mai 2019 : une faille dans WhatsApp (= Facebook) permet l’installation de logiciel malveillant6 sans aucune action utilisateur.
  • Fin 2019, pas de chance : un disque dur non chiffré contenant des données sur les employés de FB a été volé dans une voiture (à sourcer).

Au sujet de WhatsApp, zataz.com propose une analyse intéressante7 selon laquelle cette appli ne sera jamais vraiment sécurisée. Ce qui est surtout intéressant est de remarquer que Telegram est interdit en Iran ou en Russie, et pas WhatsApp qui reste autorisé. Une explication ?

Le coup de la panne

Sous surveillance

Il y avait déjà eu un précédent, a priori mal respecté8

DMZ

J’ai toujours eu du mal à cerner la notion de DMZ. Pour moi, il s’agit d’une zone sans arme, et je vois difficilement aller au combat (à savoir : se connecter à internet) sans être un minimum équipé.

Pour la clarté de l’explication, le local sera le gentil, l’extérieur sera le méchant, et le gentil cherche à se protéger du méchant.

Dans ce contexte, une DMZ est bien une zone réseau à part, servant de tampon entre les deux zones de conflit (le réseau local et le réseau extérieur, qui est en général internet). Son rôle est bien d’éviter une propagation des menaces de part et d’autre, mais les moyens employés sont bien plus coercitifs qu’un gentleman agreement, avec la différence notable qu’une des parties (le gentil) s’autorise à militariser tout ce qu’il veut, et que le but d’une DMZ réseau est de désarmer uniquement l’attaquant, et non les deux parties simultanément.

DMZ avec un seul pare-feu

Source : wikimedia.org.

Cette solution est simple à mettre en place, mais elle est moins sûre dans l’absolu, car tout repose sur une seule brique : le pare-feu. Cela suffit si la zone à protéger n’est pas trop critique, mais tout problème sur le pare-feu impacte l’efficacité de ce type de DMZ. C’est ce qu’on appelle une SPOF (Single Point Of Failure).

De plus, l’équipement utilisé pour le pare-feu doit savoir gérer tous les types de flux, ainsi que le cloisonnement demandé, ce qui en fait un équipement complexe.

DMZ avec deux pare-feu

Cette architecture est la plus sécurisée, car même si un des pare-feu est attaqué, l’autre reste disponible.

Source : wikimedia.org.

Ici, tout flux provenant d’internet arrive sur le 1er pare-feu, et il est redirigé vers la DMZ : il est donc impossbile d’aller dans le réseau local.

A l’inverse, un utilisateur du réseau local (LAN) peut accéder à la DMZ pour aller chercher ce dont il a besoin. Il peut aussi éventuellement accéder à internet, si on lui en donne l’autorisation (c’est un choix qui n’influe pas directement sur le niveau de sécurité de la DMZ).

Enfin, un équipement se trouvant à l’intérieur de la DMZ n’a accès… à rien : il est bloqué par les deux pare-feu. Il peut y avoir des exceptions, par exemple pour des mises-à-jour logicielles des équipements de la DMZ.

Sources

http://www.commentcamarche.net/contents/995-protection-introduction-a-la-securite-des-reseaux
https://www.1and1.fr/digitalguide/serveur/securite/quest-ce-quune-zone-demilitarisee-dmz/

SSL/TLS

SSL et TLS sont deux noms différents pour la même chose. Enfin presque : il y a eu plusieurs versions de SSL (notamment v2 et v3) puis l’appellation TLS a remplacé SSL. Nous avons donc eu TLS 1.0, puis TLS 1.1 et maintenant TLS 1.2.

SSL est un protocole permettant de sécuriser des échanges de flux réseaux. Comme tout protocole, il n’est constitué que de spécifications : on dit quoi faire et comment. Après, ce sont des programmes (des librairies…) qui implémentent (mettent en oeuvre en pratique) ce protocole.

SuperFish

Etablissement d’une session TLS

Avant d’échanger des messages de façon sécurisée, il faut commencer par se mettre d’accord sur la façon de faire.

Hello client (ClientHello)

Le 1er message est envoyé par le client au serveur. Ce message contient :

  • Le numéro de version de la version TLS la plus récente supportée par le client ;
  • la date et heure client ;
  • 28 octets aléatoires ;
  • un numéro de session (en cas de reprise de session) ;
  • la liste des méthodes cryptographiques supportées par le client ;
  • la liste des méthode de compression supportées ;
  • certaines valeurs spécifiques comme le nom du service demandé (Server Name Indication).

Premier retour serveur

Le serveur va ensuite envoyer un paquet de messages pour avancer dans le dialogue.

Hello serveur (ServerHello)

Le serveur va d’abord poliment renvoyer son bonjour. Il va indiquer :

  • La version du protocole SSL/TLS qu’il souhaite utiliser ;
  • la date et heure côté serveur ;
  • 28 octets aléatoires ;
  • un numéro de session si besoin ;
  • l’algorithme cryptographique et l’algorithme de compression retenus pour cette session, en fonction de ce que supporte le client.

Présentation des certificats du serveur (Certificate)

Le serveur envoie ensuite ses certificats.

à approfondir

Echange de clé serveur (ServerKeyExchange)

Le contenu de cette partie est variable. Elle est fonction de ce qui a été négocié auparavant, principalement des algorithmes cryptographiques retenus.

  • Dans le cas d’un échange de type Diffie-Hellman, ce message contient les paramètres de cet échange. Ils sont générés aléatoirement par le serveur et signés par la clé privée du serveur (sauf dans le cas d’un échangé DH/ECDH anonyme).
  • Dans les autres cas, ce message n’existe pas car les informations nécessaires sont dans le certificat.

Fin du bonjour (HelloDone)

Ce message marque la fin de cette étape. Mais ça n’est pas fini pour autant.

Pre-master secret

Voici maintenant une étape tout aussi importante dans l’établissement de l’échange : l’échange d’un pre-master secret, valeur essentielle pour la connexion, et qui ne doit être connue que des deux parties (Alice et Bob). Il existe plusieurs méthodes pour cela :

  • RSA : la valeur secrète est générée par le client, aléatoirement, et elle est envoyée au serveur chiffrée avec la clé publique du serveur (donc seul le serveur peut la déchiffrer), dans un message ClientKeyExchange.
  • Diffie-Hellman ou Elliptic Curve Diffie-Hellman (DH ou ECDH) : la valeur secrète est négociée via l’algorithme de Diffie-Hellman. Il en existe une variante basée sur les courbes elliptiques. Les paramètres côté serveur sont inclus dans le certificat ; côté client, c’est également dans le certificat si le client en présente un, sinon il doit en générer aléatoirement.
  • Diffie-Hellman Ephemeral (DHE) avec également une variante basée sur les courbes elliptiques (ECDHE) : les valeurs secrètes sont générées aléatoirement, dans tous les cas, et de façon unique pour chaque transaction. Côté serveur, les paramètres sont signés avec sa clé privée.
  • Diffie-Hellman anonyme, avec variante EC : C’est du DHE mais sans chiffrement côté serveur. En conséquence, cette négociation est vulnérable aux attaques MITM.

On en parle, hélas

Oui, on parle de SSL malheureusement, car on se rend compte de son importance et de la menace représentée par les failles du protocole ou de son implémentations. FreakPoodle ou Heartbleed sont des exemples de failles ayant fortement impacté le monde informatique mais aussi, indirectement, les utilisateurs.

Quelles versions utiliser ?

Le conseil général est le suivant : toujours utiliser la dernièr version quand c’est possible.

Est-ce toujours possible ?

Comme le titre le laisse entendre : non. Comme vu plus haut, la connexion en SSL/TLS se fait sur la base d’une négociation entre le serveur (le site internet) et le client (le navigateur web). Les deux essayent généralement d’utiliser les versions les plus récentes et les plus sécurisées, mais il arrive souvent que les navigateurs ne soient pas à jour et ne connaissent tout simplement pas les versions récentes de TLS.

Y a-t-il des versions à éviter ?

Oui, car certaines versions contiennent des failles intrinsèques (par exemple Poodle). Par ailleurs, avec le temps, certaines attaquent deviennent plus faciles : soit parce qu’elles sont mieux connues, soit parce que la puissance de calcul nécessaire est plus facilement accessible. A fin juin 2015, on considère que SSL v2 et SSL v31 ne doivent plus être utilisées.

Liens

Liens internes

Liens externes