LavaMoat und der Ledger-Software-Supply-Chain-Angriff

Was ist passiert?

Am 14. Dezember war eine der Software-Bibliotheken von Ledger, das Ledger Connect Kit, Ziel eines Software-Supply-Chain-Angriffs.

Der Angriff soll seinen Ursprung darin gehabt haben, dass ein ehemaliger Mitarbeiter, der noch über Veröffentlichungszugriff verfügte, Opfer eines Phishing-Angriffs wurde. Dabei wurden seine npm-Zugangsdaten kompromittiert. npm, oder Node Package Manager, ist ein Tool zum Einbinden von Open-Source-Software-Bibliotheken, das in der Web-Entwicklungsbranche sowie im Web3-Bereich weit verbreitet ist.

Durch diesen Angriff konnte eine bösartige Version der betreffenden Bibliothek veröffentlicht werden. Diese Bibliothek wird in vielen Web-Apps im Ethereum-Ökosystem über ein Content Delivery Network (CDN) live und fortlaufend aktualisiert eingebunden. Dies führte dazu, dass bösartiger Code in diese Web-Apps eingeschleust wurde.

Wie lässt sich das verhindern? LavaMoat.

LavaMoat ist eine Sammlung von Tools, die speziell entwickelt wurden, um die Sicherheitsprobleme in der Software-Supply-Chain zu adressieren, mit denen Web-Anwendungsentwickler konfrontiert sind.

LavaMoat bietet Schutz gegen Supply-Chain-Angriffe an drei verschiedenen Punkten im Software-Entwicklungszyklus: beim Installieren von Abhängigkeiten (wenn all diese Bibliotheken eingebunden werden), zur Build-Zeit (wenn die App für die Bereitstellung über das Internet vorbereitet wird) und zur Laufzeit (wenn die fertige Anwendung ausgeführt wird).

LavaMoat zeichnet sich durch seinen Laufzeitschutz aus. Es gibt andere Tools, die während der Entwicklung eingesetzt werden können, wie etwa snyk.io, das jedoch nur Warnungen zu bekannten Schwachstellen liefert, oder socket.dev, das eine umfassendere Code-Analyse bietet und nicht darauf wartet, dass Experten Erkenntnisse in einer zentralen Datenbank melden. Diese Scan-Tools erfüllen eine unverzichtbare Funktion, und wir empfehlen die Verwendung der GitHub-Integration von socket.dev.

Allerdings können sie keinerlei Laufzeitgarantien bieten. Aus diesem Grund halten wir den alleinigen Einsatz dieser Tools für unzureichend.

Die Sicherheitsschutzmaßnahmen von LavaMoat basieren darauf, Abhängigkeiten Ihrer Anwendung nur explizit festgelegte Berechtigungen zu erteilen.

Was bedeutet das? Lesen Sie weiter und schauen Sie sich unseren Devcon 6-Vortrag an, um ein tieferes Verständnis davon zu erlangen, wie LavaMoat funktioniert und eingesetzt wird.

Eine Einführung in Object Capabilities

Man kann sich ein System als eine Sammlung von Capabilities vorstellen: Dinge, die es tun kann, wie das Anzeigen von Informationen, das Lesen lokal gespeicherter Daten oder das Senden von Anfragen an andere Systeme – etwa Web-Anfragen an Server oder Transaktionsanfragen an Wallets – sowie die Möglichkeit, diese Capabilities an andere zu delegieren.

Beim Delegieren einer Capability kann eine eingeschränkte oder begrenzte Version davon bereitgestellt werden. Dies wird als Attenuation bezeichnet.

Diese drei Komponenten bilden die Grundlage des Object Capability Security-Modells. Mithilfe dieses Modells lässt sich nachvollziehen, wer welche Handlungsmöglichkeiten besitzt.

Sicherheit von Web-Anwendungen

Browser leisten gute Arbeit beim Sandboxing von Anwendungen, d. h. beim Isolieren dieser Anwendungen und beim Verhindern, dass sie Ihren Computer oder andere Websites beeinträchtigen.

Allerdings bieten sie Web-App-Entwicklern keine robusten Bausteine, um bestimmte Teile ihrer App weiter zu isolieren, was verhindern könnte, dass einzelne Komponenten die gesamte Anwendung gefährden.

