Pentest (test d'intrusion)

Quelques chiffres (En constante augmentation)

• Une entreprise française sur 2 est victime d'une cyberattaque
• 287 jours en moyenne sont nécessaire aux équipes de sécurité pour identifier une fuite de données
• Augmentation de 50% en 2021 comparé à 2020, avec un pic en décembre, principalement du à l'exploitation de la faille Log4j
• Plus de 450,000 nouveaux cas de malware sont découverts chaque jour.
• Parmi les victimes de ransomware, 32% paient la rançon mais seulement 65% des données sont récupérées
• 2 attaques par jour contre les établissements de santé en 2021
• Le coût moyen d’une donnée volée s’élève à 144€ (ex: Données médicales -> 200€ / Carte bancaire -> 1€)

Raisons pour réaliser un pentest:

• Etre accompagné par un professionnel
• Apporter la preuve que la solution (application, site internet, hebergement, etc ...) est sécurisée
• Preparation d'une nouvelle certification ou renouvellement (ISO27001, SOC2, PCI-DSS, Critères communs …)
• Conformité réglementaire (LPM/NIS, DORA,reglementation du secteur)
• Contribue à valider la mise en production d'une application
• Sensibiliser ou tester ses équipes/utilisateurs

Presentation et méthodologie

• Pentest ou test d'intrusion est une technique de piratage éthique consistant à tester les vulnérabilités d’un système informatique, d’une application ou d’un site web en détectant les failles susceptibles d’être exploitées par un hacker ou un logiciel malveillant.
• Il se materialise généralement par un rapport final à plusieurs niveaux de lecture (management, opérationnel)
• Peut être réalisé de manière automatique ou manuellement par une société externe (ou équipe interne)

Difference entre un test d'intrusion et un audit de sécurité ?

Objectifs

• Lister un ensemble d’informations, trouvées d’une manière ou d’une autre, et qui peuvent être sensibles ou critiques
• Dresser une liste des vulnérabilités ou faiblesses du système de sécurité pouvant être exploitées
• Démontrer qu’un attaquant potentiel est en capacité de trouver des vulnérabilités et de les exploiter pour s’introduire dans le système d’information.
• Tester l’efficacité des systèmes de détection d’intrusion et la réactivité de l’équipe de sécurité, et parfois des utilisateurs (social engineering)
• Effectuer un reporting et une présentation finale de ses découvertes au client
• Donner des pistes et conseiller sur les méthodes de résolution et de correction des vulnérabilités découvertes.

Types de pentest

• Boite noire (black box)

• Boite blanche (white box)

• Mixte (grey box) ?

Préparation d'un pentest

• Périmètre

• Autorisation / interlocuteurs / documents

Périmètre

• Application Web
• Mobile
• API
• Applications Desktop (executables/binaires)
• Infrastructure (Interne / Externe )
• Autres (ATM, hardware, IOT, etc )

Autorisation

Le « mandat d'autorisation de test de pénétration » doit être signé par le représentant légal de l’entreprise ou le responsable des systèmes d’informations.

Article 509-1 du Code pénal :

« Quiconque, frauduleusement, aura accédé ou se sera maintenu dans tout ou partie d’un système de traitement ou de transmission automatisée de données sera puni d’un emprisonnement de deux mois à deux ans et d’une amende de 500 euros à 25 000 euros ou de l’une de ces deux peines ».

Interlocuteurs

• Responsable légal de l'entreprise
• Administrateurs / responsable d'application
• Equipe de surveillance
• Equipe de sécurité
• ...

Documents/reporting

• Document de préparation ( @IP , serveurs , application etc ...)
• Mandat d'autorisation
• Rapport final
• Préconisation d'amélioration

Méthodologies (officiel)

• PTES (Penetration Testing Execution Standard)

  http://www.pentest-standard.org/index.php/PTES_Technical_Guidelines

• OWASP Testing Guide

  https://owasp.org/www-project-web-security-testing-guide/stable/

• OSSTM (Open Source Security Testing Methodology Manual)

  http://www.isecom.org/OSSTMM.3.pdf

• Technical Guide to Information Security Testing and Assessment

  http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf

Organisations qui développent et fournissent des guides et manuels

OSSTMM (Open Source Security Testing Methodology Manual)

Manuel de test et d'analyse sécurité créée par Pete Herzog et fournit par ISECOM.

Il inclut les tests de sécurité, l'analyse, les métriques de sécurité opérationnelles, l'analyse des risques, les indicateurs de risque et les tactiques essentielles de test sécurité.

ISSAF(Information Systems Security Assessment Framework)

Framework ISSAF en constante évolution qui permet de modéliser les pré-requis de contrôle internes.

Le principal apport du framework est de créer des liens distinct entre les taches d'un pentest et les outils.

Organisation qui développent et fournissent des guides et manuels (suite)

OWASP (Open Web Application Security Project).

Organisation à but non commercial (licence libre et open-source) qui oeuvre à l'amélioration de la sécurité des applications.

Son objectif est de créer des standards ouverts et adaptables à des technologies orientées Web

PTES (Penetration Testing Execution Standard )

Guide technique qui définit les procedures à suivre et appliquer pendant un test d'intrusion.

Structure de base pour la conduite des tests de sécurité.

NIST (National Institute of Standards and Technology).

Base documentaire qui fournit les aspects techniques d'un audit de sécurité.

Fournit les tests techniques et les méthodes d'analyse qu'une organisation devrait utiliser pour effectuer un audit sécurité interne, ainsi que ces impacts sur les systèmes et réseaux.

Etapes d'un pentest

Etapes d'un pentest (simplifié)

Phase de reconnaissance

• Exercice

Quels sont les 2 méthodes et cités quelques outils ?

Phase de cartographie et de reconnaissance

Objectif: Inventorier et cartographier précisément l’ensemble des actifs du SI cible.

Cette étape permet de se concentrer sur les éléments jugés critiques et sensibles.

Méthode: Passive et Active

Exemples d'outils:

- Méthode passive: Base Whois,dig/nslookup, google, shodan (moteur de recherche),...   
- Méthode active : Nmap, Nessus ou OpenVas

Phase de recherche de vulnérabilités

• Analyse des faiblesses (automatique ou manuelle)

Top 10 OWASP

CVEdetails.com

Exemples d'outils:

• Outils pour les applications web : BurpSuite, ZAP, nikto

Phase d'exploitation

Objectifs:

• Mise en application de la phase précédente

• Intrusion sur le SI cible

Exemple d'outils:

• Metasploit

• Exploit-db.com/ searchsploit

Elevation de privilèges

Objectifs:

• Obtenir de nouveaux privilèges
• Accéder à des repertoires ou données sensibles

Dépend des connaissances et du savoir faire de l'auditeur

Maintien des accès

Objectif:

• Maintenir les accès privilégiés obtenu dans l'étape précédente pour se reconnecter et poursuivre la suite du test

Opérations à réaliser de manière furtive pour éviter d'éveiller des soupçons des équipes techniques

Propagation/déplacement latéraux

Objectif:

• Etendre la compromission à d'autres systèmes du périmètre cible

Exemple d'outil:

• Empire
• Mimikatz

Nettoyage des traces

Objectif: Rendre le/les systèmes dans son état d'origine

Contenu du rapport de test

• Le contexte et le périmètre (exemple: les adresses IP qui ont été testées.)

• Les conditions du test : boîte noire, boîte grise, boîte blanche

• La méthodologie : OWASP, PCI, Penetration Testing Execution Standard, OSSTMM, etc…). À défaut, il faut indiquer le processus de test qui a été suivi.

• Les axes d’évaluation : Les 3 axes d'évaluation utilisés pour qualifier les vulnérabilités ne sont pas forcément intuitifs. Il est bon de les expliquer pour que le lecteur comprenne plus facilement.

• Les résultats du test : Généralement sous forme de tableau, il est présenté comme un listing des vulnérabilités trouvées, avec les différentes informations les qualifiantes.

Contenu du rapport de test (suite)

• Une synthèse :

Synthèse récapitulant le nombre de vulnérabilités trouvées suivant :

• La sévérité
• Le niveau de priorité de correction
• La difficulté de correction

https://owasp.org/www-community/OWASP_Risk_Rating_Methodology

Résumé

• Document technique mais lisible par des non-informaticiens
• Un rapport de test est confidentiel
• Pas de structure unique mais doit contenir des éléments indispensables

Exemple de rapport de test de vulnérabilité

Demo ?

Et après ?

Recommandations après le pentest et le rapport final:

• Ne pas dissimuler les résultats du test d’intrusion : il est important de partager le reporting en bonne intelligence avec les équipes internes, la direction et les sous-traitants.
• Inscrire le plan d’action dans la roadmap de la DSI.
• Planifier un test post-audit (re-test) ciblé sur les vulnérabilités les plus critiques et les plus exposées, après remédiation.
• Un test d'intrusion doit être réalisé au moins une fois par an.

Limites

• Test limité dans le temps
• Focus sur des vulnérabilités les plus simples et accessibles ( dans le temps imparti )
• Ne couvre qu'une partie du SI

Evolution

• Discipline amenée à évoluer avec les technologies issues de l'IA (et BigData) L'adoption des techniques d'IA/ML, des analyses sécurité et du chiffrement ont permis de réduire les couts des failles (entre 1.25M$ et 1.49M$ ) comparativement aux entreprises qui n'en font pas un usage significatif.

• Outils de reconnaissance avancés et d'exploitation des vulnérabilités

Valeur ajoutée de l'humain :

• Trouver des solutions "originales" de détection des vulnérabilités.
• Capacité à produire des rapports et des recommandations personnalisées

Quelques exemples de sites pour vous entrainer

https://www.vulnhub.com/

https://www.root-me.org/

https://www.hackthebox.eu/

https://tryhackme.com/ ...

Conseil de préparation

• Etudier la qualification CVSS 4.0 ( publication prévu fin Octobre 2023 ) et CVSS 3.0 Documentation CVSS 4.0

Calculette CVSS 4

• Méthode OWASP de l'évaluation des risques : Risque = Probabilité x Impact

Methode d'evaluation des risques OWASP

Bug Bounty (BB)

Principe et objectif:

Une entreprise met à disposition de chercheurs en sécurité (hunters) leur système d'information (Web, API, apk ,...) dans le but de trouver des failles de sécurité en échange d'une rémunération

Difference Pentest vs Bug Bounty

• Dépend du besoin du client
• Pentest apporte plus de conformité et répond aux risques metiers
• Profondeur du test plus importante pour le BB et complétude pour le pentest

Vision "pentester"

