Comment sécuriser son SI avec une détection NIDS ? La limite des GPOs

1. Introduction
2. Détection de vulnérabilités HIDS et NIDS
3. Limites des GPOs
4. Exemple avec la détection NIDS du protocole mDNS
5. Conclusion

Introduction

Au sein d’un SOC, le rôle des analystes est de détecter les intrusions, les comportements non conformes, les attaques, les vulnérabilités, etc. Il a aussi pour rôle d’aider à les corriger et d’accompagner nos clients jusqu’à la résolution totale du problème.

Cependant, selon le type de détection utilisée, elle apparait plus ou moins pertinente.

Nous allons toucher dans cet article à la détection NIDS ainsi qu’à la remédiation de vulnérabilités en mettant en avant le fait qu’il ne soit pas si simple de tout résoudre.
Nous avons constaté que dans de nombreux cas, les GPOs sont utilisées pour combler des failles de sécurités, mais que bien souvent, celles-ci ne suffisaient pas à résoudre le problème en totalité.

En aucun cas, il faut s’arrêter au fait seul qu’une action a été mise en place, car le risque d’oublier un élément important est fort.

Détection de vulnérabilités HIDS et NIDS

Introduction

« Les systèmes de détection d’intrusions machine (ou « Host Intrusion Detection Systems », HIDS) et les systèmes de détection d’intrusions réseau (ou « Network Intrusion Detection Systems », NIDS) sont des méthodes de gestion de la sécurité des ordinateurs et des réseaux. », Rédaction TechTarget, LeMagIT.

La plupart des systèmes de surveillance utilisent une détection machine HIDS et peu d’entre eux possèdent une détection réseau NIDS.

Pourtant, leur utilisation et leur résultat sont assez différents et très complémentaires. Chacun des types de détection possède des qualités intéressantes afin d’assurer la sécurité du réseau.

Quelques différences

Les applications prenant part à une détection HIDS vont récupérer les informations, évènement, logs, etc. directement sur l’hôte souhaité.

A contrario, les applications d’un système NIDS se trouvent en dehors des machines à surveiller et s’occupent de monitorer tous les flux entrants et sortant à des points précis du réseau.

A l’aide de la détection HIDS, il est possible de détecter rapidement les problèmes présents sur les machines grâce à une meilleure précision des logs et évènements qui fournissent des informations pertinentes sur les menaces potentielles, les attaques et les vulnérabilités.

Cependant, il est rare d’avoir une collecte des logs de l’entièreté des machines d’un réseau et il est donc difficile d’avoir la confirmation qu’un patch est bien appliqué et fonctionne sur chaque machine de ce même réseau. C’est alors que peut intervenir la détection NIDS qui peut avoir une vue sur l’entièreté d’un réseau.

Limites des GPOs

Résolution générique des problèmes

Une détection HIDS permet la détection de problème(s) précis comme des attaques sur une ou plusieurs machines mais aussi la détection de vulnérabilité.

Certaines vulnérabilités et problèmes pourront se résoudre assez rapidement soit via une GPO, soit directement sur les machines impactées par l’application des modifications nécessaires selon le problème.

Lors d’un audit, il est commun d’auditer seulement une sélection de machine type afin d’extrapoler sur l’état global des machines et du réseau de l’entreprise. Les résolutions proposées sont alors des résolutions globales et génériques, souvent mise en place au niveau de l’AD.

C’est alors qu’un problème survient, beaucoup plus facilement détecté par une source de log NIDS qui fournit une vue large du réseau : Qu’en est-il des exceptions ?

Cas par cas

Les exceptions peuvent souvent être les plus dangereuses. Je pense surtout aux machines n’étant pas monitorées ou n’ayant pas forcément de logs.

Un exemple simple que l’on peut citer serait les imprimantes. Certaines sont connectées à l’AD et peuvent être très rapidement vulnérables. Pourtant, ne fonctionnant pas comme une machine Windows ou Linux, les GPOs s’appliquent différemment ou pas du tout.

Il s’agit alors d’une des exceptions qui peut mettre tout votre réseau en péril.

C’est alors qu’intervient la détection NIDS. Celle-ci ne fait pas d’exception, elle détecte toutes les machines qui peuvent être impactées (à partir du moment où la détection peut être faite passivement sur le réseau). Une fois une GPO appliquée, on peut très vite s’apercevoir que tout n’est pas résolu (que ce soit un problème d’application de GPO, un bug de Microsoft…). C’est à ce moment qu’il faut réaliser de la détection au cas par cas.

