12
SHA-1 geknackt, welche Konsequenzen für IPSec VPN?
https://www.heise.de/newsticker/meldung/Todesstoss-Forscher-zerschmetter ...
Meines Wissens sind einige VPN-Appliances auf SHA-1 bzw. MD5 festgelegt. So z.B. die allseits beliebten Fritzboxen.
Da der PSK in der Phase 1 ja als Hash im Klartext übertragen wird, ist die Frage, wie die sicherheitsrelevanten Auswirkungen auf das VPN zu bewerten sind.
Ist ein möglichst komplexer PSK (64 und mehr Stellen) wirklich relevant besser als 16 oder 32 Stellen?
Wie wahrscheinlich ist ein Angriffsszenario in den verschiedenen Umgebungen? (Der Hash sollte in öffentlichen WLANS mit Wirehark problemlos mitzuschneiden sein)
6500 CPU-Jahre und 100 GPU-Jahre obendrauf klingt ja erstmal für die Praxis noch vertretbar und nach Forscher-/ Geheimdienstniveau.
Wie seht ihr das?
LG
Buc
Meines Wissens sind einige VPN-Appliances auf SHA-1 bzw. MD5 festgelegt. So z.B. die allseits beliebten Fritzboxen.
Da der PSK in der Phase 1 ja als Hash im Klartext übertragen wird, ist die Frage, wie die sicherheitsrelevanten Auswirkungen auf das VPN zu bewerten sind.
Ist ein möglichst komplexer PSK (64 und mehr Stellen) wirklich relevant besser als 16 oder 32 Stellen?
Wie wahrscheinlich ist ein Angriffsszenario in den verschiedenen Umgebungen? (Der Hash sollte in öffentlichen WLANS mit Wirehark problemlos mitzuschneiden sein)
6500 CPU-Jahre und 100 GPU-Jahre obendrauf klingt ja erstmal für die Praxis noch vertretbar und nach Forscher-/ Geheimdienstniveau.
Wie seht ihr das?
LG
Buc
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 330347
Url: https://administrator.de/forum/sha-1-geknackt-welche-konsequenzen-fuer-ipsec-vpn-330347.html
Ausgedruckt am: 22.12.2024 um 10:12 Uhr
12 Kommentare
Neuester Kommentar
Nun MD5 gilt ja schon länger als Geknackt und SHA1 gehört auch langsam mehr dazu da es ja ausreichend Power für die Berechnung schon gibt.
Für Dateihash aber noch Brauchbar für einen Schnellen Check ob die Datei "Corrupt" ist...
Nun Sicher kann man Traffic und Co mitschneiden aber bei VPN gibt es ja noch neben den Passwort den Benutzernamen den man ja auch erst mal Kennen muss.
Da aber auch PWDs regelmäßig geändert werden hat der Angreifer es ja auch noch was schwerer sowie einen Zeitlichen Rahmen.
Aber da werden die Leute eher über Sozial Engineering oder Bugs, Ransomeware ect versuchen wo reinzukommen da dort die Chance höher und schneller ist.
In Panik würde ich jetzt nicht verfallen deswegen ;)
Für Dateihash aber noch Brauchbar für einen Schnellen Check ob die Datei "Corrupt" ist...
Nun Sicher kann man Traffic und Co mitschneiden aber bei VPN gibt es ja noch neben den Passwort den Benutzernamen den man ja auch erst mal Kennen muss.
Da aber auch PWDs regelmäßig geändert werden hat der Angreifer es ja auch noch was schwerer sowie einen Zeitlichen Rahmen.
Aber da werden die Leute eher über Sozial Engineering oder Bugs, Ransomeware ect versuchen wo reinzukommen da dort die Chance höher und schneller ist.
In Panik würde ich jetzt nicht verfallen deswegen ;)
Moin,
Für Security-Anwendungen sind MD5 und SHA1 schon länger ein no-go!
Bei Safety-Anwendungen wie z.B. gegen kippende Bits auf Speichermedien oder bei Übertragungen kann man sie noch einsetzen.
Also: alles was mit vpn oder verschlüsselter übertragung, das sha1 (oder md5) einsetzt, sollte man ersetzen.
Nachtrag:
Um es zu präzisieren:. Überall da, wo es um integrität und ncht authentizität geht, braucht man noch nicht in den panikmode verfallen.
Dort wo der Angreifer genügend zeit hat, kann er die verbindung z.B. nachträglich entschlüsseln.
Oder er kann z.B. zertifikate fälschen.
Nachtrag 2 : 6500 CPU-Jahre und 100 GPU-Jahre auf wenige reale Stunden oder Tage zu reduzieren können sich im Moment nur Geheimdienste oder Großkonzerne leisten.
lks
Für Security-Anwendungen sind MD5 und SHA1 schon länger ein no-go!
Bei Safety-Anwendungen wie z.B. gegen kippende Bits auf Speichermedien oder bei Übertragungen kann man sie noch einsetzen.
Also: alles was mit vpn oder verschlüsselter übertragung, das sha1 (oder md5) einsetzt, sollte man ersetzen.
Nachtrag:
Um es zu präzisieren:. Überall da, wo es um integrität und ncht authentizität geht, braucht man noch nicht in den panikmode verfallen.
Dort wo der Angreifer genügend zeit hat, kann er die verbindung z.B. nachträglich entschlüsseln.
Oder er kann z.B. zertifikate fälschen.
Nachtrag 2 : 6500 CPU-Jahre und 100 GPU-Jahre auf wenige reale Stunden oder Tage zu reduzieren können sich im Moment nur Geheimdienste oder Großkonzerne leisten.
lks
Hi,
im verlinkten Artikel geht es um Signierung, nicht um Verschlüsselung. Das sind zwei komplett verschiedene Paar Schuhe.
Es geht also darum, dass man Daten, welche mit diesem Verfahren signiert wurden, nicht mehr 100% vertrauen kann. Es könnte also jemand Daten, welche mit einem Zertifikat von Person A signiert wurden, abfangen, nachträglich verändern und dann zusammen mit der zuvor von Person A erstellten Signatur an den ursprünglich vorgesehenen Empfänger weitersenden. Empfänger B würde beim Gegenprüfen der Daten mit der Signatur zu dem Schluss kommen, dass diese Daten noch in jenem Zustand sind, wie sie Person A mit seinem Zertifikat signiert hat.
Mal abgesehen von der Rechenpower kann man dann aber nur begrenzt Daten verändern ohne dass davon die Signatur betroffen wäre. Bei welcher Art Daten das dann in der Echtzeitübertragung zu einem Problem werden könnte, dass können wohl nur die Mathematiker beantworten.
So habe ich es verstanden.
Demnach muss ich also @Lochkartenstanzer ganz klar widersprechen: Gerade bei solchen Sachen wie
Um mal auf die Ursprungsfrage zurückzukommen:
Was ich mir vorstellen könnte, wäre, dass VPN-Tunnel, welche SHA-1verwenden, in der Aufbauphase für Man-In-The-Middle-Attacken anfällig sein könnten. Wo genau, weiß ich jetzt nicht.
E.
im verlinkten Artikel geht es um Signierung, nicht um Verschlüsselung. Das sind zwei komplett verschiedene Paar Schuhe.
Es geht also darum, dass man Daten, welche mit diesem Verfahren signiert wurden, nicht mehr 100% vertrauen kann. Es könnte also jemand Daten, welche mit einem Zertifikat von Person A signiert wurden, abfangen, nachträglich verändern und dann zusammen mit der zuvor von Person A erstellten Signatur an den ursprünglich vorgesehenen Empfänger weitersenden. Empfänger B würde beim Gegenprüfen der Daten mit der Signatur zu dem Schluss kommen, dass diese Daten noch in jenem Zustand sind, wie sie Person A mit seinem Zertifikat signiert hat.
Mal abgesehen von der Rechenpower kann man dann aber nur begrenzt Daten verändern ohne dass davon die Signatur betroffen wäre. Bei welcher Art Daten das dann in der Echtzeitübertragung zu einem Problem werden könnte, dass können wohl nur die Mathematiker beantworten.
So habe ich es verstanden.
Demnach muss ich also @Lochkartenstanzer ganz klar widersprechen: Gerade bei solchen Sachen wie
kippende Bits auf Speichermedien oder bei Übertragungen
ist dieses Verfahren nicht mehr vertrauenswürdig, weil ich mich nicht darauf verlassen kann, dass die hier berechneten Signaturen in jedem Fall die Integrität der Daten belegen, weil verschiedene Daten dieselbe Signatur erzeugen könnten.Um mal auf die Ursprungsfrage zurückzukommen:
Was ich mir vorstellen könnte, wäre, dass VPN-Tunnel, welche SHA-1verwenden, in der Aufbauphase für Man-In-The-Middle-Attacken anfällig sein könnten. Wo genau, weiß ich jetzt nicht.
E.
Zitat von @emeriks:
Demnach muss ich also @Lochkartenstanzer ganz klar widersprechen: Gerade bei solchen Sachen wie
Demnach muss ich also @Lochkartenstanzer ganz klar widersprechen: Gerade bei solchen Sachen wie
kippende Bits auf Speichermedien oder bei Übertragungen
ist dieses Verfahren nicht mehr vertrauenswürdig, weil ich mich nicht darauf verlassen kann, dass die hier berechneten Signaturen in jedem Fall die Integrität der Daten belegen, weil verschiedene Daten dieselbe Signatur erzeugen könnten.Da muß ich Dir wiederum widersprechen:
Kippende Bits auf der Festplatte/auf dem Übertragungsweg greifen Deine Daten nicht gezielt an. Sie versuchen keine Kollision zu erzeugen. Mit Deiner Argumentation wäre überhaupt kein Hash-verfahren dazu geeignet, weil es bei jedem Hash, der kürzer als die Originaldaten ist, Kollisionen gibt und von daher könntest Du bei keinem der Verfahren Dich darauf verlassen, daß die Bits in den Daten so kippen, daß Deine Hashes unverändert passen.
lks
weil es bei jedem Hash, der kürzer als die Originaldaten ist, Kollisionen gibt
Ich bin kein Mathematiker, kann das also weder bestätigen noch widersprechen. Nach meinem Kenntnisstand ist jedoch die Länge der Daten für Berechnung eines eindeutigen Hash irrelevant. Es würde mich aber auch wundern: Die Erfinder dieser Verfahren hätten doch garantiert erstmal mit kleinen Daten getestet bevor sie an die großen, rechenintensiven Daten rangegangen sind?Kippende Bits auf der Festplatte/auf dem Übertragungsweg greifen Deine Daten nicht gezielt an.
Ja, schon klar, aber darauf kommt es doch in diesem Fall vordergründig nicht an? Hier geht doch es darum, Übertragungsfehler festzustellen, oder? Und wenn es theoretisch möglich ist, dass verschiedene Daten denselben Hash erzeugen, dann sinkt mein Vertrauen in die Aussagekraft des Hash. Wobei dass dann auch wieder eine Frage der Wahrscheinlichkeit ist und des Risikos (bzgl. des Vertrauens in die Glaubwürdigket der Daten), welches ich eizugehen bereit bin.Zitat von @emeriks:
weil es bei jedem Hash, der kürzer als die Originaldaten ist, Kollisionen gibt
Ich bin kein Mathematiker, kann das also weder bestätigen noch widersprechen. Nach meinem Kenntnisstand ist jedoch die Länge der Daten für Berechnung eines eindeutigen Hash irrelevant. Es würde mich aber auch wundern: Die Erfinder dieser Verfahren hätten doch garantiert erstmal mit kleinen Daten getestet bevor sie an die großen, rechenintensiven Daten rangegangen sind?Ganz einfach: Ein Hash ist eine nichtumkehrbare Abbildung einer Menge A (Alle Dateien, d.h. bitstringlängen, die möglich sind) auf eine deutlich kleinere Menge B von Daten, die eine bestimmte bitsreamlänge haben (z.B. 512, 1025 oder 2048 bit). Da man jedes Datum aus der Menge A auf ein Datum der Menge B abbilden kann, ist es offensichtlich, daß es in der Menge B Daten gibt, die als hash für mehrere Daten in der Menge A gültig sind. d.h. du hast immer Hash-Kollisionen!
i.d.R. haben Hasfunktionen die Eigenschaft, daß die Daten aus der Menge A gleichmäßig auf die Daten den Menge B abgebildet werden. Wenn das nicht so wäre, ergeben sich einfacher Angriffspunkte um Kollisionen gezielt zu finden => schlechte Hashfunktion. Damit gibt es zu jedem hashwert sehr viele Elemente aus der Menge A, die dazu passen. Also gibt es immer kippende Bitkombinationen, die den gleichen Hash erzeugen können, so daß man eine Änderung der Daten nicht bemerkt.
Der Unterschied zischen einem Dokument, das ein Angreifer ändern will und einer defekten Festplatte/Leitung ist, daß die Festplatte/Leitung Dir kein anderes Dokument unterjubeln will.
Kippende Bits auf der Festplatte/auf dem Übertragungsweg greifen Deine Daten nicht gezielt an.
Ja, schon klar, aber darauf kommt es doch in diesem Fall vordergründig nicht an? Hier geht doch es darum, Übertragungsfehler festzustellen, oder? Und wenn es theoretisch möglich ist, dass verschiedene Daten denselben Hash erzeugen, dann sinkt mein Vertrauen in die Aussagekraft des Hash. Wobei dass dann auch wieder eine Frage der Wahrscheinlichkeit ist und des Risikos (bzgl. des Vertrauens in die Glaubwürdigket der Daten), welches ich eizugehen bereit bin.(Die meisten) Übertragunsfehler kann man mit hashes abfangen, gezielte Angriffe nicht, wenn Hash-Kollisionen "einfach" berechnenbar sind. Das ist der springende Punkt.
lks
Heise zeigt hier, was man mit hashkollisionen machen kann:
https://www.heise.de/security/artikel/Warum-SHAttered-wichtig-ist-363434 ...
lks
https://www.heise.de/security/artikel/Warum-SHAttered-wichtig-ist-363434 ...
lks
Heise schreibt in einem älteren Artikel aus dem Jahr 2005: https://www.heise.de/security/artikel/Keine-Panik-271334.html
"Auch durch Preimage-Angriffe ließen sich im Übrigen Verfahren nicht knacken, die erst digital signieren und dann chiffrieren. Wer nicht an den Klartext herankommt, kann nicht einmal eine MD4-Summe fälschen. Daher bleiben SSH und IPSec sicher. Unberührt bleiben auch so genannte HMAC-Summen. Dies sind Hashes, die sich nur bei Kenntnis eines geheimen Schlüssels berechnen lassen. Sie sind so konstruiert, dass ein Angreifer ohne das Geheimnis keine Kollisionen berechnen kann.
Die SHA-1-Attacken haben auch keine Bedeutung für die Sicherheit von Passwörtern, die in vielen Systemen nur als Hash-Werte abgespeichert werden. Die Berechnung eines Passworts zu einem vorgegebenem Hash-Wert bleibt vorerst aussichtslos, dort bleiben Wörterbuchattacken die größte Bedrohung."
Daraus lese ich, dass das Verfahren für VPN zur Zeit immer noch als sicher anzusehen ist, wenn der Angreifer das Original nicht kennt (Was beim PSK für IPSec ja der Fall sein sollte, denn sonst würde er ja das Original verwenden)
So ist also ein Passwort ein sichererer Spezialfall eines Dokuments, da um einen identischen Hashwert zu erzeugen, dem Angreifer das Original bekannt sein müsste, das aber bei der Übertragung nur Sender und Empfänger kennen.
Wer das mal genauer wissen will, warum das IPSec mit PSK auch im "aggressive mode" von der aktuellen Panik nicht betroffen ist, dem sei dieser Artikel ans Herz gelegt:
http://networkengineering.stackexchange.com/questions/13468/in-ipsec-vp ...
Ohne, dass ich als Quereinsteiger die Erklärung wirklich verstanden hätte, scheint mir die Komplexität der Authentifizierung auch mittels PSK hoch genug um mich sicher zu fühlen.
Was sagen die studierten Informatiker / Mathematiker dazu?
Buc
"Auch durch Preimage-Angriffe ließen sich im Übrigen Verfahren nicht knacken, die erst digital signieren und dann chiffrieren. Wer nicht an den Klartext herankommt, kann nicht einmal eine MD4-Summe fälschen. Daher bleiben SSH und IPSec sicher. Unberührt bleiben auch so genannte HMAC-Summen. Dies sind Hashes, die sich nur bei Kenntnis eines geheimen Schlüssels berechnen lassen. Sie sind so konstruiert, dass ein Angreifer ohne das Geheimnis keine Kollisionen berechnen kann.
Die SHA-1-Attacken haben auch keine Bedeutung für die Sicherheit von Passwörtern, die in vielen Systemen nur als Hash-Werte abgespeichert werden. Die Berechnung eines Passworts zu einem vorgegebenem Hash-Wert bleibt vorerst aussichtslos, dort bleiben Wörterbuchattacken die größte Bedrohung."
Daraus lese ich, dass das Verfahren für VPN zur Zeit immer noch als sicher anzusehen ist, wenn der Angreifer das Original nicht kennt (Was beim PSK für IPSec ja der Fall sein sollte, denn sonst würde er ja das Original verwenden)
So ist also ein Passwort ein sichererer Spezialfall eines Dokuments, da um einen identischen Hashwert zu erzeugen, dem Angreifer das Original bekannt sein müsste, das aber bei der Übertragung nur Sender und Empfänger kennen.
Wer das mal genauer wissen will, warum das IPSec mit PSK auch im "aggressive mode" von der aktuellen Panik nicht betroffen ist, dem sei dieser Artikel ans Herz gelegt:
http://networkengineering.stackexchange.com/questions/13468/in-ipsec-vp ...
Ohne, dass ich als Quereinsteiger die Erklärung wirklich verstanden hätte, scheint mir die Komplexität der Authentifizierung auch mittels PSK hoch genug um mich sicher zu fühlen.
Was sagen die studierten Informatiker / Mathematiker dazu?
Buc
Buccaner,
ich bin kein studierter Informatiker/Mathematiker, aber ich kann dir dennoch etwas dazu sagen.
Die neuen Erkenntnisse über SHA1 haben keinen Einfluss auf die Sicherheit von IKE. Die Möglichkeit eines Angriffs auf IKEv1 im Aggressive Mode mit PSK (und nur da) ist weiterhin gegeben. Das Problem besteht darin, dass alle Werte (außer dem PSK) über die der Hash gebildet wird, mitgelesen werden können. Der Hash selbst wird auch gesendet.
Indem man mit geratenen PSKs (plus den bekannten Werten) solange einen Hash bildet, bis dieser mit dem Original übereinstimmt, kann man den PSK bestimmen. Das kann man mit jeder Hashfunktion machen. Darum ist ein starker PSK sehr wichtig.
BB
ich bin kein studierter Informatiker/Mathematiker, aber ich kann dir dennoch etwas dazu sagen.
Die neuen Erkenntnisse über SHA1 haben keinen Einfluss auf die Sicherheit von IKE. Die Möglichkeit eines Angriffs auf IKEv1 im Aggressive Mode mit PSK (und nur da) ist weiterhin gegeben. Das Problem besteht darin, dass alle Werte (außer dem PSK) über die der Hash gebildet wird, mitgelesen werden können. Der Hash selbst wird auch gesendet.
Indem man mit geratenen PSKs (plus den bekannten Werten) solange einen Hash bildet, bis dieser mit dem Original übereinstimmt, kann man den PSK bestimmen. Das kann man mit jeder Hashfunktion machen. Darum ist ein starker PSK sehr wichtig.
BB
Moin,
Noch einmal um sich das deutlich zu machen
Über all da wo der Hash antelle der originaldaten benutzt wird, z.b. beim Signieren von Dokuemten oder Datein, ist eine einfache berechnung eine rKollision ein SuperGAU.
Überall da wo der hash nur dazu dient, zu überprüfen, ob die Originaldaten "konsistent sind", ist es weniger kritisch. d.h. wenn es dazu dient, zu schauen, ob die Schlüssel auf beiden Seiten gleich sein könnten, aber der Schlüssel selbst nicht über die Leitung geht, ist es noch unkritsch. Kritisch wird es dann erst, wen man mit "wenig" Aufwand zu einem gegeben has gezielt alle Kollisionen berechnen könnte. Denn dann könnte man recht schnell auch den Schlüssel berechnen.
lks
Noch einmal um sich das deutlich zu machen
Über all da wo der Hash antelle der originaldaten benutzt wird, z.b. beim Signieren von Dokuemten oder Datein, ist eine einfache berechnung eine rKollision ein SuperGAU.
Überall da wo der hash nur dazu dient, zu überprüfen, ob die Originaldaten "konsistent sind", ist es weniger kritisch. d.h. wenn es dazu dient, zu schauen, ob die Schlüssel auf beiden Seiten gleich sein könnten, aber der Schlüssel selbst nicht über die Leitung geht, ist es noch unkritsch. Kritisch wird es dann erst, wen man mit "wenig" Aufwand zu einem gegeben has gezielt alle Kollisionen berechnen könnte. Denn dann könnte man recht schnell auch den Schlüssel berechnen.
lks
O.K. Wir sind hier also bzgl. IPSec SHA-1 Hashes der Ansicht, dass die Übertragung des Hashes (noch) nicht zu einer Korrumpierbarkeit der Verbindung führt, da ich aus einem Hash noch kein passendes Original, sehr wohl aber 2 Originale mit demselben HAsh herstellen kann.
Allerdings ist das einzig geheime der PSK im aggressive Mode, was eine Angreifbarkeit nur von Rechenkapazität abhängig macht?
Wie eh und je.
?
Buc
Allerdings ist das einzig geheime der PSK im aggressive Mode, was eine Angreifbarkeit nur von Rechenkapazität abhängig macht?
Wie eh und je.
?
Buc
Zitat von @the-buccaneer:
O.K. Wir sind hier also bzgl. IPSec SHA-1 Hashes der Ansicht, dass die Übertragung des Hashes (noch) nicht zu einer Korrumpierbarkeit der Verbindung führt, da ich aus einem Hash noch kein passendes Original, sehr wohl aber 2 Originale mit demselben HAsh herstellen kann.
Allerdings ist das einzig geheime der PSK im aggressive Mode, was eine Angreifbarkeit nur von Rechenkapazität abhängig macht?
Wie eh und je.
O.K. Wir sind hier also bzgl. IPSec SHA-1 Hashes der Ansicht, dass die Übertragung des Hashes (noch) nicht zu einer Korrumpierbarkeit der Verbindung führt, da ich aus einem Hash noch kein passendes Original, sehr wohl aber 2 Originale mit demselben HAsh herstellen kann.
Allerdings ist das einzig geheime der PSK im aggressive Mode, was eine Angreifbarkeit nur von Rechenkapazität abhängig macht?
Wie eh und je.
Der Unterschied ist, daß man mit einem einfach "knackbaren" hash sehr schnell viele Kollisionen berechnen kann und damit den Suchraum für den PSK deutlich einschränken kann. bei einem guten hash ist hilft prinzipiell nur (fast) vollständige Suche.
Fazit:
Man sollte so langsam schauen, daß man sich von sha1 verabschiedet. Es ist noch nicht angebracht, in Panik-Mode auszubrechen, aber die Einschläge kommen immer nöher.
lks
