Category Archives: 安全体系

一、事情概要
2025年12月22日晚22:00，快手直播遭遇了一次里程碑式的业务逻辑DDoS攻击，攻击者利用自动化工具操控海量账号，通过推流接口漏洞绕过审核，导致违规内容大面积“沦陷”。平台最终被迫采取全量关闭直播频道的 “熔断” 措施。
2025年12月23日早00:30-08:00，直播功能陆续恢复。
此次事件对快手的口碑与股价造成了巨大冲击。

二、时间线
根据火绒12月24日发布的复盘报告，本次事件分为以下几个阶段：

1、攻击试探，12月22日18:00-20:00
平台出现零星违规内容，处于常规风控处理范围，未引起警觉。攻击者控阈值，校准攻击参数。

2、攻击爆发，12月22日22:00
攻击正式开始。正值流量高峰，约1.7万个僵尸号或被劫持号同步开播，推送预制违规内容。

3、攻击僵持，12月22日22:00-23:00
违规直播间如潮水般涌现，用户举报失效，平台封禁严重滞后，系统陷入瘫痪。

4、应急熔断，12月22日23:00-12月23日00:30
平台被迫采取极端措施：全量关闭直播频道，页面提示“服务器繁忙”或“无内容”。

5、服务恢复，12月23日00:30-08:00
平台开始清洗，直播功能陆续恢复正常。

三、本次攻击的要素
1、快手直播的封堵业务流程，瓶颈十分明显
先开播（人工审核资源不足，先播起来）-》AI抽帧审核+用户举报-》人工审核（资源不足）-》调用封堵接口进行封堵（封堵操作并不简单，需要处理下游多种操作）

2、攻击者对快手的审核流程十分了解，应该是长期潜伏关注或有其他信源
1）攻击者准备了大量的攻击账号，包括一批“高质量”账号，攻击高峰期有1.7万攻击账号同时开播（DDoS攻击的基础）
2）攻击者发现了快手推流接口的业务逻辑漏洞，可以绕开业务服务器的鉴权机制，伪造推流地址（Token），推流给CDN节点（本次DDoS攻击奏效的大前提）
3）攻击者没有针对AI自动审核功能，而是精准DDoS攻击了封堵接口（本次DDoS攻击的重点）
4）攻击者特地选择了22:00左右，用户多、流量大且快手审核人员换班的时间窗口开启DDoS攻击（雪上加霜）

3、攻击者使用了“具备自适应能力的自动化攻击框架”替代了过往的攻击脚本，提升了封杀的难度（虽然不严谨，但为了便于理解，后面称之为“AI Agent”）
1）AI Agent可以根据封堵情况，灵活的执行切换IP，粗暴的封杀IP几乎就没用了
2）AI Agent可以根据平台策略，灵活的调整攻击频率，其他路径的识别、封杀更加困难
3）AI Agent可以模拟人类操作欺骗平台行为，其他路径的识别、封杀难以奏效

四、攻击是如何成立的
1、攻击者做了大量的踩点工作及前期准备（团队）
2、攻击试探，校准攻击参数(老手)
3、1.7万攻击账号，利用推流漏洞，同步违规开播，向CDN推送违规视频
4、快手的AI审核还在工作，人工审核疲于应对，大量合法封堵请求到达“封堵接口”
5、攻击者同步DDoS精准狙击“封堵接口”，封堵请求数量比平时暴增上千倍，封堵接口崩溃，拒绝服务，封堵失败
6、平台虽然能识别出违规内容，但没有资源进行封堵，造成了“业务逻辑耗尽”（攻击成立）
7、攻击者利用推流接口漏洞，让被封杀的账号，仍然可以开播，账号封杀无效
8、攻击者借助AI，自动应对IP封堵等防守措施，人工封堵效果极差
9、攻击者借助AI，自动适配平台策略，自动调整攻击频率，封堵效果极差
10、平台难以应对，最终只能关闭整个直播服务

