Mobile Bedrohungen

Inhaltsverzeichnis

Als mobile Kommunikationszentrale und Datenspeicher fungieren Smartphones für viele Anwender mittlerweile als Mittelpunkt ihres digitalen Lebens. Damit sind sie auch ins Visier von Spionen und Betrügern gerückt. Die Hersteller versuchen, Angriffen auf die Geräte technisch und organisatorisch Einhalt zu gebieten – mit mäßigem Erfolg.

Banking-App, PayPal-App, Facebook, Mail-Konten, iTunes, WLANs, VPNs: Gelangt das eigene Smartphone unter die Kontrolle von Kriminellen, ist nicht nur die Privatsphäre futsch, es droht auch ein finanzielles Desaster. Die Konzentration von Finanz- und Zugangsdaten macht das Smartphone für Kriminelle zur lukrativen Zielscheibe. Selbst das Belauschen von Telefongesprächen und das heimliche Umfunktionieren des Smartphones in eine Abhörwanze oder eine Überwachungskamera ist mit speziellen Apps machbar. Sogar die nahezu ausgestorbenen Dialer werden wieder zum Thema, die ohne Zutun des Anwenders überteuerte Nummern anwählen. Zugleich sind die Geräte mobile Datenspeicher, die man verlieren kann oder die einem gestohlen werden können. Gerade für Unternehmen ist das Ausspionieren von Geschäftsinformationen ein nicht zu unterschätzendes Risiko.

Der iPhone-Hersteller Apple und Android-Anführer Google haben versucht, einer Entwicklung wie auf Windows-PCs vorzubeugen und ihre Plattformen gleich vorab mit diversen Sicherheitsfunktionen versehen. Sie sollen die verschiedenen Einfallstore für Hacker, Viren und Betrüger blockieren. Doch können sie einen Einbruch ins Gerät wirklich verhindern?

Üblicherweise übernimmt ein Angreifer die Kontrolle über ein Gerät, indem er eine spezielle Software einschleust und diese fernsteuert. Grundsätzlich kann derartige Software per Bluetooth, MMS-Nachrichten, E-Mail, per Download oder über Sicherheitslücken in ein Gerät gelangen. Der beliebteste Weg von Malware auf Smartphones ist aktuell der manuelle Download durch den Anwender selbst, indem der Angreifer seine mit Spionage- oder Fernsteuerfunktionen ausgestattete Software als vermeintlich nützliche „Muss-man-unbedingt-haben“-App tarnt. Dabei haben Betrüger leichtes Spiel: iPhone und Android erreichen ihre Popularität durch die Fülle von Apps für fast jeden Anwendungsfall – und in der Masse fallen bösartige Apps weniger auf. Auf PCs ist Software aus Quellen, deren Seriosität und Integrität sich nur schwer nachvollziehen lässt, ein Jahrzehnte altes, ungelöstes Problem.

Trau, schau, wem!

Trau, schau, wem!

Apple versucht Malware-Apps auf dem iPhone einen Riegel vorzuschieben, indem Anwendern nur die Installation von Programmen über einen kontrollierbaren Weg erlaubt ist: den App Store. Nur registrierte Hersteller und Entwickler dürfen dort ihre Apps zum Download feilbieten. Zudem unterzieht Apple die Apps einer kurzen Prüfung, ob sie sich an die Geschäftsbedingungen halten, sprich auf den Geräten keinen Unfug anstellen. Wie eingehend diese Prüfung ist, verrät Apple nicht. Sicherheitsspezialisten vermuten, dass Apple die eingereichten Binärdateien einer kurzen statischen und dynamischen Analyse unterzieht. Dabei schaut Apple, ob die App unerlaubte API-Aufrufe nutzt oder auf unerlaubte Ordner, Daten anderer Anwendungen oder Ressourcen zugreift. Ob dies Malware wirklich draußen halten kann, darf bezweifelt werden. So sind einige Fälle dokumentiert, in denen Apps persönliche Daten sammelten und an den Server der Entwickler schickten.

