DsiN-Blog

Der IT-Sicher­heitsblog für den Mittelstand

Themen

Tipp des Monats

Machen Sie in nur zehn Minuten den IT-Sicher­heits­check von Deutschland sicher im Netz. Der Test liefert Hand­lungs­emp­feh­lungen, mit denen Sie die eigene IT-Sicher­heitslage ver­bessern können.

News­letter

Um neue Bei­träge regel­mäßig zu erhalten, können Sie hier unseren News­letter abonnieren:

Cyber­at­tacken

Erraten Sie, wer (außer dem Militär und direkt betei­ligten Per­sonen) als Erstes wusste, wenn die USA einen neuen Angriff vor­be­reitet haben bzw. eine Krise am Kochen war? Spione? Clever als Raum­pfle­ge­rinnen getarnte Deep-Under­­cover Jour­na­lis­tinnen? Familie und Freunde hoch­ran­giger Militärs?

Alles gut möglich, aber: nein.
Lange Zeit waren das die Essens­lie­fer­dienste rund um das Pentagon.
 
Kri­sen­meeting oder Ähn­liches bedeutet übli­cher­weise, dass eine signi­fi­kante Anzahl an Per­sonen über lange Zeit­räume und zu unkon­ven­tio­nellen Zeiten zusammen sitzt. Das Kan­ti­nen­per­sonal ist schon längst nach Hause gegangen, und was dann noch bleibt ist der Piz­za­lie­ferant um die Ecke. Wenig über­ra­schend ist es auch sehr viel ein­facher, dort einen Men­schen ein­zu­schleusen — oder jemand extra Bargeld zu ver­sprechen, wenn diese Person unge­wöhnlich große Bestel­lungen außerhalb der nor­malen Pen­tagon-Dienst­­zeiten kurz an eine Han­dy­nummer meldet.

Wie nahezu alles in der Cyber­se­curity ist auch dieses Thema nicht neu. Bei Feld­zügen und Bela­ge­rungen vor Jahr­hun­derten gab es bereits desi­gnierte Per­sonen, die nur das Zelt des geg­ne­ri­schen Heer­führers aus der Ferne beob­achtet haben. Nach ein paar Tagen wussten sie, dass dieser bei­spiels­weise morgens von drei Läufern ver­schiedene Depe­schen seiner Unter­linge bekommt.
Am Abend schickt er dann viel­leicht wieder drei Läufer mit wei­teren Anwei­sungen. Diese Routine, egal wie sie auch immer aus­sehen mag, wird irgendwann Normalverhalten.
Jede Abwei­chung davon ist poten­tiell inter­essant — wenn bei­spiels­weise eines Morgens zehn Läufer mit Depe­schen in ver­schie­denste Rich­tungen aus­ge­sendet werden, weiß man, dass ein Angriff oder eine Aktion unmit­telbar bevor­steht, auch wenn man die Inhalte der Depe­schen nicht kennt.
 
In der IT gibt es viele Bei­spiele für Angriffe über solche soge­nannten Sei­ten­kanäle; Infor­ma­tionen, die mit der eigent­lichen Sache rein gar nichts zu tun haben (große Piz­zabe­stellung am Abend mit dem Beginn des Irak­kriegs), aber für einen Gegen­spieler letztlich Infor­ma­ti­ons­vor­teile bedeuten.
 
Man kann durch die Beob­achtung der Depe­schen­läufer zwar nicht ver­hindern, dass der Angriff statt­findet, man findet aber heraus, wann — und das kann stra­te­gi­scher Vorteil sein. Trans­fe­rieren wir das Bei­spiel mal auf einen Angriff auf eine Web­seite. Der Angreifer möchte wissen, welche User­namen für ein Log­infeld erlaubt sind, und welche nicht.
 
