Into the Breach : Décomposer 3 cyberattaques d’applications SaaS en 2022


Au cours de la dernière semaine de mars, trois grandes entreprises technologiques – Microsoft, Okta et HubSpot – ont signalé d’importantes violations de données. DEV-0537, également connu sous le nom de LAPSUS$, a exécuté les deux premiers. Ce groupe hautement sophistiqué utilise des vecteurs d’attaque de pointe avec un grand succès. Pendant ce temps, le groupe à l’origine de la violation de HubSpot n’a pas été divulgué. Ce blog passera en revue les trois violations basées sur des informations divulguées publiquement et suggérera les meilleures pratiques pour minimiser le risque que de telles attaques réussissent contre votre organisation.

HubSpot – Accès des employés

Le 21 mars 2022, HubSpot a signalé la violation qui s’est produit le 18 mars. Des acteurs malveillants ont compromis un compte d’employé HubSpot que l’employé utilisait pour le support client. Cela a permis aux acteurs malveillants d’accéder aux données de contact et de les exporter en utilisant l’accès de l’employé à plusieurs comptes HubSpot.

Avec peu d’informations concernant cette violation, se défendre contre une attaque est difficile, mais une configuration clé dans HubSpot peut aider. Il s’agit du contrôle “HubSpot Employee Access” (illustré dans la figure ci-dessous) dans les paramètres de compte de HubSpot. Les clients doivent désactiver ce paramètre à tout moment, sauf s’ils ont besoin d’une assistance spécifique, puis le désactiver immédiatement après avoir terminé l’appel de service.

Un paramètre similaire apparaît dans d’autres applications SaaS et doit également y être désactivé. L’accès des employés est généralement enregistré dans les journaux d’audit, qui doivent être examinés régulièrement.

Découvrez comment une SSPM peut aider à protéger votre organisation contre les erreurs de configuration SaaS

Okta – Absence de sécurité des appareils pour les utilisateurs privilégiés

Okta sous-traite une partie de son support client au groupe Sitel. Le 21 janvier, un membre de l’équipe de sécurité d’Okta a reçu une alerte indiquant qu’un nouveau facteur MFA avait été ajouté au compte d’un employé du groupe Sitel depuis un nouvel emplacement.

Une enquête a révélé que l’ordinateur d’un ingénieur de support Sitel avait été compromis à l’aide d’un protocole de bureau à distance. Cette vulnérabilité connue est normalement désactivée, sauf en cas de nécessité spécifique, ce qui a aidé les enquêteurs d’Okta à réduire le délai de l’attaque à une fenêtre de cinq jours entre le 16 et le 21 janvier 2022.

En raison de l’accès limité des ingénieurs d’assistance à leur système, l’impact sur les clients d’Okta a été minime. Les ingénieurs de support n’ont pas accès pour créer ou supprimer des utilisateurs ou télécharger des bases de données client. Leur accès aux données clients est également assez limité.

Le 22 mars, DEV-0537, plus communément appelé LAPSUS$, a partagé des captures d’écran en ligne. En réponse, Okta a publié une déclaration disant, “il n’y a pas de mesures correctives que nos clients doivent prendre.” Le lendemain, la société partagé les détails de son enquêtequi comprenait un calendrier de réponse détaillé.

Bien que cette faille ait été limitée dans les dommages qu’elle a causés, elle offre trois leçons de sécurité importantes.

  1. Sécurité de l’appareil au SaaS – la sécurisation d’un environnement SaaS ne suffit pas lorsqu’il s’agit de se protéger contre une violation. La sécurisation des appareils utilisés par les utilisateurs hautement privilégiés est d’une importance primordiale. Les organisations doivent revoir leur liste d’utilisateurs à privilèges élevés et s’assurer que leurs appareils sont sécurisés. Cela peut limiter les dégâts d’une brèche via le vecteur d’attaque auquel a été confronté Okta.
  2. AMF – C’est l’ajout de MFA qui a permis à la sécurité d’Okta de découvrir la faille. L’authentification unique ne va pas assez loin et les organisations qui prennent au sérieux la sécurité SaaS doivent également inclure des mesures de sécurité MFA.
  3. Surveillance des événements – La faille Okta a été découverte lorsque le personnel de sécurité a constaté un changement inattendu dans le journal de surveillance des événements. L’examen des événements tels que les modifications apportées à MFA, la réinitialisation du mot de passe, les connexions suspectes, etc., est essentiel pour la sécurité SaaS et doit être effectué quotidiennement.