Im Juli 2008 wurde beispielsweise das Spiel „Aurora Feint“ aus dem App Store entfernt, weil es sämtliche gespeicherten Kontaktdaten zum Herstellerserver hochlud, um Vergleiche anzustellen, ob Freunde ebenfalls das Spiel spielten. Im August 2009 wurde bekannt, dass Spiele des Herstellers Storm8 sowohl die Geräte-ID als auch die Telefonnummer an einen Server sendeten. Es ist nicht unwahrscheinlich, dass weiterhin Apps mit fragwürdigem Verhalten durch die Kontrollen rutschen, insbesondere weil mittlerweile tausende neue Apps pro Woche auf Apple einprasseln.

Google stellt zwar mit dem Android Market ebenfalls einen zentralen Software-Pool bereit, verlagert die Analyse jedoch auf den Nutzer: Dazu fragt Android bei der Installation jeder App nach, ob man ihr Zugriffsrechte auf Ressourcen wie GPS, das Adressbuch und Telefonie gewährt. Allerdings fällt es schwer, allein aus dem Wunsch nach dem Zugriff eine mögliche Bedrohung abzuleiten. Eine App für SMS wird auf das Adressbuch zugreifen und von der Telefonfunktion Gebrauch machen wollen – könnte aber auch ungefragt Kurznachrichten an teure SMS-Chats senden. Mitte August wurde ein als Media-Player-App getarnter Dialer für Android gesichtet, der vom Anwender unbemerkt teure SMS-Nummern wählte. Dass die App dies tun könnte, hat sich dem Anwender zwar bei der Installation bereits angekündigt, allein genützt hat es nichts: Viele haben sich die App trotzdem installiert. Nicht selten schildern Android-Anwender, dass sie den angezeigten Rechten ohnehin keine Beachtung mehr schenken würden und die Nachfrage ungeprüft abnicken.

Schuld daran sind zum Teil die App-Entwickler, die sich oftmals keine Gedanken darüber machen, auf welche Ressourcen ihr Tool zugreifen muss, und im Zweifel eher zu viel Rechte erfragen. Dann fordert etwa der schnöde Kalorienrechner überraschenderweise Zugriffsrechte auf das GPS-Modul und den Telefonstatus. Da sich diese Programmierunsitte offenbar epidemisch unter Android-Entwicklern verbreitet, werden Anwender im Laufe der Zeit desensibilisiert und in der Folge installieren sie Apps bedenkenlos – egal was Android meldet. Und nicht selten geraten Android-Apps aufgrund zu viel angefragter Rechte unter falschen Verdacht, den Anwender auszuspionieren.

Dank der speziellen Banking-Apps vieler Banken findet das „Mobile Banking“ immer mehr Anhänger – und auch hier gab es neben den regulären Anwendungen bereits Spionage-Apps. Für US-Banken, die noch keine eigene App angeboten hatten, versprach Ende des vergangenen Jahres die Anwendung eines Entwicklers namens Droid9 ein einfaches Login ins Konto. Parallel las die App die Login-Daten mit und sendete sie an den Entwickler. Aufgeflogen war die Sache erst, als die US-Genossenschaftsbank First Tech Kunden vor der App warnte.

Für den Fall einer epidemischen Ausbreitung einer bösartigen App haben sowohl Apple als auch Google eine Notbremse eingebaut: Per Kill Switch respektive Fernlöschung können sie Anwendungen aus der Ferne ohne Zutun des Anwenders deinstallieren. Während Apple von dieser Option bislang noch nie Gebrauch gemacht hat, löschte Google im Juni Anwendungen, die Sicherheitsspezialisten zu Demonstrationszwecken in den Android Market gestellt und an hunderte Anwender verteilt hatten. Vermutlich greift die Funktion nur für die über den Android Market installierten Apps. Etwa von anderen Webseiten als Android Packages (APK) geladene und installierte Anwendungen dürften davon ausgenommen sein. Der Installation von Software aus anderen Quellen muss der Anwender jedoch explizit einmalig zustimmen, indem er in den Einstellungen die Option „Unbekannte Quellen“ aktiviert.

