印度程序员的骚操作,昨天差点炸了全球互联网

过去两天,或许是全球互联网最“齐心”的一段时期——大量网站紧急维护,众多游戏宣布停服,各方纷纷闭门修补漏洞。

其中一个原因,你大概也能猜到,跟 PHP(一种 Web 开发语言)的漏洞有关。就连日本政府都专门为此发了一篇帖子。

要知道,这可是连黑客都当“新手村”刷的日本,连他们都急了,可见事态有多紧迫。

我还看到有段子说,这几天歇业整顿的日料才是最新鲜的,这下不得不去吃寿司郎了。(开个玩笑)

此外,日本游戏和二次元领域也是这次维护潮的重灾区,因为不少游戏的登录系统、商城、数据接口都依赖 PHP。

比如《最终幻想14》国服,用旧版启动器暂时登不上是正常的,换成新版启动器或 WeGame 就能进去。

所以说,那些用 PHP 的团队这几天恐怕得通宵打补丁了。

玩笑归玩笑,PHP 这次的漏洞确实不是小事。

作为一种广泛应用于网站开发和 Web 后端的编程语言,PHP 的存在感远超许多人的想象。

不仅全球大约 70% 的网站都在使用 PHP,而且这次发现的两个漏洞,危险程度直接拉满。根据 PHP 的官方安全公告,该漏洞的 CVSS 评分(通用漏洞评分系统,满分 10 分)高达 9.2 分。

这属于无需身份验证即可远程执行代码(RCE)的危险漏洞。轻则网站内容被篡改、用户数据遭窃取,重则服务器直接被控制,甚至整个服务瘫痪。

好在目前来看,情况并未失控。

PHP 开发团队已经紧急发布了修复补丁。对于那些来不及打补丁的系统,部分机构选择直接拔掉网线——在修好之前,最安全的网站就是暂时不存在的网站。

但话说回来,“PHP 漏洞”至少还有比较明确的应对方法。

而这两天互联网上爆出的另一个 bug,解决起来就真没个头了。因为它不是官方打一轮补丁就能解决的,甚至在某种程度上,需要我们自己排查解决。

没错,可能有些朋友也听说了,一家印度公司把他们的互联网数字证书的私钥值(相当于证书的密码),设置成了“4”、“56”、“155”等几个类似的小于 255 的数字。

更麻烦的是,这批有问题的证书已经进入了全球互联网的信任体系,对我们的影响也非常大。比如,即便事情已经过去 6 天,微信客户端内置的浏览器竟然还能连接到有问题的 emsign 数字证书。

这里需要稍微解释一下,互联网是一张网没错,但我们的手机连接到网站/APP/服务器,并不是直接拉一根线过去,中间需要无数交换机、路由器作为节点来跳转,代为传输数据包。

在传统的网络流量环境下,中间的任何一个节点如果被安插了恶意软件,都可以在你毫不知情的情况下偷偷监听你和网站之间传输的明文数据。

为了解决这个问题,现代互联网引入了数字证书对流量进行加密。只要你的浏览器提示连接是安全的,就代表这段通信是加密的。

只有你和最终收到信息的服务器,才能看到数据的明文。中间的每一跳、每个路由节点只能代为转发——它们只知道自己转发了一个数据包,但无法查看具体内容。

这套加密体系叫 TLS。为了保障这套体系顺畅运行,需要有一个绝对可信的第三方机构充当中间人,为网站颁发数字证书——具体怎么回事,大家可以问问豆包。限于篇幅,这里就不展开了。

然后问题来了,这次事件的主角 eMudhra,就是其中一家“中间人”机构。它手里攥着中间 CA 证书,可以为几乎任何网站签发数字证书,并且签发的证书被所有联网设备信任。

结果这些“中间人证书”自己的私钥出了问题。凡是掌握了这次漏洞的人,都能以 eMudhra 的身份给任何网站签发证书。即使是假网站,也能拥有一张合法可信的证书。

理论上,eMudhra 这批证书的私钥长达 384 位,有 2³⁸⁴ 种组合。正常情况下,暴力破解几千、几万亿次都无法命中。

但根据安全员的报告,eMudhra 这次的私钥,前面的字节全部设置成了 0,直到最后一个字节才开始有实际的熵,也就是随机数。1 个字节能储存的数字,对应到十进制,就只剩 256 种可能了。

换句话说,从 1 开始一个数字一个数字地试,最多试 255 次,就可能拿到私钥。更让人无语的是,其中一个私钥竟然就是数字 4。

而且顺着出事的 CA 证书往上查,你会发现 eMudhra 还跟一些老牌根证书机构进行过全球交叉签名认证。也就是说,通过这些几乎不设防的中间证书,攻击者能进一步把手伸到全球互联网的其他角落。

如果你的浏览器、手头的设备用的还是公告里说的旧证书,那么别人就有机会通过伪造数字证书,躲在你网络的上层节点中,拦截你的通信流量,窃取你的数据。

他们不仅可以监听你所有的聊天记录、生活轨迹,甚至对一些加密较弱的场景,还能伪造虚假数据。比如正常使用 app 时突然弹出一个“你中奖了”的提示,如果你信了,就可能被骗。

所以,10 月 21 日事件公开发酵后,eMudhra 股价在印度市场直接触发 20% 的跌停。

漏洞一经曝光,各大浏览器和根证书项目也立刻进入了“拔网线”模式——

最早从 17 号开始,Chrome、Firefox、苹果、微软这些公司就已经在系统层面停止信任 eMudhra 旗下的相关证书。Google 甚至宣布把签发这些中间 CA 的根证书,从 Chrome 的受信任根证书库中移除。

如果你不放心,有个叫 emudhra.we-have-a-problem 的网站,可以测试你的浏览器有没有中招。

我试了一圈,发现苹果在 21 号已经在系统层面(Safari)撤销了全部证书支持(22 号恢复了三个),Firefox 则完全撤销了 12 个证书的信任。微信在这方面确实慢了一拍。

除了这一点,我之所以说“互联网证书”导致的问题最后需要我们自己自查自修,是因为上面这些大公司的操作只能保证你的手机、电脑是安全的。

实际上,在我们的互联网环境里,还有大量服务器、物联网设备和后台程序,并没有 Chrome、Firefox 那种独立的证书黑名单热更新机制。

举个例子,我们家里的摄像头、闺蜜机、智能音箱,普遍依赖 Linux 系统里的 CA certificate 包、软件自带的 CA 信任库,或者固件里预置的根证书。

换句话说,如果运维人员不更新系统或推送固件,一些老 Linux、嵌入式 IoT、工控设备和无人维护的内网服务器,还会信任已经出问题的证书,相当于顶着被劫持的风险裸奔。

这种信任库的遗留问题,收尾过程会非常漫长。全球数不清的跨国供应链、老旧服务器、物联网设备,估计后面有的忙了。

而更让人无语的是,这么大篓子,源头可能只是一次非常低级的人为失误。

eMudhra 数字证书这事,最新的说法是 eMudhra 的技术人员“手滑”了——用于迁移测试的弱密钥,在迁移完成之后忘了换,最后流入了生产环境。真是让人气得咬牙切齿。

虽说印度这次的事情可能只是人为操作的问题,但后来 OpenAI 出来认领,说 PHP 的高危漏洞是 ChatGPT 协助发现的。

而且目前的 PHP 问题,只是他们已经找到、正在协调修复的多个重大漏洞中的一部分。更大的“惊吓”还在后面。

过去,一些漏洞可能藏在代码里十几年都没人发现。现在,我们进入了技术发展最快的时代,发现它们的门槛正在降低,接下来整个互联网安全领域恐怕都不会太平静。

对于普通用户来说,保持浏览器、系统以及常用应用的更新,可以避开绝大多数问题。

但是,如果家里的物联网设备比较多、日常生活和科技绑定得比较深的话,那我确实建议,大家多关注安全方面的消息,让自己少一些可以被攻击的暴露面。