zimbra xxe+ssrf 导致 getshell

Bertha 。 2021-09-01 10:37 411阅读 0赞

### 前言 ###

2019年３月13号，国外一名安全研究员在他的博客上公布了zimbra的这起漏洞，但是其中并未提到一些漏洞的利用细节，在此我将整个漏洞的利用过程进行复现。  
原文链接：https://blog.tint0.com/2019/03/a-saga-of-code-executions-on-zimbra.html\#href1\_ret

影响版本

*  Zimbra < 8.7.1 攻击者可以在无需登录的情况下，实现getshell
 *  Zimbra<8.8.11 在服务端使用Memcached做缓存的情况下，经过登录认证后的攻击者可以实现远程代码执行

预防：由于zimbra官方已经及时对高版本的zimbra打了补丁，所以最新版只要及时更新补丁就可以预防(详情请见Zimbra官网)。

漏洞复现

复现环境

*  Zimbra 8.5.0
 *  ubuntu 14.04（172.16.123.134）（受害者服务器）
 *  ubuntu 18.04 (172.16.123.1)(攻击者服务器）

> 此处特别强调Zimbra只能安装在特定版本的linux发行版上，与ubuntu适配最好，且zimbra8.5不支持ubuntu14以上的发行版

环境搭建

Zimbra的环境搭建比较麻烦，在此推荐几篇有关zimbra搭建的优质博文  
https://www.jianshu.com/p/722bc70ff426  
几个关键点就是选择合适版本ubuntu虚拟机，主机hosts配置，dnsmasq的配置，最后，我们的环境可以不用配置ssl.

攻击流程

如果你阅读过原文，你应该已经知道我们需要利用xxe来读取目标主机的localconfig.xml文件，这个文件中有一个类似超级管理员用户的密码，而这个超级管理员的用户名默认就是zimbra，所以只要我们拿到这个密码在某种意义上来说就相当于已经获得了zimbra的最高权限。  
但是事情没有那么简单，Zimbra是使用token来进行权限管理的，而一个管理员的token只可能分配给一个来自7071端口的请求，而这个端口一般是不会对外开放的，所以，这就需要我们的ssrf上场了。但是这个ssrf利用也是有条件的，这个ssrf的利用点存在于源码中的 ProxyServlet.doProxy() 函数处，源码如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hlX2FuZA_size_16_color_FFFFFF_t_70]  
从上面的代码逻辑中可以看出，只有在token是作为parameter传递过来的才会对其进行验证，否则，如果token是从cookie传过来的则不会进入验证token这处逻辑，所以我们只需要得到一个合法的普通的token就行了，这个token要怎么获取呢？这里又要利用到一个Zimbra的特性了。

我们只需要将一个普通的soap　AuthRequest的用户名更改为zimbra就可以得到一个我们可以利用的token了（此处可能不够清晰，具体看后续复现的操作）这个token虽然是合法的，但是它具有admin属性，所以，我们要上传shell，还需要得到真正的admin　token,所以我们只需要利用刚刚的到的token发送一个admin soap AuthRequest,就可以在响应中得到真正的admin token了，接着再利用这个token来构造文件上传的请求，就可以得到一个webshell了。

> **刚刚漏了一处细节，由于doProxy这个方法会从服务端发送一个请求到目标主机，为了安全起见，Zimbra为可访问的目标主机设置了一个白名单，所以，我们还需要绕过这个白名单，具体方法就是修改host，因为Zimbra默认管理员做任何事都是合法的，而他判断是不是管理员的方式就是获取host中的port(如果是7071就是管理员，否则不是),所以所有来自7071端口的请求都会被认为合法（直接忽略白名单限制），所以我们只要将host更改为axin:7071,再发送这个proxy请求就行了**

复现过程