Der weiteren Verbreitung eines Schädlings innerhalb des Dateisystems eines Gerätes wollen Google und Apple durch Sandboxing und Code Signing zuvorkommen (siehe Kasten Plattform-Überblick). Die Anwendungen laufen vom System abgeschottet und sollen damit keinen direkten Zugriff auf das Dateisystem und die Ressourcen anderer Prozesse haben. Dadurch dass sämtliche Anwendungen auf dem Gerät digital signiert sein müssen, kann kein Programm die Dateien anderer Programme infizieren. Das schützt leider wenig: Wie schon auf dem PC nisten sich Bots und Spionageprogramm auf dem Smartphone ohnehin direkt im System ein, ohne andere Dateien „anzufassen“. Dafür nutzen sie das zweite Einfallstor auf Computersystemen: Sicherheitslücken im Betriebssystem und in Anwendungen wie Webbrowsern, den zugehörigen Plug-ins und Mediaplayern.

Macht hoch die Tür!

Macht hoch die Tür!

Eine Kombination zweier Lücken im iPhone war im August des einen Freud und des anderen Leid: Die als Jailbreakme-Lücke bekanntgewordenen Schwachstellen ließen sich zum Entfernen des SIM-Locks auf dem iPhone und dem Befreien vom App-Store-Zwang ausnutzen – oder um ein Gerät mit Malware zu infizieren. Neu waren Sicherheitslücken im iPhone bis dato zwar keineswegs. Das Besondere an der Jailbreakme-Lücke war, dass sie als erste konkret in größerem Stil (im Sinne des Anwenders) ausgenutzt wurde und dafür bereits der Besuch einer präparierten Webseite genügte.

Bei den vorhergehenden Updates des iPhone-Betriebssystems war Apple in der günstigen Situation, dass die Informationen zu den geschlossenen Lücken erst im Nachhinein veröffentlicht wurden und somit weniger Anwender Gefahr liefen, einem Angriff zum Opfer zu fallen. Gelegenheiten hätte es genug gegeben: Allein das Update auf iOS 4.0 schloss 65 Lücken. Die meisten fanden sich in der vom Safari-Browser benutzten WebKit-Komponente und ermöglichten einer präparierten Webseite, ein iPhone zu infizieren.

Eigentlich sollen Apples Sicherheitsvorkehrungen verhindern, dass sich Lücken überhaupt ausnutzen lassen, um Code einzuschleusen und mit Root-Rechten zu starten. Der Jailbreakme-Exploit hat es aber geschafft, die Datenausführungsverhinderung des iOS (eXecute Never, XN, siehe Kasten „Plattformen“) zu umgehen und aus der Applikations-Sandbox auszubrechen. Dafür nutzt er einen Fehler in einer Systembibliothek zur Verarbeitung von PDF-Dokumenten, um via MobileSafari Code zum Entsperren einzuschleusen. Ein weiterer Fehler bei der Verarbeitung von Pixel-Puffern half dem Exploit, an Root-Rechte zu gelangen und die Restriktionen der Sandbox auszuhebeln und letztlich das Gerät für weitere Manipulationen zu öffnen.

Für Android gibt es erstaunlicherweise erheblich weniger Berichte über Sicherheitslücken im Betriebssystem oder dazugehörige Anwendungen, die zur Kompromittierung des Systems führen könnten. Google veröffentlicht bei der Herausgabe neuer Android-Versionen leider keine Informationen zu darin behobenen Sicherheitsproblemen – dass es sie gibt, lässt sich allein schon aus den gemeldeten Fehlern der aus der Computerwelt stammenden Open-Source-Software ableiten.

Da Android-Apps in Java geschrieben sind und sich dort klassische Überlauf-Fehler meist nur zum Abschießen der Software ausnutzen lassen, muss sich ein Angriff in der Regel gegen eine der in ARM-Maschinensprache ablaufenden Systemkomponente richten. Das ist bei den in C/C++ geschriebenen Modulen der Fall. Angreifer haben allerdings auch nach einem erfolgreichen Einbruch in den meisten Fällen keinerlei Zugriffsrechte auf weitere Dateien oder andere Systemressourcen. Ein gut dokumentiertes Beispiel ist eine Schwachstelle im Multimedia-Subsystem OpenCore: Ein Fehler beim Dekodieren von MP3-Dateien ließ sich zum Einschleusen von Code missbrauchen; das Einfallstor konnte auch der Browser sein. Weil der Browser die MP3-Datei zur Verarbeitung direkt an OpenCore weiterreichte, lief der Code mit den OpenCore-Rechten in einer Sandbox – und da gabs nicht viel zu holen.

