BAndroid

Project Description

The BAndroid vulnerability allows an attacker with control over your browser to also take control over your mobile phone. In broad strokes, the scenario is as follows. If attackers have control over the browser on the PC of a user using Google services (like Gmail, Google+, etc.), they can push any app with any permission on any of the user’s Android devices, and activate it – allowing one to bypass two-factor authentication via the phone. Moreover, the installation can be stealthy (without any icon appearing on the screen). For short, we refer to the vulnerability as the BAndroid (Browser-to-Android) vulnerability and to attacks that abuse it as BAndroid attacks.

We found the vulnerability in 2014, alerted Google and others and demonstrated it to banks and various parties on the 5th of February, 2015 (and later at the NCSC One venue). It seems that similar (but slightly different) issues were independently reported by Rapid 7 (on February 10, 2015).

In this time and until the Volkskrant started reporting on this, we did not seek any publicity. Because of this, some people have questioned whether there is really a problem. We think it is pretty serious, but judge for yourself.

Talks

We presented BAndroid to the public a number of times:

Media Coverage and Developments

Demo

The demo video shows how an attacker can use BAndroid to bypass the Google Authenticator, Google’s own two-factor authentication solution. We discuss the demo video in detail in our recorded talks.

Papers

FAQ

Soon after Dutch newspaper Volkskrant reported [in Dutch] about the Android vulnerability on the 27th of June, some members of the (security) community raised concerns about our attack. It would be “nothing new” and “overrated”. Some people [in Dutch] suggested that having a strong password already helps a lot, while others doubt the possibility of uploading malicious code on the Google Play Store and/or maintain that your phone will display plenty of warnings if you were to try this attack. They all miss the point. By means of the following FAQ, we explain why the reported vulnerability really is a big deal.

0. What is the use case of the BAndroid vulnerability anyway?

Assume a cyber criminal with a financial incentive. He used to be able to instruct his malware (Zeus, Dyre, …) to target Internet banking users to transfer funds to an account that is under his control. Due to the deployment of two-factor authentication he can no longer do this, as he cannot intercept transaction codes and thus experiences a declining profit. However, with the technique we describe, attackers can regain full control over the user’s actions: they can take control over the phone and conveniently intercept transaction codes sent via text message and so complete the fraudulent transactions.

1a. How easy is it for an attacker to hijack your browser?

Our attack scenario assumes that attackers already have control over your browser. This way, they can steal your Google credentials and start the remote installation of Android apps. This type of attack is also dubbed Man-in-the-Browser or MitB.

One may argue that hijacking a browser is not so easy anymore these days. While it is true that finding zero-day exploits for the latest version of a popular browser is difficult, this is not how cyber criminals operate. Instead, they use exploits that work on the previous versions of a browser and rely on the fact that not everybody will update their browser regularly. In addition, attackers can get control over the browser via alternative paths: get the user to install malware by clicking links in spam or via drive-by-downloads.

MitB is a core component for all existing financial trojans like Zeus, SpyEye, Dyre, Dridex, Carberp, etcetera. These malware are or have all been very successful in compromising PCs with millions of infections worldwide. In fact, this is considered such a serious problem that most banks and other security-sensitive organisations opted for two-factor authentication (2FA) to begin with!

1b. Once your credentials are lost, isn’t it game over anyway?

This is a valid concern: a Google account alone gives attackers a wealth of opportunities. Until recently, however, it would not give them control over the victim’s mobile devices. A PC-based MitB would remain in that particular PC. As mentioned, this is the reason that mobile-phone two-factor authentication (2FA) actually worked: even if attackers stole your password for site X, they could not use it since they did not have access to the second component (the phone).

Driven by incentives, the deployment of 2FA for banking sites was a setback also for the criminals behind banking malware. No longer could they automate the process of transferring funds using stolen online banking credentials. Of course, their MitB could still be used to steal credentials for different websites (Facebook, Google, …), potentially causing all kinds of trouble (e.g., identity theft), but it was hard to turn this into straight profit via an automated process. Cyber criminals work in bulk and often do not care about individual persona that much.

It was because of this shift that we started observing mobile components of existing malware popping up in app markets: ZitMo (Zeus in the Mobile), SpitMo (SpyEye in the Mobile), CitMo (Carberp in the Mobile), and so on. These mobile malware variants all have the functionality to intercept and forward (or redirect) incoming text (SMS) messages and – as their names already indicate – behave as the mobile component of their PC-based version. And why are they so interested in text messages? To intercept the second factor TAN codes that are used by financial institutions when customers transfer money via online banking.

In conclusion: no, losing credentials does not necessarily mean that the game is over. At least not when you’re targeted by a cyber criminal who wants to steal your money. If it is your ex-girlfriend that wants to ruin your life, you are indeed in a bad shape.

2. I do not allow app installation from “untrusted sources”. I am safe, right?

Unfortunately, no. Our attack allows us to use the Google API to push any app from Google Play to a user’s device. If an attacker can thus succeed in publishing his malicious app in Google Play, he can install it from here.

Google will tell you that this is not possible. Their Google Bouncer project will automatically detect and remove malicious applications. We tried, however, and were very successful in publishing shady apps. Something that has been shown by other researchers in prior work as well. We detail how exactly we circumvent Bouncer in our Financial Crypto paper (linked below).