Exemples:

• Outdated software
• weak/insecure method (TRACE)
• Cleartext (Telnet, http, etc)
• Ciphers and protocols
• Expired/invalid certificates
• basic authentication
• Brute forcing / no CAPTCHA
• user account enumeration
• No lockout policy
• Cookies not expiring
• weak password policy
• cookie flags

Vision (vulnérabilités qualifiantes) "hunter"

• Remote code execution (RCE)
• Local files access and manipulation (LFI, RFI, XXE, SSRF, XSPA)
• Code injections (HTML, JS, SQL, PHP, ...)
• Cross-Site Scripting (XSS)
• Cross-Site Requests Forgery (CSRF) with real security impact
• Open redirect
• Broken authentication & session management
• Insecure direct object references
• CORS with real security impact
• Horizontal and vertical privilege escalation

::: notes

This is my note.

Une entreprise a-t-elle besoin d'un pentest

If a company is wondering whether it should do a penetration test, I advise answering the following questions honestly. Start with simple yes/no answers. Then, for every yes answer, the company should see if it can back up that answer with, “Yes, because of internal process/procedure/application XYZ, which is maintained by employee ABC”:

• Is there an up-to-date record of every IP address and DNS name on the network?
• Is there a routine patching program for all operating systems and third-party applications running on the network?
• Do we use a commercial vulnerability scan engine/vendor to perform routine scans of the network?
• Have we removed local administrator privileges on employee laptops?
• Do we require and enforce strong passwords on all accounts on all systems?
• Are we utilizing multi-factor authentication everywhere?
• If your company can’t answer a solid yes to all of these questions, then a decent penetration tester would probably have little to no trouble breaking in and finding your organization’s crown jewels. I’m not saying you absolutely shouldn’t buy a penetration test, just that you should expect painful results.

:::

QCM Final (10-15 minutes)

Socrative student

SIERP0510

Bug Bounty (BB)

Principe et objectif:

Une entreprise met à disposition de chercheurs en sécurité (hunters) leur système d'information (Web, API, apk ,...) dans le but de trouver des failles de sécurité en échange d'une rémunération

Difference Pentest vs Bug Bounty

• Dépend du besoin du client
• Pentest apporte plus de conformité et répond aux risques metiers
• Profondeur du test plus importante pour le BB et complétude pour le pentest

Vision "pentester"

Exemples:

• Outdated software
• weak/insecure method (TRACE)
• Cleartext (Telnet, http, etc)
• Ciphers and protocols
• Expired/invalid certificates
• basic authentication
• Brute forcing / no CAPTCHA
• user account enumeration
• No lockout policy
• Cookies not expiring
• weak password policy
• cookie flags

Vision (vulnérabilités qualifiantes) "hunter"

• Remote code execution (RCE)
• Local files access and manipulation (LFI, RFI, XXE, SSRF, XSPA)
• Code injections (HTML, JS, SQL, PHP, ...)
• Cross-Site Scripting (XSS)
• Cross-Site Requests Forgery (CSRF) with real security impact
• Open redirect
• Broken authentication & session management
• Insecure direct object references
• CORS with real security impact
• Horizontal and vertical privilege escalation

Formulaire de rapport

Vulnérabilités fréquentes

1. XSS Stored
2. XSS Reflected
3. XSS Dom based (client side)
4. SQL Injection
5. NOSQL Injection
6. Access Control
7. Race Condition
8. RCE (Remote Command Execution)
9. Insecure Direct Object Reference
10. Business Logic Error
11. Server-Side Request Forgery
12. Man in the middle (techniques)
13. XXE injection
14. CSRF (client side)

Conseil pour ecrire un bon rapport de vulnérabilités de BugBounty:

Ces conseils sont issus de l'article publié sur le site de YesWeHack: https://www.yeswehack.com/fr/learn-bug-bounty/write-effective-bug-bounty-reports

Le score de gravité (CVSS) et la qualité du rapport vous permettent d'obtenir des points de bonus pour monter dans le classement des hunters, renforcer la confiance des équipes sécurité (client) et débloquer de nouvelles opportunité de gains ( ex: participation à des programmes privés,...)

Contrôle avant publication d'un rapport

• La vulnérabilité est-elle dans le périmètre du programme ? En tant que chasseur de bogues, vous devez respecter les règles du programme et ne chasser que sur les périmètres autorisés.

• Votre bogue fait-il partie de la liste des vulnérabilités admissibles du programme ? Une vulnérabilité non qualifiée risque d'entraîner le rejet du rapport et sa clôture en RTFS (Read The Fine Scope).

• Le bogue a-t-il un impact potentiel sur la sécurité ? En règle générale, la validation exige un impact direct sur la sécurité (sauf si la politique du programme en dispose autrement).

Analyse de l'impact

L'impact d'une vulnérabilité influe directement sur la gravité de vos conclusions et, par conséquent, sur la récompense que vous pourriez recevoir.

Démontrez l'impact en :

• Quantifiant les dommages potentiels : Évaluez les données qui pourraient être compromises ou les fonctionnalités qui pourraient être utilisées de manière abusive, et dans quel but.

Par exemple, la vulnérabilité pourrait-elle entraîner un accès non autorisé à des informations sensibles ou des pertes financières ? Quel est le scénario réaliste le plus défavorable ?

• Utiliser des scénarios du monde réel : Fournir un scénario d'attaque réaliste qui montre comment un attaquant pourrait exploiter la vulnérabilité. Cela aide l'équipe de sécurité du programme à comprendre les implications pratiques de la faille de sécurité.

Exemple de déclaration d'impact : "Cette vulnérabilité par injection SQL pourrait permettre à des pirates de récupérer l'ensemble de la base de données des utilisateurs, y compris des informations sensibles sur les clients, telles que les mots de passe et les numéros de carte de crédit.

Analyse du comportement:

Rédigez une analyse de comportement qui explique comment vous avez identifié la vulnérabilité en incitant l'application ou le système à se comporter de manière anormale.

Par exemple :

• Comprendre le comportement attendu : Comprendre comment l'application ou le système est censé fonctionner en se basant sur la documentation, les cas d'utilisation et les interactions légitimes des utilisateurs.

• Identifier les anomalies : Montrer les écarts par rapport au comportement attendu qui indiquent une vulnérabilité, tels que des messages d'erreur inattendus, des fonctionnalités non documentées ou des réponses incohérentes de l'application aux entrées de l'utilisateur.

• Exemple d'analyse de comportement : "Au cours de l'analyse, il a été observé que la soumission d'une charge utile spécialement conçue dans le formulaire de connexion de l'utilisateur entraînait un retard inhabituel dans la réponse de l'application. Ce comportement est révélateur d'une vulnérabilité d'injection SQL basée sur le temps, car le temps de réponse de l'application variait de manière significative avec différentes charges utiles, ce qui suggère qu'elle exécutait des commandes SQL non autorisées."

Rapport de recherche

Sections du rapport:

• Description de la vulnérabilité

Description de l'énumération commune des faiblesses (Common Weakness Enumeration - CWE) liée à la vulnérabilité. Cela permet au lecteur d'avoir une compréhension générale de la vulnérabilité que vous avez découverte.

• Découverte de la vulnérabilité

Description du processus de découverte de la vulnérabilité.

• Preuve de concept (PoC)

Le PoC sert essentiellement à prouver l'existence de la vulnérabilité. L'une des meilleures façons d'y parvenir est de combiner un court texte récapitulatif avec une référence visuelle sous la forme d'une image et/ou d'une vidéo.

• Exploitation:

Une démonstration des étapes qu'un attaquant pourrait suivre pour exploiter la vulnérabilité. Ces étapes doivent être faciles à suivre afin que les triagers puissent reproduire votre exploit et valider votre rapport le plus rapidement possible.

Vous pouvez également inclure un script d'exploitation, ce qui est particulièrement pratique pour les vulnérabilités avancées comportant de nombreuses étapes complexes.

• L'impact:

Décrivez clairement l'impact de votre vulnérabilité et reliez-le à la preuve de concept.

• Remédiation:

Fournissez une solution technique pour résoudre la vulnérabilité. Ce n'est pas obligatoire, mais le fait de fournir une solution potentielle peut faire gagner du temps à l'équipe de sécurité et sera très apprécié.

• Références:

Ajoutez des liens vers des ressources qui fournissent un contexte ou des informations supplémentaires qui aideront l'équipe de sécurité à comprendre la vulnérabilité.

Par exemple, il peut s'agir d'URL pour la définition CWE pertinente et d'avis de sécurité pour des vulnérabilités existantes avec lesquelles votre bogue peut être enchaîné.

CVSS (Common Vulnerability Scoring System)

CVSS est un framework public permettant d'évaluer la sévérité d'une vulnérabilité quelque soit l'éditeur de l'application.

Historique

Le score CVSS a été crée en 2005 par NIAC (US National Infrastructure Assurance Council), puis reprit par l'organisation international Forum for Incident Response and Security Teams (FIRST).

Historiquement, chaque éditeur avait sa propre méthode de scoring. Il était difficile pour les administrateurs de prioriser les corrections.

L'objectif initial était d'adresser ce problème pour uniformiser simplement l'évaluation des vulnérabilités en fonction de la sévérité et l'impact sur un environnement IT spécifique

Cette organisation regroupe diverses entreprises et individus qui aide à promouvoir et améliorer le framework

Version

CVSS2 en 2007 améliore la précédente version

CVSS3 en juin 2015 qui a apporté d'important changement pour refléter la réalité comme les privileges nécessaires à l'exploitation de la vulnérabilité.

CVSS 3.1 de juin 2019

Métrique de vulnérabilités

• Base score
• Temporal score (optionnel)
• Environnemental score (optionnel)

Métrique de Base (Base metrics) (Obligatoire)

Définit les caractéristiques de la vulnérabilité, qui ne change pas au cours du temps, de l'environnement

Composé de 2 ensemble de métriques

Métriques d'exploitabilité:

• Attack vector (AV)
• Attack complexity (AC)
• Privileges required (PR)
• User interaction (UI)

Métriques d'impacts

• Scope (S)
• Confidentiality impact (C)
• Integrity impact (I)
• Availability impact (A)

Ces métriques de base sont utilisés dans les activités de bugbounty pour qualifier une vulnérabilité.

Exemple de notation :

Base Score: 6.4 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N

Details des metriques de base:

• Attack Vector

• Attack Complexity

• User Interactivity

• Priviledge Required

• Scope

• Confidentiality

• Integrity

• Availability

Métriques temporelles (Optionnelle)

