Archives quotidiennes :

Entreprise

Les options de configuration : la boîte de Pandore des pirates

Les détails revêtent d’une importance cruciale en matière de sécurité d’entreprise. En effet, disposer seulement des meilleurs équipements technologiques ne suffisent plus à s’assurer une fiabilité totale.

Pour les pirates informatiques, l’environnement idéal pour une attaque est celui qui demande aussi peu d’effort que possible à infiltrer. Ces opportunités s’expliquent par des systèmes, des équipements peu ou mal configurés et entraînent une vulnérabilité totale de l’environnement et de ses données.

Voici les cinq principales erreurs de configuration qui peuvent entraîner des failles de sécurité.

1. Ne pas reconfigurer les identifiants par défaut

L’une des erreurs les plus courantes, et pourtant les plus évidentes, consiste à ne pas reconfigurer les noms d’utilisateur et les mots de passe par défaut des bases de données, des installations et des équipements. C’est un problème tellement basique qu’il est comparable à des clés laissées sur une porte verrouillée. Et quand cela arrive, les informations d’identification par défaut sont l’une des erreurs de configuration les plus faciles à exploiter.

Les scanners de vérification des mots de passe peuvent en effet permettre aux pirates d’accéder aux équipements clés du réseau, comme les pare-feu et les routeurs. Même les systèmes d’exploitation peuvent se trouver exposés à cause d’informations d’identification par défaut. Les attaques de force brute scriptées peuvent également fournir accès aux divers équipements en ciblant des noms d’utilisateur et des mots de passe par défaut, ou des options basiques comme « 12345 », « azerty » ou « password ».

Le processus est également automatisé jusqu’à un certain point. Les chercheurs ont récemment découvert un scanner web en Python appelé Xwo, en mesure de balayer facilement le web à la recherche de services web exposés et de mots de passe par défaut. Après avoir collecté les informations d’identification par défaut pour MySQL, MongoDB, Postgre SAL et Tomcat, le scanner transfère les résultats à un serveur de commande et contrôle pour poursuivre son action.

2. Retarder la mise à jour des logiciels

Les prestataires technologiques et les spécialistes de la sécurité répètent ce message essentiel à la sécurité depuis des années. Pourquoi ? Parce que c’est efficace. Des systèmes d’exploitation mis à jour à l’aide des derniers correctifs peuvent avoir un impact crucial sur la prévention des failles.
Certes, il peut être difficile de suivre le rythme des correctifs. Ces éléments peuvent changer tous les jours, et le défi s’étoffe à mesure que les environnements se complexifient. Mais si les administrateurs n’assurent pas une maintenance correcte sur le plan des correctifs, ils ne font qu’attendre un accident inévitable.

Et les attaquants continueront à exploiter les vieux bugs tant qu’ils seront efficaces. Bien que la détection et la prévention des vulnérabilités de type « Zéro Day » suscitent une attention justifiée, les vulnérabilités les plus couramment exploitées remontent, par comparaison, à l’âge de pierre du numérique.

3. Appliquer les mêmes mots de passe sur différents périphériques

Bien que des mots de passe forts et complexes constituent l’un des piliers de toute stratégie de sécurité basique, même lorsqu’ils sont mis en place, leur utilisation est discutable. Les environnements utilisent souvent le même compte utilisateur et le même mot de passe sur tous les périphériques d’un parc de terminaux.

L’une des principales raisons est que cela facilite la gestion. Mais, et c’est un inconvénient majeur, c’est également pratique pour les malveillants, et cela peut leur permettre de compromettre toutes les machines à partir d’une faille sur une seule d’entre elles. À partir de là, ils peuvent utiliser des programmes d’extraction des informations d’identification pour révéler les mots de passe, voire leurs hachages. C’est alors que les vrais problèmes commencent. La réutilisation des mots de passe doit être évitée à tout prix, et les comptes non indispensables doivent être désactivés avant de pouvoir fournir un accès.

4. La mauvaise configuration des interfaces à distance

Tout appareil en contact avec l’extérieur et connecté à Internet doit faire l’objet d’une protection particulièrement soignée. Des services tels que le protocole propriétaire RDP (Remote Desktop Protocol) développé par Microsoft peuvent fournir aux administrateurs une interface permettant de contrôler les ordinateurs à distance. Mais leur mauvaise configuration offre aux cybercriminels une possibilité d’accéder aux systèmes.

