Test d’intrusion SaaS

Les SaaS (software as a service) sont désormais devenus un modèle économique incontournable pour utiliser des services en ligne. Chaque jour, des millions de consommateurs font confiance à ceux-ci pour gérer leurs informations les plus sensibles.

Face au nombre d’attaques croissant et aux nouvelles législations (RGPD, DORA, NIS2), les entreprises sont désormais contraintes d’implémenter les tests d’intrusion comme partie intégrante du cycle de développement de leurs SaaS afin de protéger les informations sensibles de leurs utilisateurs.

Objectifs d’une prestation de test d’intrusion SaaS

Les tests d’intrusion visent plusieurs objectifs :

• Identifier, illustrer et valider la présence de vulnérabilités en tentant de les exploiter réellement: l’exploitation effective d’une vulnérabilité permettant d’en constater l’impact technique direct (rebonds possibles, droits effectifs obtenus, journalisation, accès à des données sensibles, etc.) ;
• Détecter à contrario l’impossibilité d’exploitation des failles existantes liée à des spécificités qui ne seraient pas détectées lors d’un audit de configuration.
• Détection d’un contrôle d’accès déficient lié à un bug d’implémentation ;
• Découverte de comptes de services actifs et masqués depuis l’interface d’administration, donc de facto indétectable par d’autres moyens ;
• Validation en situation des différentes entrées utilisateurs afin de détecter les mauvais traitements et complètent la démarche d’analyse du code source d’un applicatif dans une approche plus exhaustive et performante ;
• Validation de la segmentation entre les instances utilisateur.
• etc.

Phases des tests d’intrusion

En fonction du contexte de la mission, nos auditeurs peuvent mener les tests d’intrusion au travers d’une ou plusieurs phases :

• Phase boîte noire. L’auditeur ne dispose d’aucune autre information que les adresses IP et URL associées à la cible auditée. Cette phase est généralement précédée de la découverte d’informations et l’identification de la cible par interrogation des services DNS, par le balayage des ports ouverts, par la découverte de la présence d’équipements de filtrage, etc. ;
• Phase boîte grise. Les auditeurs disposent des connaissances d’un utilisateur standard du système d’information (authentification légitime, privilèges minimaux, etc.). Les identifiants peuvent appartenir à des profils d’utilisateurs différents afin de tester des niveaux de privilèges distincts ;
• Phase boîte blanche. Les auditeurs disposent du maximum d’informations techniques (architecture, code source, contacts téléphoniques, identifiants, etc.) avant de démarrer l’analyse. Ils ont également accès à des contacts techniques liés à la cible.

Si plusieurs de ces prestations sont effectuées, il est recommandé de préserver l’ordre d’exécution décrit ci-dessus.

OSINT

L’OSINT désigne la phase de renseignement lors de laquelle les auditeurs collectent des informations sur l’entreprise et sur ses actifs. À l’aide uniquement d’informations publiques et disponibles librement, les auditeurs vont rassembler le plus de données possibles sur l’entreprise qui pourront les aider plus tard lors des tests (adresses mails, URL, nom de projet, nom de solution, technologies utilisées, etc.).

Il s’agit de délimiter le périmètre exposé depuis internet :

Voir nos prestations d’OSINT

Tests d’intrusion automatisés (anonymes et authentifiés)

Il s’agit de détecter des vulnérabilités spécifiques aux composants identifiés ou résultant d’une erreur de configuration ou d’un défaut de contrôle d’accès.

Sur cette base, MA Cyber tentera d’exploiter des vulnérabilités découvertes, en vue :

• D’élever les privilèges de l’auditeur sur l’application afin d’obtenir d’autres accès logiques qui permettront la poursuite de l’intrusion ;
• D’obtenir des informations sensibles. Les informations obtenues peuvent servir à exploiter d’autres vulnérabilités ou être utilisées telles quelles, soit comme preuve d’intrusion, soit comme illustration de la vulnérabilité détectée.

Dans un premier temps, nous effectuons cette phase de manière automatisée en utilisant des outils gratuits et payants tels que Nessus Tenable, Nikto, OWASP ZAP, Burp, Acunetix, etc.

Ces derniers permettent d’obtenir rapidement les éléments suivants :

• L’identification de fichiers / dossiers présents par défaut ;
• La détection de comptes et mots de passe par défaut ;
• La détection de défauts de configuration ;
• Les défauts de filtrage des entrées utilisateurs lors d’applications type web ou client lourd (injection XSS, injection SQL, CSRF, etc.).

Tests d’intrusion manuels (anonymes et authentifiés)

