Accessing mobile user’s privacy based on IME personalization: Understanding and practical attacks 1 2

Abstract

Input Method Editor (IME) is an indispensable component on current smartphones. With its assistance, the number of key presses is reduced, and non-Latin characters could be inputted. Furthermore, modern IMEs integrate several personalized features like reordering suggestion lists and predicting the next words based on user’s input history. Such optimization improves the user experience but turns the IME dictionary into a pool of user privacy. Previous works have discussed the privacy risks coming from malicious IMEs. Indeed, they could cause security and privacy issues if installed by common users, but their impact is limited as the majority of IMEs are well-behaved. However, whether legitimate IMEs are bullet-proof is not answered before.

In this paper, we make the first attempt to study the security implications of IME personalization and the back-end infrastructure on Android devices. In the end, we identify a critical vulnerability lying under the Android KeyEvent processing framework, which can be exploited to launch cross-app KeyEvent injection (CAKI) attack and bypass the app-isolation mechanism. By abusing such design flaw, an adversary can harvest entries from the personalized user dictionary of IME through an ostensibly innocuous app only asking for common permissions. Our evaluation over a broad spectrum of Android OSes, devices, and IMEs suggests such issue should be fixed immediately. All Android versions we examined (from very old 2.3.4 to the latest 6.0.1) and most IME apps we surveyed (11 out of 18) are vulnerable. User’s private information, like contact names, location, etc., can be easily exfiltrated. Up to hundreds of millions of mobile users are under this threat. To mitigate this security issue, we propose a practical defense mechanism which augments the existing KeyEvent processing framework without forcing any change to IME apps.

Keywords

Android smart IME privacy leakage system flaw

1. Introduction

The smartphone is becoming the primary device for handling people’s daily tasks like making calls, sending/receiving messages, and surfing the Internet. Of particular importance in supporting these features are input devices. Among them, keyboard, either hardware keyboard integrated within mobile phone or soft keyboard displayed on the touchscreen, receives a significant volume of users’ input. Most of these keyboards are tailored for the users speaking Latin languages. Users in other regions like Chinese and Japanese have to use Input Method Editor (or IME) to type non-Latin characters. In fact, numerous IME apps3

³
We use IME and IME app interchangeably in this paper.

have emerged since the advent of smartphone and been installed by enormous population. The capabilities of IME are continuously extended to optimize users’ typing experience. The present IME (see Fig. 1) can learn the words inputted by a user, customize the suggested words, and predict the words the user plans to type. These user-friendly features help the IME gain popularity even among Latin-language users.

The wide adoption of IME, however, does not come without cost. Previous research has raised the privacy concerns with shady IMEs which illegally spy on users’ input [9,11,27,34,35,41]. Indeed, they could cause security and privacy issues if installed by common users, but their impact is limited as the majority of IMEs are well-behaved, and there have been efforts in warning the risk of enabling a new IME (see Fig. 2). The question not yet answered is whether legitimate IMEs are bullet-proof. If the answer is negative, they can be exploited by the adversary as stepping stones to breach the privacy of mobile users. In this work, we examine smart IMEs (the ones supporting optimization features) and the back-end framework in an attempt to verify their security implications. We choose Android as a target platform given its popularity and openness.

Fig. 1.

Smart IME on Android.

Fig. 2.

Warning message when activating a new IME.

KeyEvent Processing. We first look into the underlying framework which handles input processing. In short, each key press on hardware keyboard triggers a sequence of KeyEvents [22] on Android. As for the purpose of automated testing, a mobile app can also simulate key presses by directly injecting KeyEvents. Without a doubt, such behavior should be confined to prevent a malicious app from illegally injecting KeyEvents to another victim app. Android consolidates KeyEvent dispatching by ensuring that either the KeyEvent sender app and receiver app are identical or sender app has a system-level permission (INJECT_EVENTS) which cannot be possessed by third-party apps. Failing to pass such check will cause KeyEvent being discarded and an exception thrown.

Our Findings. Unfortunately, this seemingly invulnerable framework can be cracked. If a malicious app injects KeyEvents to its owned EditText widget with IME turning on, the KeyEvents will be redirected to the IME, resulting in cross-app KeyEvent injection (CAKI) attack. Following this trail, an attacker can peep into IME dictionary (usually stored in the internal storage protected by app-isolation mechanisms) and know user’s favorite words or even the words taken from other sensitive sources, like phone contact. The root cause of this vulnerability is that Android only performs security checks before KeyEvent is dispatched but misses such when KeyEvent is delivered.

For this particular case, because of the discrepancy between the point of checking and the point of delivering, IME is turned into the final receiver on the fly when KeyEvent is delivered. Therefore, the security check at the beginning is bypassed. Since this issue exists in the system layer, all IMEs are potentially under threat. The security implication of the above attack on IME apps may not be so obvious, but it actually can lead to severe privacy leakage. The nature of this attack is to simulate user keystrokes on an IME and obtain the personalized suggested words. For example, when a user strokes “pro” on her phone, the IME provides the prediction result (the default candidate) “professor”. However, another user gets the result “programmer”. We could find the same keystrokes lead to different results, which reflect the personalized information related to the user.

Attack Against IME. Even knowing this vulnerability, a successful attack against IME is not trivial. The challenges include how to efficiently extract words related to personal information or interest and how to hide the malicious activities from the user. Towards solving the first challenge, we devise new technique to enumerate the combinations of prefix letters automatically and use differential analysis to infer the words private to the user. This technique can be adapted to different language models and achieve success. To address the second challenge, we combine several well-founded techniques to make the attack context-aware and executed till the user is absent.

We implemented a proof-of-concept malicious app named DicThief and evaluated it against 18 very popular IMEs and 9 Android OS versions. The result is quite alarming: all the Android versions we examined are vulnerable, and most of the IMEs we surveyed are not immune. The population under threat is at a scale of hundreds of millions (see IME popularity in Table 3). Towards mitigating this urgent issue, we propose an origin-checking mechanism which augments the existing Android system without forcing any change to IME apps.

Our preliminary version of this work has revealed the CAKI vulnerability and the corresponding exploiting approach [15]. In this extended version, we carry out a more systematic study to explore such system-level design flaw and the privacy leakage threats coming from personalized features. Specifically, we propose a quantification method to measure the privacy leakage so that the potential security risks can be understood and noticed better. Also, we analyzed the back-end supporting framework for third-party IMEs to complete the in-depth investigation. The methods of hiding attacks are improved, and additional evaluation results (extended experiment involved nearly all mainstream IMEs for English and Chinese) are provided according to the current Android system evolution.

We reported our findings to Google’s Android Security Team, and they acknowledged the problem we have raised (bug tracking ID assigned: AndroidID-33000178). However, they decided not to release a patch and responded the fix “would greatly reduce the quality of predictions”. We hope this work could urge Google to reconsider their decision.

Contributions. The contributions of our work are listed as below:

New Vulnerability. We discovered a fundamental vulnerability in the Android KeyEvent processing framework leading to CAKI attack.

New Attack Surface. We show, by launching CAKI attack, an attacker can steal a variety of private information from IME dictionary. Different with previous IME-based attacks, our attack is the first to exploit the innocent IMEs.

Systematic Study. We carry out a systematic study on the relationship between IME user dictionary and privacy leakage. Several popular IMEs are analyzed to measure their optimization features and data sources. Also, such privacy leakage risks are quantified based on the information theory.

Implementation, Evaluation, and Defense. We implemented the attack scheme and developed a proof-of-concept attacking app, DicThief. We demonstrated the risk of this problem by evaluation under different real-world scenarios. We propose a defense solution as a remedy.

Roadmap. The rest sections are organized as follows: Section 2 provides the background knowledge about personalized user dictionaries of smart IMEs and the adversary model adopted by this paper. Section 3 analyzes the root cause of the CAKI vulnerability. Section 4 further elaborates the details of our proposed attack scheme DicThief, from the design to implementation. In Section 5, we evaluate DicThief in our experiment and highlight the results. Section 6 discusses the corresponding defense strategies and some advanced topics. We retrospect the related works in Section 7 and conclude this paper in Section 8.

2. Background and adversary model

In this section, we provide the background of the personalized user dictionary and Android back-end framework supporting third-party IMEs. After that, the adversary model used in this paper is given.

2.1. Personalized user dictionary and privacy

IMEs have emerged to support users speaking different languages like English and Chinese. A smartphone is usually shipped with pre-installed IMEs, but alternatively, users could download and use other IME apps. Smart IMEs have gained massive popularity: top IMEs like Sogou Mobile IME [39] has more than 478 million active users [44].

The IMEs used today have been evolved from solely soft keyboard to versatile input assistant with many new features to improve users’ typing experience. The goals of these new features are to reduce the number of keys a user needs to type. For instance, modern mainstream IMEs (such as SwiftKey [42], TouchPal [45], Sogou Mobile IME, etc.) implement features like dynamic suggestions order adjustment, contact names suggestions, next-word prediction and new word saving to provide suggestions for current or subsequent words. Hence, a user could select a word among them without typing the complete text. These features are called “optimization features” and we elaborate them below:

