PROJET AUTOBLOG


IT-Connect

Site original : IT-Connect

⇐ retour index

Top 10 des vulnérabilités de 2021, selon l’ANSSI

jeudi 24 février 2022 à 13:32

L'ANSSI a publié un rapport qui recense les 10 vulnérabilités les plus critiques de l'année 2021, et sur lesquelles a pu travailler l'ANSSI durant l'année passée.

Pour l'ANSSI, c'est également l'occasion de faire les comptes et de préciser qu'en 2021, le CERT-FR a publié 991 avis et 22 alertes concernant des vulnérabilités situées au sein de produits suivis par l'agence française. Quant au top 10 des vulnérabilités, il y a des noms qui vont forcément vous parler dans cette liste, notamment ProxyLogon, ProxyShell, PrintNightmare ou encore Log4Shell, cette dernière a fait beaucoup de bruit fin 2021.

Pour mettre fin au suspens, voici le top 10 des vulnérabilités de 2021 :

Les vulnérabilités ProxyLogon et ProxyShell affectent les serveurs de messagerie Exchange (versions 2010, 2013, 2016 et 2019) et elles ont fait de nombreuses victimes en 2021. En effet, un attaquant pouvait prendre le contrôle d'un serveur Exchange grâce à une exécution de code à distance, et au final devenir administrateur du domaine Active Directory. En vérité, derrière les noms ProxyLogon et ProxyShell se cachent un ensemble de 7 vulnérabilités.

Les vulnérabilités sont particulièrement critiques lorsqu'elles sont exploitables à distance, sans authentification, et qu'elles touchent des serveurs exposés sur Internet. C'est le cas de la vulnérabilité CVE-2021-26084 qui a touché la solution Confluence, où il y a eu des campagnes menées par des attaquants afin de détecter les serveurs Confluence exposés sur Internet. La vulnérabilité CVE-2021-22205 qui a touché GitLab est également un autre exemple, dans le même esprit.

Avant de vous laisser prendre connaissance du rapport complet de l'ANSSI, je suis obligé de vous (re)parler de deux vulnérabilités : PrintNightmare et Log4Shell. La première, baptisée "PrintNightmare" touche le service "Spouleur d'impression" de Windows et elle peut permettre à un attaquant d'obtenir les droits SYSTEM sur une machine, y compris un contrôleur de domaine, à partir du moment où le service est actif sur la machine. Rapidement patchée par Microsoft, elle est devenue un cauchemar pour de nombreuses entreprises et plus particulièrement les admins systèmes. En effet, Microsoft a publié plusieurs correctifs pour protéger les machines, mais ils ont créé d'énormes problèmes d'impression, notamment en réseau, au sein des entreprises. Une galère de plusieurs mois.

Et puis, pour finir l'année 2021 en beauté, nous avons eu le droit à cette faille de sécurité critique au sein de la bibliothèque Log4j, dévoilée en décembre 2021 et associée à un score CVSS de 10/10. Utilisée par énormément de sites, produits, et services, elle a littéralement secoué Internet. Parmi les entreprises concernées, nous pouvons citer Cisco, Bitdefender, Docker, IBM, Jenkins, McAfee, Microsoft, NetApp, Nutanix, Oracle, Plesk, Puppet, Salesforce, Sophos, SonicWall, Synology, TP-Link, TrendMicro, Veeam, VMware, etc... Du beau monde.

Je vous laisse en compagnie du rapport de l'ANSSI, disponible à cette adresse : Top 10 des vulnérabilités 2021 - ANSSI

The post Top 10 des vulnérabilités de 2021, selon l’ANSSI first appeared on IT-Connect.

Les listes de contrôle d’accès (ACL) avec Cisco

jeudi 24 février 2022 à 10:00

I. Présentation

Dans ce tutoriel, nous allons aborder la notion d'ACL, c'est-à-dire les listes de contrôle d'accès, avec quelques exemples pratiques à mettre en œuvre sur Cisco.

Une ACL, c’est quoi et pourquoi ?

Les ACL, pour Access Control List, sont des règles appliquées aux trafics transitant via les interfaces du routeur que ce soit en entrée (in) ou en sortie (out). Les ACL filtrent le trafic en demandant aux interfaces d’acheminer on non les paquets qui y transitent. Pour ce faire, le routeur lit l'en-tête de chaque paquet afin de déterminer s'il doit être acheminé ou non en fonction des conditions définies dans la liste de contrôle d’accès ACLs.

