Apple met en place un curieux mécanisme de sécurité pour protéger les systèmes d’exploitation mobiles de la société contre les attaques de logiciels espions sophistiqués. Il s’agit d’un mode de fonctionnement restreint qui pourrait être activé par un utilisateur s’il remarque ou soupçonne que son appareil mobile est attaqué.
Ce mode, baptisé « Lockdown », obligerait iOS à fonctionner en mode extrêmement réduit afin de réduire la zone d’exposition. Par exemple, des fonctions telles que la réception de pièces jointes dans les messages, la prévisualisation de liens, etc. ou certaines techniques d’optimisation du moteur JavaScript Webkit seraient arrêtées.
En pratique, il s’agirait évidemment de limiter l’utilisation du terminal et des applications, afin que seul un petit nombre d’utilisateurs – ceux qui pensent être la cible d’opérations d’espionnage – soit obligé de l’activer. Ce n’est pas un mode « populaire » pour les utilisateurs, car l’expérience utilisateur serait profondément affectée.
Apple s’engage ainsi à doter son système mobile d’un mode de protection destiné à un certain public restreint, mais dont l’impact médiatique est, comme nous l’avons vu à la une des journaux, important. En fait, l’entreprise offre une prime de bogue pouvant aller jusqu’à deux millions de dollars aux chercheurs qui parviendront à contourner les protections proposées par le mode Lockdown.
La société KELA a publié un rapport sur le secteur des ransomwares. Parmi de nombreuses autres constatations, ils affirment que le nombre total de victimes de ransomware (nous comprenons qu’il s’agit des gangs les plus populaires qu’ils surveillent) a considérablement diminué. De 982 au dernier trimestre de 2021 à 698 au premier trimestre de 2022.
Il est intéressant de noter que le rapport indique également que, comme lors des guerres de NetSky et de Mydoom au milieu de la première décennie, les groupes de ransomware se disputent désormais les victimes ou collaborent entre eux, ce n’est pas encore clair. Par exemple, Conti a été détecté en train de compromettre une entreprise américaine en janvier. En mars, Alphv a déclaré qu’elle l’avait également attaquée. En avril, Avos a publié à son tour les mêmes preuves de détournement qu’Alphv et le même fichier volé que Conti avait précédemment partagé.
Se battent-ils entre eux, collaborent-ils et partagent-ils leur butin, s’agit-il de simple marketing, en volant les succès des autres, ou bien créent-ils de petits groupes autonomes qui passent quelque peu inaperçus de la communauté qui analyse, étudie et poursuit ces groupes ?
Un an après l’attaque contre Colonial Pipeline, l’ Administration de la sécurité des pipelines et des matières dangereuses du ministère des transports américain (PHMSA) demande à la société de payer près d’un million de dollars, au motif que le plan d’urgence en cas de ransomware n’était pas suffisant.
Le groupe Colonial transporte de l’essence, du diesel et du carburéacteur du Texas jusqu’à New York. On estime que 45 % de tout le carburant consommé sur la côte est des États-Unis passe par son réseau de pipelines. Entre les 6 et 7 mai 2021, ils ont subi une cyberattaque de type ransomware qui a utilisé les identifiants de connexion VPN d’un ancien utilisateur comme vecteur d’entrée. L’attaque a été menée par le groupe DarkSide, et l’entreprise a payé une rançon de 4,4 millions USD, dont elle a pu récupérer environ 2,3 millions USD.
L’ampleur de l’attaque a paralysé l’ensemble du système informatique de Colonial, incitant le président Joe Biden à déclarer l’état d’urgence le 9 mai. Dans cette déclaration, il a supprimé les limites imposées au transport de carburant par la route, afin d’essayer d’atténuer toute pénurie potentielle résultant de la fermeture des pipelines.
Une mauvaise planification face aux ransomwares
Un an plus tard, l’entreprise doit faire face à un autre paiement, mais cette fois sous la forme d’une amende civile de 986 400 dollars. Cette proposition d’amende de la PHMSA est le résultat d’une enquête menée entre janvier et novembre 2020, soit des mois avant la cyberattaque. Cette enquête a révélé « une incapacité probable à planifier et à préparer de manière adéquate l’arrêt et le redémarrage manuels de son réseau de pipelines ». Elle allègue en outre qu’elle a par conséquent « contribué aux impacts nationaux lorsque le pipeline est resté hors service après la cyberattaque de mai 2021 ».
Le rapport de la PHMSA énumère sept problèmes, tous associés à la gestion de la salle de contrôle. Cet atout serait l’équivalent du centre d’exploitation du réseau d’un département informatique. Les problèmes sont largement résumés dans les cinq points suivants :
Le fait de ne pas tenir des registres adéquats des tests opérationnels passés.
Le fait de ne pas tester et vérifier le fonctionnement des détecteurs d’alarme et d’anomalie.
Absence d’un plan préalable de récupération et de fonctionnement manuel en cas de défaillance du système.
Absence de vérification des processus et procédures de sauvegarde.
Absence de notification des contrôles de sécurité manquants ou temporairement supprimés.
Les incidents liés aux ransomwares ont continué à être une tendance ces dernières années. Selon un rapport d’Unit 42, le coût des ransomwares a plus que doublé en 2021 par rapport à 2020, plus de la moitié des entreprises déclarant finir par payer la rançon.
Comparaison de la demande/du paiement moyen de ransomware en 2020 et 2021.
En conclusion, une mauvaise politique de sécurité dans un environnement d’entreprise peut non seulement conduire au détournement d’informations sensibles de l’entreprise, mais aussi à des sanctions administratives dans des secteurs critiques.
La société de cybersécurité Sophos a publié un communiqué mettant en garde contre une grave faille de sécurité dans son pare-feu, qui est activement exploitée.
La faille, enregistrée sous le nom de CVE-2022-1040, a un classement CVSS de 9,8 sur 10 et affecte la version 1.5 MR3 (18.5.3) de Sophos Firewall et les versions antérieures. La vulnérabilité est une vulnérabilité de contournement d’authentification dans le portail utilisateur et l’interface d’administration qui, si elle est exploitée avec succès, permettrait à un attaquant distant d’exécuter du code arbitraire.
Selon le communiqué, Sophos a détecté que la faille est activement exploitée contre des organisations spécifiques, principalement en Asie du Sud, qui ont été signalées directement à Sophos.
Le correctif qui corrige la vulnérabilité est automatiquement installé sur les clients dont l’option est activée sur leur pare-feu. Comme mesure d’atténuation, Sophos recommande de désactiver complètement l’accès Web aux portails utilisateur et administratif.
L’importance d’un développement sécurisé
Une fois de plus, il est démontré que lors de développement d’applications web, il est plus qu’important de les développer avec une perspective de sécurité que sur la convivialité ainsi que l’importance des tests OWASP (Open Web Application Security Project) dans les tests de pré-production afin que ces types de vulnérabilités puissent être évités autant que possible, contribuant à un environnement plus sûr.
Pour ceux qui ne connaissent pas l’OWASP, il s’agit d’un projet consacré à la recherche et à la lutte contre les vulnérabilités des logiciels. La Fondation OWASP est une organisation à but non lucratif qui fournit l’infrastructure et le soutien nécessaires pour rendre le projet possible. Il existe un guide bien connu pour effectuer les tests nécessaires afin de s’assurer que le développement réalisé par les équipes de programmeurs est conforme aux normes de sécurité, le guide OWASP Web Security Testing Guide (WSTG), un élément quasi indispensable dans la boîte à outils de toute équipe de développement soucieuse de la sécurité de ses projets.
Le botnet Muhstik vit une deuxième jeunesse grâce à une faille dans la base de données Redis sur Debian et Ubuntu (bien qu’elle puisse se produire sur plus de plateformes), qui permet d’y exécuter du code LUA en s’échappant de la sandbox. La faille, découverte début mars, s’ajoute à l’arsenal de vulnérabilités utilisées par le botnet pour se propager depuis 2018. Six au total, exploitant des problèmes dans Oracle WebLogic, Drupal, Confluence… Muhstik est responsable, entre autres activités, de la réalisation d’attaques par déni de service distribué.
Il est curieux que ce botnet utilise IRC pour communiquer avec son centre de commande et de contrôle et que le découvreur du bug Redis ait informé Ubuntu du problème, s’attendant qu’à leur tour, ils en informent Debian. Mais ils ne l’ont pas fait et il a dû notifier Debian séparément.
