Im Internet Explorer steckt eine teils als kritisch eingestufte Schwachstelle, die Remote Code Execution erlaubt. Derzeit hilft dagegen nur ein Workaround.
Microsoft hat am Freitag (17.1.) einen Sicherheitshinweis zu einer Zero-Day-Schwachstelle im Internet Explorer veröffentlicht. Die Schwachstelle in der Bibliothek jscript.dll ermöglicht das Ausführen von Schadcode aus der Ferne. Der bereits in die Jahre gekommene Internet Explorer ist Bestandteil aller Microsoft Windows-Betriebssysteme und die Scripting-Engines, die vom Browser und abhängigen Komponenten verwendet werden, fallen immer wieder durch Sicherheitslücken auf.
Vor einer Woche gab es bereits einen kurzen Hinweis des chinesischen Sicherheitsanbieters Qihoo 360 zu einem Zero-Day-Exploit im Internet Explorer auf Twitter. Der Tweet wurde aber anscheinend kurze Zeit später wieder gelöscht. Zum jüngsten Patchday am 14. Januar 2020 hat Microsoft zwar Updates für den Internet Explorer und einige Komponenten freigegeben. Aber offenbar war keine Zeit, eine Zero-Day-Schwachstelle in jscript.dll zu beheben.
Als kritisch eingestufte Remote Code Execution-Schwachstelle
In dem Sicherheitshinweis ADV200001 vom Freitagabend weist Microsoft auf die Zero-Day-Schwachstelle im Internet Explorer hin. In der vom Internet Explorer verwendeten JScript Scripting Engine gibt es einen Bug, der bei der Verarbeitung von Script-Objekten zu einem Speicherfehler (Memory Corruption) führen kann. Microsoft listet im Sicherheitshinweis den Internet Explorer in den Versionen 9 bis 11 unter allen noch mit Updates versorgten Windows-Versionen (Clients und Server) auf. Die Einstufung wird dabei, abhängig von der Windows-Version, als moderat oder kritisch angegeben.
Angreifer, die diese Schwachstelle ausnutzen, können dann unter Umständen Code im Kontext des aktuellen Benutzers ausführen. Für Nutzer, die unter Administratorkonten arbeiten, würde dies bedeuten, dass der Angreifer theoretisch Programme installieren, neue Benutzerkonten einrichten oder auch Dateien manipulieren und somit das System übernehmen könnte.
Da es die Scripting Engine JScript.dll betrifft, könnte ein Angreifer, der die Details der Schwachstelle kennt, eine präparierte Website zur Ausnutzung aufsetzen. Dann ließe sich etwa eine Mail mit einem Link zu der präparierten Webseite versenden, um Nutzer zum Besuch der Website zu verleiten und anzugreifen. Da der Internet Explorer in allen Windows-Versionen samt der Scripting Engine dabei ist, wäre das potenziell ein wirksamer Angriffsvektor.
Ausnutzbarkeit ist begrenzt
Glück für Microsoft bzw. die Windows-Anwender ist aber, dass die Ausnutzbarkeit dieser Schwachstelle begrenzt ist. Standardmäßig verwendet der Internet Explorer in den Versionen 9, 10 und 11 die Scripting Engine aus der Datei Jscript9.dll, die aber von dieser Sicherheitsanfälligkeit nicht betroffen ist. Es sind nur bestimmte Websites betroffen, die JScript als Scripting Engine verwenden – was aber einen Angreifer nicht davon abhalten wird, eine Website mit entsprechenden JScript-Objekten zu präparieren.
Microsoft stuft die Schwachstelle, die in allen unterstützten Windows-Systemen existiert, daher für einige Windows-Versionen zwar als kritisch ein, aber ganz so kritisch ist es dann doch wiederum nicht. Denn standardmäßig wird Internet Explorer unter Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016 und Windows Server 2019 in einem eingeschränkten Modus ausgeführt.
Solange Administratoren diesen erweiterten Sicherheitsschutz (Geschützter Modus) im Rahmen der Enhanced Security Configuration in den IE-Optionen nicht deaktivieren, werden externe Webseiten in einer eigenen Internetzone behandelt. Im eingeschränkten Modus gilt für externe Webseiten eine niedrige Verbindlichkeitsstufe, die das Ausführen von Programmen verhindert. Das verringert die Wahrscheinlichkeit, dass ein Benutzer oder Administrator speziell gestaltete Webinhalte im Internet Explorer herunterlädt und ausführt. Das setzt aber voraus, dass (eventuell kompromittierte) Websites im Internet Explorer nicht zur Zone der vertrauenswürdigen Sites hinzugefügt werden.
Workaround: die Scripting-Engine deaktiveren
Da aktuell kein Sicherheitsupdate für diese Schwachstelle vorliegt und diese teilweise als kritisch bewertet wird, hat Microsoft vorsorglich als Workaround eine Anleitung zur Deaktivierung der Scripting Engine in der Datei JScript.dll veröffentlicht. Dazu sind bei einem 32-Bit-Windows folgende Befehle in einer administrativen Eingabeaufforderung auszuführen:
takeown /f %windir%\system32\jscript.dll
cacls %windir%\system32\jscript.dll /E /P jeder:N
Bei einem 64-Bit-Windows sind die folgenden vier Befehle in einer administrativen Eingabeaufforderung auszuführen:
takeown /f %windir%\syswow64\jscript.dll
cacls %windir%\syswow64\jscript.dll /E /P jeder:N
takeown /f %windir%\system32\jscript.dll
cacls %windir%\system32\jscript.dll /E /P jeder:N
Es empfiehlt sich, die Befehlsfolge per Editor in eine .bat-Datei zu speichern und dann am Ende noch einen pause-Befehl einzufügen. Dann lässt sich die Batch-Datei über den Kontextmenübefehl "Als Administrator ausführen" starten und das Fenster der Eingabeaufforderung bleibt geöffnet, bis eine Taste gedrückt wird. So lässt sich die Statusanzeige jedes Befehls kontrollieren.
Lokalisierungen beachten
Die Anweisungen entziehen Windows die Berechtigung, die jscript.dll für die Benutzer auszuführen. An dieser Stelle noch der Hinweis, dass die von Microsoft im Advisory ADV200001 auf einem deutschsprachigen Windows meist nicht funktionieren. Microsoft hat beim cacls-Befehl nämlich eine Lokalisierung vorgenommen. Gegenüber den von Microsoft im Sicherheitshinweis veröffentlichten Ausführungen enthalten die obigen Befehle eine Modifikation des Autors für deutsche Windows-Varianten.
Die von Microsoft für ein englischsprachiges Windows verwendete Option everyone führt in einem deutschsprachigen Windows zu einem Fehler ‘“Zuordnungen von Kontennamen und Sicherheitskennungen wurden nicht durchgeführt.”. Dann muss in einem deutschen Windows das Attribut jeder (statt everyone) im Befehl verwendet werden, damit die Anweisung akzeptiert wird.
Sobald Microsoft einen Patch für die Schwachstelle veröffentlicht hat, kann die Scripting-Engine jscript.dll wieder freigegeben werden. Die entsprechenden Befehle sind unter ADV200001 aufgeführt, wobei auch dort in einem deutschen Windows das Attribut everyone in den Befehlen durch jeder zu ersetzen ist.
Quelle; heise
Microsoft hat am Freitag (17.1.) einen Sicherheitshinweis zu einer Zero-Day-Schwachstelle im Internet Explorer veröffentlicht. Die Schwachstelle in der Bibliothek jscript.dll ermöglicht das Ausführen von Schadcode aus der Ferne. Der bereits in die Jahre gekommene Internet Explorer ist Bestandteil aller Microsoft Windows-Betriebssysteme und die Scripting-Engines, die vom Browser und abhängigen Komponenten verwendet werden, fallen immer wieder durch Sicherheitslücken auf.
Du musst Regestriert sein, um das angehängte Bild zusehen.
Vor einer Woche gab es bereits einen kurzen Hinweis des chinesischen Sicherheitsanbieters Qihoo 360 zu einem Zero-Day-Exploit im Internet Explorer auf Twitter. Der Tweet wurde aber anscheinend kurze Zeit später wieder gelöscht. Zum jüngsten Patchday am 14. Januar 2020 hat Microsoft zwar Updates für den Internet Explorer und einige Komponenten freigegeben. Aber offenbar war keine Zeit, eine Zero-Day-Schwachstelle in jscript.dll zu beheben.
Als kritisch eingestufte Remote Code Execution-Schwachstelle
In dem Sicherheitshinweis ADV200001 vom Freitagabend weist Microsoft auf die Zero-Day-Schwachstelle im Internet Explorer hin. In der vom Internet Explorer verwendeten JScript Scripting Engine gibt es einen Bug, der bei der Verarbeitung von Script-Objekten zu einem Speicherfehler (Memory Corruption) führen kann. Microsoft listet im Sicherheitshinweis den Internet Explorer in den Versionen 9 bis 11 unter allen noch mit Updates versorgten Windows-Versionen (Clients und Server) auf. Die Einstufung wird dabei, abhängig von der Windows-Version, als moderat oder kritisch angegeben.
Angreifer, die diese Schwachstelle ausnutzen, können dann unter Umständen Code im Kontext des aktuellen Benutzers ausführen. Für Nutzer, die unter Administratorkonten arbeiten, würde dies bedeuten, dass der Angreifer theoretisch Programme installieren, neue Benutzerkonten einrichten oder auch Dateien manipulieren und somit das System übernehmen könnte.
Da es die Scripting Engine JScript.dll betrifft, könnte ein Angreifer, der die Details der Schwachstelle kennt, eine präparierte Website zur Ausnutzung aufsetzen. Dann ließe sich etwa eine Mail mit einem Link zu der präparierten Webseite versenden, um Nutzer zum Besuch der Website zu verleiten und anzugreifen. Da der Internet Explorer in allen Windows-Versionen samt der Scripting Engine dabei ist, wäre das potenziell ein wirksamer Angriffsvektor.
Ausnutzbarkeit ist begrenzt
Glück für Microsoft bzw. die Windows-Anwender ist aber, dass die Ausnutzbarkeit dieser Schwachstelle begrenzt ist. Standardmäßig verwendet der Internet Explorer in den Versionen 9, 10 und 11 die Scripting Engine aus der Datei Jscript9.dll, die aber von dieser Sicherheitsanfälligkeit nicht betroffen ist. Es sind nur bestimmte Websites betroffen, die JScript als Scripting Engine verwenden – was aber einen Angreifer nicht davon abhalten wird, eine Website mit entsprechenden JScript-Objekten zu präparieren.
Microsoft stuft die Schwachstelle, die in allen unterstützten Windows-Systemen existiert, daher für einige Windows-Versionen zwar als kritisch ein, aber ganz so kritisch ist es dann doch wiederum nicht. Denn standardmäßig wird Internet Explorer unter Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016 und Windows Server 2019 in einem eingeschränkten Modus ausgeführt.
Solange Administratoren diesen erweiterten Sicherheitsschutz (Geschützter Modus) im Rahmen der Enhanced Security Configuration in den IE-Optionen nicht deaktivieren, werden externe Webseiten in einer eigenen Internetzone behandelt. Im eingeschränkten Modus gilt für externe Webseiten eine niedrige Verbindlichkeitsstufe, die das Ausführen von Programmen verhindert. Das verringert die Wahrscheinlichkeit, dass ein Benutzer oder Administrator speziell gestaltete Webinhalte im Internet Explorer herunterlädt und ausführt. Das setzt aber voraus, dass (eventuell kompromittierte) Websites im Internet Explorer nicht zur Zone der vertrauenswürdigen Sites hinzugefügt werden.
Workaround: die Scripting-Engine deaktiveren
Da aktuell kein Sicherheitsupdate für diese Schwachstelle vorliegt und diese teilweise als kritisch bewertet wird, hat Microsoft vorsorglich als Workaround eine Anleitung zur Deaktivierung der Scripting Engine in der Datei JScript.dll veröffentlicht. Dazu sind bei einem 32-Bit-Windows folgende Befehle in einer administrativen Eingabeaufforderung auszuführen:
takeown /f %windir%\system32\jscript.dll
cacls %windir%\system32\jscript.dll /E /P jeder:N
Bei einem 64-Bit-Windows sind die folgenden vier Befehle in einer administrativen Eingabeaufforderung auszuführen:
takeown /f %windir%\syswow64\jscript.dll
cacls %windir%\syswow64\jscript.dll /E /P jeder:N
takeown /f %windir%\system32\jscript.dll
cacls %windir%\system32\jscript.dll /E /P jeder:N
Es empfiehlt sich, die Befehlsfolge per Editor in eine .bat-Datei zu speichern und dann am Ende noch einen pause-Befehl einzufügen. Dann lässt sich die Batch-Datei über den Kontextmenübefehl "Als Administrator ausführen" starten und das Fenster der Eingabeaufforderung bleibt geöffnet, bis eine Taste gedrückt wird. So lässt sich die Statusanzeige jedes Befehls kontrollieren.
Lokalisierungen beachten
Die Anweisungen entziehen Windows die Berechtigung, die jscript.dll für die Benutzer auszuführen. An dieser Stelle noch der Hinweis, dass die von Microsoft im Advisory ADV200001 auf einem deutschsprachigen Windows meist nicht funktionieren. Microsoft hat beim cacls-Befehl nämlich eine Lokalisierung vorgenommen. Gegenüber den von Microsoft im Sicherheitshinweis veröffentlichten Ausführungen enthalten die obigen Befehle eine Modifikation des Autors für deutsche Windows-Varianten.
Die von Microsoft für ein englischsprachiges Windows verwendete Option everyone führt in einem deutschsprachigen Windows zu einem Fehler ‘“Zuordnungen von Kontennamen und Sicherheitskennungen wurden nicht durchgeführt.”. Dann muss in einem deutschen Windows das Attribut jeder (statt everyone) im Befehl verwendet werden, damit die Anweisung akzeptiert wird.
Sobald Microsoft einen Patch für die Schwachstelle veröffentlicht hat, kann die Scripting-Engine jscript.dll wieder freigegeben werden. Die entsprechenden Befehle sind unter ADV200001 aufgeführt, wobei auch dort in einem deutschen Windows das Attribut everyone in den Befehlen durch jeder zu ersetzen ist.
Quelle; heise
