Les données des clients d'Oracle Cloud Infrastructure ont été divulguées à un forum sur la cybercriminalité

Résumé

Le 20 mars, un utilisateur de BreachForums a affirmé avoir compromis Oracle Cloud Infrastructure (OCI). La violation aurait affecté les serveurs chargés d'authentifier les utilisateurs auprès des services Oracle Cloud. L'individu a fourni des exemples de données à l'appui de sa réclamation et a proposé de vendre l'accès à « environ 6 millions » d'informations d'identification et de matériel d'authentification pour 100 000 Monero (XMR), une crypto-monnaie considérée comme plus difficile à tracer que le bitcoin. L'acteur de la menace propose de supprimer tous les comptes compromis du vidage de données pour un paiement non spécifié et d'échanger les informations relatives aux violations contre des exploits de type « 0 day ».

Figure 1 : capture d'écran de BreachForums


En réponse, les chercheurs en sécurité se sont efforcés de valider et de confirmer ces résultats, tandis qu'Oracle a nié toute violation à plusieurs journalistes de sécurité à Ordinateur qui saigne, Le registre, et Lecture sombre. Bien que l'ampleur de la violation ne soit toujours pas claire, ils ont affirmé avoir accès à un serveur d'authentification hébergé sur login.us2.oraclecloud.com et des échantillons des données qu'ils tentaient de vendre comprenaient divers types de données d'authentification et des fichiers liés aux systèmes Oracle Cloud. Cela contiendrait des données pour l'authentification auprès des services Oracle Cloud, car un fournisseur d'authentificateurs stocke non seulement l'authentification des utilisateurs, mais inclut les informations d'identification et les autorisations pour les systèmes automatisés. En bref, les données des utilisateurs LDAP, les informations de certificat contenues dans les fichiers Java Keystore, les clés JPS d'Enterprise Manager et l'accès à tout service garantissant son authentification avec les services cloud d'Oracle.

L'intégralité de la collection de données d'authentification volées n'a pas été divulguée dans le post de BreachForums, mais une liste des clients Oracle concernés a été partagée. Beazley Security Labs a collecté et corrélé la liste avec les organisations assurées de Beazley et Beazley Security demande aux clients de communiquer avec les organisations potentiellement touchées.

Au moment de la rédaction de cet article, Oracle affirme que son service cloud n'était pas compromis. Beazley Security recommande toutefois vivement aux organisations qui utilisent Oracle Cloud de vérifier la manière dont elles s'authentifient auprès des applications Oracle Cloud et de changer tous les mots de passe ou secrets partagés entre les différents services. En l'absence d'informations supplémentaires de la part d'Oracle, la communauté de sécurité ne dispose pas de données suffisantes pour déterminer si cet acteur de la menace a été éradiqué avec succès. Par conséquent, il est possible qu'ils aient toujours accès à l'infrastructure cloud d'Oracle. Par conséquent, la rotation des mots de passe uniques utilisés uniquement sur OCI avant qu'Oracle ne fournisse plus de détails n'est peut-être pas une solution adéquate. Veuillez consulter la section Mesures d'atténuation du présent avis pour plus de détails.

Il s'agit d'une situation en évolution, et cet avis sera mis à jour au fur et à mesure que de plus amples informations seront disponibles.

Systèmes et produits concernés

Sur la base des données dont nous disposons jusqu'à présent, Beazley Security pense qu'OCI est concerné, en particulier sa plateforme d'authentification sur login.us2.oraclecloud.com.

Beazley Security Labs a identifié que la vulnérabilité pouvait s'étendre au-delà de cette région cloud spécifique ; il est donc conseillé de considérer tous les services Oracle Cloud comme potentiellement compromis. Le serveur concerné était apparemment Oracle Fusion Middleware 11g, vulnérable à CVE-2021-35587. Bien qu'il soit possible qu'Oracle ait déployé des mesures d'atténuation sur ce système, l'acteur de la menace a affirmé avoir compromis l'Oracle à l'aide d'un CVE connu qui n'est pas une preuve de concept (POC) accessible au public.

Si l'attaque a utilisé cette vulnérabilité, il est recommandé aux utilisateurs d'Oracle Fusion Middleware de mettre immédiatement à jour leur logiciel avec les derniers correctifs.