La plupart des détections sont dues à un service ou à une application qui utilisent sa propre configuration et doit donc être reconfigurée manuellement. Certaines autres ne peuvent pas être configurées, on se devra alors de trouver une autre solution afin de mitiger les risques.

Exemple avec la détection NIDS du protocole mDNS

Introduction

« Multicast DNS (mDNS) est un service conçu pour aider à la résolution de noms dans les petits réseaux. Toutefois, le mDNS utilise une méthode différente de celle du DNS traditionnel : au lieu de solliciter un serveur de noms, tous les participants au réseau sont directement adressés. », Ionos.

Pourquoi nous pencher sur la détection de ce protocole en particulier ?

Ce protocole est finalement peu utilisé en dehors des environnements IOT (Apple IOT entre autres). Cependant, de nombreux logiciels/OS s’y sont mis et l’ont implémenté. La plupart l’utilise même par défaut comme les OS des imprimantes HP ou encore les iDracs des servers DELL.

Pourtant, ce protocole émet un certain risque (avec ses collègues LLMNR et Netbios). En effet, ces requêtes multicast reposent sur la confiance alors que toutes les machines ne devraient pas être considérées comme étant « de confiance ».

La détection et les tests ont été réalisés avec l’outil Suricata v6.8+ (Utilisation d’un SIEM NIDS – Stamus Networks).

Exemple de schéma d’attaque

Voici donc un exemple de schéma d’attaque possible exploitant le protocole mDNS :

1. L’utilisateur (ou une application) saisit de manière incorrecte un nom d’hôte qui est interrogé sur le réseau local ;
2. Le contrôleur de domaine répond et indique que le nom d’hôte n’existe pas dans le DNS ;
3. Le protocole de découverte d’hôte mDNS diffuse alors la demande ;
4. L’attaquant répond au protocole de découverte d’hôte en indiquant que l’attaquant est l’hôte recherché et que l’utilisateur doit s’authentifier auprès de l’attaquant ;
5. Le poste de travail envoie des identifiants d’authentification à l’attaquant soit sous la forme d’un nom d’utilisateur et d’un mot de passe, soit sous la forme du mot de passe de l’utilisateur haché au format NTLMv1 ou NTLMv2 ;
6. Avec ces informations d’identification, un attaquant peut soit rejouer le hachage sur un autre ordinateur et obtenir une session, soit tenter de déchiffrer le hachage hors ligne. Si un attaquant reçoit un mot de passe en clair, il dispose désormais d’informations d’identification de domaine et du même accès que l’utilisateur.

Malheureusement, ce n’est qu’un exemple et comme ce protocole peut fournir de nombreuses informations sur l’hôte envoyant la demande, il peut fournir d’autres pistes d’attaques.

Sachant qu’il n’est pas très utile et est une menace, pourquoi ne pas le désactiver ?

Détection et désactivation générique

Pour cet exemple de détection, nous allons utiliser Suricata et y créer une règle. Afin de détecter rapidement des requêtes mDNS, il suffit de détecter les requêtes Multicast (spécifique au mDNS) envoyées sur le port 5353 :

alert udp $HOME_NET 5353 -> [224.0.0.0/4, ff02::fb] 5353
(
msg:"CNX mDNS Detection (Request)";
threshold: type limit, track by_src, seconds 360, count 5;
metadata: tag RELEVANT, created_at 2023_06_27, updated_at 2023_06_27;
classtype: dns_detection; sid: 677888690; rev:1;
)

Cette simple règle va détecter tout le trafic souhaité. Il risque d’y avoir énormément d’alertes. C’est pourquoi une désactivation générique du mDNS sur tout le réseau est le plus simple pour élaguer la plus grosse partie des alertes (voir toutes les alertes si on a beaucoup de chance).
Après quelques recherches, nous pouvons très facilement trouver comment désactiver ce protocole depuis une GPO :

Key	Value	Type
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Dnscache\Parameters\EnableMDNS	0	Dword
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Dnscache\Parameters\QueryNetBTFQDN	0	Dword

Après l’application de cette GPO, nous pouvons constater une diminution de la détection, cependant grâce (ou à cause pour les administrateurs systèmes) à la détection NIDS, nous pouvons très bien voir que tout n’est pas résolu. Il va doit falloir réaliser une résolution au cas par cas.

La désactivation au cas par cas

Pour cette désactivation au cas par cas, il nous faut glaner plus d’informations. Les pistes peuvent être :

• Les requêtes mDNS elles-mêmes (particulières en fonction des services et applications) ;
• Les services et fonctions de la machine impactée ;
• Les informations sur Internet (quelles applications utilisent ce protocole ?).

