Ende-zu-Ende-Verschlüsselung
Verschlüsselung ist nicht gleich Verschlüsselung
Angriffsmöglichkeiten
Wie schon beschrieben, muss jeder für sich entscheiden, welches Sicherheitsniveau er über seine Daten auch im Falle von Verschlüsselung erreichen möchte. Als Beispiel zur besseren Einordnung möchte ich kurz auf den Fall "Lavabit" eingehen. Die Verschlüsselung von Lavabit fiel in die Klasse 2. Es handelte sich um einen US-amerikanischen Internetdienst, der verschlüsselten Mail-Verkehr realisierte, und zwar rein webbasiert. Nach den wenigen öffentlichen Informationen wurde dieser Dienst offenbar von Edward Snowden genutzt. Forderungen amerikanischer Behörden an den Diensteanbieter zur Offenlegung der Verschlüsselung beziehungsweise aller Nutzerdaten führten letztendlich zur Stilllegung des Dienstes durch den Betreiber selbst.
Obwohl die Verschlüsselung der Klasse 2 durchaus als sehr stark zu bewerten ist, gibt es verschiedene Abhängigkeiten vom Diensteanbieter, die die Verschlüsselung schwächen können. Da das Passwort die Basis für die rein webbasierte Verschlüsselung ist, ist es auch das Ziel eines jeden Angriffs auf diese Verschlüsselung. Da der Server die Berechnung der kryptografischen Schlüssel vornimmt, wird das Passwort zunächst an den Server übertragen. Erfolgreiche Angriffe auf die HTTPS-Verbindung, das heißt die verschlüsselte Übertragung des Passworts, können also die Verschlüsselung selbst brechen.
Eine einfache Möglichkeit für Behörden, die HTTPS-Verbindung zu brechen, ist die Einforderung der privaten Schlüssel des Servers vom Betreiber. Die Verwendung von "Perfect Forward Secrecy" schafft hier zumindest gegen eine nachträgliche Entschlüsselung des HTTPS-Verkehrs Abhilfe.
Wer meint, eine einfache Alternativlösung sei es, das Passwort gar nicht zu übertragen, sondern per JavaScript im Browser des Nutzers zu hashen und nur den abgeleiteten kryptografischen Schlüssel zu übertragen, dem wird schnell klar, dass in diesem Szenario dann der übertragene Schlüssel Ziel des Angriffs ist. Einen Schritt weitergedacht könnte man eine Technik entwickeln, die die Verschlüsselung selbst in JavaScript löst. Kann ein Angreifer jedoch in den HTTPS-Verkehr eingreifen, so wäre es ihm auch möglich, das vom Server gesendete JavaScript entsprechend zu manipulieren.
Dies führt auch zur zweiten Angriffsmöglichkeit auf Dienste aus Klasse 2, nämlich die Manipulation der Software auf dem Server. Hierbei spielt es keine Rolle, ob der Betreiber selbst - zum Beispiel behördlich - zur Manipulation gezwungen wird oder ob es durch Sicherheitslücken auf dem Server Hackern gelungen ist, die eigentliche Applikation zu manipulieren. Durch die Manipulation ließen sich ebenfalls das Nutzerpasswort und die erzeugten kryptografischen Schlüssel stehlen. Wenn der Angreifer bereits Serverzugriff erlangt hat, kann er damit auch nachträglich die verschlüsselten Daten entschlüsseln.
Um es deutlich zu unterstreichen: Fällt die Verschlüsselung in Klasse 2 ohne Verwendung eines Master- oder Backup-Keys seitens des Betreibers, so erfordern alle diese Angriffe ein erneutes Login des angegriffenen Nutzers!
Übrigens gibt es auch in Deutschland vergleichbare Anbieter, so ist zum Beispiel Posteo zu nennen.
Angriffe gegen Verschlüsselungslösungen der Klasse 1 hingegen erfordern immer einen Zugriff auf das entsprechende aktive Endgerät des Anwenders. Auch dies ist selbstverständlich nicht unmöglich, jedoch in der Regel wesentlich schwieriger.
- Woran Sie einen Angriff erkennen
Nach Analysen von McAfee weisen vor allem acht Indikatoren darauf hin, dass ein Unternehmensnetz in die Schusslinie von Hackern geraten ist. Hans-Peter Bauer, Vice President Zentraleuropa bei McAfee, stellt sie vor. - Interne Hosts kommunizieren mit bösartigen oder unbekannten Zieladressen
In jedem Fall verdächtig ist, wenn ein Host-Rechner auf externe Systeme zugreift, deren IP-Adressen auf "Schwarzen Listen" von IT-Sicherheitsfirmen zu finden sind. Vorsicht ist auch dann geboten, wenn Rechner häufig Verbindungen zu Systemen in Ländern aufbauen, zu denen ein Unternehmen keine geschäftlichen Beziehungen unterhält. Dabei kann es sich um den Versuch handeln, Daten aus dem Unternehmen hinauszuschmuggeln. - Interne Hosts kommunizieren mit externen Hosts über ungewöhnliche Ports
Auffällig ist beispielsweise, wenn interne Rechner über Port 80 eine SSH-Verbindung (Secure Shell) zu einem System außerhalb des Firmennetzes aufbauen. SSH nutzt normalerweise Port 22 (TCP). Port 80 ist dagegen die Standardschnittstelle für HTTP-Datenverkehr, also den Zugriff auf das Internet. Wenn ein Host einen ungewöhnlichen Port verwendet, kann dies ein Indiz dafür sein, dass ein Angreifer das System unter seine Kontrolle gebracht hat. Um IT-Sicherheitssysteme zu täuschen, tarnt ein Hacker dann die Kommunikation mit seinem Command-and-Control-Server (C&C) als Anwendung, die jedoch nicht den Standard-Port verwendet. - Öffentlich zugängliche Hosts oder Hosts in entmilitarisierten Zonen (DMZ) kommunizieren mit internen Hosts
Mithilfe solcher Hosts kann es Angreifern gelingen, gewissermaßen "huckepack" in ein Unternehmensnetz einzudringen, Daten zu stehlen oder IT-Systeme zu infizieren. - Warnungen von Malware-Scannern außerhalb der Geschäftszeiten
Verdächtig ist, wenn Antiviren-Programme in der Nacht oder am Wochenende Alarm schlagen, also außerhalb der normalen Arbeitszeiten. Solche Vorkommnisse deuten auf einen Angriff auf einen Host-Rechner hin. - Verdächtige Netzwerk-Scans
Führt ein interner Host-Rechner Scans des Netzwerks durch und nimmt er anschließend Verbindung zu anderen Rechnern im Firmennetz auf, sollten bei Administratoren die Alarmglocken schrillen. Denn dieses Verhalten deutet auf einen Angreifer hin, der sich durch das Netzwerk "hangelt". Vielen Firewalls und Intrusion-Prevention-Systemen (IPS) entgehen solche Aktionen, wie sie nicht entsprechend konfiguriert sind. - Häufung identischer verdächtiger Ereignisse
Ein klassischer Hinweis auf Angriffe ist, wenn mehrere sicherheitsrelevante Events innerhalb kurzer Zeit auftreten. Das können mehrere Alarmereignisse auf einem einzelnen Host sein, aber auch Events auf mehreren Rechnern im selben Subnetz. Ein Beispiel sind Fehler beim Authentifizieren. - Schnelle Re-Infektion mit Malware
Nach dem Scannen mit einer Antiviren-Software und dem Beseitigen eventuell vorhandener Schadsoftware sollte ein IT-System eigentlich längere Zeit "sauber" bleiben. Wird ein System jedoch innerhalb weniger Minuten erneut von Malware befallen, deutet dies beispielsweise auf die Aktivitäten eines Rootkit hin. - Dubiose Log-in-Versuche eines Nutzers
Eigenartig ist, wenn derselbe User innerhalb kurzer Zeit von unterschiedlichen Orten aus Log-in-Versuche in ein Firmennetz startet oder wenn solche Aktionen von Systemen mit unterschiedlichen IP-Adressen aus erfolgen. Eine Erklärung ist, dass die Account-Daten des Nutzers in falsche Hände gefallen sind. Denkbar ist allerdings auch, dass sich ein illoyaler oder ehemaliger Mitarbeiter Zugang zu verwertbaren Daten verschaffen will.