Proof-of-concept voor gepatchte ernstige kwetsbaarheid in Word verschijnt online

Een beveiligingsonderzoeker heeft een proof-of-concept online gezet van een remote code execution-bug in Microsoft Word. Die is inmiddels gepatcht. Aanvallers konden het lek misbruiken om schade aan te richten.

De beveiligingsonderzoeker die de kwetsbaarheid vorig jaar vond, heeft daar nu een werkende exploit van online gezet. Die past volledig in een tweet. De onderzoeker zegt dat het met dat stuk code mogelijk is een heap corruption te veroorzaken door een groot aantal fonts in te laden. De bug zit in de RTF-parser van Microsoft Word, wwlib.dll.

Volgens Joshua Drake kunnen aanvallers de bug op afstand uitbuiten door een geïnfecteerd .RTF-document naar een slachtoffer te sturen. Daarbij hoeft de ontvanger het bericht niet eens zelf te openen; de bug wordt al getriggerd als Word het document als preview opent. Als de software vervolgens een font-table inlaadt met daarin een grote hoeveelheid fonts, ontstaat er een memory corruption. Het is dan mogelijk om code uit te voeren op een machine met dezelfde rechten als de ontvanger. Als dat een admin is, kan er daarom veel schade aan het systeem ontstaan. De code die nodig is om die corruption te veroorzaken is maar klein. Sinds Drake de bug heeft aangedragen heeft hij die nog kleiner weten te maken.

Drake heeft de bug aan Microsoft doorgegeven in november. Het bedrijf heeft de kwetsbaarheid, die code CVE-2023-21716 meekrijgt, gerepareerd tijdens de Patch Tuesday van februari. De proof-of-concept is daarmee niet van toepassing op systemen die al gepatcht zijn, maar aanvallers kunnen die wel misbruiken op niet-gepatchte systemen. Het gaat om een ernstige kwetsbaarheid, die een CVSS-score van 9.8 krijgt. Dat komt met name door hoe ernstig de potentiële schade is en hoe makkelijk het is de bug potentieel uit te buiten.

Drake toont alleen dat dat hij via de kwetsbaarheid inderdaad een overflow kan veroorzaken, maar in de proof-of-concept voert hij geen daadwerkelijke code uit. Daarom is niet duidelijk of de proof-of-concept direct tot een exploit kan leiden.

Reacties (42)

[Dracula]

Ik snap niet zo goed waarom je dit zou publiceren? Waarom mensen hun systemen “in gevaar” brengen.

Dat hackers dit doen ok maar een beveiligsonderzoeker?

[kuurtjes]

Security by obscurity is niet goed

[chaozz]

Ik kan wel wat redenen bedenken. Ten eerste toon je hiermee de absolute essentie aan om de software die je gebruikt up-to-date te houden. Ten tweede heb ik liever dat een whitehat het publiceert, dan dat een blackhat het stilletjes misbruikt. Immers, als de onderzoeker deze bug kan vinden, dan kunnen criminelen dat ook.

[feuniks]

Hoewel ik het belang van patches onderken, is dat niet altijd mogelijk of wenselijk. Een gemiddeld computerlandschap is helaas erg ingewikkeld en een patch kan ook dat landschap volledig plat leggen. Dat kan, doordat de patch niet goed blijkt te zijn. Dat hebben we al meerdere keren gezien. Zie bijvoorbeeld de patches aan Windows die tot een blue screen leiden. Het kan ook zijn dat de patch iets breekt aan andere software. We hebben meerdere malen gezien dat een fabrikant de gemakkelijke route neemt bij patchen en bepaalde functionaliteit afsluit. Dat is heel vervelend als andere software juist van die functionaliteit gebruikt maakt voor zijn werking.
Beide mogelijke bijwerkingen zorgen ervoor dat je in een gecontroleerde omgeving heel graag eerst wil testen of de systemen en de meest kritische processen nog blijven draaien na de patch. Zo niet, dan mag iemand hoog in de boom een keuze maken: ofwel nu plat, door de patch, ofwel misschien later, omdat het lek wordt misbruikt door iemand. En dat kan wel eens heel vervelend en duur zijn. Welke keuze er ook gemaakt wordt...

