1. 项目概述：一次典型的内网安全准入测试

最近在做一个内部网络的安全准入测试项目，客户要求对一批新上线的物联网管理平台进行基础安全评估。在资产梳理阶段，我们发现了多套“大华智能物联综合管理平台”。这个平台名字听起来就很“综合”，通常用于集中管理视频监控、门禁、报警等各类安防物联网设备，是很多企业、园区、楼宇的神经中枢。这类系统一旦出问题，影响的可不是单一设备，而是整个安防体系的可见性和可控性。

我们的切入点，就是那个看似不起眼的“默认口令”问题。这听起来像是安全领域的“老生常谈”，但实际情况是，在时间紧、人手不足的运维环境下，或者在一些非核心的测试、演示环境中，使用出厂默认账号密码的情况依然屡见不鲜。而“大华智能物联综合管理平台”作为一个需要高权限进行配置的后台，其默认凭证如果未被修改，就相当于把整个安防系统的钥匙插在了门上。

本次复现的核心，就是围绕“token”和“默认口令”这两个关键词展开。这里的“token”通常指的是Web应用用于维持会话状态的认证令牌，而“默认口令”则是攻击者获取有效token、进而接管系统权限的最直接路径。我将从环境搭建、漏洞原理、利用过程到深度利用和修复建议，完整地拆解这个看似简单却危害极大的安全问题。

2. 漏洞原理与影响范围深度解析

2.1 什么是“默认口令”漏洞？

从本质上讲，这不是一个传统意义上的代码逻辑漏洞（如SQL注入、命令执行），而是一种“配置缺陷”或“管理疏忽”。厂商为了便于初次部署和调试，会为设备或软件预设一组通用的管理员账号和密码，例如admin/admin、admin/123456等。安全规范要求管理员在系统上线前必须修改这些默认凭证。然而，由于遗忘、认为内网就安全、或者系统由非专业人员部署等原因，这些默认口令得以保留。

在“大华智能物联综合管理平台”的语境下，这个默认口令通常对应着平台的最高管理员权限。攻击者一旦通过默认口令登录，就可以执行以下操作（具体功能可能因版本而异）：

1. 完全控制监控系统：查看、下载、删除所有摄像头录像；操控云台摄像头转动；修改录像计划。
2. 管理所有物联网设备：添加、删除门禁控制器、报警主机、消防设备等，直接扰乱物理安全。
3. 用户与权限管理：创建新的管理员账户，即使原默认密码被修改，后门依然存在。
4. 系统配置篡改：修改网络设置、关闭安全功能（如登录日志、复杂密码策略），为持久化控制铺路。
5. 获取敏感信息：平台可能存储了设备位置、人员信息、网络拓扑等敏感数据。

2.2 Token在认证流程中的关键作用

理解“token”在这里的角色，能让我们明白漏洞利用的链条。一个典型的Web登录流程如下：

1. 用户在前端输入用户名和密码。
2. 前端将凭证发送到后端认证接口（如/api/v1/login）。
3. 后端验证凭证正确后，生成一个唯一的、有时效性的字符串，这就是Session Token（或称为Session ID、Access Token）。这个Token通常与用户身份、权限等级绑定，并存储在服务器内存或数据库中。
4. 后端将这个Token返回给前端。前端在后续的每一次请求中（如访问/api/v1/getCameraList），都会在HTTP请求头（通常是Cookie或Authorization头）里带上这个Token。
5. 后端接收到请求后，不是再次验证用户名密码，而是校验这个Token的有效性。如果Token有效且未过期，就认为请求来自已登录的合法用户，并执行相应操作。

漏洞利用链：攻击者通过“默认口令”成功调用登录接口 → 获取到一个合法的、高权限的Token → 使用这个Token冒充合法管理员，调用其他所有需要认证的API接口。整个过程中，攻击者不再需要知道密码，仅凭这个“偷来的钥匙”（Token）就能畅行无阻。

注意：不同版本的系统，Token的传递和校验方式可能有细微差别，例如有的放在Cookie的JSESSIONID里，有的使用自定义的X-Access-Token头。但核心思想不变：Token是会话的凭证。

2.3 影响范围与严重性评估

这个漏洞的可怕之处在于其“低门槛、高影响”的特性。

• 攻击复杂度极低：不需要任何高深的漏洞利用技术，只需要知道默认账号密码（这些信息往往在用户手册或互联网上可轻易查到），使用浏览器或简单的HTTP请求工具即可完成。
• 影响面极大：直接获取系统最高权限，意味着整个物联网安防平台失守。从信息泄露到物理安全破坏，链条非常短。
• 隐蔽性强：如果攻击者只是登录并查看信息，不进行任何修改操作，可能不会触发任何报警，导致“隐形”入侵。
• 内网渗透跳板：该平台通常部署在内网，并需要与大量物联网设备通信。攻破该平台后，攻击者可能以此为跳板，进一步探测和攻击内网中更核心的业务系统或设备。

