Panne bei GitHub : Privater SSH-Schlüssel war öffentlich einsehbar
▻https://www.heise.de/news/Panne-bei-GitHub-Privater-SSH-Schluessel-war-oeffentlich-einsehbar-8003623.htm
Il y a plusieurs raisons pour l’utilisation de son propre serveur GIT. Cet articleen décrit une.
24.3.2023 von Rainald Menge-Sonnentag - Die Betreiber der Versionsverwaltungsplattform GitHub haben den RSA-SSH-Host-Schlüssel ausgetauscht, weil der private Schlüssel offenbar in einem öffentlichen Repository aufgetaucht war. Der Vorfall betrifft nur diejenigen, die ihre Git-Operationen über SSH (Secure Shell) mit dem RSA-Kryptoverfahren durchführen, zeigt aber auch, dass den Betreibern Pannen passieren können, vor denen sie ihre Kundschaft warnen.
Nach Angaben von GitHub hat das Unternehmen festgestellt, dass der private RSA-SSH-Schlüssel kurzzeitig in einem öffentlichen GitHub-Repository zu finden war. Laut einem Blogbeitrag handelte es sich um keine externe Attacke und es seien keinerlei Kundendaten abgegriffen worden. GitHub habe keinen Grund zur Annahme, dass jemand den exponierten Schlüssel missbraucht hat.
Kein Angriff, sondern ein peinlicher Patzer
Die Betreiber der Plattform vermuten, dass es sich bei der Veröffentlichung des Schlüssels um ein Versehen gehandelt habe. Dass private Schlüssel, Passwörter im Klartext oder andere Credentials in Repositories landen, kommt leider immer wieder vor. Das hat sowohl GitHub als auch GitLab dazu veranlasst, Schutzmaßnahmen einzuführen. GitHub hat Anfang 2021 zunächst für private Repositories Secret Scanning eingeführt, das solche Credentials aufspürt. Inzwischen ist die Funktion auch für öffentliche Repositories verfügbar.
Der KI-Codeassistent Copilot hat Anfang des Jahres einen Filter erhalten, der hartkodierte Credentials erkennen soll. Mitbewerber GitLab bietet seit Anfang 2019 die Funktion Secret Detection, die anfangs auf die teuerste Ultimate-Variante beschränkt war. Inzwischen ist sie mit geringerem Funktionsumfang auch in der kostenlosen Free-Variante enthalten. Das Thema Security bringt GitHub regelmäßig auf den Tisch und hat frisch das Secure Code Game gestartet, das Entwicklerinnen und Entwicklern dabei helfen soll, weniger Schwachstellen zu produzieren.
Update für die Betroffenen
Die meisten GitHub-User dürften von dem Schlüsselaustausch wenig mitbekommen. Betroffen sind nur diejenigen, die SSH mit RSA-Verschlüsselung verwenden. Diejenigen, die für den Secure-Shell-Zugriff ECDSA- oder Ed25519-Schlüssel nutzen, brauchen sie nicht zu ändern.
Wer folgende Fehlernachricht beim Verbindungsaufbau über SSH erhält
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
SHA256:uNiVztksCsDhcc0u9e8BujQXVUpKZIDTMczCvj3tD2s.
Please contact your system administrator.
Add correct host key in ~/.ssh/known_hosts to get rid of this message.
Host key for github.com has changed and you have requested strict checking.
Host key verification failed.
muss den alten öffentlichen RSA-Schlüssel zunächst mit ssh-keygen -R github.com löschen und dann einen neuen Schlüssel entweder manuell in die Datei ~/.ssh/known_hosts eintragen oder über curl herunterladen:
curl -L ▻https://api.github.com/meta | jq -r ’.ssh_keys \
| .[]’ | sed -e ’s/^/github.com /’ >> ~/.ssh/known_hosts
Aus Sicherheitsgründen sollen auch diejenigen den kompromittierten RSA-Schlüssel löschen, die ihn nicht nutzen oder keine Fehlermeldung erhalten.
Der Fingerprint für den neuen Schlüssel ist laut GitHub:
SHA256:uNiVztksCsDhcc0u9e8BujQXVUpKZIDTMczCvj3tD2s
Neben denjenigen, die direkt RSA für SSH verwenden, können auch bestimmte GitHub Actions betroffen sein, die mittels SSH-Schlüssel erfolgen.
Weitere Informationen zu dem Vorfall und den Gegenmaßnahmen lassen sich dem Beitrag auf dem GitHub-Blog entnehmen, der sich allerdings über Details dazu ausschweigt, wann und wie lange der private Schlüssel öffentlich einsehbar war.
