Inspection SSL/TLS et attaques de type intermédiaire dans le navigateur

Le protocole HTTPS représente désormais plus de 90 % du trafic Web, notamment les téléchargements de logiciels malveillants, les canaux C2 et l’exfiltration de données. Les outils de sécurité périmétrique incapables d’inspecter TLS ne voient que des blocs chiffrés, ce qui crée un angle mort que les attaquants exploitent activement. L’inspection SSL/TLS (également appelée interception SSL, inspection SSL ou inspection approfondie des paquets HTTPS) permet aux passerelles de sécurité de déchiffrer, d’inspecter puis de chiffrer à nouveau le trafic HTTPS avant qu’il n’atteigne le terminal. Cette visibilité est essentielle pour le filtrage du contenu Web, la DLP et l’analyse antimalware dans les environnements où la majeure partie du trafic utilise HTTPS.

L’inspection SSL est techniquement une attaque de type intermédiaire contrôlée, réalisée par l’infrastructure de sécurité de l’organisation elle-même. Le processus est le suivant : Étape 1 : le client établit une connexion TLS avec le proxy (à l’aide du certificat du proxy signé par la CA d’entreprise). Étape 2 : le proxy établit une session TLS distincte avec le serveur réel en utilisant le véritable certificat de celui-ci. Étape 3 : le proxy déchiffre le trafic provenant du client, l’inspecte, puis le rechiffre et le transmet au serveur, et inversement. Le client fait confiance au certificat du proxy, car le certificat CA d’entreprise est préinstallé sur tous les terminaux administrés via MDM ou Group Policy.

Tout le trafic ne doit pas être inspecté. Les organisations excluent généralement les catégories contenant des données sensibles sur le plan juridique ou éthique : les sites bancaires et financiers, les portails Healthcare, les bases de données de recherche juridique, les URL de transparence des certificats et OCSP (pour éviter de perturber la validation des certificats) ainsi que les sites qui utilisent l’épinglage de certificat (qui rejetteront les certificats resignés et empêcheront l’application de fonctionner). Les exclusions sont gérées sous forme de liste de contournement dans la règle d’inspection. Dans certaines juridictions, les lois relatives à la surveillance des employés peuvent limiter l’inspection de la navigation personnelle, ce qui impose une information claire dans les règles d’utilisation acceptable.

L’épinglage de certificat est une technique par laquelle une application intègre en dur le certificat ou la clé publique attendue pour un serveur donné et refuse de se connecter si le certificat ne correspond pas, même s’il est valide et approuvé par le magasin de certificats CA du système d’exploitation. Cela empêche l’inspection SSL, car le certificat resigné par le proxy ne correspond pas à la valeur épinglée. Les applications mobiles (applications bancaires ou de paiement) utilisent fréquemment l’épinglage de certificat comme mesure contre les attaques de type intermédiaire. Les entreprises doivent contourner l’inspection pour les applications utilisant l’épinglage, faute de quoi elles ne fonctionneront plus. Cela signifie également que les attaquants souhaitant contourner l’inspection SSL avec leurs logiciels malveillants peuvent mettre en œuvre l’épinglage.

Le SSL stripping est une attaque de type intermédiaire dans laquelle un attaquant intercepte le trafic HTTPS et le rétrograde en HTTP, ce qui lui permet de lire et de modifier le contenu en clair. L’attaque fonctionne sur les connexions qui commencent en HTTP avant une redirection vers HTTPS : l’attaquant intercepte la requête HTTP initiale, maintient une connexion HTTP avec la victime tout en établissant une connexion HTTPS avec le serveur légitime, puis relaie le trafic de manière transparente. Du point de vue de la victime, le site semble utiliser HTTP. Le HTTP Strict Transport Security (HSTS) se défend contre le SSL stripping en indiquant aux navigateurs d’utiliser systématiquement HTTPS pour un domaine, même si l’utilisateur saisit HTTP.

Une attaque de type Man-in-the-Browser (MitB) est une forme de cheval de Troie bancaire qui s’insère dans le navigateur Web, sous la forme d’une extension malveillante ou d’une injection dans le processus du navigateur, et modifie les pages Web et les transactions à l’insu de l’utilisateur. Contrairement à une attaque réseau de type intermédiaire, le MitB opère à l’intérieur de la session chiffrée, au niveau du navigateur ; TLS n’offre donc aucune protection. Les logiciels malveillants MitB (Zeus, SpyEye) peuvent modifier les montants des paiements, altérer les numéros de compte des bénéficiaires, intercepter les mots de passe à usage unique et modifier discrètement les formulaires après leur saisie par l’utilisateur. Les modifications se produisent après le déchiffrement TLS et avant que l’utilisateur ne voie la page affichée.

