#14 Der Trivy-Supply-Chain-Angriff

00:00:00: Dieser Podcast wurde inhaltlich von Nikolaus Stapels zusammengestellt.

00:00:04: In dieser Reihe erzählen wir wahre Geschichten aus der Welt der Cyberkriminalität, der IT-Sicherheit und digitaler Risiken.

00:00:13: Es sind Geschichten die zeigen wie schnell Unternehmen verwundbar werden können und wie wichtig es ist aus den Fehlern anderer zu lernen bevor man selbst betroffen ist.

00:00:23: Hallo und willkommen zu unserer heutigen Analyse!

00:00:26: Ich bin deine Gastgeberin und ich werde uns heute durch die erzählerische Seite dieses wirklich unfassbaren Vorfalls leiten.

00:00:34: Und ich bin auch wieder dabei, ich kümmere mich wie immer um die technischen Hintergründe und die Forensik.

00:00:41: Freut mich dass du zuhörst!

00:00:42: Also lass uns direkt reingehen.

00:00:45: Stell dir mal vor Du baust ein Hochsicherheitsgebäude Ja, du ziehst dicke Mauern hoch, installierst Kameras an wirklich jedem Winkel und vertraust dem Sicherheitsdienst am Eingang völlig blind.

00:00:58: Absolut logisch ja!

00:01:00: Was aber wenn der Metalldetektor durch den jeder Mitarbeiter morgens gehen muss?

00:01:05: Genau das Gerät ist – dass heimlich die Zugangskarten aller Angestellten kopiert.

00:01:11: Wahnsinniges Szenario!

00:01:14: Und genau das hat sich im März, zwanzig sechsundzwanzig in der digitalen Welt abgespielt.

00:01:20: Das Ziel war einer der weltweit am häufigsten genutzten Open Source-Schwachstellenscanner und zwar Trivy von Aqua Security – ein Tool, das eigentlich dafür gebaut wurde um Schwachstellen zu finden, wurde zur ultimativen Waffe gegen seine eigene Nutzer.

00:01:37: Um

00:01:38: die Tragweite dieses Vorfalls überhaupt greifen zu können, müssen wir uns mal ansehen welche Macht solche Sicherheitstools in modernen Entwicklungsabteilungen eigentlich haben.

00:01:47: Wir sprechen hier von sogenannten CI-CD Pipelines.

00:01:50: Also quasi dem Fließband der Softwareentwicklung?

00:01:52: Exakt ja!

00:01:54: Das sind die vollautomatisierten Fließbänder.

00:01:56: ein Entwickler schreibt Code und ab da übernimmt die Pipeline Sie baut die Software testet sie und bringt sie auf die Server Und ein Scanner wie Trivi sitzt da wie ein Qualitätskontrolleur direkt an diesem Fließband.

00:02:09: Das heißt, der Scanner muss ja alles sehen können oder?

00:02:11: Richtig!

00:02:13: Er benötigt extrem weitreichende Privilegien – er muss den Quail-Code lesen, Containerimages entpacken und Konfiguration tiefgreifen prüfen.

00:02:22: Um diese Arbeit machen zu können läuft das Tool in einer Umgebung die direkten Zugriff auf die intimsten Geheimnisse eines Unternehmens hat.

00:02:29: Also sowas wie Cloudkeys oder API Tokens?

00:02:33: Genau.

00:02:33: Datenbankpasswörter, Tokens, Alles.

00:02:36: Wer also die Kontrolle über diesen Scanner übernimmt, der muss sich gar nicht mehr mühsam von außen durch Firewalls hacken.

00:02:42: Er sitzt bereits direkt im Herzen der Infrastruktur.

00:02:45: Das ist wirklich erschreckend!

00:02:47: Aber der Weg dorthin begann allerdings nicht mit einem spektakulären Hackerkommando in schwarzen kaputzen Polis wie man sich das oft vorstellt.

00:02:55: Der erste Domino Stein fiel Ende Februar zwetausendsechsundzwanzig durch einen völlig automatisierten Vorgang.

00:03:03: Ein Bord...

