Wie gefährlich ist Android? Android - Sicherheitskonzept und Risiken beim beliebten Google Smartphone OS

Autor / Redakteur: Dr. Markus a Campo / Peter Schmitz

Smartphones mit dem Betriebssystem Android verbreiten sich immer mehr. Im letzten Quartal 2010 wurden mehr als 33 Millionen Geräte mit dem von Google entwickelten System ausgeliefert. Marktforscher sagen dem System einen Siegeszug voraus. Doch auch bei diesem Smartphone stellt sich die Frage, wie sicher das System ist.

Firmen zum Thema

Android ist derzeit das beliebteste Smartphone OS, aber auch beim neuen Open-Source-Star müssen Anwender mit Sicherheitsrisiken leben.
Android ist derzeit das beliebteste Smartphone OS, aber auch beim neuen Open-Source-Star müssen Anwender mit Sicherheitsrisiken leben.
( Archiv: Vogel Business Media )

Android basiert auf Linux und ist als Open-Source-Software frei verfügbar. Sicherheitsexperten können das System downloaden, testen und auf Sicherheitslücken untersuchen. Das ist ein großer Vorteil gegenüber proprietären Systemen wie BlackBerry OS von RIM oder iOS von Apple. Allerdings birgt die Freiheit eines Open-Source-Systems auch Risiken.

Mit einer entsprechend programmierten Software lassen sich Android-Smartphones in weiten Grenzen verändern, sei es durch „Rooten“ der Geräte oder gleich durch das Aufspielen einer neuen Firmware. Mit diesen Möglichkeiten ergeben sich Risiken ungeahnten Ausmaßes. Aber auch in einem Standard-Android gibt es einige Tücken, über die sich sicherheitsbewusste Benutzer informieren sollten.

Bildergalerie
Bildergalerie mit 5 Bildern

Dateien und Prozesse

Die in Java geschriebenen Android-Prozesse sind untereinander gut abgeschottet. Für jede Anwendung wird ein eigener Account angelegt. Auf der im YAFFS-Format (Yet Another Flash File System) formatierten Flash-Festplatte wird für jede Anwendung ein eigenes Verzeichnis mit den Rechten dieses Accounts angelegt. Beim Start einer Anwendung wird diese von einer eigenen Instanz der JVM (Java Virtual Machine) ausgeführt, die ebenfalls mit den Rechten dieses Accounts läuft. Ein Benutzer hat deshalb keinen eigenen Account, er arbeitet immer mit den verschiedenen Accounts der aktiven Anwendungen.

Prozesse und Dateien sind deshalb sehr gut voneinander abgeriegelt, solange keine Benutzerprozesse mit Root-Rechten laufen. In einer Default-Android-Installation ist das nicht der Fall. Einige Hersteller haben allerdings Erweiterungen in ihre Android-Versionen eingebaut, die Root-Rechte benötigen. In den meisten Fällen sind diese konservativ programmiert, d.h. ein Wechsel in den Root-Account muss vom Benutzer betätigt werden. Allerdings ist das keine Standardfunktion des Betriebssystems, sondern muss von Hersteller so eingerichtet werden.

Inhalt:

  • Seite 1: Datei- und Prozess-Absicherung gelungen
  • Seite 2: Komplexe Interprozess-Kommunikation
  • Seite 3: Fazit: Ein System nicht ohne Risiken

Interprozess-Kommunikation

Der Linux-Kernel dient unter Android nur für Basisfunktionen wie Dateizugriffe, Speicher- und Prozessverwaltung. Darüber hat Google eine ganz eigene Prozess- und Kommunikationsstruktur gelegt, die mit der Zugriffs- und Rechteverwaltung von Linux nichts zu tun hat.

Eine Android-Anwendung kann aus verschiedenen Komponenten bestehen. Diese kommunizieren miteinander über Nachrichten, wozu ein eigenes, Android-spezifisches Interface implementiert wurde – das ICC (Intercomponent Communication). Jede Applikation kann aus folgenden Komponenten bestehen:

  • Eine Activity Component ist ein Interface zum Benutzer und nimmt Eingaben über die Tastatur oder den Touchscreen entgegen.
  • Eine Service Component ist ein Hintergrundprozess, der Dienste für andere Komponenten anbietet.
  • Ein Content Provider ist ein Prozess, der auf eine SQLite-Datenbank zugreift.
  • Ein Broadcast Receiver schließlich empfängt im Hintergrund Nachrichten anderer Prozesse.

