小米IoT私有协议的漏洞挖掘尝试(五)

通过上次抓包获得的http明文,可以确定报文与域名dns.io.mi.com进行了通信,在IDA里搜索字符串,定位到相关函数:

QQ20261005-134047.png

不难看出这是在根据a5试着构造不同的域名或者主机名,并进一步构造url。

在该函数靠下的位置还发现了硬编码的证书,用base64进行了编码:

QQ20261005-134104.png

还原之后可得:

证书 1

项目值
SubjectC = US, O = DigiCert Inc, OU = www.digicert.com, CN = RapidSSL RSA CA 2018
IssuerC = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
Serial08A5A246CD4B5C8C83D702B4BBAB5349
指纹sha256 Fingerprint=C7:90:B4:71:28:44:7E:C0:B6:0F:22:BF:CB:79:5D:71:C3:26:DD:91:0E:E1:2C:BB:4C:C5:A8:61:91:EB:91:BC
生效Nov 6 12:23:33 2017 GMT
失效Nov 6 12:23:33 2027 GMT
算法rsaEncryption

证书 2

项目值
SubjectO = Mijia Root, C = CN
IssuerO = Mijia Root, C = CN
Serial03F50A60
指纹sha256 Fingerprint=0E:FA:59:BD:96:91:70:14:91:36:A4:94:C7:35:D2:FA:BA:D3:BD:DF:28:34:5C:0D:34:35:E9:B3:37:BE:8B:BE
生效Nov 23 01:39:45 2016 GMT
失效Nov 11 01:39:45 2066 GMT
算法id-ecPublicKey

俩证书包含的都是公钥,是跟小米云通信时认证身份用的,而且发包时是http明文,没有使用https,证书的意义不大。

在构造url时进一步dump,得到的结果也证实了这一点:

QQ20261005-135820.png

这里是在v27被strcmp赋值时下断点,可以看到x0寄存器存储的是0,也就是说,构造url时也是http。

已知这是一个基于http的dns服务,所以我可以考虑去研究一下它接收报文后的处理逻辑,找一下是否可能存在云主机认证不严的缺陷,通过伪造特定的包来完成dns欺骗,让它把同一局域网下的其他设备错认成云主机。

评论