With pressure mounting for U.S. states to roll out COVID-19 contact tracing apps, the latest reports show that despite some states’ best efforts, we are still a long way from sufficient contact tracing.
Still, as health experts have stated time and time again, contact tracing is our best tool to slow down the pandemic until we have a vaccine. But rolling out statewide contact tracing programs may be just one of many problems. Several countries have released these apps but come under fire due to security and privacy issues. The apps provided in Bahrain, Kuwait and Norway have been found to be putting the privacy and security of their users at stake. Amnesty International actually labeled them as “dangerous to human rights” and “mass surveillance tools.”
But worries of surveillance states are just one of many bad things happening in contact tracing apps right now. In Qatar, a security flaw allowed attackers to access the name, national ID, health status and data of more than 1 million users of the official contact tracing app. In Asia, Europe and South America, at least 12 fake contact tracing apps have been found to be imitating official government apps and stealing users’ credentials and data.
As U.S. states look forward to ramping up the rollout of their own contact tracing apps, they have the chance to learn from all these exploits and ingrain strict security measures to prevent these attacks.
Contact tracing apps deal with extremely sensitive data and need to be treated as highly critical. To ensure that the app isn’t exposed to common attack vectors and exploits, these apps should always be subject to strict independent security audits prior to release.
But the actual security of these apps starts during the development phase. Development teams must follow application security guidelines such as those from the Open Web Application Security Project’s (OWASP) Mobile Security Testing Guide.
Some required security measures include code signing (to decrease the risk of illegitimate applications in the wild) and certificate pinning (to reduce the risk of man-in-the-middle attacks). Today, these practices are commonplace among development teams, but should nonetheless be recalled.
On the contrary, one frequently disregarded aspect is the actual source code of these apps. Typically, this source code is shipped in plain text, with no protection whatsoever. And today we know that this poses a security liability. As stated on the ISO 27001 information security standard, “Program source code can be vulnerable to attack if not adequately protected and can provide an attacker with a good means to compromise systems in an often covert manner.”
OWASP also sheds some light on this issue, explaining that attackers can exploit exposed code to subvert the intended use of the software for personal or monetary gain—or even use this as a gateway for more intricate attacks. This can be achieved not only by modifying the code but also by modifying the application’s data and resources, changing the system APIs that the application uses or changing the contents of memory dynamically.