Siemens Software Center : un exécutable signé chargeait la DLL de l’attaquant

Avis Siemens du 15 octobre 2026, exploitation confirmée le 19. Siemens ProductCERT décrit une campagne qui utilisait une vraie copie signée de Siemens Software Center, accompagnée de DLL fournies par l’attaquant dans le même dossier. La version vulnérable cherchait des bibliothèques auxiliaires dans un chemin insuffisamment contrôlé et chargeait ces fichiers lors du démarrage. CVE-2026-110936 n’est donc pas une compromission du canal de mise à jour de Siemens : c’est l’abus d’une décision de chargement prise par un programme légitime.

Ce que garantit une signature, et ce qu’elle ne garantit pas

La signature d’un exécutable permet d’en vérifier l’éditeur et l’intégrité. Elle ne signe pas automatiquement tous les fichiers présents dans le répertoire où l’utilisateur l’exécute. Sur Windows, lorsqu’un programme demande une DLL par son nom sans fixer une provenance sûre, le chargeur cherche dans une série d’emplacements. Si un dossier contrôlé par l’attaquant intervient dans cette recherche, une DLL portant le nom attendu peut être chargée sous l’identité du programme. Le code malveillant s’exécute alors avec ses privilèges.

Dans l’avis de vulnérabilité, Siemens qualifie formellement la condition de locale et indique qu’un acteur authentifié capable de placer une DLL dans le chemin recherché peut obtenir l’exécution de code. Dans la campagne observée, le contexte pratique était différent : les attaquants distribuaient ensemble le programme signé et leurs fichiers, puis poussaient l’utilisateur à exécuter ce paquet par une manœuvre ClickFix. Cette ingénierie sociale explique comment ils satisfaisaient la condition de placement sans devoir altérer le binaire Siemens lui-même. Il faut distinguer cette distribution malveillante du scénario CVSS local de la CVE.

La frontière de confiance exacte

Le moment décisif n’est pas le téléchargement du logiciel signé, mais l’appel de chargement de bibliothèque. La version 3.5.8.7, décrite par Siemens comme version utilisée par la campagne, chargeait des fichiers auxiliaires depuis son propre dossier sans vérifier suffisamment ce qu’ils étaient. Un dossier choisi par l’attaquant devient ainsi une source de code pour un processus de confiance. Les noms de fichiers observés dans la campagne et les indicateurs figurent dans le rapport Siemens, mais l’article n’a pas besoin d’inférer que toutes les DLL placées à côté du binaire auraient le même effet : le comportement dépend du nom effectivement recherché.

Un audit autorisé peut utiliser un moniteur de chargement de modules pour relever le chemin de chaque DLL ouverte par le programme, puis comparer le comportement dans un dossier système protégé et dans un dossier modifiable. Le test négatif consiste à montrer que le programme corrigé refuse ou évite la DLL étrangère. Le danger se mesure aussi à la provenance du processus : un exécutable Siemens lancé depuis AppData sur un poste où le logiciel n’était pas installé est un signal différent de la même signature de fichier dans le dossier officiel.

Vérification et réponse

Siemens fixe le seuil corrigé à 4.0.9.8 et indique que les installations existantes se mettent à jour au prochain démarrage. Il précise qu’aucun système, produit ou canal de mise à jour Siemens n’était compromis à sa connaissance. Les équipes doivent donc vérifier la version, l’emplacement du binaire lancé, les DLL adjacentes et les mécanismes de démarrage automatique. Une détection limitée à la signature de l’exécutable ne distinguera pas le paquet hostile d’une copie authentique.

Cette affaire explique pourquoi « fichier signé » et « processus sûr » ne sont pas synonymes : la confiance dans le binaire doit être prolongée jusqu’aux dépendances qu’il charge et au répertoire depuis lequel il est exécuté.

Sources principales : avis Siemens SSA-580366, rapport Siemens sur l’exploitation active.