URL_Rewrite

Erste Versionen des IIS hatten immer alle Funktion, und damit auch alle Sicherheitslücken, aktiv. Nach vielen erfolgreichen Angriffen hat Microsoft mit dem Programm IISLOCKDown einen Weg geschaffen, damit Administratoren unerwünschte Funktionen schnell abschalten können. Allein die sichere Konfiguration des IIS und die Entfernung von virtuellen Verzeichnissen ist nicht ausreichend. Wenn Sie eine Firewall haben, dann können sie die HTTP-Befehle vor dem Eintreffen am IIS einer Plausibilitätskontrolle unterziehen. Genau das macht auch URLSCAN.

URLSCAN ist eine DLL, die sich als ISAPI-Filter in den IIS einbindet und alle Anfragen an den Server überprüfen kann. URLSCAN wird über eine INI-Datei gesteuert, in der die erlaubten und verbotenen Befehle konfiguriert werden können. So können Sie hier z.B. die URL-Pfade vorgeben, die überhaupt an den IIS durchgereicht werden dürfen. Sie können also mit URL_Rewrite komplette URLs oder auch nur bestimmte Pfade oder Parameter blocken, umleiten oder sogar umschreiben. URL_Rewrite kann als Teil ihrer Lösung sein, wie Skype for Business und Exchange dies nutzen oder aktiv bösartige URLs temporär oder dauerhaft blockieren.

Wer die manuelle Konfigurationsschritte laut Microsoft gegen der Exchange-0-day-Exploit 2022 ausgeführt hat, kann Autodisover lahmlegen. Details siehe letztes Kapitel

URL_Rewrite installieren

URL_Rewrite ist nicht Bestandteil der Windows Installation, sondern ein eigenständiger Download. Die Exchange 2019 Administratoren werden das schon kennen, denn das Exchange Setup prüft, ob URL_Rewrite installiert ist.

Sie müssen also zuerst URL_Rewrite herunterladen und installieren. Die Funktion ist übrigens auch für den EEMS - Exchange Emergency Mitigation Service zwingend erforderlich. Bei Exchange 2019 haben sie URL_Rewrite ja schon bei der Installation mit eingerichtet. Bei Exchange 2016 war URL_Rewrite anfangs noch nicht erforderlich.

Tipp: Sie sollten auf jeden Fall EEMS - Exchange Emergency Mitigation Service einrichten. Insbesondere wenn sie nicht zeitnah Updates oder Patches installieren. Siehe auch Exchange-0-day-Exploit 2022

Hier der Link zum Download:

URL Rewrite
https://www.iis.net/downloads/microsoft/url-rewrite
https://download.microsoft.com/download/1/2/8/128E2E22-C1B9-44A4-BE2A-5859ED1D4592/rewrite_amd64_en-US.msi

Die Installation selbst ist unspektakulär. Es gibt nur ein Willkommensfenster, einen Fortschrittsbalken und eine Schlussmeldung. Nach der Installation finden Sie dann im IIS-Manger aber auf der Webseite und jedem Verzeichnis das Icon zur Konfiguration:

Konfiguration

Sie können dann pro Server ,Webseite oder Verzeichnis eigene Regeln addieren, um die Verarbeitung von eingehenden HTTPS-Requests zu modifizieren. Früher wurde URL_Rewrite noch über eine INI-Datei gesteuert. Die aktuelle Version 2.1 nutzt dafür die WEB.CONFIG im jeweiligen Verzeichnis.

Eine häufig genutzte Funktion ist sicher die "Anforderungsblockierung", mit der Anhand von Wildcards oder RegEx-Ausdrücken bestimmte URLs mit einem 401,403,404 ablehnen oder den Request komplett abbrechen können.

Aber sie können natürlich auch URLs umschreiben oder mittels IIS ARR (Application Request Routing) als Reverse Proxy auf nachgelagerte Server weiterreichen. Viel weiter möchte und kann ich hier aber auf die Konfiguration nicht eingehen, wenn letztlich ist es ja die individuelle Anforderung, die umgesetzt werden muss.