Mit einem direkten Angriff auf den Browser hätte ein Angreifer sämtliche Informationen auslesen können, auf die der Browser Zugriff hat – gespeicherte Nutzernamen und Passwörter inklusive. Die Möglichkeit dazu böte eine im Mai vom britischen Sicherheitsdienstleister MWR gefundene Lücke in WebKit. Google soll die Lücke in Android 2.2 zwar geschlossen haben, diese Version verbreitet sich aber nur zäh. Zudem gibt es für viele ältere Smartphones schlicht keine Updates auf aktuellere Versionen und Patches zum Schließen einzelner Lücken sind selten. Einige Android-Besitzer sitzen also auf einem Pulverfass.

Bei Apple gibt es Monokultur-bedingt keine Verzögerungen von Updates aufgrund von Anpassungsschwierigkeiten für verschiedene Modelle. Doch bleiben Besitzer des ersten iPhone-Modells ebenfalls im Regen stehen, da Apple dafür gar keine Updates mehr herausgibt und die Jailbreakme-Lücke offen bleibt.

Insgesamt kann man feststellen, dass die Sicherheitsarchitektur des iPhones einem Angreifer nach einem Einbruch mehr Spielraum zur weiteren Kompromittierung des Geräts gibt. Der Einbruch an sich wird durch den Einsatz von XN und Code-Signatur stark erschwert. Bei Android sieht es genau anders herum aus. Das Einbrechen ist relativ einfach, sobald eine Schwachstelle in einer Systembibliothek gefunden ist. Das Auslesen von Benutzerdaten oder weitere Manipulationen sind allerdings kaum möglich, wenn die angegriffene App nur über wenige Zugriffsrechte verfügt – oder der Angreifer hat eine weitere Schwachstelle in der Hinterhand, um aus der Sandbox auszubrechen. Trotz aller Hürden zeichnet sich derzeit ab, dass Android bereits weiter in den Fokus Krimineller gerückt ist als das iPhone. Dabei nutzen die Autoren von Malware so gut wie nie Sicherheitslücken aus und verlassen sich vielmehr auf die Mithilfe des Anwenders, dubiose Apps zu installieren. Und genau hier wird die größere Offenheit von Android für viele Anwender zum Risiko.

Das Tor macht weit!

Das Tor macht weit!

Unter Umständen gelüstet es den iPhone-Besitzer ebenfalls nach mehr Freiheit, was er mit einem Jailbreak erreicht. Fortan steht es ihm frei, Apps aus anderen Quellen als Apples Anwendungsladen zu installieren. Beim iPhone stellt der Jailbreak leider die größte Chance für Malware dar, da damit viele Sicherheitsmechanismen ausgeschaltet werden. Am kritischsten ist wohl der Wegfall der Signatur-Prüfung der Applikationsbinaries, womit sich beliebige, unsignierte Applikationen auf dem iPhone ausführen lassen. Damit steht Viren und Würmer die Tür offen. Der aufsehenerregendste Fall war im November 2009 die Verbreitung des iPhone-Wurms Ikee.A. Er richtete sich ausschließlich gegen entsperrte iPhones, da diese von außen über einen SSH-Zugang erreichbar waren. Zudem war nach dem Jailbreak das Passwort für den Nutzer Root standardmäßig auf „alpine“ gesetzt. Ikee verbreitet sich durch simples Kopieren auf das Zielgerät mittels Secure Copy (SCP, Bestandteil von SSH). Jede Kopie von Ikee versuchte, sich weiterzuverbreiten. Kurz darauf tauchte die Variante Ikee.B auf, die versuchte, ein Botnet zu etablieren. Ikee.B versuchte in regelmäßigen Abständen neue Instruktionen (als Shellskript) von einem Server herunterzuladen. Ikee infizierte schätzungsweise 21.000 iPhones weltweit.