Les avantages de les mettre en place sont nombreux, on peut citer par exemple :

Les ACL s'appliquent selon un ordre séquentiel en évaluant les paquets au début de la liste d’instruction. Si le paquet répond aux critères de la première instruction (appelées ACE pour Access Control Entry), il ignore le reste des règles. Pour reproduire ce tutoriel, vous pouvez utiliser du matériel virtuel Cisco sous Packet Tracer.

II. ACL : entrante ou sortante

Une question très importante que l'on peut se poser lorsque l’on veut mettre en place l’ACLs, c'est savoir sur quelle interface faut-il appliquer les ACLs ? L’interface entrante ou sortante du routeur ? Répondons à cette question dans cette première partie de l'article.

Les ACLs peuvent être associés à une interface particulière et pour une direction du flux (en entrée ou en sortie). En outre, ces règles de filtrages peuvent être appliquées avant que le routeur ne prenne sa décision de routage (interface en entrée), ce qui est un bon moyen d'économiser les ressources matérielles du routeur, ou après que le routeur ait pris sa décision de transfert et déterminé l’interface de sortie à utiliser pour acheminer le paquet.

Un petit exemple :

Dans la topologie ci-dessus, l’interface entrante de R1 est Gi 1/0, et l’interface sortante est Gi 0/0.

L’interface entrante de R2 est Gi 0/1 et l’interface sortante est Gi 0/3. Si par exemple, nous avons activé une ACL sur l’interface Gi 0/2 de R2, cette ACL ne pourrait pas filtrer les paquets envoyés de PC2 au serveur S1, car les paquets ne passent pas l’interface Gi 0/2.

En somme, pour filtrer un paquet, on doit activer une ACL sur l’interface qui traite le paquet.

Si on active l’ACL sur R1 pour les paquets entrants sur l’interface Gi1/0, R1 va comparer chaque paquet entrant sur cette interface aux entrées de l’ACL afin de décider le sort de ce paquet : continuer sans changement et acheminer le paquet ou le rejeter.

III. La correspondance des paquets

C’est la manière dont on configure les ACL, on indique les informations qui seront utilisées par le processus de filtrage, cela peut être une adresse IP ou bien un protocole réseau. En se basant sur ces informations, le routeur déterminera s’il doit autoriser on refuser les paquets.

Le diagramme ci-dessous illustre mes propos :

Lors du traitement de l’ACL, le routeur traite le paquet comme suit :

Les ACLs utilisent la logique de première correspondance. Une fois qu’un paquet correspond à une ligne dans l’ACL, le routeur exécute cette règle puis le processus s’arrête.

L’exemple ci-dessous nous permettra de voir ce que cela signifie précisément :

Sur l'exemple ci-dessous, l'ACL est appliquée sur l’interface Gi1/3 et elle contient trois règles :

On considère qu’un paquet est envoyé par le PC1 (10.1.1.1) au serveur S1, le routeur R1 compare ce paquet à l’ACL correspondant à la première ligne de l'ACL, le paquet sera autorisé, car l'adresse IP du PC correspond à celle définie dans l'ACL.

Ensuite, considérons qu’un paquet est envoyé par le PC2 (10.1.1.2) au serveur S1. À l’arrivée du paquet, le routeur va poursuivre la même logique de recherche en comparant le paquet à la première ligne de notre ACL. Il ne fera pas une correspondance, car 10.1.1.2 (adresse IP de PC2) n'est pas égal à l'adresse IP définie dans la première règle (10.1.1.1). Donc, R1 passe ensuite à la deuxième instruction à savoir "10.1.1.x deny", où x correspond à n’importe quelle valeur qui peut exister dans le dernier octet. En ne comparant que les trois premiers octets, R1 réalise que notre paquet émis depuis PC2 a une adresse IP source qui correspond à "10.1.1". De ce fait, R1 considère qu’il s’agit bien d’une correspondance à la deuxième règle de notre ACL et applique l’action comme indiqué dans la règle, à savoir refuser le paquet (deny). Le routeur R1 arrête également le traitement ACL sur ce paquet, en ignorant la troisième règle de l’ACL.