Les exemples de cas particuliers sur lesquels nous avons pu nous pencher ont été :

• Le service mDNS Gateway on Cisco Wireless APs ;
• L’application Bonjour ;
• Le navigateur Chrome.

Ce sont juste des exemples, il y en a beaucoup d’autres.

Désactivation du mDNS sur les points d’accès sans fil Cisco

Une grande quantité de requêtes mDNS peut laisser présager la présence de point d’accès sans fil. Malgré que la fonctionnalité soit désactivée par défaut, par hasard nous avons détecter des requêtes mDNS en leur provenance chez un de nos clients.

Le fil que nous avons suivi fut le suivant :

1. Quand on regarde la requête mDNS, on peut voir que la machine en question envoie des requêtes avec le pattern `_heartbeat._mdns._gateway._ap._local` ;
2. Après avoir discuté avec les équipes en charge de cette machine, il s’agissait d’un point d’accès sans-fil ;
3. Avec quelques recherches internet, nous avons demandé la désactivation de la fonctionnalité mDNS Gateway sur le point d’accès, ce qui a supprimé toutes les requêtes en provenance de cette machine que l’on détectait.

Afin d’améliorer la détection finale et éviter de refaire ces opérations à chaque fois, nous avons ajouté une règle qui nous permettra de différencier les sources de ces requêtes les fois prochaines :

alert udp $HOME_NET 5353 -> [224.0.0.0/4, ff02::fb] 5353
(
msg:"CNX mDNS Gateway Enable on AP Controller";
content:"_heartbeat"; offset:13; depth:16;
content:"_mdns"; distance:1; within:30;
threshold: type limit, track by_src, seconds 3600, count 1 ;
metadata: tag INFORMATIONAL, created_at 2023_07_03, updated_at 2023_07_03;
classtype: dns_detection; sid: 677888691; rev:1;
)

Autres règles de détection et leur méthode de résolution

La méthode est similairement la même, appliquée à des requêtes spécifiques. Sans rentrer dans les détails, voici les règles de détection et procédure de résolution pour le protocole mDNS utilisées par Chrome, et l’application Bonjour.

Googlecast / Chromecast

Règle de détection Suricata :

alert udp $HOME_NET 5353 -> [224.0.0.0/4, ff02::fb] 5353
(
msg:"CNX mDNS Googlecast detection";
content:"_googlecast"; offset:13; depth:11;
threshold: type limit, track by_src, seconds 3600, count 1;
metadata: tag INFORMATIONAL, created_at 2023_07_03, updated_at 2023_07_03;
classtype: dns_detection; sid: 677888694; rev:1;
)

Résolution : Application par GPO sur toutes les machines de cette modification de clé de registre.

Key	Value	Type
HKEY_LOCAL_MACHINE\Software\Policies\Google\Chrome\EnableMediaRouter	0	Dword

Application Bonjour

Règle de détection sur Suricata sur les imprimantes :

alert udp $HOME_NET 5353 -> [224.0.0.0/4, ff02::fb] 5353
(
msg:"CNX mDNS Bonjour App enable on Printer";
content:"_printer"; offset:13; depth:8;
threshold: type limit, track by_src, seconds 3600, count 1;
metadata: tag INFORMATIONAL, created_at 2023_07_03, updated_at 2023_07_03;
classtype: dns_detection; sid: 677888692; rev:1;
)

Règle de détection sur les iDRAC :

alert udp $HOME_NET 5353 -> [224.0.0.0/4, ff02::fb] 5353
(
msg:"CNX mDNS iDrac discovery enabled";
content:"_dcimprovsrv"; offset:13; depth:12;
threshold: type limit, track by_src, seconds 3600, count 1;
metadata: tag INFORMATIONAL, created_at 2023_07_03, updated_at 2023_07_03;
classtype: dns_detection; sid: 677888693; rev:1;
)

La plupart des autres détections dont on ne peut préciser la détection sont liées à l’application Bonjour.

Résolution : Désinstallation manuelle de l’application Bonjour sur la machine détectée.

Conclusion

La détection n’est pas forcément toujours facile à comprendre surtout avec toutes les technologies possibles existantes sur le marché, mais aussi dû au fait que nous trouverons toujours des exceptions. Détecter puis demander une simple désactivation sur toutes les machines via une GPO, résout très rarement tous les problèmes et cela peut prendre beaucoup de temps et d’énergie afin de le résoudre complètement.

Mais cela ne vaut-il pas mieux que de croire que tout est résolu ?