**xxe获取localconfig.xml**  
利用xxer.py搭建一个http以及ftp服务器，以此来接受xxe返回的数据  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hlX2FuZA_size_16_color_FFFFFF_t_70 1]  
ext.dtd文件内容如下：  
![在这里插入图片描述][20190326161636593.png]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hlX2FuZA_size_16_color_FFFFFF_t_70 2]  
上图中间的shell窗口就是攻击者ftp服务器收到的localconfig.xml文件内容，我们只是对ldap\_root\_password感兴趣，也就上图中的kAQbqtlab.

**获取低权限token**  
此处有几个细节需要注意，我之前以为只要改一下用户名就可以得到token，原来还是需要刚刚获取的密码正确才行，然后在xml文本中加入`<account by="adminName">zimbra</account>`,这样就能得到token了。接下来我们就可以利用这个token来进行ssrf,进而得到一个admin token。  
\`![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hlX2FuZA_size_16_color_FFFFFF_t_70 3]

**ssrf得到admin token**  
利用刚刚得到的token,构造一下cookie,注意token的名字需要改为ZM\_ADMIN\_AUTH\_TOKEN,否则会报no auth token错误  
然后Host头需要改为axin:7071,然后还需填入我们刚刚得到的用户名以及密码（zimbra–kAQbqtlab）这样构造一个请求发送过去(请求到admin验证的链接)，就会服务器就会返回一个经过认证的admin　token,接下来我们利用这个admin token上传shell  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hlX2FuZA_size_16_color_FFFFFF_t_70 4]

**getshell**  
由于我的虚拟机卡死，导致我从新复现了以此，所以读者可能看到现在的ZM\_ADMIN\_AUTH\_TOKEN与上面不一样了。但是操作还是一样的，直接拿着得到的admin token去请求这个upload连接，构造一个上传webshell的恶意请求，这样就可以直接上传shell了。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hlX2FuZA_size_16_color_FFFFFF_t_70 5]

成功得到shell:  
![在这里插入图片描述][20190326201327818.png]

> 注：我这里之前存在一个误区，我以为文件上传这个链接只能是7071端口才能访问，导致我还是利用ssrf来进行文件上传，结果就是一直报no auth token错误，最后仔细读了一下tint0的博文，发现并没有说要通过ssrf上传文件,于是我就直接构造了上面那个链接，完成了shell上传。

参考资料＆总结

在复现的过程中，出现了很多问题，最大的问题其实就是zimbra这个东西太复杂了，很多东西只有翻手册（甚至手册都翻不到），比如代理的使用，以及soap api的使用，这两个也是整个复现过程的关键，下面贴出链接：  
代理使用：  
https://wiki.zimbra.com/wiki/Zimlet\_Developers\_Guide:Proxy\_Servlet\_Setup  
soap的使用（普通soap 认证以及管理员soap认证调用方式）：  
https://files.zimbra.com/docs/soap\_api/8.0/soapapi-zimbra-doc/api-reference/index.html

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hlX2FuZA_size_16_color_FFFFFF_t_70]: /images/20210728/d57f3b37611c4dcdb9868a854a9b6414.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hlX2FuZA_size_16_color_FFFFFF_t_70 1]: /images/20210728/98dbcc7876e648baaab606bd6f2376b1.png
[20190326161636593.png]: /images/20210728/4304a5f646d94660873b562e939aa259.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hlX2FuZA_size_16_color_FFFFFF_t_70 2]: /images/20210728/3188d262a2274c3dab75c177b1aad87b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hlX2FuZA_size_16_color_FFFFFF_t_70 3]: /images/20210728/8406d23199d645cba240b298671b284e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hlX2FuZA_size_16_color_FFFFFF_t_70 4]: /images/20210728/4f9e24a2af484d0daba6c006c89f0aea.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hlX2FuZA_size_16_color_FFFFFF_t_70 5]: /images/20210728/5a8c912d2bc8469a8a89159c00af5bce.png
[20190326201327818.png]: /images/20210728/6cb848c8cf98480da6a6f1b3540ce32a.png