Posts mit dem Label preimage Angriff werden angezeigt. Alle Posts anzeigen

Europas wichtigste Fachmesse für Gesundheits IT geht nach drei Tagen am 27.4.2017 zu Ende. Neben den klassischen Angeboten für IT-Lös...

Europas wichtigste Fachmesse für Gesundheits IT geht nach drei Tagen am 27.4.2017 zu Ende. Neben den klassischen Angeboten für IT-Lösungen in Krankenhäusern und Gesundheitseinrichtungen, ist nach 2016 der Bereich Netzwerksicherheit und Endpoint-Protection verstärkt in den Fokus der Unternehmen im Gesundheitssektor gerückt.


Nicht nur für Mediziner und Verwalter bot die conhIT also interessante Lösungen, auch die zahlreichen Mitarbeiter der IT-Abteilungen kamen voll auf ihre Kosten. Unter anderem an unserem Stand in Halle 3.2, wo sich Interessenten, Vertriebspartner, aber auch Studenten und Mitbewerber über Application Whitelisting zur Absicherung gegen unerwünschte Schadsoftware informierten.

Doch der Reihe nach. Bereits 2016 war SecuLution als Mitaussteller auf der conhIT. Nach den durchweg positiven Reaktionen und vielen Neukunden im vergangenen Jahr, haben wir unser Engagement auf der conhIT erweitert. 2017 ist SecuLution mit einem komplett neu gestalteten, eigenen Messestand vertreten.


Interessierte Besucher konnten an zwei Demo-Points die SecuLution Application Whitelisting Suite in Aktion erleben und bekamen ihre Fragen von unserem Messeteam rund um Geschäftsführer Torsten Valentin beantwortet. Hier haben sich vor allem die zahlreichen Studenten der Studienrichtungen eHealth IT, medizinische Informatik und Bioinformatik intensiv mit dem Ansatz des Application Whitelisting auseinandergesetzt. Kritische Fragen zu Schwachstellen und immer wieder bereits bekannte Gesichter mit neuen Fragen kamen zu uns.

"Sind Hash-Kollisionen wie die jüngst gefundenen bei SHA1 und natürlich auch MD5 nicht ein sicherheitsrelevantes Risiko wenn ihre Software nur anhand von Hashwerten ein Programm prüft?"
"Was passiert denn wenn ich als Angreifer den Server mit der Whitelist ausschalte oder in irgendeiner Form vom Netzwerk isoliere? Dann wären die Clients doch schutzlos weil nichts mit der Whitelist geprüft werden kann, oder?"
"Ich habe da nochmal drüber nachgedacht, wie sieht das eigentlich aus wenn ich Schadsoftware mit USB Sticks direkt ins Netzwerk bringe?"

Diese und andere Fragen zeigen, dass die zukünftigen Mitarbeiter sich intensiv mit der Materie auseinandersetzen. Die Branche kann stolz sein auf die kommende Generation von IT Spezialisten.

Doch nicht nur Studenten zeigten besonderes Interesse. Auch die gut besuchte Messeführung, die am ersten Tag bei uns Station machte und Geschäftsführer Torsten Valentin gebannt zuhörte, brachte zahlreiche Interessenten zu uns. Einer der Teilnehmer berichtete sogar, er habe IT-Sicherheit gar nicht auf seiner Agenda für die conhIT und wurde durch unsere Lösung positiv überrascht.


Alles in allem hatten wir eine großartige Woche und haben viele neue Kontakte knüpfen können. Freuen uns andererseits natürlich immer, bereits bekannte Gesichter und treue Kunden auf der Messe wieder einmal persönlich zu treffen und uns auszutauschen.

Application Whitelisting hat trotz aller positiven Resonanz noch einen weiten Weg vor sich, um als echte Alternative zu bekannten Sicherungsmethoden wahrgenommen zu werden. Das zeigt vor allem die immer noch bestehende Unbekanntheit und die vielen Vorurteile die diesem Prinzip vorauseilen.
Die conhIT 2017 war für SecuLution daher auch ein weiterer Schritt auf dem Weg, mit immer wieder angeführten Vorurteilen gegenüber Application Whiltelisting, aufzuräumen.
  • Whitelisting kann nicht nur in statischen Netzwerken eingesetzt werden, tägliche Updates und Patches stellen keine Hindernisse für die Funktionsweise dar.
  • Große Teile der Software erledigen automatisiert ihre Aufgaben, der Administrationsaufwand reduziert sich dadurch erheblich.
  • Administratoren haben wieder Kontrolle über die im Netzwerk genutzte Software.
  • Ausfallzeiten und Schäden durch unerwünschte Software gehören mit Whitelisting der Vergangenheit an. 
uvm.
Diese und andere Punkte werden wir auch zukünftig unermüdlich für den Einsatz von Whitelisting anführen. Wir bedanken uns bei den Organisatoren der Messe Berlin, uns für diese Mission wieder einmal eine großartige Plattform aufgestellt zu haben. Die conhIT 2017 war bestimmt nicht unsere letzte.

