La société Sysdig a découvert que plus d’un millier d’images de conteneurs hébergées sur le populaire dépôt Docker Hub contiennent du code malveillant, ce qui présente un grand risque de subir une cyberattaque. Cette information a été rendue publique par un rapport de la même société, où l’on indique que les images contiendraient des actifs malveillants de différents types tels que des cryptomineurs, des portes dérobées et des détourneurs de DNS.
Les images de conteneurs sont des « modèles » avec lesquels nous pouvons déployer des applications rapidement et facilement, sans devoir repartir de zéro puisque certaines fonctionnalités sont réutilisées. Les images sont téléchargées à partir de Docker Hub, ce site web permet aux utilisateurs de charger et de télécharger ces images dans sa bibliothèque publique, y compris les images officielles des développeurs de logiciels.
Le projet de bibliothèque Docker examine ces images et vérifie celles qu’il considère comme sûres, mais beaucoup restent non vérifiées. Sysdig a analysé automatiquement 250 000 images Linux non vérifiées et a constaté que 1 652 d’entre elles contenaient des éléments malveillants.
Sysdig a déclaré que ces images contenaient des « clés intégrées » qui permettent à un attaquant d’obtenir un accès après l’installation du conteneur en chargeant la clé publique depuis un serveur distant, ce qui permet au propriétaire de la clé privée correspondante d’ouvrir un shell et d’exécuter des commandes via SSH, ce qui revient à installer une porte dérobée.
Une technique utilisée par les attaquants pour faire télécharger leurs images malveillantes consiste à leur donner un nom presque identique, à quelques variantes près, à celui d’une image populaire et sûre. Ce phénomène, appelé typosquattage, est une stratégie populaire et fructueuse utilisée par les cyberattaquants sur des images compromises ou des versions non officielles d’images populaires et fiables dans l’espoir que les utilisateurs ne le remarquent pas et téléchargent leur version frauduleuse à la place.
Sysdig affirme que cette année, le nombre d’images retirées de la bibliothèque publique en raison de tels incidents a augmenté d’environ 15 %. Ce n’est qu’un indicateur que le problème ne fait que commencer, et il est recommandé de faire particulièrement attention aux images que vous téléchargez et utilisez.
Il y a actuellement une plus grande acceptation de la sécurisation des systèmes informatiques des entreprises et des institutions publiques, surtout après l’irruption du ransomware Wannacry en mai 2017. Toutefois, cette acceptation n’est pas totale, et de nombreuses entreprises et personnes ordinaires hésitent encore à le faire, se posant la même question : « Mais qui donc va m’attaquer ? ».
Depuis que Wannacry est devenu public en mai 2017, les entreprises ont commencé à être plus conscientes de la nécessité de mettre en place un système sécurisé dans leurs équipements et services, mais il y a encore beaucoup d’institutions qui n’ont pas mis en place ce type de système et, si elles l’ont fait, elles n’ont pas mis en œuvre des politiques de sécurité correctes.
Pourquoi des mesures ne sont-elles pas prises ?
Il existe plusieurs raisons pour lesquelles les entreprises et les particuliers ne prennent pas suffisamment de mesures, mais la plupart d’entre elles peuvent se résumer en un mot : désinformation.
Les médias d’information, pour la plupart, exposent les attaques menées contre les grandes entreprises ou institutions parce que ces nouvelles auront un grand impact et, de plus, il est plus difficile pour une petite entreprise de s’exposer publiquement. En outre, les informations diffusées dans les médias seront biaisées par ce que l’entreprise vous dit.
Une grande entreprise, par exemple, dira à un interlocuteur qu’elle est confrontée à un nouveau ransomware, un virus malveillant, ou que ses données ont été divulguées. Cependant, il ne dira normalement pas comment cela s’est produit ni quel était le vecteur d’entrée de l’attaquant, sauf à une autorité de cybersécurité (NCSC, NIST, CSIRT, etc.).
Phishing et vishing
Il est également possible qu’en raison du type de nouvelles sur les attaques qui apparaissent dans les médias, lorsque nous pensons à une attaque, nous pensons à un logiciel malveillant, à un ransomware, à un virus… Cependant, nous ne pensons généralement pas aux attaques de phishing ou de vishing, qui sont des attaques d’ingénierie sociale.
Le phishing consiste à inciter une personne à partager des informations confidentielles, telles que des mots de passe ou des cartes de crédit, au moyen d’un lien envoyé par courrier électronique ou par SMS, en se faisant passer pour une autre entité.
Le vishing consiste également à inciter l’utilisateur à partager des informations, mais par le biais d’un appel électronique, et ne nécessite pas de connaissances informatiques pour mener à bien cette cyber-attaque.
Ces types d’attaques sont très courants de nos jours, outre le fait qu’ils constituent un important vecteur d’entrée dans le système et qu’avec un peu de sensibilisation, il est possible de les atténuer.
Quels sont les problèmes ?
Il y a deux problèmes majeurs :
Si les attaques montrées ne concernent que les grandes entreprises ou institutions, les gens pensent que, s’ils ne font pas partie de ces membres, ils ne seront pas attaqués. Par conséquent, les PME et les personnes ordinaires ne vont pas s’inquiéter de la sécurisation de leurs systèmes.
Si, en outre, ces actualités ne comportent pas les vecteurs d’entrée des attaquants, il est très probable qu’elles ne seront pas prises en compte dans les systèmes à sécuriser. Par exemple, un élément clé de la sécurisation d’un système est la sensibilisation, car un logiciel malveillant peut s’introduire par hameçonnage ou des données peuvent être volées par un simple hameçonnage vocal.
Et pourquoi les petites entreprises ne signalent-elles pas publiquement les attaques ?
Lorsqu’une petite entreprise est attaquée, deux choses principales peuvent se produire :
Si l’attaque n’est pas puissante et qu’ils y survivent, ils ne s’exposeront pas eux-mêmes dans les médias publics, car ils exposeraient que leurs systèmes ne sont pas sécurisés. Une grande entreprise a son public déjà établi, mais pas une PME, qui perdrait des opportunités de marché et pourrait donc facilement faire faillite.
Si l’attaque est puissante et que l’entreprise n’y survit pas, ce sont les responsables de la sécurité qui perdront ces opportunités de marché et peut-être même les chances de travailler à nouveau dans le secteur.
C’est pourquoi il y a tant de désinformation sur le sujet. Cependant, certains éléments, tels que ceux examinés dans cet article, nous permettent de vérifier qu’effectivement, les PME et les particuliers sont également attaqués.
Alors, que nous montrent-ils ?
Outre les méthodes d’information classiques, il existe des sites web et des éléments qui nous présentent ce type d’informations de manière plus détaillée, comme les analyses d’acteurs du marché (IBM, Kaspersky, etc…). En outre, vous pouvez également vous tenir au courant des dernières nouvelles sur ce sujet sur ce blog 🙂 .
Ces sites présentent les dernières vulnérabilités découvertes dans les systèmes informatiques, ainsi que des statistiques sur les attaques les plus courantes et les lieux où ces attaques ont été menées. Par exemple, Kaspersky présente ici des statistiques sur les cybermenaces financières en 2021.
Dans ces statistiques, on peut voir qu’il y a eu pas mal de campagnes de phishing (8,2%), principalement des attaques de phishing visant le commerce électronique. En outre, ces attaques visaient principalement les passerelles de paiement telles que Paypal ou Mastercard, qui sont des moyens de paiement largement utilisés par la population générale.
Il nous montre également les plateformes que les attaquants usurpent le plus, comme Apple, Amazon, eBay ou Alibaba, des sites web sur lesquels nous avons l’habitude d’acheter un grand nombre d’articles en permanence et auxquels, en cas d’attaque, nous devons être préparés pour éviter de nous faire dérober.
Conclusion
Aujourd’hui, de nombreuses personnes ne se soucient pas outre mesure de la protection de leurs données en ligne ou de la fourniture d’un service entièrement sécurisé. Ils pensent, à cause des médias, que rien ne leur arrivera et n’ont pas à l’esprit qu’ils sont les plus facilement attaqués.
Si une personne est capable de vous voler dans la vie réelle sans appartenir à une grande entreprise, pourquoi ne serait-elle pas capable de vous voler sur Internet ? Et si vous mettez des alarmes, des chiens de garde et des systèmes de surveillance sur votre porte d’entrée, pourquoi ne le feriez-vous pas sur vos systèmes virtuels ?
Ou encore plus simple : si vous verrouillez votre porte d’entrée chaque fois que vous sortez, même si vous ne travaillez pas pour une multinationale, pourquoi ne pas le faire sur le web ?
Actuellement, les utilisateurs d’Azure ont la possibilité de se connecter à leurs serveurs bastion via des connexions SSH et RDP avec un client natif ou en utilisant l’interface web. Cependant, il est possible d’effectuer des attaques contre les VM Azure via Azure Bastion et son client natif.
D’après la documentation de Microsoft, il existe deux options par lesquelles un utilisateur peut établir une connexion avec le client natif à un serveur bastion. Celui qui peut être utilisé par un attaquant est celui dans lequel un plus grand nombre d’options concernant la connexion peuvent être spécifiées :
Lorsque vous exécutez la commande ci-dessus, Azure CLI crée un tunnel et écoute sur un port local. C’est en se connectant à ce port local avec le client natif que l’utilisateur accède à la VM interne via le protocole utilisé (par exemple RDP).
Pour comprendre le processus d’attaque, il faut d’abord voir comment se déroule le flux de travail du client natif :
Flux de travail du client natif d’Azure Bastion. Source de l’image : Codyburked.com
Après avoir reçu une commande via l’API pour démarrer une nouvelle session, Azure Bastion effectue trois actions :
Crée une connexion TCP entre le serveur Bastion et la VM cliente, sur le port spécifié dans la requête API.
Il crée une nouvelle clé de session associée à ce port.
Il accepte une nouvelle connexion websocket en utilisant la clé de session, et transfère toutes les informations de la connexion websocket à la connexion TCP de la VM interne.
Du côté client, Azure CLI effectue les opérations suivantes :
Écoute sur un port local.
Il accepte les nouvelles connexions sur ce port, et pour chaque connexion, il appelle l’API du service de base pour démarrer une nouvelle session, comme décrit ci-dessus.
Il crée un nouveau thread qui transfère toutes les informations reçues sur la nouvelle connexion au tunnel websocket vers le bastion.
Ainsi, en activant cette configuration, les utilisateurs finaux peuvent communiquer directement avec la VM interne par le biais d’une connexion websocket, un processus complètement différent de celui d’un serveur de bastionnement traditionnel, qui ne communique que par le biais du protocole du service utilisé pour l’accès à distance (RDP ou SSH, dans ce cas).
En outre, le fait de pouvoir spécifier un port signifie que les services internes de la VM peuvent être analysés à l’aide d’Azure Bastion, et que les ports qui exposent des services vulnérables peuvent être accessibles et exploités par toute personne demandant une session de bastionnement pour une VM particulière.
Toutefois, pour pouvoir mener des attaques contre les VM Azure via Azure Bastion, l’utilisateur en question doit disposer d’un certain nombre d’autorisations et de conditions préalables :
Un rôle RBAC Azure en lecture doit être attribué à la VM.
Un rôle RBAC Azure en lecture doit être attribué à la carte réseau associée à l’adresse IP privée.
Un rôle RBAC Azure en lecture doit être attribué au service Azure Bastion.
Le réseau doit inclure des routes qui permettent au sous-réseau Azure Bastion de communiquer avec la VM, soit sur le même VNet, soit via un peering VNet.
Les recommandations pour prévenir ce type d’attaque comprennent la désactivation du support du client natif des services de bastionnement. Toutefois, si cela n’est pas possible, les mesures suivantes peuvent être prises pour atténuer le problème dans une certaine mesure :
Assurez-vous que le sous-réseau sur lequel Azure Bastion est déployé possède un groupe de sécurité réseau (NSG) associé, afin que la connectivité soit limitée aux ports 3389 et 22.
Limitez le nombre d’utilisateurs qui ont un accès RBAC en lecture à une ressource privilégiée, comme le groupe admin root.
Incluez une règle NSG sur le sous-réseau de base qui limite la connectivité à une adresse IP spécifique ou à de petites plages de sous-réseau.
Le monde évolue, et les créateurs de logiciels malveillants n’en font pas moins, au point que l’on parle déjà dans le monde de « Ransomware-as-a-service » (Raas), le moyen qu’ils ont de monétiser leurs activités criminelles. Dans ce cas, Hive Ransomware extorque de l’argent à 1 300 entreprises.
Le modus operandi de cette activité illicite consiste à détourner un ordinateur en exploitant une vulnérabilité, qu’elle soit logicielle ou humaine, puis à exiger une rançon pour débloquer ce détournement si la victime veut que son ordinateur fonctionne à nouveau.
Lorsque la machine est infectée, le logiciel malveillant crée un document dans lequel il guide la victime sur la manière de récupérer sa machine, étape par étape, bien sûr, pour effectuer un paiement. Cela ressemble à ce qui suit:
Aujourd’hui, une attaque a cours dans laquelle Hive Ransomware extorque 1300 entreprises dans le monde entier, collectant 100 millions de dollars rien qu’en novembre 2022. Ces paiements sont totalement illicites.
Selon les services de renseignement américains, la cible de l’attaque n’a pas été filtrée, touchant tout type d’acteur, des entreprises d’infrastructure aux entreprises de soins de la santé, ce qui permet de constater l’ampleur et la criticité de l’attaque.
Le point d’exploitation semble avoir été des failles de sécurité dans le ProxyShell de Microsoft Exchange Server.
En plus de cette faille de sécurité, il existe également des contournements de moteurs antivirus ainsi que certaines mesures de sécurité de Windows.
Selon l’Agence pour la cybersécurité, les infrastructures et la sécurité (CISA), les acteurs qui ont restauré des systèmes sans paiement ont été réinfectés.
Récemment, Microsoft a publié des mises à jour facultatives pour corriger un problème qui provoque des échecs d’ouverture de session Kerberos et d’autres problèmes dans les contrôleurs de domaine d’entreprise Windows après l’installation des mises à jour cumulatives, publiées au cours du mois de novembre.
« Après l’installation des mises à jour du 8 novembre 2022 ou d’une version ultérieure sur les serveurs Windows avec le rôle de contrôleur de domaine, vous pouvez rencontrer des problèmes avec l’authentification Kerberos. » « Lorsque ce problème est rencontré, vous pouvez recevoir un événement d’erreur Microsoft-Windows-Kerberos-Key-Distribution-Key-Distribution-Center Event ID 14 dans la section Système du journal des événements sur votre contrôleur de domaine avec le texte suivant. »
Microsoft
Les scénarios d’authentification Kerberos concernés :
Microsoft a également publié des mises à jour autonomes qui peuvent être importées dans Windows Server Update Services (WSUS) et Microsoft Endpoint Configuration Manager :
Cependant, il reste encore une plateforme à corriger, à savoir Windows Server 2008 R2 SP1. Selon Redmond, il devrait recevoir une mise à jour dédiée dans le courant de la semaine prochaine.
