Wie man 1,3 TB Geheimnisse verliert – die Novo-Nordisk-Methode.

In diesem Monat hat Novo Nordisk – der dänische Pharmakonzern hinter Ozempic und Wegovy – bestätigt, dass Angreifer in seine Systeme gelangt sind [1]. Der Weg hinein, so Forscher, führte über ein hochprivilegiertes Zugriffstoken, das im JavaScript einer vergessenen, öffentlich erreichbaren Subdomain lag: ein Geheimnis, das an den Browser ausgeliefert wurde und für jeden lesbar war, der „Quelltext anzeigen“ öffnete [2]. Nachlässig, ja. Aber ein Unternehmen dieser Größe ist bei Zugangsdaten im Allgemeinen nicht nachlässig – es betreibt mit Sicherheit ernstzunehmende Zugangsdatenverwaltung, die Privileged-Access-Mechanik, die regelt, wer sich wo anmelden darf. Nichts davon hat etwas gebracht, weil all das die falsche Seite des Hauses bewacht.

Was tatsächlich passiert ist

Dieses erste Token war privilegiert genug, um Novo Nordisks private Repositories zu klonen. Und die Repositories waren voller weiterer Zugangsdaten – denn dort leben Maschinenzugangsdaten, in praktisch jedem Unternehmen der Welt: fest im Quelltext hinterlegt, in Configs abgelegt, in CI-Pipelines eingebaut, einmal committet und dann vergessen. Das Klonen der Repositories übergab den Angreifern nicht nur Quelltext. Es übergab ihnen den nächsten Schlüsselsatz, und danach den übernächsten.

So wird aus einem nachlässigen Token eine vollständige Kompromittierung. Eine Gruppe, die sich FulcrumSec nennt, sagt, sie habe auf diesem Weg zweieinhalb Monate lang pivotiert und mehr als 700.000 Dateien mitgenommen – rund 1,3 Terabyte – darunter Quelltext, vermarktete und unveröffentlichte Wirkstoffdaten, klinische Studienunterlagen, Fertigungstechnologie und die internen KI-Modelle des Unternehmens [3]. Nachdem ein gefordertes Lösegeld von angeblich 25 Millionen US-Dollar abgelehnt wurde, begann sie, die Beute zu veröffentlichen. (Novo Nordisk hat unbefugten Zugriff auf eine begrenzte Zahl von Systemen bestätigt; der volle Umfang ist die Behauptung der Angreifer, bislang nicht unabhängig verifiziert [1][3].)

Ein ausgelaufenes Token war der Türknauf. Die Repositories voller dauerhaft gültiger Zugangsdaten waren das unverschlossene Gebäude dahinter.

Das ist keine Nachlässigkeit. Es ist eine Kategorielücke.

Enterprise-Zugangsdatenverwaltung – die Tresore im CyberArk-Format, das Privileged-Access-Tooling, das jedes große Unternehmen betreibt – wurde für Menschen gebaut: menschliche Konten, Anmeldesessions, wer-was-erreichen-darf. Dafür funktioniert sie. Die Zugangsdaten, die sich durch diesen Vorfall durchgezogen haben, lagen auf der völlig anderen Seite. Das Token im JavaScript, die Geheimnisse in den Repos, die Schlüssel in der CI-Pipeline sind Maschinenzugangsdaten – diejenigen, mit denen Apps, Dienste und inzwischen Agenten sich gegenseitig authentifizieren, ohne einen Menschen in der Schleife. Für diese Seite hat es nie einen Tresor gegeben.

Und es ist die Seite, die explodiert. Jede neue Integration, jeder Mikroservice, jeder KI-Agent, den Sie ausrollen, vervielfacht die dauerhaft gültigen Maschinenzugangsdaten, die niemand verwaltet. Die Gefahr ist auf die App- und Agenten-Seite gewandert, das Tooling ist nicht mitgegangen. Die Post-Mortems werden also bei „keine Tokens ins JavaScript“ landen, und das bekämpft den falschen Feind. Tokens werden immer leakieren – in ein Log, in einen Screenshot, in ein vergessenes Bundle. Dass die erste Zugangsdaten nie auftaucht, lässt sich nicht gewinnen. Was aus einem Leak 1,3 Terabyte gemacht hat, war das Gebäude aus dauerhaft gültigen Maschinenzugangsdaten dahinter, im Code, wartend darauf geklont zu werden. Wer einen ergattert, bekommt die Karte zu allen übrigen.

Dafür gebaut, absichtlich

