VeraCrypt-audit levert acht kritieke kwetsbaarheden op

Ostif, de organisatie die de VeraCrypt-audit organiseerde, meldt dat het bedrijf QuarksLab de controle van de broncode van de encryptiesoftware heeft afgerond. De audit leverde in totaal acht kritieke kwetsbaarheden op, naast drie gemiddelde en vijftien minder ernstige lekken.

Naar aanleiding van de audit heeft VeraCrypt inmiddels versie 1.19 uitgebracht, die een groot deel van de problemen uit de audit oplost. Ostif schrijft dat sommige kwetsbaarheden door hun complexiteit niet zijn aangepakt, maar dat VeraCrypt workarounds heeft omschreven in zijn documentatie. QuarksLab meldt dat de audit zich richtte op versie 1.18 van de VeraCrypt-software, die enkele verbeteringen met zich meebracht ten opzichte van zijn voorganger TrueCrypt. De ontwikkeling van deze software werd in 2014 plotseling stilgelegd.

De eerste stap van de controle was erop gericht te verifiëren dat de problemen waren opgelost, die bij de eerdere audit van versie 7.1a van TrueCrypt naar boven waren gekomen. Vervolgens nam QuarksLab de nieuwe functies die VeraCrypt introduceerde onder de loep. Bijvoorbeeld ondersteuning voor niet-westerse encryptiealgoritmes, uefi-ondersteuning en de mogelijkheid om muisbewegingen te gebruiken om willekeurigheid aan de encryptiesleutel toe te voegen.

Onder de kritieke kwetsbaarheden bevindt zich de beschikbaarheid van het GOST-algoritme. Door implementatiefouten heeft QuarksLab de aanbeveling gedaan om dit volledig uit versie 1.19 te verwijderen. De implementatie van aes is volgens de onderzoekers nog steeds kwetsbaar voor timing attacks, maar een oplossing is nog niet geïmplementeerd omdat dit deel herschreven moet worden. Een andere kwetsbaarheid betrof Xzip en XUnzip. Deze onderdelen moesten volledig herschreven worden en zijn daarom vervangen door libzip.

De onderzoekers van QuarksLab schrijven dat het bijhouden van VeraCrypt een moeilijke taak is, omdat dit kennis van de Windows-kernel, verschillende besturingssystemen, de system boot chain en cryptografie vereist. De veranderingen die Idrix, de organisatie achter VeraCrypt, heeft aangebracht zouden getuigen van de aanwezigheid van deze vaardigheden. Gebruikers kunnen de VeraCrypt-software inzetten om bijvoorbeeld hun harde schijf te versleutelen en beveiligde containers aan te maken.

Reacties (50)

[contrast]

Ook interessant: OSTIF heeft een AMA op Reddit gehouden met betrekking tot deze audit. https://www.reddit.com/r/...ted_here_are_the_results/

[RedPixel]

tl;dr:

• Read the docs
• Use on bare metal only, no hosted virtual machines.
• Re-encrypt if you used GOST
• Re-encrypt FDE to fix bootloader problems
• No need to re-encrypt normal volumes (unless GOST)

[Reactie gewijzigd door RedPixel op 23 juli 2024 14:09]

[dehardstyler]

Use on bare metal only, no hosted virtual machines.

Waarom mag ik het niet gebruiken in een VM, weet je dat toevallig?
Zoja, hoeveel kwaad kan het?

[Reactie gewijzigd door dehardstyler op 23 juli 2024 14:09]

[contrast]

Dezelfde vraag is gesteld in de AMA en dit was het antwoord.

If you control all of the private virtual environments, it should not be a serious issue. It was more in reference to leased virtual machines or cloud infrastructure that is outside of your full control.

Oftewel, het is alleen niet aangeraden als je bijvoorbeeld een VM gebruikt op een VPS server etc.

[Reactie gewijzigd door contrast op 23 juli 2024 14:09]

[dehardstyler]

