Mobile-Menu

Analyse von Sysdig So werden Self-hosted GitHub Actions Runner als Backdoors missbraucht

Quelle: Pressemitteilung 4 min Lesedauer

Anbieter zum Thema

Fsas Technologies GmbH
FTAPI Software GmbH

Sysdig analysierte den schwerwiegenden „Shai Hulud“-Lieferkettenvorfall und zeigt auf, wie die Malware Self-hosted GitHub Actions Runner als versteckte Backdoors nutzt. Mit dieser Methode erhält sie unentdeckt dauerhaften Zugriff auf Netzwerke.

Self-hosted GitHub Actions Runner eignen sich aufgrund ihrer Eigenschaften – wie der Fähigkeit, beliebigen Code auszuführen und persistenten Zugriff auf interne Netzwerke zu bieten – für Angreifer perfekt, um dort Backdoors zu verstecken.(Bild: oz - stock.adobe.com)
Self-hosted GitHub Actions Runner eignen sich aufgrund ihrer Eigenschaften – wie der Fähigkeit, beliebigen Code auszuführen und persistenten Zugriff auf interne Netzwerke zu bieten – für Angreifer perfekt, um dort Backdoors zu verstecken.
(Bild: oz - stock.adobe.com)

Die Entdeckung von „Shai Hulud“, einer Malware im npm-Ökosystem, die sich selbst repliziert und schwer zu erkennen ist, hat die JavaScript Community erschüttert. Cybersi­cher­heits­ex­per­tinnen und -experten sind sich einig, das Shai Hulud erst der Anfang einer neuen Ära von Supply-Chain-Würmern ist. Aus diesem Grund hat sich das Forschungsteam von Sysdig ge­nauer angesehen, wie solche Würmer als Backdoors eingesetzt werden.

Self-hosted Runner sind ideal für Backdoors

Beim Einsatz solcher Supply-Chain-Würmer wie Shai Hulud ist das Ziel der Angreifer, sich dauerhaften Zugriff auf fremde Netzwerke zu verschaffen. Der Untersuchung von Sysdig zufolge, bleiben sie dabei von klassischen Network-Detection-Lösungen meist unentdeckt. Konkret hat der Hersteller untersucht, wie Bedrohungsakteure self-hosted GitHub Actions Runner missbrauchen, um persistenten Remote-Zugriff aufzubauen.

Da self-hosted Runner, als Programme oder Instanzen, die in der Continuous-Integration/Continuous-Deployment-Umgebungen (CI/CD) verwendet werden, um automatisierte Auf­gaben auszuführen, auf der Infrastruktur der Organisation laufen, eignen sie sich den For­schern zufolge perfekt, um dort Backdoors zu platzieren. Denn die self-hosted Runner würden oft Zugriff auf interne Netze und potenziell gecachte Secrets oder Credentials bieten.

Zudem seien self-hosted Runners in der Regel so konzipiert, dass sie jeden Code ausführen können, der in den GitHub Actions Workflows definiert ist. Zwar hätten User so die vollständige Kontrolle darüber haben, welche Skripte und Kommandos auf diesen Runnern ausgeführt werden. Dies kann laut Sysdig jedoch auch zum Sicherheitsrisiko werden, wenn der Runner Opfer eines Cyberangriffs wird. Ein weiterer Grund, warum self-hosted Runners beliebte Ziele für Angreifer seien, liege daran, dass sich das Onboarding von

GitHub Actions sich auf einen sogenannten „low friction“-Prozess beziehe. Dies bedeute, dass das Onboarding absichtlich „low friction“ gestaltet wurde, sodass Nutzer mit nur dem Befehl „./config.sh“ und einem Registrierungstoken schnell einen neuen Runner einrichten könnten, was eine langfristige Verbindung zu GitHub ermögliche. Allerdings bestehe dabei auch die Gefahr, dass Sicherheitsvorkehrungen, insbesondere im Umgang mit Administrator-Rechten der Tokens, vernachlässigt würden, da solche Tokens auch über die GitHub-API generiert werden könnten.

So wurde Shai-Hulud als Backdoor genutzt

