Microsoft Security Bulletin MS11-100 - Kritisch

Schadensbegrenzung bezieht sich auf eine Einstellung, häufige Konfiguration oder allgemeine empfohlene Vorgehensweise, die in einem Standardzustand existieren und den Schweregrad der Ausnutzung einer Sicherheitsanfälligkeit verringern können. Die folgenden schadensbegrenzenden Faktoren könnten hilfreich für Sie sein:

• Standardmäßig ist IIS auf keinem unterstützten Windows-Betriebssystem aktiviert.
• Sites, welche die Inhaltstypen „application/x-www-form-urlencoded“ oder „multipart/form-data HTTP“ zulassen, sind nicht anfällig.
• Standardmäßig wird ASP.NET nicht zusammen mit .NET Framework installiert. Nur Benutzer, die ASP.NET manuell installieren und aktivieren, sind anfällig für dieses Problem.

Problemumgehung bezieht sich auf eine Einstellung oder Konfigurationsänderung, die die zugrunde liegende Sicherheitsanfälligkeit nicht behebt, sondern die bekannten Angriffsmethoden blockiert, bevor Sie das Update installieren. Microsoft hat die folgenden Problemumgehungen getestet und gibt in der Beschreibung an, ob eine Problembehebung die Funktionalität einschränkt:

• Konfigurationsbasierte Problemumgehung

  Mit der folgenden Problemumgehung wird die Begrenzung der maximalen Anforderungsgröße konfiguriert, die ASP.NET von einem Client akzeptiert. Durch das Verringern der maximalen Anforderungsgröße wird die Anfälligkeit des ASP.NET-Servers gegenüber einem Denial-of-Service-Angriff ebenfalls verringert.

  Hinweis: Erstellen Sie eine Sicherungskopie Ihrer Konfiguration, bevor Sie Änderungen daran vornehmen.

  Dieser Konfigurationswert kann global auf alle ASP.NET-Sites auf einem Server angewendet werden, indem der Eintrag der Stammdatei „web.config“ oder „applicationhost.config“ hinzugefügt wird. Diese Konfiguration kann auch auf eine bestimmte Site oder Anwendung beschränkt werden, indem der Wert der web.config-Datei für die bestimmte Site oder Anwendung hinzugefügt wird. Weitere Informationen zur Konfiguration von ASP.NET finden Sie im MSDN-Artikel ASP.NET Konfiguration – Übersicht.

  1. Wenn in Ihrer Anwendung ViewState verwendet wird, fügen Sie der entsprechenden ASP.NET-Konfigurationsdatei folgende Konfiguration hinzu, um die maximale Anforderungsgröße, die ASP.NET von einem Client akzeptiert, auf 200 KB zu beschränken.

     <configuration>
  <system.web>
  <httpRuntime maxRequestLength="200”/>
  </system.web>
</configuration>

  2. Wenn ViewState nicht in Ihrer Anwendung verwendet wird, fügen Sie der entsprechenden ASP.NET-Konfigurationsdatei folgende Konfiguration hinzu, um die maximale Anforderungsgröße, die ASP.NET von einem Client akzeptiert, auf 20 KB zu beschränken.

     <configuration>
  <system.web>
  <httpRuntime maxRequestLength="20”/>
  </system.web>
</configuration>

  Weitere Informationen zur Konfigurationsoption „maxRequestLength“ finden Sie in der MSDN-Dokumentation zum httpRuntime-Element.

  Hinweis: Durch die Erhöhung der Größenbegrenzungen für die Standard-HTTP-Abfragezeichenfolge und den Anforderungsheader wird die Anfälligkeit des Servers gegenüber dem in dieser Empfehlung beschriebenen Denial-of-Service-Problem erhöht. Weitere Informationen zum Festlegen dieser Begrenzungen finden Sie in Http.sys-Registrierungseinstellungen für IIS.

  Auswirkung der Problemumgehung: Clientanforderungen, die die konfigurierte „maxRequestLength“ überschreiten, führen dazu, dass auf der Serverseite eine „ConfigurationErrorsException“ ausgelöst und ein http-Fehlerstatus an den Client zurückgegeben wird. Die zuvor konfigurierten Begrenzungen sollen als Basislinie verwendet werden und können angepasst werden, um Anwendungsfehler zu vermeiden. Wenn „maxRequestLength“ mit einem kleineren Wert konfiguriert wird, wird damit auch die Anfälligkeit des Servers gegenüber diesem besonderen Denial-of-Service verringert. Anwendungen, die Dateiuploads von Clients akzeptieren, sowie jene, die einen großen ViewState generieren, sind Beispiele für Anwendungen, auf die sich diese Problemumgehung auswirken kann.

  Nachdem Sie diese Problemumgehung übernommen haben, wird im Anwendungsereignisprotokoll u. U. folgender Fehler in einer Clientanforderung angezeigt.

  Ereigniscode: 3004