Étapes d'atténuation

Les mesures d'atténuation efficaces dépendent de la manière dont l'organisation s'authentifie auprès d'Oracle Cloud Infrastructure. Les organisations doivent déterminer quels produits OCI elles utilisent et quels systèmes d'authentification sont en place.

SAML

Si une organisation utilise l'authentification SAML, l'auteur de la menace peut avoir accès aux clés publiques utilisées pour vérifier les assertions SAML signées par votre fournisseur d'identité. Cette situation présente un peu moins de risques, car l'auteur de la menace ne serait pas en mesure de falsifier les demandes d'authentification. Toutefois, si les assertions SAML étaient chiffrées et que l'auteur de la menace était en possession des clés de déchiffrement privées d'Oracle Cloud, il pourrait déchiffrer les assertions d'authentification.

Quelle que soit la manière dont ces assertions sont envoyées (signées ou signées et cryptées), elles contiennent des informations sensibles sur les utilisateurs, telles que les adresses e-mail, les appartenances à des groupes et potentiellement d'autres attributs d'identité tels que les autorisations des services Oracle Cloud qui pourraient être exploités pour des attaques ciblées. Quoi qu'il en soit, les actions liées à l'administration de l'infrastructure d'Oracle relèvent de la responsabilité d'Oracle, et sans informations supplémentaires de la part d'Oracle, peu de choses peuvent être faites du point de vue de l'utilisateur.

OIDC

Si une organisation utilise Open Connect (OIDC), le risque peut être légèrement plus élevé. Si cet acteur malveillant a obtenu le secret du client OIDC pour Oracle Cloud, il pourrait se faire passer pour les demandes d'authentification d'Oracle Cloud adressées à votre fournisseur d'identité. Cela leur permettrait de demander des sessions valides et de s'authentifier en tant qu'utilisateurs d'Oracle Cloud. Nous recommandons la rotation de tous les secrets OIDC pour toute organisation utilisant ce mécanisme d'authentification.

Recommandations générales

Quelles que soient les stratégies d'authentification mises en œuvre pour les applications Oracle Cloud et les services connectés, les organisations doivent considérer que toutes les informations d'identification ou les secrets d'Oracle Cloud sont compromis et doivent alterner ceux qui peuvent être réutilisés ailleurs au sein de l'organisation.

Bien que nous recommandions également normalement la rotation des informations d'identification dans Oracle Cloud, nous devons répéter qu'au moment de la rédaction de cet article, Oracle nie qu'une violation ait réellement eu lieu. Cela signifie que même si Beazley Security conclut raisonnablement que les systèmes d'authentification Oracle Cloud sont compromis, nous ne peut pas concluent que les acteurs de la menace ont été supprimés de ces systèmes car, une fois de plus, Oracle nie qu'une violation se soit produite.

Détails techniques

Une grande partie de ce qui est écrit ici est le résumé d'un article en deux parties de Rahul Sasi sur CloudSek. Si nos résultats supplémentaires vous intéressent, accordez-leur l'attention qu'ils méritent. [1re partie] [Partie 2]. Cependant, il y a des résultats intéressants que nous publions pour la première fois 👀.

Après la publication initiale de BreachForums par « rose87168 », les chercheurs en sécurité ont commencé à travailler pour valider la violation signalée. Rose87168 avait confirmé l'accès à au moins l'un des serveurs concernés login.us2.oraclecloud.com en créant un lien accessible au public sur le serveur à l'adresse « https [:] //login.us2.oraclecloud.com/oamfed/x.txt ? x.` Cela impliquerait que rose87168 avait accès à la modification et à la lecture de fichiers sur au moins un des systèmes d'authentification d'Oracle. Bien que ce fichier ne soit plus disponible, la preuve de son existence se trouve sur la WayBack Machine de la Web Archive

Pour confirmer que login.us2 était un serveur de production Oracle légitime, CloudSek a validé le code de la documentation de démarrage rapide d'Oracle sur Github pour afficher l'URL du serveur concerné qui a été utilisée. CloudSek a ensuite recherché des clés d'API pour Oracle dans les référentiels Github accessibles au public, trouvant cinq cas de ce type, et les a corrélés aux domaines concernés par la fuite provenant de rose87168.