[bwerg]

Op zich heb je helemaal gelijk hoor, maar het is allemaal niet echt van toepassing omdat MS in dit geval drie maanden heeft genomen om dit te patchen, en de onderzoeker heeft ze die tijd ook gegeven.

Geen haast, wel urgentie, responsible disclosure en pas na de fix publiceren. Dit lijkt me prima gegaan.

[dasiro]

2 weken na de fix is wel kort op de bal, veel sysadmins hebben uit het verleden de praktijk er op nagehouden om 1 patchronde af te wachten. Wat het ergste is (direct patchen of afwachten) laat ik in het midden

[GekkePrutser]

Dan hebben die zich er zelf mee. Twee weken is zat tijd om te testen. Als er echt een grote bug in zit dan was die allang groot in het nieuws gekomen.

Vergeet ook niet dat zodra de patch uit is, een heel leger malwareonderzoekers gaat zitten snuffelen in wat er precies veranderd is. Het is een kwestie van dagen voor een slimmerd dit uitvogelt. Dan is het wel degelijk zinvol om het snel in het nieuws te brengen zodat die sysadmins weten dat er dit keer echt een serieuze RCE in zit.

PS: Ik ben zelf ook heel lang endpoint architect geweest en ik liet patches ook een paar dagen 'in het veld' rondhuppelen voor ik zelf de trekker overhaalde. Maar een hele maand (tot de volgende ronde) afwachten is gewoon veel te lang in deze tijden.

[dasiro]

niet alle bedrijven hebben de luxe om zelf te testen.

[K4F]

Als een bedrijf iets niet kan (laten) testen dan is het schijnbaar niet belangrijk. Alle gevallen waar dat wel zo is pure nalatigheid in deze tijd.

[dasiro]

Zo zijn er (jammer genoeg) veel meer dan je denkt.

[GekkePrutser]

Als je dat niet hebt dan heb je ook niet de hele instrumentatie om patches te beheren natuurlijk. Dan ga je gewoon mee met de publieke patch kanalen.

[dasiro]

een wsus-server is nog altijd een gratis rol die in windows server zit, die ooit kan opgezet zijn geweest bvb bij de opzet van een domein. Om verschillende redenen kan die met weinig beheer jarenlang zijn ding doen. Slechte patchen kunnen zelfs de reden geweest zijn om juist van de publieke kanalen af te stappen.

[feuniks]

Dan hebben die zich er zelf mee. Twee weken is zat tijd om te testen. Als er echt een grote bug in zit dan was die allang groot in het nieuws gekomen.

En daar zit het gevaar. Als door de patch Word ineens geen vriendjes meer is met een voor het bedrijf geschreven stukje software, dan zul je daar geen nieuws over vinden. Niemand anders gebruikt dit stuk software immers. En het kan diep in de applicatie zitten, zodat het op het eerste gezicht niet opvalt en het kan zijn dat deze maatwerksoftware gewoonweg bedrijf kritisch. Ik ken gewoon een zooitje bedrijven met een toch wat ouder applicatielandschap.

[Rob Coops]

Sorry maar kritieke systemen die word bestanden openen in MS Word... dat is toch wat ver gezocht of een zeer ongezonde omgeving.

Nu snap ik heel goed dat je een patch eerst even wil testen om zeker te weten dat de patch geen problemen veroorzaakt zo als je zelf al aangeeft dat is helaas niet geheel uit te sluiten zonder dat zelf te testen want zo iets simpels als een andere regio en dus een andere taal kunnen al voor problemen zorgen die niemand opmerkt als ze die specifieke regio en taal niet gebruiken.