Mesure l'aspect de la vulnérabilité suivant sa connaissance, sa fiabilité et les changements temporelles, comme la diffusion d'un patch officiel.

Pondère le score de base si un patch ou un contournement est possible, si elle est validé par l'éditeur.

• Exploit code maturity
• Remediation level
• Report confidence

Métriques environnementales (Optionnelle)

Permet aux organisations de redéfinir le score de base (Base score)

• Collateral damage potential
• Target distribution
• Confidentiality requirement
• Integrity requirement
• Availability requirement

Synthèse

Fonctionnement du scoring

Un score CVSS est compris entre 0.0 et 10.0 ( 10.0 est le score le plus élevé)

Classement générique à destination de personnes non techniques,

0.0 = None

0.1-3.9 = Low

4.0-6.9 = Medium

7.0-8.9 = High

9.0 - 10.0 = Critical

CVSS vs. CVE

CVE (Common Vulnerabilities and Exposures) est un identifiant unique pour chaque vulnérabilité listée par le NIST NVD (National Vulnerability Database).

Format: CVE-[4 Digit Year]-[Sequential Identifier].

Exemple: Heartbleed --> CVE-2014-0160.

Cependant CVE utilise CVSS pour fournir une indication de sévérité pour chaque CVE

Calculette CVSS

Les services de calcul CVSS en ligne publique n'indique que les scores de base, et ne concerne que la sévérité de la vulnérabilité sans prendre en compte un environnement spécifique

(Ex: Immuniweb)

Pour prendre en compte les scores temporels et environnementals, il est nécessaire d'utiliser une calculette appropriée

Calculette cvss3.1 : https://www.first.org/cvss/calculator/3.1

(Service FIRST, CISCO et NIST)

Exemple

MySQL Stored SQL Injection (CVE-2013-0375)

Vulnérabilités:

Une vulnérabilité dans la base de donnée MySql permet à un attaquant distant authentifié d'injecter du code qui s'exécute avec des privilèges sur une base de donnée distante.

Le code distant peut lire ou modifié des données.

La vulnérabilité est dû à une validation insuffisante des données fournies par l'utilisateur lors de leur réplication sur des instances distantes MySQL.

Attaques:

L'attaquant a besoin d'un compte sur la cible ( base Mysql) avec les droits permettant de modifier les droits des utilisateurs (table names).

Le compte de replication doit être dans cette table L'attaque consiste a modifier l'identifiant de cette utilisateur ( de replication) avec des caractères entre guillemets et un fragment de code SQL malveillant (Injection SQL).

Cette requête SQL est répliqué et s'exécute sur les autres instances SQL avec des privileges élevés.

Le succès de l'attaque permet de faire des updates, insertion ou suppression sur toutes les instances Mysql accessible, y compris les bases accessibles en lecture seul.

Security-Database Scoring CVSS v3

Cvss vector : CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N

Overall CVSS Score 6.4

CVSS 4.0

Documentation officielle

Publication officiel prévue fin octobre 2023

Nouvelle version

L'objectif de cette nouvelle version est de clarifier certaines metric (SCOPE a été supprimé), d'elargir les metrics( sécurité des personnes ) et d'améliorer l'adoption en permettant aux clients de ponderer le score avec des metriques internes à l'organisation

Nouvelle nomenclature pour identifier les combinaisons avec le score de base:

• CVSS-B: Score de Base
• CVSS-BT: Base + Threat
• CVSS-BE: Base + Environmental
• CVSS-BTE: Base + Threat + Environmental

Synthèse des groupes de metrique:

1. Groupe de métrique de Base

Nouvelles métriques:

• Attack Requirements (AT):Pré-requis à l'attaque

 User Interaction(UI) : Interaction d'un utilisateur (None/Active/Passive)

• La metrique Scope a été supprimé

• Les metriques d'impact ont été séparés en 2 groupes:

Seule une augmentation de l'accès, des privilèges obtenus ou d'autres résultats négatifs résultant d'une exploitation réussie doivent être pris en compte lors de l'évaluation des paramètres d'impact d'une vulnérabilité. Prenons l'exemple d'une vulnérabilité qui nécessite des autorisations en lecture seule avant de pouvoir l'exploiter. Après une exploitation réussie, l'attaquant conserve le même niveau d'accès en lecture et obtient un accès en écriture. Dans ce cas, seule la mesure de l'impact sur l'intégrité doit être évaluée, et les mesures de l'impact sur la confidentialité et la disponibilité doivent être définies comme nulles.

• Vulnerable System Confidentiality (VC), Integrity (VI), Availability (VA)

• Subsequent System(s) Confidentiality (SC), Integrity (SI), Availability (SA)

Exemple: Une vulnérabilité sur une base de données intégré à un haut-parleur intelligent affecte egalement le fonctionnement du haut parleur Prise en compte des impacts en dehors du systeme vulnerable Lorsqu'une vulnérabilité n'a pas d'impact en dehors du système vulnérable, les évaluateurs doivent laisser la valeur NONE (N) pour la mesure de l'impact sur le système ultérieur.

2. Menaces

La temporalité de la vulnérabilité a été remplacé par le groupe de métrique concernant les menaces (Threat metrics group)

• Exploit Maturity: Maturité de l'exploit

Cet indicateur mesure la probabilité que la vulnérabilité soit attaquée et se fonde sur l'état actuel des techniques d'exploitation, la disponibilité du code d'exploitation ou l'exploitation active "dans la nature".

3. Groupe de métrique environnemental

todo

4. Supplemental Metrics (metriques supplementaires)

todo

Value Density (V): La densité de valeur décrit les ressources sur lesquelles l'attaquant prendra le contrôle en un seul événement d'exploitation. Elle a deux valeurs possibles : diffuse et concentrée :

• Diffuse(D)

Le système qui contient le système vulnérable a des ressources limitées.

En d'autres termes, les ressources sur lesquelles l'attaquant prendra le contrôle lors d'un seul événement d'exploitation sont relativement faibles.

Un exemple de densité de valeur diffuse (pensez : limitée) serait une attaque sur la vulnérabilité d'un seul client de messagerie.

• Concentrated (C):

Le système qui contient le système vulnérable est riche en ressources.

Ces systèmes sont souvent sous la responsabilité directe des "opérateurs de système/admin" plutôt que des utilisateurs.

Un exemple de densité de valeur concentrée (pensez : large) serait une attaque sur un serveur de messagerie

Synthèse:

Calculette CVSS4

https://redhatproductsecurity.github.io/cvss-v4-calculator/#

Méthodologie d'évaluation des risques OWASP

Objectifs d'une Méthodologie d'évaluation des risques:

La mise en place d'un système d'évaluation des risques permet de gagner du temps et d'éviter les discussions sur les priorités.

Ce système permettra de s'assurer que l'entreprise ne se laisse pas distraire par des risques mineurs tout en ignorant des risques plus graves qui sont moins bien compris.

Calculette en ligne :

https://owasp-risk-rating.com/

Différentes méthodes:

• Classic Risk Rating: This risk rating methodology uses a Likelihood value and an Impact value with a mathematical formula applied to come up with a risk score. Typically something like Risk = Likelihood x Impact. I talk more about this risk scoring methodology in my Normalizing Risk Scores Across Different Methodologies blog post.

• CVSS: Also known as the Common Vulnerability Scoring System, CVSS is developed by the Forum of Incident Response and Security Teams (FIRST) organization and is what is used to rate all of the Common Vulnerabilities and Exposures (CVEs) found in the National Vulnerability Database (NVD). It is comprised of a Base Vector, which has multiple values to estimate likelihood and impact, along with optional values to estimate the Temporal and Environmental impact on your environment.

• DREAD: The DREAD risk assessment model was initially used at Microsoft as a simple mnemonic to rate security threats on the basis of Damage, Reproducibility, Exploitability, Affected Users, and Discoverability. We don't see it being used by customers very often, but it has been included in SimpleRisk since very early on in our product history.

• OWASP: The OWASP Risk Rating Methodology was created by Jeff Williams, one of the Founders of the OWASP organization, as a means to easily and more accurately assess the likelihood and impact of a web application vulnerability. It's an application-centric play on the Classic Risk Rating described above, where the Likelihood is assessed based on Threat Agent and Vulnerability factors and the Impact is assessed based on Technical and Business factors.

Approche standard:

Modele de risque standard:

Risk = Likelihood * Impact

En francais :
Risque = la probabilité d'exploitation d'une vulnerabilité * impacte sur le SI ou le business

La "probabilité" et "l'impact" sont décomposées pour déterminer ces facteurs de risque

Etapes:

1: Identifier un risque

2: Facteurs d'estimation de la probabilité

3: Facteurs d'estimation de l'impact

4: Determiner la sévérité du risque

5: Prioriser les remédiations

6: Personnaliser votre modèle de risque

1. Identification des risques:

Le testeur doit rassembler des informations sur l'agent de menace concerné, l'attaque qui sera utilisée, la vulnérabilité impliquée et l'impact d'une exploitation réussie sur l'entreprise.

Il peut y avoir plusieurs groupes d'attaquants possibles, ou même plusieurs impacts possibles sur l'entreprise.

En général, il est préférable de pécher par excès de prudence en choisissant l'option la plus défavorable, car c'est celle qui présente le risque global le plus élevé.

2. Facteurs d'estimation de la probabilité

Au niveau le plus élevé, il s'agit d'une mesure approximative de la probabilité que cette vulnérabilité particulière soit découverte et exploitée par un attaquant.

Il n'est pas nécessaire d'être très précis sur cette estimation
Les niveaux "low", "medium" ou "high" sont suffisant

Un certain nombre de facteurs peuvent aider à déterminer la probabilité. La première série de facteurs est liée à l'agent de menace (Threat Agent) concerné.

L'objectif est d'estimer la probabilité d'une attaque réussie à partir d'un groupe d'attaquants possibles.

Chaque facteur comporte une série d'option et chaque option est associée à une note de probabilité de 0 à 9 utilisées par la suite pour estimer une probabilité globale.

a) Agent de Menace ( Threat Agent ):

L'objectif est d'estimer la probabilité d'une attaque réussie par ce groupe d'agents de menace. Utilisez l'agent de menace le plus défavorable.

• Niveau de compétence(skill level): Quel est le niveau de compétence technique de ce groupe d'agents de menace ?

  Aucune compétence technique (1), quelques compétences techniques (3), utilisateur avancé d'ordinateur (5), compétences en réseau et en programmation (6), compétences en matière de pénétration de la sécurité (9)