Ahh oke, dus de VM op mijn werklaptop is gewoon veilig. Bedankt voor je antwoord!

[Room42]

Mits jij je werklaptop volledig beheerd en er dus geen systeembeheerder toegang heeft.

[Cerberus_tm]

En mits niet één van je andere virtuele machines van binnenuit besmet is met malware indien beide machines geheugen of andere zaken delen.

[OruBLMsFrl]

Of je hopelijk gewoon die systeembeheerder(s) kunt vertrouwen met de informatie op de werk pc. Dat maakt alles zoveel eenvoudiger. Immers kunnen er ook altijd nog collega's fysiek bij het systeem en zo bijvoorbeeld een full disk clone trekken en die offline aanvallen. Daarnaast het netwerk dat je niet zelf onder controle hebt maar waar je wel zaken als printers wilt gebruiken, drivers inladen en veelal zaken als group policy met beheerrechten worden uitgevoerd en regelmatig ook nog een corporate certificate authority die vertrouwd moet worden maar daarna ook van alles anders mag. Als je systeembeheer echt niet kunt vertrouwen moet je met eigen apparatuur die je niet onbeheerd achterlaat aan de slag en bij voorkeur netwerken via 4G of een eigen firewall, maar dat is allemaal geen makkelijke weg.

[RedPixel]

Dit is wat hij er over zegt in dat Reddit-topic:

If you control all of the private virtual environments, it should not be a serious issue. It was more in reference to leased virtual machines or cloud infrastructure that is outside of your full control.

Ik denk dat je de software niet kunt vertrouwen als je de gebruikte hardware niet kunt vertrouwen.

[MadEgg]

Gebruikte hardware of de beheerder van die hardware?

Als de hardware compromised is zou je daar nog omheen kunnen werken door de encryptiesleutel elders te genereren; bij één encryptiesleutel hoort dan toch ook één versie van de versleutelde content lijkt mij, waardoor als er geldige content geproduceerd wordt je er ook vanuit kunt gaan dat deze veilig is.

Als de beheerder van de hardware memory dumps maakt en daarmee de sleutel verkrijgt maakt wordt het lastig inderdaad. Maar dat is dan dus niet specifiek voor VeraCrypt, noch voor VM's, maar voor elke vorm van encryptie, en feitelijk voor elke vorm van beveiliging. Als je een dedicated server huurt van een derde partij moet je ook die derde partij vertrouwen, ook als het geen VM is.

[Reactie gewijzigd door MadEgg op 23 juli 2024 14:09]

[GrooV]

Volgens mij heb je geen Pre-boot authentication op VM's behalve Virtual PC en die wordt niet hosted aangeboden bij de grote aanbieders

[Demo]

Je mag het best gebruiken, hoeveel kwaad het kan hangt ervan af hoe gevoelig de verpakte data is en hoe erg jij de eigenaar van de hypervisor vertrouwt, omdat die technisch gezien de sleutel uit het geheugen van de machine zou kunnen vissen.

[Obscurax]

Ook interessant:

What are your thoughts on those who believe that TC1.7a is still safe to use?

"TC 7.1a should no longer be considered safe.

An easy good reason is that it is no longer updated, but more importantly...

The results we have show problems with the bootloader as well as problems with the zip/unzip library used, as well as the local EOP vulnerability found by Google Project Zero."

[judgewooden]

Dus TC7.1a containers zijn nog veilig.

[MadEgg]

Ik heb hier op een systeem nog een TC 7.1a-container staan, maar die gebruikt geen bootloader en wordt niet automatisch gemount - ik moet handmatig deze op de Linux command line mounten en dan ook het encryptie-wachtwoord opgegeven. Daarmee lijkt risico wat hier genoemd wordt minimaal.