Maar als de patch eenmaal al een paar maanden beschikbaar is en je dan nog aan het miepen bent dat het onverantwoordelijk is om de proof of concept vrij te geven dan klopt er iets niet. Een hacker die graag wil weten wat die bug nou precies deed hoef immers alleen de patch maar te bekijken om uit te vogelen wat de patch aanpast om te zien waar het probleem zich bevind. Dan is het een kwestie van proberen en zien wat het resultaat is op een ongepatched systeem en hop je het misschien niet een perfect geoptimaliseerde versie van de hack maar zeker een werkbare versie.

Dus waarom dan toch die code vrijgeven een whitehat hacker kan toch ook die patch bekijken? Ja natuurlijk maar die heeft daar weinig aan, immers er is geen eer te behalen aan het uitvogelen van het geen de patch nu precies aangepast en hoe je dat kan gebruiken om een systeem te hacken dus waarom de tijd er aan besteden.
Maar het is wel nuttig om te zien wat er nu precies gevonden was zodat je daar van kunt leren en misschien op een idee kunt komen om een ander stuk software eens op een soort gelijke manier te belagen.

[Z80]

Een systeem dat vastloopt zal het probleem niet zijn.
Een paar honderd systemen die op de maandagochtend een blauw scherm tonen maakt het wel ineens problematisch. Dan ligt alles gewoon langere tijd plat. Zeker als er eerst uitgezocht moet worden welke update de oorzaak is. En als je pech hebt moet elk systeem opnieuw geïnstalleerd worden.
En deze patch is ongeveer een maand uit. Had nog een maand langer gewacht. Dan waren veel meer systemen up to date.

[gerwim]

Je impliceert hiermee dat deze bug niet geexploit wordt wanneer deze man zijn proof of concept niet gepost had. Dat is niet waar, wanneer Microsoft patches uitbrengt zijn er tal van bedrijven die gaan uitzoeken wat er precies gepatched is hiervoor juist exploits gaan ontwikkelen.

Naar mijn inzien is het delen de juiste keuze. Je kunt eventueel deze losse fix installeren (zonder de hele CU patch te installeren).

[gamezfreak]

Immers, als de onderzoeker deze bug kan vinden, dan kunnen criminelen dat ook.

Het kan ook zijn dat deze bug al bekend was onder de hackers, maar dat de kwetsbaarheid nu door een onderzoeker is gevonden.
En ja, het is zeker belangrijk om je software up-to-date te houden, want anders loop je de risico dat je, zoals bij de LastPass hack, dat er via een andere software toegang tot jouw machine / gegevens is.

Daarnaast is het ook kwestie van kritisch kijken voordat je iets opent, want de bijlages zijn juist het gevaarlijkste. Als je het niet vertrouwd, open het simpelweg niet.
Of stuur het door naar een emailadres die je alleen voor spam mails gebruikt en open die mail op een Faraday achtige omgeving, als je nieuwsgierig bent wat er gebeurt.

(Buffer) overflows is een manier om alles wat in het geheugen staat, in te kunnen zien. Spectre is hiervan een voorbeeld.

[Dracula]

Ehm maar deze onderzoeker is dezelfde onderzoeker die de bug heeft gevonden dus waarom dan ook een exploit publiceren? Hij heeft tenslotte de bug al gevonden en gemeld.

Daarnaast zijn er zat bedrijven die niet binnen twee weken alles gepatched hebben dus is het we heel kort dag om na twee weken deze exploit te publiseren.

[Zoop]

Wat @chaozz ook zegt, dat een whitehat dit nu publiceert wilt niet betekenen dat het niet al veel langer misbruikt wordt door blackhats. Ga er maar vanuit dat je mensen alleen maar "in gevaar" brengt door het niet te publiceren.

[dasiro]

elke scriptkiddie die dit leest gaat het nu ook proberen, net omdat het zo simpel is en meer domme dingen doen dan dat het enkel in blackhat communities rond ging/gaat.

[GekkePrutser]