• Motivation (Motive): Quelle est la motivation de ce groupe d'agents de menace pour trouver et exploiter cette vulnérabilité ?

  Récompense faible ou nulle (1), récompense possible (4), récompense élevée (9)

• Opportunité(Opportunity): Quelles sont les ressources et les opportunités nécessaires à ce groupe d'agents de lutte contre les menaces pour trouver et exploiter cette vulnérabilité ?

  Accès total ou ressources coûteuses nécessaires (0), accès ou ressources spéciales nécessaires (4), accès ou ressources partiels nécessaires (7), aucun accès ou ressources nécessaires (9).

• Taille: Quelle est la taille de ce groupe d'agents de menace ?

  Développeurs (2), administrateurs système (2), utilisateurs de l'intranet (4), partenaires (5), utilisateurs authentifiés (6), utilisateurs anonymes de l'internet (9)

b) Facteurs de vulnérabilité:

L'objectif est d'estimer la probabilité que la vulnérabilité en question soit découverte et exploitée

• Facilité de découverte: Dans quelle mesure est-il facile pour ce groupe d'agents de découvrir cette vulnérabilité ?

  Pratiquement impossible (1), difficile (3), facile (7), outils automatisés disponibles (9)

• Facilité d'exploitation: Dans quelle mesure est-il facile pour ce groupe d'agents de menace d'exploiter cette vulnérabilité ?

  Théorique (1), difficile (3), facile (5), outils automatisés disponibles (9)

• Niveau de diffusion (awareness) : Dans quelle mesure cette vulnérabilité est-elle connue de ce groupe d'agents de menace ?

  Inconnue (1), cachée (4), évidente (6), connue du public (9)

• Détection des intrusions: Quelle est la probabilité qu'un exploit soit détecté ?

  Détection active dans l'application (1), enregistrée et examinée (3), enregistrée sans examen (8), non enregistrée (9)

3. Facteur d'estimation de l'impact

2 types d'impact : Technique et business

L'impact sur l'entreprise est généralement le plus important.

Toutefois, il se peut que vous n'ayez pas accès à toutes les informations nécessaires pour déterminer les conséquences commerciales d'un exploit réussi.

Dans ce cas, le fait de fournir autant de détails que possible sur le risque technique permettra au représentant approprié de l'entreprise de prendre une décision sur le risque commercial.

Là encore, chaque facteur est assorti d'une série d'options et chaque option est associée à une note d'impact de 0 à 9 qui sera utiliser plus tard pour estimer l'impact global.

a) Impact techniques:

L'objectif est d'estimer l'ampleur de l'impact sur le système en cas d'exploitation de la vulnérabilité.

• Perte de confidentialité: Quelle quantité de données pourrait être divulguée et quel est leur degré de sensibilité ?

  Divulgation d'un minimum de données non sensibles (2), divulgation d'un minimum de données critiques (6), divulgation d'un grand nombre de données non sensibles (6), divulgation d'un grand nombre de données critiques (7), divulgation de toutes les données (9).

• Perte d'intégrité: Quelle est la quantité de données susceptibles d'être corrompues et à quel point sont-elles endommagées ?

  Données minimales légèrement corrompues (1), données minimales gravement corrompues (3), données étendues légèrement corrompues (5), données étendues gravement corrompues (7), toutes les données totalement corrompues (9).

• Perte de disponibilité: Quelle quantité de service pourrait être perdue et quelle est son importance vitale ?

  Interruption minimale des services secondaires (1), interruption minimale des services primaires (5), interruption importante des services secondaires (5), interruption importante des services primaires (7), perte totale de tous les services (9).

• Traçabilité: Les actions des agents de menace peuvent-elles être rattachées à une personne ?

  Entièrement traçable (1), éventuellement traçable (7), complètement anonyme (9)

b) Impact business:

Le risque business justifie les investissement dans la résolution des problèmes de sécurité.

• Préjudice financier: Quel est le préjudice financier résultant d'un exploit ?

  Moins que le coût de la correction de la vulnérabilité (1), effet mineur sur le bénéfice annuel (3), effet important sur le bénéfice annuel (7), faillite (9).

• Atteinte à la réputation: Un exploit entraînerait-il une atteinte à la réputation qui nuirait à l'entreprise ?

  Dommage minime (1), perte de grands comptes (4), perte de clientèle (5), atteinte à la marque (9).

• Non-conformité: Quel est le degré d'exposition à la non-conformité ?

  Violation mineure (2), violation manifeste (5), violation très médiatisée (7)

• atteinte à la vie privée: Quelle quantité de données personnels pourrait être divulguée ?

  Une personne (3), des centaines de personnes (5), des milliers de personnes (7), des millions de personnes (9).

4. Déterminer la sévérité du risque

Dans cette étape, l'estimation de la probabilité et l'estimation de l'impact sont réunies pour calculer la gravité globale de ce risque.

L'échelle de 0 à 9 est divisée en trois parties

Utilisation des scores de probabilité

Ensuite, le testeur doit déterminer l'impact global. Le processus est similaire ici.

Dans de nombreux cas, la réponse sera évidente, mais le testeur peut faire une estimation basée sur les facteurs, ou il peut faire la moyenne des scores pour chacun des facteurs.
Encore une fois, moins de 3 est faible, 3 à moins de 6 est moyen, et 6 à 9 est élevé.

Par exemple :

Determiner la sévérité

Quel que soit le résultat des estimations de probabilité et d'impact, le testeur peut maintenant les combiner pour obtenir une évaluation finale de la gravité de ce risque.

Il est à noter que s'il dispose de bonnes informations sur l'impact commercial, il doit les utiliser à la place des informations sur l'impact technique.

En revanche, s'il ne dispose d'aucune information sur l'entreprise, il doit se contenter de l'impact technique.

Dans l'exemple précédent, la probabilité est moyenne et l'impact technique est élevé, de sorte que, d'un point de vue purement technique, il semble que la gravité globale soit élevée.
Toutefois, il convient de noter que l'impact commercial est en fait faible, de sorte que la gravité globale est également décrite comme faible.

C'est pourquoi il est essentiel de comprendre le contexte commercial des vulnérabilités que vous évaluez pour prendre de bonnes décisions en matière de risque.
Ne pas comprendre ce contexte peut conduire à un manque de confiance entre l'entreprise et les équipes de sécurité, comme c'est le cas dans de nombreuses organisations.

5. Prioriser les remédiations

Une fois les risques classifiées par ordre de priorités, les risques les plus graves doivent être corrigés en premier.

Tous les risques ne valent pas la peine d'être corrigés et que certaines pertes sont non seulement prévisibles, mais aussi justifiables en fonction du coût de la correction du problème.

Par exemple, si la mise en œuvre de contrôles permettant d'endiguer une fraude de 2 000 dollars par an coûte 100 000 dollars, il faudra 50 ans de retour sur investissement pour éradiquer la perte.

Cependant la fraude peut nuire à la réputation de l'organisation, ce qui pourrait lui coûter beaucoup plus cher.

6. Personnaliser votre modèle de risque

Un modèle personnaliser pour un domaine métier facilite l'adoption et produit de meilleur résultat.
Les risques sont mieux compris par les parties prenantes et évite les discussions inutiles sur la méthode de calcul.

• Ajout de facteurs

Le testeur peut choisir différents facteurs qui représentent mieux ce qui est important pour l'organisation spécifique.

Par exemple, une application militaire peut ajouter des facteurs d'impact liés à la perte de vies humaines ou d'informations classifiées.
Le testeur peut également ajouter des facteurs de probabilité, tels que la fenêtre d'opportunité pour un attaquant ou la force de l'algorithme de chiffrement.

• Personnaliser les options :

Des exemples d'options sont associés à chaque facteur, mais le modèle sera beaucoup plus efficace si le testeur adapte ces options à l'entreprise.

Par exemple, utilisez les noms des différentes équipes et les noms de l'entreprise pour les différentes classifications des informations.
Le testeur peut également modifier les scores associés aux options. La meilleure façon d'identifier les bonnes notes est de comparer les notes produites par le modèle avec les notes produites par une équipe d'experts.
Vous pouvez mettre au point le modèle en ajustant soigneusement les notes pour qu'elles correspondent.

• Pondération des facteurs

Le modèle ci-dessus part du principe que tous les facteurs ont la même importance.
Vous pouvez pondérer les facteurs pour mettre l'accent sur ceux qui sont les plus importants pour l'entreprise concerné.
Cela rend le modèle un peu plus complexe, car le testeur doit utiliser une moyenne pondérée. Mais pour le reste, tout fonctionne de la même manière.
Là encore, il est possible d'affiner le modèle en le comparant à des évaluations de risques que l'entreprise considère comme exactes.

Installation de docker sur Debian

** Synthèse de la doc officiel : https://docs.docker.com/engine/install/debian/#install-using-the-repository **

# Add Docker's official GPG key:
sudo apt-get update
sudo apt-get install ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Add the repository to Apt sources:
echo \
  "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/debian \
  "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update

Installation des paquets Docker:

sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Verification du bon fonctionnement

> docker run hello-world

Lister les images

docker images

Lister tous les conteneurs

docker ps -a

Telecharger une image si elle n'existe pas et lancer le conteneur

docker run nom_image

Démarrer un conteneur, se connecter avec un shell

docker run -it nom_du_conteneur /bin/bash

Démarrer un conteneur existant

docker start nom ou id du conteneur

Désinstallation de docker

#![allow(unused)]
fn main() {
>sudo apt-get purge docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin docker-ce-rootless-extras

>sudo rm -rf /var/lib/docker
>sudo rm -rf /var/lib/containerd
}

Voir la cheat-sheet/memo docker

CORS (Cross Origin Source sharing)

CORS est une "technologie" qui permet d'assouplir le principe de "Same Origin Policy" et de permettre la communication entre les sites web.

Principe de fontionnement de SOP:

** la SOP n'empêche pas une requête d'être émise, mais seulement de consulter la réponse reçue du serveur lorsque la requête est émise depuis une origine différente.**

Certaines configurations CORS peuvent etre dangereuses Websites enable CORS by sending the following HTTP response header:

Access-Control-Allow-Origin: https://example.com

Cette permission donné à "example.com" Cela permet à l'origine (domaine) listée de faire en sorte que les navigateurs web des visiteurs envoient des requêtes inter-domaines au serveur et lisent les réponses
Ce que la politique de la même origine devrait normalement empêcher. Par défaut, cette requête sera émise sans cookies ni autres informations d'identification, de sorte qu'elle ne peut pas être utilisée pour voler des informations sensibles spécifiques à l'utilisateur, comme les jetons CSRF.

