Mobile Security auf den Sicherheitskonferenzen

Mobile Geräte im Visier und unter dem Mikroskop
Kommentare

Die Verbreitung mobiler Geräte nimmt seit Jahren rasant zu, und so wie sie aus dem Alltag kaum mehr weg zu denken sind, sind sie auch auf den Sicherheitskonferenzen überall zu sehen – und das nicht nur bei den Besuchern, sondern auch bei den Vortragenden. Dieser Artikel soll Ihnen einen Überblick über die aktuellen Entwicklungen geben: Womit beschäftigen sich die Sicherheitsforscher?

Die Auswahl der Vorträge auf Sicherheitskonferenzen erfolgte mehr oder weniger willkürlich, und die Zusammenstellung hat nur ein Ziel: Egal ob Entwickler oder Anwender, ob iPhone- oder Android-Benutzer, es soll für jeden etwas dabei sein. Die meisten Vorträge stammen von den „Black Hat“-Konferenzen. Natürlich wurden auch auf anderen Sicherheitskonferenzen Themen zu Mobile Security behandelt, die Black Hats haben aber die besten Archive. Dort finden Sie unter der Beschreibung des Vortrags meist die Präsentation verlinkt, oft auch Whitepaper und/oder eine Videoaufzeichnung des Vortrags. Bei den anderen Konferenzen muss man sich diese Informationen meist zusammensuchen, wenn es sie überhaupt gibt. Ich habe mir daher erlaubt, den einfachsten Weg zu wählen. Außerdem wird so das ziemlich lange Linkverzeichnis nicht weiter aufgebläht. Los geht es mit einigen Vorträgen für Entwickler.

Unsichere Entwicklungspraktiken

Simon Roses Femerling hat auf der Black Hat Europe 2012 über unsichere Entwicklungspraktiken gesprochen: „Smartphone‘s Apps are not that smart: Insecure Development Practices“ [1]. Er vergleicht Apps mit einem „new Web“ und leider hat er damit Recht. So wie es im Web von unsicheren Webanwendungen wimmelt, wimmelt es in den App-Märkten von unsicheren Apps. Dafür gibt es zwei Ursachen, die beide zum gleichen Kernproblem führen: Entweder erfahrene Desktop- und Webentwickler entwickeln Apps, ohne sich mit deren Sicherheitsanforderungen auszukennen, oder unerfahrene Entwickler stürzen sich auf die Apps, ohne viel über sichere Softwareentwicklung zu wissen. Simon Roses Femerling hat die häufigsten Schwachstellen samt Beispielen für betroffene Apps vorgestellt und beschrieben, wie sie verhindert werden können. Außerdem gibt er Tipps, wie der Entwicklungsprozess verbessert werden kann, um zu sicheren Apps zu führen:

  • Die Entwickler müssen sich über mögliche Gefahren und deren Abwehr informieren, sowohl für die Plattform an sich als auch für die jeweilige App.
  • Bei der Entwicklung sollte ein sicherer Entwicklungsprozess verfolgt werden, zum Beispiel Microsofts Security Development Lifecycle (SDL) [2], Comprehensive, Lightweight Application Security Process ( OWASP CLASP) [3] oder Software Assurance Maturity Model (SAMM/OpenSAMM) [4].
  • Für die Apps müssen Bedrohungsmodelle ermittelt werden (Theat Modelling ist zum Beispiel ein Schritt in Microsofts SDL).
  • Die Apps müssen Security Reviews und Tests durchlaufen.

Die Apps können auch mit Funktionen zur Jailbreak-Erkennung ausgestattet werden, Simon Roses Femerling hält das aber für ein verlorenes Rennen. Außerdem erscheint es mir sowieso zwecklos, denn wenn ein Benutzer einen Jailbreak installiert und eine App danach nicht mehr läuft, wird er eher auf die App als auf den Jailbreak verzichten. Außerdem rät Simon Roses Femerling zur Code Obfuscation, von der ich aber abrate: Auch Cyberkriminelle tarnen ihren Schadcode, und generell ist jede Obfuscation verdächtig. Da sie mit mehr oder weniger viel Aufwand aufgehoben werden kann, sollten normale Apps darauf besser verzichten.