Ereignismeldung: Beitragsgröße hat die zulässigen Begrenzungen überschritten.
Ausnahmeinformationen:
    Ausnahmetyp: HttpException
    Ausnahmemeldung: Maximale Anforderungslänge überschritten.
   at System.Web.HttpRequest.GetEntireRawContent()
   at System.Web.HttpRequest.FillInFormCollection()
   at System.Web.HttpRequest.get_Form()
   at System.Web.HttpRequest.get_HasForm()
   at System.Web.UI.Page.GetCollectionBasedOnMethod(Boolean dontReturnNull)
   at System.Web.UI.Page.DeterminePostBackMode()
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

  Alternativ kann der Anforderungsfehler zu folgendem Eintrag in einer IIS-Protokolldatei führen.

  #Felder: s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status time-taken

127.0.0.1 POST /webSite/Default.aspx - 80 - 127.0.0.1 - 500 0 0 1268

  Rückgängigmachen der Problemumgehung: Um die Problemumgehung rückgängig zu machen, entfernen Sie die Konfigurationsabschnitte, die in dieser Problemumgehung hinzugefügt wurden, oder stellen Sie die Sicherheitskopie der Konfiguration wieder her, die Sie vor Implementierung der Problemumgehungen erstellt haben.

Worin genau besteht diese Sicherheitsanfälligkeit? 
Es handelt sich bei dieser Sicherheitsanfälligkeit um einen Denial-of-Service-Angriff. Diese Sicherheitsanfälligkeit ermöglicht einem nicht authentifizierten Angreifer, die Leistung einer ASP.NET-Site herabzusetzen, wodurch eine Denial-of-Service-Bedingung entsteht.

Was ist die Ursache dieser Sicherheitsanfälligkeit? 
Die Sicherheitsanfälligkeit wird dadurch verursacht, dass ASP.NET speziell gestaltete Anforderungen mit Hash versieht und diese Daten in eine Hashtabelle einfügt, was zu einer Hashkollision führt. Wenn viele dieser Kollisionen miteinander verkettet sind, wird die Leistung der Hashtabelle erheblich herabgesetzt, was wiederum zu einer Denial-of-Service-Bedingung führt.

Was kann ein Angreifer über diese Sicherheitsanfälligkeit erreichen? 
Ein Angreifer kann mit dieser Sicherheitsanfälligkeit einen Denial-of-Service-Angriff ausführen und die Verfügbarkeit von Sites stören, auf denen ASP.NET verwendet wird.

Wie gehen Angreifer vor, um diese Sicherheitsanfälligkeit auszunutzen? 
Ein nicht authentifizierter Angreifer kann eine kleine Anzahl speziell gestalteter ASP.NET-Anforderungen an eine betroffene ASP.NET-Site senden, um eine Denial-of-Service-Bedingung zu verursachen.

Für welche Systeme stellt diese Sicherheitsanfälligkeit hauptsächlich ein Risiko dar? 
Systeme, die mit dem Internet verbunden sind und auf denen ASP.NET installiert ist, sind von dieser Sicherheitsanfälligkeit besonders betroffen. Auch interne Websites, auf denen ASP.NET-Formularauthentifizierung verwendet wird, können von dieser Sicherheitsanfälligkeit betroffen sein.

Was bewirkt das Update? 
Das Update behebt diese Sicherheitsanfälligkeit, indem korrigiert wird, wie .NET Framework speziell gestaltete Anforderungen verarbeitet.

War diese Sicherheitsanfälligkeit zum Zeitpunkt der Veröffentlichung dieses Security Bulletins bereits öffentlich bekannt? 
Ja. Diese Sicherheitsanfälligkeit wurde veröffentlicht. Ihr wurde die Nummer für allgemeine Sicherheitsanfälligkeit CVE-2011-3414 zugewiesen.

