The Key to Preventing Mobile Fraud? Build a Secure App

Prevent Mobile Fraud in iOS and Android apps

Ever hear the sports metaphor ‘the best offense is a great defense’? It applies to mobile apps too. The best way to combat mobile fraud is to prevent it from occurring in the first place. And that means making your mobile apps more secure from the get-go, and including security as an integral part of your app lifecycle. In this blog, I will provide some best practices on how to prevent mobile fraud by building mobile app security into the app. The best part of this, every best practice provided in this blog will have the following traits:

1. Quick, Easy, and Automated — allowing developers, DevSecOps or DevOps groups to build secure apps at any point in the existing app lifecycle
2. No code or coding required
3. Works with every app & every app development framework—— native, hybrid, progressive, cross-platform — all app development frameworks
4. It’s instantly buildable and verifiable

The Register reported in September 2019 that a large Canadian bank suffered a major security leak of “among other things, software blueprints and access keys for a foreign exchange rate system, mobile application code, and login credentials for services and database instances.”

The publication reported that “among the hundreds of files of documentation and code, which appear to have been created by developers working on versions of the Scotiabank’s mobile apps for Central and South America, were credentials and keys to access some of the bank’s backend systems and services dotted around the world. Among the more sensitive blueprints was code and login details for what appeared to be a SQL database system of foreign exchange rates.” Jason Coulls, the IT professional who discovered the leak, referred in the article to the bank’s security as “Muppet-grade.”

How does Mobile Fraud Happen in the first Place?

­Security breaches can originate from a myriad of mobile threat vectors.

The Scotiabank breach occurred via GitHub, which by itself was shocking. Still, what this breach shows is even more telling. Critical data like mobile app source code, credentials and keys to access the bank’s backend systems and services are in the clear, not just on GitHub but in the app itself.

If the famous Muppet, Kermit the Frog were a security expert; he would agree that mobile security is not easy.

Why? Mobile apps can be attacked in a myriad of ways, and securing apps by hand-coding takes too much time and often takes a backseat to new app features.

The best approach to mobile security is a layered mobile defense that comprehensively covers the multiple areas that are susceptible to attack. While Scotiabank’s breach was discovered “where they stored their code,” the same information is already out in the wild in every public app published without in-app security features.

There are 4 key reasons why a mobile app is susceptible to mobile fraud and also the specific techniques that hackers use to execute mobile fraud — with surprisingly little effort:

1. Mobile apps operate on public, user controlled devices. This means that developers don’t control the device or the connections the app uses.
2. Your security model doesn’t support all frameworks your choice of development frameworks: Native apps are written in native languages like Swift/Objective C for iOS or Java/Kotlin for Android. They use native libraries to access OS controls and functions which are bespoke to the underlying mobile OS. Non-native apps (ie: hybrid apps or cross-platform apps) are built differently and they function differently. For example, developers build non-native apps in frameworks like React Native, Xamarin, Cordova, Flutter, using non-native programming languages (like Javascript, HTML5 or CSS and C# in the case of Xamarin). Each of these frameworks requires a different approach to secure Android and iOS apps. Most security vendors simply don’t work (or work well) with all of these frameworks, especially if your security solution requires manual coding. The security vendor must deliver support for each framework ‘one framework at a time’, which requires the developer to implement that security in the same patchwork way.
3. Your mobile app uses 3rd party libraries, SDKs and other components which represent new attack vectors that you have no control over. Third-party libraries, plug-ins, SDKs, and APIs are not your code. When you add a 3rd party component to your app, you inherit all the bugs and security vulnerabilities that are in those 3rd party components, but at the same time, you have limited (or zero) control over fixing those vulnerabilities, because you don’t have access to the code. Hackers know about these vulnerabilities, because it’s their business to know it (plus all it takes is a scan of your app and a Google search, and if you’re not obfuscating all your code it’s all up for grabs inside the app). And this opens up new security holes that hackers can exploit.
4. Your mobile app isn’t protected by the basic security measures. Every app should have the basic protections for the app, users and user data. These basic protections include encryption, obfuscation and app hardening/shielding (like anti-tampering, anti-reversing, anti-debugging). Those are the table-stakes of a reasonable app defense.

Hackers are very well versed in exploiting all the above and they use automation all the time to do so.

Recommendations for Mobile App Developers

The key lesson I learned, and one that all developers should take away from the Scotiabank example is that “ if your data and source code are valuable enough to protect in GitHub, that data and source code is valuable enough to be protected in your app. “ This is the Golden Rule that every developer should follow.

The top 4 ways to keep build Fraud-proof apps:

1. Implement basic measures like Anti-tampering, debugger prevention, and Jailbreak/rooting detection.

2. Encrypt all the data in your app — including user data that sits inside app preferences, inside resource folders, and in the code itself (in strings.xml for example). All mobile apps contain monetizable data, and that’s what attracts hackers.

3. Protect data in transit — don’t assume TLS transport has you covered. There are dozens of ways for attackers to insert themselves in the data path. PKI is not fool-proof, certificates are not hard to forge, and mobile users sometimes let their guard down, which is why phishing is experiencing a renaissance in mobile.

4. Obfuscate your code (both native and non-native elements). Don’t forget to scramble your control flows or create arbitrary/random code paths as a way to make your apps harder to reverse engineer. Remember, developers use the same tools you do — except for much different purposes.

5. Add another factor to your authentication — preferably one that uses biometrics. But whatever you do, make sure you’re not introducing operational complexity or user confusion into the mix as that may be self-defeating.

If you’re ignoring security or cutting corners because the app’s gotta get out fast, it’s only a matter of time before luck runs out. And once you lose the trust of your users, they usually don’t come back. Automate mobile app security and make it part of your mobile app lifecycle — security needs to be continuous, otherwise you might as well not even bother.

Here’s a free piece of content to get you started on why security is important, and to dispel popular mobile myths: Developer’s Guide for Mobile App Security.

Ciao!

Originally published at https://www.appdome.com on July 4, 2020.