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

举报
亿人安全 发表于 2024/10/31 23:25:32 2024/10/31
【摘要】 朋友们现在只对常读和星标的公众号才展示大图推送，建议大家把“亿人安全“设为星标”，否则可能就看不到了啦原文由作者授权，首发在奇安信攻防社区https://forum.butian.net/share/1749MyBatis 默认是支持OGNL 表达式的，尤其是在动态SQL中，通过OGNL 表达式可以灵活的组装 SQL 语句，从而完成更多的功能。在特定的情况下可能会存在RCE的风险。0x01引...

朋友们现在只对常读和星标的公众号才展示大图推送，建议大家把“亿人安全“设为星标”，否则可能就看不到了啦


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

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都在黑名单内：

图片

_useStricterInvocation属性在static代码块进行了赋值，默认是true：

图片

同样是上面的案例，此时提交对应的poc会抛出异常：

图片

但是这个黑名单应该是存在缺陷的，可以考虑Bypass。也有师傅提出了相关的poc。这里暂时不讨论了。

4.2 修复建议

在Provider定义sql时，采用#{}预编译的方式进行查询即可，如果一定要直接进行拼接的话，需要对用户的输入进行安全检查。

PS：实际上Provider指定的工具类只需要返回一个SQL字符串，所以不论是通过MyBatis3 提供的工具类org.apache.ibatis.jdbc.SQL来生成SQL，还是简单的String拼接，都是可能存在类似的问题的。

0x05 参考资料

  • http://www.yongsheng.site/2022/03/29/d3ctf/

【版权声明】本文为华为云社区用户原创内容，转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息， 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱： cloudbbs@huaweicloud.com
MyBatis SQL
  • 点赞
  • 收藏
  • 关注作者

评论（0）

0/1000
抱歉，系统识别当前为高风险访问，暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称，即可参与社区互动！

*长度不超过10个汉字或20个英文字符，设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符，设置后3个月内不可修改。

确认 取消

加入云驻计划，成为创作者

  • 华为云周边好礼
  • 免费体验产品
  • 特殊身份标识
  • 线下官方门票
  • 内部专家零距离
  • 与10000+优质创作者共同成长
立即加入