Tout d’abord, une sorcellerie intelligente du [Aqua Nautilus] équipe de recherche, qui a découvert une attaque temporelle qui divulgue des informations sur les packages npm privés. La configuration est la suivante, npm héberge les packages node.js publics et privés. Les packages publics sont accessibles à tous, mais les packages privés sont « scoped », ce qui signifie qu’ils vivent dans un espace de noms privé, « @owner/packagename » et sont inaccessibles au grand public. Essayer d’accéder au package entraîne une erreur HTTP 404 – la même erreur que d’essayer d’extraire un package qui n’existe pas.
Le plus intelligent est de continuer à essayer et de prêter vraiment attention aux réponses. Utilisez l’API de npm pour demander des informations sur votre package cible, cinq fois de suite. Si le nom du package n’est pas utilisé, les cinq requêtes prendront le temps prévu. Cette requête atterrit sur le backend du service, une recherche est effectuée et vous obtenez la réponse. D’un autre côté, si votre package cible existe, mais qu’il est de portée privée, la première requête revient avec le délai prévu et les quatre autres requêtes reviennent immédiatement. Il semble que npm dispose d’un frontal capable de mettre en cache une réponse 404 pour un package privé. Cet écart de temps de réponse signifie que vous pouvez cartographier les noms de packages privés utilisés par une organisation donnée dans leur étendue privée.
Maintenant, tout cela est très intéressant, mais cela se transforme en une attaque plausible lorsqu’il est combiné avec des problèmes de confusion de typosquattage et de dépendance. Ces attaques sont deux approches pour le même objectif, obtenir un déploiement node.js pour exécuter un package malveillant au lieu de celui légitime prévu par le développeur. L’un dépend des fautes de frappe, mais la confusion des dépendances repose uniquement sur le fait qu’un développeur ne définit pas explicitement la portée d’un package.
Siemens a laissé les clés dans le contact
Siemens a publié la version 12 de son portail TIA il y a près de 10 ans et, avec cette mise à jour, a ajouté la cryptographie asymétrique entre le portail et ses produits SIMATIC S7-1200 et S7-1500. Pour le dire en langage clair, leurs contrôleurs industriels ont commencé à utiliser HTTPS pour communiquer avec le logiciel du contrôleur. C’était une bonne chose. Malheureusement, la clé privée de cette connexion HTTPS réside sur le matériel du contrôleur, et chaque unité livrée avait la même clé.
Le vrai plaisir est de savoir comment l’équipe de Claroty a découvert tout cela. Les contrôleurs industriels sont programmés dans un langage spécifique de haut niveau, strictement réservé à la logique d’automatisation. Les pointeurs, la gestion de la mémoire et le reste de nos vecteurs vulnérables normaux n’apparaissent pas ici. Ces programmes sont compilés dans un bytecode personnalisé qui s’exécute dans un environnement contrôlé sur le contrôleur. Alors naturellement, nos chercheurs ont procédé à l’ingénierie inverse du bytecode et ont écrit leur propre compilateur, pour avoir accès à ces fonctionnalités sous le capot. Il était toujours difficile de vaincre les contrôles de sécurité intégrés à cet environnement, mais ils ont finalement trouvé une fonction qui pouvait définir un pointeur sur une valeur arbitraire, permettant les lectures et les écritures du noyau. Y compris la lecture de la clé universelle.
Et cela nous amène à la première véritable attaque que permet d’avoir cette clé secrète mais partagée. Selon la configuration, il est parfois possible de télécharger le blob de configuration sans authentification. L’un des éléments contenus dans cet ensemble de données est le hachage de mot de passe crypté, qui a été crypté à l’aide – vous l’avez deviné – de cette clé universelle. Avec la clé en main, un attaquant peut télécharger le hachage, le déchiffrer, puis s’authentifier à l’aide du hachage.
Et puis, avoir la clé secrète d’un certificat HTTPS permet toutes les manigances normales auxquelles on pourrait penser : capturer le trafic et le décrypter, ou effectuer une attaque de type « man-in-the-middle ». Les problèmes ont été résolus avec les dernières mises à jour du micrologiciel et du portail, et Siemens a publié un avis reconnaissant les problèmes. Regardez la vidéo ci-dessous pour l’histoire de première main de l’évasion de The Matrix et de l’exécution de code réel sur ces machines.
(La société mère de Hackaday, Supplyframe, appartient à Siemens.)
PNG valide, PHP valide
Il y a toujours quelque chose d’étrangement amusant à propos d’un fichier qui est valide sous plusieurs formats de fichiers très différents. Dans ce cas, c’est le fichier PNG qui vaut également PHP. L’angle de sécurité ici est que de nombreux sites Web vous permettent de télécharger des fichiers PNG, puis de les afficher. Si ce PNG pouvait aussi être sournoisement un fichier PHP, vous avez un webshell instantané. Maintenant, il existe probablement des sites non sécurisés où il suffit de télécharger un script, mais de nombreuses bibliothèques de téléchargement vérifieront au moins que le fichier est valide pour le type MIME spécifié. Simplement, il doit s’agir d’un PNG valideif set to image/png. Mais est-ce suffisant ?
Les fichiers PNG peuvent contenir des commentaires. Que fait un serveur Web lorsqu’il sert un .php fichier contenant également des données PNG binaires ? Dans de nombreux cas, il le traite comme n’importe quel autre fichier, en envoyant les données brutes jusqu’à ce qu’il trouve un <?php tag, où il pourrait simplement commencer à exécuter le script PHP. La question suivante est de savoir comment créer un fichier tel que le script PHP persiste à travers la compression, le redimensionnement et d’autres étapes de nettoyage ? La première approche discutée consiste à utiliser des blocs tEXt, qui sont généralement utilisés pour stocker le titre, l’auteur, etc. Dans de nombreux cas, ces morceaux de texte incorporé persisteront malgré toutes les modifications.
L’autre approche, plus difficile, consiste à incorporer directement du texte en tant que données d’image. Il y a le morceau PLTE, où les entrées de palette personnalisées peuvent être définies. Ceux-ci peuvent avoir n’importe quelle valeur, mais doivent avoir une longueur multiple de trois et un maximum de 768 caractères. Le plus difficile est d’utiliser les morceaux IDAT réels, AKA les données de pixels valides réelles. C’est vraiment de la magie profonde.
Zoneminder — Ça aurait pu être pire
Celui-ci frappe près de chez moi, car il s’agit d’un trio de vulnérabilités dans un projet que je recommande et pour lequel je lance occasionnellement du code. [Trenches of IT] a contacté le projet le 30 avec un trio de vulnérabilités qui avaient le potentiel d’être vraiment moche une fois assemblées. Le premier est une faille d’injection de journal, où un utilisateur Web peut pousser des données arbitraires dans les journaux ZM, sans limitation de débit. Besoin des caméras pour arrêter l’enregistrement ? Remplissez le lecteur de messages de journal. Le message lui-même et le composant qui l’a envoyé peuvent être définis arbitrairement.
La prochaine étape est un contournement CSRF. Cross-Site Request Forgery est une attaque dans laquelle le navigateur d’un utilisateur final effectue une action non prévue par l’utilisateur, simplement en faisant une requête HTTP. ZM utilise des jetons CSRF pour se protéger contre de tels problèmes, qui est un jeton aléatoire, fourni par le service Web, qui doit être inclus dans toutes les requêtes POST. Le contournement dans le cas de ZM est que certaines actions, comme la suppression d’un enregistrement, peuvent être effectuées en tant que requêtes GET, qui ne nécessitent pas de jeton. Oups.
Le dernier problème a le potentiel d’être le pire, car il s’agit d’un problème de script intersite (XSS). Ce problème d’injection de journal active également celui-ci, car le champ « fichier » peut contenir du code HTML arbitraire, y compris une balise de script. Rassemblez les trois problèmes et un utilisateur disposant de privilèges d’affichage uniquement peut injecter une commande de suppression ou de désactivation qui se déclenchera lorsqu’un administrateur consultera les journaux. C’est mauvais, mais au moins ce n’est pas une vulnérabilité de pré-autorisation. Il a été corrigé en 1.36.27, publié le 7. S’il vous arrive d’être bloqué dans la série de versions 1.34, quelques autres problèmes sont en suspens et aucune autre version n’est prévue pour cette version obsolète. Grâce à [Trenches of IT] pour trouver et signaler!
Le cadeau de Microsoft qui continue de donner
Vous vous souvenez de l’Exchange 0-day, celui qui était en quelque sorte une solution de contournement à un problème plus ancien avec le point de terminaison de découverte automatique ? Eh bien, il n’a toujours pas été corrigé et les solutions de contournement recommandées ont été mises à jour plusieurs fois, car elles ont été trivialement contournées. Il est peut-être temps de débrancher la découverte automatique et de bloquer tout accès extérieur à IIS pendant que vous y êtes.
Exécution Python et Userland
Enfin un conseil rapide pour l’équipe rouge. Vous avez lancé un shell sur un serveur et vous souhaitez intégrer des outils pour commencer à explorer l’environnement. La racine est montée en lecture seule et vos répertoires temporaires sont tous montés noexec. Comment obtenez-vous un binaire sur le système et l’exécutez-vous? Si Python est installé, vous pouvez utiliser ulexecve. [Vincent Berg] a écrit l’outil et a l’histoire. Son fonctionnement est tout aussi impressionnant, car il télécharge et analyse un binaire donné, le charge manuellement en mémoire et génère le tampon de saut. Enfin, il saute l’exécution du code dans le nouveau binaire, qui n’a jamais besoin d’être écrit sur le disque. Difficile.
