Wie ein einzelnes GitHub-Token die Perimeter-Abwehr eines globalen Pharmariesen umging

Novo Nordisk unterhält eine mehrschichtige Sicherheitsinfrastruktur. Das Unternehmen setzt fortschrittliche Endpunkterkennung, Netzwerksegmentierung und ein dediziertes Security Operations Center ein. Diese Verteidigungsmaßnahmen kosten jährlich Millionen von Dollar. Dennoch brach die gesamte Architektur aufgrund einer einzigen Zeichenfolge auf einer öffentlich zugänglichen Website zusammen. Die Sicherheitsverletzung beim dänischen Pharmariesen ist eine Fallstudie über das architektonische Paradoxon der modernen Softwareentwicklung. Eine massive Investition in die Perimeter-Abwehr scheiterte, weil ein einzelnes Authentifizierungs-Token am falschen Ort existierte.

Ich habe Jahre damit verbracht, mit Sicherheitsforschern über Signal und PGP-verschlüsselte Kanäle zu kommunizieren. Die meisten von ihnen suchen nicht nach komplexen Zero-Day-Schwachstellen in gehärteten Firewalls. Sie suchen nach dem Weg des geringsten Widerstands. Im Fall von Novo Nordisk war dieser Weg ein hochprivilegiertes persönliches GitHub-Zugriffstoken (PAT), das in clientseitigem JavaScript auf einer obskuren Subdomain hinterlassen wurde. Dies war kein anspruchsvoller Hack. Es war eine Übung in der Entdeckung. Sobald die als FulcrumSec bekannte Bedrohungsgruppe das Token im März fand, wurde der formale Sicherheitsperimeter irrelevant. Das Token ermöglichte authentifizierten Zugriff. Für die internen Systeme waren die Angreifer legitime Entwickler.

Die Anatomie einer stillen Intrusion

FulcrumSec agierte mehr als zwei Monate lang innerhalb des Netzwerks von Novo Nordisk, bevor sie entdeckt wurden. Während dieses Zeitraums nutzte die Gruppe das ursprüngliche GitHub-Token, um private Repositories zu klonen. Diese Repositories enthielten mehr als nur Code. Sie enthielten sekundäre Anmeldedaten, Infrastrukturdefinitionen und interne Dokumentationen. Dies ist ein gängiges Muster bei modernen Intrusionen. Ein Angreifer nutzt einen kleinen Brückenkopf, um mächtigere Geheimnisse zu erbeuten. Sie müssen keinen Softwarefehler ausnutzen, wenn sie die Schlüssel zur Vordertür besitzen.

Bis Novo Nordisk den Vorfall am 11. Juni offenlegte, hatten die Angreifer 1,3 TB an Daten exfiltriert. Dieser Cache umfasste 700.000 Dateien. Während das Unternehmen die Auswirkungen zunächst als auf pseudonymisierte Patientendaten und Unterlagen von medizinischem Fachpersonal begrenzt beschrieb, erscheint die Realität schwerwiegender. Die gestohlenen Daten enthalten geschützte Informationen über vermarktete und unveröffentlichte Medikamente, klinische Studienforschung und interne KI-Modelle. FulcrumSec behauptet, dass die Informationen Wettbewerbern drei bis fünf Jahre Entwicklungszeit ersparen könnten. Dies ist die Definition eines systemischen Versagens. Die Sicherheitsverletzung entwickelte sich von einem einfachen geleakten Token zum Verlust von zentralem geistigem Eigentum.

Warum Entwicklungspipelines Produktionssysteme sind

Entwicklungsplattformen sind die wertvollsten Systeme im modernen Unternehmen. Die meisten Sicherheitsprogramme erkennen diese Realität nicht an. Ein Code-Repository ist nicht mehr nur ein einfacher Speicherort für Textdateien. Es ist der Bauplan für die gesamte digitale Umgebung. Es enthält die Konfigurationen für Cloud-Umgebungen und die Deployment-Pipelines, die Code an Kunden ausliefern. Wenn ein Angreifer Zugriff auf ein Repository erhält, sieht er die gesamte Verkabelung der Organisation.