Der EEMS - Exchange Emergency Mitigation Service arbeitet aktiv mit URLRewrite, um die Exchange Lücke vom 28. Sep 2022 (Siehe Exchange-0-day-Exploit 2022) zu blockieren

URL_Rewrite Vererbung

In Verbindung mit der Exchange Lücke vom Sep 2022 habe ich ein unerwartetes Verhalten von URL_Rewrite bei einem Kunden kennengelernt, der die "Autodiscover"-Funktion blockiert hat. Der Kunde hatte sehr schnell damals die manuellen "Fixes" umgesetzt, in dem er im "Autodiscover"-Verzeichnis die schädlichen URLs per Regular Expression verhindert hat. Einige Tage später hat Microsoft dann aber die Anleitung korrigiert und die Konfiguration auf der Basis der Default Webseite angefordert. Wenn ich dann wieder auf das Autodiscover-Verzeichnis gegangen bin, habe ich folgenden Fehler bekommen.

Was war passiert? Es gab zu erst eine Regel im "Autodiscover"-Verzeichnis und einige Stunden später wurde eine korrigierte Regel auf der Webseite selbst addiert, die aber den gleichen Namen hatte. Und damit kommt URL_Rewrite so nicht zurecht. Daher habe ich mit das Thema "Vererbung" mal etwas genauer angeschaut und zuerst eine Standardregel in einem Unterverzeichnis angelegt:

Ich konnten dann problemlos in einem zweiten Schritte noch mal eine gleichnamige Regel auf der Webseite selbst erstellen:

Wenn ich dann aber wieder die Regel in der Unterseite verwalten will, bekommt ich beim Aufruf von URL_Rewrite die folgende Meldung:

Im IIS-Admin sehe ich dann nur ein leeres Regel-Fenster mit der Fehlermeldung:

Ich habe mir dann doch einmal angeschaut, wie URL_Rewrite das mit der "Vererbung" macht. Die Konfiguration des Verzeichnisses landet in der jeweiligen "Web.config". Einstellungen des darüber liegenden Verzeichnisses werden nicht in die darunter liegenden Konfigurationen geschrieben, sondern der IIS und IISAdmin parsen alle web.config-Dateien der darüber liegenden Hierarchien. Allerdings prüft IISAdmin und IIS bei der Neuanlage einer URL_Rewrite-Regel nicht, ob es schon eine gleichnamige Regel im Unterverzeichnis gibt.

Das zeigt sich aber nicht nur in der Fehlermeldung im IISAdmin sondern hat auch eine direkte Auswirkung auf die Funktion des IIS, der nämlich auch jede Anfrage mit einem Fehler returniert.

PS C:\> Invoke-WebRequest http://localhost/Sub1
Invoke-WebRequest:


IIS 10.0 Detaillierter Fehler - 500.52 - URL Rewrite Module Error.

Auch der Aufruf mit dem Browser zeigt eine hilfreiche Fehlerbeschreibung:

Wenn ich nicht sicher bin, welche Regel nun wo steht, dann ändere ich die web.config in dem Problemverzeichnis und benenne einfach die Regeln um. Das ist Risikofrei und löscht erst einmal nichts. Ich kann dann aber wieder im IISAdmin die Eigenschaften anzeigen und hier sehe ich dann, welche Regel vererbt oder lokal ist.

Vor allem ist die Funktion aber wieder gegeben, selbst wenn Regeln identisch sind. Es ist nur der Name, der "stört. Sie haben dann etwas mehr Zeit, den Konflikt zu lösen. Wenn Sie rechts oben auf "Übergeordnete Konfiguration wiederherstellen klicken, dann werden einfach alle lokalen Rewrite-Regeln entfernt. Dies ist nicht immer gewünscht.

Blöde halt, wenn durch die Änderungen Exchange-0-day-Exploit 2022 ein Admin erst auf "/autodiscover" eine "RequestBlockingRule1" anlegt und später noch mal auf "/" und damit die Funktion von Autodiscover bricht.

Weitere Links