Cette semaine en sécurité : attaque PHP désamorcée, manipulation du tableau de bord et Tillitis

Si vous utilisez PHP, vous utilisez probablement l’outil Composer pour gérer les dépendances, au moins indirectement. Et les braves gens de SonarSource ont trouvé une méchante attaque potentielle de la chaîne d’approvisionnement dans cet outil, lorsqu’il est utilisé dans le référentiel Packagist. Le problème est le support des noms de fichiers README arbitraires. Lorsqu’une mise à jour de package apparaît sur Packagist, ce service utilise un service de contrôle de version (VCS) comme Git ou Mercurial pour extraire l’emplacement du fichier readme spécifié. Cette opération d’extraction est soumise à l’injection d’arguments. Nommez votre succursale --help, et Git exécutera volontiers l’argument help au lieu de faire l’extraction prévue. Dans le cas des commandes Git, nos chercheurs intrépides n’ont pas été en mesure de militariser le problème pour obtenir l’exécution du code.

Composer prend également en charge les projets qui utilisent Mercurial comme VCS, et Mercurial a un --config option qui a… un potentiel intéressant. Il permet de redéfinir une commande Mecurial comme un extrait de script. Ainsi, un projet doit simplement contenir un programme malveillant payload.shet le fichier readme défini sur --config=alias.cat=!hg cat -r : payload.sh|sh;,txt. Pour ceux qui gardent une trace à la maison, la vulnérabilité est que cette chaîne maudite de laide est acceptée par Composer comme un nom de fichier valide. Celui-ci utilise le --config astuce pour redéfinir cat comme un peu de script qui exécute la charge utile. Il se termine en .txt car c’est une exigence de Composer.

Parlons donc de ce à quoi ce petit hack aurait pu être utilisé, ou peut-être encore utilisé sur une installation privée non corrigée de Packagist. Il s’agit d’une attaque sans surveillance qui passe directement à l’exécution de scripts à distance – sur un référentiel de packages officiel. S’il était découvert et utilisé pour le mal, cela aurait été une attaque massive de la chaîne d’approvisionnement contre les déploiements PHP. Au lieu de cela, grâce à SonarSource, il a été découvert et divulgué en privé en avril. Le référentiel officiel de Packagist sur packagist.org a été corrigé le lendemain de la divulgation, et un CVE et des packages mis à jour ont été publiés six jours plus tard. Excellent travail tout autour.

Avantage du marqueur

[Maxwell Dulin] ALIAS [Strikeout] regardait un match de basket au lycée et a soudainement remarqué le contrôleur de tableau de bord sans fil. Et s’il pouvait changer le score ? À quel point cela pourrait-il être difficile? Vous savez probablement comment cela se passe. Il s’était fait tirer dessus. Il a passé quelques mois sur celui-ci, obtenant même sa licence de jambon dans le processus. La conclusion? Plus difficile que vous ne le pensez.

La première partie de ce hack commence par lire la documentation sur les puces radio, puis faire de vraies captures et analyser les données. À propos de ces données. Un petit changement dans ce qui a été envoyé a entraîné un énorme changement dans les données en direct. A hauteur de 128 bits changeant à la fois. Ce simple petit système de tableau de bord était crypté ! Le cryptage AES-128 protégeait le système contre les altérations occasionnelles. Mais notre héros n’est pas qu’un trafiquant occasionnel.

Par conséquent, la partie 2. La prochaine étape consistait à examiner à nouveau le matériel et à cartographier les traces de PCB. L’émetteur est un ATmega connecté à un émetteur-récepteur HopeRF. Le récepteur est un émetteur-récepteur et un ATMega assortis, connectés à un Raspberry Pi 3 A+ gérant l’affichage du tableau de bord via HDMI. Le Raspberry Pi est un bon début, avec à la fois une carte SD à étudier et une clé USB dans le port USB. Un grand intérêt sur la carte ATmega est à la fois un port série et un port de débogage basé sur série. Beaucoup de surfaces d’attaque potentielles. Et enquêter sur le firmware du Pi a mené à une victoire majeure. Le logiciel qui décode les paquets sans fil est écrit en C# et peut être décompilé à l’aide de DNSpy. Bien qu’il s’agisse d’un grand pas en avant, ce qui manque, c’est la clé de cryptage elle-même.