Matt Kimpel, Chief Information Security Officer bei Magna5, stellt fest, dass Entwickler ständigen Zugriff auf die Systeme haben, auf die es am meisten ankommt. Sie besitzen Anmeldedaten für Build-Pipelines und Cloud-Umgebungen. Diese Systeme liegen der Produktionsumgebung vorgelagert. Wenn ein Angreifer den Code kompromittiert, bevor er kompiliert wird, kontrolliert er das Endprodukt. Dies macht die Workstation des Entwicklers und das Repository kritischer als den Produktionsserver selbst. Traditionelle Schutzmaßnahmen wie Branch-Approvals und Code-Reviews setzen voraus, dass die Person, die die Aktion ausführt, ein vertrauenswürdiger Mitarbeiter ist. Wenn die Identität kompromittiert ist, erleichtern dieselben Kontrollen den Angriff.

Das unsichtbare Risiko von Maschinenidentitäten

Organisationen behandeln die Verwaltung von Geheimnissen (Secrets Management) als ein Tooling-Problem. Sie kaufen einen Tresor (Vault) und nehmen an, das Problem sei gelöst. Der Vorfall bei Novo Nordisk beweist, dass Secrets Management ein Identitätsproblem ist. Das geleakte GitHub-Token ist eine Maschinenidentität. Im Gegensatz zu menschlichen Konten fehlen Maschinen-Anmeldedaten oft klare Eigentümer. Sie haben keine konsistenten Rotationspläne. Häufig mangelt es ihnen an aussagekräftiger Überwachung. Diese Token bleiben über Monate oder Jahre ohne Änderung bestehen.

Shane Barney, CISO bei Keeper Security, weist darauf hin, dass diese Unsichtbarkeit ein einzelnes Token in eine langfristige Intrusion verwandelt. Wenn ein Maschinen-Credential weitreichende Berechtigungen besitzt und niemand seine Nutzung überwacht, muss ein Angreifer seine Privilegien nicht erweitern. Der Zugriff ist bereits vorhanden. Der Explosionsradius umfasst die gesamte Umgebung. Dies ist der Grund, warum die Angreifer 60 Tage lang unentdeckt blieben. Sie brachen nicht in das System ein. Sie nutzten das System so, wie es für die Nutzung konzipiert war.

Das Auftauchen sekundärer Bedrohungsakteure

Eine zweite Bedrohungsgruppe, die sich TheUSERS007 nennt, behauptete ebenfalls, zwischen dem 5. und 7. Juni Zugriff auf die Systeme von Novo Nordisk gehabt zu haben. Diese Gruppe zielte auf Daten im Zusammenhang mit KI-Forschung ab. Dies deutet darauf hin, dass, sobald ein größeres Datenleck auftritt, andere Akteure beginnen, dieselbe Infrastruktur zu sondieren. Eine einzelne Schwachstelle in einer Entwicklungspipeline deutet oft auf breitere systemische Schwächen hin. Wenn ein Entwickler ein Token in einem öffentlichen Skript hinterlässt, folgen andere Entwickler wahrscheinlich ähnlichen unsicheren Mustern. Die Angriffsfläche ist keine statische Karte. Es ist eine dynamische Umgebung, in der ein Fehler weitere Untersuchungen durch mehrere Widersacher einlädt.

Diese sekundäre Intrusion unterstreicht das Risiko für interne KI-Modelle. Diese Modelle repräsentieren die Zukunft der pharmazeutischen Forschung. Sie basieren auf jahrelangen proprietären Daten und massiven Recheninvestitionen. Der Verlust dieser Modelle ist nicht nur eine Datenpanne. Es ist ein Verlust des Wettbewerbsvorteils. Die digitale Umgebung hat keine physischen Mauern. Sobald die Logik des Systems durch Quellcode und Modellgewichte offengelegt ist, ist der Schaden dauerhaft.

Von reaktiven Tools zur proaktiven Identitätskontrolle

Um diese Risiken zu mindern, müssen Organisationen ihre Sichtweise auf den Entwicklerzugriff ändern. Ein Vault ist eine Box für Geheimnisse. Identitätsmanagement ist die Kontrolle darüber, wer die Box öffnen darf und für wie lange. Das Ziel ist es, die Haltbarkeit jedes Geheimnisses zu verkürzen. Wenn ein Token in vier Stunden abläuft, ist ein Leak in einer JavaScript-Datei ein vorübergehendes Ärgernis. Wenn ein Token ein Jahr lang gültig ist, ist ein Leak eine Katastrophe.

