Mehr Fehler mit QR-Codes, auch bei OnePlus – Google bietet Pixel-Update

Google wollte Sicherheitsbug mit QR-Codes nicht beheben. Erst nach dem heise-Bericht ging es flott. Neu entdeckt: Android-Handys können falsche Termine haben​.

In Pocket speichern vorlesen Druckansicht 194 Kommentare lesen
Infografik zeigt zweimal den selben QR-Code. Links wird darin korrekt ein Link https:// wwwheise.de erkannt, rechts inkorrekt ein Link heise.de

Links ein Screenshot der App QR Barcode von BondRen, rechts ein Screenshot der Google Camera App auf einem Pixel 5 vor Einspielen des neu verfügbaren Updates. In diesem Fall führen beide Auswertungen zur selben Webseite - das muss aber nicht so sein.

(Bild: Daniel AJ Sokolov)

Lesezeit: 10 Min.
Inhaltsverzeichnis

Googles Camera-App verfälscht beim Auswerten von QR-Codes nicht nur enthaltene Links, sondern auch Kalenderdaten. Das Link-Problem betrifft deutlich mehr Domains, wie weitere Tests heise securitys belegen. Außerdem sind mehr Handys betroffen: Neben Pixel-Handys mit Android 12 können auch manche OnePlus-Mobiltelefone sowie Pixel-Handys mit Android 11 betroffen sein. Ein Leserhinweis hat uns zudem auf falsche Auswertung von Kalenderdaten aufmerksam gemacht, die alle Nutzer der Google-App Lens betreffen kann.

Am Donnerstag hat heise security erstmals berichtet, dass Googles Camera-App auf Pixel-Handys mit Android 12 http(s)-Links aus QR-Codes verfälscht. Wir haben dabei drei Fehlergruppen herausgearbeitet:

  1. Ein Google-Algorithmus setzt vor der Weiterleitung an den Browser falsche Punkte in den Second Level Teil von Domainnamen.
  2. Googles Algorithmus löscht Zeichen am Ende mancher Links.
  3. Googles Algorithmus verschiebt Ziffern in Domainnamen, die der Zeichenfolge "www" folgen, in einen eigenen Level, sodass zum Beispiel aus https://www1.nyc.gov das falsche https://www.1.nyc.gov wird.

Ein Klick, und der User landet bestenfalls bei einer Fehlermeldung, schlimmstenfalls in den Armen eines gewieften Angreifers. Googles hat dazu noch nicht Stellung genommen, sondern um Geduld gebeten.

Nun können wir berichten, dass die Fehlergruppen 2 und 3 in deutlich mehr Fällen auftreten (siehe unten auf Seite 2), und dass auch manche Pixel-Handys mit Android 11 sowie manche OnePlus-Handys betroffen sind. Hinzu kommt eine vierte Fehlergruppe, die Kalendereinträge auf potenziell sehr vielen Android-Handys betrifft: Aus QR-Codes entnommene Termine können völlig falsch im Kalender landen.

Zunächst hatte heise security die Fehler der Camera-App nur auf Pixel-Handys mit Android 12 verifiziert. Inzwischen konnten wir sie auch auf mehreren OnePlus 6 mit als OxygenOS verpacktem Android 11 verifizieren. Dabei hat uns unter anderem Sicherheitsexperte Christian Wieser von der Universität Oulu geholfen. Zudem haben wir Hinweise erhalten, wonach weitere OnePlus-Modelle mit Android 11 oder 12 betroffen sind. Auf unsere Anfrage vom Donnerstag hat OnePlus bislang leider nicht reagiert. Nicht betroffen war in unseren Versuchen ein OnePlus 6 mit LineageOS.

Aus unerfindlichen Gründen wird das Datum eines Termins stets um einen Monat nach hinten verschoben, wenn der Termin aus einem QR-Code mit der Camera-App eines betroffenen Pixel- und OnePlus-Geräts ausgelesen wird. Gibt es denselben Tag im Folgemonat nicht, schiebt Google den Kalendereintrag um 31 Tage. So wird aus einem Termin am 31. 1. 2022 einer am 3. 3. 2022.

Statt zu https://dasistmega.toll.tt (Trinidad & Tobago) möchte Google Camera-App (vor dem Update) den User zu dasistmega.to (Tonga) schicken.

(Bild: Daniel AJ Sokolov)