Par exemple, des ransomwares ont déjà ciblé les entreprises via des ports RDP ouverts, en utilisant des attaques par force brute et par dictionnaire. Les administrateurs doivent utiliser une combinaison de mots de passe forts et complexes, de pare-feu et de listes de contrôle d’accès pour réduire le risque de compromission.

5. Désactiver la journalisation ou la cape d’invisibilité des pirates

Bien que la désactivation de la journalisation ne permette pas nécessairement à un attaquant d’accéder à un système, cela lui permet d’agir en restant inaperçu sur la machine. Lorsque la journalisation est désactivée, les pirates informatiques peuvent se déplacer latéralement sur un réseau à la recherche de données ou d’actifs à exploiter, sans laisser de trace de leur activité.

Cela complique énormément le travail des analystes judiciaires et des intervenants en cas d’incident lorsqu’ils doivent reconstituer ce qui s’est produit lors d’un incident ou d’une intrusion. En revanche, il peut être très bénéfique d’activer la journalisation et d’en envoyer les données vers un emplacement centralisé, par exemple une plateforme de gestion des informations et des événements de sécurité (SIEM). Ces données fourniront les indices nécessaires aux analystes judiciaires lors d’une enquête pour reproduire l’attaque et comprendre l’ampleur de l’intrusion.

Tout périphérique, toute plateforme laissé(s) dans un état par défaut ou mal configuré facilite d’autant le travail d’un criminel. Bien que ces vulnérabilités n’entraînent pas nécessairement de problèmes tout de suite, les pirates informatiques les découvriront probablement à un moment donné et les exploiteront pour obtenir un accès non autorisé. La mise en place de configurations de sécurité appropriées pour protéger les applications, les serveurs et les bases de données peut aider les entreprises à préserver leurs données et leur éviter de devenir une cible facile.

Phishing

Hameçonnage du compte d’un employé de GoDaddy

Le phishing, ça n’arrive pas qu’aux autres. Un employé de la société GoDaddy, entreprise spécialisée dans les noms de domaine, se fait piéger par un hameçonnage. Le pirate en profite pour modifier des pages de clients.

Voilà un piratage qu aurait pu faire de gros dégâts dans les mains d’un pirate informatique « professionnel ». Il y a quelques jours Un employé de la société GoDaddy, un fournisseur de noms de domaine (Registar), s’est fait piéger par un hameçonnage. A la suite de ce phishing, le pirate en a profité pour usurper un client du registar.

Une fois l’employé usurpé, autant dire que la cible n’était pas n’importe qui, le malveillant le pirate a modifié six DNS de plusieurs sociétés, dont Escrow.com. GoDaddy n’a pas précisé le nombre d’adresse web impactées par la fraude. Le pirate, un Malaisien, a modifié l’affichage des sites. Une modification possible via le remplacement des DNS d’origine d’un serveur légitime vers un serveur malveillant. Il aurait pu afficher une fausse page de collecte de données ou intercepter les courriels.

Le pirate a été contacté par téléphone. Se dernier a avoué que son attaque avait débuté par son hameçonnage. GoDaddy a assuré aux clients du fait que seuls les domaines appartenant à l’entreprise elle-même étaient compromis et que toutes les données des clients étaient totalement sécurisées.

Sauvegarde

Sauvegarde : 39 % des Français n’en font pas !

Plus d’un tiers des Français ne réalisent pas de sauvegarde, et près de la moitié parce qu’ils estiment que leurs données ou leurs fichiers ne sont pas suffisamment importants.

Un éditeur d’antivirus a réalisé une enquête en ligne dans le cadre de la Journée mondiale de la sauvegarde qui s’est tenue fin mars. Les résultats de l’enquête révèlent que, selon Avats, 39 % des Français ne sauvegardent pas leurs données ou leurs fichiers, s’exposant ainsi à une perte en cas de destruction ou de suppression. Parmi les personnes qui ne sauvegardent pas leurs données, près de la moitié (46 %) affirment ne pas disposer de données ou de fichiers suffisamment importants pour être sauvegardés. 27 % ne savent pas comment sauvegarder leurs données ; 16 % veulent le faire, mais oublient ; 11 % veulent le faire, mais n’en ont pas le temps. (Enquête en ligne menée auprès de 2 020 utilisateurs des antivirus Avast et d’AVG, du 20 février au 4 mars 2020.)