Die Kommunikation von Prozessen untereinander wird nicht über Linux-Rechte geregelt, sondern über ein kompliziertes System von Labels. In diesen wird festgehalten, wer mit wem kommunizieren darf. Diese Labels werden in Form von Filtern in einer zur Applikation gehörenden Datei AndroidManifest.xml definiert und sind unveränderlich.

Risiken und Nebenwirkungen

Der Datenhunger von Google ist allgemein bekannt. Nutzer eines Android-Smartphones müssen sich darüber im Klaren sein, dass ihr Telefon bei jeder sich bietenden Gelegenheit „nach Hause telefoniert“ und Standortdaten, genutzte Anwendungen und andere Daten übermittelt. Das gilt auch für Anwendungen von Drittanbietern, die über den Android Market oder andere Quellen auf das Telefon geladen werden. Die Kontrollen von Google sind mehr als lasch, lediglich Spionage-Programme werden aus dem Market verbannt.

Inhalt:

  • Seite 1: Datei- und Prozess-Absicherung gelungen
  • Seite 2: Komplexe Interprozess-Kommunikation
  • Seite 3: Fazit: Ein System nicht ohne Risiken

Eine Verschlüsselung des Datenspeichers sucht man bei Android-Smartphones in der Regel vergebens. Da ähnlich wie beim iOS von Apple Anwendungen nur auf ihre eigenen Daten zugreifen dürfen, können auch nur diese verschlüsselt werden. Einige Hersteller wie etwa Motorola kündigen jedoch Systeme mit kompletter Verschlüsselung an, die dann über eine Erweiterung des Linux-Kernels realisiert wird. Für die meisten Android-Nutzer bleibt Verschlüsselung jedoch ein Wunschtraum. Unverschlüsselt abgelegte Daten stellen eines der größten Sicherheitsrisiken von Android dar.

Eine andere, ebenfalls gefährliche Sprengfalle ist die per Default aktivierte Option „USB Debugging“. Diese bietet die Möglichkeit, von einem externen Computer aus per USB auf das Gerät zuzugreifen. Dabei kann eine externe Shell geöffnet und über den Datenbank-Editor sqlite3 das System manipuliert werden. Damit ist es in Sekunden möglich, etwa den Lock eines gestohlenen oder gefundenen Telefons zu deaktivieren und dann das Gerät nach Gutdünken zu missbrauchen.

Eine weitere Schwachstelle von Android sind Zertifikate, mit denen jede Anwendung signiert wird. Unsignierte Anwendungen können unter Android nicht installiert werden, aber der Wert einer Signatur ist zweifelhaft. Da es keine übergeordnete Zertifikatsinstanz gibt, bleibt es letztlich dem Benutzer überlassen, ob er einer Signatur vertraut oder nicht.

Fazit: Ein System nicht ohne Risiken

Während die Linux-Funktionen von Android als ausreichend sicher gelten, kann das vom ICC-Kommunikationssystem nicht unbedingt behauptet werden. In frühen Android-Versionen waren Definition und Wirkung von Labels einfach und klar. Spätere Erweiterungen haben das Prinzip jedoch stark verwässert. So können etwa Komponenten als privat oder als Broadcast definiert werden. Private Komponenten können überhaupt keine Nachrichten mit anderen Prozessen austauschen. Leider wird das Attribut „privat“ nicht in der Datei AndroidManifest.xml angegeben. Gleiches gilt für Broadcasts, bei denen die Labels im Sourcecode definiert werden. Besonders bei unerfahrenen Programmierern können sich hier unerwartete Sicherheitslücken auftun.

Last, but not least sind auch bei Android-Systemen Angriffe gegen Datensicherungen möglich. Da Datensicherungen in der Regel unverschlüsselt abgelegt werden, dürfen sie keinesfalls in fremde Hände fallen. Ansonsten besteht die große Gefahr, dass Kontakte, Termine, Notizen, GPS-Standorte und andere persönliche Daten extrahiert und zu einem Identitätsdiebstahl genutzt werden.

Inhalt:

  • Seite 1: Datei- und Prozess-Absicherung gelungen
  • Seite 2: Komplexe Interprozess-Kommunikation
  • Seite 3: Fazit: Ein System nicht ohne Risiken

Artikelfiles und Artikellinks

(ID:2051082)