Rust Supply-Chain-Angriff zielt auf arrayref, internment und append-only-vec ab

Zusammenfassung

Ein ausgeklügelter Supply-Chain-Angriff zielte auf das Rust-Ökosystem ab, indem ein legitimes Maintainer-Konto kompromittiert und eine Typosquatting-Identität verwendet wurde, um bösartige Build-Time-Abhängigkeiten einzuschleusen. Die Angreifer vergifteten drei weit verbreitete Crates, arrayref, internment, und append-only-vec, um während des Cargo-Build-Prozesses einen Remote-Codeausführungs-Dropper auszuführen. Dies ermöglichte eine stille Codeausführung auf Entwickler-Arbeitsstationen und CI/CD-Pipelines während der Routinekompilierung.

Untersuchung

Forscher analysierten den Angriff mithilfe von Harden-Runner, das das bösartige Build-Skript erfasste, das versuchte, über Port 9089 eine ausgehende Verbindung zu einem Payload-Server herzustellen. Die forensische Überprüfung des crates.io-Index Git-Verlaufs zeigte eine gezielte Einfügung bösartiger Abhängigkeiten und ein Yank-and-Upgrade-Lockmittel, das Entwickler dazu verleiten sollte, auf kompromittierte Versionen zu wechseln. Forscher identifizierten auch sekundäre Persistenzmechanismen und C2-Verhalten, das von betroffenen Nutzern berichtet wurde.

Minderung

Sofortige Minderung umfasst das Fixieren legitimer Crates auf verifizierte sichere Versionen und das Auditieren von Cargo.lock -Dateien auf kompromittierte Abhängigkeitsveröffentlichungen. Organisationen sollten lokale und CI/CD-Caches, einschließlich ~/.cargo/registry/cache, löschen, um bösartige .crate -Dateien zu entfernen. Ausgehender Filterung für ungewöhnliche Verbindungen aus Build-Umgebungen und strikte Sperrfile-Disziplin sind ebenfalls kritische langfristige Abwehrmaßnahmen.

Reaktion

Wenn betroffene Versionen in einer Sperrdatei gefunden werden, sollte die Build-Umgebung als kompromittiert angesehen werden, und alle zugänglichen Anmeldeinformationen, einschließlich SSH-Schlüssel, Cloud-Token und CI/CD-Geheimnisse, sollten rotiert werden. Entwickler-Systeme sollten auf Persistenz-Artefakte wie unbefugte systemd-Dienste oder verdächtige Dateien in Konfigurationsverzeichnissen überprüft werden. Alle während des Expositionszeitraums hergestellten Software-Artefakte sollten aus sauberen, verifizierten Quellen neu erstellt werden.

Simulation der Ausführung

Voraussetzung: Der Telemetrie- & Basis-Pre-Flight-Check muss bestanden sein.

Begründung: Dieser Abschnitt beschreibt die präzise Ausführung der gegnerischen Technik (TTP), die darauf abzielt, die Erkennungsregel auszulösen. Die Befehle und das Narrativ MÜSSEN die identifizierten TTPs direkt widerspiegeln und darauf abzielen, die genau erwartete Telemetrie zu erzeugen, die von der Erkennungslogik erwartet wird. Abstrakte oder nicht verwandte Beispiele führen zu Fehldiagnosen.

• Angriffserzählung & Befehle: Der Angreifer hat erfolgreich ein bösartiges Crate in ein Rust-Projekt eingeschleust. Wenn der Build-Prozess gestartet wird, führt das build.rs -Skript einen Hintergrundthread aus, der versucht, eine Verbindung zu einem entfernten C2-Server auf Port 9089 herzustellen, um eine Nutzlast abzurufen. Dies simuliert die „Anomale ausgehende Netzwerkverbindung“, die in der Regel beschrieben wird. Das Ziel ist es, den Firewall-/Netzwerk-Protokoll-Alarm auszulösen, indem der spezifische Port 9089.

• Regressionstest-Skript:

  # Simulieren eines Build-Zeit-Droppers, der versucht, eine Verbindung zu einem C2-Server auf Port 9089 herzustellen
  # Wir verwenden einen TCP-Client, um den Netzwerkverbindungsversuch zu simulieren.
  
  $C2_IP = "127.0.0.1" # Localhost, um tatsächlichen externen Traffic während des Tests zu vermeiden
  $C2_PORT = 9089
  
  Write-Host "Simulierung von Netzwerkaktivität während des Build-Prozesses..." -ForegroundColor Cyan
  try {
      $client = New-Object System.Net.Sockets.TcpClient
      $beginConnect = $client.BeginConnect($C2_IP, $C2_PORT, $null, $null)
      $success = $beginConnect.AsyncWaitHandle.WaitOne(1000, $false)
  
      if ($success) {
          Write-Host "Verbindung erfolgreich! Telemetrie sollte generiert worden sein." -ForegroundColor Green
          $client.EndConnect($beginConnect)
      } else {
          Write-Host "Verbindung fehlgeschlagen (erwartet, wenn kein Listener aktiv ist), aber die Telemetrie sollte immer noch den Versuch anzeigen." -ForegroundColor Yellow
      }
      $client.Close()
  } catch {
      Write-Host "Fehler während der Simulation: $($_.Exception.Message)" -ForegroundColor Red
  }

• Bereinigung von Befehlen:

  # Keine dauerhaften Änderungen durch das Skript vorgenommen; jedoch sicherstellen, dass alle lokalen Listener gestoppt werden.
  # Wenn ein Listener zum Testen gestartet wurde, verwenden Sie:
  Stop-Process -Name "nc" -ErrorAction SilentlyContinue
  Write-Host "Bereinigung abgeschlossen." -ForegroundColor Green