CVE-2026-39031 : Récupération de mot de passe Lansweeper lsrunase 2.0 / lsencrypt 2.0

Résumé

Les outils lsrunase 2.0 et lsencrypt 2.0 de Lansweeper utilisent un schéma de chiffrement de mot de passe réversible basé sur RC4. La clé RC4 est dérivée d'un préfixe de 8 caractères stocké en clair avec le mot de passe chiffré, et d'un matériel de clé fixe intégré dans les binaires.

Toute personne disposant d'une chaîne de mot de passe chiffrée produite par l'un de ces deux outils peut retrouver le mot de passe en clair hors ligne. Le processus de récupération ne nécessite aucune force brute : il suffit de séparer le préfixe en clair de la valeur chiffrée, de reconstruire le tampon de clé, de calculer une empreinte SHA-1 et de déchiffrer un texte chiffré RC4.

Ce problème a reçu l'identifiant CVE-2026-39031. Les enregistrements publics CVE et NVD peuvent ne pas apparaître avant la publication de la divulgation et la fin de la propagation des enregistrements.

Produits concernés

Le composant concerné est la routine de chiffrement de mot de passe utilisée par lsrunase.exe 2.0 et lsencrypt.exe 2.0.

Différence par rapport aux anciens problèmes LSrunasE

Il ne s'agit pas de l'ancien problème LSrunasE / Supercrypt référencé sous le nom CVE-2007-6340. Cette ancienne CVE concernait Geert Moernaut LSrunasE 1.0 et Supercrypt 1.0.

CVE-2026-39031 couvre spécifiquement Lansweeper lsrunase 2.0 et lsencrypt 2.0. La construction vulnérable est différente : ces binaires dérivent la clé RC4 d'un préfixe en clair de 8 caractères suivi d'un suffixe fixe de 142 octets intégré dans les binaires.

Détails techniques

Une valeur de mot de passe chiffrée est construite comme suit :

8-character prefix || base64(RC4(plaintext password))

Le processus de chiffrement est le suivant :

1. Générer un préfixe ASCII de 8 caractères dans la plage 0x3f à 0x7e.
2. Construire un tampon de clé de 150 octets à partir du préfixe de 8 octets suivi d'un suffixe fixe de 142 octets intégré dans le binaire.
3. Calculer SHA1(key_buffer) pour produire la clé RC4 de 20 octets.
4. Chiffrer le mot de passe en clair avec RC4.
5. Encoder en Base64 le texte chiffré RC4.
6. Préfixer la sortie Base64 avec le préfixe original de 8 caractères.

Le suffixe fixe de 142 octets est :

0x27 0x0F 0x29 0x11 0x2B 0x13 0x2D 0x15
0x2F 0x17 0x31 0x19 0x33 0x1B 0x35 0x1D
0x37 0x1F 0x39 0x21 0x3B 0x23 0x3D 0x25
0x3F 0x27 0x41 0x29 0x43 0x2B 0x45 0x2D
0x47 0x2F 0x49 0x31 0x4B 0x33 0x4D 0x35
0x4F 0x37 0x51 0x39 0x53 0x3B 0x55 0x3D
0x57 0x3F 0x59 0x41 0x5B 0x43 0x5D 0x45
0x5F 0x47 0x61 0x49 0x63 0x4B 0x65 0x4D
0x67 0x4F 0x69 0x51 0x6B 0x53 0x6D 0x55
0x6F 0x57 0x71 0x59 0x73 0x5B 0x75 0x5D
0x77 0x5F 0x79 0x61 0x7B 0x63 0x7D 0x65
0x7F 0x67 0x81 0x69 0x83 0x6B 0x85 0x6D
0x87 0x6F 0x89 0x71 0x8B 0x73 0x8D 0x75
0x8F 0x77 0x91 0x79 0x93 0x7B 0x95 0x7D
0x97 0x7F 0x99 0x81 0x9B 0x83 0x9D 0x85
0x9F 0x87 0xA1 0x89 0xA3 0x8B 0xA5 0x8D
0xA7 0x8F 0xA9 0x91 0xAB 0x93 0xAD 0x95
0xAF 0x97 0xB1 0x99 0xB3 0x9B

Puisque le préfixe est stocké en clair et que le reste du matériel de clé est fixe quelle que soit l'installation, toutes les informations nécessaires pour dériver la clé RC4 sont disponibles pour un attaquant qui dispose d'une chaîne de mot de passe chiffrée et d'une copie du binaire ou de cette analyse.

Preuve de concept

Le script de preuve de concept n'a aucune dépendance tierce et fonctionne avec Python 3.

$ python lsrunase2cve.py --decrypt "IssS|CI|NTOEHK5Q9l7Sn89xEA67+wo="
Decrypted: testpassword12345

La valeur chiffrée ci-dessus a été générée par l'interface graphique LSrunasE 2.0 password encrypter 2.0 pour la valeur en clair testpassword12345.

Pour une vérification de chiffrement reproductible avec le même préfixe :

$ python lsrunase2cve.py --encrypt "testpassword12345" --prefix "IssS|CI|"
Encrypted: IssS|CI|NTOEHK5Q9l7Sn89xEA67+wo=

Impact

Un attaquant ayant un accès local à une valeur de mot de passe chiffrée produite par lsrunase 2.0 ou lsencrypt 2.0 peut retrouver le mot de passe en clair hors ligne.

Selon la manière dont les outils sont déployés, les identifiants récupérés peuvent permettre :

• L'élévation de privilèges par l'utilisation d'identifiants administratifs stockés.
• Le mouvement latéral vers des systèmes où le compte récupéré est valide.
• La réutilisation des identifiants récupérés contre d'autres services.
• Le déchiffrement rétroactif de chaînes de mot de passe chiffrées précédemment capturées ou sauvegardées.

Cause racine

Le problème est causé par plusieurs défauts de conception cryptographique dans le schéma de protection des mots de passe :

• RC4 est utilisé pour le chiffrement.
• Le matériel de clé secret effectif est intégré dans les binaires.
• Le préfixe aléatoire est stocké en clair avec le texte chiffré.
• SHA-1 est utilisé comme étape de dérivation de clé en une seule passe.
• Il n'existe aucun secret propre à l'installation ou à l'utilisateur.
• Les mots de passe sont stockés sous une forme réversible.

Les catégories de faiblesses pertinentes sont notamment :

• CWE-321 : Utilisation d'une clé cryptographique codée en dur
• CWE-326 : Force de chiffrement inadéquate
• CWE-327 : Utilisation d'un algorithme cryptographique cassé ou risqué

Calendrier de divulgation

Références

• Enregistrement CVE, publication publique en attente : https://www.cve.org/CVERecord?id=CVE-2026-39031
• Enregistrement NVD, publication publique en attente : https://nvd.nist.gov/vuln/detail/CVE-2026-39031
• CWE-321 : https://cwe.mitre.org/data/definitions/321.html
• CWE-326 : https://cwe.mitre.org/data/definitions/326.html
• CWE-327 : https://cwe.mitre.org/data/definitions/327.html
• RFC 7465, "Prohibiting RC4 Cipher Suites" : https://datatracker.ietf.org/doc/html/rfc7465
• Ancien enregistrement distinct CVE-2007-6340 : https://nvd.nist.gov/vuln/detail/CVE-2007-6340