Dynamic Order Adjustment. This feature adjusts the order of suggested words dynamically according to user’s input history. For example, as shown in Fig. 3, two typed characters “ba” lead to different lists of suggested words. “bankruptcy” is the first suggestion in the left picture while “banquet” is the first suggestion in the right one.

Contact Names Suggestion. IME can suggest a name from user’s phone contact when part of the name is typed. Also, suggestions also pop up when an unknown name is typed for correction. The READ_CONTACTS permission needs to be granted to support this feature. Figure 4 shows the IME gives the contact name “David Smith” as a suggestion.

Next-word Prediction. Equipping with this feature, IME attempts to predict the next word user wants to input based on the previous words typed. Figure 5 shows an example that IME gives a prediction “Newcastle” based on the previous input “Fly to”.

New-word Saving. When a word not existing in the dictionary is typed, IME automatically adds this word to its dictionary. In Fig. 6, the suggestion “Kijilogi” is a word created by the user.

Fig. 3.

Dynamic order adjustment.

Fig. 4.

Contact names suggestion.

Fig. 5.

Next-word prediction.

Fig. 6.

New-word saving.

To summarize, all the above features are driven by user’s personalized information, like user’s input history. Furthermore, when the permissions shielding user’s sensitive data are granted, IMEs can customize their dictionaries using various data sources, including SMS, Emails, and even social network data. It is very likely that the names of user’s family members and friends and nearby locations are recorded by the IME after using for a while. We manually examined the settings and permissions of several IMEs and summarized the data sources of 18 representative mainstream IMEs (most of them have over 1 million installations, all available on Google Play) in Table 1. Apparently, the personalized dictionary should be considered private assets and protected in the safe vault. In fact, most of the IME apps we surveyed keep their dictionaries in the internal storage of mobile phone which is only accessible to the owner app.

Table 1

Data sources of mainstream IMEs for optimization features

App Name and Package Name	Version	Input History	Contacts	Emails/SMS	SNS	Location
Go Keyboard [com.jb.gokeyboard]	2.18	√	√
TouchPal [com.cootek.smartinputv5]	5.6	√	√	√	√
Adaptxt–Trial [com.kpt.adaptxt.beta]	3.1	√	√	√	√	√
Google Keyboard [com.google.android.inputmethod.latin]	4.0	√	√	√	√
SwiftKey Keyboard [com.touchtype.swiftkey]	5.0	√	√	√	√
Swype Keyboard Free [com.nuance.swype.trial]	1.6	√	√		√
Fleksy Keyboard Free [com.syntellia.fleksy.kb]	3.3	√	√	√	√
Google Pinyin Input [com.google.android.inputmethod.pinyin]	4.0	√	√
Sogou Mobile IME [com.sohu.inputmethod.sogou]	7.1	√	√			√
Baidu IME [com.baidu.input]	5.1	√	√			√
QQ IME [com.tencent.qqpinyin]	4.7	√	√
Emoji Keyboard Lite [com.emojifamily.emoji.keyboard]	3.9.5	√	√	√		√
LIME IME [net.toload.main.hd]	5.1.1	√
Ginger Keyboard [com.gingersoftware.android.keyboard]	7.8.06	√	√	√	√
IQQI Keyboard [com.iqt.iqqijni.f]	2.2.8032.0	√	√			√
Kika Keyboard [com.qisiemoji.inputmethod]	5.5.5.1391	√	√			√
Linpus Keyboard [com.linpusime.android.linpuskbd]	1.7.6	√	√
TS Keyboard [com.tss21.globalkeyboard]	1.5.1	√	√

Privacy Leakage Risk. If a malicious app could extract data from the personalized user dictionary, it could infer plenty of user’s privacy, including age, gender, occupation, location, etc. For example, when a user types “heart”, the IME provides the next-word prediction “disease” as the first suggestion. Obviously, the phrase “heart disease” was ever typed by the user several times, which reflects some kind of correlation with such user. Once obtaining enough data, an attacker could outline a complete view of the victim user.

2.2. Android input method framework

IMEs are usually pre-installed, but they may not satisfy users speaking different languages. Therefore, Android provides an extensible Input Method Framework (IMF) that allows users using alternative third-party IMEs. There are three primary parties involved in IMF [18]:

The InputMethodManager [1] is the central component of the system that manages interactions among all other parts. It is expressed as the client-side API here which exists in each application context and communicates with a global system service InputMehtodManagerService [2] that manages the interaction across all processes.

An IME implements a particular interaction model allowing the user to generate text. The system binds to the current activated IME, causing it to be created and run, and tells it when to hide and show its UI.

Multiple client applications arbitrate with the InputMethodManager for input focus and control over the state of the IME. Only one such client is activated (working with the IME) at a time.

Figure 7 explains the simplified workflow of Android IMF. There are three main steps:

Fig. 7.

Android input method framework.

When a view (TextView) of an application gains the focus, it invokes the corresponding InputMethodManager to bind the current activated IME to itself. In this process, an InputChannel has been built.

This view requests the activated IME show its UI (soft keyboard).

The user starts to strike keys on the keyboard. These keystrokes are captured by the IME, and composed texts are committed to the bonded view (client application).

Supported by this framework, a user can download and install other IME apps. After installing the desired IMEs, she can select which one to use from the system settings and use it across the entire system; only one IME may be enabled at a time [13].

2.3. Adversary model

The adversary we envision here is interested in the dictionary entries of IME deemed private to the user, like contact names, and aims to steal and exfiltrate them to her side. We assume the user has installed a victim IME which is “benign” and “smart”.

“Benign” means this IME exercises due diligence in protecting user’s private data. The measures taken include keeping its dictionary in app’s private folder (internal storage).4

⁴
Android designs a global provider UserDictionary and the corresponding permissions for personalized dictionaries [47]. However, except the IMEs developed by Google, all the other third-party IMEs prefer to control user dictionaries by themselves and do not intend to share these data.

This assumption differs fundamentally from previous IME-based attacks which assume IME itself is malicious.

“Smart” means this IME can learn unique word-using habits and build a personalized user dictionary based on user’s input history, contacts, and so forth.

At the same time, we assume this user has downloaded and installed a malicious app named DicThief aiming to steal entries from victim IME. The default (enabled) IME on the device could be identified through the system class Settings.Secure [37]. This malware only claims two permissions: INTERNET and WAKE_LOCK. Both permissions are widely claimed by legitimate apps and unlikely to be rejected by users: nearly all apps declare the INTERNET permission, and WAKE_LOCK is also widely claimed by apps like alarm, instant messenger (e.g., WhatsApp and Facebook Messenger), etc. With the WAKE_LOCK permission, our attack can be launched even the phone is in the sleep mode and locked with password protection.

3. Vulnerability analysis

We identify a new vulnerability lying under Android OS, allowing an adversary to launch Cross-App KeyEvent Injection (CAKI) attack. While the direct access to the dictionary of IME is prohibited for privacy protection in Android, this vulnerability can violate this security guarantee. More specifically, by exploiting such vulnerability, a malicious app can simulate user keystrokes on an IME and read the suggested words. In this section, we describe the mechanism of keystroke processing in Android and the new vulnerability we identified subsequently.

3.1. Android KeyEvent processing flow

The internal mechanism of input processing in Android is quite sophisticated, and here we only focus on how KeyEvents5

⁵
IME accepts another kind of input event – MotionEvent [28], coming from the soft keyboard (see Fig. 1). Its processing flow is different and not covered in this paper.

are processed. At a high level, when a key is pressed on the hardware (built-in) keyboard, a sequence of KeyEvents will be generated by wrapping the raw input, and then sent to the corresponding handlers (e.g., IME). These two steps are called KeyEvent Pre-processing and KeyEvent Dispatching. We illustrate the process in Fig. 8 and then elaborate the details below:6

⁶

Our descriptions are based on Android 6.0.1_r67 [3] since these versions hold the largest market share among all the Android systems. For other versions, the flows are mostly the same, and only the paths of source code could be different.

Fig. 8.

Android KeyEvent processing framework and the CAKI vulnerability.

KeyEvent Pre-processing. As long as a hardware key (e.g., built-in keyboard) is pressed, a raw input event is sent to a system thread InputReader (initiated by WindowManagerService) and encapsulated into an object in the format of NotifyKeyArgs. Then, this object is passed to thread InputDispacher (also initiated by WindowManagerService), and a KeyEntry object is generated. Lastly, this object is converted to EventEntry object and posted to the message queue (InboundQueue) of InputDispacher to be distributed to right handlers. If a key-press event is simulated by an app, the corresponding KeyEvents are initiated directly and finally sent to the message queue (in the format of EventEntry).

KeyEvent Dispatching. Before event dispatching, there is a permission checking process on the corresponding EventEntry to ensure its legitimacy. The code undertaking such check is shown in Listing 1 (excerpted from the Android code repository [4]).

Listing 1.

Code block for permission checking in InputDispatcher

