Stell dir vor, du installierst ein offizielles, legitimes
Package und plötzlich sind deine Credentials in den Händen von
Kriminellen. Und genau das ist das Perfide an
Supply Chain angriffen. In dieser Folge sprechen wir
darüber, wie Angreifer, Maintainer, Bildprozesse oder
Paketquellen ausnutzen, welche Angriffsmuster wie zum Beispiel
Type Scorting bis hinzu kompromittierten Release
Pipelines existieren und. Und was wir als developer oder
als Unternehmen realistisch dagegen tun können und gibt es
so etwas wie die sichere Supply Chain überhaupt noch?
Hallo zusammen und ganz herzlich willkommen zu einer ganz neuen
Folge vom To do Cast, dem Developer Podcast auf Deutsch
mit Malte Lantin. Der ist Strategic Solutions
Engineer bei github. Und mit mir Robin, Manuel Thiel.
Ich bin Director für AI und Cloud beim E Commerce Software
Unternehmen Jtl. Den Podcast hier machen wir aber
privat in unserer Freizeit sprechen wir aber natürlich über
ultrarelevante Themen, die wir auch beide so ein bisschen aus
dem Berufsleben kennen und die Developer Welt bewegen und die
wir aus Kundenprojekten diskutieren und ein Thema, was
wir natürlich gerade auch hier in diesem Podcast in den letzten
News folgen und daraus resultierend auch viel mit
unseren. Kunden und Mitarbeitenden
diskutiert haben, ist das Thema Supply Chain Attacks.
Wir haben es immer wieder gesehen, wir können uns heute
fast schon nicht mehr so richtig darauf verlassen, dass das, was
wir da über npm Jahren pnpm install oder über Python oder
über New Get Pakete installieren, denn wirklich
eigentlich sicher ist und nicht nicht Schadcode ist oder
vielleicht auch mal sicher war und auf einmal zu Schadcode wird
und darüber sprechen wir diese Folge.
Tatsächlich kam der Wunsch explizit von euch, die ihr
zuhört. Also wir haben da zahlreiche E
Mails und Nachrichten bekommen, vielleicht noch mal tiefer in
das Thema einzusteigen und gerade diese Interaktion ist
super wertvoll und eine wertvolle Interaktion für uns
ist natürlich auch wenn ihr uns einen Kaffee ausgebt und da
haben wir zahlreiche von euch wieder tief in die Tasche
gegriffen und uns mit Koffein versorgt und zwar haben wir 2
Kaffee von Felix, 2 Kaffee von Nicole und einen Kaffee von
Matthias. Ganz, ganz herzlichen Dank.
Ja, steigen wir ein ins Thema und wie muss man sich das
vorstellen? Ich habe auf einmal lese ich
irgendwo hier das allerneueste axeos Paket ist kompromittiert
und das muss ich irgendwie aktiv werden, Leute sprechen darüber
unter anderem auch in Podcast, so wie diesem hier.
Das ist eigentlich so wie stell dir vor, du würdest ein
Sternerestaurant betreiben und ganz plötzlich ändert sich die
Qualität deiner Speisen, obwohl du eigentlich wie immer im
Großmarkt einkaufst. Auch beim gleichen Händler
dieselben Tomaten und der es dir vielleicht auch nicht erklären
kann und der die Tomaten vielleicht irgendwo her bezieht,
wo der sich eigentlich auch immer sicher ist und irgendwo in
dieser Kette von den Dingen, die du gar nicht kontrollieren
kannst. Hat sich irgendwas
reingeschleust, was jetzt auf einmal die Qualität einer Speise
nach unten bringt, irgendwelche faulen Tomaten oder sowas und so
ein bisschen, so muss man sich das vorstellen.
Wenn ich meine Software baue und gar nicht jede einzelne Zeile
Code die dann verwendet wird, selber geschrieben ist, sondern
mir natürlich, wie wir das alle machen Hete reingeholt habe über
Pip install, npm install und so weiter und plötzlich explodiert
oder implodiert ja eigentlich alles von innen heraus.
Der gefährlichste Angriff, den wir heute eigentlich in der
Softwareentwicklung haben, ist nicht mehr der, der unsere
Rechner von innen hackt oder unsere Firewall umgeht, sondern
den, den wir uns selber in unser System installieren.
Über die Supply Chain und was wir dagegen tun können, wie wir
uns schützen können und ob wir uns überhaupt schützen können,
ist so ein bisschen Thema der Folge, doch ich würde sagen,
bevor wir einsteigen, lass uns mal ganz kurz zusammenkratzen,
was ist denn eigentlich überhaupt die Software Supply
Chain, damit wir hier alles, damit wir alle von der gleichen
Sache reden. Ja, und ich glaube, das ist
wichtig, dass wir das alle verstehen und auch die
entsprechenden Maßnahmen kennen, weil es ist ja eigentlich
schlimmer, als du es gerade sogar beschrieben hattest.
Du hast gesagt, okay, dann wird die Qualität schlechter in
deinem Restaurant. Nein, die Qualität wird nicht
schlechter, da sterben vielleicht plötzlich Menschen,
weil dann irgendwie die Zutaten vergiftet sind und genauso kann
es natürlich bei dir sein, wenn deine Software Supply Chain
kompromittiert ist, dass irgendwie deine Software selber
irgendwie zur Malware umfunktioniert wird und das
wollen wir natürlich in. In jedem Fall verhindern und du
hattest gerade gesagt, wir schreiben seit vielen Jahren
nicht mehr jede Zeile Code in unserer Applikation selber,
sondern bauen auf einem ganz großen Eco System auf.
Und dieses gesamte Eco System ist die Software Lieferkette,
also die Software Supply Chain. Da gehört natürlich dein eigener
Quellcode dazu, also das was du geschrieben hast.
Aber all die Third Party Pakete die du Reinziehst über die von
dir gerade genannten Package Manager oder manuell.
Einlädst, vielleicht irgendwie zugekauft hast und
dementsprechend gehören dazu natürlich auch andere Menschen,
die an diesen Produkten arbeiten.
Das können Firmen sein, das Können Open Source maintainer
sein, das können diese einsamen Hero Maintainer sein, die ganz
alleine irgendwie so ein ganz wichtiges Open Source Paket
selber über viele Jahre maintainen und.
Und dann entsprechend der Community bereitstellen und
diese Bereitstellung, die läuft über Package registrys.
Wir haben in der Vergangenheit ganz oft über Supply Chain
Security gesprochen, rund um npm, was natürlich im Java
Script und Node ekosystem der Package Manager der Wahl
zumindest heute ist und über den viele Data Angriffe letzten
Endes auch verteilt wurden. Ich glaube bei diesem Verteilen,
da kann teilweise dann schon das Problem stattfinden.
Es ist heute gar nicht mehr unbedingt nur so, dass dann die
Software zur Laufzeit, wenn sie ausgeführt wird, diesen
Schadcode beinhaltet, sondern häufig ist es einfach schon,
dass wir, während wir diese Pakete runterladen, diese Pakete
dann über sogenannte Post Install Hooks noch weitere Dinge
auf unserer Maschine tun. Das ist auch eigentlich erstmal
so gewollt, es gibt bestimmte Pakete, die dann einfach Dateien
vor allem nach B kopieren oder bestimmte Dinge vorbereiten.
Und darüber kommt schon oft problematischer Code in unsere
Produkte quasi gar nicht mehr unbedingt in das Produkt, was
wir am Ende ausliefern, sondern auf die Maschinen, auf denen wir
bauen. Und damit kommen wir auch schon
dann zum nächsten Teil der Software Supply Chainsen nämlich
auch die Maschinen, auf denen wir bauen, das heißt, der ganze
cicd Prozess. Er ist natürlich auch Teil
unserer Software Supply Chain. Glaub alles, was wir darauf tun,
nämlich zum Beispiel das Signieren unserer Software, das
eigentliche Releasen, also den Prozess, dann diese, das
Kompilat irgendwohin zu kopieren, in einen
Dockercontainer zum Beispiel und den in ein ja vielleicht
kobiniertes Cluster zu deployen, sodass diese Version dann live
ist. Aber natürlich auch unsere
lokalen Developer Maschinen. Die sind auch häufig unter
anderem Ziel dieser Angriffe sind genauso wie die Buildserver
natürlich dann sehr relevante Dinge, denn da findet man als
Angreifer häufig Secrets, Passwörter, langlebige Tokens,
private Keys und. Und die werden dann oft Ziel
einer solchen Supply Chain Attacke.
Dadurch, dass ich mir ein Paket herunterladen, entweder die
Software bei mir lokal ausführe und beim Ausführen dann
irgendwas passiert oder sogar schon beim Herunterladen dieser
Pakete. Wir haben, das zeigt, wie lang
diese Lieferkette inzwischen geworden ist und wie viele
Komponenten dort enthalten sind, die entsprechend angegriffen
werden können. Und jeder dieser Punkte kann
irgendwie attackiert werden und ein Einfallstor für
entsprechende Schadsoftware werden.
Und wir haben ja in dieser Kette so ein bisschen so eine
Vertrauenskette, das heißt? Um in deinem Beispiel vom Anfang
zu bleiben, du als Restaurantbetreiber vertraust,
dem Großhändler der Großhändler vertraut wiederum seinen
Lieferanten, und die Vertrauen ihren Zulieferern und an allen
diesen Stellen kann natürlich dieses Vertrauen missbraucht
werden, weil ich vertraue vielleicht dir, aber.
Aber du hast vielleicht gar nicht gemerkt, dass dein Produkt
oder dein Teil und deine Komponente, die ich verwende,
irgendwie kompromittiert wurde. Das heißt, das ist jetzt auch
keine böse Absicht, nur weil du zum Beispiel jetzt einen
bestimmten. Entainer oder einem bestimmten
Package vertraust, ist das ja jetzt an sich nichts, was
irgendwie dann Missbrauch des Vertrauens ist, sondern
teilweise werden diese Leute natürlich ohne ihr Wissen zum
Vehikel, um Schadsoftware zu verteilen und dementsprechend
ist. Diese ganze Supply Chain,
eigentlich heute das Haupteinfallstor und Supply
Chain Security Angriffe eigentlich der Weg wie heute in
moderner Software verwundbarer Code eingeschleust wird.
Das heißt, ganz häufig werden jetzt nicht so wirklich
langwierige Angriffsprozesse auf große Unternehmen durchgeführt,
wo man dann versuchen muss, irgendwie ins Unternehmen zu
kommen. An der Corporate Firewall vorbei
in die Bildsysteme des entsprechenden Unternehmens,
sondern man geht in. Viel weiter vorne in der
Lieferkette rein, wo vielleicht die Sicherheitsstandards
geringer sind, wo man vielleicht vertrauen ausnutzen kann oder
einfach Leute überlastet sind. Wir haben ja häufig auch über
die Open Source Maintainer gesprochen und dann ist man
plötzlich bei den ganz großen Softwareprodukten angekommen und
bei den Developern, die diese bauen und kann dort entsprechend
seine Malware ausführen. Und diese Angriffe, die sind
selten gezielt auf euch. Jetzt zum Beispiel, sondern die
sind dann eher gezielt auf große Libraries, denen viele Leute
vertrauen, und dann hofft man einfach, dass sich diese
Angriffe häufig sind das irgendwelche Trojaner oder
irgendwelche Skripte, die Secrets sammeln und die dann
alle zentral auf irgendeinen Server pumpen.
Man hofft dann einfach, dass diese Angriffe möglichst
weitreichend sind und man dort dann auch möglichst viel einfach
von möglichst vielen Firmen abgreifen kann für.
Das heißt, es hilft eigentlich nicht, sich so ein bisschen
dahinter zu verstecken, zu sagen, ja, ich bin ja gar kein
spannendes Angriffsziel oder so, das weiß man gar nicht, weil man
selten hier gezielt angegriffen wird.
Die Pakete werden natürlich gezielt angegriffen, aber ihr
wahrscheinlich eher nichts, ihr seid dann eher einfach Opfer von
einem solchen Angriff und so ein Angriff, der kann ganz viele,
ganz viele verschiedene Facetten annehmen, das kann von wirklich
ganz, ganz simpel zu wirklich. Genial trickreich sich gestalten
der simpelste Angriff, würde ich sagen, ist eigentlich so ein
bisschen dieses Typo squatting. Da hofft man einfach drauf, dass
ihr euch vertippt. Das heißt, der Name sieht so
fast richtig aus. Ich will eigentlich Django
installieren und da gibt es ein Paket, das heißt dann aber nicht
DJ A NGO, sondern DAJ NGO und das sieht so für so menschliches
Auge häufig sehr sehr ähnlich aus, oder ich habe so Unicode
Zeichen oder minimale Vertipper, also so Dinge die mir dann beim
Copy, Pasten oder sowas nicht auffallen, oder?
Und dann habe ich statt das Paket, was ich eigentlich haben
wollte, das kompromittierte Paket runtergeladen.
Und häufig ist es sogar so, dass dieses kompromittierte Paket
dann das original Paket noch enthält.
Das heißt, ich merke das gar nicht auf den ersten Blick, denn
die Anwendung verhält sich so, wie ich das erwarten würde, ich
habe nur neben dem Paket mir noch irgendwie ein bisschen
Schadsoftware reingeholt, das ist so ein bisschen ähnlich, die
ja die billigste Klasse von Angreifern, aber auch so ein
bisschen die spannendste, weil man, weil man sich da gerne noch
irgendwie einredet, sagen, ja, gut, da musst du halt ein
bisschen besser aufpassen und aber ich glaube, so richtig frei
davon ist ist da niemand. Ja, und tatsächlich kann man
sich vor Tippfehlern vielleicht noch schützen, aber am Ende gibt
es natürlich auch viele andere Wege dort diese kompromittierten
Pakete einzuschleusen und eine andere Variante ist zum Beispiel
Dependency Confusion, das bedeutet, ich habe vielleicht
einen. Paket in einer bestimmten
Version sogar gepinnt. Ich habe alles richtig gemacht,
ich nutze vielleicht sogar mein internes Package
verwaltungssystem, irgendwie ein Artifactory, was ich selber
betreibe, um sicherzugehen, dass dieses Paket geprüft ist und
keine Malware enthält und dann veröffentlicht jemand in einem
Public in einer Public Registry eine neuere Version dieses
Paketes mit einer höheren Versionsnummer und vielleicht
hast du dann dein. Build System so konfiguriert,
dass immer die neueste Version zieht.
Und weil diese neueste Versionen noch nicht auf deiner lokalen
Registry vorhanden sind, gibt es dann vielleicht irgendwie einen
Fallback, wo dann wieder die Public Registry gewinnt und dann
zieht plötzlich dein Bildprozess entweder lokal oder in deiner ci
plötzlich dieses kompromittierte Paket.
Das heißt, du hast eigentlich alles richtig gemacht und am
Ende landet trotzdem wieder ein Paket auf deiner Maschine oder
im Build System, welches du nicht wolltest und hier ist.
Hast du vielleicht als Developer nichts falsch gemacht, sondern
das System, wie es irgendwann mal aufgesetzt wurde, vielleicht
von jemand völlig anderem, der ursprünglich mal das Repository
konfiguriert hat oder die CI Pipeline gebaut hat?
Hat dann hier entsprechend irgendwie immer latest
eingetragen und du hast das einfach so hingenommen und dann
hast du plötzlich den irgendwie credential Scanner auf deiner
lokalen Maschine, ohne dass du selber überhaupt etwas falsch
gemacht hast. Genau dabei setzen Angreifer
dann eben drauf, dass es fehlkonfigurationen oder zu
schwammige Konfigurationen in eurer Pipeline gibt.
Aber es kann eben auch passieren, dass ihr alles
korrekt konfiguriert habt und nicht den falschen Namen, die
falsche Quelle oder die falsche Version euch irgendwie reinholt.
Das sind ja alles so ein bisschen Flüchtigkeitsfehler,
sondern wirklich die richtige Library aus der offiziellen
Quelle mit einem offiziellen Release gezogen habt und sie
ist. Trotzdem bösartig, weil der
Mantainer kompromittiert wurde. Vielleicht das selber gar nicht
weiß, weil irgendein Publish Konto übernommen wurde und dann
ein schadhaftes Release aus der richtigen Quelle, also
eigentlich aus dieser legitimen Vertrauenskette heraus verteilt
wird und das ist dann besonders fies, weil da können wir uns
fast schon. Auch wenn wir alles richtig
konfiguriert haben, nicht wirklich davor schützen, weil
vor 2 Versionen war das noch alles perfekt was wir gemacht
haben und auf einmal hat jemand vielleicht sogar ebenfalls über
ein Paket den Maintainer kompromittiert oder gar nicht
nur den Maintainer, sondern ein weiteres eine transient
Dependency, also ein weiteres Paket, was das Paket dann
wiederum verwendet, was ich eigentlich mit ziehen will und
da kann ich dann eben nicht mehr mit ja musst du halt besser
aufpassen als meine Schutzstrategie arbeiten.
Sondern hier habe ich dann wirklich ja nen nen ne
Schadsoftware über ein vertrauenswürdiges Einfallstor
mir in das System geholt. Und genau diese Angriffswege
wurden ja zuletzt immer häufiger verwendet.
Das haben wir bei Shai Hulut gesehen, wir haben das bei Axeos
gesehen, wo dann wirklich du selber plötzlich jemand warst,
der diese Schadsoftware weiter verteilt hat, weil du dir
irgendwie ein legitimes Paket installiert hast.
Und dort war halt dieser credential Scanner drin, er hat
sich deine npm credentials geschnappt, hat geschaut, ob du
selber vielleicht ein Paket published und plötzlich war in
deinem Paket dann auch. Diese Schadsoftware drin und so
kann sich etwas natürlich extrem schnell verbreiten und häufig
ist wirklich der erste Einstiegspunkt so ein metainer
Credential League, wo einmal wirklich Informationen verloren
gegangen sind und dieses eine Paket irgendwie austauschen
konntest oder halt mit, wie du gerade gesagt hast, mit einer
Dependency versorgen konntest, die hier entsprechend
Schadsoftware einschleust und. Und das passiert natürlich jetzt
auch in Zukunft nicht mehr nur über menschliche Maintainer, die
irgendwie credentials verlieren, sondern immer häufiger verwenden
wir natürlich nicht nur automatisierte Systeme, sondern
wir verwenden sogar KI Systeme. Und auch da gibt es natürlich
jetzt schon die ersten Attacken, die das ausnutzen.
Wenn zum Beispiel du in deinem Repository irgendwie in deiner
ci irgendwas mit einem KI System machst, was vielleicht irgendwie
ein Triaging der Issues in dem Repository macht oder einen Code
Review macht und dann wird über eine prompt Injection Attacke
dann das KI System dazu gebracht hier das Package zu
kompromittieren und da hat am Ende nicht mal der.
Der Mensch selber einen Fehler begangen, sondern das KI System
wurde entsprechend überlistet. Natürlich kann man jetzt sagen,
irgendjemand hat ja dieses System ursprünglich
eingerichtet, aber das sind ja teilweise Dinge, die man einfach
vielleicht zu dem Zeitpunkt noch gar nicht so überblickt und es
entstehen natürlich gerade durch diese neuen Technologien auch
immer neue Angriffsvektoren, die ausgenutzt werden können.
Wenn. Wenn ich dann so ein Paket
irgendwie bei mir installiert habe, dann kommt diese
Schadsoftware häufig über diese sogenannten Post install Skripte
rein. Das ist eigentlich so ein
bisschen das, was jetzt die letzten Angriffe, also sowohl
diese diese Axios Attacke als auch shyho lut und so was dann
ausgenutzt haben und eigentlich ist es ein Unding, dass es
überhaupt gibt. Ich glaube, wenn wir die Zeit
zurückdrehen könnten, dann würde man wahrscheinlich sagen lassen,
das hätten wir niemals einführen dürfen.
Das ist dann einfach also ein Post and Score Script, das
funktioniert ist. Diese Pakete dürfen eben beim
Installieren auf meiner Maschine Code ausführen und wenn man sich
das heute so irgendwie anhört, nach all diesen Attacken, dann
fasst man sie ja fast schon an den Kopf, dass wir das jemals
irgendwie erlaubt haben. Dabei können natürlich dann
Dateien abgegriffen werden oder es geht eigentlich auch darum,
dass bestimmte Dinge vielleicht nachgeladen werden, also ich
installiere mir das Paket und wenn ich merke, dass ich auf Mac
OS bin, dann lade ich noch mal die Mac OS Binary von irgendwas
nach und dabei können aber natürlich auch lokale Systeme.
Inspiziert werden und dabei dann gehen diese Skripte oft auf die
Suche, ob ich nicht irgendwo lokal irgendwelche Creidentials
habe oder verschlüsseln meinen Rechner komplett.
Es kann natürlich auch sein, dass ich mir einen Virus oder
eine Ransomware darüber einfange, muss man aber
ehrlicherweise auch dazu sagen, für die Konsistenz diese Post
install Skripte, die stehen natürlich gerade im absoluten
Fokus, die sind aber nicht der gesamte Angriff, das ist nur
eine von mehreren Türen. Dieser Schadcode kann natürlich
auch beim Import ausgeführt werden.
Also wenn ich die Library in meinem Code lade oder vielleicht
auch wirklich erst zur Laufzeit, oder das ist ein Script, was
wirklich, was ich beim Bild verwende und dann wirklich erst
beim Bild irgendwie noch Sachen ausgeführt werden oder teilweise
dann auch wirklich erst im Nachhinein, wenn die wenn die
wenn die Binary. Aktiv wird also, wenn der
Endnutzer das ganze Ding verwendet.
Das heißt, wenn ich nur auf diese Post install Skripte
schaue, dann fange ich wahrscheinlich einen Großteil
der aktuellen Angriffslandschaft ab, muss aber ehrlich sagen,
dann schließe ich nur meine Haustür richtig ab.
Ich muss aber natürlich auch gucken, dass keiner durch die
Fenster oder den Hintereingang oder Irgendsowas reinkommt und
da gibt es noch ein paar andere Dinge, auf die ich achten muss,
aber Post install ist auf jeden Fall was, das kann ich in den
meisten Technologien auch mittlerweile abdrehen.
Wir sprechen gleich noch mal ein bisschen drüber, wie ich mich
jetzt eigentlich als Developer wirklich aufstellen kann, aber
das ist zumindest so dieser Hook, der jetzt in letzter Zeit
sehr, sehr stark in den Fokus gerückt ist, weil die ganzen
Skripte, die wir jetzt in der Vergangenheit gesehen haben,
eben darüber aktiviert wurden. Und hier sind wir gerade jetzt
auf der lokalen Developer Maschine häufig, und das ist ja
auch das, was wir tagtäglich nutzen, wenn wir Software
entwickeln. Und dort befinden sich natürlich
sehr viele wertvolle Ziele, also so ein Posting, Sold, Script, du
hast gerade gesagt, kann zum Beispiel einen credential
Scanner ausführen, der kann dann deine dort Inv Dateien scannen,
deine ssh Keys auslesen, deine Publish Tokens und dort
entsprechend dann dich auch zu einem ungewollten Helfer für.
Die Verbreitung von weiterer Schadsoftware machen oder
natürlich auch Secrets Clown für dein Git System oder Deine Cloud
Plattform und dieses dann auch ausnutzen.
Häufig werden diese Cloud Plattformen dann für Dinge wie
Crypto Miner oder Filesharing verwendet und da möchtest du ja
eigentlich natürlich nicht Helfershelfer werden, aber das
liegt natürlich daran. Dass gegebenenfalls du diese
Credentials auf deiner lokalen Maschine hast, hatten wir in der
Vergangenheit auch schon häufiger darüber gesprochen.
Wir reden gleich noch mal im Detail darüber, was man letzten
Endes tun kann. Aber am Ende ist das so.
Die lokale Maschine, die du selber unter Kontrolle hast.
Aber dann gibt es auch noch, ja natürlich das Bild System, was
in deinem eigenen Softwareentwicklungsprozess
natürlich auch eine Rolle spielt und dieses Bild System ist
vielleicht gar nicht unter deiner Kontrolle, wenn wir
vielleicht ein kleineres Produkt haben, wo wir irgendwie über so
einen. Def sec Ops Prozess reden wo
irgendwie man END to End Ownership hat, kontrolliert man
vielleicht das Bildsystem mit, aber gerade in größeren
Unternehmen sind das natürlich auch unterschiedliche Personen,
die diese Dinge aufgebaut haben und steuern und dementsprechend
müssen wir nicht nur auf die lokale Maschine schauen, sondern
natürlich auch auf unsere Bild und Release Pipeline, die dann
quasi im nächsten Schritt dann nachdem der Anteil der Arbeit
auf der Developer Maschine abgeschlossen wurde.
Die nächsten Schritte übernimmt aber.
Es kann ja auch einfach sein, dass ich irgendwas chippe an
meine Kunden, was dann dort wieder bei denen die Credentials
scannt und so weiter so passiert es ja auch teilweise bei diesen
Angriffen, dass dass Exeos an sich jetzt ja gar nicht das
große Angriffsziel ist, sondern die Developer von Exeos auch gar
nicht explizit getargelt werden, sondern dass die auch wieder
irgendwo etwas verwenden, was sie dann an ihre Kunden, also
die exeos, Userinnen und User. Quasi ausrollen und das dann
dort wieder zu Problemen sorgt. Das heißt, diese Kette kann auch
wirklich sehr, sehr lang und sehr, sehr verschachtelt sein
und es kann sein, dass du gar nicht weißt, dass du selber
Schadcode an deine Kundinnen und Kunden verteilst.
Ja, und das gefährliche ist ja, sobald es dann in diesem Release
Prozess ist. Dass auch diese Artefakte, die
du vielleicht auslieferst oder weiter verteilst, dann auch
entsprechend signiert werden, das heißt auch für die Nutzer
dieser Komponenten sieht das ganze alles dann sauber und
vertrauenswürdig aus, weil wir hatten es ja gerade am Anfang
gesagt, ich vertraue dir, der du dieses Paket baust und du weißt
vielleicht gar nicht, dass vor deinem oder während deines Bilds
und vor der Signatur. Schadsoftware aufgenommen wurde,
und das heißt, ich Krieg von dir ein absolut legitimes Paket,
welches von dir signiert wurde. Ich kann das quasi bis in deinen
Releaseprozess bis in deinen Quellcode nachvollziehen.
Aber trotzdem kann ich mich damit selber infizieren und das
macht das Ganze natürlich extrem schwer, auch komplett zu
unterbinden. Und am Ende sind natürlich
solche Credentialed und Secret Diebstähle so das häufigste
Szenario heute. Aber es gibt natürlich auch noch
andere Dinge, die über die Software Supply Chain Attacken
verteilt werden können. Und dazu gehören zum Beispiel
einfach diese, auch diese Seitwärtsbewegung.
Wir hatten gerade schon darüber gesprochen, dass man selber ein
Vehikel wird, um diese Schadsoftware weiter zu
verteilen, und diese Schadsoftware kann natürlich
auch Ransomware sein. Wir haben in der Vergangenheit
ganz oft darüber gesprochen, dass irgendwelche Unternehmen
und Firmen dieses Problem hatten, dass ihre ganzen it
Systeme verschlüsselt wurden und dann.
Versucht wurde, Lösegeld zu erpressen, das heißt, Secret
Diebstahl ist meistens nur der erste Schritt, um dann in
weiteren Schritten andere Schadsoftware verteilen zu
können und damit halt auch Geld zu verdienen, weil an sich, wenn
ich jetzt nicht unbedingt irgendwie deinen oder US oder
Azure Account ausnutzen kann, dann verdiene ich erstmal
vielleicht damit, dass ich deine Credentials habe, noch kein
Geld, aber sobald ich dann bei großen Unternehmen, bei
irgendwelchen Firmen. Oder in der öffentlichen
Verwaltung dann It Systeme Verschlüssele und dann dort
Lösegeld erpresse, kann ich natürlich auch entsprechend mit
diesen Angriffen Geld verdienen und ganz häufig sind natürlich
diese Angriffe nicht nur politisch motiviert, sondern
auch vor allen Dingen von Cyberkriminellen hier auch
finanziell motiviert. So, dann schauen wir doch jetzt
mal die developer Perspektive. Also wenn ihr jetzt nicht
unbedingt Main Tainer oder Publisher von solchen Projekten
seid, sondern wie wir alle einfach.
Über End Pam Install oder Konsorten euch Pakete reinholt.
Was kann ich denn realistisch machen?
Und da muss man schon leider sagen, wir haben uns jetzt im
Rahmen dieser Folge da so ein bisschen auch reingefuchst und
drauf vorbereitet und die kurze Wahrheit finde ich, ist so ein
bisschen ja eigentlich eher unangenehm, denn gegen so
legitime Releases, also nicht ich habe mich vertippt oder
irgendjemand anders hat eine neue Version veröffentlicht und
ich habe nichts gepinnt. Und diese legitimen Releases,
wie wir sie bei bei Exeos in diesen ganzen Shiyout Angriffen
haben, da gibt es jetzt leider nicht so dieses eine Ding, was
ich tun kann. Ich kann natürlich so ein
bisschen so gängigen Best Practices folgen, die Bauen oft
auf so einem Schichtenmodell auf, das heißt, a Nummer 1 ist
ganz klar weniger dependencies, um einfach diesen Angriffsvektor
zu minimieren, also ist wirklich zu fragen, brauche ich überhaupt
ein Exeos. Oder kann ich für diesen simplen
http request nicht vielleicht auch einfach die eingebauten
Tools benutzen, die das Framework oder die Delibrary,
die ich verwende, mitbringen? Das zweite ist, dass ich viel
besser kontrollieren muss eigentlich, woher ich meine, was
meine Bezugsquellen sind, die müssen Reviewbar sein, die
müssen deterministisch sein. Heißt es kann sein, dass es
darauf hinausläuft, dass ich mir selber eine zentrale Registry
irgendwo schaffe, wo ich regelmäßig Scans mache oder
policies unternehmensweit ausrolle, wo ich sage, wie in
unserem Unternehmen Pakete überhaupt auf unsere Rechner
kommen, das eine Menge vor und Nachteile ist ein sehr
kontroverses Thema, sprechen wir gleich aber noch mal im Detail
drüber und das nächste ist eigentlich, dass ich diesen
Installationscode einschränke, das heißt, dass ich diese ganzen
Post install skripte. Idealerweise ganz verbiete oder
mich zumindest darauf mal fokussiere.
Was ist denn da gut und was ist da schlecht?
Und leider ist die Wahrheit dann trotzdem so ein bisschen das,
auch wenn ich das alles gemacht habe und das sind so ein
bisschen die aktuellen Empfehlungen von großen Security
Research Vereinigungen, selbst wenn ich dem allen Folge, kann
es trotzdem sein, dass ich mir irgendwas einfange und deswegen
muss ich mich wahrscheinlich auch mit der unangenehmen
Wahrheit auseinandersetzen. Dass ich vielleicht gar nicht
ganz sicher zu 100% verhindern kann, dass die Laptops von
meinen Developer, sage ich mal, kompromittiert sind.
Das heißt, ich muss mich im letzten Schritt auch eigentlich
darum kümmern, dass nichts zu finden ist.
Auf meinen developer Maschinen, was so wertvoll ist, dass es
eine für den für einen Angreifer wahnsinnig interessant und für
mich dann eine große Katastrophe werden könnte.
Das. Dann lass uns mal in die
einzelnen Themen ein bisschen tiefer reingehen und eine der
Dinge, die du erwähnt hattest, die jeder von uns machen kann,
ist Logfiles verwenden und auf bestimmte Hashes und wirklich
feste Versionen der Packages zu pinnen.
Und das ist natürlich etwas, was nur begrenzt hilft, wenn man
davon ausgeht, dass natürlich auch der korrekte maintainer
Account kompromittiert sein kann.
Das heißt, ich habe die richtige Version.
Entsprechend, und diese ist auch entsprechend signiert, aber
trotzdem kann sie natürlich Schadsoftware enthalten, aber
das heißt nicht, dass ich das nicht tun sollte, weil ich
natürlich andere Angriffsvektoren damit abwehren
kann, zum Beispiel, dass neue Versionen released werden, die
irgendwie Schadsoftware haben, oder dass vielleicht aktuelle
Versionen überschrieben werden. Von daher habe ich da auch die
Möglichkeit, natürlich bei vielen dieser Systemen dann.
Die entsprechenden Hashes zu pinnen und damit sicher zu
gehen, dass ich wirklich eine nicht modifizierte Spinery einer
bestimmten Version habe. Das heißt, ich muss das tun,
aber sollte mich halt trotzdem nicht 100% sicher fühlen und
weiterhin die anderen Punkte, die wir jetzt mal im Detail
besprechen werden, weiterhin berücksichtigen und dazu gehört
natürlich auch so ein bisschen eine.
Ein Delay und Holdback bei neuen Paketversionen.
Genau das hat damit zu tun, dass sich, dass die meisten von
diesen kompromittierten Paketen innerhalb von Stunden erkannt
werden. Das heißt, da lädt jetzt jemand
irgendwas hoch in Nugget oder in npm, und die Maintainer und die
Unternehmen hinter diesen zentralen Registrys, die sind
eigentlich relativ gut da drin. Diese Angriffe zu erkennen, das
heißt, üblicherweise verschwinden die nach einigen
Stunden wieder. Mit diesem Delay und Holdback
konfiguriere ich jetzt mein lokales System so, dass ich zum
Beispiel einfach sage, nehmen jetzt mal an, ich, ich nutze
Pnpm in dieser ganzen Java Script Welt, was auch absolut
die Empfehlung hier sein wird, das ist auf jeden Fall das
modernste System neben npm und Jahren und auch vor allem das
was ich am am besten eigentlich einstellen und auf diese
Angriffe vorbereiten kann. Dem kann ich zumindest sagen,
dass es jetzt eine Minimum Release Age geben soll.
Ich könnte zum Beispiel sagen, Hey, ich möchte, dass du keine
Pakete installieren darfst, die jünger als 24 oder 48 Stunden
sind, bedeutet, selbst wenn der Mantainer eine neue Version
hochlädt, kann ich die frühestens in 48 Stunden in mein
System rein installieren und damit habe ich zumindest schon
mal so 8085% von diesen Angriffen vermieden.
Das kommt natürlich ein bisschen mit dem Nachteil, dass es, wenn
ich jetzt einen ganz wichtigen Security Hotfix habe, den auch
erst nach 48 Stunden bekomme. Hier kann ich aber beruhigen,
man kann dafür natürlich auch Ausnahmen definieren, das heißt,
wenn ich jetzt weiß, das ist genau ein Paket, von dem ich
irgend aus irgendeinem Grund weiß, dass es ein Security
Hotfix ist und der ist sauber, dann kann ich natürlich sagen,
den darf ich dann trotzdem früher installieren oder der
Defender bot darf den das schon früher vorschlagen oder sowas,
aber. Habe ich kann das generell
konfigurieren, wenn wir jetzt mal auf dieser in dieser npm
Welt bleiben? Ich kann zum Beispiel eine, also
wenn ich in Pnpm verwende, da kann ich diese pnpm Workspace
Punkt jammel Datei anlegen und da kann ich zum Beispiel sagen,
es gibt eine Minimum Release Age und ich kann das nämlich sagen,
da exkludiere ich aber Pakete, die zum Beispiel aus meiner
Firma kommen oder eine ganz bestimmte Liste kann ich da
pflegen, das heißt es lohnt sich absolut so ein.
Pnpm Workspace yammel Datei anzulegen und damit so ein
bisschen für so einen Delay zu sorgen, wenn ihr nicht auf Pnpm
seid, kann man das auch in der Package Chase machen.
Wir würden aber ganz klar, weil wir gleich auch noch ein paar
andere Sachen eingehen Pnpm empfehlen, wenn ihr in dem Java
Script Eco System unterwegs seid.
Und gerade für Unternehmen besteht ja zudem die Möglichkeit
und viele machen das auch, bereits eigene Registrys zu
betreiben. Das ist jetzt für vielleicht
mich als Einzel developer nicht wirklich praktikabel, aber
gerade für Unternehmen nicht nur eine Möglichkeit, um intern
eigene Pakete zu publizieren und eben Unternehmen zu verteilen,
sondern auch öffentliche Pakete quasi als Proxy vorzuhalten und
dementsprechend immer zwischen meinem Bildprozess und der
Public. Registry zu stehen und
dementsprechend kann ich dann genau kontrollieren, welche
Pakete verwendet werden und ich kann da auch halt so ein Delay
einbauen. Ich kann sagen okay diese Pakete
werden dort nur manuell aktualisiert, manuell
hinzugefügt oder es gibt quasi ein Pull through, aber das
vielleicht auch nur mit zeitlicher Verzögerung und damit
kann ich dann natürlich sicherstellen, dass ich einen
weiteren quasi sicherheitsriegel in diese Lieferkette einbaue,
den ich kontrollieren kann, um einfach zu verhindern.
Verhindern, dass irgendjemand aus Versehen in meinem
Unternehmen hier irgendwelche kompromittierten Pakete
installiert, bedeutet natürlich auch, ich muss irgendwo
sicherstellen, dass die Leute nicht aus versehen dann doch
Pakete von einem öffentlichen Mpm ziehen, indem ich das
vielleicht über die Firewall blocke oder ähnliches und nur
halt meinen Proxy freigebe, was auch vielleicht für die
Developer am Ende nicht die beste Developer Experience ist.
Insbesondere wenn ich vielleicht.
Damit noch nicht so viel Erfahrung habe, oder ich benutze
jetzt irgendwelche Coding Agent, die nicht richtig konfiguriert
sind und gar nicht wissen, dass sie auf meine lokale Registry
zugreifen sollen. Das heißt die benutzen dann
irgendwelche Pakete, die vielleicht bei mir im
Unternehmen gar nicht verfügbar sind und dann renne ich da immer
wieder gegen Wände, das heißt, das hat Auswirkungen auf die
Developer Experience, aber ist ja definitiv auch etwas, was die
Sicherheit erhöht und ich glaube, man muss da wirklich
die. Die Balance treffen insbesondere
wie man dieses System konfiguriert und welche
Möglichkeiten es dennoch gibt, vielleicht in bestimmten
Bereichen die Public Registrys zu verwenden für Pakete, wo man
vielleicht irgendwie erstmal Prototypen baut etc.
Ich glaube, da habe ich auch eine ziemlich starke Meinung zu
diesen zentralen Registrys. Ich würde das auf gar keinen
Fall so aufsetzen, dass da nur freigegebene Pakete drin sind.
Ich glaube, das schränkt eine eine Developer Experience, aber
auch irgendwo eine. Ja, eine eine Kreativität oder
einen gewissen Innovationsstream zu sehr ein.
Also ich würde da gar auf gar keinen Fall irgendwie ein
Ticketsystem bauen, was dann jede Library manuell
freischaltet, sondern wenn man das macht, dann so, wie malte
gerade gesagt hat, er durch so ein, man nennt das einen Puls
through Cash, also dass ich quasi meine meine registrys oder
bisschen meine Projekte so anweise wieder in der javastrip
Welt kann ich das über so eine npmrc Datei ja machen und sagen,
du holst dir immer was aus dieser Registry und auch für für
Python und so was kann ich dann so einen Standard upstream dann
eben irgendwie sagen und in dieser Registry die dann
unternehmensweit ist, da finde ich die internen Pakete, aber da
finde ich auch alle öffentlichen Pakete, aber vielleicht schon
mit so einem Delay oder so einem Holdback konfiguriert und
vielleicht habe ich da auch noch einen Scanner, der da regelmäßig
drüber geht und er kann natürlich dann auch tracken,
welche Pakete überhaupt irgendwie bei mir installiert
wurden. So richtig erzwingen kann ich
das natürlich nicht, das ist halt extrem schwierig.
Es gibt ein paar Sachen, wo ich das kann.
Ich kann zum Beispiel da irgendwie es es gibt Tools über
alle meine Repositories hinweg checken, ob eine Punkt NPMRC
entsprechend angelegt und konfiguriert wird.
PNPM hat auch sowas wie config dependencies, da kann ich dann
so Konfigurationen und Berechtigungen und sowas zentral
in so ein gemeinsames Config Paket auslagern und dann muss
ich eben alle meine Developer anweisen dieses config Paket zu
referenzieren. Aber wenn ich sie wirklich,
wirklich hart im Unternehmen umsetzen will, wie du gerade
gesagt hast, eigentlich nur mit Infrastruktur, und das ist dann
oft schon schwieriger. Ich glaube, da geht es eher
darum, dass die Developer das Know How haben und ohnehin die
Library an oder diese zentral Registry anbinden wollen, weil
sie da auch die unternehmensintern Pakete finden
und dann kann man zum Beispiel bei Python sagen, dass sie keine
extra ur LS oder sowas erlauben wollen, dass man einfach sagt
okay ich, ich muss um mich ohnehin einmal gegen diese
Library authentifizieren, weil das.
Paket das Projekt baut sonst gar nicht, braucht die internen
Pakete und da finde ich auch alle anderen Sachen.
Aber wie gesagt, ich glaube, da gibt es so eine richtig schöne
Lösung, dass man das zentral dann alle anderen Pakete packet
Registry es erlaubt würde nur über so Firewall Sachen gehen,
dass ich sagen kann du darfst gar nicht auf npmjs oder irgend
so was drauf. Aber ja weiß ich nicht, ist
glaube ich nicht so richtig, dass.
Der richtige Weg? Ich würde eher sagen, lass uns
dafür sorgen, dass alle diese Punkt NPMRC oder eben respektive
für die anderen Plattformen andere Konfigurationsdateien so
Konfriert haben, dass sie auch die zentrale Registry zeigen.
Aber die darf auf gar keinen Fall so ein Innovations bottle
Lack werden. Dann hat sie ja gerade auch noch
gesagt, dass wir unser Posting Store entsprechend konfigurieren
sollen. Ich glaube ganz pauschal
deaktivieren führt natürlich auch dazu, dass manche Pakete
einfach nicht mehr sich richtig installieren lassen, weil sie
das immer noch legitim nutzen, aber dann muss ich natürlich
schauen, okay kann ich das so konfigurieren, dass es
vielleicht nur bei bestimmten Paketen ausgeführt wird?
Und weil sonst wird das natürlich auch wieder zu Frust,
wenn ich halt bestimmte Packages einfach nicht mehr verwenden
kann, weil diese halt darauf ausgelegt sind, dass das Ganze
konfiguriert ist und funktioniert.
Also von daher muss man da vielleicht schauen, dass man da
ein gewisses Whitelisting erlaubt, aber am Ende sind es
immer diese Balancen zwischen Einfachheit und Developer
Experience und zusätzlicher Sicherheit, die ich natürlich
durch diese Schranken dann entsprechend.
Reinziehen kann. Und dazu gehört natürlich auch,
dass ich mir ganz genau überlegen muss, okay, was führe
ich eigentlich auf meine developer Maschine aus und wenn
wir jetzt darüber reden, dass wir keine Post Install Skripte
mehr erlauben wollen, könnte man ja auch einen Schritt weiter
gehen und sagen, ja, eigentlich darf ich gar keine Tools
installieren, die einfach irgendwie mit meinen Rechten auf
der auf dem Terminal auf der CI ausgeführt werden.
Ja, das ist wahrscheinlich nicht falsch.
Das ist natürlich auch nicht realitätsnah, aber vielleicht
kann dieses Tool ja irgendwie. Also ich sollte zumindest mal
kein komplett unvertrauenswürdiges Tool,
sondern irgendwas was ein populäres Tool und dann
vielleicht mit diesem Delay, das kann ich mir noch überlegen, ob
er auf gar keinen Fall mit Admin Rechten zum Beispiel oder ich
muss ja nicht alle Tools global ausführen, ich kann sie ja
wirklich nur in die Projekte rein installieren, in denen ich
dann genau dieses Tool brauche, wenn sie eben über eine packet
Registry kommen, die. Ich glaube damit auf jeden Fall.
Also diese ganzen CLI Tools, die muss ich genauso behandeln.
Und ja, am Ende auch kann ich mich, muss ich mich trotzdem
dann damit abfinden, dass ich darüber auch mir Schadsoftware
reinholen kann, aber ich kann ja bestimmte Dinge tun, wir haben
ja gerade darüber gesprochen, ich kann Reprovite diese
Einstellungen machen und sagen, Nein, keine Post in Soul Skripte
ich. Ich kann zum Beispiel auch wenn
ich jetzt sage, okay ich kann, weil ihr sagt, inzwischen ja
okay pnpm cool, aber wir haben auch noch developer, die nutzen
aber Jahren oder das normale Npm, und da kann ich bestimmte
Dinge nicht einstellen, auch das kann ich versuchen zu erzwingen,
zum Beispiel, ich kann zum Beispiel in der Package Jason
von meinem Repo sagen, es gibt ein Pre install Script und da
gibt es das das Pre install script npx only allow pnpm, das
heißt, damit würde ich erzwingen, dass alle Leute in
meinem Projekt Pnpm verwenden. Es sind auch Dinge, die kann ich
dann vielleicht über so eine Gerätekonfig standardisiert
ausrollen. Oder ich mach mir irgendwas, was
ja sicherstellt, dass alle meine Repositories in der gleichen
Konfiguration sind. Da gibt es auch Tools, die das
dieses checken. Also es gibt ja Wege drumherum
und trotzdem ist es mir noch mal wichtig zu sagen, Hey, am Ende
so ganz 100% sicher kann man sich nicht schützen, es kann ja
auch sein, dass ich mir ein CLI Tool installiert habe, was dann
irgendwann aufwacht und da Schadcode ausführt, obwohl das
halt lange gut aussah und diese. Diese, dieses Delay in dieser
holdback Zeit schon lange rum ist.
Und deswegen würde ich noch mal gerne letzten Endes darauf
aufmerksam machen. Ich muss davon ausgehen, dass
mein developer Rechner kompromittiert werden kann, da
haben keine langlebigen Tokens zu liegen, da hat keine Dot 11
Datei zu liegen mit einem mit einem Key zu einem AI Modell
oder sowas was ich für mehr als nur so ein bisschen testen
verwende und. Secrets haben in einem Passwort
Volt zu liegen, gegen den ich mich authentifizieren muss.
Private Keys, selbst wenn sie irgendwo liegen, die gehören in
einen Passwort Manager, da gehört ein Passwort auf den
private Key und dieser Passwort und der Passwort Manager muss
geschützt sein, es gibt keine, es gibt nur kurzlebige O aus
Tokens die wahrscheinlich dann irgendwie wieder interaktiv
durch eine 2 Faktor Mechanismus. Aktualisiert werden müssen.
Auf meinem Rechner muss ich davon ausgehen, wenn es ein
developer Rechner ist. Der braucht ohnehin elevated
Rechte, dass der kompromittiert werden kann und wir müssen uns
an die eigene Nase fassen, das hat mir glaube ich auch schon
mal bei dieser shiho Loot Folge gesagt wo dieses diese Scanner
Tools verwendet die dann auf der Maschine nach.
Nach secrets scannen, das kann ich selber auch einfach mal
machen, ohne dass es gerade einen Angriff gibt und einfach
mal schauen, wo habe ich auf meiner Maschine Dateien, die da
eigentlich nicht hingehören, denn wir sind heute, wir haben
keine Dot End Dateien mehr irgendwo liegen zu haben, wir
haben keine unverschlüsselten oder nicht passwortgeschützten
private Keys irgendwo liegen zu haben und wenn wir API Keys
irgendwas brauchen, dann gehören die in einen in einen Volt, da
gibt es hashicop Volt zum Beispiel oder es gibt auch von
jedem Cloud Hersteller. Was wir wie Azure Key wollt und
so weiter da haben die drin zu liegen und dagegen
authentifiziere ich mich auch nicht mit einem Client ID oder
einem Client secret, sondern mit einer Identität.
Du hast ja gerade gesagt, wir müssen eigentlich davon
ausgehen, dass wir betroffen sein können und dementsprechend
ist natürlich wichtig zu wissen, ob ihr oder ob euer Produkt
betroffen ist. Und dafür könnt ihr natürlich
eine Supply Chain Security Lösung verwenden.
Aber ganz wichtig dafür ist, dass man natürlich weiß, welche
Depensies habe ich eigentlich und welche Depensies haben diese
wiederum und da hatten wir auch schon mal eine Folge zu gemacht
rund um Software Bill of Material zu.
Ich glaube, das war Folge 103. Wer das noch mal nachhören
möchte, wo dann tatsächlich für alle Softwareprodukte, die wir
bauen, aufgeschlüsselt wird, welche Dependencies wir haben
und dann kann man natürlich dann auf die nächsten Ebenen runter
gehen und schauen, was sind entsprechend dort die Transitive
Dependencies, also welche Dependencies haben meine
Dependencies und so weiter und können das dann entsprechend
nachvollziehen und. Und entweder über unsere
automatisierte Supply Chain Security Lösungen sofort
alarmiert werden, wenn eine unserer Dependencies in unserer
Lieferkette kompromittiert ist. Oder natürlich automatisiert
auch Updates bestimmter Packages durchführen lassen.
Genau, weil das ja noch viel schlimmer betroffen zu sein und
das nicht zu merken. Also man braucht ja irgendwie
eine Möglichkeit, dass wenn jetzt die nächste News folge
gehört und wir sagen okay, jetzt gibt es das nächste populäre
Paket, ich nehme jetzt einfach mal keine Ahnung, Projekt ich.
In der Version 123 das ist betroffen.
Ihr hört das hier im Podcast oder lest das irgendwo online.
Ihr braucht natürlich eine Möglichkeit rauszufinden, ah
okay habe ich denn diese Version in irgendeinem meiner meiner
Projekte und dafür ist dieser s bom dieser Software Build of
Material elementar. Ich glaube, wenn ihr Gitter
Projekte habt, da gibt es sogar irgendwo glaubt es ist in einem
Paket mit drin, kann man sich dann diesen Software Build of
Material eben runterladen und nach genau dieser Versionsnummer
dann auch suchen, aber das ist natürlich super wichtig.
Dass man irgendwie ne Möglichkeit überhaupt
rauszufinden, ob man das Projekt verwendet, was da betroffen ist.
Und wenn ihr selber nicht nur konsumiert, sondern auch
produziert, sprich ihr published extern eure Pakete für die
Nutzung von anderen. Das kann im Unternehmen sein,
das kann aber auch. In der Software oder Open Source
Community sein? Dann tragt ihr natürlich noch
zusätzliche Verantwortung für die Lieferkette und
dementsprechend, und das hatten wir in diesen ganzen Folgen, um
shai Hulu auch schon angesprochen, müsst ihr
sicherstellen, dass euer Account über die entsprechende
Authentifizierung verfügt, das heißt 2 Faktor Authentifizierung
ihr müsst euren Publish Prozess so absichern, dass nur legitime.
Ci Pipelines oder ihr selber publizieren dürft.
Ihr solltet natürlich immer mit minimalen rechten arbeiten und
wie du gerade schon gesagt hattest, auf deiner Lokalen, die
waren auch paar Maschinen, auf keinen Fall langlebige Tokens
nutzen, die es bei einer Kompromittierung der lokalen
Maschine anderen erlaubt deine Packages zu manipulieren zu
überschreiben, das heißt das Schlimmste was passieren kann
ist mein Publishing Account wird kompromittiert, mein Github
Account wo das? Open Source Projekt liegt wird
übernommen und dann, ohne dass ich es vielleicht selber merke,
bin ich derjenige, bei dem diese Lieferkette entsprechend
zusammenbricht und dementsprechend brauche ich auch
immer die Unterstützung eigentlich von anderen.
Ich sollte nicht irgendwie als Single Maintainer arbeiten,
sondern immer auch mit anderen zusammenarbeiten und es hier
auch dann in meiner Konfiguration erzwingen, dass
zum Beispiel immer 4 Augen Prinzip bei Pull request Merges.
Und gerade bei sensiblen Änderungen insbesondere intensiv
drauf geschaut wird. Ganz häufig versuchen auch Leute
über wir hatten auch darüber gesprochen in der Vergangenheit
über irgendwelche kleineren Fixes in deinem Open Source
Projekt sich dein Vertrauen zu erschleichen und dann irgendwann
kommen dann die größeren PR s und Du guckst da gar nicht mehr
so drauf, weil du der Person vielleicht schon das Vertrauen
gegeben hast und dann merkst du vielleicht selber den Schadcode
in dein Projekt mit rein und. Und da ist es natürlich
wichtiger denn je, mit anderen zusammenarbeiten und umso
kritischer dein Paket ist, umso gefährlicher ist es, wenn du
alleine dafür verantwortlich bist.
Weil dann bist du der einzige Punkt, der kompromittiert werden
muss, um das Ganze zu übernehmen und zu missbrauchen.
Und hier vielleicht an der Stelle auch noch mal der Aufruf,
wenn eure Firma eigentlich auf 23 npm nu Geld.
Mavin was auch immer Paketen aufsetzt, die irgendein armer
Open Source, Maintainer oder Maintainerin da vorne alleine
betreut, dann denkt doch mal drüber nach oder?
Sprecht das doch mal irgendwie an, ob man diese Menschen nicht
irgendwie entlasten kann und entlasten kann man sie in der
Regel, indem man sie finanziert. Also ich finde immer noch mal,
es werden noch immer viel zu wenig Open Source Maintainer
gesponsort, es gibt ja mittlerweile über github so ein
Sponsoring wo ich wirklich nicht einmal einen Betrag, sondern
regelmäßig wieso ein eigentlich wieso eine Lizenz für einen Open
Source? Produkt erwerben kann, indem ich
da regelmäßig und wenn es 100€ sind oder sowas im Monat.
Aber wenn das viele machen, dann lohnt es sich eben A dieses
Paket weiter zu maintainen das heißt es gibt auch eine gewisse
Zusage oder Sicherheit, dass dieses Produkt auch oder dieses
diese Library eben auch möglichst lange noch noch weiter
überlegt und b ist das auch der Nummer 1 Hebel um Maintainer zu
entlasten, die das dann vielleicht mal irgendwann
Vollzeit machen können und weniger anfällig für Social
Engineering sind. Ich mache selber auch viel,
viel, viel zu wenig, aber. Aber es war mir wichtig, das
hier noch mal zu erwähnen. Und jetzt haben wir über diese
ganzen Maßnahmen gesprochen und mal angenommen, ich bin jetzt
dafür verantwortlich für die Developer Plattform in meiner
Firma und ich gehe jetzt hin und befolg das alles, das heißt, ich
setze irgendwie meinen eigenen Package Manager auf, irgendwie.
Mit oder meine eigene Registry als Proxy konfiguriere die so
entsprechend, dass meine Developer die nutzen können.
Ich blocke den Zugriff auf Public registrys ich mache eine
Group Policy, die es verbietet Post Install Skripte
auszuführen, ich scanne für Secrets, um sicherzustellen,
dass auf den developer Maschinen keine Secrets liegen, die dann
leaken können. Das heißt, ich mache eigentlich
alles richtig, alles irgendwie möglichst gut, um mich hier
abzusichern. Für die teuersten Security Tools
ein bin ich dann sicher, also alles was wir gerade besprochen
haben ist jetzt abgehakt, bin ich dann auf der sicheren Seite?
Nee, natürlich nicht. Hatten wir ja schon ein paar Mal
jetzt hier irgendwie gesagt, 100%, sicher kannst du gar nicht
sein, du kannst den Blast radius durch sowas natürlich
minimieren, aber kann man jetzt irgendwie eine randomware
Attacke dich trifft und alle Dateien verschlüsselt sind?
Jetzt auch nicht viel. Kannst du auch nicht viel
machen, kannst halt dafür sorgen, dass du durch gute
backup Prozesse und sowas das alles wieder wiederherstellen
kannst. Ich würde jetzt auf gar keinen
Fall in Panik verfallen und sagen, jetzt wird hier alles
wirklich abgeschottet und ich erlaube jetzt gar kein mehr,
sogar die npmjs Website oder sowas zu zu besuchen.
Ich glaube man muss schon auch irgendwie eine gute Balance
zwischen dieser Developer Experience finden und auch wie
du gerade gesagt hast, auch, dass irgendwie ich.
Vielleicht einen KI Assistenten sauber arbeiten lassen kann,
dass ich selber hier keine Innovation irgendwie hemme,
indem die Leute resignieren und sagen, Ach ja gut, bis das Paket
mal bei uns in der Patch in der Package Registry ist oder sowas,
das glaube ich funktioniert ich glaube du frustrierst die eine
Hälfte der Leute und die andere Hälfte der Leute machst du
kreativer im Regelbruch, weil das ist dann einfach schlechte
Security die einfach nur einschränkt ohne wirklich zu
schauen was ist denn sinnvoll und was steht denn aber auch
überhaupt in irgendeinem Verhältnis das deswegen glaube
ich eigentlich schon, dass wir hier in dieser Folge einen ganz
guten Mittelweg gefunden haben mit diesem, Hey entforced doch
mal alle in dieser Java Group Welt PNPM zu verwenden und nicht
mehr npm oder Jahren entforced mal alle, dass sie über eure
Registry einen Impuls Group Crash haben oder wenn ihr das
für die falsche Variante haltet, sorgt zumindest mal dafür, dass
es dass Pakete default mäßig so einen Delay, so einen holdback
Timer von sagen wir mal 48 Stunden oder sowas haben.
Ich glaube man kann da schon relativ viel machen, der
Industrie fehlt es meiner Meinung nach noch so ein
bisschen daran, dass wirklich. Ja, zuverlässig, zentral an
einer Stelle auszurollen. Pn PM hat da so ein paar
Konzepte für wie diese zentrale config Registry, aber da muss
ich auch wirklich dafür sorgen, dass alle Projekte das
einsetzen. Bisschen was kann ich vielleicht
auch über sowas wie Device Management oder sowas ausrollen,
aber ich glaube es ist wichtig, dass eine zentrale Packet
Registry es nicht irgendwie zum Bottle neck wird oder neue
Pakete ewig dauern oder diese ganzen Security Scanner die ich
habe viel zu viele Warnungen werfen, sodass Teams diese
Alerts einfach nur noch wegklicken, ich glaube.
Die beste Security ist die, bei der der sichere Weg auch der
bequemste Weg ist, weil mir einfach viel schon vorher
eingerichtet wird. Es ist natürlich auch eine eine,
eine Schulungsmaßnahme, ich muss die Awareness schaffen und dann
darf die aber auch nicht im Weg stehen, wenn Leute schnell oder
innovativ arbeiten möchten. Ja, ich glaube.
Zusammenfassend können wir sagen, diese Angriffe, die
kommen häufig trotzdem immer noch bei dir an, weil sie über
legitime Kanäle kommen, denen du vertraust.
Dementsprechend muss man wirklich das Bewusstsein dafür
haben, dass es passieren kann und eine einzelne Maßnahme wird
dort nicht die Lösung sein. Du hast gerade noch mal alles
zusammengefasst, was ich machen kann in diesen verschiedenen
Schichten und umso mehr dieser Schichten ich bei mir umgesetzt
habe und umso geringer ist das Risiko und am Ende.
Bist du nicht gegen alles geschützt, aber du kannst halt
sichergehen, dass nicht dein gesamtes Unternehmen lahmgelegt
wird oder du selber Verteiler von Malware bist.
Und ich glaube, das fasst es ganz gut zusammen, dass man da
diesen diesen Mittelweg finden muss zwischen Developer
Experience und Sicherheit. Und ich glaube, das ist etwas,
was glaube ich, uns beiden extrem.
Wichtig ist, und ich hoffe, diese Folge hat euch geholfen,
da diesen Überblick zu bekommen. Also was kann man tun, was
sollte man tun und wie kann man sich möglichst gut auch in
dieser neuen Welt, wo immer häufiger diese Dinge passieren,
gegen diese Risiken absichern. Und die Gefahr, die ist Real.
Also diese Angriffe werden immer cleverer und man merkt auch,
dass man diese Lage schon deutlich verbessern kann, indem
man dieses Vertrauen, was wir in der Vergangenheit blind
geschenkt haben. Nicht mehr genauso blind wie in
der Vergangenheit verschenkt. Aber das Thema ist jetzt
allgegenwärtig und das ist ja der Grund, warum wir diese Folge
gemacht haben, wo ihr uns nach unserer Meinung oder unserer
Sicht auf diese Dinge gefragt habt und wie, wie sehr und wie
restriktiv man da sein sollte. Uns interessiert aber auch
wahnsinnig, was macht ihr denn heute in euren Unternehmen
dagegen, weil ihr habt jetzt hier unsere beiden Meinungen
gehört, wir haben aber auch die Weisheit hier nicht mit Löffeln
gefressen, wir haben uns jetzt in der Vorbereitung dieser Folge
natürlich ganz gut. Und hoffentlich auch Recht
umfassend informiert. Und trotzdem spiegelt das ja
nicht immer die Realität ab und das könnt ihr auch gerne anonym,
aber auch gerne, wenn ihr möchtet, so dass man da noch mal
eine Nachfrage stellen kann. In den Kommentaren von der Folge
auf Youtube oder auf Spotify oder auch wenn ihr es nicht
öffentlich machen wollt, gerne per E Mail mit den Adresse in
den in den Show Notes zu. Mit uns mal besprechen, weil das
würde uns interessieren. Wir haben jetzt hier irgendwie
so eine, so eine Welt aufgezeichnet, die auch weit weg
davon ist, perfekt zu sein, aber zumindest schon mal erstmal
glaube ich, ganz gute Maßnahmen gegensteuert gegen diese sehr
sehr akute und reale Gefahrenlage, aber wie real ist
das denn bei euch im Unternehmen?
Macht ihr euch Gedanken dazu, ist das Thema präsent, was sind
eure Maßnahmen dagegen, das würde uns einfach wahnsinnig mal
interessieren und mit Sicherheit auch den Rest der Community.
Also wenn ihr da euren Beitrag zu beisteuern wollt und eure
Sicht, die Dinge oder eure Realität schildern wollt, freuen
wir uns sicherlich alle, wenn ihr das in den Kommentaren tut.
Und wenn euch die Folge weiter gebracht hat, lasst natürlich
gerne eine positive Bewertung da.
Und wenn ihr nach der Folge hingeht und die ein oder andere
Maßnahme umgesetzt habt, dann lasst uns das gerne wissen.
Allgemein freuen wir uns natürlich immer über Feedback
und Austausch mit euch und wie wir am Anfang gesagt haben,
besonders freuen wir uns natürlich, wenn ihr uns.
Uns einen Kaffee ausgebt über bei mir coffee.com könnt ihr
dies schnell und einfach tun und werdet dann auch in einer der
nächsten Folgen erwähnt. Sonst.
Freuen wir uns natürlich drüber, wenn ihr nächste Woche wieder
mit dabei seid. Der to do Cast erscheint
wöchentlich, jeden Montag gibt es eine neue Folge, immer
abwechselnd eine News Folge oder eine Themenfolge wie diese hier
und dann schauen wir doch mal, ob wir in der nächsten News
folge leider vom nächsten kompromittierten Paket berichten
müssen oder ob es uns erspart bleibt.
Bleibt also dran. Dran.
Es bleibt spannend. Wir kratzen immer alle 2 Wochen
die Tech und Developer News, der irgendwie genau dieser 2 Wochen
zusammen oder machen eine Themenfolge wie diese hier.
Wir freuen uns, wenn ihr bei beiden dabei seid, wenn ihr es
noch nicht getan habt, abonniert gerne den Podcast und sonst habt
eine gute Woche, habt eine gute Zeit und schreibt ganz viel
Code. Bis dann.