J’espère que tout le monde a passé un merveilleux Thanksgiving la semaine dernière. Ma famille a célébré en accueillant un 4e membre de la famille. Ma fille est née le mercredi matin 25 novembre. Et explique ainsi ce que j’ai fait la semaine dernière au lieu d’écrire la chronique normale de Hackaday. N’ayez crainte, nous nous rattraperons aujourd’hui et couvrirons les nouvelles qui méritent d’être remarquées.

Attaque Wifi sans clic sur iOS

[Ian Beer] du Project Zero de Google nous apporte le fruit de son travail induit par le verrouillage, une attaque iOS spectaculaire. La cible de cette attaque est le code du noyau qui gère AWDL, un protocole Apple WiFi pour les réseaux maillés adhoc entre appareils. La fonctionnalité la plus remarquable qui utilise AWDL est AirDrop, le système de partage de fichiers d’appareil à appareil d’Apple. Comme AWDL est un protocole propriétaire, le matériel WiFi ne peut pas effectuer de traitement accéléré des paquets. Il y a quelques années, il y avait une attaque contre le micrologiciel Broadcom qui nécessitait une deuxième vulnérabilité pour passer de la puce WiFi au processeur de l’appareil. Ici, comme le protocole est entièrement implémenté dans le code d’Apple, aucun pivot n’est nécessaire.

Et comme vous l’avez probablement déduit, une vulnérabilité a été découverte. AWDL utilise des messages de type-longueur-valeur (TLV) pour envoyer des données de gestion. Pour un chercheur en sécurité, les TLV sont particulièrement intéressants car chaque type de données représente un chemin de code différent pour attaquer. L’un de ces types de données est une liste d’adresses MAC, avec un maximum de 10. Le code qui la gère alloue un tampon de 60 octets, basé sur ce maximum. Le problème est qu’il n’y a pas de chemin de code pour supprimer les TLV entrants de ce type lorsqu’ils dépassent 60 octets. Le reste est écrit juste après la fin du tampon alloué.

Il y a plus de plaisir à avoir, obtenir un exploit complet, mais les détails sont un peu trop pour plonger complètement ici. Il est intéressant de noter que [Ian] s’est heurté à un problème particulier: sa poussée sur le code cible provoquait des paniques inattendues du noyau. Il a découvert deux vulnérabilités distinctes, toutes deux distinctes du vuln qu’il essayait d’exploiter.

Enfin, cet exploit nécessite que le périphérique cible ait activé AWDL, et beaucoup ne le feront pas. Mais vous pouvez utiliser les publicités Bluetooth Low Energy pour faire croire à l’appareil cible qu’un Airdrop provient d’un contact de confiance. Une fois que l’appareil permet à AWDL de vérifier la demande, l’attaque peut se poursuivre. [Ian] a rapporté ses découvertes à Apple en 2019, et cette vulnérabilité a été corrigée en mars 2020.

Via Ars Technica.

Et si un jailbreak iOS parfaitement emballé est plus votre vitesse, Odyssey a récemment été publié, une application de jailbreak open source élégante pour les appareils iOS modernes. Pour encore plus de bonté de jailbreak, que diriez-vous de jailbreaker votre HomePod? La dernière version de Checkra1n le rend partiellement possible.

Prise en main des appareils Fortinet

Devinez ce qui se passe lorsqu’une vulnérabilité grave est trouvée et corrigée et que les administrateurs système ne déploient pas les correctifs? Si vous deviniez l’exploitation de masse, vous auriez raison. CVE-2018-13379 était un bogue de traversée de répertoire dans les passerelles VPN Fortinet, découvert pour la première fois en 2018. Tout récemment, un vidage d’informations d’identification en texte clair a fait surface sur Internet – des comptes provenant de plus de 49 000 appareils. L’ensemble de la décharge est disponible dans les parties les plus sombres d’Internet.

Fantômes Webex

