CDN-Ressourcen von Drittanbietern werden zu Front-End-Angriffen auf die Lieferkette

Vor kurzem wurde eine Sicherheitslücke in der Ledger-Frontend-Bibliothek entdeckt. Hacker haben sich Zugriff auf die Bibliothek verschafft und bösartigen Code in die ledgerhq/connect-kit-Bibliothek eingeschleust und anschließend eine neue Version veröffentlicht. Normalerweise würde dies kein unmittelbares Sicherheitsproblem verursachen, da nur diejenigen Benutzer, die die Bibliotheksversion aktualisiert und die neue Version des Codes in ihre Website integriert haben, von dem bösartigen Code betroffen wären.

Allerdings gibt es hier einen besonderen Risikopunkt. Aufgrund der Versionsaktualisierungspolitik der ledgerhq/connect-kit-Bibliotheken wird jede Website, die sich auf die ledgerhq/connect-kit-loader-Bibliotheken stützt und die loadConnectKit-Funktion verwendet, automatisch den neuesten Code abrufen, sobald eine neue Version 1.x.x erscheint. Der Grund dafür ist, dass viele Websites diese Bibliotheken über das @1-Tag in der CDN-Adresse referenzieren und diese Praxis standardmäßig den neuesten Code aus der 1.x.x-Version zieht, was eine gängige Praxis in der Versionskontrolle von Drei-Wege-CDN-Frontend-Ressourcen ist.

Hacker können diesen Mechanismus nutzen, um durch dynamisch geladenen Code gefälschte Transaktionen zu initiieren. Solche npm-Pakete, die sich auf CDN-Quellen von Drittanbietern stützen, werden zu einem neuen Angriffskanal in der Lieferkette. Noch schlimmer ist, dass Benutzer angegriffen werden können, ohne aktiv zu aktualisieren, wenn ein Angreifer eine neue Version veröffentlicht.

Im Fall von premint zum Beispiel verlassen sich viele Frontend-Websites auf externe CDNs, um Pakete auf npm zu referenzieren, wie zum Beispiel unpkg oder cdnjs. premint verlässt sich direkt auf die neueste Version, wie in der Abbildung unten gezeigt. Dies birgt das Risiko, dass ein Angreifer einfach eine neue Version veröffentlichen kann, ohne den Benutzer aufzufordern, diese zu aktualisieren, und der Benutzer könnte verwundbar sein. Daher ist es wichtig, bei der Verwendung von externen CDN-Ressourcen sehr wachsam zu sein, was Sicherheitsrisiken angeht. Dieser Ansatz könnte zu einer neuen Form des CDN-Poisoning-Angriffs werden.

Previous:

Next:

Eine Antwort hinterlassen

Bitte Login zum Kommentieren