- Die einfache Verwechslung von ghcr.io und ghrc.io durch einen Tippfehler führt zu einer ernsten Sicherheitsbedrohung
- ghrc.io wirkt auf den ersten Blick wie ein normaler nginx-Server, intern wurde jedoch ein Nachahmen der OCI-API festgestellt
- Die Website verleitet Container-Clients über den
www-authenticate-Header dazu, sensible Anmeldedaten zu senden - Wenn versehentlich Anmeldedaten eingegeben werden, etwa mit
docker login, oder ein falsches Registry-Ziel verwendet wird, kann es zu einem Abfluss von Zugangsdaten kommen - Wer sich bei dem falschen Registry-Server angemeldet hat, sollte das Passwort ändern, PATs widerrufen und das GitHub-Konto auf verdächtige Aktivitäten prüfen
Überblick
Die leicht durch einen Tippfehler entstehende Verwechslung von ghcr.io und ghrc.io zeigt einen Fall, in dem ein sehr gefährliches Sicherheitsproblem entsteht. Bei ghrc.io, einer vertippten Variante der von vielen Entwicklern und Teams genutzten GitHub Container Registry (ghcr.io), wurde ein Versuch zum Diebstahl von Zugangsdaten beobachtet.
Was ist ghcr.io?
- ghcr.io ist eine OCI-kompatible Registry für Container-Images und OCI-Artefakte
- Als Teil von GitHub wird sie in zahlreichen Open-Source-Projekten als beliebte Registry verwendet
ghrc.io: der oberflächliche Eindruck
- Beim Aufruf von ghrc.io erscheint lediglich die Standardseite von nginx
- Typische Grundfunktionen wie ein 404-Fehler verhalten sich wie bei einem gewöhnlichen nginx-Server
Die Natur des bösartigen Verhaltens
- Das zentrale Problem zeigt sich bei OCI-API-Aufrufen unter dem Präfix
/v2/ - Beim Zugriff auf diesen Pfad verhält sich die Seite mit einem
www-authenticate-Header und einer 401-Antwort sehr ähnlich zu einer offiziellen Container-Registry - Der Header
www-authenticate: Bearer realm="https://ghrc.io/token";ist vorhanden - Durch diesen Header versuchen Clients wie Docker, containerd, podman und Kubernetes, Benutzeranmeldedaten automatisch an
https://ghrc.io/tokenzu übermitteln - Da die nginx-Standardkonfiguration diesen Header nicht enthält, ist dies offensichtlich absichtlich konfiguriert worden
Das Risiko: Szenario für den Diebstahl von Zugangsdaten
- Dieses Muster wird als Typo-Squatting-basierter Angriff zum Diebstahl von Zugangsdaten eingeschätzt
- Ein Risiko besteht nur dann, wenn Benutzer-Clients Anmeldedaten für ghrc.io eingegeben oder gespeichert haben
- Beispiele für Situationen, in denen echte Anmeldedaten offengelegt werden können
- Ausführung von
docker login ghrc.io - Verwendung von
docker/login-actionin GitHub Actions, wenn die Registry auf ghrc.io gesetzt ist - Speicherung von Registry-Anmeldedaten für ghrc.io in einem Kubernetes-Secret und anschließender Versuch, Images zu pullen
- Ausführung von
- Wenn nur versucht wird, Images von ghrc.io zu pushen oder zu pullen, werden Anmeldedaten nicht offengelegt (es wird ein anonymer Token versucht und anschließend ein Fehler zurückgegeben)
Gegenmaßnahmen
- Wer sich versehentlich bei ghrc.io angemeldet hat, sollte sofort das Passwort ändern und den verwendeten PAT (Personal Access Token) widerrufen
- Das GitHub-Konto sollte unbedingt auf ungewöhnliche Logins oder bösartige Aktivitäten geprüft werden
- Angreifer könnten dies ausnutzen, um bösartige Images in Repositories auf ghcr.io einzuschleusen oder Zugriff auf Konten zu erlangen
Fazit
- Vorsicht vor Phishing-Websites, die Adressen ähnlich wie ghcr.io verwenden
- Für den Umgang mit Anmeldedaten, Tokens, Passwörtern und anderen Sicherheitsinformationen sind noch strengere Sicherheitsrichtlinien erforderlich
2 Kommentare
Wäre es nicht besser, es einfach in eine Subdomain von github.com zu ändern?
Hacker-News-Kommentare
Es wird hervorgehoben, dass die GitHub Container Registry nur die bisherigen klassischen Tokens statt fein granularer Tokens unterstützt, was als ernstes Problem gesehen wird.
Dazu werden auch Links zur Dokumentation und zu Issues angefügt.
Offizielle Dokumentation
Community-Diskussion
Roadmap-Issue
Wegen dieses Problems kann man klassische PATs nicht vollständig deaktivieren.
Als zusätzliche Maßnahme könnte man die Sitzungsdauer kurz halten und per Enterprise SSO eine erneute Authentifizierung erzwingen, aber für das eine tatsächlich benötigte klassische PAT ist das eine umständliche Option.
Es wäre gut, wenn jemand aus guter Absicht alle Tippfehler-Domains kaufen und an Microsoft übergeben würde.
Microsoft sollte den Namen der Registry ändern.
Der Name ist so verwirrend, dass ich mich selbst schon oft vertippt habe.
Erst nachdem ich das Domain-Problem mehrfach gelesen hatte, konnte ich nachvollziehen, worin das Problem liegt; als Angriffsvektor ist das ziemlich überzeugend.
Sie haben es mehrfach versucht, es ist fehlgeschlagen, und selbst nach einem Neustart des Computers trat dasselbe Problem weiter auf.
Als Beispiele werden auch diese Stack Overflow-Antwort und diese Docker-Forum-Diskussion genannt.
Es wird auf Code-Suchergebnisse zu ghrc.io verlinkt.
Ich habe das Problem nicht bemerkt, bis im Artikel ausdrücklich darauf hingewiesen wurde, dass c und r vertauscht sind.
Solche Tippfehler mache ich fast zehnmal am Tag.
Das Problem hier ist, dass GitHubs Domainname misslungen ist.
Der Name der Container Registry ist wirklich schlecht.
Ein früherer Hacker-News-Diskussionslink wird geteilt.
Per whois lässt sich bestätigen, dass diese Domain bei dynadot registriert wurde.
Daher scheint es sinnvoll, sie an abuse@dynadot.com zu melden.
Es wird erwähnt, dass viele Open-Source-Projekte diese Domain verwenden, und die Code-Suchergebnisse werden noch einmal geteilt.
GitHub braucht intern ein Tool, das in großer Zahl automatische Korrekturen vorschlagen und ausrollen kann.
Es wird darauf hingewiesen, dass die GitHub-Code-Suchergebnisse tatsächlich ziemlich umfangreich sind.
Es wird die Sorge geäußert, dass ein Tippfehler in einem CI-Job große Probleme verursachen könnte.
Es wird geraten, TLDs mit geringem Sicherheitswert nach Möglichkeit zu meiden.
Sicherheit sollte Vorrang vor dem Versuch haben, „süß“ zu wirken.
Die Deaktivierung bösartiger Domain-Registrierungen könnte nicht so schnell erfolgen wie bei .com, daher wirkt .com, das von dem US-Unternehmen Verisign verwaltet wird, vertrauenswürdiger.
Sich auf das Britische Territorium im Indischen Ozean, Kolumbien oder Anguilla zu verlassen, sei unangemessen.
Es wird gefragt, ob das eigentliche Sicherheitsrisiko hier im Wiederverwenden von Tokens liegt.
Ein Bearer-Token übergibt das Passwort nicht direkt, und unter Verweis auf RFCs und Mozilla-Dokumentation wird gefragt, ob in Wirklichkeit nicht das Authentifizierungstoken selbst, sondern der Vorgang problematisch ist, mit dem man erneut ein Token zur Authentifizierung erhält.
Wenn domainübergreifendes OAuth keine Tokens wiederverwendet, würde man auf einer gefälschten Domain am Ende doch kein Token erhalten, oder?
Bei der Anfrage zum Erhalt eines Bearer-Tokens werden Passwort oder PAT im Basic-Auth-Header base64-kodiert gesendet, praktisch also im Klartext übertragen.
Nach Eingang der Anfrage wird ein
www-authenticate-Header erzeugt, ein Authentifizierungstoken wird geholt, der Zugriff auf die Registry verifiziert, und das Token läuft danach ab.Der Angreifer stiehlt also nicht das eigentliche Token, sondern bringt das Opfer dazu, genau die Zugangsdaten anzufragen, die zum Erhalt des Bearer-Tokens benötigt werden.