Le serveur peut activer la transmission des informations d'identification en utilisant l'en-tête suivant Access-Control-Allow-Credentials: true Cela crée une relation de confiance - une vulnérabilité XSS sur exemple.com est une mauvaise nouvelle pour ce site.

Access-Control-Allow-Origin: http://foo.com http://bar.net --> Aucun navigateur ne supporte cette configuration

Vous pourriez autoriser uniquement les sous domaines en specifiant un wildcard *.domaine.com Access-Control-Allow-Origin: **.portswigger.net Ca ne marchera pas non plus.

La pire configuration : ( exposition complete du site )

Access-Control-Allow-Origin: * Access-Control-Allow-Credentials: true

Principe d'une attaque CORS:

Methodologie pour pentesters

• voir si le serveur renvoie spontanément des en-têtes CORS ;
• voir si le serveur renvoie des en-têtes CORS lorsqu'on lui soumet des origines « plausibles » dans le contexte : son domaine, son domaine de second niveau, des domaines potentiellement partenaires...
• voir comment le serveur répond à des requêtes OPTIONS avec les mêmes variations que ci-dessus ;
  • on essaiera dans tous les cas d'obtenir une origine autorisée que l'on maîtrise ou peut maîtriser ;
  • si le serveur supporte plusieurs origines, on contrôlera qu'il renvoie bien un en-tête Vary: origin ;
  • De plus dans le cas de réflexion d'origine ou de header, on essaiera d'exploiter ce comportement pour faire de l'injection de headers dans la réponse.

Les outils de scans de vulnerabilités traitent les cas de vulnerabilités CORS mais pas de maniere exhaustive

Une recherche manuelle sera donc la bienvenue en complément par exemple du plugin Burp Backslash Powered Scanner

Recommandations:

En cas de mauvaise configuration et/ou de vulnérabilité, les recommandations suivantes de configuration des CORS pourront être émises en les adaptant au contexte :

• ne pas renvoyer d'en-tête CORS tant que le serveur n'a pas reçu de requête comportant un en-tête Origin: ;

• proscrire l'origine null : refuser l'origine null et ne jamais renvoyer Access-Control-Allow-Origin: null ;

• renvoyer des en-têtes CORS uniquement lorsque la réponse d'une ressource doit être accessible d'un script :

• ne pas renvoyer Access-Control-Allow-Origin: *, sauf sur de vraies ressources publiques destinées à être consommées par des scripts (catalogue de produits par exemple) exécutés par un agent ;

• lister les origines acceptées au sein d'une liste blanche et ne jamais renvoyer un en-tête Access-Control-Allow-Origin avec une valeur ne figurant pas dans la liste blanche ;

• toujours renvoyer un en-tête Vary: origin si plusieurs origines distinctes sont autorisées ;

• si l'origine reçue ne correspond à aucune origine de la liste blanche, renvoyer une erreur plutôt qu'un contenu sans en-tête Access-Control-Allow-Origin. Cela évite de divulguer du contenu potentiellement sensible, même si l'agent ne permettrait pas au script demandeur d'y accéder ;

• renvoyer Access-Control-Allow-Credentials: true uniquement lorsque la réponse d'une ressource DOIT être accessible d'un script exécuté par un agent en mode authentifié.

CSRF (Cross Site Request Forgery) ou XSRF

Microsoft qualifie ce type d'attaque de "One-Click attack" (attaque en un clic).

Définition:

CSRF est une attaque qui incitent une victime à executer une requête malveillante Elle hérite de l'identité et des privilèges de la victime pour exécuter une fonction indésirable en son nom

Pour la plupart des sites, les requêtes du navigateur incluent automatiquement toutes les informations d'identification associées au site, telles que le cookie de session de l'utilisateur, l'adresse IP, les informations d'identification du domaine Windows, etc.

Par conséquent, si l'utilisateur est actuellement authentifié sur le site, ce dernier n'aura aucun moyen de faire la distinction entre la fausse requête envoyée par la victime et une requête légitime envoyée par la victime.

Exemple:

Hypothèse :

Alice utilise un site bancaire pour transferer un m!ontant de 100€ à Bob

GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1

Maria est l'attaquante et incite Alice à lui transferer ce montant plutôt qu'à Bob

Scenario avec GET

La requete normal se presente sous cette forme : GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1

La requete que Maria doit faire executer par Alice est de la forme:

http://bank.com/transfer.do?acct=MARIA&amount=100000

La technique d'ingénierie sociale que doit utilisé Maria doit être: -envoi d'un courrier électronique non sollicité avec un contenu HTML en plaçant une URL ou un script d'exploitation sur des pages susceptibles d'être visitées par la victime pendant qu'elle effectue des opérations bancaires en ligne.

La requete originale peut être dissimulé sous ces formes :

'''<a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View my Pictures!</a>'''

Ou une fausse image de dimension 0x0 :

'''<img src="http://bank.com/transfer.do?acct=MARIA&amount=100000" width="0" height="0" border="0">'''

Scenario avec POST:

Requete d'origine:

POST http://bank.com/transfer.do HTTP/1.1

acct=BOB&amount=100

Maria doit dissimuler la requete avec un formulaire

<form action="http://bank.com/transfer.do" method="POST">

<input type="hidden" name="acct" value="MARIA"/>
<input type="hidden" name="amount" value="100000"/>
<input type="submit" value="View my pictures"/>

</form>

Ce formulaire exige que l'utilisateur clique sur le bouton de soumission, mais cette opération peut également être exécutée automatiquement à l'aide de JavaScript :

<body onload="document.forms[0].submit()">

<form...> 

Autre méthode HTTP

Les API des applications web modernes utilisent fréquemment d'autres méthodes HTTP, telles que PUT ou DELETE. Supposons que la banque vulnérable utilise la méthode PUT qui prend un bloc JSON comme argument :

PUT http://bank.com/transfer.do HTTP/1.1

{ "acct":"BOB", "amount":100 }

Ces demandes peuvent être exécutées à l'aide de JavaScript intégré dans une page d'exploitation :

<script>
function put() {
    var x = new XMLHttpRequest();
    x.open("PUT","http://bank.com/transfer.do",true);
    x.setRequestHeader("Content-Type", "application/json");
    x.send(JSON.stringify({"acct":"BOB", "amount":100})); 
}
</script>

<body onload="put()">

Cette requête ne sera PAS exécutée par les navigateurs web modernes grâce aux restrictions de la politique de même origine (CORS).

Cette restriction est activée par défaut, à moins que le site web cible n'ouvre explicitement les requêtes cross-origin à partir de l'origine de l'attaquant (ou de tout le monde) en utilisant CORS avec l'en-tête suivant :

Access-Control-Allow-Origin : *

Mesure qui ne fonctionne PAS:

• Cookie secret
• Utilisation de requete POST
• Les transactions en plusieurs étapes ne constituent pas une prévention adéquate de CSRF. Tant qu'un attaquant peut prédire ou déduire chaque étape de la transaction terminée, le CSRF est possible.
• Verification du referer
• HTTPS

Mesure de prévention

HSTS : HTTP strict transport Security

HTTP strict transport security header utilise 2 directives :

• max-age: Indique le nombre de second que le navigateur doit utiliser pour convertir les requetes HTTP en HTTPS.

• includeSubDomains: Indique tout les sous domaines relatifs au HTTPS.

• preload ( Non officiel ): Indique que le domain est prechargé sur une liste et que les navigateurs ne doivent se connecter qu'en HTTPS Supporté par la plupart des navigateurs mais ne fait pas partie de la spec officiel (See hstspreload.org for more information.)

Exemple d'implementation sz l'entete HTSTS :

Strict-Transport-Security: max-age=31536000; includeSubDomains

Comment tester : curl -s -D- https://owasp.org | grep -i strict

Insecure Direct Object Reference

Les références directes à des objets non sécurisées (IDOR) sont un type de vulnérabilité du contrôle d'accès qui se produit lorsqu'une application utilise des données fournies par l'utilisateur pour accéder directement à des objets.

Il ne s'agit que d'un exemple parmi les nombreuses erreurs de mise en œuvre du contrôle d'accès qui peuvent conduire au contournement des contrôles d'accès.

Les vulnérabilités IDOR sont le plus souvent associées à l'escalade horizontale des privilèges (privilèges équivalent à un autre utilisateur dans un contexte de sécurité different) mais elles peuvent également survenir en relation avec l'escalade verticale des privilèges (niveau supérieure de privilèges).

Exemples:

https://insecure-website.com/customer_account?customer_number=132355

La variable customer_number est directement utilisé comme index de la base de données ( en backend). Si aucun controle n'est effectué, l'utilisateur peut simplement changer la valeur pour consulter les enregistrements d'autres clients.

Un attaquant pourrait être en mesure d'effectuer une escalade de privilèges horizontale et verticale en modifiant l'utilisateur pour qu'il dispose de privilèges supplémentaires tout en contournant les contrôles d'accès. Parmi les autres possibilités, citons l'exploitation d'une fuite de mot de passe ou la modification des paramètres une fois que l'attaquant a atterri sur la page des comptes de l'utilisateur.

