从一道CTF题浅谈MyBatis与Ognl的那些事

亿人安全

发布于 2024-07-12 11:12:00

1420

发布于 2024-07-12 11:12:00

文章被收录于专栏：红蓝对抗

原文由作者授权，首发在奇安信攻防社区

https://forum.butian.net/share/1749

MyBatis 默认是支持OGNL 表达式的，尤其是在动态SQL中，通过OGNL 表达式可以灵活的组装 SQL 语句，从而完成更多的功能。在特定的情况下可能会存在RCE的风险。

0x01引言

前段时间看了一道CTF题目ezsql

传送门：http://www.yongsheng.site/2022/03/29/d3ctf/ 里面的解题过程大概是Mybatis调用时存在SQL注入，然后还存在OGNL注入。

看完文章后有一些疑惑：

为什么SQL注入能解析ognl表达式达到RCE的效果？
题目中是通过Provider注解进行sql配置的，xml配置和类似@Select配置也会存在类似的问题吗？
使用#{}预编译后也会存在类似的风险吗？

带着这些疑惑，下面从mybatis的解析流程入手，分析这个case的成因并且看看能不能解决上述提出的疑惑。

0x02 mybatis封装SQL流程

提到Mybatis很自然的会想到${}和#{}，看看具体是怎么解析的。

2.1 相关过程

Mybatis的工作流程首先是构建，也就是解析我们写的配置(xml，注解等),将其变成它所需要的对象。然后就是执行，通过前面的配置信息去执行对应的SQL，完成与Jdbc的交互。简单的分析下具体的流程，案例代码如下：对应的mapper方法：

相关的xml配置：

<select id="getUserByUserName" parameterType="String" resultMap="User">
    select * from users where username like ${username}
</select>

以mybatis 3.5.1为例，将断点下在调用的mybatis mapper方法上，简单的梳理对应的执行流程：

首先是org.apache.ibatis.binding.MapperProxy#invoke方法，主要的执行逻辑都在MapperMethod的execute()方法：

跟进org.apache.ibatis.binding.MapperMethod#execute方法，首先是SQL类型的判断（INSERT/UPDATE/DELETE/SELECT）:

mapper的方法是SELECT的，具体看看SELECT的流程，这里会通过method的返回值的不同调用不同的方法。例如前面的mapper method返回值是List<User>，会返回多行，那么就会调用executeForMany()方法：

在org.apache.ibatis.binding.MapperMethod#executeForMany中，核心的是sqlSession.selectList()，具体的sql执行应该是在这里，rowBounds参数从名称上看应该是跟分页有关的：

继续跟进，通过MappedStatement#getBoundSql()来获取要执行的sql语句，这里应该会对相关的SQL进行组装：

这里主要是通过SqlSource来组装，继续跟进相关的代码：

sqlSource主要是个接口，有四个实现类：

StaticSqlSource静态SQL，DynamicSqlSource、RawSqlSource处理过后都会转成StaticSqlSource
DynamicSqlSource处理包含${}、动态SQL节点的
RawSqlSource处理不包含${}、动态SQL节点的
ProviderSqlSource动态SQL，看名称应该是跟类似@SelectProvider注解有关

前面xml里配置的是{username}，如果包含{}的话一般会调用DynamicSqlSource进行解析，跟进具体的代码：

在rootSqlNode.apply(context)会对相关的sql节点进行组装，那么就会对root节点进行遍历，调用对应class的apply方法进行解析：

这里会遍历所有的SqlNode,然后根据对应的type再次调用对应的apply方法：

例如当前mapper的节点的类型为TextSqlNode，会调用其apply方法进行进一步的解析：

继续跟进，这里调用了org.apache.ibatis.parsing.GenericTokenParser#parse方法进行处理，主要是删除反斜杠并处理相关的参数(${})：

最后把${}包裹的内容提取出来，然后调用BindingTokenParser#handleToken方法进行解析：

再往下跟进，这里会调用OgnlCache.getValue方法，从名称看应该是对sql中ognl表达式进行解析，然后替换SQL中对应的${xxx}：

完成对应sql的封装后，最终会调用selectList方法完成sql执行的操作，从下图中的Exception信息也可以知道该方法与数据库进行了交互：

mybatis的整个封装SQL的流程大体上就是这样子了。 #{}的解析流程类似，主要不同的是BindingTokenParser变成了ParameterMappingTokenHandler，然后在handleToken对将#{}替换成占位符？。

0x03 可能的缺陷

结合前面的CTF题目以及对应的疑惑，这里做一个猜想，mybatis使用不当的话存在sql注入(即输入直接拼接${})的情况，那么根据上面的分析，会调用DynamicSqlSource然后通过OgnlCache进行相应的解析，如果parseExpression方法中解析的expression是一个恶意的ognl表达式的话，那么有可能存在风险：

那么如何找到一处可以输入${恶意ognl表达式}，同时能调用DynamicSqlSource通过OgnlCache进行相应的解析的利用点呢？题目里的Provider注解有什么关联呢？

3.1 分析过程

MyBatis 默认是支持OGNL 表达式的，尤其是在动态SQL中，通过OGNL 表达式可以灵活的组装 SQL 语句，从而完成更多的功能。从MyBatis的常见使用方式开始梳理，逐个进行分析：

3.1.1 XML配置

XML配置是比较常用的一种方式。

