Cette semaine en sécurité : OpenSSH, Git et une sorte de NGINX 0-day

OpenSSH a créé sa version 9.0 et inclut une paire de modifications de sécurité. Contrairement à la plupart des versions que nous couvrons ici, celle-ci a un renforcement de la sécurité pour éviter les problèmes, pas des correctifs d’urgence pour les versions actuelles. Tout d’abord, le vénérable protocole scp/rcp a été supprimé. Ton scp les commandes utiliseront désormais SFTP sous le capot. Le changement de sécurité le plus intéressant est le nouvel échange de clés par défaut, l’algorithme NTRU. On pense que NTRU est quantique dur.

Une introduction rapide : le chiffrement moderne dépend des fonctions de la trappe : des calculs faciles à effectuer dans un sens, mais très difficiles à inverser. Le premier de ces schémas était l’échange de clés Diffie-Hellman, qui utilise de grands nombres premiers multipliés ensemble. La multiplication est facile, mais la factorisation du résultat est un problème très difficile. Si jamais un raccourci était trouvé pour faciliter l’affacturage, la sécurité de Diffie-Hellman en souffrirait. Un tel raccourci a théoriquement été trouvé dans l’algorithme de Shor. (Des raccourcis similaires ont théoriquement été trouvés dans d’autres schémas, y compris la courbe elliptique.)

L’algorithme de Shor est en fait assez intelligent. La vidéo ci-dessus l’explique beaucoup mieux que moi, mais la clé est que cela dépend d’une fonctionnalité qui peut être intégrée aux ordinateurs quantiques, de sorte que de nombreuses solutions possibles peuvent être traitées à la fois, et les mauvaises s’annulent, ne laissant qu’un sortie probablement correcte. Le problème est que les ordinateurs quantiques de pointe ont réussi à factoriser 21 dans leurs facteurs premiers. Pas un numéro à 21 chiffres, attention, mais 21.

Nous sommes très loin de la crypto-apocalypse informatique quantique qui nous a été promise. Alors pourquoi les projets mettent-ils en œuvre des protocoles résistants au quantum ? Le scénario « capturer maintenant, déchiffrer plus tard ». Parce que c’est le protocole d’échange de clés qui sera potentiellement vulnérable, une session SSH entière peut être capturée maintenant, et une fois qu’un ordinateur quantique existe qui rompt la poignée de main, la session entière peut être déchiffrée hors ligne. Personne ne peut encore deviner combien de temps avant qu’une entreprise ou un État-nation ne dispose d’un ordinateur quantique pratique. Même si cela prend encore 20 ans, certaines données seront toujours sensibles et sujettes à décryptage.

NTRU utilise les mathématiques vectorielles sur un réseau comme fonction à sens unique, car il résiste toujours bien aux ordinateurs classiques, et aucune attaque à accélération quantique n’a été découverte contre lui. Juste au cas où NTRU s’avérerait vulnérable de manière imprévue, il est combiné avec la norme précédente, x25519, une solution de courbe elliptique.

L’ONS cible l’UE ?

Les logiciels du groupe NSO sont à nouveau apparus dans un endroit inconfortable. Cette fois, ForcedEntry semble avoir été utilisé pour tenter de compromettre des fonctionnaires de la Commission européenne de l’Union européenne. NSO a nié l’allégation, déclarant que leurs outils ne pouvaient pas être responsables des tentatives signalées. N’oubliez pas que NSO vend ses logiciels espions à plusieurs gouvernements et qu’il y aura très peu de surveillance sur ce que ces gouvernements en font. Il convient de préciser que ce n’est presque certainement pas le gouvernement d’Israël, ni même directement le NSO qui s’en est pris à l’UE. Certains ont une couverture qui a laissé ce point un peu vague. Fait intéressant, plutôt que d’être découverts par des professionnels de l’UE, les commissaires concernés ont été informés par Apple par e-mail.

Problèmes de git

Git pour Windows vient de publier une série de mises à jour pour corriger CVE-2022-24765. Le problème ici est qu’un .git dossier à la racine d’un lecteur Windows est considéré comme une configuration valide pour toute opération Git en dehors d’un répertoire Git légitime. Le danger est qu’un autre utilisateur ou un programme malveillant puisse créer ce répertoire, et la prochaine fois que Git est exécuté, des commandes arbitraires peuvent être déclenchées via le fichier config.

Et en parlant de Git, il y a une fuite de données intéressante qui vient d’être annoncée, notgitbleed. Nom filaire ? [Aaron Devaney] et [Will Deane] Trouvé le problème en 2021 et choisi “GitBleed” comme nom de vulnérabilité, mais un autre groupe de chercheurs les a battus avec un problème similaire mais distinct. Pas du genre à se prendre trop au sérieux, l’alternative ironique a été choisie.

