Computerbeveiliging - Hoe je bad guys buiten de deur houdt

Microsoft Encryptie te omzeilen ?

29-01-2010, 14:25 door Anoniem, 11 reacties
Als je een bestand wilt coderen in b.v. XP dan kan dat gemakkelijk met de rechter muisknop en door geavanceerd te kiezen. Wie dan denkt veilig te zijn komt bedrogen uit.

Wat er namelijk tijdens het coderen gebeurt (zover ik het kan zien) is dat het originele ongecodeerde bestand, test.txt, wordt gekopieerd naar een bestand met als naam EFSx.TMP. Het origineel wordt dan verwijderd en er wordt een nieuw gecodeerd bestand aangemaakt met als naam test.txt.
EFSx.TMP wordt nu gekopieerd naar de nieuwe test.txt en het ongecodeerde EFSx.TMP wordt verwijderd.

Echter is EFSx.TMP te achterhalen met een tool als Recuva, welke verwijderde bestanden terug kan halen.

Als je dus gegevens wilt beveiligen met Microsoft Encryptie dan moet je een leeg bestand aanmaken, deze meteen coderen en daarna je gegevens invoeren.
Bestaande gegevens coderen is onveilig zolang het verwijderde EFSx.TMP niet overschreven is.
Reacties (11)
30-01-2010, 09:54 door ej__
Dit is de minste van je zorgen. De encryptie zelf is gekraakt.

EJ
30-01-2010, 14:47 door Ilja. _V V
Je hele idee klopt al niet, het heeft niets met versleuteling te maken. Wist ik 3 maanden geleden ook nog niet , hoor!.. ;-)

http://207.46.16.252/en-us/magazine/2009.09.windowsconfidential.aspx
30-01-2010, 15:08 door Anoniem
Gebruik bijv. TrueCrypt als je iets wil coderen, dan kan je ook erbij overschrijven tot max. 35 keer :)
31-01-2010, 03:14 door Karl Hungus
@ topicstarter:
Dit heeft niks met "Microsoft encryptie" te maken. Als ik vanuit mijn onversleutelde home-directory of data-partitie een bestand verplaats naar een gemount Truecrypt volume, dan heb ik net hetzelfde "probleem". Dit is gewoon een inherente beperking van dit soort systemen. In elk bestandssysteem kan je nadien gaan carven.

Oplossingen: op al je schijven/partities "full disc encryptie" (FDE) gebruiken, of nadien je vrije ruimte overschrijven, of een vorm van "secure move" gebruiken, waarbij het bronbestand naar het doel gekopiëerd wordt en daarna overschreven.

Of er tussendoor door je programma's niet ergens een tussentijds opgeslagen temp-bestandje gemaakt is, kan je trouwens nooit zeker weten.

@ ej__:
Bronnen graag (en nee, "mijn mama heeft gezegd dat ..." is niet overtuigend).

@ Ilja. _\\//
Ik sta helemaal achter je eerste bewering, alleen snap ik niet wat die link daar doet, die heeft niets met EFS te maken. Of wou je de topicstarter echt helemaal van de wijs brengen? Ondeugend hoor :)
31-01-2010, 14:10 door Bitwiper
Ik ben het eens met Karl. Enkele aanvullingen: het artikel met URL met IP-adres waar Ilja. _\\// naar verwijst is hetzelfde als http://technet.microsoft.com/en-us/magazine/2009.09.windowsconfidential.aspx. Dat beschrijft het encoden en niet encrypten van een deel van de registry (in dit geval gaat het er om hoe vaak een gebruiker een bepaalde applicatie gebruikt, deze gegevens kijg je te zien in het "Software" applet van Control Panel).

