文章总结： 本文详细披露了某品牌智能门锁云端API存在水平越权漏洞，攻击者通过修改请求中的deviceId即可远程开锁。漏洞根因在于服务端未校验设备归属、设备ID可枚举且高危操作缺乏二次确认。文章提供了完整的攻击链分析、挖掘方法总结及防御建议，强调物联网安全中资源归属校验的重要性。 综合评分： 95 文章分类： 渗透测试,漏洞分析,IoT安全,WEB安全,红队

我改了个设备ID，打开了别人家的门：智能门锁云端API越权漏洞全纪实

原创

逍遥 逍遥

昆仑AI安全实验室

2026年8月20日 01:39 广东

在小说阅读器读本章

去阅读

上周参加一个智能家居产品的安全评估，目标是一款市面上卖得挺火的智能门锁，号称“金融级加密”“银行级安全”。我注册了个账号，绑定了自己测试用的门锁，抓包分析开门流程。在请求体里看到一个字段：deviceId，值是lock_20260801001。我把它改成lock_20260801002，重放。三秒后，响应返回{"code":200,"message":"开锁指令已下发"}。那一刻我意识到，这锁防君子不防小人。

本文把整个攻击链路、漏洞根因、挖掘方法和防御方案全部拆开。2026年的物联网安全，远比你想的更脆弱。

一、智能门锁的云端架构：一道被忽视的信任链

现代智能门锁早已不是离线设备。一把锁通常由四部分组成：

1. 锁体：内置蓝牙/Wi-Fi模块，连接家庭网关或手机。
2. 手机APP：用户通过APP远程操作门锁。
3. 云端API：手机APP与锁体之间的桥梁，负责指令转发。
4. 厂商云平台：管理所有设备、用户、权限的中央系统。

当你用手机APP点“开锁”时，请求实际走的是：

手机APP → 厂商云端API → 锁体网关 → 门锁

这个链条里，云端API是一个关键节点。它必须确认两件事：你是谁（身份认证）和你有没有权限操作这把锁（资源归属校验）。前者通常靠Token或Session实现，后者则依赖后端在收到请求时，去数据库里查“这个用户是否绑定了这个设备”。

问题恰恰出在第二步。很多厂商的实现逻辑是这样的：

• 前端请求携带deviceId和userId。
• 后端只校验了userId是否有效（甚至这一步也省略）。
• 后端直接调用“下发开锁指令”的微服务，把deviceId作为目标设备。

后端没有验证“当前登录的userId是否真的拥有这个deviceId”。这意味着攻击者只要登录自己的账号，把请求里的deviceId改成别人的，就能操作别人的门锁。

二、实战：从抓包到远程开锁的完整攻击链

以下是脱敏后的授权测试过程。

目标设备：某品牌智能门锁，支持远程开锁、临时密码、门锁状态查询等功能。

第一步：正常抓包

我注册账号，在APP里添加自己的门锁设备（测试用），然后抓取“远程开锁”的请求包：

POST /api/v3/lock/remoteOpen HTTP/1.1Host: api.smartlock.comAuthorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...Content-Type: application/json
{  "deviceId": "lock_20260801001",  "userId": "user_8f3d2a7e",  "timestamp": 1724072000,  "sign": "a3f9c2e1b8d74f6a"}

响应正常返回：

{"code":200,"message":"开锁指令已下发","data":{"commandId":"cmd_01HZ..."}}

第二步：修改设备ID

我在Burp Repeater里把deviceId改成lock_20260801002（这是另一个用户的设备ID，通过之前测试发现设备ID是自增的），重放。响应同样返回200，commandId成功生成。

此时目标门锁真的被开锁了（在受控环境中，另一把测试锁被物理验证确实收到指令并执行了开锁动作）。

第三步：测试其他权限接口

除了开锁，这款门锁的云端API还提供了多个高危接口：

• POST /api/v3/lock/tempPassword：生成临时密码，同样存在越权。
• GET /api/v3/lock/status：查询门锁状态（是否关门、电量），可越权获取其他用户的门锁状态。
• DELETE /api/v3/lock/unbind：解绑设备，可越权解除其他用户与门锁的绑定关系。
• POST /api/v3/lock/firmware：触发固件更新，可越权强制其他门锁更新。

逐一测试，全部存在水平越权。攻击者可以批量枚举deviceId，对任意门锁下发开锁指令。如果结合设备ID的生成规律（自增、时间戳+序列号），一个简单的脚本就能覆盖全网的该品牌门锁。

