Vor ein paar Tagen GitHub enthüllte zwei Vorfälle in der NPM-Paket-Repository-Infrastruktur: Darin heißt es, dass am 2. November Sicherheitsforscher von Drittanbietern im Rahmen des Bug-Bounty-Programms eine Schwachstelle im NPM-Repository gefunden haben die es ermöglicht, eine neue Version jedes Pakets zu veröffentlichen, obwohl es nicht autorisiert ist um solche Aktualisierungen durchzuführen.
Die Schwachstelle wurde durch falsche Berechtigungsprüfungen im Microservices-Code verursacht die Anfragen an NPM verarbeiten. Der Autorisierungsservice hat eine Berechtigungsprüfung für die Pakete basierend auf den in der Anforderung übergebenen Daten durchgeführt, aber ein anderer Service, der das Update in das Repository hochgeladen hat, hat das zu veröffentlichende Paket basierend auf dem Metadateninhalt im hochgeladenen Paket bestimmt.
So könnte ein Angreifer die Veröffentlichung eines Updates für sein Paket anfordern, auf das er Zugriff hat, aber im Paket selbst Informationen über ein anderes Paket angeben, das eventuell aktualisiert würde.
In den letzten Monaten hat das npm-Team in Infrastruktur- und Sicherheitsverbesserungen investiert, um die Überwachung und Analyse kürzlich veröffentlichter Paketversionen zu automatisieren, um Malware und anderen bösartigen Code in Echtzeit zu identifizieren.
Es gibt zwei Hauptkategorien von Malware-Posting-Ereignissen, die im npm-Ökosystem auftreten: Malware, die aufgrund von Kontoentführungen veröffentlicht wird, und Malware, die Angreifer über ihre eigenen Konten veröffentlichen. Obwohl Account-Akquisitionen mit großen Auswirkungen relativ selten sind, können Account-Akquisitionen im Vergleich zu direkter Malware, die von Angreifern über ihre eigenen Accounts verbreitet wird, weitreichend sein, wenn es um beliebte Paketbetreuer geht. Während unsere Erkennungs- und Reaktionszeit beim Erwerb beliebter Pakete bei jüngsten Vorfällen nur 10 Minuten betrug, entwickeln wir unsere Malware-Erkennungsfunktionen und Benachrichtigungsstrategien weiter in Richtung eines proaktiveren Reaktionsmodells.
Das Problem es wurde 6 Stunden nach Meldung der Schwachstelle behoben, aber die Schwachstelle war länger in NPM vorhanden als das, was Telemetrieprotokolle abdecken. GitHub gibt an, dass es keine Spuren von Angriffen gegeben hat, die diese Sicherheitsanfälligkeit ausnutzen seit September 2020, aber es gibt keine Garantie dafür, dass das Problem nicht schon einmal ausgenutzt wurde.
Der zweite Vorfall ereignete sich am 26. Oktober. Im Zuge der technischen Arbeit mit der Dienstdatenbank Replikant.npmjs.com Es wurde festgestellt, dass in der Datenbank vertrauliche Daten für externe Konsultationen verfügbar waren, die Informationen über die Namen der internen Pakete enthüllt, die im Changelog erwähnt wurden.
Informationen zu diesen Namen kann verwendet werden, um Abhängigkeitsangriffe auf interne Projekte durchzuführen (Im Februar ermöglichte ein solcher Angriff die Ausführung von Code auf den Servern von PayPal, Microsoft, Apple, Netflix, Uber und 30 anderen Unternehmen.)
Zusätzlich im Zusammenhang mit der zunehmenden Beschlagnahme von Endlagern bei Großprojekten und die Förderung von bösartigem Code durch Kompromittierung von Entwicklerkonten, GitHub hat beschlossen, eine obligatorische Zwei-Faktor-Authentifizierung einzuführen. Die Änderung tritt im ersten Quartal 2022 in Kraft und gilt für die Betreuer und Administratoren der Pakete, die in der Liste der beliebtesten enthalten sind. Darüber hinaus berichtet es über die Modernisierung der Infrastruktur, die die automatisierte Überwachung und Analyse neuer Paketversionen zur Früherkennung bösartiger Änderungen einführen wird.
Denken Sie daran, dass laut einer Studie aus dem Jahr 2020 nur 9.27% der Paketmanager die Zwei-Faktor-Authentifizierung zum Schutz des Zugriffs verwenden und in 13.37 % der Fälle bei der Registrierung neuer Konten versuchten, kompromittierte Passwörter wiederzuverwenden, die in bekannten Passwörtern vorkommen .
Bei der Überprüfung der Stärke der verwendeten Passwörter wurden 12% der Konten in NPM (13% der Pakete) aufgrund der Verwendung vorhersehbarer und trivialer Passwörter wie "123456" aufgerufen. Zu den Problemen gehörten 4 Benutzerkonten der 20 beliebtesten Pakete, 13 Konten, deren Pakete mehr als 50 Millionen Mal pro Monat heruntergeladen wurden, 40 - mehr als 10 Millionen Downloads pro Monat und 282 mit mehr als 1 Million Downloads pro Monat. In Anbetracht der Modullast entlang der Abhängigkeitskette könnte die Kompromittierung nicht vertrauenswürdiger Konten insgesamt bis zu 52 % aller Module in NPM betreffen.
Schließlich wenn Sie mehr darüber wissen möchten Sie können die Details überprüfen im folgenden Link.