Qu'est-ce que le Public Key Pinning ?
Normalement, le trafic entre une application cliente et son serveur repose sur l’ infrastructure à clé publique (PKI). Bien que ce mécanisme soit suffisant pour la plupart du trafic Internet, l’ engagement de sécurité d’identité Okta Secure Identity Commitment nous oblige à tenir compte des attaquants ciblés persistants avancés, y compris les acteurs étatiques.
Okta utilise PKI et TLS comme base pour toutes les communications entre les services, y compris Okta Verify. Dans les scénarios d'attaque avancés, cependant, un certificat public hors du contrôle d'Okta pourrait être compromis et accepté par le système d'exploitation d'un appareil ou explicitement approuvé par l'utilisateur de cet appareil. Dans de tels cas, un acteur malveillant peut alors inspecter et manipuler le trafic entre Okta Verify et les points de terminaison côté serveur d'Okta via une attaque de l'intercepteur (AITM), ce qui entraîne un certain nombre de problèmes que nous expliquerons plus tard.
L’épinglage de clé publique est un moyen d’autoriser uniquement les certificats attendus par l’application cliente, bloquant tous les autres. Cela signifie que même en cas de compromission d’une autorité de certification publique (par ex. Digicert), nos applications clientes n’accepteront pas ces certificats. Au lieu de cela, un attaquant devrait avoir volé les clés privées détenues en interne d’Okta pour usurper l’identité de nos serveurs.
Exemple d'attaque : Faux réseau WiFi ou VPN
Imaginez qu'un utilisateur travaille dans un café. Un autre client du café a un ananas dans son sac à dos. Cet appareil peut usurper le WiFi du magasin et prendre agressivement le contrôle des connexions en simulant une force de signal élevée, entre autres tactiques intelligentes.
Lorsqu'un appareil se connecte à un réseau WiFi, il récupère les paramètres réseau tels que les paramètres DNS et proxy, ce qui lui permet de router tout le trafic vers lui-même avant de l'envoyer à la destination appropriée. Avec un certificat SSL volé à un tiers (ou un profil accepté), même le trafic HTTPS peut être déchiffré sans déclencher d'alarme.
Une fois que cela est en place, les flux tels que OpenID Connect deviennent vulnérables au reroutage du trafic, ce qui peut entraîner le vol de jetons d’accès ou leur définition sur une autre URL.
Dans le flux ci-dessus, la séquence suivante se produit :
- Okta Verify tente de se connecter à la configuration openid-configuration de l'organisation, ce qui est requis par la spécification du protocole.
- Le trafic est redirigé vers l'infrastructure de l'attaquant.
- Les valeurs renvoyées par l'infrastructure de l'attaquant modifieront les paramètres clés :
- Modifiez keys_uri vers le point de terminaison de clés de l’attaquant. Cela permet à l’attaquant d’envoyer des JWT, qui passeront la vérification même en l’absence de clés privées légitimes.
- Modifier les points de terminaison tels que token_endpoint qui pourraient entraîner l'acheminement des flux d'échange de jetons définis par la norme vers l'infrastructure de l'attaquant (qui peut ensuite être interceptée).
- À ce stade, l'attaquant a considérablement étendu la surface d'attaque, ce qui pourrait entraîner une prise de contrôle du compte si elle est combinée à un type d'hameçonnage.
Comment l'épinglage vous protège
L'épinglage de nos connexions TLS a trois objectifs principaux : l'authenticité, l'intégrité et la confidentialité.
Authenticité
Les applications clientes d'Okta sont déployées avec une protection anti-altération et des clés publiques intégrées. L'infrastructure d'Okta détient les clés privées, nous les utilisons donc pour confirmer l'identité du serveur à l'aide de ces clés intégrées. Cela signifie qu'Okta Verify ne peut pas être dupé et connecté à un site d'hameçonnage ou à une autre infrastructure contrôlée par un attaquant.
Intégrité
Bien que la plupart des données transférées entre le client et le serveur soient déjà encapsulées dans des structures vérifiables telles que les JSON Web Tokens, les points de terminaison nécessaires pour vérifier ces structures peuvent ne pas l'être (par exemple, `/oauth2/v1/keys`). L'épinglage des clés empêche le client d'accepter un ensemble de clés manipulées, ce qui pourrait entraîner une large surface d'attaque, y compris des erreurs de configuration et des attaques de phishing.
Déclaration de confidentialité
Bien qu’Okta s’efforce de minimiser l’utilisation des informations personnelles identifiables (PII), la nature d’ Okta Verify Device Assurance comprend l’identification réussie de l’appareil et des signaux détaillés qui y sont associés afin d’accroître la sécurité de votre organisation. Si des tiers lisent ces données, ils pourraient recueillir des informations sur les utilisateurs et leurs appareils pour les utiliser dans des attaques ou la collecte de données.
Exemple d'attaque lorsque l'épinglage est actif
Lorsque l'épinglage est actif, Okta Verify examine la connexion TLS pendant la négociation TLS avant d'envoyer ou de recevoir des données. Le client abandonne alors la connexion, bloquant immédiatement toute possibilité qu'une infrastructure non Okta lise ou modifie les données en transit.
Cette protection représente un contrôle d'atténuation pour Okta FastPass qui n'est pas réalisable par d'autres authentificateurs résistants à l'hameçonnage comme les clés matérielles / WebAuthN, car ceux-ci reposent sur l'implémentation (non épinglée) de PKI + TLS par le navigateur pour l'envoi d'assertions signées sur Internet.
Les inconvénients
Le principal inconvénient de l'épinglage pour Okta est la complexité opérationnelle. Comme toujours, nous sommes prêts à accepter ce travail supplémentaire pour assurer la sécurité de nos clients.
Certaines organisations ont des politiques qui inspectent tout le trafic à l'intérieur de leur périmètre réseau. Si le trafic d'Okta Verify est inclus dans les règles d'inspection, il bloquera ses propres connexions réseau, comme il le ferait si un attaquant effectuait une inspection ou une modification du trafic.
Pour les raisons énumérées ci-dessus, nous ne pouvons pas autoriser l'inspection du trafic entre Okta Verify et son infrastructure sans exposer les clients aux scénarios d'attaque énumérés ci-dessus. Si vous devez inspecter le trafic dans votre réseau, vous pouvez autoriser l'infrastructure d'Okta à partir des règles d'inspection. Les organisations qui ont besoin d'inspecter le trafic de connexion entre les navigateurs et l'infrastructure Okta peuvent utiliser un domaine personnalisé et inspecter le trafic vers ce domaine sans impacter Okta Verify.
Nous surveillons cet espace et serions ouverts à l'exploration d'alternatives qui représentent des améliorations en matière de sécurité et de fonctionnement. Vous pouvez être assuré que si cela se produit, le niveau de sécurité du remplacement sera égal ou supérieur au niveau actuel.
Okta s’est engagé à faire de la sécurité une priorité. Nous nous efforçons chaque jour de faire d’Okta Verify l’authentificateur le plus sûr au monde, protégeant ainsi Okta et nos clients. L’épinglage de clé est un élément essentiel de la sécurité globale d’Okta Verify, et nous continuerons à faire tout notre possible pour vous protéger.
Vous avez des questions sur cet article de blog ? Contactez-nous à l'adresse suivante : eng_blogs@okta.com.
Consultez d’autres Blogs sur l’ingénierie d’Okta pour approfondir vos connaissances.
Prêt à rejoindre notre équipe d’ingénieurs aussi passionnés qu’exceptionnels ? Consultez notre page Carrières.
Libérez le potentiel d’une gestion des identités moderne et sophistiquée pour votre entreprise. Contactez notre équipe commerciale pour plus d’informations.
