learn.hack.repeat

Catégorie : Sécurité Page 23 of 26

Microsoft Exchange Emergency Mitigation

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

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

Print Nightmare

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

Patch Tuesday

Très peu de vulnérabilités corrigées ce mois-ci (44 en comptant les vulnérabilités « pures » de Microsoft et 51 en comptant celles partagées avec Cromium) par Microsoft compte tenu de l’escalade de privilèges et du désastre d’Exchange que nous avons subi ces dernières semaines. 7 sont critiques, deux étaient déjà connus et un était exploité par des attaquants.

  • Parmi les deux connues, l’une est la célèbre liée à la file d’attente d’impression. CVE-2021-36936. Comme il y avait plusieurs bogues à cet égard, Microsoft s’est en fait attaqué au comportement de la fameuse fonctionnalité Point and Print, qui semble être la source de tous les problèmes. Quoi qu’il en soit, il semble, d’après les tests effectués par plusieurs chercheurs, que le problème n’est toujours pas complètement résolu.
  • L’autre est petitPotam CVE-2021-36942. Ce qu’il a fait, c’est de bloquer l’accès aux appels API qui ont été utilisés pour forcer une tentative d’authentification NTLM.
  • L’un des plus sérieux cependant est CVE-2021-26424. Il s’agit de l’exécution de code dans la pile TCP/IP qui gère l’ipv6.
  • Un autre bug très grave est celui du service Windows Update Medic, qui récupère le système à partir d’un état corrompu.
  • 6 bugs ont également été corrigés dans Chromium.

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

PetitPotam

PetitPotam n’est toujours pas résolu, et Microsoft recommande toujours de regarder la lune et non le doigt, c’est-à-dire de désactiver Web PKI sur un domaine alors qu’en fait le problème est double : continuer à utiliser le protocole d’authentification NTLM en général, et le fait que vous pouvez vous connecter via RPC aux appels MS-EFSR sans authentification. Mais quelqu’un s’est souvenu d’une solution alternative, puisqu’il n’est pas possible d’arrêter complètement le service de cryptage et bien sûr de bloquer l’accès RPC au système : bloquer les filtres RPC spécifiques avec netsh.
Lors de la communication avec les tuyaux efsrpc et lsarpc, le client et le serveur échangent un UUID spécifique pour savoir de quoi ils parlent, comme l’indique la documentation elle-même :

“Remote servers MAY respond to EFSRPC messages sent using the well-known endpoint \pipe\lsarpc. When connecting to \pipe\efsrpc, the server interface is identified by UUID [df1941c5-fe89-4e79-bf10-463657acf44d], version 1.0. When connecting to \pipe\lsarpc, the server interface is identified by UUID [c681d488-d850-11d0-8c52-00c04fd90f7e”

L’astuce consiste à bloquer ces UUID avec ces commandes (enregistrées dans un fichier txt) :

rpc
filter
add rule layer=um actiontype=block add condition field=if_uuid matchtype=equal data=c681d488-d850-11d0-8c52-00c04fd90f7e
add filter add rule layer=um actiontype=block
add condition field=if_uuid matchtype=equal data=df1941c5-fe89-4e79-bf10-463657acf44d
add filter
quit

Et ensuite l’exécuter avec netsh -f file.txt

Plus d’information:
https://twitter.com/gentilkiwi/status/1421949715986403329

Page 23 of 26

Fièrement propulsé par WordPress & Thème par Anders Norén