Aus diesem Grund delegieren Sie beim Einbinden einer Bibliothek in Ihre Anwendung effektiv alle Capabilities an diese Bibliothek. Dies wird dadurch weiter verkompliziert, dass die meisten JavaScript-Bibliotheken nicht nur ihren eigenen Code, sondern eine Sammlung von Bibliotheken verschiedener Autoren mitbringen.

Details zum Ledger-Angriff

Die Bibliothek @ledger/connect-kit-loader ist Ledgers empfohlene Methode zur Integration mit ihren Produkten. Dieses Paket ist ein schlanker Wrapper, der die neueste Version ihrer Bibliothek von einem CDN lädt.

Das bedeutet zwar, dass Ihre App stets über die neueste Version der Bibliothek verfügt, aber es bedeutet auch, dass Sie die Kontrolle über Ihre Web-App effektiv an die Ledger-Loader-Bibliothek delegieren, die sie wiederum an den auf dem CDN gehosteten Code weitergibt.

Die Delegationskette lässt sich wie folgt darstellen:

Web App → **@ledger/connect-kit-loader** → jsDelivr CDN → npm → Ledger → ehemaliger Ledger-Mitarbeiter → Angreifer

Selbst das ist noch eine Vereinfachung. Betrachtet man eine einzelne Komponente genauer, wie etwa das jsDeliver CDN, offenbart sich eine verblüffende Komplexität zusätzlicher Dienste, die ebenfalls Teil der Supply Chain und potenzielle Einfallstore für Angriffe sind.

Anwendungen mit Object Capability Security absichern

Obwohl Browser selbst, wie erwähnt, kaum Werkzeuge zur Einschränkung der Capabilities von Unterkomponenten einer Anwendung bereitstellen, ist die Programmiersprache JavaScript für diese Aufgabe tatsächlich gut geeignet.

JavaScript ermöglicht es mit etwas Sorgfalt, sogenannte Compartments zu erstellen, die den Zugriff von Code einschränken. Für eine Implementierung von Compartments sei auf Agoric's Hardened Javascript verwiesen.

MetaMasks LavaMoat Supply-Chain-Sicherheitssystem und das MetaMask Snaps Plugin-System bauen beide auf Compartments auf, um Isolation zu erreichen.

Hätte LavaMoat den Ledger-Supply-Chain-Angriff verhindert?

Die Frage, ob LavaMoat ihn verhindert hätte, ist ein bisschen so, als würde man fragen, ob die Berührungsschutzfunktion einer Tischkreissäge helfen würde, wenn man die Säge festhält und von einer Klippe springt – ja, die Finger würden nach dem Sprung wahrscheinlich noch an der Hand hängen.

Grundsätzlich zwingt die Funktionsweise von @ledgerhq/connect-kit-loader den App-Entwickler dazu, auf viele etablierte Sicherheits-Best-Practices zu verzichten. Doch es gibt noch Hoffnung.

Der beste Weg, LavaMoat (und andere Supply-Chain-Sicherheitstools) für sich arbeiten zu lassen, wäre die direkte Verwendung von @ledgerhq/connect-kit, ohne die gesamte Kontrolle an den Loader abzugeben.

LavaMoat wurde entwickelt, um Angriffe wie den Copay-Wallet-Hack, auch bekannt als „the event-stream incident", abzuwehren, und schützt gut dagegen. Wie schneidet LavaMoat also bei diesem anderen Angriff ab?

Die Antwort lautet leider, wie so oft: „Es kommt darauf an." LavaMoat ist aufgrund seiner Integration in die App-Laufzeit ein Tool für Anwendungsentwickler, nicht für Bibliotheksentwickler. Das bedeutet, dass zwar einige Web-Apps sich mit LavaMoat hätten schützen können, Anwendungen ohne LavaMoat jedoch weiterhin anfällig gewesen wären.

Darüber hinaus setzt LavaMoat nur eine vom Entwickler festgelegte Richtlinie durch. Wenn Sie eine unsichere Richtlinie festlegen, kann LavaMoat Sie nicht schützen.

