Wie bereits vorab auf www.tecChannel.de berichtet, stellte ein dezidierter Vortrag während der am 8.10.2004 zu Ende gegangenen "Hack in the Box" Hacker-Konferenz im malaysischen Kuala Lumpur Methoden vor, um die bis dato als sicher eingestufte J2ME-Plattform anzugreifen. Sun hat die Sicherheitslücke gegenüber tecCHANNEL.de bestätigt. In einem Interview spricht Adam Gowdiak über die Intention seines Hacks sowie über Gefahren und Schutzmöglichkeiten für Verbraucher.
Ohne direktes Insiderwissen gelang es Adam Gowdiak mittels Reverse Engineering und eigenen Tools, den Lücken auf die Spur zu kommen. Am Beispiel des Nokia 6310i hat er mögliche Exploits konkret nachgewiesen.
Gowdiak vom polnischen "Poznan Supercomputing and Networking Center" hat bereits mehrfach in seiner Rolle als "ethischer" Hacker auf Sicherheitslücken insbesondere im Unix-Umfeld aufmerksam gemacht. Es dürfte nicht überraschen, wenn Firmen im J2ME-Umfeld auch diesmal vorab informiert wurden. In seinem Vortrag hat er wichtige Details weggelassen, um den Anbietern genug Zeit zu geben, aktiv auf die Gefährdung ihrer Produkte einzugehen, bevor die ersten Hacker das gesamte Geheimnis lüften und für eigene Zwecke missbrauchen.
Tatsache ist, dass das Bedrohungspotenzial groß bleibt, so lange die aufgedeckten Lücken nicht geschlossen werden und weit verbreitet sind. Laut einer Studie des finnischen Herstellers Nokia wurden bis Anfang 2004 weltweit bereits 250 Millionen Java-fähige Geräte verkauft.
Grundlagen
Das von Gowdiak skizzierte Szenario nutzt eine Kombination diverser Schwächen und Strategien, um ein MIDlet zu erstellen. Dies durchbricht die Schutzmechanismen unerkannt vom ahnungslosen Anwender und erhält Zugang zu allen Systemressourcen. Dabei verwendet es ausgerechnet die von Sun Microsystems zum Schutz in die Laufzeitumgebung integrierten Techniken.
Der Vortrag gibt Einblick in die Vorgehensweise beim J2ME-Hack. Die Schwachstelle betrifft grundsätzlich jedes Handy, das die Java 2 Micro Edition verwendet. Der Anwender muss das MIDlet auf dem Gerät installieren und starten. Ist das Programm aktiv, liegen durch die auf dem Gerät zur Verfügung stehenden Kommunikations-Features wie SMS, direkte Socket-Verbindungen oder E-Mail sehr persönliche Daten auf dem Präsentierteller.
Den Kunden können beispielsweise durch kostenpflichtige Premium SMS oder ungewollte Internet-Verbindungen hohe Kosten entstehen. Der Schaden, der durch das Mitschneiden der Kommunikation entsteht, kann allerdings weit höher ausfallen.
Vorbereitungen
Gowdiak ging vom bekannten "Sandbox"-Modell der J2ME-Systemumgebung aus. Diese Sandbox hat zur Aufgabe, alle Applikationen in einem geschützten Bereich ablaufen zu lassen.
Anwendungen sollen keine unerlaubten Zugriffe auf die eigentliche Systemumgebung des mobilen Endgeräts erhalten. Applikationen können also innerhalb der Sandbox arbeiten und mit Fehlern behaftet sein. Sie haben aber keinen Einfluss auf die externe Systemwelt.
Wichtig in diesem Zusammenhang sind der Zugriff auf externen Speicher, fremde Java-Klassen oder native Systemroutinen.
Sicherheitsarchitektur der J2ME
Im Zentrum der Sicherheitsmechanismen von Java steht der "Bytecode-Verifier". Er überprüft den von Java-Quellen erzeugten Code und stellt Folgendes sicher:
Der Bytecode enthält keine illegalen Instruktionen.
Er adressiert Objekte nur auf erlaubte Weise.
Er greift nicht auf unerlaubte Speicherbereiche zu (keine Stack Over- oder Underflows, Pointer).
Er honoriert die Zugriffsprivilegien.
Er wird nicht in einer unerwünschten Reihenfolge ausgeführt.
Das Verifizieren des Bytecodes ist in einem Java-Umfeld die zentrale Instanz, um das angepeilte Sicherheitsniveau zu erreichen. J2ME stellt in diesem Zusammenhang einen Sonderfall dar. In "normalen" Laufzeitumgebungen überprüft die Java Virtual Machine (JVM) den Code erst beim Laden. Um allerdings Speicherplatz und Laufzeit auf den mobilen Geräten einzusparen, wird der Bytecode nach dem Kompilieren auf dem Entwicklungssystem "pre-verifiziert". Dies geschieht vor dem Erstellen der JAR-Datei.
Das Resultat weist danach zusätzliche so genannte "Stack-Map-Attribute" auf. Diese "Stack Maps" stellen eine Art Fingerabdruck der Applikation dar und definieren verschiedene Werte für jede Instruktion:
die Anzahl der Register,
den Systemstatus nach der Abarbeitung (durch Simulation),
die Größe des genutzten Stacks
oder den Typ des verbundenen Datenobjekts.
Die Überprüfung erfolgt dann zur Laufzeit. Dieses zweiphasige Sicherheitsinstrumentarium aus Pre-Verifier und Stack Map Check zur Laufzeit stellt laut Gowdiak das lohnende Angriffsziel dar. Gelingt die Manipulation dieser Maps, lässt sich die Überwachung ausschalten.
Suche nach Angriffspunkten
Die Suche nach Schwachstellen liefert laut Gowdiak schnell mehrere Ansätze. So überprüft der Verifier bei einer GOTO-Instruktion lediglich, ob überhaupt ein Stack-Map-Eintrag vorhanden ist, nicht jedoch, ob das Sprungziel im erlaubten Bereich liegt. Prinzipiell sind so Sprünge an illegale Stellen möglich.
Die GOTO_W-Instruktion reduziert zunächst die Zieladresse von 32 Bit auf 16 Bit, da die Stack Maps für Sprungadressen lediglich 16 Bit vorsehen. Bei geschickter Manipulation lässt sich dieser Umstand nutzen, um zu illegalen Adressen, etwa außerhalb der Sandbox im Bereich der KVM selbst, zu verzweigen. Damit ist ein erster Weg aus dem geschützten Bereich vorgezeichnet.
Der eingebrachte Code muss an eine bestehende Methode gebunden werden. Dies verhindert, dass der Garbage Collector (GC) den unerlaubten Bytecode aus dem Speicher-Heap löscht.
Der tatsächliche Angriff
Nach diesen ersten Schritten greift Gowdiak das Java-Laufzeitsystem aktiv an. Hier versucht er, die Laufzeitumgebung beim Umformen (casten) eines Objekts von einem Typ in einen anderen zu überlisten ("Type Confusion Attack"). Mittels einer illegalen Umformung lassen sich dann Speicherbereiche "inoffiziell" ansprechen - der nächste Schritt beim Angriff auf die Laufzeitumgebung.
Tatsächlich zeigen Gowdiaks Bemühungen Erfolg. Für die Attacke nutzt er die "getfield/putfield"-Instruktionen, da diese zur Laufzeit nicht auf korrekte Parameter überprüft werden. Damit ist ein späterer Zugriff auf Objekte möglich. Gowdiak stellte auf der Konferenz ein Beispiel auf Basis der "Type Confusion Attack" vor, um einen uneingeschränkten Zugang zum Speicher zu erlangen, ohne jedoch das Geheimnis seiner "Blackbox" gänzlich zu offenbaren. Damit gibt er den Anbietern etwas Zeit, auf die Schwächen zu reagieren.
Der nächste Angriff gilt dem Zugriff auf beliebige Bibliotheksroutinen der Laufzeitumgebung beziehungsweise des nativen Systemumfeldes mittels "Class Spoofing". Gelingt dies, steht der ehemals kontrollierten Java-Applikationsumgebung der Zugang zu allen Funktionen des Geräts offen. Tatsächlich erreicht Gowdiak auch dieses Ziel. Die Anwendung kann außerhalb der Sanbox agieren. Nun lassen sich beispielsweise eingebaute Sicherheitsabfragen durch eigene Routinen ersetzen.
Demonstration am Nokia 6310i
Zur Demonstration der Angriffe am "lebenden" Objekt nutzte Gowdiak ein Nokia 6310i. Zuerst suchte er auf Basis der bereits erwähnten unerlaubten Zugriffe auf den lokalen Speicher nach Methoden- und Klassennamen der nicht offen gelegten Laufzeitumgebung.
Außerdem lassen sich dem Gerät so weiter gehende Informationen zu internen Java-Objekten entlocken. Das Disassemblieren des internen Bytecodes sowie der nativen Umgebung führte zu weiteren Informationen und einer "Datenbank" bekannter Systemunterroutinen, die sich dann bei Bedarf aufrufen lassen.
Zum besseren Verständnis emulierte Gowdiak den Maschinencode, in diesem Fall für den ARM-Prozessor. Hierzu nutzt er eine Applikation, die den Code auf dem PC emuliert und dabei mittels spezieller Stub-Routinen mit dem Handy in Verbindung steht. Mit Hilfe der Routine lassen sich Speicherbereiche gezielt übertragen und bei Bedarf manipulieren. Über ein weiteres MIDlet findet er die Namen bestimmter Subroutinen und anderer Objekte auf Basis des Hash-Keys.
Mit diesen Tools entschlüsselt Gowdiak die Laufzeitumgebung schrittweise und entziffert beispielsweise die Tabelle aller Systemaufgaben sowie den prinzipiellen Aufbau. Dieser enthält etwa die für jede Firmware-Version festen Memory-Slots für Objekte und Tasks der Laufzeitumgebung. Damit verfügt er über eine dezidierte Memory Map für alle Objekte und die Task-Liste des 6310i.
Fester Speicherplatz im Flash-Memory
In einem letzten Schritt untersucht er, wie die RecordStoreFile-Klasse genutzt wird, um Objekte dauerhaft auf dem Gerät zu speichern. Hier stellt sich heraus, dass neben den Objektdaten eines MIDlets mit dem gleichen System auch Daten des Adressbuchs, SMS-Nachrichten, Audio-Daten, der WAP-Cache, angerufene Nummern und weitere Informationen in einem lokalen Dateisystem abgespeichert werden. Eine Schwachstelle der Methode open0 öffnete den Zugang zu Informationen über die interne Prozesskommunikation (IPC), was wiederum ein Mitschneiden der gesamten Kommunikation erlaubte.
Mit all diesen Methoden ebnet sich ein Angreifer den Weg, um beliebigen Java-Code, der sich in die Kommunikation einbettet, persistent im Speicher des Geräts abzulegen. Da die meisten Funktionen auf dem 6310i per IPC aufgerufen werden, kann eine entsprechend manipulierte Applikation ebenfalls auf diese Funktionen zugreifen und beispielsweise SMS versenden oder an sensible Daten gelangen und diese versenden oder ändern.
Hierbei kann man alle Sicherheitsschritte wie beim Aufbau einer aktiven Verbindung per GPRS oder anderen Methoden überwinden. Der gesamte Vorgang geschieht dann transparent und ohne einen Hinweis an den Besitzer. Der geschilderte Angriff funktioniert allerdings nur, wenn eine entsprechend vorbereitete Anwendung vom Anwender direkt auf dem Gerät installiert wird. Ein Angriff über eine bestehende Netzwerkverbindung oder Bluetooth kommt nicht in Betracht.
Gowdiak verweist auf die potenziell bestehende Möglichkeit, durch permanente Veränderungen des Flash-Speichers auf dem jeweiligen Handy eine für Trojaner typische "Backdoor" einzurichten, die nach jedem Neustart geladen wird. Zudem lässt sich durch Überschreiben der Firmware das Handy unbrauchbar machen. Er geht davon aus, dass erste schädliche Exploits bereits in den nächsten sechs Monaten auftauchen.
Seiner Meinung nach ist die Mobilfunkindustrie derzeit nicht angemessen auf dieses Problem vorbereitet. Bei einer Zahl von mehreren hundert Millionen neu verkaufter Java-fähiger Mobiltelefone pro Jahr wäre ein koordinierter Angriff, beispielsweise eine "Denial of Service"-Attacke, katastrophal für die weltweite Kommunikationslandschaft. Ein Papier mit allen Details soll in den nächsten Monaten folgen.
Fazit
Die besprochenen Sicherheitslücken zeigen das hohe Gefahrenpotenzial, das hiermit erstmals öffentlich gemacht wird. Nutzer von Java-Handys sollten unbedingt die Quelle von MIDlets kontrollieren, die sie auf das Gerät aufspielen. Die von den Herstellern und Providern in diesen Tagen eingeführten Zertifizierungsprogramme sind dabei ein erster Schritt. Es gilt dabei jedoch zu beachten, dass viele Entwickler ihre Applikationen nicht für diese kostenpflichtigen Zertifizierungsprogramme anmelden, sondern diese direkt vertreiben.
Dennoch ist bei all der zu erwartenden Aufregung festzuhalten, dass andere Systemumgebungen für Mobiltelefone ebenfalls einen potenziellen Unsicherheitsgrad in sich bergen. Während ein Angreifer unter J2ME immerhin genau hinsehen muss, um an interne Ressourcen zu gelangen, lassen Umgebungen wie Symbian OS oder Smartphone 2003/2004 den Zugriff auf wesentlich mehr interne Funktionen direkt per API zu. Zudem dürfte es nach wie vor im Vergleich zum Java-Pendant leichter sein, diese in C/C++ erstellten Systeme per Exploit anzugreifen.
Die Mobilfunkindustrie steht ohne Zweifel vor einer Bewährungsprobe auf technologischer und sicherheitstechnischer Ebene. Es stellt sich die Frage, wie offensiv die Industrie dem Problem mittels einer aggressiven Informationspolitik begegnet.
Stellungnahme der betroffenen Firmen
Russell Castronovo, zuständig für Global Communications bei Sun Microsystems, bestätigte gegenüber tecCHANNEL.de die Sicherheitslücke. Sun sei es möglich gewesen, diese zu reproduzieren, da Gowdiak Sun bereits vorabinformiert habe. Ein Fix für dieses Problem sei fertig und werde an die Lizenznehmer verteilt.
Anja Klein, Pressesprecherin bei Siemens Mobile, und Myriam Hoffmann, Pressesprecherin bei Sony Deutschland, können allerdings noch keine genauen Angaben machen, wann ein Update für die gefährdeten Geräte erscheinen wird. Man sei auf Sun angewiesen, zudem müssen zuerst interne Tests durchgeführt werden.
Andere Handyhersteller wie Nokia oder Motorola haben bislang keine Stellungnahme abgegeben.(mja)