Réalisez un test d'intrusion web

Comprenez la notion de chiffrement

Dans ce chapitre, nous allons nous intéresser à la qualité du chiffrement des flux chiffrés.

On parle de chiffrement et non pas de cryptage pour désigner des flux et données protégés par des mécanismes cryptographiques.

On utilise le terme "déchiffrement" quand on connaît les clés pour retrouver le message en clair, et le terme "décryptage" quand on ne connaît pas la clé de déchiffrement et qu’on doit la retrouver.

C'est pour ça que les hackers décryptent des flux chiffrés : ils n’ont pas la clé !

Pour établir une communication TLS :

1. Le client entre en contact avec le serveur et lui indique les protocoles et les suites de chiffrement qu’il supporte.

2. Le serveur lui répond en lui communiquant son certificat et en indiquant quel protocole et quelle suite vont être utilisés.

3. S’ensuit plusieurs opérations et échanges entre le client et le serveur pour achever ce qu’on appelle la "négociation TLS" ou "TLS handshake" en anglais et ainsi sécuriser la communication à venir.

Un chiffrement de mauvaise qualité vaudra toujours mieux qu’une absence de chiffrement. Comme pour l’authentification. Mais un chiffrement de qualité, c’est mieux :

1. Cela sécurise mieux les échanges (logique).

2. Il existe aussi des services et entreprises qui notent les sites exposés sur internet (et la qualité du chiffrement entre en ligne de compte).

Vérifiez la qualité du chiffrement

Si l’on a besoin de vérifier que le chiffrement est bien de qualité, c’est qu’il n’est pas non plus infaillible !

En simplifiant, sur les points suivants :

• une qualité insuffisante du certificat utilisé, qui pourrait en faciliter la falsification par un attaquant ;

• les protocoles proposés par le serveur, qui peuvent contenir des défauts d’implémentation ;

• les suites de chiffrement proposées, parfois faibles ;

• la librairie utilisée pour le chiffrement, qui peut comporter des vulnérabilités.

Vous savez, il s’agit de ce fameux message :

La plupart du temps, c’est lié à un problème de certificat ;

• qui peut ne pas être dans sa période de validité ;

• dont le champ  subject name  ne correspond pas au nom DNS du site ;

• dont l’autorité de certification n’est pas connue de votre ordinateur ;

• qui peut simplement être révoqué ;

• etc.

Mais il y a d’autres points à regarder dans le cadre d’un test d’intrusion, et notamment :

• la taille de clé du certificat, qui ne doit pas être trop faible (< 2 048 bits) ;

• l'algorithme de hachage (SHA-256 avec RSA ou supérieur).

Nous allons également vérifier que les librairies utilisées ne sont pas vulnérables ou ne comportent pas de faiblesses qui pourraient dégrader la robustesse du chiffrement. Car oui, le chiffrement n'est pas magique et est opéré par du code contenu dans ces librairies, la plus connue et répandue étant OpenSSL.

La cryptographie est plutôt complexe, et heureusement tous ces contrôles s 'automatisent très bien !

Pour cela, il existe plusieurs outils :

• certains en ligne comme SSLlabs de la société Qualys ;

• et d’autres, locaux et en CLI (ligne de commande), comme SSLscan et testssl.sh.

• les scanners de vulnérabilité que nous avons évoqués dans le chapitre précédent sont généralement en mesure de mener ces tests.

Nous avons aussi évoqué des notions aux noms un peu barbares :

• protocoles de chiffrement ;

• suites de chiffrement.

Voyons maintenant comment comprendre ces notions, à notre niveau de pentester, dans le cadre d’un audit ou d’un test d’intrusion. On ne nous demande pas d’avoir les compétences d’un cryptologue !

Faites la différence entre protocoles de chiffrement et suites de chiffrements

Les protocoles de chiffrement

Ces protocoles sont les suivants :

• SSL v2 ;

• SSL v3 ;

• TLS v1.0 ;

• TLS v1.1 ;

• TLS v1.2 ;

• TLS v1.3. 

