Microsoft noodpatch voor ASP.NET-lek

28-09-2010,10:00 doorRedactie

Microsoft zal vandaag een noodpatch uitbrengen voor een beveiligingslek in het .NET Framework, waardoor aanvallers op dit moment gevoelige informatie kunnen stelen. Het zero-day lek werd twee weken geleden onthuld en vorige week waarschuwde de softwaregigant dat hackers de kwetsbaarheid ook daadwerkelijk misbruiken. Gisteren kwam het nog met een tijdelijke oplossing voor het probleem.

Ondanks dat het om een noodpatch gaat, geeft Microsoft de update "important" rating mee. "Aan de hand van onze uitgebreide monitoring van het dreigingslandschap, hebben we besloten dat een out-of-band release nodig is om onze klanten te beschermen, aangezien we beperkte aanvallen en continue pogingen om huidige beschermingsmaatregelen en workarounds te omzeilen hebben waargenomen", zegt Dave Forstrom, directeur Trustworthy Computing

Uitrol
Een ander opmerkelijk punt aan deze noodpatch is dat die niet meteen via de Automatische Update functie wordt verspreid. In eerste instantie biedt Microsoft de patch alleen via het Microsoft Download Center aan. "Dit laat ons de update zo snel als mogelijk uitbrengen, en geeft systeembeheerders bij bedrijven of eindgebruikers de mogelijkheid om zelf de update te installeren en in hun omgeving te testen en uit te rollen."

Als alles goed gaat, wordt de update over een paar dagen ook via Windows Update en Windows Server Update Services aangeboden. MS10-070 is vanaf vanavond te downloaden.

Trojaans paard steelt mobiele TAN-codes

Spamhaus bestrijdt spam met whitelist

Reacties

28-09-2010,

12:14 door

Anoniem

-1 Rating:

Quote deze reactie | Reactie niet OK

Kloten Microsoft!!!!!

Mag ik als WSUS beheerder zelf beslissen of ik iets patch of niet? K? tnx

12:52 door

+0 Rating:

Jij werd toch zelf WSUS beheerder :) Kunt moeilijk MS de schuld geven van een fout die je zelf maakte :)

Grtz EzMe

13:16 door

Door Anoniem: Kloten Microsoft!!!!!

Mag ik als WSUS beheerder zelf beslissen of ik iets patch of niet? K? tnx

Wat een domme reactie!

Bedankt Microsoft dat er een oplossing komt voor dit probleem.

13:21 door

Lees eens goed. Er staat aangeboden.
WSUS beheerder kan nog altijd zelf beslissen of die patch doorvoert

14:59 door

Mysterio

Of volg een cursus WSUS zodat je weet hoe het moet.

19:43 door

Peter V

Saillant detail: de patch wilde zich niet laten installeren. Wat ik ook probeerde. Er werd mij gemeld dat de patch was geblokkeerd. Waarom is mij nog niet duidelijk.

21:46 door

Bitwiper

Door Peter V: Saillant detail: de patch wilde zich niet laten installeren. Wat ik ook probeerde. Er werd mij gemeld dat de patch was geblokkeerd. Waarom is mij nog niet duidelijk.

Peter, het is geen patch "voor een beveiligingslek in het .NET Framework" zoals de redactie stelt, maar voor in ASP.NET webapplicaties die op IIS (Internet Information Server) draaien.

Alleen als je IIS + met daarop een ASP.NET applicatie draait (zoals Sharepoint) moet je patchen (met name als die site vanaf internet toegangelijk is).

Aanvulling/correctie 2010-09-30 22:38: het bovenstaande is onjuist. Mijn excuses voor deze (te snelle) conclusie!

Het gaat namelijk wel om een vulnerability in alle .NET framework versies. Echter deze bug is ontdekt als een kwetsbaarheid in ASP.NET, een Microsoft framework voor web-applicaties dat bouwt op zo'n .NET framework. Onder meer Microsoft's eigen Sharepoint server is daardoor kwetsbaar (maar vermoedelijk ook enorm veel webshops).

In hoeverre deze kwetsbaarheid exploitable is in applicaties die van .NET gebruik maken, weet ik niet, maar vermoedelijk zijn alle .NET-based applicaties, die gebruik maken van de betrokken cryptografische functies, kwetsbaar.

