Sécurisez la MFA contre les proxys de phishing avec F5 BIG-IP APM et Distributed Cloud Bot Defense

Jim Downey

Les entreprises qui protègent les comptes utilisateurs au moyen de l’authentification à deux facteurs (2FA) devraient également se prémunir contre les proxys de phishing en temps réel, qui permettent aux cybercriminels de contourner les mesures d’authentification multifacteur (MFA) et de prendre le contrôle des comptes. Heureusement, les clients de F5 BIG-IP Access Policy Manager (APM) peuvent facilement ajouter F5 Distributed Cloud Bot Defense afin de neutraliser efficacement ces proxys.

Que sont les proxys de phishing en temps réel ?

Une attaque par proxy de phishing en temps réel commence par un message de phishing envoyé par SMS, par e-mail ou via une page web. Ce message contient un lien qui redirige l’utilisateur vers un domaine contrôlé par l’attaquant et conçu pour relayer toutes les requêtes vers l’application ciblée. Du point de vue de l’utilisateur, tout semble légitime, à l’exception du nom de domaine, généralement choisi pour ressembler étroitement au véritable domaine.

Trompé par le proxy d’hameçonnage, l’utilisateur saisit ses identifiants. Dans le cas d’une authentification à facteur unique, cette saisie suffit à l’attaquant pour accéder au compte. Dans le cas de l’authentification à deux facteurs (2FA), le proxy d’hameçonnage en temps réel transmet les identifiants à l’application légitime, ce qui déclenche la demande de 2FA. Malheureusement, l’utilisateur, qui pense toujours interagir avec l’application légitime, acceptera probablement la demande de 2FA, quelle qu’elle soit.

Les proxys inverses de phishing peuvent compromettre presque toutes les formes d’authentification à deux facteurs :

• 2FA basée sur le service de messages courts (SMS). Dans le cadre d’une 2FA par SMS, le système d’authentification envoie à l’utilisateur un SMS contenant un mot de passe à usage unique (OTP), que celui-ci saisit dans l’application. Lors d’une attaque de phishing par proxy, l’utilisateur saisit directement ce code dans l’application malveillante, qui le transmet ensuite à l’application légitime, permettant ainsi au cybercriminel d’y accéder. Le même principe s’applique à la 2FA lorsque l’OTP est envoyé par e-mail. Si le mécanisme exige que l’utilisateur saisisse l’OTP dans une application, une attaque de phishing par proxy en temps réel peut intercepter cet OTP.
• 2FA par jeton matériel. Les jetons matériels, qui sont des dispositifs physiques générant des codes à intervalles réguliers selon un algorithme cryptographique, remplissent la même fonction que les mots de passe à usage unique (OTP) dans la 2FA par SMS. L’utilisateur consulte le dispositif, puis saisit le code dans l’application. S’il est trompé par un proxy d’hameçonnage en temps réel et saisit ce code dans une application malveillante, l’attaquant accède au compte. En un sens, que le code soit transmis par SMS, par e-mail ou par un dispositif matériel ne change rien pour le proxy d’hameçonnage en temps réel. (En revanche, les clés matérielles FIDO2/U2F ne sont pas vulnérables à l’hameçonnage, car le navigateur collabore avec la clé matérielle pour lier l’authentification à l’origine.)
• 2FA basée sur une application. Les applications mobiles d’authentification telles que Google Authenticator et Duo Mobile génèrent des jetons de manière très similaire aux dispositifs matériels. Là encore, les utilisateurs doivent saisir le jeton dans l’application. Si l’utilisateur est amené à saisir le jeton dans une application malveillante, l’attaquant accède à l’application légitime.
• 2FA basée sur les notifications push. Certes, tout mécanisme de 2FA qui demande à l’utilisateur de saisir un mot de passe à usage unique (OTP) dans une application peut être compromis en incitant celui-ci à saisir l’OTP dans une application malveillante. Mais qu’en est-il de la 2FA basée sur les notifications push, qui ne nécessite pas que l’utilisateur saisisse un OTP dans une application ? Dans un système basé sur les notifications push, lorsqu’elle reçoit une demande de connexion, l’application envoie une requête à un système de notifications push, ce qui entraîne l’envoi d’une notification sur l’appareil mobile de l’utilisateur. Il suffit à ce dernier de cliquer une fois pour accepter la demande. Le système de notifications push effectue alors un appel API vers l’application pour lui indiquer que l’authentification push a réussi, puis l’application termine le processus d’authentification et accorde l’accès à l’utilisateur. Dans ce scénario, le proxy d’hameçonnage ne reçoit jamais le jeton, car celui-ci est transmis directement à l’application. Néanmoins, le cybercriminel parvient tout de même à accéder au compte, car l’application finit par transmettre le jeton de session authentifiée à l’utilisateur par l’intermédiaire du proxy, ce qui permet à l’attaquant de l’intercepter et de l’utiliser pour accéder à l’application en usurpant l’identité de la victime.

