Les tests d'intrusions ont comme différence avec le Hacking "in the Wild" qu'ils se font avec l'accord du client qui peut soumettre ses conditions aux pentesters. Ses conditions peuvent toujours être discutées quand elles risquent de nuire à la qualité du pentest mais si il y en a bien une avec laquelle on ne badine pas, c'est la disponibilité de la production.

Ceci est d'autant plus vrai lorsque les composants du SI audités sont des serveurs critiques. La liste de "bavures" possibles pouvant nuire aux clients est assez longue voir le billet Plantages et blocages en tout genre.

Dans la majorité des cas, ce genre de soucis est du au pentester qui ne maîtrise pas suffisament ses outils ; il a voulu jouer au bourrin et ça a planté. A sa décharge, disons aussi que le pentester doit souvent aller vite (Comprends moi jeune pentester, on a laché quelques jours pour remporter cet appel d'offre) et l'utilisation de certains outils automatisés peut éviter certains tests fastidieux.

Bref ... vous comprenez bien qu'un pentest sur la production est limité dans les tests. Cependant, il peut être intéressant pour un client de savoir qu'un service "fait maison" peut être sujet à un déni de service ou à une exécution de code avec un buffer overflow.

Alors comment faire pour détecter ce genre de vulnérabilités sans perturber la production? Comment laisser le pentester faire mumuse avec des outils parfois un peu bourrin sans pour autant risquer de déclencher une tempête de mails et d'escalade de responsabilités parce qu'un serveur critique vient de planter ?

La solution est simple, réaliser les tests sur des environnments similaires à la production mais qui ont l'avantage de pouvoir planter sans activer l'alerte rouge! Les entreprises disposent souvent de ce type d'environnments.

Voici les plus classiques:

  • Environnement de production : C'est l'architecture qu'utilise les utilisateurs finaux dans le travail quotidien.

  • Environnement de développement : Il est utilisé par les développeurs pour développer, tester et débugger une application.

  • Environnement de recette: Une fois le développement figé, il n'est pas question de le passer directement en production. C'est là qu'intervient l'environnement de recette. Ce dernier va servir à valider par une batterie de tests que les nouveautés de l'application fonctionnent correctement avant de les déployer sur la version de production.

Donc sur le papier tout est OK. On fait le pentest dans un environnement similaire à la prod (isoprod) mais moins critique. Il n'y aura à priori pas de problèmes. Dans la pratique c'est une autre histoire.

Voici donc les avantages et inconvénients des environnements de production et de leur sosies. Il faut garder à l'idée que quel que soit l'environement audité, le but est de trouver des vulnérabilités suceptibles d'impacter aussi la production (les entreprises n'accordent souvent pas beaucoup d'intérêt à la sécurité des environnements de dev ...).

L'environnement de développement

C'est peut être l'environnement le plus trompeur. En effet, côté possibilité de tests, à peu près tout est permis. En revanche niveau similarité avec la production et bien c'est pas gagné. Il ne sera pas rare de trouver des vulnérabilités existantes en dev et pas en production :-( .

Ci-dessous quelques inconvénients des tests en environement de développement:

  • Les configurations des serveurs sont souvent plus laxistes ou plus expérimentales qu'en production. On retrouve énormément de services ouverts sur les serveurs, des mots de passe par défaut, des versions d'applications obsolètes, des configurations expérimentales en cours de test.
  • Des fonctionnalités applicatives que l'on retrouve en production peuvent être inexistantes, différentes ou non utilisables. Y'a Ronald qui a testé une modification avant que vous arriviez et depuis ça marche plus ...
  • Les comptes d'accès sont souvent gérés de manière différentes. Pour gagner du temps en test, les développeurs sont assez adeptes du mot de passe équivalement à l'identifiant.
  • Les permissions des utilisateurs applicatives, systèmes ou en bases sont différentes. J'ai accès aux options d'administrations avec le compte censé être en lecture seule, c'est normal ??
  • Les serveurs sont mutualisés. Faire planter l'environnement dans lequel vous travaillez pourra également faire planter d'autres environnements de dev en cours d'utilisation.
  • L'étanchéité des environnments peut être douteuse. Un site Web de test pourra facilement renvoyé sur le site en production à cause d'un lien qui traine. Si on ne s'en aperçoit pas ça peut vite mal tourné.

Voici autant de points qui amèneront à une perte de temps assez conséquente ... le pentester consciencieux cherchera souvent à vérifier l'existence en production des vulnérabilités identifiées précédemment.

Ceci l'amenera à un premier interlocuteur ne maîtrisant pas forcémment le contexte technique qui le renverra vers un développeur, qui le renverra vers le responsable de l'infra de dev, qui lui même enverra un mail au responsable de l'infrastructure de production, qui demandera au RSSI l'autorisation de vous communiquer des informations confidentielles sur la production .... qui répondra peut-être ou se manifestera après la remise du rapport ...

Petit bonus sympa cette fois, il est parfois possible de valider des vulnérabilités de l'environnement de dev n'existant pas sur la prod dans le cas ou "par exemple", la base de données de dev est une copie récente de la base de production. A ce moment vous pouvez invoquer, du haut de votre statut d'expert en paranoïa, le risque de perte de confidentialité dû aux 200 comptes faibles présents sur la base de données de dev.

L'environnement de recette

Cet environnement est intéressant. Il s'agit en effet d'un environnement de validation avant mise en production. Les responsables du développement feront souvent attention à être isoprod un maximum afin d'éviter les mauvaises surprises.

Des différences peuvent toutefois existées ; elles se situent rarement au niveau des configurations serveurs, mais plutôt sur les permissions, les comptes par défaut, et les fonctionnalités applicatives. Ces différences peuvent amener à des revérifications en production (coûteux en temps).

Enfin, il arrive que l'environement de recette ne soit pas disponible pour cause de futur mise en production ... et là et bien on repart sur l'environnement de dev ... damnation !

L'environnement de production

Alors là on touche à un point sensible ... production comme productivité ... productivité comme business ... business comme thunes ... alors là pas de blagues, les clients peuvent vite être nerveux sur ce point.

"Notre application de minitel (lol) est extrêmement critique", entendez par là "Si ça tombe, je suis dans la merde, donc vous êtes dans la merde".

Les responsables de l'application, de l'exploitation, de l'activité, du support ... autant de personnes qui passeront des mauvaises journées voire de mauvaises fin de mois si l'application venait à planter. Ils n'hésiteront pas à vous transmettre ce stress si vous veniez à faire une boulette sur cet environnement.

Par la même occasion, la réput' de votre boîte pourrait aussi en patir et votre boss réflechirait à deux fois avant de vous envoyer sur un test d'intrusion critique (donc intéressant).

Alors là forcemment on marche sur des oeufs ... ninja style ... on se fait discret, on évite les tests automatiques et on fait surtout confiance aux outils que l'on maîtrise bien. Ces contraintes rendent le boulot forcément plus risqué, et les tests seront moins exhaustifs. En revanche, une intrusion réussi sur la prod c'est tout de suite plus joussif (comparé a owner une base de données non confidentielles dans un environnement de dev) et plus démonstratif pour le client.