Gauntlt (“Be Mean to Your Code” - "Soyez méchant avec votre code") permet d'exécuter des tests de sécurité dans le pipeline de CI/CD. Plus précisément, Gauntlt peut être utilisé :

  • dans le Continuous Integration, en exécutant des Security Smoke Tests : ce sont des tests rapides, simples;
  • dans le Continuous Delivery, en automatisant des simulations d'attaque.

Si des tests échouent, l'équipe doit alors immédiatement corriger les problèmes relevés.

La mise en place de ces tests de sécurité doit se faire dans un flux distinct du pipeline utilisé par les développeurs, afin de ne pas bloquer leurs builds. En cas d'échecs des tests de sécurité, il est en effet nécessaire de passer en revue les résultats. Au terme de cette revue, le seuil de défaillance peut éventuellement être modifié pour éviter l'apparition de trop de faux-positifs.

Une fois tout cela stabilisé, vous pouvez intégrer ces tests dans le flux de build et rendre bloquant la build si ce seuil de défaillance est dépassé.

Gauntlt repose sur Cucumber, un framework de test BDD (Behavior-driven development) basé sur Ruby. L'utilisation de BDD simplifie ainsi beaucoup l'écriture des tests de sécurité et de contrôles de l'application et de sa configuration.

Il contient des adaptateurs d'attaque masque la technique nécessaire pour utiliser ces outils de PenTest. Voici des exemples de fichiers d'attaque :

  • Vérification de la configuration SSL (à l'aide de sslyze),
  • Vérification de la configuration réseau (à l'aide de nmap),
  • Test des vulnérabilités d'injection SQL (à l'aide de sqlmap),
  • Exécution d'attaques d'applications Web simples (à l'aide de curl),
  • Recherche de vulnérabilités courantes (à l'aide d'arachni, de dirb et garmr),
  • Vérification de vulnérabilités spécifiques (exemple : Heartbleed).

Ces fichiers d'attaque sont fournis en exemple. Ils sont directement utilisables, après changement des arguments, mais vous pouvez les peronnaliser pour créer de nouvelles attaques.

Mais Gauntlt est très ouvert puisqu'il est impossible d'intégrer n'importe quel outil exécutable par ligne de commande.

Les fichiers d'attaque sont décrits dans un DSL (Domain Specific Language) Ruby, appelé Gherkin. Gherkin utilise la syntaxe suivante :

Given {préconditions}

When {execution des étapes de test}

Then {resultats attendus}

Chaque test renvoyant un résultat de réussite ou d'échec, il est simple d'intégrer ces tests dans un pipeline CI ou CD.

Prenons un exemple de fichier d'attaque. Ces fichiers ont un suffixe ".attack". Chaque fichier contient donc un ou plusieurs scénarios, chacun contenant plusieurs étapes Given / When / Then :

Feature: Description de l'attaque ou de la vérification

Background: Mise en place du contexte pour tous les scénarios

Scenario: Logique de l'attaque en format Given/When/Then

Given “tool” is installed

When I launch a “tool” attack with:

  “””

  Etapes

  “””

Then it should pass with/should contain/and should not contain:

  “””

  Résultats

  “”

Voici un exemple complet et réel, qui consiste à rechercher du XSS (cross site scripting) sur le site Web http://scanme.nmap.org (qui sert pour les tests de sécurité) avec l'outils arachni, intégré dans Gauntlt :

Feature: Look for cross site scripting (xss) using arachni against scanme.nmap.org



Scenario: Using arachni, look for cross site scripting and verify no issues are found

 Given "arachni" is installed

 And the following profile:

   | name        | value             |

   | url         | http://scanme.nmap.org    |

 When I launch an "arachni" attack with:

 """

 arachni --checks=xss --scope-directory-depth-limit=1 <url>

 """

 Then the output should contain "0 issues were detected."
 

Voyons maintenant comment installer Gauntlt. Nous allons voir deux méthodes. La première est la méthode classique, en utilisant le gestionnaire de package Gem de Ruby :

$ gem install gauntlt

Pour lancer une attaque, il suffit de lancer cette commande :

$ gauntlt attacks/my_attack.attack

Pour lancer toutes les attaques, la syntaxe est simplifiée :

$ gauntlt

Vous pouvez aussi afficher facilement les étapes utilisées dans les attaques :

$ gauntlt --steps

Pour obtenir les attaques prédéfinies, qui ne restent plus qu'à être personnalisées, téléchargez le code source :

git clone https://github.com/gauntlt/gauntlt
cd gauntlt/examples

Et pour obtenir la liste des attaques définies :

$ gauntlt --list

La seconde méthode est d'utiliser Docker. Commencez par cloner le repository https://github.com/gauntlt/gauntlt-docker :

git clone https://github.com/gauntlt/gauntlt-docker.git

Ensuite, construisez le container Docker :

$ make build

Pour vérifier que tout a bien fonctionné, il suffit d'entrer cette commande :

$ make help

Vous devez ensuite copier un Stub binaire dans le path de votre système. Pour cela, lancez cette commande :

$ make install-stub

Vérifions que cette opération a bien fonctionné en lançant cette commande :

$ gauntlt-docker --help

Maintenant, vous pouvez créer les fichiers d'attaque dans un répertoire, par exemple le sous-répertoire ./attacks. Pour lancer un fichier d'attaque qui s'appelerait ./attacks/xss.attack, entrez cette commande :

$ gauntlt-docker ./examples/xss.attack

Cela permet de lancer les fichiers d'attaque locaux directement depuis le container Docker.

Si vous en avez besoin, vous pouvez aussi exécuter Docker en mode interactif, pour avoir accès à la ligne de commande du container Docker :

$ make interactive

Nous avons vu au début de l'article que nous pouvions répartir les tests de sécurité sur le CI et sur le CD. Dans les fichiers d'attaque se trouve des annotations qui indiquent si le test est rapide ou lent. Plus précisément, si le test est lent, une annotation @slow y figure en début de fichier. En l'absence de cette annotation, le test est rapide.

L'idée est donc de lancer les attaques lentes dans le pipeline de Continuous Delivery comme ceci :

$ gauntlt --tags @slow

Et de lancer les autres attaques, donc les rapides, dans le pipeline de Continuous Integration :

$ gauntlt --tags ~@slow

La dernière étape est donc d'intégrer ces tests BDD dans votre pipeline de Continuous Integration et de Continuous Delivery. Nous ne parlons pas de la manière de faire pour arrêter la build si les tests échouent.

Site officiel de Gauntlt : http://gauntlt.org/index.html