Proxys de phishing en temps réel en tant que service

Il faut s’attendre à une augmentation des attaques par proxy d’hameçonnage en temps réel, car les services de proxy d’hameçonnage (PhaaS), tels qu’EvilGinx, Muraena et Modlishka, rendent leur mise en œuvre remarquablement facile pour les cybercriminels en leur fournissant tout ce dont ils ont besoin pour lancer ces attaques :

• Modèles d’e-mails d’hameçonnage qui incitent les utilisateurs à consulter des sites malveillants
• Serveurs web hébergés qui imitent les applications ciblées
• Bases de données pour stocker les identifiants volés
• Surveillance en temps réel
• Mécanismes de défense visant à contrer les chercheurs en sécurité
• Documentation et service client

Comment Distributed Cloud Bot Defense neutralise les proxys d’hameçonnage en temps réel

Le trafic qui transite par un proxy d’hameçonnage présente des caractéristiques distinctives : le nom de domaine ne correspond pas à celui du site légitime, le code HTML et JavaScript peut être modifié pour tenir compte du changement de nom de domaine, et la temporisation ainsi que les signatures TLS peuvent être altérées. En s’appuyant sur bon nombre des mêmes signaux côté client et réseau que ceux utilisés pour distinguer les bots des humains, Distributed Cloud Bot Defense peut détecter les anomalies propres aux proxys d’hameçonnage en temps réel et ainsi neutraliser l’une des menaces les plus courantes pesant sur l’authentification multifacteur.

Pourquoi les entreprises devraient combiner BIG-IP APM et Distributed Cloud Bot Defense pour se protéger contre l’hameçonnage en temps réel

BIG-IP APM est une solution flexible et performante de gestion des accès pour les applications et les API. Elle fournit des services d’authentification aux applications en connectant les services d’identité de l’entreprise, tels qu’Active Directory, les fournisseurs LDAP et RADIUS, aux protocoles d’authentification modernes, tels que l’authentification unique (SSO), la fédération des accès, OAuth 2.0, SAML et OIDC.

BIG-IP APM prend en charge l’authentification renforcée, avec une authentification à deux facteurs par mot de passe à usage unique envoyé par SMS prête à l’emploi. De plus, BIG-IP APM s’intègre à la plupart des principales solutions d’authentification multifacteur, notamment celles de Cisco Duo, Okta, Azure AD, entre autres.

En raison du rôle central que joue BIG-IP APM dans le processus d’authentification de nombreuses entreprises, il constitue l’emplacement idéal pour déployer Distributed Cloud Bot Defense afin de protéger les utilisateurs contre les attaques de phishing en temps réel par proxy qui utilisent l’automatisation pour contourner les protections MFA.

Étapes suivantes

Pour plus de détails techniques, consultez l’article F5 DevCentral sur la configuration de Distributed Cloud Bot Defense dans BIG-IP APM

À propos de l’auteur

Jim Downey

Autres articles de Jim Downey