Mobile Risiken

Chris Eng hat auf der RSA Conference Europe 2011 die „Top 10 Mobile Application Risks“ vorgestellt [5]. Im ersten Teil des Vortrags ging es um bösartigen Code, der auf vielfältige Art Schaden anrichten kann. Er kann zum Beispiel die Aktivitäten des Benutzers beobachten und Daten ausspähen, SMS weiterleiten, unautorisierte Anrufe durchführen, SMS senden oder Zahlungen tätigen, unautorisierte Netzwerkverbindungen aufbauen, das System modifizieren und logik- oder zeitbasiert Aktionen starten. Außerdem ist er zur UI-Impersonation, das heißt dem Nachahmen von Benutzerinterfaces beliebiger Programme oder des Smartphones, in der Lage.

Thema des zweiten Teils waren Schwachstellen im Code: Datenlecks, die unsichere Speicherung sensitiver Daten, die unsichere Übertragung sensitiver Daten sowie hartkodierte Passwörter und Schlüssel. Für alle Punkte wurden jeweils einige Beispiele aus der Praxis beziehungsweise „in the wild“ vorkommende Schädlinge vorgestellt, um zu zeigen, dass es sich nicht um theoretische Überlegungen, sondern um handfeste Bedrohungen handelt.

Android und die Patches

Mit Androids Patches haben sich Anthony Lineberry, Tim Strazzere und Tim Wyatt auf der Black Hat USA 2011 auseinandergesetzt: „Don’t hate the Player, hate the Game: Inside the Android Security Patch Lifecycle“ [6]. Im Gegensatz zu den anderen Vorträgen, zu denen es immer mindestens die Präsentation, teilweise auch Whitepaper und Videos des Vortrags gibt, ist die Dokumentation in diesem Fall etwas eingeschränkt: Es gibt einen Blogeintrag von Tim Wyatt [7] und einen Verweis auf den Abschnitt „Platform Vulnerabilities + Patching“ im Mobile Threat Report von Lookout [8]. Die drei gingen der Fragestellung „Wie lange dauert es, bis eine heute entdeckte Schwachstelle in Android in den Smartphones der Benutzer gepatcht wird?“ auf den Grund. Dazu wurden Firmware-Update in „millions of Android devices around the world“ ausgewertet.

Währen der Patch-Prozess bei PC-Betriebssystemen recht einfach ist (die Hersteller veröffentlichen die Patches, die dann von den Benutzern installiert werden), sieht er bei mobilen Systemen wie Android deutlich komplizierter aus: Betriebssystementwickler, Smartphonehersteller, Carrier und Benutzer müssen unter einen Hut gebracht werden.

Untersucht wurde die Verbreitung einiger Schadsoftware und der Patches für die davon ausgenutzten Schwachstellen. Nachdem Google eine Schwachstelle entdeckt hat oder sie gemeldet wurde, wird in einigen Tagen oder Wochen der Patch dafür entwickelt. Der fertig getestete Patch wird dann ins Android Open Source Project (AOSP) Repository geladen, von wo aus die Smartphonehersteller und Carrier ihn herunterladen, anpassen und an ihre Kunden verteilen können. Das ist dabei der aufwendigste Prozess, da die Smartphonehersteller die Firmware für alle betroffenen Modelle anpassen und dabei spezielle Anforderungen der Carrier berücksichtigen müssen.

Die „Schwachstellen-Halbwertszeit“ in Form der Zeit, die zwischen der Veröffentlichung einer Schwachstelle und dem Zeitpunkt, zu dem die Hälfte der Geräte im Markt gepatcht sind, vergeht, schwankt dabei stark. Als Beispiel werden die vom Schädling DroidDream genutzte Exploid-Schwachstelle mit 42 Wochen und die nicht ausgenutzte Schwachstelle CVE-2010-1807 (WebKit NaN) mit 30 Wochen genannt.

Schwachstellensuche für Android

