比利时八成银行都在用的电子签名工具，被我们找到了一个能直接控制你电脑的漏洞

幻泉之洲

2026年8月11日 10:16
北京

在小说阅读器读本章

去阅读

Connective签名扩展是比利时电子身份证（eID）生态的核心组件，覆盖200多万用户、8家头部银行和60多个政府机构。我们在这套系统里挖出了一连串致命漏洞：任何网站都能静默读取你的eID和银行卡数据、截获PIN码并在本地解密、甚至通过加载恶意DLL实现远程代码执行。从发现到完整修复，花了146天。

先说这东西是什么

Connective签名系统由两部分组成：浏览器扩展和本地程序。网站通过扩展发消息给本地程序，本地程序再跟读卡器里的eID或Maestro银行卡通信，完成数字签名、身份认证这些操作。扩展本身很薄，就是个传话筒，所有消息原样转发。根据2021年的数据，这套系统覆盖了比利时60多个政府服务、超过1000家企业。Chrome Web Store和Edge商店的用户量确实破了200万，这个数字我们能确认。

▲ 一张用于测试的模拟eID卡

为什么会盯上它

我们的自动化扫描系统把Connective扩展揪了出来，原因是它转发消息时从不携带请求来源（origin）。这意味着本地程序根本不知道跟自己说话的是哪个网站。这个设计本身就很可疑。我们还发现几乎所有操作都需要一个叫activationToken的东西，只有查看版本号不需要。但这个token同样跟来源域名毫无绑定，任何网页只要拿到一个有效token，就能在用户机器上为所欲为。Connective当时只是我们的扫描测试数据，没想到越挖越深。

那个号称保护系统的Token，形同虚设

activationToken是合作网站用来向Connective系统证明\"我有权限使用你的功能\"的凭证，用RSA 2048签名。解码后长这样：

{
\"token\": \"b138fcf4-4619-47eb-846a-dc9cbeb7714d\",
\"ttl\": 1773811513534,
\"features\": 7
}

里面一个UUID（没见它起过作用）、一个有效期（TTL）、一个功能位掩码（features）。位掩码控制哪些操作被允许：bit 0管读卡、验证PIN、签名这些核心功能，bit 2管Maestro银行卡操作。我们从Doccle.be拿到了测试token——全部功能开放，有效期24小时。关键是这token里没有任何域名限制。你拿到了，就等于拿到了用户机器上Connective系统的万能钥匙。

读你的eID和银行卡，无需任何授权

有了不绑域名的activationToken，任何网站或iframe都能在用户毫无察觉的情况下读取连接的eID和银行卡数据。但这还算轻的。真正离谱的是PIN码的处理方式。

PIN码？直接送给网页了

当我们搞清楚pinToken的机制时，意识到这已经不是某个开发者的疏忽了，而是整个设计都没有安全常识。用户在Connective弹出的PIN输入框里输入密码后，本地程序会生成一个pinToken，通过扩展原样传给网页。网页能直接拿到这个token。

▲ 攻击者完全控制弹窗的标题和提示文字，用户看到的是跟正规场景一模一样的界面

更魔幻的是，这个pinToken的结构直接暴露了PIN码。一个样本pinToken：

Z0WLa8YjezJpmDxkc0gzZlHcsHT/XEkZSpToKuxYVWLh+AAByPpJIGoAP3VlbtC0

解码过程简单到令人发指。Base64解码后得到48字节，前32个字节的偶数位（0、2、4……30）是AES-128密钥，后16字节是密文。IV是硬编码在二进制里的16个0xA6。解密后直接拿到明文PIN：4、2、0、6、9。是的，他们把加密密钥和密文打包在一起，用固定IV，然后把这个包直接交给了网页。

这意味着什么？任何网站弹个框骗你输一次PIN，不光当时能用，之后只要你的eID还插在电脑上，他们就能随时用这个PIN伪造签名。房屋抵押贷款文件？政府税务账户登录？全部可以。eID的非抵赖签名在法律上等同于白纸黑字的亲笔签名，一旦被伪造，你得自己举证不是自己签的。

▲ 我们当时都惊了

这怎么把整个比利时eID生态给掀了的

比利时eID体系建立在一个核心假设上：你的PIN只会交给你主动选择运行的软件，你的密钥只会用于你真正想要签名的东西。这个假设一破，下游所有依赖全部崩塌。eIDAS合格签名（法律效力等同纸质签名）、政府签发的身份数据文件（全名、国籍注册号、地址）——全部可以被攻击者获取并滥用。用户甚至不需要访问恶意网站，一个广告iframe或被注入的追踪脚本就能完成所有操作。

itsme账户也能被接管