This routine first verifies whether the event is generated by a hardware device (checking injectionState). If injectionState is NULL, the check is passed, and the event is directly sent to handlers. When the event is generated by an app, this routine verifies whether the sender app owns the required permission or if it is identical to the receiver app (we fill in the details in Section 3.2).

An input event passing the above check will be dispatched via a system IPC mechanism InputChannel to the receiver app, which should run in the foreground and take the input focus. In particular, the WindowInputEventReceiver component belonging to the receiver app process will be notified, and then forward the received KeyEvent to other components of ViewRootImpl, a native OS class handling GUI updates and input event processing, for further processing. When an IME is activated and also brought to the foreground (see Fig. 1), there exists a special policy: ViewRootImpl will redirect the KeyEvent to the IME, which absorbs the event and renders the resulting text (suggested word or the raw character) on the client app’s view. This policy guarantees the KeyEvents are processed by IME with high priority.

3.2. Cross-app KeyEvent injection vulnerability

Since the simulated key-presses could come from a malicious app, Android enforces much stricter checking. Still, the checking routine is not flawless. Below, we elaborate a critical vulnerability in this routine (illustrated in Fig. 8):

KeyEvent Injection. An app can simulate various input events using the APIs provided by Android Instrumentation Library [19]. This function is supposed to support automated app testing. For example, an app can invoke the function Instrumentation.sendKeyDownUpSync() to simulate user’s keystrokes, such as “d”, “7”, “!”, and the corresponding KeyEvents will be injected into the message queue subsequently.

Verification. Injected KeyEvent needs to be vetted. Otherwise, one app can easily manipulate the input to the app taking focus. To a new coming KeyEvent, at least one of the following security checks has to be passed (see the code block of checkInjectionPermission in Listing 1):

The KeyEvent is originated from the hardware keyboard.

The KeyEvent injector and receiver are the same.

The KeyEvent injector has been granted the INJECT_EVENTS permission.

Since INJECT_EVENTS is a system-level permission, a non-system-level app (installed by the user) simulating key-press has to meet the only possible requirement: the receiver app is itself.

CAKI Vulnerability. At first glance, the above verification process is sound. However, it fails when IME is in the picture, and as such, a malicious app can launch Cross-App KeyEvent Injection (CAKI) attack.

A non-system-level malicious app (named ${app}_{x}$ ) running in the foreground first activates IME (named ${IME}_{y}$ ) set as default by the user, which could be achieved by setting the focus on an EditText widget [16] in ${app}_{x}$ ’s window. After ${IME}_{y}$ is ready, and its virtual keyboard is displayed, ${app}_{x}$ injects a KeyEvent to the message queue. At this point (Time-of-Check), the KeyEvent receiver is also ${app}_{x}$ as it takes input focus (another party, IME, cannot take focus by design). The projected event flow turns out to be ${{app}_{x} \to system \to {app}_{x}}$ and clearly passes the check of routine checkInjectionPermission. Then (Time-of-Use), the KeyEvent is sent to RootViewImpl of ${app}_{x}$ . Given ${IME}_{y}$ is activated at this moment, this KeyEvent is redirected to ${IME}_{y}$ (see Section 3.1), turning the actual event flow into ${{app}_{x} \to system \to RootViewImpl of {app}_{x} \to {IME}_{y}}$ . In this stage, no additional checks are enforced, and ${IME}_{y}$ will respond to the KeyEvent. Apparently, the security guarantee is violated because ${app}_{x}$ and ${IME}_{y}$ are not identical. This vulnerability allows a malicious app to send arbitrary KeyEvents to IME.

This CAKI vulnerability can be attributed to a significant class of software bugs, namely time-of-check to time-of-use (TOCTTOU) [8,29,46,50,55]. However, we are among the first to report such bugs on the Android platform,7

⁷
We found only one vulnerability disclosure by Palo Alto Networks’ researchers [53] regarding TOCTTOU on Android, which was reported in March 2015.

and our exploitation showcase indicates this CAKI vulnerability could cause grave consequences.

4. Attack: Design and implementation

In this section, we describe the design and implementation of the proof-of-concept attacking app DicThief, which exploits the CAKI vulnerability to steal private dictionary entries. Also, the quantification of privacy leakage and a concrete attack case are presented to help understand our proposed attack.

After DicThief is run by the victim user, it starts to flood KeyEvents to an EditText widget which pops up the default IME when the owner app DicThief is in the foreground. IME will commit words to the EditText, and they are captured by DicThief. When the number of stolen entries hits the threshold, DicThief will stop flooding KeyEvents and exfiltrate the result (compressed if necessary) to attacker’s server. Such attack flow is illustrated in Fig. 9. Since KeyEvent injection has been discussed in the previous section, here we elaborate how to harvest meaningful entries from the dictionary and our context inference technique in making the attack stealthy.

Fig. 9.

CAKI attack flow.

4.1. Enumerating entries from dictionary

Given the enormous size of IME dictionary (hundreds of thousands of words), the most prominent challenge is how to identify the entries comprehending user’s private information efficiently. These entries could be added from user’s typed words, imported from user’s private data (e.g., contact names) or reordered according to user’s type-in history. We refer to such entries as private entries here. Through manually testing several popular IME apps, we observed one important insight regarding these private entries: they usually show up after 2 or 3 letters/words typed and placed in the first or second position in the suggestion list. In other words, by enumerating a small number of letter/word combinations, a large number of private entries can be obtained. We design two attack modes based on such insight:

Attack Mode 1 – Word Completion: For each round, DicThief injects 2 or 3 letters and then injects the space key or number “1” to obtain the first word from the suggestion list of IME, which is then appended to the list of collected results. After all the valid combinations are exhausted, or the threshold is reached, the list is sent to attacker’s server. This attack works based on the dynamic order adjustment feature of IME: e.g., if a user frequently chooses “bankruptcy” from suggestion list, when she types “ba”, the suggestion list will become ${bankruptcy | ban | bank | bad}$ , and the private entry can be readily determined.

Attack Mode 2 – Next-word Prediction: This time, DicThief injects a complete word (or several words) for each round and selects the first word prompted by IME. Similarly, the space key or number “1” is used to obtain the first suggestion, and the attack ends when a certain number of rounds is reached. This attack exploits IME’s next-word prediction feature: e.g., the injected words “fly to” will trigger the list ${Newcastle | the | be | get}$ if IME concludes that “Newcastle” is user’s favorite choice.

The generated list comprehends both private entries and the entries irrelevant to customization. We need to filter out the latter ones. To this end, we carry out a differential analysis. We run DicThief against a freshly installed IME app which has not been used by anyone, then collect all the first words in two modes. Next, we find the different words between the list collected from victim’s phone with ours. The words left are deemed private entries. This data filtering procedure runs on the attacker’s server.

4.2. Attack in stealthy mode

When DicThief is launched, it has to be displayed and run in the foreground in order to turn on IME. If the user is operating her phone at the same time, the malicious activities will be noticed quickly. In this section, we propose several techniques to reduce the risks of notice.

Circumventing Lock Screen. Our attack has to be executed even if the phone is asleep and locked with password protection. To proceed the attack, DicThief requires the WAKE_LOCK permission has been granted first. As discussed in Section 2.3, users will not reject such request in most cases. Besides, DicThief needs to add the FLAG_SHOW_WHEN_LOCKED flag in its window configuration, making it take precedence over keyguard or any other lock screen [52].

Yet, common apps cannot be brought to the top of foreground when the phone is locked. On Android, apps’ windows are managed by the system service WindowManagerService. Also, each window corresponds to a WindowState which stores the Z-order regarding its order of layer in display. WindowState is managed by WindowManagerService and Z-order cannot be tweaked by apps. According to the design of Android UI management policy, the window with the bigger Z-order will be shown in a higher layer. Following this rule, a general app window is set to 2 while the keyguard window (lock screen) is set to 13. Therefore, the keyguard window will always display in front of other general apps. Nevertheless, when an app invokes an IME, it will be brought to the top of the client app disregarding its assigned Z-order due to one policy of Android [5] (due to the special window type TYPE_INPUT_METHOD), as illustrated in Fig. 10. Hence, our attack can succeed even when the screen is securely locked with the password.

Fig. 10.

Windows layer relationship.

Context Inference. DicThief is designed to run when a mobile user falls asleep. At that time, the phone should be placed on a flat platform (no acceleration observed), the screen should be dimmed, and the time should be at night. All of such information can be retrieved using APIs from system classes (SensorManager for accelerator metrics, PowerManager for screen status and Calendar for current time respectively) without any permission. These techniques are also exploited by other works [14,36] to make their attacks stealthy. In practical terms, when the user opens DicThief, it stays in the background and is periodically awakened to infer the running context. DicThief will not start to inject key-presses until the current context meets the attack criteria.

Brightness Reduction. DictThief can be even stealthier if the screen brightness is reduced. Combined with the above context inference, after setting the attribute screenBrightness of app window to 0, the phone display will not be noticed by users, and malicious activities could stay hidden accordingly.

