Microsoft dicht eenvoudig te misbruiken kwetsbaarheid in Outlook

Microsoft heeft in zijn Patch Tuesday-update van juni onder meer een kritieke kwetsbaarheid in Outlook gedicht. De remotecode-executionfout kan misbruikt worden zonder dat hier interactie van een gebruiker voor nodig is.

De kwetsbaarheid in kwestie, gevolgd als CVE-2024-30103, werd ontdekt door onderzoekers van beveiligingsbedrijf Morphisec. Via de fout kunnen aanvallers eigen code uitvoeren op getroffen systemen, wat kan leiden tot datalekken, ongeautoriseerde toegang tot systemen en andere malafide praktijken. De code kan uitgevoerd worden met dezelfde privileges als de getroffen gebruiker heeft, wat volgens de onderzoekers er mogelijk toe kan leiden dat het gehele systeem overgenomen wordt.

Aanvallers kunnen de fout misbruiken door een malafide e-mail te versturen. Volgens de onderzoekers is de kwetsbaarheid extra gevaarlijk omdat er geen interactie van gebruikers nodig is voor misbruik. Het openen van de malafide e-mail is al voldoende. "Dit is met name gevaarlijk voor accounts die de auto-openfunctie van Microsoft Outlook gebruiken", aldus de onderzoekers. "Dit gebrek aan vereiste gebruikersinteractie, gecombineerd met de ongecompliceerde aard van de exploit, vergroot de kans dat kwaadwillenden deze kwetsbaarheid zullen misbruiken voor initiële toegang." De onderzoekers raden aan om de door Microsoft vrijgegeven patch zo snel mogelijk te installeren.

Microsoft heeft met zijn Patch Tuesday-update van juni 51 kwetsbaarheden gedicht, waarvan er één als kritiek wordt gezien. De rest, waaronder CVE-2024-30103, wordt aangemerkt als belangrijk. De volledige lijst met gedichte kwetsbaarheden is te vinden op de website van Microsoft.

Door Eveline Meijer

Nieuwsredacteur

14-06-2024 • 14:17

32

Submitter: marcop82

Reacties (32)

32
32
19
0
0
5
Wijzig sortering
Waarom hebben we nog steeds software die code uitvoert die van extern komt? Dat is bij definitie vragen om problemen.
Je stuurt data over, verder niets. De verwerking van de data is aan de ontvangende applicatie. Die voer je niet uit, die verwerk je. Dan hou je alleen nog issues met data validatie over of gebrek daar aan.
Het gaat hierbij vaak om een stukje code dat aan een instructie wordt toegevoegd, omdat de input niet volledig (lees onjuist) wordt gevalideerd door een stukje code in Outlook. Hierdoor lukt het een aanvaller om een stukje code achter een bestaande instructie te plakken, waardoor de machine het alsnog uitvoert. Dit heet ook wel een exploit.

[Reactie gewijzigd door RiCkY82 op 22 juli 2024 17:25]

Wat bedoel je met een instructie? Als een e-mail instructies bevat die Outlook uitvoert is het om te beginnen al niet veilig. Input validatie op e-mail is zeker nuttig, maar het uberhaupt uitvoeren van zaken die in e-mails staan staat al haaks op een secure design waar je ervanuitgaat dat wat je binnenkrijgt niet uitgevoerd gaat worden. Als dat het uitgangspunt is dan is het gebruik van C#, Java, Rust of Go al voldoende om deze hele klasse van bugs te omzeilen. Echter: MS is hier verwijtbaar laks door te blijven knutselen aan een oude code-base.
Wat bedoel je met een instructie?
Een instructie kan een stukje CSS of HTML maar ook plaintext zijn dat iets in de basis onschuldigs doet, zoals tekstopmaak of leestekens. Een karakter-encodingfout in die instructie kan al genoeg zijn om een lib iets anders te laten doen dan waar het voor is bedoeld.

Zowel de body als de headers zijn code die wordt uitgevoerd, ook als je tekst zonder opmaak en bijlagen stuurt. Het gaat altijd door functies heen.
CSS of HTML zijn data elementen en geen instructie. Een instructie is iets wat je voert aan een CPU die er iets mee doet. Plaintext is per definitie geen instructie. Als we inderdaad alles instructie gaan noemen en aan de CPU voeren dan hebben we inderdaad een heel groot probleem.

