Logo ETI Quitter la lecture facile

L’Actu de l’innovation

Les tests d’intrusion comme révélateurs de dysfonctionnements

Posté le par La rédaction dans Informatique et Numérique

Les tests d'intrusion ne servent pas uniquement à révéler des problèmes techniques. Parfois, ils font surgir des dysfonctionnements plus profonds. La preuve par l'exemple.

Les responsables chargés de maintenir la sécurité d’un système d’information (SI) disposent d’une gamme d’outils variés pour identifier les faiblesses potentielles. Parmi ceux-ci, les tests d’intrusion sont généralement utilisés de manière à relever les vulnérabilités purement techniques (mauvaise configuration, erreurs de développement, non application des correctifs…). Cependant, en regardant ces tests et leurs résultats sous un autre angle, il est possible, dans certains cas, d’en tirer des conclusions d’un niveau plus élevé qui peuvent servir de point d’entrée à des réflexions d’ordre plus général sur la sécurité du SI.Voici quelques exemples, tirés de cas rencontrés au cours d’audits réels, dont peuvent être déduits l’existence de problèmes de fond dans la sécurité d’un SI : au niveau de la conception (réseaux, architecture logicielle, développement d’applications) mais aussi dans la définition et l’application de la politique de sécurité.

Les problèmes de conception
Comme indiqué, les tests d’intrusion techniques (externes ou internes) peuvent mettre en évidence des problèmes de conception. La preuve, via ces trois exemples qui illustrent, chacun à leur niveau, ce cas de figure.

Au niveau architecture réseau
Au cours d’un test d’intrusion externe, un auditeur peut parvenir à passer des commandes sur une des machines frontales (par exemple un reverse proxy Web). L’auditeur cherche ensuite à cartographier les machines internes accessibles et à identifier les ressources sensibles. Dans l’exemple qui suit, l’auditeur exploite la méthode HTTP CONNECT sur le reverse proxy situé en frontal d’un service HTTPS (secure.site.fr) pour établir des connexions vers des serveurs du réseau interne: 
# openssl s_client -connect secure.site.fr:443CONNECTED(00000003)[…]CONNECT 192.168.0.10:80 HTTP/1.0HTTP/1.0 200 Connection establishedProxy-Agent: NetCache NetApp/5.6.2R2GET / HTTP/1.0HTTP/1.1 200 OK[…] Connexion SSL vers le port 443 du site secure.site.frEtablissement de la connexion Tentative de connexion vers le port 80 d’un serveur interne. Ici 192.168.0.10 La connexion avec le serveur est effective. L’attaquant peut donc effectuer des requêtes sur le port distant, au travers du reverse-proxy.
L’exemple précédent démontre la possibilité de se connecter au service HTTP (80/tcp) d’un serveur interne du réseau cible (192.168.0.10), au travers du reverse-proxy mal configuré. La page d’accueil retournée constitue une ressource interne de la société qui ne devrait en aucun cas être accessible depuis Internet. Ce serveur ne devrait pas être accessible depuis le reverse-proxy. Cela dénote un manque de cloisonnement dans la définition de l’architecture réseau. La mise en place de DMZ et de filtrage entre les différentes DMZ et le réseau local aurait permis d’éviter les intrusions par rebonds successifs depuis l’extérieur. Cette mesure vaut également pour contrer des intrusions depuis le réseau interne et spécifiquement depuis le LAN utilisateur.Remarque : en fonction de la configuration du reverse proxy, il peut être possible d’atteindre n’importe quel service (SMB, SSH, telnet…).

Au niveau développement logiciel
Dans le cadre d’un test d’intrusion sur une application Web, l’auditeur va chercher à vérifier le degré de liberté que possède un utilisateur dans les valeurs envoyées en paramètre à l’application. L’objectif est d’injecter des chaînes de caractères qui seront interprétées comme du code et exécutées comme tel :
  • soit côté serveur : injection de code dynamique (PHP/ASP/JSP), injection de code SQL (SQL Injection);
  • soit côté client : injection de JavaScript dans le navigateur client ou Cross-Site Scripting (XSS).
En fonction des résultats observés, l’auditeur pourra identifier des faiblesses au niveau du développement de l’application. Par exemple si le fait de passer une commande du type : http://www.site.com/rechercher.php?requete=

Posté le par La rédaction


Réagissez à cet article

Commentaire sans connexion

Pour déposer un commentaire en mode invité (sans créer de compte ou sans vous connecter), c’est ici.

Captcha

Connectez-vous

Vous avez déjà un compte ? Connectez-vous et retrouvez plus tard tous vos commentaires dans votre espace personnel.

INSCRIVEZ-VOUS
AUX NEWSLETTERS GRATUITES !