'Previewfunctie van macOS kan thumbnails van versleutelde bestanden lekken'

Twee beveiligingsonderzoekers hebben aandacht gevraagd voor een methode om onder macOS bestanden in te zien, die al langer in forensische kringen bekend zou zijn. Zo zou de QuickLook-functie thumbnails uit versleutelde containers kunnen prijsgeven via caching.

MacOS-beveiligingsonderzoeker Patrick Wardle heeft samen met onderzoeker Wojciech Reguła een blogpost gewijd aan het verschijnsel, dat volgens hem al jaren bekend is in forensische kringen. Daaruit is op te maken dat de QuickLook-functie macOS-gebruikers in staat stelt om een preview van een bestand te bekijken door het te selecteren en op de spatiebalk te drukken. Doordat deze thumbnails in de cache worden opgeslagen, zouden ze echter ook gevoelige informatie kunnen prijsgeven, omdat ze later weer uit te lezen zijn. Dit is problematisch bij bestanden die zijn opgeslagen in een versleutelde container.

In de blogpost demonstreren de onderzoekers de techniek, door bijvoorbeeld een dergelijke container met VeraCrypt aan te maken, er twee afbeeldingen in te plaatsen en ze kort met de previewfunctie te bekijken. Met een script is het vervolgens mogelijk om een gecachete versie van de afbeeldingen uit het geheugen op te diepen. Dat kan ook in het geval van een versleutelde apfs-container en nadat deze niet langer is gemount, aldus de onderzoekers. Ze voegen daaraan toe dat het niet per se vereist is eerst een preview te bekijken, maar dat de gecachete thumbnail in dat geval kleiner is.

Hetzelfde zou ook werken met tekstbestanden, al is onder meer de gekozen fontgrootte van invloed op de leesbaarheid van de thumbnail. Ook de inhoud van aangesloten usb-drives zou te vinden zijn in de cache. Wardle stelt dat het verschijnsel een risico kan opleveren als bijvoorbeeld een aanvaller fysieke toegang heeft tot een ingeschakeld systeem. Een work-around is het handmatig legen van de QuickLook-cache, waarvoor hij instructies geeft.

Reacties (24)

[ZpAz]

Ik denk niet dat dit een OSX probleem is. Ik heb VeraCrypt niet, maar quicklook werkt standaard enkel met een aantal bestandstypen. Bijvoorbeeld een zip bestand werkt niet. Een Developer kan wel een plug-in maken zodat het wel werkt voor zijn bestandstype.

Vera-crypt moet dan voor zijn bestandstype in de preview niets laten zien (of geen plug-in hiervoor installeren) dan is de preview namelijk enkel de naam en het icoon.

Ik gebruik zelf het op OSX standaard aanwezige disk Utility om een encrypted “folder” aan te maken. En hier kan ik met de quicklook functie niets zien.

Plaatje


Zie reactie van Magic hieronder, ik had het probleem blijkbaar niet helemaal goed begrepen.

[Reactie gewijzigd door ZpAz op 22 juli 2024 23:51]

[Jerie]

Je hebt duidelijk niet de PoC gelezen. Want het is niet zo dat je dmv een plaatje de boel ziet, maar dmv een find command.

com.apple.QuickLook.thumbnailcache/index.sqlite
com.apple.QuickLook.thumbnailcache/thumbnails.data

com.apple.* betekent dat het officiele Apple software zit, en QuickLook geeft aan welk programma het betreft. Wel degelijk een onderdeel van macOS dus.

Als je die SQLite index opent zie je de filenames staan. Dat alleen al is een lek want het zorgt er voor dat bijvoorbeeld VeraCrypt's plausible deniability niet meer werkt. APFS is ook een voorbeeld

Dat niet alleen, de data staat ook in thumbnails.data en is te extracten.

Wel degelijk een bug in macOS dus.

Dat is iets anders dan bijv .DS_Store of Thumbs.db. Die zitten in de folders zelf, en als die folders versleutels zijn dan dus ook die files.

[Magic]

Het probleem is dat de thumbnails van de bestanden ín deze container zichtbaar zijn, wanneer je dus je voorbeeldbestandje "wallets.dmg" opent, en dan via finder er in gaat kijken dan worden deze thumbnails in je preview cache opgeslagen.

