Mieux protéger son réseau en le segmentant
Deux vulnérabilités récentes affectant les systèmes Windows 10 et Windows Server 2016 et 2019 de Microsoft montrent une fois encore l'intérêt qu'il y a à segmenter ce réseau.
Avec la pandémie, les entreprises ont besoin que leur technologie soit accessible depuis n'importe où. Cependant, du fait des nombreuses vulnérabilités en matière de sécurité, il n'est peut-être pas très judicieux d'exposer toutes ses ressources à Internet. Malgré tout, des entreprises ou des établissements d'enseignement ont fait le choix d'attribuer des adresses IP publiques à tous leurs ordinateurs et périphériques. Or, il arrive couramment que des réseaux soient accidentellement ouverts aux attaquants. La segmentation des réseaux permet d'atténuer les risques liés à ces portes involontairement ouvertes. Mais, avant d'aborder ce sujet, quelques exemples récents permettent de mieux comprendre comment les attaquants parviennent à compromettre tout un réseau.
Bad Neighbor exploite la gestion par Windows des paquets RA
En octobre dernier, Microsoft a livré une mise à jour de sécurité pour corriger une vulnérabilité liée à une mauvaise gestion des messages d'annonce du routeur (RAM) ou Router Advertisement (RA) ICMPv6 par la pile TCP/IP de Windows. Appelée « Bad Neighbor », la vulnérabilité référencée CVE-2020-16898 impactait toutes les versions de Windows 10 et de Windows Server 2016 et 2019. Cette vulnérabilité n'exposait pas nécessairement le réseau à une attaque directe à distance, mais à une attaque mixte démarrant par une campagne de phishing, puis l'injection d'un malware dans la station de travail via un leurre et débouchant finalement sur un accès au réseau. Les preuves de concept déclenchent des écrans bleus de la mort, mais pas un contrôle à distance complet. Le problème sous-jacent résulte du traitement inapproprié des messages d'annonce des routeurs, lui-même lié au Neighbor Discovery Protocol. Un hacker distant peut exécuter l'attaque sans authentification, mais pas facilement. Comme indiqué dans une preuve de concept, « pour réaliser l'exécution du code à distance, l'attaquant doit contourner la protection de la pile de cookie, et doit également connaître l'état de la mémoire du noyau de la machine cible, ce qui signifie que le bogue doit probablement être associé à une vulnérabilité supplémentaire de divulgation de la mémoire ».
Certains ont recommandé de désactiver l'IPv6 pour atténuer cette attaque, mais comme le recommande le programme Internet Storm Center du SANS Technology Institute (SANS ISC), il est préférable de ne pas désactiver l'IPv6 à moins d'en connaître l'impact avec certitude. Si vous ne pouvez pas appliquer de patch, mieux vaut désactiver la fonctionnalité spécifique. Pour cela, il faut utiliser la commande suivante :
netsh int ipv6 set int *INTERFACENUMBER* rabaseddnsconfig=disable.
Pour déterminer le numéro d'interface, tapez la commande route print sur une ligne de commande élevée. Cela permettra de lister les interfaces sur vos adresses IP comme indiqué ci-dessous.
Ensuite, tapez la commande :
netsh int ipv6 set int *INTERFACENUMBER* rabaseddnsconfig=disable
Insérez le numéro d'interface indiqué plus haut (ici, le 7) dans la commande comme indiqué dans la capture ci-dessous.
Dès que vous êtes prêt à déployer le patch, annulez le contournement en tapant la commande :
netsh int ipv6 set int *INTERFACENUMBER* rabaseddnsconfig=enable
La vulnérabilité SharePoint permet l'exécution de code à distance
Le deuxième correctif de sécurité est tout aussi important pour une entreprise, si ce n'est plus. La vulnérabilité référencée CVE-2020-16952 a un impact sur SharePoint 2013, 2016 et 2019 quand un attaquant/utilisateur télécharge un paquet d'application SharePoint spécialement conçu vers une version affectée de SharePoint. Le logiciel ne vérifie pas le balisage source d'un paquet d'application et permet alors l'exécution de code à distance (Remote Code Execution, RCE). Comme indiqué dans la preuve de concept, « un attaquant authentifié peut créer des pages pour déclencher une inclusion côté serveur (Server Side Inclusion, SSI) qui peut servir à divulguer le fichier web.config. L'attaquant peut en tirer parti pour exécuter du code à distance ».
Si SharePoint est configuré pour qu'un utilisateur SharePoint sans privilége puisse télécharger des fichiers - s'il dispose par exemple de l'autorisation AddAndCustomizePages - des utilisateurs non authentifiés pourraient déclencher ce RCE si vos déploiements SharePoint disposent d'autorisations moins strictes que celles qui sont recommandées. Les permissions normales pour les utilisateurs authentifiés permettent de créer des pages et autorisent la fuite d'un fichier arbitraire, notamment le fichier web.config de l'application. Les attaquants peuvent utiliser ce fichier pour déclencher une exécution de code à distance via la désérialisation de .NET, comme le note AttackerKB. De nombreux serveurs sont exposés à Internet et pourraient être exposés à des attaques.
Les avantages de la segmentation du réseau
Ces deux vulnérabilités mettent en évidence les risques d'exposition en fonction de la configuration de votre réseau. Même si dans ces deux exemples le remède immédiat consiste à appliquer les correctifs appropriés, il est important de vérifier l'accès et la configuration de votre réseau. Quand vous configurez un ordinateur, un serveur, un service cloud ou toute autre ressource potentiellement accessible depuis Internet, essayez d'évaluer les précautions et les ressources supplémentaires dont vous pourriez avoir besoin pour en protéger l'accès. Trop souvent, les règles de pare-feu de la politique de groupe sont configurées pour autoriser l'accès et ne sont pas limitées de manière spécifique à un réseau ou à un groupe.
Depuis de nombreuses années, la segmentation du réseau a fait ses preuves et peut être considérée comme une bonne pratique fondamentale. Le concept derrière la segmentation du réseau consiste à s'assurer que le réseau est compartimenté en fonction du type d'information, de la sensibilité des processus d'information et du lieu où sont stockées les données. Que vous protégiez des machines ou des serveurs physiques ou virtuels, ou même des ressources cloud, examinez précisément la configuration de vos ressources, et sachez qui et quoi y a accès.
Ces meilleures pratiques peuvent vous aider à protéger vos ressources internes :
- Scannez régulièrement le réseau pour vous assurer que seuls les dispositifs autorisés sont connectés.
- Limitez les dispositifs qui se trouvent sur le même sous-réseau aux seuls dispositifs requis ou autorisés.
- Quand vous créez des zones démilitarisées (DMZ), configurez la journalisation et la surveillance de façon à conserver les informations d'en-tête et de charge utile passant par la frontière du réseau et envoyez les informations à un système de journalisation.
- Utilisez des réseaux locaux virtuels (VLAN) pour isoler les types d'information et de traitement ayant des exigences de protection différentes avec un filtrage par pare-feu pour garantir que seules les personnes autorisées peuvent communiquer avec les systèmes nécessaires pour exercer leurs responsabilités spécifiques.
- Établissez un inventaire des assets technologiques qui se connectent au réseau, y compris une liste des dispositifs et des adresses IP. Cet inventaire devrait inclure tous les systèmes du réseau. Parmi les appareils ayant une adresse IP qui se connectent à votre réseau, il peut y avoir des appareils IoT, des imprimantes, des mobiles, et, le travail à domicile étant devenu la nouvelle norme, des appareils domestiques qui ont été connectés involontairement.
Segmenter le réseau pour tester un patch
Analysez l'impact des mises à jour d'octobre sur votre réseau. Si vous avez besoin d'appliquer un correctif immédiatement, essayez de voir si vous pouvez segmenter votre réseau afin de gagner du temps. Veillez toujours à ce que les postes de travail et les serveurs ne soient pas directement exposés à Internet sans une certaine protection. Vérifiez la configuration de vos serveurs SharePoint et la manière dont ils sont déployés. Ce ne sera pas la dernière fois que l'on trouvera une vulnérabilité RCE sur les serveurs SharePoint. Vérifiez comment vous avez déployé vos serveurs et si vous pouvez mieux les protéger avec SSL VPN ou d'autres options. Vous constaterez peut-être qu'il y a de bien meilleures façons de déployer les ressources et de les protéger.
