Minor user interface updates are prioritised over privacy issues

If you spot a spelling mistake, grammatical error or inaccuracy please help improve the senate submission by editing this page. Small fixes, over time, add up to huge improvements. Thank-you 💕

Submission Name: Minor user interface updates are prioritised over privacy issues
Url: https://covidsafe.watch//senate-submissions/minor-user-interface-updates-are-prioritised-over-privacy-issues
Status: Submitted, pending confirmation of receipt.
Version: 5416860c24987a6b241515b36b6268c003d03448 on https://github.com/covidsafewatch/website

Select Committee on COVID-19

Terms of Reference

On 8 April 2020 the Senate established the Select Committee on COVID-19 and referred the following matters to it for inquiry and report on or before 30 June 2022:

  • the Australian Government's response to the COVID-19 pandemic; and
  • any related matters.


To members of the Senate Select Committee on COVID-19. Thank you for the opportunity to participate in this Senate inquiry. Below you will find a submission related to the COVIDSafe application. We are doing seperate submissions on a per-topic basis to optimize for your reading experience.

Members from the https://covidsafe.watch/ community are available to give in-person evidence to future public (or private) hearings by video conference.

We would appreciate a confirmation of the receipt of this submission and welcomes any feedback you may have.

https://covidsafe.watch/ is an online community backed by a team of security researchers, open-source software engineers, community managers and privacy specialists that support the concept of technology based contact tracing.

  • We want to see lives saved through the use of this unprecedented technology.
  • It is crucial to us that privacy and security issues are addressed promptly and communicated in an inclusive and open manner.
  • We believe transparency is essential to achieve both of these goals without compromising either. Compromising privacy risks people’s lives by undermining public trust in the systems built to protect them.
  • This can only be achieved by direct collaboration with engineers using transparent open source platforms as done by the UK National Health Service.

Experts available for in-person evidence

Geoffrey Huntley

🙌 I'm Geoff, the probono open-source software engineer leading the independent analysis of covidsafe via studying the source code. Software that I maintain is inside Microsoft Visual Studio, GitHub, Atlassian Sourcetree, Amazon Drive, Halo, Slack, is heavily used by the financial services industry and has been installed by other software developers over 21 million times.

Photo licensed under Attribution 4.0 International (CC BY 4.0)

Jim Mussared

I'm a hybrid hardware and software developer, with current professional experience with open-source development and designing/developing BLE-based products for George Robotics. Formerly worked in programming/electronics education at Grok Learning, and before that at Google Australia as a tech lead in the SRE team as well as some time working with the Android team.

My Bluetooth research into contact tracing has received world wide praise. I discovered a Bluetooth security vulrunability (CVE-2020-12856) which requires governments to modify their technological approaches and programs of work.

Photo licensed under Attribution 4.0 International (CC BY 4.0)

Richard Nelson

I'm a professional software engineer of 16 years, 8 of which have been in mobile app development and leadership. I have a strong interest in infosec, and my research into the iPhone application background behaviour identified a coding error as a contributing factor preventing COVIDSafe from working effectively. I discovered a denial of service vulnerability (CVE-2020–12717) in COVIDSafe.

Photo licensed under Attribution 4.0 International (CC BY 4.0)

Contact person(s) for this submission

Technical Expert & Coordinator

Name: Geoffrey Huntley
Email: ghuntley@ghuntley.com
LinkedIn: https://www.linkedin.com/in/geoffreyhuntley


Minor user interface updates are prioritised over privacy issues, with the justification of "sprint planning". This is not how "agile software development" is supposed to work.

When it comes to knowledge work, the type of items that teams get to work on varies in urgency, requirements, perceived business value and level of priority.

For example, a software development team has just gone live with their application. The team is now expected to work on both enhancements and maintenance work. At the start of the workday, they are scheduled to work on features for a planned release version and a few minor production issues. Midday comes and a security vulnerability has been reported, putting client data at risk. The team focuses attention to the production issue and works on it immediately. If this affects the teams work capacity, other work items might be halted to address the critical issue.

