There are thousands of apps in the Google Play mobile market that contain serious mistakes in the way that SSL/TLS is implemented, leaving them vulnerable to man-in-the-middle attacks that could compromise sensitive user data such as banking credentials, credit card numbers and other information. Researchers from a pair of German universities conducted a detailed analysis of thousands of Android apps and found that better than 15 percent of those apps had weak or bad SSL implementations.
The researchers conducted a detailed study of 13,500 of the more popular free apps on Google Play, the official Android app store, looking at the SSL/TLS implementations in them and trying to determine how complete and effective those implementations are. What they found is that more than 1,000 of the apps have serious problems with their SSL implementations that make them vulnerable to MITM attacks, a common technique used by attackers to intercept wireless data traffic. In its research, the team was able to intercept sensitive user data from these apps, including credit card numbers, bank account information, PayPal credentials and social network credentials.
The team also built a proof-of-concept tool called MalloDroid that was designed to find the potentially exploitable SSL bugs in Android apps, which they then investigated further to determine whether an attack was in fact possible. In a lot of cases–1,074, to be exact–it was.
“These 1,074 apps represent 17.0% of the apps that contain HTTPS URLs. To evaluate the real threat of such potential vulnerabilities, we have manually mounted MITM attacks against 100 selected apps from that set. This manual audit has revealed widespread and serious vulnerabilities. We have captured credentials for American Express, Diners Club, Paypal, Facebook, Twitter, Google, Yahoo, Microsoft Live ID, Box, WordPress, IBM Sametime, remote servers, bank accounts and email accounts. We have succesfully manipulated virus signatures downloaded via the automatic update functionality of an anti-virus app to neutralize
the protection or even to remove arbitrary apps, including the anti-virus program itself. It was possible to remotely inject and execute code in an app created by a vulnerable app-building framework,” the authors wrote in their paper, “Why Eve and Mallory Love Android: An Analysis of Android (In)Security”.
Security researcher Jon Oberheide of Duo Security, who has worked extensively on Android security, said that it’s important to realize that the presence of problematic code in an app doesn’t mean that it’s ever actually used during operation.
“The presence of such code in an app doesn’t necessarily mean the app is vulnerable to MITM. Many apps may contain the code, but it might not be in use at runtime. For example, many developers will have an option to disable SSL cert validation when the app is in debug mode, but that code path won’t be taken when the app is running for real,” Oberheide said.
The researchers discovered several separate classes of vulnerabilities, including apps that accepted any certificate; allowing all hostnames; trusting a huge number of certificate authorities by default; and apps using mixed-mode or no SSL. Their MalloDroid app evaluates target apps in a number of different ways, looking at the permissions they request, what network connections they use, how the apps use HTTP and HTTPS and how SSL certificates are handled.
Once they’d use their tool to weed out the apps with potential MITM vulnerabilities, the researchers set up a test environment to execute sample attacks against the apps, which they did manually.
“For the manual app auditing, we used a Samsung Galaxy Nexus smartphone with Android 4.0 Ice Cream Sandwich. We installed the potentially vulnerable apps on the phone and set up a WiFi access point with a MITM SSL proxy. Depending on the vulnerability to be examined, we equipped the SSL proxy either with a self-signed certi ficate or with one that was signed by a trusted CA, but for an unrelated hostname,” the researchers said in the paper.
“Of the 100 apps selected for manual audit, 41 apps proved to have exploitable vulnerabilities. We could gather bank account information, payment credentials for PayPal, American Express and others. Furthermore, Facebook, email and cloud storage credentials and messages were leaked, access to IP cameras was gained and control channels for apps and remote servers could be subverted.”
The research, which was done by teams from Leibniz University in Hanover and Philipps University of Hamburg, shows that app developers, like many Web developers, have trouble implementing SSL correctly. The researchers said that while Android’s default browser does a good job with SSL connections and gives users useful warnings when a certificate problem arises, there are a number of areas ripe for improvement. They suggest implementing an Android-specific version of the HTTPS Everywhere plugin, which automatically uses SSL when it’s available. They also say that using something such as MalloDroid with app installers would help find potentially vulnerable apps and implementing the tool in the app market could help, as well.
“The fi ndings of our investigation suggest several areas of future work. We intend to provide a MalloDroid Web App and will make it available to Android users. Moreover, there seems to be a need for more education and simpler tools to enable easy and secure development of Android apps. But most importantly, research is needed to study which countermeasures o er the right combination of usability for developers and users, security bene ts and economic incentives to be deployed on a large scale,” the researchers said.
Oberheide of Duo Security said that there are lessons in the paper both for developers and users.
“The fact that Android and other mobile platforms provide proper HTTPS routines as part of the core platform is important though. There will always be incompetent developers who shoot themselves in the foot security-wise and there’s only so much the mobile platform can do to prevent that without hampering legitimate cases,” he said.
“As far as users go, I think the biggest lesson to be learned is that downloading third-party unofficial apps can be risky (eg. downloading an unofficial banking app instead of the one actually released by your bank) for a number of reasons including poor coding practices.”
