Dans la description de l' attaque, Zdrnya donne la séquence d'actions suivante. Après avoir accédé à l'ordinateur de la victime, l'attaquant active le mode développeur dans Google Chrome, ce qui lui permet de télécharger l'extension localement, plutôt que via le magasin. Ainsi, une extension malveillante déguisée en plug-in d'un produit de sécurité est chargée dans le navigateur.
Dans le code de l'extension elle-même, le chercheur décrit une méthode standard d'interaction avec l'infrastructure cloud de Google, qui permet à des données arbitraires d'être "échangées" entre deux navigateurs. Autrement dit, l'attaque ressemblait probablement à ceci: nous piratons l'ordinateur, installons une extension malveillante, autorisons le navigateur sous un compte Google unique. Du côté de l'attaquant, il suffit de se connecter sous le même compte pour récupérer les données de l'ordinateur de la victime.
Ce qui a exactement été transféré de cette manière, l'expert ne le divulgue pas, mais indique les limites de la méthode: la taille maximale des «clés» transmises via l'infrastructure Google Chrome ne peut pas dépasser 8 Ko, et leur nombre maximum est de 512. Autrement dit, 4 Mo de données peuvent être transférés par session ... Cela suffit pour contrôler un ordinateur infecté, ainsi que pour transférer des jetons pour accéder aux services cloud d'entreprise.
Zdrnya souligne qu'il n'y avait aucun autre logiciel malveillant sur le système affecté. Cela ne fonctionnera pas comme ça pour bloquer l'accès à l'infrastructure cloud de Google au niveau des politiques de réseau d'entreprise: non seulement le cloud y est lié, mais aussi, par exemple, vérifier la disponibilité de l'accès au réseau dans le navigateur. En guise de solution, le chercheur propose l'application de politiques interdisant l'installation de toutes extensions dans le navigateur, à l'exception de celles marquées dans la liste blanche. Une telle méthode originale d'interaction avec le système attaqué peut être ignorée pendant longtemps - cela ouvrira la voie aux attaquants vers des données d'entreprise, qui, dans des conditions normales, sont accessibles via un navigateur. Dans la plupart des cas, il peut s'agir d'un courrier électronique d'entreprise, d'outils de collaboration de documents et bien plus encore.
Que s'est-il passé d'autre
L'histoire de l'attaque contre les experts en sécurité de l'information (voir le résumé précédent ) s'est poursuivie. Une vulnérabilité zero-day dans le moteur V8 a été découverte et fermée dans le navigateur Google Chrome . Bien que les développeurs de Google ne commentent pas cela, on suppose que les organisateurs de l'attaque l'ont utilisé. En outre, les experts sud-coréens ont trouvé un autre vecteur de la même attaque: les victimes ont reçu des fichiers .mhtml contenant un code malveillant exploitant une vulnérabilité jusque-là inconnue dans Internet Explorer 11. Le fichier contenait des informations sur une vulnérabilité du navigateur Google Chrome 85.
Netscout, citant des chercheurs chinois de Baidu Labs, rapporte une nouvelle méthode pour amplifier une attaque DDoS en utilisant un serveur multimédia Plex mal configuré.
Dans le fil de discussion sur le lien ci-dessus, un chercheur sous le surnom d'OverSoft parle d'une caméra vidéo IP mal protégée avec une fonction de comptage de personnes. L'histoire commence avec un identifiant et un mot de passe de réseau WiFi irremplaçables, et cela ne fait que devenir plus triste. À l'intérieur de la caméra, j'ai trouvé un module de calcul Raspberry Pi avec un utilisateur pi par défaut, des documents laissés par le développeur (y compris un fichier mp3) et un tas de code Python. Le résultat est un appareil qui, en théorie, se connecte à un réseau d'entreprise avec une connexion Wi-Fi pratiquement non sécurisée et la possibilité d'obtenir un accès complet à un compte avec un mot de passe standard et des privilèges maximum.
L'équipe Google Project Zero publieaperçu des vulnérabilités zero-day utilisées lors d'attaques réelles l'année dernière. Sur les 24 trous, huit utilisent une nouvelle méthode d'exploitation d'un problème déjà connu. Conclusion: il est possible de compliquer quelque peu la vie des attaquants si les vulnérabilités sont fermées après une analyse détaillée de la cause afin que le problème résolu ne puisse pas être rouvert.
Il y a plus d'un mois, le 4 janvier, il y avait un problème majeur dans le messager Slack. Un rapport détaillé a été publié sur les résultats de l'incident . La baisse était due à une combinaison de raisons: le premier jour ouvrable après les vacances dans la plupart des pays, les utilisateurs ont chargé l'infrastructure plus que nécessaire et l'outil de mise à l'échelle automatique de la capacité d'Amazon Web Services n'a pas fonctionné comme prévu.
Une étude du malware Kobalos pour les systèmes Linux révèle une cible d'attaque inhabituelle: les supercalculateurs.
Un nouvel exemple d'attaque sur la chaîne d'approvisionnement: des chercheurs d'ESET ont trouvé un logiciel NoxPlayer infecté (émulation d'applications Android) distribué directement depuis le site Web du développeur.