Voir L’enquête de Cloudflare sur le compromis Okta de janvier 2022 pour un bon exemple de réponse à une telle violation.

Découvrez comment Adaptive Shield fournit la gestion de la posture des terminaux et le contrôle de la configuration SaaS

Microsoft – MFA pour tous les utilisateurs privilégiés

Le 22 mars, Microsoft Security informations partagées concernant une attaque subie par DEV-0537. Microsoft avait un seul compte compromis, ce qui a entraîné le vol et la publication du code source.

Microsoft a assuré à ses utilisateurs que l’attaque LAPSUS$ n’avait compromis aucune de leurs informations et a en outre déclaré qu’il n’y avait aucun risque pour aucun de leurs produits en raison du code volé.

Microsoft n’a pas spécifiquement partagé comment la violation a été effectuée, bien qu’il ait alerté les lecteurs que LAPSUS$ recrute activement des employés dans les télécommunications, les principaux développeurs de logiciels, les centres d’appels et d’autres industries pour partager les informations d’identification.

La société a également proposé ces suggestions pour sécuriser les plates-formes contre ces attaques.

  1. Renforcer la mise en œuvre de l’AMF – Les lacunes MFA sont un vecteur d’attaque clé. Les organisations doivent exiger des options MFA, limitant autant que possible les SMS et les e-mails, comme avec les jetons Authenticator ou FIDO.
  2. Exiger des terminaux sains et fiables – Les organisations doivent évaluer en permanence la sécurité des appareils. Assurez-vous que les appareils accédant aux plates-formes SaaS respectent leurs politiques de sécurité en appliquant des configurations d’appareils sécurisés avec un faible score de risque de vulnérabilité.
  3. Tirez parti des options d’authentification modernes pour les VPN – L’authentification VPN doit tirer parti des options d’authentification modernes telles que OAuth ou SAML.
  4. Renforcez et surveillez votre posture de sécurité dans le cloud – Les organisations doivent, au minimum, définir un accès conditionnel pour les utilisateurs et les configurations de risque de session, exiger une MFA et bloquer les connexions à haut risque.

Pour une liste complète des recommandations de Microsoft, voir ce Remarque.

Dernières pensées

La sécurisation des plateformes SaaS est un défi majeur, et comme on l’a vu cette semaine, même les entreprises mondiales doivent rester au top de leur sécurité. Les acteurs malveillants continuent d’évoluer et d’améliorer leurs méthodes d’attaque, ce qui oblige les organisations à être à l’affût et à prioriser leur sécurité SaaS en permanence.

Les mots de passe forts et les solutions SSO ne suffisent plus à eux seuls. Les entreprises ont besoin de mesures de sécurité avancées, telles qu’une MFA solide, des listes d’adresses IP autorisées et le blocage de l’accès inutile des techniciens d’assistance. Une solution automatisée telle que SaaS Security Posture Management (SSPM) peut aider les équipes de sécurité à maîtriser ces problèmes.

L’importance de la sécurité des appareils dans le SaaS est un autre point à retenir de ces attaques. Même une plate-forme SaaS entièrement sécurisée peut être compromise lorsqu’un utilisateur privilégié accède à une application SaaS à partir d’un appareil compromis. Tirez parti d’une solution de sécurité qui combine la posture de sécurité des appareils avec la posture de sécurité SaaS pour une protection complète de bout en bout.

Le défi de la sécurisation des solutions SaaS est complexe et plus que fastidieux à relever manuellement. Les solutions SSPM, comme Adaptive Shield, peuvent fournir gestion automatisée de la posture de sécurité SaaS, avec contrôle de la configuration, gestion de la posture des terminaux et contrôle des applications tierces.

Remarque – Cet article est rédigé et contribué par Hananel Livneh, analyste produit senior chez Adaptive Shield.



ttn-fr-57