In ieder geval wel goed om te lezen dat VeraCrypt er tot nu toe goed uitziet (er even vanuitgaande dat ik Ostif en Quarkslab vertrouw) - een van de redenen om bij TrueCrypt te blijven was dat de audit van TrueCrypt feiltelijk weinig verontrustends aan het licht bracht en ik er niet veel voor voelde om een nieuwe random organisatie die TrueCrypt forkte naar VeraCrypt meer te vertrouwen.

Ik ga binnenkort maar eens even onderzoeken wat het zou inhouden om te migreren naar VeraCrypt.

[Verwijderd]

Waarom zou iemand GOST willen gebruiken, een cipher die vergelijkbaar is met DES? Totaal onzinnig dat ze dit hebben toegevoegd. Meer code geeft ook meer kans op fouten!

[kvdveer]

Bijvoorbeeld ondersteuning voor niet-westerse encryptiealgoritmes

Niet-westerse talen zijn een flinke uitdaging voor programmeurs (westers en niet-westers), maar niet-westerse algoritmes is een beetje een rare aanduiding. Hier worden encryptie algo's van niet-westerse (voornamelijk Russisch) makelij bedoeld - er is niets oosters aan die algoritmes, de wiskunde er achter is taal- en cultuuronafhankelijk.

edit:
Genuanceerd

[Reactie gewijzigd door kvdveer op 23 juli 2024 14:09]

[multiplexer]

De bedoelde betekenis van "westerse algoritmes" is "encryptie-algoritmes die ontwikkeld zijn als onderdeel van westerse instituten, waarbij het risico aannemelijk is dat veiligheidsdiensten (zoals de NSA) er in geslaagd zijn om de praktische toepassing van algoritmes te verzwakken door invloed op de besluitvorming rond implementaties uit te oefenen." - deze aanpak is in de Snowden leaks bekend geworden, en heeft als naam "Operation Bullrun" (NSA) of "Edgehill" (GCHQ). Het bekendste voorbeeld is dat RSA een verzwakte random-number generate gebruikte, in ruil voor geld van de NSA.

Een aantal mensen in de crypto-community is er van overtuigd dat algoritmes die buiten organisaties zoals NIST ontwikkeld zijn hier beter tegen bestand zijn... dit leunt natuurlijk op de aanname dat deze algoritmes niet door hun eigen niet-westerse veiligheidsdiensten gecompromitteerd zijn. Iets dat we niet zeker kunnen weten.

[The Zep Man]

De bedoelde betekenis van "westerse algoritmes" is "encryptie-algoritmes die ontwikkeld zijn als onderdeel van westerse instituten, waarbij het risico aannemelijk is dat veiligheidsdiensten (zoals de NSA) er in geslaagd zijn om de praktische toepassing van algoritmes te verzwakken door invloed op de besluitvorming rond implementaties uit te oefenen." - deze aanpak is in de Snowden leaks bekend geworden, en heeft als naam "Operation Bullrun" (NSA) of "Edgehill" (GCHQ). Het bekendste voorbeeld is dat RSA een verzwakte random-number generate gebruikte, in ruil voor geld van de NSA.

Een kleine nuance (voor de niet oplettende lezer): het gaat hier om bewuste implementatiefouten, niet om fouten in de encryptie-algoritmes zelf. Encryptie-algoritmes zoals RSA (asymmetrisch) en AES (symmetrisch) zijn niet onveilig bewezen. Het is hierom lastig om deze algoritmes onveilig te implementeren, want een onveilige variant kan geen data meer uitwisselen met veilige varianten.

Kort samengevat komt het erop neer dat je voor de implementatie bij kritische acties niet afhankelijk moet zijn van oncontroleerbare elementen. VeraCrypt doet dit bijvoorbeeld door wel AES-NI te gebruiken voor encryptie en decryptie, maar niet voor het genereren van sleutels. Sowieso is het bij het genereren van entropie verstandig om meerdere bronnen te gebruiken: elke bron kan entropie toevoegen, maar geen enkele bron kan entropie wegnemen. Je moet alleen de uitvoer van entropiegenerators niet gebruiken als invoer voor dezelfde soort generators. Zo voorkom je afhankelijkheden, en kan zelfs een potentieel onveilig (NSA-approved™) onderdeel geen roet in het eten gooien.

