Quoi de plus dangereux que l’assurance injustifiée d’un bon niveau de sécurité ? Plusieurs remèdes largement employés par les entreprises deviennent finalement de nouveaux maux, parfois plus graves que ceux qu'ils devaient corriger. Les « bonnes recettes », laissées entre des mains inexpertes, sont des portes ouvertes aux pires revers.
1. « Pour chaque problème, il existe une solution simple, claire…et fausse »
Cette citation de Henry Louis Mencken, une de mes favorites, bien que sortie de son contexte, a le mérite de résumer simplement le problème.
Lors de nos audits, un certain nombre de problèmes « pathétiques » reviennent de façon récurrente et sont généralement dus à une application parcellaire des recommandations de sécurité ou bien à un suivi aveugle d’une obscure source Internet.
Il nous incombe donc d’être les plus précis possible dans nos préconisations et d’insister sur les points qui sont « recommandés » et ceux qui sont « indispensables ». Lorsque l’on dit à un à client que son application interne nécessite une page d’authentification, car elle permet des actions sensibles et qu’il faut protéger le tout par HTTPS, il comprend généralement : « il faut mettre une authentification et quand on aura le temps, on mettra du HTTPS ».
Il est fréquent que l’application de tous les correctifs conseillés soit difficile, pour des raisons de coût et/ou de temps. Le client va donc faire des choix et décider de ce qu’il garde et de ce qu’il remet à plus tard. Or, malheureusement, une moitié de mesure est parfois pire que pas de mesure du tout.
Petit extrait, parmi tant d’autres, de ce qu’il ne faut plus faire.
2. Wifi et Radius, le 802.1X avec les pieds
Le Wifi dit « Entreprise » (WPA2 MGT) s’oppose au Wifi « personnel » (WPA PSK) en faisant intervenir l’usage du standard 802.1X, généralement au travers d’une authentification Radius. Cette solution possède de multiples atouts et séduit, à juste titre, nombre de sociétés.
2.1 Pourquoi que c’est bien ?
En lieu et place d’une clé Wifi unique, l’utilisateur s’authentifie avec son compte personnel, généralement celui du domaine Windows de l’entreprise.
Premier gros avantage, plus besoin de changer la clé Wifi lorsque Michel quitte l’entreprise (pour éviter qu’il vienne se reconnecter le week-end et télécharger illégalement la discographie de Mickael Vendetta). En effet, il suffit de désactiver son compte sur le domaine et Michel n’aura plus de moyen de se connecter et cela reste totalement transparent pour les autres utilisateurs.
Ceci est également valable en cas de perte ou de vol d’un ordinateur nomade (l’attaquant pourrait facilement en extraire la clé Wifi enregistrée). Il suffit alors simplement de modifier le mot de passe associé au compte sans avoir besoin de faire une communication interne à toute l'entreprise stipulant que le code Wifi a changé.
Deuxièmement, les attaques classiques contre le chiffrement Wifi WPA2 ne sont plus faisables. Notamment celle qui consiste à capter une poignée de main d’authentification et à attaquer la clé unique via un dictionnaire. Ici, plus de clé unique à découvrir.
« Donc on met un serveur Radius pour l’authentification Wifi et on est bon ». Oui…mais non. L’authentification Radius possède son lot de pièges et pas des moindres.
2.2 Je m’présente je m’appelle Henri
Première erreur classique, la verbosité. Voici ce qu’un quidam pourrait capter avec sa carte Wifi en mode écoute (deux lignes de commandes sous Kali) en étant sur le trottoir en face de l’entreprise :
Nous pouvons voir qu’avant que l’utilisateur ne s’authentifie avec son mot de passe, des échanges en clair sont faits avec le serveur Radius (Request Identity et Response Identity). Ces messages ont le bon goût de divulguer le nom du domaine de l’entreprise et celui de l’utilisateur.
Le Wifi WPA2 (entreprise ou personnel) se base sur le protocole EAP pour ce qui concerne l’authentification. Il existe diverses versions de celui-ci, plus ou moins sécurisées. Une des plus robustes et répandues, EAP-TLS est définie dans la RFC 5216 qui nous dit par exemple dans la section 2.1.4 [1] :
« EAP-TLS peer and server implementations MAY support privacy. Disclosure of the username is avoided by utilizing a privacy Network Access Identifier (NAI) [RFC4282] in the EAP-Response/Identity, and transmitting the peer certificate within a TLS session providing confidentiality. »
Nous voyons donc que la confidentialité du nom de l’utilisateur n’est pas un comportement par défaut et qu’il convient de mettre en place des mesures supplémentaires pour l’assurer.
2.2.1 Pourquoi que c’est grave ?
Un attaquant en possession de cette seule information dispose déjà d’un vecteur d’attaque conséquent et largement sous-estimé.
Connaissant le nom valide du domaine ainsi qu’au moins un utilisateur existant, il peut tenter une attaque par force brute sur le mot de passe de cet utilisateur. Bien des entreprises ne limitent pas encore le nombre d’essais infructueux avant le blocage d’un compte.
Des dictionnaires ciblés peuvent rapidement venir à bout de la plupart des comptes (dérivation du nom de l’utilisateur, dérivation du nom de la société, base des mots de passe les plus fréquents, etc.). Une base de prénoms et/ou de dates possède également de bonnes chances de réussite (beaucoup de parents utilisent le nom de leurs enfants ou des dates anniversaires).
L’attaquant peut également passer la journée à espionner le nom des utilisateurs qui se connectent au Wifi. Sur une structure assez grande, on observe invariablement des mots de passe pathétiques (login=password par exemple). Ainsi, chaque nouvel utilisateur qui se connecte augmente les chances de l'attaquant de tomber sur un compte ayant un mot de passe faible.
Mieux, l’attaquant a pu observer que le nom d’utilisateur était hmichel (pour Henri Michel). Il peut écumer les différents réseaux sociaux professionnels (LinkedIn, Viadeo, etc.), les coupures de presse et les sites web de l'entreprise pour énumérer le nom de toutes les personnes qui y sont publiquement rattachées. Il peut alors construire leur nom d’utilisateur probable (Pierre Martin = pmartin).
Le temps avant de trouver un compte ayant un mot de passe évident en sera encore réduit. Et tout ceci peut se faire, rappelons-le, sans avoir à pénétrer dans les locaux de l’entreprise.
Bien entendu, chaque tentative de mot de passe demande d’interroger le serveur d’authentification, ce qui limite fortement la vitesse des essais et peut lever des alertes à l’administrateur de la société.
2.3 Redites-moi ce que c’est que la clé déjà ?
Mais nous sommes loin d’en avoir fini. Comme nous l’avons dit, il n’y a plus de clé Wifi unique, elle est remplacée par le compte AD de l’utilisateur… vous savez...cette chose dont la connaissance permet une prise de contrôle totale du réseau dans 80 % des cas.
Il faut donc mesurer le progrès. Oui, la clé n’est plus aussi simple à découvrir. Par contre, si on y arrive, on n’est pas simplement connecté au réseau, on est connecté au réseau avec un compte du domaine valide !!! Et ça, en termes de pentest, c’est l’équivalent d’une rave party.
Michel a un complexe de Dieu
Petit aparté basé sur notre expérience en termes d’audits internes. Je suis michel sur le domaine, je voudrais être dieu.
« Chewie branche l’hyperpropulsion !! Wrrggraa » : metasploit/psexec sur le contrôleur de domaine, getsystem, hashdump ou mimikatz, récupération du hash LM ou NTLM de l’administrateur du domaine, metasploit/psexec en mode pass-the-hash sur n’importe quelle machine du domaine (4 minutes).
Cette année 2015, ceci était possible lors de 80 % de nos audits internes.
Supplément frites-coca : un coup de john the ripper sur la base des condensats extraite. En général, cela permet de se faire une bonne idée du motif du mot de passe par défaut utilisé dans l’entreprise : NS@2k15, H@ck1ngT34 m !, les classiques.
On dérive un petit peu ce fameux motif de mot de passe jusqu’à trouver celui de l’administration du pare-feu et roulez jeunesse.
Il existe bien d’autres méthodes d’escalade dans un domaine Windows, mais ce n’est pas l’objet de cet article. Retenez simplement que très souvent, d’une façon ou d’une autre : un compte du domaine = le domaine.
Donc appliquez-le dans la phrase « un compte du domaine est exposé via le Wifi qui va jusqu’en face de la rue »… voilà de quelle catégorie de risque on parle.
Bien, nous avons vu précédemment que nous connaissons déjà les noms d’utilisateurs valides. Mais rien ne nous oblige à tenter de découvrir leurs mots de passe en partant de zéro.
Le protocole EAP, utilisé pour l’authentification du client, possède, comme nous l’avons dit, plusieurs versions. Le Wifi de type Entreprise utilise généralement l’une de celles-ci [2] :
-LEAP ;
-EAP-MD5 ;
-EAP-FAST ;
-PEAP ;
-EAP-TLS.
LEAP et EAP-MD5 n’utilisent pas de couche TLS. Ceci implique que le mot de passe est observable dans la forme où il est transmis (via un format MS-CHAP pour LEAP et haché en MD5 pour EAP-MD5).
Pour ces deux protocoles, il suffit à l’attaquant de continuer d’observer le trafic Wifi pour capturer la poignée de main d’authentification (4-way handshake) puis de tenter de s’attaquer à l’empreinte du mot de passe (ce que font très bien des outils comme asleap[3] et eapmd5[4]).
À la différence de la seule connaissance du nom d’utilisateur, la connaissance d’une empreinte du mot de passe permet de mener une attaque en local. Ceci implique des vitesses de cassage pouvant tester des millions de mots de passe par seconde.
De plus, MD5 et MS-CHAP souffrent tous les deux de biais de sécurité pouvant être exploités afin d’accélérer la tentative de cassage.
« Heureusement », les normes PEAP et EAP-TLS sont les plus répandues. Il s’agit de protocoles sûrs et robustes qui ne souffrent pas de défaut de design connu.
La simple écoute du trafic Wifi ne permettra pas de révéler d’empreinte du mot de passe puisqu’il y aura encapsulation dans une couche de chiffrement.
Mais l’intervention d’une couche TLS nécessite l’utilisation de certificats. Ceci nous entraîne donc vers une attaque plus sophistiquée qui consiste à usurper l’identité du serveur Radius. En effet, plutôt que de nous attaquer directement aux protocoles PEAP et EAP-TLS, nous ciblons ici une faille très (voire très très) fréquente dans leur implémentation.
L’objectif est d’émettre un réseau Wifi depuis la machine de l’attaquant qui imitera le profil du réseau légitime (ESSID, canal, adresse MAC du même constructeur, etc.) avec un signal plus fort que ce dernier afin de détourner les utilisateurs.
Ceci est relativement facile localement, en utilisant une carte Wifi dédiée (comme les très célèbres cartes Alfa), débridée ou non. En se collant au mur d’un bâtiment de la société, il est aisé de fournir un meilleur signal que les bornes légitimes aux utilisateurs à proximité.
Ceci nécessite également de fournir un service d’authentification Radius qui réponde aux requêtes de connexion des utilisateurs (au moins jusqu’à la phase de la poignée de main d’authentification).
Ici, guère besoin d’éplucher les RFC, Brad Antoniewicz nous fourni le très intéressant patch hostapd-wpe[3] à utiliser en conjonction avec l’outil hostapd. Celui-ci va permettre de répondre systématiquement aux requêtes d’identification et d’émettre un Wifi de type Entreprise imitant le profil de notre cible (anciennement, cet outil était divisé en deux parties : hostapd et freeradius-wpe).
Un fichier de configuration modifié plus tard (trois lignes dans hostapd-wpe.conf), nous voilà prêts à hameçonner nos victimes :
$./hostapd-wpe hostapd-wpe.conf
Configuration file : hostapd-wpe.conf
Using interface wlan2 with hwaddr 00 : c0 : ca :81 :97 : f1 and ssid “MONWIFI”
wlan2 : RADIUS Authentication server 127.0.0.1 :18120
wlan2 : interface state UNINITIALIZED->ENABLED
wlan2 : AP-ENABLED
wlan2 : STA b8 : ee :65 : e3 : c0 : c6 IEEE 802.11 : authenticated
wlan2 : STA b8 : ee :65 : e3 : c0 : c6 IEEE 802.11 : associated (aid 1)
wlan2 : CTRL-EVENT-EAP-STARTED b8 : ee :65 : e3 : c0 : c6
wlan2 : CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=1
wlan2 : CTRL-EVENT-EAP-STARTED b8 : ee :65 : e3 : c0 : c6
wlan2 : CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=1
wlan2 : CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25
mschapv2 : Thu Oct 15 10 :10 :55 2015
username : MON-AD\hmichel
challenge : 4f :16 :6e : c8 :22 : e6 :33 :57
response : e7 :94 :81 : b1 :0b :76 :6d :8a : b5 :67 :89 :10 :11
jtr NETNTLM : MON-AD\hmichel :$NETNTLM$4f166ec822e63357 $e79481b10b766d8ab567891011
wlan2 : STA b8 : ee :65 : e3 : c0 : c6 IEEE 802.11 : disassociated
wlan2 : STA b8 : ee :65 : e3 : c0 : c6 IEEE 802.11 : deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Nous voyons donc qu’une station s’est connectée à notre point d’accès et a échangé une poignée de main d’authentification avec nous (le challenge-response au format (vulnérable [6]) MS-CHAP2). Le fait que ce soit encapsulé dans une couche de sécurité TLS est réduit à néant puisque cette connexion sécurisée a été négociée avec notre certificat.
2.4 Chef, chef qu’est-ce qui faut que j’fais ?
Bien, alors ce qui vous intéresse maintenant c’est de savoir quelle faute a été commise dans le déploiement et qui a pu permettre de rendre inutiles les deux meilleurs protocoles EAP.
Il s’agit évidemment de la validation du certificat du serveur Radius. Comme lorsque l’on visite le site PayPal, l'on est content que personne d’autre ne puisse voir ce qu’on lui envoie, mais l'on aime surtout être sûr qu’on l’envoie bien à PayPal.
Les attaques d’interception (Man in The Middle) sont beaucoup plus faciles et crédibles, dans les contextes de réseaux internes, que pour les serveurs Internet. Pourtant, c’est généralement là que l’on observe le plus de laxisme quant aux certificats.
Dans notre cas, l’erreur vient de la configuration des postes utilisateurs. Dans une écrasante majorité des cas, ceux-ci ne sont pas configurés pour vérifier l’identité du serveur Radius avec lequel ils vont communiquer :
Il convient de forcer les postes clients à :
- vérifier l’identité du serveur Radius ;
- ne pas demander à l’utilisateur s'il souhaite accepter un certificat non valide ;
- ne pas permettre d’accepter des méthodes d’authentification vulnérables (comme LEAP, EAP-MD5).
Ceci n’est généralement pas fait, car nécessite de déployer un certificat de confiance (payant) sur le serveur Radius ou bien d’intégrer l’autorité de certification de l’entreprise (si elle en a une) sur les postes utilisateurs (jugé fastidieux). Cette seconde solution est pourtant très utile et peut resservir à nombre d’autres problématiques. Généralement, intégrer cette autorité dans le master par défaut déployé sur les postes rend la tâche moins pénible.
Pour résumer, une tentative d’améliorer l’étanchéité du réseau, menée de façon trop légère, nous mène ici à l’exposer plus qu’il ne l’a jamais été, tout en ayant un faux sentiment de sécurité.
3. L'authentification low cost
Chaque entreprise utilise un certain nombre d'applications métiers internes propres à son activité qui peuvent être des solutions sur étagère ou bien issues de développements spécifiques (par un prestataire ou en interne).
3.1 En ce moment même en France, des milliers d'applications souffrent
Chez des entreprises encore peu matures en matière de sécurité, il n'est pas rare (mais vraiment pas) d'observer des faiblesses majeures sur les applications développées sur mesure. Ces faiblesses peuvent permettre, à terme, de compromettre le réseau ou un bien essentiel de l'entreprise, alors même que le serveur qui les héberge est irréprochable au niveau des mises à jour et de la configuration.
Pour citer le top 3 de ces faiblesses [13] :
- fonction sensible non protégée (par exemple, qui ne vérifie pas si l'utilisateur est bien authentifié) ;
- injection SQL avec contournement de l'authentification ou exfiltration de la base des comptes où les mots de passe sont conservés (en clair ou cassables rapidement) et réutilisables sur le réseau (sur l'AD par exemple) ;
- parcours d'arborescence permettant d'accéder à des données normalement réservées aux utilisateurs authentifiés : logs, stockage de documents uploadés, etc.
En effet, les applications développées spécifiquement ont souvent un objectif avant tout fonctionnel. Les considérations de sécurité ne faisant même souvent pas partie du cahier des charges.
Un premier audit chez un tel client nous amène donc régulièrement à préconiser une meilleure protection des applicatifs web internes.
« Imaginons » le cas d'une société ayant recours à des démarcheurs téléphoniques et dont une application interne permet le suivi en temps réel de leurs résultats et, notamment, l'attribution de primes.
Ou encore une entreprise d'infogérance, dont l'interface de gestion des assets clients est gérée via une application développée maison et permettant donc de redémarrer/éteindre/restaurer une machine, etc.
Dans la plupart des exemples, la sécurité de l'application repose uniquement sur la confidentialité de son existence. Aucune authentification n'est nécessaire. Donc, un scan de ports interne et une visite de tous les ports 80 ouverts révèlent rapidement l'existence de la poule aux œufs d'or.
3.2 Marcel, passe-moi la clé de 12
Pour répondre rapidement au risque fort que nous avions relevé et à nos préconisations de mettre en place un système d’authentification encapsulé dans une couche SSL, le client a tôt fait d'installer un htaccess « temporaire » en attendant la mise en place d'une solution plus propre.
Il se trouve qu'un an plus tard, le nouvel audit révèle que la « rustine » que constitue le htaccess est toujours en place et plus personne ne songe à améliorer ce point, car « hey on a quand même mis en place 50 % de la préconisation » et « le SSL c'était compliqué, mais au moins on peut déjà plus y accéder comme ça ».
3.3 De l'intérêt discutable d'un bon code secret quand le voleur regarde par-dessus votre épaule
Htaccess utilise généralement la méthode basic access authenticationde HTTP. Celle-ci transmet simplement le login et le mot de passe de l'utilisateur encodé en base64 [7]. Cette méthode s’affranchit de toute utilisation de cookie ou de jeton de session. Les identifiants sont transmis au sein d'un en-tête HTTP :
GET /index.php HTTP/1.1
Host: monapplicationsensible.mondomaine.fr
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101
Firefox/18.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Inutile de revenir sur le niveau de sécurité que procure un encodage base64, il ne s'agit ici même pas de l'élément le plus dangereux.
Le comportement du navigateur après que l'utilisateur ait renseigné son login et son mot de passe, est de mettre en cache ces informations qui doivent être retransmises dès que l'utilisateur consulte une page protégée.
Au même titre qu'un cookie, cette information est donc présente dans toutes les requêtes. C'est ici que le manque de couche SSL devient vraiment critique.
3.4 Gerard Majax en action
En effet, au sein d'un réseau interne, il existe de nombreuses possibilités d'interception de trafic : ARP cache poisonning, rogue DHCP server, etc. Il est excessivement rare qu'une entreprise dispose de toutes les contre-mesures. Ceci implique qu'un attaquant sera quasiment toujours à même d'observer le trafic interne. Il s'agit d'une assertion qui doit être prise en compte par tout administrateur réseau lors des choix des mesures de protection (et qui doit l'encourager à recourir à la défense en profondeur).
Lors du second audit chez la société d'infogérance, tous les ingénieurs qui maintiennent les serveurs des clients sont connectés en permanence sur l'application de supervision. Notre première tentative, réussie, d'interception réseau (ARP spoofing), révèle alors 8 couples d'identifiants login/mot de passe en 1 minute !!!
Tout simplement, car les ingénieurs qui utilisaient l'application de supervision émettaient des requêtes régulières vers celle-ci dont chacune contenait l'en-tête d'authentification Basic.
Sur ces 8 comptes, 5 étaient directement réutilisables sur le domaine, 1 nécessitait une petite variation sur le mot de passe (lorsque l'on observe monmotdepassede2014, il est assez évident de localiser le sous-élément itérable) et 1 de ceux-ci était administrateur du domaine.
3.5 Je t'avais dit qu'il fallait une clé de 15
Même un durcissement de la configuration du htaccess n'aurait pas constitué une protection viable. La méthode DIGEST (qui transmet un condensat du mot de passe), plus sécurisée que la méthode BASIC, peut tout de même nous permettre de tenter une attaque par dictionnaire sur l'empreinte du mot de passe observé.
Nous pouvons aussi réutiliser directement cette empreinte sur l'application en question (s'il n'y a pas de nonce).
L'utilisation d'une véritable page d'authentification, qui crée ensuite un jeton de session associé à un cookie, aurait réduit légèrement les possibilités d'interception puisque le mot de passe de l'utilisateur n'est transmis qu'une fois : lors de l'authentification. L'ARP cache poisonning aurait donc dû se faire sur une période plus longue pour avoir la « chance » d'observer le moment de l'authentification.
Bien entendu, la chance peut se forcer. L'attaquant peut intercepter les requêtes de l'utilisateur et en supprimer le cookie, il sera alors redirigé vers la page d'authentification et devra renseigner de nouveau ses identifiants de connexion (bien que ce comportement puisse quand même éveiller ses soupçons).
Quoi qu'il en soit, même la seule observation du cookie (et non du mot de passe original) peut permettre d'accéder à l'espace authentifié sur l'application elle-même (mais cela n'expose pas directement le reste du réseau).
Ici, seule une couche de sécurité TLS bien configurée permet d'assurer le niveau de sécurité adéquat. Encore faut-il fallu que le certificat légitime soit reconnu par les postes clients. Dans le cas contraire, l'attaquant peut substituer le sien puisque l'utilisateur voit une alerte de sécurité dans son navigateur même lorsqu'il utilise le certificat légitime.
3.6 Fais-le ou ne le fais pas
Nous sommes donc également dans le cas d'une mesure parcellaire qui conduit à un risque plus grand que l'absence de protection. En effet, initialement le risque était qu'un attaquant muni d'un simple outil automatique (nmap) accède aux fonctionnalités d'une application sensible.
Avec les mesures prises, le risque est désormais qu'avec un autre simple outil automatique (ettercap), l'attaquant accède aux fonctionnalités d'une application sensible et prenne le contrôle du domaine ! Ceci lui permet ensuite de se connecter en administrateur sur tous les postes, d'écouter les frappes au clavier, d'espionner l'activité des processus, etc.
4. Haute indisponibilité
Nombre d'entreprises ont recours aux clusters de pare-feu, routeurs, ou autres équipements, afin d'assurer une disponibilité continue en cas de défaillance de l'équipement.
En effet, la perte d'un routeur peut par exemple gravement impacter la production si les moyens de remplacement ne sont pas suffisamment rapides. Certaines entreprises (trading, approvisionnement industriel, etc.) ne peuvent tout simplement pas se permettre la moindre indisponibilité.
On appelle « haute disponibilité » le recours aux mécanismes de redondance des équipements. Il s'agit de la solution la plus adaptée pour toute entreprise dont une perte de disponibilité du SI engendre des coûts trop importants.
Et pourtant, mal configurés (c'est-à-dire configurés par défaut) ces mécanismes peuvent devenir les principaux ennemis de la disponibilité.
4.1 La théorie
Le principe global consiste à définir une adresse IP « virtuelle » qui sera jointe par tous les postes clients. Les deux machines du cluster, l'actif et le passif, qui ont chacune une adresse IP propre, se partagent ensuite le droit de répondre sur cette adresse virtuelle.
Si l'actif vient à avoir une défaillance, le passif récupère automatiquement la gestion de l'IP virtuelle, ceci est donc transparent pour les utilisateurs.
Le moyen privilégié pour gérer ce système de bascule consiste , pour les deux machines du cluster, à émettre, à intervalle régulier, des « Hello » stipulant qu'elles fonctionnent toujours bien et indiquant leur priorité. Ces paquets sont émis en multicast, sur une des adresses réservées (dans la plage 224.0.0.0/24), et sont donc adressées à tout le sous-réseau local, mais ne peuvent pas être transmises par un routeur sur une autre interface [8][12] (afin de ne pas perturber les protocoles de redondances des autres routeurs).
La machine émettant le paquet de plus forte priorité prend la main sur l'adresse IP virtuelle et devient l'actif. Dès lors, le passif surveille que l'actif envoie toujours les « Hello » à intervalle régulier. Dès que ceux-ci ne sont plus émis, le passif en déduit que l'actif n'est plus opérationnel et prend donc sa place.
Être « actif » et « gérer » l'adresse IP virtuelle se matérialise par le fait de répondre aux requêtes ARP émises sur l’adresse IP virtuelle par les clients du segment réseau. Le routeur passif s'interdit donc d'y répondre.
Il existe plusieurs protocoles implémentant ce dispositif et il est fréquent de rencontrer les suivants : Hot Standby Router Protocol (HSRP), Virtual Router Redundancy Protocol (VRRP) et Gateway Load Balancing Protocol (GLBP) qui ont été développés par Cisco (VRRP étant une version standardisée de HSRP).
Par chance, les trois souffrent du même défaut flagrant.
4.2 Nan mais #sécurité quoi
Voici à quoi ressemble par exemple le trafic HSRP (captable depuis n'importe quel poste du segment réseau) :
Nous pouvons voir que les deux adresses IP du cluster, 10.142.50.191 et 10.142.70.191, émettent régulièrement des paquets « Hello » relatifs à la gestion de l'IP virtuelle 10.142.0.1 (toutes les 3 secondes) et en multicast. L'actif est la machine qui possède l'IP 10.142.70.191 et qui déclare une priorité de 250. Le passif émet une priorité de 100 (il s'agit d'un entier non signé codé sur 8 bits).
Bien, que se passerait-il si Kevin, connu pour avoir un humour douteux, s'amusait à envoyer des paquets HSRP avec une priorité de 255 ? Oh et bien le protocole est remarquablement efficace, le routeur actif capte qu'il n'est plus la machine de plus forte priorité et cède sa place (comme quoi, des fois, le hacking, il suffit de demander poliment). Nous avons donc deux machines passives (les routeurs) et une active (celle de Kevin the evil hacker).
Bien qu’il soit officiellement devenu le routeur, généralement, l'attaquant n'est pas en position de pouvoir router tout le trafic (et donc de l'intercepter) : il n'a pas d'accès aux autres interfaces réseaux auxquels sont connectés les routeurs légitimes. Il doit donc réémettre les paquets vers l’un des routeurs légitimes. Il peut ainsi espionner le trafic de façon transparente ou bien le bloquer totalement et ainsi engendrer une chute de tout le réseau local (comme quoi la réputation de Kevin n'est pas usurpée elle).
Il est utile de préciser que parfois, seul le déni de service est réalisable. En effet, comme les routeurs légitimes sont en positions passive, suivant le protocole de redondance utilisé et son implémentation, il est possible qu’ils ne retransmettent pas les paquets que leur envoie l’attaquant essayant de réaliser un Man in The Middle (puisqu’ils ne sont pas censés être sollicités).
Devant tant de laxisme, les braves gens se lèvent d'indignation « on pourrait au moins mettre une authentification sur ce protocole ». Messieurs, Cisco vous a entendu ! Si vous observez bien la capture précédente, vous verrez qu'il y a une section « Authentication data » avec un mot de passe (ici cisco …).
Alors, nous pourrions écrire un livre sur l'utilité d'un mot de passe « secret » envoyé en multicast sur tout le segment réseau… ... mais il serait aussi court que celui de Microsoft qui traite de l'utilité de cacher une clé privée dans une dll publique du système d'exploitation le plus distribué au monde [10] (ouvrage préfacé par MacAfee [11]).
Plusieurs types d'authentification ont été employés, mais le fonctionnement même du protocole les rend caducs ou superflus. La RFC 3768 qui définit le protocole VRRP a notamment tranché là-dessus :
« VRRP does not currently include any type of authentication. Earlier versions of the VRRP specification included several types of authentication ranging from none to strong. Operational experience and further analysis determined that these did not provide any real measure of security »
Traitons rapidement du niveau de compétence nécessaire à la réalisation de cette attaque... Les outils comme yersinia ou loki le font automatiquement et avec interface graphique. Donc en termes de complexité, nous noterons « surmontable ».
4.3 R2 répare l'hyperpropulsion ou nous sommes perdus
On imagine bien que sur un réseau ayant déployé un mécanisme de haute disponibilité, une coupure du réseau est pour le moins mal vécue et ressemble rapidement à un cauchemar.
Prenez en considération le temps nécessaire pour identifier la source du problème. Si un attaquant a déposé un dispositif (un Raspberry Pi par exemple) configuré pour envoyer automatiquement ses messages HSRP en continu, troubleshooter la panne réseau va vite devenir un enfer.
Rien qu'observer le trafic sera déjà difficile. La panne pourrait durer des heures. Éteindre et rallumer tout le réseau ne suffirait pas. L'administrateur pourra tenter de connecter un à un les ports des switchs jusqu'à repérer celui qui refait tomber le réseau. Gageons que cette méthode ne sera employée qu'après épuisement des autres solutions.
Si par exemple l'entreprise est engagée vis-à-vis de ses clients sur des indicateurs de disponibilité, l'affaire peut avoir des répercussions financières non négligeables.
4.4 Je veux des noms
Penchons-nous maintenant sur ce qui aurait dû être fait pour éviter cette atteinte. Rien de très simple malheureusement.
Premièrement, fixer la priorité du routeur actif à 255 afin que personne ne puisse le supplanter n'est pas viable. En effet, en cas d'égalité, c'est la machine ayant l'adresse IP la plus « élevée » qui récupère le bébé. Donc ceci n'est pas une protection fiable (de plus, certaines mauvaises langues prétendent que Cisco ne permet pas de fixer une priorité supérieure à 250 [9]).
Les protocoles HSRP, VRRP, etc. supportent plusieurs types d'authentification, mais aucun d'eux n'est assez probant pour éviter un rejeu de paquet et aboutir, d'une façon ou d'une autre, à une panne du réseau. Notamment via la coexistence de plusieurs routeurs actifs (et donc un réseau totalement inutilisable) [8].
La meilleure solution consiste à restreindre les machines pouvant émettre des paquets HSRP (ou autre). Pour cela, plusieurs solutions existent. Le trafic multicast peut se faire sur un VLAN différent de celui de l'IP virtuelle, un tunnel IPSec peut également être utilisé entre les deux machines du cluster, etc.
Il est également possible de stipuler, au niveau des routeurs, les machines depuis lesquelles ils acceptent les paquets HSRP. Ceci n’empêche pas l'attaquant d'usurper leur adresse, avec de l'ARP spoof par exemple, si les protections nécessaires ne sont pas en place sur le réseau (mais si l'ARP spoof est possible, l'attaquant n'a pas de raison de s’embêter avec HSRP).
4.5 Si c'est trop facile à installer, c'est probablement vulnérable
Sachant qu'une entreprise qui a recours à la redondance du matériel a probablement un fort besoin de disponibilité, il est regrettable que l'implémentation de la solution de haute disponibilité constitue, in fine, la source principale d'atteinte à cette dernière.
L'utilisation d'un protocole au sein d'une entreprise doit systématiquement s'accompagner d'un minimum de recherche sur ses vulnérabilités inhérentes et sur les moyens de s'en prémunir. Un très grand nombre de protocoles ne sont pas designés pour assurer une quelconque sécurité : ARP, DHCP, telnet, DNS, etc.
Les mesures permettant d'éviter leur exploitation passent souvent par les équipements réseaux au travers de fonctionnalités plus ou moins complexes à déployer.
Conclusion
Ces trois exemples classiques nous montrent comment une volonté d'améliorer la sécurité peut aboutir à l'effet inverse en l'absence d'un suivi rigoureux des bonnes pratiques.
Ces expériences doivent mener les consultants à prévoir ces réactions et à adapter leurs recommandations. Les préconisations doivent être segmentées en mesures atomiques correspondant aux paliers où le gain de sécurité est avéré. Il doit être stipulé que l'application partielle des mesures de la préconisation donnée ne permet pas d'atteindre le palier de sécurité et peut même en dégrader le niveau.
L'objectif est d'éviter que le client ne s'arrête à mi-chemin dans une position où il est plus exposé qu'au départ.
Par exemple, pour la mise en place d'une authentification sur une application, la première recommandation atomique est : « mettre en place une première barrière d'authentification (page de login ou htaccess) et utiliser le protocole HTTPS avec un certificat valide ». Ceci assure un premier niveau de sécurité indivisible au travers de deux mesures : HTTPS sans l'authentification est aussi inutile que l'authentification sans HTTPS.
Dans un second temps, il peut être proposé au client de : « privilégier une page d'authentification permettant d'allouer un cookie de session, non prédictible, à l'utilisateur. Protéger le cookie avec les attributs httpOnly et secure »
Ici aussi : mettre en place un gestionnaire de session par cookie sans prendre les mesures de protection adéquates sur ceux-ci reviendrait à dégrader la sécurité par rapport au palier précédent. Il s'agit donc d'un paquetage de mesures atomique.
Références
[1]http://www.ietf.org/rfc/rfc5216.txt
[2] https://en.wikipedia.org/wiki/Extensible_Authentication_Protocol
[3] http://tools.kali.org/wireless-attacks/asleap
[4] http://tools.kali.org/wireless-attacks/eapmd5pass
[5] https://github.com/OpenSecurityResearch/hostapd-wpe
[6] https://www.cloudcracker.com/blog/2012/07/29/cracking-ms-chap-v2/
[7] https://tools.ietf.org/html/rfc1945#section-11.1
[8] https://tools.ietf.org/html/rfc3768#section-10
[11] https://funoverip.net/wp-content/uploads/2013/12/Turning-your-managed-AV-into-my-botnet_OWASP2013_Nokin-Jerome_v1.1.pdf (slide 15)
[12] https://en.wikipedia.org/wiki/Multicast_address
[13] Basé sur les audits menés par ITrust sur 2014-2015