第四步：扩大战果

我进一步分析了设备ID的生成规律，发现它由“产品代码+注册序号”组成，注册序号是全局自增的。这意味着攻击者可以从lock_20260801001遍历到lock_20260802000，每一把锁都能被远程操作。

一个可能的攻击场景是：攻击者编写脚本，每晚凌晨对目标小区的所有门锁批量下发“开锁”指令。由于云端不会向锁主发送“有人远程开锁”的通知（或通知被静默），用户毫无感知。第二天早上，家里可能已经被“合法”进入过了。

三、漏洞根因：物联网平台的三层失守

第一层：资源归属校验缺失。 这是最根本的问题。后端没有执行“这个deviceId是否属于当前userId”的检查。这类校验在Web应用里已经是基本要求，但在物联网平台里，由于设备数量庞大、微服务拆分复杂，反而常常被忽略。

第二层：设备ID可枚举。 设备ID使用全局自增序列号，没有使用随机UUID。攻击者不需要知道目标的设备ID，枚举即可。

第三层：高危操作缺少二次确认。 开锁、解绑、固件更新这类高危操作，应该在服务端进行额外的安全验证——比如要求用户输入安全密码，或者通过短信验证码二次确认。但这把锁的云端API没有做任何二次鉴权。

四、不止门锁：物联网设备API越权的通用模式

我在其他物联网产品里也发现了类似问题，涵盖智能摄像头、车联网、智能家居网关等。

• 智能摄像头API越权：修改摄像头ID，可以查看其他用户的视频流。
• 车联网API越权：修改车辆识别码（VIN），可以远程解锁车门、启动引擎。
• 智能音箱API越权：修改设备ID，可以向其他用户的音箱推送任意音频。
• 智能电表API越权：修改电表ID，可以读取其他用户的用电数据。

这些漏洞的共同规律是：设备ID由云端管理，但云端只做了身份认证，没做资源归属校验。 攻击者只要有一个有效账号，就能访问整个设备池。

挖掘方法总结：

1. 购买或注册目标物联网产品，绑定自己的设备。
2. 用Burp Suite或Charles抓取所有涉及设备操作的API请求。
3. 找到deviceId、device_id、serial_number、mac等设备标识字段。
4. 修改为其他值（加1、减1、随机），观察响应是否正常。
5. 若响应正常且返回了其他人的设备数据或成功执行了操作，则存在越权漏洞。
6. 测试设备ID的生成规律，看是否可枚举。

五、防御：让云端成为真正的守护者

服务端强制资源归属校验。 每个设备操作API执行前，必须在后端查数据库：当前userId是否与该deviceId绑定。不依赖前端传入的任何绑定关系。

设备ID随机化。 不要使用自增ID，改用至少128位的随机字符串，或使用设备出厂时烧录的唯一芯片ID结合云端随机映射。

高危操作二次确认。 对开锁、解绑、固件更新、数据导出等敏感操作，强制要求二次验证（短信验证码、安全密码、或APP推送确认）。

异常行为检测。 监控单个用户对大量不同设备ID的访问行为，一旦发现短时间内操作多个不相关设备，立即告警并冻结账号。

权限模型设计。 将“设备所有者”“家庭成员”“管理员”等角色严格区分，不同角色对应不同的API访问范围。

六、写在最后

智能门锁这类物联网设备，连接着物理世界的安全。一个云端API的越权漏洞，远比一个Web后台的越权漏洞危险得多——后者最多泄露数据，前者直接打开家门。

2026年，物联网设备数量已突破千亿级，但很多厂商的安全能力还停留在“能用就行”的阶段。攻击者不需要物理接触门锁，不需要破解蓝牙协议，甚至不需要知道目标用户是谁。只需要一个有效账号，加上一个可枚举的设备ID，就能远程打开任何一扇门。

如果你在做物联网产品的安全测试，一定要把云端API的越权测试放在首位。如果你在做物联网产品开发，请记住：云端的资源归属校验，是物理安全的最后一道防线。

严正声明 本文所述技术仅用于合法授权的安全测试，所有案例均已脱敏处理。未经授权利用漏洞入侵他人智能设备属于违法行为，与作者无关。物联网安全测试必须在设备所有者或厂商授权范围内进行，遵守法律法规。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：昆仑AI安全实验室 逍遥 逍遥《我改了个设备ID，打开了别人家的门：智能门锁云端API越权漏洞全纪实》