itsme是比利时事实上的身份认证层，网上银行、税务、社保、养老金都靠它登录。创建itsme账户的方式之一是用eID在网站上签署服务条款——用的恰恰就是Connective插件。签名完成身份核验后，剩下的步骤只是输入激活码和短信验证码，把已验证的身份绑定到某部手机上。

▲ 我们在iframe中模拟的恶意广告

那绑到我们的手机上呢？itsme的帮助页面写了两件事：封锁一个itsme账户不需要任何认证，只要输入手机号和证件上的名字（手机号从数据中介那里随便买）；账户被封锁后，可以用eID在网站上重新激活并绑定新号码。攻击者拿到的不是一个临时会话，而是一个能永久使用的、受害者名下的itsme账户。浏览器关了、eID拔了、漏洞修了，都不影响。我们还没有直接用itsme做完整测试，但已经在依赖eID认证的CSAM.be上复现了账户接管。itsme本身没做错任何事，整个体系依赖QTSP（合格信任服务提供商）是真正合格。Connective / Nitro Software Belgium就是eIDAS信任名单上的QTSP，最高信任等级。itsme也是eIDAS认证的\"高\"保证级别。这些攻击场景的根源全部在Connective身上。

一个合理的问题：这些问题存在多久了？很可能从这套扩展和本地程序诞生第一天起就有了，但因为缺乏历史数据，我们没法确证。Connective声称每年都做渗透测试。说真的，如果不是在SOC 2合规检查表上用签字笔画圈圈，我们很好奇这些测试到底测了什么。挖出这些问题不需要什么高级AI模型，只需要有基本安全能力的人认真看一眼。我们用的是Opus 4.[5-7]辅助分析，因为Connective系统本来就是我们自动化分析平台的测试素材。

▲ Connective官网上关于\"每年进行渗透测试\"的声明（2022年存档）

远程代码执行：下载个PDF，你的电脑就被控了

在遍历所有可调用命令时，我们发现了GET_READERS命令的一个参数：library。这个参数允许网页指定要加载哪个DLL，而且支持相对路径。

{
\"cmd\": \"GET\_READERS\",
\"library\": \"..\\..\\..\\..\\Downloads\\lib.dll\"
}

唯一限制是路径里必须包含.dll。Chrome会自动拦截.dll扩展名的下载，所以我们不能用常规方法让用户下载恶意DLL。但可以用一个多格式文件，命名为frien.dlly_reminder.pdf，浏览器只会看到PDF。因为Connecting安装在AppData下，相对路径可以一路回溯到Downloads文件夹执行这个库。整个过程用户只看到一个PDF下载，Chrome沙箱已被突破。这是我们认为最严重的发现——无需任何特殊配置，无需用户做任何高危操作，只要装了这套扩展并访问一个恶意页面，就能实现远程代码执行。场景上甚至可以做蠕虫式传播：偷session、发钓鱼链接给联系人，让其他人也中招。

修复过程：拖了146天

Nitro在2026年5月8日推出了第一版修复，通过远程服务器验证请求来源，只有已批准的网站才能发送命令。但这没解决RCE和pinToken泄露的问题，只是把攻击面限制在了\"已批准网站\"的范围内。5月19日，Nitro联系我们请求推迟公开披露。同一天我们明确指出修复不完整，library命令原封未动、pinToken仍然能被传给网页，并给出了具体修复建议。完整补丁6月1日发布，禁用了library命令，并把pinToken缓存到扩展内部，只给网站一个随机UUID来引用PIN。7月22日，远程来源检查强制执行，终于阻止了任何网站静默读取eID和钓鱼获取PIN。说句公道话，Nitro确实有安全联系邮箱、没拿漏洞赏金程序逼我们签NDA、回应了、没否认事实。但响应速度实在太慢。修好了总比我们现在还在交锋的其他厂商强。问起赏金，他们给了200美元。

这行当的问题不止这一家

▲ 有类似问题的扩展和本地程序远不止Connective一家

还有大量扩展把本地程序通信桥直接暴露给任意网站，影响范围从几十家到上百家银行。真正让人觉得荒诞的是，Connective是eIDAS信任名单上的QTSP（合格信任服务提供商），标准要求的\"合格\"到底体现在哪？如果连比利时最大的eID签名扩展——Chrome Web Store上用户最多的那个——都能漏成这样，说明整个认证体系的安全审查基本是走过场。我们需要明确规定QTSP必须接受有能力的渗透测试，而不是自说自话的合规自查。感谢比利时网络安全中心（CCB）批准在安全港条款保护下发布这系列漏洞。漏洞利用代码在GitHub上[1]，你也可以用我们的免费扫描器[2]检查自己装的扩展在干什么，或者用企业版[3]看看公司整体暴露了多少风险。