Twitter vient de connaître sa plus grande faille de sécurité depuis des années. Mercredi, Mike nous en a avertis, mais cela vaut la peine de revoir quelques détails. L'histoire est toujours en développement, mais il semble que des acteurs malveillants aient utilisé l'ingénierie sociale pour accéder à un tableau de bord interne Twitter. Ce tableau de bord, entre autres choses intéressantes, permet de changer directement l'adresse e-mail associée à un compte. Une fois que l’adresse est remplacée par celle de l’attaquant, il est simple de réinitialiser le mot de passe et d’y accéder.

L'adresse bitcoin utilisée dans l'escroquerie cryptographique a fini par recevoir près de 120 000 $ USD de bitcoin, qui ont tous été mélangés dans différents comptes. Il s'agit d'une arnaque ancienne et simple, mais apparemment assez crédible, car les messages ont été publiés par des comptes Twitter vérifiés.

Capture d'écran de la carte mère

Une série de captures d'écran a été publiée, prétendant être le tableau de bord interne de Twitter utilisé dans l'attaque. Plus de quelques sourcils ont été relevés grâce à ce tableau de bord. Tout d'abord, le fait que les employés de Twitter puissent modifier directement l'adresse e-mail d'un compte pose problème. Les balises qui peuvent être ajoutées à un compte sont encore plus intéressantes. "Trends Blacklist" et "Search Blacklist" rappellent les rumeurs d'interdiction des ombres, mais à ce stade, il est impossible de connaître les détails. La carte mère signale que Twitter supprime cette capture d'écran à tous les niveaux lorsqu'elle est publiée, et suspend même les comptes qui la publient. Bien sûr, ils le feraient si c'était aussi truqué, alors qui sait?

SIGRed

CVE-2020-1350 vient d'être annoncé et corrigé dans le cadre de la mise à jour des correctifs de Microsoft mardi. Si vous exécutez une machine Windows Server, en particulier si un résolveur DNS est en cours d'exécution, assurez-vous d'aller immédiatement au patch. Encore un autre CVE marquant un 10 parfait, celui-ci est particulièrement mauvais car il semble être un exploit vermifuge.

Certains détails de vulnérabilité sont déjà disponibles – suffisamment pour avoir une idée de ce qui se passe. La faille réside dans la façon dont le démon DNS gère les réponses DNS SIG. Le code qui alloue un tampon pour la réponse sig utilise un entier 16 bits pour la taille d'allocation. Il atteint au maximum 64 000 caractères. Comme les réponses DNS UDP ont une taille limite imposée de 4096 octets, cela semble sûr. Comme vous pouvez le deviner, il y a un hic.

Certaines réponses DNS légitimes nécessitent en fait plus de 4096 octets. La spécification inclut donc l'indicateur de troncature, ce qui signifie que ce message ne contient pas plus dans le paquet UDP. La réponse appropriée consiste à établir une connexion TCP et à refaire la demande. Une fois que la demande DNS est effectuée via TCP, ce message peut atteindre 64 Ko. Toujours pas assez longtemps pour déclencher le bug. Entrez la compression du pointeur DNS. Les réponses DNS peuvent contenir un type simple de compression de données, généralement utilisé pour compresser un message dans un seul paquet UDP. Si cette compression est utilisée sur une requête DNS TCP, la taille finale du message décompressé peut dépasser 64 Ko.

Une fois le message décompressé, un tampon est alloué, en fonction de la taille du message, mais comme il s'agit d'un entier 16 bits, si la taille est supérieure à 64 Ko, cette valeur revient à 0. Un petit tampon est donc alloué, puis Plus de 64 Ko de données y sont copiés, écrasant la fin du tampon. En raison des fonctionnalités de sécurité intégrées dans les versions modernes de Windows Server, il existe d'autres étapes vers un compromis complet, mais en fonction de la réponse à cette vulnérabilité, il semble qu'un attaquant sophistiqué n'aura pas trop de mal à le développer en un exploit complet .

SAP RECON

Le troisième événement majeur de cette semaine est la vulnérabilité RECON dans les appareils SAP, accompagnée d'un PDF peu utile. CVE-2020-6287 a obtenu une gravité de 10, car il est exploitable à partir du réseau sans authentification et conduit facilement à une prise de contrôle complète du système. Le défaut est double, le premier est encore une autre attaque transversale de voie. L'opérateur «../» n'est pas correctement supprimé des demandes entrantes. L'autre moitié de la vulnérabilité est le fait que certains points de terminaison d'URL sur un appareil vulnérable sont accessibles sans authentification.

Une preuve de concept a été publiée sur Github, mais sans les éléments RCE. Il est probable que les détails nécessaires pour compromettre pleinement l'appareil seront déterminés rapidement, il est donc préférable de mettre à jour vos appareils immédiatement.

Contournement de sécurité Apple

MacOS dispose d'un système de sandboxing intégré, appelé TCC. Le but de ce composant particulier est d'empêcher une application d'accéder au reste du système de fichiers sans autorisation de l'utilisateur. (Jeff Johnson) a découvert un moyen de contourner cette protection et l'a signalé à Apple, qui doit encore le réparer. Après avoir attendu six mois, soit le double du délai de divulgation standard, il a publié ses conclusions à la vue de tous.

Mises à jour de sécurité Android

Les mises à jour de sécurité de juillet pour Android ont été publiées, et il y a quelques vulns intéressants, à savoir CVE-2020-0224 et CVE-2020-0225.

0224 semble être lié au traitement des expressions régulières. Sur la base de l'écriture limitée des bogues, il est difficile de savoir comment cette vulnérabilité serait déclenchée à distance. Ce bug est un peu plus ancien, découvert pour la première fois dans le projet Chromium. En raison du partage de code entre les projets, il était présent dans les deux, et seulement maintenant corrigé dans Android.

0225 est un problème Bluetooth lié à l'audio via Bluetooth. Les détails sont rares, mais il semble qu'un paquet de longueur 0 puisse déclencher un accès pointeur nul.

La découverte de 4 heures Unc0ver

Et enfin pour cette semaine, (Brandon Azad) au Project Zero de Google nous raconte l'histoire de démonter le jailbreak unc0ver, de concevoir un PoC et d'envoyer le problème à Apple. Dans le cas d'une grosse version comme celle-là, il y a une sorte de course pour voir qui peut le désosser en premier. Brandon ne pouvait pas faire de têtes ou de queues à partir de l'exploit binaire lourdement obscurci, mais il avait un truc intelligent dans sa manche. Lancez l'exploit, mais tuez cette application avant la fin de l'installation. Le système a été laissé dans un état instable, s'est écrasé et il a pu retracer l'accident jusqu'à la vulnérabilité. La rédaction complète mérite d'être vérifiée.

LAISSER UN COMMENTAIRE

Rédigez votre commentaire !
Entrez votre nom ici