EFS maakt (volgens http://en.wikipedia.org/wiki/Encrypting_File_System#Algorithms_used_by_Windows_version) sinds XP SP1 by default gebruik van AES, dat bij gebruik van een sleutel van voldoende lengte, in de praktijk nog onkraakbaar is. EFS is, in elk geval onder XP en ouder, net zo "sterk" als het wachtwoord van de gebruiker, en meestal van andere mogelijkheden om fysiek toegang tot dat account (of het administrator account) te krijgen. Een ander EFS probleem is dat bestanden niet-versleuteld via het netwerk worden gekopieerd en niet-versleuteld op backups terecht kunnen komen.

En voor de TS: los van een terug te halen unencrypted bestand bestaan er bij het gebruik van EFS nog meer risico's: fragmenten of het hele bestand zijn soms in de swapfile en/of hibernate file terug te vinden, en veel applicaties maken daarnaast tijdelijke bestanden aan in temp mappen. Zoals Karl al aangaf is FDE (Full Disk Encryption) hiervoor de meest veilige oplossing. Daarnaast zou je bijzonder kritische bestanden ook nog op individuele basis kunnen versleutelen (zodat een aanvaller daar niet meteen toegang toe heeft bijv. als je even naar het toilet gaat zonder je PC te locken).

Overigens is mijn vertrouwen in "secure delete" of "wipen" van individuele bestanden zeer beperkt. Bij mijn weten garandeert Microsoft niet dat als je op het NTFS bestandssysteem een bestand overschrijft dat je dezelfde fysieke locaties (sectoren) op de schijf overschrijft (daar zou bijv. best een "slim" defragmentatiemechanisme tussen kunnen zitten, evt. van een third-party leverancier). Die garantie bestaat bijv. bij flashdisks zeker niet, het daarin meestal toegepaste wear-leveling mechanisme voorkomt juist dat dezelfde fysieke locaties steeds opnieuw worden overschreven.
31-01-2010, 18:36 door Ilja. _V V
Ik heb dat artikel in de Nederlandse vertaling gelezen in het TechNet Magazine, nummer november 2009, blz. 74. Bij het Googlen kwam het IP van TechNet als eerste er uit. Jongens & meisjes alhier zijn wijs genoeg om dat te controleren, mag ik aannemen... ;-)

Waar de meesten incluis de TS op het verkeerde been worden gezet, zit hem in het verschil tussen de Engelstalige & Nederlandstalige Windows: Als je doet wat de TS beschrijft in de Engelse versie, dan staat er toch echt: Encrypt contents to secure data. Terwijl in de Nederlandse versie er staat: Inhoud coderen om gegevens te beveiligen.

Ik heb het net nog even getest op een simpel tekstbestand, & er word niet eens om een wachtwoord gevraagd. Alleen als een andere niet-geautoriseerde gebruiker het probeert te openen, dan krijgt die een pop-up: Toegang geweigerd.

Dus als je echt wilt versleutelen, moet je dat niet via die RMK in Windows doen...
31-01-2010, 20:39 door ej__
Door Karl Hungus: @ topicstarter:
Dit heeft niks met "Microsoft encryptie" te maken. Als ik vanuit mijn onversleutelde home-directory of data-partitie een bestand verplaats naar een gemount Truecrypt volume, dan heb ik net hetzelfde "probleem". Dit is gewoon een inherente beperking van dit soort systemen. In elk bestandssysteem kan je nadien gaan carven.

Oplossingen: op al je schijven/partities "full disc encryptie" (FDE) gebruiken, of nadien je vrije ruimte overschrijven, of een vorm van "secure move" gebruiken, waarbij het bronbestand naar het doel gekopiëerd wordt en daarna overschreven.

Of er tussendoor door je programma's niet ergens een tussentijds opgeslagen temp-bestandje gemaakt is, kan je trouwens nooit zeker weten.

@ ej__:
Bronnen graag (en nee, "mijn mama heeft gezegd dat ..." is niet overtuigend).

@ Ilja. _\\//
Ik sta helemaal achter je eerste bewering, alleen snap ik niet wat die link daar doet, die heeft niets met EFS te maken. Of wou je de topicstarter echt helemaal van de wijs brengen? Ondeugend hoor :)

Bitwiper geeft daar al een voorbeeld van. Verder is recovery door systeembeheerder een standaard functie. Derhalve niet bruikbaar. Het algoritme mag dan wel AES zijn, dat zegt helemaal niets over de implementatie. EFS is een domme manier om je data te beschermen.

De eerste de beste google zoekactie levert een commercieel tool als eerste hit: http://www.elcomsoft.com/aefsdr.html. Zucht. Karl: je mag best zelf even googelen hoor. Dat doet geen pijn en is niet moeilijk.

EJ
01-02-2010, 00:37 door Bitwiper
Door ej__: Verder is recovery door systeembeheerder een standaard functie. Derhalve niet bruikbaar.
Dat hangt ervan af. Als je werkgever bent en de werknemer komt onder de tram, dan wil je nog wel zijn bestanden kunnen openen.

