Test d’intrusion externe

Les applications web sont incontournables depuis maintenant des décennies. De nos jours, chaque entreprise dispose d’au moins d’une application web, qu’elle soit utilisée pour créer une présence en ligne (site vitrine, WordPress, etc.) ou pour proposer des services métiers (e-commerce, services SaaS, etc.).

Les services web font partie des services les plus exploités par les pirates informatiques. Par conséquent, chaque service web exposé est une porte d’entrée potentielle pour un attaquant. En cas de présence de vulnérabilités critiques, l’attaquant pourrait aller jusqu’à prendre le contrôle de serveur(s) web ou même rebondir sur l’infrastructure interne, accédant de fait à des données confidentielles. De plus, les sites étant disponibles directement depuis internet, les attaquants n’ont besoin d’aucun pré-requis et peuvent facilement tenter des attaques opportunistes aidé d’un sentiment d’anonymat.

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

Objectifs d’une prestation de test d’intrusion externe

Les tests d’intrusion visent plusieurs objectifs :

• Évaluer la quantité et la précision des informations disponibles en ligne sur l’entreprise (OSINT, fuite de données) ;
• Recenser tous les actifs de votre entreprise disponibles en ligne (actifs non inventoriés, applications et services) ;
• 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, 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.

En complément d’un audit de configuration Cloud, ils permettent de découvrir des failles non visibles au seul moyen d’un audit de code ou 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 ;
• etc.

En complément d’un audit de code source d’un applicatif, ils permettent de valider en situation les différentes entrées utilisateurs afin de détecter les mauvais traitements dans une approche plus exhaustive et performante.

Méthodologie

Afin de réaliser leurs tests d’intrusion externe, nos auditeurs utilisent comme cadre méthodologique les frameworks de l’OWASP et de l’OSSTMM. Nos auditeurs utilisent généralement le Web Security Testing Guide de l’OWASP comme base, 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.

L’auditeur va au fur et à mesure fermer les voies n’offrant que peu de perspectives et se concentrer sur les vulnérabilités identifiées pour tenter de s’infiltrer sur les systèmes cibles.

Pour ce faire, il dispose d’une batterie d’outils regroupés en deux catégories :

• La première contient les outils destinés à « collecter » les informations techniques accessibles via le réseau ;
• La seconde rassemble les outils destinés à « exploiter » des failles.

Cette exploitation peut signifier :

• Obtenir plus d’informations techniques (version des produits, code source d’une application web, organisation du système de fichiers, emplacement des données métier, base de comptes et/ou de mots de passe) ;
• Accéder à des informations métier (accès à une application, des flux ou des fichiers) ;
• Accéder et même contrôler le système ou l’équipement.

Le schéma ci-dessous synthétise la démarche.

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.