Ransomware : pris à la gorge, un hébergeur coréen débourse un million de dollars
To pay or not to pay
Le 21 juin 2017 à 06h30
7 min
Internet
Internet
En Corée du Sud, une entreprise s’est vue contrainte de payer plus d’un million de dollars de rançon. Ses serveurs, infectés par le ransomware Erebus, hébergeaient les données de nombreux clients. Un cas qui rappelle encore les dangers de ce type de malware, ainsi que l’importance des mises à jour.
Un ransomware est pour rappel un logiciel malveillant dont la finalité est d’obtenir une rançon. Pour y parvenir, la technique employée est toujours la même : chiffrer les données de la machine et menacer l’utilisateur de ne plus jamais y avoir accès s’il ne s’acquitte pas de la somme demandée. Celle-ci est presque toujours exigée en crypto-monnaie, le plus souvent en bitcoins.
Pour autant, la « qualité » et la dangerosité des ransomwares varient. Parfois, des failles dans leur code permettent de créer un logiciel capable de redonner accès aux données, comme on l’a vu avec WannaCrypt. Mais Erebus, qui a infecté la société coréenne Nayana, n’en a a priori aucune exploitable.
De très vieux composants, un nombre élevé de failles potentielles
Comme indiqué par Trend Micro, le ransomware Erebus n’est pas nouveau. On le trouvait déjà l’année dernière, exploitant diverses failles de sécurité selon l’époque, dont certaines dans le lecteur Flash.
Dans le cas présent, on ne sait pas réellement comment il s’est infiltré dans Nayana. Cependant, comme relevé par la société de sécurité, il est fort probable que là encore, des vulnérabilités aient été exploitées. Pourquoi ? Parce que la société coréenne, qui officie dans l’hébergement web, utilisaient des composants logiciels particulièrement anciens.
Les serveurs eux-mêmes utilisaient ainsi une vieille distribution Linux dont le kernel était en version 2.6.24.2, vieille de plusieurs années. Considérant la vitesse à laquelle sont découvertes les failles, il en existait nécessairement que les pirates pouvaient utiliser.
Les soucis détectés ne s’arrêtent pas là. Les versions utilisées d’Apache et PHP pour le site principal de Nayana étaient respectivement les 1.3.36 et 5.1.4, toutes deux datent de 2006. L’analyse est ici la même : plus de dix ans se sont écoulés depuis et les failles de sécurité à disposition des pirates étaient probablement nombreuses.
Un fonctionnement impitoyable
Une fois en place, Erebus n’avait qu’à remplir sa mission. Documents, archives, bases de données et autres fichiers multimédias étaient ainsi passés à la moulinette du malware, qui les renommait ensuite avec l’extension .ecrypt. En tout, 433 formats sont pris en charge.
Erebus fait partie de ce type de malware qui utilise plusieurs algorithmes différents et un découpage de fichier en plusieurs couches. Au-delà de son entête, on trouve ainsi le contenu du fichier chiffré en RC4 et divisé en blocs de 500 ko, tandis que le nom dudit fichier est lui chiffré en RSA-2048. Le résultat final, en .ecrypt, contient la clé RC4, différente pour chaque fichier. Cependant, elle est chiffrée une première fois en AES, puis une seconde en RSA-2048.
Il s’agit en fait de la clé privée. La clé publique en RSA-2048 est de son côté partagée. Selon Trend Micro, un tel fonctionnement rend impossible tout décryptage des données sans posséder la clé. Ce qui amène immanquablement la question de la rançon.
Une rançon très élevée, qui ne doit pas faire des émules
Conscients probablement que leur malware ne pouvait être contourné et que la victime manipulait les données de nombreux clients (153 serveurs infectés pour un total de plus de 3 400 sites commerciaux), les pirates ont réclamé une rançon salée.
Nayana, qui raconte elle-même ses mésaventures dans une série de notes sur son propre site, indique ainsi que la somme demandée initialement était de 550 bitcoins, soit l’équivalent d’environ 1,6 million de dollars. L’entreprise ajoute qu’elle a cherché à négocier cette rançon, ce que les pirates ont accepté. Résultat, la somme est descendue à 397,6 bitcoins, soit environ un million de dollars, réglables en trois fois.
Le 17 juin, soit il y a trois jours seulement, Nayana indiquait que le deuxième des trois paiements avait été fait. La logique des pirates est simple : chacun permet de retrouver l’accès à un tiers des installations. Le 18 juin, la société déclarait redémarrer ses serveurs par groupes, mais des problèmes se manifestaient dans le deuxième lot de machines libérées d’Erebus. Le dernier paiement ne doit être fait que lorsque les deux premiers tiers des machines seront opérationnels.
Un véritable cas d’école
L’exemple de Nayana synthétise à lui seul tout ce que l’on peut dire d’un ransomware et les problématiques qu’il pose, tant aux victimes qu’aux experts en sécurité.
Les ransomwares peuvent être utilisés de plusieurs manières. Le cas le plus courant est celui d’un logiciel malveillant infectant une machine unique et réclamant une rançon à un utilisateur « simple ». Une petite somme, mais répétée autant de fois que possible. Au contraire, un ransomware peut viser des machines moins fréquentes, mais à l’impact plus important.
Comme on l’a vu au début du mois, des milliers de bases de données sont contaminées ou potentiellement vulnérables à de tels malwares. Puisque les entreprises visées stockent potentiellement des données sensibles et/ou appartenant à des clients, en retrouver l’accès peut faire la différence entre une survie et un dépôt de bilan. Dès lors, comment suivre la recommandation officielle qui est, le plus souvent, de ne pas payer la rançon ?
La question revient perpétuellement, se posant à chaque nouvelle victime. Dans le cas de Nayana cependant, elle constitue une dure leçon sur la nécessité absolue de n’utiliser que des composants logiciels parfaitement à jour. Les vulnérabilités, comme on a pu le voir de nombreuses fois depuis les révélations Snowden, font l’objet d’un véritable trafic. Elles sont ainsi vendues comme cyberarmes dans des marchés noirs et gris, le FBI et l’armée américaine n’hésitant pas par exemple à en acheter, particulièrement celles de type 0-day.
Le brutal chemin vers la sécurité
Le simple fait d’installer les mises à jour de sécurité n’est par ailleurs pas une garantie de protection. Par définition, les patchs ne colmatent que les brèches dont les éditeurs sont au courant. Ces mises à jour doivent donc être accompagnées de mesures d’hygiène informatique, toujours les mêmes : sauvegarde des fichiers, suppression de tout composant ou logiciel qui n’est pas utilisé, n’attribuer que le moins de privilèges possibles à chaque utilisateur, surveiller les fichiers journaux et ainsi de suite. Trend Micro en liste d’ailleurs une série à la fin de son billet.
Il est probable que les entreprises finiront par s’adapter petit à petit à ce type de menace en faisant évoluer leurs règles, quand ce n’est pas déjà le cas. Signe qui ne trompe pas, les éditeurs de solutions de sécurité tablent de plus en plus sur des solutions qui vont bien au-delà du simple antivirus, en renforçant leurs offres d’apprentissage profond et de surveillance distante. Mais au vu des cas que l’on peut voir encore en 2017, un constat s’impose : la route vers la sécurité aura été apprise par beaucoup de manière bien brutale.
Ransomware : pris à la gorge, un hébergeur coréen débourse un million de dollars
-
De très vieux composants, un nombre élevé de failles potentielles
-
Un fonctionnement impitoyable
-
Une rançon très élevée, qui ne doit pas faire des émules
-
Un véritable cas d’école
-
Le brutal chemin vers la sécurité
Commentaires (60)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 21/06/2017 à 07h05
Et tout simplement faire de vrais sauvegardes (sur bandes) avec un durée de rétention suffisante ? Non ? Personnes ? A croire que ça n’effleure même pas l’esprit des gens. Désespérant.
Le 21/06/2017 à 07h06
Le 21/06/2017 à 07h33
Le 21/06/2017 à 07h34
[troll]
Tient bizarre sur cette news on verra personne dire que Linux c’est plus mieux trop bien parce que c’est impossible à pirater.
[/troll]
Dette de 10 ans de mise à jour de sécurité… La ou je bosse (plus ou moins le même domaine), on est à jour niveau sécurité dans la semaine (voir la journée) pour la plupart des serveurs, pour les postes utilisateurs c’est la méthode “pas le choix” (comme ce que fait Microsoft au final) quelque soit l’os.
Pour ceux qui parlent de sauvegarde erebus installe bien avant son exécution (plusieurs semaines voir mois) un driver Bluetooth qui est exécuté dès le lancement de l’os. bien sur tu as la solution si les disques ne sont pas chiffrés de monter le disque sur une autre machine pour le lire mais quel en serait le coup ? a mon avis s’ils ont des milliers de serveurs le coup dépasserait facilement le million.
Et pour finir, maintenir apache à jour va être de pus en plus crucial apache a de nombreuses failles permettant d’escalader de shell à root (voir il tourne toujours en root), cela va certainement être l’une des cibles de choix des prochains mois.
Le 21/06/2017 à 07h34
Vu l’ancienneté de leurs systèmes, il y a fort a parier que des failles d’élévation de privilège étaient disponibles.
Comme dit précédemment, au delà d’avoir des systèmes à jour, c’est un système de backup efficace qui aurait du être mis en place.
Le 21/06/2017 à 07h45
Cela se fait tjs ,hein ….en plus d’un serveur de sauvegarde, etc….
Le 21/06/2017 à 07h48
Le 21/06/2017 à 07h54
Les bandes sont toujours une bonne solution.
Le 21/06/2017 à 07h58
Le 21/06/2017 à 08h21
Le problème c’est que l’hébergeur va retrouver ses données, mais il risque de perdre ses clients. Voire se prendre des procès…
J’espère au moins que cela lui servira de leçon, et qu’à l’avenir il fera des sauvegardes et qu’il mettra à jour. En même temps ce n’est pas ce que j’appelle un professionnel s’il utilise des versions vieilles de 10 ans… " />
Le 21/06/2017 à 08h24
Le 21/06/2017 à 08h31
[HS]
Justement j’ai refusé ce matin un job de développeur, où on me proposait une évolution jusqu’au poste de CTO, sauf que le boss fait tourner ses applis sur un vieux framework (sorti en 2006, qui a connu 2 nouvelles versions majeures depuis). J’ai demandé s’il souhaitait migrer à l’avenir, il me répond “oh non ça tourne bien ainsi, j’ai pas d’argent et de temps à perdre pour ça, il faut me montrer par a+b ce que ça apporte de migrer”. Il n’a pas compris pouquoi je refusais le poste, pourtant c’est sympa de faire CTO sur une stack technique antique et qui n’évolue pas " /> Donc j’attends qu’il se fasse hacker, et je lui reproposerai mes services avec une petite majoration de mon tarif " />
[/HS]
Le 21/06/2017 à 08h35
C’est aussi très résistant, facile à déplacer au besoin et ça se range bien dans les coffres, notamment quand il y a besoin d’archivage longue durée.
Pas de problème de foudroyage électrique, le media n’est pas sensible a une attaque virus via le réseau vu qu’il est complétement détaché et inaccessible.
Le 21/06/2017 à 08h37
Prend les devants et hack le (si tu en as la capacité et sans faire de dégât irréparable " />)
“Voilà la preuve”.
Le 21/06/2017 à 08h38
Le 21/06/2017 à 08h38
Tu « attends » qu’il se fasse hacker ? " />
Le 21/06/2017 à 13h29
Le 21/06/2017 à 14h01
Le 21/06/2017 à 14h04
si les mots de passes sont stockés avec un vieux truc genre somme MD5
MD5 en 1985 ? " /> " />
Sérieux, je ne vais pas m’étendre sur le chiffrage utilisé, mais quand je dis zéro sécurité, ce n’est peut-être pas tout à fait zéro, mais c’est pas loin. " />
Le 21/06/2017 à 15h39
“4h d’arrêt c’est pas la fin du monde”, dépend de l’impact de ton système mais si c’est potentiellement 4h de commandes perdues c’est une jolie perte sèche…
Le coup de la sécurité / SLA est exponentiel selon la criticité, la multiplicité et la taille de ton système.
Le 21/06/2017 à 15h53
Le 21/06/2017 à 15h59
Le 21/06/2017 à 16h42
Le 21/06/2017 à 18h50
Le 21/06/2017 à 19h52
M’en fout, moi je fait des sauvegardes " />.
Le 21/06/2017 à 20h11
Le 21/06/2017 à 20h56
Le 21/06/2017 à 21h47
heu.. tu décris exactement ce que j’ai dit.
Le Backup c’est une copie qui sert de secours en cas de perte de l’original.
L’archive c’est la donnée originale mise hors-ligne (pour gagner de la place).
Le 21/06/2017 à 22h01
C’est très daté comme manière de faire, même pour moi.
Le backup sur bande c’était la solution des années 80⁄90 car le stockage sur disque-dur coutait très cher, alors que les bandes beaucoup moins. Ca a été détrône un moment par les DVD-RW. Mais en 2017, le prix du stockage sur disque-dur (ou même en cloud puisque c’est la mode) a considérablement diminué.
Et puis le backup la nuit c’était pour les vieux mainframes avec des I/O poussifs et la nécessité de ne pas toucher aux fichiers pendant la copie. A présent on peut sauvegarder les donnés en journée sans pénaliser les I/O et sans empêcher les accès concurrents.
Le 22/06/2017 à 00h31
Oui, les problématiques me paraissent un peu vieilles, je ne pratique pas trop mais vive le snapshot instantané avec les nouveaux filesystems et autres archis SAN. On avait pas ces solutions à l’époque pré-web sur PC.
" />
Le 22/06/2017 à 03h43
méfie toi des snapshots de VM, si tu veux récupérer l’espace disque, il faut reconstruire un nouveau fichier et ça prend autant d’espace disque que la somme des snapshots. enfin c’était comme ça sous HyperV de windows 2008 en tout cas
Le 22/06/2017 à 07h09
Le 21/06/2017 à 08h39
" />" />
Le 21/06/2017 à 08h40
Le 21/06/2017 à 08h43
Sans parler de la fiabilité… Les bandes pro (LTO etc) sont beaucoup, beaucoup plus fiables dans le temps que les disques durs. Et je parle même pas des supports WORM.
Le 21/06/2017 à 08h44
Le 21/06/2017 à 08h46
Les serveurs eux-mêmes utilisaient ainsi une vieille distribution Linux dont le kernel était en version 2.6.24.2, vieille de plusieurs années. Considérant la vitesse à laquelle sont découvertes les failles, il en existait nécessairement que les pirates pouvaient utiliser.
Fake ! Y a pas de virus sur Linux, c’est internet qui l’a dit.
News putaclick avec contenu bidon " />
" />
Le 21/06/2017 à 09h00
Ah oui, moi je corrige les problèmes, je ne les cause pas (enfin, pas volontairement " /> " />)
Le 21/06/2017 à 09h29
Les serveurs eux-mêmes utilisaient ainsi une vieille distribution Linux dont le kernel était en version 2.6.24.2, vieille de plusieurs années.
Les soucis détectés ne s’arrêtent pas là. Les versions utilisées d’Apache et PHP pour le site principal de Nayana étaient respectivement les 1.3.36 et 5.1.4, toutes deux datent de 2006.
Non mais sérieux…
J’aurais augmenté la rançon rien que pour ça
" />
Le 21/06/2017 à 09h31
C’est tellement désespérant que c’en est à se flinguer
Ce qu’ils ont fait
" />
Le 21/06/2017 à 09h35
Le 21/06/2017 à 09h42
Non : Les bandes sont toujours la solution à long terme ;)
Le 21/06/2017 à 09h44
#jvachez " />
Le 21/06/2017 à 10h01
Ouh putain, ca fait longtemps que j’avais pas entendu son nom à celui là " />
Le 21/06/2017 à 11h24
Le 21/06/2017 à 11h31
Le 21/06/2017 à 12h15
Le 21/06/2017 à 12h37
Et vous venez de perdre une belle place pour des motifs éthiques vaseux, comme si une plateforme moderne ou un ERP flambant neuf était la garantie d’une sécurité totale. Il n’en est rien, vous le savez.
J’ai une place depuis 17ans comme dev (je suis DSI aussi) sur un ERP écrit en BASIC qui date d’il y a 30 ans et qui roule impec sur un W2000 avec 500-1000 personnes dessus. L’ERP a zéro sécurité, chacun des employés peut effacer l’ERP (base de données, noyau) dans la minute. Le serveur n’a pas d’antivirus (incompatibilité avec l’ERP), pas de backup (juste des snapshots de la VM). Et ? Rien.
Est-ce qu’il n’est jamais rien arrivé ? Non :
· infecté par un ransomware=>restaure d’un backup, 4h d’arrêt, c’est pas la fin du monde.
· répertoires déplacés par erreur=>restaurés
· fichiers ouverts avec un éditeur texte (=endommagé)=>réparés
Mais c’est si peu en regard de l’investissement pour le remplacer (en cours).
Quelqu’un d’autre à pris la place et en est sûrement heureux, comme moi je le suis.
Le 22/06/2017 à 07h41
Nope , malheureusement ….
Pour ne pas les citer, un service clef de edf nucléaire …ont des saves ET des backups sur bande ….
Le 22/06/2017 à 08h24
+1 sur le résistant. Ça comprend le “résistant au temps” : environ 30 ans contre moins de 10 ans pour la flash, moins de 5 ans pour le disque dur et le CD.
Le 22/06/2017 à 08h29
Va visiter le CERN aussi (gros cas particulier). La bande est le meilleur moyen qu’ils aient trouvé pour
* Résistance au temps, attaques, etc
* Faible consommation électrique (gros hangar climatisé + robot qui va chercher les tapes)
* Bonne densité de stockage, très bonne vitesse d’écriture/lecture
* Assez bon marché
* …
Et oui, tout ça pour des backups qui sont accédés relativement régulièrement (pas trop quand même héhé)
Les résultats des expériences sont dumpées en instantanné sur RAM/SSD (chais plus trop), puis directement après sur bandes.
Sauf erreur c’est du LTO qu’ils utilisent :
Wikipedia
Le 22/06/2017 à 09h24
Le 22/06/2017 à 09h30
Chacun son opinion
Mais demande à Google pourquoi ils s’en sont sortis en février 2011 ou Amazon en 2013 … les bandes … c’est “has been” mais ça marche parce que c’est offline.
Si HP investit et vend encore beaucoup de robots et IBM des TS1150 c’est que les gros clients font la différence entre sauvegarde et continuité d’opération.
Sauvegarder quelques milliers de serveurs tous les jours ne se fait pas nécessairement sur disques.Souvent les snaps ne sont la que pour être copiés sur bande
Sauvegarder des données en live dans la journée sert plus souvent à faire de la continuité d’opération pour se protèger en cas de panne.( on fait aussi de la copie synchrone mais hélas en dessous de 30km de distance)
Mais dans le cas du ransomware,( ou d’une autre action maléfique virus ou autre ) les données copiées risquent grandement d’être inutilisables car en ligne au moment du massacre et donc affectées.
La théorie c’est sympa, mais l’incrémental live ou la log transactionelle en live ont leurs limites.
L’intégrité des données n’est pas le même combat que celui de leur présence.
De plus emmener quelques k7 de 10to ou 100to chacune à l’autre bout du pays ou à distance suffisante pour éviter une cata est plus pratique que de démonter les disques chaque jour " />.
Alors c’est peut-être antique ( dans le jargon :PTAM .. Pickup Truck Access Method ) mais essayer de backuper quelques centaines de téra via le réseau est compliqué en 24h même avec de gros tuyaux et garder les quelques péta pas facile sur disque ( et cher ) .
Les bandes ont encore de beaux jours devant elles à cause de leur vitesse et de leur capacité et surtout du fait qu’elles sont offline et je suis presque certain que dans le cas de notre hébergeur coréen , s’il avait eu des sauvegardes , il n’aurait pas eu à payer la rançon .
Car si on y réfléchit un erase . ( " /> ) aurait eu les même conséquences.
Après il faut voir le ROI d’une solution robotique adéquate.( c’est quand même pas donné) Mais toutes les grosses banques CA, BNP,SG Natexis,CE ou assurances,google, amazon,EDF, Agirc Arcco, PSA ou Renault en ont et en auront pour un bon bout de temps.
Le 22/06/2017 à 12h23
Oui oui oui
Le 23/06/2017 à 14h02
merci pour l’explication de Dette Technique
Le 25/06/2017 à 13h31
Je ne pige pas.
Les bandes j’ai testé, plus jamais je veux entendre parler de cette cochonnerie, ça coute un bras, il faut une bande par jour, une bande pour une semaine, une bande pour un mois, une bande de nettoyage, changer toutes les bandes au bout d’un an, tout ça pour s’apercevoir malgré tout que lorsque la sauvegarde indique un état “OK, j’ai fini et tout s’est bien passé après 12h de sauvegarde” : on peut pas relire la bande parce que la tête à fait je ne sais quoi au dernier moment provoquant la destruction de la bande.
Non merci, une vrai sauvegarde c’est une machine séparé et dans le meilleur des cas déporté qui se connecte au moment voulu sur les serveurs à sauvegarder (et non l’inverse comme tout le monde fait) avec par exemple un système de fichier ZFS digne de ce nom…
Le 26/06/2017 à 10h35
Je te renvois au commentaire de JoePike quelques messages au dessus.
Tout est question d’échelle. Peut être que ça n’était pas adéquat à ton niveau et/ou que le matériel ne suivait pas, mais je me répète : à très gros volume c’est encore indispensable.
Le 21/06/2017 à 06h38
Mais cela prend combien de temps pour faire autant de dégats ?
Je ne comprend pas le fait qu’on ne remette pas en ligne une version de sauvegarde non polluée.
Ou alors on n’a pas de sauvegarde ?
c’est une vraie question !
Le 21/06/2017 à 06h41
Si je comprends bien, l’hébergeur a cumulé une dette technique d’un million de dollars au cours des dix dernières années. De quoi financer deux administrateurs système à temps plein.
Le 21/06/2017 à 06h48
Une solution à développer pour peut-être limiter la casse : bloquer l’accès par application et par utilisateur avec des autorisations très spécifiques (clefs d’accès…). Les fichiers ne pourraient plus être modifiés par n’importe qui, n’importe quoi ou n’importe comment.