Angriffe über Seitenkanäle

Autor: Stefan Hager / Erstveröffentlichung 2016

Angriffe über Seitenkanäle

Erraten Sie, wer (außer dem Militär und direkt beteiligten Personen) als Erstes wusste, wenn die USA einen neuen Angriff vorbereitet haben bzw. eine Krise am Kochen war? Spione? Clever als Raumpflegerinnen getarnte Deep-Undercover Journalistinnen? Familie und Freunde hochrangiger Militärs?

Alles gut möglich, aber: nein.
Lange Zeit waren das die Essenslieferdienste rund um das Pentagon.

Krisenmeeting oder Ähnliches bedeutet üblicherweise, dass eine signifikante Anzahl an Personen über lange Zeiträume und zu unkonventionellen Zeiten zusammen sitzt. Das Kantinenpersonal ist schon längst nach Hause gegangen, und was dann noch bleibt ist der Pizzalieferant um die Ecke. Wenig überraschend ist es auch sehr viel einfacher, dort einen Menschen einzuschleusen - oder jemand extra Bargeld zu versprechen, wenn diese Person ungewöhnlich große Bestellungen außerhalb der normalen Pentagon-Dienstzeiten kurz an eine Handynummer meldet.

Wie nahezu alles in der Cybersecurity ist auch dieses Thema nicht neu. Bei Feldzügen und Belagerungen vor Jahrhunderten gab es bereits designierte Personen, die nur das Zelt des gegnerischen Heerführers aus der Ferne beobachtet haben. Nach ein paar Tagen wussten sie, dass dieser beispielsweise morgens von drei Läufern verschiedene Depeschen seiner Unterlinge bekommt.
Am Abend schickt er dann vielleicht wieder drei Läufer mit weiteren Anweisungen. Diese Routine, egal wie sie auch immer aussehen mag, wird irgendwann Normalverhalten.
Jede Abweichung davon ist potentiell interessant - wenn beispielsweise eines Morgens zehn Läufer mit Depeschen in verschiedenste Richtungen ausgesendet werden, weiß man, dass ein Angriff oder eine Aktion unmittelbar bevorsteht, auch wenn man die Inhalte der Depeschen nicht kennt.

In der IT gibt es viele Beispiele für Angriffe über solche sogenannten Seitenkanäle; Informationen, die mit der eigentlichen Sache rein gar nichts zu tun haben (große Pizzabestellung am Abend mit dem Beginn des Irakkriegs), aber für einen Gegenspieler letztlich Informationsvorteile bedeuten.

Man kann durch die Beobachtung der Depeschenläufer zwar nicht verhindern, dass der Angriff stattfindet, man findet aber heraus, wann - und das kann strategischer Vorteil sein. Transferieren wir das Beispiel mal auf einen Angriff auf eine Webseite. Der Angreifer möchte wissen, welche Usernamen für ein Loginfeld erlaubt sind, und welche nicht.

Zu dem Zweck automatisiert er seinen Part des Loginvorgangs (manuell wäre der Aufwand meist zu hoch) und misst die Zeit, die bis zur Ablehnung des Anmeldevorgangs vergeht - ein typischer sogenannter Timing-Angriff. Hat die Webseite bzw. der Authentisierungsmechanismus keine Gegenmaßnahmen eingeplant, passiert folgendes:

Der Angreifer misst die Zeit, die vergangen ist, um einen höchstwahrscheinlich ungültigen User ("JhbsjfbdsaUGDSADSjb" zum Beispiel) mit beliebigem Passwort abzulehnen. Am Beginn der Authentisierung steht meist die Überprüfung, ob der eingegebene User gültig ist. Gibt es diesen nicht, wird eine Fehlermeldung zurückgegeben oder aber es klappt eben einfach nicht und der Angreifer landet wieder auf der Login-Seite. Es kommt auch nicht darauf an, ob etwas Sinnvolles in der Fehlermeldung steht wie "Username falsch" oder ob es eine generische Fehlermeldung ist ("Username oder Passwort falsch"), oder es gar keine Fehlermeldung gibt: entscheidend ist die vergangene Zeit. Nehmen wir als Beispiel 100 ms.

Der erste Schritt wird einige Male wiederholt, um ein gutes statistisches Mittel bilden zu können. Hier wird der Angreifer Quell-IPs und Usernamen variieren, damit keine Schutzmechanismen wie Verzögerungen nach Falscheingabe etc. wirken.

Als nächstes werden Listen mit wahrscheinlich vorhandenen Nutzernamen durchgegangen, wieder mit beliebigem Passwort. Die Zeit wird nach wie vor gemessen. Weicht die Zeit deutlich von der vorher gemessenen ab, hat man mit hoher Trefferquote einen gültigen Benutzer. Der erste Schritt des Authentisierungsmechanismus war festzustellen, ob es denn Benutzer gibt. Wenn das so ist, wird das Passwort kryptographisch verglichen mit dem gespeicherten Hash für diesen User. Diese Berechnung benötigt Zeit - nicht lange genug, um einem Menschen aufzufallen (üblicherweise), aber sie addiert einige Millisekunden auf den Vorgang. Der Login-Versuch schlägt natürlich nach wie vor fehl, weil das Passwort inkorrekt ist, aber der Vorgang dauert jetzt eben beispielsweise nicht mehr 100 ms, sondern 300 ms.

Voila - der Angreifer verfügt nun über gültige Benutzernamen und muss nun noch Passwörter dazu finden. Je nachdem, wie die Webseite das zulässt, kann er es mit den beliebtesten Passwörtern versuchen oder einen Brute Force - Angriff starten.

Auf den ersten Blick sieht es so aus, als könnte man sich kaum gegen so etwas schützen. Was kann man also tun? Bei der Implementierung einer Authentisierung kann das Programm so gestaltet werden, dass alle einzelnen Schritte wie Check des Users sowie Check des Passworts durchlaufen werden, bevor eine Fehlermeldung zurück gegeben wird. Alternativ oder zusätzlich kann eine Zufallskomponente mit eingebaut werden. Wenn ein Schritt in der Kette "Warte 30 ms - 2000 ms vor der Rückgabe einer Erfolgs- oder Fehlermeldung" ist, wird eine Messung des Normalzustands für den Angreifer schwieriger.

Als Pentagon kann man Küchenpersonal 7*24 (nach extensivem Hintergrundcheck) einstellen, und der Feldherr kann ab und zu mal zur Ablenkung anders handeln, als bisher beobachtet, um die Erkennung eines Normalzustands zu erschweren.

Und schon hat es ein Angreifer oder eine feindlich gesonnene Person wieder schwerer.