Tyrone Erasmus hat auf der Black Hat Europe 2012 einen Vortrag über die Schwachstellensuche auf Android-Geräten gehalten: „The Heavy Metal that poisoned the Droid“ [9]. Nach einer allgemeinen Beschreibung des Android-Sicherheitsmodells und möglicher Schwachstellen wurde die Suche nach Schwachstellen in Apps demonstriert. Dabei hilft ein neues Tool, das Tyrone Erasmus entwickelt hat: Mercury [10]. Das Testframework besteht aus einem Server, der auf dem Android-Gerät läuft, und einem Client, der auf einem PC läuft. Mercury benötigt nur eine Berechtigung INTERNET. Zwei interessante Fakten in diesem Zusammenhang sind folgende:

  1. Jede App kann die Systeminformationen lesen und ein Profil des Geräts erstellen. Um dann zum Beispiel Exploits für vorhandene Schwachstellen zu laden oder die gesammelten Daten an einen Angreifer zu schicken, ist nur die Berechtigung INTERNET nötig.
  2. Jede App kann ohne jede Berechtigung die SD-Card lesen, mit der Berechtigung INTERNET können die Daten dann auf einen Server geladen werden.

Als Beispiele wurden zahlreiche Schwachstellen in Apps aufgeführt, die zum Beispiel das Ausspähen vertraulicher Informationen von Instant Messages über Kontaktdaten und E-Mails bis zu WPA2-Passwörtern erlauben.

Apples Sandkasten

Mit Apples XNU Sandbox hat sich Dionysus Blazakis auf der Black Hat DC 2011 befasst: „The Apple Sandbox“ [11]. Nach einem Überblick über die Sandbox wurde deren Einsatz durch Verwendung des Tools sandbox-exec beschrieben und auf die dabei auftretenden Probleme eingegangen. Danach wurde die Implementierung der Sandbox sowohl im User Space als auch im Kernel unter die Lupe genommen. Wenn Sie also wissen wollen, wie die Sandbox funktioniert – im Whitepaper zum Vortrag dürften Sie die Antwort finden. Kommen wir nun zu einem Thema, das alle betrifft: neue Angriffe.

Gefährlicher USB-Anschluss

Auf der Black Hat DC 2011 haben Angelos Stavrou und Zhaohui Wang über den Missbrauch des USB-Anschlusses am Smartphone gesprochen: „Exploiting Smart-Phone USB Connectivity For Fun And Profit“ [12]. Vorgestellt wurden verschiedene Möglichkeiten, den USB-Anschluss als Einfallstor für Angriffe zu missbrauchen. Dabei wurden alle möglichen Richtungen berücksichtigt: Angriffe vom Computer auf das Smartphone, vom Smartphone auf den Computer und zwischen Smartphones direkt. So kann sich ein präpariertes Smartphone als Human Interface Driver, also beispielsweise als Tastatur, Touchpad oder Maus, ausgeben und beim Anschluss an einen Computer diesen steuern. Ein bösartiger Computer kann auf einem damit verbundenen Smartphone Schwachstellen ausnutzen, um sich Root-Rechte zu verschaffen oder Schadcode einzuschleusen.

Außer Angriffen wurden natürlich auch mögliche Gegenmaßnahmen vorgestellt: eine Authentifizierung der USB-Geräte und das Einbinden des Benutzers, der den Typ des angeschlossenen Geräts und dessen Berechtigungen prüfen muss.

Neue Bedrohungen im Mobile Computing

Auf der RSA Conference Europe 2011 hat Adam Meyers einen Vortrag über neue Bedrohungen im Mobile Computing gehalten: „Emerging Threats in Mobile Computing“ [13]. Nach den üblichen Grundlagen zur mobilen Landschaft und den bekannten Sicherheitsproblemen und Schutzmaßnahmen wurden Angriffsflächen und Angriffsvektoren vorgestellt. Danach ging es ums eigentliche Thema, die neuen Bedrohungen: Schadsoftware, für die Beispiele „in the wild“ aufgeführt wurden, und Angriffe auf die Telefonverbindungen wie GSM Interception und IMSI Catching. Außerdem wurden Remote-Access-Tools und die sichere Entwicklung im Mobilbereich angesprochen.

