Dit kan alleen gebruikt worden als de persoon die zelf op een ingelogde machine zit het bewust doet. Als een aanvaller al zo ver is is hij al door de encryptiebeveiliging heen. Lijkt me een issue dat hooguit op dichtgetimmerde bedrijfs PC's speelt waar iemand dan beheersrechten op kan krijgen.

Is dit een beveiligingslek dat Truecrypt zelf onveilig maakt? De referentie lezend, gaat het om een manier om admin rechten in Windows te krijgen. Als je standaard een admin account gebruikt, zou dit dus geen lek zijn?

Weer een poging om het gebruik van Truecrypt in een kwaad daglicht te stellen. Truecrypt is uitgebreid op veiligheid geaudit en daar zijn geen serieuze lekken uitgekomen.Het beschreven 'lek' gaat eerder over de beveiliging van Windows dan over Truecrypt, en dat die Idrassi de 'problemen' bevestigd is alleen maar eigen belang omdat het gebruik van VeraCrypt fors achter loopt op Truecrypt. Veracrypt is nog nooit geaudit en aangezien het een fork is weten we niet of daar achterdeurtjes in gestopt zijn. Van Truecrypt weten we wel dat er geen achterdeuren inzitten.

Nee, maar wel jouw PC als je Windows gebruikt. Waarbij moet worden opgemerkt dat privilege escalation kwetsbaarheden zeer veel voorkomen en meestal flink lagere risicoscores krijgen dan remote code execution kwetsbaarheden.

Als je standaard een admin account gebruikt begrijp je (nog) niet goed wat de risico's daarvan zijn of heb je daar lak aan.

Wellicht was het een typo, en bedoelde Dick99999 hopelijk "[...] geen admin account [...]"?

Ik ken dit specifieke issue niet maar er heeft ook iets soortgelijks onder Linux gespeeld, dan kon je een versleutelde file mounten onder een bestaande directory, dus ook /bin of /usr/bin. Ook alleen interessant op een multi-user systeem, want als het om een eigen machine gaat weet je het admin/root password. Of ik nu standaard onder een beheersaccount werk of niet, het is vrij zinloos om op die manier mijn eigen machine te hacken.

De reden van een lagere score is dat je voor de EoP al toegang dient te hebben tot het systeem. Bij RCE zit dit al impliciet in de vulnerability ingebakken. Wanneer er toegang is, wordt een EoP vulnerability in het algemeen juist hoger aangeslagen.

Ook naar aanleiding van de reactie van SPiff: ongeacht wat dick99999 bedoelde, het standaard inloggen met Armin privileges is gewoon dom, maar zelfs dan is EoP mogelijk (naar System, al kan je dit als Admin sowieso wel bereiken) wanneer dit door een kwetsbaarheid binnen truecrypt wordt bereikt, is het gewoon een lek in de software.

@johanw, als een aanval wordt uitgevoerd door slechts 1 lek te gebruiken, heb je gelijk. Een dergelijke simpele poging komt echter vrijwel alleen voor bij script kiddies. In het algemeen wordt er gestapeld: eerst verkrijgen van toegang, via vulnerability A, een droppen + malware gevolgd door EoP via vulnerability B. En ziezo systeem pwned. (Vandaar de hogere score van een RCE -> eenvoudigere first point of entry).

Klinkt eenvoudig en dat is het ook.

De issue is dat, als je ingelogd bent als admin, je onbedoeld malware start, deze meteen jouw complete systeem kan compromiteren. Als admin heb je schrijfrechten in het register onder HKLM, in mappen onder C:\Windows\, onder alle mappen onder C:\Users\ en, niet te vergeten, het MBR (Master Boot Record) en andere sectoren en bestanden betrokken bij het bootproces - waardoor een system-level rootkit geïnstalleerd kan worden. Maar ook kunnen allerlei beveiligingsinstellingen worden gewijzigd, zoals uitschakelen van firewall of virusscanner zonder dat je daar een melding van krijgt.

Als je UAC gebruikt (met de slider in de hoogste stand) is het lastiger voor malware om -ongemerkt voor jou- daadwerkelijk de privileges van de groep Administrators te verkrijgen, maar zeker niet onmogelijk (Microsoft zegt zelf, niet voor niets, dat UAC geen security boundary is).

De stap daarvandaan naar SYSTEM, voor zover noodzakelijk voor de malware, is helemaal een peuleschil.

User-mode malware kan ook veel schade aanrichten (denk aan ransomware) maar is veel eenvoudiger van een systeem te verwijderen - doordat het systeem zelf intact blijft. Tenzij die malware een werkende privilege escalation exploit "aan boord heeft" (of downloadt) en zo alsnog admin/systeemrechten verkrijgt.

Hoewel ik meestal admin accounts gehad heb op de PC's waar ik op werk, gebruik ik die accounts uitsluitend voor beheertaken. Voor dagelijks werk (inclusief programmeren) gebruik ik (sinds NT4, ca. 1999 - 2000) een "ordinary user" account. Ik gebruik Truecrypt en baal dus stevig van dit lek.

Dit kan ik alleen maar bevestigen. Want wie precies zitten achter de fork VeraCrypt? Van TrueCrypt weten we zeker dat er geen backdoors aangebracht zijn en we weten zeker dat er geen inlichtingenboys achter de code van TrueCrypt zaten.

Dat zou de standard manier van werken moeten zijn voor wat dan ook OS je gebruikt.

Volg de analyses van wat hacks en je ziet dat dit principe (server based) vaak genegeerd wordt. Er zijn heel wat "security specialisten" "architecten" en "beheerders" die beweren dat een gebruiker maar één (1) account mag hebben.
Het via wat richtlijnen echter heel duidelijk gesteld dat men de acties onder een bepaald account tot maar één persoon wil kunnen herleiden. De weerstand tegen meer accounts (beheer accounts/gewone gebruiker) en specifieke functionele accoutns (service accounts) is verbazend hoog.

Wat een onzin weer. Het auditeren van truecrypt betrof het beoordelen van software op hoe de code geschreven is en of de software doet wat het moet doen (intended functionality). En of er backdoors aanwezig waren. Unintended functionality is iets wat uit een (whitebox) pentest naar voren kan komen. Dit hoeft niet per de uit een code review/audit naar voren te komen.

Helaas komen de meeste vulnerabilities niet voort uit intended functionality maar uit Unintended functionality.

En ja, omdat truecrypt op een bepaalde manier werkt, waarvoor helaas binnen windows nog ondersteuning voor aanwezig is, is het mogelijk om truecrypt code te gebruiken voor dit lek.

En zoals iemand op reddit al aangaf: de jongens van NCC zijn goed, maar geen Google Project Zero. Niet voor niets komen deze vulnerabilities (2 CVE's) weer bij James Forshaw vandaan.

[edit: typo in aantal CVE's. Hersteld van 3 naar 2]

Dit is eerder een probleem in het brakke Microsoft Windows dan een applicatieprobeem.

Ja, inderdaad. Microsoft heeft de truecrypt code geschreven....

Dus was het toch geen onzin, want ik zei namelijk precies hetzelfde.

Nee, er wordt nl niet gekeken of de software buiten dat het doet waarvoor het is geschreven, ook nog per ongeluk iets anders kan doen. (Onvoorziene functies)

Nou, Veracrypt is ook open source dus het is wel te checken. Omdat veel code hetzelfde zal zijn als bij TrueCrypt lijkt me dat zelfs een stuk minder werk, nu er al een TC audit is.