Veracrypt doet eigenlijk precies hetzelfde als wat jij hier doet, enkel ondersteund het wat meer "hardcore" versleutelingsmethodes.

Het gaat niet om de thumbnails van het containerbestand zelf natuurlijk.

Ik verbaas me er echter over dat dit nu naar boven komt, dit is al een poos bekend op het internet. Het is in principe op te lossen door ook gewoon je schijf te versleutelen. Enkel dat het je "plausible denyability" in de weg zit.

[Reactie gewijzigd door Magic op 22 juli 2024 23:51]

[Jerie]

Enkel dat het je "plausible denyability" in de weg zit.

Dat niet alleen. De thumbnails staan ook daadwerkelijk onversleuteld op com.apple.QuickLook.thumbnailcache/thumbnails.data ergens in /var/folders

[Magic]

ow, dan is dat al anders dan het "probleem" waar ik bekend mee ben. Dat is zekers iets dat Apple moet fixen.

[Jerie]

Mja, er zijn wel veel meer applicaties die plausible deniability verneuken. Als je bijvoorbeeld LUKS/TrueCrypt/VeraCrypt/enz gebruikt op Linux en je wil die data niet in je slocate DB hebben zul je die directory moeten excluden in cron of w/e je slocate DB maakt. Of gewoon slocate nooit aanzetten. Anders heb je een metadata leak en dus plausible deniability leak. Ernstig, maar ook PEBCAK.

Een ander voorbeeld is ~/.bash_history als jij in je FDE hebt lopen werken en de commands die je hebt gebruikt zijn opgeslagen in (in dit geval) de Bash history.

Zo zou je dit ook kunnen zien. Eigenlijk zou een minimalist guide voor VeraCrypt (enzo) dit probleem moeten benoemen en de suggestie geven om in geval van macOS QuickLook uit te zetten. Maar je zou ook kunnen zeggen dat dat de verantwoordelijkheid v/d gebruiker is. Desondanks zit het probleem in macOS software (QuickLook) en niet in (o.a.) VeraCrypt.

En ik neem aan dat Windows Search hetzelfde probleem heeft, alsmede Spotlight. Het is aan te raden om dat eerst uit te zoeken alvorens je met FDE en plausible deniability aan de slag gaat.

[Reactie gewijzigd door Jerie op 22 juli 2024 23:51]

[Magic]

Mag geen +2 geven op een reactie, maar bij deze dan maar

Gelukkig hoef ik me niet in de bos met prikkeldraad te begeven die "plausible denyability" heet. Zolang mijn gegevens maar niet zonder mijn toestemming leesbaar zijn vind ik het goed, de quicklook bug doet daar wel afbreuk aan dan.

[trab_78]

PEBCAK? FDE?

[xrf]

Hier, ik heb het even voor je opgezocht:

PEBCAK - Wiktionary

https://en.wiktionary.org/wiki/PEBCAK

PEBCAK. (humorous) Problem Exists Between Chair And Keyboard.

En FDE is Full Disk Encryption.

[fapkonijntje]

Voor zover ik weet laat Windows Search geen thumbnails zien van bestanden waar 'ie niet bij kan, want de thumbnails die overal in Windows te zien zijn, zijn lokaal bij de bestanden in de mappen opgeslagen (de bekende thumbs.db bestanden). Er is wel een lastig toegankelijke thumbnail storage in Windows 10, maar die doet minder dan QuickLook bij macOS. Ook worden er geen thumbnails van textbestanden en andere bestanden, behalve afbeeldingen, gemaakt. Onder macOS wel. Onder macOS kun je PDFjes en héél veel andere bestanden goed bekijken. De thumbnails zijn behoorlijk (overdreven) high-res.

Overigens is dit allemaal erg oud nieuws. Dit was in 2010 al bekend; http://osxdaily.com/2010/...n-from-encrypted-volumes/ Dus waarom dit nu ineens nieuws is, snap ik niet helemaal?

[DigitalExorcist]