Naast onderstaande bijdrage zal ik nog aanvullende info toevoegen aan een nieuwe thread die Peter V. hier gestart is: https://secure.security.nl/artikel/34613/1/.NET_patch_via_Windows_Upate.html.

Laatst gewijzigd: 30-09-2010, 22:38

22:25 door

Ik heb wat info over de kwetsbaarheden verzameld. Hoewel eerder al JSF (Java Server Faces) kwetsbaar bleek voor een vergelijkbare aanval maakt Microsoft het weer lekker bont aldus http://netifera.com/research/poet//PaddingOraclesEverywhereEkoparty2010.pdf:

ASP.NET MAC-then-Encrypt these things:
- ViewStates.
- Form Authentication Tickets.
- Anonymous Identification.
- Role Cookies.
In other words, universial padding oracles in every ASP.NET application!

De kwetsbaarheid bestaat er uit dat er bekende "padding" (aanvullen tot een bepaalde buffergrootte) achter plain-text geplakt wordt voordat deze wordt versleuteld gecombineerd met het feit dat IIS/ASP.NET verschillende foutmeldingen teruggeeft afhankelijk van wat je probeert te raden. Daarmee is een brute-force attack mogelijk waarmee de encryptie kan worden gekraakt (zonder de sleutel te kennen).
Elders uit dat document:

The Golden Rule of Web Security: “Do not keep anything sensitive inside the document root.”

Web.config is the most important and sensitive file in ASP.NET.

Guess what? It’s just a normal file inside the document root!
- Usernames, passwords, connection strings.
- MachineKey: validationKey (HMAC key) and decryptionKey (DES, 3DES, or AES key).
- A lot of configuration information.
All it takes is one file disclose vulnerability.

Uit http://www.microsoft.com/technet/security/bulletin/MS10-070.mspx

In Microsoft .NET Framework 3.5 Service Pack 1 and above, this vulnerability can also be used by an attacker to retrieve the contents of any file within the ASP.NET application, including web.config.

Terug naar http://netifera.com/research/poet//PaddingOraclesEverywhereEkoparty2010.pdf:

POET -> remote code execution -> Cesar’s Token Kidnapping -> ROOT privilege on Windows

De POET versie die dat kan hebben ze nog niet gereleased, maar als er daadwerkelijk remote code exec mee mogelijk is dan onderdrijft Microsoft weer lekker in haar MS10-070 advisory (door slechts van "Important" te spreken).

Met "Cesar’s Token Kidnapping" doelen T. Duong en J. Rizzo overigens op dit document van Cesar Cerrudo http://www.argeniss.com/research/TokenKidnappingRevengePaper.pdf waarin hij een reeks privilege escalations (en fixes) beschrijft. Bizar trouwens dat ordinary users in in Vista, W7 en W2K R1+R2 schrijfrechten hebben op HKLM\Software\Microsoft\Tracing\tapisrv (*), op het XPSP3 systeem waarop ik dit tik is dat gelukkig nog niet zo (read only access voor Users).

(*) Zou dit veroorzaakt worden door de registry en filesystem virualisaties die Microsoft met Vista heeft ingevoerd? Zo ja, dan mag ik toch aannemen dat de Microsoft ontwikkelaars wel zo slim zijn geweest om dergelijke gevirtualiseerde data door meer privileged processen te laten negeren?!? Anders kun je net zo goed weer iedereen overal schrijfrechten geven...
Hmm, onder XP en W2K3 was Microsoft in elk geval nog niet slim bezig, want bij die systemen laat ze services die onder SYSTEM draaien ook keys en values onder HKEY_USERS\S-1-5-20_Classes ("Network" account) en HKEY_USERS\S-1-5-19_Classes (Local Service account) evalueren, waarmee privilege escalation attacks vanuit die accounts naar SYSTEM mogelijk zijn, aldus Cesar Cerrudo.

Laatst gewijzigd: 28-09-2010, 22:28

E-mail:
Wachtwoord:
Blijf 30 dagen ingelogd
Wachtwoord kwijt? Account aanmaken

Login