Vous vous souvenez de la panique éphémère entourant les réunions Zoom non sécurisées et des farceurs non invités se connectant à ces réunions? Ce fut assez d’un moment que le «zoombombing» fut inventé. Eh bien, attendez, car Webex vient de nous apporter des «utilisateurs fantômes». La recherche a été réalisée par le groupe SecurityIntelligence d’IBM. Ils ont découvert qu’il était possible de manipuler la poignée de main de jointure tout en rejoignant une réunion Webex et d’accéder à la réunion sans apparaître sur la liste des auditeurs. Le danger ici est qu’un «fantôme» puisse écouter une réunion confidentielle. C’est un rappel qu’il y a une nouvelle série de défis dans notre nouveau monde courageux. IBM a fait part de ses découvertes en privé et Cisco a corrigé les vulnérabilités.

Le code intégré est également vulnérable

Il existe tout un monde de piles de logiciels propriétaires, cachées dans des périphériques embarqués, des contrôleurs en temps réel et des applications industrielles. L’une de ces piles est la pile réseau EtherNet / IP (ENIP), vendue par Real Time Automation (RTA). Dans un article récent, Claroty a détaillé une vulnérabilité assez sérieuse dans ce logiciel. L’une des fonctions de l’ENIP est d’accepter une demande d’ouverture vers l’avant, qui fait partie du protocole industriel commun. Le code de validation pour ces demandes entrantes n’est pas aussi robuste qu’il devrait l’être, et une demande trop volumineuse entraîne des écritures en mémoire en dehors du tampon alloué.

La vulnérabilité est suffisamment grave, permettant potentiellement de compromettre des périphériques sur le réseau sans interaction de l’utilisateur. Le pire, c’est que ce code est verrouillé sur des millions d’appareils qui ne recevront probablement jamais de mises à jour de sécurité. Ce type de vulnérabilité est une cible parfaite pour la prochaine attaque de style Stuxnet contre une infrastructure quelque part. Il est difficile d’estimer où toute cette pile réseau est cachée, mais Claroty a trouvé une poignée d’appareils vulnérables directement connectés à Internet, prêts à être exploités. RTA a été notifié et a corrigé son code, mais l’application de ce correctif sur chaque appareil vulnérable prendra des années.

Regex pour la sécurité?

XKCD CC BY-NC 2.5

Si vous vous retrouvez à écrire du code pour une application où la sécurité est importante et que vous vous tournez vers une expression régulière pour valider quelque chose, arrêtez-vous et réfléchissez aux choix de vie qui vous ont conduit à ce point. Il y a trop de façons dont une regex peut mal tourner, ou une entrée inattendue peut correspondre d’une manière que vous n’aviez pas anticipée. Exemple concret, package npm private-ip.

John Jackson, alias [JohnJHacking] a trouvé une faille SSRF (Server Side Request Forgery) dans une application serveur et a commencé à creuser pour en trouver la cause. Un SSRF est un style d’attaque assez simple, où une requête contient des données falsifiées, dans le but de tromper le serveur pour qu’il se connecte à une adresse IP différente. En effet, un attaquant peut demander des données, sur lesquelles il a un certain contrôle, et demander au serveur d’envoyer ces données vers un emplacement arbitraire. Une fois qu’un attaquant a une SSRF, il existe un tas d’attaques potentielles pour lesquelles une primitive peut être utilisée, impliquant généralement l’envoi de messages à des services internes uniquement.

La vulnérabilité réelle dans private-ip est facile à manquer. Le package est conçu pour filtrer toutes les demandes adressées aux adresses IP privées, par exemple, il bloquerait tous les SSRF vers localhost. Alors d’abord, 0.0.0.0 est une adresse IP spéciale. Il agit très similaire à 127.0.0.1, mais signifie techniquement toutes les adresses IP d’écoute sur la machine locale. Private-ip détecte avec succès une demande à 0.0.0.0, mais un attaquant pourrait à la place faire une requête SSRF à 0000.0000.0000.0000. Le système d’exploitation les interprète comme la même chose, mais le code regex manque l’adresse IP avec les 0 supplémentaires. Private-ip a publié 2.0.0 avec une série de correctifs et un système de correspondance IP plus sensé.

LAISSER UN COMMENTAIRE

Rédigez votre commentaire !
Entrez votre nom ici