2090505

OS X und iOS: Forscher kritisieren Sicherheit

17.06.2015 | 16:00 Uhr |

Sechs Sicherheitsforscher kritisieren Apples Sicherheitsmechanismen: Sie wollen schwerwiegende Lücken gefunden haben.

Die sechs Forscher Luyi Xing, Xiaolong Bai, Tongxin Li, Xiao Feng Wang, Kai Chen, Xiaojing Liao der Indiana University in den USA und der Peking University in China haben die Struktur von Sicherheitsmechanismen wie Schlüsselbund oder Sandbox in OS X und Apples URL-Protokoll für die Kommunikation zwischen iOS-Apps untersucht und wollen dabei mehrere Angriffsmöglichkeiten gefunden haben. Apple haben die Forscher nach eigenen Angaben bereits im Oktober 2014 über ihre Funde informiert.

Angeblich anfälliger Schlüsselbund (OS X)

Die Computerwissenschaftler wollen beispielsweise Angriffsflächen in Apples Schlüsselbund (unter OS X) gefunden haben. Es sei ihnen möglich gewesen, mit Hilfe einer eigenen App Passwörter und Zugriffstokens für iCloud und weitere Dienste auszulesen. Eine der Sicherheitsmängel im Schlüsselbund sei, dass es durch Tricks möglich sei, dass eine Anwendung den Schlüsselbundeintrag einer anderen für sich beanspruchen könne.

Einschätzung der Gefahr

Walter Mehl : Ich kann mir bei dieser Beschreibung das nachfolgende Szenario vorstellen.

Die bösartige App legt einen Eintrag im Schlüsselbund an und gibt sich beispielsweise als Evernote aus. Installiert man später Evernote, erkennt die neue App, dass bereits eine „ältere Version“ von Evernote Daten im Schlüsselbund hinterlegt hat und hängt die tatsächlichen Zugangsinformationen (Benutzername und Kennwort bzw. „Evernote Security Token“) an das vorhandene Zeug im Schlüsselbund an. Wenn das in dieser Reihenfolge geschieht, kann die böswillige App die Daten von Evernote lesen und beispielsweise über Internet verschicken. Bei diesem Szenario gibt es aber wichtige Beschränkungen: Apples Review-Team muss die böswillige App zunächst im Mac App Store freigeben, so dass der Nutzer die App ohne Bedenken herunterladen kann. (Hier stoßen die Verbrecher an die erste Hürde, da die Klon-Apps gegen Apples Richtlinie 2.11 verstoßen und meistens abgewiesen werden - Anm. d. Red.)

Die Reihenfolge der Installationen ist auch ausschlaggebend: Die böswillige App muss vor der Original-App auf dem OS X installiert werden, ansonsten funktioniert der Angriff nicht.

Mögliche Schwachstelle des Sandboxings (OS X)

Die Forscher beschreiben zudem Lücke mit der sich die systemseitige Trennung von Mac Apps durch das so genannte Sandboxing umgehen ließe. Denn Sub-Programme - kleinere Dienste oder Helper von Mac-Apps - würden nicht auf die gleiche Weise eingesperrt. Diese Tools könnten - anders als Mac Apps - beliebige IDs tragen und so auch die bereits bestehende ID einer Mac App verwenden. Dies führe hinzu, dass boshafte Dienste die ID eines bereits installierten Dienstes übernehmen und so Zugriff auf dessen Sandbox bekommen könnten, so die Forscher.

Einschätzung der Gefahr

Walter Mehl:   Über gemeinsame Hilfsprogramme, wie zum Beispiel den Dropbox-Zugriff, können zwei Programme Daten austauschen. Leider bekommen damit beide Programme Zugriffsrechte auf das Hilfsprogramme und damit auch den gegenseitigen Zugriff auf den Container mit allen Voreinstellungen der beiden Programme. Das bösartige Programm kann über das Hilfsprogramm die Daten des Originals lesen. Auch hier greifen die beiden Beschränkungen - Das verbrecherische Programm muss die Überprüfung in dem App Store bestehen; das böswillige Programm muss vor dem Ursprungsprogramm installiert werden.


URL-Schemata (iOS)

Die sechs Forscher kritisieren zudem Mängel an der URL-Übergabe ("URL-schemes"), mit der der iOS-Apps Parameter an andere Apps übergeben können. Sicherheitsforscher warnen App-Entwickler bereits seit langem, dass solche URLs keine sicheren Methoden sind, um kritische Daten zu übergeben. Einfache Beispiele solcher URL-Befehle sind "tel:", womit Telefonnummern an die Telefonapp übermittelt werden oder "maps:", womit beispielsweise Koordinaten an Google Maps übermittelt werden können. Die Forscher kritisieren, dass Apps beliebige URL-"Vorwahlen" für sich beanspruchen können (außer denen, die für Systemapps registriert sind). iOS kontrolliere nicht, ob ein Schema bereits vergeben ist oder zu einer anderen, bekannten App gehöre. So hätten die Forscher es geschafft, eine Fake-App in den App Store zu bekommen, die ein spezielles URL-Muster für sich beansprucht und so das Facebook-Login-Token abgefangen, das die Pinterest-App von der Facebook-Login-API abgefragt hatte.

Ortwin Gentz: Entwickler-Kommentar zu der iOS-Schwachstelle

Das beschriebene Problem existiert definitiv und die Attacke auf das Facebook Single-Sign-On-Verfahren aber auch auf andere Dienste wie Google Sign-On über den Browser sind plausibel. Das Facebook Single-Sign-On-Verfahren erspart dem Benutzer die Registrierung für neue Dienste und nutzt stattdessen das Facebook-Login. Bei diesem Verfahren wird zwischen der aufrufenden App und der Facebook-App mithilfe von URLs hin und her gewechselt. Nach Autorisierung übergibt Facebook der aufrufenden App ein Zugriffstoken. Beide URL-Schemas, das der Facebook-App und das der aufrufenden App könnte eine böswillige App für sich beanspruchen und damit Zugriffstoken oder sogar das Facebook-Passwort des Benutzers ausspähen.

Leider ist das Problem nicht einfach zu beheben. Apple müsste dem Entwickler die Möglichkeit geben, zu prüfen, welche App ein bestimmtes URL-Schema registriert hat. Dies erfordert aber eine Veränderung an allen Apps, die per URL sicherheitsrelevante Informationen austauschen. Ich nehme daher an, dass im ersten Schritt bei der Überprüfung der Apps verschärfte Kontrollen bezüglich der Registrierung von URL-Schemas durchgeführt werden. Ob damit alle denkbaren Trojaner-Attacken verhindert werden können, ist jedoch fraglich.

Ortwin Gentz ist Entwickler der Branchensuche-App " Wohin? " und der Street-View-App " Streets ".

Insgesamt wollen die Forscher Hunderte, oft bekannte Mac- und iOS-Apps gefunden haben, die durch solche Angriffe Passwörter, Login-Tokens oder andere sensible Daten verraten würden. Die Forscher sehen die Verantwortung primär bei Apple, vor allem müsse der Hersteller die Verantwortung zwischen dem System und den App-Entwicklern bei der Verifizierung der erlaubten Daten-Anfragen klar definieren und den Entwicklern zusätzliche Tools und Dokumentation hierfür liefern.

0 Kommentare zu diesem Artikel
2090505