- Pixnapping ist eine neue Angriffstechnik, mit der bösartige Android-Apps heimlich personenbezogene Daten stehlen, die in anderen Apps oder auf Websites angezeigt werden
- Der Angriff nutzt einen Side Channel zwischen Android-API und GPU-Hardware und betrifft die meisten aktuellen Geräte großer Hersteller wie Google und Samsung
- Alle auf dem Bildschirm angezeigten Informationen wie Authentifizierungscodes, Chats und E-Mails können offengelegt werden, und der Angriff ist auch ohne App-Berechtigungen möglich
- Bei Google Authenticator können 2FA-Codes innerhalb von 30 Sekunden gestohlen werden
- Sowohl Google als auch die GPU-Anbieter verfügen derzeit über keine ausreichenden Patches oder Gegenmaßnahmen, um den Angriff wirksam abzuschwächen
Überblick
- Pixnapping ist ein Angriff, mit dem eine bösartige Android-App Informationen aus anderen Apps oder von Websites unbemerkt vom Nutzer stehlen kann
- Der Informationsabfluss erfolgt durch Ausnutzung eines Side Channels zwischen Android-API und GPU; betroffen sind die meisten aktuellen Android-Smartphones, darunter Geräte von Google und Samsung
- Zu den nachweislich betroffenen Apps gehören Gmail, Signal, Google Authenticator, Venmo, Google Maps; auch die 2FA-Codes von Google Authenticator lassen sich innerhalb von 30 Sekunden stehlen
Forschungsarbeit und Demonstration
- Die Veröffentlichung ist auf der ACM CCS 2025 unter dem Titel „Pixnapping: Bringing Pixel Stealing out of the Stone Age“ vorgesehen
- Über den Preprint lassen sich Funktionsweise und Details des Angriffs nachvollziehen
Wichtige Fragen und Antworten
Welche Geräte sind betroffen?
- Nachgewiesen wurde der Angriff auf Google Pixel 6, 7, 8, 9 und Samsung Galaxy S25 mit Android 13 bis 16
- Es ist sehr wahrscheinlich, dass das Grundprinzip des Angriffs auch auf Geräten anderer Hersteller funktioniert
Unter welchen Bedingungen funktioniert der Angriff?
- Jede Android-App ohne Berechtigungen kann den Angriff ausführen
- Er funktioniert auch ohne gesonderte Berechtigungsdeklaration in der App-Manifestdatei
Welche Informationen können gestohlen werden?
- Alle auf dem Bildschirm angezeigten Informationen (Chats, Authentifizierungscodes, E-Mails usw.) sind potenzielle Ziele
- Nicht sichtbare interne Informationen können nicht abgegriffen werden
Gibt es bereits reale Missbrauchsfälle?
- Ob der Angriff derzeit tatsächlich aktiv ausgenutzt wird, ist bislang unbestätigt
Wie können sich Nutzer schützen?
- Es wird empfohlen, neue Android-Sicherheitsupdates sofort nach Veröffentlichung zu installieren
Wie können sich Entwickler schützen?
- Wirksame Abwehr- oder Umgehungsmaßnahmen sind derzeit nicht bekannt
- Falls sicherheitsrelevante Erkenntnisse vorliegen, bitten die Forscher um Kontaktaufnahme
Funktionsweise des Angriffs
- Eine bösartige App ruft die Ziel-App (z. B. Google Authenticator) auf und bringt sie dazu, sensible Informationen zu rendern
- Auf dem Bildschirm der Ziel-App wird auf bestimmte Pixel gezielt eine Grafikoperation wie Blur angewendet
- Über einen Side Channel wie GPU.zip werden die Pixel aus Schritt 2 einzeln extrahiert
- Durch Wiederholung von Schritt 2 und 3 wird das vollständige Pixelbild rekonstruiert und anschließend per OCR der ursprüngliche Inhalt ausgelesen
- Das ähnelt effektiv einem Screenshot eines Bildschirms, auf den die bösartige App eigentlich keinen Zugriff haben dürfte
Ausgenutzte Android-APIs
- Über die window blur API wird auf sensible Pixelbereiche eine Grafikverarbeitung (Blur) angewendet
- Über VSync-Callbacks wird die Renderzeit gemessen und für die pixelweise Extraktion genutzt
Googles Patches und Reaktion
- Google reagierte zunächst, indem die Anzahl der von Apps ausgelösten Blur-Aktivitäten begrenzt wurde, doch bald wurde ein Workaround gefunden
- Dieser Workaround ist derzeit noch nicht öffentlich (unter Embargo)
Side Channel auf Hardware-Ebene
- Die Pixelinformationen werden über einen GPU-basierten Side Channel namens GPU.zip extrahiert
- Stand Oktober 2025 haben GPU-Hersteller keine gesonderten Patch-Pläne
Schwachstellenkennung (CVE)
- Die Schwachstelle ist offiziell als CVE-2025-48561 registriert
Betrifft das auch andere Betriebssysteme?
- Android ist angreifbar, weil Apps Grafikoperationen auf Bildschirmdaten anderer Apps auslösen und deren Seiteneffekte messen können
- Ob sich der Angriff auch auf andere Betriebssysteme übertragen lässt, ist unklar
Zusätzliche Schwachstelle: App List Bypass
- Es gibt außerdem eine App-List-Bypass-Schwachstelle, mit der sich die Liste anderer installierter Apps ohne zusätzliche Berechtigungen oder Manifest-Deklarationen ermitteln lässt
- Sie kann für Nutzerprofiling verwendet werden und funktioniert im Unterschied zu bisherigen Umgehungsmethoden ohne zusätzliche Deklarationen
- Google stufte sie als „Infeasible“ ein und schloss den Fall ohne weitere Maßnahmen
Logo, Quellcode und Lizenz
- Das Pixnapping-Logo kann unter der CC0-Lizenz frei verwendet werden
- Nach Auslieferung der Patches soll der Quellcode auf GitHub(https://github.com/TAC-UCB/pixnapping) veröffentlicht werden
Reaktion und wichtiger Zeitplan
- Zwischen Februar und Oktober 2025 wurden Google und Samsung schrittweise über die Schwachstellen informiert und um Gegenmaßnahmen gebeten
- Google stufte das Risiko von Pixnapping und dem App-List-Bypass als High bzw. Low ein; einige Patches wurden als unzureichend bewertet oder als nicht behebbar eingestuft
- Weitere Patches sind für das Android-Sicherheitsbulletin im Dezember 2025 vorgesehen
Zusammenfassung
- Pixnapping ist ein Angriff, der durch die Kombination von Schwächen im App-Berechtigungsmodell und im Hardware-Verhalten wichtige Informationen vom realen Bildschirm unrechtmäßig abfließen lassen kann
- Sowohl bei der Android-Software als auch bei der Hardware-Sicherheit sind strukturelle Verbesserungen notwendig
1 Kommentare
Hacker-News-Kommentare
Meiner Meinung nach ist das Kernproblem, dass das Android-Berechtigungssystem Dinge wie „im Hintergrund ausführen“ oder „Internetzugang“ standardmäßig auch ohne Zustimmung des Nutzers erlaubt. Solche Angriffe sind möglich, weil alle Apps — sogar Offline-Spiele — diese Berechtigungen standardmäßig haben. Viele Apps sollten nur dann Internetzugang haben, wenn man die App verwendet. Das wäre kein perfekter Schutz, könnte die Wirksamkeit des Angriffs aber deutlich senken, weil immer das Risiko besteht, versehentlich eine bösartige App auszuführen.
Ich frage mich, ob es eine solide Studie zum Risiko von automatischen Updates im Vergleich zu manuellen oder ausbleibenden Updates gibt, besonders in halbwegs sandboxed Umgebungen wie Android. Mich würde interessieren, ob es Untersuchungen zum Vergleich der Fehlerquoten gibt.
Tatsächlich gibt es eine Berechtigung für Internetzugang, und in GrapheneOS kann man Apps, die diese Berechtigung deklarieren, den Internetzugang komplett verweigern.
Es gibt eine überzeugende Antwort darauf, warum Android-Apps den Nutzer nicht um Erlaubnis für Internetzugang bitten. Es ist eine direkte Antwort des Android-Entwicklungsteams Quelle. Was „im Hintergrund ausführen“ angeht: Da Android auf „Intents“ basiert, können Apps jederzeit aufgeweckt werden, weshalb eine einfache Option wie „Hintergrundausführung verbieten“ möglicherweise nicht so funktioniert, wie Nutzer es erwarten.
Ich habe mir das Video angesehen und finde es trotzdem schwer zu verstehen, wie dieser Angriff funktioniert. Ich frage mich, ob nach dem Wechseln der App überhaupt noch Zugriff auf die Pixel der Authentifizierungs-App möglich ist.
Auf die Frage, wie man als App-Entwickler Nutzer schützen sollte, wurde zwar gesagt, es gebe keine veröffentlichten Gegenmaßnahmen, aber ich denke, es gibt ein paar naheliegende Ansätze: zum Beispiel die Position des Passcodes nicht fest auf dem Bildschirm zu lassen, ihn im Hintergrund zu verbergen, den Code ständig zu bewegen, Farbe und Kontrast zu verändern, statisches Rauschen anzuzeigen oder nur Teile des Codes kurz aufblinken zu lassen statt den gesamten Code. Natürlich würde das die UX etwas verschlechtern, aber theoretisch könnte es die Hürde für Angreifer deutlich erhöhen. Gleichzeitig gilt: Wenn geheime Informationen bereits per Screenshot gecacht sind, gibt es Grenzen.
Ich erinnere mich, dass Google Authenticator früher so geändert wurde, dass TOTP-Codes erst nach einer Berührung angezeigt wurden. Damals dachte ich, das halte reale Bedrohungen nicht auf und sei nur unbequem, und viele andere sahen das genauso, sodass die Funktion bald stillschweigend zurückgenommen wurde. Ich frage mich, ob das eine vorbeugende Maßnahme gegen genau diese Schwachstelle war.
Hier ist eine Demo: unscreenshottable.vercel.app
Zu TOTP wird betont, dass dieser Angriff praktisch nur möglich ist, wenn Schriftart und Pixelpositionen perfekt bekannt sind. Laut dem Paper dauert es lange, sensible Bildschirmbereiche auszulesen, und 2FA-Codes werden zum Beispiel standardmäßig alle 30 Sekunden aktualisiert, also gibt es ein strenges Zeitfenster. Wenn der Angreifer nicht innerhalb von 30 Sekunden alle 6 Stellen exfiltrieren kann, verschwindet der Wert. Wenn dem Angreifer die Schriftart bekannt ist, kann er allerdings schon mit nur wenigen exfiltrierten Pixeln unterscheiden, was angezeigt wird.
Es wird erklärt, dass diese Technik schon länger existiert, aber sehr effektiv ist, wenn man ein Ziel präzise angreifen will. Wenn man eine bestimmte App auf dem Telefon des Nutzers installieren kann, muss man es oft gar nicht so kompliziert machen und kann direkt mit der App auf die gewünschten Informationen zugreifen. Wenn etwa Facebook den Nutzern einen Datenschutzhinweis wie „Diese App erstellt regelmäßig Bildschirmaufnahmen“ anzeigen würde, würden überraschend viele Leute trotzdem zustimmen. Der Pixnapping-Quellcode soll hier veröffentlicht werden, sobald ein Patch möglich ist, aber vermutlich wäre auch Reverse Engineering nicht besonders schwer. Man hätte bis zur Behebung warten können, aber die Forschenden wollten offenbar schnell Aufmerksamkeit erzeugen.
Der ursprüngliche Patch für die Schwachstelle ist bereits öffentlich. In der Commit-Nachricht des zugehörigen Commits steht sogar ausdrücklich, dass durch Messen der Blur-Zeit zwischen Fenstern das Abgreifen von Pixeln verhindert werden soll. Dass die Forschenden den Code nicht veröffentlichen, liegt daran, dass sie einen Weg gefunden haben, diesen Patch zu umgehen. Zusätzlich wird erwähnt: „Kein GPU-Hersteller hat zugesagt, GPU.zip zu patchen“ und „Google hat ebenfalls nicht vor, die Umgehungsschwachstelle bei App-Listen zu patchen“ („closed as infeasible“). Wenn man bedenkt, dass die erste Meldung am 24. Februar 2025 erfolgte, kann man schwer sagen, die Forschenden seien vorschnell gewesen. Und selbst wenn es eine Benachrichtigung gäbe wie „Diese App erstellt regelmäßig Bildschirmaufnahmen“, könnten Bildschirme, die explizit als nicht screenshotfähig markiert sind, ohne einen separaten Exploit nicht aufgenommen werden.
Das Datum der ersten Meldung an Google war der 24. Februar 2025. Es wurde also genug Zeit eingeräumt.
Es wird anerkannt, dass dieser Angriff eine clevere Methode ist, die Renderzeit als Side-Channel nutzt. Selbst bei Google Authenticator dauert es wohl ziemlich lange, alle Pixel einzusammeln. Ich mache mir eher Sorgen, wie gut sich so etwas zum Stehlen von OTPs aus Textnachrichten einsetzen lässt. Auch Phishing-Mails mit festem Muster, etwa GitHub-Benachrichtigungen per E-Mail, nehmen zu, sodass ich aufgehört habe, überhaupt auf Links in E-Mails zu klicken. Inzwischen denke ich auch, dass man Empfehlungen zum Öffnen von Apps per Intent besser meiden sollte. Es ist besser, Apps direkt zu öffnen und unnötige Apps zu löschen. Die Angriffsfläche kann sich auch über SDKs oder Web-Page-Intents ausweiten, was meiner Meinung nach oft unterschätzt wird.
Ich dachte beim Titel zuerst, es gehe um ein Browser-Spiel, und habe deshalb nachgesehen.
Ich bin kein Sicherheitsexperte, aber ich denke, wenn man eine App auf einem Windows-Desktop installiert, sind Angriffe viel schneller und unauffälliger möglich als Android-Pixnapping. Wenn man dasselbe Passwort auf mehreren Websites verwendet, kann eine davon das Passwort stehlen und sich damit woanders anmelden, sofern keine zusätzliche Schutzschicht vorhanden ist. Theoretisch ist das also ziemlich unsicher, auch wenn solche Angriffe in der Praxis nicht unbedingt häufig oder leicht durchzuführen sind.
Hinweis auf die vorherige Diskussion
Ich denke, moderne Geräte sind so komplex geworden, dass vollständige Sicherheit unmöglich ist. Es werden endlos Funktionen hinzugefügt, die niemand wirklich braucht, und dadurch entstehen solche Probleme. Ich glaube, die Nachfrage nach sicherheitsorientierten Betriebssystemen mit minimalem Funktionsumfang, ähnlich wie FreeBSD, wird weiter steigen.
Ich möchte eine Umgebung, in der ich auch unterwegs im Terminal
make worldausführen kann.Es gibt Precursor von Bunnie. Ich fand es zwar cool, aber viel zu teuer. Wenn man schon einen Taschenrechner für 100 Dollar teuer findet, dann ist Precursor ähnlich geformt, hat eine ähnliche Rechenleistung, kostet aber 1000 Dollar und taugt nicht einmal für eine Mathematikprüfung. Offizieller Precursor-Blog (derzeit nicht erreichbar, vielleicht später wieder)
Nach einigen Jahren des Lesens von HN-Kommentaren habe ich den Eindruck gewonnen, dass Sicherheitswissen und Sicherheitspraktiken stark zurückgegangen sind. Durch die Verbreitung generativer KI wird es wohl noch schlimmer. In letzter Zeit gibt es zusammen mit Diskussionen über das FSF-Phone-Projekt auch viele Leute, die sich darüber beschweren, dass Mobile-Banking-Apps unbequem seien. Manche sagen sogar, es sei lästig, auf dem Desktop alle 30 Minuten ein Passwort einzugeben, und viele fragen: „Muss ich wirklich zwei Telefone dabeihaben?“ Aus meiner Sicht würde ein Dieb, der nur zusieht, wie jemand sein Passwort eingibt, sofort die Banking-App oder Money-App öffnen und versuchen, möglichst viele Daten abzugreifen. Solche Straftaten passieren tatsächlich jeden Tag. Solche Apps sollte man am besten gar nicht auf dem Telefon installiert haben oder jedenfalls nicht eingeloggt lassen, und das gilt auch für 2FA-Apps. Es ist, als würde man mit einem teuren Marken-Reisekoffer herumlaufen und sich damit selbst zum Ziel machen. Wenn man kein CEO ist oder Ziel staatlicher Angriffe, sollte man umso vorsichtiger sein. Auch bei einem „Minimal-Feature-Sicherheits-OS“-Gerät bleibt das physische Problem bestehen, dass jemand das Passwort beobachten und dann das Gerät stehlen kann. Aber man sollte ein Telefon, auf dem nur Spiele und Werbe-Apps für die Nutzung in der Kneipe installiert sind, strikt von einem Telefon trennen, das man für Banking, 2FA und Arbeit verwendet.