In bald 25 Jahren habe ich eine Vielzahl an Schwachstellen in bekannten und weniger bekannten Produkten gefunden. Dabei folge ich dem Leitfaden unseres Unternehmens, dass eine Zusammenarbeit mit dem Hersteller und dadurch eine koordinierte Veröffentlichung angestrebt wird. Dieser Beitrag diskutiert eine kuriose Schwachstelle in iPhones, bei der Apple nicht zu einer Zusammenarbeit gewillt war.

Als Youtube auf einem iPhone XS mit iOS 12.3.1 genutzt wurde, wurde plötzlich Siri aufgerufen. Es schien, als hätte Siri den Aufruf Hey, Siri gehört und darauf reagiert. Im gesehenen Video war aber kein entsprechender Aufruf enthalten. Zuerst gingen wir davon aus, dass es sich um einen Zufall handeln sollte.

Mehrere Wochen später trat dieser Effekt erneut bei einem anderen Video auf. Dieses Mal wurde das Gerät jedoch in der Hand gehalten und der Effekt konnte ebenfalls bei einem liegenden Gerät beobachtet werden. Auch beim zweiten Video war kein Aufruf von Siri enthalten. Es schein, als wäre hier ein self-reference Angriff möglich.

Analyse der Schwachstelle

Das erste Mal ist der Effekt aufgetreten, als das Handy im Liegen an den Hals gehalten wurde. Das Auslöser-Video war 10 Game Company Decisions That BACKFIRED BADLY bei Position 7:30. Als es um die Reproduktion der Schwachstelle ging, sollte sich dies dann auch als zentrales Element erweisen. Nur wenn das Gerät richtig positioniert war, wurde der Aufruf von Siri erfolgreich umgesetzt.

Die erste Vermutung war, dass die Position bzw. der Abstand wichtig sein sollte. Es wurde davon ausgegangen, dass die Reflektion des Schalls ausserhalb und innerhalb des Gehäuses für den Aufruf verantwortlich war.

Als das Problem einige Wochen später wieder auftrat, waren die Gegebenheiten ein bisschen anders. Dieses Mal war das Auslöser-Video Terminator T-900 Explained bei Position 3:38. Und der Effekt trat nicht in der gleichen liegenden Position auf. Stattdessen war dieser (auch) zu beobachten, wenn das Gerät im Querformat in den Händen gehalten wurde. Es sollte sich herausstellen, dass es auch auf den Tisch gelegt werden konnte.

Interessanterweise trat der Effekt nur dann auf, wenn die Laufstärke auf Position 1 oder 2 war. Sobald das Gerät lauter geschaltet wurde, blieb der Siri-Aufruf aus. Ein Grund für diese Eigenschaft könnte sein, dass die Stimmerkennung bei leisen Quellen anders funktioniert. Dass eventuell Frequenzen verstärkt oder Lücken selbstständig gefüllt werden, wodurch der vermeintliche Siri-Aufruf zustande kommt.

Möglichkeiten eines Angriffs

Selbstreferenzierende Eingaben sind nichts neues, wie wir schon am Beispiel der Gestenerkennung von Samsung Smart-TVs aufgezeigt haben. Dort wurde es möglich, dass eine Filmaufnahme dank einer Reflektion eine Eingabe auf sich selbst auswirkt.

Im Zusammenhang mit Siri wird dies dahingehend spannend, weil ein entsprechendes Audio-Konstrukt unter Umständen Siri steuern kann. Dadurch können sämtliche Möglichkeiten erschlossen werden, die mit Siri aufgetan werden. Dies reicht von der Anzeige von Informationen über das Speichern von Inhalten bis hin zu Anpassungen von Einstellungen.

Kontaktaufnahme zu Apple

Um dem Responsible Disclosure Prozess zu folgen, haben wir Apple vorgängig am 10. Juli 2019 per Email über unsere Entdeckung informiert. Wir haben die beiden Testcases (inkl. Links zu den Videos) mitgeschickt.

During some experimental testing we were able to let YouTube videos call Siri on the same device. This should usually not be possible. (…) It looks like some resonance disturbance (within the case) is responsible for this effect. An attacker might be able to create a video with controls a device.