Lagen Microsoft zum Zeitpunkt der Veröffentlichung dieses Security Bulletins Informationen vor, dass diese Sicherheitsanfälligkeit bereits ausgenutzt wurde? 
Nein. Microsoft lagen zum Zeitpunkt der Erstveröffentlichung dieses Security Bulletins keine Informationen vor, dass diese Sicherheitsanfälligkeit öffentlich für Angriffe auf Benutzer ausgenutzt wurde.

Ist dies ein Branchenproblem?
Angriffe, die auf diese Art von Sicherheitsanfälligkeit abzielen, sind allgemein als Hashkollisionsangriffe bekannt. Angriffe wie diese sind nicht für Microsoft-Technologien spezifisch und betreffen andere Anbieter von Webdienst-Software. Endbenutzer sollten sich an die Anbieter ihrer Internetplattform wenden, um Anweisungen oder Updates zu erhalten.

Schadensbegrenzung bezieht sich auf eine Einstellung, häufige Konfiguration oder allgemeine empfohlene Vorgehensweise, die in einem Standardzustand existieren und den Schweregrad der Ausnutzung einer Sicherheitsanfälligkeit verringern können. Die folgenden schadensbegrenzenden Faktoren könnten hilfreich für Sie sein:

• Diese Sicherheitsanfälligkeit ermöglicht einem Angreifer keine Codeausführung oder direkte Erhöhung von Berechtigungen, sondern kann zum weiteren Sammeln von Informationen verwendet werden, mit denen die Benutzerdaten noch stärker kompromittiert werden können.
• Formularauthentifizierung wird durch die Installation von ASP.NET nicht standardmäßig aktiviert. Sie muss ausdrücklich für jede Anwendung konfiguriert werden, um aktiv zu sein.
• Standardmäßig ist IIS nicht installiert.
• Standardmäßig wird ASP.NET nicht zusammen mit .NET Framework installiert. Nur Benutzer, die ASP.NET manuell installieren und aktivieren, sind anfällig für dieses Problem.
• Der Angreifer muss den Benutzer dazu verleiten, auf einen Link zu klicken, um die Sicherheitsanfälligkeit ausnutzen zu können.

Problemumgehung bezieht sich auf eine Einstellung oder Konfigurationsänderung, die die zugrunde liegende Sicherheitsanfälligkeit nicht behebt, sondern die bekannten Angriffsmethoden blockiert, bevor Sie das Update installieren. Microsoft hat die folgenden Problemumgehungen getestet und gibt in der Beschreibung an, ob eine Problembehebung die Funktionalität einschränkt:

• Deaktivieren der Formularauthentifizierung in web.config
  1. Öffnen Sie die Anwendung oder die globale web.config-Datei, nachdem Sie eine Sicherungskopie erstellt haben.
  2. Setzen Sie den Authentifizierungsmodus auf „Windows“, „Kennwort“ oder „Kein“.

     <system.web>

       <authentication mode="Windows | Passport | None" />

     </system.web>

     Details zu den einzelnen Modi finden Sie unter http://msdn.microsoft.com/en-us/library/aa291347(v=vs.71).aspx.

     So machen Sie die Problemumgehung rückgängig. 

     Stellen Sie die Sicherungskopie der Datei „web.config“ wieder her.

Worin genau besteht diese Sicherheitsanfälligkeit? 
Dies ist eine Sicherheitsanfälligkeit durch Spoofing. Diese Sicherheitsanfälligkeit kann einem Angreifer ermöglichen, einen Benutzer ohne dessen Kenntnis zu einer Website nach Wahl des Angreifers umzuleiten. Der Angreifer kann dann einen Phishingangriff durchführen, um Informationen vom Benutzer zu erhalten, deren Offenlegung nicht beabsichtigt war. Diese Sicherheitsanfälligkeit ermöglicht dem Angreifer nicht, Code auszuführen oder Benutzerrechte direkt zu erhöhen, doch damit können weiterhin Benutzerinformationen kompromittiert werden, die privat bleiben sollten.

Was ist Phishing? 
Online-Phishing (ausgesprochen: Fisching) ist eine Möglichkeit, Computerbenutzer durch eine betrügerische E-Mail oder Website zur Offenbarung persönlicher oder finanzieller Informationen zu überlisten. Ein üblicher Online-Phishingbetrug beginnt mit einer E-Mail, die einer offiziellen Nachricht von einer vertrauenswürdigen Quelle ähnelt, z. B. einer Bank, einem Kreditkartenunternehmen oder einem achtbaren Onlinehändler. In der E-Mail werden Empfänger zu einer betrügerischen Website dirigiert, auf der sie um die Bereitstellung persönlicher Informationen wie einer Kontonummer oder einem Kennwort gebeten werden. Diese Informationen werden dann meist für einen Identitätsdiebstahl verwendet.

