Étiquette : Vulnérabilité Page 12 of 15

Patch Tuesday

On 10/11/2021

5 vulnérabilités, ce n’est pas beaucoup pour un mois chez Microsoft. Cependant, six d’entre elles sont essentielles. Quatre d’entre elles étaient connus auparavant et deux sont exploitées par des attaquants. Ces dernières sont des problèmes dans Excel qui permettent de contourner les protections mais nécessitent une interaction de l’utilisateur.

Et Exchange n’est pas épargné. CVE-2021-42321. Un bug sérieux qui, bien qu’il exige que l’attaquant soit authentifié, atteint une gravité de 8.8.
Un bug grave (9.0) a également été corrigé dans Virtual Machine Bus, qui permettrait à un attaquant de sortir de la machine virtuelle.

L’une des plus intéressantes est la faille dans RDP (CVE-2021-38666) qui permettrait l’exécution de code à distance non pas sur le serveur, mais du serveur vers le client s’il se connecte à un client vulnérable. Il serait intéressant de créer des « pots de miel » qui, au final, se retourneraient contre l’attaquant supposé.

Plus d’information:
https://msrc.microsoft.com/update-guide/vulnerability/

Kinder Surprise!

de jabot

On 08/11/2021

dans Sécurité

L’empoisonnement des paquets open source utilisés dans la programmation fait fureur. Deux paquets NPM (node.js repository) comptant 22 millions de téléchargements ont été compromis en raison de la compromission des comptes de leurs développeurs.

Coa, un parseur d’options de ligne de commande et rc, un chargeur d’amorçage ont été distribués avec une surprise : ils ont volé des mots de passe sur Windows, grâce à une variante de DanaBot téléchargée. NPM a conseillé d’activer le deuxième facteur d’authentification pour tous les comptes.

L’impact est impossible à calculer. Une fois encore, la réflexion : dans quelle mesure sommes-nous dépendants de logiciels et de bibliothèques tiers ? Et donc, dans quelle mesure dépendons-nous de l’hygiène de sécurité du développeur du jour ?

Plus d’information:
https://thehackernews.com/2021/11/two-npm-packages-with-22-million-weekly.html

Microsoft Exchange Emergency Mitigation

de jabot

On 28/09/2021

dans CVE, Sécurité

Après de nombreux échecs en matière de sécurité dans Exchange (principalement causés par ProxyLogon et plusieurs défaillances du service d’impression), Microsoft a décidé d’adopter une nouvelle stratégie de sécurité. Un service appelé Microsoft Exchange Emergency Mitigation (EM) sera déployé de manière imminente sur ces serveurs. Il sera chargé d’atténuer l’exploitation des failles de sécurité jusqu’à ce qu’un correctif soit disponible.
Ce service se connectera en fait toutes les heures à l’Office Config Service (OCS) et téléchargera des atténuations dans des fichiers XML avec des atténuations de trois types :

Règles de réécriture pour IIS.
Désactiver certains services.
Désactiver les pools d’applications.

Une étape très intéressante car elle atténuera de nombreux bugs que les administrateurs n’osent pas appliquer, mais d’un autre côté, elle peut être intrusive (dans ces cas, elle peut être désactivée). Cela ferme la fenêtre aux attaquants. Tout comme au début des années 2000, Microsoft a rendu les correctifs automatiques et, peu après, a commencé à créer de petits programmes pour atténuer les bugs graves qui devaient être appliqués à la main, ces atténuations deviennent maintenant automatiques.

Plus d’information:
https://techcommunity.microsoft.com/t5/exchange-team-blog/new-security-feature-in-september-2021-cumulative-update-for/ba-p/2783155

HackerOne

de jabot

On 22/09/2021

dans Sécurité

L’un des mythes les plus répandus (et les plus erronés) est que les logiciels libres ou à code source ouvert sont plus sûrs par définition, car des milliers d’yeux les examinent et corrigent les problèmes. Dans un monde idéal, oui, mais la réalité est que les bugs sont là, ouverts ou fermés, tout de même. Même dans le code source ouvert le plus populaire, la détection des bogues peut être retardée. Selon une étude de GitHub, il faut en moyenne quatre ans pour détecter une faille de sécurité, mais seulement un mois pour la corriger. Étant donné que de plus en plus de logiciels en général s’appuient sur des parties open source (94 % sur GitHub), il s’agit d’un problème mondial qui s’est matérialisé par des attaques de la chaîne d’approvisionnement pouvant mettre en péril d’importantes infrastructures.

Ainsi, HackerOne, le programme de bug bounty, a fait un pas en avant avec l’Internet Bug Bounty (IBB) qui se concentrera sur le code open source avec la particularité que la récompense sera divisée 80/20 entre ceux qui le trouvent et les volontaires qui doivent le corriger. De cette façon, l’écosystème est encouragé. Les paiements vont de 300 à 5000 dollars pour les plus critiques.

Plus d’information:
https://www.hackerone.com/internet-bug-bounty

CVE-2021-33766

de jabot

On 31/08/2021

dans CVE

Bien qu’elle ait fait l’objet d’un correctif en juillet, des détails viennent d’apparaître sur la CVE-2021-33766, ou ProxyToken dans Exchange, qui vient s’ajouter à la série de vulnérabilités récentes de ce système. Il permet de voler des informations de la boîte de réception de n’importe quel utilisateur et est très facile à exploiter avec un POST où voyage l’email de la victime et un cookie avec la valeur « SecurityToken=x ».

Dans Exchange, les ports 80 et 443 sont créés pour le front-end et 81 et 444 pour le back-end vers lequel il redirige en s’attendant à ce qu’il résolve l’authentification déléguée s’il voit le SecurityToken non vide. Mais pour une raison quelconque, le back-end (l’ECP, le panneau de contrôle Exchange) laisse passer tout ce qui arrive avec un SecurityToken non vide parce que le module DelegatedAuthModule qui devrait être chargé de l’authentification n’est pas chargé par défaut.

Pour l’exploiter, l’attaquant doit également connaître un « ECP canary », qui est comme un cookie de session. Mais en essayant d’attaquer, le système renvoie un 500 avec une valeur valide qui peut être réinjectée avec le cookie « SecurityToken=x » et modifier la configuration d’Exchange.

Plus d’information:
https://www.zerodayinitiative.com/blog/2021/8/30/proxytoken-an-authentication-bypass-in-microsoft-exchange-server