Le moteur de détection d'Ostorlab

La technologie de détection de vulnérabilités d'Ostorlab repose sur 3 composants clés : un moteur d'analyse statique, un moteur d'analyse dynamique et comportementale, et un moteur d'analyse backend.

Le moteur d'analyse statique remplit les fonctions suivantes :

• Vérifications de configuration : par exemple, vérifier que l'application désactive le mode debug, dispose de paramètres de framework adaptés à la production, comme une liste blanche Apache Cordova sécurisée, ou d'une politique de sécurité réseau sécurisée.

• Vérifications des dépendances : consiste à identifier les dépendances et leurs versions, soit grâce aux fichiers de version que certains frameworks fournissent aimablement, soit en inspectant le binaire à la recherche d'identifiants spécifiques conçus à la main par l'équipe Ostorlab. Ces dépendances sont analysées à la recherche de vulnérabilités connues.

• Analyse de taint : l'une des fonctionnalités avancées et uniques d'Ostorlab est un moteur d'analyse de taint très performant et de qualité production. Le moteur couvre un ensemble de technologies, comme le bytecode Android, et peut mener l'analyse sur l'ensemble de l'application pour dénicher des vulnérabilités cachées derrière des dizaines d'appels de méthodes. Ces vulnérabilités comprennent l'utilisation d'une cryptographie non sécurisée, comme le mode de bloc ECB ou l'algorithme DES, les injections SQL exposées via un schéma d'URL ou un content provider, et l'exécution de commandes exposée via un service ou un content provider.

Le moteur d'analyse dynamique effectue plusieurs actions :

• Préparation de l'application : reconditionne l'application pour l'analyse, ce qui comprend l'activation du mode debug, la nouvelle signature de l'application et la désactivation des vérifications problématiques qui peuvent gêner l'analyse.

• Préparation de l'appareil : installe l'application sur un appareil réel et configure l'application pour qu'elle attende un débogueur, ce qui s'applique à Android comme à iOS. Ostorlab s'appuie sur des appareils réels pour les performances et la reproductibilité.

• Analyse via les protocoles de débogage : instrumente l'application à l'aide de protocoles de débogage comme JDWP ou LLDB. Ostorlab maintient sa propre pile pour pouvoir interagir à bas niveau avec l'application. L'instrumentation consiste à placer des traces sur des API stratégiques, appelées sources (d'entrées non fiables) et sinks (susceptibles de conduire à des vulnérabilités). Ostorlab s'appuie sur les protocoles de débogage pour l'analyse, plutôt que sur une analyse en mémoire, pour des raisons de stabilité et d'extensibilité. Les protocoles de débogage sont moins risqués que la manipulation de la mémoire pour intercepter les API par hooking, et ils sont stables d'une version d'OS à l'autre. Les protocoles de débogage ont un coût en performances, car ils ralentissent l'application, un coût qui reste acceptable dans le contexte de la détection de vulnérabilités. L'extensibilité vient des fonctionnalités que fournissent les débogueurs, comme la compréhension de l'organisation de la mémoire de Swift ou d'Objective C, qui permet d'écrire un code d'instrumentation clair et concis.

• Traçage et analyse : les traces sont collectées et analysées à la volée pour détecter des schémas vulnérables connus, par exemple l'appel d'une API cryptographique avec une méthode non sécurisée, ou une clé codée en dur. Cette étape collecte aussi le trafic en s'accrochant directement aux API TLS/SSL et Socket. Cette approche contourne le SSL Pinning. Le trafic collecté est ensuite envoyé au moteur d'analyse backend ; voir un exemple de rapport ici.

• Monkey Testing : un monkey de test commence à interagir avec l'application, soit à l'aide d'un ensemble d'heuristiques pour détecter les pages d'authentification, soit en cliquant au hasard dans l'application. Dans le cas d'interactions complexes avec l'interface, des règles d'automatisation de l'interface sont écrites en BDD pour scripter l'interaction.

Le moteur d'analyse backend s'appuie sur l'analyse dynamique pour collecter le trafic, puis effectue les actions suivantes :

• Détection passive : elle repose sur l'analyse des attributs des requêtes et des réponses, comme le corps et les en-têtes, pour détecter des vulnérabilités comme des attributs de cookie manquants, un CORS non sécurisé, des composants vulnérables à partir de versions déduites, etc.

• Détection active : en tant que scanner de sécurité orienté mobile d'abord, Ostorlab s'attache à comprendre plusieurs protocoles de sérialisation couramment utilisés dans les applications mobiles, comme GraphQL ou Protobuf. Ces protocoles de sérialisation sont soumis à du fuzzing pour détecter des vulnérabilités comme l'injection SQL, XXE, l'injection de template, etc.

Ces étapes ne sont pas exécutées séquentiellement, car derrière chacune d'elles se trouvent plusieurs micro-agents spécialisés dans une tâche précise. Ces agents communiquent via un bus partagé et reposent sur une architecture événementielle.

Au cours de chacune de ces analyses, des artefacts sont collectés, comme des captures d'écran de l'application, les logs de l'appareil et le code source décompilé.

Les trois moteurs d'analyse offrent une couverture complète de la surface d'attaque de l'application et compensent les limites propres à chaque analyse prise isolément. Par exemple, l'analyse statique offre une excellente couverture de la surface d'attaque de l'application, mais peut en même temps produire des faux positifs en raison de chemins d'exécution complexes ou de code mort. L'analyse dynamique produit beaucoup moins de faux positifs, car elle observe le comportement réel, mais elle ne peut pas garantir une couverture complète de la surface de l'application, et l'analyse backend détecte les vulnérabilités propres au backend, qui, dans la plupart des cas, est dédié à l'application mobile.