4.3. Case study of IMEs for non-latin languages

Not only is our attack effective against IMEs for English, but IMEs for non-Latin languages are also vulnerable as well. Apart from English users, the users who type in non-Latin words have to rely on alternative IMEs since the language characters are not directly mapped to English keys. In this section, we demonstrate a case study on attacking Chinese IMEs. It turns out just a few adjustments need to be applied to the enumeration algorithm, and private entries can be obtained efficiently, albeit the complexity of such language.

Chinese and Pinyin. Pinyin is the official phonetic system for transcribing the Mandarin pronunciations of Chinese characters into the Latin alphabet [33]. Pinyin-based IMEs are, in fact, the most popular IMEs used by Chinese users. Except for some special cases, every Chinese syllable can be spelled with exactly one initial followed by one final [20,33]. In total, there are 23 initials8

⁸
The initial set: ${w, y, b, p, m, f, d, t, n, l, g, k, h, j, q, x, z h, c h, s h, r, z, c, s}$ .

and 37 finals. Figure 11 describes an example.

Each Chinese character has a unique syllable, but one syllable is associated with many distinct characters. Each Chinese word is composed of multiple characters (usually two to three). An example is shown in Fig. 12. The character combination poses a big challenge in harvesting meaningful Chinese entries: a prefix (e.g., “ji”) might only reveal one Chinese character, far from meaningful words. On the other side, a prefix in English (e.g., “mis”) can yield the list of meaningful words with viable size.

Fig. 11.

Example of Chinese Pinyin.

Fig. 12.

Pinyin: One-to-many mapping.

Attack. Fortunately, Pinyin-based IME optimizes the input experience. By providing several syllable initials, the suggestion list of words with the same initials will be produced. For instance, typing “j’h” (initial j plus initial h) will yield the list of 5 Chinese words shown in Fig. 12. It motivates us to enumerate the combination of initials instead of the leading Pinyin letters. Here, we elaborate the algorithm of attacking word-completion mode of Pinyin-based IME in Algorithm 1.

Algorithm 1

Enumerating 2-character words of Pinyin-based IMEs

5. Evaluation and findings

We implemented a prototype of the attack app DicThief (with around 550 Java lines of code) and tested it on several mainstream IMEs to evaluate the attack effectiveness. Particularly, in this section, we first analyzed the scope of attacks (vulnerable Android versions and IMEs) in Section 5.1. Also, we are curious whether our attack could be detected by the latest anti-virus software, and the corresponding results are provided in Section 5.2. Finally, we evaluated the effectiveness of proposed two attack modes (word completion and next-word prediction) in Section 5.3 and Section 5.4 respectively.

5.1. Scope of attack

Our newly discovered CAKI vulnerability derives from the design flaw of Android framework. Thus, theoretically, all Android devices will suffer from this vulnerability. To corroborate this assumption, we test 8 different versions of Android OS on 6 physical Android phones. The test turns out all versions ranging from very old (2.3.4) to the latest (6.0.1) are vulnerable without exception. The vulnerable phones and the corresponding OS versions are listed in Table 2.

Table 2
Evaluation on different Android OSes

Phone Model Android Version Attack Result

Nexus 6 AOSP Android 6.0.1 success

AOSP Android 5.1.1 success

AOSP Android 5.0 success

Sony Xperia Z3 Sony official 4.4.4 success

Samsung Galaxy S3 CyanogenMod 4.4.4 success

Samsung official 4.3 success

Meizu MX2 Meizu official 4.2.1 success

Sony Xperia ion Sony official 4.1.2 success

Motorola Defy+ Motorola Official 2.3.4 success

Phone Model	Android Version	Attack Result
Nexus 6	AOSP Android 6.0.1	success
AOSP Android 5.1.1	success
AOSP Android 5.0	success
Sony Xperia Z3	Sony official 4.4.4	success
Samsung Galaxy S3	CyanogenMod 4.4.4	success
Samsung official 4.3	success
Meizu MX2	Meizu official 4.2.1	success
Sony Xperia ion	Sony official 4.1.2	success
Motorola Defy+	Motorola Official 2.3.4	success

Also, our attack is not limited to a specific language or a specific IME. All smart IMEs equipped with optimization features should be potentially vulnerable. We tested our attack on 18 popular IMEs and 11 among them are vulnerable, as shown in Table 3. Our attack does not succeed on 7 IMEs, and we further explored the reasons of unsuccess. After manual code analysis and event instrumentation testing, we confirmed two main causes: (1) KeyEvents cannot trigger the word suggestion feature (on Fleksy and IQQI); (2) The suggestion committing only could be completed through screen operations (on Swype, Google, Kika, Emoji, and Ginger). We could conclude these IMEs only respond to taps on soft keyboard (MotionEvent), but ignore the key-presses simulated by apps (KeyEvent). However, they may have compatibility issues since hardware keyboard is not supported well. Therefore, we believe such lucky escape is probably due to design flaw rather than protection enforced.

Table 3

Evaluation on popular IMEs

App Name and Package Name	Version	Language(s)	Vulnerable	Installations
Go Keyboard [com.jb.gokeyboard]	2.18	Multi-language	Yes	100,000,000+
TouchPal [com.cootek.smartinputv5]	5.6	Multi-language	Yes	50,000,000+
SwiftKey Keyboard [com.touchtype.swiftkey]	5.0	Multi-language	Yes	100,000,000+
Adaptxt–Trial [com.kpt.adaptxt.beta]	3.1	Multi-language	Yes	1,000,000+
Google Pinyin Input [com.google.android.inputmethod.pinyin]	4.0	Chinese, English	Yes	100,000,000+
Sogou Mobile IME [com.sohu.inputmethod.sogou]	7.1	Chinese, English	Yes	10,000,000+
Baidu IME [com.baidu.input]	5.1	Chinese, English	Yes	1,000,000+
QQ IME [com.tencent.qqpinyin]	4.7	Chinese, English	Yes	1,000,000+
LIME IME [net.toload.main.hd]	5.1.1	Chinese, English	Yes	500,000+
Linpus Keyboard [com.linpusime.android.linpuskbd]	1.7.6	Chinese, English	Yes	100,000+
TS Keyboard [com.tss21.globalkeyboard]	1.5.1	Multi-language	Yes	500,000+
Swype Keyboard Free [com.nuance.swype.trial]	1.6	Multi-language	No	5,000,000+
Fleksy Keyboard Free [com.syntellia.fleksy.kb]	3.3	Multi-language	No	5,000,000+
Google Keyboard [com.google.android.inputmethod.latin]	4.0	Multi-language	No	500,000,000+
Kika Keyboard [com.qisiemoji.inputmethod]	5.5.5.1391	Multi-language	No	100,000,000+
Ginger Keyboard [com.gingersoftware.android.keyboard]	7.8.06	Multi-language	No	5,000,000+
IQQI Keyboard [com.iqt.iqqijni.f]	2.2.8032.0	Multi-language	No	1,000,000+
Emoji Keyboard Lite [com.emojifamily.emoji.keyboard]	3.9.5	Multi-language	No	5,000,000+

Remarks: The data of installations is based on Google Play.

5.2. Anti-virus apps detection

A successful attack also means it should not be found by anti-virus software. We tested five leading mobile anti-virus apps, including AVG, McAfee, Avira, Dr. Web, and ESET. After executing threat scanning, none of them reported DicThief as a malicious app. In the process of attacks, none of them can detect the malicious behaviors of DicThief. Such result is reasonable because our attack exploits a new vulnerability which is never reported before. Also, the attack app does not invoke any sensitive permission and violate the Android security checking. Therefore, no detection policy of anti-virus apps was triggered.

5.3. Experiment on word completion attack mode

In this mode, DicThief injects 2 or 3 random letters and selects the first word suggested by IME. The victim IME we chose is Sogou Mobile IME [39], a dominant Pinyin-based IME in China with 478 million monthly active users [44]. The information leakage and overhead caused by DicThief are assessed separately:

Information Leakage. We conducted a user study9

⁹
The experiments have followed the IRB rules, and all human subjects fully understood the privacy implication of the experiments and agreed to participate.

to portrait and quantified the leaked information. We recruited 9 Sogou Mobile IME users (labeled as

{User}_{1}

–

{User}_{9}

) to participate in our experiments. All of them are native Chinese speakers. Their basic information and the final results are shown in Table 4.

Table 4

Word Completion Attack: user study

User	Age	Gender	Installation Time	Feeling of Info Leakage	Category of Info Leakage	Personalized Entries
1	25∼30	male	1 year+	Many	① ② ③ ⑤	416 (78.6%)
2	25∼30	male	8 months+	Many	① ②	239 (45.2%)
3	25∼30	male	1 year+	Some	② ⑤	358 (67.7%)
4	18∼25	male	2 months+	Many	② ③ ⑤	107 (20.2%)
5	18∼25	male	2 months+	Some	② ⑤	436 (82.4%)
6	25∼30	male	2 years and 4 months+	Many	① ② ③ ⑤	388 (73.3%)
7	25∼30	female	1 year and 6 months+	Many	① ② ⑤	299 (57.0%)
8	18∼25	male	10 months+	Many	① ②	130 (24.6%)
9	18∼25	male	1 year and 5 months+	Many	② ⑤	394 (74.5%)