00:03:04: Genau, ein KI-gesteuerter BOT namens HackerBotClaw.

00:03:08: Der scente systematisch das Internet ab – solche Bots rütteln ja quasi rund um die Uhr an digitalen Türgriffen immer auf der Suche nach Fehlkonfiguration und beim offiziellen Tree wie Repository wurde dieser BOT dann fündig.

00:03:21: Ja, der BOT entdeckte ein strukturelles Problem in der Konfiguration der GitHub Actions also dem Automatisierungssystem von GitHub.

00:03:29: Spezifisch ging es da um einen sogenannten Workflow Trigger namens Pull Request Target.

00:03:34: Okay, warte das musst du für uns ein bisschen einordnen!

00:03:37: Klar

00:03:37: also wenn ein fremder Entwickler eine Code Änderung einen Pull Request vorschlägt sollte dieser Code normalerweise in einer isolierten stark rechte Beschränken Umgebung testet werden.

00:03:48: man vertraut fremdem Code ja nicht sofort

00:03:51: macht Sinn.

00:03:52: Dieser spezielle Trigger dreht die Logik jedoch um.

00:03:55: Er erlaubt es, dass der vorgeschlagene Code mit den vollen Rechten des Zielrepositories ausgeführt wird und der Angräfer Bot hat das gnadenlos ausgenutzt.

00:04:04: Er reichte einen simplen Einzeiler ein.

00:04:07: Nur einen Einzeilen?

00:04:08: Ja dieser Code lud ein winziges Skript nach welches sich direkt in den Arbeitssprecher des Systems einklinkte und sensible Zugangsdaten auslas.

00:04:17: Die primäre Beute war ein hochprivilegierter Zugangstoken, Ein Personal Access Token des Service Accounts Aquabot.

00:04:24: An diesem Punkt fragt man sich unweigerlich also Aquasecurity ist ja ein renommiertes IT-Sicherheitsunternehmen.

00:04:32: Wenn ein Bot dort Alarm auslöst und Token stiehlt dann fällt das doch auf oder?

00:04:38: Definitiv Ja!

00:04:39: Die haben diesen KI-Angriff hier auch bemerkt Das Repository bereinigt Und die gestohlenen Zugangsdaten ausgetauscht.

00:04:47: Warum stehen wir dann heute vor einem der größten Supply Chain Angriffe der Geschichte?

00:04:53: Hier berühren wir den wahrscheinlich schmerzhaftesten Punkt dieser gesamten Recherche.

00:04:57: Es ist eine harte Lektion für die gesamte IT-Branche, die zeigt wie fragil Incident Response unter extremem Zeitdruck eigentlich ist.

00:05:06: Weil Sie einen Fehler gemacht haben...

00:05:07: Ja, aber wir machen hier keine Schuldzuweisungen.

00:05:11: Der Fehler lag nicht darin dass sie reagiert haben sondern wie sie die kompromittierten Zugangsdaten rotierten.

00:05:18: Aquasecurity generierte neue AP Schlüssel und Tokens und löchte die Alten Aber – und das ist der Knackpunkt!

00:05:26: Dieser Austausch passierte nicht atomar

00:05:29: Nicht Atoma, das heißt der Austausch fand nicht exakt im selben Bruchteil einer Sekunde statt.

00:05:35: Das ist also wie bei einem Hausbesitzer, der merkt dass sein Schlüsselbund gestohlen wurde.

00:05:40: er tauscht am Montag das Schloss an der Vordertür aus kommt aber erst am Mitwuchs dazu das Schlosse an der Hintertür zu wechseln.

00:05:46: Eine sehr treffende Analogie.

00:05:48: und genau in diesem Übergangsfenster das in der IT mehrere Tage andauerte passierte das Unvermeidliche.

00:05:56: Eine hochprofessionelle menschliche Cyberkriminellengruppe namens TeamPCP hatte den ursprünglichen KI-Angriff offenbar überwacht oder die erbeuteten Daten gekauft.

00:06:07: Die haben also gesehen, dass die Vordertür ein neues Schloss bekam?

00:06:11: Genau!

