Ouvrir des portes avec des cadenas

Magazine
Marque
MISC
Numéro
85
|
Mois de parution
mai 2016
|
Domaines


Résumé
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.

Body

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 :

eap-capture

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, getsystemhashdump 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 :

eap_settings

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.

vrrp

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) :

hsrp_capture

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

[9] https://media.blackhat.com/bh-us-10/presentations/Rey_Mende/BlackHat-USA-2010-Mende-Graf-Rey-loki_v09-slides.pdf

[10] https://social.technet.microsoft.com/Forums/windowsserver/en-US/0bc15258-2bc5-40f9-a383-93adcba25a38/microsoft-rdp-server-private-key-disclosure?forum=winserverTS

[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


Sur le même sujet

Auditer la sécurité d'une application iOS

Magazine
Marque
MISC
Numéro
106
|
Mois de parution
novembre 2019
|
Domaines
Résumé

Auditer la sécurité d'une application iOS n'est toujours pas une tâche aisée. Force est de constater que la plupart des auditeurs, amateurs de bug bounty ou autres curieux préfèrent travailler sur les applications Android malgré les récentes protections ajoutées au système d'exploitation de Google. Nous allons malgré tout essayer de présenter une méthodologie qui rend possible l'analyse orientée sécurité d'une application iOS, même sans jailbreak. Un bref rappel sera effectué pour ensuite introduire quelques outils et documentations apparues ces derniers mois.

Sondes de détection : performances, évaluations et biais

Magazine
Marque
MISC
Numéro
106
|
Mois de parution
novembre 2019
|
Domaines
Résumé

En avril 2019, l’ANSSI a qualifié les premières sondes pour assurer la supervision de sécurité de réseaux. Les opérateurs d’importance vitale (OIV), les opérateurs de services essentiels (OSE) et, d’une manière générale, les organismes opérant des fonctions sensibles disposent ainsi de produits français de confiance : Cybels Sensor de Thales et Trackwatch Full Edition de Gatewatcher.La méthodologie d’évaluation des sondes n’est, hélas, pas publique. Les ingénieurs sécurité et réseau devant intégrer ces sondes ne disposent donc pas de guides pour effectuer la recette de leur efficacité en production. Cet article propose un retour d’expérience sur l’évaluation des sondes, notamment sous l’angle de la performance. Cet aspect est, en effet, particulièrement significatif puisque le taux de détection d’une sonde diminue si elle est submergée, quand bien même elle serait équipée des meilleurs signatures et moteurs d’analyse.

Richelieu : solution du challenge de la DGSE

Magazine
Marque
MISC
Numéro
106
|
Mois de parution
novembre 2019
|
Domaines
Résumé

En mai 2019, la DGSE (Direction Générale de la Sécurité Extérieure) a organisé pour la première fois un challenge de sécurité informatique ouvert au public, qu’elle a baptisé Challenge Richelieu. Je vous invite à écouter la bande originale du Bureau des Légendes en fond sonore. Imprégnez-vous de cette atmosphère pleine de tension où les secrets sont rois, puis regardons ensemble ce que nous réservait ce challenge.

Aléa et cryptanalyse de générateurs

Magazine
Marque
MISC
Numéro
106
|
Mois de parution
novembre 2019
|
Domaines
Résumé

La plupart des applications en cryptographie moderne nécessitent à un moment ou un autre une source d’aléa [1]. Que ce soit pour chiffrer, générer des nonces, des clés ou même des sels cryptographiques. Mais comment générer de l’aléa sur nos ordinateurs qui sont des machines déterministes ?Dans cet article, nous allons nous intéresser à la place de l’aléa dans les algorithmes de chiffrements modernes. Puis nous verrons trois CTF ou le but est de cryptanalyser des générateurs de nombres aléatoires ; cela nous permettra d’en comprendre le fonctionnement et de voir quelques attaques sur des générateurs de nombres aléatoires.

Contournement de l'API Google Play Billing

Magazine
Marque
MISC
Numéro
106
|
Mois de parution
novembre 2019
|
Domaines
Résumé

D'après le blog [INVESP], le montant global des paiements dits « in-app » représentait environ 37 milliards de dollars (USD) en 2017 pour les applications mobiles (Android et Apple). Ce montant représente quasiment la moitié des revenus générés par les applications mobiles (48,2%), dépassant les revenus générés par les régies publicitaires (14%), ainsi que l'achat d'applications (37,8%). Il est donc important que la sécurité de ces paiements soit correctement implémentée afin d'éviter un manque à gagner pour les développeurs des applications. Dans le cadre de cet article, nous avons passé en revue 50 applications Android afin d'étudier le fonctionnement de l'API Google Play Billing et d'identifier les vulnérabilités liées à une mauvaise implémentation. Nous détaillerons en exemple des applications vulnérables.

Par le même auteur

Ouvrir des portes avec des cadenas

Magazine
Marque
MISC
Numéro
85
|
Mois de parution
mai 2016
|
Domaines
Résumé
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.

Implémentation d'AES : la nitroglycérine

Magazine
Marque
MISC
Numéro
85
|
Mois de parution
mai 2016
|
Domaines
Résumé
AES est une solution de chiffrement puissante. Ceci implique notamment qu'elle doit être manipulée avec soin et ne pas être laissée entre les mains de développeurs trop pressés. Comme pour la plupart des chiffrements modernes, les failles résultent essentiellement d'une mauvaise utilisation/implémentation plutôt que d'un problème intrinsèque.

Mots de passe, le mieux est l’ennemi du bien

Magazine
Marque
MISC
Numéro
80
|
Mois de parution
juillet 2015
|
Domaines
Résumé
Où en est-on actuellement de l’état de l’art de notre cher sésame ? Doit-on encore suivre aveuglément l’idéal suranné du « mot de passe complexe » ? Mise à jour sur ce qui demeure, in fine, la clé de voûte de la sécurité.