Remarks: The native language of ${User}_{5}$ is Cantonese, which is a dialect of Chinese.

All the participants installed a modified version of DicThief on their phones before the experiment. All 2-initial combinations are probed, counting up to 529 rounds ( $23 \times 23$ combinations, see Section 4.3). To address the privacy concerns of our human subjects, we did not collect any word entries from their phones. Instead, we asked them to report the type and quantity of personalized entries (calculated by DicThief). The detailed result is presented in two aspects:

Intuition: Severity of Leaked Information. DictThief shows the extracted words to the volunteers directly after the attack finishes, and then the volunteers are asked to fill a survey. Questions include: how much sensitive information are extracted [“Many” / “Some” / “None”]? which categories can be used to summarize the leaked information [① “Occupation” / ② “Contacts” / ③ “Location” / ④ “Hobby” / ⑤ “Other personalized information”]? The result is shown in the 5th and 6th columns of Table 4.

Quantification: Percentage of Personalized Entries. For each volunteer, MD5 for all extracted words (529 entries total) are generated and compared with the MD5 of extracted words from the IME freshly installed. Personalized entry is counted if discrepancy identified. The result is shown in the last column of Table 4.

Apparently, plenty of sensitive information will be leaked if the CAKI vulnerability is exploited by real attackers. On average, 58.2% of the words extracted are indeed personalized. The ratio of personalized entries is associated with the frequency of IME usage, either in principle or practical experiment results. Figure 13 illustrates such rough positive correlation relationship. The only exception is ${User}_{5}$ whose native language is Cantonese (a dialect of Chinese), and we believe the significantly different word-using habits lead to such high ratio of personalization. Also, according to the cubic fitted curve (after excluding ${User}_{5}$ ) plotted in Fig. 13, there exists an upper boundary for the ratio of personalization, say around 80%. It means the remaining part (20%) should be some very common word combinations.

From the statistics of Table 4 (plotted in Fig. 14), the most obvious information leakage source is the contact name which is definitely sensitive to users. Besides, based on the feedback of volunteers, the category of “other personalized information” includes the names of installed apps, watched films, friends’ nicknames, frequently used slang expressions, the names of nearby restaurants, and so forth. It reflects the kinds of leaked information are various from another point of view.

Fig. 13.

Word Completion Attack: personalized entries vs. duration of IME usage.

Fig. 14.

Word Completion Attack: category of information leakage.

Time and Battery Consumption. The time for KeyEvent injection is negligible, but DicThief has to pause for a while after a round of key injection till the IME renders its UI.

The actual time overhead depends on both the implementation of IME apps and the performance of phone’s hardware. We measure it on Samsung Galaxy S3 and set the waiting period to 70 ms based on manual testing a priori. We further test the time consumption for all 2-initial combinations and 3-initial combinations. These two kinds of combinations have covered most situations of common Chinese words [26]. The total time consumed adds up to 221 s for all 2-initial combinations injections against Sogou Mobile IME. Meanwhile, the battery consumption is also slim, costing less than 1% of total battery life. Also, all 3-initial combinations injections can be done within two and half hours. Considering the attack can be done during sleep time, this is still a reasonable range.

5.4. Experiment on next-word prediction attack mode

In this mode, DicThief injects one or more words and choose the first word from the list of predictions provided by IME. The IME we evaluated is TouchPal [45], an English IME with over 10 million installations worldwide. Since it is hard for us to recruit enough native English speakers as volunteers in our region, we decided to use public web resources to create virtual user profiles and customize IME dictionary with them. It brings the extra benefit that now we are allowed to look into what exact private entries are leaked. We document the steps for generating user profiles as below:

In a real-world scenario, an IME is customized by the text a user inputs or information left by the user. Likewise, for each virtual user, we compile the text she could enter and dump it to IME. In all, we create five users (labeled as ${Sample}_{1}$ – ${Sample}_{8}$ ) and use content scraped from 8 blogs to externalize them separately. The blogs are carefully chosen so that the topic focused on by each one is different. Table 5 shows statistics of the prepared data.

Table 5
Next-word Prediction Attack: simulation experiment

Sample	Crawled Words	Author Info & Blog Topics	Blog URLs	Personalized Entries
1	31581	female, professor, work experience	http://getalifephd.blogspot.com/	273 (63.3%)
2	31661	male, cooking, food	http://fforfood.blogspot.com/	39 (9.0%)
3	35606	male, American football	http://footballislifeblog.blogspot.com/	73 (17.0%)
4	40913	male, daily life	http://livingstingy.blogspot.com/	54 (12.5%)
5	32347	female, traveling	http://www.stephstravels.com/	208 (48.3%)
6	42127	male, defense, military	http://formerspook.blogspot.com/	103 (23.9%)
7	37638	male, film review	http://filmbabble.blogspot.com/	93 (21.6%)
8	35875	male, aeronautics and astronautics	http://spaceflighthistory.blogspot.com/	151 (35.0%)

Since TouchPal can read messages and customize itself, we dump the collected blog content into the SMS outbox of the test phone (Samsung Galaxy S3) using an Android app developed by ourselves. We use one paragraph to fill one text message.

Now, TouchPal can proceed to customize its dictionary. We tick the options “TouchPal Cloud → Personalization → Learn messages automatically” and “Only learn sent messages”, and then execute the “Learn from messages” function of TouchPal. It takes about one hour for the customization processing to complete.

When a predicted word is selected, TouchPal will prompt a new predicted word. Hence, a user can type one word and continuously choose the words provided by TouchPal to build a long phrase. We leverage this feature to carry out 3-level prediction attack. For example, DicThief injects one word “want” and then chooses three predicted words – “to”, “go” and “shopping” – prompted consecutively (through injecting number “1”). As a result, a meaningful phrase “want to go shopping” will be revealed. Our empirical study suggests that starting from a verb, we have higher chances to capture a meaningful phrase. Therefore, we select 431 words from 1000 frequently used English verbs [43] (from “is” to “wrap”) to bootstrap our attack. The remaining 569 words are not selected as they are either other tenses of the selected verbs or used mainly as nouns.

Information Leakage. We followed the same leakage quantification method used in the last experiment, and the result is listed in Table 5. On average, 28.8% entries are personalized. Also, since the data comes from virtual users, we take a close look at the personalized words this time. The results are quite alarming, and several personalized information could be found. Here, we use ${Sample}_{1}$ and ${Sample}_{5}$ as examples to demonstrate the leaked information.

For a sequence of injected keys, we compare the phrase generated from fresh IME (left-side of “⟶”) and ${Sample}_{1}$ ’s IME (right-side of “⟶”) (see Table 6). One can easily find several words related to ${Sample}_{1}$ ’s occupation – professor, such as “tenure”, “professional editor”, “advise”, “university”, and “recent talk”. Expectedly, the privacy of a real-world user will be under severe threat if such attack is launched.

Table 6

Next-word Prediction Attack: examples of private entries – ${Sample}_{1}$

Default Suggestion		Personalized Suggestion
know what to do	⟶	know I always advise
want to go to	⟶	want to publish an
become a better place	⟶	become a professional editor
relate to the gym and	⟶	relate to the New York
create a new one	⟶	create a Gmail account
invest in a few days	⟶	invest in a recent talk
rely on the way	⟶	rely on the tenure
buy a new one	⟶	buy a new university
wish I could have	⟶	wish I could write
discuss the same time	⟶	discuss the work of
learn to be a	⟶	learn to translate the
discover that the only	⟶	discover that the world

For ${Sample}_{5}$ , several terms related to traveling could be found, as listed in Table 7. They reflect what topics the author often types, which can be considered as sensitive information by many people. Especially, they point to a location – “Utah” and a kind of transportation – “Sky train” which is the rapid transit railroad system operating in Bangkok, Thailand. After examining the blog content of ${Sample}_{5}$ , we found the location was visited, and the transportation was boarded before.

Table 7

Next-word Prediction Attack: examples of private entries – ${Sample}_{5}$

Default Suggestion		Personalized Suggestion
see you soon then	⟶	see the stars and
supply of the day	⟶	supply of our trip
prepare for the first	⟶	prepare for the flight
intend to do it again	⟶	intend to do in Utah
behave like a good	⟶	behave like a packing
rest of the day	⟶	rest of the city
use the bathroom and	⟶	use the Sky train
travel to the gym	⟶	travel tips for the
search for the first	⟶	search for the flight
make it to you	⟶	make it two days
complain about the same	⟶	complain about the details
rely on the way	⟶	rely on the unsuspecting

Time and Battery Consumption. The time overhead is slight as well. Injection of single key costs 35 ms (counting waiting time) and the whole attack takes around 401 s. The battery consumption is also negligible (less than 1%).

6. Discussion

