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.