Sysdig erläutert am Beispiel von Shai-Hulud wie dieser Wurm als Backdoor genutzt wurde. Nach der initialen Kompromittierung über npm-Pakete habe Shai-Hulud GitHub so ausgenutzt, dass ein kompromittiertes System praktisch „von innen heraus“ an die GitHub-Infrastruktur an­gebunden wurde. Dabei habe die Malware ein neues öffentliches Repository mit einem festen Marker in der Beschreibung angelegt und bewusst nur „Discussions“(ein Feature, das es Be­nut­zern ermöglicht, Ideen, Fragen oder Vorschläge innerhalb eines Repositorys zu diskutieren) als späteren Kommunikationskanal aktiviert. Anschließend habe die Malware per GitHub-API ein Runner-Registration-Token beschafft, den offiziellen GitHub-Actions-Runner versteckt installiert, ihn persistent im Hintergrund gestartet und Schutzmechanismen ausgehebelt, indem der Runner die explizit Erlaubnis bekam, mit Root-Rechten laufen zu dürfen.

Der eigentliche „Backdoor-Mechanismus“ sei durch einen absichtlich verwundbaren Workflow entstanden, der den Text einer Discussion direkt in einen „run“-Befehl übernommen habe. Durch Shell-Metazeichen habe sich so eine Command Injection auslösen lassen. Dafür hätten die Angreifer eine Discussion posten müssen, wodurch der Runner die eingeschleusten Befehle ausgeführt habe.

Schutz für GitHub Actions

Um kompromittierte GitHub Actions Runner zu erkennen, empfehlen die Sicherheitsforscher, gezielt nach entsprechenden Signalen zu suchen.

  • Ein besonders starkes Indiz sei die Variable „RUNNER_TRACKING_ID=0“, da diese ty­pischerweise dazu diene, den üblichen Prozess-Cleanup nach Job-Ende zu umgehen.
  • Das Runner-Inventar sollte regelmäßig geprüft werden, wobei auch hinterfragt werden sollte, wann und von wem Runner registriert wurden. Solche Registrierungen lassen sich über Audit-Log-Events wie „repo.register_self_hosted_runner” nachvollziehen.
  • Zusätzliche Hinweise können von Runner-Prozessen kommen, die in versteckten Ver­zeich­nissen, wie „~/.dev-env“, laufen, sowie von ungewöhnlichen Runner-Namen und un­er­war­teten Verbindungen zu unbekannten Repositories.
  • Auch Workflow-Dateien, in denen „untrusted“ Eingaben unsauber in Run-Befehle eingefügt werden, können Sysdig zufolge wichtige Informationen für die Entdeckung einer Kom­pro­mittierung liefern.

Zur Härtung und Eindämmung empfiehlt der Hersteller folgende präventive Maßnahmen:

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zur IT-Sicherheit

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung
  • Self-Hosted-Runner nicht in öffentlichen Repositories einsetzen.
  • Wo es möglich ist, sind ephemere Runner sinnvoll, da sie nach jedem ausgeführten Job sofort zurückgesetzt werden, wodurch die Umgebung nicht länger vorhanden ist. Dies reduziere das Risiko, auch wenn es keine Garantie dafür gibt, dass sie nur für einen einzigen Job ver­wendet werden können. Dennoch erschwere dies es Angreifern deutlich, dauerhaften Zugriff zu erlangen.
  • Außerdem sollte der Einsatz über Runner Groups mit Repository-Restriktionen strikt segmentiert werden, sodass nur klar definierte Repositories bestimmte Runner nutzen dürfen.
  • Auf Runner-Systemen grundsätzlich keine sensiblen Daten wie Secrets, SSH-Schlüssel oder API-Token speichern, da Workflow-Auslöser im Zweifel Zugriff auf die Runner-Umgebung haben könnten.
  • Die Netzwerkzugriffe von Runnern stark begrenzen und insbesondere Zugriffe auf Metadaten-Services, Produktionsdatenbanken oder andere kritische interne Ziele verhindern.

Security-Learning: Self-hosted Runner sind eine unterschätzte Angriffsfläche. Sie führen per Design Workflow-Code aus, halten persistente Verbindungen zu GitHub und laufen häufig mit weitreichenden Berechtigungen. Der von Sysdig untersuchte Shai-Hulud-Fall zeigt, wie An­greifer diese Eigenschaften schnell nutzen können, um Backdoors zu etablieren, die im nor­ma­len CI/CD-Traffic untergehen. Die Sicherheit von Software-Lieferketten ist entscheidend, da Schwachstellen in einem Teil der Kette potenziell gesamte Systeme gefährden können.

(ID:50703529)

Weiterführende Inhalte