mirror of
https://github.com/gelusus/wxvl.git
synced 2025-08-13 03:17:22 +00:00
浅谈edusrc，逻辑漏洞，越权，接管到getshell，如何快速找准漏洞、超过1200个SAP NetWeaver服务器容易受到主动利用漏洞的攻击、AI生成虚假漏洞报告污染漏洞赏金平台、电商诈骗平台漏洞挖掘实录：从供应链后台到数据泄露的破局之路、CVE-2025-29774∕CVE-2025-29775: xml-crypto XML Signature Wrapping、超越漏洞管理：CVE体系面临哪些挑战？、
This commit is contained in:
test
parent
678567e7df
commit
6b96962904
@ -13844,5 +13844,11 @@
|
||||
"https://mp.weixin.qq.com/s?__biz=MzAwMjA5OTY5Ng==&mid=2247526287&idx=1&sn=6b71b0ff47c9db7f74c5d92b44ced3d8": "某OA代码审计之挖掘0day，未公开poc",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzkwNDUwNDU0OA==&mid=2247483765&idx=1&sn=43c35400f383276717ac879629f7db49": "关于小红书SRC暂停漏洞测试活动的公告",
|
||||
"https://mp.weixin.qq.com/s?__biz=Mzg4MTgxNjQwOQ==&mid=2247484866&idx=1&sn=354d8638c29cecc786bb0cb463c2f741": "好用的漏洞复现靶机推荐",
|
||||
"https://mp.weixin.qq.com/s?__biz=Mzk1NzMwNTM5NQ==&mid=2247485682&idx=1&sn=5907f8b6dea30490048f9168c84cc95c": "282G福利大放送！2025黑客、网络安全资料全网最全资料大合集（从0到挖漏洞、打CTF、护网、就业）"
|
||||
"https://mp.weixin.qq.com/s?__biz=Mzk1NzMwNTM5NQ==&mid=2247485682&idx=1&sn=5907f8b6dea30490048f9168c84cc95c": "282G福利大放送！2025黑客、网络安全资料全网最全资料大合集（从0到挖漏洞、打CTF、护网、就业）",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650610697&idx=3&sn=ee9f9fefcd9cd42cfca299aa1a8d44da": "浅谈edusrc，逻辑漏洞，越权，接管到getshell，如何快速找准漏洞",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzI0MDY1MDU4MQ==&mid=2247582281&idx=1&sn=eff71cea21807271925c234b3191e3c9&subscene=0": "超过1200个SAP NetWeaver服务器容易受到主动利用漏洞的攻击",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650610697&idx=2&sn=71bf35dc2d544216c0138f43b22158a1": "AI生成虚假漏洞报告污染漏洞赏金平台",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzIxOTM2MDYwNg==&mid=2247513780&idx=1&sn=8d53faf470573cd7361a1f1ea2f65d70": "电商诈骗平台漏洞挖掘实录：从供应链后台到数据泄露的破局之路",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzAxODM5ODQzNQ==&mid=2247488287&idx=1&sn=464d2d0e5dc7738859fbed59509f0993": "CVE-2025-29774∕CVE-2025-29775: xml-crypto XML Signature Wrapping",
|
||||
"https://mp.weixin.qq.com/s?__biz=MjM5NjA0NjgyMA==&mid=2651320568&idx=1&sn=434f968a88b181c31066694c59734bb1": "超越漏洞管理：CVE体系面临哪些挑战？"
|
||||
}
|
||||
@ -1,67 +1,43 @@
|
||||
# AI生成虚假漏洞报告污染漏洞赏金平台
|
||||
FreeBuf 2025-05-09 09:58
|
||||
黑白之道 2025-05-10 12:46
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 漏洞赏金计划遭遇AI伪造报告冲击
|
||||
|
||||
曾经因激励独立研究人员报告真实漏洞而备受赞誉的漏洞赏金计划，如今正面临AI生成虚假漏洞报告的重大挑战。这些伪造的漏洞报告在业内被称为"AI垃圾"，不仅浪费维护人员的时间，更令人担忧的是，有时甚至能获得实际的金钱奖励。
|
||||
|
||||
|
||||
这种现象反映出一种日益增长的趋势：恶意行为者利用大语言模型（LLM）生成看似专业实则完全虚构的安全报告。这些AI生成的报告之所以构成特殊威胁，是因为它们初看往往显得真实可信，特别是对那些没有专职安全专家的组织而言。
|
||||
|
||||
### Part01
|
||||
### AI伪造报告的特征分析
|
||||
|
||||
## AI伪造报告的特征分析
|
||||
|
||||
这些报告通常包含技术术语、安全概念引用，甚至提供修补建议——所有这些设计都是为了通过初步筛选流程。然而，当领域专家进行更仔细检查时，这些报告很快就会暴露出欺诈本质，因为它们描述的漏洞无法复现，引用的功能根本不存在。
|
||||
|
||||
|
||||
Socket.dev研究人员指出，这一趋势对开源项目和资源不足的组织尤其不利，因为它们缺乏正确评估技术安全报告的内部专业知识。许多组织陷入两难境地：要么投入时间和资源彻底调查每份报告，要么干脆支付赏金以避免潜在安全风险和负面宣传。
|
||||
|
||||
### Part02
|
||||
## 典型案例：curl项目遭遇AI欺诈
|
||||
###
|
||||
|
||||
|
||||
近期一个备受关注的案例涉及curl项目，该项目通过HackerOne收到了一份欺诈性漏洞报告（编号H1#3125832）。curl团队发现该报告引用了不存在的功能并包含未经证实的修补建议后，将其标记为AI生成的垃圾报告。据调查，与@evilginx账户关联的攻击者曾对其他组织使用类似手法，在某些情况下成功获得了漏洞赏金。
|
||||
|
||||
|
||||
安全研究员Harry Sintonen指出，curl作为一个技术含量高、专业知识深厚的开源项目，立即识破了这一骗局。"攻击者的算计大错特错，"Sintonen表示，"curl能轻易识别出AI生成的垃圾报告。"
|
||||
|
||||
### Part03
|
||||
### AI伪造报告的典型特征
|
||||
|
||||
## AI伪造报告的典型特征
|
||||
|
||||
仔细研究这些伪造报告，可以发现几个明显的特征。这些报告通常通过引用听起来合理但实际上在代码库中并不存在的函数或方法，来维持表面的技术可信度。例如，在curl案例中，报告引用了一个名为"ngtcp2_http3_handle_priority_frame"的不存在函数。
|
||||
|
||||
|
||||
当被质疑时，攻击者会辩称问题存在于特定的旧版本或新版本中，经常编造提交哈希值来延续欺骗。这些报告故意对复现步骤含糊其词，使维护者无法验证所声称的漏洞。它们通常将合法的安全概念与虚构的实现细节相结合，构建出看似合理但经不起专家推敲的叙述。
|
||||
|
||||
### Part04
|
||||
### 开源社区面临资源压力
|
||||
|
||||
当被质疑时，攻击者会辩称问题存在于特定的旧版本或新版本中，经常编造提交哈希值来延续欺骗。这些报告故意对复现步骤含糊其辞，使维护者无法验证所声称的漏洞。它们通常将合法的安全概念与虚构的实现细节相结合，构建出看似合理但经不起专家推敲的叙述。
|
||||
## 开源社区面临资源压力
|
||||
|
||||
Python软件基金会驻场安全开发者Seth Larson证实，开源维护者越来越多的时间被用于审查这类AI生成的漏洞报告。"问题在于，在LLM时代，这些报告乍看之下似乎可能真实，因此需要时间进行反驳，"Larson解释道，这凸显了该现象如何给开源安全生态系统中本已有限的资源带来压力。
|
||||
|
||||
|
||||
###
|
||||
###
|
||||
###
|
||||
### 推荐阅读
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MjM5NjA0NjgyMA==&mid=2651320090&idx=1&sn=cb1b7e4d9fbfa8c98cf0c378da407981&scene=21#wechat_redirect)
|
||||
|
||||
### 电台讨论
|
||||
|
||||
[]()
|
||||
> **文章来源：freebuf**
|
||||
|
||||
|
||||
|
||||
黑白之道发布、转载的文章中所涉及的技术、思路和工具仅供以安全为目的的学习交流使用，任何人不得将其用于非法用途及盈利等目的，否则后果自行承担！
|
||||
|
||||
如侵权请私聊我们删文
|
||||
|
||||
|
||||
**END**
|
||||
|
||||
|
||||
|
||||
|
||||
@ -0,0 +1,130 @@
|
||||
# CVE-2025-29774/CVE-2025-29775: xml-crypto XML Signature Wrapping
|
||||
romi0x securitainment 2025-05-10 15:20
|
||||
|
||||
> 【翻译】[하루한줄] CVE-2025-29774, CVE-2025-29775 xml-crypto의 XML Signature Wrapping 취약점
|
||||
|
||||
## URL
|
||||
|
||||
https://workos.com/blog/samlstorm
|
||||
## Target
|
||||
- xml-crypto 库 (版本 <= 6.0.0)
|
||||
|
||||
## Explain
|
||||
|
||||
该漏洞利用 XML 数字签名验证逻辑中的缺陷，可绕过 SAML 响应或基于 XML 签名的认证机制。该漏洞源于 xml-crypto
|
||||
库签名验证方式的结构性问题，分为 CVE-2025-29774 和 CVE-2025-29775 两个漏洞公开。
|
||||
|
||||
**CVE-2025-29774**
|
||||
是利用 "SignedInfo 节点重复" 的漏洞。在正常的已签名 XML 文档中，<Signature>
|
||||
节点内应仅存在一个 <SignedInfo>
|
||||
节点。然而，xml-crypto
|
||||
的漏洞版本在存在多个 <SignedInfo>
|
||||
节点时，会对攻击者插入的伪造 <SignedInfo>
|
||||
节点进行签名验证，而不是验证正常的节点。这使得攻击者可以保留一个有效的 SignedInfo，同时在另一个节点中包含权限提升或用户篡改等恶意操作，从而绕过签名验证。在实际攻击示例中，攻击者会在 <Signature>
|
||||
块中插入两个 <SignedInfo>
|
||||
，并在其中一个包含伪造的 Digest 值，以实现认证绕过。
|
||||
|
||||
**CVE-2025-29775**
|
||||
是基于 DigestValue 操作的漏洞。该漏洞通过在 DigestValue 中插入 HTML 注释 (<!-- -->
|
||||
) 的方式实现。正常的 DigestValue 应为 Base64 编码的纯数据，但 xml-crypto 的验证逻辑并未基于节点解析该值，而是基于字符串处理。因此，攻击者可以插入如下所示的注释和伪造值：
|
||||
```
|
||||
<DigestValue>
|
||||
<!--TBlYWE0ZWM4ODI1NjliYzE3NmViN2E1OTlkOGDhhNmI=-->
|
||||
c7RuVDYo83z2su5uk0Nla8DXcXvKYKgf7tZklJxL/LZ=
|
||||
</DigestValue>
|
||||
```
|
||||
|
||||
验证逻辑会忽略注释，仅验证实际的 DigestValue，因此会认为签名有效。然而，解析的应用程序会将注释和值结合起来处理，导致错误的数据。这使得攻击者能够巧妙地更改用户的身份信息或权限信息，同时绕过签名验证。
|
||||
|
||||
攻击者可以利用此漏洞进行认证绕过和权限提升攻击。这对所有基于 xml-crypto
|
||||
实现 SAML SSO 的服务都有广泛影响，特别是即使包含重要身份信息或权限信息的 XML 消息被篡改，仍然能够通过签名验证，这是一个严重的问题。
|
||||
|
||||
该漏洞已在 xml-crypto
|
||||
库的 6.0.1 版本中修复。所有 6.0.0 及以下版本均受影响。
|
||||
1. **SignedInfo 节点重复检测 (CVE-2025-29774 检测方法)**
|
||||
|
||||
需要检查 SAML 响应或 XML 文档中 <Signature>
|
||||
内是否存在两个或更多 <SignedInfo>
|
||||
节点。正常文档中必须只有一个。
|
||||
```
|
||||
<Signature>
|
||||
<SomeNode>
|
||||
<SignedInfo>
|
||||
<Reference URI="somefakereference">
|
||||
<DigestValue>forgeddigestvalue</DigestValue>
|
||||
</Reference>
|
||||
</SignedInfo>
|
||||
</SomeNode>
|
||||
<SignedInfo>
|
||||
<Reference URI="realsignedreference">
|
||||
<DigestValue>realdigestvalue</DigestValue>
|
||||
</Reference>
|
||||
</SignedInfo>
|
||||
</Signature>
|
||||
```
|
||||
|
||||
检测用的 JavaScript 代码如下：
|
||||
```
|
||||
const signedInfoNodes = xpath.select(".//*[local-name(.)='SignedInfo']", signatureNode);
|
||||
if (signedInfoNodes.length > 1) {
|
||||
// Compromise detected
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
|
||||
1.
|
||||
1.
|
||||
1.
|
||||
1.
|
||||
1.
|
||||
1.
|
||||
1.
|
||||
1.
|
||||
1.
|
||||
1.
|
||||
1.
|
||||
1.
|
||||
1.
|
||||
1.
|
||||
1.
|
||||
1.
|
||||
1.
|
||||
1.
|
||||
1. **DigestValue 内注释检测 (CVE-2025-29775 检测方法)**
|
||||
|
||||
在正常的 XML 签名中，<DigestValue>
|
||||
块内绝对不应存在 <!-- -->
|
||||
形式的注释。如果发现此类情况，应将其视为被篡改的消息。
|
||||
```
|
||||
<DigestValue>
|
||||
<!-- malicious comment -->
|
||||
validDigestValue==
|
||||
</DigestValue>
|
||||
```
|
||||
|
||||
检测用的 JavaScript 代码如下：
|
||||
```
|
||||
const digestValues = xpath.select("//*[local-name()='DigestValue'][count(node()) > 1]", decryptedDocument);
|
||||
if (digestValues.length > 0) {
|
||||
// Compromise detected
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
|
||||
1.
|
||||
1.
|
||||
1.
|
||||
1.
|
||||
1.
|
||||
1.
|
||||
1.
|
||||
1.
|
||||
## 参考文档 (Reference)
|
||||
1. xml-crypto 安全公告 GHSA-x3m8-899r-f7c3
|
||||
|
||||
1. xml-crypto 安全公告 GHSA-9p8x-f768-wp2g
|
||||
|
||||
|
||||
|
||||
@ -1,5 +1,7 @@
|
||||
# 浅谈edusrc，逻辑漏洞，越权，接管到getshell，如何快速找准漏洞
|
||||
薛定谔不喜欢猫 Z2O安全攻防 2025-05-08 12:47
|
||||
黑白之道 2025-05-10 12:46
|
||||
|
||||
|
||||
|
||||
文章首发：奇安信攻防社区
|
||||
|
||||
@ -10,14 +12,12 @@ https://forum.butian.net/share/4291
|
||||
今年对某高校进行了渗透测试，发现了一些比较经典的漏洞，写一下和师傅们一起分享。
|
||||
## 1.教务系统登录处短信轰炸
|
||||
|
||||
|
||||
![]( "")
|
||||
|
||||
|
||||
|
||||
学校的教务系统登录处，发现有一个手机验证码认证
|
||||
|
||||
|
||||
![]( "")
|
||||
|
||||
|
||||
|
||||
这里会发送一个验证码
|
||||
@ -26,19 +26,18 @@ https://forum.butian.net/share/4291
|
||||
|
||||
但是这里抓包之后，发现能抓到两个数据包
|
||||
|
||||
|
||||
![]( "")
|
||||
|
||||
|
||||
|
||||
这是第一个数据包，可以发现是对验证码的验证，我们把第一个数据包通过之后，拿到第二个数据包：
|
||||
|
||||
|
||||
|
||||
|
||||
可以看到我们的手机号出现在了第二个数据包中
|
||||
|
||||
我们点击放到repeater，然后点击send，可以发现一直发送：
|
||||
|
||||
|
||||
|
||||
|
||||
**原理**
|
||||
：正常来说校验码的验证和发送短信应该是在同一个数据包中，这里不严谨的设置，将校验码的验证和发送短信的数据包分成了两个，我们输入正常的验证码，通过第一个验证的数据包，拦截第二个发送短信的验证码，即可实现短信轰炸。
|
||||
@ -48,13 +47,13 @@ https://forum.butian.net/share/4291
|
||||
|
||||
这是挖某专属src时遇到的
|
||||
|
||||
|
||||
|
||||
|
||||
account为手机号，正常情况下，一个手机号短时间内只能发送一条验证码。
|
||||
|
||||
在account中的手机号前面每加一个空格可以突破限制进行多发一次验证码，
|
||||
|
||||
|
||||
|
||||
|
||||
burp设置两个载荷
|
||||
|
||||
@ -65,34 +64,33 @@ burp设置两个载荷
|
||||
#### 3.伪造XF头
|
||||
## 2.校内某实训平台任意用户注册、任意用户登录、修改任意用户密码、验证码爆破
|
||||
|
||||
|
||||
|
||||
|
||||
这是校内某实训平台，我们先点击注册功能点。
|
||||
|
||||
|
||||
![]( "")
|
||||
|
||||
|
||||
|
||||
我们点击获取验证码，然后进行抓包：
|
||||
|
||||
|
||||
|
||||
|
||||
可以看到手机号被编在了url里，我们这里使用“,”去拼接手机号，这样就可以把验证码同时发送给两个手机号，并且收到的验证码相同。好比我知道你的手机号，拿你手机号去注册，我根本不需要知道你的验证码，因为验证码也会发到我手机上。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
修改密码功能点也是相同，我这里不进行过多赘述
|
||||
#### 验证码爆破
|
||||
|
||||
|
||||
|
||||
|
||||
正常发送验证码，然后在填写验证码的地方，随意输入四位数
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
可以看到在7710的时候，长度不一样，成功登录进去了。
|
||||
|
||||
@ -100,12 +98,11 @@ burp设置两个载荷
|
||||
：对验证码输入次数进行限制
|
||||
## 3.越权查看所有学生和教职工个人信息，数万条记录
|
||||
|
||||
|
||||
|
||||
|
||||
教务系统个人中心处有一个查看最近登陆记录的功能点，发现右上角有个查询，我们抓包尝试：
|
||||
|
||||
|
||||
![]( "")
|
||||
|
||||
|
||||
|
||||
可以看到这里可以看到我们的登陆情况，我们尝试去修改value的值，看看能不能直接越权查看别人的登录信息。但是发现无论修改成什么都会提示登录信息错误。
|
||||
@ -114,59 +111,55 @@ burp设置两个载荷
|
||||
|
||||
我们让value=null
|
||||
|
||||
|
||||
|
||||
|
||||
但是登录的记录明显有点少，而且观察发现好像都是登录失败的记录，这时我发现有个name字段，我把userid改成*：
|
||||
|
||||
|
||||
|
||||
|
||||
拿下所有学生和教职工的个人信息，包括姓名、手机号、身份证号、学号、教职工编号、登录ip等
|
||||
## 4.教务系统绕过手机验证码换绑手机号
|
||||
|
||||
|
||||
![]( "")
|
||||
|
||||
|
||||
|
||||
也是这个教务系统，安全中心有一个换绑手机号的功能点，我们点击发送验证码
|
||||
|
||||
|
||||
|
||||
|
||||
这里可以看到是修改195开头的那个手机号，然后我们forward
|
||||
|
||||
|
||||
![]( "")
|
||||
|
||||
|
||||
|
||||
之后弹出一个验证码，我们输入验证码点击确定
|
||||
|
||||
|
||||
![]( "")
|
||||
|
||||
|
||||
|
||||
这里的验证码就做的很好，和发送短信的验证码数据包放在一起了，杜绝了短信轰炸。但是我们这里把195开头的手机号修改成我自己的手机号。
|
||||
|
||||
|
||||
|
||||
|
||||
成功让自己的手机号收到验证码，以为皆大欢喜了，结果。
|
||||
|
||||
|
||||
![]( "")
|
||||
|
||||
|
||||
|
||||
显示验证码错误，这是为什么呢？
|
||||
|
||||
我们继续审一下错误的数据包，也就是我们抓输入完短信验证码，点“下一步”的那个数据包
|
||||
|
||||
|
||||
|
||||
|
||||
可以看到居然在“下一步”的地方，对手机号又进行了一次验证，我们将这里的phone改成我自己的手机号，然后forward
|
||||
|
||||
|
||||
|
||||
|
||||
成功到达绑定新手机的界面，成功绕过了验证码认证，可以换绑任意用户的手机号。
|
||||
## 5.校内某平台druid未授权访问，导致泄露用户session，可以实现任意用户接管
|
||||
|
||||
|
||||
|
||||
|
||||
这是校内的一个实习平台，url为“https://xxx.edu.cn/shixi/”
|
||||
|
||||
@ -175,68 +168,67 @@ burp设置两个载荷
|
||||
|
||||
于是尝试拼接 ：“https://xxx.edu.cn/shixi/druid/index.html”
|
||||
|
||||
|
||||
|
||||
|
||||
可以看到是有druid的未授权访问，这里会泄露很多东西，比如数据库信息，数据库查询语句、访问记录等等。我们这里搞一下session。
|
||||
|
||||
可以看到有一个session监控：
|
||||
|
||||
|
||||
|
||||
|
||||
可以看到这里有登录过系统的用户的session，我们要做的就是把session收集起来。这里我有个比较好用的方法，可以ctrl+a复制全页，然后粘贴到excel里，然后选中session列，就可以快速的把session复制到txt里了。
|
||||
|
||||
|
||||
|
||||
|
||||
可以看到我们把session这样收集到了txt里，然后打开yakit
|
||||
|
||||
把txt导入到yakit的pyload里，然后去抓一下登录窗口的数据包：
|
||||
|
||||
|
||||
|
||||
|
||||
可以看到cookie有个jessionid，我们把他的值设置成标签，然后去拼接刚才的session的payload去批量访问：
|
||||
|
||||
|
||||
|
||||
|
||||
可以看到有很多200成功访问的，也有一些无法访问的，无法访问的原因主要是因为session是具有时效性的，长时间后这个session可能就会失效，但是只要源源不断的访问这个系统，我们就可以源源不断的盗取新的session。
|
||||
|
||||
我们找一个200正常访问的数据包，把里面的session复制下来。
|
||||
|
||||
|
||||
|
||||
|
||||
然后回到网页，打开f12里的存储，替换里面的jsessionid
|
||||
|
||||
|
||||
|
||||
|
||||
然后刷新页面：
|
||||
|
||||
|
||||
|
||||
|
||||
可以发现直接接管了别人的账号，登录进了系统。
|
||||
## 6.内部系统存在sql注入导致rce
|
||||
|
||||
|
||||
|
||||
|
||||
学校新出的一个平台，还是挺重要第一个平台，负责校内事务和档案的，应该还是个通用，很多学校都购买了这个平台。
|
||||
|
||||
我在那个平台抓包的时候，这个数据包偶然出现在我的burp里，我一看，居然直接把sql语句写出来了，这不就可以直接利用了吗？
|
||||
|
||||
|
||||
|
||||
|
||||
直接执行select user，可以看到右边直接进行回显了。那个user字段的内容就是回显的。
|
||||
|
||||
后来我写报告的时候，怎么找也找不到这个包在哪抓的，没办法，只能转化思路去找js接口。
|
||||
|
||||
|
||||
![]( "")
|
||||
|
||||
|
||||
|
||||
可以看到这个data里有sql:t
|
||||
|
||||
成功找到了这个接口，然后还有意外收获！
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
找到了近400个接口，这400个接口基本上都和上面的一样，直接写出了sql的语句，都可能存在sql注入！
|
||||
|
||||
@ -260,7 +252,7 @@ file = open('C:/Users/xxx/Desktop/111.txt','r') lines = file.read() apis=re.
|
||||
|
||||
然后我们将收集到的api，放到burp里去批量访问
|
||||
|
||||
|
||||
|
||||
|
||||
但是没有跑出来，应该是没有未授权漏洞，做了全局验证，逐个删除cookie字段，但还是不行，没有cookie就被深信服的设备拦住了。
|
||||
|
||||
@ -268,20 +260,20 @@ file = open('C:/Users/xxx/Desktop/111.txt','r') lines = file.read() apis=re.
|
||||
|
||||
首先我们要判断数据库类型，于是我继续看js
|
||||
|
||||
|
||||
|
||||
|
||||
一开始看到了from dual，我以为是oracle数据库，然后尝试了oracle数据的sql语法，发现总是报错。
|
||||
|
||||
后来再翻js数据包的时候，发现了这个包：
|
||||
|
||||
|
||||
|
||||
|
||||
这个数据包不仅直接暴露了usr_bsp，重要的是告诉了我们这个是postgresql数据库，这个数据库不太了解，我去百度了一下sql语法。发现他和mysql的语法差不多。
|
||||
```
|
||||
select table_name from information_schema.tables where table_schema=''
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
成功注入。然后在征得校方同意后，可以使用postgresql数据库的集成利用工具直接进行rce。
|
||||
|
||||
@ -290,59 +282,11 @@ select table_name from information_schema.tables where table_schema=''
|
||||
注：严禁未拿到授权就进行渗透测试
|
||||
|
||||
|
||||
建立了一个
|
||||
src专项圈子
|
||||
，内容包含**src漏洞知识库**
|
||||
、**src挖掘技巧**
|
||||
、**src视频教程**
|
||||
等，一起学习赚赏金技巧，以及专属微信群一起挖洞
|
||||
黑白之道发布、转载的文章中所涉及的技术、思路和工具仅供以安全为目的的学习交流使用，任何人不得将其用于非法用途及盈利等目的，否则后果自行承担！
|
||||
|
||||
圈子专注于更新src相关：
|
||||
|
||||
```
|
||||
1、维护更新src专项漏洞知识库，包含原理、挖掘技巧、实战案例
|
||||
2、分享src优质视频课程
|
||||
3、分享src挖掘技巧tips
|
||||
4、小群一起挖洞
|
||||
```
|
||||
如侵权请私聊我们删文
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
图片
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
图片
|
||||
|
||||
|
||||
|
||||
图片
|
||||
|
||||
|
||||
|
||||
图片
|
||||
|
||||
|
||||
图片
|
||||
|
||||
|
||||
|
||||
图片
|
||||
|
||||
|
||||
图片
|
||||
|
||||
**END**
|
||||
|
||||
|
||||
|
||||
19
doc/2025-05/电商诈骗平台漏洞挖掘实录：从供应链后台到数据泄露的破局之路.md
Normal file
19
doc/2025-05/电商诈骗平台漏洞挖掘实录：从供应链后台到数据泄露的破局之路.md
Normal file
@ -0,0 +1,19 @@
|
||||
# 电商诈骗平台漏洞挖掘实录：从供应链后台到数据泄露的破局之路
|
||||
原创 子午猫 网络侦查研究院 2025-05-10 10:27
|
||||
|
||||
|
||||
|
||||
|
||||
## 一、钓鱼网站初体验：分红模式下的技术嗅觉
|
||||
|
||||
接到侦查委托的那一刻，我盯着屏幕上的
|
||||
"跨境电商分红平台" 陷入沉思。表面上看，这是一个打着 "巴西电商项目" 旗号的投资平台 —— 用户投钱支持项目，每完成一笔巴西订单就能获得分红。但凭借多年经验，这种 "稳赚不赔" 的模式大概率是诈骗陷阱。带着怀疑打开网站，简洁的 UI 背后藏着诡异：首页没有任何商品详情，只有滚动的 "用户收益" 跑马灯，注册按钮旁的倒计时弹窗不断催促 "最后 3 个黄金席位"。
|
||||
|
||||
|
||||
### （一）技术侦查前的业务画像
|
||||
|
||||
先不急着开
|
||||
burp 抓包，而是用思维导图梳理平台逻辑：
|
||||
<table><tbody><tr><td data-colwidth="100.0000%" width="100.0000%" valign="top" style="padding: 3pt 6pt 1.5pt;border-width: 1pt;border-style: solid;border-color: rgb(222, 224, 227);background: rgb(245, 246, 247);"><p><span style="font-family:Arial;mso-fareast-font-family:等线;font-size:11.0000pt;"><span leaf="">graph TD</span></span><span style="font-family:Arial;mso-fareast-font-family:等线;font-size:11.0000pt;"><o:p></o:p></span></p><p><span style="font-family:Arial;mso-fareast-font-family:等线;font-size:11.0000pt;"><span style=""><span leaf=""> </span></span><span leaf="">A[</span><font face="等线"><span leaf="">用户投资</span></font><font face="Arial"><span leaf="">] --> B[</span></font><font face="等线"><span leaf="">资金进入平台</span></font><font face="Arial"><span leaf="">]</span></font></span><span style="font-family:Arial;mso-fareast-font-family:等线;font-size:11.0000pt;"><o:p></o:p></span></p><p><span style="font-family:Arial;mso-fareast-font-family:等线;font-size:11.0000pt;"><span style=""><span leaf=""> </span></span><span leaf="">B --> C{</span><font face="等线"><span leaf="">资金流向</span></font><font face="Arial"><span leaf="">?}</span></font></span><span style="font-family:Arial;mso-fareast-font-family:等线;font-size:11.0000pt;"><o:p></o:p></span></p><p><span style="font-family:Arial;mso-fareast-font-family:等线;font-size:11.0000pt;"><span style=""><span leaf=""> </span></span><span leaf="">C -->|</span><font face="等线"><span leaf="">宣称</span></font><font face="Arial"><span leaf="">| D[</span></font><font face="等线"><span leaf="">巴西电商项目</span></font><font face="Arial"><span leaf="">]</span></font></span><span style="font-family:Arial;mso-fareast-font-family:等线;font-size:11.0000pt;"><o:p></o:p></span></p><p><span style="font-family:Arial;mso-fareast-font-family:等线;font-size:11.0000pt;"><span style=""><span leaf=""> </span></span><span leaf="">C -->|</span><font face="等线"><span leaf="">实际</span></font><font face="Arial"><span leaf="">| E[</span></font><font face="等线"><span leaf="">诈骗分子腰包</span></font><font face="Arial"><span leaf="">]</span></font></span><span style="font-family:Arial;mso-fareast-font-family:等线;font-size:11.0000pt;"><o:p></o:p></span></p><p><span style="font-family:Arial;mso-fareast-font-family:等线;font-size:11.0000pt;"><span style=""><span leaf=""> </span></span><span leaf="">F[</span><font face="等线"><span leaf="">分红机制</span></font><font face="Arial"><span leaf="">] --> G[</span></font><font face="等线"><span leaf="">伪造订单数据</span></font><font face="Arial"><span leaf="">]</span></font></span><span style="font-family:Arial;mso-fareast-font-family:等线;font-size:11.0000pt;"><o:p></o:p></span></p><p><span style="font-family:Arial;mso-fareast-font-family:等线;font-size:11.0000pt;"><span style=""><span leaf=""> </span></span><span leaf="">H[</span><font face="等线"><span leaf="">技术架构</span></font><font face="Arial"><span leaf="">] --> I[</span></font><font face="等线"><span leaf="">前后端分离</span></font><font face="Arial"><span leaf="">]</span></font></span><span style="font-family:Arial;mso-fareast-font-family:等线;font-size:11.0000pt;"><o:p></o:p></span></p><p><span style="font-family:Arial;mso-fareast-font-family:等线;font-size:11.0000pt;"><span style=""><span leaf=""> </span></span><span leaf="">I --> J[</span><font face="等线"><span leaf="">前端</span></font><font face="Arial"><span leaf="">: Webpack</span></font><font face="等线"><span leaf="">构建</span></font><font face="Arial"><span leaf="">]</span></font></span><span style="font-family:Arial;mso-fareast-font-family:等线;font-size:11.0000pt;"><o:p></o:p></span></p><p><span style="font-family:Arial;mso-fareast-font-family:等线;font-size:11.0000pt;"><span style=""><span leaf=""> </span></span><span leaf="">I --> K[</span><font face="等线"><span leaf="">后端</span></font><font face="Arial"><span leaf="">: Spring Boot]</span></font></span><span style="font-family:Arial;mso-fareast-font-family:等线;font-size:11.0000pt;"><o:p></o:p></span></p></td></tr></tbody></table>
|
||||
这种模式下，技术突破口往往不在前端展示层，而在供应链管理后台—— 诈骗分子需要一个地方伪造订单、管理假数据。带着这个假设，开始第一步：信息收集。
|
||||
|
||||
124
doc/2025-05/超越漏洞管理：CVE体系面临哪些挑战？.md
Normal file
124
doc/2025-05/超越漏洞管理：CVE体系面临哪些挑战？.md
Normal file
@ -0,0 +1,124 @@
|
||||
# 超越漏洞管理：CVE体系面临哪些挑战？
|
||||
FreeBuf 2025-05-10 10:03
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
漏洞管理的被动性叠加政策流程的延迟，使安全团队不堪重负。根据我们漏洞运营中心（VOC）的数据分析，在68,500个客户资产中发现了1,337,797个独立安全事件，其中32,585个为不同CVE（通用漏洞披露）编号，10,014个CVSS（通用漏洞评分系统）评分≥8分。外部资产存在11,605个独特CVE，内部资产则高达31,966个。面对如此庞大的漏洞数量，部分漏洞未能及时修补导致系统沦陷已不足为奇。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
本文将探讨漏洞报告现状、基于威胁和利用可能性的优先级排序方法，分析统计概率并简要讨论风险应对。最后我们将提出降低漏洞影响的解决方案，同时为管理团队提供危机响应的灵活策略。
|
||||
|
||||
### Part01
|
||||
## CVE体系的局限性
|
||||
###
|
||||
|
||||
|
||||
西方国家普遍采用由MITRE和NIST（美国国家标准与技术研究院）主导的CVE和CVSS体系。截至2025年4月，运行25年的CVE项目已发布约29万条记录（含"已拒绝"和"延期"条目）。NIST国家漏洞数据库（NVD）依赖CVE编号机构（CNA）进行初始评估，这种机制虽提升效率但也引入偏差。研究者与厂商对漏洞严重性的分歧常导致关键漏洞披露延迟。
|
||||
|
||||
|
||||
2024年3月的行政延误造成NVD积压24,000条未处理的CVE记录。2025年4月，美国国土安全部终止与MITRE的合同更引发行业对CVE体系未来的担忧，所幸在业界强烈反响下最终延续了资金支持。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
中国自2009年运营的CNNVD漏洞库虽具技术价值，但受政治因素影响难以国际合作。值得注意的是，并非所有漏洞都会立即披露（形成盲区），而未被发现的零日漏洞更持续被利用。2023年谷歌威胁分析组（TAG）和Mandiant共发现97个零日漏洞，主要影响移动设备、操作系统和浏览器。相比之下，CVE词典中仅约6%的漏洞曾被利用，2022年研究显示半数企业每月仅修复15.5%或更少的漏洞。
|
||||
|
||||
### Part02
|
||||
## 威胁情报驱动的决策
|
||||
##
|
||||
###
|
||||
|
||||
|
||||
尽管存在缺陷，CVE系统仍提供有价值的漏洞情报。为应对海量漏洞，需优先处理最可能被利用的威胁。事件响应与安全团队论坛（FIRST）开发的EPSS（漏洞利用预测评分系统）能预测漏洞在野利用概率。安全团队可据此选择广泛修补策略或重点防御关键漏洞，两者各有利弊。
|
||||
|
||||
|
||||
为验证覆盖范围与效率的平衡，我们分析某公共部门客户的397个漏洞扫描数据。如图所示，当考虑前264个漏洞时，利用概率的缩放计算已接近100%，而此时最高单个漏洞EPSS评分仍低于11%。这说明在系统规模扩大时，仅依赖EPSS进行优先级排序将面临巨大挑战。
|
||||
|
||||
|
||||
|
||||
|
||||
### Part03
|
||||
### 攻击者的成功概率
|
||||
|
||||
|
||||
通过概率模型分析可得出三个关键结论：
|
||||
|
||||
|
||||
1. 攻击者成功率随目标系统数量呈指数增长：针对100个系统时，中等技能攻击者的成功概率已接近100%
|
||||
|
||||
2. 企业内网通常存在数千台设备，单点突破即可横向移动
|
||||
|
||||
3. 专业渗透测试人员对互联网目标的平均成功率约为30%
|
||||
|
||||
|
||||
|
||||
|
||||
### Part04
|
||||
## 重构漏洞管理范式
|
||||
###
|
||||
|
||||
|
||||
当前以CVE为核心的漏洞管理模式已难以应对挑战，建议转向"威胁缓解"与"风险降低"双轨制：
|
||||
|
||||
|
||||
**威胁缓解措施**
|
||||
|
||||
1. 重点防护互联网暴露面系统
|
||||
|
||||
2. 动态响应流程整合补丁、配置调整、补偿控制等手段
|
||||
|
||||
3. 将EPSS作为威胁情报的辅助工具
|
||||
|
||||
|
||||
**风险降低策略**
|
||||
|
||||
1. 收缩攻击面：清理未管理的互联网暴露资产
|
||||
|
||||
2. 限制影响范围：通过网络分段、零信任架构控制横向移动
|
||||
|
||||
3. 提升基线安全：系统化减少漏洞数量与严重性，优先投资回报率高的改进
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Part05
|
||||
## 2030安全战略框架
|
||||
##
|
||||
###
|
||||
|
||||
|
||||
未来安全建设应关注：
|
||||
|
||||
1. 源头治理：将安全融入系统设计与供应链管理
|
||||
|
||||
2. 威胁建模：通过攻防演练验证防御有效性
|
||||
|
||||
3. 架构革新：实施SASE和零信任战略
|
||||
|
||||
4. 默认安全：建立强制性的安全基线标准
|
||||
|
||||
|
||||
### 推荐阅读
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MjM5NjA0NjgyMA==&mid=2651320090&idx=1&sn=cb1b7e4d9fbfa8c98cf0c378da407981&scene=21#wechat_redirect)
|
||||
|
||||
### 电台讨论
|
||||
|
||||
[]()
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user