00:06:12: Also gingen sie durch die noch ungesicherte Hintertür.

00:06:15: Sie nutzten die verbleibenden noch aktiven alten Tokens.

00:06:19: Im System angekommen finken sie dann die gerade neu generierten Zugangsdaten der Vordertür ab, als diese im System verteilt

00:06:26: wurden.".

00:06:26: Wow!

00:06:26: Die KI hatte gewissermaßen nur das Schloss für einen Spaltbreit geöffnet und Team PPCP ist dann unbemerkt eingezogen und hat sich dauerhafte Nachschlüssel für alle Räume anfertigen lassen?

00:06:38: So kann man das sagen ja...

00:06:39: Und mit diesen Generalschlüsseln schlug Team PPCP dann an, März, im Herzen der CICD-Infrastruktur?

00:06:54: Ein wirklich präziser Schlag.

00:06:55: Ja, die Methodik der Angreifer war von einer beeindruckenden kriminellen Energie geprägt.

00:07:01: Sie nutzten Spoofing – also das Felschen von digitalen Identitäten um ihre Code-Änderungen als legitime Arbeit von vertrauenswürdigen Entwicklern zu tarnen.

00:07:10: In einigen Fällen nutzen sie sogar die Identität des CEOs einer bekannten Techfirma, um absolut keinen Verdacht zu erregen.

00:07:18: Das perfideste war aber die Manipulation der Versions-Tags.

00:07:23: Wir sprechen hier vom sogenannten Tech Poisoning.

00:07:26: Erklär das mal kurz.

00:07:27: Entwickler verlassen sich in ihren Pipelines darauf, dass sie eine stabile, sichere Version eines Tools laden.

00:07:33: Sie verweisen in ihrem Code auf Tags wie V-I oder Nullpunktdreifunddreißig Punkt Null.

00:07:40: Die Annahme ist wenn ich Version Eins lade bekomme ich immer exakt die gleiche überprüfte Software.

00:07:46: Aber das is ein Trugschluss

00:07:48: Ein gewaltiger Trug.

00:07:49: schluss.

00:07:50: Git-Tags sind nicht in Stein gemeißelt.

00:07:52: Man kann sie sich eher wie Post-at-Zettel vorstellen, ich kann den Zettel mit der Aufschrift Version eins jederzeit von einem sicheren Codebacquet abziehen und auf ein bösartiges Codebakket kleben.

00:08:03: Krass!

00:08:04: Und exakt das hat TeamPCP gemacht.

00:08:07: Durch einen sogenannten Force Push überschrieben Sie seventy-fünfundseptig der Sechsundsiebzig Versions Texte GitHub Action von Trivie.

00:08:14: auch alle sieben Textes des dazugehörigen Setup Tools wurden kompromittiert.

00:08:18: Das heißt, jeder Entwickler der am nächsten Morgen zur Arbeit kam und seine Pipeline startete lud im guten Glauben an das Versions-Einspost.it den Schadcode der Angreifer herunter.

00:08:28: Genauso ist es passiert.

00:08:29: Zusätzlich luden die Angreiver eine kompromittierte Trivy Binary auf alle offiziellen Verteilkanäle wie Docker Hub oder Amazon ECR hoch.

00:08:38: Hier wird es wirklich interessant!

00:08:40: Das Fatale in diesem Schad Code war ja seine Tarnung.

00:08:44: Er lief nicht an Stelle des eigentlichen Sicherheitsscanners, das wäre sofort aufgefallen wenn plötzlich die gewohnten Scanberichte fielen würden.

00:08:53: Der Schadcode lief vor dem eigentlichen Trivyscan.

00:08:56: ein genialer Schachzug aus Angreifersicht

00:08:59: Ja!

00:09:00: Das heißt der Scan lief danach ganz regulär durch.

00:09:04: Die Ampeln in der Pipeline der Entwicklersprangen auf Grün – das System meldete keine Schwachstellen gefunden.

00:09:10: Alles wirkte perfekt, aber während die Entwickler das grüne Licht sahen hatte der Datendiebstahl im Hintergrund bereits stattgefunden.

