[Technik] Mehrere Schwachstellen in VeraCrypt durch Audit entdeckt

Nachdem im Mai 2014 die Entwicklung des bekannten und beliebten Verschlüsselungsprogramms TrueCrypt eingestellt wurde, hat sich als Nachfolger recht schnell VeraCrypt herauskristallisiert. Bei handelt es sich ursprünglich um einen Fork von TrueCrypt aus dem Jahre 2012, der seit dem eigene Wege geht. Dieses Programm wurde nun einem Audit unterzogen. Dieser wurde von aus Frankreich erstellt.

Im Rahmen des Audits wurden 8 kritische, 3 mittlere und 15 geringe Schwachstellen gefunden. Mit der am 17.10.16 veröffentlichten Version von VeraCrypt (1.19) wurde ein Hauptteil dieser Schwachstellen bereits behoben. Einige sind aufgrund der hohen Komplextität noch offen. Die Dokumentation von Veracrypt bietet hierzu aber Workarounds an.

Der komplette Audit kann unter unten genannten Quelle als PDF-Datei heruntergeladen werden.

Quelle:
 
Ich hab den Report jetzt mal kurz ueberflogen, da war eigentlich nichts drinnen, was einem (securitytechnischen) Weltuntergang gleichgekommen waere - ausser vielleicht 4.1.11, wobei ich mir da nicht ganz sicher bin, wie das zu bewerten ist. Selbst die Schwachstellen, die als "High" klassifiziert wurden machen mir in der Praxis eher wenig Sorgen. Ich muss gestehen, ich waere beunruhigter gewesen, wenn sie nichts gefunden haetten. :D
 
Mal für DAUs wie mich. Wie update ich eigentlich VeraCrypt? Eine entsprechende Funktion in-built gibt es ja scheinbar nicht. Deinstalliere ich einfach eine Version und packe die neue wieder drauf? Oder gibt das dann Probleme mit der verschlüsselten Boot-Partition?
 
Gut, bei einem Audit steigt die Vertrauenswürdigkeit enorm.
Da wird dann auch ein Umstieg von Truecrypt auf Veracrypt interessant.
 
  • Thread Starter Thread Starter
  • #6
@Kenobi van Gin:

Im Grunde besorgst du dir die aktuelle Installationsdatei auf der offiziellen Seite und führst diese einfach aus. Allerdings solltest du vorher die und Ankündigungen ansehen.

@TBow:

TrueCrypt hat inzwischen schon so einige bekannte Schwachstellen. Audit hin oder her. TrueCrypt würde ich nicht mehr nutzen.
 
TrueCrypt hat inzwischen schon so einige bekannte Schwachstellen. Audit hin oder her. TrueCrypt würde ich nicht mehr nutzen.
Ich kenne keine, die es ermöglichen würde, Daten zu entschlüsseln. Gibts da ein "echtes" Problem?
Wer zB auf Hidden Container/Volumes angewiesen ist, der müsste in der Tat von TC Abstand nehmen.
 
  • Thread Starter Thread Starter
  • #9
@TBow:

Ich bin einfach der Ansicht, dass man Software die nicht mehr weiterentwickelt wird und bei der nach dem Audit noch Schwachstellen gefunden wurden, nicht nutzen sollte.

@m6ld8ywqya:

Eine extra Bereich in dem das zusammengefasst ist, gibt es wohl nicht. Die Workarounds sind vermutlich einfach als allgemeiner Hinweis in die Dokumentation eingepflegt worden. Gestern wurden einige Seiten der Dokumentation geändert ( ). Eventuell betrifft dies genau diese Workarounds.
 

TrueCrypt hat mittlerweile zwei kritischere Schwachstellen:
  • Eine privilege escalation, mit der sich ein nicht-administrativer User Admin-Rechte erschleichen könnte. Uninteressant wenn man der einzige Benutzer ist
  • Hidden Volumes sind nicht ganz so unsichtbar, wie sie sein sollten (man kann mit einer gewissen Wahrscheinlichkeit erkennen, ob eine Datei/Partition einen versteckten Container enthält). Das Problem hatte VeraCrypt anfangs auch, ist aber dort mittlerweile gepatcht.
Deine Daten können auch weiterhin nicht entschlüsselt werden. Kommt auf den genauen Anwendungszweck an, ob TrueCrypt noch geeignet ist. Ein Rundum-Sorglos-Paket ist es aber nicht mehr.
 
Hidden Volumes sind nicht ganz so unsichtbar, wie sie sein sollten (man kann mit einer gewissen Wahrscheinlichkeit erkennen, ob eine Datei/Partition einen versteckten Container enthält). Das Problem hatte VeraCrypt anfangs auch, ist aber dort mittlerweile gepatcht.
Wenn pagefile.sys 150GB hat kann man immer noch mit einer gewissen Wahrscheinlichkeit erkennen, dass da was nicht passt .. :D
 
@JohnDoe
Für zB Container.enc kann eine Person das Passwort des Fake Containers herausgeben und verneinen, dass es noch einen versteckten Bereich gibt. Ein Angreifer kann das nicht widerlegen.
Truecrypt hat noch und Veracrypt hatte das Problem, dass Hidden Containers/Partitionen dennoch detektierbar sind/waren. Das Problem liegt/lag am Fake Header. Die Sicherheit der Daten war jedoch nie in Gefahr.

EDIT: Nachzulesen bei...
 