假设xml配置如下：

<select id="test" parameterType="String" resultMap="User">
    select * from users where username like ${@java.lang.Runtime@getRuntime().exec("open /System/Applications/Calculator.app")}
</select>

根据前面的分析MyBatis处理{}的时候，会使用OGNL计算这个结果值，然后替换SQL中对应的{xxx}。

很明显在调用这个mapper method时，OGNL会计算@java.lang.Runtime@getRuntime().exec("open /System/Applications/Calculator.app")的结果，然后再拼接到原始的SQL中。那么对应的恶意OGNL表达式就会被执行，这里简单写一个controller调用验证猜想。

可以看到提取了${}里的内容，然后OGNL进行了解析，很明显会调用Runtime执行对应的命令：

以上是一种比较理想的情况，实际上也不会有人在xml里写恶意的ognl表达式，替换跟覆盖已有的XML也不太现实。

更常见的场景一般是如下配置：

<select id="getUserByUserName" parameterType="String" resultMap="User">
    select * from users where username like ${username}
</select>

如果整个解析顺序如下：

用户输入username->拼接到${}中->调用OGNL解析器解析新的expression

那么确实这里除了SQL注入以外，还可以通过OGNL注入达到上面RCE的效果。显然Mybatis的设计者在设计之初就考虑到了这一个风险，下断点调试，可以看到实际情况在解析时只会解析原有的${username},解析完毕后再把用户输入的值赋予给他。避免了RCE的利用。

3.1.2 普通注解

mybatis3提供了注解的方式，常见的有@Select、@Insert、@Update、@Delete，他们跟xml配置中对应的标签语法是类似的。这里一般sql配置是不可控的，跟xml一样没办法操作。

3.1.3 Provider注解

除了上述两种方式以外，MyBatis3提供了使用Provider注解指定某个工具类的方法来动态编写SQL。也就是题目里的注解，常见的注解有：

@SelectProvider
@InsertProvider
@UpdateProvider
@DeleteProvider

本质上Provider指定的工具类只需要返回一个SQL字符串，通过在外部定义好 sql直接引用。

跟进下其封装SQL的过程，前面的过程都是一样的，最后都会通过MappedStatement#getBoundSql()来获取要执行的sql语句，进行相应的组装。

然后会调用org.apache.ibatis.builder.annotation.ProviderSqlSource#getBoundSql进一步组装：

相比xml配置，多了一个org.apache.ibatis.builder.annotation.ProviderSqlSource#createSqlSource的调用：

继续跟进，调用org.apache.ibatis.builder.annotation.ProviderSqlSource#invokeProviderMethod:

因为Provider注解是用户自己编辑的，从对应的参数信息可以看出来这里大致应该是解析相应的外部类，得到对应的SQL，然后返回：

PS：在外部类中一般会通过MyBatis 3 提供的工具类org.apache.ibatis.jdbc.SQL或者StringBuilder拼接来生成SQL。

再往下就跟XML配置的解析过程一样了，通过SqlSource来组装，如果SQL中包含${}的话则调用DynamicSqlSource进行解析，最后封装完SQL后调用selectList方法完成sql执行的操作。

相比XML配置方式，其中间会多了一个获取自定义SQL的过程。可以简单的类比为动态生成了一个xml mapper配置。同时因为是直接进行拼接的，假设内容用户可控的话，那么就可以尝试写入类似{content}的内容，因为包含{}，SQL会有变动的可能，拼接成SQL后会调用DynamicSqlSource通过OgnlCache进行相应的解析，达到RCE的效果。也就是题目里的效果。

3.2 缺陷利用过程

根据前面的猜想，这里以@SelectProvider为例进行验证。 Controller如下：通过调用mapper的getUserByUserName方法查询对应的用户名信息：

@GetMapping("/mybatis/ognl")
public List<User> mybatisOgnl(@RequestParam("name") String name) {
   return userMapper.getUserByUserName(name);
}

查看对应的Provider实现，传入的参数name通过SQL拼接进行查询，这里明显是存在SQL注入的，可以任意的拼接内容，写入前面提到的${}：

@SelectProvider(type = FindUserByName.class, method = "getUser")
List<User> getUserByUserName(String name);

class FindUserByName {
    public String getUser(String name) {
        String s = new SQL() {
            {
                SELECT("*");
                FROM("users");
                WHERE("username='" + name+"'");
            }
        }.toString();
        return s;
    }
}

根据前面的分析，这里实现的过程可以类比成xml配置中存在如下的select标签：

<select id="getUserByUserName" parameterType="String" resultMap="User">
    select * from users where username like 用户传入的name
</select>

假设name的值是一个ognl表达式的话，mybatis会进行解析，从而达到RCE的效果。

这里将name设置为如下poc进行请求：

${@java.lang.Runtime@getRuntime().exec("open /System/Applications/Calculator.app")}

可以看到ognl正常解析并且执行了对应的命令：

到这里已经把整个CTF题目重新完整的“复现一遍”了。相关的问题也有了答案了。

0x04 其他

4.1 相关限制

从mybatis从3.5.4开始，在org.apache.ibatis.ognl.OgnlRuntime#InvokeMethod方法中，有一个黑名单机制，当_useStricterInvocation属性为true时，黑名单中的类将不能被使用，例如执行命令要用到的Runtime和ProcessBuilder都在黑名单内：