With the release of the COVIDSafe app on Sunday afternoon, I’ve opted to take a bit of a dive into the application and its functionality over the past few hours, the late time of this writing courtesy of redoing and rooting a Nexus 5X to get this experiment working.
This evenings activity consisted of the following lab environment:
1- a nexus 5X, our main test environment, rooted with bluetooth logging turned on.
2- an iPhone 7, to act as an additional client.
3- an instance of Kali conducting a person in the middle attack as a WiFi access point using an alfa card. Bettercap was also installed here for bluetooth analysis with CSR 4.0 bluetooth dongle to interact with the bluetooth interfaces.
Over the wire- whats occurring on the web server
Attempts to analyse the HTTPS traffic were a bit of a challenge due to the cert setup on the device, however I can at least attest everything I’ve seen so far is going over TLS to AWS servers with a variety of covidsafe.gov.au certs. a few of the test environments appear to be commented out in the APK as well.
I’d tried recompiling the APK file with modifications to allow passive interception, but this did not work after half a dozen attempts. I moved onto bluetooth interaction.
This appeared to be the more interesting element of the covidsafe app. The app introduces a single service with a characteristic (b82ab3fc15954f6a80f0fe094cc218f9) which presents a static value structured as shown below:
The MSG is a unique 120 character parameter that is set to the app and remains static and accessible without any authentication by the interrogating device.
The characteristic is also presented as having READ WRITE Properties, however I have not been able to write over the values on my test devices.
2x interesting directories were observed:
- /data/data/au.gov.health.covidsafe/shared_prefs/Tracer_pref.xml Which sets a number of settings such as postcode, age (possibly range), & phone number. Another setting in this file appears to be a 2 hourly update, no doubt to see if a reported “positive” person has been in contact with the person who owns the phone. These values are stored in clear text and, if its an individual users device, would be reasonably well known.
- /data/data/au.gov.health.covidsafe/databases/ which contains the database. Contents include a date (for each time the device was identified), MSG, device used & RSSI. The database also appears to identify when the device in use is or is not scanning by time. Interesting to note that GPS was not in the dataset I had.
A scan appears to occur every 10 seconds according to the database.
I have not made any attempts to decrypt the MSG values contained within the database (in accordance with https://www.health.gov.au/using-our-websites/privacy/privacy-policy-for-covidsafe-app).
Is there a risk?
Right now, and without permission to conduct “active” testing, I can only hypothesise actual risks. I’d be interested to see if any threat modelling considered one of the following attack scenarios:
- placing multiple instances of the same characteristic throughout the city as a nuisance. This same tactic could be employed to track outbreaks or undermine the confidence of the system.
- Injecting untrusted inputs via bluetooth to recipient devices (which could be subsequently injected into the AWS database).
- Rewriting the characteristic (if possible).
Capability and intent for exploiting this issue I believe would largely be limited to issue motivated groups as opposed to anything practical, however I’d be happy to see if anyone has any other thoughts or ideas.
The real risk however is if individuals leave the app turned on after it is no longer used. iPhones & Androids when up to date and patched are alot harder to track over bluetooth and this simply lowers the barrier to such an activity.
I also note that I have not been able to qualify if the MSG is associated with an individual user within the AWS environment and what data has actually been sent.
Its 4am and its been a while since I’ve dived down a rabbit hole like this. I might have another look later this week.