image

Windows snipping tool kan gevoelige informatie uit screenshots lekken

woensdag 22 maart 2023, 09:06 door Redactie, 19 reacties

De snipping tool in Windows 11 en de Snip & Sketch tool in Windows 10, in het Nederlands bekend als het knipprogramma, kunnen gevoelige informatie lekken die gebruikers uit screenshots hebben weggeknipt. Eerder werd een dergelijk probleem bij de Markup-tool van Google Pixel-telefoons aangetroffen. Google kwam deze maand met een beveiligingsupdate (CVE-2023-21036) voor Pixel-telefoons.

Nu blijkt het probleem ook aanwezig te zijn in twee tools van Windows 10 en 11, zo melden beveiligingsonderzoekers David Buchanan en Chris Blume op Twitter. Wanneer gebruikers een screenshot bewerken en informatie wegknippen of de afbeelding verkleinen is dat gedeelte niet meer zichtbaar, maar blijft de weggeknipte informatie in het bestand staan als dat vervolgens wordt opgeslagen en daarmee het origineel overschrijft. Deze informatie is daardoor te herstellen, waardoor het weggeknipte gedeelte weer zichtbaar kan worden gemaakt.

Iets wat ook zichtbaar is via de bestandseigenschappen, aangezien het aangepaste bestand even groot is als het onbewerkte bestand, meldt onderzoeker Will Dormann. Het probleem doet zich alleen voor bij png-bestanden. Microsoft heeft aangegeven op de hoogte van het probleem te zijn en zal volgens een woordvoerder indien nodig maatregelen nemen.

Reacties (19)
22-03-2023, 09:50 door Anoniem
Oke, tijd om een imgsec tool te schrijven!

Een tool die enkel de gewilde pixel-informtie kopieert naar een apart bestand.
Dan kan je ook geen last meer hebben van dit soort datalekken...
22-03-2023, 09:54 door Anoniem
Het probleem is dat er bij het wegschrijven van het bestand na bewerken geen nieuw bestand gemaakt wordt maar het bestaande bestand wordt "overschreven" met de nieuwe inhoud. Echter men vergeet aan het eind van die schrijf actie een "truncate" systemcall te doen waardoor de size van het bestand ook echt gezet wordt op de hoeveelheid die er nu in geschreven is. Dit moet standaard gebeuren bij ieder programma wat een file "overschrijft" met nieuwe inhoud (geen los record maar een compleet nieuwe file), en wat degene die dit programma gemaakt heeft kennelijk niet gedaan heeft. Of misschien zit het probleem wel in een of andere library.
22-03-2023, 10:10 door Anoniem
Ben soms paranoïde als ik een screenshot maak voor documentatie of iets dergelijks waar een username/password veld instaat ter verduidelijking van het een of ander. Wat ik dan doe als ik het weg knip of blur nogmaals van dat bestand en screenshot maken en die doorsturen of in het document zetten. vervolgens smijt ik die andere afbeeldingen weg (indien opgeslagen)

Maar goed dat blijkt dus maar weer dat dit terug te herleiden is. Zelf gebruik ik Greenshot.
22-03-2023, 10:17 door Tintin and Milou
Daarom SNAGIT, of eventuee ShareX
22-03-2023, 11:01 door Anoniem
Geld dit ook voor de combinatie, "Shift / Windowsknop / S" ?
22-03-2023, 11:49 door Anoniem
Door Anoniem: Ben soms paranoïde als ik een screenshot maak voor documentatie of iets dergelijks waar een username/password veld instaat ter verduidelijking van het een of ander. Wat ik dan doe als ik het weg knip of blur nogmaals van dat bestand en screenshot maken en die doorsturen of in het document zetten. vervolgens smijt ik die andere afbeeldingen weg (indien opgeslagen)

Maar goed dat blijkt dus maar weer dat dit terug te herleiden is. Zelf gebruik ik Greenshot.
Wat ook werkt: opslaan in nieuw bestand ipv opslaan in hetzelfde bestand. De oude weggooien en alleen verder met het nieuwe bestand.
Of je screenshot editten, en dan pas opslaan. De data die je weggehaald hebt is dan nooit opgeslagen en kan dus ook niet teruggehaald worden.
22-03-2023, 12:34 door Anoniem
weer een lek in Windows 10 11..?.waarom moeste we overstappen naar win 11.? het zou volgens Microsoft veel en veel veiliger
zijn dat win 11?...onze oudelaptop s konden we weg gooien .wat een milieu verspilling.......
22-03-2023, 13:52 door Anoniem
Door Anoniem: weer een lek in Windows 10 11..?.waarom moeste we overstappen naar win 11.? het zou volgens Microsoft veel en veel veiliger
zijn dat win 11?...onze oudelaptop s konden we weg gooien .wat een milieu verspilling.......

