npm hat diese Woche einen neuen Schutz eingeführt für seine am stärksten abhängigen Konten. Wenn npm eine sensible Aktion auf einem Konto mit hoher Auswirkung erkennt, wie einen E-Mail-Wechsel oder die Verwendung eines 2FA-Wiederherstellungscodes, versetzt es dieses Konto in einen 72-stündigen Nur-Lese-Status und sendet eine Benachrichtigung an die vorherige E-Mail-Adresse. Die Paketinstallationen und -Downloads funktionieren während dieser Zeit normal weiter, und die Sperre wird am Ende der Wartezeit automatisch aufgehoben.
Dieses Update verhindert Aktionen, die die Registry oder die Kontosicherheit betreffen, wie Veröffentlichung, Token-Verwaltung, Änderungen der Paketsichtbarkeit und Änderungen der Organisationsmitgliedschaft. Es ist eine Kontrolle auf Registry-Ebene, um schnell zu erkennen, wenn ein Konto aus der Kontrolle seines Besitzers gerät.
Das ist großartig und nur die jüngste in einer Reihe von Sicherheitsverbesserungen von npm. Sie haben uns im Mai Staged Publishing gegeben und werden im Juli in v12 Postinstall-Skripte standardmäßig blockieren. Die Standardeinstellungen neigen sich langsam der Prävention zu und weg von der Reaktion. Microsoft hat in letzter Zeit an Sicherheitsfixes gearbeitet, wahrscheinlich inspiriert durch eine Reihe von Malware-Angriffen, die auf seinen Plattformen (und gegen seine Plattformen) stattfinden.
npm hat für diese Funktion keinen neuen Schwellenwert festgelegt, aber den Begriff bereits zuvor verwendet. Seine 2FA-Durchsetzungsrichtlinie definiert ein Konto mit hoher Auswirkung als eines, das Pakete mit mehr als 1 Million wöchentlichen Downloads oder 500 Abhängigkeiten verwaltet, und der Cooldown verwendet wahrscheinlich die gleichen Kriterien.
Der Anstoß für diese Änderung
Die jüngste axios-Kompromittierung im März und der Mastra-Angriff erst letzte Woche sind die deutlichsten Beispiele in jüngster Erinnerung, warum dies notwendig ist. Diese Angriffe nutzten Social-Engineering-Kampagnen gegen die Zielkonten, um Zugang zu erhalten. Im Fall von axios gab sich der Angreifer als Unternehmensgründer aus und lockte einen leitenden Maintainer in einen Videoanruf. Der Anruf-Link enthielt eine „Ihr System ist veraltet“-Aufforderung, die einen Remote Access Trojaner (RAT) installierte und dem Angreifer die Kontrolle über die Maschine des Opfers und eine aktive npm-Sitzung übergab. Sie änderten die Konto-E-Mail und veröffentlichten dann direkt zwei bösartige Versionen von axios, wobei das gesamte CI-System umgangen wurde. axios verzeichnet etwa 100 Millionen Downloads pro Woche.
Diese Art von Angriff ist für die Registry größtenteils unsichtbar, ebenso wie die Schritte auf Slack und die kompromittierte Maschine. Die E-Mail-Änderung ist der einzige Schritt in der Abfolge, in den npm Einblick hat. Angreifer ändern E-Mails, weil dies den Wiederherstellungspfad des tatsächlichen Besitzers unterbricht und Sicherheitswarnungen von ihnen wegleitet.
Wie es zu npms anderen Sicherheitsänderungen passt
Der Cooldown ist noch nützlicher, wenn man ihn im Zusammenhang mit den beiden Fixes betrachtet, die npm im letzten Jahr oder so ausgeliefert hat.
Trusted Publishing entfernt langlebige Tokens. Die Veröffentlichung authentifiziert sich über kurzlebige OIDC-Anmeldeinformationen, die auf einen CI-Workflow zugeschnitten sind, sodass kein langlebiges Token auf einer Maschine liegt, das ein RAT stehlen könnte. Es nützt jedoch nichts, wenn ein Angreifer eine aktive Sitzung hält und direkt veröffentlicht.
Staged Publishing, das wir letzten Monat erhalten haben, fügt einen menschlichen Genehmigungsschritt hinzu. Ein Paket, das aus CI gestaged wurde, geht erst live, wenn ein Maintainer es mit 2FA genehmigt, sodass ein automatisierter Workflow allein keine Veröffentlichung in die Welt bringen kann. Ein Angreifer, der das Konto kontrolliert, kann dies umgehen, indem er sein eigenes gestagedes Paket genehmigt, sofern das Paket dies überhaupt aktiviert hat.
Zusammen bewältigt Trusted Publishing gestohlene Anmeldeinformationen, Staged Publishing ungeprüfte automatisierte Veröffentlichungen, und der Cooldown die Kontoübernahme, die die anderen beiden umgehen. Natürlich löst dies nicht alles, aber wenn Sie nur-Staging Trusted Publishing und deaktivierte Tokens haben, verhindern Sie einen Großteil der Veröffentlichungswege, die Angreifer genutzt haben.
Was jetzt zu tun ist
Wenn Sie ein populäres Paket pflegen, überprüfen Sie, ob die E-Mail-Adresse Ihres npm-Kontos eine ist, die Sie kontrollieren und tatsächlich überwachen (andernfalls werden Sie deren E-Mail-Benachrichtigung verpassen). Wechseln Sie zu FIDO2, wo immer möglich. Behandeln Sie eine unerwartete E-Mail-Änderungsbenachrichtigung als Sicherheitsvorfall und nicht als Spam oder Fehler. Wenn Sie aus CI veröffentlichen, konfigurieren Sie Trusted Publishing als nur-Staging und deaktivieren Sie Tokens, sodass jede Veröffentlichung eine menschliche Genehmigung durchläuft und keine langlebigen Anmeldeinformationen gestohlen werden können. Wenn Sie doch eine unerwartete E-Mail über eine Kontoänderung erhalten, kontaktieren Sie den npm-Support.
Wenn Sie Pakete konsumieren, anstatt sie zu veröffentlichen, herzlichen Glückwunsch! Sie profitieren, ohne etwas zu tun. Dennoch werden einige Pakete nicht alle ihre Sicherheitsmaßnahmen aktiviert haben (viele haben diese Sicherheitseinstellungen immer noch nicht aktiviert). Safe Chain von Aikido ist ein kostenloser, quelloffener Wrapper für npm, npx und yarn, der jedes Paket vor der Installation auf Malware prüft und eine Wartezeit für neue Versionen erzwingt, wodurch ein Großteil kompromittierter Releases abgefangen wird, bevor sie Ihre Maschine erreichen.
Es war großartig, in letzter Zeit über positive Änderungen an den Paket-Registries schreiben zu können.
