Microsoft dicht vier zerodays op Patch Tuesday, waarvan twee actief misbruikt

Microsoft heeft tijdens de Patch Tuesday-updateronde 89 kwetsbaarheden verholpen. Vier daarvan waren zerodays, waarvan er weer twee in het wild werden uitgebuit. Die laatste twee waren een hash disclosure-bug en een privilege escalation in de Windows Task Scheduler.

Microsoft heeft KB5046633 voor Windows 11 en KB5046613 voor Windows 10 uitgebracht. In totaal heeft het bedrijf 89 bugs gerepareerd. Vier daarvan krijgen een Kritiek-rating. De rest is grotendeels Belangrijk of Gemiddeld. De Kritieke bugs zitten in Kerberos, .NET en Visual Studio, Airlift en VMSwitch.

Volgens Microsoft zijn er signalen dat twee van de kwetsbaarheden in de praktijk worden misbruikt. Dat zijn CVE-2024-43451 en CVE-2025-49039. De eerste is een disclosure spoofing-bug waarmee aanvallers via een geïnfecteerd bestand de NTLM v2-hash uit Windows kunnen achterhalen. Daarmee kan een aanvaller zich makkelijk voordoen als het slachtoffer. De tweede kwetsbaarheid is een privilege escalation-bug in de Windows Task Scheduler. Daarmee kunnen aanvallers hun rechten naar Medium verhogen op een systeem als zij een applicatie op een systeem kunnen zetten.

Er zitten nog twee andere zerodays in de Patch Tuesday-update: CVE-2024-49040 en CVE-2024-49019. Die zitten in Exchange Server en Active Directory en maken het respectievelijk mogelijk om het e-mailadres van een slachtoffer te spoofen aan lokale gebruikers en om adminrechten te krijgen in een AD-omgeving via de certificaatconfiguratie. Van de eerste twee zerodays zegt Microsoft dat het 'exploitatie heeft gedetecteerd', bij de andere twee niet. Zoals gewoonlijk geeft het bedrijf daarover geen verdere details.

Door Tijs Hofmans

Nieuwscoördinator

13-11-2024 • 14:41

27

Submitter: Anonymoussaurus

Lees meer

Reacties (27)

27
27
16
0
0
10
Wijzig sortering
die .net bug zit dus in alle programma's die gecompiled zijn met die kwetsbare versie ook... hoe controleer je dit dan... :-/
Is er wel een .net security update ?

https://devblogs.microsof...r-2024-servicing-updates/

Note: There are no new security improvements for .NET 8.0, .NET 6.0, or .NET Framework this release.

En 2e bron :

https://github.com/dotnet...otes/8.0/8.0.11/8.0.11.md

'This update contains non-security changes'

edit: ok voor de meeste mensen niet van toepassing dus :

https://github.com/dotnet...ories/GHSA-v7vf-f5q6-m899

Any .NET 9.0 application running on .NET 9.0.0.RC.2 or earlier.

[Reactie gewijzigd door DDX op 13 november 2024 15:55]

Ze zijn blijkbaar zelf het spoor ook een beetje kwijt want een stukje lager in het artikel van link 1 staat
.NET Framework November 2024 Updates
This month, there are security and non-security updates in these releases, be sure to browse our release notes for .NET Framework for more details.
Edit:Dat is het klassieke Framework, niet goed gelezen dus

[Reactie gewijzigd door robvh99 op 13 november 2024 17:25]

Maar dat spreekt het stukje weer tegen wat ik quote want daar zeggen ze dat er geen .NET Framework security improvements zijn.
Dus ja ze zijn echt het spoor kwijt.

Of is een security improvement wat anders dan een security update ? (schijnbaar wel)

[Reactie gewijzigd door DDX op 13 november 2024 17:29]

Daar zijn tools voor waarmee je in een .NET Compiled executable kunt kijken.

- dotPeek
- ILSpy

Dan kan je precies zien met welke .NET versie de software is gecompileerd.

Bij dotPeek ziet dat er zo uit als op dit plaatje: https://i.sstatic.net/TBsLt.png

Daar zie je in dat voorbeeld dat hij dus compiled is met .NET Framework 4.7, specifiek build 4.0.30319.

[Reactie gewijzigd door wildhagen op 13 november 2024 18:15]

Je plaatje doet het niet:

Error 1011 Ray ID: 8e2064e70923b383 • 2024-11-13 17:13:44 UTC
Access denied
What happened?
The owner of this website (i.sstatic.net) does not allow hotlinking to that resource (/TBsLt.png).
Alleen programma's die het .NET Remoting Binary Format gebruiken zijn daarvoor kwetsbaar. Dat zijn er maar heel weinig. Standaard is die functie niet ingeschakeld en de functie is alleen kwetsbaar bij een versie die expliciet als "experimenteel" is gemarkeerd. Ik denk niet dat dit een probleem zal zijn voor veel mensen, dit zal eerder iets zijn voor web devs die .NET backends gebruiken.
Dank voor de toelichting. Maar om uw netwerk hier op te scannen zal het dus niet evident zijn..
Nee, hier kun je als eindgebruiker/beheerder weinig mee met standaardtools.

Je kunt tooling maken die voor iedere .exe controleert of die .NET 9 gebruikt en, zo ja, of die of diens dependencies de kwetsbare library gebruiken. Dan blijft het de vraag of je liever de software tijdelijk laat draaien in afwachting van een patch vanaf de leverancier of dat de software optioneel genoeg is dat je het direct kunt uitschakelen.
89 kwetsbaarheden, waarvan 4 zerodays, waarvan 2 gebruikt. Wat is het verschil tussen zerodays en andere kwetsbaarheden?
Een zero-day is een kwetsbaarheid waarvan niet bekend was dat hij bestond. Na het bekend maken van de kwetsbaarheid is het een 1 / x-day en heeft het (vaak) al een CVE-nummer.
Bor Coördinator Frontpage Admins / FP Powermod @Alex313 november 2024 16:12
Op hoofdlijn (maar de exacte definitie verschilt per partij soms enigszins)