Finalement, admettons que le PC3 (10.3.3.3) veut envoyer un paquet au serveur S1. R1 examine les deux premières règles dans l’ACL, et il voit qu’elles ne correspondent pas à l'adresse IP 10.3.3.3 (adresse IP source du paquet), donc il poursuit l’exécution de l’ACL. De ce fait, il regarde la troisième règle qui s'applique à toutes les adresses IP sous la forme "10.X.X.X", ce qui correspond à l'adresse IP de PC3. La troisième règle de l'ACL s'applique, donc le paquet est autorisé et poursuit son chemin vers le serveur S1.

Si jamais un paquet ne correspond à aucune des règles de la liste ACLs, le paquet est rejeté. On parle d'un refus implicite.

Il est important de savoir que le traitement des ACL en mode séquentiel, en lisant les règles dans l'ordre, s’applique sur tout type d’ACL.

IV. Les types d'ACLs

Il existe plusieurs types d'ACL, que nous allons découvrir ensemble sans plus attendre.

A. Les ACL standards

Dans ce type, l’ACL ne peut être liée qu'à l’adresse IP source du paquet. Ces ACLs sont identifiables par identifiant correspondant à un nombre allant de 1 à 99 et de 1300 à 1999.

Nous pourrons utiliser ce type d'ACL pour autoriser ou interdire un segment du réseau ou l'adresse IP d’une machine à communiquer avec un autre segment de réseau ou une autre machine.

Afin de concrétiser la notion d’ACL standard, nous allons les mettre en place sur un routeur Cisco.

Dans l’exemple ci-dessus, les trois ordinateurs, situés sur des segments réseau différents, communiquent entre eux. Le but est d’interdire au réseau « 10.1.1.0/24 » de communiquer avec le réseau « 10.1.2.0/24 » tout en ayant la possibilité de communiquer avec le réseau « 10.1.3.0/24 » pour ce faire, nous allons, sur l’interface Gi0/2, interdire les paquets provenant du réseau « 10.1.1.0/24 »

Pour parvenir aux résultats souhaités, nous appliquons trois étapes :

1 - Après s’être connecté sur le routeur en mode de configuration globale en tapant les commandes "enable" puis "configuration terminal", on commence par la création de la règle :

Router(config)#access-list 1 deny 10.1.1.0 0.0.0.255

En précisant "access-list 1" on attribue un ID à notre ACL, puis ensuite on précise que l'on veut refuser avec "deny", et enfin on précise l'adresse IP de destination (10.1.2.0) et le masque au format inversé appelé wildcards mask (0.0.0.225).

Wildcards mask ? De quoi parle-t-on ? Une petite explication s’impose. En effet, souvent, l’objectif de mettre en œuvre l’ACL c’est de faire correspondre une plage d’adresse IP (ou un sous-réseau complet) à l'ACL plutôt qu’une seule adresse IP. Cela est faisable à l’aide ce que l’on appelle Wildcards mask, ou en français masque générique (ou inversé). Notez qu’il ne s’agit pas d’un masque de sous-réseau. Par le biais de cette notation, nous avons la possibilité d’ignorer des parties de l’adresse IP, comme si elles correspondaient déjà.

Cela signifie que :

C’est-à-dire pour la règle « deny 10.1.2.0 0.0.0.255 » le routeur va refuser tous les paquets où les trois premiers octets de l'adresse IP source correspondent à ce masque générique. D'autre valeurs sont possible pour le wildcard mask, permettant d'affiner le filtrage en fonction des plages IP ou des regroupements de plages. Ainsi, un wildcard mask en 0.0.255.255 correspondra à un masque en /16; un wildcard mask en 0.0.63.255 correspondra à un masque en /18. Pour calculer la valeur, rien de plus simple, il suffit de soustraire la valeur du masque de sous-réseau à 255.

Exemple :

255.255.255.255

 -255.255.255.0

= 0.0.0.255

On retrouve bien notre wildcard mask correspondant à notre /24.

Deuxièmement, comme évoqué précédemment, il faut autoriser explicitement les réseaux que l’on veut laisser passer, dans notre exemple c’est « 10.1.3.0/24 ». À défaut, il n’y aura pas de correspondance entre l’IP source contenue dans l’en-tête du paquet et les règles ACL, ce qui veut dire que le routeur va les refuser implicitement et notre réseau en 10.3.0/24 ne pourra pas non plus communiquer  avec le 10.1.2.0/24.

Router(config)#access-list 1 permit 10.1.3.0 0.0.0.255