Il est temps de souder sur l’ATmega et de voir si cela révélera ses secrets. ICSP, cette interface de débogage mentionnée précédemment, possède une commande qui permet de lire la totalité de la mémoire de la puce. Parfait! Et parce que cela ne pouvait pas être aussi simple, le paramètre de sécurité de la puce était activé, ce qui interdisait cette commande. L’approche traditionnelle du port série a également échoué, car les traces sont ancrées sur la carte de production. Il y a une autre interface à regarder, la connexion SPI (Serial Peripheral Interface) entre l’ATmega et l’émetteur-récepteur. Quelles données sont envoyées sur ce lien lors du démarrage du système ? Il s’avère que les modules RF font le gros du travail de cryptage dans ce système, et ces modules ont la particularité de perdre totalement leur configuration lorsqu’ils sont éteints. Renifler la clé a conduit à une victoire facile et une valeur clé de 0x01020304050607080102030405060708. Ce n’est probablement pas une valeur aléatoire.

La troisième partie reprend cette découverte importante et aborde le domaine de l’envoi réel de paquets sans fil. Ce n’est pas facile, cependant, car il y a du « blanchiment des données » à gérer. Ce terme étrange est juste une référence à un problème de dérive d’horloge, lorsque trop de « 0 » ou « 1 » sont envoyés à la suite sur un signal sans horloge. Le blanchiment utilise un algorithme LFSR (Linear Feedback Shift Registers), et une fois que vous avez fait ce calcul, il vous manque juste la valeur d’initialisation. Heureusement, il y a des données envoyées avec chaque paquet qui est blanchi et non chiffré – et cet algorithme n’a que 511 états initiaux possibles, donc trouver le bon IV n’est pas difficile. Ce qui ressemblait à un défi était de déterminer le contrôle de redondance cyclique (CRC). Ce sont des routines de vérification d’erreurs non cryptographiques, elles existent dans tout un tas d’endroits et il existe une multitude de variantes différentes. Et bien sûr, aucune des options publiées ne semblait convenir. Pour sauver la journée, CRC RevEng est un outil spécialement conçu pour déterminer exactement comment fonctionne un CRC donné, uniquement à partir de données d’exemple capturées. Ça marche! (Avec un hack mineur pour les paquets longs)

Maintenant, pour transformer le code en véritables signaux sans fil, il suffit d’un SDR et d’une radio GNU. L’astuce ici est de corrompre les signaux légitimes dans l’air, puis d’envoyer vos fausses commandes entre les deux. Avec cela, vous êtes le marqueur. Donner 100 points supplémentaires à l’équipe de basket de votre fils pourrait être amusant, mais cela va totalement se faire remarquer. [Strikeout] a des suggestions plus sournoises. La plus intelligente consiste à faire tourner l’horloge 10% plus vite que la normale, pour prendre une avance vers une victoire. Alternativement, changez l’indicateur de possession à la mi-temps pour donner à votre équipe la possession au prochain jumpball. Ou même planter le tableau de bord pour un délai d’attente supplémentaire non facturé. Et parce que notre clé AES *totalement aléatoire* est la même pour chacune de ces unités, vous pouvez semer le chaos partout où vous rencontrez une unité. Des points bonus pour toute personne qui met sur pied un programme wardriver, à la recherche de signaux de tableau de bord.

Pixel Patch déroutant

Le bulletin de sécurité de Google de mai contenait un RCE sérieux dans le chargeur de démarrage. Les chargeurs de démarrage sont particulièrement intéressants en tant que vecteurs d’attaque, car la plupart des appareils vous permettront de flasher les anciens chargeurs de démarrage potentiellement vulnérables sur les plus récents. L’équipe de sécurité de Google connaît bien cette astuce et dispose d’une protection contre celle-ci, la fonction anti-retour en arrière. Un nouveau chargeur de démarrage contiendra une version du chargeur de démarrage qui sera écrite de manière permanente sur l’appareil, et un micrologiciel plus ancien que celui-ci refusera simplement d’écrire sur la mémoire flash.

