More MiFit 2 app analysis

Xiaomi Mi Band 2 data collection and bluetooth fun

After losing my Mi Band last year I waited the release of the Mi Band 2, which I now use for a few months.

Like I did for its previous version I tried to have a look at the data Xiaomi decided every Mi Band user should give out.
The Mi Fit app reached version 2.x but the quantity of data collected remains the same.

This time I found out this awesome project called Androlyzer that does static analysis of Android APKs installed on your smartphone and lists all the app’s detailed permissions, URLs contacted and APIs used to give you an overview of the privacy leaks generated.
You can see the results on the project’s site

However I fired up my Burpsuite proxy anyway to double check the app’s actual behaviour.
My setup was:
• Burpsuite on a Kali Linux VM configured as a proxy with interception on the local wifi network (with self-signed certificate)
• the wifi connection on Android 6.0 configured to connect to the proxy
• NetGuard firewall to filter the other app’s connections
• Mi Fit app v.2.1.9
• Mi Band 2 firmware 1.0.0.39

I did not see connections to every URL indicated on the androlyzer report, since many of them belong to older versions of the Mi Band, since the Mi Fit app is the same for the versions 1, 1s and 2.

The URLs I found matching are the following:

pingma.qq.com
Tencent QQ is an instant messaging service, China-based. Its logo is the penguin we see as one of the default icons on the Mi Band 2.
The request is to the port 80 with no SSL/TLS and looks like:

POST /mstat/report/?index=1477342937
[...]

with indexes that are incremental numbers. The content is encrypted with RC4 so we can’t understand its meaning, but the requests happen quite often, so I guess it’s some sort of ping/update for the IM client status.
From some research I did online seems that it’s the Wechat SDK that needs this channel for data gathering.
By the way, this obfuscation of the content makes me suspicious.

api.weibo.com
Weibo is China’s Twittter, and again its logo is the eye in the default icons. As above, I guess this REST API connections are needed for wechat notification purposes.

hm.mi-ae.com, resolver.gslb.mi-idc.com, mibind.chat.gslb.mi-idc.com
These domains are linked with the Mi account every Mi Band user has. The most part of the data collection happens within the borders of the Mi personal account, and so within the (damned) License Terms Agreement.
However the connection to mi-ae.com happened in proper SSL/TLS, rejecting self-signed certificates.
The other requests looked like this:

GET /gslb/gslb/getbucket.asp?ver=3.0&type=wifi&uuid=0&list=app.chat.xiaomi.net%2Cresolver.gslb.mi-idc.com HTTP/1.1
User-Agent: Dalvik/2.1.0 (Linux; U; Android 6.0; ZP951 Build/MRA58K)
Host: resolver.gslb.mi-idc.com
[…]
POST /mibind/http-bind?t=640 HTTP/1.1
X-Content-Sig: iLbkB4fFTl7BqLzr%2Fz83TmgmxxU%3D
Connection: close
Content-Length: 128
Content-Type: application/octet-stream
Host: mibind.chat.gslb.mi-idc.com:80
[…]

The strange thing of the connections from the WeChat SDK is that they happen even if no wechat account is configured and no client has been ever configured on the device.

Bluetooth fun

I analyzed the bluethooth hci logs from the Android developer options with Wireshark without finding anything interesting.
Also, no information leaks to a client connecting to the Mi Band, even if the MAC address is known (or spoofed).

So I decided to do a PoC of an hypothetical malicious app sending arbitrary alerts to the Mi Band.

With the great nRF Connect tool from Nordic Semiconductor I arranged a GATT (Generic ATTributes) server replicating all the bluetooth services of the Mi Band, and managed to send specific commands to the bracelet.
If your Mi Band is associated as bt device in Android (to use it in Smart Lock for example), you can see it listed in the nRF Connect “Bonded” tab.
Tap connect and a Mi Band 2 device tab will open.

On the menu near Disconnect tap Clone device’s services and save.
Then from the main menu go to Configure GATT server and from the top choose the configuration you just saved.
Now there’s a Server tab showing Device Information strings and all the bt services.

Reading these attributes can be useful if you need detailed info on your bracelet that are not listed in the information screen of the Mi Fit app, like the hardware and firmware version and the serial number.
The UUIDs are automatically decoded (if known) from the GATTs in the BLE specs .

Now from the Client tab you can choose the Immediate Alert service and send a value of 1 for a Mild Alert, select Command in the Advanced field and feel your bracelet vibrate with a notification icon!
An High Alert corresponds to an incoming call notification.

The lesson is: beware for the apps with bluetooth permissions, because with a Mi Band associated they can wake you up in your sleep…

Conclusions

I have to recognise that many things got better with this new version of the Mi Fit app: at least the communications with the Mi account servers happen in SSL/TLS and the License Terms Agreement is readable in english.

However, so much data about the device is still collected by Xiaomi and partners, especially through the WeChat SDK that is built-in in the app.
This third party services (like Google Fit as well) should be opted-out by default, because they’re only collecting data of the device without giving any service to the user.

As usual, my advice is to analyze the traffic outgoing from your device with a tool like NetGuard firewall and block the domains you find suspicious from /etc/hosts or through some kind of firewall or blocking VPN.