Het algoritme mag dan wel AES zijn, dat zegt helemaal niets over de implementatie. EFS is een domme manier om je data te beschermen.

De eerste de beste google zoekactie levert een commercieel tool als eerste hit: http://www.elcomsoft.com/aefsdr.html. Zucht. Karl: je mag best zelf even googelen hoor. Dat doet geen pijn en is niet moeilijk.
In jouw eerste post beweerde je iets anders:
Dit is de minste van je zorgen. De encryptie zelf is gekraakt.
Karl reageerde terecht op jouw stelling dat de encryptie gekraakt zou zijn (die jij bovendien niet verder toelichtte). AES is niet gekraakt, evenmin als de implementatie van AES onder Windows (voor zover ik weet).

In http://www.elcomsoft.com/WP/advantages_and_disadvantages_of_efs_and_effective_recovery_of_encrypted_data_en.pdf staat onder meer:
Advanced EFS Data Recovery can be used to successfully restore upto 99% of EFS-encrypted data, if the user keys are retrieved
Die keys kunnen echter op een server zijn opgeslagen, en vanaf Vista wordt opslag op een smartcard ondersteund; in beide gevallen zal een dief van je notebook de EFS-versleutelde bestanden niet kunnen decrypten (wel kan hij mogelijk onversleutelde kopieën vinden op de schijf).

Je zult mij niet voor het gebruik van EFS horen pleiten, maar het ligt wel wat genuanceerder dan jij stelt, en Karl's reactie was naar mijn mening terecht (voor hetzelfde geld is de encryptie gekraakt en hebben wij dat gemist).
01-02-2010, 00:57 door Bitwiper
Door Ilja. _\\//: Ik heb dat artikel in de Nederlandse vertaling gelezen in het TechNet Magazine, nummer november 2009, blz. 74. Bij het Googlen kwam het IP van TechNet als eerste er uit. Jongens & meisjes alhier zijn wijs genoeg om dat te controleren, mag ik aannemen... ;-)
Vast wel, maar als je op een IP-adres-URL klikt ben je feitelijk klikvee...

Waar de meesten incluis de TS op het verkeerde been worden gezet, zit hem in het verschil tussen de Engelstalige & Nederlandstalige Windows: Als je doet wat de TS beschrijft in de Engelse versie, dan staat er toch echt: Encrypt contents to secure data. Terwijl in de Nederlandse versie er staat: Inhoud coderen om gegevens te beveiligen.
Daarom hou ik ook niet van naar het Nederlands vertaalde software. Dat zuigt. De uitgang (output) van netstat -ano past in NL niet op 1 regel omdat een of andere moron meende dat "listening" vertaald moest worden in "bezig met luisteren".

Ik heb het net nog even getest op een simpel tekstbestand, & er word niet eens om een wachtwoord gevraagd.
Dat is geen kever (bug) maar een gezichtskenmerk (feature :)
Als je je systeem goed hebt opgezet wordt er bij het inloggen om een wachtwoord gevraagd. Bij EFS beschermt datzelfde wachtwoord (en dat van de Administrator) ook jouw bestanden. Er wordt dus wel degelijk versleuteld (in de zin van encryption). Dat de sleutels makkelijker te achterhalen zijn dan bij sommige andere file-encryption-tools staat m.i. los van de discussie versleutelen vs coderen.
01-02-2010, 10:06 door ej__
Door Bitwiper:
Door ej__: Verder is recovery door systeembeheerder een standaard functie. Derhalve niet bruikbaar.
Dat hangt ervan af. Als je werkgever bent en de werknemer komt onder de tram, dan wil je nog wel zijn bestanden kunnen openen.

Het algoritme mag dan wel AES zijn, dat zegt helemaal niets over de implementatie. EFS is een domme manier om je data te beschermen.

De eerste de beste google zoekactie levert een commercieel tool als eerste hit: http://www.elcomsoft.com/aefsdr.html. Zucht. Karl: je mag best zelf even googelen hoor. Dat doet geen pijn en is niet moeilijk.
In jouw eerste post beweerde je iets anders:
Dit is de minste van je zorgen. De encryptie zelf is gekraakt.
Karl reageerde terecht op jouw stelling dat de encryptie gekraakt zou zijn (die jij bovendien niet verder toelichtte). AES is niet gekraakt, evenmin als de implementatie van AES onder Windows (voor zover ik weet).