Maar een scriptkiddie haalt daar niet zoveel mee uit. Die heeft te weinig kennis om zoiets echt uit te buiten. Want daar komt veel meer bij kijken dan alleen de initiele infiltratie, wat deze exploit verzorgt. Een succesvolle hackcampagne zal zich als het binnen is eerst vastleggen (persistence), verkennen naar andere systemen, het zoeken naar autorisatiepaden (privilege escalation), het vinden van waardevolle informatie en het exfiltreren daarvan, alles terwijl men onder de radar blijft van EDR of op zijn minst antivirus. Of men zoekt naar een escalatiepad richting een AD admin en distribueert vanaf daar ransomware naar het hele bedrijf. Dat soort dingen vereisen veel kennis, vooral om onder de radar te blijven.

Een scriptkiddie doet dat niet, die gooit 1 of 2 servers plat of defacet een website en dan heb je het wel gehad. De grote blackhat groepen zijn een veel groter gevaar.

[Reactie gewijzigd door GekkePrutser op 2 augustus 2024 00:45]

[M3m3nt0m0r1]

Microsoft heeft de kans gehad om het te patchen, wat ze ook gedaan hebben.
Dus nu kan hij het vrij geven.

[Cergorach]

Stel je voor dat beveiligingsonderzoekers over de hele wereld netjes alles stilletjes patchen en je er nooit wat van merkt. Wat krijg je dan te horen? Waarom verdienen beveiligingsonderzoekers zoveel, waarom hebben we überhaupt beveiligingsonderzoekers nodig, er gaat immers nooit wat fout. Want als mensen niets zien, dan bestaat het niet (in hun hoofd).

Dit is een stukje marketing voor beveiligingsonderzoekers en deze beveiligingsonderzoeker specifiek.

Daarnaast zet je ook een stukje druk achter mensen en ITers die nooit (tijdig) de boel updaten.

[Klauwhamer]

Lijkt mij dat de vulnerability disclosure termijn hier zeer redelijk is. Waarom je dit doet? Omdat je als onderzoeker ook domweg credit wil voor je werk. Bovendien is patchen een gedeelde verantwoordelijkheid van eindgebruiker en leverancier, niet van de onderzoeker. Die kan hooguit een (onprettige) incentive afgeven op deze manier.

[bwerg]

Waarom je dit doet? Omdat je als onderzoeker ook domweg credit wil voor je werk.

Dat kun je natuurlijk ook krijgen als het bedrijf in kwestie je werk valideert. Publiceren kan ook zonder werkende exploit beschikbaar te stellen.

[Klauwhamer]

Ik vind het prima dat hij een PoC aanlevert, zeker gezien de tijd die hij gewacht heeft. Bovendien moet je vooral niet de illusie hebben dat alleen hij dit kan of weet te vinden. Uiteindelijk heeft een PoC niet meer negatieve gevolgen dan er nu zijn.

[PolarBear]

Hij heeft toch credit voor zijn werk:

https://msrc.microsoft.co...23-21716#acknowledgements

Joshua J. Drake
Microsoft recognizes the efforts of those in the security community who help us protect customers through coordinated vulnerability disclosure.

En daarnaast heeft Microsoft een Bug Bounty programma dus levert het ook nog wat knaken op (dit zou zomaar 20.000 dollar of meer kunnen opleveren).

[mcDavid]

Wat voor "gevaar" zie je dan voor je? De patch is inmiddels al verspreid. Dat betekent dat:

1. deze exploit in principe niet meer misbruikt kan worden (mits mensen hun eigen verantwoordelijkheid genomen hebben natuurlijk)
2. het criminele circuit ook al op de hoogte is van de ins en outs van de exploit, en die gaan echt niet op een POC zitten wachten tot ze daarmee aan de slag gaan...

Tegelijkertijd kan een POC dienen om een hoop mensen te waarschuwen en op te voeden, en biedt het inzicht in mogelijke attack surfaces zodat ook andere software zich wapenen tegen soortgelijke exploits.

[Reactie gewijzigd door mcDavid op 22 juli 2024 13:44]

[Soldaatje]

"Hackers" kunnen nu deze exploit toevoegen aan hun toolkit, ja, maar systemadmins kunnen nu ook extra maatregelen nemen zoals het scannen van deze code in rtf bestanden in emails. Het mes snijdt aan twee kanten.