Een 'zero-day'-kwetsbaarheid is een softwarekwetsbaarheid die eerder door hackers is ontdekt dan door de leverancier. Aangezien leveranciers het niet in de gaten hebben, bestaat er nog geen patch voor de 'zero-day'-kwetsbaarheden, waardoor de kans groot is dat aanvallen slagen.
AuteurTijsZonderH Nieuwscoördinator @Alex313 november 2024 16:38
De meestgebruikte definitie, en die ook wij hanteren, is dat een zeroday een kwetsbaarheid is waarvan de informatie al (semi)openbaar bekend is. In veel gevallen zie je dat tijdens een aanval, maar je kunt ook denken aan informatie die ergens op een blogpost is gezet.

Daarom maken wij ook het onderscheid als we hierover schrijven tussen 'zerodays' en 'actief misbruikte zerodays'. Soms hoor ik wel eens dat dat een pleonasme is, maar die twee dingen kunnen los van elkaar bestaan.
Bij de vorige “Patch Tuesday”1 PC W11 en 1 PC W10 na update no boot. Gevolg 1x herstel USB en 1x boot “CMD repair” benodigd. Ik ben wat voorzichtiger met MS-updates ook na de berichten over W11-24H2! Deze keer vragen de updates geduld bij de installatie.
Het is een dilemma. Ik zou het zelf gooien op beveiligingsupdates zo snel mogelijk installeren en goede back-ups paraat hebben.
Dat hangt van de organisatie (doelwit?), de bezetting op de IT-afdeling (leuk 150 pc's herstellen met 2 man), en de mate van kwetsbaarheid af (hoeveel exposure heb je richting internet, maak je gebruik van de aangedane diensten).

Persoonlijk wacht ik wel een weekje tot de grote jongens weer nat zijn gegaan.
Het lijkt een wat kwetsbaarder proces geworden de laatste maanden. Hier bijna alle systemen succesvol, op één na die gewoon echt niet wil en maar BSOD's blijft geven. Gevalletje oude drivers (touchpad) en nu gaat het wel goed.
Ik had exact hetzelfde met deze patch.
En onder Windows 10 22H2 wederom gezeik met update KB5048239 en loopt vast vanwege foutmelding 0x80070643.

Die foutmelding was al bekend van een eerdere update zoals KB5034441 waarbij de herstelpartitie niet groot genoeg zou zijn, nu is deze inmiddels 1x verhoogt naar 782MB en nu is het binnen hetzelfde jaar dus al 2x voorgekomen dat dit opnieuw gebeurt.

Ik ga niet weer telkens die herstelpartitie vergroten, dat slaat nergens op.

Avast! Cleanup (de software updater binnen Avast! Antivirus) kan deze updates wel geforceerd installeren met succes nadat je de hoofdzakelijke updates hebt geïnstalleerd en herstart hebt, het is voor mij nu een workaround maar wat irritant zeg.

Blijkt maar weer dat de testers ontslagen zijn.
Toch wel vreemd dat een herstelpartitie niet groot genoeg is. Probeert die update een nieuwe recovery image te schrijven dan ofzo? Met de oude data nog in plaats? Dan kan ik me voorstellen dat ~800MB niet voldoende zal zijn ja.

En komt dit ook voor bij installaties zonder herstelpartitie?
Zonder geen idee, standaard was de partitie zo'n 500MB bij verse installaties, maar dat bleek begin dit jaar niet groot genoeg voor de update KB5034441 en Microsoft beloofde een fix en die is uiteindelijk nooit gekomen.

En nu blijkt het een terug kerend probleem eens in de zoveel tijd, dat zou niet mogen.
Wellicht dat Windows Update het na een herstart na het installeren van de andere updates het wel accepteert als de fix al een keer is doorgevoerd maar dat was bij mij niet het geval zover ik weet.

Maar ronduit irritant.
Hier ook 30 tal (misschien meer) handmatig moeten bijwerken,
maar wel met alle aanpassingen meteen voor een 1gb+ partitie gegaan.

Omdat bij sommigen een 750mb al te klein was en de fout gaf, andere waren 512mb,
maar allemaal gelijk naar de 1gb gezet (+256 of +512 resp.)
En daarna gelukkig niet meer terug gezien.
Even offtopic en uit nieuwsgierigheid; wat staat er dan op die recovery partitie? Ik ken dat alleen uit de XP/Vista tijd, waar fabrikanten drivers e.d opsloegen zodat je bij een herinstallatie/herstelactie niet met een berg onbruikbare hardware zat. Daarna ben ik dat niet meer tegengekomen, want drivers via internet, en ik ben met Windows gestopt grotendeels ook.
Het wordt hiervoor gebruikt zover bij mij bekend:
https://learn.microsoft.c...reference?view=windows-11

Het heet eigenlijk ook de WinRE partitie, ofwel de Windows Recovery Environment.
CVE-2025-49039

Die is er mooi vroeg bij
Gelukig hier (W10) nooit problemen mee gehad.
Ik baal alleen dat ik weer eerst moet aanmelden op woensdagochtend steeds... ;)
KB5046633 zorgde bij mijn accountant voor een zwart scherm nadat ie had ingelogd. Alleen de taakmanager werkte en kon ik met wusa /uninstall /kb:5046633 deze update weer verwijderen - dat werkte.

Op dit item kan niet meer gereageerd worden.