Microsoft waarschuwt voor ViewState-misbruik via openbaar vindbare ASP.NET-keys

Microsoft waarschuwt voor aanvallers die malware verspreiden op machines met behulp van openbare ASP.NET-keys. Het bedrijf zegt dat het al zeker 3000 van zulke sleutels heeft gevonden, waarmee aanvallers zogenaamde ViewState-code-injectionaanvallen kunnen uitvoeren.

Microsoft schrijft in een waarschuwingsbericht dat zijn Threat Intelligence-afdeling de eerste dergelijke aanvallen in december vorig jaar ontdekte. Het gaat om aanvallen waarbij aanvallers een functionaliteit in ViewState voor ASP.NET misbruiken door standaardkeys in te zetten.

ViewState maakt het mogelijk voor webformulieren via ASP.NET om persistence te krijgen, bijvoorbeeld om gebruikersinput te onthouden als een pagina ververst. De ViewState-functionaliteit maakt daarbij gebruik van twee keys, de validationKey en de decryptionKey, die ViewState beschermen tegen aanpassingen van buitenaf. Normaal gesproken worden die keys autogegenereerd, maar ze kunnen ook in configuratiebestanden worden geplaatst.

Microsoft waarschuwt er nu voor dat sommige ontwikkelaars keys gebruiken die uit openbare bronnen zoals codedocumentatie of repo's komen. Als een aanvaller zulke sleutels gebruikt, is het mogelijk om de ViewState-functionaliteit te misbruiken. Microsoft wijst erop dat er zeker 3000 van zulke sleutels online staan die in theorie kunnen worden gebruikt voor ViewState-code-injectionaanvallen. In hoeveel gevallen dat daadwerkelijk gebeurt, zegt Microsoft niet.

Volgens Microsoft gebruikten hackers dergelijke openbare keys om in ieder geval één aanval uit te voeren. Daarbij laadden de aanvallers het Godzilla-framework in, inclusief een aantal plug-ins. Godzilla maakt het mogelijk commando's uit te voeren, wat volgens Microsoft werd misbruikt om shellcode in bepaalde processen te injecteren.

Reacties (37)

[bartje]

Ik schrik me daar kapot, bang dat ik mag gaan ploeteren in onze legacy software,.
maar nu blijkt er zit geen bug in de viewstate, maar in de implementatie ervan.

Dat haal je zo even niet uit de titel.

[markvt]

Het kan geen kwaad om je config bestanden erop na te lopen overigens.

[Blokker_1999]

Dat kan zeker geen kwaad, maar het probleem met dit soort problemen is dat, tenzij je weet wie het geimplementeerd heeft en weet waar de keys vandaan komen, je nu best gewoon alle keys opspoort en gaat roteren ipv enkel na te kijken, want de lijst van MS kan onvolledig zijn.

[CaptainCapslock]

Je kan ook je repositories door sonarqube of tricky (gratis, self hosted) heen halen. Die geven altijd waarschuwingen bij keys die op plekken staan waar ze niet thuis horen.

[YDh]

Dit zal in dit specifieke geval maar een heel beperkt aantal cases te pakken krijgen.

Meestal worden deze keys niet opgezet door de developers. Ze rekenen op deze die het systeem aanmaakt onder C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys . En doen ze dat niet, dan gaan ze meestal voor de optie om ze in de machine.config te zetten onder C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\ . En gebruiken ze toch nog de web.config, dan worden ze meestal geïnjecteerd in CI/CD pipelines. Allemaal plaatsen die sonarqube of tricky niet kunnen controleren.

Het probleem ontstaat meestal bij systemen die in een farm gehost worden. Dan moeten alle instances dezelfde key hebben. En dan gaan mensen wel eens creatief om met het kopiëren van keys. Of in dit geval blijkbaar ook met de origine van hun keys.

[CaptainCapslock]

Als men de keys via pipelines injecteren kan je ervan uitgaan dat ze uniek zijn.

