Zusammenfassung

  • LACNIC veröffentlichte am 7. Oktober Guillermo Pereyras Leitfaden zu Canary Tokens. Der Text nutzt den Vorfall bei Grafana Labs aus dem Jahr 2025, um zu zeigen, wie eine getestete Köder-Zugangsdatenfolge Alarm auslösen kann.
  • Das Grafana-Transkript trennt ein Angriffsereignis um 04:30 Uhr, die Auslösung eines Canary während einer TruffleHog-Prüfung um 06:15 Uhr, eine Reaktion um 08:00 Uhr und die Protokollanalyse um 11:00 Uhr. Eine Zeitzone fehlt; der erste Zeitpunkt belegt nicht den Beginn des Erstzugriffs.

Der Alarm datiert nicht den Beginn des Angriffs

Ein Geheimnis kann gestohlen worden sein, bevor jemand den Köder berührt. Genau diese Unterscheidung steckt in dem Fall, den LACNIC für seinen neuen Leitfaden ausgewählt hat. Am 7. Oktober veröffentlichte der LACNIC Blog Guillermo Pereyras Erklärung zu Canary Tokens: Köderdateien, Zugangsdaten, URLs oder Domains, die bei einer bestimmten Interaktion Alarm schlagen. Ein Hinweis der Seite stellt klar, dass die Ansichten der Autoren nicht notwendigerweise die von LACNIC wiedergeben. Der Beitrag ist eine Anleitung; er belegt weder einen Einsatz solcher Tokens durch LACNIC noch einen entsprechenden Vorfall bei der Organisation.

Der Leitfaden schildert Grafana als Beispiel für schnelle Erkennung: Ein Angreifer, der Geheimnisse aus GitHub-Repositories erbeutet hatte, wollte einen AWS-Schlüssel validieren, der tatsächlich ein Canary war. Laut LACNIC kam die Meldung sofort an, und der Vorfall sei innerhalb weniger Minuten eingedämmt worden. Grafanas eigene Veröffentlichungen zeigen mehrere getrennte Schritte.

Im Sicherheitsbericht von 2025 erklärte Grafana Labs, ein fehlerhaft konfigurierter GitHub-Actions-Workflow habe eine begrenzte Zahl von Tokens offengelegt. Der unbefugte Zugriff blieb demnach auf Automatisierungssysteme beschränkt; Produktionsumgebungen und Release-Artefakte waren nicht betroffen. Grafana erklärte, die offengelegten Tokens ungültig gemacht, Zugangsdaten rotiert, Workflows geprüft und Zugriffsprotokolle untersucht zu haben. Zum Zeitpunkt der Veröffentlichung lief die Untersuchung noch; das Unternehmen war mit hoher Zuversicht davon ausgegangen, dass der Zugriff auf fünf betroffene Repositories begrenzt blieb.

Ein späteres GrafanaCON-Transkript präzisiert die Funktion des Canary. Die Vortragenden beschreiben TruffleHog als ein Werkzeug, das gefundene Geheimnisse gegen aktive Dienste prüfen kann. Sie setzen ein Angriffsereignis auf 04:30 Uhr, die Auslösung des Canary während einer TruffleHog-Prüfung auf 06:15 Uhr, die Reaktion auf 08:00 Uhr und die Loki-Protokolluntersuchung auf 11:00 Uhr. Eine Zeitzone nennen sie nicht. Das sind Zeitmarken aus dem Vortrag, keine vereinheitlichte Vorfallchronologie: Die erste belegt nicht den Zeitpunkt des ersten Zugriffs, und der Token erfasste eine spätere Prüfung eines gestohlenen Geheimnisses.

Nach der Zeitachse des Vortrags liegen 1 Stunde und 45 Minuten zwischen der Auslösung um 06:15 Uhr und der Reaktionsmarke um 08:00 Uhr. Das Transkript legt weder fest, ob 08:00 Uhr die erste operative Maßnahme oder eine formelle Eskalation bezeichnet, noch wann die Eindämmung abgeschlossen war. Der Ablauf widerlegt die Aussage des Leitfadens, der Vorfall sei binnen Minuten eingedämmt worden, nicht; er bestätigt sie aber auch nicht unabhängig. Er zeigt, warum Alarm, Reaktion und Eindämmung getrennte Zeitstempel brauchen.

So wird „sofort“ präziser. Ein Token kann melden, sobald genau sein Köder benutzt wird. Allein zeigt er nicht, wann ein Workflow kompromittiert wurde, wer Zugangsdaten erhielt, wie weit der Zugriff reichte oder ob die Gefahr eingedämmt ist. Laut Vortrag machte der Alarm den Validierungsversuch sichtbar; Protokolle und weitere Reaktionsarbeit waren nötig, um den Umfang einzugrenzen.

Die später beschriebenen Maßnahmen bestanden nicht nur darin, weitere Köder auszulegen. Die Vortragenden verlagerten Geheimnisse in einen Tresor, machten Zizmor- und TruffleHog-Prüfungen verpflichtend, weiteten Canary-Abdeckung aus, beschränkten zu weitreichende GitHub-App-Rechte und schulten Nutzer. Diese Maßnahmen richten sich gegen Offenlegungspfade, Berechtigungsumfang und Wiederholbarkeit. Ein Canary ist ein Signal innerhalb dieser Kontrollen, kein Ersatz dafür.

Auch LACNICs Leitfaden warnt, dass manche Werkzeuge öffentliche Token-Dienste erkennen können und eine Meldung nur hilft, wenn jemand den Kanal überwacht. Grafanas Vortragende nennen einen konkreten Fall: TruffleHog erkennt die kostenlosen Thinkst-Tokens, die es kennt, und prüft sie nicht. Das lässt sich weder auf alle Werkzeuge noch alle Tokens übertragen. Es bedeutet aber, dass ein stiller Canary nicht beweist, dass niemand nach dem Geheimnis gesucht hat. LACNIC bezeichnet Fehlalarme zudem als selten, veröffentlicht dafür jedoch weder eine gemessene Quote noch deren Nenner.

Das Signal hängt weiter vom Tokentyp, seinem Verbreitungsweg und der möglichen Interaktion anderer Software ab.

Die belastbare Lehre ist nicht, dass ein Canary einen Angriff vom ersten Schritt an erkennt. Ein gezielt platzierter Köder kann eine spätere Interaktion schnell aufdecken – wenn der Alarm ein Team erreicht, die Belege für die Untersuchung erhalten bleiben und die Verantwortlichen Zugangsdaten ungültig machen und Berechtigungen beschränken können.

Quellen