Alarm: das NuGet-Paket, das vorgab, eine Bank SDK zu stehlen PFX Anmeldeinformationen und Zertifikate

Sicherheitsforscher haben ein schädliches Paket in NuGet posiert als legitimes SDK für Sicoob, einer der größten Finanzgenossenschaften in Brasilien, und dessen Ziel war, stehlen API-Berechtigungen und PFX-Zertifikate von Unternehmen verwendet, um das Banknetz zu authentifizieren und Zahlungen und Gebühren zu automatisieren. Die Bedrohung ist nicht nur technisch: Sie nutzt das Vertrauen von Entwicklern, die Bankdienstleistungen integrieren wollen, und verwandelt eine Routineinstallation in eine potenziell kritische Lücke für Zahlungen und Finanzdaten.

Technisch griff das Paket den normalen Kunden-Initialisierungsfluss ab: wenn ein Entwickler einen ID-Client, die Route zu einer PFX-Datei und sein Passwort bereitstellte, las der bösartige Code die PFX-Datei von der Festplatte, kodierte ihren Inhalt und schickte dieses Paket - zusammen mit dem ID-Client und dem Passwort - zu vorkonfigurierten Endpunkten, die als Exfiltrationsrezeptoren wirken. Darüber hinaus gab es dedizierte Kanäle, um Rohreaktionen von der Ticket-API zu erfassen, die nicht nur Anmeldeinformationen, sondern auch Details von Transaktionen, Beträgen, Reifungen und sensiblen Kennungen enthüllt.

Es gibt mehrere Punkte von Interesse an dieser Kampagne, die die Gemeinschaft betreffen müssen: erstens wurde das Paket von NuGet verteilt und erreichte Hunderte von Downloads, bevor es blockiert wurde, was zeigt, dass öffentliche Aufzeichnungen ein effektiver Vektor bleiben, um bösartigen Code zu verbreiten. Zweitens benutzten die Angreifer ein "legitimate hergestellt" Taktik indem das Paket mit einem scheinbar legitimen GitHub-Repository assoziiert wird, wodurch ein Diskord zwischen dem öffentlichen Code und dem Binär verteilt von NuGet entsteht; diese Trennung macht manuelle Erkennung und Täuschung von Oberflächenverifikationen.

Ein weiterer Verstärker des Problems war das Auftreten des Pakets in Ergebnissen, die von IA-basierten Suchtools generiert wurden, die es als gültige Bibliothek empfohlen, mit Sicoob zu integrieren. Diese Kombination - Public Record + legitimes Aussehen + automatische Empfehlungen - macht unvorbereitete Entwickler installieren Einheiten ohne richtige Kontrollen, so dass die Produktion Anmeldeinformationen und kritische Vermögenswerte.

Dieser Vorfall wird in eine breitere Welle von Software-Versorgungs-Kettenangriffen eingefügt, die hauptsächlich das npm-Ökosystem beeinflusst haben, mit Kampagnen mit Typosquating, Postinstall-Hooks und Abhängigkeitstechniken, um Anmeldeinformationen aus lokalen Umgebungen, CI / CD-Pipelines und .envos-Dateien zu extrahieren. Sicherheitsanalysten und Unternehmen wie Sonatype haben dokumentiert, wie Angreifer hinter einfachen Schreibfehlern zurückgelassen haben und jetzt Designnamen von Paketen und Versionen, die in realen Workflows völlig plausibel erscheinen, eine Praxis, die sie beschreiben, als Legitimität. Um Analyse und Empfehlungen zu diesen Techniken zu lesen, sind öffentliche Ressourcen wie Sonatypes Blog nützlich https: / / www.sonatype.com / blog und Projekte, die die Unterschrift und Überprüfung von Artefakten wie Sigstore fördern https: / / sigstore.dev.

Die praktischen Auswirkungen sind schwer: mit einem PFX und Ihrem Passwort kann ein Angreifer supplanting bank integration, Zahlungen erstellen oder im Namen des Opfers Mittel erhalten oder Finanzinformationen von Dritten filtern. Auf organisatorischer Ebene kann dies zu direkten wirtschaftlichen Verlusten, Betrug, regulatorischen Sanktionen und Reputationsschäden führen, insbesondere in Märkten, in denen Methoden wie Pix und Boleto weit verbreitet sind.

Um das unmittelbare Risiko zu verringern, müssen sowohl Notfall- als auch strategische Maßnahmen ergriffen werden. In der unmittelbaren Antwort muss jeder, der das betreffende Paket installiert hat, es von seinen Codes und Repositories entfernen, PFX-Material als Kompromisse betrachten, widerrufen oder ersetzen die exponierten Zertifikate, rotieren Passwörter und deaktivieren oder regenerieren die betroffenen Kunden. Parallel dazu wird empfohlen, die Authentifizierungs- und Transaktionsprotokolle in Sicoob auf der Suche nach anormaler Aktivität zu prüfen und mit dem Sicherheitsteam der Bank zu koordinieren, wenn es Anzeichen von Missbrauch gibt.

Auf einer breiteren präventiven Ebene sollten Organisationen und Entwickler verhindern, sensibles Material in flachem Text innerhalb von Repositories oder freigegebenen Festplatten zu speichern; stattdessen ist es angebracht, geheime Puffer und HSM / Vaults zu verwenden, die das Vorhandensein von Schlüsseln im Dateisystem minimieren. Die Lieferkette sollte durch Richtlinien geschützt werden, um unverified Pakete zu blockieren, interne Register oder Whitelists zu verwenden, die Validierung von Paketsignaturen, die Erzeugung von SBOMs und die Annahme von Kontrollen wie SLSA. Implementieren automatische Einheits-Scanning, Überprüfung Unterschiede zwischen dem veröffentlichten Paket und dem verknüpften Quellcode, und beschränken CI / CD-Zugriff auf empfindliche Geheimnisse sind Gegenmaßnahmen, die die Angriffsfläche reduzieren.

Schließlich dient dieser Fall als Erinnerung daran, dass die Sicherheit der Zahlungsinfrastruktur sowohl von guten kryptographischen Praktiken als auch von Hygiene in der Einheitsverwaltung abhängt. Automatische Empfehlungs- und Suchwerkzeuge können die Entwicklung beschleunigen, aber auch Risiken verstärken, wenn sie nicht mit menschlicher Verifikation und technischen Kontrollen kombiniert werden. Die Industrie muss in Richtung der Ströme bewegt werden, in denen die Herkunft und Integrität jeder Einheit standardmäßig nachprüfbar sind, und Entwicklungsteams müssen Sicherheitsbewertungen in jedem Schritt des Software-Lebenszyklus einfügen.