Eine Warnung, die man wegzuklicken lernt, schützt nicht

Serguey Asael Shinder26 September 2026, 10:342 Min. Lesezeit

Zwei voneinander unabhängige Meldungen des letzten Tages beschreiben dasselbe Versagen von entgegengesetzten Enden her.

Die erste ist die Analyse des Macfinger-ClickFix-Stealers durch SANS. Nichts an dieser Infektion umgeht die Schutzmechanismen von macOS. Das Opfer fügt einen Befehl ins Terminal ein, weil eine Webseite darum gebeten hat, und danach fragt die Malware einfach: Zugriff auf Dokumente, Schreibtisch und Downloads, auf die Fotomediathek, auf Apple Music, Steuerung von Notizen, schließlich das Administrator- und das Schlüsselbund-Passwort. Jeder Dialog ist echt, und jeder erfüllt seine Aufgabe. Der Angriff beruht darauf, dass Menschen Dialoge bestätigen - weil fast jeder Dialog, den sie je gesehen haben, harmlos war.

Die zweite ist CodeQL 2.27.1, dessen Änderungsliste größtenteils von Alarmen handelt, die nicht hätten anschlagen dürfen: per Lockfile gepinnte Actions, die trotzdem als ungepinnt galten; vorgeschlagene LINQ-Umbauten, die nicht kompiliert hätten; eine Anti-Forgery-Prüfung, die einen global registrierten Filter übersah. Nichts davon ist aufregend. Alles davon ist die Pflege, die entscheidet, ob jemand den nächsten Alarm überhaupt liest.

Derselbe Mechanismus

Eine Warnung ist nur dann eine Kontrolle, wenn jemand auf sie reagiert, und ob das geschieht, hängt davon ab, was die letzten hundert Warnungen gewesen sind. Jeder Fehlalarm verbraucht ein wenig Glaubwürdigkeit. Ist genug verbraucht, läuft die Regel weiter, das Dashboard zählt sie weiter - und die Organisation hat sie faktisch abgeschaltet. Das Zustimmungssystem von macOS ist dasselbe im Maßstab einer ganzen Plattform: Dialoge kommen so häufig und sind so meist harmlos, dass eine Folge von sechs davon als lästige Reibung gelesen wird, nicht als Alarm.

Daraus folgen zwei Gewohnheiten.

Erstens: Wegklicken zählen, nicht nur Alarme. Eine Code-Scanning-Regel, deren Funde überwiegend als "won't fix" oder "false positive" geschlossen werden, schützt nicht; sie trainiert das Klicken. Dann gilt es, die Regel zu reparieren, einzugrenzen oder zu entfernen. Wenige Alarme, die immer stimmen, sind mehr wert als viele, die manchmal stimmen.

Zweitens: Die Entscheidung weg vom Moment des Dialogs verlagern. Wirksam gegen ClickFix sind nicht bessere Dialoge, sondern Richtlinien, die den Dialog überflüssig machen: Auf einem verwalteten Laptop sollte Terminal keine Ketten aus Herunterladen und Ausführen starten, neue LaunchAgents mit Namen von Apple-Diensten sollten dort einen Alarm auslösen, wo niemand etwas bestätigen muss, und alle sollten wissen, dass keine Website je einen Terminal-Befehl braucht. Beim Code Scanning entspricht dem, das Pinnen im CI zu erzwingen - dann ist der Alarm ein Auffangnetz und nicht die einzige Linie.

Beide Meldungen enden am selben Punkt. Eine Kontrolle, die darauf baut, dass ein Mensch etwas bemerkt, ist nur so gut wie das letzte Mal, als dieser Mensch recht damit hatte, es zu ignorieren.