Zwar ist Android nicht so zugemauert wie das iPhone, die volle Kontrolle über das System hat der Anwender aber auch dort nicht. Die Installation eines alternativen Firmware-ROMS ermöglicht jedoch den vollen „Root-Zugriff, womit sich zusätzliche Anwendungen im „Android Core“ integrieren lassen, etwa ein spezieller VPN-Dienst. Mittlerweile gibt es sogar Tools, die zur Laufzeit das Gerät auf Systemebene „rooten“. So kursiert für diverse Android-Modelle ein One-Click-Rooting-Tool, das eine Lücke im Linux-Dienst init ausnutzt, um aus der Sandbox auszubrechen und an Systemrechte zu gelangen. Schädlinge können sowohl die Lücke selbst als auch den offenen Zustand eines Geräts ausnutzen, um sich tief im System einzunisten.

Bislang ist eine Malware-Bedrohung für Android auf dieser Ebene noch theoretischer Natur. Sicherheitsforscher haben aber bereits Anfang Juli ein Rootkit für Android vorgestellt und in Umlauf gebracht, das man auf diesem Wege in das System einbringen kann, um missliebige Funktionen vor dem Auge des Anwenders und anderen Prozessen zu verbergen. Das Rootkit integriert sich als Linux-Kernel-Modul und ist aus der Ferne steuerbar. Einmal aktiviert hat es Zugriff auf alle Ressourcen. Doch Ungemach droht nicht nur durch Angriffe aus dem Netz, der erfolgreiche Griff von echten Dieben nach dem Gerät hat ebenfalls weitreichende Konsequenzen.

Fremde Hände

Fremde Hände

Früher war es bei dem Verlust oder Diebstahl eines Handys meist damit getan war, die SIM-Karte sperren zu lassen, um Missbrauch zu verhindern. Dies genügt bei Smartphones nicht mehr: Dort sind Zugangsdaten für Mail, Social-Networking-Seiten und weitere Apps hinterlegt, die beim Aufruf in der Regel ohne weitere Nachfrage automatisch benutzt werden. Ein Dieb hätte mit diesem Generalschlüssel Zugriff auf vielerlei Daten; konfigurierte WLANs und VPNs öffnen einem Angreifer zudem den Zugang ins Firmennetz oder ins heimische LAN. Schutz davor bietet allein die Zugangssperre des Geräts, die beim iPhone die Eingabe eines Passcodes oder einer Phrase und bei Android das Zeichnen eines Entsperrmusters oder ab Android 2.2 ebenfalls ein Kennwort erfordert.

Doch selbst wenn das Gerät vermeintlich gesperrt ist, bieten sich dem Schnüffler noch Möglichkeiten, zumindest an einige Daten zu gelangen. Das Android-Betriebssystem unterstützt einen USB-Debugging-Modus für Entwickler, über die der Zugriff auf Teile des Dateisystems möglich ist. Darüber lassen sich sogar Apps installieren und der sonst erscheinende Nachfragedialog für die Zugriffsrechte lässt sich umgehen. Jemand, der das Handy für kurze Zeit in die Hände bekommt, könnte auf diesem Wege unbemerkt eine Spionage-App installieren. Standardmäßig ist USB-Debugging deaktiviert.

Im Falle des Verlusts und der drohenden Kompromittierung der Daten gibt es noch die Notbremse aus der Ferne: per Remote Wipe lassen sich Adressbuch, Kurznachrichten und weitere Daten auf dem Gerät und der SD-Karte löschen und der weitere Zugriff blockieren. Bei Android muss man sich bei den meisten Smartphone-Anbietern dafür vor dem Verlust eine spezielle App wie WaveSecure installiert haben, die beispielsweise in eingehenden SMS-Nachrichten nach einer abgemachten Parole sucht und bei Erfolg die Daten löscht. Der Ansatz funktioniert leider nicht, wenn ein Spion vorher die SIM-Karte entfernt hat und das Gerät keine SMS mehr empfängt. Die App „Lost Phone“ hingegen versendet SMS-Nachrichten an die Handys von Freunden, wenn jemand die SIM-Karte gewechselt hat. Bei Apples iPhone lässt sich eine vom Besitzer initiierte Fernlöschung beziehungsweise Fernsperrung nur über eine Anbindung an den Dienst MobileMe realisieren – und die kostet 79 Euro Dollar pro Jahr.