Hier noch einige Eindrücke von der conhIT 2017: 


Ende Februar 2017 verkündete eine Gruppe Forschern von Google und dem CWI Institut Amsterdam, den 1995 von der NSA freigegebenen SHA...

Hash Collision is not relevant for Software Whitelisting
Ende Februar 2017 verkündete eine Gruppe Forschern von Google und dem CWI Institut Amsterdam, den 1995 von der NSA freigegebenen SHA-1 Algorithmus in Bezug auf Kollisionsresistenz gebrochen zu haben.

Bisher galt SHA1 als sicher.

Ist das jetzt nicht mehr so?
Und was hat das alles mit dem älteren Bruder MD5 zu tun?

Unser Application Whitelisting beispielsweise nutzt das MD5 Verfahren, um z.B. eine ausführbare Datei anhand des resultierenden MD5 Hashes eindeutig zu identifizieren. Man kann das Verfahren mit einem elektronischen Fingerabdruck vergleichen. In letzter Zeit häufen sich Bedenken, dass jeder mit frei erhältlichen Programmen eine Hash Kollision zweier unterschiedlicher Datensätze erzeugen und somit das Prinzip, auf dem unsere Sicherheitslösung aufbaut, überlisten könne.
Wir möchten in diesem Beitrag erklären, warum MD5 und auch SHA-1 zwar in Bezug auf ihre Kollisionsresistenz kryptografisch gebrochen sind, aber dennoch vollkommen sicher im Bezug auf unsere Verwendung für die eindeutige Identifizierung von Computer Software sind. Der Beitrag ist keine wissenschaftliche Abhandlung über Kryptografie.

Kryptographie und Identifizierung

Eines der bekanntesten Beispiele für die kryptografische Verschlüsselung von Nachrichten aus dem letzten Jahrhundert ist sicherlich die Enigma. Es handelt sich hierbei um eine eine Rotor-Schlüsselmaschine, die im Zweiten Weltkrieg zur Verschlüsselung des Nachrichtenverkehrs des deutschen Militärs verwendet wurde. Das zugrunde liegende Verfahren wies jedoch eine Schwachstelle auf (fixpunktfreie Permutation). In der Konsequenz konnten die Alliierten alle Nachrichten über Positionen und Verlegungen der Flotten der deutschen Marine entschlüsseln, was schlussendlich zu einem der Hauptfaktoren für den Ausgang des Krieges wurde.
Prinzipiell ist jeder in der Praxis verwendete kryptographische Algorithmus “knackbar”, die Frage ist nur, ob es realistisch möglich ist, dies mit der aktuell zur Verfügung stehenden Technik tatsächlich zu bewerkstelligen. Heute gilt jedes Verschlüsselungsverfahren als gebrochen, wenn es tatsächlich durchführbar ist, den verschlüsselten Nachrichteninhalt in den Klartext zurück zu wandeln, ohne den Schlüssel zu kennen. Ein Hash Verfahren wie MD5 oder SHA-1 wird als gebrochen bezeichnet, wenn es praktisch möglich ist, Kollisionen zu erzeugen.
Genau dies ist den Forschern nun für SHA-1 gelungen. Durch Nutzung einer mathematischen Abkürzung und immer noch enormer Rechenpower, die von Google bereitgestellt wurde.
Der Angriff erforderte über 9.223.372.036.854.775.808 SHA-1 Berechnungen, die äquivalente Rechenleistung wie 6.500 Jahre Single-CPU-Berechnungen oder 110 Jahre Single-GPU-Berechnungen. Man könnte vermuten, nach Einsatz derartiger Rechenpower sei nun ein Ergebnis gefunden, das künftige Kollisionen leichter macht. Doch genau das ist nicht der Fall, durch diese Berechnungen wurde genau eine Kollision erzeugt. Jede neue Kollision von SHA-1 Hashes würde wieder den selben Aufwand nach sich ziehen.
Um eine derartige Rechenleistung zur Verfügung zu haben, benötigt man Zugriff auf Rechenzentren, wie Google, Amazon oder die NSA sie mutmaßlich betreiben. Das für diesen Angriff notwendige Brutforcing lässt sich leicht parallelisieren. So kann die theoretische Rechenzeit von 6.500 Single-CPU Jahren auf nur 110 Jahre mit Single-GPUs verteilt werden, oder einem Jahr mit 110 GPUs oder ein Monat mit 1.320 GPUs. Somit ist die Frage, ob ein Verfahren sicher ist, oder als gebrochen gelten muss, abhängig davon, ob und für wen es machbar ist, eine derartige Rechenleistung bereit zu stellen, um im Ergebnis genau einen Schlüssel zu knacken. Es mag auf den ersten Blick nach viel klingen, wenn man sagt, man müsse tausend Jahre rechnen, um einen Schlüssel zu knacken. Dennoch gibt es Organisationen, für die es nicht außer Reichweite ist, 1.300 Prozessoren einen Monat auf das Knacken eines Schlüssels zu investieren. Teuer, aber eben nicht unmachbar. 

