Support technique
Documentation
Connexion
Nous contacter
Configurations par défaut des logiciels et des applications dans le domaine de la cybersécurité
Joao Correia
8 janvier 2024 - Évangéliste technique
Cet article fait partie d'une série consacrée à l'examen d'un récent avis conjoint de la avis conjoint sur la cybersécurité de la NSA et de la CISA sur les principaux problèmes de cybersécurité identifiés lors d'exercices en équipe rouge/bleue menés par ces organisations. Dans cet article, vous trouverez un examen plus approfondi du problème spécifique, avec des scénarios réels où il s'applique, ainsi que des stratégies d'atténuation qui peuvent être adoptées pour le limiter ou le surmonter. Cet article développe les informations fournies par le rapport NSA/CISA.
-
Souvent, les configurations par défaut fournies par les fabricants ne sont pas optimisées pour la sécurité, ce qui rend les systèmes vulnérables aux attaques. Les configurations par défaut des services et applications du système peuvent, par inadvertance, ouvrir des portes à des accès non autorisés et à des activités malveillantes, ou faciliter des opérations de reconnaissance par des adversaires en s'appuyant sur des conditions opérationnelles bien connues.
Deux problèmes majeurs se posent : les informations d'identification par défaut et les autorisations de service et paramètres de configuration par défaut permissifs. Ces configurations, destinées à faciliter l'installation et l'utilisation, deviennent souvent le maillon faible de la cybersécurité.
Impact dans le monde réel
Lors du déploiement d'une pile logicielle bien connue (par exemple, LAMP - Linux, Apache, Mysql et PHP), l'état du système qui en résulte peut facilement être déduit et reproduit. Il est ainsi facile de recréer le système d'une cible potentielle et de rechercher des vulnérabilités, au lieu de déclencher des systèmes de surveillance et d'alerte sur les tentatives de recherche des acteurs de la menace contre les systèmes réels. Il sera également plus facile pour un adversaire d'identifier des vecteurs d'attaque potentiels en identifiant simplement un composant et en supposant (à juste titre) que l'ensemble de la pile est présent.
Problèmes de configuration par défaut
Dans leurs tests d'équipe rouge/bleue, la NSA et la CISA ont trouvé les exemples communs suivants :
Informations d'identification par défaut
Les appareils réseau commerciaux (COTS) sont souvent livrés avec des identifiants prédéfinis par défaut pour les comptes administratifs. Ceux-ci sont facilement découvrables et exploitables par des acteurs malveillants pour l'accès non autorisé aux appareils, la réinitialisation des comptes administratifs ou l'exploitation des informations d'identification VPN. En outre, les appareils tels que les imprimantes, les scanners et les appareils IoT, avec leurs comptes de domaine privilégié chargés, peuvent fournir aux attaquants des capacités de mouvement latéral au sein d'un réseau.
Par le passé, des incidents très médiatisés se sont produits, ou ont été exacerbés, en exploitant ces configurations par défaut. Les botnets ciblant les appareils IoT, en particulier, prospèrent et se développent dans des environnements où le mouvement et la découverte de nouveaux bots se font en exploitant des états de configuration par défaut connus, ce qui permet une propagation rapide et simple du botnet à travers de multiples appareils, réseaux et organisations.
Services de certificats Active Directory (ADCS) non sécurisés
ADCS, un composant essentiel de la gestion de l'infrastructure à clé publique (PKI) dans les environnements Active Directory, peut être compromis en raison d'une mauvaise configuration des modèles. Par exemple, l'activation de l'inscription web sans protection adéquate peut permettre à des attaquants d'obtenir des certificats frauduleux, de se faire passer pour des entités légitimes et d'obtenir un accès non autorisé à des systèmes et des données critiques.
Protocoles et services hérités non sécurisés
Les services réseau vulnérables tels que LLMNR et NetBIOS Name Service dans Windows peuvent être exploités par des techniques d'usurpation, d'empoisonnement et de relais. Ces protocoles, s'ils sont activés, permettent aux attaquants d'intercepter les hachages de domaines et d'accéder au système, ce qui constitue une menace importante pour les environnements Windows.
Service SMB (Server Message Block) non sécurisé
Le service SMB, principalement utilisé pour le partage de fichiers dans Windows, est une autre victime des paramètres par défaut non sécurisés. L'absence de signature SMB obligatoire permet aux pirates d'effectuer des attaques de type "machine-in-the-middle", en accédant à des systèmes distants sans avoir besoin de capturer et de craquer des hachages.
Si ces résultats semblent indiquer que le problème est plus répandu sur les réseaux basés sur Windows, ce n'est pas nécessairement le cas. Les résultats peuvent simplement avoir été faussés par les environnements de test disponibles. Les configurations par défaut connues peuvent affecter, et affectent en fait, tout type de système d'exploitation et d'environnement. Par exemple, la plupart des distributions Linux sont livrées avec une configuration sshd (secure shell daemon) activée qui n'impose pas la connexion par clé (ou l'active même) par défaut, même si cette forme d'authentification est plus résiliente que la connexion et le mot de passe traditionnels. Une autre configuration par défaut courante est l'absence de protection par force brute sur le même service sshd, ce qui fait de tout système Linux nouvellement déployé (et tourné vers l'internet) une cible immédiate pour des armées de robots cherchant des comptes vulnérables par essais et erreurs.
Stratégies d'atténuation
Pour lutter contre ces vulnérabilités, il est essentiel de modifier les configurations par défaut des applications et des appareils avant leur déploiement. Il s'agit notamment de modifier ou de désactiver les noms d'utilisateur et les mots de passe par défaut fournis par le fournisseur et d'imposer l'utilisation de mots de passe forts. Pour les ADCS, il faut garantir des configurations sûres en mettant à jour et en corrigeant l'infrastructure, en employant des mécanismes de surveillance et d'audit robustes et en mettant en œuvre des contrôles d'accès rigoureux. Il est également essentiel d'examiner et de restreindre les autorisations sur les modèles ADCS afin d'empêcher l'émission de certificats non autorisés.
Une stratégie plus invasive consiste à ne pas laisser les systèmes dans un état utilisable immédiatement après leur déploiement. Lorsqu'un système est déployé et qu'il est immédiatement utilisable, les avantages d'une modification de la configuration sont moindres. Ainsi, faire en sorte que l'état par défaut ne soit pas immédiatement utilisable rendrait la nécessité de modifier la configuration obligatoire plutôt qu'optionnelle. Bien que cela aille à l'encontre des attentes et ait quelques détracteurs, cela obligerait également les équipes informatiques à appliquer intentionnellement des modifications de configuration spécifiques à l'environnement qui rendraient un déploiement différent du suivant, ce qui réduirait considérablement ce type de risque. Ce type d'approche, bien que plus efficace, présente donc certains inconvénients, à savoir l'augmentation de la charge de travail et du temps de déploiement des nouveaux systèmes.
En résumé, voici quelques stratégies possibles pour atténuer le problème :
Modifier les configurations par défaut avant le déploiement
Modifier ou désactiver les noms d'utilisateur et les mots de passe par défaut avant de déployer les systèmes. Utiliser des mots de passe robustes et respecter les directives de sécurité fournies par le fournisseur.
Utiliser des outils de gestion de la configuration
Utiliser des outils automatisés pour la gestion de la configuration afin de garantir un déploiement sécurisé dès le départ.
Intégrer des audits et des mises à jour régulières
Effectuer des audits réguliers des configurations et appliquer les mises à jour nécessaires pour remédier aux vulnérabilités.
Sensibiliser et former les employés
Mettre en œuvre des programmes de formation complets pour sensibiliser aux risques associés aux configurations par défaut. Ceci est particulièrement important dans les environnements BYOD, où le risque de configurations par défaut provient d'appareils étrangers.
Mise en œuvre d'une politique d'état par défaut non utilisable
Déployer les systèmes dans un état par défaut non utilisable pour obliger les équipes informatiques à appliquer les configurations de sécurité nécessaires. Discutez des compromis de cette approche, tels que l'augmentation du temps de déploiement et la résistance potentielle.
Surveillance continue et journalisation
Mettre en place des pratiques de surveillance continue et de journalisation pour détecter les modifications non autorisées des configurations. Envisager la création d'alertes pour les configurations par défaut présentes dans un système.