Was ist die Ursache dieser Sicherheitsanfälligkeit? 
Diese Sicherheitsanfälligkeit wird dadurch verursacht, dass .NET Framework während der Formularauthentifizierung Rückgabe-URLs falsch überprüft.

Was ist Formularauthentifizierung in ASP.NET? 
Bei der Formularauthentifizierung wird ein Authentifizierungsticket verwendet, das erstellt wird, wenn ein Benutzer sich bei einer Site anmeldet. Dadurch wird die Navigation des Benutzers auf der Site verfolgt. Das Formularauthentifizierungsticket ist meist in einem Cookie enthalten. ASP.NET Version 2.0 unterstützt jedoch die Formularauthentifizierung ohne Cookies, was dazu führt, dass das Ticket in einer Abfragezeichenfolge weitergegeben wird. Weitere Informationen finden Sie im MSDN-Artikel Funktionsweise der Formularauthentifizierung in ASP.NET 2.0.

Was kann ein Angreifer über diese Sicherheitsanfälligkeit erreichen? 
Ein Angreifer, der diese Sicherheitsanfälligkeit erfolgreich ausnutzt, kann einen Benutzer ohne dessen Kenntnis zu einer Website des Angreifers umleiten. Diese Sicherheitsanfälligkeit ermöglicht dem Angreifer nicht, Code auszuführen oder Benutzerrechte direkt zu erhöhen, doch damit können weiterhin Benutzerinformationen kompromittiert werden, die privat bleiben sollten.

Wie gehen Angreifer vor, um diese Sicherheitsanfälligkeit auszunutzen? 
Ein Angreifer kann eine speziell gestaltete URL erstellen und einen Benutzer dazu verleiten, darauf zu klicken. Nachdem ein Benutzer sich bei einer erwarteten Website angemeldet hat, leitet der Angreifer den Benutzer zu einer Website um, die vom Angreifer kontrolliert wird. Dann kann der Angreifer den Benutzer zum Preisgeben von Informationen überlisten, die eigentlich privat bleiben sollten. Ein Angreifer kann Benutzer jedoch nicht zwingen, die vom Angreifer kontrollierten Inhalte anzuzeigen. Stattdessen muss ein Angreifer Benutzer zu Handlungen verleiten. Zu diesem Zweck werden Benutzer normalerweise dazu gebracht, auf einen Link in einer E-Mail-Nachricht oder einer Instant Messenger-Nachricht zu klicken, wodurch die Benutzer zur Website des Angreifers gelangen.

Für welche Systeme stellt diese Sicherheitsanfälligkeit hauptsächlich ein Risiko dar? 
Systeme, die mit dem Internet verbunden sind und auf denen ASP.NET installiert ist, sind von dieser Sicherheitsanfälligkeit besonders betroffen. Auch interne Websites, auf denen ASP.NET-Formularauthentifizierung verwendet wird, können von dieser Sicherheitsanfälligkeit betroffen sein.

Was bewirkt das Update? 
Das Update behebt diese Sicherheitsanfälligkeit, indem korrigiert wird, wie .NET Framework während der Formularauthentifizierung Rückgabe-URLs überprüft.

War diese Sicherheitsanfälligkeit zum Zeitpunkt der Veröffentlichung dieses Security Bulletins bereits öffentlich bekannt? 
Nein. Microsoft hat Informationen zu dieser Sicherheitsanfälligkeit durch eine koordinierte Offenlegung der Sicherheitsanfälligkeit erhalten.

Lagen Microsoft zum Zeitpunkt der Veröffentlichung dieses Security Bulletins Informationen vor, dass diese Sicherheitsanfälligkeit bereits ausgenutzt wurde? 
Nein. Microsoft lagen zum Zeitpunkt der Erstveröffentlichung dieses Security Bulletins keine Informationen vor, dass diese Sicherheitsanfälligkeit öffentlich für Angriffe auf Benutzer ausgenutzt wurde.

