Cette semaine en sécurité : OpenSSL Fizzle, Java XML et rien d’autre qu’il n’y paraît

Le monde de la sécurité a retenu notre souffle collectif en début de semaine pour la grande annonce de vulnérabilité OpenSSL. Il s’avère qu’il s’agit de deux problèmes distincts, tous deux liés à la gestion du punycode, et ils ont été rétrogradés à une gravité élevée au lieu de critique. Punycode, soit dit en passant, est le système permettant d’utiliser des caractères Unicode non ASCII dans les noms de domaine. La première vulnérabilité, CVE-2022-3602, est un débordement de tampon qui écrit quatre octets arbitraires dans la pile. Notamment, le code vulnérable n’est exécuté qu’après vérification de la chaîne d’un certificat. Un certificat malveillant devrait être soit correctement signé par une autorité de certification, soit approuvé manuellement sans signature valide.

Quelques sources ont élaboré les détails de cette vulnérabilité. C’est une erreur de un par un dans une boucle, où la longueur du tampon est vérifiée plus tôt dans la boucle que la variable de longueur est incrémentée. En raison du glissement logique, la boucle peut potentiellement s’exécuter une fois de trop. Cette boucle traite les caractères Unicode, encodés à la fin de la chaîne punycode, et les injecte au bon endroit, faisant ainsi glisser le reste de la chaîne sur un octet en mémoire. Si la longueur totale de la sortie est de 513 caractères, il s’agit d’un débordement d’un seul caractère. Un caractère Unicode occupe quatre octets, il y a donc votre débordement de quatre octets.

Maintenant, l’exploitabilité de ce débordement dépend de ce qu’il y a dans ces quatre octets. Lorsque les chercheurs de Datadog ont testé la vulnérabilité sur Linux, ils ont découvert que pratiquement chaque binaire compilé avait une section de 4 octets de mémoire libre ici, qui n’était initialisée qu’après le débordement. En d’autres termes, sur ces binaires, cette vulnérabilité est entièrement bénigne. Sous Windows, cette section de mémoire était gérée différemment par le compilateur, en raison de différentes optimisations. Ici, il contient un canari de pile. C’est une valeur spéciale qui existe entre le dernier tampon de la pile et les valeurs de pointeur et de retour. À la fin d’une fonction utilisant un canari de pile, la valeur est validée avant de retourner à la fonction parente, et le processus plante s’il a été falsifié. L’idée est qu’un débordement de tampon qui écrase l’adresse de retour ne serait pas en mesure de prédire la valeur canari, et les canaris ont tendance à inclure intentionnellement des octets de terminaison comme 0x00 pour rendre l’exploitation encore plus difficile. Notez que les binaires Linux utilisent également des canaris de pile, ce qui empêcherait les exploits, mais en raison de la disposition de la mémoire et de la longueur de débordement limitée, ceux-ci ne sont jamais modifiés.

Le deuxième problème résolu était CVE-2022-3786, et Checkpoint Security a tenté d’expliquer celui-ci. Dans le cas de Punycode suivi d’un point, ce point est ajouté à la fin de la chaîne de sortie, potentiellement après la fin du tampon. C’est l’inverse de la vulnérabilité précédente. Ici, la longueur du débordement est presque arbitraire, mais la valeur est verrouillée uniquement sur le symbole du point. Par conséquent, celui-ci est strictement un problème de déni de service.

Heureusement, le ciel ne tombe pas avec ces vulnérabilités, mais il pourrait toujours y avoir des cas imprévus où OpenSSL n’est pas compilé avec des canaris de pile, ou le crash pourrait être utilisé dans le cadre d’une chaîne d’exploitation plus compliquée, alors assurez-vous toujours de saisir le correctif mis à jour ou rétroporté si vous utilisez la bibliothèque vulnérable, versions 3.0.0-3.0.6.

Les chercheurs en sécurité se tournent-ils vers le côté obscur ?

La loi des gros titres de Betteridge est certainement en jeu ici. Cette histoire est tout simplement étrange, car quelqu’un a lancé une attaque de ransomware, qui est également un logiciel de protestation, et prétend également être l’œuvre de certains chercheurs en sécurité notables. Alors, Bleeping Computer est-il vraiment derrière cette campagne de ransomware qui proteste également contre le manque de soutien à l’Ukraine de la part de l’Occident ? Oof, il y a beaucoup à déballer ici.

