Mehr als 100.000 infizierte Repositories auf GitHub entdeckt

Mehr als 100.000 infizierte Repositories auf GitHub entdeckt

• Ein Team für Sicherheitsforschung und Data Science hat festgestellt, dass eine bösartige Repository-Confusion-Kampagne, die Mitte letzten Jahres begann, in großem Maßstab wieder aufgetaucht ist.
• Dieser Angriff betrifft mehr als 100.000 GitHub-Repositories (und schätzungsweise Millionen weitere), wenn Entwickler Repositories verwenden, die bekannten vertrauenswürdigen Repositories ähneln, tatsächlich aber bösartigen Code enthalten.

Wie funktionieren Repository-Confusion-Angriffe?

• Repository-Confusion-Angriffe ähneln Dependency-Confusion-Angriffen, indem bösartige Akteure dafür sorgen, dass das Ziel statt der echten Version eine bösartige Version herunterlädt.
• Während Dependency-Confusion-Angriffe die Funktionsweise von Paketmanagern ausnutzen, beruhen Repository-Confusion-Angriffe darauf, dass Menschen versehentlich statt der echten Version die bösartige auswählen; manchmal kommen dabei auch Social-Engineering-Techniken zum Einsatz.

Was passiert, wenn ein bösartiges Repository verwendet wird?

• Wenn Entwickler arglos ein bösartiges Repository verwenden, entschlüsselt eine versteckte Payload sieben Stufen der Obfuskation und lädt bösartigen Python-Code sowie anschließend eine binäre ausführbare Datei nach.
• Die Malware sammelt Anmeldeinformationen verschiedener Apps, Browser-Passwörter und Cookies sowie weitere vertrauliche Daten, sendet sie an den C&C-Server des Angreifers und führt zusätzliche bösartige Aktivitäten aus.

Auswirkungen der Automatisierung auf GitHub

• Die meisten geforkten Repositories werden von GitHub schnell entfernt, doch die automatisierte Erkennung übersieht viele Repositories, und manuell hochgeladene Repositories überleben.
• Da die gesamte Angriffskette im großen Maßstab weitgehend automatisiert ist, bedeuten selbst die verbleibenden 1 % noch immer Tausende bösartiger Repositories.

Wann die Kampagne begann

• Mai 2023: Laut dem ersten Bericht von Phylum wurden mehrere bösartige Pakete auf PyPI hochgeladen, darunter frühe Teile der aktuellen Payload.
• Juli–August 2023: Nachdem PyPI die bösartigen Pakete entfernt hatte und die Sicherheits-Community dort stärker hinsah, wurden mehrere bösartige Repositories auf GitHub hochgeladen, die die Payload diesmal direkt auslieferten, anstatt PyPI-Pakete nachzuladen.
• November 2023 – heute: Mehr als 100.000 Repositories mit ähnlichen bösartigen Payloads wurden erkannt, und ihre Zahl steigt weiter.

Verlagerung von Malware von Paketmanagern zu Source Code Management (SCM)

• Viele Vorfälle, die auf Paketmanagern und SCM-Plattformen beobachtet wurden, deuten darauf hin, dass der Wechsel dieser Kampagne von bösartigen Paketen auf PyPI zu bösartigen Repositories auf GitHub einen allgemeinen Trend widerspiegelt.

Wie man sich vor Repository Confusion schützt

• GitHub wurde informiert und hat die meisten bösartigen Repositories gelöscht, doch die Kampagne dauert an, und Angriffe, die bösartigen Code in die Supply Chain einschleusen wollen, werden immer häufiger.
• Apiiro hat ein Malware-Erkennungssystem aufgebaut, das verbundene Codebases überwacht.
• Zur Angriffserkennung werden verschiedene fortgeschrittene Techniken eingesetzt, darunter LLM-basierte Codeanalyse, die Zerlegung von Code in vollständige Execution-Flow-Graphen, eine ausgefeilte heuristische Engine sowie dynamisches Decoding, Entschlüsselung und Deobfuskation.

Meinung von GN⁺