五、快手存在的问题
1、审核过程，大量依靠人工，封堵手段，过于传统，难以对抗AI攻击（作为头部直播平台，理应做的更好）
AI审核工具其实没有生杀大权，只能发现问题，并不执行
人工审核也只是同意封堵，执行也是给到下游的封堵接口
2、推流接口存在严重的逻辑漏洞，可以被攻击者绕过鉴权机制，账号封杀没有用（据说是为了兼容低版本应用，特殊情况下不做二次校验，作为头部直播平台，理应做的更好）
3、封堵接口设计时，并没有考虑到如此大的并发量，被直接打爆了（平台前序防御措施被绕过，超过平时上千倍的请求一起过来，确实比较难）
业务逻辑复杂，没有主动降级，扩容也不及时，有提升空间
流量预计：平时请求级别大概率在1秒钟十几个几十个，被攻击时请求级别可能在1秒钟可能有几万几十万个，请求数量可能提升了上千倍
4、没有对抗AI攻击的应对能力，面对AI自动换IP、调整攻击频率、模拟用户行为等操作，缺少防御手段（确实比较难）
5、决策者缺少快速熔断的决断力，导致负面影响扩大化（这条十分苛刻，按当时的情况判断，很考验决策者的判断力和勇气，很难很难很难）

六、对我们的启示
本次攻击，攻击者利用接口漏洞+AI工具，用“合法流量”发起“自杀式”业务拥堵，暴露出当前安全架构在自动化防御与极限架构上的双重短板。
这次事件不仅仅是一次技术事故，更像是一场针对“传统互联网防御体系”的公开处刑。咱们的安全防疫体系，也要尽快从“被动修补”快速过渡到“主动免疫”：
1、零信任：不再区分“内外”，所有请求默认可疑，严验“行为”而非只验“身份”
2、入口决胜：在入口处就把机器人挡在外面，别等出事了再“救火”
3、防流不能只防点：攻击者用“合法流量”淹没你，防御必须从“堵漏洞”升级为“控流速”
4、用AI对抗AI：对于高置信事件，审核权和封堵权也要给到AI，人工只做复核，必须实现秒级自动熔断
5、独立救命通道：核心防御接口（如封禁）必须物理隔离，必须做好熔断和降级，扩容资源要充足，哪怕天塌下来也要打得开
6、成本换生存：安全无小事，平时看似浪费，关键时刻能救命。AI时代，安全防护的成本会与攻击成本会更加的不对称
7、高危风险：必须及时发现和修复，不能被业务牵着鼻子走

持续记录中。。。

2026年1月：Bluspark Global物流平台数据暴露
事件经过：1月14日安全研究员发现其Bluvoyix物流平台存在明文密码存储、未授权API接口漏洞，2007年以来的所有货运记录、客户核心数据直接暴露于互联网，攻击者可直接创建管理员账户操控数据；漏洞2025年10月已被发现，企业长期未采取修复措施。
攻击方式：漏洞利用、未授权访问、数据暴露
造成损失：影响数百家大型企业供应链数据安全，企业面临合规追责与客户流失风险，凸显物流行业云平台权限管控、漏洞响应及常态化安全审计的短板。

2026年1月：中央缅因医疗中心数据泄露
事件经过：1月13日披露，该中心2025年3月19日~6月1日遭黑客持续入侵超2个月，导致14.5万名患者的个人与医疗数据泄露，涵盖姓名、联系方式、诊疗记录等。
攻击方式：系统潜伏入侵、数据窃取。
损失影响：患者隐私暴露，面临身份盗用与医疗诈骗风险；医院需承担数据修复、合规处罚及声誉损失，倒逼医疗行业强化长期入侵检测能力。

2026年1月：欧洲铁路运营商Eurail数据泄露
事件经过：1月10日首次披露，泄露数据含用户姓名、出生日期、护照号等身份信息，通过DiscoverEU项目购票的用户还可能泄露身份证复印件、银行参考号及健康数据，暂未披露具体受影响人数。
攻击方式：数据窃取、身份信息泄露
造成损失：违反欧盟GDPR合规要求，引发欧盟监管机构介入调查；用户面临身份盗用与跨境出行安全风险，Eurail需投入巨额成本修复系统、排查风险并重建用户信任。

2026年1月：暗网论坛 BreachForums 用户数据库泄露（网络犯罪生态）
事件经过：1月9日，黑客James通过shinyhunte.rs公开泄露该论坛32.4万用户数据，含显示名、邮箱、密码哈希、Telegram关联账户等，数据经PGP签名验证真实；论坛方称源于2025年8月恢复过程中数据存于不安全目录被盗。
攻击方式：内部数据窃取、暗网数据公开。
损失影响：大量网络犯罪参与者身份面临暴露，或遭执法部门追查；冲击暗网数据交易生态，暴露地下论坛自身安全防护薄弱问题。

