Interview mit Laurie Voss, Co-Founder und COO von npm

Autopsie des ESLint-Hacks: Einmal-Passwort, 2-Faktor-Authentifizierung und die Frage nach den Folgen
Keine Kommentare

ESLint wurde letzte Woche kompromittiert: Ein Package des Projekts versuchte, Nutzerdaten für npm abzugreifen. Wir haben mit npm-Gründer Laurie Voss im Interview über den Vorfall gesprochen und ihn gefragt, wie npm seine Nutzer vor solchen Angriffen schützt.

ESLint wurde angegriffen, npm annullierte daraufhin alle Zugangstoken. Dieser Vorfall erregte letzte Woche viel Aufsehen in der Entwicklerszene und verunsicherte manche Nutzer. Woher kamen die Zugangsdaten, die für den Angriff genutzt wurden? Wie kann man das eigene Projekt schützen? Wir haben Laurie Voss, Gründer von npm, gefragt, welche Folgen der Angriff hatte und ob sich der Schadcode noch in anderen Packages auf npm verstecken könnte.

Entwickler: Der Vorfall vom 12. Juli betraf ESLint und wurde durch eine Sicherheitslücke woanders verursacht, wie ESLint bestätigt. Was ist genau passiert und wer war betroffen?

Laurie Voss: Bei ESLint arbeiten einige Freiwillige zusammen an der Entwicklung von Open Source Software. Etwa ein Dutzend Personen

Laurie Voss

haben Zugang zur Veröffentlichung von ESLint-Packages auf npm und wir wissen aus dem Blogpost von ESLInt, dass einer der Mitwirkenden ein Passwort benutzt hat, das ebenfalls auf anderen Seiten benutzt wurde. Die Zwei-Faktor-Authentifizierung (2FA), die von npm bereitgestellt wird, war nicht aktiviert worden. ESLint vermutet, dass der Angriff damit begann, dass jemand das Passwort des Nutzers in irgendeiner anderen Quelle gefunden hat und dann auf dem entsprechenden npm-Account ausprobierte.

Als der Angreifer dann einen funktionierenden Benutzernamen mitsamt Passwort zur Verfügen hatte, loggte er sich in npm ein und veröffentlichte eine neue Version (3.7.2) des Package „eslint-scope“. In dieser neuen Version war schädlicher Code enthalten, der ausgeführt werden sollte, sobald ein Benutzer eslint-scope herunterlädt und installiert. Dieser Code hat versucht, weitere Login-Tokens für npm von anderen Nutzern zu stehlen, indem er sie an einen remote Server schicken sollte. Wenn das geklappt hätte, hätten so andere Packages übernommen und mehr Nutzer kompromittiert werden können.

Das schädliche Package wurde um 3:40 Uhr PST gepostet. Um 5:00 Uhr haben npm-Benutzer das Problem entdeckt; der remote Server wurde um 5.30 Uhr PST abgeschaltet. Dadurch wurde das weitere Sammeln von persönlichen Daten unterbunden. Gegen 7:30 Uhr PST hatte npm Maßnahmen getroffen, um die Veröffentlichung von weiteren, kompromittierten Packages zu verhindern. Wir sind dann einen wichtigen Schritt weiter gegangen und haben alle Login-Tokens für npm deaktiviert, die vor 7.30 Uhr PST erstellt wurden. Das bedeutet, dass alle Token, die zwischen 3.40 Uhr und 7.30 Uhr PST vom Angreifer gestohlen wurden, nutzlos sind. Die Lücke wurde geschlossen.

Unseres Wissens nach wurde im Zeitraum des Angriffs und danach kein anderes Package erfolgreich kompromittiert. Einer der Gründe dafür ist, dass die 2FA-Features von npm eine „2fa on puplish“-Funktion beinhalten. Das bedeutet, dass selbst bei einem erfolgreichen Diebstahl eines Login-Tokens immer noch ein physischer Zugang zum Handy oder zu einem anderen Gerät des Opfers notwendig wäre. Die Autoren der beliebtesten Packages auf npm haben diese Funktion aktiviert, sodass sich der Angriff nicht ausweiten konnte. ESLint war ein sehr seltener Fall eines schwachen Glieds in der Kette.

In Anbetracht der Tatsache, dass das Zeitfenster für den Angriff bei zwei Stunden lag und gemessen anhand der Zahl eingeloggter Nutzer, die das Package in dieser Zeit hätten herunterladen können, lag die Zahl der potentiell betroffenen Nutzer bei etwa ~500. Die tatsächliche Zahl scheint aber eher bei Null zu liegen, mit der Ausnahme des ersten Opfers natürlich. Wir untersuchen den Fall immer noch, um das zu bestätigen.

Entwickler: Wie werden solche Vorfälle identifiziert?

Laurie Voss: Die riesengroße Nutzerbasis von npm mit ihren 10 Millionen Entwicklern umfasst einen großen Pool an Experten, die böswilliges und unerwartetes Verhalten identifizieren können. Zwar verfügt npm auch über zahlreiche automatisierte Mechanismen zur Erkennung von Sicherheitslücken, aber dennoch sind es oft Menschen, die ein Problem zuerst melden. Das war dieses Mal der Fall: Unsere erste Benutzerbenachrichtigung über ein Problem traf um 4:56 Uhr am Morgen ein. Hätte eine größere Kettenreaktion stattgefunden, hätten auch die automatisierten Systeme von npm das Problem bemerkt. Die Nutzer haben es aber bereits am Anfang entdeckt.