Van de machine keys heb ik geen kennis. Neem aan dat ze op Azure WebApps wel uniek zijn?

[Alfa1970]

Het gaat in het geheel niet om een bug, niet in viewstate en ook niet in de implementatie ervan.

Het is een probleem dat er keys worden gebruikt die gepubliceerd zijn op het internet.
Het is zoiets als een groot bord op je voordeur plakken met de tekst "de sleutel ligt onder de mat".

[jja2000]

De bug is dat LOSFormatter een extreem onveilige deserializer is en Microsoft deze gebruikt voor ViewStates. Ontwikkelaars gebruiken ViewStates, want waarom niet "MS biedt de functionaliteit aan" en maken de fout om een bekende key te gebruiken. De programmeur is hier niet volledig de foute partij.

[Alfa1970]

Nee, de deserializer is niet onveilig.
Het gaat om een mens die een sleutel gebruikt die op straat ligt.
Zonder die sleutel lukt de inbraak niet.
Het probleem is een menselijk falen.
De mensen die de sleutel van de straat hebben opgepakt en gebruikt zijn het probleem, niet de software.

[jja2000]

https://learn.microsoft.c...etframework-4.8.1#remarks gelukkig is Microsoft het niet met je eens

[aikebah]

Het gaat om bugs in de implementatie van het gebruik van ViewState-beveiliging gemaakt door website/webapp developers die duidelijk niet goed door hadden wat ze aan het doen waren (die namelijk niet door hadden dat die beveiliging hoort te worden gedaan mbv informatie die geheim gehouden wordt en dus nooit met sleutels die ergens publiek staan)

[Alfa1970]

Het is geen bug. Want er is niks mis met de programmatuur. Het product is niet onveilig. Er is niks mis met de implementatie.
Een mens die een fout besluit heeft genomen aangaande welke sleutel is gebruikt is geen bug, het is een menselijk falen.

[Hansie9999]

beveiliging hoort te worden gedaan mbv informatie die geheim gehouden wordt en dus nooit met sleutels die ergens publiek staan

Ik ben totaal geen programmeur, maar uhm, dat weet ik zelfs , toch raar dat er mensen zijn die zich "programeur" noemen (ik zeker niet) en die zo een beginnersfouten maken

Je zou denken dat je op die gasten hun server dan ook nog kan inloggen met het wachtwoord "changeme"

[TheVivaldi]

changeme? Ik dacht dat het 12345 was.

[Cyb]

nu blijkt er zit geen bug in de viewstate, maar in de implementatie ervan.

"Implementatie" (net als bug) vind ik een verwarrend woord in deze context. Het klinkt alsof er nog steeds iets mis is met dé implementatie van ASP.NET, wat niet het geval is.
Het probleem is simpel gezegd dat er ontwikkelaars bestaan die *domweg* letterlijk wachtwoorden uit tutorials en examples hebben overgenomen, en die vervolgens gebruiken in een productie systeem.

[jja2000]

Nou ja, als Microsoft dezelfde extreem onveilige deserializer blijft gebruiken voor ViewStates en daar random pleisters op blijft plakken, dan is het heel makkelijk om de schuld in de schoenen van de ontwikkelaars te schuiven.

[familyman]

Een sleutel vinden op het net, en deze gebruiken, heeft niets met serializers te maken.

En ook niet met bugs, of problemen met dit framework.

Heel kwalijk geschreven tekst door tweakers!

En blij dat het er nu een stuk beter staat

[Reactie gewijzigd door familyman op 9 februari 2025 20:04]

[Chopper_Rob]

Microsoft heeft het ook niet over een bug in het document, maar over een aanval met publiekelijk bekende sleutels. Het is Tweakers die het weer eens verwarrend maakt door dit een bug te noemen.

[cracking cloud]

Lijkt me meer een exploot dan echt een bug

[Avalaxy]

