ERR_UNSAFE_PORT浏览器安全问题导致无法访问的解决方案

最新推荐文章于 2025-07-02 14:26:54 发布

原创

最新推荐文章于 2025-07-02 14:26:54 发布 · 1.9k 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#安全 #java #tomcat

本文探讨了Java内存马的分析与查杀，特别是针对ERR_UNSAFE_PORT安全问题的解决方案。通过分析内存马的利用方式，如冰蝎内存马，提出了一种自动检测和修复内存马的方案。文章详述了如何获取当前字节码，解决非法字节码问题，以及如何分析字节码以确定内存马，并提供了自动修复的思路。

前言

出发点是Java Agent内存马的自动分析与查杀，实际上其他内存马都可以通过这种方式查杀

本文主要的难点主要是以下三个，我会在文中逐个解答

1.如何dump出JVM中真正的当前的字节码
2.如何解决由于LAMBDA表达式导致非法字节码无法分析的问题
3.如何对字节码进行分析以确定某个类是内存马

背景

对于Java内存马的攻防一直没有停止，是Java安全领域的重点

回顾Tomcat或Spring内存马：Filter和Controller等都需要注册新的组件

针对于需要注册新组件的内存马查杀起来比较容易：

例如c0ny1师傅的java-memshell-scanner项目，利用了Tomcat API删除添加的组件。优点在于一个简单的JSP文件即可查看所有的组件信息，结合人工审查（类名和ClassLoader等信息）对内存马进行查杀，也可以对有风险的Class进行dump后反编译分析

或者LandGrey师傅基于Alibaba Arthas编写的copagent项目，分析JVM中所有的Class，根据危险注解和类名等信息dump可疑的组件，结合人工反编译后进行分析

但实战中，可能并不是以上这种注册新组件的内存马

例如师傅们常用的冰蝎内存马，是Java Agent内存马。以下这段是冰蝎内存马一段代码，简单分析后可以发现冰蝎内存马是利用Java Agent注入到javax.servlet.http.HttpServlet的service方法中，这是JavaEE的规范，理论上部署在Tomcat的都要符合这个规范，简单来理解这是Tomcat处理请求最先且总是经过的地方，在该类加入内存马的逻辑，可以保证稳定触发

类似的逻辑，可以使用Java Agent将内存马注入org.apache.catalina.core.ApplicationFilterChain类中，该类位于Filter链头部，也就是说经过Tomcat的请求都会交经过该类的doFilter方法处理，所以在该方法中加入内存马逻辑，也是一种稳定触发的方式（据说这是老版本冰蝎内存马的方式）

还可以对类似的类进行注入，例如org.springframework.web.servlet.DispatcherServlet类，针对于Spring框架的底层进行注入。或者一些巧妙的思路，比如注入Tomcat自带的Filter之一org.apache.tomcat.websocket.server.WsFilter类，这也是Java Agent内存马可以做到的

上文简单地介绍了各种内存马的利用方式与普通内存马的查杀，之所以最后介绍Java Agent内存马的查杀，是因为比较困难。宽字节安全的师傅提出查杀思路：基于javaAgent内存马检测查杀指南

引用文章讲到Java Agent内存马检测的难点：

调用retransformClass方法的时候参数中的字节码并不是调用redefineClass后被修改的类的字节码。对于冰蝎来讲，根本无法获取被冰蝎修改后的字节码。我们自己写Java Agent清除内存马的时候，同样也是无法获取到被redefineClass修改后的字节码，只能获取到被retransformClass修改后的字节码。通过Javaassist等ASM工具获取到类的字节码，也只是读取磁盘上响应类的字节码，而不是JVM中的字节码

宽字节安全的师傅找到了一种检测手段：sa-jdi.jar

借用公众号师傅的图片，这是一个GUI工具，可以查看JVM中所有已加载的类。区别在于这里获取到的是真正的当前的字节码，而不是获取到原始的，本地的字节码，所以是可以查看被Java Agent调用redefineClass后被修改的类的字节码。进一步可以dump下来认为存在风险的类然后反编译人工审核