Seit dem Modell 3GS nimmt das iPhone zwar eine durchgehende, für das System transparente Datenverschlüsselung des Flashspeichers vor. Dies dient aber weniger dem Schutz vor unbefugtem Zugriff, sondern hilft vielmehr bei der Fernlöschung die Daten schnell unbrauchbar zu machen. Statt nämlich auf einem iPhone beispielsweise 16 GByte mit Nullen zu überschreiben – was Stunden dauern kann – wird einfach der Schlüssel gelöscht. Da die Datenverschlüsselung transparent ist, können Unbefugte via Jailbreak über die USB-Schnittstelle im DFU-Mode (Device Firmware Update) Flashinhalte im Klartext auslesen, obwohl der eigentliche Speicherinhalt verschlüsselt ist. Aufpassen sollte man zudem, mit welchen Rechnern man sein iPhone für iTunes paart. Einmal geschehen, verbindet es sich später ohne weitere Eingabe eines Passcodes und lässt sich die Daten als unverschlüsseltes Backup herausziehen. Android sieht standardmäßig keinerlei Verschlüsselung vor; die Daten und Programme liegen immer im Klartext im Flash und auf der SD-Karte. Zusätzlichen Schutz bieten nur Krypto-Apps wie Notes und OI Safe, die Texte und Passwörter verschlüsseln.

Nicht nur diebische Hände sind eine Gefahr für das Smartphone, oft interessiert sich der Lebens- oder Geschäftspartner für das Gerät. Immer häufiger kommen dabei kommerzielle Spionageanwendungen wie FlexiSpy, Mobile Spy, MobiStealth ins Spiel, die geführte Telefonate, Inhalte von SMS und GPS-Daten an den Server eines Dienstleisters senden und sogar das Lauthören und Aufnehmen von Fotos unterstützen – ab 100 US-Dollar im Jahr.

Ausblick

Ausblick

Alles das, was an Gefahren bereits auf dem Desktop-PC droht, findet langsam seinen Weg in die mobile Welt. Weil Smartphones für viele Besitzer mittlerweile zu einer Kommunikationszentrale geworden sind, immer „am Mann“ sind und zudem mehr „Peripherie“ mitbringen, die sich gegen den Anwender richten kann (GPS, Mikrofon), wird das Problem um einiges dramatischer. Dabei scheint das iPhone derzeit besser wegzukommen – was unter anderem an der verdongelten Plattform und dem restriktiven App Store liegt. Vermutlich dürfte es für Kriminelle derzeit zu riskant sein, Malware in den App Store zu schleusen, Anwender anzulocken und zu hoffen, dass die betrügerischen Machenschaften längere Zeit nicht auffliegen – denn nur so wird ein lohnendes Geschäftsmodell daraus. Zwar kann auch Google über den Market installierte Apps wieder zurückziehen, doch sind die Zugangshürden für Entwickler erheblich niedriger und eingestellte Anwendungen werden kaum kontrolliert. Zudem können Apps aus anderen Quellen auf ein Android-Gerät gelangen. Noch sind wir von einer epidemischen Malware-Verbreitung wie unter Windows weit entfernt, daher sind Virenscanner für Smartphones weiterhin unnötig – obwohl die Antivirenhersteller uns weiterhin vom Gegenteil überzeugen wollen. Und ob sich Virenscanner vernünftig ins System integrieren, ist ohnehin fraglich.

Während vor der Installation dubioser Apps bislang noch das Einschalten des Gehirns und im Zweifel der Abbruch des Vorgangs hilft, können ein paar einfache Handgriffe die Sicherheit der Geräte gegen fremde Zugriffe schützen. Ein paar davon finden sie in den Kästen für iPhone und Android. Welche Apps man aus Sicherheitsgründen am besten nicht zur Kommunikation in WLANs verwenden sollte, verraten wir in einem folgenden Artikel.

