Les chercheurs en sécurité ont découvert cinq vulnérabilités dans les équipements réseau d’Aruba (appartenant à HP) et d’Avaya (appartenant à ExtremeNetworks), qui pourraient permettre à des acteurs malveillants d’exécuter du code à distance sur les appareils.
Les dommages causés par une attaque réussie vont de la violation de données et de la prise de contrôle complète de l’appareil au mouvement latéral et au dépassement des défenses de segmentation du réseau.
Les chercheurs en sécurité de la société de cybersécurité Armis spécialisée dans les appareils connectés ont surnommé l’ensemble de vulnérabilités « TLStorm 2.0 », car la découverte appartient à la même classe de problèmes que l’utilisation abusive de la bibliothèque NanoSSL TLS, qu’ils ont signalée sur les modèles d’onduleurs APC populaires.
Les analystes ont constaté que les appareils d’autres fournisseurs présentaient des risques de sécurité identiques et ont fourni une liste des produits concernés :
- Avaya ERS3500
- Avaya ERS3600
- Avaya ERS4900
- Avaya ERS5900
- Série Aruba 5400R
- Série Aruba 3810
- Série Aruba 2920
- Série Aruba 2930F
- Série Aruba 2930M
- Série Aruba 2530
- Série Aruba 2540
Bibliothèques externes sur les commutateurs
Les commutateurs réseau sont des éléments courants dans les réseaux d’entreprise, aidant à appliquer la segmentation, une pratique de sécurité qui est fondamentale de nos jours dans les grands environnements.
Leur rôle est d’agir comme un pont réseau, connectant les périphériques au réseau et utilisant la commutation de paquets et les adresses MAC pour recevoir et transférer les données vers le périphérique de destination.
L’utilisation de bibliothèques externes est souvent une solution pratique et économique, mais cela s’accompagne parfois d’erreurs d’implémentation et de problèmes de sécurité.
Cette pratique incite les pirates à se pencher sur ces minuscules blocs de construction pour trouver des failles potentiellement exploitables.
Dans le cas de TLStorm 2.0, la cause du problème est que le code « glue logical » utilisé par les fournisseurs n’est pas conforme aux directives NanoSSL, conduisant à un potentiel RCE (exécution de code à distance).
Sur Aruba, NanoSSL est utilisé pour le serveur d’authentification Radius ainsi que pour le système de portail captif. La façon dont il a été implémenté peut entraîner des débordements de tas de données d’attaquants.
Sur Avaya, l’implémentation de la bibliothèque introduit trois failles, un débordement de tas de réassemblage TLS, un débordement de pile d’analyse d’en-tête HTTP et un débordement de traitement de requête HTTP POST.
Les problèmes proviennent de vérifications d’erreurs manquantes, d’étapes de validation manquantes et de vérifications de limites inappropriées.
Ces problèmes ne sont pas dans la bibliothèque elle-même mais dans la façon dont le fournisseur l’a implémentée.
Scénarios d’attaque
Armis présente deux principaux scénarios d’exploitation qui permettent d’échapper à un portail captif ou de briser la segmentation du réseau, ouvrant tous deux la voie à des cyberattaques à fort impact.
Dans le scénario du portail captif, l’attaquant accède à la page Web d’une ressource réseau limitée qui nécessite une authentification, un paiement ou une autre forme de jeton d’accès. Ces portails captifs se trouvent généralement dans les réseaux hôteliers, les aéroports et les centres d’affaires.
En exploitant TLStorm 2.0, l’attaquant peut exécuter du code à distance sur le Switch, en contournant les restrictions du portail captif ou même en le désactivant complètement.
Dans le deuxième scénario, un attaquant peut utiliser les vulnérabilités pour casser la segmentation du réseau et accéder à n’importe quelle partie du réseau informatique, en passant librement de l’espace « invité » au segment « entreprise ».
Remédiation
Armis a informé Aruba et Avaya des vulnérabilités de TLStorm 2.0 il y a trois mois et a collaboré avec eux sur le plan technique.
Les analystes des menaces ont déclaré à EZpublish-france.fr que les clients concernés avaient été informés et que des correctifs corrigeant la plupart des vulnérabilités avaient été publiés.
De plus, Armis nous a dit qu’ils n’étaient pas au courant de l’exploitation des vulnérabilités de TLStorm 2.0.