Microsoft a découvert une faille de sécurité au sein de macOS qui permet de contourner les protections du composant TCC (Transparence, Consentement et Contrôle). Une vulnérabilité appelée Powerdir.
Avant de parler de la vulnérabilité, commençons cet article par une bonne nouvelle : cette faille de sécurité est corrigée au sein de macOS 12.1, disponible depuis la mi-décembre. Si vous n'avez pas encore fait la mise à jour, cela devrait peut-être vous inciter à prendre le temps de le faire.
La fonctionnalité TCC de macOS n'est pas récente puisqu'elle a été introduite pour la première fois en 2012, au sein d'OS X Moutain Lion. L'intérêt de cette fonctionnalité est de permettre aux utilisateurs de gérer les autorisations accordées aux différents logiciels installés sur macOS : accès au micro, à la webcam, aux informations de géolocalisation, etc... C'est à cet endroit que cela se configure. En complément, Apple a introduit des fonctions de sécurité notamment pour éviter l'exécution de code arbitraire et l'accès à la fonction TCC est limité.
Aperçu de la fonction TCC de macOS
Les chercheurs en sécurité de l'équipe Microsoft 365 Defender Research ont découvert cette vulnérabilité nommée Powerdir et associée à la référence CVE-2021-30970. En fait, TCC s'appuie sur deux bases de données SQLite pour stocker les autorisations : une base de données spécifique à l'utilisateur (~/Library/Application Support/com.apple.TCC/TCC.db) et une base de données au niveau du système (/Library/Application Support/com.apple.TCC/TCC.db).
Ce n'est pas la première fois qu'une vulnérabilité est corrigée dans TCC. Microsoft rappelle dans son article plusieurs références : CVE-2020-9771, CVE-2020-9934 et CVE-2021-30713. D'ailleurs, c'est en regardant de plus près le correctif pour la faille CVE-2020-9934 que les chercheurs sont parvenus à trouver une nouvelle manière de bypasser TCC, en manipulant les bases de données.
En utilisant cet exploit, un attaquant peut modifier les autorisations de n'importe quelle application. Par exemple, l'attaquant peut accorder des autorisations à une application pour qu'elle accède au micro et à la webcam du Mac, que ce soit une application malveillante ou une application existante. Ci-dessous, un exemple de l'outil Powerdir qui s'en prend à Teams (cet outil permet l'exploitation de cette vulnérabilité).
Depuis quelques jours, WordPress 5.8.3 est disponible et cette mise à jour permet de corriger 4 vulnérabilités au sein de ce CMS utilisé sur des millions de sites.
Parmi ces quatre vulnérabilités, il y en a trois considérées comme importante. Tout d'abord, nous retrouvons la vulnérabilité CVE-2022-21661 qui est une injection SQL via WP_Query et elle affecte toutes les versions de WordPress, sauf la nouvelle version 5.8.3. Cette vulnérabilité n'est pas exploitable directement via le coeur de WordPress mais en passant par certains plugins ou thèmes.
Ensuite, nous avons la vulnérabilité CVE-2022-21662 qui est une faille XSS pouvant permettre l'installation d'une porte dérobée sur le site ou d'en prendre le contrôle. Pour exploiter cette faille de sécurité qui affecte toutes les versions de WordPress sauf la 5.8.3, il faut disposer d'un compte ayant les autorisations de publier des articles sur le site. Par exemple, il faut disposer du rôle "Auteur" sur le site cible.
La troisième vulnérabilité, associée à la référence CVE-2022-21663, est probablement la moins grave puisqu'elle est très difficile à exploiter. Enfin, disons qu'il faut des prérequis qui peuvent surprendre : pour exploiter cette vulnérabilité, il faut des droits de super administrateur, et elle concerne uniquement les sites Multisite de WordPress (gestion de plusieurs sites depuis une même interface). Comme l'explique Wordfence sur son site, dans certains cas, relativement rares, même le super administrateur n'est pas autorisé à exécuter du code arbitraire donc c'est là que l'exploitation de cette faille peut avoir du sens.
Enfin, un peu dans le même esprit que la première vulnérabilité évoquée dans cet article, la vulnérabilité CVE-2022-21664 est une injection SQL via WP_Meta_Query. Elle affecte WordPress pour les versions comprises entre la 4.1 et la 5.8.2.
Voilà, vous en savez un peu plus sur cette mise à jour de sécurité WordPress, et si ce n'est pas déjà fait, je vous invite à l'installer sur votre site !
Le malware FluBot continue d'évoluer et d'être distribué sur les appareils Android au travers de nouvelles campagnes d'attaques, notamment en Europe qui est une cible privilégiée. Méfiance.
Pour rappel, FluBot est un Cheval de Troie bancaire qui s'installe sur les appareils Android et qui est capable de dérober des identifiants de connexion en affichant son propre formulaire de connexion en superposition de celui de votre banque. Ce n'est pas tout, il intègre d'autres fonctionnalités lui permettant d'envoyer ou d'intercepter les SMS (notamment pour récupérer les codes de vérification à usage unique), de désinstaller des applications, de désactiver Play Protect, de prendre des captures d'écran, etc.
Dans sa dernière version, FluBot a fait évoluer son algorithme de génération de domaine (DGA - Domain Generation Algorithm), et il génère des domaines à la volée afin de communiquer avec les serveurs C2. Le système DGA utilise près de 30 domaines TLD différents. De cette manière, il devient presque impossible de bloquer FluBot grâce à du filtrage DNS. En complément, FluBot se connecte au serveur C2 grâce à la méthode du DNS tunneling over HTTPS afin que les données soient masquées dans des requêtes DNS et que le flux soit chiffré.
FluBot est distribué par SMS et ce message peut vous inviter à télécharger une mise à jour de sécurité pour votre appareil, ou encore une mise à jour d'Adobe Flash Player. Bien sûr, tout cela est faux et l'objectif est que vous téléchargiez le logiciel malveillant sur votre appareil.
Comme l'explique F5 Labs au travers d'un schéma, une fois qu'une personne est victime de FluBot, la liste des contacts de l'appareil est exploitée afin d'envoyer des SMS malveillants et lui permettre de se diffuser.
Source : F5 Labs
En ce moment, FluBot semble particulièrement apprécier les SMS qui invitent à télécharger une mise à jour de Flash Player. Résultat, une application "Flash Player" apparaît bien sur le smartphone Android mais il s'agit en fait de FluBot. Voici un exemple sur le smartphone d'une victime polonaise :
Source : CSIRT KNF
Pour finir, je tiens à (re)dire qu'il vaut mieux éviter d'installer les packages APK en provenance d'Internet, à moins d'être sûr de l'origine du package (certains éditeurs distribuent des applications sous ce format directement plutôt que par les magasins d'applications habituels).
Nous continuons notre suite d'articles sur le CTF du FIC 2021 proposé par l'école EPITA afin de découvrir certains outils et méthodes de forensic (investigation numérique). Dans cet article nous allons nous pencher sur l'analyse de journaux d'évènements d'un service web et d'une image disque.
II. Contexte : Panic on board - PearlArmor
Le contexte de l'incident sur lequel nous intervenons est le suivant : un bateau de croisière de la compagnie maritime ArMor a subi une panne et se retrouve bloqué en pleine mer.
Nous savons à présent qu'à la suite d'un phishing, l'attaquant est parvenu à dérober les identifiants VPN d'un utilisateur puis à mener une attaque sur les automates du bateau afin de les arrêter. Le cinquième et dernier contexte de cette analyse est le suivant :
Avant chaque appareillage, l’ordinateur de maintenance présent à bord met à jour sa documentation depuis le serveur de fichiers interne. Le PDF qui a infecté le SeaCastle a donc été téléchargé depuis ce serveur, pourtant situé dans les locaux d’ArMor ! Il ne reste plus qu’à trouver comment le fichier qui a infecté le SeaCastle a été uploadé sur le serveur de documentation !
Deux fichiers nous sont ici fournis :
Droits Serveur Doc.pdf
FIC-SERVEUR-DOC.ova.gz
Utilisateurs Serveur Doc.pdf
Nous devons répondre aux questions suivantes pour compléter cette dernière étape de l'analyse :
La date vraisemblable d'intrusion ;
Le nom du fichier ayant exploité la faille Apache ;
La commande ayant été exécutée en root.
N'oublions pas de vérifier l'intégrité des éléments récupérés (le hash BLAKE2 est fourni avec les fichiers sur le site du challenge) :
Vous trouverez le challenge en question et les fichiers utilisés dans cet article ici : Panic On Board - PearlArmor
Les deux documents PDF ne sont pas des preuves, mais des informations fournies à l'analyste. Dans un cas réel, ce genre d'information peut être obtenue par un échange direct avec les responsables du périmètre étudié. Ils nous informent sur les utilisateurs légitimes et la matrice de droit en place.
III. Gestion des preuves
L'un des principes importants lorsque l'on manipule les preuves (objets analysés) en forensic est de s'assurer de leur intégrité comme nous l'avons vu. En cela, il peut arriver que la simple lecture d'un fichier puisse altérer son contenu. Prenons par exemple le cas de notre image disque : nous pouvons tenter de monter cet OVA dans Vmware/VirtualBox puis de parcourir manuellement le contenu du serveur. Cependant, cette action entrainera de fait une modification du contenu de la preuve (écritures d'évènements de démarrage dans les journaux, de tentative d'authentification, etc.). Voire pire, l'attaquant a très bien pu installer un code de destruction qui s'activera au prochain démarrage.
Nous allons donc commencer par effectuer une copie de tous les éléments que nous comptons étudier, nous travaillerons alors sur cette copie et non sur le fichier récupéré.
IV. Analyse d'une image disque
Nous avons donc sous la main un fichier OVA.
Le format OVA (Open Virtual Machine Format) est un format d'archivage des données d'une machine virtuelle (disque & configuration) permettant de facilement les exporter et les importer d'un hyperviseur à un autre (changement de système ou de technologie). Plus simplement, il s'agit d'une archive .tar dont le contenu est défini par le format OVA.
$ file FIC-SERVEUR-DOC.ova FIC-SERVEUR-DOC.ova: POSIX tar archive
$ tar -xvf FIC-SERVEUR-DOC.ova FIC-SERVEUR-DOC.ovf FIC-SERVEUR-DOC-disk001.vmdk FIC-SERVEURit-DOC.mf
Le fichier OVF permet d'obtenir des informations sur la machine virtuelle, ce fichier est normalement lu par l'hyperviseur pour construire une VM avec les bonnes ressources (RAM, périphériques, etc.). Au passage, on remarque la présence d'une mauvaise pratique, probablement mise ici pour faciliter la résolution du challenge :
Un autre fichier intéressant dans cette archive OVA est le fichier FIC-SERVEUR-DOC-disk001.vmdk.
VMDK (Virtual Machine Disk) est un format de fichier ouvert (à la base créé par VmWare) permettant de simuler un disque dur virtuel pour les machines virtuelles telles que VMware ou Virtualbox.
Le problème rencontré ici est que les outils d'analyse d'image disque ne sont pas tous accoutumés au format VMDK, nous devons donc convertir ce format VMDK en format raw (image disque brute). Cela à l'aide de la commande suivante :
$ qemu-img convert FIC-SERVEUR-DOC-disk001.vmdk -m 16 -O raw image.disk
À noter que dès lors, nous pouvons présumer que des preuves sont peut-être écrasées ou perdues par cette manipulation, d'où l'intérêt de travailler sur une copie de la preuve et non sur la preuve reçue directement. Cela nous permettra de revenir sur un fichier sain si nous pensons avoir supprimé quelque chose ou pour valider un constat par une autre technique. Nous nous retrouvons donc avec un fichier de 50Go, soit la taille du disque défini lorsque la machine a été créée :
Périphérique Début Fin Secteurs Taille Type image.disk1 2048 4095 2048 1M Amorçage BIOS image.disk2 4096 104855551 104851456 50G Système de fichiers Linux
Nous voyons ici que notre image disque comporte deux partitions, une partition d'amorçage BIOS, et une contenant un système de fichier Linux (très probablement ext4). Tentons à présent de monter cette partition pour pouvoir parcourir son contenu :
Étant donné que notre image disque contient deux partitions, nous sommes obligés ici d'indiquer l'offset de début de notre partition dans le fichier transmis à mount. Celui-ci est obtenu en multipliant l'offset de début indiqué par fdisk pour la partition ciblée (4096) à la taille d'un secteur sur le disque (512), ce qui donne 2 097 152 .
Puis nous pouvons parcourir librement le contenu de la partition montée :
La date d'accès du fichier, qui fait partie des attributs des fichiers dans le système de fichier ext4, a été modifiée par notre accès en lecture. Nous ne pouvons ici plus savoir si ce fichier a été lu dans le cadre de l'attaque menée sur le système.
Pour palier à cela, nous pouvons monter le disque en lecture seule (read-only) :
Nous apprendrons plus loin dans cet article que l'attaque a eu lieu à une date ultérieure à la date d'accès du fichier /etc/timezone. Nous pouvons donc ici être relativement sûr que l'attaquant n'a pas consulté ce fichier. Cette information ne sert à rien ici, mais c'est un exemple pour montrer l'intérêt de conserver une trace dans son état d'origine autant que possible, et d'être conscient du fonctionnement de nos outils pour savoir quelles données risquent d'être modifiées par nos actions.
V. Étude des journaux d'évènements
Maintenant que nous avons un accès au disque dur, nous pouvons parcourir celui-ci et tenter de savoir ce qu'il s'est passé. Le fichier /etc./init.d/apache2.4.29 nous renseigne sur l'emplacement des configurations apache :
root@siftworkstation:/mnt/m/etc/init.d# cat apache2.4.29 [...] HTTPD='/usr/local/apache2/bin/httpd' # # pick up any necessary environment variables if test -f /usr/local/apache2/bin/envvars; then . /usr/local/apache2/bin/envvars fi
Les journaux du service web apache2 (/usr/local/apache2/logs/access.log) sont notamment intéressant :
Constat de l'absence de journaux pour le 14/08 et le 15/08
On peut constater qu'il y a un trou au niveau des dates de journalisation. Cela peut être dû à une suppression intentionnelle de l'attaquant qui a souhaité effacer ses traces. Ce type d'action est référencé par la T1070.002 - Indicator Removal on Host: Clear Linux or Mac System Logs dans le framework MITRE ATT&CK.
Également, la configuration Apache nous apprend que le répertoire /home/ de l'utilisation deloin_c était exposé sur le service web :
root@siftworkstation:/mnt/m/usr/local/apache2/conf# grep "deloin_c" -A 5 httpd.conf Alias "/log" "/home/deloin_c" <Directory "/home/deloin_c"> Options Indexes FollowSymLinks Require all granted </Directory>
L'attaquant ayant compromis ce compte a donc pu s'en servir pour exposer des fichiers sur le service web, sans avoir besoin des droits du compte de service apache2. Intéressons nous maintenant à l'activité des comptes utilisateur, par exemple en regardant le contenu du fichier .bash_history des utilisateurs du système.
Sur les systèmes Linux, un fichier .bash_history est situé dans le /home/ de chaque utilisateur et contient l'historique des commandes saisies dans le terminal. Il n'a pas pour vocation première la journalisation dans un but d'investigation numérique puisqu'il peut être supprimé ou désactivé par l'utilisateur. Il est plus fréquemment utile lorsque l'on souhaite retrouver une commande saisie par le passé (Ctrl+R).
Le contenu du fichier /home/deloin_c/.bash_history est suspect :
root@siftworkstation:/mnt/m/home/deloin_c# cat .bash_history [...] echo hello >> test.txt ls cat test.txt cp test.txt /usr/local/apache2/htdocs/Siemes/ vim /usr/local/var/log/carpediem.php ls ls -lha /usr/local/apache2/htdocs/Siemes/ ls -lh /usr/local/apache2/htdocs/Siemes/ ls -lh /usr/local/var/log/ chmod 777 /usr/local/var/log/carpediem.php ls -lh /usr/local/var/log/ wget http://192.168.2.10/log cat log rm log ls ls -lh /usr/local/apache2/htdocs/Siemes/ ls -lh /usr/local/var/log/ ls pwd cp /home/deloin_c/test.txt /usr/local/apache2/htdocs/Siemes/ curl http://192.168.2.10/log/carpediem.php?cmd=cp+/home/deloin_c/test.txt+/usr/local/apache2/htdocs/Siemens ls -lh /usr/local/apache2/htdocs/Siemes/ cat /proc/self/map cat /proc/self/maps cat /usr/local/apache2/logs/httpd.pid cat /usr/local/apache2/logs/access_log curl http://192.168.2.10/log/carpediem.php?cmd=/bin/bash service apache2.4.29 graceful logout touch hello.txt vim hello.txt cat hello.txt rm hello.txt
On remarque notamment différentes commandes visant à télécharger des fichiers(wget, curl) et à écrire ou modifier des fichiers dans le répertoire de travail d'apache2. Deux commandes nous interpellent plus particulièrement :
vim /usr/local/var/log/carpediem.php curl http://192.168.2.10/log/carpediem.php?cmd=cp+/home/deloin_c/test.txt+/usr/local/apache2/htdocs/Siemens
On retrouve ici un élément caractéristique des webshells, l'utilisation d'un paramètre (cmd) contenant une commande système. Nous pouvons donc fortement supposer que le fichier PHP créé (carpediem.php) contienne du code PHP permettant d'exécuter des commandes système. Le nom du fichier carpediem.php est aussi peu commun, une rapide recherche sur internet nous oriente vers un exploit concernant une élévation de privilège locale sur Apache :
Code d'exploitation de la CVE-2019-0211 nommée "Carpe diem"
Si l'on regarde la date de dernière édition du fichier /home/deloin_c/.bash_history, on retrouve la date du 15/08/2020 :
root@siftworkstation:/mnt/m/home/deloin_c# ls -al -rw------- 1 1012 1012 1284 août 15 2020 .bash_history
Ces différents constats nous permettent de répondre à la première question :
La date vraisemblable d'intrusion : 15/08/2020
Un autre fichier intéressant est le fichier .viminfo :
Le fichier .viminfo est créé automatiquement dans le /home/ de chaque utilisateur et permet d'historiser certains éléments comme les commandes saisies dans vim, les recherches faites dans les fichiers, les marques, etc.
Dans notre cas, on obtient le chemin absolu des fichiers modifiés par Mr Deloin (ou l'attaquant ayant compromis son compte) :
# Historique des marques dans les fichiers (les plus récentes en premier) : /usr/local/var/log/hello.html /usr/local/var/log/carpediem.php /usr/local/apache2/conf/httpd.conf ~/index.php /usr/local/var/log/index.php ~/hello.txt
L'attaquant semble avoir créé des fichiers dans /usr/local/var/log/ ainsi que dans le répertoire /home/ de l'utilisateur, or nous savons que le home de l'utilisateur était exposé sur le web, les fichiers PHP créés pouvaient donc y être interprétés par le service web. Avec les éléments recueillis, nous pouvons nous répondre à ces questions :
Le nom du fichier ayant exploité la faille Apache : index.php
Le dossier ayant servi de point d'entrée à l'attaquant : /home/deloin_c
Au passage, l'utilisation d'un exploit sur un système ou une application en vue d'élever ses privilèges est référencée par la T1068 - Exploitation for Privilege Escalation dans le framework MITRE ATT&CK.
VI. Récupération d'une preuve supprimée
Problème, lorsque l'on tente de lire ces fichiers, ils n'existent plus. Il semble donc que l'attaquant ayant utilisé ce compte utilisateur ait pris le soin de supprimer certaines informations. Nous allons tenter d'utiliser un outil de File Carving pour récupérer ces fichiers.
Le File Carving est le processus consistant à essayer de récupérer des fichiers en l'absence de leurs métadonnées (fichiers supprimés de la table de référence). Cela se fait en analysant les données brutes et en identifiant de quel format il peut s'agir (texte, exécutable, png, mp3, etc.). Cela peut être fait de différentes manières, mais la plus simple est de rechercher la signature de fichier ou les magic number qui marquent le début et/ou la fin d'un type de fichier particulier (lecture du contenu du disque en hexadécimal et marquage du début d'un fichier lorsque l'on rencontre un magic number). Nous avons déjà abordé les magics numbers dans l'article de cette même série : Forensic – SteerOnSomewhere : analyse de PDF et EXE malveillants
Nous utiliserons ici photorec :
Choix du média à analyser par photorec
Il nous faut ensuite sélectionner la partition à analyser dans l'image disque. Mais avant cela, nous allons faire un tour dans le paramètre File Opt (en bas) :
Sélection de la partition à analyser et des options d'analyse
Ici nous allons pouvoir préciser à photorec quels sont les types de fichiers qui nous intéressent, nous sélectionnerons txt (qui comprend les extensions web) :
Choix des extensions et types de fichiers à chercher
Pour faciliter le travail de photorec, nous lui précisons quel système de fichier est utilisé :
Précision du système de fichier de la partition analysée
Et enfin, le dossier de sortie dans lequel positionner les fichiers retrouvés :
Sélection du dossier dans lequel seront positionnés les fichiers retrouvés
Après une vingtaine de minutes d'exécution, photorec a retrouvé plus de 60 000 fichiers, cela fait beaucoup trop pour une recherche manuelle. Mais l'on se souvient avoir observé cette commande :
Celle-ci nous a menés vers un exploit dont le code peut être trouvé ici. On sait donc que notre fichier contient au moins le mot CARPE par exemple. Utilisons à présent grep :
Nous avons identifié plusieurs fichiers parmi les 60 000 fichiers retrouvés par photorec. Une exploration de leur contenu nous en apprend plus sur ce qu'ils font et nous permet de répondre à notre dernière question :
La commande ayant été exécutée en root : cp ./S7-300.pdf /usr/local/apache2/htdocs/Siemens/S7-300.pdf
VII. Conclusion
Cette série d'articles sur le challenge Panic On Board proposé par le FIC/l'école EPITA est maintenant terminée. Comme dans toute analyse forensic, il est maintenant temps de résumer les différentes TTP (Tactics, techniques and procedures) utilisées par l'attaquant et identifiées dans notre analyse :
Phase
ATT&CK
Nom
Initial Access
T1566.01
Phishing : Spearphishing attachment
Execution
T1059.003
Command and Scripting Interpreter: Windows Command Shell
Credential Access
T1552.001
Unsecured Credentials: Credentials In Files
Persistence
T1078
Valid Accounts
Impact
T0826
Loss of Availability
Discovery
T1046
Network Service Scanning
Execution
T1204.002
User Execution: Malicious File
Defense Evasion
T1497.003
Virtualization/Sandbox Evasion: Time Based Evasion
Defense Evasion
T1070.002
Indicator Removal on Host: Clear Linux or Mac System Logs
Privilege Escalation
T1068
Exploitation for Privilege Escalation
Le résumé des TTP a plusieurs objectifs, il permet notamment de pouvoir rapidement corréler deux attaques en constatant que leur TTP sont similaires, ce qui peut être utile pour l'attribution d'une attaque ou simplement pour noter qu'il est probable que deux attaques aient été opérées par un même attaquant.
Dans les rapports d'analyse forensic, il est aussi courant de trouver un ensemble d'IOC (Indicator of Compromission) qui peuvent être des URL, domaines, IP, noms d'exécutable, de services, etc. La synthèse de ces IOC permet elle aussi de pouvoir faire une corrélation entre différentes attaques pour lesquelles on retrouverait les mêmes IOC. Ils permettent également de mettre à jour les systèmes de détection et de prévention (ex : mettre en blacklist une adresse IP, ajouter une alerte de détection pour un certains nom d'exécutable sur les solutions antivirales) ou d'effectuer des recherches ciblées sur les journaux d'évènements du SI (qui sont centralisés bien évidemment ).
J'espère que cette suite d'articles vous a plu, il existe encore de nombreux challenges de ce type disponibles sur le site de l'EPITA et je ne peux que vous conseiller d'aller y jeter un œil :). C'est par ici : Challenges Forensic
SonicWall a confirmé que certains de ses produits de sécurité ont été touchés par le bug de l'an 2022, un peu dans le même esprit que Microsoft avec Exchange. Que s'est-il passé ?
Depuis le 1er janvier 2022, les utilisateurs de certains produits SonicWall, dont Email Security et les firewalls, peuvent rencontrer des problèmes dans l'utilisation de leur solution. Par exemple, les journaux ne sont plus mis à jour au sein de la solution Email Security, donc il n'est plus possible de tracer les e-mails entrants et sortants. Autrement dit, les journaux se sont arrêtés à la date du 1er janvier 2022. Autre exemple, les utilisateurs n'ont plus accès au contenu de la boite de courriers indésirables.
Dès le 2 janvier 2022, SonicWall a déployé une mise à jour sur les instances hébergées dans le Cloud au travers du service Hosted Email Security, à la fois pour l'Europe et l'Amérique du Nord. Pour les instances hébergées on-premises, c'est bien sûr à l'administrateur local d'effectuer la mise à jour.
L'appliance Email Security doit être mise à jour vers la version 10.0.15 pour corriger le bug Y2K22, tandis que pour les pare-feux avec la fonctionnalité "Anti-Spam Junk Store" il faut viser la version 7.6.9 de Junk Store. SonicWall précise que cette version de Junk Store peut être récupérée sous SonicOS 6.5.X de la section MySonicWall du site officiel. Il faut également préciser que SonicOS 7.X n'est pas impacté par ce bug de l'an 2022 !
Pour le moment, SonicWall n'a pas donné de détails donc on ne sait pas ce qui a déclenché le bug de l'an 2022 dans certains de ses produits. Après Microsoft avec un bug dans Exchange, puis le fabricant Honda où un bug touche les véhicules (l'horloge est revenue 20 ans en arrière), il y a désormais une troisième victime du bug de l'an 2022 : SonicWall. À qui le tour désormais ?
).