0.12.4 Android-Permissions, eine Show-Veranstaltung
Die Trennung der Android-Apps untereinander durch unterschiedliche User-IDs und die Freischaltung von zusätzlichen Rechten per Group-IDs ist erstmal eine gute Sache. Aber neben der kompletten Entwertung dieses Systems durch Root gibt es noch weitere Wege, die die Android-Permissions wertlos machen.
Standardmäßig muß der Benutzer alle Permissions während der Installation akzeptieren oder die App kann nicht installiert werden. Manche System erlauben auch die Zuordnung von Einzel-Permissions, aber das ändert das folgende Problem nicht:
Das Zugeständnis von Berechtigungen passiert statisch und punktuell pro App bei der Installation. Die Nutzung der Rechte erfolgt jedoch dynamisch und verteilt und unterliegt nicht vollständig der Kontrolle, die der Benutzer zu haben glaubt, denn es gibt einige offizielle "by design" Möglichkeiten, alle scheinbar nicht erlaubten Dinge zu tun. Android Apps können verschiedene Arten von 2-Wege-Kommunikation verwenden, um in Teamwork die Permissions ad absurdum zu führen.
App Services, Activities und ihre Freunde
Jede Android App kann, ohne daß der Benutzer das direkt sieht oder verhindern könnte, sogenannte "Services" anbieten. Jede Android App kann ebenso ungestört diese Dienste benutzen, um mit der anderen App zu kommunizieren. Services sind offizielle Android APIs für alle Apps.
Die Malware muß nur eine passende App wählen, die den gewünschten Service anbietet.
Da Google legitime Gründe für Inter-App-Kommunikation sah, haben sie Android um verschiedene einfache Arten von Interprocess Communication (IPC) für Apps erweitert, die auf GNU/Linux-Systemen nicht zu finden waren: Binder, Services (oben grad genannt), Intents (kommen gleich) und ContentProviders (für beispielsweise die Contacts). Diese IPC-Arten stehen natürlich auch Malware zur Verfügung, die damit die Permissions umgehen kann.
Wenn Deine Malware keinen Internet-Zugriff hat, könnte sie den passenden Service einer anderen App aufrufen oder sie benutzt einfach den immer vorhandenen eingebauten Browser über einen Intent, um Nachrichten rauszuschicken. Das geht auch unsichtbar im Hintergrund oder wenn das Gerät gesperrt wird. Und dazu benötigt die App keine spezielle Permission. Zum Empfangen muß sich die Malware lediglich für ein URI-Schema, beispielsweise "mybackdoor://" registriert haben, was der Benutzer ebenfalls nicht mitbekommt. Der kontaktierte böse Webserver macht beim Empfang einen Redirect auf die Malware-URI und kann damit Nachrichten an die Malware zurückschicken.
Man kann sich auch etwas mehr Mühe geben und
ohne jede Permission eine Remote-Shell nutzen.
Zum Vergleich: Auf iOS gibt es solch reichhaltigen IPCs nicht. Es gibt ein paar offizielle APIs, um das Adreßbuch zu benutzen und dergleichen, aber eine Kommunikation zwischen Dritt-Apps ist ansonsten wohl aufgrund der iOS-Sandboxen nur über URL-Schemen möglich.
Weiterlesen..
)