Notez qu'ici, on pourrait utiliser le mot clé "any" à la place de la plage réseau et du wildcard mask. Ce mot clé , qui veut dire "n'importe qui" peut être utilisé lorsque la règle s'adresse à tous les réseaux et hôtes. Comme on à déjà interdit en premier lieu notre premier réseau, on peut très bien estimer que le reste est permis.

Troisièmement, on sélection l’interface concernée par la règle :

Router(config)#interface gigabitEthernet 0/2

Enfin, on applique la règle en sortie :

Router(config)# ip access-group 1 out

Le "1" étant le numéro de l’ACL créée à la première étape, et "out" signifie que la règle s’applique sur les paquets sortants de l’interface.

Nous avons vu les ACLs Standard et leur champ d’application, passons maintenant au deuxième type d’ACLs à savoir les « ACLs étendues ».

B. Les ACL étendues

Les ACL étendues présentent plusieurs similitudes par rapport aux ACL Standards décrites dans la section précédente. Tout comme une ACL standard, on active les ACL étendues sur les interfaces pour les paquets entrants ou sortants, puis le routeur cherche dans la liste de manière séquentielle.

Les ACL étendues utilisent également la logique de première correspondance, car dès que la première instruction est mise en correspondance, le routeur arrête la recherche dans la liste d'ACL, en effectuant l’action définie.

En comparaison des ACL standards, les ACLs étendues vont permettre d'analyser une plus grande variété de champs au sein de l'en-tête d'un paquet. Cela rend les ACL étendues plus puissantes, plus précises, mais aussi un peu plus complexes.

Les ACL étendues suivent la même logique que les ACL standards, elles sont identifiables par un numéro, allant de 100 à 199 et de 200 à 2699.

Un exemple sera plus parlant, nous allons créer une règle qui aura pour but d’interdire le Ping de PC2 vers le PC3, tout en l'autorisant vers le PC1, en posant les règles sur les sous-réseaux (tous en /24). Mettons ça en place en reprenant la même topologie :

Voici la configuration à appliquer sur notre routeur Cisco :

Router(config)# access-list 100 deny icmp 10.1.3.0 0.0.0.255 10.1.2.0 0.0.0.255
Router(config)# access-list 100 permit icmp 10.1.1.0 0.0.0.255 10.1.2.0 0.0.0.255
Router(config)#interface gig 0/2
Router(config-if)#ip access-group 100 in

Dans l'exemple ci-dessus, "icmp" correspond au protocole, en l'occurrence ici c'est un moyen de bloquer le ping. Ensuite, "10.1.3.0" c'est l'adresse IP d'origine suivie de son masque générique, et "10.1.2.0" l'adresse IP de destination suivie aussi de son masque générique.

Il est à noter que les ACLs étendues peuvent aussi examiner des parties d'en-têtes TCP ou UDP, en particulier les champs qui contiennent le numéro de port source et port de destination. Les numéros de port identifient le service qui envoie ou reçoit les données. Quand le mot "tcp" ou "udp" est inclus dans la règle de l'ACL, cela permet de préciser le port source et le port de destination afin d'avoir une règle plus précise.

Voici un exemple :

Router(config)# access-list 100 permit tcp 10.1.1.0 0.0.0.255 10.1.2.0 0.0.0.255 eq 21

Concernant « eq » il s’agit d’un opérateur qui veut dire égal, et le numéro de port 21 utilisé par le serveur FTP. On autorise le réseau 10.1.1.0/24 à communiquer sur le port 21 (pour le FTP) avec le réseau 10.1.2.0/24.

Prenons un autre exemple...

L’exemple suivant se concentre sur la compréhension de la syntaxe de base. Ici, l'objectif est de créer une ACL pour empêcher l'utilisateur David d’utiliser le protocole FTP pour se connecter sur les serveurs. Pour cela, on va le bloquer en entrée sur l’interface Gi0/0 de R2, car c’est l’interface la plus proche de la source, donc l’ACL sera associée à cette interface. Quant à l'utilisateur Florian, on va lui interdire l’accès au serveur Web de serveur1. Dans cet exemple, on active l’ACL sur R3 en entrée de l'interface Gi0/0.

Voici la topologie :

Je vous propose que l'on se connecte sur R2 afin de créer la première règle.

La première chose à faire, c’est interdire David d’accéder à tous les serveurs FTP :

access-list 101 deny tcp host 172.16.3.10 172.16.1.0 0.0.0.255 eq ftp