Encryptie-algoritmes kan je met VeraCrypt stacken. Daarmee wordt voorkomen dat met het breken van één encryptie-algoritme de data ontsloten kan worden. De kans dat dit zal gebeuren is echter klein. Als bijvoorbeeld AES 'gekraakt' zou worden, dan zijn er wereldwijd grotere problemen dan enkele VeraCrypt containers (voor zowel overheden, bedrijven als individuen).

[Reactie gewijzigd door The Zep Man op 23 juli 2024 14:09]

[Rob Wu]

Toevoeging: Het gaat niet eens om een fout in het RSA algoritme, maar in een product (BSAFE) van een bedrijf dat RSA Security heet.

Het is hierom lastig om deze algoritmes onveilig te implementeren, want een onveilige variant kan geen data meer uitwisselen met veilige varianten.

Dit is niet waar: side-channel aanvallen kunnen nog steeds informatie lekken.

[The Zep Man]

Dit is niet waar: side-channel aanvallen kunnen nog steeds informatie lekken.

Een systeem gevoelig voor side-channel attacks kan nog steeds ciphertext genereren die niet te ontsleutelen is zonder toegang tot het originele systeem, en waarmee andere systemen aan de slag kunnen mits zij toegang hebben tot het juiste sleutelmateriaal. Het punt dat ik maakte is dat zo'n systeem nog steeds geldige ciphertext genereert.

Ik denk dat ik een beter onderscheid moet maken tussen de logische en fysieke implementaties van het algoritme. Die laatste is inderdaad gevoelig voor side-channel attacks.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 14:09]

[HellStorm666]

ik denk dat het vooral gaat om de gebruikte karakters.
de westerse encryptiealgoritmes bevatten westerse tekens.
Kan me voorstellen dat de niet-westerse encryptiealgoritmes ook niet-westerse tekens bevat.

[kvdveer]

Schijf-encryptie gaat over bytes - niet over tekens, dus die vlieger gaat niet op. Ik heb mijn reactie aangepast om duidelijk te maken dat het gaat om algo's van niet-westerse makelij.

[analog_]

maakt weinig uit aangezien je gewoon papers en bijhorende (wiskundige) formules hebt. een groter deel komt volgens mij eerder uit japan, china en india.

[Jace / TBL]

ik denk dat het vooral gaat om de gebruikte karakters.

Het gaat om de herkomst van de makers/bedenkers van het betreffende algoritme.

de westerse encryptiealgoritmes bevatten westerse tekens.
Kan me voorstellen dat de niet-westerse encryptiealgoritmes ook niet-westerse tekens bevat.

Wat Dit betekent niets, een encryptiealgoritme bevat geen tekens van deze of gene soort.

Encryptiealgoritmes werken met bits en bytes, geen tekens.

[aikebah]

Encryptiealgoritmes werken met bits en bytes, geen tekens.

