Morgen - am 1.2.2023 - soll mein neuer $dayjob anfgangen - und damit die Quelle, aus der ich die Mittel beziehe, weiterhin meine Kuchenzutaten bezahlen zu können. Das wird irgendwas mit Sicherheit sein. Und am Tag davor hat sich - wer eigentlich genau? - überlegt: "Komm, lass ihn uns nochmal so richtig auf Betriebstemperatur überkochen!". Aber - der Reihe nach...

Die Explosion ereignete sich am Vormittag des 30. Januar 2023: Ich scrollte nochmal in Ruhe durch meine Mastodon-Timeline, in die ich vor einiger Zeit auch den Heise-Verlag mit aufgenommen hatte. Inzwischen habe ich mir eigentlich angewöhnt, über irgendwelche Meldungen von denen drüberzuscrollen ohne sie zu lesen, aber an dieser einen blieb mein Auge doch hängen. Ich adle sie hier mal nicht durch einen Link, da sich später herausstellte, dass derjenige bei Heise, der die Meldung verbrochen hatte gar keine Schuld trug - er hatte die Originalmeldung (die Heise übrigens auch nicht verlinkt hatte - ich musste sie mir mühsam selber heraussuchen) einfach in einen maschinellen Übersetzer geworfen und das Ergebnis unreflektiert publiziert.

Aber ich wollte ja am Anfang anfangen: In dem Heise Artikel wurde kolportiert, dass Ubekannte "Zertifikate zum Signieren von Code" abgegriffen hätten. Hier hätte ich eigentlich spätestens mit Lesen aufhören müssen, denn Zertifikate sind etwas per se öffentliches - man kann sie nicht "abgreifen", denn das suggeriert ja, dass sich da irgendjemand verbotenerweise Zugang zu irgendwelchen Geheimnissen verschafft. Zertifikate stellen letztlich eine Beglaubigung dar, dass gewisse geheime Informationen (ein privater Schlüssel, identifiziert durch seinen im Zertifikat enthaltenen zugehörigen öffentlichen Widerpart) und die ebenfalls im Zertifikat aufgeführten öffentlichen Attribute zu derselben (juristischen) Person gehören. Das muss jedem klar sein, der schon mal eine Seite mit dem Webbrowser angesurft hat, deren URL mit "https" begann: Für alle diese Seiten kann man im Browser nämlich mit höchstens drei Mausklicks ebenfalls das Zertifikat "abgreifen"!

Dann schwurbelte der Artikel noch etwas von "verschlüsselten Zertifikaten", die zum Codesigning benutzt worden wären, und auf die - bzw. auf die diese Zetifikate enthaltenden privaten Repositories - hätten ebendiese Angreifer mittels eines kompromittierten Personal Acces Tokens Zugriff erlangt.

Zunächst sei hier nochmal betont, was der eigentliche Grund für meine Aufregung ist: Mit einem Zertifikat erzeugt man keine Signatur! Mit den enthaltenen Inhalten kann man lediglich eine Signatur prüfen und nach dieser Prüfung entscheiden, ob man dem Ersteller der Signatur vertrauen möchte! Es ist, als ob niemand meinen Vortrag beim diesjährigen Jahresend-Event angehört hätte!

Als ich also so weit war, dass sich mein Geisteszustand ob dieses extrem schlampigen und dummen Aufschriebs nur noch mit dem Zitat "Oro, reiche er mir mein Riechfläschchen - ich muss mich echauffieren!" beschreiben ließ, suchte und fand ich die originale Meldung im Blog von Github.

Und da begriff ich, dass die Idee von git eine wirklich gute ist - sonst hätte ich postwendend damit anfangen müssen, meine diversen Repositories bei GitHub sofort zu kopieren und von dort abzuziehen. Erschreckenderweise stellt sich nämlich heraus, dass alles, was in dem Heise-Artikel steht, genauso von GitHub verbreitet wurde! Die haben also offenbar noch nicht mal die Grundzüge von Ahnung von Dingen, auf denen Sicherheit und Crypto im heutigen Internet basieren!

Zur nochmaligen Klarstellung und Präzisierung: Wenn da Dinge zu finden waren, mit denen man Code im Namen von GitHub signieren konnte, dann müssen das private Schlüssel gewesen sein. Die sehr seltsame Formulierung im Original von "encrypted code signing certificates" weist für mich darauf hin, dass PKCS#12-Container in den Repos abgelegt waren - und wenn von "encrypted" die Rede ist, dann waren die wohl wenigstens mit einem Passwort gesichert. Aber ein solcher PKCS#12-Container enthält eben auch den privaten Schlüssel - und der ist der Knackpunkt bei der Sache!

Nun muss man sich die Frage stellen, warum ein solches Schwergewicht wie GitHub überhaupt Dateien zur Speicherung seiner privaten Schlüssel benutzt und keine Hardware-Token (oder "Sichere SignaturErstellungsEinheiten" wie sie im § 2 Nr. 3 SigG genannt werden). Diese haben die Eigenschaft, dass man den privaten Schlüssel auch bei remote-Zugriff auf den Rechner oder das Repo nicht abziehen kann, weil sämtliche Crypto-Operationen auf der SSEE stattfinden und der private Schlüssel diese dafür nie verlässt.

Auf der anderen Seite - wenn man bei GitHub schon den - sehr wichtigen - Unterschied zwischen privatem Schlüssel und Zertifikat nicht kennt und offenbar nicht weiß, welches davon man geheimhalten muss, kann man auch nicht verlangen, dass man sich dort mit so fortgeschrittenen Konzepten wie Sicheren SignaturErstellungsEinheiten beschäftigt!

Artikel, die hierher verlinken

Kommentar hinzufügen (via ) Kommentare ansehen (via )

Kommentar hinzufügen (via ) Kommentare ansehen (via )