Au sein de la commande ci-dessus, on précise bien l'hôte de David avec "host 172.16.3.10", car cela correspond à la source à bloquer selon notre schéma initial.

La deuxième règle va permettre d'autoriser tout le reste du trafic :

access-list 101 permit ip any any

On applique l'ACL à l'interface concernée :

R2(config)# interface gi0/0 
R2(config-if)#ip access-group 101 in

Interdisons maintenant à Florian d’accéder au serveur Web :

access-list 101 deny tcp host 172.16.2.10 host 172.16.1.100 eq www

Note : vous pouvez remarquer que j'ai utilisé le même numéro d'ACL que pour la première réalisée. Cela n'a pas d'importance, car ce numéro est interne au routeur, et je ne suis pas sur le même routeur.

Encore une fois, on autorise tout le reste du trafic ensuite :

access-list 101 permit ip any any

Après avoir créé les règles d'ACL, il nous reste plus qu’à les appliquer toujours à partir du routeur R1 :

R3(config)# interface gi0/0
R3(config-if)#ip access-group 101 in

Voilà, mission accomplie ! 

C. Named IP Access Lists

Comme vous le savez, toutes les listes d’accès doivent être identifiées par un nom ou un numéro. Ce type de liste d’accès est plus pratique, car on peut spécifier un nom significatif qui est facile à retenir et associer à une règle.

Les ACL nommées peuvent correspondre aux mêmes champs qu’une ACL standard et étendue, cependant, elles présentent trois grandes différences par rapport aux listes de contrôles d’accès numérotées, voyons cela ensemble :

On va reproduire le même schéma :

Cette fois-ci, on va changer un peu les règles du jeu : le but sera d’interdire David d’accéder au serveur Web (Serveur1) via le protocole http. On aura besoin donc d’une ACL qui contiendra plusieurs informations : IP source, IP destination et un protocole bien précis. Pas le choix, il faudrait utiliser une ACL étendue.

Profitons de cet exemple pour utiliser une ACL nommée et poursuivre notre découverte des ACLs.

Sur le R1, tout d’abord, on crée l’ACLs avec le nom "David-HTTP" :

R2(config)# ip access-list extended David-HTTP

Puis, on se retrouve dans cette ACL, donc on ajoute notre règle :

R2(config-ext-nacl)#deny tcp host 172.16.3.10 host 172.16.1.100 eq www

Vous constatez bien que le prompt a changé, car on se trouve dans l’invite de configuration de l’ACL nommée. On pose une interdiction via la directive "deny" depuis l’adresse source "172.16.3.10" vers le serveur web avec l'adresse IP "172.16.1.100". « www » c’est pour faire référence au service web, mais on peut bien évidement mettre le port 80 au lieu de www.

En dernier lieu, on autorise toutes les autres connexions, car souvenez-vous, la directive implicite (deny any ) se trouve à la fin de chaque ACL !

R1(config-ext-nacl)#permit ip any any

Il ne reste plus qu’à associer l’ACL à l’interface G0/0 de R2 comme vous savez le faire maintenant. Vous pouvez retrouver d'autres exemples sur le site de Cisco.

V. Placement des ACL

Bon, nous savons maintenant qu'il y a deux types d'ACL : standards et étendues. On sait aussi qu'il y a deux possibilités pour les placer : en entrée ou en sortie d'une interface. Mais alors, où placer tel type d'ACL? Sur quel routeur? Quelle interface?

Dans tous les cas, il existe une règle simple et immuable : une ACL standard se placera toujours au plus proche de la destination, une ACL étendue se placera toujours au plus proche de la source.

Pourquoi? Tout simplement, car une ACL standard, comme vous avez pu le constater, est très restrictive (blocage de tout le trafic d'un réseau ou d'un hôte), un placement au plus proche de la source risque de limiter fortement les possibilités de celles-ci. En revanche, l'ACL étendue filtrant au niveau de la couche 4 (ports TCP/UDP), son placement au plus proche de la source permet d'éviter de faire transiter des paquets qu'on ne souhaite pas voir sur le réseau, ainsi, on économise du temps de calcul.

Un petit exemple, en reprenant le schéma de la partie II :

ACL standard VS ACL étendue

Admettons que le PC1 soit la source, à savoir que c'est à partir de lui que je vais déterminer mes règles. Je veux interdire à ce PC1 d'accéder au réseau du serveur S1, je vais donc placer l'ACL standard sur l'interface Gi 0/3 de R2 en sortie . En revanche, si je veux interdire à PC1 d'accéder en SSH au serveur S1, je vais placer mon ACL étendue sur l'interface Gi 1/0 de R1 en entrée.