[Zebby]

Het defect is in november gemeld bij Microsoft. Door het zo te doen forceer je hun hand ook, van "joh dit duurt te lang, kijk eens, nou kan iedereen het".

[Hatseflats]

Zo moet je wel upgraden. Ondanks eventuele invloeden.

Je kan het nog steeds niet doen, met alle gevolgen van dien.

[lenwar]

Het basisidee daar achter is transparantie (disclosure). Door zaken te publiceren forceer je openheid.
Alleen op deze manier kan er een vorm van vertrouwen worden gecreëerd. Veel afleggen van veiligheid zijn op vertrouwen gebaseerd. Zo ook dit.
Bekijk zelf. Waar heb jij met vertrouwen in, in een changelog waar de generaal verbeterd is (general improvements) of waar er daadwerkelijk functionele zaken benoemd zijn.

Als ik puur naar mezelf kijk en ik in een changelog bij de afgelopen 20 patches alleen maar. “We work continuously on improving our software. This release fixes bugs and increases stability” dan kan ik dat bedrijf eigenlijk al niet serieus nemen hierin.

[MiesvanderLippe]

Als dat een admin is, kan er daarom veel schade aan het systeem ontstaan.

Tsja, in een ideale wereld zou het zo zijn. In de realiteit zit user en domain admin een handjevol trucs uit elkaar.

[batjes]

In de realiteit zit dit helemaal niet zo vaak uit elkaar.

[RoestVrijStaal]

Is het niet beter om de attack surface te verminderen door support van RTF-documenten te stoppen ten gunste van open standaard formaten zoals OpenDocument- en Office Open XML-documenten?

Zelfs de "hoofdgebruiker" WordPad ondersteunt tegenwoordig OpenDocument- en Office Open XML-documenten, dus wat is het probleem?

[xorpd]

RTF is in de praktijk ook een open standaard en simpel van opzet (simpel is goed, weinig kans op bugs). Het probleem zit dan ook niet in RTF, maar in Word. Zo te lezen heeft Wordpad het probleem dan ook niet.

[Verwijderd]

Omdat er een update uitgebracht is ga ik er van uit dat dit probleem zich niet in versie 2007 en 2010 bevinden?
Als dat wel zo is, moet dat dan niet zéér duidelijk gemaakt worden zodat blijven hangers extra duidelijk wordt dat het gewoon niet safe is om Office niet bij te werken naar ondersteunde versies?

[lamello12]

Is deze kwetsbaarheid ook van toepassing in de preview van een (word) document in de Explorer?

[beerse]

Tegenwoordig zijn er een aantal verschillende versies/varianten van msWord in gebruik. Het had mooi geweest als deze in dit artikel zouden worden benoemd:
Om te beginnen is er de msOffice<jaartal> versie van msWord: 2010, 2013, 2016, 2019 of zo iets voor de msWindows gebaseerde systemen.
Voor de Apple Mac zijn daar deels andere versie nummers. Geldt het issue, het uitbreken uit msWord daar ook?
En tegenwoordig is er Office365. Dat is voor zover ik er zicht op heb een iets andere code-base. Maar voor lokaal geïnstalleerde systemen zou het in deze toch de zelfde code en dus de zelfde issues hebben. Mijn eerste gedachte hier zegt dat de online-varianten van office365 hier geen probleem zijn.

En dan nog het document formaat: bestand.rtf. Voor zover ik het mij herinner is dat formaat ooit als het kleine broertje van document.doc gebruikt, in de applicatie 'wordpad'. Of heb ik dat mis? Als het om wordpad gaat, dan denk ik dat die helemaal met msWindows mee komt. Daarmee zou deze library in een bepaalde versie onderdeel zijn van msWindows (denk: 2000, xp en zo, dus mogelijk ook antiek). Hoe zit dat?

[xorpd]

Wordpad gebruikt(e) inderdaad standaard het RTF formaat. Bij mijn weten is Wordpad niet meer dan een wrapper om de Rich Text Edit Control, en gebruikt dus die library niet.