Pour chaque protocole, il existe une liste de suites de chiffrements compatibles et acceptées.

Les suites de chiffrements

Les suites de chiffrements vont être de la forme suivante :

<algo échange de clé>-<algo  authentification>-<algo  chiffrement symétrique et taille de clé>-<algo signature>

Ce qui donne par exempleECDHE-RSA-AES128-GCM-SHA256, avec :

• ECDHE  pour l’échange de clés ;

• RSA  pour l’authentification ;

• AES-128  pour le chiffrement ;

• GCM  pour le mode d’opération du chiffrement par bloc (ce qui ne nous intéresse que peu dans notre cas de pentester, sauf dans certains cas très particuliers) ;

• SHA-256  pour la signature.

C’est simplement une convention de nommage différente. Pour les suites de chiffrement, les tirets séparent les “fonctions” de chaque terme, tandis que pour les algorithmes de chiffrement comme AES ou de hachage comme SHA, le tiret sépare le nom de la fonction de la taille de clé.

Appliquez les bonnes pratiques

La cryptographie est un domaine qui peut sembler complexe, mais son application ne l’est pas !

La configuration recommandée est la suivante :

• redirection : automatique du canal HTTP vers le canal HTTPS (i.e. port 80 vers port 443 par défaut) ;

• certificat : configurer une durée de vie de 90 jours dans l’idéal, dans tous les cas inférieure à 1 an ;

• protocoles autorisés : TLS 1.3 et TLS 1.2 ;

• suites de chiffrement : tailles de clé > 128 bits, fonction de hachage > 256 bits.

D’un autre côté, les puissances de calcul augmentant et les vulnérabilités apparaissant, les recommandations évoluent. Il est alors nécessaire de réviser régulièrement la configuration de son serveur web avec les recommandations à jour.

Si vous testez par exemple une application vieille de 10 ans qui n’a jamais évolué pour diverses raisons techniques, il y a des chances que vous ne puissiez pas beaucoup agir sur la qualité du chiffrement ! Déjà, si l’application possède un chiffrement des flux, le commanditaire pourra s’estimer heureux… C’est donc à bien prendre en compte dans vos recommandations.

À vous de jouer

Challenge

1. Connectez-vous à Root Me.

2. Cliquez sur ce lien (CTF OpenClassrooms - DVWA) pour démarrer ou rejoindre l'environnement.

3. Une fois sur la page, attendez qu'un cartouche vert apparaisse : 

4. L’adresse à analyser y sera indiquée : lancez-vous !

Vos objectifs sont de vérifier les points suivants  de la configuration SSL du service :

• La qualité du certificat utilisé : 

  • Est-ce que le CN ou le SAN du certificat correspond au nom de domaine du site ?

  • Quelle est la taille de la clé ?

  • Quel est l’algorithme de signature ?

• Les protocoles proposés par le serveur.

• Les suites de chiffrement supportées.

• La présence de vulnérabilités connues dans la librairie utilisée.

Un dernier conseil : utilisez plutôt testssl.sh pour cet exercice.

Solution

En résumé

• Le chiffrement des communications permet de s’assurer de la sécurité des flux entre les clients de l’application et le serveur, contre l’interception et la modification des flux par un attaquant. C’est le principe de l’attaque de l’homme du milieu.

• Mieux vaut une application avec un chiffrement laissant à désirer qu’une application accessible sans chiffrement, ou “en clair”.

• La qualité du chiffrement peut être mise à mal par plusieurs facteurs, et notamment : le certificat, les protocoles de chiffrement supportés et les suites de chiffrement acceptées.

• Bien que la cryptographie soit un sujet complexe, ce sont des vérifications qui s’automatisent bien, et des outils très performants sont disponibles en ligne ou en local : ssllabs, sslscan, testssl.sh.

Nous en avons terminé pour cette partie ! Dans la suivante, nous allons commencer à nous intéresser de plus près à l’application web en elle-même, et allons découvrir l’outil avec lequel vous allez le plus travailler : le proxy d’interception !