Googles Kamera verfälscht Links in QR-Codes

Künstliche Intelligenz + QR Codes = Chaos. Googles Camera-App erzeugt unter Android 12 falsche Links – eine Einladung für freche Attacken.

Lesezeit: 13 Min.
In Pocket speichern
vorlesen Druckansicht Kommentare lesen 374 Beiträge
Infografik zeigt zweimal den selben QR-Code. Links wird darin ein Link heise.net.at erkannt, rechts ein Link https://heisenet.at

Suchbild: Wer findet den Unterschied? Links ein Screenshot der Google Camera App auf einem Pixel 5, rechts ein Screenshot der App QR Barcode von BondRen auf dem selben Handy.

(Bild: Daniel AJ Sokolov)

Von
  • Daniel AJ Sokolov
Inhaltsverzeichnis

QR-Codes in freier Wildbahn sind grundsätzlich verdächtig – besonders Misstrauen ist angezeigt, wenn man sie mit der Camera-App eines Pixel-Handys unter Android 12 ausliest. Algorithmen der App verändern beim Auslesen von QR Codes darin enthaltene Links leicht und schlagen dann sehr ähnliche, aber falsche Webadressen zum Öffnen vor. Ein Klick, und der User landet bestenfalls bei einer Fehlermeldung, schlimmstenfalls direkt in den Armen eines gewieften Angreifers.

Der Grund für den Bug ist nicht unmittelbar deutlich. Ein Zusammenhang mit optischen URL-Verkürzungen, die sich in Googles Chrome-Browser eingenistet haben, drängt sich auf. Vielleicht verschlimmbessert ein Algorithmus auch nur vermeintliche Tippfehler. Dabei sind die quadratischen QR-Codes gerade dazu gedacht, Abschreibfehler bei der Weitergabe von Information zu vermeiden.

heise security konnte das Fehlverhalten mit Pixel-Handy-Modellen 3 XL, 3a, 4, 4a, 5, und 6 Pro dokumentieren – allerdings nur mit Android 12. Ein Pixel 3a wies den Fehler unter Android 11 nicht auf, nach Update auf Android 12 schon. Bei Geräten anderer Hersteller haben wir das Problem bislang nicht beobachten können. Nicht betroffen sind, soweit wir gesehen haben, Links für andere Protokolle als http(s), also zum Beispiel ftps oder mailto. Wird gar kein Protokoll angegeben, variieren die Ergebnisse.