Cela amène les chercheurs en sécurité à conclure raisonnablement à un comportement sommaire du serveur login.us2.oraclecloud.com. Cependant, nous devons maintenant travailler pour valider le mécanisme de l'attaque qui aurait pu compromettre ce serveur. Certains chercheurs ont deviné que la version d'Oracle Fusion Middleware était suffisamment ancienne sur ce serveur et affirment qu'il a peut-être été affecté par une vulnérabilité critique (CVE-2021-35587). Beazley Security Labs n'avait pas validé cette hypothèse au moment de la rédaction du présent rapport.

Rose87168 s'est entretenu avec Bleeping Computer et a affirmé être sur ce serveur depuis 40 jours avant de tenter de vendre ces données. Pour étudier cette question, Beazley Security a utilisé la Wayback Machine pour tenter d'obtenir un aperçu de la version d'Oracle Fusion Middleware qui s'exécutait sur cet hôte lors de l'accès présumé des acteurs de la menace.

Nous pouvons trouver une page archivée à partir du 17 févrierth de cette année montrant que ce serveur exécutait « ORACLE FUSION MIDDLEWARE 11 g». À l'aide de ces informations, nous pouvons commencer à trouver d'autres serveurs Oracle Fusion Middleware 11g correspondant au modèle de login.*.oraclecloud.com. Vous trouverez ci-dessous plusieurs exemples de ce qui semble être des systèmes gérés Oracle qui sont en ligne au moment de la rédaction de cet article :

  • login.us9.oraclecloud.com
  • login.us8.oraclecloud.com
  • cldadmininternal.us8.oraclecloud.com 👀
Figure 2 : login.us8.oraclecloud [.] com

En naviguant sur ce site, nous pouvons voir une section intitulée « Documentation en ligne » indiquant que la version de certains services Oracle Cloud est 11.1.1.5, qui semble être un logiciel publié en 2009 selon la documentation d'Oracle.

Figure 3 : Informations sur la version

Il convient de noter ici que de nombreux autres services exécutent ce logiciel, mais qui ne semblent pas être directement liés à Oracle Cloud Infrastructure. Si rose87168 avait exploité une vulnérabilité dans Oracle Fusion Middleware pour us2, nous pouvons raisonnablement supposer que ces autres services sont actuellement vulnérables s'ils ne sont pas affectés.

De plus, un compte Twitter du même nom a commencé à publier des informations qui semblent corroborer le compte du BreachForum. Cela inclut un lien vers la vidéo partagé via AnonFile.io qui montre apparemment une formation administrative interne que rose87168 prétend avoir extraite du serveur. Bien que la connexion entre cet utilisateur de Twitter et l'utilisateur de notre BreachForum ne soit pas confirmée, il convient de garder un œil sur l'activité continue d'AT sur ce compte Twitter.

À ce stade, en tant qu'utilisateurs, nous n'avons que peu de travail concret à faire pour remédier à ce problème. Oracle nie toute violation de données et, en l'absence d'une déclaration publique d'Oracle expliquant les pages archivées présentées ci-dessus, les utilisateurs finaux n'ont aucun moyen de savoir si Oracle prendra des mesures à l'avenir. Cela inclut si rose87168 a toujours accès à login.us2. Rendre la rotation des mots de passe potentiellement infructueuse. D'autant plus qu'il existe des correctifs pour Oracle Fusion Middleware qui corrigent les vulnérabilités actuellement connues, sans qu'une vulnérabilité ou une attaque ne soit reconnue, les utilisateurs utilisant des versions sur site de ce logiciel n'ont pas grand-chose à faire pour atténuer les risques. Cela place les chercheurs en sécurité dans une situation précaire lorsqu'ils signalent des informations potentiellement incorrectes, tandis qu'Oracle peut continuer à nier tout impact potentiel.

Comment Beazley Security réagit

Beazley Security Labs a collecté la liste des organisations prétendument touchées et l'a corrélée avec les organisations assurées par Beazley et Beazley Security a demandé aux clients de communiquer avec les organisations potentiellement touchées.

Sources

Aware of an incident impacting your industry? Let us know:

Report an incident