Les raisons invoquées par les propriétaires d’appareils Android et iPhone pour ne pas faire de sauvegarde sont également légèrement différentes. Les propriétaires d’iPhone semblent accorder plus de valeur à leurs données que les propriétaires d’Android. 44 % des propriétaires d’iPhone ne font pas de sauvegarde parce qu’ils pensent que leurs données ne sont pas importantes, contre 38 % des propriétaires d’Android qui partagent cette opinion. Le pourcentage de propriétaires de smartphones qui ne savent pas comment sauvegarder leurs données ne varie pas beaucoup entre les propriétaires d’iPhone et d’Android, puisque 19 % et 20 % d’entre eux, respectivement, affirment ne pas savoir comment faire.

L’étude d’Avast  indique aussi que 11 % des propriétaires d’iPhone et 19 % des propriétaires d’Android oublient d’effectuer une sauvegarde. Pour ce qui est du manque de temps à consacrer aux sauvegardes, 11 % des propriétaires d’iPhone et 16 % des propriétaires d’Android ont invoqué cette raison.

Comment optimiser la sauvegarde de ses données ?

Sauvegarder à deux endroits: lorsqu’il s’agit de sauvegarder des données, on n’est jamais trop prudent. S’il arrive quelque chose à un certain type de sauvegarde, tout pourrait être perdu. Il est donc recommandé de le faire à deux endroits différents, comme dans le cloud, et un stockage physique, comme un disque dur externe.

Déconnecter: les disques durs externes devraient être déconnectés après une sauvegarde afin de les protéger contre les logiciels malveillants tels que les ransomwares, qui peuvent se propager de l’ordinateur aux périphériques connectés.

Sauvegarder automatiquement: la plupart des services de stockage dans le cloud proposent une option de sauvegarde automatique, qu’il est conseillé d’activer, afin que les données soient automatiquement sauvegardées et sécurisées.

Le partage des responsabilités est primordial à la sécurité du cloud

« Jusqu’en 2025, au moins 99 % des incidents de sécurité liés au cloud seront imputables au client. » indiquait Gartner dans un analyse. L’entité tire ainsi la sonnette d’alarme quant à l’importance du partage des responsabilités en matière de sécurité cloud. Cet avertissement sous-entend que les organisations elles-mêmes – et non pas les fournisseurs de services cloud – doivent veiller à l’exhaustivité de leur approche en matière de sécurité.

En entreprise, la question de la migration des données sur le cloud divise l’opinion. Certains estiment que la sécurité accrue des données dans le cloud constitue l’une des principales raisons en faveur d’une migration. D’autres redoutent au contraire le manque de sécurité. Les deux parties ont en réalité raison. La sécurité constitue en effet l’aspect le plus important de l’offre d’un fournisseur de services cloud : un seul incident peut provoquer des pertes financières colossales.

Aucune organisation ne peut assumer à elle seule l’entière responsabilité de la sécurité des données. Organisations, utilisateurs, professionnels de la sécurité informatique et fournisseurs de services cloud ont pour mission commune de s’assurer que toutes les parties impliquées emploient le cloud de façon sûre.

À l’ère de l’économie numérique, la mise en œuvre d’un modèle de responsabilité est synonyme de confiance client, de risques réduits, de réputation  et plus généralement de succès opérationnel pour les entreprises.

Une clarification indispensable

Une sécurité optimale du cloud requiert plusieurs niveaux de protection. Les différents acteurs doivent s’occuper de chaque composant de la « pile des responsabilités » de façon individuelle, tout en interagissant comme une structure unifiée. Sécurité des infrastructures, contrôle du réseau, vérifications applicatives, gestion des identités et des accès, protection des terminaux, classification des données, contrôle des utilisateurs/périphériques/données, contrôle de la collaboration : la liste est longue et potentiellement effrayante pour tout service informatique, quelle que soit sa taille.

La protection proposée par les fournisseurs de services cloud ne garantit malheureusement pas une parfaite sécurité des données. Microsoft, Amazon, Google et autres grands noms précisent à juste titre que la responsabilité ne leur incombe pas entièrement et que les entreprises doivent se faire à l’idée d’une responsabilité partagée. Microsoft a par exemple publié son modèle pour Azure. Amazon applique une approche similaire pour AWS.

Dans un cas comme dans l’autre, la sécurité de l’infrastructure repose sur les actions mises en œuvre par le client afin de garantir la sécurité et la conformité du système.

Les fournisseurs de services cloud divisent traditionnellement les responsabilités en deux : ils énumèrent les fonctionnalités de sécurité proposées et laissent au client le soin de s’occuper du reste. Cette division est un bon début, mais elle peut être source d’incertitudes pour les entreprises clientes : comment déterminer et répartir les aspects relevant de leur responsabilité ? Dans chaque organisation, il est aujourd’hui indispensable de clarifier les rôles et les responsabilités de chaque acteur (sécurité informatique, risque et conformité, développeurs, acheteurs de services cloud et utilisateurs).