In http://www.elcomsoft.com/WP/advantages_and_disadvantages_of_efs_and_effective_recovery_of_encrypted_data_en.pdf staat onder meer:
Advanced EFS Data Recovery can be used to successfully restore upto 99% of EFS-encrypted data, if the user keys are retrieved
Die keys kunnen echter op een server zijn opgeslagen, en vanaf Vista wordt opslag op een smartcard ondersteund; in beide gevallen zal een dief van je notebook de EFS-versleutelde bestanden niet kunnen decrypten (wel kan hij mogelijk onversleutelde kopieën vinden op de schijf).

Je zult mij niet voor het gebruik van EFS horen pleiten, maar het ligt wel wat genuanceerder dan jij stelt, en Karl's reactie was naar mijn mening terecht (voor hetzelfde geld is de encryptie gekraakt en hebben wij dat gemist).

Nee, dat ligt het niet, in ieder geval niet voor EFS op XP. Daar is de encryptie (dus AES op EFS) wel degelijk niet veilig en gekraakt.. Zoek maar eens wat beter. En dat een werkgever bij de data van een werknemer moet kunnen is ook geen uitgemaakte zaak. Gebruik google eens wat verder dan de eerste hit. Ik heb niet beweerd dat AES gekraakt is, maar dat EFS gekraakt is. Dat is ook de context van het artikel.

En dat 'if the user keys; are retrieved' slaat op de certificaten... Juist daar zit de zwakheid van EFS. EFS is schijnveiligheid, net als de xor encryptie die eerst werd gebruikt. EFS gebruikt certificaten die niet veilig genoeg zijn.

Dit alles neemt zeker niet weg dat de poster zich druk maakt over iets wat nog veel minder belangrijk is. De poster zal zich moeten realiseren dat zijn document enigertijd unencrypted in ram zit, en in een swapfile en in temp files. Hij heeft alleen het laatste stapje gezien en maakt zich alleen daar druk om. Dat is echt de minste van zijn zorgen als hij zaken geheim wil houden.

EJ
01-02-2010, 23:22 door Ilja. _V V
Door Bitwiper: Vast wel, maar als je op een IP-adres-URL klikt ben je feitelijk klikvee...
Hihi..: "Can't blame a guy for trying..."... Maar ik had het zelf al dubbel gecontroleerd alvorens te plaatsen, hoor.

Door Bitwiper: Daarom hou ik ook niet van naar het Nederlands vertaalde software. Dat zuigt.
Kan ook zijn dat de oorspronkelijke subroutine door een Chinees of Taiwanees is geschreven, daarna verkeerd vertaald naar het Engels, & waarna in opvolgende vertalingen de terminolgie weer is gecorrigeerd...

Door Bitwiper: Als je je systeem goed hebt opgezet wordt er bij het inloggen om een wachtwoord gevraagd. Bij EFS beschermt datzelfde wachtwoord (en dat van de Administrator) ook jouw bestanden. Er wordt dus wel degelijk versleuteld (in de zin van encryption). Dat de sleutels makkelijker te achterhalen zijn dan bij sommige andere file-encryption-tools staat m.i. los van de discussie versleutelen vs coderen.
Aha. Gelukkig word dat wachtwoord op een andere plek opgeslagen.
Maar wat versleuteling betreft nog even een highlight van Raymond Chen: "If programmers do want to mess with it, they have to apply the (extremely simple but still non-null) decoding algorithm before proceeding."
Verder is er in het algoritme geen verandering aangebracht vanaf Windows 2000. Alleen in Windows 7 is er een wijziging maar dat dient alleen maar om het verschil met oudere versies weer te geven.
Het is nooit ontworpen als beveiliging, maar alleen als barriere.

Zelfs als je een degelijke versleuteling toepast, dan helpt dat niets tegen allerlei unerasers. Alhoewel daartegen weer schredders in omloop zijn. Ben je er nog niet, want een kwaadwillende kan er dan weer inplaats van inzage alsnog voor kiezen om je ozo belangrijke versleutelde bestanden simpelweg te vernietigen...
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.