一.背景

此次是针对一款智能设备进行的审计，审计范围包含服务端、APP、硬件、固件。

二.发现的一些问题

作为一款新上市的设备，仍然出现了一些智能设备中常见的问题。

例如几个常见的漏洞

1，局域网访问设备存在弱密码，可以通过密码爆破的方式获得设备访问权限。

2，设备进行证书信任的方式是在云端获取可信任的证书列表作为根证书校验，但是更新获取可信任证书的HTTP请求没有使用HTTPS（设备固件内置一份可信任证书，但是更新请求没有使用HTTPS，应该是避免由于更新请求通过不了证书校验导致设备无法联网）

3，开放了串口，可以通过暴力破解登录设备

4，部分接口没有限制长度，导致可以传入伪造的数据，造成设备容易被局域网DOS。这个也是智能设备常见问题，在一些比较敏感的设备，例如路由器/摄像头上，这个问题容易造成比较严重的后果。

5，没有一机一密

6，局域网服务器容易被重放攻击。

只能说，智能设备整个行业的安全水位，距离web、云行业，还有相当的距离。也可以理解，毕竟智能设备行业里，还遗留着大量比较古老的架构，即便是大厂的产品，也有很多是ODM,OEM，而供应商的研发对安全的重视显然是不足的。

三.一个漏洞的细节

详细记录一个业务逻辑导致的漏洞。

设备的服务端提供了一个注册接口，大概的业务逻辑是传入设备序列号，返回一个设备的认证信息。请求大概如下

返回信息中包含以下几个字段：

device_name :request中传入的值，通过对比两个设备，device_name就是设备的序列号。

device_key:request中传入的值，device_key不同设备共用。

device_secret:这个是服务端返回的值，从secret可以猜测，这个值是一个类似token的作用。通过抓取设备的其他请求，印证了这一点，device_secret是另外一个请求的输入参数。

该POST请求依赖于请求Header中的token值，例如一次请求的token是

token: 06950e46d37c614750a73e751220396c9f11ce43

从这个长度来看，猜测是一个SHA1。具体逻辑，从请求和服务端无法作更多判断了，只能获知，目前的逻辑如下

1，register请求，输入参数中的token可变的变量是device_name，固定的变量是device_key，另外可能存在一个盐，加盐后进行sha1，生成请求的最终token

2，通过register请求，获取到device_secret，该device_secret每次请求都会更换，应该是服务端生成的，作为其他重要请求的token。业务上通过这种方式，实现一机一密，以及动态的token认证。

下面的主要工作是猜测,register请求中的token生成逻辑。

token可能来源于device_key，device_name，可能还存在一个秘钥，该秘钥如果是一机一密，则也无法被利用，但是如果是一型一秘，则可能存在漏洞利空的空间。

所以下一步就是从固件层面去分析了。

==================

略

==================

从固件层面的分析，我们获取token的生成是product_key+device_key+_device_name三个输入拼接后，加盐，进行SHA1生成的token。但是盐是写死在固件中的，可以获取。

所以现在我们获取了register接口的逻辑，可以用Python脚本批量跑出device_secret。而device_secert可以作为另外一个请求B的token,请求B的返回中，包含敏感数据。最终通过批量跑请求B，获取了其他设备的数据。

四.漏洞小结

由于获取device_secret的请求，没有有效的加密强度，因此可以通过遍历DeviceName可批量获取device_secret， device_secret可以作为敏感请求B的token使用， 攻击者可以利用这种攻击，获取批量用户的敏感信息。

问题出现的原因主要是请求的重要参数，被硬编码在固件中。并且该重要参数实际上是相同型号公共的。设备想采取接口请求的方式实现一机一密，但是实际上由于请求逻辑存在漏洞，攻击者可以通过遍历device_name的方式批量获取设备的token信息。