Microsoft Security Bulletin MS06-033 - Viktig

• Mappevisning er ikke aktivert som standard i kataloger i Program-mappen. En angriper må gjette eller vite navnene på filene han eller hun forsøker å hente eller vise.
• Filtypene som brukes av Visual Studio- og ASP.NET-webprosjekter, er tilordnet aspnet_isapi.dll System.Web.HttpForbiddenHandler som standard, og kan dermed ikke hentes/vises eksternt ved hjelp av dette sikkerhetsproblemet.

  Her er en fullstendig liste over filtyper som er beskyttet (og ikke sårbare): *.asax, *.ascx, *.master, *.skin, *.browser, *.sitemap, *.config (men ikke*.exe.config eller *.dll.config), *.cs, *.csproj, *.vb, *.vbproj, *.webinfo, *.licx, *.resx, *.resources, *.mdb, *.vjsproj, *.java, *.dd, *.jsl, *.ldb, *.ad, *.ldd, *.sd, *.cd, *.adprototype, *.lddprototype, *.sdm, *.sdmDocument, *.mdf, *.ldf, *.exclude, *.refresh

• IIS 6.0 sender ingen filtyper som ikke har MIME-tilordning definert for IIS 6.0. IIS 6.0 lagrer bare de tillatte MIME-tilordningene i metabasen.

  Hvis for eksempel en tilpasset filtype av typen .data ligger i app_data-mappen på en IIS6-server og det ikke finnes noen MIME-tilknytning for .data-filene som er definert i IIS eller Windows-registeret på serveren, kommer ikke IIS (Internet Information Services) til å behandle denne filtypen og returnerer en 404-feilmelding (uavhengig av hvilken mappe filen ligger i).

• Kunder som bruker URLScan, og som har fulgt rådene i Knowledge Base-artikkel 815155 for herding av ASP.NET-webprogrammer, er mindre utsatt for dette sikkerhetsproblemet.

Microsoft har testet de midlertidige løsningene nedenfor. Disse midlertidige løsningene løser ikke det underliggende sikkerhetsproblemet, men hjelper med å blokkere kjente angrepsvektorer. Hvis en midlertidig løsning reduserer funksjonaliteten, angis dette nedenfor.

• Fjern lesetillatelse fra alle ASP.NET 2.0-Program-mapper.
  Hvis du fjerner lesetillatelser for webinnhold, er det med på å beskytte systemet mot forsøk på å utnytte dette sikkerhetsproblemet.

Slik angir du tillatelser for webinnhold på Windows 2000 som kjører IIS 5.0 ved hjelp av MMC (Microsoft Management Console):

1. Klikk Start, klikk Kjør, og skriv deretter inn følgende: %systemroot%\system32\inetsrv\iis.msc
2. Når Internet Information Services-MMC-snapin-modulen lastes inn, klikker du plusstegnet (+) i den venstre ruten ved siden av datamaskinnavnet for å utvide listen over webområder på serveren.
3. Utvid det første webområdet ved å klikke plusstegnet (+) ved siden av det.
4. Høyreklikk mappen for hver ASP.NET 2.0-Program-mappe, og velg Egenskaper
   Hvis du vil se en fullstendig liste over ASP.NET 2.0-Program-mapper, kan du gå til dette webområdet.
5. I kategorien Directory (Mappe) eller Virtual Directory (Virtuell mappe) fjerner du merkingen for Read (Les) og trykker OK.
6. Gjenta trinn 3 for hvert webområde og program på serveren.

Slik angir du tillatelser for webinnhold på Windows 2003 med IIS 6.0 ved hjelp av MMC (Microsoft Management Console):

1. Klikk Start, klikk Kjør og skriv deretter inn følgende: %systemroot%\system32\inetsrv\iis.msc
2. Når Internet Information Services-MMC-snapin-modulen er ferdig lastet inn, klikker du plusstegnet (+) i den venstre ruten ved siden av datamaskinnavnet
3. Klikk plusstegnet (+) ved siden av Web sites-mappen (Webområder) for å utvide listen over webområder på denne serveren.
4. Utvid det første webområdet ved å klikke plusstegnet (+) ved siden av det.
5. Høyreklikk mappen for hver ASP.NET 2.0-Program-mappe, og velg Egenskaper
   Hvis du vil se en fullstendig liste over ASP.NET 2.0-Program-mapper, kan du gå til dette webområdet.
6. I kategorien Directory (Mappe) eller Virtual Directory (Virtuell mappe) fjerner du merkingen for Read (Les) og trykker OK.
7. Gjenta trinn 4 for hvert webområde og program på serveren.

Hva løsningen kan føre til: Hvis det nektes lesetilgang i den virtuelle mappen, vil det blokkere gjenspeiling og dermed hindre ekstern feilsøking.

• Bruk URLScan med innstillingen DenyUrlSequences for å forby URL-adresser som spør etter beskyttede filtyper.
  1. Hvis URLScan allerede er installert, bør du sikkerhetskopiere URLScan.ini før du fortsetter til neste trinn.
  2. Konfigurer URLScan.ini (ligger i mappen %windir%\system32\inetsrv\urlscan som standard) med følgende innstillinger:
  3. Kontroller at NormalizeUrlBeforeScan er satt til 1 i delen [Options]
  4. Kontroller at VerifyNormalization er satt til 1 i delen [Options]
  5. Kontroller at tegnet omvendt skråstrek, \, er oppført i delen [DenyUrlSequences]
  6. Start IIS på nytt for at endringene skal tre i kraft.

