Tester la configuration de l'infrastructure réseau

Résumé

La complexité intrinsèque d'une infrastructure de serveur web interconnectée et hétérogène, qui peut inclure des centaines d'applications web, fait de la gestion et de la revue de la configuration une étape fondamentale pour tester et déployer chaque application. Il suffit d'une seule vulnérabilité pour compromettre la sécurité de toute l'infrastructure, et même des problèmes mineurs et apparemment sans importance peuvent évoluer vers des risques graves pour une autre application sur le même serveur. Afin de résoudre ces problèmes, il est de la plus haute importance d'effectuer un examen approfondi de la configuration et des problèmes de sécurité connus, après avoir cartographié l'ensemble de l'architecture.

Une gestion de configuration appropriée de l'infrastructure du serveur web est très importante afin de préserver la sécurité de l'application elle-même. Si des éléments tels que le logiciel du serveur web, les serveurs de base de données backend ou les serveurs d'authentification ne sont pas correctement examinés et sécurisés, ils peuvent introduire des risques indésirables ou de nouvelles vulnérabilités qui pourraient compromettre l'application elle-même.

Par exemple, une vulnérabilité du serveur web qui permettrait à un attaquant distant de divulguer le code source de l'application elle-même (une vulnérabilité qui est apparue à plusieurs reprises dans les serveurs web et les serveurs d'applications) pourrait compromettre l'application, car les utilisateurs anonymes pourraient utiliser les informations divulguées dans le code source pour exploiter des attaques contre l'application ou ses utilisateurs.

Les étapes suivantes doivent être suivies pour tester l'infrastructure de gestion de la configuration :

• Les différents éléments qui composent l'infrastructure doivent être déterminés afin de comprendre comment ils interagissent avec une application web et comment ils affectent sa sécurité.
• Tous les éléments de l'infrastructure doivent être examinés afin de s'assurer qu'ils ne contiennent aucune vulnérabilité connue.
• Un examen doit être fait des outils administratifs utilisés pour maintenir tous les différents éléments.
• Les systèmes d'authentification doivent être examinés afin de s'assurer qu'ils répondent aux besoins de l'application et qu'ils ne peuvent pas être manipulés par des utilisateurs externes pour exploiter l'accès.
• Une liste des ports définis qui sont requis pour l'application doit être maintenue et conservée sous contrôle de changement.

Après avoir cartographié les différents éléments qui composent l'infrastructure (voir Cartographier le réseau et l'architecture de l'application), il est possible d'examiner la configuration de chaque élément trouvé et de tester les vulnérabilités connues.

Objectifs du test

• Examiner les configurations des applications définies sur le réseau et valider qu'elles ne sont pas vulnérables.
• Valider que les frameworks et systèmes utilisés sont sécurisés et ne sont pas susceptibles de vulnérabilités connues en raison de logiciels non maintenus ou de paramètres et d'informations d'identification par défaut.

Comment tester

Vulnérabilités connues du serveur

Les vulnérabilités dans divers domaines de l'architecture de l'application, que ce soit dans le serveur web ou la base de données backend, peuvent gravement compromettre l'application. Par exemple, considérez une vulnérabilité de serveur qui permet à un utilisateur distant non authentifié de télécharger des fichiers sur le serveur web ou même de remplacer des fichiers existants. Cette vulnérabilité pourrait compromettre l'application, car un utilisateur malveillant pourrait être en mesure de remplacer l'application elle-même ou d'introduire du code qui affecterait les serveurs backend, car son code d'application serait exécuté comme n'importe quelle autre application.

L'examen des vulnérabilités du serveur peut être difficile à réaliser si le test doit être effectué via un test de pénétration en boîte noire. Dans ces cas, les vulnérabilités doivent être testées à partir d'un site distant, généralement à l'aide d'un outil automatisé. Cependant, le test de certaines vulnérabilités peut avoir des résultats imprévisibles sur le serveur web, et le test d'autres (comme celles directement impliquées dans les attaques par déni de service) peut ne pas être possible en raison de l'indisponibilité du service impliquée si le test était réussi.

Certains outils automatisés signaleront les vulnérabilités en fonction de la version du serveur web qu'ils récupèrent. Cela conduit à la fois à des faux positifs et à des faux négatifs. D'une part, si la version du serveur web a été supprimée ou masquée par l'administrateur du site local, l'outil d'analyse ne signalera pas le serveur comme vulnérable même s'il l'est. D'autre part, si le fournisseur fournissant le logiciel ne met pas à jour la version du serveur web lorsque les vulnérabilités sont corrigées, l'outil d'analyse signalera des vulnérabilités qui n'existent pas. Ce dernier cas est en fait très courant car certains fournisseurs de systèmes d'exploitation mettent à jour les correctifs de vulnérabilités de sécurité vers le logiciel qu'ils fournissent dans le système d'exploitation, mais ne font pas une mise à niveau complète vers la dernière version du logiciel. Cela se produit dans la plupart des distributions GNU/Linux telles que Debian, Red Hat et SuSE. Dans la plupart des cas, l'analyse des vulnérabilités d'une architecture d'application ne trouvera que les vulnérabilités associées aux éléments "exposés" de l'architecture (tels que le serveur web) et sera généralement incapable de trouver les vulnérabilités associées aux éléments qui ne sont pas directement exposés, tels que le backend d'authentification, la base de données backend ou les proxys inverses [1] en cours d'utilisation.