00:09:17: Hier müssen wir mal einen forensischen Blick auf die Mechanik.

00:09:21: wer GitHub Actions nutzt, erkennt dass wenn Passwörter oder Tokens versehentlich in die Log-Dateien geschrieben werden, er kennt GitHub das normalerweise und ersetzt diese sensiblen Daten durch Sternchen!

00:09:33: Wie konnten die Angreifer diese Sicherheitsfunktion denn umgehen?

00:09:36: Ja, die Maskierung durch Sternchen ist ein reiner Oberflächenschutz.

00:09:41: Also nur kosmetisch?

00:09:43: Genau!

00:09:44: Sie greift erst in dem Moment, indem das System versucht Text in eine Datei zu schreiben oder auf einem Bildschirm auszugeben.

00:09:51: Team PCP hat sich aber für diese Lockdateien überhaupt nicht interessiert.

00:09:55: Sie wussten dass ihr Schadcode auf dem ausführenden Server den sogenannten Runner weitreichende administrative Rechte besaß.

00:10:02: Also gingen sie direkt an die Quelle.

00:10:04: Richtig Sie gingen direkt an das Gehirn des Computers den Arbeitsspeicher.

00:10:08: Sie steuerten den Systemfahrt PROC PITMEM an, dass es der nackte völlig unmaskierte Arbeitsspeichertes Prozesses in dem die Pipeline läuft.

00:10:17: Bevor das System auch nur die Gelegenheit hatte ein Passwort in eine Lockdatei zu schreiben und es dabei mit Sternchen zu zensieren, lasen die Angreifer die rohen Gedanken des Computerstirekt aus.

00:10:27: Sie haben also den Arbeitsspeicher regelrecht abgepumpt.

00:10:30: Und dabei blieb es ja nicht mal, der Schadcode suchte zusätzlich in über fünfzig vordefinierten Dateipfaden nach allem was wertvoll sein könnte.

00:10:39: Das war kein gezielter Diebstahl das war ein industrieller Staubsauger

00:10:44: Definitiv.

00:10:45: Die Malwehr suchte nach AWS Credentials, nach Zugängen für die Google Cloud und Azure.

00:10:50: Sie sammelte SSH Schlüssel durch wühte kubernetes Konfigurationen- und Terraformstatusdateien Und sie machte nicht einmal vor Kryptowollezalt.

00:10:58: Der Abtransport dieser gigantischen Datenmengen also... ...die Exfiltration war wirklich meisterhaft konstruiert!

00:11:05: Die Angrafer wussten ja dass viele Unternehmen ihren ausgehenden Netzwerkverkehr überwachen.

00:11:09: Klar, wenn plötzlich Tausende Klartextpasswörter über das Netz gesendet werden, schlagen sofort Alarmsysteme an.

00:11:15: Genau!

00:11:16: Daher nutzten sie eine hybride Verschlüsselung direkt auf dem infizierten Rechner.

00:11:22: Sie packen alle gestohlenen Geheimnisse in ein Archiv und verschlüsselten dieses mit dem hochsicheren AES-Zweihundertsechsundfünfzig Standard.

00:11:30: Und das reicht dann schon?

00:11:31: Noch nicht ganz.

00:11:32: Den Schlüssel für dieses Archiv sicherten sie dann noch einmal.

00:11:41: Das bedeutet, selbst wenn das IT-Sicherheitsteam des betroffenen Unternehmens den Netzwerkverkehr aufgezeichnet hätte, hätten sie nur einen wertlosen Datenklumpen gesehen.

00:11:53: Exakt!

00:11:54: Ohne den privaten Schlüssel der ausschließlich auf den Servern der Angreifer lag waren die gestohlenen Daten für Verteidiger absolut unlesbar.

00:12:03: Verschickt wurden diese verschlüsselten Pakete dann an eine getarnte Domain.

00:12:07: Sie nannten sie scan.aquasecurity.org.

00:12:12: Auf den ersten Blick eine völlig legitime Adresse des Herstellers, aber bei genauem Hinsehen fällt der Buchstabendreher am Ende auf.

00:12:19: Taupo Squatting in Reihenform.

