Ist die Geschäftskontinuität nicht Teil der Sicherheit?
Andrea Covello
Kaum ein Gerät hat in den letzten beiden Jahren für soviel Furore gesorgt wie das iPhone. Während andere Hersteller händeringend um die Aufmerksamkeit der Konsumenten buhlen, kann sich der Softwaregigant aus Cupertino entspannt zurücklehnen und verfolgen, wie sämtliche Mainstream Medien die Ankündigung des neuen iPhone 4 verkünden. Apple hat mit dem iPhone ein Produkt geschaffen, dass es innert kürzester Zeit geschafft hat, ein integraler Bestandteil der heutigen Informationskultur zu werden. Unter diesen Vorraussetzungen wundert es wenig, dass nach dem Consumer Markt auch zahlreiche Mitarbeiter in Unternehmen bald nach iPhones riefen. Warum soll man sich auch mit, im Vergleich, träge wirkenden Windows Mobile und Symbian Geräten herumschlagen, wenn man das momentan populärste und angeblich „beste“ Gerät als Alternative betrachtet.
Der Ruf nach dem iPhone endet in den meisten Unternehmen beim Security Officer. Dieser teilt zwar meistens Begeisterung für die schicken Geräte – allerdings nur solange sie sich nicht in seinem Netzwerk befinden. Aus Compliance Sicht ist das iPhone ein harter Brocken: Keine Hardwareverschlüsselung, die FIPS 140-2 erfüllt. Kein solides Policy Enforcement, wie es zum Beispiel Branchenprimus RIM mit Blackberry vormacht. Kein allgemeines Device Management, wie man es allgemein für Corporate Geräte kennen und erfordern würde. Neben diesen rudimentären und wichtigen Dingen verlangen viele Unternehmen noch diverses Zubehör – AV Software ist nur ein Beispiel unter vielen, das auf der nur begrenzt offenen iPhone Plattform bis dato nicht zu finden ist.
Die Anstrengungen von Hersteller Apple selber, das iPhone als Business-Gerät stärker zu etablieren sind relativ limitiert. Das iPhone Configuration Tool zur Erstellung von Gerätepolicies im XML Format, die per E-Mail oder Web auf Geräte geladen werden können, zeigt grundsätzliches Interesse an der Materie. Aber auch, dass man anscheinend auch ohne weitere Bemühungen gutes Geld verdienen kann.
Apples momentaner Verzicht auf die aktive Bewirtschaftung dieses Geschäftsbereiches stellt natürlich eine offene Einladung für Drittanbieter dar, die hier ihre Chance auf ein Stück des iPhone Kuchens sehen. Entsprechend viele Hersteller drängen derzeit auf den Markt und versuchen mit Hilfe von Workarounds zu erreichen, was Apple bislang versäumte: Das iPhone als Geschäftsgerät zu ermöglichen.
Ein Beispiel für ein derartiges Produkt ist Mobile Office for iPhone des Herstellers Sybase iAnywhere, einer Tochter der traditionsreichen Firma Sybase, die in erster Linie durch relationale Datenbanksysteme in den 80ern bekannt wurde. Mobile Office, das auch für andere Plattformen verfügbar ist, erlaubt es, zentral gelagerte Daten wie Kontakte, Termine und Aufgaben mit dem Endgerät zu synchronisieren. Es erlaubt des Weiteren die Verwendung von Push E-Mail.
Während serverseitig verschiedene Softwarekomponenten eingesetzt werden müssen, kommt bei Anwendung von Mobile Office auf dem Endgerät nur eine reguläre iPhone App zum Einsatz. Diese kann durch den Benutzer, wie jede andere App, aus Apples AppStore bezogen werden. Startet der Benutzer die Applikation, so erhält er innerhalb dieser Applikation, zur Laufzeit, Zugriff auf die oben genannten Daten.
In einem Produkt Whitepaper erklärt der Hersteller den Ansatz: Durch das Sandboxing der Applikation soll es möglich sein, ein privates Gerät geschäftlich zu nutzen, zumal eine Trennung der Daten von iAnywhere und der nativen iPhone Daten stattfindet. Der Benutzer kann seine privaten Daten und Anwendungen also weiterhin nutzen, ohne dabei auf geschäftliche Integration verzichten zu müssen. Weiterhin gibt iAnywhere an, bei der kryptografischen Speicherung seiner Daten die Anforderungen von FIPS 140-2 durch den Einsatz von 128-bit AES-CFB zu erfüllen. Was im ersten Moment logisch und einleuchtend klingt, offenbart bei genauer Betrachtung aber verschiedene Schwachpunkte.
Der erste Punkt, der von essentieller Wichtigkeit ist, betrifft das sogenannte Sandboxing. Sandboxing ist eine durchaus sinnvolle Herangehensweise zum Erreichen gewisser sicherheitsrelevanter Ziele. Konkret heisst Sandboxing, dass man einer Applikation oder einem Prozess eine klar abgegrenzte und isolierte Umgebung zur Verfügung stellt, in der Ressourcen (CPU, Festplattenplatz, Speicherbereiche) und Schnittstellen (Netzwerk, HID) stark restriktiv gehandhabt oder gar vollständig abgeschirmt werden.
Apple setzt auf dieses Konzept, um Applikationen voneinander abzuschirmen. Eine Applikation soll keinerlei Zugriff auf die Daten einer Applikation erhalten. Zugriff auf das Kernsystem, also auf das Betriebssystem, wird nur über entsprechend vorgesehene Klassen erlaubt. Im Fall von Mobile Office heisst das: Eine andere Applikation erhält keinen Zugriff auf die Daten von iAnywhere, genau so wenig wie iAnywhere Zugriff auf die Daten anderer Applikationen erhält. Jede Applikation im AppStore muss diese Richtlinien beachten und einhalten, auch iAnywhere. Die Entscheidung, das „Feature“ Sandboxing zu verwenden ist daher wahrscheinlich eher als grundlegende Restriktion denn als bahnbrechende Designentscheidung zu betrachten.
Ein grundlegendes Problem des Sandboxing ist, dass eine massive Diskrepanz dazwischen existiert, was eine Applikation tun kann und was sie tun soll. Eine Applikation kann zum Beispiel auf grosse Teile des Dateisystems frei zugreifen. Es existieren keine technischen Massnahmen, um sie davon abzuhalten. Aber: Apple schreibt in seinen Development Guidelines ganz klar vor, dass eine Applikation das nicht tun darf. Ein harmloses Beispiel: Es wäre problemlos möglichen, auf Fileebene auf Kontaktdaten zuzugreifen. Apple würde eine Applikation, die das tut aber niemals für den AppStore freigeben. Dem Entwickler wird nahegelegt, die freigegebenen APIs – und nur diese – zu benutzen, um dieses Ziel zu erreichen. Dasselbe gilt für zig andere Beispiele, bei denen auf Systemressourcen oder -schnittstellen zugegriffen werden soll.
Wir rekapitulieren: Es existiert eine Sandbox, die klar reglementiert, was eine Applikation darf und was nicht und Apple sorgt durch seinen Approval Prozess mit einer Mischung aus technischen und administrativen Massnahmen dafür, dass dieses Konzept auch gewürdigt wird. Eine Applikation, die eine andere Applikation manipuliert oder deren Daten ausliest, würde niemals ihren Weg in den AppStore finden.
Was passiert nun aber, wenn ein Gerät in der Lage ist, unsignierten Code auszuführen, der nicht aus dem AppStore stammt? Richtig, der Approval Prozess fällt weg und die verbleibende Sicherheit des Gerätes steht und fällt mit der rein technischen Implementation der Sandboxing Mechanismen.
Am 10. Juli 2007 wurde der erste Jailbreak für die erste Generation des iPhones veröffentlicht, der Beginn eines Katz und Maus Spiel zwischen Hersteller und Entwicklern, die sich nicht genötigt sahen, sich von Apples restriktiver Entwicklungsrichtlinie davon abhalten zu lassen, beliebigen Code auf dem iPhone laufen zu lassen. Bis zum heutigen Tag hat sich die Technik zum Umsetzen eines Jailbreaks massiv verbessert: Version 3.2 des iPhones konnte mittels blackra1n oder verschiedener Alternativtools innerhalb von Sekunden und ohne jedes technische Know-how gebrochen werden. Im Anschluss an den einfachen Prozess kann des iPhone jeden beliebigen Code ausführen. Es existieren diverse Software Manager, die dem Benutzer die Installation von 3rd Party Software, von SSH Servern bis zu Videorecordern, ermöglichen.
Durch einen Jailbreak kann eine beliebige Applikation Zugriff auf das komplette Dateisystem erhalten. Dies umfasst auch die Daten, die Mobile Office auf dem Gerät ablegt. Dies führt uns zur ersten Konklusion: Das Sandboxing funktioniert nur, solange das Gerät keinen unsignierten Code ausführen kann, der noch dazu auf Systemebene, also sozusagen hierarchisch „über“ der Mobile Office Applikation läuft. Hier gilt ein klassisches Konzept der Systemsicherheit: Eine Softwarekomponenten kann maximal die Sicherheit erreichen, die eine ihr übergeordnete Komponenten erreicht. Wird die Betriebssystemebene kompromittiert, so muss auch die Applikationsebene als gefallen betrachtet werden.
Man muss Mobile Office natürlich an dieser Stelle zu Gute halten, dass die synchronisierten Daten nicht im Klartext auf dem Gerät speichert. Wie etwas früher in diesem Artikel erwähnt, werden Daten verschlüsselt abgelegt. Konkret handelt es sich im Falle von Mobile Office um eine SQLite Datenbank, die mittels der SQLite Encryption Extension verschlüsselt wird. Zum Einsatz kommt dabei eine 128-bit AES – OFB Verschlüsselung, wobei der Schlüssel durch die iPhone eigene Funktion SecRandomCopyBytes() generiert wird und in der iPhone Keychain abgelegt wird. Gehen wir aber auch hier wieder davon aus, dass ein Angreifer beliebigen, unsignierten Code auf dem Gerät zur Ausführung bringen kann:
Konkret heisst das: Schlüssel, Algorithmus und Daten sind allesamt bekannt. Es bleibt dem Angreifer nur noch überlassen, diese drei Teile in der richtigen Konstellation zusammenarbeiten zu lassen. Ebenfalls werden Daten zur Laufzeit im Klartext in den Speicher geladen, was naheliegenderweise notwendig ist, um sie innerhalb der Applikation verwenden zu können. Auch hier gibt der Hersteller im Whitepaper zu Protokoll, dass die „native Funktionalität des iPhones dazu führt, das alle unverschlüsselten Informationen im Speicher gelöscht werden, wenn die Applikation beendet wird“. Auch hier verlässt man sicher aber lieber auf das rigide, mangels Rechenleistung des Gerätes implementierte, Speicherverwaltung aus dem Haus Apple, als sich selber um den Schutz des Speicherinhaltes zu bemühen, lässt es sich aber nicht nehmen, dies als „Feature“ herauszustreichen. Währenddessen kann eine Applikation, die im Hintergrund läuft (eine Funktionalität, die vor iOS4 offiziell nicht möglich war, auf gejailbreakten Geräten aber durchaus zum gängigen Programm gehört), beliebig auf den Speicherbereich von Mobile Office zugreifen.
Aller Kritik zum Trotz: iAnywhere Mobile Office ist kein grundsätzlich schlechtes Produkt. Es ist durchaus ersichtlich, das man bei der Entwicklung versucht hat, Lösungen für Probleme zu finden, deren Rahmenbedingung einer saubere Löung zum jetzigen Zeitpunkt gar nicht erlauben. Bei allem Respekt für diese Bemühungen, fällt es aber dennoch schwer im Hinblick auf massive Mängel einen Einsatz in einem sensitiven Umfeld, wie zum Beispiel dem eines Finanzinstituts, zu erlauben oder gar zu empfehlen. Die Hauptgründe dafür liegen in der Sicherheit der Applikation selber, die durch halbherziges Sandboxing leider nicht annähernd so gut geschützt ist, wie es im ersten Moment den Anschein macht. Alles weitere ergibt sich dann aus dem Umstand, dass eine Applikation, die nach den Regeln von Apple spielt im direkten Duell gegen eine vollprivilegierte Applikation mit root Rechten leider nun einmal den Kürzeren zieht.
Hoffnung für iPhone-affine Unternehmen existiert jedoch: Mit iOS4 hat Apple eine komplett neue API zum Zwecke von Device Management implementiert, die einige dieser Schwächen vielleicht zu einem gewissen Mass zu kompensieren vermag. Ob und inwiefern es den Herstellern jedoch gelingt, damit mit den Favoriten im Mobile Device Segment mitzuhalten, bleibt abzuwarten.
Unsere Spezialisten kontaktieren Sie gern!
Andrea Covello
Michèle Trebo
Lucie Hoffmann
Yann Santschi
Unsere Spezialisten kontaktieren Sie gern!