3. 复现环境搭建与信息收集

3.1 实验环境准备

重要声明：本复现仅用于合法授权的安全测试、教学研究及企业自查，严禁对任何未授权系统进行测试。请在隔离的实验室环境中进行。

1. 目标系统获取：从官方或合法渠道获取“大华智能物联综合管理平台”的安装包或虚拟机镜像。记录确切的版本号（如V3.0.20221117），不同版本的默认口令和接口可能存在差异。
2. 部署环境：建议使用一台独立的Windows Server虚拟机（因为此类平台常基于Windows部署）。按照官方安装手册部署系统。确保网络通畅（仅主机或NAT模式，隔离于生产网络）。
3. 测试工具：
   • 浏览器：Chrome或Firefox，用于手工测试和抓包。
   • 抓包/代理工具：Burp Suite Community版或Fiddler，用于拦截和分析HTTP/HTTPS流量，这是理解登录和Token机制的核心。
   • HTTP请求工具：Postman或cURL命令行，用于自动化发送请求和测试接口。
   • 目录扫描工具：dirsearch或gobuster，用于发现未公开的登录页面或API接口（备用）。

3.2 信息收集与默认口令确认

在发起任何测试前，充分的信息收集是成功的关键。

1. 识别登录入口：访问目标IP地址，通常会出现平台登录页面。查看页面源代码，有时会包含版本信息。
2. 查找默认凭证：
   • 官方文档：查阅随安装包提供的用户手册或快速入门指南。
   • 网络搜索：使用“大华 智能物联 综合管理平台 默认密码”、“dahua iot platform default credential”等关键词搜索。请注意，务必在合法的知识库或技术论坛中查找，用于自身环境测试，切勿用于攻击。
   • 常见默认口令库：参考公开的默认口令列表。对于大华早期或某些版本的平台，常见的组合有admin/admin、admin/123456、admin/空密码、supervisor/supervisor等。
3. 验证服务端口：使用nmap或Advanced Port Scanner快速扫描目标，确认开放了哪些端口（如80, 443, 8000等），有助于发现其他管理入口。

4. 漏洞利用过程详细拆解

假设我们通过信息收集，确定目标系统版本的一个常见默认口令是admin/123456。

4.1 步骤一：拦截登录过程，分析Token生成

1. 打开浏览器，配置代理指向Burp Suite（如127.0.0.1:8080）。
2. 访问目标平台登录页面，在用户名和密码框中输入admin和123456。
3. 点击登录前，确保Burp Suite的“Intercept is on”处于开启状态。
4. 点击登录按钮，此时请求会被Burp Suite拦截。

关键分析点（在Burp的Proxy -> Intercept标签页中）：

• 请求方法：通常是POST。
• 登录接口URL：可能是/api/login、/login.action、/dahua_api/login等。
• 请求体（Body）：查看Raw或Params标签，通常是以JSON或表单形式提交的凭证。

  // 可能是JSON格式 { "username": "admin", "password": "123456" }

  # 也可能是表单格式（在Raw中查看） username=admin&password=123456

