Andrey Kuzmin - stock.adobe.com

Ransomware : pourquoi le silence des victimes peut être dangereux

Il peut être tentant de payer la rançon, dans l’espoir d’éviter que les données dérobées par les cybercriminels durant leur attaque ne soient divulguées. Mais rien ne garantit que le paiement permette d’atteindre effectivement cet objectif.

Les cybercriminels utilisant les ransomwares Conti, Sodinikibi ou Avaddon, pour ne citer qu’eux, pratiquent la double-extorsion : le chiffrement des données de leur victime n’est que la dernière étape d’une attaque, parfois longue et marquée par un vol de données. Après le déclenchement du chiffrement, les attaquants menacent leur victime de divulguer ces données si elle refuse de verser une rançon.

Suite de l'article ci-dessous

Dès lors, il peut être plus que tentant de céder aux exigences des cybertruands, pour éviter une telle divulgation. Ils l’ont bien compris, et c’est pour cela qu’ils ont adopté cette approche.

Cette tentation, il n’est pas rare que des victimes y cèdent. Mais voilà, malgré toutes les belles promesses des attaquants et leur façon de se présenter comme un « business », est-il vraiment raisonnable de leur faire confiance ? Peut-on vraiment croire qu’ils présentent bien, lors de la négociation, toutes les données qu’ils ont volées ? Et quand ils fournissent de prétendues preuves d’effacement, peut-on être confiant dans le fait qu’ils n’ont rien conservé ? Non, de toute évidence.

L’épisode d’Elior en a fait la démonstration, hormis sur le volet paiement de rançon, dont le groupe assure qu’il n’a pas eu lieu. Plusieurs mois après une cyberattaque dont l’intéressé avait préféré ne pas parler, un cybertruand impliqué nous a montré des données d’authentification dérobées dans le système d’information de sa victime ; qu’il détenait donc encore. Cela s’arrêtait peut-être là, mais rien ne permet d’en avoir la certitude. Surtout, l’assaillant s’était ménagé de quoi revenir, au cas où Elior n’aurait pas procédé à une enquête et un nettoyage en profondeur.

Seul Elior peut juger de l’importance et de la sensibilité des données qui lui avaient été dérobées par l’affidé de Revil/Sodinokibi. Mais la question prend une tout autre dimension lorsque les attaquants ont eu accès à du code source, notamment celui d’un fournisseur de solutions IT. C’est justement ce qu’a affirmé l’affidé Conti ayant attaqué ExaGrid, entre avril et mai derniers.

Ce spécialiste du stockage pourrait bien avoir décidé de verser la rançon pour protéger son code source. Mais rien ne garantit que les truands, malgré leurs affirmations, n’en ont pas conservé une copie. Ce code source pourrait déjà faire l’objet de travaux de rétro-ingénierie par des attaquants en quête de vulnérabilités à exploiter.

Dans le cas d’une telle attaque, la victime doit au moins à ses clients une transparence spontanée. Et ce afin d’assurer le fait que son code fait l’objet d’un réexamen approfondi, visant à assurer qu’aucune vulnérabilité non décelée jusque-là ne risque d’en compromettre le bon fonctionnement, dans le cas d’une cyberattaque conduite contre l’un des clients finaux. Après tout, dans le cas d’ExaGrid, on parle bien de systèmes de stockage pensés notamment pour aider à remonter la pente en cas d’attaque de ransomware…

En outre, la sécurité du système d’information du constructeur a été compromise. L’histoire récente a montré quel risque cela pouvait représenter, notamment avec SolarWinds. Lequel n’a d’ailleurs pas manqué de montrer rapidement l’exemple en matière de transparence. Parce que l’éditeur l’a compris : dans une telle situation, il est essentiel d’assurer à ses clients que son système d’information est de nouveau fermé aux assaillants ; que ses processus de build sont sûrs et qu’il n’y a plus à craindre la présence d’une éventuelle porte dérobée dans une mise à jour.

Quel risque aurait fait peser sur son écosystème SolarWinds en se murant dans le silence ? Et pendant combien de temps ? Ou bien Codecov…, sans compter les entreprises utilisatrices de leurs produits et services. Heureusement, eux semblent avoir compris. Surtout, ils ont pu constater la nature du risque en question pour leurs clients, dans la durée.

Mais ExaGrid ne donne pas l’impression d’avoir retenu la leçon apprise par d’autres avant lui, dans la douleur. Le constructeur n’a pas répondu à nos demandes de commentaires et d’informations complémentaires. Il n’en a pas même accusé réception. Mais c’est peut-être son PDG, Bill Andrews, qui envoie le plus préoccupant des signaux.

À notre confrère Chris Mellor, de Blocks & files, le patron d’ExaGrid s’est ainsi contenté d’indiquer que son entreprise « ne discute pas de la sécurité de son réseau, bonne ou mauvaise ». Semblant vouloir rassurer, il a souligné à notre confrère, à au moins deux reprises que « l’entreprise est pleinement opérationnelle et conduit ses affaires comme d’habitude ». Las, ce « comme d’habitude » sonne là tel un « comme avant ». Et ce n’est pas franchement rassurant.

Pour approfondir sur Gestion de la sécurité

Close