关于apache kylin漏洞就2篇帖子:
https://mp.weixin.qq.com/s/QzlHYST0kIqjNV-hnosyAw
https://www.freebuf.com/vuls/243541.html
其中,CVE-2020-1392是jd蓝军发现的。
直接就开始分析吧,首先分析sink,
Sink就很简单

这里的 sink我们就正常的去定义一个construtorCall,然后这个construtorCall限定在processBuilder下就行。如果你不会写,那就很棒棒了,codeql官方有一个ExternalProcess.qll库里面有一个ArgumentToExec类,这个类会覆盖到这个sink

那么就直接写一个

override predicate isSink(DataFlow::Node sink) {
        sink.asExpr() instanceof ArgumentToExec
}

就定义好了sink。
接下来定义source。
我们看到漏洞的分析里,漏洞最开始的参数是来源于

这的注解的project参数。这个project应该就是一个任务的名字。
对于这个source 的定义的话,就可以判断下他的注解和参数,参数也是有注解的,把这个抽象出来一个method
代码就是

class DumpProjectDiagnosisInfoMethod extends Method {

     DumpProjectDiagnosisInfoMethod() {

    //    this.hasName("dumpProjectDiagnosisInfo")

     this.getSourceDeclaration().getAnAnnotation().toString().matches("%Mapping%")  and

     this.getAParameter().getAnAnnotation().toString().matches("PathVariable")

    }

}

接下来我们可以看到整个漏洞的产生有不断的调用方法。
那么定义一个

class CallTaintStep extends  TaintTracking::AdditionalTaintStep {

    override  predicate step(DataFlow::Node n1, DataFlow::Node n2) {

      exists(Call  call |

        n1.asExpr()  = call.getAnArgument() and

        n2.asExpr()  = call

      )

    }

}

来保证调用关系。
然后我们跑下codeQL

可以看到source有3个地方可以流入processbuilder,分别是CubeController.java,DiagnosisController.java这2个文件,其中Diagnosisxx.java这个文件有2个注解方法可以流入到processbuilder。分别获得了CVE-2020-13925,CVE-2020-1956。
京东的那个分析文章也说了,漏洞存在的2个接口,而我们多了一个。这个会不会存在问题呢?
我们来看下他的数据流:

可以看到数据流第5步经过了一个checkParameterWhiteList方法,这个方法需要满足正则表达式:

COMMAND_WHITE_LIST =  "[^\\w%,@/:=?.\"\\[\\]]";

反正我是绕不过。绕过了 这就是一个新的CVE了。但是放心,这个数据流是通的。

自从用了数据流,挖洞都轻松了很多。
用CodeQL分析1day 很轻松 看看cve描述 然后挖掘一下就基本上可以把没poc的漏洞分析出利用方式了。
apache kylin就有一个新的cve 也是国人提交的,大家可以试试分析下

点击收藏 | 1 关注 | 1
  • 动动手指,沙发就是你的了!
登录 后跟帖