Cloud et location de véhicule : la responsabilité partagée de la sécurité comme point commun

La location d’une voiture illustre parfaitement le partage des responsabilités. Tout d’abord, le constructeur est dans l’obligation d’assurer que le véhicule est en état de rouler à sa sortie de la chaîne de montage. Les freins, roues et airbags doivent fonctionner comme il se doit. Une fois la voiture réceptionnée par l’agence de location, cette dernière ne vérifie pas les airbags, le locataire non plus : tous deux partent du principe que ces équipements fonctionnent correctement. Quand le véhicule n’est plus tout neuf, l’agence doit entretenir le véhicule et garantir qu’il est en état de marche.

Le locataire suppose que toutes les vérifications sur les équipements soient « ok » ; malheureusement, lorsque ce n’est pas le cas, il ne le découvre qu’au moment d’un problème avec le véhicule.

Pour les ceintures de sécurité, le principe est le même. Le constructeur doit les installer, l’agence de location les entretenir, mais c’est au conducteur qu’il revient de l’attacher et de vérifier que tous les passagers ont fait de même.

La location d’un véhicule implique ainsi une répartition des responsabilités entre cinq catégories de personnes. Chacun de jouer son rôle. Ignorer un niveau de sécurité peut avoir des conséquences désastreuses.

La responsabilité associée à la gestion des risques incombe à l’entreprise

Microsoft, Amazon et les autres fournisseurs de services cloud s’efforcent d’appliquer systématiquement des modèles de partage des responsabilités, mais les utilisateurs finaux – l’organisation en elle-même, les responsables de la sécurité des données, l’équipe de sécurité informatique, les utilisateurs – doivent assumer davantage de responsabilités.

Les dirigeants et responsables informatiques ne peuvent garantir la protection des informations dans le cloud que si les modules de sécu sont compris, en fonction et correctement mises en oeuvre !

C’est ce que démontre, depuis des semaines, des violation,  conséquence d’une mauvaise configuration des règles AWS pour des serveurs accessibles au public.

De manière générale, les responsables technologiques doivent déterminer à qui incombent la vérification et la gestion des configurations cloud, des flux de données entre différents services cloud, du comportement des utilisateurs, ou encore des contrôles relatifs à la collaboration, aux accès et aux périphériques.

Responsabilité associée

En définitive, la responsabilité associée à la gestion des risques incombe à l’entreprise, car c’est avant tout elle qui se charge de la collecte et de la sécurité.

Le fournisseur de services cloud joue certes un rôle important, mais contrairement à l’organisation cliente, il n’est pas en contact direct avec le public et n’assume pas le risque à la gestion de ces informations sensibles.

Les membres de l’équipe informatique doivent jouer le rôle de gardiens de la sécurité et de la conformité pour l’entreprise. Ils doivent travailler de concert avec le RSSI et les autres dirigeants pour comprendre et définir les politiques en matière de contrôle des données, coopérer avec les différents services pour catégoriser précisément les données, assurer la conformité réglementaire, faciliter les décisions du service des achats, définir les services cloud accessibles aux utilisateurs et garantir l’exhaustivité de la formation des utilisateurs.

En l’absence de processus stricts et de responsabilités clairement définies, une décision opérationnelle comme le déploiement d’un nouveau service de cloud public peut fortement exposer une entreprise à une violation de données ou à des incidents de sécurité connexes. À l’inverse, une démarche de partage des responsabilités permet de veiller à ce que chacun accomplisse son rôle.

Securite informatique

CDN et DDoS : Ne pas mettre tous les œufs dans le même panier

Les réseaux de diffusion de contenu, les Content Delivery Network (CDN) ont été conçus pour optimiser les performances en matière de distribution de contenus sur Internet et pour optimiser les coûts de bande passante pour celui qui produit ce contenu, afin de faire face à des demandes de plus en plus nombreuses, et à une volumétrie de données à fournir, en forte croissance. Nous entendons souvent l’argument que la protection contre les attaques DDoS fournie par un CDN est LA solution permettant de se protéger : Voyons sur quoi se base cet argument.