Schauen wir uns an, wie eine Anwendung mit LavaMoat vor diesem Angriff hätte geschützt werden können.

LavaMoat verwendet eine Richtliniendatei, um festzulegen, welche Capabilities in Form von globalen Plattform-APIs eine Abhängigkeit erhalten soll. Um dies zu erleichtern, kann LavaMoat ein Paket analysieren und automatisch ermitteln, was ein Paket für seinen Betrieb zu benötigen scheint. Dies wird als statische Analyse bezeichnet.

Obwohl die statische Analyse eine unvollkommene Methode ist, um zu verstehen, was ein bestimmter Code zu tun versucht, verwendet LavaMoat die statische Analyse nur als Hilfsmittel, um die Erstellung einer Richtliniendatei zu erleichtern. Sie wird nicht verwendet, um Richtlinien zur Laufzeit durchzusetzen. Die generierten Richtlinien werden anschließend vom Entwickler überprüft, angepasst und genehmigt.

Zur ursprünglichen Frage lautet eine Antwort: Ja, LavaMoat kann Ihre App und Ihre Nutzer vor Supply-Chain-Angriffen schützen, indem es verhindert, dass Pakete zur Laufzeit neuen Code laden können. Es kann Sie schützen, wenn Sie es korrekt konfiguriert haben und Abhängigkeiten verwenden, die keine übermäßig weitreichenden Capabilities erfordern.

Eine weitere Antwort lautet: Nein. Wenn Sie LavaMoat so konfiguriert hätten, dass **@ledgerhq/connect-kit-loader** normal funktionieren und einen Script-Tag einschleusen darf, der beliebigen Code ausführt außerhalb der LavaMoat-Laufzeit, wäre der Angriff dennoch erfolgreich gewesen. Dies ist Teil des Kompromisses von LavaMoat zwischen Abwärtskompatibilität und einem sichereren System. LavaMoat ist sehr flexibel, um maximale Kompatibilität zu gewährleisten, sodass Sie es in Ihre App integrieren können, ohne sie von Grund auf neu zu schreiben. Die Verantwortung liegt nach wie vor beim App-Entwickler, sinnvolle Richtlinien festzulegen und sinnvolle Abhängigkeiten zu wählen. LavaMoat ermöglicht es, globale Browser-APIs selektiv bereitzustellen, aber einige globale APIs enthalten schlicht zu viel Macht, um sie sicher an ein Drittanbieter-Paket weiterzugeben. Wir erforschen verschiedene Möglichkeiten, diese Befugnisse weiter einzuschränken, aber es ist eine Herausforderung, etwas zu entwickeln, das einfach funktioniert für Pakete, die selbst keine Anstrengungen unternehmen, ihre Kontrolle zu begrenzen.

Eines der Features von LavaMoat, genannt Scuttling, würde sowohl das bösartige als auch das originale Paket, das vom @ledgerhq/connect-kit-loader geladen wird, beeinträchtigen. Scuttling entzieht Code, der außerhalb der LavaMoat-Sandbox ausgeführt wird, den Zugriff auf Capabilities. Dies würde Sie von vornherein daran hindern, den unsicheren @ledgerhq/connect-kit-loader zu verwenden, und Sie dazu bewegen, @ledgerhq/connect-kit direkt zu verwenden und damit den Aktualisierungsprozess selbst zu kontrollieren, sodass Sie die volle Kontrolle über den in Ihrer App ausgeführten Code behalten.

LavaMoat ist zwar kein Allheilmittel, gibt Ihnen aber Kontrolle und Transparenz dort, wo Sie sonst keine hätten. LavaMoat sollte nur eines von mehreren Tools in Ihrer Sicherheitsstrategie sein.

Folgendes können Sie jetzt sofort tun, um sich gegen einen Angriff von morgen zu wappnen:

• Fügen Sie den kostenlosen Socket.dev-Abhängigkeitsmonitor hinzu (2 Min.).

• Fügen Sie eine CSP mit strikter Ressourcenkontrolle hinzu (30 Min.).

• Fügen Sie LavaMoat zu Ihrem Build-System und zu Ihrem App-Bundle hinzu (1 Std.).