Étiquette : Sécurité Page 23 of 27

Microsoft Exchange Emergency Mitigation

On 28/09/2021

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

Quantum FAQs

de jabot

On 02/09/2021

dans Chiffrement

La NSA a publié une FAQ sur la cryptographie quantique, dans laquelle elle clarifie de manière très simple certaines questions intéressantes sur le présent et l’avenir de cette technologie. Quelques réponses intéressantes :

La NSA ne sait pas quand, ni même si, à un moment donné, il y aura un ordinateur quantique suffisamment puissant pour exploiter le système de clé publique actuel. C’est ce qu’on appelle un ordinateur quantique cryptographiquement pertinent.
Ce n’est pas indiqué dans la FAQ, mais en 2014, il a été révélé par Snowden que la NSA a déjà investi 80 millions de dollars dans un système quantique capable de casser la cryptographie actuelle. Il l’a appelé « Owning de net ».
Il est également important de noter qu’elle a lancé depuis 2016 un Post-Quantum Standardization Effort pour rendre les algorithmes à clé publique résistants aux dangers quantiques potentiels.

Il s’agit d’une phrase curieuse qui est probablement formulée avec une certaine intention. En tout état de cause, on ne sait jamais comment le matériel nécessaire à la construction de l’ordinateur quantique va se développer et quels progrès seront réalisés dans l’algorithme nécessaire pour casser les clés actuelles.

Plus d’information:
https://media.defense.gov/2021/Aug/04/2002821837/-1/-1/1/Quantum_FAQs_20210804.PDF

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

Print Nightmare

de jabot

On 12/08/2021

dans CVE, Sécurité

Il est difficile de suivre tous les bugs liés au spooleur d’impression de Microsoft qui apparaissent ces derniers temps. Juste après avoir publié une mise à jour censée corriger (bien qu’il ne soit pas entièrement confirmé qu’elle corrige) les problèmes d’élévation du spooleur d’impression, Microsoft vient de reconnaître un autre bogue qui permet une élévation facile du SYSTÈME. CVE-2021-36958.

Aucune solution n’est donnée, il est seulement recommandé de désactiver le spouleur d’impression (et de l’empêcher d’imprimer). Ce qui est curieux, c’est qu’elle a reconnu ce bug 8 mois après qu’un chercheur l’ait signalé en décembre 2020. Peut-être a-t-elle été mise sous pression par les conclusions du créateur de Mimikatz, qui analyse les bugs depuis #printNightmare.

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