《电脑漏洞验证》

一台没打补丁的电脑Windows 7机器，开机联网不到四分钟，漏洞屏幕上突然弹出一个计算器。验证不是电脑用户点的，是漏洞别人远程弹出来的。这事发生在2017年5月，验证我亲眼看着同事老周在测试机上复现了永恒之蓝。电脑他没运行任何程序，漏洞只是验证插了根网线。计算器弹出来那一刻，电脑他扭头冲我笑了一下，漏洞笑得挺得意，验证又有点后怕——那台机器如果放在公司内网，电脑整个办公区当天就得停摆。漏洞

漏洞验证这件事，验证外行听着像黑客电影，内行干起来更像法医。你要证明一个洞确实能钻过去，不能靠猜，不能靠扫描器报个“可能存在”，得亲手把利用代码跑通，拿到那个计算器、那个shell、那个被篡改的返回值。扫描器说“有漏洞”，跟验证说“漏洞可利用”，中间隔着一整个太平洋。

我习惯把验证分成两种：一种是证明“能进去”，一种是证明“进不去”。前者是攻击视角，后者是防御视角。很多团队只做前者，扫出一堆高危就收工，结果修复方案上线后没人复测。我见过一个电商系统，开发把Struts2的补丁打了，但漏了一台老测试机。三个月后那台机器成了跳板，攻击者从它横向摸到了订单库。验证没闭环，等于没验证。

具体怎么验？拿一个SQL注入点举例。扫描器告诉你参数id存在注入，你手动构造 id=1' and 1=1-- 和 id=1' and 1=2--，页面返回不同，这只说明“可能有”。真正的验证要往下走：判断数据库类型、猜表名、读字段、直到把管理员密码哈希拖出来。拖不出来，就不能在报告里写“可获取敏感数据”。我吃过这个亏。早年给一家银行做测试，注入点确认存在，但权限极低，只能读当前库的几张废表。报告里我写了“高危”，修复团队按高危排期，结果耽误了另一个真正能提权的漏洞。后来我学乖了，验证报告里必须写清楚“能读到什么、能写到什么、能执行什么命令”。

再说一个反直觉的：有些漏洞验证失败，反而比成功更有价值。去年测一个工控网关，扫描器报了个缓冲区溢出。我花了两天写利用脚本，最后发现那个溢出点被编译器优化掉了，实际不可触发。但在这个过程中，我发现网关的固件更新接口没有签名校验。这个发现比原漏洞严重得多——攻击者可以推一个恶意固件，直接拿下设备。如果我只盯着扫描器那个红点，这个真问题就漏了。

验证环境也常被忽视。有人在生产环境直接跑利用代码，弹个计算器出来，然后跟客户说“你看，我说有漏洞吧”。客户脸都绿了。正确的做法是搭一套和现场版本、配置、网络拓扑一致的靶机。但现实里经常做不到——你拿不到客户的完整配置，或者硬件根本买不到。这时候退而求其次，至少要在隔离网段做，并且提前写好回滚方案。我包里常年带着一个树莓派，刷好各种旧版本系统，就是为了现场快速搭验证环境。

最后说个细节。验证成功后，截图要截全。别只截一个计算器窗口，要把系统时间、IP地址、进程列表一起截进去。我见过有人只截了个弹窗，客户质疑是PS的，扯皮了一周。后来我养成习惯，验证过程全程录屏，从敲命令到结果输出，一镜到底。这玩意儿不光是证据，也是复盘时的教材——哪一步卡住了，哪一步绕过去了，下次遇到类似目标，直接翻录像。

漏洞验证不是炫技。它是一道工序，跟车工车一个零件、焊工焊一条缝没本质区别。区别只在于，车坏了零件能重来，漏洞验证搞错了，可能把客户整个网络搭进去。