3. 中间件安全基础(三)
0x00 前言
前两篇文章我们对六款中间件的基本信息和相关的安全配置做了介绍，这篇文章我们主要就中间件常见的漏洞利用方式及修复方法做出讲解。如果某些地方存在疑问可以对比着前两篇文章阅读，更好地加深理解。
0x01 Apache
解析漏洞是指非程序文件被异常解析为程序文件的漏洞，利用这种漏洞可以绕过一些安全检测从而获取webshell，Apache和IIS的解析漏洞是较为经典的漏洞场景。
Apache
在Apache 1.x和Apache 2.x中存在解析漏洞，它的利用形式如图所示
可以看到图中访问的文件名为为test.php.xxx，正常情况下遇到一个未知的文件名应该是提示下载或者将文件显示出来，但是这里执行了php代码并显示出phpinfo函数的执行结果，这就是Apache解析漏洞。test.php.xxx的内容为：
<?php
phpinfo();
?>
Apache在解析文件时有一个原则：当碰到不认识的拓展名时，将会从后向前解析，直到碰到认识的拓展名为止，如果都不认识则会暴露其源码。那么Apache认识哪些文件名呢？在mime.type文件中有详细的拓展名列表
这个问题本质是一个配置问题，新版本的Apache默认情况下已经不存在这个漏洞，不过人为的修改配置文件依然可以引起解析错误，比如在Apache的配置文件httpd.conf中加入：AddHandler php5-script.php，就可以触发解析漏洞。
另外一种情况：如果在Apache中.htaccess可被应用（Apache的配置文件httpd.conf中对目录的AllowOverride设置为All时，apache会应用目录下.htaccess中的配置 By sfasfas），那可以尝试在.htaccess中写入:
<FilesMatch “shell.jpg”> SetHandler application/x-httpd-php </FilesMatch>
然后上传覆盖原有的.htaccess文件，再上传一个shell.jpg木马文件，这样shell.jpg就可解析为php文件。
IIS
IIS解析漏洞也算是一种比较久远的漏洞，在IIS5和IIS6下有下面这两种方式
目录解析：/xx.asp/xx.jpg
文件解析：xx.asp;.jpg
第一种，在网站下建立文件夹的名字为 .asp、.asa 的文件夹，其目录内的任何扩展名的文件都被IIS当作asp文件来解析并执行。例如创建目录1.asp，那么/1.asp/mm.jpg将被当作asp文件来执行。假设攻击者可以控制上传路径名，那就可以以任意的后缀名上传文件然后获取shell了。
第二种，在IIS6.0下，分号后面的不被解析，也就是说xx.asp;.jpg会被服务器看成是xx.asp。IIS6.0 默认的可执行文件除了asp还包含这三种asa、cer、cdx。
在IIS7.0和IIS7.5版本下也存在解析漏洞，在默认Fast-CGI开启状况下，在一个文件路径/xx.jpg后面加上/xx.php会将 /xx.jpg/xx.php 解析为 php 文件。常用利用方法：将一张图和一个写入后门代码的文本文件合并，要使用二进制的写入方式，避免破坏图片文件头和尾，命令如下：
copy xx.jpg/b + yy.txt/a xy.jpg
0x02 逻辑漏洞
IIS写权限漏洞
这也是IIS的一个经典漏洞，他的本质是源于对服务器的WebDAV配置不当，现在IIS默认关闭了这个组件。
如果在IIS管理器开启了这个组件，就会允许直接将文件PUT到服务器上去，从而导致漏洞发生。
利用方式也比较简单，使用桂林老兵IIS写权限利用程序即可
提交数据包后会在服务端生成一个1.txt文件
但是这个txt并不会解析执行，需要再执行一次MOVE操作将txt文件修改为asp可执行文件
然后就可以访问shell
IIS短文件名漏洞
Windows下可以通过~表示短文件名，比如以某CMS生成的数据库备份文件为例
那么它就可以表示为很短的文件名
该短文件名有以下特征：只有前六位字符直接显示且相同，后续字符用~1指代，其中数字1还可以递增，后缀名最长只有3位，多余的被截断。同时在启用.net的IIS下暴力列举短文件名时有以下特性：访问构造的某个存在的短文件名，会返回404；访问构造的某个不存在的短文件名，会返回400。所以，利用这个特性，我们可以暴力破解网站文件。一旦爆破出了其文件名就可以直接访问直接访问
Tomcat 样例目录session操纵漏洞
Apache Tomcat默认安装包含”/examples”目录，里面存着众多的样例，其中session样例(/examples/servlets /servlet/SessionExample)允许用户对session进行操纵。因为session是全局通用的，所以用户可以通过操纵 session获取管理员权限。 示例如下，首先新建一个登陆表单login.jsp
再建一个后台模拟界面（用户登录才可进入）admin.jsp
然后是一个登录验证的代码login2.jsp
如果直接访问/examples/servlets/admin.jsp会跳转到login.jsp，因为没有登录无法访问
这个时候打开/examples/servlets/servlet/SessionExample
然后填入如下数据
提交后显示session已经写入
再次访问admin.jsp即可成功访问
0x03 Getshell
Tomcat后台获取webshell
Tomcat后台管理目录/manager/html中可以直接上传一个war文件（用于远程管理tomcat服务的脚本文件），来自动建立虚拟目录。
因此可以将jsp木马用打包后上传，这里要首先压缩为zip文件，然后将后缀改为war，上传后服务器自动解压，然后就可以访问虚拟目录下的木马。比如上传一个123.war的文件，上传到后台后自动生成一个同名文件夹
文件夹里既是之前的压缩的jsp木马访问即可
Weblogic后台获取webshell
Weblogic后台webshell也是通过部署war包获取的，其操作方法实质就是部署一个web项目，步骤如下。点击“部署”==>“安装”
然后上载文件，文件是一个包含webshell的war包
一直点击下一步，最后完成并在左上角激活更改，然后启动项目
然后shell即可访问
WebSphere后台获取webshell
WebSphere后台获取webshell实质也是部署web程序的过程，将shell.jsp打包到war包中，然后新建应用程序。
一直点击下一步直到安装完成，最后记得保存。
然后将新添加的weShell项目启动
然后访问shell即可
Jboss后台获取webshell
这里的后台指的是jmx-console，如果能够进入Jboss的jmx-console首先可以看到很多敏感信息，比如这些相关链接
进入最后一个链接可以看到服务器的敏感信息
jmx-console也是通过上传war包的形式获取webshell，但是这个上传有些不同。首先在jmx-console的首页找到如下链接
在页面中找到这么一个输入框
在输入框里输入war包的外网路径（需要将war包放到外网的服务器上），点击Invoke，addURL方法会将war下载到本地，然后在页面上方找到如下界面
点击Apply Changes后war包才会部署生效，然后就可以执行shell。
0x04 Java反序列化漏洞
漏洞简介
早在2015年的1月28号，国外研究人员Gabriel Lawrence 、Chris Frohoff 在AppSecCali上给出了一个报告，报告中介绍了Java反序列化漏洞可以利用Apache Commons Collections这个常用的Java库来实现任意代码执行，当时并没有引起太大的关注。后来FoxGlove Security安全团队的breenmachine 发布的一篇博客中介绍了如何利用Java反序列化漏洞，来攻击最新版的WebLogic、WebSphere、JBoss等这些大名鼎鼎的Java应用，实现远程代码执行，在文中博主直指这是2015年最被低估的漏洞。由于Apache Commons Collections这样的基础库有非常多的Java程序在使用，一旦编程人员误用了反序列化这一机制，使得用户输入可以直接被反序列化，就能导致任意代码执行，同时漏洞所造成的影响面也是非常广泛的。
漏洞分析
序列化就是把对象转换成字节流，便于保存在内存、文件、数据库中；反序列化即逆过程，由字节流还原成对象。Java中的ObjectOutputStream类的writeObject()方法可以实现序列化，类ObjectInputStream类的readObject()方法用于反序列化。下面是将字符串对象先进行序列化，存储到本地文件，然后再通过反序列化进行恢复的样例代码：
问题在于，如果Java应用对用户输入，即不可信数据做了反序列化处理，那么攻击者可以通过构造恶意输入，让反序列化产生非预期的对象，非预期的对象在产生过程中就有可能带来任意代码执行。
在拿到一个Java应用时，需要找到一个接受外部输入的序列化对象的接收点，即反序列化漏洞的触发点。我们可以通过审计源码中对反序列化函数的调用（例如readObject()）来寻找，也可以直接通过对应用交互流量进行抓包，查看流量中是否包含java序列化数据来判断，java序列化数据的特征为以标记（ac ed 00 05）开头。确定了反序列化输入点后，再考察应用的Class Path中是否包含Apache Commons Collections库（ysoserial所支持的其他库亦可），如果是，就可以使用ysoserial来生成反序列化的payload，指定库名和想要执行的命令即可：
java -jar ysoserial-0.0.2-SNAPSHOT-all.jar CommonsCollections1 'id >> /tmp/redrain' > payload.out
其中ysoserial是java反序列化工具，CommonsCollections1 是指定的库名（本例的漏洞就是由于Apache Commons Collections库造成的），whoami就是要执行的命令，生成的payload如图所示
然后通过先前找到的传入对象方式进行对象注入，数据中载入payload，触发受影响应用中ObjectInputStream的反序列化操作，随后通过反射调用Runtime.getRunTime.exec即可完成利用。
Weblogic
Weblogic曾多次被爆出反序列化漏洞，比如 CVE-2016-0638、CVE-2016-3510和CVE-2017-3248等。之所以频繁出现跟他的修复策略有关，Weblogic采用黑名单的方式过滤危险的反序列化类，只要发现可用并且未在黑名单之内的反序列化类，那么之前的防护就会被打破，系统就会遭受攻击。该漏洞影响WebLogic 10.3.6.0, 12.1.3.0,12.2.1.0, 12.2.1.1多个版本。利用程序如下（payload用上文提到的方法生成）
相应的自动化的检测和利用工具在网上已有公开，下图是利用本地搭建的环境进行的测试。
WebSphere
WebSphere的反序列化漏洞编号为CVE-2015-7450，漏洞文件为commons-collections.jar，对应端口为8880。默认情况下WebSphere会开启10个端口用于从不同接口上获取数据，在配置文件
IBM/WebSphere/AppServer/profiles/AppSrv01/properties/wsadmin.properties
中定义了8880端口的作用：用作SOAP协议的端口，用来交换特定的信息。
那么就可以使用如下payload检测，其中的base64编码是java序列化后的对象。
若返回如图所示的内容则证明存在漏洞
想要生成自定义的payload需要执行上文提到的ysoserial命令，最后对生成的数据进行base64编码然后将数据包中的payload替换即可。
Jboss
Jboss的Java反序列化漏洞与Weblogic和WebSphere基本是一致的，也是由于调用了存在漏洞的基础库Apache Commons Collections造成的，但是Jboss相对影响较小，因为要成功利用必须要找到程序接受外部输入的点，而此处的利用需要/invoker/jmx的支持，大部分情况下的实际场景，jboss都删除了jmx，所以让此处的利用大打折扣。在利用方式上与上文提到的WebSphere基本一致，都是直接发送一个序列化的数据包，不过不需要base64编码。漏洞利用时发送如下的报文即可，其中payload替换成自己生成的payload。
也有相对简单的图形界面工具
0x05 其他
Weblogic的SSRF漏洞的CVE编号为CVE-2014-4210，问题出现在UDDI功能上，用户可以在这个界面进行信息搜搜
其中operator参数可以传入一个内网URL于是造成了对内网信息探测或漏洞利用，如下图所示探测IP为10.108.40.45的主机的端口号80，并提示返回提示，说明相应内网主机开启了80端口。