Le véritable problème, ce sont les développeurs et notre mémoire musculaire lorsque nous faisons un git push. Faites le commit, poussez vers Github et saisissez le nom d’utilisateur et le mot de passe. Cependant, lors de ce premier commit, Git vous demandera votre nom et votre adresse e-mail. Si vous n’y prêtez pas attention, c’est trop facile de lui donner un nom d’utilisateur et un mot de passe. Je vous entends sûrement vous moquer, pas plus qu’une petite poignée de développeurs ne ferait cette erreur. En extrapolant à partir de leurs découvertes, il semble que plus de 50 000 mots de passe aient fui dans les métadonnées de validation au fil des ans.

Typosquatting social et prise de contrôle

Nous avons parlé de la prise de contrôle de domaine/sous-domaine, où un domaine a été autorisé à expirer, mais est toujours considéré comme actif quelque part. Un nouvel outil de [Utku Sen] vous permet de rechercher des liens de médias sociaux qui sont vulnérables de la même manière. Imaginez que j’ai l’intention de créer un lien vers mon compte Twitter, vous demandant tous de me suivre là-bas, mais j’ai tapé le lien. S’il n’y avait pas déjà un compte au lien manqué, quelqu’un pourrait en créer un et se faire passer pour moi. Pour preuve, il y a même l’article où j’ai mis le lien vers le (faux) compte. Oups ! C’est là qu’intervient socialhunter. Pointez-le sur une URL et il recherchera de faux liens de médias sociaux. Apparemment, de nombreux programmes de primes de bogues accepteront ces fautes de frappe comme des problèmes valides, alors mettez-vous au travail !

Cambriolage Amazon RDS

Certaines découvertes de vulnérabilité se lisent comme un film de câpres à l’ancienne, et c’est l’une d’entre elles. Les chercheurs de Lightspin travaillaient sur Amazon Relational Database Service (RDS), qui est l’offre de base de données cloud d’Amazon. Une option pour le moteur de base de données pour RDS est PostgreSQL. Il existe plusieurs façons d’échapper au moteur SQL et d’exécuter du code sur la machine, mais les trous évidents sont bouchés : vous n’avez pas un véritable accès superutilisateur, vous ne pouvez pas charger une extension de langage non approuvée, etc. Il existe une poignée d’extensions disponibles, et log_fwd est celui qui est intéressant. Cela vous permet d’accéder aux fichiers journaux en tant que table étrangère, très utile pour le débogage. Si vous pouvez enquêter sur les fichiers journaux, pouvez-vous également extraire d’autres fichiers avec cette astuce ? Des chercheurs ont tenté d’importer ../../../../../etc/passwd. Cela a jeté une erreur, naturellement. La vie ne peut pas être aussi facile.

Quelques requêtes supplémentaires plus tard, et il était clair qu’il y avait une fonction de validation de correspondance de modèle qui bloquait la traversée du chemin. PostgreSQL utilise des wrappers de données étrangères pour accéder à des données externes comme celle-ci, et ils incluent des fonctions de validation en tant que fonctionnalité facultative. Facultatif dans la mesure où vous pouvez les désactiver lors de l’exécution. Donc, désactivez le validateur, puis essayez d’accéder au passwd dossier? Saleté.

Tout fichier du système de fichiers que le démon PostgreSQL peut lire, l’utilisateur le peut aussi. Après avoir cherché quelque chose d’intéressant, le terme grover surgi. Après une série de fichiers de configuration liés, un identifiant API a finalement été découvert. Ces informations d’identification autorisaient l’accès à AWS en tant que csd-grover-role, un service AWS interne. À ce stade, les chercheurs avaient percé le voile et jouaient dans le backend AWS. Ils ont appelé cela une journée de travail et ont remis les résultats à Amazon. La sécurité d’AWS a validé le bogue, confirmé qu’il n’avait pas été exploité dans le passé et était curieusement discret sur ce que le grover le service est. Quoi qu’il en soit, le bogue est corrigé et c’est une histoire intéressante d’échapper au bac à sable AWS.

NGINX 0-day — Peut-être

Il y a eu des rumeurs, juste au moment où cette colonne se dirige vers les presses, que NGINX pourrait avoir un exploit de 0 jour dans la nature. Il apparaît que c’est précisément l’implémentation de référence LDAP dans NGINX qui est vulnérable. F5 a confirmé qu’il y a bien un problème. Des correctifs de sécurité ont été poussés vers le nginx-ldap-auth repo, résolvant vraisemblablement le problème. BlueHornet est le groupe qui a divulgué le bogue et a publié son point de vue sur l’histoire. Utiliser LDAP avec NGINX ? C’est celui qu’il faut regarder de près.

Leave a Comment