Die Zentralisierung des Secrets Managements ist ein notwendiger Schritt. Jede Identität in der Umgebung sollte dem Prinzip der geringsten Privilegien (Least Privilege) folgen. Das bedeutet, dass ein GitHub-Token nur Zugriff auf die spezifischen Repositories haben sollte, die für eine Aufgabe erforderlich sind. Es sollte keine weitreichenden administrativen Berechtigungen über die gesamte Organisation haben. Eine automatisierte Rotation stellt sicher, dass Anmeldedaten ihren Zweck nicht überdauern. Diese Disziplin hindert einen Angreifer nicht daran, ein Token zu finden, aber sie schränkt ein, was er damit tun kann.

Praktische Schritte für die Pipeline-Sicherheit

Organisationen sollten mit einer Bestandsaufnahme nicht-menschlicher Identitäten beginnen. Die meisten Unternehmen wissen nicht, wie viele API-Schlüssel oder Service-Konten in ihrer Umgebung existieren. Man kann nicht schützen, was man nicht sieht. Diese Bestandsaufnahme sollte den Umfang jedes Schlüssels und sein letztes Nutzungsdatum enthalten. Viele Organisationen stellen fest, dass ein großer Prozentsatz ihrer aktiven Token nicht mehr notwendig ist. Diese verwaisten Geheimnisse sind hochwertige Ziele für Angreifer.

Die Überwachung von Maschinenidentitäten ist ebenso wichtig wie die Überwachung menschlicher Logins. Sicherheitsteams müssen ein Basisverhalten für Service-Konten festlegen. Wenn ein GitHub-Token normalerweise von einer bekannten IP-Adresse auf drei Repositories zugreift und plötzlich beginnt, 500 Repositories aus einer anderen Region zu klonen, sollte das System einen Alarm auslösen. Die Erkennung muss auf der Identitätsebene erfolgen. Das Patchen von Software ist wichtig, aber in einer Ära, in der Identitäten das primäre Ziel sind, ist die Sichtbarkeit der Credential-Nutzung der einzige Weg, einen stillen Eindringling zu fassen.

Schritte zur sofortigen Risikominderung

1. Scannen Sie alle öffentlich zugänglichen Assets nach exponierten Geheimnissen. Verwenden Sie automatisierte Tools, um Token, API-Schlüssel und Datenbank-Anmeldedaten in clientseitigem Code zu finden.
2. Implementieren Sie kurzlebige Token. Ersetzen Sie langlebige persönliche Zugriffstoken durch feingranulare, zeitlich begrenzte Anmeldedaten, wann immer die Plattform dies unterstützt.
3. Auditieren Sie Repository-Berechtigungen. Entfernen Sie administrativen Zugriff von Entwickler-Token. Stellen Sie sicher, dass kein einzelnes Token die Macht hat, die gesamte Codebasis zu klonen.
4. Aktivieren Sie das Scannen nach Geheimnissen (Secret Scanning) in der CI/CD-Pipeline. Blockieren Sie jeden Commit, der ein Klartext-Geheimnis enthält, bevor er das Repository erreicht.
5. Überwachen Sie auf anomale Repository-Aktivitäten. Richten Sie Alarme für Massen-Klonvorgänge oder Zugriffe von ungewöhnlichen Standorten ein.

Dieser Vorfall ist eine Erinnerung daran, dass sich der Perimeter verschoben hat. Er befindet sich nicht mehr am Rand des Netzwerks. Er existiert auf der Ebene des einzelnen Tokens und der spezifischen Identität. Wenn Sie diese Identitäten nicht mit der gleichen Strenge verwalten wie Ihre Produktionsserver, ist Ihre Verteidigung eine Illusion.

Quellen: NIST Cybersecurity Framework, MITRE ATT&CK Framework (Technique T1528: Steal Application Access Token), Berichterstattung von DataBreaches.net.

Haftungsausschluss: Dieser Artikel dient nur zu Informations- und Bildungszwecken. Er ersetzt kein professionelles Cybersicherheits-Audit oder einen Incident-Response-Service.