Ja niet alleen VeraCrypt als ik het zo lees, maar een encrypted apfs-folder dus ook, staat in de tekst. En da's slordig. Maar als je het niet kunt reproduceren vraag ik me af wat jouw installatie anders maakt dan die van die onderzoeker(s).

Vraag me af of Windows niet iets soortgelijks doet eigenlijk.

[xrf]

Windows slaat thumbnails op in een cache-bestand genaamd Thumbs.db in dezelfde map, dus als het goed is wordt dat ook gewoon meeversleuteld.

[DigitalExorcist]

Ah ja.. da's waar ook. Maar geldt dat dan ook echt als cache, of is het puur een indexingbestand? Ik bedoel, zou daar ook niet iets van in de Prefetch-mappen blijven zitten wellicht?

[xrf]

Wikipedia zegt dat het puur als cache is, bestanden indexeren valt dus ergens anders onder.

Ik lees overigens ook in het artikel dat Windows sinds Vista in veel gevallen de cache niet meer in dezelfde map als het bestand opslaat, maar ergens in de AppData-map.

[batjes]

Indexeren gebeurd door de Windows Search service. De thumbs.db caches worden hier ook door aangemaakt.

[TimTurbo2]

Ja, wel alles dat in de zelfde map staat maar Windows slaat in sommige gevallen tumbnails ook op in een centrale plek op de c schrijf die niet geencrypt is, ook tumbnails van geencrypt containers zijn daar soms terug te vinden, ik weet alleen niet zeker wat de voorwaarden zijn voordat iets daar ook gecached wordt

[xrf]

Het gaat er volgens mij niet om dat er info wordt onthuld via de thumbnail van je .dmg-bestand, maar dat als je een map op zo'n versleutelde schijf opent de thumbnails die Finder toont, of de preview die de QuickLook-functie genereert, ergens op een onversleutelde plek worden opgeslagen om ze de volgende keer sneller te kunnen tonen.

[Booster]

In het blog-artikel van de onderzoekers wordt gekeken naar qlmanage -r om de cache te legen. Zij concluderen al dat dit niet zoveel lijkt te doen. Volgensmij is de juiste manier om de QuickLook cache te legen:

qlmanage -r cache

Dit maakt de sqlite database en thumbnails.data-file in ieder geval leeg, maar er kan nog data op disk aanwezig zijn. Om vrije ruimte te wissen op een HDD kun je daarna vrije diskruimte overschrijven:

diskutil list
[kies een volume]
diskutil secureErase freespace [X] [gekozen volume]

Vul X in als:
0 - Single-pass zero-fill erase.
1 - Single-pass random-fill erase.
2 - US DoD 7-pass secure erase.
3 - Gutmann algorithm 35-pass secure erase.
4 - US DoE algorithm 3-pass secure erase.

Bv: diskutil secureErase freespace 1 /dev/disk1s1

Op SSD is dit minder effectief door wear leveling dingetjes.
Zie man diskutil voor meer info.

[_Thanatos_]

Je kunt natuurlijk simpelweg de thumbnail cache ook encrypten. Problem solved.

[WhatsappHack]

Dat wordt het eigenlijk al als FileVault aanstaat, maar het systeem weet de decryptiesleutel. Daarom is het ook een probleem als een kwaadwillende toegang heeft. Als je Mac nog opgestart moet worden kan je naar mijn weten die cache niet uitlezen vanwege de encryptie.

Het probleem is echt als iemand toegang krijgt tot je Mac en die bestanden nog in een cache staan ipv louter je apart versleutelde container. De extra laag encryptie faalt dan omdat het in de cache te vinden is.

[Reactie gewijzigd door WhatsappHack op 22 juli 2024 23:51]

[_Thanatos_]

Als je de cache encrypt, en die kan alsnog uitgelezen worden, dat geldt dat dus ook voor de bestanden waar die thumbnails over gaan. Als je beide op dezelfde manier encrypt, dan zijn ze allebei even veilig.

Als dat niet voldoende is, moet je misschien een andere techniek gebruiken. Maar als er dán ergens anders een cache terecht komt, kun je het OS niet de schuld geven. Bijv als je veracrypt gebruikt, heeft het OS totaal geen weet van dat de files daarin effectief encrypted zijn.

[Capa]

Dat hoef je dan niet hier te melden...