Ostorlab passe en open source 🎊

C'est l'annonce la plus importante depuis la création d'Ostorlab, et celle que je suis particulièrement enthousiaste de faire.

Ostorlab passe en open source : nous publions notre moteur de scan, nos détecteurs de vulnérabilités et nos analyseurs.

Au cœur d'Ostorlab se trouve un moteur très modulaire qui rend la composition de détecteurs de vulnérabilités plaisante.

Pour renforcer cette modularité, nous publions un store livré avec des outils de sécurité open source populaires, comme Nmap, OpenVAS, Tsunami, Nuclei, et bien d'autres à venir.

Avec cette nouvelle version, nous ajoutons la prise en charge du scan de tout : applications mobiles, applications web, adresses IP et conteneurs, avec pour objectif la détection de presque tout, de la découverte de simples problèmes de configuration et la recherche de secrets jusqu'à l'exécution d'un environnement d'analyse dynamique complet.

Se lancer est aussi simple qu'une commande pour installer et une commande pour exécuter :

pip install -U ostorlab 
oxo scan run --install \
 --agent agent/ostorlab/nmap --agent agent/ostorlab/openvas --agent agent/ostorlab/tsunami --agent agent/ostorlab/nuclei \
 ip 8.8.8.8

Mais avant de détailler la nouvelle plateforme et les fonctionnalités qu'elle offre, laissez-moi commencer par ce qui nous a conduits à ouvrir le code de la plateforme.

L'histoire derrière cette décision

Ostorlab a été une plateforme tournée vers la communauté dès ses débuts. Elle a été créée comme une plateforme en ligne gratuite qui permettait de scanner des applications mobiles sans limite. Il suffisait d'envoyer son application ou de la sélectionner dans le store, et c'était tout.

Cette décision est portée par la conviction profonde que la sécurité ne doit pas être réservée aux grandes entreprises qui ont les moyens de payer des outils coûteux.

Ouvrir le code de la plateforme en est le prolongement naturel, que nous avons retardé parce que nous voulions partager quelque chose que d'autres puissent facilement utiliser, adopter, expérimenter et auquel ils puissent contribuer.

La seconde raison de cette ouverture est une déception générale face à la direction prise par l'industrie de la sécurité. Les scanners de sécurité historiques, et même les plateformes plus récentes, sont tous orientés entreprise, avec une tendance croissante à l'hyper-spécialisation.

Si vous gérez aujourd'hui un programme de scan de vulnérabilités, même à très petite échelle, vous avez besoin d'une pléthore d'outils pour obtenir une couverture suffisante. Un outil pour les applications web, les infrastructures réseau, les API web, les projets cloud, les politiques IAM, les conteneurs, le code source, les dépendances, les secrets, et la liste s'allonge encore et encore.

Le problème est que ces outils ne sont pas interopérables, reposent sur des concepts et une terminologie différents et utilisent des niveaux de risque différents.

D'un autre côté, la scène de la sécurité open source est dynamique, avec plusieurs excellents projets. Sa sérieuse faiblesse est la courte durée de vie de ces outils, souvent conçus pour quelques présentations en conférence avant de tomber en déshérence. Il existe bien sûr des exceptions notables comme le vénérable Nmap ou l'étonnant sqlmap, mais ce sont des exceptions, pas la règle.

Qu'est-ce que cela implique ?

Alors, quel rôle joue Ostorlab dans cette réalité et comment essaie-t-il d'aider ?

D'abord, Ostorlab fait fonctionner les outils ensemble de façon transparente en fournissant un langage commun unique : quel que soit le langage de programmation dans lequel ils sont écrits, quelle que soit la plateforme sur laquelle ils s'exécutent, tous parlent le même jargon pour servir ensemble un objectif unique, trouver des vulnérabilités.

Concrètement, Ostorlab encapsule les outils dans des agents qui communiquent de façon asynchrone par des messages distribués. Ces messages représentent une taxonomie de sécurité partagée sur laquelle les outils peuvent s'accorder. Les messages sont fortement typés, compacts, binaires et suivent une structure hiérarchique.

Par exemple, pour scanner une application web, la taxonomie partagée comprendrait :