Dans un second temps, cette phase est réalisée manuellement. C’est la phase la plus importante car c’est celle qui met à contribution l’expérience et l’expertise de nos auditeurs. En effet, les outils automatisés ne peuvent pas détecter certaines vulnérabilités, et les auditeurs doivent les identifier manuellement.

Cette phase permet de tester, entre autres :

• Les défauts de logique métier ;
• Les contrôles d’accès défectueux ;
• L’injection de contenu lors de scénarios complexes ;
• etc.

 Cette phase manuelle peut se traduire par :

•  L’exécution de commandes à distance ;
•  L’extraction d’informations sensibles ;
•  L’altération de traces, ou d’informations (uniquement sur des données de tests) ;
•  Le contournement de la logique métier ;
•  etc.
  

Méthodologie

Afin de réaliser leurs tests d’intrusion SaaS, nos auditeurs utilisent des cadres méthodologiques reconnus comme l’OSSTMM, ou le Web Security Testing Guide de l’OWASP, celui-ci étant un standard reconnu et éprouvé. Néanmoins, bien que ces méthodologies cadrent les différentes actions de l’auditeur, c’est le contexte qui va orienter l’enchaînement de ces actions.

Notre approche va au-delà d’une analyse classique et vous permet d’identifier des vulnérabilités complexes présentes dans les applications modernes.

Reconnaissance

• Énumération des ports ouverts sur la machine et des services associés.
• Recherche de sous domaines associés au périmètre de l’audit (API déportée, service interconnecté, instance clients, etc.).
• Énumération des technologies composant la ou les applications Web.
• Récupération des différentes sources d’information utiles a l’audit (robots.txt, sitemap, etc.)
• Recherche d’identifiants ayant fuité publiquement.

Énumération des mauvaises configuration serveur

• Recherche d’en-têtes de sécurité mal configurées ou absentes (HSTS, CSP, Attributs de cookies manquants, etc.).
• Analyse du certificat HTTPS utilisé par l’application (recherche de protocoles et algorithme dépréciés).
• Analyse de la bonne configuration des services exposés (SSH, FTP, MySQL etc.) et de leur version.

Cartographie de l’application

• Énumération des différentes fonctionnalités de l’application et identification des fonctionnalités clés (trésor IT).
• Recherche et identification de fonctionnalités susceptibles d’être des vecteurs d’attaque importants (téléversement de fichier, connexion utilisateur, soumission de formulaires, API exposée, etc.).
• Identification du scénario de fonctionnement logique de l’application (business logic).
• Recherche de pages ou sections nécessitant un niveau d’autorisation particulier.

Audit des fonctionnalités

• Audit des fonctionnalités d’accès a l’application (tentative d’attaque par force brute sur le formulaire de connexion, recherche de mauvaises configurations OAUTH, audit de la fonctionnalité d’inscription etc.).
• Audit des paramètres GET (XSS réfléchie, OpenRedirect, SSTI, SQLi, etc.).
• Audit des champs utilisateurs (tentative d’injection XSS, SQLi, SSTI, HTML, CSS, etc.).
• Audit des fonctionnalité de téléversement de fichiers (contournement des limitations, téléversement de fichier interprété comme du code par l’application, etc.)
• Tests d’élévation de privilèges (modification arbitraire des rôles utilisateur, etc.).
• Tests de prise de contrôle de compte utilisateur (détournement de fonctionnalité de réinitialisation de mot de passe, modification arbitraire d’un autre utilisateur, etc.).
• Tentative de détournement abusif des fonctionnalités (envoi de mail arbitraire au travers d’un service de notification, etc.).
• Test de cloisonnement des données traitées par l’application (tentative de lecture, modification, suppression de données n’appartenant pas a l’utilisateur).
• Recherche de mauvaises configurations exposant des données ou informations critiques (dossier .git présent dans la webroot, fichiers de sauvegarde, message d’erreurs non gérés, etc.).
• Recherche d’API exposées et de documentation associée.
• Audit de l’API (contrôle de la segmentation des données et des privilèges, tentatives d’injection).

Focus SaaS multi-instances

• Tests de cloisonnement entre les instances clients (réutilisation d’identifiants entre différentes instances, tentative d’accès a des données présente au sein d’une autre instance, etc.)
• Recherche d’erreur de conception dans le système de paiement (environnement de test, manipulation de réponse, contournement de paiement, etc.)
• Test de contournement de la fonctionnalité SSO (Single Sign-On) (Tentative de connexion depuis une organisation exterieure, tentative d’énumération des utilisateurs, etc.)