VI. Conclusion

Nous avons vu ensemble comment les ACLs peuvent être utiles pour contrôler le réseau afin de filtrer certains flux. Les ACL permettent un filtrage au niveau du réseau et peuvent être complétées avec le filtrage applicatif (Proxy) qui va venir au niveau de la couche Application du modèle OSI. Le filtrage de paquet via ACLs opère niveaux 3 et 4 du modèle OSI, ce qui permet de faire déjà beaucoup de choses, mais peu ne pas suffire dans certains cas.

Merci à Florian Duchemin pour sa relecture technique avant publication.

The post Les listes de contrôle d’accès (ACL) avec Cisco first appeared on IT-Connect.

Cyberattaque : l’Ukraine ciblée par un malware destructeur de données

jeudi 24 février 2022 à 08:17

À l'heure actuelle, la situation est très difficile en Ukraine, et au-delà de la guerre sur le terrain, ce pays est également la cible de nombreuses cyberattaques. Un malware s'en prend aux machines afin de détruire les données.

L'Ukraine est touchée par de nombreuses cyberattaques, notamment des attaques DDoS contre des banques et des agences gouvernementales, mais aussi des attaques avec un logiciel malveillant qui a un seul objectif : détruire les données des machines infectées.

De nombreuses machines sont victimes de ce que l'on appelle un "data wiper", c'est-à-dire un logiciel malveillant qui a pour objectif de corrompre les données afin de les rendre inutilisables. Contrairement à un ransomware où les données sont récupérables si l'on paie la rançon, là c'est de la destruction de données pure et simple.

Symantec et ESET ont fait la découverte de ce data wiper, et sur VirusTotal, cette souche malveillante "Win32/KillDisk.NCV" est détectée seulement par 28 des 71 moteurs de détection de la liste. Disons que les principaux antivirus sont capables de le détecter : ESET, BitDefender, Avast, Kaspersky, Fortinet, McAfee, Webroot, etc.

D'après Symantec, ces cyberattaques ciblent des centaines de machines associées à des organismes financiers et des entreprises qui travaillent pour le gouvernement Ukrainien. En complément, la Lituanie et la Lettonie sont également ciblées.

De son côté, ESET remarque que le malware a été compilé le 28 décembre 2021 : une preuve que ces attaques étaient planifiées depuis un bon moment. Le malware s'appuie sur des pilotes associés à l'éditeur EASUS, ce dernier propose des logiciels pour la sauvegarde des données, mais aussi le partitionnement des disques. Le data wiper s'appuie sur ces pilotes EASEUS pour corrompre les données avant de redémarrer la machine.

Toujours d'après ESET, dans le cadre de l'une de ces attaques, le logiciel malveillant a été déployé sur les machines directement à partir d'un contrôleur de domaine. On imagine les conséquences désastreuses sur les machines associées à ce domaine Active Directory. Là encore, cela signifie que les attaquants avaient accès à l'infrastructure depuis un moment.

