Violation BePrime : absence de MFA à l’origine d’une fuite de données

Une société de sécurité ne configure pas d’AMF sur ses propres comptes administrateurs. Un mot de passe volé plus tard : 12,6 Go de données client publiquement accessibles, 1 858 appareils réseau sous contrôle étranger – et des mots de passe en clair dans les fichiers volés.

6 min de lecture

Qu’est-ce que BePrime ? BePrime est un prestataire de services de cybersécurité mexicain qui offre des services de sécurité gérés pour les moyennes et grandes entreprises. Parmi ses clients figurent des entreprises des secteurs de l’énergie, de l’acier, des biens de consommation et de la restauration – autant de secteurs nécessitant une protection élevée pour la technologie opérationnelle et l’infrastructure réseau.

L’incident chez BePrime est instructif car il montre ce qui se passe lorsque la conformité et les opérations de sécurité divergent. BePrime n’est pas une petite start-up sans budget de sécurité. L’entreprise est un prestataire de services de cybersécurité – elle protège donc professionnellement d’autres entreprises contre ces mêmes attaques. Et n’a pas mis en œuvre le contrôle le plus simple disponible dans sa propre maison.

C’est le cœur de cette étude de cas : non pas que l’AMF manque, mais que l’écart entre la rhétorique de conformité et la réalité opérationnelle de la sécurité est si grand qu’il existe même dans les sociétés de sécurité.

Ce que l’attaquant a trouvé : un système ouvert

Le déroulement était peu spectaculaire. L’attaquant, alias « dylanmarly », a obtenu l’accès à un compte administrateur sans authentification à multi-facteurs. Un mot de passe volé a suffi pour un accès complet au système. Ce qui a suivi n’était pas une intrusion avancée, mais un simple vol de tout ce qui était accessible.

Ce que contenaient les 12,6 GB de données volées :

1. Mots de passe en clair – Les identifiants n’étaient ni hachés ni chiffrés. Une erreur fondamentale considérée comme inacceptable depuis des décennies.
2. Identifiants Superuser PostgreSQL – Accès complet aux bases de données contenant des données clients. Un seul identifiant, sans concept de rotation.
3. Données MinIO S3-Bucket – Stockage d’objets avec des documents internes ; MinIO est typiquement utilisé pour des données sensibles d’entreprise.
4. Clés API Cisco Meraki – C’est ici que réside la véritable escalade : les clés API Meraki permettent un contrôle total sur les équipements réseau connectés. 1.858 appareils ont été compromis.
5. Rapports d’audit de sécurité internes des clients – C’est la partie la plus problématique pour les personnes concernées. Ces documents décrivent les vulnérabilités dans les infrastructures des clients. Ils sont maintenant accessibles au public.
6. Flux de surveillance en direct – Via les consoles Meraki compromises, les flux de caméras de systèmes de surveillance actifs étaient accessibles.

Les clients figurant dans les données volées : Iberdrola (fournisseur d’énergie), Whirlpool, ArcelorMittal et Alsea (exploitant de Starbucks et Domino’s en Amérique latine).

Conformité de façade versus véritables opérations de sécurité

La réaction : une leçon de mauvaises priorités

Après la découverte de la faille, BePrime n’a publié aucune analyse technique. Aucune communication publique avec les clients. À la place : des menaces juridiques contre les journalistes qui ont rapporté l’incident.

C’est un schéma que les équipes de sécurité devraient connaître – non pas parce qu’il est rare, mais parce qu’il est un signal fiable du degré de maturité d’une entreprise. Ceux qui, en cas de stress lié à un incident, pensent d’abord à la direction juridique plutôt qu’à l’analyse forensique et à la communication avec les clients, n’ont pas intégré la sécurité comme une discipline opérationnelle.

Le facteur d’ironie est élevé : BePrime réalise des rapports d’audit de sécurité pour ses clients – ces mêmes rapports étaient non chiffrés dans le système et sont maintenant publics. Y compris les vulnérabilités des clients qui y sont documentées. Ce n’est pas seulement un dommage à la réputation pour BePrime, c’est un risque direct pour Iberdrola, ArcelorMittal, Whirlpool et Alsea.