Maar eigenlijk snap je het wel als je schrijft: "het gaat altijd door een functie heen": door functies gaat data (vroeger bij wiskunde al). De operatie (+, - etc.) zitten in de functie en je substitueert hier data in. Op het moment dat je data als instructie gaat zien heb je een heel blik wormen te pakken, zoals hier ook weer blijkt.
Echter...... Als de functie die de data uit leest kwetsbaar is dan wordt de data de functie...... Zoals al eerder gemeld, vergelijkbaar met sql injectie.
CSS, HTML, fonts en charsets geven aan hoe iets moet worden weergegeven en volgens welke structuur. Het stuurt de interpreterende functie aan. Dat maakt het per definitie een instructie.
Ken je de iMessage-crash nog op de iPhone? nieuws: Sms-bericht met bepaalde tekst kan Messages-app iOS laten vastlopen -...

In de Unicode-verwerking van de Messages app zat een bug waardoor je de app kon laten crashen als instructies op een bepaalde manier werden verwerkt.

Dat is hetzelfde idee bij dit. Iemand stuurt je een mailtje met een bepaald stukje tekst, en je CPU gaat dat op een bepaalde manier interpreteren. Als de code die de stukjes tekst in de email verkeerd interpreteert kan je iets creeeren waardoor je eigen code in het stukje tekst verwerkt kan worden, en deze dan verwerkt wordt door je CPU, waardoor de aanvaller toegang krijgt tot jouw PC of gegevens.

[Reactie gewijzigd door MrFax op 22 juli 2024 17:25]

Het equivalent van remote sql injection zoals jij het bschrijft. En waarom zou j instructies van remote accepteren?
SQL injection is al jaren gefixed, waarom code injection niet?
Code injection is al zo oud als dat gebruikers eigen data kunnen inladen in een app. Er is alleen geen magische oplossing om het te voorkomen. Er gebeurt al enorm veel validatie om dit te voorkomgen, maar er blijven altijd mogelijkheden die men niet voorzien heeft. 1 onvoorzichtigheid in het aanpassen van code kan voldoende zijn om bijv. een buffer overflow te creeeren of om uit je gevangenis uit te breken waar je inzit.
Geen magische oplossing nee, maar wel oplossingen. Misschien is het mijn interpretatie van remote code execution. Maar data en wat uitgevoerd word zouden altijd twee gescheiden dingen moeten zijn.
Klinkt mij als iets van mensen die nog steeds met c en c++ en zo kloten die talen laten zo makkelijk problemen toe dat ze verboden zouden moeten zijn.
Ja er zijn performance voordelen, maar iets als rust zou al een hele verbetering zijn.
"Maar data en wat uitgevoerd word zouden altijd twee gescheiden dingen moeten zijn"

Dat is het in principe nooit zodra je iets met die data wil doen. En ja, de hele wereld draait praktisch nog op C en C++. Zelfs al gebruik je een hogere level taal zoals C# of Python, dan zijn de libraries die door het framework van die talen gebruikt wordt alsnog in C of C++.

Het is onbegonnen werk om alle C en C++ code te herschrijven.
Laat het a.u.b. zo, C en C++ zijn talen die zo onwijs goed zijn bedacht en ontwikkeld. Ik vind ze erg fijn en zou er wil er niet willen mee stoppen te schrijven.
Je kan er bijna letterlijk alle apparaten op de wereld mee programmeren.
Er is alleen geen magische oplossing om het te voorkomen.
Een taal als Rust komt toch een heel eind..
*kuch* These are not the bugs you're looking for... *kuch*
https://threatprotect.qua...batbadbut-cve-2024-24576/