Enfin, tous les fournisseurs de logiciels ne divulguent pas publiquement les vulnérabilités, ce qui signifie que ces faiblesses peuvent ne pas être enregistrées dans les bases de données de vulnérabilités connues [2]. Ces informations ne sont divulguées qu'aux clients ou publiées via des correctifs qui ne sont pas accompagnés d'avis. Cela réduit l'efficacité des outils d'analyse des vulnérabilités. En règle générale, la couverture des vulnérabilités de ces outils sera très bonne pour les produits courants (tels que le serveur web Apache, Microsoft IIS ou Lotus Domino d'IBM), mais manquera pour les produits moins connus.

C'est pourquoi l'examen des vulnérabilités est mieux effectué lorsque le testeur reçoit des informations internes sur le logiciel, y compris les versions, les versions et les correctifs appliqués. Avec ces informations, le testeur peut récupérer des données auprès du fournisseur et analyser les vulnérabilités potentielles dans l'architecture, ainsi que leur impact potentiel sur l'application. Lorsque cela est possible, ces vulnérabilités peuvent être testées pour déterminer leurs effets réels et pour détecter s'il peut y avoir des éléments externes (tels que des systèmes de détection ou de prévention d'intrusion) qui pourraient réduire ou annuler la possibilité d'une exploitation réussie. Les testeurs peuvent même déterminer par un examen de la configuration que la vulnérabilité n'est pas réellement présente car elle affecte un composant logiciel qui n'est pas utilisé.

Il est également utile de noter que les fournisseurs corrigeront parfois silencieusement les vulnérabilités et rendront les correctifs disponibles avec les nouvelles versions du logiciel. Différents fournisseurs ont des cycles de publication variables qui déterminent le support qu'ils peuvent fournir pour les anciennes versions. Un testeur disposant d'informations détaillées sur les versions logicielles utilisées par l'architecture peut analyser le risque associé à l'utilisation d'anciennes versions logicielles qui pourraient ne pas être prises en charge à court terme ou qui ne sont déjà plus prises en charge. Ceci est essentiel car si une vulnérabilité apparaît dans une ancienne version de logiciel non prise en charge, le personnel des systèmes peut ne pas en être directement conscient. Aucun correctif ne sera jamais mis à disposition pour celui-ci et les avis peuvent ne pas répertorier cette version comme vulnérable car elle n'est plus prise en charge. Même s'ils sont conscients de la vulnérabilité et des risques système associés, une mise à niveau complète vers une nouvelle version du logiciel sera nécessaire, ce qui peut introduire un temps d'arrêt important dans l'architecture de l'application ou nécessiter un nouveau codage de l'application en raison d'incompatibilités avec la dernière version du logiciel.

Outils administratifs

Toute infrastructure de serveur web nécessite l'existence d'outils administratifs pour maintenir et mettre à jour les informations utilisées par l'application. Ces informations incluent le contenu statique (pages web, fichiers graphiques), le code source de l'application, les bases de données d'authentification des utilisateurs, etc. Le type d'outils administratifs utilisés peut varier en fonction du site, de la technologie ou du logiciel spécifique utilisé. Par exemple, certains serveurs web seront gérés à l'aide d'interfaces administratives qui sont elles-mêmes des serveurs web (comme le serveur web iPlanet) ou seront administrés par des fichiers de configuration en texte brut (comme dans le cas d'Apache [3]) ou utiliseront des outils d'interface graphique du système d'exploitation (comme lors de l'utilisation du serveur IIS de Microsoft ou d'ASP.Net).

Dans la plupart des cas, la configuration du serveur est gérée avec divers outils de maintenance de fichiers, administrés via des serveurs FTP, WebDAV, des systèmes de fichiers réseau (NFS, CIFS) ou d'autres mécanismes. De toute évidence, le système d'exploitation des éléments qui composent l'architecture de l'application sera également géré à l'aide d'autres outils. Les applications peuvent également contenir des interfaces administratives intégrées pour la gestion des données de l'application (utilisateurs, contenu, etc.).

Après avoir cartographié les interfaces administratives utilisées pour gérer différentes parties de l'architecture, il est important de les examiner. Si un attaquant accède à l'une de ces interfaces, il pourrait potentiellement compromettre ou endommager l'architecture de l'application. Pour ce faire, il est important de :

• Déterminer les mécanismes qui contrôlent l'accès à ces interfaces et leurs vulnérabilités associées. Ces informations peuvent être disponibles en ligne.
• Assurez-vous que le nom d'utilisateur et le mot de passe par défaut sont modifiés.

Certaines entreprises choisissent de ne pas gérer tous les aspects de leurs applications de serveur web et peuvent déléguer la gestion du contenu à d'autres parties. Cette entreprise externe peut ne fournir que certaines parties du contenu (telles que des mises à jour d'actualités ou des promotions), ou elle peut gérer complètement le serveur web (y compris le contenu et le code). Il est courant de trouver des interfaces administratives accessibles depuis Internet dans ces situations, car l'utilisation d'Internet est moins coûteuse que la fourniture d'une ligne dédiée qui connectera l'entreprise externe à l'infrastructure de l'application via une interface de gestion uniquement. Dans de telles situations, il est crucial de tester si les interfaces administratives sont vulnérables aux attaques.

Références

• [1] WebSEAL, également connu sous le nom de Tivoli Authentication Manager, est un proxy inverse d'IBM qui fait partie du framework Tivoli.
• [2] Tels que Bugtraq de Symantec, X-Force d'ISS ou la National Vulnerability Database (NVD) du NIST.
• [3] Il existe des outils d'administration graphiques pour Apache (comme NetLoony) mais ils ne sont pas encore largement utilisés.