^-^【tl;dr 省流版】
北京时间6月26日下午,我们的网站遭遇了约 47分钟 的访问异常。经技术团队严密排查与逻辑推导,目前倾向于推测:本次事件的根源在于第三方 CDN边缘节点可能存在供应链攻击,导致了网站的访问异常,非我方源站服务器问题。 根据现有迹象推测,CDN边缘节点可能使用了弱加密/带有0day漏洞的面板/供应链攻击等“可能”的问题,导致我方的面板和一条API线路访问出现问题。请广大用户放心:我方源站及核心数据库完好无损,用户的密码、邮箱、计费等核心隐私数据均加密,完全安全,绝无泄露迹象。 目前,我们已连夜整体迁移至新的安全 CDN 链路。
^-^前言: 我是做梦都没想到可能会被CDN背刺……
一、 根因推导:为什么推测是 CDN 边缘节点及供应链问题?
事件发生后,技术团队针对所有潜在的攻击面(包括 Cloudflare DNS、外部证书单纯伪造、CDN边缘节点安全隐患)进行了深度的技术排查与逻辑排除,基于现有现象做出了以下合理推测:
1. Cloudflare(DNS解析)被黑?(已排除)
我们第一时间审计了 Cloudflare 的全量官方审计日志。结果证实,DNS 解析记录在事发期间未发生过任何越权修改,账号安全防护策略也未受触发,因此排除了 DNS 层面的劫持可能。
2. CDN 边缘节点隐患与供应链攻击?(多项迹象指向的高度疑似原因)
结合上述分析与事发期间的实际操作现象,技术团队倾向于推测故障点位于第三方分发链路。由于该第三方 CDN 边缘节点涉及特定面板管理及复杂的外部供应链组件,我们做出以下推论:
可能存在的0day或供应链污染: 我们推测,相关边缘节点服务器可能存在弱加密缺陷,或其使用的管理面板可能存在 0day漏洞,亦或是遭遇了供应链攻击。攻击者可能借此绕过了常规控制台,直接在边缘节点层面对流量实施了局部越权干预,并通过 HTTP 文件验证伪造了证书,随后在 CDN 的其他账户中重定向了流量,缓存了异常内容。
缓存刷新失效迹象: 在故障期间,我方技术团队曾多次尝试通过 CDN 控制台执行强制刷新缓存操作,但当时系统反馈无法刷新。这在一定程度上印证了边缘节点的底层配置和控制流可能已被越权锁定或处于异常状态。
控制平面下发覆盖现象: 当我方在 CDN 后台强行修改设置、开始签发并下发新证书及新配置时,原本显示篡改内容的页面逐渐转变为完全不可访问状态(报错404)。这一渐变过程在技术逻辑上清晰地表明:我方正规控制平面下发的正确配置,正在逐步强制覆盖和清洗边缘节点上的错误或恶意配置。
综上所述,我方源站完好无损,故障根源高度可能源于第三方 CDN 边缘节点的安全隐患或供应链漏洞。并且但凡我们的服务器被入侵了,当场就已经被删库了 ^-^
^-^目前我们尚无法对根因作最终定性。基于现有现象,问题更可能出现在 CDN 访问链路、边缘侧状态、证书使用或配置下发相关环节,但我们没有足够证据指向任何单一确定原因。因此,我们不会在证据不足的情况下对第三方服务商作结论性判断,也不会在本说明中披露其名称。^-^
二、如何防止同类事件再次发生呢?
为了降低类似事件再次发生的概率,我们将继续推进以下改进:
- 接入 CT Log 证书监控,发现未知证书签发时立即告警;
- 增强 CDN 配置变更、证书变更、源站变更的监控和告警;
- 进一步限制源站访问,仅允许可信回源 IP 访问;
- 优化多 API 线路容灾和快速切换能力;
- 加强日志留存、安全审计和异常检测能力;
- 已迁移到更加可控的自建链路和自建 CDN 集群。
三、事件时间线
以下时间均为 UTC+8。
时间 |
事件 |
|---|
15:45 |
事后通过 CT Log 发现,有一张非我们主动签发的 Let’s Encrypt 证书被签发,证书仅包含官网域名和受影响 API 域名。 |
16:47 |
首次收到用户反馈,官网访问异常,页面返回异常篡改内容。我们同时发现当时使用的 TLS 证书并非我们原本部署的证书。 |
16:49 |
发现其中一条 API 线路访问异常,部分大客户反馈 API 调用失败。 |
16:51 |
官网短暂自然恢复正常。此时我们已开始准备关闭相关服务器转发并进行排查。 |
16:54 |
官网再次出现异常内容,无法正常访问。 |
17:00 |
技术人员 on-call 上线,关停官网和 API 相关 Nginx 转发。但异常内容仍可被访问到,因此我们开始怀疑问题可能与 CDN 缓存、边缘节点或 CDN 侧配置有关。 |
17:11 |
开始全面排查源站服务器、面板服务器、API 转发服务器及容器环境,未发现文件被修改、异常登录或异常进程。 |
17:25 |
检查 DNS 和 CDN 控制面板。Cloudflare 仅作为 DNS 解析使用,未代理业务流量;DNS 解析未发现异常修改。CDN 控制面板中也未发现证书签发、源站修改或异常操作记录。 |
17:34 |
重新签发并部署证书,清理 CDN 缓存并重新下发配置后,官网、面板和受影响 API 线路开始恢复正常。 |
17:36 |
API 转发服务器排查完成,未发现入侵痕迹。 |
18:02 |
与 CDN 服务商完成沟通。服务商反馈其日志和源站变更记录中未发现异常操作。 |
18:29 |
完成异常证书吊销,并进一步检查数据库、业务服务、请求日志、用户数据和计费系统,未发现异常访问或泄漏迹象。 |
19:30 |
为降低再次发生风险,开始整体迁移出原 CDN 服务商。 |
|
|
^-^本次劫持的所谓“起因”,就是有人觉得所有套餐用尽后,费用扣到了余额,产生了超支,这点不合理。此方案的初心,是为了能让用户彻底用完套餐额度,不会因为套餐仅剩余0.01usd就无法用尽额度,这也是行业内的通行办法,就连小米官方的AI模型平台,也会有负余额的产生(见下图),本站内许多富可敌国也有该方案。
并且为了满足用户灵活的需求,我们也有每日0点自动重置大于-0.5的负余额部分,第二天可以不受影响,继续使用,也可以自行小额充值5元的余额,或者购买套餐来自动回正余额。

^-^目前,我们也已经上线了新功能,把选择的权利交还给用户。可自由选择套餐用尽后,是否自动用余额计费。具体请查阅新功能介绍:Krill AI
四,最后也是本片帖子的重点:Krill狂蹬节!即刻起,直接免费发双倍周额度卡,直到今日(28日)23:59分!
对所有付费套餐的用户,我们立即发放2倍于周额度的狂蹬卡~

比如你有每周900刀的月卡,我们直接发放1800刀!让各位佬友狂蹬!
^-^每人最多有一张狂蹬卡。 ^-^新用户购买套餐5分钟后,自动发放狂蹬卡。
^-^不算十人团的拼团额外赠送的额度。均为套餐默认的周额度。
后记:我们特别感激在此期间为Krill发声的各位佬友,衷心的感谢你们。有些佬友因为在群里发言,还被他人挂在了评论区,被说成是我们的洗地小号,算是“无妄之灾”了。 ^-^