In this section, we propose some possible defense solutions and discuss how to fix the vulnerability described in this paper (Section 6.1). Also, we discuss the possibility of attack utilizing MotionEvent injection (Section 6.2). In addition, we try to measure the severity of our proposed attack through a quantitative method (as supplementary materials for interested readers, see Appendix).

6.1. Defense

Our proposed attack, DicThief, exploits a critical vulnerability which exists in the Android KeyEvent processing framework. In particular, the security checks fail to cover the complete execution path. Based on the above sections, our proposed attack can steal dictionary entries and further obtain users’ personal information.

It is indeed a non-trivial task to fix this vulnerability due to the highly sophisticated design of Android. First of all, it is useless to add a new permission to circumscribe such attacking behaviors. For example, injecting KeyEvent to the app itself should be permitted as usual for the purpose of automated testing unless IME is involved in the process. Yet, there is no way to ensure this when the app is installed. Second, it is also infeasible to modify IME app code merely and reject all the injected KeyEvents since the injections from system-level apps owning the INJECT_EVENTS permission will always be allowed.

To mitigate such threat, we propose to augment the current KeyEvent processing framework. Currently, the information about KeyEvent sender is limited. It only tells whether the KeyEvent is injected by one app or coming from the hardware keyboard, turning out to be too coarse-grained. We argue that the identity of the source app (i.e., package name, signature) should be enclosed in KeyEvent as well, which can be fulfilled by adding a new field to its data structure. Before dispatching a KeyEvent, Android OS automatically attaches the sender’s identity to it. Before forwarding KeyEvents to IME, Android OS verifies the sender and discard the injected KeyEvents if the sender is neither system app owning the INJECT_EVENTS permission nor the hardware keyboard. The updated KeyEvent processing framework is illustrated in Fig. 15 in which we could find there is no discrepancy between the time of check and time of use. Attaching origin has also been explored by Wang et al. [49] to prevent one app from sending unauthorized intents to another app in Android. Their approach requires modifications to Android OS and app’s code, and the policy setting process is delegated to the app side. In contrast, our approach only calls for the modification to Android OS, as the policy should be identical to all IME apps, which protects them transparently.

Fig. 15.

Android KeyEvent processing framework with defense logic.

Furthermore, we examine other possible countermeasures, but all of them come with the loss of usability or compatibility. One possible solution is to prohibit IME being invoked when the phone is securely locked, but this will disable the quick-reply feature of the default SMS app and third-party instant messaging (IM) apps. We can also force IME to commit words to text controls only if the word displayed on the touchscreen is tapped, but it will block the input from the hardware keyboard.

From the aspect of data cache, the source of privacy leakage is the IME personalized dictionary. As a developer, sensitive information should not be designed to store in such dictionary. However, how to define the “sensitive” will be a challenge. The balance between usability and security is one of the eternal conundrums in software development.

6.2. The possibility of attack utilizing MotionEvent injection

In this paper, our attack is based on the cross-app KeyEvent injection. One straightforward question is whether the cross-app MotionEvent (touch event) [28] injection is possible. Unfortunately, based on the exploration of the internal mechanism of Android touch event dispatching, we cannot see the possibility of exploiting MotionEvent. The fundamental reason is that IME apps do not have a higher priority to receive dispatched MotionEvents, which is different from the flow for KeyEvent. In details, when the system dispatches a MotionEvent, a similar security check (like the one for KeyEvent illustrated in Fig. 8) is deployed to prevent cross-app MotionEvent injection. Though a malicious app is allowed to inject MotionEvents to itself, IME apps will never become the final receiver because the location information (x-axis, y-axis) contained in the MotionEvent has specified the final receiver explicitly.

7. Related works

To the best of our knowledge, our work makes the first attempt to evaluate the security implications of IME personalization and the back-end infrastructure on Android devices. None of the previous work on IME has addressed security concerns from this perspective. We classify related work into three categories based on the previous discussions: (1) IME security issues (2) key-logging attacks (3) untrusted input.

7.1. IME security issues

According to Android’s official documents [13,18], the Input Method Framework (IMF) has several security features: (1) the system can directly access an IME’s interface via the BIND_INPUT_METHOD permission rather than any other mobile apps; (2) only one client process of the IMF can be active at a time even though there may be many of them; (3) clients of an IME can only access to its InputMethodSession interface with permission; (4) only the activated client’s InputConnection can accept operations; (5) the IMF is responsible for managing the client processes, like notifying each of them whether it is active and ignoring the inactive processes calls on to the current InputConnection; (6) an IME can never interact with an InputConnection while the screen is off; (7) an app allows users to select a new IME via the system dialog but cannot programmatically switch to one itself; (8) mobile users must explicitly enable a new IME through settings before using it. Due to these restrictions, Android tries itself to avoid the security risk of IMEs. However, there are an enormous amount of potential security issues associated with IMEs.

IMEs can collect all user-typed text, and user’s privacy will be breached if an IME sends out the collected key presses out of malice. There are some existing issues found in built-in IMEs. A recently published post about the vulnerability of Samsung built-in IME shows that a remote attacker capable of controlling a user’s network traffic can manipulate the keyboard update mechanism on Samsung phones and execute code as a privileged (system-level) user on the target’s phone [51]. It can be used in behavior that requires no user intervention. Even if the vendor has fixed this kind of issue, the security issue itself always catch our eyeballs.

Besides built-in IMEs, the Android IMF also allows using third-party IMEs, which always leads to potential risks. In fact, there have been questionable behaviors of IMEs observed in the wild [9,34,35]. Also, Cho et al. [11] demonstrated malicious IMEs on Android could effectively steal users’ sensitive keystrokes. Hence, Android users should be aware of this risk, and only install third-party IMEs from the official app store, and even then, make sure the source is legitimate. To prevent such threat of information leakage, Chen et al. [10] propose I-BOX, an app-transparent oblivious sandbox that minimizes sensitive input leakage by confining untrusted IME apps to predefined security policies.

In our work, we identify an entirely different venue to abuse IME: rather than enticing users to install a malicious IME, an adversary can exfiltrate the sensitive information through a new system design flaw and a novel IME dictionary probing technique.

7.2. Keystroke inference attacks

Key-logging on mobile devices is the action of recording (logging) the keystrokes on a virtual or physical keyboard, typically in an underlying way, so that users usually have no idea that their movements are being captured. Suenaga [41] and Mohsen et al. [27] also studied key-logging threats of malicious IMEs on the Windows and Android platforms respectively. In the Android system, a non-system app cannot obtain users’ keystrokes directly. However, previous works show that it is possible to infer keystrokes through various side-channels.

Phone motions can also be exploited to detect the keystrokes. More specifically, a touch on the screen, especially the soft keyboard will cause vibrations, and touching on different positions will introduce distinctive vibration patterns. Previous works monitor the motion sensor like accelerometers to collect vibration statistics and infer what keys are pressed [6,7,25,31,32,54]. For instance, TouchLogger [7] is an Android app which can extract features from device orientation data to infer keystrokes. This work claimed that it could correctly infer more than 70% of the keys typed on a number-only virtual keyboard. TapLogger [54] also can stealthily monitor the movement and gesture changes of a smartphone using its onboard motion sensors, so that it can infer the users’ inputs according to the learned patterns. TextLogger [32] utilizes the shared memory side-channel for detecting window events and tap events of a soft keyboard, which achieves long user inputs inference. More recently, such threats of key-logging have been extended to wearable devices. Liu et al. [24] and Wang et al. [48] have first demonstrated the possibility of inferring user’s key-presses through smartwatch.

Besides, other sources are also exploited for keystrokes inference, such as microphone [30], Wi-Fi information [23], camera [17,38], and light sensor [40]. For example, a combination of stereoscopic microphones and gyroscopes is used to infer users’ keystroke when they tap on a soft keyboard [30]. In the work of Li et al. [23], the adversary can exploit the strong correlation between the channel state information (CSI) fluctuation and the keystrokes to infer the user’s number input. Further, Simon and Anderson [38] demonstrate that video camera and microphone can be used to infer PINs entered on a number-only soft keyboard on a smartphone. In particular, the microphone can detect touch events, while the camera is used to estimate the smartphone’s orientation, and correlate it to the position of the digit tapped by the user. Also, Spreitzer [40] shows the light sensor employed in today’s mobile devices actually represents a new type of side channel that leaks the user’s input.

In comparison with the existing works, our work steals user’s input history in plain text without inference, and a significant amount of typed text can be unveiled in a short time.

7.3. Untrusted input

A plethora of key functionalities in mobile devices are driven by user’s input and the modules handling such data are usually entailed with very high privileges. A natural path for a malicious app to elevate its privileges is impersonating human and injecting false input.

Besides direct leakage due to IME, other sources or tools can also be used as an untrusted input to launch attacks. Diao et al. [14] discovered that an adversary could inject prerecorded voice commands to the built-in voice assistant module (Google Voice Search) of Android and bypass permission checks. According to the paper experiment, theoretically, all Android (4.1+) devices equipped with Google Services Framework can be affected by GVS-Attack. Jang et al. [21] investigated accessibility (a11y) support framework of popular desktop and mobile platforms and identified a number of system vulnerabilities in handling user’s input.

