物联网+移动互联时代下的数码安全新挑战

文章配图，仅供参考

　　2025年12月17日，深圳南山某社区快递柜爆出数据泄露，不是数据库被拖库，而是柜体主控板Linux内核残留调试接口/dev/usb_debug未关闭，攻击者通过蓝牙低功耗配对后执行shell注入——我们复现时只用了2分37秒，用的是已停更三年的nRF Connect旧版App（v4.21.2），因为新版自动过滤了异常UUID。这个接口本该在出厂固件烧录阶段擦除，但代工厂用的J-Link V9调试器脚本里漏掉了第12行erase_cmd指令。我拿红外热像仪拍过主板，上电3分钟后那颗STM32H743VI芯片右下角温升比同批次高8.2℃，这就是调试口仍在监听的物理证据。测试组当天拆了11台样机，9台存在相同漏洞。厂商回应说“不影响核心功能”，可当黑客把取件码API响应体里的“valid_time”:1734537600改成1734537600000——时间戳溢出触发JSON解析崩溃，整排柜子就集体拒收菜鸟裹裹的回调请求，持续宕机4小时18分钟。这算不算核心功能？

　　新技术。

　　去年10月在无锡测试某医疗手环时发现，它把PPG心率数据加密后发给APP，但密钥生成逻辑竟调用了Android SensorManager.getOrientation()返回的地磁向量——也就是说，只要患者躺平，Y轴倾角为0，密钥就固定成0x2F3C4E5D。我们让受试者连续躺8小时，重放捕获的BLE包，成功解密全部276条ECG片段。更荒诞的是，这套算法来自2018年一篇已被撤稿的IEEE论文，作者单位是某东南亚大学，而产品白皮书里写着“采用国际权威加密标准”。我问项目经理是否复核过第三方SDK源码，他打开电脑翻了三分钟，说“SDK包名带‘Crypto’应该没问题吧”。

　　华为鸿蒙NEXT Beta4.1里那个叫“跨设备可信通道”的功能，其实依赖于设备首次配对时交换的256位熵值，但我们发现它没做侧信道防护——用示波器夹住USB-C接口的VBUS线，在配对瞬间能清晰看到密钥生成过程中AES S盒查表引发的电流毛刺，傅里叶变换后直接还原出前128位。这是我们在东莞松山湖实验室测的，设备序列号范围：HBNXT-202511-BK0882至BK0895。可惜没来得及写进正式报告，因为12月20日鸿蒙团队突然宣布该模块暂不开放外部审计。

　　我的主观判断是：现在90%的物联网安全测试还在用Web思维套模型，比如执着于SQLi或XSS——可当你面对的是固件里用汇编写的状态机，或者靠压电陶瓷片震动频率反推用户步态的传感器，这种路径完全失效。我们团队上个月在杭州某儿童手表项目里，故意把IMU采样率调高到400Hz，结果发现运动轨迹数据上传延迟从平均120ms暴增到2100ms，进而触发云端AI模型误判为“跌倒事件”——连续推送17条虚假报警。没人教过怎么测“误触发阈值漂移”。

　　继续用JTAG调试器扫国产Wi-Fi6模组。

　　我打算下周约虹软的工程师喝咖啡，他们刚发布的AR眼镜SDK文档里提到“本地人脸特征向量永不出设备”，但我用adb shell进入/data/misc/arcsoft/cache发现，每次识别后都会留下一个.tmp文件，十六进制查看，头两字节是0xFF 0xD8，分明是JPEG缩略图——也就是说，原始人脸图像曾被明文缓存。这事我没报漏洞平台，先自己留着。

　　下次测试得带信号屏蔽帐篷去。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!