Page 24 – learn.hack.repeat

Patch Tuesday

On 13/10/2021

Ce mois-ci, Microsoft corrige 81 vulnérabilités, dont 3 sont critiques et une est exploitée par des attaquants. C’est une élévation de privilèges dans win32k.sys.

Un autre défaut dans la file d’attente d’impression et un autre dans Exchange, les plus importants maux de tête actuels de l’entreprise, ont été corrigés sans trop de détails.

Le bug d’élévation (CVE-2021-40449) est curieux. Ils ont basé l’exploit sur un autre datant de 2016. Il est entièrement conçu pour fonctionner sur des serveurs (ce qui dénote un certain professionnalisme). Il s’agit d’une exploitation libre de l’utilisateur dans la fonction NtGdiResetDC du pilote. La technique est typique de l’élévation, un callback est défini sur la fonction en mode utilisateur, mais au moment de l’appel du pilote et au milieu de l’exécution, la fonction est appelée à nouveau et l’espace mémoire est occupé par une fonction noyau arbitraire à exécuter dans le contexte du noyau.

Les attaquants ont installé un outil que Kaspersky appelle MysterySnail RAT pour contrôler le système.

Plus d’information:
https://securelist.com/mysterysnail-attacks-with-windows-zero-day/104509/

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

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