In our work, we identify a new channel to inject fake input and bypass the security checking. We believe such threat is not yet over and encourage future research in identifying other exploitable sources and building better input validation mechanisms.

8. Conclusion

In this paper, we identify a new cross-app KeyEvent injection vulnerability against IMEs installed on Android devices. By exploiting such flaw, an adversary can infer words frequently used by a user or coming from other sensitive sources. We implement DicThief, a prototype app and evaluate it under real-world settings. The result shows that all Android versions and most popular IMEs are vulnerable, putting a lot of users into danger. Such issue should be fixed immediately, and we propose a solution only requiring changes to Android system. In the end, we believe this vulnerability is only the tip of the iceberg, and the security of input processing framework and IME needs to be further studied.

Footnotes

Acknowledgments

We thank anonymous reviewers for their insightful comments. We also thank Fenghao Xu for helpful discussion. This work was partially supported by National Natural Science Foundation of China (NSFC) under Grant No. 61572415, Hong Kong S.A.R. Research Grants Council (RGC) Early Career Scheme/General Research Fund No. 24207815 and 14217816, Guangzhou Key Laboratory of Data Security and Privacy Preserving, Guangdong Key Laboratory of Data Security and Privacy Preserving, and National Joint Engineering Research Center of Network Security Detection and Protection Technology.

Quantifying the information leakage

To better understand how severe our proposed attack could be, it is necessary to take a quantitative study on the information leaked through this attack. Without loss of generality, we build the analysis model based on the information theory [12] by calculating the entropy (i.e., uncertainty) changes of the data in the personalized user dictionary before and after attacking.

We assume that adversary can get the default non-personalized dictionary from a freshly installed victim IME. Let $L_{d}$ be the default suggestion list mapped to the injected key sequence K, and $L_{p}$ be the personalized suggestion list mapped to the same K. The information leakage could be understood as the adversary’s knowledge about a particular user (i.e., which suggested word she will select when typing K), and a part of the uncertainty has been eliminated after the attack. So, the information leaked by observing the difference between $L_{p}$ and $L_{d}$ can be calculated as: $\begin{array}{l} (1) & I_{leak}^{K} = H (L_{d}) - H (L_{p}) \end{array}$ in which $H (L_{d})$ and $H (L_{p})$ are the entropies of list $L_{d}$ and list $L_{p}$ respectively.

To the default suggestion list $L_{d}$ , suppose $L_{d} = {S_{1}, S_{2}, \dots, S_{n}}$ , where $S_{j}$ ( $j = 1, 2, \dots, n$ ) is the jth word in the list. Since we has no knowledge about the user, we have to consider the worst case in which the probabilities of selecting any suggestion are the same, say $Pr (S_{1}) = Pr (S_{2}) = \dots = Pr (S_{n}) = \frac{1}{n}$ . Therefore, the entropy contained in list $L_{d}$ is: $\begin{array}{l} (2) & H (L_{d}) = - \sum_{i = 1}^{n} Pr (S_{i}) {log}_{2} Pr (S_{i}) = {log}_{2} n \end{array}$

To the personalized suggestion list $L_{p}$ , suppose the first m ( $1 ⩽ m ⩽ n$ ) elements now are revealed through our proposed attack, as shown in Fig. 16. In the m ordered elements, the element (suggested word) with the higher ranking is selected more frequently by the user. Therefore, the probability of being selected for each element is not equiprobable, say $Pr (S_{1}) ⩾ Pr (S_{2}) ⩾ \dots ⩾ Pr (S_{n})$ . We apply the geometric progression to model it, that is $Pr (S_{i}) = c {(1 - c)}^{i - 1}$ in which c is the (non-fixed) base probability and $0.5 ⩽ c ⩽ 1$ . Since there is no knowledge about the remaining $(n - m)$ elements, we still have to make the worst case assumption that each of them would have the same selection probability as $\frac{1 - (c + c (1 - c) + \dots + c {(1 - c)}^{m - 1})}{n - m} = \frac{1 - {(1 - c)}^{m}}{n - m}$ , so: $\begin{array}{l} H (L_{p}) & = - \sum_{i = 1}^{n} Pr (S_{i}) {log}_{2} Pr (S_{i}) = - \sum_{i = 1}^{m} Pr (S_{i}) {log}_{2} Pr (S_{i}) - \sum_{i = m + 1}^{n} Pr (S_{i}) {log}_{2} Pr (S_{i}) \\ (3) & = {log}_{2} (1 - c) + [{(1 - c)}^{m} - 1] [{log}_{2} c + \frac{{log}_{2} (1 - c)}{c} + {log}_{2} \frac{1 - {(1 - c)}^{m}}{n - m}] \end{array}$

As a result, the leaked information $I_{leak}^{K}$ could be expressed as: $\begin{array}{l} I_{leak}^{K} & = H (L_{d}) - H (L_{p}) \\ (4) & = {log}_{2} n - {log}_{2} (1 - c) - [{(1 - c)}^{m} - 1] [{log}_{2} c + \frac{{log}_{2} (1 - c)}{c} + {log}_{2} \frac{1 - {(1 - c)}^{m}}{n - m}] \end{array}$ In our case, we only consider the first word is revealed via the proposed attack, i.e., $m = 1$ . So: $\begin{array}{l} (5) & I_{leak}^{K} = {log}_{2} n - c {log}_{2} (n - 1) + 2 c {log}_{2} c \end{array}$ The intuitive explanation of this formula is that the leaked information is equal to the uncertainty of the default word list minus the uncertainty of the personalized dictionary. Therefore, after the attack, with the leaked confidential information, the adversary has a higher probability to predict which suggestion will be selected by the user, that is more knowledge about the user. Also, the entropy of leaked information is affected by the entry amount n of the suggestion list (triggered by different injected key sequence K).

References

Android Open Source Project, InputMethodManager.java. https://android.googlesource.com/platform/frameworks/base/+/android-6.0.1_r67/core/java/android/view/inputmethod/InputMethodManager.java.

Android Open Source Project, InputMethodManagerService.java. https://android.googlesource.com/platform/frameworks/base/+/android-6.0.1_r67/services/core/java/com/android/server/InputMethodManagerService.java.

Android Open Source Project. android-6.0.1_r67. https://android.googlesource.com/platform/frameworks/base/+/android-6.0.1_r67.

Android Open Source Project, InputDispatcher.cpp. https://android.googlesource.com/platform/frameworks/native/+/android-6.0.1_r67/services/inputflinger/InputDispatcher.cpp.

Android Open Source Project, PhoneWindowManager.java. https://android.googlesource.com/platform/frameworks/base/+/android-6.0.1_r67/services/core/java/com/android/server/policy/PhoneWindowManager.java.

A.J.

Aviv,

Sapp,

Blaze and

J.M.

Smith, Practicality of accelerometer side channels on smartphones, in: Proceedings of the 28th Annual Computer Security Applications Conference (ACSAC), 2012.

Cai and

Chen, TouchLogger: Inferring keystrokes on touch screen from smartphone motion, in: Proceedings of the 6th USENIX Workshop on Hot Topics in Security (HotSec), 2011.

Cai,

Lale,

X.C.

Zhang and

Johnson, Fixing races for good: Portable and reliable UNIX file-system race detection, in: Proceedings of the 10th ACM Symposium on Information, Computer and Communications Security (ASIACCS), 2015.

Carman, SwiftKey bug leaked emails and other personal information, 2016. http://www.theverge.com/2016/7/29/12326152/swiftkey-bug-backup-sync-down-error-prediction.

10.

Chen,

Bauman,

Lin,

Zang and

Guan, You shouldn’t collect my secrets: Thwarting sensitive keystroke leakage in mobile IME apps, in: Proceedings of the 24th USENIX Security Symposium, 2015.

11.

Cho,

Cho and

Kim, Keyboard or keylogger?: A security analysis of third-party keyboards on Android, in: Proceedings of the 13th Annual Conference on Privacy, Security and Trust (PST), 2015.

12.

T.M.

Cover and

J.A.

Thomas, Elements of Information Theory, 2nd edn, John Wiley & Sons, 2012.

13.

Creating an Input Method. http://developer.android.com/guide/topics/text/creating-input-method.html.

14.

Diao,

Liu,

Zhou and

Zhang, Your voice assistant is mine: How to abuse speakers to steal information and control your phone, in: Proceedings of the 4th ACM Workshop on Security and Privacy in Smartphones & Mobile Devices (SPSM), 2014.

15.

Diao,

Liu,

Zhou,

Zhang and

Li, Mind-reading: Privacy attacks exploiting cross-app KeyEvent injections, in: Computer Security – ESORICS 2015 – 20th European Symposium on Research in Computer Security, Proceedings, Part II Vienna, Austria, September 21–25, 2015.

16.

EditText. http://developer.android.com/reference/android/widget/EditText.html.

17.

Fiebig,