Tout d’abord, il semble qu’il ne s’agisse même pas d’un rançongiciel, car il n’y a aucun moyen d’acheter une clé de déchiffrement. Donc plus correctement c’est un essuie-glace. Le nom utilisé dans la note d’essuie-glace est « Azov », un régiment des forces spéciales en Ukraine avec un passé néo-nazi étrange, qui joue dans la rhétorique russe sur leur guerre là-bas. Ensuite, la note prétend provenir de Hasherezade, et répertorie plusieurs identifiants Twitter de chercheurs en sécurité. Mentionne ensuite la Crimée et se plaint du manque d’aide pour l’Ukraine. jIl y a un message spécifique pour le peuple américain, appelant le président Biden, appelant à la révolution, puis abandonnant le slogan « Keep America Great ». Puis un message à l’Allemagne, gentiment passé par Google Traduction, nous donne : « Vous ! Un homme d’Allemagne, allez, sors !
Mais c’est une catastrophe que Biden leur a apportée. C’était sympa quand Merkel était là ? Et encore plus bizarre, la note se termine par le hashtag « #TaiwanIsChina », qui semble être un slogan de la rhétorique parrainée par le PCC autour de Taiwan.

Il est difficile de comprendre exactement ce qui se passe avec cette campagne. Ce n’est évidemment pas ce qu’il prétend être. Un hacker pro-Russie ou anti-Russie essayant d’obtenir du soutien ? Quelque chose d’entièrement différent, utilisant la géopolitique comme couverture ? Les infections semblent toutes être le résultat de SmokeLoader, l’un des botnets malware-as-a-service. Payez de l’argent, envoyez votre charge utile aux machines du botnet. Juste un rappel, si vous ou quelqu’un que vous connaissez êtes touché par l’une de ces campagnes, les services chargés de l’application de la loi veulent en avoir une trace. Afin de localiser et de poursuivre les criminels derrière ces entreprises, ils ont besoin de cas concrets pour commencer. Et même s’il semble que les criminels rançongiciels ne seront jamais attrapés, ils sont identifiés et attrapés.

Project Zero résiste à l’appeler XML4Shell

[Felix Wilhelm] a trouvé un problème Java, et pour notre plus grand plaisir partagé, il n’a pas ressenti le besoin de lui trouver un surnom « 4shell ». Cette histoire commence avec SAML, Security Assertion Markup Language, le protocole basé sur XML qui alimente une grande partie de la prise en charge de l’authentification unique sur le Web. Vous souhaitez visiter le site Web X, un fournisseur de services (SP) et utiliser votre compte à partir du site Web Y, votre fournisseur d’identité (IdP). Le SP génère une demande SAML, sous la forme d’un document XML, et votre navigateur envoie ce document à l’IdP. L’IdP confirme que vous y avez bien un compte et renvoie une signature XML via le navigateur. Comme c’est un problème potentiel évident pour le navigateur de l’utilisateur d’être celui qui gère les données de connexion, les données elles-mêmes sont vérifiées dans le cadre de la signature. L’ensemble du processus est compliqué et l’une des complexités est qu’une signature peut inclure des références à d’autres signatures. Avant que la signature ne soit entièrement vérifiée, le document XML signé peut devoir passer par plusieurs étapes de transformation, et le langage XSLT (eXtensible Stylesheet Language Transformations) est pris en charge. Ouais, c’est un langage turing-complet directement dans vos objets SAML. Et si le code effectuant la vérification ne s’est pas activé secureValidationle code est compilé en code Java pour améliorer les performances.

Une partie de ce processus de compilation consiste à convertir les valeurs de l’entrée XSLT en pool de constantes Java. Ce pool a une taille limitée et le processus de compilation ne vérifie pas correctement les limites. Que se passe-t-il lorsque vous écrivez après la fin de la piscine ? Ces données sont comprises comme des champs de classe – des champs comme les définitions de méthode. Faites le travail pour créer des valeurs valides pour les trois champs que ce débordement obstruera, et vous avez la possibilité d’exécuter un bytecode arbitraire. Cela fonctionne pour toute application Java qui gère les signatures XML – en théorie. La grande mise en garde est que secureValidation désactive toutes les transformations XSLT, mais cela n’a été activé par défaut que dans JDK 17.

urlscan.io détient des secrets

Le service fourni par urlscan.io est en fait assez utile. Donnez-lui un lien Web et il le chargera, prévisualisera la page pour vous et vous fournira des statistiques à ce sujet. Quelqu’un a envoyé un lien bizarre, et vous ne voulez pas l’ouvrir sur votre machine ? Voici votre solution. La seule chose à garder à l’esprit est qu’à moins que vous ne marquiez explicitement l’analyse comme privée, le lien et les résultats sont visibles publiquement. Github a été mordu l’année dernière, en divulguant accidentellement des noms de référentiels privés au service. Cela fait [FABIAN BRÄUNLEIN] me demande si d’autres services avaient fait une erreur similaire ? Oui. Il existe des liens vers des documents Google privés, des clés API, des invitations Sharepoint et Zoom, etc. Apparemment, plusieurs services de sécurité automatisés poussent des liens vers le service sans aucune interaction de l’utilisateur et n’utilisent pas l’API correctement. Oups.