Sicherheitstipps

Sicherheitstipps für iPhone und Android

Grundsätzlich gilt: Hütet euer Smartphone wie die Geldbörse und das Schlüsselbund. Gerade weil es den Zugriff auf diverse Dienste über diverse Kanäle ermöglicht, stellt das Smartphone für viele eine Art Generalschlüssel auf das Leben im Web dar. Anders als ein Desktop-PC bieten Smartphones von Hause aus erheblich weniger Möglichkeiten, das System zu sichern und auf Anomalien zu kontrollieren.

Als Erstes sollte man unbedingt den Zugriffsschutz aktivieren: Auf Android das Entsperrmuster oder ab Version 2.2 auf allen Modellen eine Passphrase, beim iPhone der vierstellige Passcode oder ab iOS 4 alternativ die längere Passphrase. Wer will, kann beim iPhone einstellen, dass nach zehn Fehlversuchen alle Daten gelöscht werden – dann sollte man sein iPhone aber vor Spaßvögeln hüten oder auf sein iSync-Backup vertrauen.

Wer nicht auf die Sperren der Geräte vertraut, sollte eine Fernlöschung oder Fernsperrung als zusätzliche Option in Erwägung ziehen. Dazu muss der Besitzer vorsorgen und bei Android eine zusätzliche, meist kostenpflichtige App wie WaveSecure, SmrtGuard oder WatchDroid Pro installieren. Beim iPhone muss man ein MobileMe-Konto einrichten und das Gerät damit koppeln. Damit lassen sich Daten nicht nur aus der Ferne löschen, sondern zusätzlich synchronisieren und sichern. Beim Android-Gerät sollte der Besitzer zusätzlich darauf achten, den USB-Debug-Mode (unter Anwendungen/Entwicklung) zu deaktivieren, um diese Hintertür zu schließen.

Um im Hintergrund spionierenden Apps auf die Schliche zu kommen, bieten sich Prozessmonitore an, die anzeigen, welche Anwendungen überhaupt laufen. Unter Android ist beispielsweise der Open Advanced Task Killer populär, fürs iPhone gibt es etwa den SysStats Monitor. Eine Suche bei Google kann bei der Einschätzung helfen, ob es sich um eine böswillige oder unerwünschte App handelt und man sie besser stoppen oder gar gleich deinstallieren sollte. Schon die einfache Beobachtung der GPS- beziehungsweise Kompasssymbole in der Statusleiste kann Hinweise geben, ob gerade verdächtige Dinge vor sich gehen und eine Anwendung zum Beispiel Daten zur Ortung sammelt.

Wer nachträglich unter Android die Rechte von bereits installierte Apps kontrollieren will, kann dies unter dem Menüpunkt „Einstellungen/Anwendungen/Anwendungen verwalten“ für die jeweilige Anwendung (runterscrollen) tun.

Plattform-Überblick

Plattform-Überblick

Beim Betriebssystem setzt das iPhone auf ein spezielles Mac OS X, das wie der große Bruder auf einer Mischung aus MACH-Kernel und FreeBSD beruht. Android setzt auf den bewährten Linux-Kernel 2.6. Auf beiden Plattformen stammen zahlreiche Systemanwendungen und Dienste aus der Open-Source-Welt. Bei den Apps gehen die Plattformen verschiedene Wege: Anwendungen für Android sind üblicherweise in Java geschrieben und laufen in der Dalvik getauften Virtual Machine, die nicht zu normalen Java-Compilern kompatibel ist. Konzeptbedingt können in Java berühmt-berüchtigte Sicherheitsprobleme wie Buffer Overflows nicht auftreten. Apps für das iPhone sind zumeist aus Objective-C in Maschinensprache übersetzt und laufen ohne zusätzliche Laufzeitumgebung.