Schadensbegrenzung bezieht sich auf eine Einstellung, häufige Konfiguration oder allgemeine empfohlene Vorgehensweise, die in einem Standardzustand existieren und den Schweregrad der Ausnutzung einer Sicherheitsanfälligkeit verringern können. Die folgenden schadensbegrenzenden Faktoren könnten hilfreich für Sie sein:

• Ein Angreifer muss ein Konto in der ASP.NET-Anwendung registrieren können und einen vorhandenen Benutzername kennen.
• Formularauthentifizierung wird durch die Installation von ASP.NET nicht standardmäßig aktiviert. Sie muss ausdrücklich für jede Anwendung konfiguriert werden, um aktiv zu sein.
• Standardmäßig ist IIS nicht installiert.
• Standardmäßig wird ASP.NET nicht zusammen mit .NET Framework installiert. Nur Benutzer, die ASP.NET manuell installieren und aktivieren, sind anfällig für dieses Problem.

Problemumgehung bezieht sich auf eine Einstellung oder Konfigurationsänderung, die die zugrunde liegende Sicherheitsanfälligkeit nicht behebt, sondern die bekannten Angriffsmethoden blockiert, bevor Sie das Update installieren. Microsoft hat die folgenden Problemumgehungen getestet und gibt in der Beschreibung an, ob eine Problembehebung die Funktionalität einschränkt:

• ticketCompatibilityMode auf Framework40 setzen

  Dies gilt nur für Sites, auf denen ASP.NET 4 und höher ausgeführt wird, da die Einstellung „ticketCompatibilityMode“ in ASP.NET v4.0 eingeführt wurde.

  1. Öffnen Sie die Anwendung oder die globale web.config-Datei, nachdem Sie eine Sicherungskopie erstellt haben.
  2. Setzen Sie „ticketCompatibilityMode“ auf „Framework40“. Der Standardwert für diese Einstellung lautet „Framework20“.

     <system.web>
  <authentication mode="Forms">
    <forms ticketCompatibilityMode="Framework40" />
  </authentication>
</system.web>

  So machen Sie die Problemumgehung rückgängig. 

  Stellen Sie die Sicherungskopie der Datei „web.config“ wieder her.

• Deaktivieren der Formularauthentifizierung in web.config
  1. Öffnen Sie die Anwendung oder die globale web.config-Datei, nachdem Sie eine Sicherungskopie erstellt haben.
  2. Setzen Sie den Authentifizierungsmodus auf „Windows“, „Kennwort“ oder „Kein“.

     <system.web>

       <authentication mode="Windows | Passport | None" />

     </system.web>

     Details zu den einzelnen Modi finden Sie unter http://msdn.microsoft.com/en-us/library/aa291347(v=vs.71).aspx.

     So machen Sie die Problemumgehung rückgängig. 

     Stellen Sie die Sicherungskopie der Datei „web.config“ wieder her.

Worin genau besteht diese Sicherheitsanfälligkeit? 
Dies ist eine Sicherheitsanfälligkeit bezüglich der Erhöhung von Berechtigungen, bei der ein nicht authentifizierter Remoteangreifer Zugriff auf ein anderes Konto in der ASP.NET-Anwendung erhalten kann, der einem Angreifer wiederum ermöglicht, im Kontext des Zielbenutzers willkürliche Befehle auf der Site auszuführen.

Was ist die Ursache dieser Sicherheitsanfälligkeit? 
Diese Sicherheitsanfälligkeit wird dadurch verursacht, dass ASP.NET Framework speziell gestaltete Benutzernamen falsch authentifiziert.

Was kann ein Angreifer über diese Sicherheitsanfälligkeit erreichen? 
Ein Angreifer, der diese Sicherheitsanfälligkeit erfolgreich ausnutzt, kann im Kontext des Zielbenutzers beliebige Aktionen durchführen, einschließlich des Ausführens willkürlicher Befehle auf der Site.

Wie gehen Angreifer vor, um diese Sicherheitsanfälligkeit auszunutzen? 
Um diese Sicherheitsanfälligkeit auszunutzen, muss ein nicht authentifizierter Angreifer zunächst Kenntnis von einem vorhandenen Konto haben, um die Site nachzuahmen. Der Angreifer kann dann eine speziell gestaltete Webanforderung mit einem zuvor registrierten Konto erstellen, um Zugang zu jenem Konto zu erhalten. Der Angreifer kann dann im Kontext des Zielbenutzers Aktionen durchführen, einschließlich des Ausführens willkürlicher Befehle auf der Site.

