Two years ago, I decided to conduct research in order to obtain a global view of the state of security of mobile banking apps from some important banks. In this blog post, I will present my latest results to show how the security of the same mobile banking apps has evolved.
Scope
My research included 40 mobile banking apps with the following global distribution:
The metrics I used for this research are the same as before:
- Limited to iOS platform
- Black box approach
- All tests were only performed on the app (client side); my research excluded any server-side testing
- This research does not describe the vulnerabilities I found or how to exploit them in order to protect the owners of the apps and their customers
- Some of the affected banks were contacted, and the vulnerabilities reported
Tests
I performed the following tests on each app:
-
Transport Security
- Plaintext traffic
- Improper session handling
- Properly validate SSL certificates
-
Compiler Protection
- Anti-jailbreak protection
- Compiled with PIE
- Compiled with stack cookies
- Automatic reference counting
-
UIWebViews
- Data validation (input, output)
- UIWebView implementations
-
Insecure Data Storage
- SQLlite database
- File caching
- Property list files
- Log files
-
Logging
- Custom logs
- NSLog statements
- Crash reports files
-
Binary Analysis
- Disassemble the application
- Detect obfuscation of the assembly code protections
- Detect anti-tampering protections
- Detect anti-debugging protections
- Protocol handlers
- Client-side injection
- Third-party libraries
I will present my results in two parts:
- Network and Logging Analysis
- Binary and File System Analysis
Network and Logging Analysis
12.5% of the audited apps did not validate the authenticity of the SSL certificates presented, which makes them susceptible to Man-in-The-Middle (MiTM) attacks.
35% of the apps contained non-SSL links throughout the application. This allows an attacker to intercept traffic and inject arbitrary JavaScript/HTML code in an attempt to create a fake login prompts or similar scams.
30% of the apps did not validate incoming data and were vulnerable to JavaScript injections via insecure UIWebView implementations allowing client-side attacks.
42.5% of the apps provided alternative authentication solutions to mitigate the risk of leaking user credentials and impersonal attacks.
Related to client-side information exposed via system or custom logs, 40% of the apps still leak information about user activity or client-server interactions, such as requests or responses from the server.
Evolution between 2013 and 2015:
Binary and File system Analysis
After reviewing the file system and binary of each app, 7.5% still do not have some compiler protections, such as PIE and Stack Smashing Protection, enabled.
Moreover, only 15% of the apps have jailbreak protection to detect and advise end users about the risk of jailbroken devices.
15% of the apps store unencrypted and sensitive information, such as details about customers’ banking accounts and transaction history, in the file system via sqlite databases or other plaintext files.
Finally, 17.5% of the apps have development and/or hardcoded information in their binary files.
Evolution between 2013 and 2015:
Vulnerability Distribution by Continent
Conclusions
· Most of the apps have increased transport security of the data by properly validating SSL certificates or removing plaintext traffic. This helps mitigate the risk of users being exposed to MiTM attacks.
· Although the numbers are down overall, there are still a high number of apps storing insecure data in their file system. Many of them are still susceptible to client-side attacks.
· Few of apps provide alternative authentication solutions, relying just on username and password for authentication.
· While overall security has increased over the two-year period, it is not enough, and many apps remain vulnerable.