Les vulnérabilités IDOR apparaissent souvent lorsque des ressources sensibles sont situées dans des fichiers statiques sur le système de fichiers côté serveur. Par exemple, un site web peut enregistrer les transcriptions de messages de chat sur le disque en utilisant un nom de fichier incrémentiel, et permettre aux utilisateurs de les récupérer en visitant une URL ( ex: https://insecure-website.com/static/12144.txt )

RCE (Remote Code Execution ou Injection de code à distance) - "Code Injection" selon l'OWASP

Cette vulnérabilité permet d'executer du code à distance sur un système vulnérable en utilisant le language de l'application (PHP, javascript, java pour les applications Web, C#, ...)

D'autres vulnérabilités peuvent conduire à une exécution de code arbitraire à distance:

• Buffer Overflow (dépassement de tampon) dans des langages tels que C/C++ peuvent permettre à l'attaquant d'exécuter du code arbitraire dans l'application.
• Les vulnérabilités de désérialisation peuvent également permettre aux attaquants de fournir une charge utile qui, une fois désérialisée, est exécutée par l'application.
• Des vulnérabilités d'injection SQL et de cross-site scripting (XSS) peuvent conduire à l'exécution de code à distance dans une application vulnérable.

3 types d'attaques RCE possible:

• Côté Serveur:

Injection dans une application web ou une base de données afin de l'exécuter sur un serveur.

Ce type d'attaque vise les champs d'entrée de l'utilisateur, tels qu'un champ de recherche ou un formulaire de connexion. Les applications qui ne valident pas correctement les entrées sont plus vulnérables à l'injection côté serveur.

• Côté client

Injection de code malveillant dans une application client, telle qu'un navigateur web. Cela se fait par le biais de publicités, de courriels ou de sites web malveillants qui exploitent les vulnérabilités du logiciel du client.

• Injection dans un shell:

Code malveillant dans un shell où le serveur est en cours d'exécution. Cela se fait par le biais de champs de saisie de l'utilisateur qui permettent l'exécution de commandes ou par le biais de vulnérabilités existantes dans le système d'exploitation ou les périphériques de réseau.

Exemple simple:

<?php 
$command = $_GET['cmd'];
system($command);
?>

Ce code prend une entrée GET nommée "cmd" et l'utilise pour exécuter une commande système via la fonction PHP "system()". Si un attaquant envoie une requête GET avec une entrée de cmd malveillante, par exemple

http://example.com/script.php?cmd=cat%20/etc/passwd"

L'attaquant peut exécuter n'importe quelle commande sur le serveur cible.

Pour PHP : Désactiver/analyser les fonctions eval(), system(), ou exec().

Exemple 2 :

Le formulaire de contact:

<?php
$username = $_POST['username'];
$password = $_POST['password'];

$query = "SELECT * FROM users WHERE username='$username' AND password='$password'";
$result = mysqli_query($conn, $query);

if (mysqli_num_rows($result) > 0) {
// login successful
} else {
// login failed
}
?>

SELECT * FROM users WHERE username='''; system('rm -rf /'); //' AND password=''

Autres exemples de vulnérabilités RCE :

• CVE-2021-44228 (Log4Shell) dans Apache Log4j 2.x (followed up by CVE-2021-45046 and a CVE-2021-45105 denial of service vulnerability)

• CVE-2019-8942 dans WordPress 5.0.0. Un attaquant peut executé du code arbitraire en chargeant ( upload) une image manipulée contant du code PHP dans les metadata EXIF.

Conséquences possibles des RCE:

• Installation de WebShell: Ces payloads (même privilèges que le serveur web) peuvent donner à l'attaquant un acces shell pour executer des commandes systèmes
• Installation de reverse shell: Installation sur la cible d'un script/code qui va initier une connexion vers un serveur contrôlé par l'attaquant.Permet de passer les firewalls.

Si l'attaque est réussi l'attaquant peut :

• Installer des ransomwares ou malwares
• Installer des mineurs de cryptomonnaies
• Récupérer des informations sensibles,réaliser des escalades de privilèges sur le système ou realiser des mouvements latéraux

Reduire les risques des RCE :

• Dans le cas d'une application personnalisé

  • Eliminer du code de votre application les fonctions d'évaluation qui traitent les entrées contrôlées par l'utilisateur

• Dans le cas d'une application tierce (commercial/opensource)

  • Verifier les dernières vulnérabilités et effectuer les mises à jour avec la version qui corrige cette vulnérabilité (Généralement la dernière version)

  • Utilisation d'un WAF ( Web Application Firewall) ; solution temporaire permettant de rendre plus difficile l'exploitation RCE mais n'élimine par la cause du problème

Détecter les RCE :

• Application commercial ou opensource :

  • Outils SCA (Software Composition Analysis) : Processus automatisé permettant d'identifier les logiciels tiers et open source (OSS) dans une base de code. L'objectif de SCA est d'évaluer la qualité du code, la sécurité et la conformité aux licences. Differents des outils SAST (Static Analysis Security Testing) / DAST (Dynamic Analysis Security Testing)

  Exemple d'outils:

  • Gitlab
  • Snyk (Free/licensing)
  • XRay (Jfrog)

• Utilisation de DAST (Dynamic Application Security Testing)

  • Pentest dynamique sur la chaine de CI/CD

  ex outils : ZAP ( scripting de scénario)

Server-Side Request Forgery (SSRF)

Les SSRF permettent d’interagir avec le serveur, afin d’en extraire des fichiers et de trouver ses autres services actifs. Il est egalement d'effectuer d'autres actions comme de scanner le reseau interne pour decouvrir les IP internes et les ports ouverts

Exemple de code vulnérable :

Exemple d'exploitation :

• Accès à une fonctionnalitée du serveur Apache (non exposée) : http://vulnerable-serveur.com/ssrf.php?url=http://localhost/server-status

• Accès à un service web du serveur (non exposé) : http://vulnerable-serveur.com/ssrf.php?url=http://localhost:8080

• Accès à un fichier du serveur (LFI : Local File Inclusion) : http://vulnerable-serveur.com/ssrf.php?url=file:///etc/passwd

• Accès à un serveur web du réseau interne : http://vulnerable-serveur.com/ssrf.php?url=http://10.0.0.15/

• Interface du routeur : http://vulnerable-serveur.com/ssrf.php?url=http://10.0.0.1/

D’autres exploitations peuvent être réalisées : XML External Entity (XXE), Cross-Site Scripting (XSS), injection de commande, etc.

C’est la fonction file_get_contents qui ouvre la brèche. Cependant, d’autres fonctions peuvent également en être la source, les plus classiques étant :

• file_get_contents()
• fopen()
• fread()
• fsockopen()
• curl_exec()

Ces fonctions vulnérables ne se limitent pas à php mais peuvent se retrouver dans d'autres languages.

Differents types de SSRF:

• Content-Based: Le contenu de la ressource chargée est retourné par le serveur (echo $content;)
• Boolean-Based : la réponse du serveur est différente que la ressource existe ou non
• Error-Based : une erreur, HTTP (404 ou 500) par exemple, permettant de déduire les ressources existantes ou non
• Time-Based : dans le cas où la réponse du serveur reste la même que la ressource existe ou non, le temps de réponse peut quant à lui varier de manière significative

Detection et exploitation

Outils d'exploitation semi-automatique: https://github.com/swisskyrepo/SSRFmap

Evasion de filtre:

1. Scanner le reseau interne:

L’application pourrait cependant exiger que la valeur saisie soit un nom de domaine, et non une adresse IP, empêchant une exploitation de type « ?url=http://192.168.1.100 »

Une méthode simple de contournement est d’acheter n’importe quel domaine et d’ajouter l’enregistrement DNS vers l’IP voulu. Par exemple, on pourrait réaliser les enregistrements DNS suivants :

1.mon-domaine-de-test.com -> 192.168.1.1 2.mon-domaine-de-test.com -> 192.168.1.2 … 254.mon-domaine-de-test.com -> 192.168.1.254

On pourrait ensuite scanner le réseau avec : « ?url=http://100.mon-domaine-de-test.com ».

--> Methode contraignante

• Utilisation de la plateforme nip.io

Il suffit de saisir .nip.io : le serveur DNS va dynamiquement fournir l’adresse IP saisie comme IP correspondante. Par exemple : http://192.168.1.100.nip.io permettrait d’accéder à l’IP 192.168.1.100.

Si le filtre est un peu plus restrictif (pas de chiffres dans le sous-domaine par exemple), on peut ajouter n’importe quelles valeurs avant l’IP : http://this.bypass-filter.192.168.100.nip.io donne le même résultat que précédemment.

2. Cibler le serveur vulnérable

Une vérification peut etre faite sur le paramètre url vulnérable, ne permettant pas de saisir localhost ou 127.0.0.1.

Plusieurs méthodes peuvent permettre de contourner cette restriction et cibler le serveur :

• Utiliser NIP.IO mentionné précédemment : 127.0.0.1.nip.io

• Utiliser d’autres domaines prévus à cet effet : http://spoofed.burpcollaborator.net ou http://localtest.me (enregistrés à l’adresse 127.0.0.1)

• Utiliser des valeurs décimales : http://2130706433/ (= http://127.0.0.1)

Pour aller plus loin : https://github.com/swisskyrepo/PayloadsAllTheThings

Remédiation:

Mettre en place des regles sur les ressources chargées

• Les noms DNS et/ou adresses IP autorisées En l’absence de localhost et 127.0.0.1, cela empêchera l’accès aux services/fichiers du serveur.
• L’accès illégitime au réseau interne sera empêché.
• Les protocoles autorisés L’utilisation de file://, sftp://, sera alors empêché.

XSS (Cross Site Scripting Stored/Reflected)

Faille de sécurité qui permet à un attaquant d'injecter dans un site web un code client malveillant.

Ce code est exécuté par les victimes et permet aux attaquants de contourner les contrôles d'accès et d'usurper l'identité des utilisateurs.

Ces attaques réussissent si l'application Web n'emploie pas assez de validation ou d'encodage. Le navigateur de l'utilisateur ne peut pas détecter que le script malveillant n'est pas fiable et lui donne donc accès à tous les cookies, jetons de session ou autres informations sensibles propres au site, ou permet au script malveillant de réécrire le contenu HTML.

• Objectif :

Détourner la logique d’une application web et permettre par exemple le vol de cookies ou de jetons de session, l’altération de données ou de contenus, l’exécution d’un malware, etc. Les possibilités d’exploitation d’une faille XSS sont nombreuses

3 Catégories:

• Attaques XXS stockées:

Le script injecté est stocké en permanence sur les serveurs cibles. La victime extrait ensuite ce script malveillant du serveur lorsque le navigateur envoie une demande de données.

• Les attaques XSS reflétées:

Lorsqu'un utilisateur est trompé en cliquant sur un lien malveillant, en soumettant un formulaire spécialement conçu ou en naviguant sur un site malveillant, le code injecté se rend sur le site Web vulnérable.

Le serveur Web renvoie le script injecté au navigateur de l'utilisateur, par exemple dans un message d'erreur, un résultat de recherche ou toute autre réponse incluant des données envoyées au serveur dans le cadre de la demande. Le navigateur exécute le code car il suppose que la réponse provient d'un serveur "de confiance" avec lequel l'utilisateur a déjà interagi.

• Les attaques XSS basées sur DOM*

La charge utile est exécutée à la suite de la modification de l'environnement DOM (dans le navigateur de la victime) utilisé par le script d'origine côté client.

La page elle-même ne change pas, mais le code côté client contenu dans la page s'exécute de manière inattendue en raison des modifications malveillantes apportées à l'environnement DOM.

La plupart du temps, les propriétés DOM telles que document.location, document.write et document.anchors sont utilisées pour lancer ce type d’attaque XSS. Cependant, cette vulnérabilité est plutôt rare car il est très difficile de l’identifier.

Remarque:

Le scoring CVSS est principalement affecté par

• Le changement de scope ( la vulnérabilité du composant web est transféré vers le navigateur du client)

• Confidentialité : Low Les informations du navigateur de la victime associées au composant vulnérable peuvent être lues par le code JavaScript malveillant et envoyées à l'attaquant.

• Intégrité : Low Les informations du navigateur de la victime associées au composant vulnérable peuvent être modifiées par le code JavaScript malveillant.

Remédiation:

Il faut partir du principe que les données recu de l'application Web ne sont pas toujours sûres.

• L’encodage (ou échappement) des données en entrée ou en sortie reste la mesure de sécurité essentielle pour prévenir les attaques XSS.

il s’agit de remplacer les caractères spéciaux par des valeurs encodées, de manière à ce que toute donnée saisie par un utilisateur soit traitée (reçue et interprétée) comme du texte, plutôt que comme du code.

• Filtrage des données reçues côté client.

Cela signifie que l’ensemble des données doit passer par un filtre qui élimine les caractères dangereux comme la balise <script>, les gestionnaires d’événements HTML comme onActivate(), onClick(), les éléments JavaScript, etc. Cette méthode fonctionne essentiellement pour les attaques XSS stockées.

• Valider les entrées utilisateurs:

Tous les champs de saisie correspondent au type de données attendu. Par exemple, pour un champ de saisie d’un numéro de téléphone, il doit être impossible pour un utilisateur d’insérer du texte. De la même manière, les balises HTML n’étant pas légitimes dans ce type de formulaire, elles doivent être validées pour empêcher les attaquants de soumettre des scripts malveillants.

• CSP (Content Security Policy) développé par Mozilla

Ce standard de sécurité permet de contrôler (restreindre via autorisation) les sources externes (autres sites web) de récupération de données.

Si ce mécanisme est en place, le navigateur sera autorisé à accéder uniquement aux ressources figurant sur la liste blanche, en ignorant tous les autres domaines. Les scripts injectés ne seront donc pas exécutés même si un attaquant découvre des possibilités d’injection XSS.

Ressources:

PayloadsAllTheThings

Annexes

*DOM: Document Object Model est une represention objet des données qui composent la structure et le contenu d'un document sur le web (HTML ou XML) = Interface de programmation (independant de tout language)

Pour rappel (non exhaustif), une XSS permet de réaliser des attaques de :

• Ad-Jacking, en injectant des publicités invasives afin de générer des revenus à l'insu du site légitime ;

• Click-Jacking, ajout d’une surcouche (overlay) cachée sur une page pour hijack (capturer / manipuler) des clics d'une victime ;

• Session Hijacking, en dérobant les cookies de session des victimes non protégées par le drapeau HttpOnly ;

• Content-Spoofing, en altérant le rendu des pages, le DOM, toutes les ressources côté client pour afficher un autre contenu ;

• Credential Harvesting, en modifiant le rendu pour afficher une fausse page/mire d'authentification en vue de dérober les crédentiels d'une victime ;

• Forced Downloads, pour forcer le téléchargement d'un fichier malicieux sur un domaine de confiance / légitime ;

• Crypto Mining, en exploitant les ressources du CPU des victimes afin de générer de la cryptomonnaie ;

• Anti-CSRF bypass, contournement de toutes les protections anti-CSRF (token dans des forms, en cookies, referer, etc.) ;

• Keylogging, en définissant des events JavaScript capturant les frappes du clavier sur la page impactée ;

• Recording audio, avec les évolutions de JavaScript et HTML5, il est possible d'accéder au microphone de la victime et d'enregistrer / espionner les échanges vocaux (nécessite une autorisation) ;

• Taking pictures, accès à la webcam de la victime et espionnage (nécessite une autorisation) ;

• Geo-location, accès à la géolocalisation de la victime (nécessite une autorisation) ;

• Stealing HTML5 web storage data, une XSS permet d'atteindre et de dérober le contenu des nouveaux lieux de stockage locaux de données utilisés par les applications modernes, dont window.localStorage() et window.webStorage() ;

• Browser & System Fingerprinting, récupération du browser name, version, plugins installés et leurs versions, système d'exploitation, architecture, heure, langue, résolution d'écran, etc. ;

• Network scanning, via une XSS un attaquant a la main sur le site chargé dans le navigateur d'une victime, donc il se situe dans le réseau de la victime et peut scanner des ranges d'IP et ports à sa convenance (via JavaScript) [BEE] ;

• Crashing Browser, simplement pour nuire à des victimes, en réalisant des traitements très consommateurs en ressources ou via des exploits DoS destinés à une version précise ;

• Stealing information, récupération d'informations sensibles / personnelles sur une page web authentifiée sous le compte d'une victime, et les transmettre au serveur de l'attaquant ;

• Redirecting, une XSS permet la redirection d'une victime et donc engendre une Open-Redirect ;

• Tab-napping, en détectant l'activité d'une victime (pas de clic ni de touche clavier durant 1 minute, la victime a quitté son poste). En conséquence il est possible de remplacer la page courante par une autre à son insu ;

• Capturing screenshot, via HTML5 Canvas, il est possible de simuler la prise d'un screenshot complet de la page web courante (très employé avec les Blind-XSS) ;

• Perform Actions, l'attaquant ayant la main sur le navigateur, celui-ci peut réaliser toutes les actions souhaitées dans le contexte de la victime. Sur un réseau social : poster des messages, XSS-worm, etc.

• Black-SEO, avec les « bots » tels que le Google-Bot qui reposent sur des navigateurs headless (et donc interprète le JavaScript), il est possible de nuire au ranking et référencement d'un site web en injectant et référençant des URL comprenant des XSS qui injectent du contenu nuisible (Viagra, etc.) ;

• Brute-force / user-enumeration distributed, en exploitant une XSS et des faiblesses au niveau des CORS, un attaquant peut profiter de toutes les victimes de son XSS pour brute-forcer un espace authentifié tiers ou réaliser une énumération de manière distribuée avec la multitude d'adresses IP que lui fournissent ses victimes.

XXE

Sql

Definition:

L'injection SQL (SQLi) est une vulnérabilité de sécurité qui permet à un attaquant d'interférer avec les requêtes qu'une application fait à sa base de données.

Elle permet généralement à un pirate de visualiser des données qu'il n'est normalement pas en mesure d'extraire. Il peut s'agir de données appartenant à d'autres utilisateurs ou de toute autre donnée à laquelle l'application elle-même peut accéder.

Dans de nombreux cas, un attaquant peut modifier ou supprimer ces données, ce qui entraîne des changements persistants dans le contenu ou le comportement de l'application.

Dans certains cas , le serveur ou l'infrastructure sous jacent peut etre compromis, jusqu'à effectuer des attaques de deni de service.

Principe:

Soit l'URL ( l'utilisateur clique sur lacategorie Cadeaux )

https://website.com/produits?categorie=Cadeaux

L'application effectue en arriere plan la requete ci-dessous sur la base de données

SELECT * FROM produits WHERE categorie = 'Cadeaux' AND disponibilité = 1

La requete indique de retourner

• Tous les details
• de la table produits
• de catégorie "Cadeaux"
• et de disponibilité 1

disponibilité =1 permet d'afficher uniquement les produits disponible ( les produits non disponible auront la valeur 0 - disponibilité=0)

L'application n'implemente aucune sécurité contre les injection SQL , il est donc possible de construire une requete de type

https://website.com/produits?categorie=Cadeaux'--

SELECT * FROM produits WHERE categorie ='Cadeaux'--' AND released=1

Les caracteres -- sont interpreté comme un commentaire dans une requete SQL , le reste de la requete est ignoré, tous les produits ( disponible ou non ) sont affichés

Il est possible d'utiliser d'autre combinaisons de caracteres pour aller plus loin

https://website.com/produits?categories=Cadeaux'+OR+1=1--

SELECT * FROM produits WHERE categorie = 'Cadeaux' OR 1=1--' AND disponible = 1

1=1 etant toujours vrai, la suite de la requête est ignorée

Ce type d'injection peut invalider la logique de l'application

Exemple: Cas d'une authentification d'un utilisateur avec son mot de passe : SELECT * FROM users WHERE username = 'administrator'--' AND password = ''

--> La connexion d'un utilisateur s'effectue sans mot de passe

Recuperer des données d'une autre table de la base de données (UNION)

SELECT name, description FROM produits WHERE categorie= 'cadeaux'

l'ajout de ces caractères permet de récuperer les noms et mot de passe de tous les utilisateurs

' UNION SELECT username, password FROM users--

Recuperer des information de la base de données ( Version , schema des tables, ... )

SELECT * FROM v$version
SELECT * FROM information_schema.tables

Blind SQL injection :

De nombreux cas d'injection SQL sont des vulnérabilités aveugles. Cela signifie que l'application ne renvoie pas les résultats de la requête SQL ou les détails des erreurs de base de données dans ses réponses. Les vulnérabilités aveugles peuvent toujours être exploitées pour accéder à des données non autorisées, mais les techniques utilisées sont généralement plus compliquées et plus difficiles à mettre en œuvre.

...

Detection des injections SQL :

L'injection SQL peut être détectée manuellement en utilisant un ensemble systématique de tests pour chaque point d'entrée de l'application.

• Soumission du caractère guillemet simple ' et recherche d'erreurs ou d'autres anomalies.
• soumettre une syntaxe SQL spécifique qui évalue la valeur de base (originale) du point d'entrée et une valeur différente, et rechercher les différences systématiques dans les réponses de l'application qui en résultent.
• Soumettre des conditions booléennes telles que OR 1=1 et OR 1=2, et rechercher les différences dans les réponses de l'application.
• Soumission de charges utiles conçues pour déclencher des délais lorsqu'elles sont exécutées dans le cadre d'une requête SQL, et recherche de différences dans le temps de réponse.
• Soumettre des charges utiles OAST conçues pour déclencher une interaction réseau hors bande lorsqu'elles sont exécutées dans le cadre d'une requête SQL, et surveiller les interactions qui en résultent.

Les injections sql peuvent etre réalisé sur les differentes partie d'une requete sql

• Dans les instructions UPDATE, dans les valeurs mises à jour ou dans la clause WHERE.
• Dans les instructions INSERT, dans les valeurs insérées.
• Dans les instructions SELECT, dans le nom de la table ou de la colonne.
• Dans les instructions SELECT, dans la clause ORDER BY.

Injection SQL dans d'autres contextes:

Les attaques par injection SQL peuvent être utiliser sur n'importe quelle entrée contrôlable qui est traitée comme une requête SQL par l'application. Par exemple, certains sites web prennent des données au format JSON ou XML et les utilisent pour interroger la base de données.

Ces différents formats peuvent même fournir des moyens alternatifs pour obscurcir les attaques qui sont autrement bloquées par les WAFs et autres mécanismes de défense. Les implémentations faibles se contentent souvent de rechercher les mots-clés d'injection SQL courants dans la requête, de sorte que vous pouvez contourner ces filtres en encodant ou en échappant simplement les caractères dans les mots-clés interdits. Par exemple, l'injection SQL basée sur XML suivante utilise une séquence d'échappement XML pour encoder le caractère S dans SELECT :

<stockCheck>
    <productId>
        123
    </productId>
    <storeId>
        999 &#x53;ELECT * FROM information_schema.tables
    </storeId>
</stockCheck>

Le decodage s'effectuera par le serveur avant d'etre envoyé à la BDD

Injection SQL de 2e ordre ou Injection SQL stocké (Stored sql injection )

l'application prend les données de l'utilisateur à partir d'une requête HTTP et les stocke en vue d'une utilisation ultérieure. Cela se fait généralement en plaçant les données dans la BDD, mais aucune vulnérabilité n'apparaît au moment où les données sont stockées. Plus tard, lors du traitement d'une autre requête HTTP, l'application récupère les données stockées et les incorpore dans une requête SQL de manière non sécurisée.

.

L'injection SQL de second ordre survient souvent dans des situations où les développeurs sont conscients des vulnérabilités de l'injection SQL et gèrent donc en toute sécurité le placement initial de l'entrée dans la base de données. Lorsque les données sont traitées ultérieurement, elles sont considérées comme sûres, puisqu'elles ont été placées dans la base de données en toute sécurité. À ce stade, les données sont manipulées de manière dangereuse, car le développeur les considère à tort comme fiables

Specificité des BDD:

Bien qu'il y ait des caratcteristiques communes dans l'utilisation du language SQL , il est necessaire de prendre en compte les specificités de chaque editeur Les differences peuvent etre sur :

• Les commentaires
• la syntax pour concatener des chaines de caracteres
• le regroupement de requetes
• les messages d'erreur
• la structure interne des tables ( nom des tables , des schemas etc )

Exemple: Concatenation de chaine :

Oracle: 'foo'||'bar' Microsoft: 'foo'+'bar' PostgreSQL: 'foo'||'bar' MySQL: 'foo' 'bar' [Note the space between the two strings] CONCAT('foo','bar')

Commentaires:

Oracle: --comment Microsoft: --comment /comment/ PostgreSQL: --comment /comment/ MySQL: #comment -- comment [Note the space after the double dash] /comment/

Mesure preventive contre les injections SQL

La plupart des cas d'injection SQL peuvent être évités en utilisant des requêtes paramétrées (prepared statement ) au lieu de la concaténation de chaînes de caractères dans la requête.

Le code suivant est vulnerable car les entrées utilisateur sont directement implementeés dans la requete

String query = "SELECT * FROM produits WHERE categorie = '"+ input + "'";
Statement statement = connection.createStatement();
ResultSet resultSet = statement.executeQuery(query);

Elle peut etre réecrites de manière plus sûre. L'entrée de l'utilisateur ne vient pas interferer avec la structure de la requête

PreparedStatement statement = connection.prepareStatement("SELECT * FROM produits WHERE categorie = ?");
statement.setString(1, input);
ResultSet resultSet = statement.executeQuery();

Pour qu'une requête paramétrée soit efficace dans la prévention des injections SQL, la chaîne utilisée dans la requête doit toujours être une constante codée en dur et ne doit jamais contenir de données variables, quelle qu'en soit l'origine.

Contournement de la logique métier / failles logiques

Différentes des vulnérabilités techniques liées au code de l'application Web ou implementation de configuration Plus difficile à identifier que les vulnérabilités techniques (XSS, injections SQL, CSRF…)

Principalement du à un manque de rigueur dans le design et d’un manque de tests approfondis d’un point de vue sécurité sur les processus métier de la solution.

Méthodologie:

Tester la sécurité logique nécessite d’aller plus loin que des outils de sécurité automatisés. Ces failles sont découvertes lors des tests d’intrusion.

Il est nécessaire d’étudier et de comprendre le fonctionnement prévu (et non prévu) d’un site ou d’une application et de penser « attaque » : quels gains pourraient obtenir des attaquants dans cette situation ?

Détecter les failles logiques nécessite :

• une compréhension complète du fonctionnement de l’application : règles métiers, processus…

• découper et modéliser le workflow,

• identifier où sont effectués les contrôles, et où ils ne sont pas effectués, d’analyser les contrôles effectués, les paramètres envoyés, les réponses retournées…

Exemple:

Ex1 : Attaque temporelle

Sur un site de reservation en ligne de billet , l'application bloque temporairement la reservation de billets pour les autres clients, le temps de réaliser la transaction. Une attaque possible est de créer un script( ou manuellement via l'interface) qui reserve tous les billets , empêchant tous les clients d'utiliser le site. -> Deni de service pour les autres clients

Impact: financier, image de marque, perte de confiance

Ex2: Attaque de contournement de workflow

Un site web de commerce électronique permettait aux utilisateurs de voir le produit et son prix, de sélectionner ce produit, d'acheter un résumé, puis de passer à la caisse. Le processus a été conçu pour être exécuté dans cet ordre précis uniquement. L'administrateur n'a pas défini de règles pour un ordre différent.

Un pirate a découvert qu'il pouvait retourner au panier d'achat après avoir injecté des prix personnalisés dans l'URL. Le serveur du site web l'a exécuté et a permis à l'attaquant de payer les prix révisés.

Ex3: Mauvais traitement de données

Un site permet le transfert d'un montant entre 2 comptes

$transferAmount = $_POST['amount'];
$currentBalance = $user->getBalance();

if ($transferAmount <= $currentBalance) {
    // Complete the transfer
} else {
    // Block the transfer: insufficient funds
}

Si l'attaquant insère un montant négatif dans le champ "tranferAmount" (-1000) Cette valeur est toujours inférieur à "currentBalance", le compte de l'attaquant peut être créditer du montant (1000).

Quelques grandes « catégories » de failles logiques :

• les failles liées à un manque de robustesse dans un workflow, qui peut être contourné,
• les failles liées à un manque de contrôle sur les données, qui influencent les actions en cours d’exécution,
• les failles liées à une réaction inattendue de l’application,
• les failles liées à des attaques temporelles,
• les failles liées à un assemblage de fonctionnalités, qui deviennent problématiques uniquement une fois combinées.

Remédiation:

• Implémenter les contrôles adéquats à chaque étape de chaque workflow permet de s’assurer que la logique métier ne peut pas donner lieu à des abus ou être contournée

• Pentesteurs avec des compétences particulières pour ce type de faille

Man in The Middle (attaque de l'homme du milieu)

1. Principe

L'attaquant intercepte et altère la communication entre l'utilisateur et le serveur

Les attaques MITM peuvent affecter n'importe quel échange de communication, y compris les communications entre appareils et les objets connectés (IoT).

2 categories:

• Active :

L'attaquant empêche le client initial de communiquer avec le serveur et se replace ensuite dans la session.

À partir de ce moment, l'attaquant communique avec le serveur et peut faire tout ce qu'un utilisateur normal peut faire.

Il peut altérer les données ou collecter des informations sensibles susceptibles d'avoir un impact ultérieur.

• Passive

L'attaquant surveille les données qui circulent sur le réseau sans interrompre la communication proprement dite. L'intrus écoute la communication mais ne modifie en rien le flux de messages. Il peut collecter toutes les données qui passent par le réseau, ce qui peut entraîner une attaque active ultérieurement.

2. Techniques communes:

   a. Rogue Access Point (Point d'accès frauduleux)

   Dispositif/équipement installé sans autorisation qui est configuré pour tromper les utilisateurs qui se connecte automatiquement au wifi en se faisant passer pour des points d'accès public.

   b. Arp (Address Resolution protocol) spoofing

ARP (Address Resolution Protocol) est un protocole de résolution d'adresses qui traduit les adresses MAC physiques de 40 bits en adresses IP logiques de 32 bits. Essentiellement, il traduit les adresses de la couche 3 du réseau en adresses de la couche 2 de liaison de données.

Protocole utilisé pour trouver l'adresse MAC à partir d'une adresse IP Chaque demande ou réponse ARP est fiable, il est donc possible d'envoyer des requêtes ( sur un domaine de collision/LAN) pour indiquer que l'attaquant est le routeur.

Les clients peuvent accepter des réponses même s'ils n'ont pas envoyé de demande.

Ex d'outil: arpspoof ( paquet dsniff de Debian)

arpspoof -i eth0 192.168.1.1

Commande qui annonce aux clients du réseau que la machine qui émet cette requête est le routeur Il faut également , forwarder tous les paquets vers le routeur réel sinon aucune machine n'est en mesure de communiquer à l'extérieur (réseau différent)

L’utilisation de commutateurs de niveau 3, capables de gérer l’association MAC/IP/port est également une solution au problème.

Ou solution active : arpwatch : détecte les changements d'association adresses MAC/IP

Mesure de protection: HTTPS

Nota: arp spoofing ( usurpation d'une adresse mac ; ex 1 hote) / arp poisonning ( empoisonnement arp , à l'echelle d'un réseau)

c. DNS spoofing ( Usurpation de DNS) ou DNS Cache poisonning ( empoisonnement du cache DNS)

Même principe que l'arp spoofing L'usurpation de DNS consiste à remplacer les adresses IP stockées dans le serveur DNS par des adresses sous le contrôle de l'attaquant. Ainsi, lorsqu'un utilisateur tente d'accéder à un site web particulier, il est dirigé vers le site web malveillant placé par l'attaquant dans le serveur DNS usurpé.

L'attaquant doit au préalable prendre le contrôle du "resolver" DNS (local) en utilisant une faille de sécurité de l'équipement ou en récupérant les identifiants ( Box, serveur, routeur, ...)

Mesure corrective:

Changer régulièrement le mot de passe du routeur ( si le routeur fait la résolution DNS) Utilisation de DNSSEC

Tips:

Vider le cache DNS régulièrement :

Windows : ipconfig /flushdns

Linux : systemd-resolve --flush-caches

Chrome: chrome://net-internals/#dns

d. Email Hijacking 

e. ICMP Redirection

f. DHCP spoofing

g. SSL stripping

Mesure corrective ou prevention:

• Ne pas utiliser les réseaux public(utilisation de VPN non gratuit) ,
• Utiliser ( forcer ) HTTPS
• Changer régulièrement les mots de passe des AP wifi et routeur
• restreindre le réseau local au seul machine autorisés
• DNSSEC