Software Security goes mobile

Russell Spitler hat auf der Black Hat Abu Dhabi 2011 über das Thema „Software Security goes mobile“ gesprochen [14]. Dabei ist er drei Fragen auf den Grund gegangen: Was ist „mobile“? Wer kümmert sich um Mobile Security? Worum geht es bei Mobile Security? Nachdem die Fragen beantwortet wurden, ging es um Schwachstellen in und Angriffe auf Android und wie man sie verhindert.

Pufferüberläufe auf ARM

Auf der Black Hat DC 2011 hat Itzhak Avraham Angriffe auf Android-Geräte beschrieben: „Popping Shell on A(ndroid)RM Devices“ [15]. Konkret ging es dabei um die Ausnutzung von Pufferüberlaufschwachstellen auf ARM-Geräten. Nach einem Überblick über Pufferüberlaufschwachstellen allgemein ging es dann um die ARM-Prozessoren. Dabei wurden die vorhandenen und nicht vorhandenen Schutzmaßnahmen gegen die Ausnutzung von Pufferüberläufen untersucht und dann beschrieben, wie Pufferüberlaufschwachstellen auf ARM-Systemen unter Android ausgenutzt werden können. Außerdem wurden Möglichkeiten zur Privilegieneskalation untersucht, um Root-Rechte zu erhalten. Avrahams Fazit: Pufferüberlaufschwachstellen sind auch auf ARM-Systemen eine Bedrohung, und die Entwickler sollten alle Gegenmaßnahmen ergreifen, die ihnen möglich sind.

Blick über die Schulter

Für den folgenden Vortrag wurden leider keine Materialien veröffentlicht, trotzdem ist er eine Erwähnung wert: Federico Maggi, Stefano Zanero und Alberto Volpatto haben auf der Black Hat Abu Dhabi 2011 unter dem Titel „iSnoop: How to steal Secrets from Touchscreen Devices“ demonstriert, wie ein Angreifer Eingaben auf dem Touchscreen ausspähen kann [16]. Damit wurde das Shoulder Surfing automatisiert, und zwar mit beachtlichem Erfolg. Eine auf den Touchscreen des Opfers gerichtete Kamera zeichnet die Bewegungen des Benutzers und das Feedback des Touchscreens auf, aus denen dann die Tastendrücke ermittelt werden. Dabei konnten bis zu 97.07 Prozent der Tastendrücke erkannt werden, die Fehlerrate lag bei 1.15 Prozent. Als Beispiel wurde das iPhone ausgewählt, der Angriff ist aber auf andere Touchscreengeräte übertragbar. Sie sollten in Zukunft also drauf achten, dass Ihnen keine Kamera beim Eintippen vertraulicher Daten zusieht.

Neue Angriffe auf iOS