Zu dem Zweck auto­ma­ti­siert er seinen Part des Log­invor­gangs (manuell wäre der Aufwand meist zu hoch) und misst die Zeit, die bis zur Ablehnung des Anmel­de­vor­gangs vergeht — ein typi­scher soge­nannter Timing-Angriff. Hat die Web­seite bzw. der Authen­ti­sie­rungs­me­cha­nismus keine Gegen­maß­nahmen ein­ge­plant, pas­siert folgendes:

  1. Der Angreifer misst die Zeit, die ver­gangen ist, um einen höchst­wahr­scheinlich ungül­tigen User (“Jhbs­jfbd­saUG­D­SADSjb” zum Bei­spiel) mit belie­bigem Passwort abzu­lehnen. Am Beginn der Authen­ti­sierung steht meist die Über­prüfung, ob der ein­ge­gebene User gültig ist. Gibt es diesen nicht, wird eine Feh­ler­meldung zurück­ge­geben oder aber es klappt eben einfach nicht und der Angreifer landet wieder auf der Login-Seite. Es kommt auch nicht darauf an, ob etwas Sinn­volles in der Feh­ler­meldung steht wie “Username falsch” oder ob es eine gene­rische Feh­ler­meldung ist (“Username oder Passwort falsch”), oder es gar keine Feh­ler­meldung gibt: ent­scheidend ist die ver­gangene Zeit. Nehmen wir als Bei­spiel 100 ms.
  2. Der erste Schritt wird einige Male wie­derholt, um ein gutes sta­tis­ti­sches Mittel bilden zu können. Hier wird der Angreifer Quell-IPs und User­namen vari­ieren, damit keine Schutz­me­cha­nismen wie Ver­zö­ge­rungen nach Falscheingabe etc. wirken.
  3. Als nächstes werden Listen mit wahr­scheinlich vor­han­denen Nut­zer­namen durch­ge­gangen, wieder mit belie­bigem Passwort. Die Zeit wird nach wie vor gemessen. Weicht die Zeit deutlich von der vorher gemes­senen ab, hat man mit hoher Tref­fer­quote einen gül­tigen Benutzer. Der erste Schritt des Authen­ti­sie­rungs­me­cha­nismus war fest­zu­stellen, ob es denn Benutzer gibt. Wenn das so ist, wird das Passwort kryp­to­gra­phisch ver­glichen mit dem gespei­cherten Hash für diesen User. Diese Berechnung benötigt Zeit — nicht lange genug, um einem Men­schen auf­zu­fallen (übli­cher­weise), aber sie addiert einige Mil­li­se­kunden 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 bei­spiels­weise nicht mehr 100 ms, sondern 300 ms.
  4. Voila — der Angreifer verfügt nun über gültige Benut­zer­namen und muss nun noch Pass­wörter dazu finden. Je nachdem, wie die Web­seite das zulässt, kann er es mit den belieb­testen Pass­wörtern ver­suchen 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 Imple­men­tierung einer Authen­ti­sierung kann das Pro­gramm so gestaltet werden, dass alle ein­zelnen Schritte wie Check des Users sowie Check des Pass­worts durch­laufen werden, bevor eine Feh­ler­meldung zurück gegeben wird. Alter­nativ oder zusätzlich kann eine Zufalls­kom­po­nente mit ein­gebaut werden. Wenn ein Schritt in der Kette “Warte 30 ms — 2000 ms vor der Rückgabe einer Erfolgs- oder Feh­ler­meldung” ist, wird eine Messung des Nor­mal­zu­stands für den Angreifer schwieriger.

Als Pen­tagon kann man Küchen­per­sonal 7*24 (nach exten­sivem Hin­ter­grund­check) ein­stellen, und der Feldherr kann ab und zu mal zur Ablenkung anders handeln, als bisher beob­achtet, um die Erkennung eines Nor­mal­zu­stands zu erschweren.

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

 

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Stefan Hager, DATEV eG

Beschäftigt sich seit den späten 80ern mit Themen rund um Cyber-Security. Beruflich erfolgte die Fokus­sierung auf die Absi­cherung von Netz­werken sowie Bedro­hungen aus dem Internet in 1999, mit Arbeits­plätzen in Schottland und Deutschland. Seit 2010 tätig für die DATEV in The­men­ge­bieten rund um Netz­werk­si­cherheit und Internet-Security.

 

Koope­ra­ti­ons­partner

Für DATEV sind Daten­schutz und Daten­si­cherheit seit Gründung des Unter­nehmens zen­trale Ele­mente in der Geschäfts­po­litik. Daher enga­giert sich DATEV mit dem Blog für mehr IT-Sicherheit im Mittelstand.