2026年1月：Instagram“密码重置风暴”及信息泄露争议
事件经过：全球数百万Instagram用户集中收到异常密码重置邮件，引发广泛恐慌；后曝光约1750万个账户的非密码类个人信息（用户名、真实姓名、邮箱、电话、部分住址），于2024年通过API接口遭非法获取，2026年1月8日被威胁行为者在BreachForums论坛公开发布。Meta声明无数据泄露，仅为已修复的技术漏洞导致虚假重置请求触发。
攻击方式：API接口非法获取、数据暗网公开、技术漏洞利用
造成损失：虽无账户被盗案例，但泄露信息易被用于鱼叉式钓鱼、身份冒用等犯罪；Meta声誉受影响，引发用户对社交平台数据存储与API管控的质疑，推动行业强化漏洞应急响应机制。

2026年1月：Ledger数据泄露事件
事件经过：知名硬件钱包提供商Ledger确认遭遇数据泄露，攻击并非破解硬件钱包本身，而是通过其第三方电商合作伙伴Global-e的系统漏洞，导致通过Ledger.com购物的客户个人数据（姓名、联系方式、配送地址）遭未授权访问；Ledger强调自有硬件与软件钱包安全，用户资金、私钥及支付信息未受影响，已聘请独立法证专家调查。
攻击方式：第三方服务商漏洞利用、供应链安全攻击、用户数据窃取
造成损失：虽无资金损失，但27万余名用户面临精准钓鱼诈骗风险，引发加密货币行业信任危机；暴露“冷钱包”背后的供应链安全短板，警示行业安全性取决于整个合作生态中最弱环节，倒逼企业强化第三方服务商安全审核。

2026年1月：美国电信巨头Brightspeed数据泄露
事件经过：黑客组织Crimson Collective宣称入侵，在Telegram公开泄露超100万驻站用户核心信息，含姓名、邮箱、电话、账户状态及网络配置数据。
攻击方式：系统入侵、数据窃取与公开泄露。
损失影响：用户面临精准诈骗、身份盗用风险；企业遭监管问询与声誉打击，凸显电信行业用户数据防护与应急响应不足。

2026年1月：法国邮政跨年“连环劫”攻击
事件经过：攻击者选在圣诞2025年12月22日、新年假期2026年1月1日业务高峰期，对法国邮政（La Poste）及其邮政银行发起两次分布式拒绝服务（DDoS）攻击。12月22日攻击导致部分投递业务、线上服务及邮政银行部分线上移动端服务瘫痪，12月26日逐步恢复；1月1日再次攻击，造成官网、App及包裹追踪系统全面瘫痪，线下投递及邮局柜台服务未受影响。
攻击方式：分布式拒绝服务（DDoS）攻击、高峰期精准打击
造成损失：客户数据未被泄露，但线上服务中断严重影响民众假期包裹查询、业务办理，引发广泛社会困扰；凸显基础设施在节假日高峰期的网络防御薄弱点，推动法国强化公共服务机构的DDoS防护与应急响应能力。

整理了一些大模型常见攻击方法，用拟人的方法描述，感觉还挺有趣的：

感觉现在的大模型，越来越像《思考快与慢》中的系统1和系统2：
先看人脑，人脑平时工作用系统1，能耗低，效率快，系统2处于低能耗的待机观察状态；
但系统1吃不准的时候，就会把主动权给到系统2。系统2更理性，更克制，但耗能更高，输出速度更低。

回到大模型，当前大模型相当于一个系统1异常发达，系统2刚开始发育的状态。
当前系统2仅仅是拦截，能耗相对较低。
如果要系统2能处理更复杂的任务，输出一个比系统1更合适，更优雅的答案，势必就要更多的计算和能耗了。
人脑的系统2由于能耗高，经常会偷懒，系统1就会有不少犯错的机会。
如果大模型成本因素也变的特别重要，大模型的系统2，是不是也会偷懒呢？

现在多模态大模型能力都很强，但大模型安全防御难度也会急剧增加。
如果攻击者剑走偏锋会更难防护，比如：
1、将原有诱导方式，通过中文+拼音+其他语种混杂编码的方式传递
2、将原有诱导方式，通过错误拼写、错误的多音字等传递
3、和大模型约定一种新的编码方式，编码后，发给大模型解码
4、将部分诱导内容，放到参考数据中，通过引用参考数据
5、将诱导内容，放到一段编码中，要求参考输出内容
6、将部分诱导内容，隐藏到参考图片中，甚至视频中

进一步拉通视觉与和文本语义防护策略，比分别应用不同的防护策略，效果应该更好一些

最近和朋友聊天的时候，大家聊到了MCP，然后聊到了MCP的安全问题。
大家后面一致认为，MCP协议，目前只描述了如何通讯，如何调用MCP服务端的能力，在安全方面还是很薄弱的。

尤其是当前阶段，暂且不说个人提供的MCP服务品质，其实各大厂提供的MCP服务也只是做了部分的能力封装而已。
而应用MCP的下游，无论是服务器还是应用，在处理MCP返回输出方面，如何进一步规避风险，是严重缺乏经验和手段的。

这就导致了，无论是MCP的客户端还是服务端，都很容易成为攻击者，也很容易成为被攻击者。

很多传统的攻击方式，都可以用到MCP攻击上，比如：
1、DNS攻击
2、中间人攻击
3、MCP供应链攻击
4、大模型投毒
5、大模型地址替换
6、社会工程学攻击

举个例子，对一个自动编码的MCP服务，一旦攻破该MCP服务，就可以返回代码时，自动插入一段删除数据文件的恶意代码。
如果MCP的下游，没有做任何校验，就执行了代码，后果不堪设想。

目前看来，最好的方式，还是相对集中式的管理。
1、统一的平台，审核、发布、维护MCP服务，各厂商负责开发，最后发布到统一平台上。
2、建立MCP服务的信息评价体系，对于恶意版本及时下线，对于恶意厂商及时封堵。
3、推行零信任的认证方式。

整理资料的时候，发现之前汇总过的一些安全法规，上次更新大概在24年中：

本以为我们的系统安全和网络安全做的很好，静态扫描、动态扫描、组件扫描、主机扫描、网络扫描，都把系统扫烂了，而且有集团安全提供的各安全供应商的各类工具，发现的问题，包括0day漏洞都会尽快修复，于是膨胀了。

邀请了集团及合作的安全专家，对系统的测试环境进行了渗透攻击，我们进行防御，不出意外，意外很快就发生了，很快就收到了被攻破的报告。
被打脸了，攻击路径：
1、在测试环境发布的时候，为了调试方便，开启了一个配置，导致关键组件可以不授权访问
2、该漏洞被蓝军利用，直接获取了数据库、配置中心等内外服务地址和账号密码
3、蓝军通过修改网关配置，直接将配置中心管理界面映射到了外网，获取了配置中心的全部配置
4、通过配置信息，蓝军很快就获取了OBS访问密钥、部分AK/SK信息、数据库地址信息、开放平台配置信息等
*此时安全团队才发现问题，及时进行了干预，阻断了进一步的攻击
5、后续蓝军可以访问数据库，导出数据库信息，直接挂到网关上，外网可以直接下载
6、后续蓝军可以访问OBS，枚举文件，将部分文件挂到网关上，外网可以直接下载
7、后续蓝军可以继续挂马，继续向内渗透攻击其他主机，进一步扩大战果
8、后续可以通过获取的信息，加上社会工程学信息，继续进行渗透
9、后续蓝军可以继续投放勒索病毒等，达到进一步的攻击目的

后续我们进行了集体反思，看似铜墙铁壁的防护，被一行简单的配置全部破掉了。
后续整改措施很多，包括：
1、及时排查和修复此类问题，对开放、测试、生产进行全面整改
2、通过访问日志，确认过往未发生数据泄露问题
3、再次确认网络安全策略，对办公、开发、测试、特别是生产环境进行隔离
4、不仅生产，在测试和开发环境上也要保持配置隔离，宁可增加一些资源
5、不仅生产，在测试和开发环境上也要加强管控，否则问题一定会蔓延到生产环境
6、部分关键信息是明文存储的，必须调整为加密存储
7、非必要，开发及测试环境不对外开放，即使必要，及时关闭
8、加强对软件提供商的管理，避免
9、与多个安全厂商合作，引入外部专家，进一步加强渗透及越权测试