This is much similar to the medical triage concept being used in the emergency department of hospitals. The triage nurse assesses each patient that arrives. Based on the severity of their condition, the triage nurse determines the order of patient treatment. A patient suffering from cardiac arrest will be considered a higher priority than a patient with a tummy ache.

Establishing a set of rules that govern how incoming work is treated enables teams to work in the best interest of the customer. Teams will also decrease the amount of time a task remains in the backlog.

From: https://kanbanzone.com/resources/kanban/classes-of-service/

Branding instead of resolution of privacy policy breach

Initially Geoffrey Huntley was supportive of the application but publically withdrew his support after the first update (v1.0.15) of COVIDSafe was released as the privacy breaches were not resolved and the update primarily focused adjusting the application branding.

Geoffrey Huntley, a security researcher who with colleagues and acquaintances has decompiled the app’s Android .APK and observed the iOS app running with a debugger, told The Register he has found a flaw in the app’s use of unique identifiers that retains one value instead of making a change every two hours. He also said the app’s Bluetooth implementation makes it possible to read device names with a Bluetooth beacon.

Australia’s app uses some of Singapore’s open source contact-tracing code. Huntley said he found flaws in Singapore’s code, reported it to developers there and saw changes made on the same day. He said he’s since informed Australian authorities of the same problem and seen it left in place in an app update that he said has changed nothing of substance. His research and opinions are detailed in this Tweet and subsequent thread.

From: https://www.theregister.co.uk/2020/05/07/covidsafe_australia_contact_tracing_app_issues/

Issue 1 - CVE-2020-12857

The first issue is that the COVIDSafe app caches the characteristic value that will be read by a remote device using the MAC address of the remote device. Due to a logic error, this cache is only cleared when a successful transaction takes place (i.e. the remote device subsequently writes its own payload back to the characteristic). Importantly, the cache entry is not removed when:

  • The two-hour expiry finishes for the TempID
  • After any sort of short time limit.

This means that a remote device using a static address that never completes the transaction will always see the same cached TempID. This cached value will last until the app is restarted (likely due to a phone reboot).

This is a breach of the privacy policy which states:

An encrypted user ID will be created every 2 hours. This will be logged in the National COVIDSafe data store (data store), operated by the Digital Transformation Agency, in case you need to be identified for contact tracing.

From: https://www.health.gov.au/using-our-websites/privacy/privacy-policy-for-covidsafe-app

This issue was first reported to privacy@health.gov.au at 1:19am on 27/04/2020, and subsequently by in-app feedback later that day. It was also reported to asd.assist@defence.gov.au at 4:52pm on 27/04/2020.

This issue was first reported to the Singapore OpenTrace team at 12:38am on 30/04/2020 and was fixed in this commit to the opentrace-android repository at 7:11pm on the same day.

This issue was fixed in v1.0.17 released on 14/05/2020.

Note on the fix: When this issue was fixed, instead of removing the cache, there was additional logic added to the disconnection event to remove the entry. I'm not aware of any way that this event can fail to fire, but it would have been far more robust and easy to reason about the fix if the cache had been removed altogether.

This issue remains unfixed on iPhones.

Issue #2 - CVE-2020-12858

The second issue is much simpler. The advertising payload is generated once at startup and used for the lifetime of the app. Due to requirements by the iPhone app, there are additional bytes included in this payload added to the manufacturer field. However, specifically in the Australian app, these bytes are generated once at startup, and then the same data is used continuously for the lifetime of the app. This means that the advertising payload will consistently identify the same device.

The OpenTrace app appears to behave in a similar way. See this function where the random data is generated and then appended to the manufacturer field, however this data is generated every time advertising is restarted (every 180 seconds). There is a small but crucial difference introduced in the Australian app where the data is then cached and used for the lifetime of the app. This is evident in the disassembly.

From: https://docs.google.com/document/d/1u5a5ersKBH6eG362atALrzuXo3zuZ70qrGomWVEC27U/edit

This issue was first reported via in-app feedback subsequently by in-app-feedback on 27/04/2020. It was also reported to asd.assist@defence.gov.au at 4:52pm on 27/04/2020.

This issue was fixed in v1.0.17 released on 14/05/2020.

Note on the fix: The implemented fix was just to undo the regression, the payload is no longer cached.