Der erste Fehler betrifft http(s)-Links bestimmter Länderdomains (ccTLD), egal ob sich der Link auf den Domainnamen beschränkt (https://fooco.at) oder nach dem Domainnamen noch Linktext folgt, der auf ein Verzeichnis oder Dokument verweist (https://fooco.at/bar/index.htm). Endet der von hinten gelesen zweite Teil der Domain (second level) auf eine bestimmte Zeichenfolge, stellt Googles Camera-App vor die Zeichenfolge einen Punkt, obwohl der im QR-Code kodierte Hyperlink gar keinen Punkt enthält. So wird https://www.fooco.at/hello plötzlich zu https://www.foo.co.at/hello. Optisch dargestellt wird überhaupt nur foo.co.at/hello.

Betroffen sind neben .at zumindest auch die Länderzonen (ccTLD) .au, .br, .hu, .il, .kr, .nz, .ru, .tr, .uk und .za. Zu den betroffenen Zeichenfolgen am Ende des Second Level gehören beispielsweise co, com, ac, net, org, gov, mil, muni und edu, nicht aber or, gv oder k12. Ein hypothetischer Link https://foonet.uk/verysecure, kodiert in einem QR-Code, würde den User zum Öffnen der Seite https://foo.net.uk/verysecure verleiten. Gehört die Domain einem Dritten, könnte dort Malware lauern, Falschinformation verbreitet werden oder ein Phisher auf Eingabe echter Zugangsdaten für foonet.uk-Konten hoffen.

Gefeit wirken http(s)-Links, die internationale Domainnamen (IDN) mit entsprechenden Unicode-Sonderzeichen enthalten – wir haben aber nicht alle Varianten durchprobiert. Ziffern im Domainnamen bieten hingegen keinen Schutz.

Wer findet den Unterschied? Oben der korrekt ausgelesene QR-Code, unten das Ergebnis mit Google Camera unter Android 12.

(Bild: Daniel AJ Sokolov)

Auf die Spur gebracht hat uns der in einer Google-Datenbank einsehbare Fehlerbericht eines österreichischen heise-Lesers: Dessen Arbeitgeber sucht Mitarbeiter und hat Anzeigen mit QR-Code veröffentlicht. Der Code führt direkt zu einer Webseite mit Jobangeboten – es sei dann, man liest den QR-Code mit einem Pixel-Handy mit Android 12 aus. Denn der Firmenname und somit die unter .at registrierte Domain endet auf eine der unvorteilhaften Zeichenfolgen. Die App streut einen falschen Punkt ein, der Link führt ins Leere, und das Geld für die Anzeigenkampagne verpufft.

Der Bug wirkt sich abhängig vom Schema der Top-Level-Domain unterschiedlich aus. Bei .at kann jedermann eine Domain unter co.at registrieren. Ein Angreifer könnte also foo.co.at registrieren, wenn er sieht, dass QR-Codes mit Links zu https://fooco.at/superjobs im Umlauf sind. Bei .ru sind Domainregistrierungen unter com.ru und org.ru möglich. Die traditionellen Beschränkungen bei .uk sind 2019 gefallen, sodass neben foonet.uk auch foo.net.uk bestehen und einen anderen Inhaber haben kann. Ziemlich geschützt ist .tr, wo keine Second-Level-Domains vergeben werden. Bei .au hingegen werden ab 24. März Second-Level-Domains feilgeboten.

Googles Camera-App wertet QR-Codes nur dann aus, wenn die Option "Google Lens Suggestions" aktiviert ist – dann aber oft fehlerhaft. Obskur ist, dass der Fehler in der Google-Lens-App selbst nicht auftritt. Ein Workaround ist also, die "Google Lens Suggestions" in der Camera-App zu deaktivieren und stattdessen die App Google Lens oder gleich eine unabhängige QR-Scan-App zu verwenden – sofern man auf das Auslesen der QR-Codes in freier Wildbahn nicht verzichten kann. Denn selbst wenn ein QR-Code korrekt ausgelesen wird, ist oft nicht gesichert, dass der Code nicht von einem Dritten angebracht wurde und in die Irre leiten soll.

Google vertreibt seine Pixel-Handys zurzeit nur in ausgewählten Märkten. Die Chance, dass ein QR-Code einen Pixel-User in die Irre führt, ist also in Großbritannien größer als in Österreich oder Russland. Natürlich gibt es in diesen Ländern Grauimport der Geräte, unter anderem aus Deutschland.

Im Zuge der empirischen Untersuchung der zusätzlichen Punkte fand heise security eine zweite Fehlergruppe. Sie betrifft http(s)-Links mit bestimmten Top-Level-Domains, die länger als zwei Zeichen sind. Bei einer ganzen Reihe lässt die Künstliche Intelligenz der Camera-App eines oder mehrere Zeichen der Top-Level-Domain und gegebenenfalls auch des rechts davon stehenden Linktextes unter den Tisch fallen. So verweist ein Link auf die Webseite der katalanischen Unabhängigkeitsabstimmung https://referendum.cat Google-User unerwartet auf die kanadische Adresse https://referendum.ca.

Das widerfährt auch zahllosen anderen .cat-Domains. In ähnlicher Weise wird .int für internationale Organisationen zu .in (Indien), .pro zu .pr (Puerto Rico), oder .travel zur türkischen .tr-Zone verkürzt. Statt auf eine .apple-Domain zu verweisen, leitet die App lieber auf .app um, statt bei .amex kann man in Armenien (.am) landen, und wer .bet oder .beer sucht, muss eventuell mit Belgien (.be) vorliebnehmen.

Und so weiter. .ar und .au entpuppten sich in den heise-security-Versuchen als Fehlkürzungen für eine ganze Reihe junger TLD wie .army, .art, .arte und .arab respektive .audi, .audio, .auto und .autos. Im Unterschied zur ersten Fehlergruppe sind auch IDN-Domainnamen betroffen.

Fehlt da nicht was?

(Bild: Daniel AJ Sokolov)

Nicht verstümmelt wurden bei unseren Versuchen zur Fehlergruppe 2 Hyperlinks, die rechts der TLD vier oder mehr weitere Zeichen (inklusive / ) aufweisen, etwa https://edu.audi/F103. Manchmal reichten aber auch schon zwei Zeichen, etwa https://gas.audi/f, um korrektes Auslesen zu erzwingen. In anderen Fällen löschte Googles Kamera-Algorithmus nicht nur die letzten Stellen der TLD, sondern auch kurzen Linktext rechts davon. https://hellonet.art/12 wurde so zu https://hellonet.ar zerhackt. https://hellonet.arte/12 wurde korrekt übertragen, während https://hellonet.arte/1 zu https://hellonet.ar schrumpfte.

Die Zeichen links der TLD beeinflussen Googles Künstliche Intelligenz ebenfalls. So lief bei https://www.audi, und https://net.art/12 alles korrekt, während https://edu.audi zu https://edu.au, https://234.audi zu https://234.au und https://ipv4only.art/12 zu https://ipv4only.ar verkamen. Manchmal hat die Camera-App Links mit "foo" korrekt ausgelesen; haben wir "foo" durch "ipv4only" ersetzt, löschte die App bisweilen wieder Zeichen an der TLD. Die Zeichenfolge ipv4only haben wir uns übrigens von der Zone ipv4only.arpa ausgeborgt.

Bei unserer Untersuchung wurde heise security von Adrian Dabrowski, einem Sicherheitsforscher der University of California Irvine, unterstützt. Er entdeckte nach unserem Hinweis ein weiteres verbundenes Problem: Die App stellt bei der Auflösung von http(s)-Links in QR Codes einen Punkt vor eine Ziffer, die nach der Zeichenfolge www steht. Beispiel: Die Royal Bank of Canada nutzt für einen Online-Banking-Dienst https://www6.rbc.com – eine technisch einwandfreie Adresse. Aus einem QR-Code ausgelesen, verlinkt Googles Camera-App fälschlich auf https://www.6.rbc.com, was zu einem 404-Fehler führt.

Lesen Sie auch

Das Schema scheint bei Kanadas Banken beliebt zu sein. Wir haben bei dortigen Finanzinstituten mehrere ähnliche Adressen gefunden, die wir per QR-Code und Google-Camera kaputt machen konnten. Selbstredend raten wir davon ab, Online-Banking über einen QR-Code aufzurufen, den man nicht selbst erstellt hat – unabhängig von den hier beschriebenen Fehlern einer bestimmten Applikation.

Als eher in öffentlich angebrachten QR-Codes anzutreffende URL sei https://www1.nyc.gov erwähnt, die offizielle Webseite der Stadt New York. Die Adresse verkommt bei der Camera App zu https://www.1.nyc.gov, was nicht auflöst. Diese Fälle von www+Ziffer sind relativ selten, und man ist versucht, kaum ein Sicherheitsproblem zu erkennen.

Allerdings lässt sich Fehler 3 mit Fehler 1 oder Fehler 2 koppeln. Aus https://www2co.at wurde, erraten, https://www.2.co.at – die App spendiert gleich zwei unwillkommene Trennpunkte, sodass aus einer Two-Level-Domain eine Four-Level-Domain wird. Da wird es schwer, den Durchblick zu bewahren. Kurze Linktexte rechts der TLD schützen ebenso wenig wie Unicode-Sonderzeichen im Domainnamen. Aus https://www2.arte/24 wird übrigens https://www.2.ar. Alle Klarheiten beseitigt?

Sicherheitsforscher Dabrowski hegt den Verdacht, dass die Fehler bei der Auswertung der QR-Codes mit einem umstrittenen Google-Projekt zusammenhängen: Dem Verkürzen der in der Adresszeile des Chromium- beziehungsweise Chrome-Browsers angezeigten URLs. Dort versteckt Google seit einiger Zeit Adressteile wie https:// und www. Technisch müssen diese Adressteile aber erhalten bleiben, zumal der Webserver unter https://www.foo.at nicht derselbe sein muss, wie unter https://foo.at.

"Im Interface der Camera-App ist nicht viel Platz für die Anzeige der URL", stellte Dabrowski fest, "Daher ist es nachvollziehbar, dass die Einblendung dort auf ein Minimum getrimmt wird. Allerdings darf das keine irreleitenden Fehler hineintragen – und schon gar nicht verkürzte Adressen an den Browser übergeben, wie das jetzt passiert." Alle beschriebenen Fehler traten übrigens auch dann auf, wenn auf dem Pixel-Handy ein anderer Browser als Chrome als Standardanwendung eingestellt war – am Browser liegt es also nicht.

Dass bestimmte Handys QR-Codes anders interpretieren als andere Mobiltelefone, ist für Dabrowski übrigens nichts Neues. Der Forscher hat bereits 2014 demonstriert, dass sich ein kleiner QR-Code in einem größeren QR-Code einnisten lässt. Manche Endgeräte lesen den kleineren Code aus, andere den größeren, wobei sie den kleineren dank Redundanz im QR-Code ignorieren können. Wer die Geräte der Enduser kennt, kann eine Attacke designen, die bei ausgewählten Zielen wirkt und andere unbehelligt lässt.

Oben gibt es Jobs, unten 404. Der QR-Code ist derselbe.

(Bild: Daniel AJ Sokolov)

Die Fehler sind bislang vor allem störend, weil Seitenaufrufe nicht funktionieren oder umgeleitet werden. Dem österreichischen Unternehmen wird vielleicht die eine oder andere Stellenbewerbung entgehen. In bestimmten Konstellationen lassen sich die Bugs jedoch für Attacken gegen Pixel-Nutzer einsetzen; beobachtet haben wir das bislang nicht.

Endusern empfehlen wir Argwohn gegenüber QR-Codes, die außerhalb geschlossener Systeme auftauchen. Sicherer ist, die neben dem QR-Code angegebenen Daten zu lesen und, bei Internet-Adressen, diese zu prüfen und gegebenenfalls einzutippen. Das Vorhandensein des Klartextes alleine ist allerdings kein Qualitätsmerkmal – schließlich kann ein Übeltäter, der QR-Codes überpickt, auch den Klartext überkleben.

User, die partout nicht auf das automatische Auslesen von QR-Codes verzichten können und derzeit ein Pixel-Handy mit Android 12 nutzen, sollten bis auf Weiteres die "Google Lens Suggestions" der Camera-App ausschalten und eine andere App zum Auslesen von QR-Codes nutzen. Von Applikationen, die in QR-Codes (vermeintlich) erkannte Links sofort öffnen ohne sie vorher anzuzeigen und auf Bestätigung zu warten, raten wir dringend ab. heise security hat Google um Auskunft dazu ersucht, wie es zu den Fehlern kommt, und wann Abhilfe erwartet werden darf.

Wer Unterlagen mit QR-Codes öffentlich in Umlauf bringen möchte, die nicht nur für eine ganz bestimmte, selbst kontrollierte Software vorgesehen sind, sollte zweimal darüber nachdenken, ob das modische Quadrat wirklich notwendig ist. Und ob der Support-Aufwand oder verlorene Kundenkontakt bei fehlgeleiteten Anwendern den Nutzen übertrifft.

Lesen Sie auch

Tunlich ist, neben QR-Codes menschenlesbar anzugeben, was in den Codes versteckt ist. Je nach Verbreitungsweg besteht zwar das Risiko, dass Angreifer den QR-Code und den Text überkleben; solange Text und QR-Code den gleichen Inhalt haben, sind versteckte Angriffe jedoch etwas leichter zu entdecken. Und wenn nichts überklebt wird, besteht immerhin die Chance, dass einem Nutzer auffällt, wenn seine App den QR-Code falsch interpretiert, bevor er die Webseite eines Angreifers aufruft.

(ds)