Tags darauf hat das Apple Security Team geantwortet. Dieses weist darauf hin, dass der Sachverhalt zwar existiert, aber nicht als Risiko gewertet wird:

After examining your report we do not see any actual security implications. “Hey Siri” is meant to make your voice more recognizable for Siri, not limit access to Siri for only your voice.

Hier zeichnet sich ab, dass der Angriffsvektor und die damit einhergehenden Möglichkeiten nicht verstanden wurden.

Falls der Hersteller eine Schwachstelle nicht anerkennen oder beheben will, streben wir eine Veröffentlichung an. Durch den öffentlichen Druck können wir in der Regel eine Behebung erzwingen. In diesem Fall waren wir entsprechend um die Zuweisung einer CVE durch MITRE bemüht. MITRE wies uns aber darauf hin, dass Apple selber eine CNA (CVE Numbering Authority) sei, nur sie zur Generierung von CVEs für Apple-Produkte berechtigt sind und uns deshalb MITRE keine CVE zuweisen kann.

Indirekt zeigt dies auf, dass durch die Möglichkeit der Hersteller, selber als CNA zu fungieren, ein wichtiges Element bei der Veröffentlichung von Schwachstellen aus der Hand gegeben wurde. Uns blieb somit nur die Möglichkeit, eine eigenständige Veröffentlichung ohne CVE anzustreben.

Mittlerweile ist iOS 13 erschienen. Und auf dem selben Gerät können die Effekte der beiden Videos nicht mehr nachvollzogen werden. In den seit der Entdeckung veröffentlichten Security Advisories finden sich keine Hinweise auf den Effekt und etwaig etablierte Massnahmen. Wir müssen deshalb davon ausgehen, dass Apple das Problem unwissentlich oder gar heimlich gelöst hat. Wir empfehlen entsprechend ein Update auf iOS 13. Dies ist leider schon die zweite Zusammenarbeit in Bezug auf die Veröffentlichung einer Schwachstelle mit Apple, bei der es zu unnötigen Reibungspunkten gekommen ist.

Fazit

Die gefundene Schwachstelle ist kurios und exotisch. Und die Geschichte, wie diese gefunden wurde zeigt einmal mehr, dass manche Schwachstellen durch Zufall gefunden werden können. Der Grund für den Effekt konnten wir bis heute nicht zweifelsfrei ausmachen. Ob es nun auf akkustische Reflektionen oder die Resonanz im Gehäuse zurückzuführen ist, ist uns nicht bekannt.

Die fehlende Kooperationsbereitschaft von Apple hat jedenfalls enttäuscht. Und dass das Problem bei neueren Versionen von iOS plötzlich nicht mehr existiert, aber nirgends ein Vermerk dazu zu finden ist, hinterlässt einen fahlen Beigeschmack. Dies ist genau das Verhalten, das die No More Free Bugs Bewegung vor 10 Jahren befeuert hat und auch heute noch dazu führen kann, dass der eine oder andere lieber auf die undankbaren Reibungen von Responsible Disclosure verzichtet.

Über den Autor

Marc Ruef ist seit Ende der 1990er Jahre im Cybersecurity-Bereich aktiv. Er hat vor allem im deutschsprachigen Raum aufgrund der Vielzahl durch ihn veröffentlichten Fachpublikationen und Bücher – dazu gehört besonders Die Kunst des Penetration Testing – Bekanntheit erlangt. Er ist Dozent an verschiedenen Fakultäten, darunter ETH, HWZ, HSLU und IKF. (ORCID 0000-0002-1328-6357)

Links

• https://cve.mitre.org/cve/request_id.html
• https://cve.mitre.org/cve/request_id.html#cna_participants
• https://support.apple.com/en-us/HT201222
• https://threatpost.com/no-more-free-bugs-software-vendors-032309/72484/
• https://www.computec.ch/mruef/?s=publikationen&l=d
• https://youtu.be/ClbQwjMtQSU
• https://youtu.be/SWrkw_W8YdI