Bijzonder. De variant van ASP.NET die een viewstate had is echt al antiek (15 jaar oud ofzo?). Dat deze kwetsbaarheid dan nu pas gevonden wordt is wel opmerkelijk.

[plofkip]

Het is niet echt een kwetsbaarheid, maar meer onkunde van de ontwikkelaar in kwestie als je de keys overneemt van een random bron op het internet.

[downtime]

Niet echt. Viewstates in je configs opnemen kan een manier zijn om load balancing voor elkaar te krijgen waarbij de gebruiker dus naadloos van de ene naar de andere server gaat. En als je die config dan in een openbare repo zet dan heb je dus een lek.

[bush]

keys,secrets moet je nooit in een repro zetten, publiek of niet.

[downtime]

True. Maar de fout is niet dat de ontwikkelaar "de keys overneemt van een random bron op het internet", zoals plofkip het omschreef, maar juist dat ie zijn eigen keys in een open repo op het internet zet.

[SunnieNL]

Volgens mij gaat het om beide gevallen.

Microsoft waarschuwt er nu voor dat sommige ontwikkelaars keys gebruiken die uit openbare bronnen zoals codedocumentatie of repo's komen

Dat is toch echt het overnemen van code van een repro en documentatie zonder die keys aan te passen.

Hetgene wat jij beschrijft geeft Microsoft niet eens letterlijk aan, maar komt ook nog wel regelmatig voor. Net als api-keys en wachtwoorden die in openbare repro's terecht komen of een repro die openbaar wordt gezet met dat niet had moeten zijn.

[downtime]

Good point. Zo had ik die zin niet gelezen.

[SPee]

Er zijn zóveel developers die hun AWS keys in GitHub hebben gezet, dat ze daar nu automatisch op scannen en die key blokkeren.
Je zou zeggen "het kan de beste gebeuren", maar heel eerlijk gezegd, vaak zitten er gewoon domme ontwikkelaars tussen.

[familyman]

Toch nog steeds onkunde, dat je het zo opzet dat de keys openbaar worden.

[Blokker_1999]

Dit is geen kwetsbaarheid in de code, maar een developer of beheerder die ergens gewoon de voorbeeldcode vandaan heeft gehaald en de sleutels in het voorbeeld heeft overgenomen, ondanks dat die voorbeeld documentatie meestal expliciet stelt van die sleutels te veranderen. Het is nog net een stapje minder erg dan het standaard wachtwoord niet te veranderen van je appliance die je net aan het internet hebt gekoppeld.

[aikebah]

Even erg als, niet een stapje minder erg

[Bigs]

Dit betreft wel ASP.NET Web Forms, een oudere maar nog steeds ondersteund onderdeel van .NET Framework t/m 4.x. In het nieuwere .NET Core en .NET 5+ bestaat deze functie, en dus ViewState, en dus deze gevoeligheid niet.

[banaj]

Misleidende titel. Er is geen bug.

Viewstates werken met geheime sleutels. Met toegang tot de geheime sleutels kun je spannende dingen doen. Works as designed.

't Probleem is dat dwazen hun geheime sleutels openbaar toegankelijk maken, of openbare (voorbeeld)sleutels als geheim gebruiken. There's no patch for human stupidity

[Reactie gewijzigd door banaj op 7 februari 2025 16:33]

[jja2000]

Eeuwenoude bug, er staan al jaren een legio aan gelekte/default keys online die je kan gebruiken voor RCE bij een fout ingestelde webapp. Het is naar mijn mening interessanter dat er malware gebouwd is die dit systematisch probeert uit te buiten. Goed dat Microsoft een stel keys heeft gepubliceerd om onderzoek te vergemakkelijken.

[Nozmordre]

Wat ik mis in dit artikel is wat ik als normale gebruiker nu moet doen om mezelf te beschermen.

[plofkip]

Niks :-)

[DataGhost]

Niet alle artikelen slaan op normale gebruikers.

[Wouterie]

Heb je überhaupt het bericht van Microsoft gelezen!?