00:12:22: Im Rauschen von tausenden Lockeinträgen pro Minute übersieht man so einen verdrehten Buchstaben total leicht.

00:12:29: Aber am erschreckendsten fand ich eigentlich den Plan B der Angreifer.

00:12:33: Wenn eine Firewall diese gefälschte Domain blockierte, war der Diebstahl ja nicht gestoppt.

00:12:37: Nein und das ist der Moment in dem die Infrastruktur des Opfers zur Waffe gegen sich selbst wird!

00:12:43: Wenn die primäre Domänen nicht erreichbar waren, nutzte die Mairware einfach das legitime Githubtoken des Opffers, dass ohnehin in der Pipeline vorhanden war.

00:12:51: Also die eigenen Werkzeuge des Opfs?

00:12:54: Richtig Sie wies GitHub über die offizielle AP an, ein neues öffentliches Repositori namens TPTPCP-Docs im eigenen Account des Opfers zu erstellen.

00:13:06: Dort lud sie die verschlüsselten Geheimnisse als scheinbar harmlose Dateihoch.

00:13:10: Das Opfer stellte den Angreifern also unwissentlich den Fluchtwagen zur Verfügung?

00:13:14: Ganz genau!

00:13:16: Für jede klassische Firewall sah dieser Vorgang wie völlig legitimer Datenverkehr eines Entwicklers zu Github aus.

00:13:22: Ein Alarm wird hier einfach nicht ausgelöst

00:13:24: Wahnsinn.

00:13:24: Sie hatten nun also zehntausende Zugangsdaten aus den verschiedensten Unternehmen erbeutet.

00:13:30: Ein menschliches Team kann diese Berge an Daten gar nicht mehr händisch verarbeiten!

00:13:35: Die logische Konsequenz für die Angreifer war Automatisierung.

00:13:38: Keine vierundzwanzig Stunden später mutierte der Angriff Ja,

00:13:42: die Täter werteten die Beute blitzschnell aus.

00:13:45: Unter den gestohlenen Tokens befanden sich auch gültige Zugangs-Daten für NPM.

00:13:49: Erklär mal kurz für alle, die nicht täglich programmieren was das ist...

00:13:53: NPM ist der zentrale Paketmanager für die Programmiersprache JavaScript.

00:13:57: Entwickler laden darüber vorgefertigte Codebausteine herunter, um das Rad nicht bei jedem Projekt neu erfinden zu müssen.

00:14:04: Wer gültige NPM-Tokens besitzt kann im Namen von vertrauenswürdigen etablierten Entwicklern neuen Code veröffentlichen.

00:14:10: Und Team PCP fackelte da nicht lange?

00:14:12: Überhaupt nicht!

00:14:13: Sie infizierten über siebenundvierzig völlig legitime Softwarepakete in Namensräumen wie addemilgroup oder attele.io.

00:14:22: Das war ja die Gewürzstunde einer digitalen Pandemie, der sogenannte Canister Warm.

00:14:28: Wenn ich mir das mal aus der Perspektive eines normalen Entwicklers vorstelle... Ich sitze morgens mit meinem Café am Schreibtisch, tippe den Befehl ein um ein völlig etabliertes Paket für meine neue Website zu laden und ohne dass sich ein Passwort eingebe oder auf eine Fishing Mail klicke bin ich schon infiziert!

00:14:46: So

00:14:46: furchteinflößend es klingt?

00:14:48: Ja genauso ist es.

00:14:50: Der Wurm nutzte einen legitimen Mechanismus in NPM, das sogenannte Post-Install-Skript.

00:14:58: Dieses Skript ist eigentlich dafür gedacht nach dem Download eines Pakets noch ein paar Aufräumarbeiten auf dem Rechner durchzuführen.

00:15:05: Aber hier hat es was anderes gemacht?

00:15:07: Genau!

00:15:09: Sobald das Paket installiert war führte es sofort Schadcode aus.

00:15:14: Der Canister Warm durchsuchte rasend schnell den lokalen Rechners des Entwicklers nach weiteren NPM Tokens

00:15:21: Und wenn er was gefunden hat?

