- 微信
- 微博
  
  分享文章到微博
- 复制链接
  
  复制链接到剪贴板

php代码审计-zzcms

亿人安全发表于 2023/03/31 10:02:52 2023/03/31

【摘要】环境搭建：代码审计1.xxe漏洞通过搜索，发现 xml_unserialize() 对 parse() 函数进行了调用，再去搜索xml_serialize()函数的调用情况在该处发现xml_serialize()函数调用并且参数可控，紧接着在该文件中简单翻找中发现了一个我认为造成该漏洞至关重要的函数。parse_str()函数可以把传递的字符串解析为变量，也就是说这里传递过去的字符串可以当做...

环境搭建：

代码审计

1.xxe漏洞

通过搜索，发现 xml_unserialize() 对 parse() 函数进行了调用，再去搜索xml_serialize()函数的调用情况

在该处发现xml_serialize()函数调用并且参数可控，紧接着在该文件中简单翻找中发现了一个我认为造成该漏洞至关重要的函数。

parse_str()函数可以把传递的字符串解析为变量，也就是说这里传递过去的字符串可以当做参数进行使用。在上面一行可以发现这里的 $code 是可以直接控制的，但是这里 $code 的参数值经过_authcode() 函数的处理，我们去跟进下该函数。

大致看下该函数是用于加解密字符串的， $string 参数传入我们需要加解密的字符串，这里也就是我们上述可控的 $code ； $operation 默认为DECODE也就是解密字符串，而 $key 则为加解密的秘钥。这里的秘钥默认为123456，在代码的第500行也有体现。

由于 $code 这里可控，所以下面的 $get['time'] 、 $get['action'] 可控

在代码59行判断我们传入的$get['action']方法是否为数组中的其中一个，如果是的话调用该方法，并将$get 、 $post 以参数形式传递。目前可知 $get 、 $post 我们可控。接下来的目标就是要去数组中找找在这些方法中有没有执行危险操作的方法。

通过查看这些方法，发现 updateapps() 方法中使用 preg_replace() 将我们传入的内容进行正则匹配替换并通过 fwrite() 保存到配置文件。而这里的 $post['UC_API'] 是可控的，所以这里我们可以替换任意内容到配置文件中。

漏洞复现：

由前面的代码分析可知, $code 参数我们需要构造的内容要满足两点：① $timestamp - $get['time']> 3600 ② $get['action']=updateapps; 且要通过 _authcode() 解码，所以我们这里要将 $code 的内容先进行编码这里 $code 传入加密后的内容，而 $post 的内容按照XML格式构造才能解析。

POC如下：

配置文件中已经被我们成功写入一句话

2.任意文件删除

在搜索 unlink() 函数时发现该系统大部分删除处都调用一个名叫 checkstr() 的函数来检测传入内容的合法性，但还是发现后台一处存在漏洞的功能点。

我们跟进该文件并向上回溯 unlink() 下 $file 参数是否可控，最终在代码14、15行发现了该文件两个可控参数，而这里的 $mlname 参数正是此处的关键所在，我们接着向下看。

在代码38行的 $action 是我们可控的， $mlname 也是我们可控的，这里通过 $mlname 传入文件夹名并遍历出该文件夹下的文件，最终将文件名赋值给 $file 。最终在上述的 unlink() 函数中实现遍历删除文件。

当文件夹下的文件全部遍历删除后，再通过代码底部 rmdir() 删除传入的文件夹。

漏洞复现：

通过上面分析我们构造出路由进行文件删除测试，通过上面代码过滤了 ../ ，我们通过 ..\ 绕过该处过

滤

3.前台XSS漏洞

这可能是第一次去写XSS审计的代审解析，因为我总认为大部分的XSS不需要代码层的介入，只要在日常

测试的过程中遵循见框就插的原则测试就可以。今天也是无意间看到该处的XSS漏洞就去给大家分析一

下，以后可能在XSS漏洞审计的方面会非常的少。

由于该系统并没有严格的遵循MVC开发模式去开发，大部分的前后端代码都写在一个php文件中，如下

面我们看到的这个php文件。在该PHP文件中本应该是有权限校验的，并且该权限还是后台admin权

限，但是这里的 $_COOKIE["UserName"] 是我们可以伪造的，以致于可以绕过这里的逻辑校验。

通过HTML代码可以看的出这是一处上传的功能点，并且这里直接通过GET方式传递两个参数并通过echo直接输出，传递过程中没有任何过滤造成XSS。

一些MVC框架大多都使用了模板，并没有直接传入参数而是通过模板渲染进行输出的，如果在传输的过程中没有进行过滤或者转义的话也会造成XSS。

漏洞复现：

我们在Cookie中加入UserName值

4.SQL注入漏洞

在搜索关键字时发现一处SQL语句参数可控的地方，很明显的发现这里的 $classname 参数是可控的

在代码开始处可以看出这里的 dowhat 参数可控，我们可直接控制该参数进入 modifybigclass() 函数。跟进 modifybigclass() 函数

在该函数中我们可以控制 action 参数走到存在漏洞的if条件中，而由我们上述说提到的这里的classname直接通过POST传入并拼接到SQL语句中，最后通过代码340行query()执行SQL语句。

query() 中封装了 mysqli_query() 去执行SQL语句。

漏洞复现：

从上面的分析可以看出这里的是存在盲注的，接下来我们用payload测试下

经过测试我们发现这里的语句已经完整闭合，但却没有执行我们的sleep()函数造成页面延时，大家可以

查看代码分析是什么原因导致这里的payload没有执行的。

5.逻辑缺陷导致的暴力破解

该处问题其实是在黑盒测试的时候发现的，由于我们这里探讨的是代码中存在的问题，所以更关注的是代码的底层逻辑是如何实现的，我们去看看该处的漏洞是如何产生的。在登录测试时发现该处登录页面有验证码和登录次数的校验

这段代码中主要存在问题的是下面这段代码，首先通过 getip() 获取我们登录的ip地址，大概率这个函数是有问题的。将获取到的IP地址直接拼接在SQL语句中并且在15分钟内登录次数不能尝试超过10次，最后通过 checkyzm() 来进行验证码校验。

getip ()函数中，可以通过XFF的形式获来获取IP地址，所以存在伪造的情况，而下面的 check_isip()则会检测ip地址的合法性，这里防止了SQL注入。

而上述代码中的 checkyzm() 函数用来判断验证码是否准确，而恰恰该封装函数也是存在逻辑缺陷，所以才导致这里会造成暴力破解的可能。跟进 checkyzm() 函数：该函数通过判断传入的验证码与SESSION中的验证码是否相同而忽略了验证码可重用的问题。应该对每次提交的验证码进行删除并重新生成SESSION中的验证码，所以这里在设计时是存在逻辑缺陷的。