Ce que les équipes de sécurité DACH peuvent faire concrètement

Trois conséquences directement applicables de cet incident :

Premièrement : Les évaluations de sécurité des fournisseurs doivent être techniques, pas seulement basées sur des documents. Un questionnaire demandant si MFA est activé n’est pas une preuve que MFA est actif. L’accès à une preuve technique – ou au moins une capture d’écran de reporting Entra/Okta – devrait devenir la norme.

Deuxièmement : Les clés API des tiers nécessitent un scoping et une rotation. Les clés API Meraki avec accès complet à 1.858 appareils dans un système de prestataire de services sont un risque, peu importe à quel point le prestataire de services est sécurisé. Les clés API avec les privilèges minimaux qui ne font que lire et tournent automatiquement sont meilleures qu’un accès complet permanent.

Troisièmement : Les rapports d’audit de sécurité sont des documents hautement sensibles. Ils décrivent des vulnérabilités. Leur stockage chez le prestataire de services doit répondre aux mêmes exigences de protection que les systèmes décrits eux-mêmes.

Foire aux questions

Qu’est-ce que l’authentification multi-facteurs et pourquoi un mot de passe seul ne suffit-il pas ?

MFA nécessite, en plus du mot de passe, une deuxième preuve – généralement un code TOTP ou une notification push. Un mot de passe volé seul ne donne donc pas accès. Dans le cas de BePrime, MFA aurait probablement stoppé l’attaque, car l’attaquant n’avait pas accès au deuxième appareil de facteur.

Pourquoi les mots de passe en clair dans les bases de données sont-ils un risque indépendant ?

Les mots de passe hachés volés peuvent souvent être craqués avec des GPU modernes, mais cela coûte du temps et des ressources. Les mots de passe en clair sont immédiatement utilisables – pour le bourrage d’identifiants contre d’autres services, le mouvement latéral et la prise de contrôle de compte. Le stockage en clair n’est pas une erreur de configuration, mais une erreur fondamentale qui ne doit pas exister dans un système contenant des données de production.

Que doivent faire les entreprises concernées (clients de BePrime) maintenant ?

Priorité un : faire tourner tous les identifiants auxquels BePrime a eu accès – clés API, mots de passe de comptes de service et accès partagés. Priorité deux : vérifier si les données volées disponibles publiquement contiennent des détails sur votre propre réseau. Priorité trois : vérifier les configurations Meraki et les journaux d’audit de vos appareils pour détecter les accès non autorisés.

Comment MFA aurait-il concrètement stoppé cette attaque ?

MFA intervient au niveau de l’authentification. Si l’attaquant « dylanmarly » avait un mot de passe administrateur mais pas accès au deuxième appareil de facteur, la connexion aurait échoué. Il existe des scénarios où MFA peut être contourné (SIM-Swapping, phishing d’authenticator), mais ceux-ci nécessitent beaucoup plus d’efforts qu’un simple vol d’identifiants. La faille de BePrime ne semblait pas être une attaque sophistiquée ciblée.

Quels standards de conformité rendent MFA obligatoire pour les comptes privilégiés ?

NIS2 stipule dans l’article 21 des mesures techniques et organisationnelles pour sécuriser les accès privilégiés – MFA y est implicite, souvent explicite dans les mises en œuvre nationales. DORA exige des contrôles IAM qui incluent MFA pour les prestataires de services financiers. ISO 27001:2022 mentionne MFA dans l’annexe A comme contrôle pour l’accès privilégié. Pour un prestataire de services de sécurité opérant dans des secteurs pertinents pour NIS2, ce n’était pas une option facultative.

Source de l’image de couverture : Tima Miroshnichenko / Pexels

À propos de l'auteur: Alec Chizhik

Plus d'articles de Alec Chizhik