Nexus Repository Manager 3几次表达式解析漏洞的示例分析

小编给大家分享一下Nexus Repository Manager 3几次表达式解析漏洞的示例分析，相信大部分人都还不怎么了解，因此分享这篇文章给大家参考一下，希望大家阅读完这篇文章后大有收获，下面让我们一起去了解一下吧！Nexus Repository Manager 3最近曝出两个el表达式解析漏洞，编号为CVE-2020-10199，CVE-2020-10204，都是由Github Secutiry Lab团队的@pwntester发现。由于之前Nexus3的漏洞没有去跟踪，所以当时diff得很头疼，并且Nexus3 bug与安全修复都是混在一起，更不容易猜到哪个可能是漏洞位置了。后面与@r00t4dm师傅一起复现出了CVE-2020-10204，CVE-2020-10204是CVE-2018-16621的绕过，之后又有师傅弄出了CVE-2020-10199，这三个漏洞的根源是一样的，其实并不止这三处，官方可能已经修复了好几处这样的漏洞，由于历史不太好追溯回去，所以加了可能，通过后面的分析，就能看到了。还有之前的CVE-2019-7238，这是一个jexl表达式解析，一并在这里分析下，以及对它的修复问题，之前看到有的分析文章说这个漏洞是加了个权限来修复，可能那时是真的只加了个权限吧，不过我测试用的较新的版本，加了权限貌似也没用，在Nexus3高版本已经使用了jexl白名单的沙箱。文中会用到三个Nexus3环境：nexus-3.14.0-04nexus-3.21.1-01nexus-3.21.2-03nexus-3.14.0-04用于测试jexl表达式解析，nexus-3.21.1-01用于测试jexl表达式解析与el表达式解析以及diff，nexus-3.21.2-03用于测试el表达式解析以及diffCVE-2020-10199、CVE-2020-10204漏洞的修复界限是3.21.1与3.21.2，但是github开源的代码分支好像不对应，所以只得去下载压缩包来对比了。在官方下载了nexus-3.21.1-01与nexus-3.21.2-03，但是beyond对比需要目录名一样，文件名一样，而不同版本的代码有的文件与文件名都不一样。我是先分别反编译了对应目录下的所有jar包，然后用脚本将nexus-3.21.1-01中所有的文件与文件名中含有3.21.1-01的替换为了3.21.2-03，同时删除了META文件夹，这个文件夹对漏洞diff没什么用并且影响diff分析，所以都删除了，下面是处理后的效果：如果没有调试和熟悉之前的Nexus3漏洞，直接去看diff可能会免费云主机域名看得很头疼，没有目标的diff。抓下nexus3发的包，随意的点点点，可以看到大多数请求都是POST类型的，URI都是/service/extdirect：post内容如下：可以看下其他请求，json中都有action与method这两个key，在代码中搜索下coreui_Repository这个关键字：可以看到这样的地方，展开看下代码：通过注解方式注入了action，上面post的method->getBrowseableFormats也在中，通过注解注入了对应的method：所以之后这样的请求，我们就很好定位路由与对应的处理类了Nexus3的API也出现了漏洞，来看下怎么定位API的路由，在后台能看到Nexus3提供的所有API。点几个看下包，有GET、POST、DELETE、PUT等类型的请求：没有了之前的action与method，这里用URI来定位，直接搜索/service/rest/beta/security/content-selectors定位不到，所以缩短关键字，用/beta/security/content-selectors来定位：通过@Path注解来注入URI，对应的处理方式也使用了对应的@GET、@POST来注解可能还有其他类型的路由，不过也可以使用上面类似的方式进行搜索来定位。还有Nexus的权限问题，可以看到上面有的请求通过@RequiresPermissions来设置了权限，不过还是以实际的测试权限为准，有的在到达之前也进行了权限校验，有的操作虽然在web页面的admin页面，不过本不需要admin权限，可能无权限或者只需要普通权限。在跟踪调试了CVE-2018-16621与CVE-2020-10204之后，感觉buildConstraintViolationWithTemplate这个keyword可以作为这个漏洞的根源，因为从调用栈可以看出这个函数的调用处于Nexus包与hibernate-validator包的分界，并且计算器的弹出也是在它之后进入hibernate-validator的处理流程，即buildConstraintViolationWithTemplate(xxx).addConstraintViolation()，最终在hibernate-validator包中的ElTermResolver中通过valueExpression.getValue(context)完成了表达式的执行，与@r00t4dm师傅也说到了这个：于是反编译了Nexus3所有jar包，然后搜索这个关键词（使用的修复版本搜索，主要是看有没有遗漏的地方没修复；Nexue3有开源部分代码，也可以直接在源码搜索）：后面作者也发布了漏洞分析，确实用了buildConstraintViolationWithTemplate作为了漏洞的根源，利用这个关键点做的污点跟踪分析。从上面的搜索结果中可以看到，el表达式导致的那三个CVE关键点也在其中，同时还有其他几个地方，有几个使用了this.getEscapeHelper().stripJavaEl做了清除，还有几个，看起来似乎也可以，心里一阵狂喜？然而，其他几个没有做清除的地方虽然能通过路由进入，但是利用不了，后面会挑选其中的一个做下分析。所以在开始说了官方可能修复了几个类似的地方，猜想有两种可能：官方自己察觉到了那几个地方也会存在el解析漏洞，所以做了清除有其他漏洞发现者提交了那几个做了清除的漏洞点，因为那几个地方可以利用；但是没清除的那几个地方由于没法利用，所以发现者并没有提交，官方也没有去做清除不过感觉后一种可能性更大，毕竟官方不太可能有的地方做清除，有的地方不做清除，要做也是一起做清除工作。这个漏洞对应上面的搜索结果是RolesExistValidator，既然搜索到了关键点，自己来手动逆向回溯下看能不能回溯到有路由处理的地方，这里用简单的搜索回溯下。关键点在RolesExistValidator的isValid，调用了buildConstraintViolationWithTemplate。搜索下有没有调用RolesExistValidator的地方：在RolesExist中有调用，这种写法一般会把RolesExist当作注解来使用，并且进行校验时会调用RolesExistValidator.isValid()。继续搜索RolesExist：有好几处直接使用了RolesExist对roles属性进行注解，可以一个一个去回溯，不过按照Role这个关键字RoleXO可能性更大，所以先看这个（UserXO也可以的），继续搜索RoleXO：会有很多其他干扰的，比如第一个红色标注RoleXOResponse，这种可以忽略，我们找直接使用RoleXO的地方。在RoleComponent中，看到第二个红色标注这种注解大概就知道，这里能进入路由了。第三个红色标注使用了roleXO，并且有roles关键字，上面RolesExist也是对roles进行注解的，所以这里猜测是对roleXO进行属性注入。有的地方反编译出来的代码不好理解，可以结合源码看：可以看到这里就是将提交的参数注入给了roleXO，RoleComponent对应的路由如下：通过上面的分析，我们大概知道了能进入到最终的RolesExistValidator，不过中间可能还有很多条件需要满足，需要构造payload然后一步一步测。这个路由对应的web页面位置如下：测试（这里使用的3.21.1版本，CVE-2018-16621是之前的漏洞，在3.21.1早修复了，不过3.21.1又被绕过了，所以下面使用的是绕过的情况，将$换成$x去绕过，绕过在后面两个CVE再说）：修复方式：加上了getEscapeHelper().stripJavaEL对el表达式做了清除，将${替换为了{，之后的两个CVE就是对这个修复方式的绕过：这就是上面说到的对之前stripJavaEL修复的绕过，这里就不细分析了，利用$x格式就不会被替换掉（使用3.21.1版本测试）：这个漏洞对应上面搜索结果是ConstraintViolationFactory：buildConstraintViolationWith（标号1）出现在了HelperValidator（标号2）的isValid中，HelperValidator又被注解在HelperAnnotation（标号3、4）之上，HelperAnnotation注解在了HelperBean（标号5）之上，在ConstraintViolationFactory.createViolation方法中使用到了HelperBean（标号6、7）。按照这个思路要找调用了ConstraintViolationFactory.createViolation的地方。也来手动逆向回溯下看能不能回溯到有路由处理的地方。搜索ConstraintViolationFactory：有好几个，这里使用第一个BowerGroupRepositoriesApiResource分析，点进去看就能看出它是一个API路由：ConstraintViolationFactory被传递给了super，在BowerGroupRepositoriesApiResource并没有调用ConstraintViolationFactory的其他函数，不过它的两个方法，也是调用了super对应的方法。它的super是AbstractGroupRepositoriesApiResource类：BowerGroupRepositoriesApiResource构造函数中调用的super，在AbstractGroupRepositoriesApiResource赋值了ConstraintViolationFactory（标号1），ConstraintViolationFactory的使用（标号2），调用了createViolation（在后面可以看到memberNames参数），这也是之前要到达漏洞点所需要的，这个调用处于validateGroupMembers中（标号3），validateGroupMembers的调用在createRepository（标号4）和updateRepository（标号5）中都进行了调用，而这两个方法通过上面的注解也可以看出，通过外部传递请求能到达。BowerGroupRepositoriesApiResource的路由为/beta/repositories/bower/group，在后台API找到它来进行调用（使用3.21.1测试）：还有AbstractGroupRepositoriesApiResource的其他几个子类也是可以的：对应上面搜索结果的CleanupPolicyAssetNamePatternValidator，可以看到这里并没有做StripEL清除操作：这个变量是通过报错抛出放到buildConstraintViolationWithTemplate中的，要是报错信息中包含了value值，那么这里就是可以利用的。搜索CleanupPolicyAssetNamePatternValidator：在CleanupPolicyAssetNamePattern类注解中使用了，继续搜索CleanupPolicyAssetNamePattern：在CleanupPolicyCriteria中的属性regex被CleanupPolicyAssetNamePattern注解了，继续搜索CleanupPolicyCriteria：在CleanupPolicyComponent中的to CleanupPolicy方法中有调用，其中的cleanupPolicyXO.getCriteria也正好是CleanupPolicyCriteria对象。toCleanupPolicy在CleanupPolicyComponent的可通过路由进入的create、previewCleanup方法又调用了toCleanupPolicy。构造payload测试：然而这里并不能利用，value值不会被包含在报错信息中，去看了下RegexCriteriaValidator.validate，无论如何构造，最终也只会抛出value中的一个字符，所以这里并不能利用。
与这个类似的是CronExpressionValidator，那里也是通过抛出异常，但是那里是可以利用的，不过被修复了，可能之前已经有人提交过了。还有其他几个没做清除的地方，要么被if、else跳过了，要么不能利用。人工去回溯查找的方式，如果关键字被调用的地方不多可能还好，不过要是被大量使用，可能就不是那么好处理了。不过上面几个漏洞，可以看到通过手动回溯查找还是可行的。可以参考下@iswin大佬之前的分析https://www.anquanke.com/post/id/171116，这里就不再去调试截图了。这里想写下之前对这个漏洞的修复，说是加了权限来修复，要是只加了权限，那不是还能提交一下？不过，测试了下3.21.1版本，就算用admin权限也无法利用了，想去看下是不是能绕过。在3.14.0中测试，确实是可以的：但是3.21.1中，就算加了权限，也是不行的。后面分别调试对比了下，以及通过下面这个测试：才知道3.14.0与上面这个测试使用的是org.apache.commons.jexl3.internal.introspection.Uberspect处理，它的getMethod方法如下：而在3.21.1中Nexus设置的是org.apache.commons.jexl3.internal.introspection.SandboxJexlUberspect，这个SandboxJexlUberspect，它的get Method方法如下：可以看出只允许调用String、Map、Collection类型的有限几个方法了。看完上面的内容，相信对Nexus3的漏洞大体有了解了，不会再无从下手的感觉。尝试看下下其他地方，例如后台有个LDAP，可进行jndi connect操作，不过那里调用的是context.getAttribute，虽然会远程请求class文件，不过并不会加载class，所以并没有危害。有的漏洞的根源点可能会在一个应用中出现相似的地方，就像上面那个buildConstraintViolationWithTemplate这个keyword一样，运气好说不定一个简单的搜索都能碰到一些相似漏洞（不过我运气貌似差了点，通过上面的搜索可以看到某些地方的修复，说明已经有人先行一步了，直接调用了buildConstraintViolationWithTemplate并且可用的地方似乎已经没有了）仔细看下上面几个漏洞的payload，好像相似度很高，所以可以弄个类似fuzz参数的工具，搜集这个应用的历史漏洞payload，每个参数都可以测试下对应的payload，运气好可能会撞到一些相似漏洞以上是“Nexus Repository Manager 3几次表达式解析漏洞的示例分析”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注云编程开发博客行业资讯频道！

相关推荐: 应用下载需警惕,“猜你妹”病毒潜伏应用市场伺机刷流氓应用

概述 游戏猜的正嗨的时候,突然提示系统存在安全漏洞,吓死本宝宝有没有,在线等要不要修复?小伙伴遇到此类提示可千万别点,这是在骗你安装恶意程序。 近期,腾讯移动安全实验室和腾讯反诈骗实验室就发现一款名为”猜你妹”恶意游戏应用潜伏于各大应用市场,在特定的条件下伺机…