Diese Lücke ist der ganze Grund, warum es Clavitor gibt: ein Tresor für die Seite, für die CyberArk nie gebaut wurde – die Zugangsdaten, die Apps und Agenten verwenden. Bei Clavitor liegen keine Zugangsdaten in den Repositories, die man ernten könnte. Der Code enthält nie ein Geheimnis, das er committen könnte; er fragt den Tresor nach der Nutzung einer Zugangsdaten in dem Moment, in dem er eine braucht, und der Wert landet nie im Quelltext, in der Config oder im Build. Ein Angreifer, der das erste Token stiehlt und jedes Repository klont, das Sie besitzen, findet genau das, was dort sein sollte: Code, und keine Schlüssel. Die Kette, die aus einem Leak alles macht, reißt am ersten Glied.

Der Einstiegstoken wird auf dieselbe Weise entschärft. Eine Clavitor-Zugangsdaten ist auf eine Aktion begrenzt und läuft ab – ein Token, das in einem herumliegenden Bundle gefunden wird, ist also kein Generalschlüssel: Es kann die Organisation nicht klonen und nicht zur nächsten Zugangsdaten gelangen, weil es nur für die eine Aktion gültig war, nach der es benannt ist. Es ist an die Maschine gebunden, für die es ausgestellt wurde; eine Kopie, die woanders benutzt wird, ist tot. Auch wird aus keiner einzelnen Zugangsdaten eine stille Exfiltrationsleitung: jede Freigabe ist ratenbegrenzt und löst bei einer auffälligen Sperre aus, damit nicht 700.000 Dateien über zehn Wochen à eine sinnvoll aussehende Anfrage hinausrutschen. Und jede Nutzung wird außerhalb der Maschine protokolliert und hash-verkettet – das macht einen stillen Aufenthalt deutlich schwerer, wenn die Aufzeichnung nicht auf einem Rechner liegt, den der Eindringling besitzt.

All das macht Sie nicht unangreifbar, und wer das verspricht, verkauft etwas. Hinterlegen Sie einen langlebigen Masterschlüssel fest im Code, und wer ihn findet, kann ihn benutzen – einmal, für das, was er erlaubt. Was sich ändert: Das Finden einer Zugangsdaten liefert nicht mehr die übrigen mit – kein Repository voller dauerhafter Geheimnisse dahinter, keine Kette vom Leak zu den 1,3 Terabyte. Der Schadensradius eines ausgelaufenen Tokens schrumpft zurück auf das Token.

Der Teil, der bleibt

Die Schlagzeile werden die Wirkstoffformeln und die Darknet-Auktion sein, und das ist der Teil, der wehtut. Die Lehre ist leiser: Ein anspruchsvolles Unternehmen mit echter Zugangsdatenverwaltung ist trotzdem 1,3 Terabyte tief gegangen – weil sein Tresor die Menschen überwachte, während der Einbruch über die Apps hereinkam. Maschinenzugangsdaten sind dort, wo heute die Gefahr liegt, und sie sind die eine Seite, die noch immer offen daliegt. Die Antwort ist nicht, Ihre Repositories sauberzukratzen – es ist eine Zugangsdaten, die dort nie dauerhaft lag, um sie zu entfernen; eine, die selbst gestohlen nur für eine einzige begrenzte Aktion taugt, ohne Schlüsselschrank dahinter. Der Leak bleibt ein Leak. Er hört nur auf, der Schlüssel für alles zu sein.

Wir haben die Regeln aufgeschrieben, die ein Zugangsdaten-Werkzeug für die App- und Agenten-Seite einhalten sollte – die vollständigen zehn stehen hier.

Clavitor (@clavitorai) ist der Zugangsdaten-Tresor, gebaut für KI-Agenten – und gegen sie. clavitor.ai

Quellen

[1] Novo Nordisk (@novonordisk) — Incident update. Bestätigt unbefugten Zugriff auf eine begrenzte Zahl interner IT-Systeme.

[2] CybelAngel (@CybelAngel) — Novo Nordisk Was Breached Through JavaScript: what the coverage got wrong. Verfolgt den Erstzugriff auf ein hochprivilegiertes Zugriffstoken zurück, das in minimiertem clientseitigem JavaScript auf einer vergessenen, öffentlich erreichbaren Subdomain hinterlassen wurde.

[3] TechRepublic (@TechRepublic) — Ozempic Maker Novo Nordisk Confirms Security Incident After $25M Hacker Demand. Die Gruppe FulcrumSec beansprucht eine Aufenthaltsdauer von rund 2,5 Monaten und rund 700.000 Dateien / 1,3 TB – Quelltext, vermarktete und unveröffentlichte Wirkstoffdaten, klinische Studienunterlagen sowie interne KI-Modelle – nach dem Klonen von Repositories und dem Ernten weiterer Zugangsdaten; Datenleck nach Ablehnung der Lösegeldforderung.