Neue Angriffe aus iOS sowie zugehörige Gegenmaßnahmen wurden von Nitesh Dhanjani auf der Black Hat Europe 2011 vorgestellt: „New Age Attacks against Apple‘s iOS (and Countermeasures)“ [17]. Beschrieben wurde Folgendes:

  • Angriffe auf Protokollhandler, zum Beispiel über unsichere URLScheme-Implementierungen wie die von Skype, die einem Angreifer das Durchführen von Skype-Anrufen unbemerkt vom Benutzer erlauben
  • Spoofing des User Interface, beispielsweise für Phishing-Angriffe
  • Missbrauch von Push Notifications
  • Man-in-the-Middle-Angriffe, Privacy Leaks (die unfreiwillige Freigabe vertraulicher Daten wie der UDID (Unique Device ID) und Möglichkeiten zum Ermitteln der Identität des Benutzers

Dazu wurden die jeweiligen Gegenmaßnahmen genannt. Außerdem wurde der Schutz vorhandener Daten (Data at Rest) beschrieben. Im Anhang des Whitepapers gibt es eine „iOS Application Security Assessment Checklist“ zur Prüfung der Sicherheit von iOS und Apps.

Chrome OS im Visier

Matt Johansen und Kyle Osborn haben sich auf der Black Hat USA 2011 Googles Chrome OS angenommen: „Hacking Google Chrome OS“ [18]. Dazu nutzten sie einen von Google bereitgestellten Cr-48-Prototypen des Chromebooks. Das besondere an Chrome OS und den damit betriebenen Chromebooks ist die rein browserbasierte Oberfläche, alles findet in der Cloud statt. Egal ob E-Mail, Textverarbeitung, Terminverwaltung, alles läuft in der Cloud und ist dadurch potenziell für die üblichen Webangriffe wie Cross-Site Scripting, Cross-Site Request Forgery und Clickjacking anfällig. Gelingt es einem Angreifer, die Schutzmaßnahmen von Chrome OS zu überwinden, erlangt er Zugriff auf alle Benutzerdaten.

Johansen und Osborn fanden eine Reihe von Schwachstellen, aber auch Angriffsmöglichkeiten auf Anwendungen ohne eigene Schwachstellen. Für die Angriffe kann das Browser Exploitation Framework BeFF [19] genutzt werden, für das neue Plug-ins entwickelt wurden. Möglich sind zum Beispiel das Ausspähen von E-Mails, Kontakten und gesicherten Dokumenten und durch Ausspähen des Session-Cookies die Übernahme des Google-Accounts. Es gibt aber auch gute Nachrichten: Während Chrome OS für webbasierte Angriffe relativ offen ist, sind herkömmliche Angriffe fast ausgeschlossen. Es gibt quasi keinen lokalen Speicher und der Browser verwendet eigene Plug-ins, sodass die meisten aktuellen Angriffe durch Schadsoftware ins Leere laufen.

Mit der Sicherheit von Chrome OS haben sich auch die Google-Mitarbeiter Will Drewry und Sumit Gwalani auf der RSA Conference Europe 2011 beschäftigt: „Chrome OS – Practical Security“ [20]. Sie beschrieben die zugrunde liegende Sicherheitsarchitektur und ihre Umsetzung vom sicheren Bootprozess über die Minimierung der Angriffsfläche des Systems zur sicheren Verwaltung und dem Beheben möglicher Schwachstellen.

Angriffe auf den iOS-Kernel

Stefan Esser hat auf der Black Hat USA 2011 Angriffe auf den iOS-Kernel beschrieben: „Exploiting the iOS Kernel“ [21]. Um ein iOS-Gerät vollständig unter seine Kontrolle zu bekommen, muss Code in den Kernel eingeschleust werden. Nach einigen Grundlagen hat Stefan Esser erst einmal gezeigt, wie man den im iOS-Kernel enthaltenen Debugger nutzen kann: Indem man den seriellen Anschluss im iPhone Dock Connector nutzt und den Debugger des iPhone SDK über den SerialKDPProxy mit dem iPhone verbindet. Danach wurde die Ausnutzung eines Stack- und eines Heap-basierten Pufferüberlaufs im Kernel beschrieben. Zum Abschluss wurden dann noch die im Rahmen von Jailbreaks installierten Kernel-Patches und deren Auswirkungen auf die Schutzfunktionen von iOS untersucht. Wie sieht es denn mit der Sicherheit von diesem und jenem aus?

Passwortsicherheit

Andrey Belenko und Dmitry Sklyarov befassten sich auf der Black Hat Europe 2012 mit der Sicherheit von Passwortmanagern: „Secure Password Managers and Military-Grade Encryption on Smartphones: Oh Really?“ [22]. Beim üblichen Verfahren zum Sichern von Daten werden diese mit einem zufällig erzeugten Master Key verschlüsselt, der dann selbst wieder verschlüsselt gespeichert wird, am besten in einem Hardware Security Module. Der Zugriff auf den Master Key wird über ein Zugriffskontrollsystem geregelt. Während auf einem PC das Trusted Platform Module, Biometrie, Smartcard mit PIN oder Passwort beziehungsweise Passphrase zur Sicherung des Master Key verwendet werden können, gibt es auf dem Smartphone nur eine Möglichkeit: Passwort beziehungsweise Passphrase. Sie sind noch dazu im Allgemeinen schlechter als die auf einem PC, da sie sich durch die kleine Tastatur nur schwer eingeben lassen und aufwendige Berechnungen die ohnehin schwache CPU zu sehr belasten. Ein Angreifer kann dagegen auf einen PC mit dessen größerer Rechenleistung und gegebenenfalls GPU-Unterstützung zurückgreifen.

Untersucht wurde, was ein Angreifer erreichen kann, der zum Beispiel physikalischen Zugriff auf das Smartphone, eine Kopie des Backups des Geräts oder Zugriff auf die Datenbank des Passwortmanagers hat (oder eine beliebige Kombination dieser drei Punkte). Das Angriffsziel ist dann entweder das Ermitteln des Master-Passworts für den Passwortmanager oder das Extrahieren der im Passwortmanager gespeicherten Passwörter. Ausgehend von diesen Voraussetzungen folgt dann eine Vorstellung verschiedener Passwortmanager für BlackBerry und iOS samt Vor- und Nachteilen

Mobile Schadsoftware im Überblick

Auf der Black Hat USA 2011 gab Neil Daswani einen Überblick über mobile Schadsoftware und wie man sie erkennt: „Mobile Malware Madness, and how to cap the Mad Hatters“ [23]. Als Beispiele dienten DroidDream (Android), Ikee.A (iOS) und Zitmo (Symbian, BlackBerry, Windows Mobile).

Zur Erkennung von Schadsoftware gibt es die Verhaltensanalyse (Behavioral Analysis), bei der der Schadcode bei der Ausführung beobachtet und aus seinem Verhalten auf schädliche Absichten geschlossen wird und die signaturbasierte Erkennung, bei der bekannte Schädlinge anhand ihres „Fingerabdrucks“ erkannt werden. Für Mobilgeräte bietet sich eine Kombination beider Ansätze an: Während die rechenintensive Verhaltensanalyse in der Cloud durchgeführt wird, werden die Schädlinge auf den mobilen Geräten anhand der dabei ermittelten Signaturen erkannt.

Als Test wurden zufällig 10 000 Apps aus Googles Android Marketplace ausgewählt und jeweils für 30 Sekunden in einem Emulator analysiert. Dabei wurden Apps gefunden, die die IMEI verraten oder unerwünschte SMS senden, außerdem wurden verdächtige Verhaltensmuster identifiziert.

Der Ansatz eignet sich also zum Erkennen bösartiger Apps. Ein Problem, dass sich so nicht lösen lässt, sind Drive-by-Infektionen auf mobilen Geräten, bei denen schon der Besuch einer harmlosen, aber kompromittierten Website ausreicht, um das Smartphone mit Schadsoftware zu infizieren, die eine Schwachstelle im Browser oder System ausnutzt.

Das verschlüsselte Dateisystem ab iOS 4

Mit dem verschlüsselten Dateisystem von iOS ab Version 4 hat sich Andrey Belenko auf der Black Hat USA 2011 befasst: „Overcoming iOS Data Protection to Re-enable iPhone Forensic“ [24]. Für eine forensische Untersuchung, zum Beispiel zur Suche nach Spuren eines Angriffs, wird ein physikalischer Zugriff auf die betroffenen Massenspeicher benötigt. Ab iOS 4 reicht das aber nicht mehr aus, da das Dateisystem teilweise verschlüsselt ist. Zwar sind die Metadaten unverschlüsselt, sodass die Dateinamen und Properties lesbar sind, die Dateiinhalte sind aber in der Regel verschlüsselt. Andrey Belenko hat erklärt, was und wie verschlüsselt wird und wie die Daten wieder entschlüsselt werden können. Einen Überblick über die Schutzfunktionen von iOS 3 bis iOS 5 haben Andrey Belenko und Dmitry Sklyarov auf der Black Hat Abu Dhabi 2011 gegeben: „Evolution of iOS Data Protection and iPhone Forensics: from iPhoneOS to iOS 5“ [25].

Die Sicherheit von iOS 4 unter der Lupe

Dino Dai Zovi hat auf der Black Hat USA 2011 die Sicherheitsfunktionen von iOS 4 analysiert: „Apple iOS Security Evaluation: Vulnerability Analysis and Data Encryption“ [26]. Nach einer Einführung in mögliche Bedrohungen wurden die Address Space Layout Randomization (ASLR), die Signierung des Codes samt Prüfung der Signatur, die Sandbox und die Datenverschüsselung beschrieben und mögliche Schwachstellen beziehungsweiser Angriffe aufgezeigt. Zum Schluss dieses Artikels gibt es noch ein paar Tipps für Reisende.

Ratschläge für USA-Reisende

Ratschläge für USA-Reisende mit digitalen Geräten gaben Marcia Hofmann und Seth Schoen auf der Black Hat Europe 2012: „Defending Privacy at the U.S. Border: a Guide for Travelers Carrying Digital Devices“ [27]. Die Präsentation zum Vortrag trägt den Titel „Laptop and Electronics Searches at the U. S. Border“, und genau um diese Durchsuchungen geht es auch im Wesentlichen: Welche rechtlichen Grundlagen für Durchsuchungen digitaler Geräte gibt es generell, und welche Behörden setzen diese in welchem Umfang und mit welchen Begründungen um? Danach geht es um die Frage, wie man diesen Durchsuchungen begegnet. Dabei werden verschiedene Punkte angesprochen.

Nehmen Sie nur das Nötigste mit auf die Reise („don’t bring what you don’t need“): Installieren Sie ein neues System, speichern Sie Daten auf einen Server und laden Sie sie von dort nach dem Überqueren der Grenze herunter, oder schicken Sie Laptops oder Datenspeicher mit der Post, statt sie als Handgepäck mit zu nehmen.

Verschlüsseln Sie die Daten („encryption“): Wählen Sie ein sicheres Passwort (und geben Sie sich dabei Mühe, denn Sie können davon ausgehen, dass die Behörden die meisten durch Brute Force brechen können), aber denken Sie daran, dass das Verschweigen des Passworts gegebenenfalls auch unangenehme Folgen haben kann. Es ist also besser, das Passwort beim Grenzübertritt gar nicht zu kennen, zum Beispiel weil es Ihnen erst nach der Ankunft mitgeteilt wird. Wenn Sie nicht die ganze Festplatte, sondern nur Teile davon verschlüsseln, achten Sie darauf, dass keine verräterischen Daten wie Dateinamen, im unverschlüsselten Bereich zurück bleiben.

Ein weiterer zu berücksichtigender Punkt: das sichere Löschen von Daten, insbesondere einzelnen Dateien, ist nicht ganz einfach. Meist lassen sich die Daten wieder herstellen. Das Löschen der kompletten Festplatte, bei dem die Daten einmal überschrieben werden, ist dagegen im Allgemeinen ausreichend, um eine Wiederherstellung zu verhindern. Für verschiedene Geräteklassen gibt es unterschiedliche Probleme zu berücksichtigen:

  • Mobile Geräte ermöglichen meist keine Verschlüsselung der kompletten Festplatte und auch das sichere Löschen von Dateien ist nicht möglich.
  • Digitalkameras ermöglichen kein sicheres Löschen der Bilder, ein einfaches undelete-Programm reicht im Allgemeinen zum Wiederherstellen der Bilder aus.

Zum Schluss gabt es noch einige Hinweise zum Umgang mit den Kontrolleuren und die Warnung vor möglicherweise noch schlimmeren Zuständen in anderen Staaten. Außer der Präsentation (und einem Video) gibt es auch ein ausführliches Whitepaper. Für die von Ihnen, die in die USA reisen müssen, eine sicher lohnenswerte Lektüre (wenn Sie sie nicht sowieso schon kennen).

Fazit

In der IT-Sicherheit gibt es ständig neue Entwicklungen, und das gilt natürlich auch für mobile Geräte. Neue Angriffe erfordern neue Schutzmaßnahmen, neue Schutzfunktionen führen zu neuen oder angepassten Angriffen, dazu kommen neue Schwachstellen, und das macht das Ganze doch eigentlich erst interessant.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -