- 背景
乌云还在的时候，猪猪侠爆一个XX银行的OGNL表达式注入漏洞，拿到了第一滴血。然后，唐朝实验室爆了个Spring-Boot的SPEL注入漏洞，虽然不是第一滴血，但是让我有了一个想法。因为看到过曾经黑帽大会有国外研究者写的一个很好的Paper：名字：us-15-Kettle-Server-Side-Template-Injection-RCE-For-The-Modern-Web-App-wp.pdf 里面提到了服务器端模板注入导致的远程命令执行类型漏洞产生。
- 萌芽
我对远程命令执行漏洞的理解就是以各种方式直接或间接的导致远程服务器执行成功了你想要让它执行的系统命令的一类漏洞，英文叫：Remote Command Execute Vulnerability（简称RCE漏洞），这是一种很简单暴力的漏洞，一种一言不合就可以rm -rf /或者 format /fs C: 的致命漏洞。哪么都有些什么类型的命令执行漏洞，可以看看exploit-db上关于RCE漏洞的exp有哪些。点击查看
下面是我简单的归了一下类别，RCE漏洞包括但不限于下面提到的。
- 应用程序开发框架里的RCE
这里的框架包括但不仅限于：Struts2框架/xwork框架，ThinkPhp框架，Spring框架 ，IOSurface编程框架类
- 中间件平台/服务应用平台的RCE
这里的代表就举例之前火的JAVA反序列化漏洞影响下的：WebLogic/Jboss/WebSphere/Jenkins、还有比如IIS,nginx，apache因文件名解析，路径解析问题导致的命令执行类，还有Elasticsearch，Redis，Zabbix ，mongodb等各种为业务应用，为数据存储提供服务的软件的命令执行类。
- 应用程序里的RCE
应用程序编写中调用系统API接口，调用系统命令执行函数，程序中系统命令执行相关方法的不恰当使用等导致的一类。
- 第三方应用里的RCE
最喜闻乐见的就是各种CMS被曝SQL注入，命令执行漏洞，代码执行漏洞，这类CMS共同特点就是支持第三方插件，支持用户对原cms程序框架结构进行改造。当然还有之前火了的ImageImagick图形处理库的RCE，和 fffmep导致的RCE等等。
- 等等等
穷尽脑汁就想到了上面这些，有遗漏的典型分类还望大牛多多留言不吝赐教。
然后我好奇的上乌云搜了搜公开的漏洞里（PS: 打开虚拟机搜了搜）关键字：命令执行 的案例。
公开的有2373个案例，119页，我翻了很多页案例，其中以刷Struts2的S2-xxx的最多。命令执行漏洞案例里我看到了下面几类：
- OGNL表达式|程序代码注入导致的RCE
1.Struts2的S2-xxx系列，
2.参数里注入或直接传值OGNL表达式，
3.变量名里或参数里注入编程语言基本语法代码
- 系统命令注入|模板代码注入导致的RCE:
1.变量名里或参数里注入系统命令，
2.变量名里或参数里注入框架模板代码，
- 配置或业务设计不当导致的RCE
1.RMI对外匿名开放或服务未授权导致
2.文件解析执行绕过
3.缓存模板，日志记录，请求信息等被带入奇葩业务执行的
4.业务应用接口,系统接口等权限不当导致的
- 等等。。。
我的重点放在了参数中被带入了系统命令，程序代码，OGNL表达式，模板代码之类导致的RCE漏洞发生的情况。这类情况，有个共同点，大都是通过HTTP/HTTPS请求出现。之前，顺着之前流行的sqlmapapi的思路，我想是否可以同样实现一个， 你上着网就把漏洞给挖出来了呢？萌生了这个想法，于是就有了这么个小脚本。
- 实现.
基于sqlmapapi的实现思路，同样用到了代理正常流量，提取Fuzzing点，带入测试payload进行Fuzzing测试。
实现环境：
第三方模块（版本）：
- requests (2.9.1)、tornado (4.3)
先用Tornado实现代理正常上网，定义SSTIF_Fuzz类用于进行测试，SSTIF_Fuzz类里面定义了下面的函数：
- _init_payloads_： 初始化各种测试payload的函数，里面现在已经具备了一些测试payload，包括通用的，PHP基础代码，JAVA语法的，OGNL表达式，EL表达式，SPEL表达式，Groovy测试payload，鸟哥爆的CA
technologies存在远程命令执行漏洞poc.（暂时就这么多，会不断补充，除非证明此思路此脚本不可行。） - HttpHelper
：发出带有payload的构造好的请求，根据规则（响应数据包括字符串：10516*61501的结果：646744516，或者在自己配置的cloudeye里面手工确认）判定是否存在RCE漏洞。 - Fuzzing_GET
：分析GET请求中的变量-值（key-value）组合，目前是对每一个value进行测试，未实现对key即变量名进行测试。 - Fuzzing_HEADER：未实现，因为在乌云的案例中，发现有在Referer中，注入命令导致的RCE的案例，所以未来会考虑对这里的参数进行测试。
- FileHelper：将测试可能存在RCE漏洞的记录在
rce_success_result.txt文件里，格式例如：+==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==+
+=+URL: http://202.111.222.333/index.jsp?id=1111&page=222&count=123
+=+method: GET
+=+param: id
+=+payload: java.lang.Runtime.getRuntime().exec('cat</etc/passwd;$BASH')
+==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==+
记录上面的一条，就可以比较清晰的看出要表达的意思了。
- 使用.
1、安装第三方模块
pip install requests
pip install tornado
2、修改SSTIF_Fuzz类中配置文件：
大概在第49行：
self.my_cloudeye = “xxxx.dnslog.info” 这里配置为你的dnslog的域名地址。
3、然后找到一个没有使用的端口，命令：
python ssitf.py 8081 启用代理监听8081端口
4、和设置burpsuite一样，浏览器设置通过8081代理端口上网，然后后面就像使用Sqli半自动化工具那样安心上你的网吧。
注意：
ProxyHandler类中定义了黑名单请求后缀，域名黑名单，这是为了避免带来麻烦的，可以自己添加：大概在246-250行代码处：
url_ext_black = ['ico','flv','css','jpg','png','jpeg','gif','pdf','ss3','txt','rar','zip','avi','mp4','swf','wmi','exe','mpeg']
domain_black = ['gov.cn','gov.com','mil.cn','police.cn','127.0.0.1','localhost','doubleclick','cnzz.com','baidu.com','40017.cn','google-analytics.com','googlesyndication','gstatic.com','bing.com','google.com','sina.com','weibo.com']
- 总结.
这个脚本做了什么：
- 从乌云上，从国外的研究者paper上拔下来了一些payload，作为fuzzing的依据。
- 实现了代理，从正常上网流量中提取GET和POST请求中的提取有效的参数作为Fuzzing测试点。
- 实现了个初级版本。
反思不足：
- payload是固定死的，这是一大弊端。
- 无法支持HTTPS流量的处理，这是技术盲点。
- Fuzzing太慢，目前是单线程的。
- Fuzzing情况考虑不全，应该是思路和认知盲点。
- 没有考虑狗，软硬防护产品的拦截绕过问题。
最后，看了很多案例，RCE其实就是插入那些东西进去，带入那些东西进去就可以简单初步判断是否存在该漏洞了，我感觉这是一种不错的思路，只是要实现自己的自动化挖掘漏洞神器还是长路漫漫~
Github地址：
SSTIF
欢迎测试，提出意见~
国外的一个自动化服务端模板注入检测和利用工具：https://github.com/epinna/tplmap http://www.mottoin.com/91727.html
