Ein Exploit in einem bisher nicht identifizierten ActiveX-Control und ein möglicher Tippfehler sind das Thema dieses Standpunkt Sicherheit.

Und so beginnt es...

Roger Thompson von AVG berichtet über einen Exploit, der eine Schwachstelle in einem bisher unbekannten ActiveX-Control ausnutzen soll. Der Exploit wurde in einem chinesischen Exploit-Kit gefunden, auf den eine für Drive-by-Infektionen präparierte harmlose Website verwies. Das besondere daran: Eine Google-Suche nach der CLSID des Controls, '0955AC62-BF2E-4CBA-A2B9-A63F772D46', erbrachte kein Ergebnis, inzwischen findet man damit Thompsons Blogeintrag. Die einzige Information, die Thompson bisher gefunden hat, ist ein zugehöriger Name: BDATuner.MPEG2TuneRequest, und der führt zur Schwachstelle im Microsoft Video ActiveX-Control und damit zu den Schwachstellen in der Active Template Library (ATL), durch die das Killbit im Internet Explorer wirkungslos wird.

Dazu ein Zitat aus dem Standpunkt Sicherheit der vorigen Woche, in dem es um die Schwachstellen in der Active Template Library (ATL) ging:

Betrachten wir die Schwachstellen doch mal genauer: Wir haben zwei, die das Einschleusen von Code erlauben und für die Microsoft selbst mit funktionierendem Exploitcode rechnet. Und eine davon erlaubt nebenbei noch das Umgehen des Killbits. Das ist doch ein gefundenes Fressen für jeden Cyberkriminellen, der sich mit Drive-by-Infektionen beschäftigt: Erst das Killbit umgehen, dann Schadcode einschleusen, und das in einem Durchgang. Was ihm zu seinem Glück noch fehlt, sind betroffene ActiveX-Controls.

Allen Anschein nach hat AVG das erste solche ActiveX-Control entdeckt, bzw. genauer: Den Exploit dafür, denn das betreffende Control ist ja noch nicht bekannt. Und was jetzt? Da über das Control so wenig heraus zu finden ist, scheint es nicht sehr weit verbreitet zu sein. Dann stellt sich nur die Frage, wieso die Cyberkriminellen sich die Mühe machen, einen Exploit dafür in ihren Exploit-Kit aufzunehmen. Logische Schlussfolgerung (sofern das Control nicht so selten ist, dass wir es mit einem gezielten Angriff zu tun haben): Das Control ist weiter verbreitet, als es den Anschein hat. Vielleicht nur in China, da es sich um ein chinesisches Exploit-Kit handelt, aber wo die Rechner stehen, die die Cyberkriminellen ihren Botnets hinzufügen, ist ziemlich egal.

Aber wühlen wir mal ein bisschen weiter...

Kaufe ein C und ein F

Die CLSID des von AVG gesuchten Controls wird von Google nicht gefunden. Bei der Suche nach BDATuner.MPEG2TuneRequest landet man bei der Schwachstelle im Microsoft Video ActiveX-Control, das aber eine andere CLSID hat,
'0955AC62-BF2E-4CBA-A2B9-A63F772D46CF' statt der gesuchten
'0955AC62-BF2E-4CBA-A2B9-A63F772D46'.

Oh, was ist das denn? So direkt untereinander sieht das doch ziemlich gleich aus. Ich gebe es zu: Ich habe keine Ahnung, wie die CLSID gebildet werden, und habe darum mal kurz Google bemüht. Und da erfahre ich folgendes:

Eine CLSID ist ein 16-byte Wert, welcher 32 hexadezimal Ziffern enthält. Diese Ziffern sind in Gruppen angeordnet: 8-4-4-4-12 ...

Und bei der von AVG gesuchten CLSID komme ich auf 8-4-4-10, demnach wäre das gar keine vollständige CLSID.

Glück braucht der Mensch!

Mit etwas Glück haben wir es also nur mit einem Tippfehler im Exploit zu tun, und die chinesischen Cyberkriminellen versuchen, die inzwischen behobene Schwachstelle im Microsoft Video ActiveX-Control mit einem der bereits bekannten Exploits oder einer Modifikation davon auszunutzen.

Es könnte aber auch sein, das der Tippfehler ein Copy-Paste-Fehler von Roger Thompson ist und es ein bisher unbekanntes ActiveX-Control mit einer ähnlichen CLSID wie der des Microsoft Video ActiveX-Control gibt.

Es gäbe noch eine dritte Möglichkeit, aber die trifft hoffentlich nicht zu: Die Schwachstelle im Microsoft Video ActiveX-Control wird dadurch behoben, das für die betroffenen CLSIDs das Kill-Bit gesetzt wird. Ein Eintrag in Microsofts Security Research & Defense Blog zu den ATL-Schwachstellen sagt dazu folgendes aus:

Was the msvidctl vulnerability (MS09-032) related to this ATL update?

First of all, the kill bits issued by the July release for msvidctl (MS09-032) will block the public exploits of msvidctl as stated here.

This public exploit took advantage of the fact that msvidctl uses a modified version of vulnerable ATL headers which is not in the public version. The vulnerabilities exploited in this attack are found in the private versions of ATL, as described in Security Advisory 973882. In this specific instance, the vulnerability allows an attacker to corrupt memory which may lead to a remote code execution. For more information on this specific issue see Michael Howard’s “Bug 1” in his SDL Blog Post.

Das gesetzte Killbit schützt also nur vor der Ausnutzung der Schwachstelle durch die damals bekannten Exploits. Und wir wissen ja inzwischen, dass das Killbit im Internet Explorer wirkungslos ist. Was ist, wenn es sich um einen Tippfehler der Cyberkriminellen handelt - und um einen neuen Exploit, der das gesetzte Killbit umgeht? Zum Glück geht der Eintrag in Microsofts Security Research & Defense Blog noch weiter:

Will the IE update that helps protect against the ATL issues also protect against msvidctl attacks?

Even without the kill-bits from MS09-032, the IE mitigations in MS09-034 will help protect against the exploitation of all the ATL vulnerabilities that are described and fixed in the Visual Studio bulletin. That said, we highly encourage you to not remove MS09-032 and keep your machine fully updated.

Wer also die Patches zum Security Bulletin MS09-034 installiert hat, wird durch die damit implementierten Defense-in-depth-Maßnahmen (hoffentlich) geschützt. Wer die Patches noch nicht installiert hat, sollte das jetzt schleunigst nachholen.

Des Rätsels Lösung?

Ich habe in einen Kommentar unter Roger Thompsons Blogeintrag auf die auffällige Übereinstimmung bei den CLSIDs hingewiesen. Wenn der moderiert wird, klärt sich das ganze ja vielleicht schnell auf.

Carsten Eilers