Dem nicht genug, Googles Auswertung hat auch die Zeitzonenangabe ignoriert: Die Internet-Kalender-Spezifikation RFC 5545 legt fest, dass der Buchstabe Z nach einer Uhrzeit ("230000Z") bedeutet, dass die Angabe in Weltzeit ist. Googles Algorithmus ignoriert das Z und nimmt Uhrzeiten in jener Lokalzeit an, die auf dem Gerät gerade eingestellt ist.

Diese falsche Interpretation der Uhrzeiten ist bei unseren Tests bis Freitagabend auch mit der App Google Lens aufgetreten, egal, auf welchem Handy. Wer entweder mit der Camera-App auf einem Pixel- oder OnePlus-Handy, oder mit der Google-App Lens, Termine aus QR-Codes in seinen Kalender gespeichert hat, sollte diese Einträge nun überprüfen. Andernfalls droht das Verpassen dieser Termine, wenn sie falsch eingetragen sind.

In der Nacht auf Samstag hat Google den serverseitig laufenden Algorithmus für die Lens-App aktualisiert, sodass uns Lens seit Samstag korrekte Angaben liefert. Neuinstallationen der App waren an Wochenende übrigens mit mehreren Versuchsgeräten unmöglich: Lens wurde zwar heruntergeladen, konnte dann aber nicht benutzt werden. "Please try again later", bittet die Einblendung.

Beim Aufruf der Kamera blendet Google einen Hinweis auf das Update ein.

(Bild: Daniel AJ Sokolov)

Die Camera-App hingegen wertet Kalender- und Links aus QR-Codes datenschutzfreundlich auf dem Gerät selbst aus, ohne Internetverbindung. Für diese App hat Google in der Nacht auf Samstag ein Update in den Play Store gestellt, das für alle Pixel-Handys mit Android 12 verfügbar ist (App-Versionsnummer beginnend mit 8.4.400). Damit möchte das Unternehmen die Fehler bei der Auswertung von QR-Codes beheben.

Gelungen ist das nur teilweise: Googles Camera-App liest URLs, soweit heise security auf den ersten Blick feststellen konnte, nun korrekt aus. Kalendereinträge aus QR-Codes sind jedoch nach wie vor um 28 bis 31 Tage plus/minus ein paar Stunden falsch. Womöglich liegt dieser Bug nicht in der Kamera-App, sondern beim Google Calender. Sicherheitsrelevant ist dieser Fehler nicht, mag er auch ärgerlich sein.

Auf den heise-security-Bericht über die sicherheitsrelevanten Link-Fehler beim Auslesen von QR-Bugs hat Google also sehr schnell reagiert. Doch stellt sich heraus, dass Google von den Problemen spätestens seit Frühjahr 2021 wusste. Damals meldete der kanadische Sicherheitsberater Louis Dion-Marcil, im Brotberuf bei Mandiant tätig, das Problem an Google. Er hatte es mit Pixel 4 und 5 unter Android 11 entdeckt.

Doch am 11. Juni 2021 änderte der Datenkonzern den Status der Meldung auf "Won't Fix (Intended Behavior)" (etwa: Das korrigieren wir nicht, weil es absichtlich so gemacht ist). Diese Einstufung ist absurd und wohl einer beschränkten Auswahl an Statuseinstellungen geschuldet. "Wir haben beschlossen, dass das von Ihnen gemeldete Problem nicht schwerwiegend genug ist, um es als Sicherheitsproblem zu verfolgen", schrieb das Google Bug Hunter Team damals an Dion-Marcil, ohne das Google Security Team auf den Bug hinzuweisen.

Die erstaunliche Begründung: Es stelle keinen Sicherheitsgewinn dar, würden Google-Handys ihre Nutzer nicht mehr auf falsche Webseiten leiten. Eine unter der falschen Adresse lauernde Phishing- oder Betrugsseite sei Social Engineering, gegen das Google nach eigenen Richtlinien wenig unternimmt. Geheimnis des Sachbearbeiters bleibt, warum er den doch so harmlosen Bug in der Datenbank nicht öffentlich einsehbar hält.

Googles Algorithmen löschen unter Umständen nicht bloß ein paar Zeichen am Ende einer Top-Level-Domain (TLD) und sehr kurze Linktexte rechts davon. Abhängig von der TLD kommt es vor, dass Google die gesamte Top Level Domain des http(s)-Links und weitere Zeichen des Second-Level-Teils löscht, wenn der Second Level drei bis fünf Zeichen aufweist und der Third Level relativ lang ist (neun Zeichen bei https-Links, zehn Zeichen bei http-Links).