Het is niet echt een lek, maar vooral onkunde van de gebruiker.
22-03-2023, 14:22 door Anoniem
/Facebook aan
Door Anoniem: weer een lek in Windows 10 11..?.waarom moeste we overstappen naar win 11.? het zou volgens Microsoft veel en veel veiliger
zijn dat win 11?...onze oudelaptop s konden we weg gooien .wat een milieu verspilling.......
Nee! er is een mogelijk lek indien er bij een windows applicatie gebruik wort gemaakt van een bepaald fileformaat i.c.m een specifieke functie. Nee, nee en nee. Windows 10 wordt nog volledig ondersteund.
/facebook uit
22-03-2023, 14:52 door Anoniem
Slordig natuurlijk. Ik zie hier andere tools genoemd worden, maar wie zegt dat deze dan wel goed hun werk doen? of geloof je in de wij van WC eend....
22-03-2023, 15:40 door Anoniem
Door Anoniem:
Het is niet echt een lek, maar vooral onkunde van de gebruiker.
Welnee, het is onkunde van de programmeur! Die wist even niet dat als je een file voor write opent zonder truncate, de oude inhoud blijft staan als je nieuwe inhoud korter is.
Dat is niet iets waar de gebruiker zich mee bezig hoeft te houden.
22-03-2023, 19:55 door Anoniem
Door Anoniem: Het probleem is dat er bij het wegschrijven van het bestand na bewerken geen nieuw bestand gemaakt wordt maar het bestaande bestand wordt "overschreven" met de nieuwe inhoud. Echter men vergeet aan het eind van die schrijf actie een "truncate" systemcall te doen waardoor de size van het bestand ook echt gezet wordt op de hoeveelheid die er nu in geschreven is. Dit moet standaard gebeuren bij ieder programma wat een file "overschrijft" met nieuwe inhoud (geen los record maar een compleet nieuwe file), en wat degene die dit programma gemaakt heeft kennelijk niet gedaan heeft. Of misschien zit het probleem wel in een of andere library.

"vergeten" :-)

Mensen die met operationele security bezig zijn en hier om geven, weten al langer dat je na een obfuscatie steeds opnieuw een screenshot/afdruk moet maken. Deze 2de kan dan nooit de niet geobfusceerde informatie bevatten.
22-03-2023, 21:00 door Anoniem
Door Anoniem: Het probleem is dat er bij het wegschrijven van het bestand na bewerken geen nieuw bestand gemaakt wordt maar het bestaande bestand wordt "overschreven" met de nieuwe inhoud. Echter men vergeet aan het eind van die schrijf actie een "truncate" systemcall te doen waardoor de size van het bestand ook echt gezet wordt op de hoeveelheid die er nu in geschreven is. Dit moet standaard gebeuren bij ieder programma wat een file "overschrijft" met nieuwe inhoud (geen los record maar een compleet nieuwe file), en wat degene die dit programma gemaakt heeft kennelijk niet gedaan heeft. Of misschien zit het probleem wel in een of andere library.
Veronderstel je dit of weet je dit?

Mij lijkt dit heel onwaarschijnlijk. Als je de nieuwe PNG-gegevens naar het begin van het bestand schrijft overschrijf je daarmee een deel van de weggesneden data die nou juist hersteld bleken te kunnen worden en dus helemaal niet overschreven kunnen zijn. Ook is een PNG-bestand gecomprimeerd, en decompressie gaat alleen goed als de voorgaande data klopt en goed gedecomprimeerd is. Als je opeens van een afgeronde afbeelding (het deel dat overschreven is door de gecropte afbeelding) overstapt op de originele PNG dan stap je ergens middenin een stroom te decomprimeren data waarvan het voorgaande niet klopt. Dan is het uitermate onwaarschijnlijk dat dat decomprimeren lukt.

Waarschijnlijker lijkt me dat de crop-informatie op de een of andere manier als metadata aan de afbeelding wordt toegevoegd zonder dat de pixel-data wordt veranderd. Als het zo gedaan is kan door simpelweg die crop-informatie weer te verwijderen de volledige afbeelding hersteld worden.