00:15:22: Dann passierte folgendes im Hintergrund, die Malwehr lud den sauberen Quellcode aller Pakete herunter für die dieser Entwicklerschreibrechte hatte.

00:15:31: Sie indizierte sich selbst in diesen saubern Code.

00:15:34: dann veränderte sie die Versionsnummer künstlich.

00:15:37: also aus einer harmlosen Version eins Punkt fünfzig Punkt null wurde ein vermeintliches Patch Update Eins Fünfundfünfzig Punkt Eins

00:15:44: und das hat sich dann wieder hochgeladen.

00:15:46: Ja

00:15:47: Die malware veröffentlichte dieses frisch infizierte Paket automatisch wieder auf NPM.

00:15:52: Der Entwickler am Schreibtisch bemerkt davon absolut nichts, der Wurm pflanzte sich rasant fort von Entwicklerechner zu Entwicklerechner.

00:16:00: Um so einen Wurm am Leben zu halten und fernzusteuern brauchen die Angreifer ja eine Infrastruktur – Server, von dem der Wurmpfehle erhält eine sogenannte Command and Control-Infrastruktur kurz C-II.

00:16:14: Klassischerweise versuchen Behörden dieses Server aufzuspüren und vom Netz zu nehmen.

00:16:19: Aber TeamPCP wählte einen Weg, der solche Takedowns praktisch unmöglich macht!

00:16:24: Sie setzten auf die Blockchain.

00:16:25: Das

00:16:26: war ein brillanter Schachzug.

00:16:28: Die Täter verlagerten ihr Kommandozentrum auf einem Smart Contract innerhalb der Internetcomputer-Blockchain kurz ICP.

00:16:35: Der Trick daran war... ...die dynamische Tarnung.

00:16:37: Wie hat das funktioniert?

00:16:38: Wenn Sicherheitsforscher diesen Vertrag auf der Blockchain analysierten sahen sie in seinem Ruhezustand nur einen völlig harmlosen Coach-Nipsel, der ein YouTube Link zurückgab.

00:16:49: Das Skript auf dem infizierten Entwicklerrechner fragte die Blockchain ab, sah den YouTube Link und blieb inaktiv.

00:16:58: Erst wenn die Angreifer den Smart Contract auf der Blockchain aktualisierten und eine echte bösartige Downloadadresse hinterlegten wurde die Malware scharfgestellt.

00:17:10: Unmittelbar danach änderten die Täter den Contract wieder auf das harmlose Video zurück.

00:17:14: Und warum ist es so schwer zu bekämpfen?

00:17:17: Weil es keine zentralen Server gibt.

00:17:18: Exakt!

00:17:19: Das liegt in der Natur der Blockchain.

00:17:21: Es gibt kein zentrales Rechenzentrum, bei dem die Polizei einfach den Stecker ziehen kann.

00:17:26: Die Daten liegen verteilt auf Tausenden von Knotenpunkten weltweit.

00:17:30: Eine

00:17:30: dezentrale Infrastruktur

00:17:32: Ja und die ist resilient gegen klassische Serversperrungen.

00:17:36: Man kann eine Blockchain einfach nicht vor Netz nehmen.

00:17:39: Zwar wurden die ursprünglichen Trivyschwachstellen relativ schnell gepatched und die verseuchten Version entfernt, doch der Schaden war ja angerichtet.

00:17:47: Die gestohlenen Daten, die Passwörter, die Cloud-Schlüssel blieben in den Händen der Hecker!

00:17:53: Wochenlang passierte nichts Sichtbares – bis zum Augusts.

00:17:58: Da kam der große Knall.

00:17:59: Ja am elften August tauchten die Daten plötzlich öffentlich im Netz auf Und dieses Mal nicht verschlüsselt.

00:18:06: Der Datensatz war im Klartext für jeden einsehbar

00:18:09: Und wenn wir über das Ausmaß dieses Leaks sprechen, müssen wir penibel zwischen forensisch bestätigten Fakten und den Hochrechnungen verschiedene Sicherheitsfirmen trennen.

00:18:18: Das ist wichtig.