En simplifiant, un CDN est constitué d’un ensemble de serveurs interconnectés, largement distribués du point de vue géographique et mais aussi logique au sein du maillage de l’Internet. Le CDN utilise ces serveurs distribués pour cacher le contenu de leurs clients et le diffuser à leurs utilisateurs. Une utilisation astucieuse du routage permet de s’appuyer sur les « caches » les plus proches de chaque client, permettant une livraison plus rapide du contenu, et d’éviter ainsi de consommer des ressources – y compris la bande passante – du serveur d’origine hébergeant le contenu original.

Quand un client demande une première fois une ressource – une image ou une page web, le CDN doit chercher ce contenu auprès du serveur d’origine pour servir le client. Par contre, à partir de ce moment, la ressource reste « en cache », distribuée au sein du CDN, afin de servir toute nouvelle demande, par n’importe quel client, à partir de ces caches.

Les CDN cachent typiquement le contenu statique, qui ne change pas, comme justement les images d’un site web. Cependant, les CDN ne peuvent pas ou sont plus limités en leur capacité de cacher du contenu dynamique, comme les informations concernant les stocks et les commandes d’un site de vente.

Le contenu dynamique typiquement hébergé par le site d’origine. Le site d’origine sollicité, non pas par ses utilisateurs, mais par le CDN, d’une part pour du contenu statique pas encore caché et d’autre part pour le contenu dynamique, qui ne peut pas être caché.

CDN ET PROTECTION CONTRE LES ATTAQUES DDOS

De par sa nature, le CDN dispose des mécanismes qui peuvent être utiles en face d’attaques par déni de service distribuée. Par exemple, un CDN dispose souvent de ressources importantes en termes de capacité réseau et de serveurs, lui permettant souvent tout simplement d’absorber une quantité plus importante de requêtes que le serveur d’origine.

De plus, par les mêmes mécanismes de distribution et de routage qui lui permettent de distribuer la charge des utilisateurs, les attaques distribuées amenées à viser non plus une cible unique, mais une cible distribuée en fonction de la localisation de chaque source d’attaque.

« THE DEVIL IS IN THE DETAILS »

Par contre, malgré ces couches de protection utiles, le fonctionnement même d’un CDN peut ouvrir de nouveaux vecteurs d’attaque ou rendre la défense du serveur d’origine plus

difficile. Par exemple, si une attaque, faisant usage d’un botnet, sollicite un site web pour des ressources non-existantes, et donc non-cachées, cela peut amener le CDN à solliciter à son tour le serveur d’origine à répétition pour ces ressources et provoquer une condition de déni de service pour le serveur d’origine.

En plus, l’attaque vue par le serveur d’origine semble provenir du CDN lui même ! Dans cette situation, il peut être difficile au serveur d’origine de se protéger car le CDN est en même temps l’origine de l’attaque et des requêtes légitimes: Des approches simples s’appuyant sur le blacklisting des sources au niveau du serveur d’origine ne peuvent plus être utilisées dans ce cas.

D’autre part, il ne faut pas oublier que les protections fournies par le CDN ne couvrent que le contenu caché. Le serveur d’origine, ainsi que plus généralement, l’entreprise à qui le site appartient, aura probablement besoin d’une connectivité fonctionnelle. Au-delà du serveur d’origine qui doit pouvoir fournir le contenu non-caché et dynamique pour le CDN, le service aura peut-être besoin d’interagir avec d’autres sites, l’entreprise de pouvoir envoyer et réceptionner des emails, ses équipes d’accéder aux services de Voix sur IP ou de se connecter à Internet d’une manière générale pour accéder à des services cloud comme Google GSuite ou Microsoft Office 365.

Tout cela nécessite que des services on-site ou à minima l’accès Internet de l’entreprise, qui ne peuvent pas être protégés par un CDN, continuent à fonctionner.

Protections de type volumétriques

De plus, en fonction du CDN, les protections fournies limitées aux protections de type volumétriques, alors que des attaques applicatives plus sophistiquées risquent de traverser le CDN et d’atteindre le site d’origine. En somme, la situation est souvent bien plus complexe qu’imaginée au premier abord.

Premièrement, il est important de bien comprendre le fonctionnement, pas seulement de son site Internet, mais de son entreprise dans sa globalité et d’effectuer une analyse de risque pour identifier les différentes menaces. Ensuite, selon les risques impliquant la disponibilité et/ou la qualité de service des communications, des services réseau et/ou des applications, il peut être utile de s’appuyer sur des fonctionnalités de protection fournies par son CDN – potentiellement plus capables pour des grosses attaques volumétriques – ou utiliser des protections plutôt de type « On-Premise », potentiellement plus précises et capables pour des attaques applicatives.

