C’est en l’espace de deux mois, la deuxième alerte émise par Varonis sur des moyens que pourraient exploiter des attaquants pour compromettre des comptes Box et voler des données sensibles d’entreprise.

En décembre 2021, le Varonis Threat Lab avait émis une première alerte sur un moyen de contourner le MFA basé sur des applications d’authentification telles que Google Authenticator, de Box. Le problème avait évidemment été signalé en amont à Box (le 2 novembre 2021) via HackerOne, et la société avait publié un correctif.

Cette nouvelle alerte émise par le Varonis Threat Labs porte sur l’authentification multifactorielle utilisant un code SMS pour la vérification de la connexion.

Grâce à cette technique, un attaquant pourrait utiliser des informations d’identification volées pour compromettre le compte Box d’une organisation et exfiltrer des données sensibles sans avoir accès au téléphone de la victime.

Quel est le problème ?

Face à la pression croissante en faveur de l’adoption et de l’application de l’authentification multifacteurs, de nombreux fournisseurs SaaS proposent désormais plusieurs options MFA afin d’offrir aux utilisateurs une deuxième ligne de défense contre les attaques de credential stuffing et autres attaques par mot de passe. Varonis Threat Labs a analysé les mises en œuvre du MFA pour voir dans quelle mesure elles sont réellement sûres.

Selon Box, 97 000 entreprises et 68 % des entreprises du classement Fortune 500 font confiance aux solutions de la société pour accéder aux informations de n’importe où et collaborer avec n’importe qui.

Comme de nombreuses applications, Box permet aux utilisateurs qui n’ont pas d’authentification unique (SSO) d’utiliser une application d’authentification, comme Okta Verify ou Google Authenticator, ou un SMS avec un code d’accès à usage unique comme deuxième étape d’authentification.

Comment fonctionne la vérification par SMS dans Box ?

Après avoir saisi un nom d’utilisateur et un mot de passe dans le formulaire de connexion de Box, Box définit un cookie de session et redirige l’utilisateur vers l’une des deux options suivantes :

o un formulaire de saisie d’un mot de passe temporaire à usage unique (TOTP) si l’utilisateur est inscrit à une application d’authentification ; ou

o un formulaire permettant de saisir un code SMS si l’utilisateur s’est inscrit pour recevoir un code d’accès par SMS.

Lorsque l’utilisateur navigue vers le formulaire de vérification par SMS, un code est envoyé sur son téléphone. Il doit saisir ce code pour accéder à son compte Box.com.

Snir Ben Shimol, Directeur Global Cybersecurity de Varonis explique que « le problème vient du fait que plusieurs process de MFA se mélangent ».

Si l’utilisateur ne se rend pas au formulaire de vérification par SMS, aucun SMS n’est envoyé, mais un cookie de session est tout de même généré. Un acteur malveillant n’a qu’à saisir l’adresse électronique de l’utilisateur et son mot de passe - volé lors d’une fuite de mot de passe ou d’une attaque de phishing, par exemple - pour obtenir un cookie de session valide. Aucun code de message SMS n’est nécessaire.

Une fois le cookie généré, l’acteur malveillant peut abandonner le processus de MFA par SMS (auquel l’utilisateur est inscrit) et lancer à la place le processus de MFA par TOTP, mélangeant ainsi les modes de MFA...

L’attaquant termine le processus d’authentification en envoyant un identifiant et un code à partir de son propre compte Box et de son application d’authentification au point de terminaison de la vérification TOTP en utilisant le cookie de session qu’il a reçu en fournissant les informations d’identification de la victime.

Box n’a pas vérifié si la victime était inscrite à la vérification TOTP et n’a pas validé que l’application d’authentification utilisée appartenait à l’utilisateur qui se connectait.

Il a donc été possible d’accéder au compte Box de la victime sans utiliser le téléphone de cette dernière et sans avertir l’utilisateur par SMS.

Voici également les grandes étapes de l’attaque résumées :
1. L’attaquant s’inscrit à l’authentification multifactorielle en utilisant une app d’authentification et stocke l’ID de facteur de l’appareil.
2. L’attaquant saisit l’adresse e-mail et le mot de passe d’un utilisateur sur account.box.com/login.
3. Si le mot de passe est correct, le navigateur de l’attaquant reçoit un nouveau cookie d’authentification et est redirigé vers : /2fa/verification.
4. L’attaquant, cependant, ne suit pas la redirection vers le formulaire de vérification par SMS. Au lieu de cela, il transmet son propre ID et code de facteur de l’application d’authentification au point final de vérification TOTP : /mfa/verification.
5. L’attaquant est maintenant connecté au compte de la victime et celle-ci ne reçoit pas de message SMS.

Quels enseignements et bonnes pratiques retirer de cette alerte ?

Snir Ben Shimol précise : « Avec toute l’agitation autour du MFA obligatoire de la part d’entreprises comme Salesforce et Google, et même d’un décret de la Maison Blanche, nous voulons souligner que le MFA n’est pas bon que si le développeur qui a écrit le code est bon. En effet, le MFA peut donner un faux sentiment de sécurité. Ce n’est pas parce que le MFA est activé qu’un attaquant doit nécessairement obtenir un accès physique à l’appareil d’une victime pour compromettre son compte. Notre équipe a démontré non pas une, mais deux failles d’application qui nous ont permis d’accéder au compte Box d’une victime compatible MFA avec seulement le nom d’utilisateur et le mot de passe ! ».

Pour l’expert : Cela souligne la nécessité d’une approche centrée sur les données. Les RSSI doivent se poser les questions suivantes :

– Suis-je capable de détecter si le MFA a été désactivé ou contourné pour un utilisateur dans toutes mes applications SaaS ?
– À quelle quantité de données un attaquant peut-il accéder s’il compromet un compte utilisateur normal ?
– Certaines données sont-elles inutilement exposées à un trop grand nombre d’utilisateurs (ou exposées publiquement) ?
– Si un utilisateur accède anormalement aux données, recevrai-je une alerte ?

Snir Ben Shimol conclut : « Nous recommandons de commencer par sécuriser les données là où elles se trouvent. Lorsque l’on limite l’accès et surveille les données elles-mêmes, la probabilité d’une exfiltration de données due à un contournement du périmètre diminue considérablement ».