App development teams must look for resilient source code protection that not only obfuscates the source code to hinder reverse-engineering but that also adds runtime defenses to thwart copycats and lock attackers out.
The Department of Justice and the Federal Trade Commission have been issuing more scam alerts since the pandemic outbreak. Attackers are creating apps that use the same branding as official government apps and distributing these copycats via unofficial channels.
In June, Canadians were tricked into installing a fake COVID-19 contact tracing app that, despite being advertised as “Health Canada,” covertly installed ransomware -- encrypting the user’s files and demanding a ransom payment. In a similar fashion, 12 other fake contact tracing apps in South America, Europe and Asia were also found to be installing Trojan horses on users’ devices and stealing their credentials and other sensitive data.
But contact tracing programs are just an example of the many apps developed by both public- and private-sector teams that have been imitated or otherwise breached by attackers. Often, the app developers must meet very strict deadlines and may end up putting security on the backburner, intending to address it later.
Application security guidelines
Security is critical for any type of application that handles sensitive user information. Personally identifiable information is extremely valuable to attackers, and it takes just one security gap for an app to facilitate a huge data breach. For government apps, this can mean countrywide ramifications.
What can be done to ensure in-depth security? First and foremost, these applications -- and especially government-backed apps -- must always undergo strict independent security audits before being released. This process should start as early as possible in the software development lifecycle.
Development teams should follow well-established application security guidelines, namely the Open Web Application Security Project’s (OWASP) Mobile Security Testing Guide. This guidance describes several possible attack vectors and urges teams to make sure that the app isn’t vulnerable in any of its many fronts.
Another security concern is source code protection. When apps are released, their source code is typically shipped in plain text, completely exposed to the eyes of users and attackers alike. This by itself poses a significant security risk that is mentioned in the ISO 27001 information security standard, which states that “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.”
As stated on the OWASP Mobile Top 10 Security Risks guide, attackers can take advantage of exposed code to “directly modify the code, change the contents of memory dynamically, change or replace the system APIs that the application uses, or modify the application’s data and resources. This can provide the attacker a direct method of subverting the intended use of the software for personal or monetary gain.”
If attackers have easy access to an app’s source code, they can distribute dozens or hundreds of copycats via third-party websites or apps, tricking users into installing it by exploiting the branding of government agencies.
To counter this and other security liabilities, development teams must look for resilient source code protection that not only obfuscates the source code to hinder reverse-engineering but that also adds runtime defenses to prevent tampering to thwart copycats and lock attackers out.
With every passing day, attackers go further to grab valuable user data, so development teams must be aware of the huge responsibility in their hands. When it comes to government-backed apps and the private data of millions, no security risk is too small.