learn.hack.repeat

Catégorie : CVE Page 6 of 10

Vol de jeton JWT dans VMWare Workspace ONE Access

Une vulnérabilité dans VMWare Workspace ONE Access (anciennement connu sous le nom de VMware Identity Manager), qui fournit une authentification multifactorielle à d’autres services, permet d’obtenir un jeton JWT avec des autorisations d’administrateur en exploitant un SSRF.

L’équipe de recherche d’Assetnote a découvert une vulnérabilité dans la fonction responsable de la surveillance des instances de VMWare Workspace ONE, grâce à laquelle des jetons JWT avec des autorisations d’administrateur peuvent être obtenus. La vulnérabilité exploite un SSRF (server-side request forgery), qui permet à une demande avec les informations d’identification d’être faite à un serveur contrôlé par l’attaquant.

VMWare Identity Manager, désormais connu sous le nom de Workspace ONE Access, est utilisé pour fournir une authentification multifactorielle, un accès restreint et une authentification unique aux services SaaS, aux sites Web et aux applications mobiles. Ce produit est utilisé par de multiples applications d’entreprise dans différents secteurs pour fournir une méthode d’authentification centralisée.

L’exploitation nécessite des informations d’identification d’accès au gestionnaire d’informations d’identification VMWare afin d’appeler la fonction dans ‘/SAAS/API/1.0/REST/system/health/instanceHealth’.
Ce chemin est chargé de demander la surveillance d’une des instances enregistrées dans le service. Pour ce faire, il reçoit deux paramètres : ‘hostname’ (le serveur distant à surveiller) et ‘path’ le chemin du serveur distant à appeler. Bien qu’une liste blanche vérifie que le premier appartient à l’une des instances configurées, le second n’est pas vérifié et peut être utilisé dans l’exploit. Si le code de la fonction est vérifié :

Construction de l’url à appeler depuis le VMWare Identity Manager. Source : Assetnote.

La première conditionnelle construit l’url en utilisant le ‘hostname’ et le ‘path’, et bien que dans une fonction précédente le ‘hostname’ soit vérifié (par exemple ‘bob.com’) en ne vérifiant pas si le chemin commence par un slash (‘/’) le symbole @ peut être utilisé (par exemple ‘@eve.com’) pour construire l’url ‘bob.com@eve.com’, étant ‘eve.com’ le destinataire réel de la requête. L’exemple complet de l’exploit serait : « /SAAS/API/1.0/REST/system/health/instanceHealth?hostname=bob.com&path=@eve.com ».

L’url construite à partir de la conditionnelle ci-dessus sera utilisée dans la fonction ‘getStatusFromRemoteHost’, qui fait une demande à l’url en incluant le jeton avec des autorisations d’administrateur. Si le serveur cible est contrôlé par un attaquant, comme dans l’exemple ci-dessus, l’attaquant recevra le jeton :

Fonction permettant d’obtenir l’état du serveur distant, indiquant la ligne avec le jeton à envoyer. Source : Assetnote.

La vulnérabilité a été identifiée comme étant CVE-2021-22056 avec un score de 7.5 (niveau de risque élevé). L’équipe de VMWare a publié un avis concernant cette vulnérabilité et d’autres, qui sont déjà corrigées. La vulnérabilité a été découverte le 5 octobre 2021, et résolue par VMWare le 17 décembre. Il est recommandé de mettre à jour dès que possible la dernière version disponible afin de résoudre ces problèmes.

Plus d’information:
https://blog.assetnote.io/2022/01/17/workspace-one-access-ssrf/

Browser nightmare

La sécurité des navigateurs s’est beaucoup améliorée ces dernières années, mais les dizaines de « 0days » découverts dans Chrome ces derniers temps font réagir le secteur. Chrome a annoncé qu’il mettrait en œuvre une spécification du W3C appelée accès au réseau privé (PNA), qui protégera les attaquants contre l’accès aux ressources internes telles que les routeurs ou les serveurs par CSRF dans le navigateur.

Edge, quant à lui, a fait un pas de plus. Il mettra en œuvre un mode de navigation spécialement conçu pour améliorer la sécurité contre les vulnérabilités inconnues (0days). Pour ce faire, elle a mis en œuvre une série de modifications du registre qui, une fois activées, permettront d’appliquer cette sécurité et d’autoriser des exceptions. Il s’agit de EnhanceSecurityMode, EnhanceSecurityModeBypassListDomains et EnhanceSecurityModeEnforceListDomains.
Cela permettra d’activer trois mesures génériques d’atténuation des exploits dans le navigateur :

  • Hardware-enforced Stack Protection : elle permet une protection au niveau du processeur (en prenant en charge la technologie Shadow stack sur AMD et la technologie CET sur Intel) contre les attaques typiques par débordement de pile.
  • Arbitrary Code Guard (ACG), Alors que grâce à la technologie CIG de Windows, un processus ne peut pas charger de binaires non signés, ACG empêche cela avec du code mappé en mémoire.
  • Content Flow Guard (CFG). Une technologie qui a échoué (Microsoft a dû arrêter de payer des primes pour le contournement) pour tenter de prévenir à nouveau les exploits fonctionnels.

Plus d’information:
https://docs.microsoft.com/en-us/deployedge/microsoft-edge-relnote-beta-channel#version-980110823-january-14

