Hab heute ein gehacktes GitRepo ein bisschen genauer angesehen. Es war das kubernetes-el Repo. Die Hack-Spuren sind mittlerweile weitgehend beseitigt, aber ich konnte sie mir zeitnah ansehen. Was passiert ist, ließ sich so für mich rekonstruieren:

  • Angreifer forked das Repo
  • Angreifer schickt einen Test-PR
  • GitHub Worker läuft los, führt dabei aber malicious code durch den Worker aus
  • Angreifer sieht, dass es geht und baut ein Script ein, dass einen GitHub Token an einen externen Webhook schickt und stellt damit erneut PR
  • PR Check Worker läuft los, schickt den Token raus
  • Angreifer nutzt den schreibberechtigten Token, um direkt von extern auf das Hauptrepo zuzugreifen
  • Angreifer baut in das Paket ein "rm -rf" ein (ein Emacs Kubernetes Paket) und defaced das Repo; löscht letztlich alle Dateien im Repo bis auf ein Bild und einen Hack-Hinweis

Was hier zu sehen war: Der Angriff war letztlich einfach. Eine einfache Fehlkonfiguration - der GitHub Worker konnte Git Commits auf das eigene Repo durchfühfren und reagierte sehr gutgläubig auf PRs - hat gereicht, um theoretisch ein Tool mit Schadcode zu versehen, das viele Nutzende in Emacs haben. Das ist Supply Chain nicht nur auf großen Infrastrukturen, sondern direkt als Angriff auf einen Editor.

tl;dr: Pipeline und Worker Security ist ein Ding.

@leitmedium Ja, und gerade bei GitHub ist die Security nicht einfach zu erreichen, weil zu viele Funktionen nur mit Schreibrechten auf dem Repository funktionieren.