Mehr als 100.000 infizierte Repositories auf GitHub entdeckt

 (apiiro.com)
1 Punkte von GN⁺ 2024-03-01 | 1 Kommentare | Auf WhatsApp teilen
  • Eine seit Mitte 2023 laufende Kampagne zur Repository-Verwechslung (repo confusion) breitet sich erneut aus; auf GitHub wurden mehr als 100.000 Repositories mit ähnlichen bösartigen Payloads entdeckt
  • Die Angreifer erstellen bösartige Kopien, die legitimen Repositories ähneln, um Entwickler zu Fehlgriffen zu verleiten, und kombinieren Klonen, Einfügen von Loadern, erneutes Hochladen, massenhaftes Forken und verdeckte Bewerbung
  • Wird ein bösartiges Repository ausgeführt, werden nach 7 Stufen der Verschleierung Python-Code und Binärdateien nachgeladen; dabei werden sensible Daten wie Anmeldedaten, Browser-Passwörter und Cookies gestohlen
  • Selbst wenn GitHub die meisten Forks automatisch löscht, bleiben nicht erkannte Repositories und manuell hochgeladene Kopien bestehen; selbst wenn nur 1 % überlebt, bleiben Tausende bösartige Repositories erhalten
  • Der Angriffsablauf verlagert sich von bösartigen PyPI-Paketen zu GitHub-Repositories, wodurch auch die Software-Lieferkette außerhalb von Paketmanagern zu einer direkten Angriffsfläche wird

Funktionsweise des Repository-Verwechslungsangriffs

  • Repository-Verwechslung ähnelt Dependency Confusion insofern, als Benutzer dazu verleitet werden, statt des legitimen ein bösartiges Repository herunterzuladen
  • Der Unterschied liegt im Ausnutzungspunkt
    • Dependency Confusion nutzt die Funktionsweise von Paketmanagern aus
    • Repository-Verwechslung beruht darauf, dass Menschen versehentlich ein ähnlich aussehendes Repository falsch auswählen
  • Diese Kampagne erhöht die Infektionswahrscheinlichkeit, indem sie bösartige Repositories massenhaft auf GitHub verbreitet
    • Vorhandene Repositories wie TwitterFollowBot, WhatsappBOT, discord-boost-tool, Twitch-Follow-Bot werden kopiert
    • In die Kopien wird ein Malware-Loader eingefügt
    • Anschließend werden sie unter demselben Namen erneut auf GitHub hochgeladen
    • Jedes Repository wird automatisiert tausendfach geforkt
    • In Foren und auf Discord werden sie verdeckt beworben

Ablauf nach dem Ausführen eines bösartigen Repositories

  • Wenn ein Benutzer ein bösartiges Repository verwendet, entschlüsselt der versteckte Payload eine 7-stufige Verschleierung
  • Danach werden schädlicher Python-Code und binäre ausführbare Dateien nachgeladen
  • Der Schadcode basiert überwiegend auf einer modifizierten Version von BlackCap-Grabber
  • Gesammelt werden Anmeldeinformationen verschiedener Apps, Browser-Passwörter und Cookies sowie andere vertrauliche Daten
  • Die exfiltrierten Daten werden an den C&C-Server (command-and-control) der Angreifer übertragen, worauf weitere bösartige Aktivitäten folgen
  • Eine Analyse des zugehörigen Codes findet sich in der technical analysis von Trend Micro

Automatische Löschung durch GitHub und verbleibende Repositories

  • GitHub erkennt die Automatisierung und entfernt den Großteil der geforkten Repositories schnell
  • Allerdings übersieht die Automatisierungserkennung viele Repositories, und manuell hochgeladene Repositories überleben
  • Da die Angriffskette in großem Maßstab automatisiert ist, entstehen selbst wenn nur 1 % übrig bleibt noch Tausende bösartige Repositories
  • Wer auf GitHub nach 🔥 2024 language:python sucht, kann einige derzeit verbreitete Repositories sehen
  • Rechnet man auch gelöschte Repositories mit ein, erreicht das Gesamtvolumen Millionenhöhe
    • Die Löschung erfolgt meist erst einige Stunden nach dem Upload, was die Dokumentation erschwert
    • Viele Original-Repositories bleiben bestehen, und die Löschungen zielen hauptsächlich auf die Fork-Bombe
    • Als Beispiel zeigt die Repository-Liste von Mattia69 in der Zusammenfassung Tausende Forks, die in den Fork-Details jedoch nicht erscheinen
  • Einige Nutzer forken bösartige Repositories unwissentlich und erzeugen so zusätzlich einen sekundären Social-Engineering-Netzwerkeffekt