Hang natuurlijk helemaal van je encryptiealgoritme af. Encryptie-algoritme ROT13 (https://en.wikipedia.org/wiki/ROT13) werkt wel degelijk met tekens (en is natuurlijk zo kraakbaar als wat)

[nst6ldr]

Uiteindelijk zijn alle karakters een verwijzing naar een karakter in een karakterset, deze verwijzing is gewoon een nummer, wat wordt opgeslagen als een byte. Algoritmes bewerken die bytes (of combinaties ervan) om versleuteling te bewerkstelligen. Het is verder irrelevant wat de gebruikte karakterset is.

[angelina]

Een van de niet-westerse encryptiealgorithmes in Veracrypt is Kuznyechik, een symmetrisch cryptografie algorithme van Russische makelij.

[Verwijderd]

Ik vraag mij af of we ooit zullen weten wat er met de oorspronkelijke Truecrypt is gebeurd.

[Jace / TBL]

Dat weten we toch al lang?

Die zijn onder druk van overheidsdiensten gedwongen hun software offline te halen, en een boodschap te plaatsen dat TrueCrypt onveilig was (wat later door de Audit niet het geval bleek) en dat ze in plaats daarvan een closed source proprietary oplossing van een Amerikaans bedrijf aanraden.

[stresstak]

Dat weten we toch al lang?
Die zijn onder druk van overheidsdiensten gedwongen hun software offline te halen, en een boodschap te plaatsen dat TrueCrypt onveilig was

Blijft het dilemma of het werkelijk onveilig is of te goed. Te goed in de ogen van de diensten die het graag zouden willen kraken binnen een kort tijdsbestek.

Ik heb het wel in gebruik en mount niks automatisch, dat vind ik tegennatuurlijk.

[Jace / TBL]

Ik snap het dilemma niet goed, waarom zou het eventueel 'werkelijk onveilig' zijn?

Hoe liever overheidsdiensten het offline willen hebben, hoe veiliger het is.

[stresstak]

Hoe liever overheidsdiensten het offline willen hebben, hoe veiliger het is.

Argwanend als ik ben, denk ik dat ook. Maar we weten het niet.

[beerse]

Veilig of niet veilig is maar net wat je definitie van veilig is. Als het er om gaat dat de gegevens niet bereikbaar zijn voor anderen, dan moet het doorbreken van de encryptie niet opwegen tegen de waarde van de inhoud.

Als een versleuteld bestand mogelijk bloot foto's van een president kandidaat van de verenigde staten van Amerika bevat, dan zal er veel meer op ingehakt worden dan als het de vakantie foto's van opa en oma van vorig jaar zijn. Met een standaard true-crypt of vera-crypt volume zal de tweede zwaar overbeveiligd zijn, de eerste mogelijk niet..

Maar zet de bestanden op een 8-inch floppy schijf met een cp/m filesysteem en niemand zal er naar omkijken, als ze al herkennen dat er mogelijk bestanden op staan.

Security by obscurity is op zich geen beveiliging maar maakt het mogelijk doorbreken van versleuteling wel minder waarschijnlijk.

Een kluis deur met de sleutel erin zal door iedere inbreker worden geopend. De meterkast met sleutel erin waarschijnlijk niet....

[LowTone]

Weten we dat officieel of is dat het hardnekkigste gerucht? Goede kans dat dat klopt inderdaad, maar is het ooit "officieel" bevestigd?

[Jace / TBL]

Wat zou volstaan qua "officieel bevestigd"? Dat lijkt me subjectief, en bovendien zijn hier dermate grote belangen mee gemoeid dat er toch altijd een roddelcircus van conspiracies en ontkenningen omheen zal blijven hangen.

De overheidsdiensten zelf zullen het nooit erkennen natuurlijk. En iemand anders, zoals iemand die beweert een oorspronkelijke TrueCrypt developer te zijn of een anonieme en/of voormalige medewerker van een overheidsdienst (een tweede Snowden o.i.d.) wordt toch op talloze manieren in diskrediet gebracht.

[Verwijderd]

Nee, dat weten we niet. Dat is wat jij er van maakt.

[LowTone]

Overigens zat de functie om muisbewegingen te gebruiken om de encryptiesleutel verder te randomizen ook al in TrueCrypt.

Goede zaak dit soort audits, zeker voor beveiligingssoftware als dit. Gebruik het om mijn backups te encrypten op een externe locatie. Ik ben ook benieuwd naar de EU audits naar KeyPass en Apache webserver. Ook software die ik zelf gebruik en graag als veilig bevestigd zie (voor zover ziets helemaal kan natuurlijk)

[judgewooden]

Beetje off-topic. Maar weet men wanneer de KeyPass audit is te verwachten?

[Ketho]

(edit) Die zou eind 2016 klaar moeten zijn, het code review onderdeel voor KeePass 1.31 is in ieder geval al afgerond
• https://joinup.ec.europa....sa/og_page/implementation
• https://joinup.ec.europa....-review-call-contribution

[Reactie gewijzigd door Ketho op 23 juli 2024 04:20]

[LowTone]

Ik zie het daar ja. Goed om te weten, thanks. Goede kans dat nu wordt gewerkt aan een update voor keypass en dat kort nadat die verschenen is de details van de audit naar buiten worden gebracht. Net als dat bij VeraCrypt nu is gebeurd. Logisch om t eerst te fixen en dan naar buiten te brengen lijkt me zo.

[regmaster]

Grappig (of eigenlijk niet), Truecrypt kwam een stuk beter uit de audit en werd als onveilig afgeserveerd. Nu heeft het zogenaamde veiligere Veracrypt maar liefst 8 kritieke punten maar nu hoor ik nergens dat Veracrypt onveilig is om te gebruiken, terwijl dat met 8 kritieke lekken wel zo mag worden opgevat.

[WhatsappHack]

Kwam dat niet omdat de ontwikkelaars zelf die onzin verkondigde...?

[True]

Niet als je deze 'kritieke' lekken gelijk oplost met een nieuwe update die dezelfde dag publiekelijk wordt gemaakt als het resultaat van de audit.

[Verwijderd]

Jammer!
Ik gebruik momenteel Veracrypt met een wachtwoord van 50 cijfers en 35-pass gutman.
Iemand een idee wat écht veilige encryptie-software is??

[sprikkel25]

dit is echt veilig, een huis tuin en keuken laptop kraakt echt geen wachtwoord zin, dit is door de spaties, een werkelijk onmogelijke taak om te brute-forcen. ik zou persoonlijk banger zijn voor keyloggers zodat ze je ww mee kunnen lezen.

wat ik het machtige vind is het verstoppen van je container tussen je gewone bestanden en dat de gui geen sjoege geeft als je een fout wachtwoord gebruikt
maar gelijk bij een fout ww meld dat het ook weleens geen container hoeft te zijn.
en de tijd die het nodig heeft om uit te pakken is ook wel een plusplunt dan word brute-force wel heel langdradig.

echter als je aan het werk bent in je container terwijl je een RAT op je os hebt die mee kan kijken realtime.

dan werkt zelfs encryptie niet.

[Franckey]

Is VeraCrypt compatible met TrueCrypt? Kan ik TrueCrypt containers/bestanden openen met VeraCrypt?
En is VeraCrypt het meest logische alternatief als je een tevreden TrueCrypt gebruiker bent?

[Otkurom]

Ja, Ja, en mogelijk.

Zoals hierboven te lezen is, is er twijfel over het statement dat Truecrypt offline is gehaald om zwakheden in de software. Er is een gerucht dat dit gebeurd is omdat de software niet te kraken was en onder druk offline gehaald is. Als dit waar was zou Truecrypt nog steeds een prachtig alternatief voor Truecrypt zijn.

Veracrypt is echter naar mijn idee een doorontwikkelde versie van Truecrypt, dus in dat geval zal het wel de meest logische vervanger van Truecrypt zijn.,

[Franckey]

Bedankt voor je reactie. Maar als Veracrypt een doorontwikkelde versie van Truecrypt is, waarom 'mag' Veracrypt dan wel en Truecrypt niet?

[Otkurom]

Ik heb geen idee, ik ben zelf ook overgegaan op veracrypt.

het is allemaal conspiracy natuurlijk, maar het zou me niks verbazen als de oorspronkelijke ontwikkelaars niet verder mochten met de naam Truecrypt vanwege contracten die in achterkamertjes zijn gesloten. Wat ik wel weet is dat ik het prettiger vind om met software te werken die regelmatig geupdate wordt en zoals nu blijkt, ook recente audits krijgt.

Mijn advies zou dan ook zijn, lekker overgaan.