Durch den Ablauf der Android-Apps in der VM und die integrierte Zugriffskontrolle (Mandatory Access Control, MAC) ist jede Anwendung gegen andere Anwendungen abgeschottet und hat keinen unmittelbaren Zugriff auf das Android-System und seine Ressourcen, sprich die Hardware, das Dateisystem, Daten anderer Apps und so weiter. Der Anwender kann bei der Installation benötigte Zugriffsrechte gewähren. Android zeigt alle angeforderten Rechte an. Welche Rechte eine App gerne hätte, ist im Installationspaket in der Manifest-Datei formuliert (AndroidManifest.xml). Leider hat man nur die Wahl, alle Wünsche zu erfüllen oder die Installation abzubrechen; einzelne Rechte lassen sich nicht gewähren. In der Manifest-Datei ist die digitale Signatur der App hinterlegt, mit der der Entwickler sein Programm unterzeichnet hat. Das dafür benutzte Zertifikat des Autoren darf selbst signiert sein – es geht bei Android weniger darum, die Identität des Programmierers verifizierbar zu machen, als vielmehr um die fälschungssichere Bindung der Apps an die zugeteilten Rechte.

Apples Sicherheitskonzept sieht zwar ebenfalls eine Isolierung der Apps und Prozesse mittels einer Mandatory Access Control voneinander vor, das iPhone-Betriebssystem setzt dies offenbar nicht so streng durch wie Android. In der Vergangenheit stellte sich immer wieder heraus, dass trotz Sandboxing Apps zumindest lesend auf Konfigurationsdateien des Systems und anderer Apps zugreifen können. Das liegt unter anderem daran, dass die vom Mac OS X abgeschauten Zugriffsregeln auf Basis von Regular Expression statisch und generisch definiert sind statt auf einzelne Apps abgestimmt. Im Unterschied zu Android läuft auf dem iPhone zudem nicht jeder Prozess mit einer eigenen Nutzerkennung: Systemdienste und einige Anwendungen arbeiten als „root“; die im Kontext des Anwenders als „mobile“. Über eine im Rahmen des Pwn2own-Wettbewerbs 2010 aufgedeckte Lücke in Safari (der als „mobile“ lief) ließ sich die SMS-Datenbank auslesen und auf den Webserver der Angreifer übertragen. Unter Android ist dies so nicht möglich, weil dort jeder Prozess eine eigene Kennung (UID) hat und die Zugriffskontrolle feiner abgestimmt ist.

Wie bei Android laufen auf dem iPhone ebenfalls nur digital signierte Anwendungen. Anders als bei Android dient dies in erster Linie dazu, nur von Apple freigegebene Anwendungen laufen zu lassen sowie die Herkunft der Apps nachvollziehen zu können. Entwickler für das iPhone müssen ihre Apps von Apple unterschreiben lassen oder können auf Wunsch ein von Apple ausgestelltes Code-Signing-Zertifikat zum eigenständigen Unterschreiben der Software erhalten.

Neben dem per Software implementierten Sandboxing und dem Code Signing bietet das iPhone noch einen hardwareseitigen Schutz: Der ARM-Prozessor unterstützt eine Datenausführungsverhinderung (DEP), die die Auswirkung von Buffer Overflows und Heap Overflows limitieren soll. Das „eXecute Never“-Flag (XN) verhindert, dass Angreifer etwa auf den Anwendungs-Stack geschleusten Code starten können. Raffiniertere Angriffe haben gezeigt, dass sich der Schutz durch sogenanntes Return-oriented Programming (ROP) umgehen lässt. Dabei schleusen Angreifer keinen eigenen Code auf den Stack, sondern rufen vorhandene Bibliotheks-Funktionen durch Manipulation von Rücksprungadressen und Parametern auf. Durch die geschickte Verknüpfung von Funktionen kann der Angreifer seinen Code quasi vor Ort zusammenbauen. Die von modernen Desktop-Betriebssystemen eingesetzte Speicherverwürfelung Address Space Layout Randomization (ASLR) kann solche Tricksereien erschweren, leider bringt das iPhone sie nicht mit. Googles Android nutzt weder die „eXecute Never“-Funktion des ARM-Prozessors noch verwürfelt es den Speicher. (dab)