With the malicious app installed on the mobile device, attackers can do (almost) anything they want. In our video, we show the example of replacing an existing app (PayPal) with a repackaged version. In our version of this attack, we assumed the “allow installation from untrusted sources” option to be enabled: we did not publish the repackaged PayPal app in the Play Store due to legal issues. We also expect that repackaged apps are more likely to be picked up by Bouncer.

Many other attack scenarios are possible though, including those for which the “allow untrusted sources” option is not required. For financial malware, for example, it is sufficient that the app that is first installed provides a means to forward text messages to a remote server.

3. Since this attack installs a new app on my phone, won’t I be able to detect this?

Maybe, but not as easy as you think. The malicious app that we published will, after installation, not appear on your home screen, nor in the launcher. You can see it by going over “installed apps” via the Google Play app or your phone’s settings, but honestly, how often do you do that?

During installation, you will see messages in your notification bar: downloading …, installing …, but as soon as installation is completed, the only trace left (“… has been installed”) is visible when the notification area is pulled down explicitly.

We doubt that the app installation process will be spotted by a regular user.

4. Newly installed apps are by default in a ‘stopped’ state and can only be started when I open them explicitly. Why would I do that?

It is true that newly installed Android apps are deactivated by default and cannot start services until it’s main activity is started. This means that the app needs to be started at least once before it can intercept text messages or perform other malicious behavior. We found, however, that a vulnerability in the Android platform (like this one, only slightly different and still applicable on the latest Android version) allows this to be done from another app on the phone. By sending a special intent to the deactivated app, it’s main activity can be started and it becomes active. A very convenient app that can be used to send such intent is the default Android browser: Chrome. For our attack, we crafted a special web page that, when opened in Chrome, sends an intent to our malicious application.

Two questions remain: (i) how do we trick our user into opening this web page and (ii) wouldn’t the unexpected popup of our app arouse suspicion?

For (i), a little bit of social engineering is required. Not much though, given that we have access to the user’s Google credentials: we can use these to send the victim an e-mail from himself (or one of his friends) containing a URL to the web page; if the victim makes use of Google Drive, we can modify links in his documents to redirect to our web page; If he uses Chrome’s synchronization features, we can replace all of his bookmarks in such a way that they first visit our web page before we automatically redirect them to the original bookmark; if we also happen to have access to other social networking accounts like Twitter or Facebook (credentials harvested by the PC-based MitB), we could use these to even further prime the victim into unknowingly visiting our web page, and so on. Note that these are all techniques that can be perfectly automated by an attacker.

For (ii), our app was written in such a way that it’s main activity is closed immediately after the app is started. This way, a user is unlikely to suspect the ongoing attack.

5. Don’t you agree that this is not really a vulnerability but more a design feature of Google (with a potentially bad outcome)?

No. In fact, many vulnerabilities are the result of poorly reviewed design decisions. While it is true that no real data is leaked (we did not discover a database revealing user passwords), the discussed vulnerability can – as we describe above – be used by malware authors to bypass two-factor authentication used by financial institutions around the world. This is a huge vulnerability and has the potential to cost those institutions a lot of money.

In fact, we think that vulnerabilities that result from poor design decisions are often worse than a regular buffer overflow. The latter can easily be fixed by a software patch, while a design decision is not something that is reversed quickly. This is illustrated perfectly by comments on our findings that we received, as well as by the attitude from Google. They don’t see a security issue here and are unwilling to change the feature. Usability and the desire to synchronize everything has become more important than security.

Also, because much of the vulnerability is by design, it is very easy to exploit. We do not need complicated exploits, Heap Feng Shui, or custom ROP chains; many Android coders can actually pull this one off.

6. What can Google do to fix this?

That is easy: move the app installation process (where the user is prompted to accept the app’s permissions) to the mobile device instead of handling it in the browser.

7. What can I do to protect myself?

There are a couple of things that you can do to protect yourself against this attack, most of them are “the usual”:

  • Keep your software up to date.
  • Do not click on unknown or suspicious links.
  • Do not access your Google account from an untrusted machine.

A more harsh but very effective approach is to use two (or multiple) Google accounts: one for your PC and one on your phone. This way, the attacker will not be able to install apps, as your PC-based Google Play account won’t have any devices available. Another is to use a dumb phone to receive 2FA one-time passwords.

As for the suggestion that strong passwords will help here: while it is wise to use different and strong passwords for different websites, this will help very little in stopping the BAndroid attack: a PC-based MitB can still steal your credentials.

8. Is there any related work?

Yes, have a look at the work done by Alexandra Dmitrienko et. al.

9. Now what?

  1. Be alert!
  2. Be alert!
  3. Did you open any link listed above? Are you sure those pages are safe? Can you also confirm that advertisement providers used by those pages have not been hacked? If not, did you install your updates today? And did you read about that zero-day? Are you sure that you are not infected?
  4. Be alert!
  5. Now, if you have any, please send us your feedback. We will happily add more questions and answers to the list. You can contact Herbert, Radhesh or Victor via e-mail.

Acknowledgements

This work was supported by the MALPAY project and by the Netherlands Organisation for Scientific Research through grants NWO 639.023.309 VICI “Dowsing” and NWO CSI-DHS 628.001.021. The public artifacts reflect only the authors’ view. The funding agencies are not responsible for any use that may be made of the information they contain.