SSRF漏洞
SSRF（服务端请求伪造），指的是攻击者在未能取得服务器所有权限时，利用服务器漏洞以服务器的身份发送一条构造好的请求给服务器所在内网。SSRF攻击通常针对外部网络无法直接访问的内部系统。
简单的说就是利用一个可发起网络请求的服务当作跳板来攻击其他服务
SSRF形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能且没有对目标地址做过滤与限制。
1.1 影响版本
weblogic 10.0.2
weblogic 10.3.6
1.2 漏洞描述
Weblogic中存在一个SSRF漏洞，利用该漏洞可以发送任意HTTP请求，进而攻击内网中redis、fastcgi等脆弱组件。
访问
http://your-ip:7001/uddiexplorer/，无需登录即可查看 uddiexplorer 应用。
1.3 漏洞环境搭建
使用vulhub的docker镜像来搭建
执行命令
sudo docker-compose up -d
随后访问7001端口即可，根据下图看这个漏洞存在的weblogic的版本也非常早了，估计现在基本上不怎么会用到这个漏洞了应该。
1.4 漏洞复现
- 首先进入存在漏洞的界面
http://192.168.10.104:7001/uddiexplorer/ - 使用漏洞poc验证漏洞是否存在，访问如下链接
http://192.168.10.104:7001/uddiexplorer/SearchPublicRegistries.jsp?rdoSearch=name&txtSearchname=&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search&operator=http://127.0.0.1:7001
- 返回内容如下图所示
- 显然使用上面的payload已经成功探测出了内网的服务，因为成功返回了404，从某些方面讲，这也是一种成功。如果这是一个没有开启的服务，返回的内容会是下图的内容。
- 复现成功。
1.5 漏洞利用
这一步是实战必须的，任何漏洞都有存在的必要。也许是为了我们进行下一步的操作，也许是为了拿到数据等等。而ssrf漏洞很显然是为了方便我们进行下一步的利用而存在的，方便我们对该系统的内网资产做一个描绘。
这里因为我使用的是vulhub的漏洞环境，可以配合redis未授权打一波内网，下面再简单记录一下漏洞利用部分。
Redis 默认情况下，会绑定在 0.0.0.0:6379，如果没有进行采用相关的策略，比如添加防火墙规则避免其他非信任来源 ip 访问等，这样将会将 Redis 服务暴露到公网上，如果在没有设置密码认证（一般为空）的情况下，会导致任意用户在可以访问目标服务器的情况下未授权访问 Redis 以及读取 Redis 的数据。攻击者在未授权访问 Redis 的情况下，利用 Redis 自身的提供的config 命令，可以进行写文件操作
redis未授权主要就是利用写文件的命令，这里可以因为不能使用写webshell的方式，只能使用设置Linux定时任务的方式getshell了。
这个vulhub的镜像好像有问题，不知道是不是我的问题，我这里这个docker总是起不来。
上图框住的容器里面运行的应该是一个docker内网中的redis容器，鉴于解决此问题的时间成本太高（没见到过遇到这个问题的），这里不再对redis未授权进行利用。考虑之后单独对redis未授权进行复现，redis未授权的利用方式可以参考1.6节的文章。
1.6 参考文章
Weblogic SSRF漏洞(CVE-2014-4210)
redis未授权getshell的4种方式