Nogmaals, er is geen magische oplossing. Is het niet de software, is het de data, is het de gebruiker, is het de hardware, is het een externe invloed... Het zijn niet voor niets bugs die worden opgelost.
Nog los van wat je als code ziet, word er natuurlijk altijd wel data 'verwerkt'. Of dit dan om HTML, CSS, of een .png plaatje gaat. En met de enorme wildgroei aan gesupporte formats kan een buffer overflow in een klein hoekje zitten. Je verstopt dan je code in een ander stukje data wat om de een of andere manier fout verwerkt word waardoor jou code terecht komt in een stuk geheugen wat later uitgevoerd word. Wikipedia: Buffer overflow
Buffer overflow. Nog zo eentje waar we jaren tal van talen en mechanismes voor hebben om ze te voorkomen. Niets is perfect, maar toch.
Wij wel, maar MS niet: dat is een andere afdeling die C# en .Net maakt....
Remote code executie als 'issue' zal altijd blijven bestaan; het gaat hierbij niet om het binnenhalen van te executeren code, maar door gebruik (misbruik) te maken van bv code voor interpretatie voor het geven van onbedoelde opdrachten.
Gooien ze die twee op 1 hoop? voor mij is er een heel verschil tussen remote code exeecution/injection en het "creatief" gebruik van een api om iets onbedoelds te laten gebeuren.
Je initiële reactie was "software die code uitvoert die van extern komt". Het leek erop dat je dingen door elkaar haalde. Los daarvan, de exploit zelf moet nog worden gepubliceerd, dus vooralsnog speculatie wat er exact aan de hand is.
Veel van dit soort bugs zijn buffer overflow fouten. Hierbij wordt een deel geheugen gereserveerd voor data dat je wil uitlezen. Je ontvangt echter teveel data voor dat stuk geheugen. Zodra je dit er dan in gaat stoppen komt een deel van de data in een onverwacht deel geheugen. Door de data naar de ontvanger te sturen herschrijf je een deel geheugen wat dan wordt uitgevoerd.

Dit heeft alles te maken met het programmeren in talen waarbij de programmeur totaal verantwoordelijk is voor het geheugenmanagement, denk aan c++. Een fout is hierbij dus snel gemaakt. Even niet de ontvangen data controleren en het gaat al snel fout.

Nu weet ik niet of dat in dit specifieke geval ook zo is. Maar het is dus zeker niet zo dat er altijd spraken is van bewust opdrachten uitvoeren van buiten af.
Dat doet deze website ook en de browser die je gebruikt. E-mail gebruikt praktisch hetzelfde als een browser.

En daarbij zal je af en toe tegen security problemen aanlopen. Deels de reden dat Apple o.a. browsers met eigen rendering engines niet toelaat.
Hoe zit het precies met die updates? Wij gebruiken bijv voor de Ms365 apps enterprise channel waarmee je 3 maanden achter loopt. Krijg je deze update dan wel gewoon direct binnen in de 2404 versie?
Met die channels loop je achter op functionele wijzigingen. Zodat je bijv je gebruikers voortijdig kan inlichten over veranderingen in de software.
Security updates op die channels zijn actueel, die krijg je direct.
Wel wat onhandig dat outlook nu al veel genoemd wordt zonder te weten welke bedoeld wordt.
Hier blijkbaar de standalone versie uit office 2016 en 2019 en 365.
Outlook new of hoe ze het ook gaan noemen is een heel ander verhaal....
Lijkt me inderdaad wel handig om gelijk de versienummers in zo'n artikel te plaatsen, maar soms verandert het inzicht daar ook nog wel eens in (een "oh crap, die versie heeft het ook") en dan moeten ze het artikel weer updaten.

Outlook new;; nieuwe ronde, nieuwe kansen! :+
Sowieso bijzonder irritant dat het voorbeeldvenster/leesvenster standaard aanstaat in Outlook. Zeker in een tijd van spam, phishing en virussen. Deze exploit geeft nog maar weer eens een goede reden om dit gewoon standaard uit te zetten.

Maar goed, ze (MS) hadden laatst ook het lumineuze idee om het emailadres weer te geven in de spam folder. Dit is iets wat ze al jaren geleden hadden moeten regelen en niet alleen in de spam folder. Het is nu door allerlei bochten en hoepels wringen om het voor elkaar te krijgen en het veld is leeg wanneer je in dezelfde Exchange groep zit.
Straks wordt het ook nog mogelijk om een afzender zonder hostnaam te blokkeren. Het moet niet veel gekker worden. Dat zou wel echt veel te logisch zijn.
waarom als ik de oude outlock wil waarom start elkekeer weer de nieuwe op |:(
vinkje rechtsbovenaan in je Outlook die aangeeft dat je de nieuwe wenst.
In regedit aanpassen:

Computer\HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Preferences
Naar UseNewOutlook zoeken en die value aanpassen naar 0.

Regedit aanpassingen op eigen risico :)
bekijk ik wel als dit wel werkt _/-\o_

Op dit item kan niet meer gereageerd worden.