Zeitlicher Verlauf der Kampagne

  • Mai 2023: Phylum meldet bösartige Pakete auf PyPI
    • Diese Pakete enthalten frühe Teile des aktuellen Payloads
    • Sie verbreiteten sich über in Forks populärer GitHub-Repositories wie chatgpt-api platzierte Aufrufe wie os.system("pip install package")
  • Juli–August 2023: Mehrere bösartige Repositories wurden auf GitHub hochgeladen und lieferten den Payload direkt aus, statt PyPI-Pakete nachzuladen
    • Das war eine Veränderung, nachdem PyPI die bösartigen Pakete entfernt hatte und die Aufmerksamkeit der Security-Community gestiegen war
    • Aliakbar Zahravi und Peter Girnus von Trend Micro veröffentlichten eine technische Analyse
  • November 2023 bis heute: Mehr als 100.000 Repositories mit ähnlichen bösartigen Payloads wurden entdeckt, und die Zahl steigt weiter
  • Warum diese Methode für Angreifer vorteilhaft ist, liegt auf der Hand
    • GitHub ist so groß, dass selbst Masseninstanzen im Verhältnis klein wirken und schwer zu erkennen sind
    • Anders als früher ist kein Paketmanager mehr beteiligt, sodass kein expliziter Name eines bösartigen Pakets als Indikator zurückbleibt
    • Ziel-Repositories liegen oft in kleinen Nischen mit geringer Popularität, wodurch Entwickler eher versehentlich ein bösartiges Imitat klonen

Vom Paketmanager zum SCM

  • Die Verlagerung von bösartigen PyPI-Paketen zu bösartigen GitHub-Repositories entspricht einem Muster, das über verschiedene Paketmanager und SCM-Plattformen hinweg beobachtet wurde
  • Weil sich die Security-Community stärker auf Paketmanager konzentrierte, wurde der Angriffsweg gewissermaßen an andere Orte verlegt
  • GitHub und ähnliche Plattformen erleichtern die automatische Erstellung von Konten und Repositories und bieten komfortable APIs sowie lockere Rate Limits, die sich leicht umgehen lassen
  • Da man sich zwischen unzähligen Repositories verstecken kann, ist SCM ein gutes Ziel für die verdeckte Infektion der Software-Lieferkette
  • Kampagnen mit Dependency Confusion, Schadcode in Paketregistern und die Verbreitung über SCM zeigen, dass die Sicherheit der Software-Lieferkette trotz vieler Tools und Schutzmechanismen verwundbar bleibt