Für welche Systeme stellt diese Sicherheitsanfälligkeit hauptsächlich ein Risiko dar? 
Systeme, die mit dem Internet verbunden sind und auf denen ASP.NET installiert ist, sind von dieser Sicherheitsanfälligkeit besonders betroffen. Auch interne Websites, auf denen ASP.NET-Formularauthentifizierung verwendet wird, können von dieser Sicherheitsanfälligkeit betroffen sein.

Wenn meine Website eine Webfarm verwendet, muss ich dann alle Computer in der Webfarm aktualisieren? 
Ja. Dieses Update ändert das Format des Formularauthentifizierungstickets in einer Art und Weise, die mit dem früheren Format unvereinbar ist. Das bedeutet, dass Tickets, die mithilfe des neuen Verhaltens generiert werden, nicht von Computern gelesen werden können, die das alte Verhalten verwenden, und umgekehrt. Administratoren, in deren Anwendungen formularbasierte Authentifizierung verwendet wird, müssen beim Bereitstellen dieses Sicherheitsupdates bestimmte Maßnahmen ergreifen, um sicherzustellen, dass all ihre Server gleichzeitig zu dem neuen Verhalten wechseln.

Weitere Informationen finden Sie in dem Microsoft TechNet-Artikel 2659968.

Ist es möglich, die Computer in meiner Webfarm nacheinander statt gleichzeitig zu aktualisieren? 
Ja. Wenn MS11-100 nicht auf allen Servern einer gegebenen Webfarm gleichzeitig bereitgestellt werden kann, können Sie in der Datei „web.config“ bzw. „machine.config“ eine Kompatibilitätsoption festlegen, bevor das Update installiert wird, um das alte Verhalten zu erzwingen, nachdem das Update installiert ist. Die zu verwendende Kompatibilitätsoption lautet wie folgt:

<appSettings>
  <add key="aspnet:UseLegacyFormsAuthenticationTicketCompatibility" value="true" />
</appSettings>

Durch das Festlegen dieser Option können Webfarmen, in denen nur einige Computer aktualisiert wurden, weiterhin richtig funktionieren. Sie müssen sich jedoch bewusst ein, dass Computer mit dem Konfigurationsoptionssatz sich in einem nicht sicheren Zustand befinden und nicht von der Problembehebung in diesem Sicherheitsupdate profitieren. Nachdem MS11-100 auf allen Computern in einer Farm bereitgestellt wurde, muss die Konfigurationsoption entfernt werden, um das neue, sichere Verhalten zu aktivieren.

Wird bei diesem Update die Einstellung ticketCompatibilityMode für die Formularauthentifzierung meiner Site berücksichtigt? 
Nein. Da die Problembehebung in diesem Sicherheitsupdate das Format von Formularauthentifizierungstickets ändert, wird die Konfigurationseinstellung „ticketCompatibilityMode“ nicht mehr unterstützt, sobald MS11-100 installiert ist.

Was bewirkt das Update? 
Das Update behebt diese Sicherheitsanfälligkeit, indem korrigiert wird wie ASP.NET Framework Benutzer authentifiziert.

War diese Sicherheitsanfälligkeit zum Zeitpunkt der Veröffentlichung dieses Security Bulletins bereits öffentlich bekannt? 
Nein. Microsoft hat Informationen zu dieser Sicherheitsanfälligkeit durch eine koordinierte Offenlegung der Sicherheitsanfälligkeit erhalten.

Lagen Microsoft zum Zeitpunkt der Veröffentlichung dieses Security Bulletins Informationen vor, dass diese Sicherheitsanfälligkeit bereits ausgenutzt wurde? 
Nein. Microsoft lagen zum Zeitpunkt der Erstveröffentlichung dieses Security Bulletins keine Informationen vor, dass diese Sicherheitsanfälligkeit öffentlich für Angriffe auf Benutzer ausgenutzt wurde.

Schadensbegrenzung bezieht sich auf eine Einstellung, häufige Konfiguration oder allgemeine empfohlene Vorgehensweise, die in einem Standardzustand existieren und den Schweregrad der Ausnutzung einer Sicherheitsanfälligkeit verringern können. Die folgenden schadensbegrenzenden Faktoren könnten hilfreich für Sie sein:

• Standardmäßig werden ASP.NET-Antworten nicht im OutputCache zwischengespeichert. Der Entwickler der Site muss die Ausgabezwischenspeicherung durch die OutputCache-Direktive auf einer Seite auswählen.
• Ein Angreifer, der diese Sicherheitsanfälligkeit erfolgreich ausnutzt, kann die gleichen Benutzerrechte wie der Zielbenutzer erlangen. Für Endbenutzer, deren Konten mit weniger Benutzerrechten konfiguriert sind, kann dies geringere Auswirkungen haben als für Benutzer, die mit administrativen Benutzerrechten arbeiten.
• Standardmäßig ist IIS unter keiner Version der betroffenen Betriebssysteme installiert. Nur Endbenutzer, die dies manuell installieren, sind anfällig für dieses Problem.
• Standardmäßig wird ASP.NET nicht zusammen mit .NET Framework installiert. Nur Benutzer, die ASP.NET manuell installieren und aktivieren, sind anfällig für dieses Problem.

Problemumgehung bezieht sich auf eine Einstellung oder Konfigurationsänderung, die die zugrunde liegende Sicherheitsanfälligkeit nicht behebt, sondern die bekannten Angriffsmethoden blockiert, bevor Sie das Update installieren. Microsoft hat die folgenden Problemumgehungen getestet und gibt in der Beschreibung an, ob eine Problembehebung die Funktionalität einschränkt:

• Beschränken von Formularauthentifizierungscookies auf SSL-Channels

  Öffnen Sie die Anwendung oder die globale web.config-Datei, nachdem Sie eine Sicherungskopie erstellt haben.

  Legen Sie für das <forms>-Element „requireSSL = "true"“ fest, wie im folgenden Code gezeigt:

  <forms loginUrl="Secure\Login.aspx"
    requireSSL="true" />

  So machen Sie die Problemumgehung rückgängig. 

  Stellen Sie die Sicherungskopie der Datei „web.config“ wieder her.

• Deaktivieren Sie die gleitende Gültigkeit für Formularauthentifizierungscookies.
  1. Öffnen Sie die Anwendung oder die globale web.config-Datei, nachdem Sie eine Sicherungskopie erstellt haben.
  2. Legen Sie für das <forms>-Element „slidingExpiration="false"“ fest, wie im folgenden Code gezeigt:

     <forms slidingExpiration="false"/>

  Auswirkung der Problemumgehung: Benutzer sind gezwungen, sich erneut anzumelden, nachdem ihre Tickets abgelaufen sind.

  So machen Sie die Problemumgehung rückgängig. 

  Stellen Sie die Sicherungskopie der Datei „web.config“ wieder her.

• Deaktivieren des OutputCache
  1. Erstellen Sie eine Sicherungskopie von Ihrem Webanwendungsordner.
  2. Entfernen Sie alle <%@ OutputCache %>-Direktiven aus Ihren Webseiten.
  3. Wenn Ihre Website eine MVC-Anwendung ist, entfernen Sie auch alle OutputCache-Attribute aus Ihren Controlleraktionen.

  Auswirkung der Problemumgehung: Benutzer sind gezwungen, sich erneut anzumelden, nachdem ihre Tickets abgelaufen sind.

  So machen Sie die Problemumgehung rückgängig. 

  Stellen Sie Ihren Webanwendungsordner wieder her.

Worin genau besteht diese Sicherheitsanfälligkeit? 
Dies ist eine Sicherheitsanfälligkeit bezüglich der Erhöhung von Berechtigungen, bei der ein nicht authentifizierter Remoteangreifer Zugriff auf ein anderes Konto in der .NET-Anwendung erlangen kann.

Was ist die Ursache dieser Sicherheitsanfälligkeit? 
Diese Sicherheitsanfälligkeit wird dadurch verursacht, dass .NET Framework zwischengespeicherte Inhalte falsch verarbeitet, wenn Formularauthentifizierung mit gleitender Gültigkeit verwendet wird.

Was kann ein Angreifer über diese Sicherheitsanfälligkeit erreichen? 
Ein Angreifer, der diese Sicherheitsanfälligkeit erfolgreich ausnutzt, kann im Kontext des Zielbenutzers beliebige Aktionen auf der Site durchführen, einschließlich des Ausführens von willkürlichen Befehlen.