00:18:19: Absolut!

00:18:20: Das Bild, dass sich aus dem Berichten zusammensetzt, ist jedenfalls gewaltig.

00:18:24: Die Sicherheitsfirma CloudSec hat die Struktur der gefundenen Daten hochgerechnet und schätzt, dass mehr als zweitausend fünfhundert Organisationen und über vierhundertvierunddreißigtausend CECD Pipelines potenziell betroffen sein könnten.

00:18:37: Das ist aber ein theoretisches Modell der Reichweite, oder?

00:18:41: Genau.

00:18:41: Das ist eine Hochrechnung!

00:18:42: Wir haben aber auch Firmen die nicht nur hoch rechnen sondern den konkreten öffentlich gewordenen Datensatz durchgezählt haben.

00:18:49: Step Security hat genau das getan.

00:18:51: Richtig – Die Zählung von Step Security liefert uns hier harte Zahlen.

00:18:55: Sie fanden in dem veröffentlichten Material exakt seventy-tausend dreihundertdreißig eindeutig gestohlenes Secrets, die sich zwei tausend einenhundertsechsund achtzig unterschiedlichen Organisationen zuordnen ließen.

00:19:07: Gibt es da nicht noch einen anderen Datensatz?

00:19:09: Ja, parallel dazu berichteten Medien wie Heldnet Security unter Berufung auf die Analysten von Hudson Rock von einem weiteren Archiv.

00:19:19: Diese soll hundertdreiundfünfzig Gigabyte umfassen über vierhundertdreißigtausend Dateien enthalten und aus einem Parallelen-Angriffstrang auf das KI Tool Light LLM stammen bei dem eine sehr ähnliche Methodik angewandt würde.

00:19:34: Diese Zahlen zeigen jedenfalls, dass es hier nicht nur kleine Start-ups getroffen hat die vielleicht an der Sicherheitsbahn.

00:19:41: Forensische Analysen haben belegt und das ist ein bestätigter Fakt, dass selbst Großkonzerne auf diesen Listen stehen.

00:19:48: Auch kritische Infrastruktur?

00:19:50: Ja bei der Deutschen Bahn AG sind laut den Auswertungen mindestens fünfundzwanzig geschächskritische Geheimnisse aus.

00:19:56: fünfunddreißig Pipeline Läufen direkt abgeflossen.

00:19:59: Moderne Software-Lieferketten verbinden alle Akteure.

00:20:02: Das Werkzeug, das der Hobbyentwickler nutzt ist oft exakt dasselbe auf das auch internationale Logistikkonzerne vertrauen.

00:20:09: Und genau deshalb hat das Bundesamt für Sicherheit in der Informationstechnik –das BSI- eine unmissverständliche Warnung ausgesprochen

00:20:18: Die Assume Breach

00:20:19: Bewiese Ganz genau!

00:20:21: Wer in diesem kritischen Zeitfenster im Frühjahr die kompromittierten Versionen in seiner Pipeline hatte muss zwingend davon ausgehen, dass alle in dieser Umgebung vorhandenen Geheimnisse kompromitiert sind.

00:20:32: Es darf nicht gehofft werden, dass die Angreifer ausgerechnet den eigenen API-Schlüssel übersehen haben.

00:20:38: Panik hilft hier aber auch nicht weiter!

00:20:40: Was bedeutet das alles für die Hörer und wie können Unternehmen ihre Pipelines absichern?

00:20:46: Dieser Fall erfordert von Unternehmen ein völliges Umdenken in der Verteidigungsstrategie.

00:20:51: An erster Stelle steht die konsequente atomare Rotationen von Zugangsdaten.

00:20:56: Das bedeutet, wenn auch nur der geringste Verdacht besteht das eine Pipeline kompromittiert wurde müssen ausnahmslos alle damit verbundenen Schlüssel und Tokens getauscht werden.

00:21:05: Und zwar gleichzeitig!

00:21:07: Richtig – Eine schrittweise Rotation bei der tagelang alte und neue Schlüssel parallel existieren wie wir es beim Initialen Vorfall ja gesehen haben ist nicht nun nutzlos.

