Curl a récemment été informé d’un CVE, CVE-2020-19909, évalué à 9,8 sur l’échelle CVSS. Et PostgreSQL a CVE-2020-21469, avec une gravité de 7,5. Vous remarquerez peut-être quelque chose d’étrange à propos de ces deux vulnérabilités, mais je vous promets que la date de 2020 n’est que la pointe de l’iceberg.
Commençons par PostgreSQL. Cette vulnérabilité n’était présente que dans la version 12.2, publiée en février 2020, et a été corrigée avec la version 12.3 en mai de la même année. Le problème est un débordement de tampon de pile, qui ne semble pas permettre l’exécution de code, mais provoque une situation de déni de service. Pour déclencher le bug ? Envoyez à plusieurs reprises au démon PostgreSQL le signal SIGHUP.
Si vous êtes familier avec les signaux Linux, cela peut paraître étrange. Vous voyez, le signal SIGHUP indique techniquement la fin d’une session utilisateur, mais la plupart des démons l’utilisent pour indiquer une demande de redémarrage ou de rechargement. Et pour envoyer ce signal, un utilisateur doit disposer de privilèges élevés, suffisamment élevés pour simplement arrêter complètement le démon. En termes simples, il ne s’agit pas d’une faille de sécurité, juste d’un bug mineur.
Et maintenant, passons au curling – Celui-ci est tout simplement bizarre. Le problème est un débordement d’entier dans le --retry-delay argument, qui spécifie en secondes à quelle fréquence curl doit réessayer un téléchargement ayant échoué. La valeur est multipliée par 1 000 pour être convertie en millisecondes, ce qui entraîne un débordement pour les valeurs très importantes. Le résultat de ce débordement ? Une valeur plus petite pour le délai de nouvelle tentative.
[Daniel Stenberg] fait remarquer que cette histoire est une merveilleuse démonstration de la défaillance du système CVE et de la manière dont NVD le gère. Et dans ce cas précis, il est difficile de ne pas y voir de la négligence. Nous devons travailler très dur pour construire un scénario théorique dans lequel ce bug pourrait réellement être exploité. Le mieux que j’ai pu trouver est un outil de téléchargement en ligne, dans lequel l’utilisateur peut spécifier une partie du nom de la cible et un délai d’attente. Si cet outil vérifiait que le délai d’attente était suffisamment long pour éviter un trafic excessif, ce bug pourrait contourner cette vérification. Devrions-nous attribuer des CVE à ce genre d’attaque théorique et alambiquée ?
Mais voici le problème, ce scénario d’attaque devrait évaluer quelque chose comme un CVSS de 4,8 au pire absolu. NVD lui a attribué la note de 9,8. Vous ne pouvez pas examiner ce bug suffisamment attentivement pour légitimement le classer aussi grave. Au moment de la rédaction de cet article, le NVD indique que cela est « EN COURS DE RÉANALYSE ».
Allergies au BGP
Début juin, une route BGP (Border Gateway Protocol) a commencé à être annoncée à partir d’un petit réseau au Brésil. Cette route avait un attribut de capacité d’étiquette d’entropie BGP dans le cadre des champs d’attribut, mais la longueur de ce champ était définie sur zéro. La plupart des autres routeurs BGP n’ont aucune idée de la signification de cet attribut, il est donc ignoré mais transmis.
Les routeurs Juniper, cependant, savent très bien ce qu’est cet attribut et ont des opinions assez arrêtées sur la façon dont il doit être formaté. Et cette route s’est trompée. L’ancienne réponse à une erreur de décodage consiste à déclencher un arrêt de session BGP, supprimant temporairement le routeur de l’Internet au sens large. Étant donné que l’itinéraire à l’origine du problème est toujours annoncé, ce processus peut continuer à se répéter, gardant les routeurs concernés hors ligne jusqu’à ce que quelqu’un intervienne pour résoudre le problème. La RFC 7606 résout ce problème en spécifiant que seules les mauvaises routes doivent être supprimées. Mais le déploiement de cette RFC a été lent.
Ce qui nous amène à la recherche proprement dite de cette histoire. [Benjojo] a décidé d’installer certains routeurs BGP sur un banc de test et de fuzzer certains paquets BGP. Il existe une liste impressionnante de fournisseurs qui n’ont pas été victimes de l’attaque, mais Juniper, Nokia, FRR, OpenBSD et Extreme Networks ont tous obtenu des résultats quelque peu inattendus. Parmi eux, l’équipe de sécurité d’OpenBSD s’est démarquée en prenant le rapport au sérieux et en préparant rapidement un correctif pour y remédier. Les autres fournisseurs ont été moins réactifs, c’est un euphémisme.
Le piratage TPM simplifié
Ici, sur Hackaday, nous avons couvert quelques attaques TPM (Trusted Platform Module), où une clé de cryptage peut être détectée à partir d’une trace physique sur la carte mère. Il s’avère que ces attaques compliquent beaucoup les choses et vous pouvez simplement écraser la touche Entrée comme un enfant de 6 ans jouant au combattant de rue.
Cette attaque fonctionne sur les machines Linux qui utilisent le TPM pour activer le déverrouillage sans surveillance pour le chiffrement de disque LUKS. Cela semble étrange au début, mais c’est la solution pour chiffrer le disque du serveur dans l’armoire réseau, sans avoir à entrer un mot de passe à chaque redémarrage. Le TPM fournit la clé de chiffrement et le système d’exploitation prend en charge la sécurité. L’astuce consiste à combler cet espace en appuyant plusieurs fois sur Entrée avant que le TPM ne déverrouille le disque, chacune comptant comme une tentative de saisie de mot de passe. La limitation de débit entre en jeu, empêchant le flux de démarrage normal, et finalement le système ne parvient pas à démarrer et laisse tomber l’utilisateur vers un shell privilégié root.
Le disque dur est toujours verrouillé, mais il est assez simple d’utiliser les outils de démarrage pour demander au TPM de déverrouiller le disque. Il est apparemment possible d’appuyer rapidement sur la touche Entrée suffisamment rapidement à la main pour résoudre ce problème. La solution est en fait un peu compliquée. Vous pouvez ajouter rd.shell=0 et rd.emergency=reboot à la ligne de commande du noyau, ce qui comble l’écart, mais ce n’est peut-être pas la meilleure option pour la plupart des utilisateurs.
Bits et octets
Vous vous souvenez de Wardriving ? Où pourriez-vous emporter un ordinateur portable et une carte WiFi et conduire à la recherche de réseaux sans fil vulnérables ? Il y a de fortes chances que vous ayez un ordinateur plus puissant dans votre poche, alors pourquoi ne pas le mettre à profit ? Toute la série sur les hackers mobiles concerne la boîte à outils Android Kali NetHunter et nous guide tout au long de l’installation, de la sélection de certains périphériques et de la mise au travail d’audit du WiFi. A déguster de manière responsable !
L’un de nos outils préférés dans la boîte à outils anti-malware, Malwarebytes, se prépare à de grands changements. Malheureusement, environ 100 employés ont été licenciés dans le cadre du travail préparatoire à la scission de l’entreprise entre les branches consommateurs et entreprises. Aucun travail n’a encore été réalisé sur la manière dont le produit anti-malware phare sera affecté.
Une nouvelle souche de malware, « Infamous Chisel », a été découverte, ciblant apparemment les appareils Android ukrainiens. Le malware s’installe de manière permanente sur le netd démon et utilise le réseau TOR pour les communications. Il inclut même Dropbear SSH pour l’accès à distance. Avec l’installation permanente et le remplacement des fichiers, ce malware ne semble pas être destiné aux installations furtives.