Indikatoren zur Überprüfung einer Infektion

  • Im Python-Code sollte nach folgenden Mustern gesucht und jeder Treffer untersucht werden
    • exec(Fernet
    • exec(requests
    • exec(__import
    • exec(bytes
    • exec("""\nimport
    • exec(compile
    • __import__("builtins").exec(
  • Es sollte geprüft werden, ob lokal Repositories zu Social-Platform-Automatisierung, Bots oder Spielen vorhanden sind, und diese sollten entfernt werden
  • Falls sie unbedingt benötigt werden, sollten sie neu installiert werden, wobei die Herkunft sorgfältig zu prüfen oder die Ausführung in einer Sandbox vorzunehmen ist
  • Wenn die Möglichkeit besteht, dass ein Repository dieses Typs geklont wurde, sollte man davon ausgehen, dass folgende Cookies, Zugangsdaten und Schlüssel kompromittiert wurden, und entsprechend reagieren
    • Browser: Finanzdienste, E-Mail-Dienste, Krypto-Dienste, Amazon, eBay, AliExpress, Facebook, Instagram, Twitter, Youtube, Discord, TikTok, Telegram, Twitch, Steam, Yahoo, ExpressVPN, Spotify, Streaming-Dienste
    • Apps: Exodus, Atomic Wallet, Guarda, Coinomi, Ethereum
  • Eine vollständige Liste der Datei-Checksummen ist praktisch schwer handhabbar, einige gemeinsame Elemente lassen sich aber im VirusTotal graph einsehen
  • Cloudflare deaktivierte nach der Benachrichtigung die DNS-Einträge der entdeckten bösartigen Adressen

Abwehr und Reaktion

  • GitHub wurde benachrichtigt und hat die meisten bösartigen Repositories gelöscht, doch die Kampagne geht weiter
  • Angriffe, die Schadcode in die Lieferkette einschleusen wollen, verbreiten sich zunehmend
  • Es gibt viele Lösungen, die Malware auf System- und Netzwerkebene erkennen, aber die Lieferkette bleibt für Angreifer weiterhin eine große und profitable Angriffsfläche
  • Wird ein bösartiges Repository entdeckt, kann es unabhängig davon, ob es Teil dieser Kampagne ist, über GitHubs abuse or spam report gemeldet werden
  • Apiiro hat ein System zur Malware-Erkennung aufgebaut, das verbundene Codebasen überwacht
    • LLM-basierte Codeanalyse
    • Zerlegung von Code in vollständige Ausführungsflussgraphen
    • Heuristische Engine
    • Dynamisches Decoding, Entschlüsselung und Entschleierung
  • Ohne die Überwachung eingeschleuster bösartiger Payloads hängt die Sicherheit einer Organisation davon ab, dass Entwickler nicht versehentlich nahezu identische falsche Repositories auswählen, dass es keinerlei Fehler in CI/CD-Konfigurationen gibt und dass Drittanbieter-Code zu 100 % sicher ist
  • Über die allgemeine Erkennung und Sammlung von Schwachstellen hinaus ist ein Ansatz nötig, der die nächste Generation von Risiken in der Software-Lieferkette und bei Anwendungen sichtbar macht

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-03-01
Meinungen auf Hacker News

  • Über die allgemeine Warnung hinaus, bei Code aus öffentlichen Repositories oder externen Quellen vorsichtig zu sein und den Dependency Tree zu prüfen, frage ich mich, welche Auswirkungen es auf LLMs und Automatisierungstools hat, wenn öffentliche Repositories massenhaft Schadcode enthalten und diese Modelle darauf trainiert wurden.
    Es scheint durchaus möglich, dass bei Tools wie Copilot in längeren Code-Antworten zufällig schädliche Teile mit hineingeraten.
    Einfache Injection-Schwachstellen sieht man ja schon häufig.

    • Mehr als dass zufällig eine Backdoor in LLM-Ausgaben landet, mache ich mir Sorgen, dass Nachrichtendienste Backdoors in LLM-Ausgaben einschleusen.
      Vielleicht noch nicht jetzt, aber in ein paar Jahren wirkt das durchaus möglich.
    • LLMs werden wohl nicht nur anfälligen Code aus ihren Eingabedaten einfügen, sondern auch selbst neue Schwachstellen erzeugen.
      KI gibt keinerlei Garantie für Korrektheit.
    • Ich habe gerade ein LLM-bezogenes Problem gepostet, bei dem der safetensors-Konvertierungs-Bot von Hugging Face übernommen wird: https://news.ycombinator.com/item?id=39549482
      Es wurde gezeigt, dass ein Angreifer einen Service-Bot übernehmen kann, der mit dem Hugging-Face-Safetensors-Konvertierungs-Space verbunden ist; das ist ein beliebter Dienst im Ökosystem, der unsichere Machine-Learning-Modelle in sicherere Versionen konvertiert.
    • Das Risiko ist real, aber es ähnelt dem Risiko, dass beim ungeprüften Akzeptieren eines PRs von Kollegen irgendwo kopierter anfälliger Code hineinkommt.
      Wer LLMs nutzt, muss mehr Aufwand in Code Reviews investieren, und ich halte diesen Kompromiss für lohnend.
    • Die Zahl der in dieser Kampagne entdeckten Samples ist so groß, dass das Risiko realistischer ist, als man denkt.
      Allerdings gibt es meist zwei Hürden, bevor daraus ein tatsächlicher Vorfall wird: Der Generator erhält interne Anweisungen, solchen Code zu vermeiden, und aufgrund der Eigenschaften von LLMs ist es unwahrscheinlich, dass sie die Adresse eines realen Angreifers exakt wiederholen.
      Trotzdem bleiben verschiedene Angriffsvektoren wie Bind Shells, Denial of Service oder Exfiltration vor Ort bestehen.

  • GitHub scheitert auf ähnliche Weise, wie Usenet gescheitert ist.
    Jeder kann ein Repository erstellen, und es gibt nichts, das offizielle Repositories von Spam-Repositories unterscheidet.
    So wie Amazon das Ziel hatte, „der Laden für alles“ zu sein, dann aber von „90 % von allem ist Müll“ getroffen wurde und zu einem Laden wurde, der größtenteils aus Müll besteht, muss GitHub entscheiden, ob sein Produkt „Repositories für alle“ oder „vertrauenswürdiger Code“ ist.
    Beim offiziellen PG JDBC zum Beispiel sehe ich nichts, was ein Spammer nicht nachbilden könnte. Wie kann man also darauf vertrauen, dass dies kein infiziertes Repository ist: https://github.com/pgjdbc

    • GitHub scheint sich schon vor 16 Jahren, als das Unternehmen gegründet wurde, für Repositories für alle entschieden zu haben.
    • Eine Java-Bibliothek lädt man normalerweise nicht von GitHub herunter, sondern aus Maven Central.
      Sonatype verlangt einen Nachweis des Besitzes der Reverse-Domain, die in der groupId verwendet wird; in diesem Fall ist das org.postgresql.
      Die Anleitung steht hier: https://central.sonatype.org/faq/how-to-set-txt-record/
      Wenn man noch mehr Sicherheit will, kann man auch die GPG-Signaturen prüfen, da alle in Maven Central veröffentlichten Artefakte signiert sind; der Nachteil ist allerdings, dass man den von Postgres für die Signatur verwendeten Schlüssel über einen von Sonatype unabhängigen Weg beziehen muss.
      Im Fall von PG habe ich den Schlüssel bei einer schnellen Suche nicht gefunden.
    • Ich glaube, man hat kein richtiges Gefühl dafür, wie klein diese Zahl ist.
      GitHub hat etwa 500 Millionen Repositories, daher ist diese Größenordnung tatsächlich ziemlich gut.
    • Mehr als 100.000 infizierte Repositories sind nicht gut, aber das bedeutet nicht, dass GitHub gescheitert ist.
      Ein Entwickler, der ein infiziertes Repository verwenden würde, findet auch ohne solche Repositories auf GitHub genügend andere Wege, ein unsicheres Produkt zu bauen.
    • Wenn man den Domainbesitz nachweist, kann man auf der Organisationsseite ein Verifizierungs-Badge erhalten, was die Vertrauenswürdigkeit deutlich erhöht.
      Die als Beispiel genannte Organisation scheint das einfach nicht getan zu haben.

  • Supply-Chain-Probleme sind wirklich ein Albtraum
    Wir zielen zwar nicht direkt auf npm-Releases ab, erstellen aber npm-Releases, um mit socket.dev ein leichtgewichtiges Virtualisierungs-Webbrowser-Projekt namens BrowserBox zu überwachen
    Auch dieses Projekt nutzt inklusive aller transitiven Abhängigkeiten etwa 800 Pakete und nur 19 direkte Abhängigkeiten; bezogen auf den gesamten Stack ist es damit vergleichsweise leichtgewichtig
    Ich überlege nun, alle 800 Abhängigkeiten im npm-Namespace @browserbox als Snapshots abzulegen und gefundene Schwachstellen nachzuverfolgen und zu patchen
    Das klingt verrückt, aber so ist die Lage nun einmal; zumindest könnte man damit die Supply-Chain-Schwachstellen auf der Node/JS-Seite direkt auf dem Sicherheitsniveau des Unternehmens garantieren
    https://socket.dev
    https://github.com/BrowserBox/BrowserBox

    • Ich weiß nicht, wie viel davon npm bietet, aber crates.io und cargo haben Tools wie cargo audit und cargo deny, die in der Pipeline CVEs im Dependency-Tree prüfen
      Da die Lock-Datei den sha256 des gesamten Trees festhält, muss man nicht spiegeln, nur um Änderungen zu verhindern, selbst wenn das Repository gehackt wird
      Auf Versionen zu pinnen, die ein paar Monate hinter der neuesten liegen, scheint ein guter Kompromiss zu sein: neue CVEs vermeiden, ohne auf so alten Versionen festzusitzen, dass man später alles auf einmal groß reparieren muss
      Die Download-Zahlen wirken als Maßstab ganz brauchbar, wenn man sie mit direkten Abhängigkeiten für ähnliche Zwecke vergleicht, aber das ist eine subjektive Einschätzung
      Austral vergibt mit linearen Typen feingranulare Berechtigungen an Abhängigkeiten
      Etwa: Eine Grafikbibliothek braucht keinen Datei-I/O, und eine Bibliothek für Netzwerkübertragung braucht keinen Zugriff aufs Mikrofon
      Das ist nur eine Abmilderung, aber ich würde so etwas gern auch in anderen Sprachen sehen
    • Die Formulierung „nur etwa 800 Abhängigkeiten“ ist leicht gruselig
      Als ich vor rund 10 Jahren von .NET zu Java wechselte, war ich überrascht, wie viel mehr Zeit in Dependency Hell floss; heute ist der Aufwand für Sicherheitsupdates und Dependency-Probleme sowohl in Java- als auch in Python-Projekten erschreckend hoch
      Dass dieses Problem bei .NET weniger ausgeprägt war, lag wohl daran, dass automatisches Paketmanagement dort relativ spät eingeführt wurde und auch NuGet noch recht jung war; damals hatten viele Projekte es noch nicht übernommen, und es gab eine starke Kultur, riesige transitive Dependency-Trees zu vermeiden
      Die jüngsten Probleme bei Boeing wirken ähnlich
      In den vergangenen Jahrzehnten wurde immer mehr Produktion an externe Zulieferer ausgelagert und auf Kostenoptimierung fokussiert, wodurch Supply-Chain-Management immer schwieriger wurde; im großen Bild ähnelt das der Supply-Chain-Kultur moderner Softwareentwicklung
      Als ich bei einem Finanzunternehmen arbeitete, das Paketmanager aus Gründen der Supply-Chain-Sicherheit verboten hatte, war Dependency-Management am wenigsten lästig und es gab auch die wenigsten Qualitätsprobleme
      Code, der sich nie ändert, solange man ihn nicht ausdrücklich ändert, hat Vorteile
      Vieles, wofür andere Pakete herangezogen hätten, haben wir selbst implementiert; weil wir nur das Nötige taten und höhere Code-Standards anlegten, war es leichter zu verstehen, zu debuggen und zu ändern
      Die anfänglichen Kosten beim Schreiben fallen einmalig an und amortisieren sich gut, aber die wiederkehrenden Kosten für Code, der für alle alles tun will, werden langfristig größer und häufen sich meist an
      Rich Hickeys „Simple Made Easy“ zeigt dieses Phänomen gut: Einfach und leicht sind nicht dasselbe, und die einfache Option wirkt anfangs zwar schwerer, wird aber langfristig leichter, wenn sich die Zweitrundeneffekte aufsummieren

  • Mir war so etwas schon aufgefallen, als ich zufällig auf ähnliche Repositories stieß
    Ich führe ohnehin nicht einfach Code aus beliebigen Repositories aus, aber inzwischen starte ich selbst dann eine Sandbox-VM, wenn ich dem Repository und dem Besitzer vertraue
    Als Entwickler sollte man heute Arbeit, Hobby und Privates wohl mindestens sauber in drei Umgebungen trennen

    • Allein die Aussage, dass Entwickler Arbeits-, Hobby- und Privatumgebungen trennen sollten, zeigt, wie sehr die Komplexität des digitalen Lebens gewachsen ist – bis zu dem Punkt, an dem man zweifeln kann, ob das langfristig nachhaltig ist
    • Mit jedem Jahr wirkt Qubes wie die vernünftigere Wahl
    • Ich mache das inzwischen ebenfalls, und zwar nicht nur wegen potenziell bösartiger Software
      Es gibt Projekte, die zwar nicht bösartig sind, aber vom Design her schlampig oder töricht geschrieben wurden
      Ein Programm, das ich vor Kurzem ausgeführt habe, fügte meiner ~/.bashrc drei Zeilen hinzu, noch bevor ich überhaupt irgendetwas angefordert hatte; ich bemerkte es erst ein paar Tage später
      Ich kann nicht verstehen, welcher Entwickler das für eine gute Idee hält, und deshalb nutze ich inzwischen jedes Mal eine Sandbox, wenn ich fremden Code ausführe
    • Klingt nach einem guten Grund, Qubes OS zu nutzen, wo grundsätzlich alles in einer VM läuft
      Das ist mein Alltags-OS
    • Arbeits- und Privatumgebung nicht zu vermischen, ist doch eigentlich absolute Basis, oder?
      Gibt es wirklich Arbeitgeber, die so etwas erlauben?

  • Ich bin neugierig, welche Tools ihr bei der Arbeit nutzt, um solche Probleme zu vermeiden, und ob ihr mit eurer aktuellen Konfiguration zufrieden seid.
    Wir entwickeln mit einem ziemlich kleinen Team ein SDK mit vielen wöchentlichen Downloads und haben Lösungen auf Basis von snyk, aikido.dev, renovate usw. evaluiert, aber es ist nicht klar, ob sie bei solchen Problemen helfen.
    Da wir noch ein kleines Team sind, ist es auch belastend, Tools mit vielen False Positives wie snyk zu betreuen.

    • Statt GitHub-Repositories direkt zu verwenden, nutzen wir öffentliche Pakete aus üblichen Paket-Repositories wie NuGet, PyPI und npm und setzen Sonatypes Repository und Firewall als Proxy zwischen uns und die Paket-Repositories.
      Sonatype analysiert alle Pakete, versieht sie mit diversen Metadaten und definiert Richtlinien, die in der Firewall genutzt werden können, um den Rest herauszufiltern.
      Das funktioniert nur für öffentliche Abhängigkeiten, aber nach einigen Jahren Nutzung funktioniert es ziemlich gut.
      Bisher hatten wir keine Malware-Probleme; Pakete mit bekannten Schwachstellen kommen nicht in die Codebasis, und wenn in etwas, das wir nutzen, eine Schwachstelle gefunden wird, werden wir benachrichtigt.
    • Wir verwenden bei der Arbeit Semgrep Supply Chain und sind ziemlich zufrieden.
      Es teilt gefundene Supply-Chain-Schwachstellen in erreichbar, nicht erreichbar und unklar ein, was die Triage viel einfacher gemacht und die Zeit zur Bewertung neuer Schwachstellen deutlich reduziert hat.
    • In diesem Unterthread werden Malware und Schwachstellen offenbar oft verwechselt.
      Die genannten Anbieter erkennen keinen bösartigen Code, sondern nur Schwachstellen.
      Selbst wenn die Schwachstellenerkennung gut ist, schützt sie euch weiterhin nicht vor in die Codebasis eingeschleustem bösartigem Code.
    • Ich arbeite an Packj, einem Open-Source-Tool zur Erkennung riskanter PyPI-/NPM-/Ruby-/PHP-/Maven-/Rust-Pakete, darunter öffentlich bekannte bösartige Pakete, verwaiste Pakete und Typosquatting-Pakete.
      Es führt statische, dynamische und Metadaten-Analysen durch und prüft mehr als 40 Eigenschaften wie Shell-Ausführung, Nutzung von SSH-Schlüsseln, Netzwerkkommunikation und die Verwendung von decode+eval, um riskante Pakete zu markieren.
      https://github.com/ossillate-inc/packj
    • Trivy ist einen Blick wert.
      Bisher hat es ziemlich gut funktioniert.
      https://trivy.dev/

  • Ich frage mich, ob die Praxis, Shell-Installationsskripte per curl herunterzuladen und mit sudo auszuführen, bald ein Ende findet.
    Ein Ansatz wie „Um unsere Software zu installieren, führen Sie curl [https://somesite/install.sh](<https://somesite/install.sh>;)' | sudo sh aus“ scheint sehr gut zu dem im Artikel erwähnten infizierten Code zu passen.

    • Als Autor dieser Studie kann ich das bestätigen.
      Unser System listet jede Woche etwa 100 der erwähnten Muster auf, und davon sind rund 3 % bösartig.
      Ich würde gerne sehen, dass diese Praxis endet.
    • Leider hat npm i dieselben Berechtigungen.
      Unter den heute gängigen Tools zum Herunterladen von Abhängigkeiten kenne ich nur go get, bei dem zur Installations- oder Build-Zeit kein feindlicher Code ausgeführt wird.
      Wir brauchen zumindest bessere Tools, um in einer Sandbox zu arbeiten, damit die Explosion eingegrenzt bleibt.
      Der Ansatz von ChromeOS, bei dem „eine virtuelle Maschine Wayland-Fenster auf dem Haupt-Desktop öffnen kann“, ist elegant, aber als ich mir den Code zuletzt angesehen habe, war er nicht besonders sauber oder wiederverwendbar.
    • Für solche Beispiele sollte man example.com verwenden.
      Diese Domain ist für genau diesen Zweck reserviert: https://www.rfc-editor.org/rfc/rfc2606.html#section-3
    • Es ist nicht wirklich schlechter als die realistischen Alternativen: „Fügen Sie ein Repository für Ihre Distribution hinzu und vertrauen Sie ihm“, „laden Sie eine .deb/.rpm/einen Installer herunter“ oder, im schlimmsten Fall, „vertrauen Sie etwas, das nicht vom Herausgeber, sondern von Dritten paketiert wurde“.

  • In npm kann man die Ausführung von Malware mit --ignore-scripts abmildern.
    https://blog.uirig.com/getting-rid-of-npm-scripts

    • Stattdessen kann der heruntergeladene bösartige Code in der Produktionsumgebung ausgeführt werden.
      Mit Glück verhält er sich in CI auffällig und wird entdeckt.
      Die eigentliche Lösung wäre ein Reputationssystem wie https://github.com/crev-dev/cargo-crev, aber leider wird so etwas kaum genutzt.
    • Aus Sicherheitssicht sollte das der Standard sein.
      Auch der Kommentar, dass man ein Makefile braucht, ist beachtenswert.

  • Solche Berichte tauchen immer wieder auf, und in den letzten Monaten verbessere ich die Sicherheit meiner Entwicklungsumgebung Schritt für Schritt.
    Ich nutze VSCode dev containers für die Entwicklung: https://code.visualstudio.com/docs/devcontainers/create-dev-...
    Einmal eingerichtet, sind sie auch ohne viel Docker-Wissen leicht zu verwenden und gut geeignet, um Web-/Konsolen-Apps zu starten; Dinge wie Flutter oder Electron waren aber schwierig.
    An GitHub Codespaces habe ich mich bei kleinen Projekten ebenfalls gewöhnt: https://github.com/codespaces
    Früher hatte ich in einem Vorstellungsgespräch einmal Live-Coding, bei dem ein einfaches Node-Projekt geändert werden sollte; heute würde ich in so einer Situation sicher Container oder Codespaces nutzen: https://www.welivesecurity.com/en/eset-research/lazarus-luri...
    Best Practices für npm, Node und Docker setze ich um, indem ich regelmäßig die OWASP-Leitlinien lese und bei Docker nach Möglichkeit kleine Images sowie explizite Image-Tags verwende: https://cheatsheetseries.owasp.org/cheatsheets/NodeJS_Docker...
    Bei npm-/Python-Paketen prüfe ich vor der Installation mit socket.dev den Zugriff auf Umgebungsvariablen, Netzwerkaufrufe, Supply-Chain-Angriffe und jüngste Änderungen an der Code-Eigentümerschaft; außerdem kann man, wie von OWASP empfohlen, postinstall-Skripte global deaktivieren: https://cheatsheetseries.owasp.org/cheatsheets/NPM_Security_...

  • Vor weniger als einem Jahr gab es einen Fall mit einem Repository, das einen Trojaner enthielt: https://github.com/orgs/community/discussions/63603

    • Das Repository behauptete, ein Passwort-Stealer zu sein; wenn man es heruntergeladen, entpackt hat und es dann persönliche Daten und Dateien gestohlen hat, sehe ich das Problem nicht.
      Es hat im Grunde genau das getan, was das Repository behauptet hat.

  • Schon eine einfache Kennzeichnung als offizielles Repository könnte eine gewisse Aufmerksamkeit erzeugen.

    • Vielleicht beginnt GitHub später sogar, diesen blauen Haken zu verkaufen.
      Was soll da schon passieren /s
      Trotzdem stimme ich zu, dass GitHub besser sichtbar machen sollte, welches Repository das offizielle Repository eines Projekts ist.