L’usurpation/l’empoisonnement DNS est l’attaque découverte par [Dan Kaminski] en 2008 qui refuse tout simplement de s’en aller. Cette semaine, une vulnérabilité a été annoncée dans les bibliothèques standard uClibc et uClibc-ng, rendant à nouveau pratique une attaque par empoisonnement DNS.
Donc, pour un rappel rapide, les recherches DNS se produisent généralement sur des connexions UDP non chiffrées, et UDP est une connexion sans état, ce qui facilite l’usurpation. À l’origine, DNS utilisait simplement un ID de transaction 16 bits (TXID) pour valider les réponses DNS, mais [Kaminski] réalisé que cela n’était pas suffisant lorsqu’il était combiné avec une technique qui générait des quantités massives de trafic DNS. Cette attaque pourrait empoisonner les enregistrements DNS mis en cache par les serveurs DNS publics, amplifiant considérablement l’effet. La solution consistait à randomiser le port source UDP utilisé lors de l’envoi de requêtes UDP, ce qui rendait beaucoup plus difficile de « gagner à la loterie » avec un paquet usurpé, car le TXID et le port source devaient correspondre pour que l’usurpation fonctionne.
uClibc et uClibc-ng sont des implémentations miniatures de la bibliothèque standard C, destinées aux systèmes embarqués. L’une des choses que cette bibliothèque standard fournit est une fonction de recherche DNS, et cette fonction a un comportement étrange. Lors de la génération de requêtes DNS, le TXID est incrémentiel – il est prévisible et non aléatoire. De plus, le TXID sera périodiquement réinitialisé à sa valeur initiale, de sorte que même l’intégralité de l’espace de clé 16 bits n’est pas sollicitée. Pas génial.
La torsion vient quand on regarde l’histoire de uClibc. Il a été écrit à l’origine pour μClinux, un port Linux pour les microcontrôleurs. Lorsque Linksys a publié la source du WRT54G, certains des projets nés autour de cette suppression de code ont combiné la source avec la bibliothèque uClibc et buildroot. OpenWRT était l’un des utilisateurs les plus notables, et lorsque le développement d’uClibc s’est arrêté, les développeurs d’OpenWRT l’ont transformé en uClibc-ng. OpenWRT a gagné en popularité et plusieurs fournisseurs comme Qualcomm l’ont adopté comme SDK. C’est ainsi que nous obtenons des choses comme OpenWRT 15.05 en cours d’exécution sur le routeur Starlink.
La divulgation de la vulnérabilité (premier lien, tout en haut ^) vérifie le nom d’OpenWRT comme utilisant uClibc-ng. Ce fut le cas jusqu’en 2017, lorsque la version LEDE est passée à la bibliothèque standard musl mieux entretenue. Aucune version maintenue d’OpenWRT ne présente cette vulnérabilité. Le problème, ce sont des appareils comme le routeur Starlink, qui peuvent être vulnérables, car il exécute un ancien fork d’OpenWRT.
Réviser le code à la dure
Des chercheurs du groupe Dolos ont été embauchés pour une tâche simple, une revue de code pour le code robot. Robot signifie ici Robots RPA d’Automation Anywhere – extraits de code Robotic Process Automation. Ce sont des scripts avec des interfaces graphiques pour automatiser un processus, comme la copie de données d’un formulaire à un autre. Le problème est que ces scripts étaient moins que simples à auditer. C’était un zip, contenant des fichiers XML, contenant des données encodées en Base64. Décodez les données base64 et le résultat est… un bruit aléatoire. Les possibilités sont qu’il s’agit en fait de données binaires, qu’elles soient compressées ou cryptées. Un test rapide avec ent révèle que c’est presque parfaitement aléatoire – c’est crypté. Comment procédez-vous pour auditer le code crypté ? La meilleure question est peut-être, comment l’application exécute-t-elle le code crypté ?
La réponse est simple : le programme d’installation du framework inclut des clés AES codées en dur. Nous pourrions nous demander quel est l’intérêt du chiffrement à clé pré-partagée, lorsque la clé est accessible au public. Si nous nous permettons d’être un peu blasés, nous pourrions conclure que ces scripts sont cryptés uniquement pour que l’entreprise puisse annoncer un « cryptage de qualité bancaire » sur son site Web – il n’y a certainement aucun avantage en matière de sécurité. Les chercheurs du groupe Dolos sont un peu plus charitables, observant simplement que la gestion des clés est un problème beaucoup plus difficile que la cryptographie elle-même.
Le piratage bancaire simplifié
[Hussein Daher] et [Shubham Shah] d’Assetnote a relevé le défi du programme de primes aux bogues d’une banque et a découvert que dotCMS était l’avenue la plus intéressante à parcourir. Pourquoi? C’est open source, donc ils faisaient de l’audit de code au lieu d’une enquête de boîte noire. Et l’audit a en effet trouvé quelque chose d’intéressant. DotCMS avait une fonction de téléchargement de fichiers avec une faille de traversée de répertoire. Cela signifie théoriquement un RCE facile – il suffit de télécharger un shell Web et d’ouvrir l’URL. Sur le système réel, c’est un peu plus compliqué. Tout d’abord, ils devaient mapper la structure de répertoires du système cible, ce qui n’était pas une tâche facile. Même en utilisant une astuce, /proc/self/cwd/ pour accéder au bon répertoire, la racine Web réelle était bien verrouillée. Le PoC réel qui a fonctionné consistait à attaquer l’emplacement JavaScript, car ces scripts pouvaient être écrasés. C’est une histoire amusante de trouver un problème assez grave. Il semble qu’ils se soient plutôt bien débrouillés lors de cette recherche de primes de bogues.
La chèvre Kubernetes
La meilleure façon d’en savoir plus sur la sécurité d’une plate-forme est de plonger et de se salir les mains. C’est apparemment l’avis de [Madhu Akula], qui a construit Kubernetes Goat comme un terrain de jeu intentionnellement peu sûr pour Kubernetes. Le cluster d’images Docker est livré avec une série de scénarios – des vulnérabilités guidées que vous pouvez explorer et tirer des enseignements. Si la sécurité Docker ou Kubernetes semble intéressante, saisissez la chèvre par les cornes et plongez.
Qui est UNC3524
Mandiant a découvert un groupe APT particulièrement sournois, les nommant UNC3524. Considérez cela comme un espace réservé, car il y a de fortes chances que ce soit l’un de nos vieux amis, comme Fancy Bear et Cozy Bear, deux groupes basés en Russie. Il n’y a pas assez de cadeaux pour faire une identification positive, et il pourrait s’agir d’un groupe entièrement différent, car tous les indicateurs sont des techniques publiquement connues – comme l’utilisation de reGeorg pour les connexions par procuration. C’est un logiciel open source, ainsi qu’une intelligence open source.
Quoi qu’il en soit, ces gars ont réussi des exploits impressionnants, comme rester dans un réseau sans être détecté pendant 18 mois dans certains cas. Une technique distincte consiste à compromettre les appareils IoT sur le réseau, comme les caméras IP, et à les utiliser comme serveurs de commande et de contrôle locaux. Comme on dit, le S dans IoT signifie sécurité. La ségrégation de réseau est votre amie.
Une fois qu’un pied est établi, le groupe cible les informaticiens et les cadres, et tente d’accéder à leurs comptes de messagerie. Il a émis l’hypothèse que les comptes informatiques sont ciblés pour savoir quand l’infection est découverte. L’accès au compte exécutif a montré que les attaquants cherchaient à être informés à l’avance des nouvelles de l’entreprise, comme les fusions et acquisitions. Connaître ce type de plans à l’avance pourrait donner à un investisseur un avantage considérable dans le trading, mais les techniques avancées suggèrent un acteur parrainé par le gouvernement. Peut-être que la Russie ou un autre État développe une nouvelle source de revenus. Il y a quelques indicateurs de compromis à surveiller. L’un des plus faciles à repérer est le trafic SSH sur les ports non standard. Il existe également quelques noms DNS connus.
Via Ars Technica