Die angebliche Sicherheitsluecke wegen der Hidden Systems kann ich auch absolut nicht nachvollziehen.
Spaetestens wenn ein Profi sich den Computer vornimmt wird er feststellen, dass etwas nicht stimmt (nach z. Bsp einer Beschlagnahmung wird der Computer von einem Forensiker untersucht, der hat genug Ahnung um sowas zu erkennen) Da kann die Partition noch so gut versteckt sein. Wenn eine Festplatte 1GB hat aber nur eine 300mb Parition angezeigt wird weiss ich dass da was faul zein muss.

Ein Laie wie zum bsp. ein Flughafen Security Beamter/Zoll Beamter wird das zwar wahrscheinlich nicht erkennen. Der wird aber auch genausowenig die versteckte Parition von Truecrypt erkennen (trotz Sicherheitslucken)
Diese ganzen angeblichen Sicherheitsluecken sind in meinen Augen keine, da sie in der Praxis nur auftreten wenn man diese Scenarios kuenstlich herstellt.
Mein Rechner ist noch nachwievor mit Truecrypt verschluesselt und es wird keiner es schaffen ihn in den naechsten Jahren zu entschluesseln.
Der einzige Grund auf Veracrypt zu wechseln, ist dass dort Windows 8 und 10 direkt unterstuetzt werden und somit die Installation wesentlich einfacher ist.
 
Die angebliche Sicherheitsluecke wegen der Hidden Systems kann ich auch absolut nicht nachvollziehen.
Spaetestens wenn ein Profi sich den Computer vornimmt wird er feststellen, dass etwas nicht stimmt (nach z. Bsp einer Beschlagnahmung wird der Computer von einem Forensiker untersucht, der hat genug Ahnung um sowas zu erkennen) Da kann die Partition noch so gut versteckt sein. Wenn eine Festplatte 1GB hat aber nur eine 300mb Parition angezeigt wird weiss ich dass da was faul zein muss.
Trotzdem, eine eindeutige Identifizierung durch einen falschen Header ist immer noch eine Schwachstelle, ganz gleich ob es auf anderem Wege ebenfalls erkennbar ist - wie oben angesprochen. Es muss ja nicht gleich eine ganze VM sein, die ich verstecke. Es reichen auch 2MB Bombenbastelanleitungen. Und die zu finden erfordert schon wieder wesentlich mehr forensischen Analyseaufwand.
Diese ganzen angeblichen Sicherheitsluecken sind in meinen Augen keine, da sie in der Praxis nur auftreten wenn man diese Scenarios kuenstlich herstellt.
Die Aussage habe ich schon bei so vielen Schwachstellen gelesen. Und am Ende hat dann doch irgendwer einen praktischen Anwendungszweck gefunden, siehe bei Comodo gerade mit OCR.
 
Spaetestens wenn ein Profi sich den Computer vornimmt wird er feststellen, dass etwas nicht stimmt (nach z. Bsp einer Beschlagnahmung wird der Computer von einem Forensiker untersucht, der hat genug Ahnung um sowas zu erkennen) Da kann die Partition noch so gut versteckt sein. Wenn eine Festplatte 1GB hat aber nur eine 300mb Parition angezeigt wird weiss ich dass da was faul zein muss.

autsch.. hast du dir mal die mühe gemacht nachzuschauen, wie das hidden volume funktioniert? das wird in den freien speicherplatz einer bestehenden partition geschrieben! und da jede truecrypt-partition beim erstellen vollständig mit zufallszahlen überschrieben wird, kann auch ein "forensiker" nicht unterscheiden, ob es wirklich nur zufallszahlen sind (d.h. freier speicher innerhalb der partition) oder ein weiterer ungekennzeichneter TC-container.. jede TC-partition, die überhaupt freien speicherplatz enthält, könnte somit auch einen versteckten container von der größe des freien speicherplatzes enthalten (und dieser kann ungewollt zerstört werden, wenn man neue daten auf die partition schreibt ohne den versteckten container zu mounten).. man kann es jedoch nicht forensisch "beweisen", außer über die sicherheitslücke mit dem versteckten header..

die "lösung" mit dem fake header kommt mir aber ebenso suboptimal vor.. das gibt einem zwar rechtlich gesehen "plausible deniability", aber wenn jemand schon die mittel hat, einen zur herausgabe von passwörtern zu zwingen, wird dieser sich auch nicht unbedingt an "im zweifel für den angeklagten" halten, zumal ja noch alte versionen im umlauf sind, wo der vermeintliche "fake header" garnicht fake ist.. aus meiner sicht bringt es die opfer eher noch zusätzlich in gefahr, weil dann der mafiaboss oder CIA-agent ggf. noch gründlicher aus einem herausprügeln will, ob hinter dem fake header nicht doch noch was versteckt ist.. schlauer wäre eine lösung komplett ohne header, wo der offset zum versteckten container entweder aus der geometrie der äußeren partition und/oder aus dem passwort berechnet wird.. selbst wenn die bösen jungs diesen offset selbst berechnen können, sind die rohdaten an dieser stelle ohne das passwort nur zufallszahlen - da dies für jede denkabre TC-partition gilt (mit oder ohne versteckten container), wäre plausible deniability also immernoch gegeben, aber man bräuchte keinen exploitbaren header (samt fake header) mehr..
 
Ohne jetzt den Thread entgleisen lassen zu wollen, aber plausible deniability ist in 99,5% der Fälle ein Mythos. Die meisten Leute hier werden den entsprechenden xkcd-Comic dazu kennen.
 
Zurück
Oben