Issue #3 - CVE-2020-12859

The phone model name included in the OpenTrace JSON payload is weakly identifiable. There are enough different models of phones, that it gives a high probability of identifying someone, especially in non-crowded environments. If a house has three residents, each with a different phone, it would allow someone outside the house to trivially identify which of those people were currently at home.

Additionally, the fact that this information is exchanged is not mentioned in the privacy policy at https://www.health.gov.au/using-our-websites/privacy/privacy-policy-for-covidsafe-app

The use of this field in the payload is documented and designed into the BlueTrace protocol, so this is not specific to the Australian app. The reason it is included is for calibration of signal strength to physical distance, however it is likely from my own experiments that this calculation does not actually work.

Example values are "Pixel 2", or "Galaxy G8".

From: https://docs.google.com/document/d/1u5a5ersKBH6eG362atALrzuXo3zuZ70qrGomWVEC27U/edit

This issue was first reported to privacy@health.gov.au at 1:19am on 27/04/2020, and subsequently by in-app feedback later that day. It was also reported to asd.assist@defence.gov.au at 4:52pm on 27/04/2020.

It has not yet been fixed.

Issue #4 - CVE-2020-12860

A BLE device can be any combination of the four roles: Advertiser, Peripheral, Scanner, Central. Typical combinations are:

  • Advertiser-only (a beacon)
  • Advertiser+Peripheral (a device like a heart rate monitor)
  • Scanner (phone app, looking for beacons)
  • Scanner+Central (phone app talking to a device)

COVIDSafe runs in a fairly unique "all of the above" configuration.

When you are a peripheral, you must also be a "connectable advertiser" -- that is, you must advertise, and set the advertisement type to "connectable" -- and then you run a GATT server.

A peripheral must include a set of services containing characteristics and descriptors (the COVIDSafe service is described above). There are several generic services that contain characteristics with useful metadata about the device. One example is 0x1800 "Generic Access" which contains 0x2a00 "Device Name". On iPhones, there's an additional service 0x180a "Device Information" which contains 0x2a24 "Model Number String".

The device name on Android is set by the user. On most Android phones it appears to default to some variant of the phone model, either exactly, e.g. "Samsung Galaxy S7" or "My new Pixel 2". In this sense it's very similar to Issue #3 but might provide further uniqueness in combination.

However, many people do something like "Jim's Pixel 2" as this is the string that shows up in for example a car hands free system -- "Connected to Jim's Pixel 2". I have even seen cases of "Firstname Lastname's Phone Model".

Normally, phones are not peripherals, so unless any app asks to be a Peripheral, there will be no registered services and the device will not be connectable. So although the existence of this data is actually leaked by the OS, unless COVIDSafe was running, the phone would not be connectable and this data would not be available. For most people, their phone never would have been connectable during normal operation, and certainly not in background operation.

Note: It's worth being aware of Apple bleee which was published in October 2019 which contains a very detailed analysis of what's available in the additional services registered by an iPhone, due to the AirDrop service, so in many cases this data was already accessible if Airdrop is enabled. However, COVIDSafe forces it for all phones, Android or iPhone.

Many thanks to John Evershed of ProjectComputing, who contacted me from a Facebook post I had written for my friends explaining how the COVIDSafe app works. He noticed in some of his own experiments that the device name he had assigned his iPhone was available when connecting to a peripheral which prompted both of us to look into this in more detail.

From: https://docs.google.com/document/d/1u5a5ersKBH6eG362atALrzuXo3zuZ70qrGomWVEC27U/edit

This issue was first reported to privacy@health.gov.au, ASD/ACSC, and Cybersecurity CRC at 4:30pm on 02/05/2020.

It has not yet been fixed.

Appendix - Timeline

