1. 项目概述如果你负责过企业级Java应用的运维或安全评估大概率对Oracle WebLogic Server这个名字不会陌生。作为一款重量级的Java EE应用服务器它在金融、电信、政府等关键行业里有着庞大的部署量。然而伴随着其广泛使用而来的是层出不穷的安全漏洞尤其是那些高危的Java反序列化漏洞一旦被利用往往意味着服务器权限的完全丢失。手动去验证这些漏洞你需要记忆一堆CVE编号、对应的URL路径、请求包构造方式效率低下且容易遗漏。今天要聊的WeblogicScan就是一款由国内安全研究员Tide_RabbitMask开发的专门用于一键化、自动化检测WebLogic历史漏洞的工具。它把那些繁琐的检测流程打包成了一个Python脚本你只需要提供一个IP和端口它就能帮你跑完几乎全部已知的高危漏洞检查并给出清晰的结果报告。这个工具特别适合几类朋友一是企业的安全运维人员需要定期对内部资产进行漏洞扫描二是渗透测试人员在授权测试中快速验证目标WebLogic服务器的安全性三是安全研究爱好者想要学习WebLogic漏洞原理及自动化检测的实现思路。WeblogicScan目前版本是V1.5虽然项目更新停留在2020年但它集成的漏洞覆盖了从2014年到2019年间多个关键的CVE包括著名的CVE-2017-10271XMLDecoder反序列化、CVE-2018-2628T3协议反序列化等对于排查历史遗留风险依然非常有效。接下来我会带你从工具的原理、使用到背后的技术细节彻底搞懂这个“WebLogic漏洞扫描利器”。2. 工具核心原理与架构设计2.1 漏洞检测引擎的工作逻辑WeblogicScan本质上是一个漏洞验证PoC集成框架而不是一个模糊测试Fuzzing工具。它的核心逻辑是“已知漏洞已知检测方法”。开发者Tide_RabbitMask事先分析了每一个目标CVE漏洞的成因和利用条件然后为每个漏洞编写了独立的检测模块在工具的poc目录下。当你运行脚本时它会按照既定顺序向目标WebLogic服务器的特定端口默认7001发送一系列精心构造的HTTP请求或T3协议数据包。这些请求的设计非常巧妙目的是为了触发漏洞的“特征”但又避免造成实际的破坏。例如对于反序列化漏洞检测请求可能包含一个经过特殊构造、但无害的反序列化载荷通过分析服务器的响应如特定的错误信息、响应延迟、或返回的特定字符串来判断漏洞是否存在。这种“非侵入式”的检测是安全扫描工具的基本伦理也是WeblogicScan在代码中强调“仅用于安全测试”的原因。2.2 支持的漏洞类型与分类工具V1.5版本主要集成了四大类漏洞这也是WebLogic历史上最典型的几类安全问题信息泄露类主要是控制台路径泄露。WebLogic的管理控制台Console如果配置不当可能无需认证即可访问这会暴露一个极大的攻击面。工具会尝试访问/console/login/LoginForm.jsp等路径来验证这一点。服务端请求伪造SSRF对应CVE-2014-4210。这个漏洞存在于UDDI Explorer组件中攻击者可以利用它让WebLogic服务器向内部网络发起任意HTTP请求从而探测或攻击内网服务。Java反序列化漏洞这是重灾区也是工具检测的重点。涵盖了从2016年到2019年的多个CVE如CVE-2016-0638、CVE-2018-2628、CVE-2019-2725等。这类漏洞通常通过WebLogic的T3协议、RMI通信或HTTP接口触发能够导致远程代码执行RCE。XMLDecoder反序列化漏洞以CVE-2017-10271和CVE-2017-3506为代表。漏洞存在于WebLogic的WLS Security组件中通过发送一个恶意的XML数据到特定的HTTP端点如/wls-wsat/CoordinatorPortType可以触发XMLDecoder解析并执行任意Java代码。任意文件上传CVE-2018-2894。该漏洞允许攻击者通过WebLogic管理控制台的上传功能将恶意文件上传到服务器从而获取shell。工具通过模块化的设计将每一类、每一个CVE的检测逻辑封装成独立的函数或类使得引擎可以灵活地调用和扩展。2.3 网络通信与协议处理WeblogicScan的检测涉及两种主要的网络协议HTTP/HTTPS和T3协议。对于HTTP类的检测如控制台泄露、SSRF、XMLDecoder漏洞工具使用Python的requests库或urllib来构造和发送HTTP请求。这里有一个关键点连接超时和读取超时的设置。在企业网络环境中目标服务器可能响应缓慢或存在网络抖动。如果超时设置过短会导致大量误报将存活的服务判为不存在漏洞设置过长又会极大影响扫描效率。WeblogicScan在代码中通常会有合理的默认超时设置比如3-5秒但在实际使用中根据网络状况调整这些参数是必要的。对于T3协议的反序列化漏洞检测如CVE-2018-2628情况则复杂得多。T3是WebLogic专用的高性能RMI通信协议。检测时需要先与目标端口建立Socket连接然后按照T3协议格式组装并发送序列化后的检测载荷。这要求工具能够正确构造T3协议头、处理Java序列化流。WeblogicScan的Whoareu模块就是基于T3协议进行版本识别的它通过发送一个特定的T3握手请求从服务器的响应中提取出版本信息。精准的版本识别有助于缩小漏洞检测范围提高效率。3. 环境准备与工具部署3.1 系统与Python环境要求WeblogicScan是一个纯Python编写的工具因此具有很好的跨平台性可以在Windows、Linux或macOS上运行。它的核心依赖是Python 3。虽然早期版本支持Python 2但V1.3之后已全面转向Python 3这也是当前的主流和安全选择。在开始之前请确保你的系统已经安装了Python 3.6或更高版本。你可以通过在命令行输入python3 --version或python --version来检查。如果未安装请前往Python官网下载安装。建议使用虚拟环境如venv或conda来管理项目依赖避免污染全局环境。3.2 获取与安装WeblogicScan工具的源代码托管在GitHub上。由于网络访问的差异性这里提供两种常见的获取方式方式一直接克隆GitHub仓库推荐如果你所处的网络环境可以顺畅访问GitHub这是最直接的方法。打开终端或命令提示符执行git clone https://github.com/rabbitmask/WeblogicScan.git cd WeblogicScan这条命令会将最新的代码库下载到当前目录下的WeblogicScan文件夹中。方式二下载ZIP压缩包如果git clone速度不理想你可以直接访问项目的GitHub页面点击绿色的“Code”按钮然后选择“Download ZIP”。下载完成后在本地解压即可。进入工具目录后你需要安装必要的Python依赖包。工具根目录下通常有一个requirements.txt文件它列出了所有需要的库。使用pip一键安装pip3 install -r requirements.txt主要的依赖库通常包括requests用于HTTP请求和colorama用于终端彩色输出等。安装过程通常很快。如果遇到权限问题可以在命令前加上sudoLinux/macOS或以管理员身份运行命令提示符Windows。注意在某些严格的内网环境或离线机器上可能无法直接连接互联网进行pip install。针对这种情况WeblogicScan在早期的V1.2版本中曾提供一个离线安装模式/whl/文件夹和install.py但根据V1.4的更新日志这个模式在后续版本中被移除了。对于离线环境通用的做法是在一台能联网的机器上使用pip download -r requirements.txt -d ./offline_packages将所有依赖包.whl或.tar.gz文件下载到本地然后拷贝到离线机器上使用pip install --no-index --find-links./offline_packages -r requirements.txt进行安装。3.3 首次运行验证与常见问题安装完依赖后你可以先运行帮助命令来验证安装是否成功python3 WeblogicScan.py -h如果一切正常你应该会看到那个标志性的ASCII艺术字Banner以及简洁的参数说明。这表示工具已经准备就绪。首次运行可能遇到的问题“python3: command not found”这表示你的系统没有将Python 3的可执行文件加入环境变量。在Windows上你可能需要检查安装时是否勾选了“Add Python to PATH”。在Linux/macOS上可以尝试使用python命令或者通过which python3查找具体路径。有时Python 3的命令可能就是python。ModuleNotFoundError: No module named ‘xxx’这表示某个依赖库没有安装成功。请确保你是在工具所在的目录下运行的pip3 install -r requirements.txt。如果问题依旧可以尝试手动安装缺失的模块例如pip3 install requests。Windows系统下命令行显示乱码这通常是字符编码问题。可以尝试将命令行窗口的代码页改为UTF-8执行命令chcp 65001。或者使用更现代的终端如Windows Terminal它能更好地支持Unicode。4. 核心功能详解与实战操作4.1 单目标扫描精准探测这是最基础也是最常用的功能。当你已经明确知道一个WebLogic服务器的地址和端口时使用-u和-p参数。python3 WeblogicScan.py -u 192.168.1.100 -p 7001-u(IP)指定目标服务器的IP地址。-p(PORT)指定WebLogic的监听端口默认是7001。如果目标服务器将管理端口修改为其他如7002、8001务必在此指定。执行后工具会依次进行以下工作Banner展示与初始化打印出工具标识。版本识别Whoareu模块首先尝试通过T3协议与目标通信获取精确的WebLogic版本号如10.3.6.0、12.2.1.3.0。这一步非常关键因为不同版本的漏洞存在情况差异很大。顺序漏洞检测按照内置的漏洞列表逐个发送检测请求。在控制台上你会看到实时的输出[]表示检测到该漏洞。[-]表示未检测到该漏洞。[*]表示任务开始或结束的信息。结果汇总所有检测完成后会输出“Task End”。实战技巧理解输出内容以一段输出为例[] [192.168.1.100:7001] Weblogic Version Is 10.3.6.0 [] [192.168.1.100:7001] Weblogic console address is exposed! [-] [192.168.1.100:7001] weblogic not detected CVE-2017-10271 [] [192.168.1.100:7001] weblogic has a JAVA deserialization vulnerability:CVE-2018-2628第一行告诉你目标的版本是10.3.6.0即WebLogic 10g这是一个相对古老的版本漏洞较多。第二行是一个高危发现控制台路径暴露。这意味着http://192.168.1.100:7001/console可能可以直接访问为后续的爆破或利用提供了入口。第三行显示CVE-2017-10271未检测到这可能是该版本已打补丁或组件未启用。第四行显示检测到了CVE-2018-2628这是一个极其危险的T3反序列化漏洞可导致远程代码执行需要立即处理。4.2 批量扫描高效资产梳理在内部安全巡检或红队演练中你往往需要面对一个IP地址列表。手动一个个输入效率太低。WeblogicScan的-f参数就是为批量扫描而生。首先你需要准备一个文本文件例如targets.txt里面按行存放要扫描的目标。格式非常灵活192.168.1.100 192.168.1.101:7001 10.0.0.5:8001 domain.com可以只写IP工具会使用默认端口7001。可以指定IP:PORT格式。甚至可以使用域名。然后运行命令python3 WeblogicScan.py -f targets.txt工具会读取文件自动解析每一行并依次进行扫描。所有结果会统一输出到控制台并且详细的扫描过程会同步记录到Weblogic.log日志文件中。批量扫描的注意事项网络超时设置批量扫描时网络状况不一的节点可能导致整个扫描进程卡住。虽然WeblogicScan V1.4之后声称解决了“脚本异常卡死问题”但在实际大规模扫描中建议结合其他手段。例如可以使用timeout命令Linux或编写外层脚本来控制每个目标的扫描时间。日志分析Weblogic.log文件是纯文本记录了时间戳和每一条检测结果。这对于后续的审计、报告生成至关重要。你可以用grep命令快速过滤出所有[]的结果grep ^[0-9].*\[\] Weblogic.log。性能与礼貌不要对单一目标或整个网络发起过高频率的扫描。这可能会触发目标的入侵检测系统IDS/IPS甚至对目标服务器造成拒绝服务DoS影响。在授权测试中也应合理安排扫描节奏。4.3 结果解读与日志分析控制台输出提供了即时反馈而Weblogic.log则提供了完整的、可追溯的审计记录。日志的每一行都遵循固定的格式时间戳 [检测结果] [目标] 详细信息。如何高效利用日志漏洞统计你可以编写简单的脚本从日志中提取所有带[]的行然后按CVE编号进行排序和去重快速生成一个漏洞分布统计。问题排查如果某个漏洞在所有目标上都显示[-]可能是该漏洞的检测脚本PoC本身在网络环境或特定WebLogic配置下失效了。查看日志中该漏洞检测前后的网络请求记录如果工具开启了更详细的调试日志有助于分析原因。证据保存在正式的渗透测试报告中这些带有时间戳的日志记录是重要的测试证据。实操心得我习惯在每次启动批量扫描前先备份或重命名旧的Weblogic.log文件例如mv Weblogic.log Weblogic.log.bak或者使用--log参数如果工具支持指定新的日志文件路径这样可以保证每次扫描的结果都是独立的避免混淆。5. 检测漏洞原理解析与修复建议了解工具检测了什么漏洞以及这些漏洞为何危险能帮助你在拿到结果后采取正确的行动。下面挑选几个经典的漏洞进行剖析。5.1 CVE-2017-10271 (XMLDecoder反序列化)原理简述WebLogic的WLS Security组件对外提供了Web服务SOAP其端点如/wls-wsat/CoordinatorPortType在处理SOAP请求时使用了XMLDecoder来解析XML数据。XMLDecoder是Java中一个用于将XML编码转换回Java对象的功能类但其设计上存在安全隐患可以用于实例化任意Java类并执行其方法。攻击者通过构造一个包含恶意Java代码的SOAP请求发送到该端点即可实现远程代码执行。WeblogicScan的检测逻辑工具会向目标服务器的/wls-wsat/CoordinatorPortType等已知的漏洞路径发送一个特制的SOAP请求包。这个请求包中包含了一段利用XMLDecoder执行无害命令如ping一个不存在的地址或者执行echo的XML载荷。然后工具会检查服务器的响应。如果漏洞存在服务器会执行这段载荷并在响应中留下特定的痕迹如特定的错误信息、响应延迟工具通过匹配这些特征来判断漏洞是否存在。修复建议官方补丁立即安装Oracle发布的最新安全补丁Critical Patch Update, CPU。这是最根本的解决方法。临时缓解如果无法立即升级可以删除或限制访问wls-wsat组件对应的WAR包。具体路径通常在$DOMAIN_HOME/servers/AdminServer/tmp/_WL_internal和$DOMAIN_HOME/servers/AdminServer/tmp/.internal下找到包含wls-wsat的文件并移除。同时在防火墙或负载均衡设备上对/wls-wsat/路径的访问进行阻断。访问控制确保WebLogic控制台Console和管理端口不直接暴露在互联网上应通过VPN或跳板机进行访问。5.2 CVE-2018-2628 (T3协议反序列化)原理简述WebLogic的T3协议在处理反序列化数据时存在过滤缺陷。攻击者可以通过T3协议向WebLogic服务器发送恶意的序列化对象该对象在服务器端被反序列化时会触发精心构造的利用链通常利用InvokerTransformer、ChainedTransformer等类最终执行任意命令。WeblogicScan的检测逻辑工具会与目标的T3服务端口建立Socket连接然后发送一个精心构造的、利用java.rmi.registry.Registry进行绑定的序列化攻击载荷。这个载荷被设计为在反序列化时会尝试连接一个由检测工具控制的“假”的RMI服务地址。工具通过监听该地址是否收到连接尝试或者分析服务器返回的特定错误信息来判断漏洞是否存在。这是一种“回连”检测机制相对更可靠。修复建议打补丁应用Oracle官方补丁。限制T3协议访问这是最有效的临时加固措施。可以在WebLogic控制台的“域结构”-“环境”-“服务器”-选择具体服务器实例-“配置”-“协议”-“常规”下将“启用T3”的选项取消或者更精细地在“协议”-“T3”-“筛选器”中配置只允许受信任的IP地址访问T3协议。网络层隔离在防火墙规则中只允许必要的管理IP访问WebLogic的T3端口默认7001。5.3 CVE-2014-4210 (SSRF)原理简述WebLogic的UDDI Explorer组件通常路径为/uddiexplorer/中的SearchPublicRegistries.jsp页面在处理用户提供的operator参数时未对内部发起的HTTP请求目标进行有效过滤。攻击者可以构造一个包含内网地址如http://192.168.1.1:8080的请求让WebLogic服务器作为代理去访问该地址并根据返回的错误信息如连接超时、返回内容差异来探测内网存活主机和端口。WeblogicScan的检测逻辑工具会访问/uddiexplorer/SearchPublicRegistries.jsp并提交一个指向一个已知不存在的或特定的外部地址的operator参数。通过分析返回页面的内容判断是否存在SSRF漏洞的特征字符串或错误模式。修复建议删除或禁用组件直接删除uddiexplorer应用对应的WAR包或通过控制台将其部署状态改为“不活动”。更新补丁安装修复该漏洞的官方补丁。输入验证如果业务必须使用该组件应严格在代码层面验证operator参数限制其协议、主机和端口范围。6. 高级用法与脚本定制6.1 集成到自动化工作流WeblogicScan作为一个命令行工具很容易被集成到更大的自动化安全体系中。例如你可以将其与资产发现系统结合端口扫描联动使用nmap或masscan扫描出开放7001、8001等常见WebLogic端口的资产将结果导出为IP:PORT格式的列表直接作为-f参数的输入文件。nmap -p 7001,7002,8001 --open -oG - 192.168.1.0/24 | grep “/open/” | awk ‘{print $2}’ weblogic_hosts.txt python3 WeblogicScan.py -f weblogic_hosts.txt定时任务与告警在Linux服务器上你可以编写一个Shell脚本定期执行批量扫描然后使用grep分析Weblogic.log如果发现新的[]漏洞就通过邮件、钉钉、企业微信等机器人接口发送告警消息。与漏洞管理平台整合将扫描结果解析Weblogic.log转换成标准的格式如JSON、CSV然后通过API导入到像OpenVAS、Nexpose或自建的漏洞管理平台中实现统一的漏洞跟踪和生命周期管理。6.2 自定义检测策略与PoCWeblogicScan的代码结构比较清晰主要逻辑在WeblogicScan.py而具体的漏洞检测函数通常放在poc目录或集成在主脚本中。如果你有新的WebLogic漏洞PoC想要加入或者想调整现有检测的逻辑可以尝试自己修改。添加新PoC的通用思路研究漏洞理解新漏洞的触发点URL、协议、利用方式数据包格式和成功特征响应内容、错误码、延迟。编写检测函数在工具框架内仿照现有漏洞检测函数的格式编写一个新的函数。这个函数通常需要接收目标ip和port参数构造特定的请求发送并分析响应。集成到主流程在主扫描循环中调用你新写的检测函数。测试务必在可控的测试环境如自己搭建的漏洞靶场中充分测试确保检测准确且不会对目标造成损害。重要警告修改安全工具需要一定的Python编程能力和安全知识。错误的PoC可能导致扫描器崩溃、误报、漏报甚至可能违反安全测试的道德和法律边界。请仅在授权测试环境和出于学习目的进行尝试。6.3 性能调优与稳定性提升当扫描成百上千个目标时工具的稳定性和速度就变得很重要。调整超时时间在WeblogicScan.py中找到发起网络请求的地方通常是requests.get()或socket连接适当调整timeout参数。对于内网环境可以设短一些如2-3秒对于网络延迟高的环境可能需要设长一些如5-10秒。但要注意超时过长会严重影响批量扫描的总时长。引入并发/多线程原版的WeblogicScan是单线程顺序扫描的。你可以使用Python的concurrent.futures库或multiprocessing模块对其进行改造实现多线程并发扫描极大提升批量扫描效率。核心思路是将目标列表分发给多个工作线程/进程每个线程独立运行扫描函数。但必须小心处理共享资源如日志文件的写入避免冲突。错误处理增强工具自带的错误处理可能不够完善。你可以增加更详细的异常捕获和日志记录比如记录连接拒绝、超时、DNS解析失败等不同错误方便后续分析网络问题。7. 常见问题排查与解决实录在实际使用WeblogicScan的过程中你可能会遇到各种各样的问题。下面是我和同事们踩过的一些坑以及解决办法。7.1 扫描结果全为阴性[-]现象针对一个已知存在漏洞的测试环境如Vulhub、VulnHub上的WebLogic靶场运行工具后所有漏洞检测结果都是[-]。可能原因与排查步骤网络连通性问题这是最常见的原因。首先用ping和telnet或nc命令检查到目标IP和端口的网络连通性。ping -c 4 192.168.1.100 telnet 192.168.1.100 7001 # 或 nc -zv 192.168.1.100 7001如果telnet不通可能是防火墙阻止或者WebLogic服务未运行。目标服务并非WebLogic端口开放不代表一定是WebLogic。用浏览器访问http://ip:port或者用curl查看返回的标题和内容确认是否是WebLogic的默认页面。工具与目标版本不兼容WeblogicScan V1.5主要针对2019年及之前的漏洞。如果目标是更新版本的WebLogic如12.2.1.4, 14.x可能内置的PoC已经失效。此时版本识别Whoareu模块可能仍然有效可以先用-u参数扫描看能否正确识别出版本。PoC被防御措施绕过目标服务器可能部署了WAFWeb应用防火墙、入侵防御系统或者对WebLogic进行了深度加固拦截或篡改了工具发送的恶意请求。尝试关闭工具的代理设置如果使用了或者直接在有网络权限的环境测试。工具依赖或环境问题在极少数情况下Python环境或依赖库的版本冲突可能导致脚本运行异常。尝试在一个全新的Python虚拟环境中重新安装依赖并测试。7.2 工具运行卡住或无响应现象扫描到某个特定目标时工具停止输出长时间卡住甚至需要强制终止CtrlC。可能原因与排查步骤目标响应缓慢或网络延迟高工具在等待一个HTTP请求或Socket连接的响应。按照6.3节的方法适当调低超时时间。对于批量扫描建议使用外层脚本为每个目标扫描设置总超时。特定PoC逻辑缺陷某个漏洞的检测函数可能陷入死循环或者等待一个永远不会发生的事件如“回连”检测中等待连接。查看卡住时最后打印的日志定位到正在检测的CVE编号然后可以尝试在代码中临时注释掉该CVE的检测函数看是否能跳过。线程/进程阻塞如果自己改写了并发在自改的多线程版本中如果线程间同步或资源竞争处理不当可能导致死锁。7.3 误报与漏报的处理误报False Positive工具报告存在漏洞但实际不存在。原因PoC检测的逻辑可能不够精确服务器返回的某些正常响应恰好匹配了漏洞存在的特征。应对手动验证。根据工具报告的CVE编号和URL使用浏览器、curl或Burp Suite等工具手动访问相关路径发送检测载荷分析原始响应。这是渗透测试中确认漏洞的必要步骤。漏报False Negative工具报告不存在漏洞但实际存在。原因网络问题、目标环境差异如路径修改、PoC过时或不够完善。应对同样需要手动验证。可以搜索该CVE的其他公开PoC或利用脚本进行测试。同时检查Weblogic.log中该漏洞检测时的详细网络交互记录如果工具提供了调试输出选项看请求是否成功发送响应是什么。7.4 日志文件不生成或内容不全现象扫描完成后当前目录下没有Weblogic.log文件或者文件内容很少。排查步骤检查写入权限确保运行脚本的用户在当前目录有创建和写入文件的权限。检查脚本配置查看WeblogicScan.py源码中关于日志记录的部分通常是Python的logging模块配置。确认日志文件路径是相对路径./Weblogic.log还是绝对路径。如果是相对路径确保你的工作目录正确。程序异常退出如果脚本因为未捕获的异常而崩溃日志模块可能来不及写入缓存内容。尝试在脚本开头添加更全面的异常捕获或者用try...except包裹主函数。工具的价值在于快速初筛但它不能替代专业的人工分析和验证。尤其是在出具正式的安全报告前对工具发现的所有高危漏洞进行手动复核是安全从业人员必须恪守的职业准则。WeblogicScan作为一个已经归档的项目它很好地完成了它的历史使命为安全社区提供了一个简单易用的WebLogic漏洞检测方案。理解它的原理善用它并在其基础上结合自己的经验进行判断和扩展才能让它真正成为你安全工具箱中一把趁手的利器。
WeblogicScan工具详解：自动化检测WebLogic历史漏洞的原理与实践
1. 项目概述如果你负责过企业级Java应用的运维或安全评估大概率对Oracle WebLogic Server这个名字不会陌生。作为一款重量级的Java EE应用服务器它在金融、电信、政府等关键行业里有着庞大的部署量。然而伴随着其广泛使用而来的是层出不穷的安全漏洞尤其是那些高危的Java反序列化漏洞一旦被利用往往意味着服务器权限的完全丢失。手动去验证这些漏洞你需要记忆一堆CVE编号、对应的URL路径、请求包构造方式效率低下且容易遗漏。今天要聊的WeblogicScan就是一款由国内安全研究员Tide_RabbitMask开发的专门用于一键化、自动化检测WebLogic历史漏洞的工具。它把那些繁琐的检测流程打包成了一个Python脚本你只需要提供一个IP和端口它就能帮你跑完几乎全部已知的高危漏洞检查并给出清晰的结果报告。这个工具特别适合几类朋友一是企业的安全运维人员需要定期对内部资产进行漏洞扫描二是渗透测试人员在授权测试中快速验证目标WebLogic服务器的安全性三是安全研究爱好者想要学习WebLogic漏洞原理及自动化检测的实现思路。WeblogicScan目前版本是V1.5虽然项目更新停留在2020年但它集成的漏洞覆盖了从2014年到2019年间多个关键的CVE包括著名的CVE-2017-10271XMLDecoder反序列化、CVE-2018-2628T3协议反序列化等对于排查历史遗留风险依然非常有效。接下来我会带你从工具的原理、使用到背后的技术细节彻底搞懂这个“WebLogic漏洞扫描利器”。2. 工具核心原理与架构设计2.1 漏洞检测引擎的工作逻辑WeblogicScan本质上是一个漏洞验证PoC集成框架而不是一个模糊测试Fuzzing工具。它的核心逻辑是“已知漏洞已知检测方法”。开发者Tide_RabbitMask事先分析了每一个目标CVE漏洞的成因和利用条件然后为每个漏洞编写了独立的检测模块在工具的poc目录下。当你运行脚本时它会按照既定顺序向目标WebLogic服务器的特定端口默认7001发送一系列精心构造的HTTP请求或T3协议数据包。这些请求的设计非常巧妙目的是为了触发漏洞的“特征”但又避免造成实际的破坏。例如对于反序列化漏洞检测请求可能包含一个经过特殊构造、但无害的反序列化载荷通过分析服务器的响应如特定的错误信息、响应延迟、或返回的特定字符串来判断漏洞是否存在。这种“非侵入式”的检测是安全扫描工具的基本伦理也是WeblogicScan在代码中强调“仅用于安全测试”的原因。2.2 支持的漏洞类型与分类工具V1.5版本主要集成了四大类漏洞这也是WebLogic历史上最典型的几类安全问题信息泄露类主要是控制台路径泄露。WebLogic的管理控制台Console如果配置不当可能无需认证即可访问这会暴露一个极大的攻击面。工具会尝试访问/console/login/LoginForm.jsp等路径来验证这一点。服务端请求伪造SSRF对应CVE-2014-4210。这个漏洞存在于UDDI Explorer组件中攻击者可以利用它让WebLogic服务器向内部网络发起任意HTTP请求从而探测或攻击内网服务。Java反序列化漏洞这是重灾区也是工具检测的重点。涵盖了从2016年到2019年的多个CVE如CVE-2016-0638、CVE-2018-2628、CVE-2019-2725等。这类漏洞通常通过WebLogic的T3协议、RMI通信或HTTP接口触发能够导致远程代码执行RCE。XMLDecoder反序列化漏洞以CVE-2017-10271和CVE-2017-3506为代表。漏洞存在于WebLogic的WLS Security组件中通过发送一个恶意的XML数据到特定的HTTP端点如/wls-wsat/CoordinatorPortType可以触发XMLDecoder解析并执行任意Java代码。任意文件上传CVE-2018-2894。该漏洞允许攻击者通过WebLogic管理控制台的上传功能将恶意文件上传到服务器从而获取shell。工具通过模块化的设计将每一类、每一个CVE的检测逻辑封装成独立的函数或类使得引擎可以灵活地调用和扩展。2.3 网络通信与协议处理WeblogicScan的检测涉及两种主要的网络协议HTTP/HTTPS和T3协议。对于HTTP类的检测如控制台泄露、SSRF、XMLDecoder漏洞工具使用Python的requests库或urllib来构造和发送HTTP请求。这里有一个关键点连接超时和读取超时的设置。在企业网络环境中目标服务器可能响应缓慢或存在网络抖动。如果超时设置过短会导致大量误报将存活的服务判为不存在漏洞设置过长又会极大影响扫描效率。WeblogicScan在代码中通常会有合理的默认超时设置比如3-5秒但在实际使用中根据网络状况调整这些参数是必要的。对于T3协议的反序列化漏洞检测如CVE-2018-2628情况则复杂得多。T3是WebLogic专用的高性能RMI通信协议。检测时需要先与目标端口建立Socket连接然后按照T3协议格式组装并发送序列化后的检测载荷。这要求工具能够正确构造T3协议头、处理Java序列化流。WeblogicScan的Whoareu模块就是基于T3协议进行版本识别的它通过发送一个特定的T3握手请求从服务器的响应中提取出版本信息。精准的版本识别有助于缩小漏洞检测范围提高效率。3. 环境准备与工具部署3.1 系统与Python环境要求WeblogicScan是一个纯Python编写的工具因此具有很好的跨平台性可以在Windows、Linux或macOS上运行。它的核心依赖是Python 3。虽然早期版本支持Python 2但V1.3之后已全面转向Python 3这也是当前的主流和安全选择。在开始之前请确保你的系统已经安装了Python 3.6或更高版本。你可以通过在命令行输入python3 --version或python --version来检查。如果未安装请前往Python官网下载安装。建议使用虚拟环境如venv或conda来管理项目依赖避免污染全局环境。3.2 获取与安装WeblogicScan工具的源代码托管在GitHub上。由于网络访问的差异性这里提供两种常见的获取方式方式一直接克隆GitHub仓库推荐如果你所处的网络环境可以顺畅访问GitHub这是最直接的方法。打开终端或命令提示符执行git clone https://github.com/rabbitmask/WeblogicScan.git cd WeblogicScan这条命令会将最新的代码库下载到当前目录下的WeblogicScan文件夹中。方式二下载ZIP压缩包如果git clone速度不理想你可以直接访问项目的GitHub页面点击绿色的“Code”按钮然后选择“Download ZIP”。下载完成后在本地解压即可。进入工具目录后你需要安装必要的Python依赖包。工具根目录下通常有一个requirements.txt文件它列出了所有需要的库。使用pip一键安装pip3 install -r requirements.txt主要的依赖库通常包括requests用于HTTP请求和colorama用于终端彩色输出等。安装过程通常很快。如果遇到权限问题可以在命令前加上sudoLinux/macOS或以管理员身份运行命令提示符Windows。注意在某些严格的内网环境或离线机器上可能无法直接连接互联网进行pip install。针对这种情况WeblogicScan在早期的V1.2版本中曾提供一个离线安装模式/whl/文件夹和install.py但根据V1.4的更新日志这个模式在后续版本中被移除了。对于离线环境通用的做法是在一台能联网的机器上使用pip download -r requirements.txt -d ./offline_packages将所有依赖包.whl或.tar.gz文件下载到本地然后拷贝到离线机器上使用pip install --no-index --find-links./offline_packages -r requirements.txt进行安装。3.3 首次运行验证与常见问题安装完依赖后你可以先运行帮助命令来验证安装是否成功python3 WeblogicScan.py -h如果一切正常你应该会看到那个标志性的ASCII艺术字Banner以及简洁的参数说明。这表示工具已经准备就绪。首次运行可能遇到的问题“python3: command not found”这表示你的系统没有将Python 3的可执行文件加入环境变量。在Windows上你可能需要检查安装时是否勾选了“Add Python to PATH”。在Linux/macOS上可以尝试使用python命令或者通过which python3查找具体路径。有时Python 3的命令可能就是python。ModuleNotFoundError: No module named ‘xxx’这表示某个依赖库没有安装成功。请确保你是在工具所在的目录下运行的pip3 install -r requirements.txt。如果问题依旧可以尝试手动安装缺失的模块例如pip3 install requests。Windows系统下命令行显示乱码这通常是字符编码问题。可以尝试将命令行窗口的代码页改为UTF-8执行命令chcp 65001。或者使用更现代的终端如Windows Terminal它能更好地支持Unicode。4. 核心功能详解与实战操作4.1 单目标扫描精准探测这是最基础也是最常用的功能。当你已经明确知道一个WebLogic服务器的地址和端口时使用-u和-p参数。python3 WeblogicScan.py -u 192.168.1.100 -p 7001-u(IP)指定目标服务器的IP地址。-p(PORT)指定WebLogic的监听端口默认是7001。如果目标服务器将管理端口修改为其他如7002、8001务必在此指定。执行后工具会依次进行以下工作Banner展示与初始化打印出工具标识。版本识别Whoareu模块首先尝试通过T3协议与目标通信获取精确的WebLogic版本号如10.3.6.0、12.2.1.3.0。这一步非常关键因为不同版本的漏洞存在情况差异很大。顺序漏洞检测按照内置的漏洞列表逐个发送检测请求。在控制台上你会看到实时的输出[]表示检测到该漏洞。[-]表示未检测到该漏洞。[*]表示任务开始或结束的信息。结果汇总所有检测完成后会输出“Task End”。实战技巧理解输出内容以一段输出为例[] [192.168.1.100:7001] Weblogic Version Is 10.3.6.0 [] [192.168.1.100:7001] Weblogic console address is exposed! [-] [192.168.1.100:7001] weblogic not detected CVE-2017-10271 [] [192.168.1.100:7001] weblogic has a JAVA deserialization vulnerability:CVE-2018-2628第一行告诉你目标的版本是10.3.6.0即WebLogic 10g这是一个相对古老的版本漏洞较多。第二行是一个高危发现控制台路径暴露。这意味着http://192.168.1.100:7001/console可能可以直接访问为后续的爆破或利用提供了入口。第三行显示CVE-2017-10271未检测到这可能是该版本已打补丁或组件未启用。第四行显示检测到了CVE-2018-2628这是一个极其危险的T3反序列化漏洞可导致远程代码执行需要立即处理。4.2 批量扫描高效资产梳理在内部安全巡检或红队演练中你往往需要面对一个IP地址列表。手动一个个输入效率太低。WeblogicScan的-f参数就是为批量扫描而生。首先你需要准备一个文本文件例如targets.txt里面按行存放要扫描的目标。格式非常灵活192.168.1.100 192.168.1.101:7001 10.0.0.5:8001 domain.com可以只写IP工具会使用默认端口7001。可以指定IP:PORT格式。甚至可以使用域名。然后运行命令python3 WeblogicScan.py -f targets.txt工具会读取文件自动解析每一行并依次进行扫描。所有结果会统一输出到控制台并且详细的扫描过程会同步记录到Weblogic.log日志文件中。批量扫描的注意事项网络超时设置批量扫描时网络状况不一的节点可能导致整个扫描进程卡住。虽然WeblogicScan V1.4之后声称解决了“脚本异常卡死问题”但在实际大规模扫描中建议结合其他手段。例如可以使用timeout命令Linux或编写外层脚本来控制每个目标的扫描时间。日志分析Weblogic.log文件是纯文本记录了时间戳和每一条检测结果。这对于后续的审计、报告生成至关重要。你可以用grep命令快速过滤出所有[]的结果grep ^[0-9].*\[\] Weblogic.log。性能与礼貌不要对单一目标或整个网络发起过高频率的扫描。这可能会触发目标的入侵检测系统IDS/IPS甚至对目标服务器造成拒绝服务DoS影响。在授权测试中也应合理安排扫描节奏。4.3 结果解读与日志分析控制台输出提供了即时反馈而Weblogic.log则提供了完整的、可追溯的审计记录。日志的每一行都遵循固定的格式时间戳 [检测结果] [目标] 详细信息。如何高效利用日志漏洞统计你可以编写简单的脚本从日志中提取所有带[]的行然后按CVE编号进行排序和去重快速生成一个漏洞分布统计。问题排查如果某个漏洞在所有目标上都显示[-]可能是该漏洞的检测脚本PoC本身在网络环境或特定WebLogic配置下失效了。查看日志中该漏洞检测前后的网络请求记录如果工具开启了更详细的调试日志有助于分析原因。证据保存在正式的渗透测试报告中这些带有时间戳的日志记录是重要的测试证据。实操心得我习惯在每次启动批量扫描前先备份或重命名旧的Weblogic.log文件例如mv Weblogic.log Weblogic.log.bak或者使用--log参数如果工具支持指定新的日志文件路径这样可以保证每次扫描的结果都是独立的避免混淆。5. 检测漏洞原理解析与修复建议了解工具检测了什么漏洞以及这些漏洞为何危险能帮助你在拿到结果后采取正确的行动。下面挑选几个经典的漏洞进行剖析。5.1 CVE-2017-10271 (XMLDecoder反序列化)原理简述WebLogic的WLS Security组件对外提供了Web服务SOAP其端点如/wls-wsat/CoordinatorPortType在处理SOAP请求时使用了XMLDecoder来解析XML数据。XMLDecoder是Java中一个用于将XML编码转换回Java对象的功能类但其设计上存在安全隐患可以用于实例化任意Java类并执行其方法。攻击者通过构造一个包含恶意Java代码的SOAP请求发送到该端点即可实现远程代码执行。WeblogicScan的检测逻辑工具会向目标服务器的/wls-wsat/CoordinatorPortType等已知的漏洞路径发送一个特制的SOAP请求包。这个请求包中包含了一段利用XMLDecoder执行无害命令如ping一个不存在的地址或者执行echo的XML载荷。然后工具会检查服务器的响应。如果漏洞存在服务器会执行这段载荷并在响应中留下特定的痕迹如特定的错误信息、响应延迟工具通过匹配这些特征来判断漏洞是否存在。修复建议官方补丁立即安装Oracle发布的最新安全补丁Critical Patch Update, CPU。这是最根本的解决方法。临时缓解如果无法立即升级可以删除或限制访问wls-wsat组件对应的WAR包。具体路径通常在$DOMAIN_HOME/servers/AdminServer/tmp/_WL_internal和$DOMAIN_HOME/servers/AdminServer/tmp/.internal下找到包含wls-wsat的文件并移除。同时在防火墙或负载均衡设备上对/wls-wsat/路径的访问进行阻断。访问控制确保WebLogic控制台Console和管理端口不直接暴露在互联网上应通过VPN或跳板机进行访问。5.2 CVE-2018-2628 (T3协议反序列化)原理简述WebLogic的T3协议在处理反序列化数据时存在过滤缺陷。攻击者可以通过T3协议向WebLogic服务器发送恶意的序列化对象该对象在服务器端被反序列化时会触发精心构造的利用链通常利用InvokerTransformer、ChainedTransformer等类最终执行任意命令。WeblogicScan的检测逻辑工具会与目标的T3服务端口建立Socket连接然后发送一个精心构造的、利用java.rmi.registry.Registry进行绑定的序列化攻击载荷。这个载荷被设计为在反序列化时会尝试连接一个由检测工具控制的“假”的RMI服务地址。工具通过监听该地址是否收到连接尝试或者分析服务器返回的特定错误信息来判断漏洞是否存在。这是一种“回连”检测机制相对更可靠。修复建议打补丁应用Oracle官方补丁。限制T3协议访问这是最有效的临时加固措施。可以在WebLogic控制台的“域结构”-“环境”-“服务器”-选择具体服务器实例-“配置”-“协议”-“常规”下将“启用T3”的选项取消或者更精细地在“协议”-“T3”-“筛选器”中配置只允许受信任的IP地址访问T3协议。网络层隔离在防火墙规则中只允许必要的管理IP访问WebLogic的T3端口默认7001。5.3 CVE-2014-4210 (SSRF)原理简述WebLogic的UDDI Explorer组件通常路径为/uddiexplorer/中的SearchPublicRegistries.jsp页面在处理用户提供的operator参数时未对内部发起的HTTP请求目标进行有效过滤。攻击者可以构造一个包含内网地址如http://192.168.1.1:8080的请求让WebLogic服务器作为代理去访问该地址并根据返回的错误信息如连接超时、返回内容差异来探测内网存活主机和端口。WeblogicScan的检测逻辑工具会访问/uddiexplorer/SearchPublicRegistries.jsp并提交一个指向一个已知不存在的或特定的外部地址的operator参数。通过分析返回页面的内容判断是否存在SSRF漏洞的特征字符串或错误模式。修复建议删除或禁用组件直接删除uddiexplorer应用对应的WAR包或通过控制台将其部署状态改为“不活动”。更新补丁安装修复该漏洞的官方补丁。输入验证如果业务必须使用该组件应严格在代码层面验证operator参数限制其协议、主机和端口范围。6. 高级用法与脚本定制6.1 集成到自动化工作流WeblogicScan作为一个命令行工具很容易被集成到更大的自动化安全体系中。例如你可以将其与资产发现系统结合端口扫描联动使用nmap或masscan扫描出开放7001、8001等常见WebLogic端口的资产将结果导出为IP:PORT格式的列表直接作为-f参数的输入文件。nmap -p 7001,7002,8001 --open -oG - 192.168.1.0/24 | grep “/open/” | awk ‘{print $2}’ weblogic_hosts.txt python3 WeblogicScan.py -f weblogic_hosts.txt定时任务与告警在Linux服务器上你可以编写一个Shell脚本定期执行批量扫描然后使用grep分析Weblogic.log如果发现新的[]漏洞就通过邮件、钉钉、企业微信等机器人接口发送告警消息。与漏洞管理平台整合将扫描结果解析Weblogic.log转换成标准的格式如JSON、CSV然后通过API导入到像OpenVAS、Nexpose或自建的漏洞管理平台中实现统一的漏洞跟踪和生命周期管理。6.2 自定义检测策略与PoCWeblogicScan的代码结构比较清晰主要逻辑在WeblogicScan.py而具体的漏洞检测函数通常放在poc目录或集成在主脚本中。如果你有新的WebLogic漏洞PoC想要加入或者想调整现有检测的逻辑可以尝试自己修改。添加新PoC的通用思路研究漏洞理解新漏洞的触发点URL、协议、利用方式数据包格式和成功特征响应内容、错误码、延迟。编写检测函数在工具框架内仿照现有漏洞检测函数的格式编写一个新的函数。这个函数通常需要接收目标ip和port参数构造特定的请求发送并分析响应。集成到主流程在主扫描循环中调用你新写的检测函数。测试务必在可控的测试环境如自己搭建的漏洞靶场中充分测试确保检测准确且不会对目标造成损害。重要警告修改安全工具需要一定的Python编程能力和安全知识。错误的PoC可能导致扫描器崩溃、误报、漏报甚至可能违反安全测试的道德和法律边界。请仅在授权测试环境和出于学习目的进行尝试。6.3 性能调优与稳定性提升当扫描成百上千个目标时工具的稳定性和速度就变得很重要。调整超时时间在WeblogicScan.py中找到发起网络请求的地方通常是requests.get()或socket连接适当调整timeout参数。对于内网环境可以设短一些如2-3秒对于网络延迟高的环境可能需要设长一些如5-10秒。但要注意超时过长会严重影响批量扫描的总时长。引入并发/多线程原版的WeblogicScan是单线程顺序扫描的。你可以使用Python的concurrent.futures库或multiprocessing模块对其进行改造实现多线程并发扫描极大提升批量扫描效率。核心思路是将目标列表分发给多个工作线程/进程每个线程独立运行扫描函数。但必须小心处理共享资源如日志文件的写入避免冲突。错误处理增强工具自带的错误处理可能不够完善。你可以增加更详细的异常捕获和日志记录比如记录连接拒绝、超时、DNS解析失败等不同错误方便后续分析网络问题。7. 常见问题排查与解决实录在实际使用WeblogicScan的过程中你可能会遇到各种各样的问题。下面是我和同事们踩过的一些坑以及解决办法。7.1 扫描结果全为阴性[-]现象针对一个已知存在漏洞的测试环境如Vulhub、VulnHub上的WebLogic靶场运行工具后所有漏洞检测结果都是[-]。可能原因与排查步骤网络连通性问题这是最常见的原因。首先用ping和telnet或nc命令检查到目标IP和端口的网络连通性。ping -c 4 192.168.1.100 telnet 192.168.1.100 7001 # 或 nc -zv 192.168.1.100 7001如果telnet不通可能是防火墙阻止或者WebLogic服务未运行。目标服务并非WebLogic端口开放不代表一定是WebLogic。用浏览器访问http://ip:port或者用curl查看返回的标题和内容确认是否是WebLogic的默认页面。工具与目标版本不兼容WeblogicScan V1.5主要针对2019年及之前的漏洞。如果目标是更新版本的WebLogic如12.2.1.4, 14.x可能内置的PoC已经失效。此时版本识别Whoareu模块可能仍然有效可以先用-u参数扫描看能否正确识别出版本。PoC被防御措施绕过目标服务器可能部署了WAFWeb应用防火墙、入侵防御系统或者对WebLogic进行了深度加固拦截或篡改了工具发送的恶意请求。尝试关闭工具的代理设置如果使用了或者直接在有网络权限的环境测试。工具依赖或环境问题在极少数情况下Python环境或依赖库的版本冲突可能导致脚本运行异常。尝试在一个全新的Python虚拟环境中重新安装依赖并测试。7.2 工具运行卡住或无响应现象扫描到某个特定目标时工具停止输出长时间卡住甚至需要强制终止CtrlC。可能原因与排查步骤目标响应缓慢或网络延迟高工具在等待一个HTTP请求或Socket连接的响应。按照6.3节的方法适当调低超时时间。对于批量扫描建议使用外层脚本为每个目标扫描设置总超时。特定PoC逻辑缺陷某个漏洞的检测函数可能陷入死循环或者等待一个永远不会发生的事件如“回连”检测中等待连接。查看卡住时最后打印的日志定位到正在检测的CVE编号然后可以尝试在代码中临时注释掉该CVE的检测函数看是否能跳过。线程/进程阻塞如果自己改写了并发在自改的多线程版本中如果线程间同步或资源竞争处理不当可能导致死锁。7.3 误报与漏报的处理误报False Positive工具报告存在漏洞但实际不存在。原因PoC检测的逻辑可能不够精确服务器返回的某些正常响应恰好匹配了漏洞存在的特征。应对手动验证。根据工具报告的CVE编号和URL使用浏览器、curl或Burp Suite等工具手动访问相关路径发送检测载荷分析原始响应。这是渗透测试中确认漏洞的必要步骤。漏报False Negative工具报告不存在漏洞但实际存在。原因网络问题、目标环境差异如路径修改、PoC过时或不够完善。应对同样需要手动验证。可以搜索该CVE的其他公开PoC或利用脚本进行测试。同时检查Weblogic.log中该漏洞检测时的详细网络交互记录如果工具提供了调试输出选项看请求是否成功发送响应是什么。7.4 日志文件不生成或内容不全现象扫描完成后当前目录下没有Weblogic.log文件或者文件内容很少。排查步骤检查写入权限确保运行脚本的用户在当前目录有创建和写入文件的权限。检查脚本配置查看WeblogicScan.py源码中关于日志记录的部分通常是Python的logging模块配置。确认日志文件路径是相对路径./Weblogic.log还是绝对路径。如果是相对路径确保你的工作目录正确。程序异常退出如果脚本因为未捕获的异常而崩溃日志模块可能来不及写入缓存内容。尝试在脚本开头添加更全面的异常捕获或者用try...except包裹主函数。工具的价值在于快速初筛但它不能替代专业的人工分析和验证。尤其是在出具正式的安全报告前对工具发现的所有高危漏洞进行手动复核是安全从业人员必须恪守的职业准则。WeblogicScan作为一个已经归档的项目它很好地完成了它的历史使命为安全社区提供了一个简单易用的WebLogic漏洞检测方案。理解它的原理善用它并在其基础上结合自己的经验进行判断和扩展才能让它真正成为你安全工具箱中一把趁手的利器。
