Eine Sicherheitslücke, die die Veröffentlichung eines Updates für jedes Paket im NPM-Repository ermöglichte

GitHub hat zwei Vorfälle in seiner NPM-Paket-Repository-Infrastruktur offengelegt. Am 2. November meldeten externe Sicherheitsforscher (Kajetan Grzybowski und Maciej Piechota) im Rahmen des Bug Bounty-Programms das Vorhandensein einer Schwachstelle im NPM-Repository, die es Ihnen ermöglicht, mit Ihrem Konto eine neue Version eines beliebigen Pakets zu veröffentlichen. das nicht berechtigt ist, solche Updates durchzuführen.

Die Schwachstelle wurde durch falsche Berechtigungsprüfungen im Code von Microservices verursacht, die Anfragen an NPM verarbeiten. Der Autorisierungsdienst führte Paketberechtigungsprüfungen basierend auf den in der Anfrage übergebenen Daten durch, aber ein anderer Dienst, der das Update in das Repository hochgeladen hat, bestimmte das zu veröffentlichende Paket basierend auf dem Metadateninhalt des hochgeladenen Pakets. So könnte ein Angreifer die Veröffentlichung eines Updates für sein Paket, auf das er Zugriff hat, anfordern, aber im Paket selbst Informationen über ein anderes Paket angeben, das schließlich aktualisiert werden würde.

Das Problem wurde 6 Stunden nach der Meldung der Schwachstelle behoben, die Schwachstelle war jedoch länger in NPM vorhanden, als die Telemetrieprotokolle abdecken. GitHub behauptet, dass es seit September 2020 keine Spuren von Angriffen unter Ausnutzung dieser Schwachstelle gegeben habe, es gibt jedoch keine Garantie dafür, dass das Problem nicht bereits zuvor ausgenutzt wurde.

Der zweite Vorfall ereignete sich am 26. Oktober. Während der technischen Arbeit mit der Datenbank des Dienstes „repliate.npmjs.com“ wurde das Vorhandensein vertraulicher Daten in der Datenbank aufgedeckt, die für externe Anfragen zugänglich waren, und Informationen über die Namen interner Pakete preisgegeben, die im Änderungsprotokoll erwähnt wurden. Informationen über solche Namen können verwendet werden, um Abhängigkeitsangriffe auf interne Projekte durchzuführen (im Februar ermöglichte ein ähnlicher Angriff die Ausführung von Code auf den Servern von PayPal, Microsoft, Apple, Netflix, Uber und 30 anderen Unternehmen).

Darüber hinaus hat GitHub aufgrund der zunehmenden Fälle von Kaperung von Repositories großer Projekte und der Verbreitung von Schadcode über kompromittierte Entwicklerkonten beschlossen, eine obligatorische Zwei-Faktor-Authentifizierung einzuführen. Die Änderung tritt im ersten Quartal 2022 in Kraft und gilt für Betreuer und Administratoren von Paketen, die in der Liste der beliebtesten Pakete aufgeführt sind. Darüber hinaus wird über die Modernisierung der Infrastruktur berichtet, bei der eine automatisierte Überwachung und Analyse neuer Paketversionen eingeführt wird, um böswillige Änderungen frühzeitig zu erkennen.

Denken Sie daran, dass laut einer im Jahr 2020 durchgeführten Studie nur 9.27 % der Paketbetreuer eine Zwei-Faktor-Authentifizierung verwenden, um den Zugriff zu schützen, und in 13.37 % der Fälle versuchten Entwickler bei der Registrierung neuer Konten, kompromittierte Passwörter wiederzuverwenden, die in auftauchten Bekannte Passwortlecks. Bei einer Überprüfung der Passwortsicherheit wurde auf 12 % der NPM-Konten (13 % der Pakete) aufgrund der Verwendung vorhersehbarer und trivialer Passwörter wie „123456“ zugegriffen. Zu den problematischen zählten 4 Benutzerkonten aus den Top 20 der beliebtesten Pakete, 13 Konten mit Paketen, die mehr als 50 Millionen Mal pro Monat heruntergeladen wurden, 40 mit mehr als 10 Millionen Downloads pro Monat und 282 mit mehr als 1 Million Downloads pro Monat. Unter Berücksichtigung des Ladens von Modulen entlang einer Kette von Abhängigkeiten könnte die Gefährdung nicht vertrauenswürdiger Konten bis zu 52 % aller Module in NPM betreffen.

Source: opennet.ru

Kommentar hinzufügen