En bref : lien de support hardcodé ociforums.com à l'intérieur du settings-v2.js d'Oracle
- Chaque entreprise croit retirer proprement ses références fournisseurs, mais Oracle a livré un lien de support pas-d-agents-disponibles vivant vers ociforums.com depuis settings-v2.js pendant que le domaine était expiré et à vendre.
- cside a repéré la référence à ociforums.com par observation comportementale côté client, l'a signalée, et Oracle nous a crédités sur l'avis de sécurité cpuoct2025, précisément parce que le CSP aurait gardé un nouveau propriétaire malveillant sur la liste autorisée et le SRI ne protège pas un lien hypertexte dans l'UI qui n'est pas une dépendance de script hachée.
- Le lien était hardcodé dans le JavaScript de chaque intégration du widget, donc la décision est de savoir si vous continuez à découvrir des références expirées dans du code livré par chance ou par surveillance comportementale continue à l'exécution de chaque domaine que vous appelez encore.
Chez cside, nous surveillons en permanence les sites web à la recherche de tout comportement suspect, afin de protéger les utilisateurs avant que les attaques ne surviennent. Récemment, nous avons repéré un cas intéressant impliquant un site bien connu : Oracle.
En examinant l'un des fichiers JavaScript publics d'Oracle, nous avons constaté qu'il contenait un lien vers un domaine expiré.
[https://www.oracle.com/asset/web/js/settings-v2.js](https://www.oracle.com/asset/web/js/settings-v2.js)
Ce blog met en lumière les risques liés aux domaines oubliés ou expirés dans le code côté client. Ce n'est pas un problème ancien ou rare : il peut toucher aussi bien les grandes que les petites entreprises, et ouvrir facilement la porte à une attaque de la chaîne d'approvisionnement.
Remarque : Notre équipe a signalé cette découverte à Oracle, qui y a remédié rapidement. L'objectif de ce blog est d'examiner les implications en matière de sécurité d'un point de vue défensif. Il ne doit pas être interprété comme un guide d'exploitation ou de développement de nouvelles techniques d'attaque.
Le domaine expiré en question
Certaines parties de cette section sont rédigées au présent, car elles sont tirées directement de conversations avec notre analyste en sécurité.
Le domaine expiré est :
ociforums.com
Le visiter aujourd'hui redirige vers :
https://expireddomains.com/domain/ociforums.com
(la capture d'écran a été prise au moment de la découverte ; le problème a depuis été corrigé).
Dans le fichier JavaScript d'Oracle, on trouve une référence à :
http://ccc.ociforums.com/
Ce lien apparaît dans le code du site dans le cadre d'un message affiché aux utilisateurs lorsqu'aucun agent de chat en direct n'est disponible. Le domaine étant expiré et disponible à la vente, n'importe qui pourrait l'acheter et l'utiliser à des fins malveillantes.
Pourquoi ce domaine expiré représentait un risque de sécurité
Voici l'extrait exact du fichier :
ocFeedback: {
en: "Sorry, no agents are available... post your question at <a href='http://ccc.ociforums.com/'>http://ccc.ociforums.com/</a>..."
}
Ce message est affiché aux utilisateurs qui cherchent déjà de l'aide. Ils sont donc plus enclins à faire confiance au lien, le percevant comme une page d'assistance Oracle légitime. Si un attaquant achetait le domaine, plusieurs risques pourraient en découler :
- Phishing : l'attaquant pourrait créer un faux forum imitant celui d'Oracle et inciter les utilisateurs à saisir leurs identifiants de connexion.
- Hébergement de malwares : le domaine pourrait distribuer des téléchargements malveillants ou exécuter des kits d'exploitation.
- Abus SEO : le domaine conservant potentiellement un bon référencement, il pourrait apparaître dans les recherches d'assistance Oracle et orienter les internautes vers le faux site.
- Atteinte à la marque : si des utilisateurs sont trompés, ils pourraient en tenir Oracle pour responsable et perdre confiance dans la marque.
Risque à long terme : le lien est codé en dur dans le JavaScript, ce qui signifie que chaque site utilisant ce widget devrait être mis à jour. Sans correctif rapide, l'exposition persiste.
Exemple de scénario d'attaque
- Un utilisateur tente d'obtenir de l'aide auprès d'Oracle, mais aucun agent n'est disponible.
- Le message l'invite à se rendre sur ccc.ociforums.com.
- Le domaine appartient désormais à un attaquant.
- L'utilisateur clique et est invité à se connecter avec ses identifiants Oracle.
- L'attaquant récupère les identifiants et peut également distribuer des malwares ou lancer d'autres arnaques.
Ce qu'a fait l'équipe cside
Nous avons contacté Oracle et les avons informés du problème lié au domaine expiré. Ils ont agi très rapidement pour racheter le domaine et nous ont accordé un crédit dans leurs programmes de signalement de sécurité. Nous saluons la réactivité d'Oracle.
Cette situation illustre à quel point la complexité des sites web et leur exposition dans le temps peuvent devenir un défi, même pour des organisations remarquablement bien préparées face aux incidents de sécurité. La sécurité côté client est un domaine souvent négligé, et cela s'applique malheureusement aux entreprises de toutes tailles.
Qu'est-ce qui aurait pu prévenir une attaque par domaine expiré ?
Si l'on envisage le scénario où un attaquant aurait effectivement obtenu l'accès à ce domaine : la CSP et la SRI auraient toutes deux échoué à le détecter.
La CSP et la SRI auraient été insuffisantes :
La CSP (Content Security Policy) et la SRI (Sub Resource Integrity) sont des mécanismes de défense côté client couramment utilisés. La CSP valide l'origine des requêtes, mais pas si la destination est toujours sûre. Le navigateur autorisera la requête quel que soit le propriétaire actuel du domaine. La SRI garantit l'intégrité des fichiers uniquement lorsque le développeur contrôle la ressource. Dans ce cas, la référence était un hyperlien affiché dans l'interface utilisateur, et non une dépendance de script externe protégée par un hash.
La sécurité côté client détecte les signes d'une attaque par domaine expiré :
Une plateforme de sécurité côté client comme cside observe en permanence le comportement des scripts à l'exécution. Si un domaine commence soudainement à émettre des redirections, à collecter des frappes clavier, à servir du JavaScript inattendu ou à renvoyer des réponses inhabituelles, ce changement de comportement devient immédiatement un signal d'alerte. Une notification est alors déclenchée pour que les équipes de sécurité puissent procéder à une inspection.
