疑似浏览器java漏洞攻击

昨天下午三点多，浏览a漏我正对着屏幕改一段前端代码，洞攻浏览器突然卡死，浏览a漏风扇狂转。洞攻任务管理器里Chrome的浏览a漏CPU占用飙到98%，内存从平时的洞攻1.2G直接跳到3.8G。这不是浏览a漏第一次了。我第一反应是洞攻某个标签页里的广告在搞鬼，但关掉几个页面后情况没改善。浏览a漏打开开发者工具，洞攻Console里跳出一行奇怪的浏览a漏报错——跟Java有关，具体是洞攻 java.lang.Runtime 的调用被拦截了。我当时就警觉起来。浏览a漏

浏览器里跑Java？洞攻现在绝大多数人早就忘了这回事。Chrome从2015年就彻底砍掉了NPAPI插件支持，浏览a漏Firefox也在后面几年跟进了。可问题在于，很多企业内网系统、老旧的OA平台、甚至部分银行的网银助手，仍然依赖JRE（Java运行环境）在浏览器里跑Applet。这些环境往往没打最新补丁，或者用了过时的 deploy.jar。攻击者就盯着这块。

我顺着那条报错往下查，发现页面里嵌入了一个 <applet> 标签，指向一个远程加载的jar包。jar包名字伪装成 jre-8u291-windows-x64.exe，实际上是个恶意载荷。更离谱的是，这个页面通过 document.write 动态注入了一段JavaScript，调用 java.awt.Desktop.getDesktop().browse()，试图打开一个远程SMB共享。SMB？浏览器里的Java去连445端口，这摆明了是要走NTLM中继或者直接投毒。

我抓了一下网络包，目标IP是 185.xxx.xxx.xxx，位于东欧。请求的URL路径里带了一串Base64编码的参数，解码后是一段PowerShell下载命令。典型的“Java Applet → 反序列化 → 远程加载”链。攻击者不需要你点击任何东西，只要页面加载了那个applet，JRE就会自动执行。前提是你的浏览器还支持NPAPI，或者你用IE模式打开了这个页面。

这事让我想起去年帮一个客户排查的案例。他们的财务系统突然往外发大量SMB请求，IT部门以为是勒索软件。结果查了一周，发现是某个供应商的报价页面里藏了Java漏洞利用代码。那个页面只在IE11里触发，因为只有IE还保留着ActiveX和Java插件的支持。财务同事用IE打开报价单，Java插件自动加载，漏洞利用成功，机器就成了跳板。

现在主流浏览器确实安全多了。Chrome和Edge默认禁用Java，Firefox需要手动开启。但问题出在“兼容模式”和“企业策略”上。很多公司为了跑老系统，强制把浏览器配置成允许Java运行。更麻烦的是，有些国产浏览器基于Chromium魔改，偷偷保留了NPAPI接口。你根本不知道它什么时候会加载一个jar包。

防御这件事，说复杂也复杂，说简单也简单。第一，别在浏览器里用Java。如果非要用，把JRE升到最新版，并且把 deployment.properties 里的 deployment.security.level 设成 VERY_HIGH。第二，检查企业策略里有没有 AllowOutdatedPlugins 这种要命的开关。第三，如果看到 java.lang.Runtime.exec 或者 java.lang.ProcessBuilder 在浏览器进程里被调用，直接杀进程，别犹豫。

我后来把那个页面扔进沙箱跑了一遍。五秒后，沙箱里多了一个 svchost.exe 的伪装进程，监听本地8080端口。再晚几分钟，它就该横向移动了。浏览器Java漏洞这东西，平时没人提，真碰上了就是大麻烦。别等到风扇狂转才想起来看Console。