Ce RCE était suffisamment mauvais pour que Google ait activé l’anti-rollback Onze treize. Tout ce brouhaha convaincu [Gagnerot Georges] d’eShard pour jeter un coup d’œil. Il nous emmène dans un voyage bien écrit à travers l’ingénierie inverse du correctif, puis nous rappelle enfin que c’est la manière la plus difficile de faire les choses, car Google ouvre ses chargeurs de démarrage. Tricheur. La partie 2 contient plus d’informations sur la prise de primitives de lecture et d’écriture et sur la réalisation d’un exploit de programmation orientée retour (ROP) avec elles. Vous n’obtiendrez pas tout à fait un exploit copier-coller des messages, mais certainement un bon coup de pouce dans la bonne direction.

Les résolveurs DNS Kaminski et cachés

Nous avons déjà parlé de l’attaque DNS de Dan Kaminski. DNS utilise UDP, et il était trop facile d’usurper les réponses DNS, en particulier lorsque vous pouviez contrôler les domaines qu’un résolveur donné demanderait à un moment donné. L’attaque a été divulguée en privé aux principaux fournisseurs et corrigée en 2008. Nous savons qu’elle est corrigée, car nous pouvons analyser les résolveurs DNS du monde. Mais qu’en est-il des résolveurs que nous ne pouvons pas vérifier ? Étaient-ils tous réparés ? Avec un résolveur DNS disponible uniquement pour les parties de confiance et caché derrière un pare-feu d’entreprise, il est sûrement sûr.

Sauf que DNS est maintenant utilisé pour la détection de spam. Mes excuses si vous avez dû faire fonctionner ces technologies – mais Sender Policy Framework (SPF); Courrier identifié par clés de domaine (DKIM); et Domain-based Message Authentication, Reporting & Conformance (DMARC) utilisent tous des enregistrements DNS pour stocker des informations sur les paramètres de messagerie. Envoyez un e-mail à un utilisateur @Corp.com, et le serveur de messagerie de corp.com effectuera probablement plusieurs recherches DNS sur votre domaine d’envoi. Et ainsi, ces résolveurs cachés ne sont plus cachés. Alors, quels sont les résultats ? L’analyse de seulement 7 000 domaines a révélé 25 serveurs dans le monde qui sont toujours vulnérables à l’attaque de Kaminski.

Bits et octets

Wireshark 4.00 est sorti. Une poignée de nouveaux protocoles sont pris en charge et les bosses de bibliothèque normales auxquelles vous vous attendez. Certaines fonctionnalités voient une amélioration de la vitesse et les interfaces sont un peu crachées.

Vous voulez un jeton de sécurité matériel, mais vous voulez vraiment qu’il soit entièrement ouvert ? La tillite pourrait être pour vous. Il s’agit d’une plate-forme USB pour expérimenter de nouvelles idées de clés de sécurité, et est entièrement open source, y compris le matériel. Il n’y a pas encore d’endroit où aller en commander un, mais vous pouvez demander à votre fabricant de PCB préféré d’en construire un pour vous. La première révision manque également d’un certain renforcement matériel qui doit vraiment être présent pour les cas d’utilisation de grande valeur, mais ce projet est à surveiller.

Google a publié le jeu/expérience Hacking Google. C’est une série de défis Capture The Flag, juste pour le plaisir, mais une bonne pratique pour résoudre un problème de sécurité.

Un autre exploit PS5 est en cours de développement, basé sur une vulnérabilité WebKit connue. Tromper le navigateur de la console en chargeant un fichier cuit, et vous déclenchez l’exploit. C’est utile, mais toujours un travail en cours, et ne va pas encore à l’encontre de l’hyperviseur ou n’exécute pas de code arbitraire.

La semaine dernière, nous avons couvert une fausse arnaque à la demande d’emploi, et cette semaine, c’est un faux recruteur. Un e-mail a attiré l’attention de [osint_matter], car il était bien rédigé, envoyé à une adresse professionnelle et que les enregistrements DNS des e-mails étaient correctement configurés. Il était lié à un site Web de recrutement d’apparence décente: MHS partners. Peut-être était-ce légitime ? Ah, non, ce site était rempli de photos d’archives, et les noms des partenaires faisaient référence à des émissions de télévision américaines. Une recherche d’images Google sur les images a permis de trouver d’autres sites similaires avec des noms de sociétés différents. Bien qu’il s’agisse de l’un des inconvénients les mieux gérés, il semble toujours qu’il s’agisse d’une expédition de phishing. Dans ce cas, recherchez des CV et d’autres informations à vendre ou à utiliser à mauvais escient.