- Security
- A
Android. Data theft via keyboard: myth or reality?
Can confidential user data be stolen through third-party apps on the device? Ideas for protection against potential attacks and discussion of how possible this is today
Hello, tekkix!
In this article, I would like to share my experience (or even discovery) and discuss an interesting topic, namely protection against possible ways to steal user confidential data on Android using another malicious app on a non-rooted device via the keyboard.
And before reading the article, I would like to remind you that it is written solely for educational purposes and does not encourage illegal actions, and it is not an instruction for criminal data theft. This article raises the issue of protection against potential attacks on the data of users of your app.
The implementation of the attacking side's code is intentionally omitted in the article, and only the potential attack vector is presented without a specific implementation, to show ways of protection against it.
Illegal obtaining of confidential data is punishable by law.
Now, after a long disclaimer, let's get to the point.
Plan:
Introduction
Attack using an overlay over all applications and protection against it
Attack using an accessibility service and protection against it
Conclusion
Introduction
Once, while listening to a presentation on Android development, I came across an interesting type of attack, namely TapJacking. I won’t go into details of this attack and how to defend against it: it is well described on this page in Google's documentation.
However, such an attack was a discovery for me, and immediately another thought arose: is it possible that a malicious app on a device could somehow read everything the user inputs in a similar way?
Two ideas immediately came to mind on how this could be implemented:
By overlaying a transparent overlay on the screen that would read all the user’s touches and send them to a server
Somehow reading data from the keyboard input in another service and sending it to a server
This article will focus on the feasibility of these attacks and how to protect against them.
Attack using an overlay over all applications and protection against it
The idea of this attack is simple: a malicious app should, at some point, overlay a transparent overlay over all apps, which will read all the user’s taps and send them in the background to a remote server. Given that most users do not change the appearance of their keyboards, it will not be difficult to correlate tap coordinates with the characters being entered.
What is the threat?
Primarily, it lies in the fact that sooner or later, the user will enter confidential information that the attacker will inevitably exploit.
In just a few hours, a prototype of an attacking application was developed, which successfully displayed over the windows of other applications, but here we encountered the first nuance: the application could either intercept touch coordinates on the transparent overlay and send them to the server, but in this case, the user could not interact with the application beneath the overlay. Alternatively, the user could interact with the overlay, but the overlay itself could not intercept the touch coordinates.
It turned out to be a vicious circle, which I couldn't solve quickly.
For me, this type of attack remained unfeasible due to the peculiarities of how Android works. But if you managed to implement it, I would be happy to discuss protection from such an attack in the comments of this post.
Attack using the accessibility service and protection against it
After the failed attempt to attack myself (I'm a strategist of sorts myself), another idea came to mind: what if the system itself reports the input of a password?
And, after digging a little in the documentation, I found this possibility: Android provides accessibility services with unique features: not only to read user touches, but also to immediately read the text entered by the user! Now the picture formed in my head, and a prototype of the attacking software was made.
The only nuance: for such an application to work, it is necessary to explicitly grant permission in the "Accessibility" settings section, otherwise nothing will happen. Some may say that this is unlikely and not worth worrying about, but I see a different picture: a child downloads a game from an unverified source and is shown a window with the words: "grant permission on the next screen to continue the game." And here, parents, unknowingly, have a service on their device that sends every keystroke to the network.
I consciously do not post the implementation of such an attack here, but with such permission, a third-party application can carry out this attack.
The logical question arises: how to protect yourself from such an attack?
After looking through the documentation, I found nothing better than simply disabling accessibility service access on fields where sensitive data is entered by setting the following methods:
For Android View:
setImportantForAccessibility(
or the corresponding xml attribute
View.IMPORTANT_FOR_ACCESSIBILITY_NO)android:importantForAccessibility="no"
For Compose:
Modifier.clearAndSetSemantics()
After setting these attributes, it is impossible for the accessibility service to read what the user is typing in the input field.
By the way, an interesting fact is that if the field type is password, data cannot be read from it impossible. But impossible until you press the "show password" button, which often removes
inputType==password
. One click, and your password is sent to the attacker
Conclusion
Despite the fact that I couldn't reproduce the overlay attack, the attack through the accessibility service is possible, and in my opinion, it is worth protecting against, as without 2FA, account credentials can be intercepted.
And considering that the user's phone may also have an app that reads your notifications, any app that requires login+password and a code from a notification is susceptible to this attack. Moreover, the device does not necessarily need to have ROOT rights to be vulnerable to this attack.
Do you consider protection against this attack the responsibility of the developer (since it seems that they should ensure the safety of your confidential data in the app)? Or does the responsibility for granting permissions lie entirely with the user? Share your opinion.
Write comment