Exif (een metadata-formaat dat aan allerlei afbeeldingsformaten kan worden toegevoegd) kent de tag DefaultUserCrop. Als die (0,0) tot (1,1) aangeeft (de default) wordt de hele afbeelding geselecteerd, met waarden tussen 0 en 1 kan een deel worden geselecteerd. Ik weet niet of dat is wat hier gebruikt is, maar wat mij waarschijnlijker lijkt lijkt inderdaad te kunnen.
23-03-2023, 06:55 door Anoniem
Als ik het goed begrijp is dit issue min of meer het gevolg van de moderne windows file API. https://twitter.com/sjmurdoch/status/1638623990817103888?s=46&t=_jYL8DdGZRY359hkaqDU_A
23-03-2023, 12:41 door karma4
Door Anoniem: Als ik het goed begrijp is dit issue min of meer het gevolg van de moderne windows file API. https://twitter.com/sjmurdoch/status/1638623990817103888?s=46&t=_jYL8DdGZRY359hkaqDU_A
Dank u, samples en voorbeeldcode kunnen een bron van ernstige codeerfouten zijn. Vaker gezien.
23-03-2023, 12:52 door Anoniem
Door Anoniem:
Door Anoniem:
Het is niet echt een lek, maar vooral onkunde van de gebruiker.
Welnee, het is onkunde van de programmeur! Die wist even niet dat als je een file voor write opent zonder truncate, de oude inhoud blijft staan als je nieuwe inhoud korter is.
Dat is niet iets waar de gebruiker zich mee bezig hoeft te houden.
Het is onkunde dat de gebruiker voor overschrijven kiest, en niet voor opslaan als nieuw bestand en de oude weggooien. En zelfs dan - weggegooide bestanden zijn vaak ook niet eens echt weg. Met speciale recovery software is "weggegooide data" vaak nog wel terug te halen - dat is gewoon hoe veel computersystemen werken.
23-03-2023, 13:58 door Anoniem
Door Anoniem:
Door Anoniem: Het probleem is dat er bij het wegschrijven van het bestand na bewerken geen nieuw bestand gemaakt wordt maar het bestaande bestand wordt "overschreven" met de nieuwe inhoud. Echter men vergeet aan het eind van die schrijf actie een "truncate" systemcall te doen waardoor de size van het bestand ook echt gezet wordt op de hoeveelheid die er nu in geschreven is. Dit moet standaard gebeuren bij ieder programma wat een file "overschrijft" met nieuwe inhoud (geen los record maar een compleet nieuwe file), en wat degene die dit programma gemaakt heeft kennelijk niet gedaan heeft. Of misschien zit het probleem wel in een of andere library.
Veronderstel je dit of weet je dit?
Ik weet dit, want ik heb de bron van dit topic gelezen. Daar staat duidelijk in wat er fout ging (het bovenstaande).
23-03-2023, 14:51 door Anoniem
Door Anoniem:
Veronderstel je dit of weet je dit?

Mij lijkt dit heel onwaarschijnlijk.[...]
Ik lees in de verwijzing van Anoniem 06:55 dat ik ongelijk had. De verwijzing als klikbare URL:
https://twitter.com/sjmurdoch/status/1638623990817103888?s=46&t=_jYL8DdGZRY359hkaqDU_A

@Anoniem 06:55: dank voor de verwijzing, maar ook: sla nou niet over er even een klikbare hyperlink van te maken. Het is echt maar een kleine moeite en de essentie van het world wide web is dat je op hyperlinks kan klikken, dat is het verschil tussen een web en een verzameling losse pagina's.
25-03-2023, 10:00 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem:
Het is niet echt een lek, maar vooral onkunde van de gebruiker.
Welnee, het is onkunde van de programmeur! Die wist even niet dat als je een file voor write opent zonder truncate, de oude inhoud blijft staan als je nieuwe inhoud korter is.
Dat is niet iets waar de gebruiker zich mee bezig hoeft te houden.
Het is onkunde dat de gebruiker voor overschrijven kiest, en niet voor opslaan als nieuw bestand en de oude weggooien. En zelfs dan - weggegooide bestanden zijn vaak ook niet eens echt weg. Met speciale recovery software is "weggegooide data" vaak nog wel terug te halen - dat is gewoon hoe veel computersystemen werken.
Het is nooit de onkunde van een gebruiker! Het ligt altijd aan wat het OS biedt
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.