• URL: pour l'exploration et la recherche par force brute d'URL ;
• Request/Response : pour extraire des empreintes et rechercher dans les réponses des motifs, comme des secrets codés en dur ;
• Fingerprint : pour lister les bibliothèques, services et stacks technologiques et les confronter aux vulnérabilités connues ;
• Injection Endpoint : pour faire du fuzzing à la recherche de vulnérabilités comme XSS, injection SQL, XXE …

Cette approche rend :

• Le chaînage des outils automatique ;
• Le remplacement des outils, voire l'utilisation de plusieurs d'entre eux, sans effort ;
• Leur extension standardisée.

Cette approche a aussi l'avantage de rendre le scan scalable : les outils peuvent s'exécuter sur plusieurs machines sans aucune modification.

En plus de fournir la plateforme qui fait collaborer les outils, Ostorlab est livré avec un nouveau store pour accéder facilement à des outils de sécurité packagés pour fonctionner ensemble de façon transparente.

En coulisses, les outils ne sont rien d'autre que des conteneurs, ce qui permet de prendre en charge des configurations complexes tout en restant dans le standard de l'industrie.

Le store fournit aussi un outil de visualisation pour composer des agents ensemble afin d'effectuer des tâches d'analyse complexes, de la recherche de domaines par force brute à la capture d'écran de pages ou à l'extraction de secrets. La visualisation peut ensuite générer un fichier de définition YAML qui peut être exécuté sur votre actif cible avec une seule commande.

En plus de la CLI pour lancer des scans, Ostorlab est livré avec un SDK pour construire vos propres agents. Le SDK prend en charge les cas d'usage standard avec peu de code, tout en fournissant de puissantes API pour construire des agents complexes capables de passer à l'échelle sur plusieurs machines, comme la limitation de QPS, le verrouillage distribué, la persistance d'état partagé, ainsi que le traçage et les métriques distribués…

Un élément essentiel qui facilite l'ajout et la publication de nouveaux outils est le build automatisé et l'intégration avec les dépôts Git. Les mises à jour et les changements sont automatiquement récupérés depuis le dépôt de l'agent. De nouvelles versions sont construites et partagées dès qu'un nouveau tag de version est ajouté, et le store prend en charge toutes les contraintes de construction et de livraison des nouvelles versions.

Que pouvez-vous faire ?

Prenez-le en main et partagez vos retours. Signalez les bugs, envoyez vos suggestions et vos commentaires. Nous aimerions beaucoup vous lire et en savoir plus sur la façon dont nous pouvons améliorer l'outil.

La véritable puissance de la plateforme se révèle à mesure que davantage d'agents sont construits et partagés. Publiez votre outil préféré et partagez-le dans le store, ou soumettez une demande de fonctionnalité pour qu'il soit ajouté.

Prochaines étapes ?

Cette version n'est qu'un début : de nombreuses autres fonctionnalités et mises à jour sont déjà en route.

Parmi les mises à jour à venir, on compte l'ajout d'une version managée qui permet de lancer un scan sur n'importe quel actif dans un environnement managé. L'environnement managé s'appuie sur les capacités existantes de la plateforme Ostorlab, comme la persistance des données, l'historique des scans, la montée en charge automatique, l'intégration aux systèmes de tickets, la prise en charge de plusieurs appareils (iOS, macOS, …) et l'accès à l'environnement d'analyse.

Les prochaines versions se concentreront aussi sur l'ajout d'actifs cibles et d'outils plus spécialisés. Ces versions comprendront l'ouverture du code d'autres de nos détecteurs internes auxquels nous tenons, comme notre vénérable crawler, notre scanner XSS, le moteur de taint analysis d'Ostorlab, notre détecteur de secrets et notre fuzzer web en boîte noire.

Enfin, nous travaillons à soutenir les mainteneurs open source en partageant une part importante des revenus d'Ostorlab.

Ces revenus tiendront compte de facteurs clés pour promouvoir des outils de meilleure qualité, notamment :

• La popularité de l'outil ;
• La contribution de l'outil à la détection de vulnérabilités (vrais positifs) ;
• Le taux de faux positifs ;
• La consommation de ressources (CPU, mémoire, taille sur disque).

Nous espérons ainsi permettre aux mainteneurs d'outils de disposer d'un moyen concret de continuer à soutenir ces outils et à les améliorer.