Obs! Innstillingene ovenfor aktiveres som standard for versjoner av URLScan som er installert ved hjelp av veiviseren for IIS Lockdown, og for alle frittstående installasjoner av URLScan 2.5.

Obs! Hvis du vil ha mer informasjon om hvordan du konfigurerer URLScan slik at det fungerer med ASP.NET-programmer, kan du se Knowledge Base-artikkel 815155.

Hva løsningen kan føre til: Ugyldig konfigurasjon av URLScan kan føre til at enkelte webprogrammer ikke fungerer som de skal.

• Bruk filtyper for filene i App_*-mappene som ikke er tilordnet ASP.NET, og som ikke har noen MIME-lignende tilordning som IIS kan bruke.
  Hvis en statisk filtype ikke har noen MIME-lignende tilordning, blir den ikke behandlet av Internet Information Services 6.0 (IIS).

Hva løsningen kan føre til: Ingen

Hva er omfanget av sikkerhetsproblemet?
Dette sikkerhetsproblemet som kan føre til tilgjengeliggjøring av informasjon, kan gi en angriper muligheten til å omgå ASP.Net-sikkerheten og få uautorisert tilgang til objekter i Program-mappen eksplisitt etter navn. Legg merke til at dette sikkerhetsproblemet ikke gjør det mulig for en angriper å kjøre kode eller å utvide egne brukerrettigheter direkte, men det kan brukes til å fremskaffe nyttig informasjon som senere kan brukes til å skade det berørte systemet ytterligere.

Hva forårsaker sikkerhetsproblemet?
ASP.NET 2.0 validerer ikke den sendte URL-adressen på riktig måte.

Hva er ASP.NET
ASP.NET er en samling teknologier i .NET Framework som gjør at utviklere kan utvikle webprogrammer og XML-webtjenester.
I motsetning til tradisjonelle websider, som bruker en kombinasjon av statisk HTML og skripting, bruker ASP.NET kompilerte, hendelsesdrevne sider. Det gjør at utviklere kan utvikle webbaserte programmer med samme omfang og funksjonalitet som programmer utviklet med programmeringsspråk som Visual Basic eller Visual C++. Fordi ASP.NET er et webbasert programmiljø, krever det en underliggende webserver for å ha grunnleggende HTTP-funksjonalitet. Av den grunn kjører ASP.NET på toppen av IIS 5.0 på Windows 2000, IIS 5.1 på Windows XP og IIS 6.0 på Windows Server 2003.

Hvordan kan en angriper utnytte dette sikkerhetsproblemet?
En angriper som klarer å utnytte dette sikkerhetsproblemet, kan få uautorisert tilgang til deler av et webområde. Hvilke handlinger angriperen kan utføre, avhenger av hva slags innhold som blir beskyttet.

Hvem kan utnytte sikkerhetsproblemet?
I et webbasert angrepsscenario må angriperen ha tilgang til et webområde som inneholder en Program-mappe, for å kunne utnytte dette sikkerhetsproblemet. Legg merke til at dette sikkerhetsproblemet ikke gjør det mulig for en angriper å kjøre kode eller å utvide egne brukerrettigheter direkte, men det kan brukes til å fremskaffe nyttig informasjon som senere kan brukes til å skade det berørte systemet ytterligere.

Hvilke systemer er hovedsakelig i faresonen på grunn av sikkerhetsproblemet?
Systemer som brukes på Internett, er hovedsakelig i faresonen på grunn av dette sikkerhetsproblemet. I tillegg kan interne webområder som bruker ASP.NET som vert for sensitive data, være i faresonen på grunn av dette sikkerhetsproblemet.

Kan sikkerhetsproblemet utnyttes over Internett?
Ja. En angriper kan prøve å utnytte dette sikkerhetsproblemet over Internett.

Hva gjør oppdateringen?
Oppdateringen fjerner sikkerhetsproblemet ved å endre måten ASP.NET validerer URL-baner på.

Hadde dette sikkerhetsproblemet blitt offentliggjort da denne sikkerhetsbulletinen ble publisert?
Nei. Microsoft mottok informasjon om dette sikkerhetsproblemet gjennom begrenset offentliggjøring. Microsoft hadde ikke mottatt informasjon som tyder på at dette sikkerhetsproblemet var offentliggjort da denne sikkerhetsbulletinen opprinnelig ble publisert.

Hadde Microsoft mottatt rapporter om at dette sikkerhetsproblemet ble utnyttet da denne sikkerhetsbulletinen ble publisert?
Nei. Microsoft hadde ikke mottatt informasjon som tydet på at dette sikkerhetsproblemet offentlig hadde blitt brukt til å angripe kunder, og hadde ikke sett noen eksempler på at konseptbeviskode var publisert da denne sikkerhetsbulletinen først ble publisert.