Souvent une protection optimale implique une protection hybride, combinant la précision et rapidité d’une solution « On-Premise », avec des capacités volumétriques suffisamment élevés proposées par un fournisseur de service de mitigation.

Dans certains cas le CDN peut-être un composant adapté, dans d’autres vous aurez besoin d’une capacité de protection volumétrique importante capable aussi à protéger votre site local. (Par Jouni Viinikka, Directeur R&D chez 6cure ; Frédéric Coiffier, Ingénieur Développement Logiciel chez 6cure)

backdoor, Cybersécurité, IOT

NAS et Routeurs Zyxel/Linksys dans la ligne de mire de pirates

Découvertes de plusieurs cyber attaques visant les utilisateurs de stockages connectés Zyxel et routeurs Linksys.

Une ne nouvelle variante de Mirai vise les stockages connectés Zyxel.

Appelé Mukashi, ce malware utilise des attaques par force brute. Mission, s’infiltrer via différentes combinaisons d’identifiants par défaut afin de se connecter aux produits de stockage en réseau Zyxel.

Une cyber attaque qui a pour mission de prendre le contrôle et d’ajouter à un réseau de dispositifs pouvant être utilisés pour conduire des attaques DDoS.

Le PoC (proof-of-concept) de la faille CVE-2020-9054 a été rendu public en février 2019. Une vulnérabilité rapidement exploitée pour infecter des modèles NAS de chez Zyxel avec une nouvelle variante de Mirai : Mukashi. Ce code malveillant utilise la force brute pour s’infiltrer en utilisant différentes combinaisons d’identifiants par défaut, tout en informant son serveur C2 (command & contrôle) de ses réussites. De nombreux serveurs NAS de Zyxel, si ce n’est tous, utilisant les versions de firmware allant jusqu’à 5.21 sont concernés par cette vulnérabilité.

Cette vulnérabilité classée critique (c’est-à-dire un score de 9,8 selon le CVSS v3.1) en raison de son incroyable facilité d’exploitation. Faille découverte à l’origine par la vente de son code en tant que 0-day. Les pirates indiquaient que cet exploit était désormais dans les mains d’un groupe de cyber criminels qui cherchaient à l’intégrer dans l’autre code malveillant, Emotet.

Bot contre Zyxel

Mukashi est un bot qui scanne les ports 23 TCP d’hôtes au hasard. Il utilise la force brute pour s’infiltrer en utilisant différentes combinaisons d’identifiants par défaut et qui renvoie ses essais réussis vers un serveur C2. Comme les autres variantes de Mirai, Mukashi peut également recevoir des ordres de son serveur C&C et de lancer des attaques par déni de service (DoS). Une fois exécuté, Mukashi affiche le message « Protecting your device from further infections. » sur la console. Le malware change alors le nom de son processus en dvrhelper, suggérant que Mukashi a pu hériter de certaines particularités de son prédécesseur.

Avant d’exécuter son opération, Mukashi se lie au port TCP 23448 pour s’assurer qu’il n’y a qu’une seule instance tournant sur le système infecté. Le malware décode quelques chaînes de caractères à la volée lors de son initialisation. Contrairement à ses prédécesseurs qui utilisent le chiffrement xor classique, Mukashi utilise une routine de décryptage personnalisée pour chiffrer ces commandes et ces informations d’identification.

Il est indispensable de mettre à jour le firmware pour ne pas laisser entrer les attaquants. Les dernières versions du firmware sont disponibles en téléchargement. Mieux vaut utiliser des couples identifiants/mots de passe complexes pour éviter les attaques par la force brute.

Chez Linksys

Pendant ce temps, Bitdefender découvrait une nouvelle attaque ciblant les routeurs Linksys. La cyber attaque a pour mission de modifier les paramètres DNS des matériels. Mission, diriger les utilisateurs vers une page web liée au COVID-19. Une page ayant pour mission diffuser des logiciels malveillants. L’attaque a débuté le 18 mars 2020. Elle utilisait le service de raccourcissement d’adresse web TinyURL et quatre stockages Bitbucket.

Les principaux pays touchés auraient été la France, l’Allemagne et les États-Unis. 1 193 téléchargements auraient été détectées en deux jours.

Kit Covi-19 : protéger son entreprise et ses employés

Besoin d’un outil pour sécuriser vos équipes lors du confinement ? Le Kit Cyber Covid-19 a été mis en place par plusieurs entreprises Françaises, à l’initiative de ITrust.