Prevent Mobile Fraud in iOS and Android apps
The best way to combat mobile fraud is to prevent it from occurring in the first place. And that means making your app more secure: from the very beginning or as part of the app’s 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:
- Quick, Easy, and Automated – allowing developers, DevSecOps or DevOps groups to build secure apps at any point in the existing app lifecycle
- No code, No source code, no development required
- Work across all app types – native, hybrid, progressive, cross-platform – all app development frameworks
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? Because the attack surface of a mobile app is so vast and diverse, usually mobile app security falls behind features needed in the app.
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 your mobile app is susceptible to mobile fraud and also the specific techniques that hackers use to execute mobile fraud:
- Your mobile app operates on public devices (known as zero-trust environments). This means that developers don’t control the device nor the connections the app uses.
- Mobile fraud technique: Account takeover, Fake WiFi, Screen Overlay, Fake or Malicious proxy, credential harvesting (followed by credential stuffing), MiTM attack, Phishing, Pharming, modified or Fraudulent certificate, TLS version attack. I could go on for days.
- Your security model doesn’t support 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, Maui, Xamarin, Cordova, Flutter, using non-native programming languages (like Javascript, HTML5 or CSS and C# in the case of Maui, 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.
- Mobile fraud technique: Cross-site scripting as a means to hi-jack sessions, code injection, database infiltration (via SQL injection). All of the following are preceded by Reverse engineering (static and dynamic code analysis, debugging, running your app on simulator/emulator). The reason hackers do this is to learn how your app works. Once they know your app is a hybrid app, they will use all the best techniques they have used for years to attack web apps (because hybrid apps are effectively web apps inside, wrapped in a native shell).
- Your mobile app uses 3rd party libraries and other components. 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.
- Mobile fraud technique: SDK Spoofing, Click-fraud, Ad-fraud, card skimming, Scan your app > followed by a search in Mitre’s public CVE database for known security vulnerabilities in whatever component you use in your app.
- 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).
-
- Mobile fraud technique: Fake app, tampering, disable security protections, defacing, create ‘mod’ of your app, re-sign your app, redistribute your app on overseas app store and monetize on it, steal your IP, copy your source code, sell your source code, sign other mobile certificates on your behalf, pirating, SDK Spoofing, Jailbreaking and Rooting, etc. Hackers can even disable SDKs from your favorite security vendor. How? If your code is not protected, then a security SDK will do you no good because anything in your code can be changed if the security model is compromised and if you have not taken comprehensive measures to protect your app, your data and your code.
Hackers are very well versed in exploiting all the above and they use automation all the time to do so. For example:
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 Appdome Mobile Security Suite provides developers with an instant no-code solution to follow this Golden Rule and prevent mobile fraud from occurring in the first place:
- TOTALData Encryption encrypts data-at-rest, data-in-use and data-in-transit encryption.
- TOTALCode Obfuscation obfuscates the binary code, native and non-native libraries, and the app’s flow control and logic.
- Secure Communications protects data at all points that are ‘in-transit’ and ensures the validity of all endpoints and any intermediate systems in between an app and its backend.
- OS Integrity protects the app from operating in unsafe environments, such as on Jailbroken/Rooted devices.
- ONEShield by Appdome hardens the app to protect your IP from attempts to tamper with or reverse engineer the app.
By protecting your mobile apps with Appdome Mobile Security Suite, mobile app developers and non-developers can use a non-cascading, multi-layered defense to protect against any security threat their apps can be faced with. Learn more in the Developer’s Guide for Mobile App Security.
And it can be implemented in minutes, or fully automated and integrated into your DevOps and CI/CD workflows. And you don’t need to write or modify a single line of code to build mobile fraud protection directly into your app.