Entwickler: Wie lange dauert das für gewöhnlich?

Laurie Voss: Solche Sicherheitsvorfälle sind ziemlich selten, daher kann man auch nicht von einem „normalen“ Zeitraum sprechen. Frühere Vorfälle wurden allerdings in einem ähnlichen Zeitrahmen gelöst: 2 bis 3 Stunden nach dem anfänglichen Problem für die Notfallmaßnahmen und eine anschließende, sechs- bis siebenstündige Bereinigungsphase und Sicherung des Systems.

Entwickler: npm hat in den letzten Releases viel an der Sicherheit gearbeitet. Haben die neuesten Erweiterungen der npm-Sicherheit eine Auswirkung auf diese Art von Vorfällen?

Laurie Voss: Auf jeden Fall. Um 7.30 Uhr wurde ein Sicherheitshinweis zum Package in die npm-Datenbank eingefügt. Jeder Anwender von npm 6 oder höher wurde auf diese Weise darüber benachrichtigt, dass es einen kritischen Sicherheitsvorfall gab. npm hat aber noch eine Menge an Arbeit vor sich, um unsere Systeme zu härten und diese Art von Angriff von Anfang an zu vermeiden, statt die Nutzer nur schnell darüber zu informieren.

Entwickler: Die Blogposts zu dem Vorfall von ESLint und npm sagen, dass es an anderer Stelle ein Sicherheitslücke gegeben hat, durch die die Zugangsdaten eines Nutzers gestohlen wurden, die auch auf npm funktionierten. Eine andere Theorie über den Vorgang des Vorfalls besagt aber, dass es andere npm-Packages geben könnte, die mit der gleichen Art von Malware infiziert waren und so den Zugriff auf Zugriffstoken für ESLint ermöglichten. Was halten Sie von dieser Theorie?

Laurie Voss: Wir stimmen mit ESLint darin überein, dass das ESLint-Teammitglied der „Patient Zero“ dieses Angriffs war. Wir verlassen uns jedoch nicht auf diese Schlussfolgerung: Wir und unsere Partner scannen jedes der 750.000 Pakete in der Registry gründlich um sicherzustellen, dass dieses Muster des schädlichen Code nirgendwo anders vorkommt. Bis jetzt haben wir keine Anzeichen des schädlichen Codes gefunden, aber die Scans laufen noch.

Entwickler: Gibt es ein npm-Feature, das Anwender jetzt nutzen können, wenn sie sicherstellen wollen, dass diese Art von Malware nicht in einer Abhängigkeit von ihren Projekten versteckt ist?

Laurie Voss: Der einfachste und offensichtlichste Schritt ist ein Upgrade auf npm 6, falls das noch nicht geschehen ist. Dadurch werden die Benutzer sofort über alle bekannten Sicherheitslücken informiert. Der Befehl npm audit führt einen vollständigen Scan des Dependency Trees durch, um sicherzustellen, dass es keine Probleme gibt. Es gibt zusätzliche npm-Konfigurationsschritte, die unternommen werden können, um paranoidere Benutzer zu schützen. Die Konfigurationsoption ignore-scripts deaktiviert das Verhalten, mit dem der bösartige Code bei der Installation ausgeführt werden konnte. Das ist jedoch mit Kompromissen verbunden: Viele nützliche Konfigurationsarbeiten werden oft von Packages während der Installation durchgeführt, sodass das Deaktivieren zu einer Menge von Unannehmlichkeiten führen kann. Den Entwicklern steht es frei, ihre eigenen Kompromisse einzugehen.

Entwickler: In eurem Blogpost habt ihr empfohlen, dass Entwickler eine Zwei-Faktor-Authentifizierung verwenden sollten, um sich vor solchen Vorfällen zu schützen. Wie stellt man das mit npm ein und gibt es noch andere Ratschläge, wie man sich vor solchen Vorfällen schützen kann?

Laurie Voss: Am einfachsten ist es, sich auf npmjs.com einzuloggen und diesen kurzen Anweisungen zu folgen. Der Vorgang dauert etwa 30 Sekunden und wer bereits eine Zwei-Faktor-Authentifizierung auf einer anderen Website genutzt hat, dem werden diese Schritte sehr bekannt vorkommen. Wir empfehlen hier die höchste Sicherheitseinstellung, die sowohl für die Anmeldung als auch bei jeder Veröffentlichung eines Packages ein Einmalpasswort erfordert. In Bezug auf andere Schritte gibt es nicht viel, was normale npm-Benutzer tun müssen; dieser Angriff richtet sich eher gegen Package-Autoren als an Leute, die Pakete installieren.

Vielen Dank für das Interview!

Im Interview: Laurie Voss
Laurie Voss is co-founder and COO of npm.
Unsere Redaktion empfiehlt:

Relevante Beiträge

X
- Gib Deinen Standort ein -
- or -