• 响应包（Forward请求后，在HTTP history中查看）：登录成功后的响应包是重点。我们需要找到服务器返回的Token。
  • 查看响应头（Response Headers）：关注Set-Cookie字段，里面可能包含JSESSIONID=xxxxxx或token=xxxxxx这样的信息。
  • 查看响应体（Response Body）：通常是一个JSON数据。登录成功的响应里，极有可能直接包含一个Token字段。

    { "code": 200, "msg": "登录成功", "data": { "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...", // 这是一个JWT Token示例 "userId": 1, "userName": "admin" } }

  • 记录下这个Token值。这就是我们后续操作的“万能钥匙”。

4.2 步骤二：使用Token进行未授权访问

现在，我们有了Token，可以尝试访问需要管理员权限的接口，而无需再次输入密码。

1. 在Burp Suite的HTTP history中找到登录成功后的任意一个后续请求（比如浏览器自动跳转后加载用户信息的请求）。
2. 观察这个请求的请求头（Request Headers），看Token是如何被携带的。
   • Cookie方式：Cookie: JSESSIONID=xxxxxx; token=yyyyyy
   • Authorization头方式：Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
   • 自定义头方式：X-Access-Token: xxxxxx
3. 使用Postman或cURL，模拟一个高权限操作。例如，尝试获取摄像头列表。
   • 方法：GET
   • URL：http://<目标IP>/api/v1/camera/list(接口路径需根据实际抓包确定)
   • Headers：添加正确的Token携带方式。如果是在Cookie里，就添加Cookie头；如果是Bearer Token，就添加Authorization: Bearer <你的Token>。
4. 发送请求。如果返回了摄像头列表的JSON数据（而不是401未授权或403禁止访问），则证明漏洞复现成功！我们仅凭默认口令获取的Token，就拥有了系统的完全控制权。

4.3 步骤三：尝试进行实质性操作

为了进一步验证危害，可以尝试进行一个无害但能证明权限的写操作。在测试环境中进行！

1. 添加一个测试用户：寻找用户管理接口，如POST /api/v1/user/add。
2. 构造请求，在Body中填入新用户信息，并在Headers中带上Token。

   { "username": "test_hacker", "password": "Test@12345", "role": "admin" // 尝试赋予管理员角色 }

3. 发送请求。如果返回成功，则证明攻击者可以创建后门账户，实现权限维持。即使管理员后来修改了admin的默认密码，攻击者仍可通过test_hacker账户登录。

5. 深度利用与后渗透思路

在实战的渗透测试中，获取平台控制权只是开始。一个有经验的安全工程师会思考如何最大化利用这个入口点。

5.1 信息深度收集

1. 全量资产发现：利用获取的Token，遍历所有API接口，获取完整的设备清单（摄像头、NVR、门禁、报警主机）、用户列表、组织架构。
2. 配置文件与数据库探查：寻找是否有接口能下载配置文件（如config.properties,application.yml），或存在数据库查询接口。配置文件中可能包含数据库密码、其他系统集成密钥等更敏感的信息。
3. 网络拓扑探测：平台管理的设备IP地址段，揭示了内网的网络划分情况。这些物联网设备所在的网段，可能与其他业务系统存在弱隔离或信任关系。

5.2 权限维持与持久化

1. 创建隐藏后门账户：如前所述，创建一个权限与admin相当但用户名不显眼的新账户。
2. 篡改现有账户：如果可以，直接修改其他已知管理员的密码或邮箱，为后续登录提供更多选择。
3. 植入Webshell：检查平台是否有文件上传功能（如升级包上传、图片上传），尝试上传经过伪装的Webshell脚本，获取服务器命令执行权限。这需要结合文件上传漏洞的测试手法。
4. 利用Token刷新机制：研究平台的Token刷新接口（如/api/auth/refresh）。如果刷新机制存在缺陷（如仅校验旧Token有效性即可发放新Token），攻击者可以永久维持有效会话。

5.3 横向移动与跳板

1. 平台服务器本身：如果平台部署在Windows服务器上，且权限足够，可以尝试从Web漏洞转向系统漏洞利用，获取服务器系统权限。
2. 通过平台连接设备：很多物联网平台支持通过Web界面直接“直连”或“运维”设备。攻击者可能利用这个功能，以平台服务器为跳板，直接访问内网中摄像头、NVR等设备的Web管理界面。这些设备本身也可能存在默认口令或其他漏洞。
3. 利用平台发起的网络请求：分析平台与设备通信的协议和端口。攻击者可以尝试在平台服务器上构造恶意请求，发送给内网其他设备，进行漏洞探测或攻击。

6. 漏洞修复与安全加固建议

对于企业管理员和安全运维人员，发现此类问题后，应立即采取以下措施：

6.1 紧急处置

1. 立即修改默认口令：这是第一步，也是最重要的一步。为所有管理员账户设置强密码（长度大于12位，包含大小写字母、数字、特殊字符，且无规律）。
2. 审计账户与权限：立即审查系统所有用户账户，删除可疑的、未知的账户，特别是测试期间创建的账户。检查每个账户的权限，确保遵循最小权限原则。
3. 排查后门：检查系统是否有异常的计划任务、服务、启动项或Webshell文件。对比官方原始文件哈希值。
4. 重置Token：如果条件允许，重启平台服务或所有用户强制下线，使之前被盗的Token全部失效。

6.2 长期加固策略

1. 强制修改初始密码：在系统首次安装或创建新管理员时，强制要求修改默认密码，否则无法使用任何功能。
2. 启用多因素认证（MFA）：为管理员登录启用短信验证码、TOTP动态令牌或硬件Key等二次验证，即使密码泄露，攻击者也无法登录。
3. 加强口令策略：系统后台强制启用强密码策略，并定期（如90天）要求更换密码。
4. 网络访问控制：
   • 将物联网管理平台部署在独立的VLAN中，严格限制访问源IP。仅允许运维堡垒机或特定管理终端的IP地址访问其管理后台（80/443端口）。
   • 平台与前端设备（摄像头等）之间的通信网络也应与其他业务网络隔离。
5. 完善日志审计与监控：
   • 确保所有登录（成功/失败）、权限变更、重要配置修改操作都被详细记录。
   • 部署SIEM或日志分析系统，设置告警规则。例如：针对“使用默认用户名admin登录成功”这一事件，应立即产生高危告警并通知安全人员。
   • 监控异常时间的登录行为、同一账户多地登录等异常会话。
6. 定期安全评估：将物联网平台纳入常规的漏洞扫描和渗透测试范围，定期检查是否存在新的安全漏洞或配置错误。
7. 关注厂商更新：及时关注厂商发布的安全公告和版本更新，及时修补已知漏洞。

7. 测试中的常见问题与排查技巧

在实际复现过程中，你可能会遇到一些问题，以下是一些常见情况的排查思路：

问题1：使用默认口令登录失败。

• 可能原因：版本不对，默认口令已不同；口令已被人为修改；登录接口地址或参数格式不对。
• 排查：
  1. 确认版本：通过页面版权信息、JS文件、404错误页面等细节确认平台确切版本，重新查找对应版本的默认口令。
  2. 分析登录包：用Burp仔细查看登录请求的每一个参数。除了username和password，是否还需要code（验证码）、token（一次性CSRF Token）？密码是否是加密传输（如Base64, MD5, RSA加密）？如果是，需要找到前端加密方式并模拟。
  3. 尝试其他常见组合：除了admin，尝试supervisor,system,administrator等用户名。密码尝试空密码、admin123、dahua123等。

问题2：登录成功，但找不到Token。

• 可能原因：Token存储位置不常规；系统使用Session而非Token认证；响应被加密或编码。
• 排查：
  1. 检查所有响应头：仔细查看每一个Set-Cookie字段，可能有多个Cookie，Token可能藏在不起眼的名称里。
  2. 检查响应体格式：响应体可能是XML格式，或者JSON的字段名不是token，而是accessToken、sessionId、auth_key等。
  3. 全局搜索：在Burp的HTTP history中，对登录成功后的所有请求和响应进行搜索（Ctrl+F），关键词可以是token、session、auth等。
  4. 观察后续请求：登录后浏览器自动发起的第一个请求，其Cookie或Header里携带了什么，那个就是认证凭证。

问题3：拿到Token，但访问其他接口返回403/401。

• 可能原因：Token已过期；Token格式错误或携带方式不对；接口需要额外的权限标识。
• 排查：
  1. 检查Token有效期：如果Token是JWT格式（通常形如xxx.yyy.zzz），可以到 jwt.io 解码中间部分（Payload），查看exp字段判断是否过期。
  2. 精确复制携带方式：完全模仿浏览器发送请求的方式。如果浏览器用Cookie: JSESSIONID=xxx，你就不要用Authorization: Bearer xxx。
  3. 检查接口路径和权限：确认你访问的接口路径是否正确，以及该接口是否需要特定的角色（如/api/admin/xxx可能需要role=admin）。尝试访问更基础的接口，如/api/user/info（获取当前用户信息）来测试Token是否有效。

问题4：在复现深度利用时，操作失败。

• 可能原因：接口参数不全或格式错误；后端有额外的业务逻辑校验（如状态检查）；当前Token所属用户权限不足。
• 排查：
  1. 抓取正常操作包：在Web界面上手动进行一次类似操作（如添加一个普通用户），用Burp抓包，分析完整的请求结构（URL、Method、Headers、Body），然后依葫芦画瓢进行修改。
  2. 分析错误响应：仔细阅读接口返回的错误信息（msg或message字段），它们通常会给出具体原因，如“用户名已存在”、“密码强度不足”、“无操作权限”等。

8. 从漏洞复现到安全思维的提升

这次对“大华智能物联综合管理平台默认口令”的复现，看似只是输入了一个简单的密码，但其背后串联起了Web认证机制（Token）、配置安全、权限提升、持久化控制等多个安全知识点。对于安全从业者而言，真正的价值不在于“会用一个漏洞”，而在于通过这个点，看到整个面的风险。

在物联网和工控领域，“默认口令”问题尤为普遍和致命。很多设备部署在机房、车间、野外，运维人员可能一年才现场访问一次，修改默认密码这种“小事”极易被忽略。作为防御方，必须建立资产清单，并强制对所有入网设备进行初始安全配置核查。作为攻击方（在授权测试中），则应将“默认凭证”测试作为内网渗透的必备步骤，并养成习惯：每发现一个新IP、新服务，首先尝试的就是那些最常见的“万能钥匙”。

最后，分享一个我在内部红队演练中的小技巧：我们会维护一个不断更新的“默认口令-设备厂商-型号”对应表，并集成到自动化扫描工具里。当扫描器发现一个Web服务，它会自动根据HTTP响应头中的Server、X-Powered-By、特定静态文件哈希值来识别服务类型和版本，然后自动尝试对应的默认口令列表。这种高度自动化的方式，能在短时间内快速定位出那些“低垂的果实”，为后续更复杂的手工测试节省大量时间。安全攻防，本质上是一场效率与深度的博弈。