Day Date Notes
0 26/04/2020 COVIDSafe app launched
1 27/04/2020 First long-term tracking issues reported to privacy@health.gov.au, ASD, Maddocks (author of the PIA). First reports of the app interacting poorly with other Bluetooth devices (e.g. Continuous Glucose Monitors).
2 28/04/2020 First four issues described in a single document that was distributed widely to the relevant teams (both through official and unofficial channels).
4 30/04/2020 First contact with Singapore OpenTrace team. TempID caching issue fixed same-day. The Singapore team confirms that iPhones in the background are “not expected to work”. ASD confirmed that they will “follow this up”. No further contact. The Cybersecurity CRC confirmed that they have forwarded this doc but are extremely dismissive of the findings. No further contact. Maddocks replied and promised to forward the doc. No further contact.
8 04/05/2020 First contact with DTA. v1.0.15 & v1.0.16 (Android) released containing only updates to graphics and animations and some minor text changes. The only issue fixed is the confusing wording raised by Geoff. risky.biz publishes a high-level summary of the known issues at this stage.
9 05/05/2020 v1.1 (iPhone) released. DTA confirms that they were first aware of the issues on 30/04/2020, but our contact still had not read the document. Full details of CVE-2020-12586 shared with the ASD/ACSC and DTA
10 06/05/2020 DTA CEO questioned by the Select Senate Committee on COVID-19. Topics include the iPhone background behavior and engagement with the tech community. Richard Nelson discovered the remote iPhone crash, reported to DTA.
12 8/05/2020 Source code of v1.0.16 (Android) and v1.1 (iPhone) released, confirming that there are no differences in the Bluetooth implementation to the upstream Singapore codebase.
13 9/05/2020 Same issues discovered in the ABTraceTogether app used by Alberta, Canada. Emailed, and Skype meeting arranged within 24 hours.
17 13/05/2020 DTA confirms that there will be a release tomorrow to fix the iPhone crash but it will fix none of the outstanding privacy issues.
18 14/05/2020 v1.0.17 (Android) and v1.2 (iPhone) released. Contrary to advice from the day before, fixes the first two privacy issues (along with the remote iPhone crash). DTA asked (via SMS to Jim Mussared) for availability to discuss fixes for CVE-2020-12586 in the next couple of days. Jim offered that they can call any time, but then they never followed through on arranging a time. No further contact received from the DTA, all follow-up emails ignored. (Edit: update after this doc was published, see below)
19 15/05/2020 Source code of v1.0.17 (Android) and v1.2 (iPhone) released.
20 16/05/2020 Source code of Alberta, Canada’s ABTraceTogether released. None of the issues raised on 09/05/2020 have been fixed.
21 17/05/2020 v1.3 (iPhone) released.
22 18/05/2020 Source code of v1.3 (iPhone) released. iPhone crash fixed in Singapore OpenTrace.
23 19/05/2020 Full details of CVE-2020-12586 shared with the Singapore & Alberta teams (and other affected countries).
26 22/05/2020 iPhone TempID expiry issue raised with DTA (and Singapore & Alberta).
29 25/05/2020 The The COVIDSafe App - 4 week update document was released publicly. 26 minutes later, update from the DTA with a planned release date for “the remaining Bluetooth issues”.
30 26/05/2020 v1.4 (iPhone) released and available to download, source code partially available same day but unable to compile as source code is missing. v1.0.18 (Android) source code released but Android application but not available to download from the app store.
32 28/05/2020 Submisisons for the Australian Senate Select Committee on COVID-19 close.

Appendix - Google Android Changelog

Version Date Comments
v1.0.11 2020-04-26 Initial Release. Implementation in serious breach of privacy policy. Contained text that caused public panic - "You have COVID19"
v1.0.15 2020-05-04 Brand new coat of paint and did not resolve privacy breach. Accidentally added 20 second pause to the launch screen.
v1.0.16 2020-05-04 Removed 20 second pause from the launch screen.
v1.0.17 2020-05-14 Partially resolves privacy breaches.
v1.0.18 2020-05-27 Source code released but application not available for download from the app store. Analysis pending.

Appendix - Apple iPhone Changelog

Version Date Comments
v1.0 2020-04-26 Initial Release.
v1.1 2020-05-05 Debug view removed, updated design and removed com.googleusercontent URLScheme.
v1.2 2020-05-14 Largely fixed background behaviour. Implemented the fix for CVE-2020-12717.
v1.3 2020-05-14 Removed daily notifications to remind users to keep app in foreground.
v1.4 2020-05-26 Application released, source code was partially published but unable to compile as files are missing. Analysis pending.