Résistance au phishing en premier
L'authentification résistante au phishing est la base actuelle de l'authentification sécurisée, ce qui signifie FIDO/WebAuthn, FastPass, PIV/CAC, etc. Cet article se concentrera sur la manière dont ceux qui respectent déjà cette base peuvent faire passer la sécurité au niveau supérieur.
Les mots de passe, les SMS, les notifications push et les codes à usage unique sont vulnérables à des attaques beaucoup moins sophistiquées que celles décrites dans cet article. Nous ne les recommandons donc pas.
Où la résistance au phishing est insuffisante
Comme indiqué ci-dessus, FastPass, les clés d'identification et les autres authentificateurs FIDO sont un excellent moyen de protéger votre organisation contre les attaques de phishing, obligeant essentiellement l'attaquant à obtenir une sorte de présence sur votre appareil (ou même à voler physiquement une clé).
Les authentificateurs résistants au phishing reposent sur deux exigences définies par le NIST : Verifier Name Binding (liaison du nom du vérificateur) et Channel Binding (liaison de canal) [il s’agit d’une version préliminaire des spécifications, les commentaires sont « fermés »], qui, ensemble, empêchent la plupart des attaques de phishing. FIDO et FastPass reposent tous deux sur la liaison du nom du vérificateur, par exemple.
Outre ces exigences, les systèmes d’authentification résistants au phishing doivent créer un canal protégé entre le navigateur et le système d’authentification afin d’empêcher l’écoute clandestine ou les attaques par relais vers un appareil distant. Toutefois, les exigences ne tiennent pas compte d’une présence malveillante sur l’appareil de l’utilisateur. Par conséquent, une catégorie d’attaques plus sophistiquées peut se produire et, en cas de succès, permettre aux attaquants de satisfaire aux exigences de résistance au phishing.
Exemple d’attaque : authentification inter-appareils via SOCKS
Imaginez une victime qui a cliqué sur un lien qui a installé un malware sur son système. Comme base de référence pour cette attaque, l'attaquant doit déjà être capable d'exécuter du code en tant qu'utilisateur sur sa machine.
|
1 |
L'attaquant crée un proxy inverse SOCKS entre l'appareil compromis et son propre appareil (Étape 1 dans le schéma). Avec la bonne configuration, l'attaquant peut ensuite relayer les défis FastPass ou FIDO2 de son propre appareil vers l'appareil compromis via le proxy SOCKS. |
|
2-3 |
L'attaquant tente d'accéder aux ressources de l'utilisateur depuis son propre appareil et relaie le défi d'authentification vers l'appareil de l'utilisateur via le proxy. |
|
4 |
Le navigateur interroge directement l'appareil de l'attaquant au serveur Okta, en attendant que le défi d'authentification soit satisfait. |
|
5 |
L'attaquant doit amener l'appareil compromis à signer la réponse au défi avec son TPM.
Une politique bien configurée exigera la présence de l'utilisateur, déclenchant une invite utilisateur pour la biométrie ou le code d'accès de l'appareil, ce qui pourrait éveiller les soupçons de l'utilisateur. Étant donné un scénario où un logiciel malveillant est présent sur l'appareil, l'attaquant peut être en mesure de fournir un code d'accès ou de synchroniser habilement l'attaque de telle sorte que l'utilisateur ne soit pas surpris par l'invite (par exemple, lorsque l'utilisateur est absent de sa machine ou s'attend de toute façon à une invite d'authentification). |
|
6-8 |
Enfin, la réponse au défi est envoyée de l'appareil compromis au serveur Okta, réussissant les contrôles de clé TPM, la résistance au phishing et les garanties de confiance de l'appareil.
Par conséquent, l'appareil de l'attaquant dispose désormais d'une session valide, car il a pu relayer de manière transparente l'authentification entre son navigateur web et l'authentificateur sur l'appareil compromis. |
Entrez Trusted App Filters
En août 2024, Okta a lancé une fonctionnalité visant à atténuer ce type d’attaque pour FastPass : Filtres d’applications approuvées. Cette configuration haute sécurité permet aux administrateurs de bloquer automatiquement toutes les tentatives d’authentification par des applications qui ne figurent pas spécifiquement sur la liste verte ou qui ne sont pas du tout signées, ou qui sont signées par un certificat de signature de code non approuvé.
Fonctionnement
Lorsqu'une application comme Chrome tente de s'authentifier à l'aide de FastPass, le widget de connexion d'Okta tente de se connecter à Okta Verify s'exécutant sur l'appareil, puis envoie le défi d'authentification depuis le backend d'Okta.
Pendant que cette connexion est active, Okta Verify retrace le port et le processus qui ont créé la connexion sur l'appareil. Si le port et le processus sont introuvables, cela peut indiquer que l'origine était distante et que la connexion est abandonnée.
Si le processus peut être identifié, Okta Verify collecte ensuite des données de signature détaillées sur l'exécutable, en vérifiant que la signature correspond au certificat de signature de code et que le certificat de signature de code est approuvé par la chaîne d'approbation locale.
Par exemple, nous utilisons SecCodeCopySigningInformation (macOS) WinVerifyTrust (Windows) pour obtenir des informations détaillées sur le processus. Une fois que toutes ces données sont capturées, elles sont envoyées dans un échange requête-réponse avec l’attestation de gestion et les signaux de l’appareil, le tout regroupé et signé avec une clé liée au matériel.
Surveillance
Si vous utilisez FastPass sur macOS ou Windows, ces données sont actuellement disponibles dans vos SysLogs.
Ceci est un exemple de connexion au tableau de bord Okta à l'aide de Chrome pour macOS.
En consultant vos journaux, vous pouvez voir avec quelles applications vos utilisateurs s'authentifient et créer des flux de travail pour vous alerter lorsque de nouvelles applications sont utilisées. Il est important de bien comprendre quels binaires sont associés aux applications auxquelles on accède dans votre organisation. Par exemple, les utilisateurs doivent s'authentifier auprès de Slack uniquement via un navigateur ou l'application native Slack.
Application
Après avoir compilé une liste complète des applications qui s'appliquent à une politique d'authentification donnée, vous pouvez appliquer des filtres d'applications approuvées pour bloquer ces attaques avant qu'elles ne commencent. Cela peut être un peu complexe, il est donc plus simple de créer des règles de politique d'authentification distinctes pour chaque plateforme de bureau (par exemple, définir la règle de plateforme ou d'assurance de l'appareil sur macOS ou Windows pour une règle donnée).
Une fois que votre Expression Language est en place, toute application ne parvenant pas à réussir la vérification de signature (par exemple, un logiciel malveillant non signé) sera bloquée, ainsi que l'entrée SysLog correspondante. Les applications signées qui ne figurent pas dans la liste (telles que le démon SSH) seront également bloquées.
Exemple 1 : Chrome, Firefox et Safari sur macOS
Dans cet exemple, nous autorisons tous les principaux navigateurs pris en charge sur macOS, à l’aide de l’extension SSO ou des liaisons Loopback. Cela signifie que seules les deux liaisons résistantes au phishing déclencheront la règle pour FastPass. Notez que les applications natives avec leurs propres vues Web, telles que O365, ne correspondent pas à cette règle. Si vous souhaitez les autoriser, vous devrez également inclure leurs identifiants.
Exemple 2 : Edge et Chrome sous Windows
Windows est un peu plus simple, car LOOPBACK est la seule liaison valide pour cette vérification. Notez que cela empêchera également les flux non résistants au phishing déclenchés par la liaison CUSTOM_URL.
Combinaison de filtres d’applications approuvées avec FIDO ou d’autres systèmes d’authentification
Si vous souhaitez utiliser un autre authentificateur que FastPass, par exemple une clé de sécurité FIDO, vous pouvez également appliquer les filtres d'applications de confiance sur cette règle d'authentification, à condition qu'un compte Okta Verify soit également enregistré sur cet appareil.
Pour ce faire, créez une règle avec tous les éléments suivants :
- Une condition enregistrée ou gérée
- Le langage d'expression des filtres d'applications approuvées
- Autorisez les authentificateurs que vous souhaitez prendre en charge, ou utilisez "Autoriser toute méthode"
Si vous utilisez FastPass sur macOS ou Windows dans votre organisation, vous pouvez commencer à surveiller quelles applications natives déclenchent l'authentification FastPass dès aujourd'hui ! Une fois que vous avez une idée claire des applications approuvées qui sont utilisées, vous devez autoriser ces applications et empêcher toutes les autres d'utiliser FastPass.
Si vous souhaitez en savoir plus à ce sujet, y compris une excellente démonstration de Zach Newton, consultez notre présentation d’Oktane 2024 (inscription gratuite obligatoire).
Vous avez une question sur FastPass ou Device Security ? Rejoignez le forum de la communauté Okta FastPass et lancez une conversation.
Vous avez des questions concernant cet article de blog ? Contactez-nous à l'adresse 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.