En janvier dernier, l'Ukraine était déjà la cible d'un data wiper nommé "WhisperGate". Cette fois-ci, cela est coordonné avec l'offensive Russe sur le terrain, même si ce n'est pas précisé si ce sont les Russes qui utilisent ce data wiper (on peut s'en douter !).

Source

The post Cyberattaque : l’Ukraine ciblée par un malware destructeur de données first appeared on IT-Connect.

ASUSTOR vs DeadBolt : Zero-day ? Plex ? EZConnect ? L’origine reste inconnue

jeudi 24 février 2022 à 07:45

Depuis plusieurs jours, les NAS ASUSTOR sont ciblés par les pirates informatiques derrière le ransomware DeadBolt. Résultat, des utilisateurs perdent toutes leurs données car elles sont chiffrées : à moins de payer la rançon d'environ 1 000 euros. Voici les dernières infos sur cette affaire.

Une zero-day exploitée... ou pas ?

Les pirates à l'origine de ces attaques évoquent l'utilisation d'une faille zero-day afin de compromettre les NAS ASUSTOR, dans le même esprit de ce qu'ils avaient annoncé lors des attaques des NAS QNAP. Une manière de mettre la pression à ASUSTOR et d'obtenir une importante somme d'argent en échange de la master key permettant de déchiffrer l'ensemble des NAS compromis. Si ASUSTOR souhaite récupérer la master key, le fabricant doit payer près de 2 millions d'euros (50 bitcoins), tandis que pour obtenir les détails sur la faille zero-day, la rançon s'élève à environ 270 euros (7,5 bitcoins).

ASUSTOR DeadBolt

Reste à savoir quelle est la faille de sécurité exploitée : ASUSTOR mène son enquête. Certains évoquent une faille de sécurité au sein du paquet Plex, qui permet de monter un serveur multimédia, ou de la fonctionnalité EZConnect qui facilite l'accès à distance à son NAS.

Dans tous les cas, il y a peu de chances qu'ASUSTOR paie cette rançon très élevée afin de récupérer la master key universelle. Si votre NAS est chiffré par DeadBolt, vous devez vous-même payer la rançon ou compter sur une sauvegarde de vos données, ce qui est bien sûr préférable.

Quelques modèles non affectés ?

Même s'il n'y a aucune certitude à ce sujet, certaines personnes estiment que les modèles suivants ne sont pas vulnérables à cette attaque : AS6602T, AS-6210T-4K, AS5304T, AS6102T, et AS5304T. C'est tout de même étonnant car le système reste le même, ensuite c'est une question de configuration. A voir si cela se confirme par la suite.

Que faire en attendant ?

En attendant d'en savoir plus, ASUSTOR recommande à ses clients de ne plus rendre accessible le NAS à partir d'Internet. Pour cela, il faut effectuer les actions suivantes :

Sur Reddit et le forum ASUSTOR, il y a de nombreux messages au sujet des attaques DeadBolt.

The post ASUSTOR vs DeadBolt : Zero-day ? Plex ? EZConnect ? L’origine reste inconnue first appeared on IT-Connect.

Zabbix : la CISA affirme que deux vulnérabilités sont exploitées par les pirates

mercredi 23 février 2022 à 12:10

La CISA met en garde contre deux vulnérabilités au sein de la solution de supervision Zabbix puisqu'elles sont utilisées par des pirates dans le cadre d'attaques informatiques. Faisons le point.

Pour rappel, la CISA est une agence fédérale américaine qui traite des questions de la cybersécurité et elle rattachée directement au département de la sécurité intérieure. Dans le même esprit que l'ANSSI en France, elle publie régulièrement des informations intéressantes et elle tient à jour une liste des vulnérabilités exploitées dans le cadre d'attaques. Cette fois-ci, la CISA alerte sur deux failles de sécurité au sein de Zabbix.

Associé à un score CVSS v3.1 de 9,8, cette CVE correspond à une vulnérabilité critique qui permet de contourner le processus d'authentification de Zabbix. Pour exploiter cette vulnérabilité, un attaquant non authentifié doit avoir accès à l'interface de connexion de Zabbix, et l'authentification SSO via SAML doit être activée, ce qui n'est pas le cas par défaut. En complément, l'attaquant doit connaître le nom d'un utilisateur existant au sein de l'instance Zabbix, ou utiliser le compte invité, mais ce dernier est désactivé par défaut.

Cette vulnérabilité est présente dans Zabbix de la version 5.4.0 à la version 5.4.8, ainsi que la version 6.0.0 Alpha-1. Si votre instance Zabbix est à jour, vous êtes déjà protégé. Sinon, vous pouvez vous assurer que l'authentification SAML est désactivée si vous ne l'utilisez pas, afin d'être protégé malgré tout.

Moins grave de par son score CVSS v3.1 de 5,3, cette CVE offre la possibilité à un attaquant non authentifié d'accéder au fichier "setup.php". Cette faille de sécurité permet à un attaquant d'accéder à certaines étapes du processus d'initialisation de Zabbix et de modifier la configuration. Là encore, ce sont les versions 5.4.0 à 5.4.8 de Zabbix qui sont touchées, ainsi que les versions Alpha de Zabbix 6.0.0.

Il n'est pas précisé si les deux vulnérabilités sont utilisées dans les mêmes attaques. Autrement dit, si la faille sur le fichier setup.php permettrait d'activer l'authentification SAML et ensuite d'exploiter la vulnérabilité concernant cette méthode d'authentification.

CISA - Bulletin officiel

The post Zabbix : la CISA affirme que deux vulnérabilités sont exploitées par les pirates first appeared on IT-Connect.