Kollisionsresistenz und Pre-image Angriffe

Für den Anwendungszweck des Application Whitelisting wie SecuLution es bietet, trifft dies alles aber nicht zu. Wir nutzen die Eigenschaft eines Hashes, eine bestimmte Version einer Software eindeutig in einer recht kurzen Kette von Buchstaben und Zahlen eindeutig und fälschungssicher zu identifizieren. Es wird also lediglich die Masse aller verfügbaren Hashes genutzt, um eine eindeutige Identifikation zu ermöglichen. Es soll nichts verschlüsselt und entschlüsselt werden.
Um einen Angriff auf diese Technik durchzuführen, hilft dem Angreifer eine Kollision nicht. Wir erinnern uns, dass eine Kollision lediglich zwei identische Hashes erzeugt die wir darüber hinaus nicht beeinflussen können. Der Angreifer müsste aber zwingend eine Datei erzeugen, die im Ergebnis einen Hash hat, der in der Application Whitelist bereits als vertrauenswürdig eingestuft ist. Es ist also der Hash vorgegeben (Pre-Image) und der Angreifer muss eine Datei erstellen, die genau diesen Hash erzeugt. Man nennt das einen Pre-Image Angriff.
 SHA-1 und auch MD5 sind im Bezug auf ihre Kollisionsresistenz gebrochen, im Bezug auf Pre-Image Angriffe aber stehen diese Algorithmen auch heute wie ein Fels in der Brandung. Es ist nach wie vor nicht möglich Eingabedaten (z.B. Schadsoftware) zu erzeugen, die einen vorgegebenen Hash (z.B. MD5 von calc.exe) haben wird.
Pre-Image und Kollision sind zwei unterschiedliche Angriffe auf Hashes: Eine Kollision ermöglicht es, aus zwei Anwendungen unterschiedlicher Funktion einen identischen Hashwert zu generieren, aber auf den im Ergebnis erzeugten Hash kann dabei kein Einfluss genommen werden. 

Die Magie der großen Zahlen

Um diese Unmöglichkeit der Durchführung eines Pre-Image Angriffs auf MD5 besser veranschaulichen zu können, kann man folgendes tun:
Die Aufgabenstellung des Angreifers ist, eine Schadsoftware zu erzeugen, die im selben MD5 Hash resultieren soll, wie das Programm calc.exe. Es ist also der Hash von calc.exe vorgegeben. Im Falle von MD5 mit einer Länge von 128 Bit, wäre man mit Brute-Force nach 2 hoch 128 Versuchen garantiert erfolgreich.
Wählen Sie in Gedanken eine Zahl zwischen 1 und 10, und Ihr Gegenüber ist nach garantiert maximal 10 Versuchen erfolgreich, Ihre Zahl erraten zu haben. Im Durchschnitt würde er aber nur 5 Versuche benötigen.
 Analog dazu ist die durchschnittliche Anzahl von Bruteforce Versuchen auf einen MD5 Pre-Image Angriff 2 hoch 64 Versuche. 2 hoch 64 ist eine unvorstellbar große Zahl. Was uns zu dem Problem führt, dass Zahlen wie 2 hoch 64 für viele Menschen zu abstrakt sind, es fehlt uns eine Bezugsgröße, um sie besser in uns geläufige Zeiträume einordnen zu können. Als Vergleich wird daher oft die Rechenzeit angegeben, die eine aktuelle GPU zum „Durchprobieren“ dieser Zahlenmenge benötigen würde.
Die beste GPU in 2017 kann rund 2.000.000 = 2 × 10 hoch 6 MD5 Varianten einer Schadsoftware pro Sekunde erzeugen und deren Hash berechnen.* 
Um 2 hoch 64  (=1,84 × 10 hoch 19 ) Berechnungen durchzuführen benötigt die aktuell modernste GPU damit 9.223372 × 10 hoch 12 Sekunden oder, als Referenzwert für uns besser geeignet, 292.471 Jahre Rechenzeit. 
Das bedeutet, 292.471 GPUs rechnen ein Jahr oder 3.509.654 GPUs rechnen einen Monat. Diese Größenordnung wird gemeinhin als nicht durchführbar betrachtet, deshalb gilt dieses Verfahren im Bezug auf Pre-Image Angriffe weiterhin als ungebrochen.


* Diese GPU kann 25.000.000 Rechenoperationen/Sekunde durchführen, allerdings verringert sich diese Zahl für den beschrieben Fall immens, da immer auch die Schadsoftware mit in die Hash Berechnung einbezogen werden muss.