Vietnam's contact tracing app broadcasting a fixed ID

Prologue

Bluezone (Android, iOS) is a Bluetooth-based contact tracing app sponsored by the Government of Vietnam and developed by a coalition of local tech companies and the Ministry of Information and Communications.

The developers claim that the app is designed to alert people who may have come in contact with the virus while keeping their identity anonymous. The Android and iOS apps were released a few days ago, and according to the official tally they have attracted more than 150,000 users (last update April 30th 2020). The media quoted a top official touting that Bluezone is a breakthrough because it allows the government not to collect people's information and is able to solve the basic errors in similar apps from other countries.

Needless to say, Bluezone piqued my curiosity. I want to know it works. The developers pledge to open source the app, but they actually haven't released neither code nor documentation. I break software professionally, and decided to send them a note offering my service pro bono, if they could give me early access to the design or something. I also suggested that they should consider open solutions such as DP3T. They said thanks, but didn't send me nothing.

When the app was released Thursday, I downloaded and reverse engineered it. I found terrible vulnerabilities. I wrote a report and shared with the developers, urging them to use DP3T. I also published a summary without too many details on my blog to alert my community. The developers published a rebuttal basically calling me mistaken. They didn't send me a copy.

Below is my report which includes a rebuttal to their rebuttal.

--

The report

1/ First of all, Bluezone assigns each installation a fixed 6-character ID, and broadcasts it over and over again. I've spent a majority of my waking moments in the past two weeks studying secure and private contact tracing technologies and to the best of my knowledge, Bluezone is the only app doing this. Needless to say, this puts users at grave risks, as it leaks their location, movement, or social graph, etc. to whoever's watching.

In their rebuttal, the developers said they don't think changing the ID can improve user privacy because the Bluetooth MAC address is constant anyway. This is not true.

Bluetooth has two sub standards: Bluetooth Classic and Bluetooth Low Energy. A Bluetooth Classic device can be either discoverable or non-discoverable. When it is discoverable, it broadcasts its MAC address, device name and other information. But when it is non-discoverable, it doesn't broadcast anything. For privacy, neither Android nor iOS is discoverable by default. Phones are discoverable if and only if the Bluetooth System Setting app is running in the foreground, i.e., only when users want to pair with other devices.

Both Android and iOS also randomize the MAC address when broadcasting BLE advertisements. On Android, experiments by various groups show that restarting BLE advertising causes the OS to choose a new random MAC address. On iOS, experiments by a friend of mine and in this paper show that the OS automatically chooses a new random MAC address every hour or so.

I don't blame them for this confusion. I was confused myself when I thought Android and iOS expose APIs allowing apps to change the MAC address however they see fit.

2/ To add insult to injury, the fixed 6-character IDs are predictable.

This is how they are generated:

var generateUserId = function() {
      var t = '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ',
      n = t.length,
      o = '';
      Math.seedrandom(new Date().getTime());
      for (var s = 0; s < 6; s++) o += t.charAt(Math.floor(Math.random() * n));
      return o;
  }

It uses this seedrandom library which always generates the same output when seeding with the same value. In this case, the seed is the current timestamp. The app fell victim to one of the classic blunders in practical crypto software security. Pro tips: if you are to design a PRNG and let your users choose their own seed you may as well just return 4.

Anyways, this means all past and future IDs are predictable. The developers rebut that the timestamp is unpredictable because it has a millisecond precision. This is missing the forest for the trees. While it may be a bit difficult to guess the ID assigned to a particular person, there are many ways to exploit this weakness at the system level. A few examples from top of my head:

- An attacker can generate all possible IDs and broadcast them everywhere. He can also target a group of users, who he knows installed the app in some particular time frame.

- After generating an ID, the app attempts to register it with the server. It generates a FCM token and associates the ID with the token. I bet that the server uses this to send infected IDs and other notifications to the app. If the registration fails because the ID already exists, the app doesn't generate another ID and try again. Because I can predict all future IDs, I can preregister all of them. This is a denial of service attack, denying all future users to participate in this system.

3/ Acute readers probably have noticed that the IDs are too short! There are only 36^6 ~ 2^31 IDs. Because of the birthday paradox, if 65K people use the app, two of them will be assigned the same ID with high probability. When so, if a person is declared infected, the other is also too! At the current growth rate, I think the first collision will happen within 2 weeks.

The developers rebut that they've ensured that no collision is going to happen, regardless of the probability.

Because the app tries to register the ID with the server, it's possible to handle collisions, by checking whether the ID already exists on the server database. I don't think the Android app is doing that (I haven't looked at the iOS app).

The developers also claimed that their system can solve a problem that many other teams around the world can't. That is, they can prevent abusers from replaying IDs collected at a hospital. How? Users can optionally upload their observed IDs to the server. Wait, what? This is contradict to the "no data collection" claim. You don't want to upload observed IDs to the server.

4/ The app backups to Android's public storage (a.k.a external storage) the database of all observed IDs and the MAC address and the device name of observed Bluetooth classic devices (yes, it also scans for them -- this is the source of the confusion in #1?). This means, information correlated to the user's location, movement and social graph is accessible to other apps installed on the phone that can read external storage. If the backup database is used by health authority to determine who to quarantine users can easily falsify exposure records.

In my initial report, I didn't know that they did this but I still flagged the external storage permission request because I don't think a contact tracing app needs access to photos, media and files to do its job. This is the principle of least privilege.

They rebut saying that requiring external storage access is not a security issue, and expressing surprise why a Google engineer doesn't know external storage is where Android stores photos, media and files. Well I flagged the permission request exactly because I *knew* external storage has sensitive information.

The app also requires access to fine-grained location information. Now, this is something I didn't know. I flagged this permission request, but it turns out that for privacy Android requires the ACCESS_FINE_LOCATION permission if an app wants to use Bluetooth.

--

Epilogue

The boss of the developers emailed asking me to help secure the app. I said I'd love to, if they move development to GitHub. This is what they've pledged since day one. The boss said they're going to upload today, but I haven't seen it yet. Stay tuned for more fun!

Update: fix some typos and remove unnecessary languages.

Update: fix more languages. The app now has 150K users. The good news is the growth rate has slowed down. My friends and I have filed several bugs on the app's GitHub page, but got zero response so far.

(Discussions on Hacker News)