00:21:19: sie vermittelt ein falsches Gefühl von Sicherheit während die Täter längst das Haus von innen übernehmen.

00:21:24: Eine weitere fundamentale Lehre betrifft das blinde Vertrauen in sogenannte Versions-Tax.

00:21:30: Wir haben ja gesehen, dass ein Version-Eins-Posterzettel auf GitHub beliebig umgeklebt werden kann!

00:21:37: Die Lösung dafür ist das Pinnenauffeste Komitschars.

00:21:41: Ein

00:21:41: Komitschar ist keine veränderliche Beschriftung sondern ein kryptografischer Fingerabdruck eines Codes.

00:21:47: Wenn ein Angreifer auch nur ein einziges Komma in diesem Code ändert, verändert sich der Fingerabdruck komplett.

00:21:54: Und die Pipeline bricht dann sofort ab

00:21:56: Genau und verweigert die Installation.

00:21:59: So nimmt man den Tätern die Möglichkeit unbemerkt Schadcode unter falscher Flagge unterzuschieben.

00:22:05: Eng damit verwandt ist die Notwendigkeit langlebige Tokens aus dem System zu verbannen.

00:22:10: Ein Schlüssel, der jahrelang gültig ist, ist ein tickendes Risiko.

00:22:15: Die Industrie muss standardmäßig auf kurzlebige Tokens umsteigen.

00:22:19: Wie macht man das am besten?

00:22:21: Idealerweise durch Protokolle wie OIDC also OpenID Connect.

00:22:26: Das Prinzip gleicht einer Schlüsselkarte im Hotel.

00:22:29: die Karte öffnet deine Zimmertür aber sie verliert am Abreisetag um Punkt elf Uhr automatisch ihre Gültigkeit.

00:22:36: Ein OIDC-Token existiert nur für die Minuten, in denen die Pipeline tatsächlich läuft.

00:22:41: Das heißt wenn ein Angreifer einen solchen Token stielt?

00:22:44: Dann hält er kurz darauf nur wertlose Datenfragmente in der Hand.

00:22:47: Die Zeitfenster für Missbrauch werden drastisch minimiert.

00:22:50: Das

00:22:50: zwingt uns am Ende zu einer grundlegenden Erkenntnis.

00:22:54: CICD Pipelines wurden lange Zeit als eine Art internes geschütztes Hilfswerkzeug für Entwickler verstanden, ein Bereich hinter den Kulissen um den sich die Sicherheitsteams weniger sorgen mussten als um die von außen erreichbaren Webserver.

00:23:08: Aber dieser Vorfall beweist das Gegenteil.

00:23:10: Die Pipeline ist die Produktion

00:23:13: Ganz genau.

00:23:13: Diese

00:23:14: Systeme müssen ab sofort genauso rigoros abgesichert isoliert und permanent überwacht werden wie die kritischsten produktiven Server.

00:23:22: Denn Angreifer haben ihre Strategie längst angepasst!

00:23:26: Sie versuchen gar nicht mehr zwingend dicke Firewalls aufzubrechen.

00:23:32: Richtig,

00:23:32: sie infizieren einfach die Werkzeuge den wir vertrauen um diese Firewall zu bauen.

00:23:37: wenn der Wächter selbst korrumpiert ist fällt jede noch so starke Mauer.

00:23:41: Und das wirft unweigerlich eine letzte Frage auf, die sich nach dieser Recherche eigentlich jedes Unternehmen stellen muss.

00:23:48: Wenn ein Angreifer heute nicht mehr versucht deine Firewalls zu durchbrechen sondern stattdessen einfach das Werkzeug manipuliert dass deine Fire Walls überprüfen soll Wie viel unhinterfragtes Vertrauen steckt eigentlich noch tief verborgen in den Open Source Bausteinen, auf denen unsere gesamte digitale Infrastruktur jeden Tag ruht.

00:24:22: Schreib uns auch gerne deine Gedanken zur Folge oder deine Ideen für eine der nächsten Episoden.

00:24:28: Bis zum nächsten Folge, bleib aufmerksam und digital sicher!