Alerte : le paquet NuGet qui prétend être un SDK bancaire pour voler les identifiants et certificats PFX

Les chercheurs en sécurité ont détecté un paquet malveillant à NuGet posant comme un SDK légitime pour Sicoob, l'une des plus grandes coopératives financières au Brésil, et dont l'objectif était de vol des identifiants API et des certificats PFX utilisé par les entreprises pour authentifier le réseau bancaire et automatiser les paiements et les frais. La menace n'est pas seulement technique: elle exploite la confiance des développeurs qui cherchent à intégrer les services bancaires, transformant une installation de routine en un écart potentiellement critique pour les paiements et les données financières.

Techniquement, le paquet a intercepté le flux d'initialisation normal du client : lorsqu'un développeur a fourni un client ID, la route vers un fichier PFX et son mot de passe, le code malveillant a lu le fichier PFX à partir du disque, encodé son contenu et envoyé ce paquet - avec le client ID et le mot de passe - pour préconfigurer des paramètres agissant comme récepteurs d'exfiltration. En outre, il y avait des canaux dédiés pour capturer les réponses brutes de l'API Ticket, qui expose non seulement les identifiants mais aussi les détails des transactions, des montants, des échéances et des identifiants sensibles.

Il y a plusieurs points d'intérêt dans cette campagne qui doivent concerner la communauté : d'abord, le paquet a été distribué depuis NuGet et a atteint des centaines de téléchargements avant d'être bloqué, ce qui montre que les enregistrements publics restent un vecteur efficace pour répandre le code malveillant. Deuxièmement, les agresseurs ont utilisé Tactique "légitime fabriquée" en associant le paquet à un dépôt GitHub apparemment légitime, créant une discorde entre le code public et le binaire distribué par NuGet ; cette séparation rend la détection manuelle et trompe les vérificateurs de surface.

Un autre amplificateur du problème a été l'apparition du paquet dans les résultats générés par les outils de recherche basés sur l'IA, qui l'a recommandé comme bibliothèque valide pour s'intégrer à Sicoob. Cette combinaison - enregistrement public + apparence légitime + recommandations automatiques - fait des développeurs non préparés installer des unités sans contrôle approprié, exposant ainsi les qualifications de production et les actifs critiques.

Cet incident est inséré dans une vague plus large d'attaques de la chaîne d'approvisionnement logicielle qui ont principalement affecté l'écosystème de npm, avec des campagnes utilisant le typosquating, des crochets postinstall et des techniques de dépendance pour extraire des identifiants des environnements locaux, des pipelines CI / CD et des fichiers .envos. Les analystes de sécurité et les entreprises comme Sonatype ont documenté comment les attaquants ont laissé derrière de simples erreurs d'orthographe et maintenant concevoir des noms de paquets et de versions qui semblent totalement plausibles dans les flux de travail réels, une pratique qu'ils décrivent comme légitime. Pour lire l'analyse et les recommandations sur ces techniques, les ressources publiques telles que le blog de Sonatype sont utiles https: / / www.sonatype.com / blog et projets favorisant la signature et la vérification d'objets tels que Sigstore https: / / sigstore.dev.

Les implications pratiques sont graves: avec un PFX et votre mot de passe un attaquant peut remplacement de l'intégration bancaire, créer des paiements ou recevoir des fonds pour le compte de la victime, ou filtrer les informations financières de tiers. Au niveau organisationnel, cela peut entraîner des pertes économiques directes, des fraudes, des sanctions réglementaires et des dommages à la réputation, en particulier sur les marchés où des méthodes telles que Pix et Boleto sont largement adoptées.

Afin de réduire le risque immédiat, des mesures d'urgence et stratégiques doivent être prises. Dans la réponse immédiate, toute personne qui a installé le paquet en question doit le retirer de son code et de ses dépôts, considérer le matériel PFX comme compromis, révoquer ou remplacer les certificats exposés, faire pivoter les mots de passe et désactiver ou régénérer les clients touchés. Parallèlement, il est recommandé de vérifier les registres d'authentification et de transaction de Sicoob à la recherche d'une activité anormale et de coordonner avec l'équipe de sécurité de la banque en cas de signes d'abus.

Sur un plan préventif plus large, les organisations et les développeurs devraient éviter de stocker du matériel sensible dans un texte plat dans des dépôts ou des disques partagés; il est plutôt approprié d'utiliser des coffres secrets et HSM / Vaults qui minimisent la présence de clés dans le système de fichiers. La chaîne d'approvisionnement devrait être protégée par des politiques visant à bloquer les colis non vérifiés, l'utilisation de registres internes ou de listes blanches, la validation des signatures des colis, la génération de SBOM et l'adoption de contrôles tels que SLSA. Mettre en place un balayage automatique des unités, examiner les différences entre le paquet publié et le code source lié, et restreindre l'accès CI / CD aux secrets sensibles sont des contre-mesures qui réduisent la surface de l'attaque.

Enfin, cette affaire rappelle que la sécurité de l'infrastructure de paiement dépend à la fois des bonnes pratiques cryptographiques et de l'hygiène dans la gestion des unités. Les outils automatiques de recommandation et de recherche peuvent accélérer le développement, mais aussi amplifier les risques lorsqu'ils ne sont pas associés à la vérification humaine et aux contrôles techniques. L'industrie doit évoluer vers des flux où la provenance et l'intégrité de chaque unité sont vérifiables par défaut, et les équipes de développement doivent intégrer des examens de sécurité à chaque étape du cycle de vie du logiciel.