Krissler and

Hänsch, Security impact of high resolution smartphone cameras, in: Proceedings of the 8th USENIX Workshop on Offensive Technologies (WOOT), 2014.

18.

InputMethodManager. http://developer.android.com/reference/android/view/inputmethod/InputMethodManager.html.

19.

Instrumentation. http://developer.android.com/reference/android/app/Instrumentation.html.

20.

ISO 7098:1991 Romanization of Chinese, ISO/TC 46 Information and Documentation (1991).

21.

Jang,

Song,

S.P.

Chung,

Wang and

Lee, A11y attacks: Exploiting accessibility in operating systems, in: Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security (CCS), 2014.

22.

KeyEvent. http://developer.android.com/reference/android/view/KeyEvent.html.

23.

Li,

Meng,

Liu,

Zhu,

Liang,

Liu and

Ruan, When CSI meets public WiFi: Inferring your mobile phone password via WiFi signals, in: Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security (CCS), 2016.

24.

Liu,

Zhou,

Diao,

Li and

Zhang, When good becomes evil: Keystroke inference with smartwatch, in: Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security (CCS), 2015.

25.

Miluzzo,

Varshavsky,

Balakrishnan and

R.R.

Choudhury, Tapprints: Your finger taps have fingerprints, in: Proceedings of the 10th International Conference on Mobile Systems, Applications, and Services (MobiSys), 2012.

26.

Ministry of Education of the People’s Republic of China, The modern Chinese common words list (in Chinese). http://www.moe.edu.cn/publicfiles/business/htmlfiles/moe/s230/201001/75598.html.

27.

Mohsen and

Shehab, Android keylogging threat, in: Proceedings of the 9th IEEE International Conference on Collaborative Computing: Networking, Applications and Worksharing (CollaborateCom), 2013.

28.

MotionEvent. https://developer.android.com/reference/android/view/MotionEvent.html.

29.

Mulliner and

Michéle, Read it twice! A mass-storage-based TOCTTOU attack, in: Proceedings of the 6th USENIX Workshop on Offensive Technologies (WOOT), 2012.

30.

Narain,

Sanatinia and

Noubir, Single-stroke language-agnostic keylogging using stereo-microphones and domain specific machine learning, in: Proceedings of the 2014 ACM Conference on Security and Privacy in Wireless and Mobile Networks (WiSec), 2014.

31.

Owusu,

Han,

Das,

Perrig and

Zhang, ACCessory: Password inference using accelerometers on smartphones, in: Proceedings of the 2012 Workshop on Mobile Computing Systems and Applications (HotMobile), 2012.

32.

Ping,

Sun and

Mao, TextLogger: Inferring longer inputs on touch screen using motion sensors, in: Proceedings of the 8th ACM Conference on Security & Privacy in Wireless and Mobile Networks (WiSec), 2015.

33.

Pinyin. http://en.wikipedia.org/wiki/Pinyin.

34.

Rodriguez, Your Keyboard App Is Hoarding Your Data, 2016. http://motherboard.vice.com/read/keyboard-apps-data-privacy.

35.

Sanders, Japanese government warns Baidu IME is spying on users, 2014. http://www.techrepublic.com/blog/asian-technology/japanese-government-warns-baidu-ime-is-spying-on-users/.

36.

Schlegel,

Zhang,

Zhou,

Intwala,

Kapadia and

Wang, Soundcomber: A stealthy and context-aware sound Trojan for smartphones, in: Proceedings of the 18th Network and Distributed System Security Symposium (NDSS), 2011.

37.

Settings.Secure. http://developer.android.com/reference/android/provider/Settings.Secure.html.

38.

Simon and

Anderson, PIN skimmer: Inferring PINs through the camera and microphone, in: Proceedings of the Third ACM Workshop on Security and Privacy in Smartphones & Mobile Devices (SPSM), 2013.

39.

Sogou Mobile IME. https://play.google.com/store/apps/details?id=com.sohu.inputmethod.sogou.

40.

Spreitzer, PIN skimming: Exploiting the ambient-light sensor in mobile devices, in: Proceedings of the 4th ACM Workshop on Security and Privacy in Smartphones & Mobile Devices (SPSM), 2014.

41.

Suenaga, IME as a possible keylogger, Virus Bulletin (2005), 6–10.

42.

SwiftKey Keyboard. https://play.google.com/store/apps/details?id=com.touchtype.swiftkey.

43.

Top 1000 Verbs. http://www.talkenglish.com/Vocabulary/Top-1000-Verbs.aspx.

44.

Top 500 Apps in China by Monthly Active Users in Apr 2017. http://www.iresearchchina.com/content/details7_33344.html.

45.

TouchPal. https://play.google.com/store/apps/details?id=com.cootek.smartinputv5.

46.

Tsafrir,

Hertz,

Wagner and

D.D.

Silva, Portably solving file TOCTTOU races with hardness amplification, in: Proceedings of the 6th USENIX Conference on File and Storage Technologies (FAST), 2008.

47.

UserDictionary. http://developer.android.com/reference/android/provider/UserDictionary.html.

48.

Wang,

T.T.

Lai and

R.R.

Choudhury, MoLe: Motion leaks through smartwatch sensors, in: Proceedings of the 21st Annual International Conference on Mobile Computing and Networking (MobiCom), 2015.

49.

Wang,

Xing,

Wang and

Chen, Unauthorized origin crossing on mobile platforms: Threats and mitigation, in: Proceedings of the 20th ACM Conference on Computer and Communications Security (CCS), 2013.

50.

Wei and

Pu, TOCTTOU vulnerabilities in UNIX-style file systems: An anatomical study, in: Proceedings of the 4th Conference on File and Storage Technologies (FAST), 2005.

51.

Welton, Remote Code Execution as System User on Samsung Phones Summary, 2015. https://www.nowsecure.com/blog/2015/06/16/remote-code-execution-as-system-user-on-samsung-phones/.

52.

WindowManager.LayoutParams. http://developer.android.com/reference/android/view/WindowManager.LayoutParams.html.

53.

Xu, Android Installer Hijacking Vulnerability Could Expose Android Users to Malware, 2015. http://researchcenter.paloaltonetworks.com/2015/03/android-installer-hijacking-vulnerability-could-expose-android-users-to-malware/.

54.

Xu,

Bai and

Zhu, TapLogger: Inferring user inputs on smartphone touchscreens using on-board motion sensors, in: Proceedings of the Fifth ACM Conference on Security and Privacy in Wireless and Mobile Networks (WiSec), 2012.

55.

Yang,

Cui,

S.J.

Stolfo and

Sethumadhavan, Concurrency attacks, in: Proceedings of the 4th USENIX Workshop on Hot Topics in Parallelism (HotPar), 2012.

Accessing mobile user’s privacy based on IME personalization: Understanding and practical attacks 1 2

Abstract

Keywords

1. Introduction

3 We use IME and IME app interchangeably in this paper.

2.1. Personalized user dictionary and privacy

4 Android designs a global provider UserDictionary and the corresponding permissions for personalized dictionaries [47]. However, except the IMEs developed by Google, all the other third-party IMEs prefer to control user dictionaries by themselves and do not intend to share these data.

3.1. Android KeyEvent processing flow

5 IME accepts another kind of input event – MotionEvent [28], coming from the soft keyboard (see Fig. 1). Its processing flow is different and not covered in this paper.

7 We found only one vulnerability disclosure by Palo Alto Networks’ researchers [53] regarding TOCTTOU on Android, which was reported in March 2015.

4.2. Attack in stealthy mode

8 The initial set: { w , y , b , p , m , f , d , t , n , l , g , k , h , j , q , x , z h , c h , s h , r , z , c , s } .

5.1. Scope of attack

5.3. Experiment on word completion attack mode

9 The experiments have followed the IRB rules, and all human subjects fully understood the privacy implication of the experiments and agreed to participate.

Table 5 Next-word Prediction Attack: simulation experiment

6.1. Defense

7. Related works

7.1. IME security issues

7.2. Keystroke inference attacks

7.3. Untrusted input

8. Conclusion

Footnotes

Acknowledgments

Quantifying the information leakage

References

³
We use IME and IME app interchangeably in this paper.

⁴
Android designs a global provider UserDictionary and the corresponding permissions for personalized dictionaries [47]. However, except the IMEs developed by Google, all the other third-party IMEs prefer to control user dictionaries by themselves and do not intend to share these data.

⁵
IME accepts another kind of input event – MotionEvent [28], coming from the soft keyboard (see Fig. 1). Its processing flow is different and not covered in this paper.

⁷
We found only one vulnerability disclosure by Palo Alto Networks’ researchers [53] regarding TOCTTOU on Android, which was reported in March 2015.

⁸
The initial set: ${w, y, b, p, m, f, d, t, n, l, g, k, h, j, q, x, z h, c h, s h, r, z, c, s}$ .

⁹
The experiments have followed the IRB rules, and all human subjects fully understood the privacy implication of the experiments and agreed to participate.

Table 5
Next-word Prediction Attack: simulation experiment