1

I would like to begin by clarifying, my question does not relate to TapJacking attacks on Android and to my knowledge filterTouchesWhenObscured will not help in my case.

Here is the scenario: I work on an application that has sensitive information stored on it which is locally encrypted using a user-provided password. Therefore when the user opens the application they have to login by typing in their password. If this password was ever stollen, it would compromise the entire application.

Meanwhile, I have also been able to create a trojan horse style application that has been proven capable of stealing inattentive user's inputs. The prototype trojan application does the following:

  1. The user would download and install this application either by Google Play Store or side-load it. Either way, this isn't the important part.

  2. The user opens the evil app with the cute cat photos, and then navigates away from the application, leaving it in the background but not closing it.

  3. onPause, the evil application sets a series of timers for a predetermined amount of time where each timer will launch an evil service. Each evil service once created will spawn an invisible screen overlay that contains an invisible EditText field which will programatically pull focus to it and bring up the soft keyboard.

  4. If the timing is done right, the user may be in the middle of typing in sensitive information such as their password into our application. So the user may click on the password input in the app, then just as they go to type in their password, the invisible overlay is constructed and the keyboard swaps focus from the password field the user still see's on screen to the invisible EditText. The user types their password quickly off muscle memory, then hit's enter on the keyboard to realize they didn't type anything into the password field. Annoyed, they click the password field again and the evil service has a ClickListener fire on the invisible overlay, signalling its time to go, and it closes the service. The user now has normal control of their phone back.

A prototype for the above logic has been created and proven successful. It does rely on incredible luck to get the timing correct, but for a quick prototype attack vector developed in less than a few hours, it is worringly effective.

Here is sample code from the attack prototype:

final WindowManager.LayoutParams params =
    new WindowManager.LayoutParams(0, 0,
        WindowManager.LayoutParams.TYPE_PHONE, 0,
        PixelFormat.TRANSLUCENT);
View floatyView;
params.gravity = Gravity.CENTER | Gravity.START;
params.x = 0;
params.y = 0;

FrameLayout interceptorLayout = new FrameLayout(this);
floatyView = ((LayoutInflater) getSystemService(Context.LAYOUT_INFLATER_SERVICE)).inflate(R.layout.floating_view, interceptorLayout);
floatyView.setOnTouchListener(this);

windowManager.addView(floatyView, params);

final EditText editText = (EditText) floatyView.findViewById(R.id.myEditText);

final ScheduledExecutorService executorService = Executors.newSingleThreadScheduledExecutor();
executorService.scheduleAtFixedRate(new Runnable() {
  @Override
  public void run() {
    editText.requestFocus();
    showKeyboard(editText);
  }
}, 10, 10, TimeUnit.MILLISECONDS);


@Override
public boolean onTouch(View view, MotionEvent motionEvent) {
    final EditText editText = (EditText) floatyView.findViewById(R.id.myEditText);
    Log.d("EvilApp", "Stolen input = " + editText.getText());
    windowManager.removeView(floatyView);
    this.stopSelf();           
    return true;
}

Therefore with all of this said, is there any reliable means of either telling Android that it cannot allow other app's to overlay view's over your app or a reliable means of detecting when another application steals focus away from your application?

Thank you!

  • 1
    "or a reliable means of detecting when another application steals focus away from your application?" -- onPause() will be called on your activity and its fragments when it no longer is in the foreground from an input standpoint. – CommonsWare Sep 17 '18 at 19:34
  • When I first saw your comment I thought yo were right. But I have thoroughly tested this and onPause is never called when the invisible screen overlay steals focus. – dFrancisco Sep 18 '18 at 14:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.