Uitleg van WMF exploit, verbeterde patch en Nederlandse FAQ
Ondanks de aankondiging van Microsoft dat het volgende week dinsdag met een patch voor het WMF lek in Windows zal komen, lopen nog veel internetgebruikers risico. Voor doorsnee gebruikers is er nu een verbeterde versie van de onofficiele "patch". Dankzij de .MSI installer is het installeren een stuk eenvoudiger en krijgt men geen technische meldingen meer te zien. In sommige netwerken kan het installeren van de update er toe leiden dat werkstations niet meer kunnen printen.
Ondanks het advies van een Microsoft medewerker om te patch niet te gebruiken, raden security experts het wel aan om de onofficiele patch te installeren.
Voor iedereen die precies wil weten hoe de exploit in z'n werk gaat, heeft het Internet Storm Center de volgende PDF en PPT presentaties. Ook is de WMF FAQ betreffende exploits in het Nederlands vertaald, hieronder een aantal vragen:
Als ik besmet raak door de exploitcode, wat kan ik doen?
Niet veel . Het hangt er sterk af door welke exploitcode je besmet bent geraakt. De meeste zullen bijkomende componenten downloaden. Het kan moeilijk, zoniet onmogelijk worden om alles te achterhalen. Microsoft biedt gratis support aan. (nvdr. voor België: 02/503 31 13)
Zal het unregistreren van de DLL (zonder de niet-offiële patch te gebruiken) mij beschermen?
Het kan helpen maar het is niet waterdicht. We willen hier duidelijk zijn: we hebben sterke aanwijzingen dat enkel het unregistreren van shimgvw.dll niet altijd voldoende is. De .dll kan opnieuw geregistreerd worden door kwaadaardige processen of andere installaties. Er kunnen trouwens andere aanvalshoeken gebruikt worden tegen de Escape() functiie in gdi32.dll. Zolang er geen Microsoft patch beschikbaar is raadt het ISC aan om de niet-offiële patch te gebruiken in combinatie met het unregistreren van shimgvw.dll.
Hoe goed zijn antivirusprodukten om de exploitcode tegen te houden?
Op dit moment hebben we weet van versies van de exploitcode die niet gedetecteerd worden door antivirus engines. We hopen dat ze dit vlug kunnen oplossen, maar het zal een harde strijd worden om alle versies van de code te detecteren. Een up-to-date antivirus systeem is noodzakelijk maar waarschijnlijk onvoldoende.
maar de laatste ging niet, omdat ik windows 98 (SE) heb.
Klopt dat; is er een minimum-vereiste van windows2000 bijvoorbeeld ?
2000 wel en op de andere weer niet
Niet dat ik weet.
Werkt de patch van Ilfak Guilfanov onder Win98(SE)?
Nee. Behalve dat de GDI32.DLL anders in elkaar zit onder
Win98, werkt Ilfak's patchmethode niet omdat Win98 geen
"AppInit_DLLs" kent.
Voor info over AppInit_DLLs alsmede hoe de exploit en
Ilfak's patch werken zie mijn bijdrage (tweede van boven) in
http://www.security.nl/article/12609/1/Onofficiele_patch_voor_zeer_ernstig_WMF_lek_in_Windows.html.
NT4, Win98SE en shimgvw.dll?
Bij mijn weten komt shimgvw.dll standaard niet voor op
Win98SE en NT4. Er valt dus niks te de-installeren.
Is NT4 kwetsbaar?
Ja, als je een third-party viewer geinstalleerd hebt zoals
Irfanview.
Is Win98SE kwetsbaar?
Weet ik niet zeker. Waarschijnlijk bevat Win98SE wel
routines voor het uitvoeren van abortproc functionaliteit,
maar het is mij onder Win98SE nog niet gelukt om (via
Irfanview) code in een metafile aan de praat te krijgen.
Bijvoorbeeld de tests van Ilfak en van Heise (ga naar
http://www.heise.de/security/dienste/browsercheck/demos/ie/wmf.shtml
en klik daarin op de "Test" URL) doen niets onder Win98SE.
Hetzelfde geldt voor door mijzelf gemaakte wmf bestanden die
wel code uitvoeren onder XP en NT4 (via Irfanview), maar
niet onder 98.
Daarnaast blijkt Win98SE een stuk kritischer naar sommige
velden in de metafileheader te kijken en weigert "corrupte"
bestanden te openen, terwijl XP zich er in soms niets van
aantrekt (en de exploit code uitvoert). Wel lijken er eerder
crashes in Win98SE GDI te kunnen optreden als er verderop in
de metafile onjuiste gegevens staan.
Maken de huidige exploits gebruik van bufferoverflows of
iets dergelijks?
Nee. De eerste exploits waren voorzien van allerlei truuks
(die o.a. een BO deden vermoeden) waarschijnlijk om
onderzoekers op een dwaalspoor te zetten. De reden dat DEP
op nieuwe AMD processoren werkt is, gok ik, dat de code uit
de file in een geheugengebied (datasegment) staat waarin
geen code mag worden uitgevoerd. Dat geeft meteen aan dat
alle applicaties (printen) die deze "feature" nog gebruiken
zich op een dood spoor bevinden.
Had Microsoft deze 0day kunnen voorkomen?
Als je een willekeurige webpage op microsoft.com opent zul
je zien dat pagina's nooit lang geleden "reviewed" zijn. Ik
ga ervan uit dat ze dit ook met hun sources doen, in elk
geval bij OS releases en bij service packs; daarnaast zijn
er afgelopen jaar al minstens 2 patches geweest voor
metafile issues. Mede door de implementatieverschillen
tussen de Win32 besturingssystemen lijk het me stug dat
Microsoft medewerkers dit risico niet eerder hebben ingezien
(en anders reviewen ze niet hard genoeg).
Is dit de laatste kwetsbaarheid t.g.v. metafiles?
Lijkt me sterk. Lang niet alles van metafiles is door
Microsoft gedocumenteerd, maar de informatie die wel
voor het oprapen ligt doet me vermoeden dat we nog meer
0days gaan zien. En reken maar dat blackhats daar naar op
zoek zijn.
Wat zou Microsoft hier aan moeten doen?
In elk geval moeten MSIE en dus verkenner metafiles niet
meer renderen. Bovendien moet Microsoft ophouden met het
bepalen van bestandstypes op basis van enkele bytes aan het
begin (of soms verderop) in een file. Hou je aan de extensie
en stel evt. een tooltje beschikbaar om handmatig een
bestandstype op basis van inhoud te bepalen. Microsoft's
Jesper Johansson:
http://blogs.technet.com/jesper_johansson/archive/2006/01/02/416762.aspx
It only stops those we know about right now that use WMF
extensions. This works because the system is written to be
smart about file contents. If the file extension says it is
a JPG file, but the content says it is WMF, then clearly
someone must have made a mistake and they really wanted the
file parsed as WMF so it will go ahead and do so.
Unfortunately, we live in a file extension oriented world,
but the components are written assuming that file-extensions
are unreliable.
de gebruikers die deze extensies niet zien doordat Microsoft
ze niet toont. Door deze kortzichtigheid word je eigenlijk
gedwongen om alle plaatjes te blokkeren.
Voor toekomstige bestandstypes is het misschien een goed
idee om een type-GUID op een vaste plaats op te nemen. Ten
slotte moet support voor metafiles snel worden afgebouwd
en/of moet in elk geval in GDI veel strakkere
input-validation worden gerealiseerd. Voor vectorplaatjes
kan wellicht een Javascript-vrije versie van SVG gebruikt
worden.
Erik van Straten
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