Wie gehen Angreifer vor, um diese Sicherheitsanfälligkeit auszunutzen? 
In einem E-Mail-Angriffsszenario kann ein Angreifer diese Sicherheitsanfälligkeit ausnutzen, indem er einen speziell gestaltete Link an den Benutzer sendet und ihn dazu verleitet, auf den Link zu klicken. Ein Angreifer kann Benutzer nicht zum Besuch einer bestimmten Website zwingen. Stattdessen muss ein Angreifer Benutzer zu Handlungen verleiten. Zu diesem Zweck werden Benutzer normalerweise dazu gebracht, auf einen Link in einer E-Mail-Nachricht oder einer Instant Messenger-Nachricht zu klicken.

Was ist Formularauthentifizierung in ASP.NET? 
Bei der Formularauthentifizierung wird ein Authentifizierungsticket verwendet, das erstellt wird, wenn ein Benutzer sich bei einer Site anmeldet. Dadurch wird die Navigation des Benutzers auf der Site verfolgt. Das Formularauthentifizierungsticket ist meist in einem Cookie enthalten. ASP.NET Version 2.0 unterstützt jedoch die Formularauthentifizierung ohne Cookies, was dazu führt, dass das Ticket in einer Abfragezeichenfolge weitergegeben wird. Weitere Informationen finden Sie im MSDN-Artikel Funktionsweise der Formularauthentifizierung in ASP.NET 2.0.

Für welche Systeme stellt diese Sicherheitsanfälligkeit hauptsächlich ein Risiko dar? 
Systeme, die mit dem Internet verbunden sind und auf denen IIS und ASP.NET installiert ist, sind von dieser Sicherheitsanfälligkeit besonders betroffen. Auch interne Websites, auf denen ASP.NET-Formularauthentifizierung verwendet wird, können von dieser Sicherheitsanfälligkeit betroffen sein.

Was bewirkt das Update? 
Das Update korrigiert, wie ASP.NET zwischengespeicherte Inhalte verarbeitet.

War diese Sicherheitsanfälligkeit zum Zeitpunkt der Veröffentlichung dieses Security Bulletins bereits öffentlich bekannt? 
Nein. Microsoft hat Informationen zu dieser Sicherheitsanfälligkeit durch eine koordinierte Offenlegung der Sicherheitsanfälligkeit erhalten.

Lagen Microsoft zum Zeitpunkt der Veröffentlichung dieses Security Bulletins Informationen vor, dass diese Sicherheitsanfälligkeit bereits ausgenutzt wurde? 
Nein. Microsoft lagen zum Zeitpunkt der Erstveröffentlichung dieses Security Bulletins keine Informationen vor, dass diese Sicherheitsanfälligkeit öffentlich für Angriffe auf Benutzer ausgenutzt wurde.

Referenztabelle

Die folgende Tabelle enthält die Informationen zu Sicherheitsupdates für diese Software. Sie finden zusätzliche Informationen im Unterabschnitt Informationen zur Bereitstellung in diesem Abschnitt.

Hinweis: Das Update für unterstützte Versionen von Windows XP Professional x64 Edition gilt auch für unterstützte Versionen von Windows Server 2003 x64 Edition.

Referenztabelle

Die folgende Tabelle enthält die Informationen zu Sicherheitsupdates für diese Software. Sie finden zusätzliche Informationen im Unterabschnitt Informationen zur Bereitstellung in diesem Abschnitt.

Hinweis: Das Update für unterstützte Versionen von Windows Server 2003 x64 Edition gilt auch für unterstützte Versionen von Windows XP Professional x64 Edition.

Referenztabelle

Die folgende Tabelle enthält die Informationen zu Sicherheitsupdates für diese Software. Sie finden zusätzliche Informationen im Unterabschnitt Informationen zur Bereitstellung in diesem Abschnitt.

Referenztabelle

Die folgende Tabelle enthält die Informationen zu Sicherheitsupdates für diese Software. Sie finden zusätzliche Informationen im Unterabschnitt Informationen zur Bereitstellung in diesem Abschnitt.

Referenztabelle

Die folgende Tabelle enthält die Informationen zu Sicherheitsupdates für diese Software. Sie finden zusätzliche Informationen im Unterabschnitt Informationen zur Bereitstellung in diesem Abschnitt.

Referenztabelle

Die folgende Tabelle enthält die Informationen zu Sicherheitsupdates für diese Software. Sie finden zusätzliche Informationen im Unterabschnitt Informationen zur Bereitstellung in diesem Abschnitt.