• Dieser Artikel liefert Entwicklern wichtige Informationen über Sicherheitsbedrohungen, auf die sie bei der Nutzung von GitHub-Repositories achten sollten.
• Wenn Entwickler und Sicherheitsexperten verstehen, wie Malware in die Software Supply Chain eindringt, können sie stärkere Abwehrmechanismen aufbauen.
• Solche Angriffe unterstreichen nicht nur, wie wichtig die Fähigkeit ist, vertrauenswürdige Repositories auszuwählen, sondern auch, wie stark man auf die Korrektheit von CI/CD-Konfigurationen und die Sicherheit von Third-Party-Code angewiesen ist.
• Aus kritischer Perspektive zeigen diese Angriffe, dass die automatisierten Systeme von Plattformen wie GitHub und die Existenz riesiger Repository-Bestände ein zweischneidiges Schwert sein können.
• Ähnliche Security-Tools sind etwa SonarQube, Snyk und WhiteSource; sie können helfen, Schwachstellen im Code zu erkennen und die Sicherheit zu verbessern.
• Vor der Einführung dieser Technologie sollten Organisationen ihre Kompatibilität mit den eigenen Sicherheitsrichtlinien, die Implementierungskosten und die technischen Fähigkeiten der Teammitglieder berücksichtigen.
• Zu den Vorteilen dieser Technologie gehören mehr Sicherheit und geringeres Risiko; mögliche Nachteile sind jedoch die Lernkurve für neue Systeme und die höhere Komplexität im Betrieb.

[GN⁺]

Hacker-News-Kommentare

• Beim Übernehmen von Code aus öffentlichen Repositories ist Vorsicht geboten, und es ist wichtig, den Abhängigkeitsbaum zu überprüfen. Das wirft die Frage auf, welche Auswirkungen Malware in öffentlichen Repositories auf automatisierte Tools wie Sprachmodelle (Large Language Models, LLMs) haben könnte. So könnten Tools wie GitHub Copilot versehentlich Malware in Antworten auf Coding-Fragen einbauen.
• Es wird darauf hingewiesen, dass GitHub auf ähnliche Weise scheitert wie einst Usenet. Jeder kann auf GitHub ein Repository anlegen, und es gibt keine Möglichkeit, offizielle Repositories von denen von Spammern zu unterscheiden. Als Amazon das Ziel verfolgte, ein „Laden für alles“ zu sein, stand das Unternehmen vor dem Problem, dass die meisten Produkte Müll waren. GitHub muss klären, ob es ein „Repository für alle“ sein will oder ob seine Identität darin liegt, die Frage „Kann ich diesem Code vertrauen?“ zu beantworten.
• Es wird beklagt, dass Supply-Chain-Probleme gravierend sind. Zwar zielt man nicht auf npm-Releases ab, nutzt aber socket.dev für das Projekt-Monitoring. Das BrowserBox-Projekt verwendet etwa 800 Abhängigkeiten, davon sind 19 direkte Abhängigkeiten. Es wird erwogen, alle Abhängigkeiten in den npm-Namespace @browserbox zu snapshotten, um Schwachstellen nachzuverfolgen und Patches einzuspielen.
• Es wird betont, dass Entwickler mindestens drei getrennte Umgebungen für Arbeit, Hobbys und Privates haben sollten. Selbst bei vertrauenswürdigen Repositories und Eigentümern ist es klug, Code in einer Sandbox-VM auszuführen.
• Wer in einem kleinen Team ein SDK mit vielen wöchentlichen Downloads entwickelt, prüft derzeit Lösungen auf Basis von snyk, aikido.dev, renovate usw. Es ist nicht klar, ob diese Tools das Problem wirklich lösen helfen, und der Umgang mit vielen False Positives ist schwierig, wie die Erfahrung mit snyk zeigt.
• Es wird die Frage gestellt, ob die Installation per Shell-Skript mit curl und sudo bald ein Ende haben wird. Diese Methode steht in engem Zusammenhang mit der im Artikel erwähnten infizierten Software.
• In npm kann die Ausführung von Malware mit der Option --ignore-scripts verhindert werden.
• Es wird erwähnt, dass es vor weniger als einem Jahr Repositories mit Trojanern gab.
• Kritisiert wird, dass aktuelle Beiträge zu Sicherheitsproblemen in Werbung dafür münden, LLM-Startups zu finanzieren. Diese Startups können nur einen Teil der Sicherheitslücken adressieren, und Verträge mit vielen verschiedenen Startups können Kosten- und Integrationsprobleme verursachen.
• Aufgrund der fortlaufenden Sicherheitsberichte wird die Sicherheit der Entwicklungsumgebung schrittweise verbessert. Ausprobiert werden VSCode Development Containers, GitHub Codespaces, das Lesen der OWASP-Richtlinien sowie Reviews von npm-/Python-Paketen mit socket.dev.