Les logiciels malveillants MitB s’accrochent aux API du navigateur au niveau de l’application. Sous Windows, ils injectent du code dans les processus du navigateur (Chrome, Firefox, IE) au moyen d’une injection de DLL ou d’un détournement de COM, puis s’accrochent aux fonctions JavaScript et aux API de manipulation du DOM. Lorsqu’un utilisateur consulte son compte bancaire, le logiciel malveillant intercepte le JavaScript qui affiche la page et la confirmation de transaction, puis remplace le compte destinataire par celui de l’attaquant. Le serveur voit la transaction correcte et les journaux HTTPS côté serveur ne montrent rien d’inhabituel. L’utilisateur voit la confirmation correcte — avec le montant souhaité — alors que le virement réel est effectué vers le compte de l’attaquant.

Se défendre contre MitB nécessite des contrôles à plusieurs niveaux. Isolation du navigateur (Menlo Security, Zscaler Browser Isolation) : le rendu du navigateur est exécuté dans une VM cloud distante et seuls les pixels sont transmis à l’écran de l’utilisateur — le logiciel malveillant ne peut pas injecter de code dans un processus de navigateur exécuté dans un environnement distant. Vérification des transactions : les banques confirment les détails de la transaction (montant + destinataire) par un canal hors bande (un OTP par SMS contenant les détails de la transaction), afin que l’utilisateur doive vérifier ce que le serveur a réellement reçu. Un EDR de point de terminaison qui détecte les injections de DLL dans les processus du navigateur peut identifier les infections MitB. L’autorisation par liste des extensions du navigateur empêche les extensions malveillantes.

Les extensions de navigateur malveillantes représentent une menace importante pour les points de terminaison. Les extensions disposent d’autorisations étendues : elles peuvent lire le contenu des pages, modifier les requêtes, intercepter les soumissions de formulaires et accéder aux cookies. Une extension se faisant passer pour un outil utile (bloqueur de publicités, mode sombre) peut dérober des identifiants, injecter des publicités, rediriger le trafic ou agir comme un agent MitB. Contrôles d’entreprise : utilisez Group Policy ou MDM pour limiter l’installation des extensions à une liste d’autorisation approuvée. Bloquez l’installation d’extensions provenant de sources autres que Chrome Web Store ou les modules complémentaires de Firefox. Auditez régulièrement les extensions installées sur les points de terminaison gérés afin de détecter les violations de la politique.

Les organisations qui mettent en œuvre une inspection SSL doivent prendre en compte ses implications pour la confidentialité des employés. De nombreuses juridictions et législations du travail exigent une information claire avant la surveillance du trafic chiffré. Bonnes pratiques : publier une Politique d’utilisation acceptable (AUP) indiquant explicitement que le trafic réseau, y compris HTTPS, peut être inspecté ; faire prendre connaissance de l’AUP aux employés lors de leur intégration ; mettre en œuvre des catégories de contournement pour les sites de banque en ligne et les sites médicaux personnels ; et conserver les journaux du trafic déchiffré uniquement pendant la durée nécessaire (généralement 30 à 90 jours). Le service juridique devrait examiner le programme d’inspection avant son déploiement, en particulier dans les pays de l’UE, où le GDPR impose des limites plus strictes à la surveillance des employés.

Certificate Transparency est un cadre (RFC 6962) qui exige que tous les certificats TLS approuvés publiquement soient consignés dans des journaux CT publics, vérifiables et en ajout uniquement, avant que les navigateurs ne leur accordent leur confiance. CT permet aux propriétaires de domaines de surveiller les certificats mal émis : si un attaquant parvient d’une manière ou d’une autre à convaincre une CA d’émettre un certificat pour votre domaine (comme cela s’est produit avec DigiNotar en 2011), les journaux CT permettent une détection quasi instantanée. Des outils comme crt.sh permettent aux équipes de sécurité de rechercher dans les journaux CT tous les certificats émis pour leur domaine. Les navigateurs appliquent CT en exigeant une preuve d’inclusion dans un journal (Signed Certificate Timestamps, SCT) intégrée à la négociation TLS.

Testez votre compréhension des concepts de CompTIA Security+ (SY0-701) présentés dans cette leçon.

Dans cette leçon, vous avez appris que l’inspection SSL/TLS déchiffre, inspecte et rechiffre le trafic HTTPS au niveau d’un proxy à l’aide d’un certificat d’une CA d’entreprise approuvé par les points de terminaison gérés ; que le contournement SSL rétrograde HTTPS vers HTTP et est neutralisé par HSTS ; et que les attaques de type man-in-the-browser injectent du code dans le processus du navigateur au-dessus de la couche TLS pour modifier les transactions de manière invisible, ce qui nécessite l’isolation du navigateur ou une vérification des transactions par un canal hors bande. Nous allons maintenant étudier le remplacement des protocoles non sécurisés par leurs équivalents sécurisés.