Patch Tuesday

Microsoft a publié, comme chaque deuxième mardi du mois, sa série de correctifs de sécurité. Au cours de ce mois, Microsoft a corrigé un total de 97 vulnérabilités, dont 9 vulnérabilités à risque critique, ainsi que 6 vulnérabilités 0day, qui ont été publiquement divulguées sans l’existence d’un correctif de sécurité.

Les vulnérabilités, établies comme critiques par Microsoft, et corrigées dans le Patch Tuesday sont les suivantes :

Les vulnérabilités, établies comme 0day par Microsoft, ont été identifiées comme CVE-2021-22947, CVE-2021-36976, CVE-2022-21919, CVE-2022-21836, CVE-2022-21839 et CVE-2022-21874.

Actuellement, aucune activité liée aux vulnérabilités divulguées n’a été détectée. Cependant, étant donné qu’il existe des POC publiques pour certaines de ces vulnérabilités, il est recommandé d’appliquer de toute urgence les correctifs de sécurité de Microsoft.

Pour obtenir une liste complète des vulnérabilités avec des correctifs de sécurité, veuillez consulter le guide des mises à jour de sécurité de Microsoft.

Plus d’information:
https://msrc.microsoft.com/update-guide/vulnerability
https://www.tenable.com/blog/microsofts-january-2022-patch-tuesday-addresses-97-cves-cve-2022-21907

Nouvelles failles de sécurité critiques chez Netgear

La société Netgear, spécialisée dans les systèmes de mise en réseau, publie plusieurs failles de sécurité critiques pour ses appareils.

Ces derniers jours, plusieurs vulnérabilités de sécurité ont été successivement publiées. Elles pourraient permettre à un attaquant non authentifié de provoquer un dépassement de tampon (CVE-2021-45611) et d’effectuer une injection de commande avant l’authentification, permettant ainsi une élévation de privilèges (CVE-2021-45618) ; toutes deux dues à la manipulation d’une entrée qui n’a pas été publiée par Netgear.

La dernière vulnérabilité critique annoncée permettrait à un attaquant de contourner l’authentification en raison d’une authentification faible (CVE-2021-45496), affectant l’intégrité, la disponibilité et la confidentialité des ordinateurs. Les fonctions affectées par ces bugs n’ont pas été divulguées.

De nombreux périphériques réseau fabriqués par la société sont affectés par ces failles de sécurité, il est donc recommandé de mettre à jour vers les dernières versions disponibles à partir du lien suivant :

https://www.netgear.com/support/

Plus d’information:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45618
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45496
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45611

Guide d’atténuation de Log4j publié par le ministère américain de la Sécurité intérieure

L’Agence pour la cybersécurité et les infrastructures (CISA) du ministère américain de la sécurité intérieure a publié des recommandations sur la manière de remédier à la vulnérabilité désormais répandue d’Apache Log4j.

Tout d’abord, les vendeurs doivent identifier, atténuer et mettre à niveau les produits utilisant Log4j vers la dernière version de la bibliothèque.

Deuxièmement, toutes les organisations doivent prendre immédiatement les mesures suivantes :

  • Identifiez toutes les ressources accessibles via Internet qui permettent la saisie par l’utilisateur et utilisent la bibliothèque Log4j quelque part dans leur infrastructure.
  • Identifiez tous les actifs qui utilisent Log4j.
  • Mettez à jour ou isolez les actifs affectés. Une fois identifiée, l’organisation doit rechercher des indicateurs de compromission et des schémas habituels d’activités post-exploitation. Supposons que l’actif a été compromis.
  • Surveillez les schémas de trafic inhabituels. Par exemple, le trafic sortant lié aux protocoles JNDI, LDAP/RMI, DNS ou DMZ.
Flux d’actions pour identifier les installations vulnérables. Source : https://www.cisa.gov

Une fois le risque maîtrisé, les utilisateurs ou organisations concernés doivent, dans la mesure du possible, mettre à niveau la bibliothèque vers la dernière version disponible. Si une mise à niveau n’est pas possible, les contre-mesures suivantes sont recommandées :

  • Désactiver les logiciels qui utilisent la bibliothèque. Cela pourrait limiter la visibilité d’autres problèmes opérationnels, car ĺa bibliothèque est chargée de prendre les journaux.
  • Bloquer les recherches JNDI. Il s’agit d’une option efficace, mais qui peut nécessiter des travaux de développement et une perte de fonctionnalité.
  • Arrêter temporairement les infrastructures touchées. Cela réduirait la probabilité d’une attaque.
  • Créez un réseau isolé pour séparer les infrastructures touchées du reste du réseau de l’entité.
  • Déployer un WAF pour protéger les infrastructures concernées. Bien qu’elle ne soit pas une solution complète, elle peut contribuer à réduire le nombre de menaces.
  • Appliquez des micro-patchs. Il existe des solutions qui ne font pas partie de la mise à jour officielle mais qui peuvent contribuer à atténuer les risques dans certains cas spécifiques.

Pour rester à jour, la CISA a créé un dépôt Github où elle publiera les mises à jour de ce protocole : https://github.com/cisagov/log4j-affected-db.

Plus d’information :
https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance

Page 6 of 10

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