So rufen die betroffenen Handys statt https://dasisttoll.mega.tt einfach https://dasisttoll.me auf; aus https://dogbetter.cats.co wird https://dogbetter.ca. Die Liste betroffener TLD ist sehr lang. Alleine unter den mit a beginnenden Ländercodes (ccTLD) konnten wir den Bug bei .ac, .ae, .af, .ag, .al, .ao, .aq, .as, .aw und .az nachstellen. Die Liste der betroffenen Second Level Domains ist extrem lang – entscheidend ist, dass die ersten zwei bis drei Stellen einer bekannten TLD entsprechen. Beispielsweise würde aus https://yellowribbon.mila.sx ein Hyperlink zur US-Militär-Seite https://yellowribbon.mil.

Der Originallink muss nicht unbedingt auf eine zweistellige ccTLD enden – beispielsweise mit .bio, .icu, .tel, .wtf und .xxx tritt Googles Software ebenfalls fehl. Folgt rechts der TLD noch kurzer Linktext, tritt der Bug manchmal nicht auf, manchmal schon. Wer seine Camera-App noch nicht upgedatet und Lust hat, selbst mit TLD zu experimentieren, mag sich von der öffentlichen Suffix-Liste inspirieren lassen.

Sicherheitsforscher Adrian Dabrowski von der University of California Irvine hatte entdeckt, dass Googles Camera-App bei http(s)-Links in QR Codes einen Punkt vor jede Ziffer stellt, die nach der Zeichenfolge www steht. So wird https://www1.nyc.gov zu https://www.1.nyc.gov. Bei weiteren Versuchsreihen hat heise security nun festgestellt, dass dies nicht nur Ziffern betrifft, sondern bei allen möglichen Zeichenfolgen nach "www".

Hier macht Googles Algorithmus in der Camaer-App (vor dem Update) aus https://www-foo.de den technisch unmöglichen Link "-foo.de". Domainnamen dürfen gar nicht mit "-" beginnen.

(Bild: Daniel AJ Sokolov)

Weil das keineswegs nur Subdomains (wie das "www1" bei www1.nyc.gov) betrifft, stellt diese erweiterte Fehlergruppe ein kleines Sicherheitsrisiko dar. Denn es gibt auch registrierte Domainnamen, die mit www beginnen. Beispielsweise hat heise medien neben heise.de auch wwwheise.de registriert, was von Googles Camera-App zu www.heise.de umgewandelt wird.

In dem Fall tut das nicht weh. In anderen Fällen muss der Inhaber von bar.foo aber nicht derselbe sein, wie jener von wwwbar.foo. Wieder könnten Nutzer fehlgeleitet werden. Das Sicherheitsrisiko ist bescheiden, doch wirklich unnötig: Da QR-Codes starke Fehlerkorrektur eingebaut haben, ist ein Algorithmus, der das Leseergebnis zu korrigieren sucht, keine schlaue Idee.

Immerhin: Während "www" als Subdomain extrem verbreitet ist, sind Domainnamen, die direkt mit der Zeichenfolge www beginnen, selten. Nach Auskunft der österreichischen Registry nic.at sind bei ihr 273 Domains registriert, die mit www beginnen – das sind knapp 0,2 Promille der .at-Domains. Die kanadische CIRA hat heise online verraten, 527 solche Registrierungen zu haben – ebenfalls rund 0,2 Promille.

Bei .xyz, der vielleicht größten TLD jüngerer Generation, konnten wir selbst das gesamte Zone-File analysieren. Wie sich zeigt, beginnen etwa 3900 Domains mit der Zeichenfolge www. Das liegt in der Größenordnung von einem Promille aller .xyz-Domains.

Bei all der Verschlimmbesserung haben Googles Algorithmen nicht realisiert, dass Domainnamen nicht mit "-" beginnen dürfen. Die App findet nichts dabei, den real möglichen Link https://www-foo.de zum unmöglichen https://-foo.de zu verstümmeln. Immerhin ist das nicht einmal ein kleines Sicherheitsrisiko: Der Aufruf der Seite schlägt dann nämlich fehl.

(ds)