手機收購yload of each HTTP request sent to pinyin.voicecloud.cn with the following algorithm. Let s be the current time in seconds since the Unix epoch at the time of the request. For each request, an 8-byte encryption key is then derived by first performing the following computation:
x = (s % 0x5F5E100) ^ 0x1001111
The 8-byte key k is then derived from x as the lowest 8 ASCII-encoded digits of x, left-padded with leading zeroes if necessary, in big-endian order. In Python, the above can be summarized by the following expression:
k = b’%08u’ % ((s % 0x5F5E100) ^ 0x1001111)
The payload of the request is then padded with PKCS#7 padding and then encrypted with DES using key k in ECB mode. The value s is transmitted in the HTTP request in the clear as a GET parameter named “time”.
Since DES is a symmetric encryption algorithm, the same key used to encrypt a message can also be used to decrypt it. Since k can be easily derived from s and since s is transmitted in the clear in every HTTP request encrypted by k, any network eavesdropper can easily decrypt the contents of each HTTP request encrypted in the manner described above. (Since s is simply the time in single second resolution, it also stands to reason that a network eavesdropper would have general knowledge of s in any case.)
We found that users’ keystrokes were transmitted in a protobuf serialization and encrypted in this manner (see Figure 6). Therefore, a network eavesdropper who is eavesdropping on a user’s network traffic can observe what that user is typing by taking advantage of this vulnerability.
1: 0
2: 0
3: 49
4: “xxxxx”
5: 0
7 {
1: “app_id”
2: “100IME”
}
7 {
1: “uid”
2: “230817031752396418”
}
7 {
1: “cli_ver”
2: “12.1.14983”
}
7 {
1: “net_type”
2: “wifi”
}
7 {
1: “OS”
2: “android”
}
8: 8
Figure 6:
Decrypted information revealing what we had typed (“xxxxx”).
Finally, the DES encryption algorithm is an older encryption algorithm with known weaknesses, and the ECB block cipher mode is a simplistic and problematic cipher mode. The use of each of these technologies is problematic in itself and opens the Android version of iFlytek IME’s communications to additional attacks.
Samsung
We analyzed Samsung Keyboard on Android as well as the versions of Sogou IME and Baidu IME that Samsung bundled with our test device, an SM-T220 tablet running ROM version T220CHN4CWF4. We found that Samsung Keyboard for Android and Samsung’s bundled version Baidu IME includes a vulnerability that allows network eavesdroppers to recover the plaintext of insufficiently encrypted network transmissions, revealing sensitive information including what users have typed (see Table 5 for details).
Platform
Application name
Package name
Version analyzed
Secure?
OneUI 5.1
Samsung Keyboard
com.samsung.android.honeyboard
5.6.10.26
✘✘
OneUI 5.1
百度输入法 (Baidu IME)
com.baidu.input
8.5.20.4
✘✘
OneUI 5.1
搜狗输入法三星版 (Sogou IME Samsung Version)
com.sohu.inputmethod.sogou.samsung
10.32.38.202307281642
✔
Table 5: The keyboards analyzed on our Samsung test device.
Samsung Keyboard (com.samsung.android.honeyboard)
We found that when using Samsung Keyboard on the Chinese edition of a Samsung device and when Pinyin is chosen as Samsung Keyboard’s input language, Samsung Keyboard transmits keystroke data to the following URL in the clear via HTTP POST:
http://shouji.sogou.com/web_ime/mobile_pb.php?durtot=339&h=8f2bc112-bbec-3f96-86ca-652e98316ad8&r=android_oem_samsung_open&v=8.13.10038.413173&s=&e=&i=&fc=0&base=dW5rbm93biswLjArMC4w&ext_ver=0
The keystroke data is contained in the request’s HTTP payload in a protobuf serialization (see Figure 7 below).
1 {
1: “8f2bc112-bbec-3f96-86ca-652e98316ad8”
2: “android_oem_samsung_open”
3: “8.13.10038.413173”
4: “999”
5: 1
7: 2
}
2 {
1: “\351\000”
2: “\372\213”
}
4: “com.tencent.mobileqq”
7: “nihaocanyoureadthis”
16: 10
17 {
3 {
1: 1
2: 5
}
5: 1
9: 1
}
18: “”
19 {
1: “0”
4: “339”
}
Figure 7:
Protobuf message transmitted after typing “nihaocanyoureadthis”.
The device on which we were testing was fully updated on the date of testing (October 7, 2023) in that it had all OS updates applied and had all updates from the Samsung Galaxy Store applied.
Since Samsung Keyboard transmits keystroke data via plain, unencrypted HTTP and since there is no encryption applied at any other layer, a network eavesdropper who is monitoring a Samsung Keyboard user’s network traffic can easily observe that user’s keystrokes if that user is using the Chinese edition of the ROM with the Pinyin input language selected.
When using the global edition of the ROM or when using a non-Pinyin input language, we did not observe the Samsung keyboard communicating with cloud servers.
百度输入法 (“Baidu IME”, com.baidu.input)
We found that the version of Baidu IME bundled with our Samsung test device transmitted keystroke information via UDP packets to udpolimenew.baidu.com. This version of Baidu IME used the BAIDUv3.1 protocol that we describe in the Baidu section earlier but with a different cipher and compression algorithm as indicated in each transmission’s header. In the remainder of this section we explain how a network eavesdropper can, just like with AESv2, decrypt the contents of messages encrypted using a scheme we call BAIDUv3.1+AESv1 (see Table 6).
Protocol
Scheme
Cipher
Mode
Comparison of cipher to AES
BAIDUv3.1
BAIDUv3.1+AESv1
AESv1
ECB
Additional permutations
BAIDUv3.1+AESv2
AESv2
ECB
Missing round
BAIDUv4.0
BAIDUv4.0+AESv3
AESv3
BCTR
Uses home-rolled cipher mode
Table 6: Summary of ciphers used across different Baidu protocols.
Samsung’s bundled version of Baidu IME encrypts keystrokes using a modified version of AES which we name AESv1, as we believe it to be the predecessor to Baidu’s AESv2. When encrypting, AESv1’s key expansion is like that of standard AES, except, on each but the first subkey, the order of the subkey’s bytes are additionally permuted. Furthermore, on the encryption of each block, the bytes of the block are additionally permuted in two locations, once near the beginning of the block’s encryption immediately after the block has been XOR’d by the first subkey and again near the end of the block’s encryption immediately before S-box substitution. Aside from complicating our analysis, we are not aware of these modifications altering the security properties of AES, and we have developed an implementation of this algorithm to both encrypt and decrypt messages given a plaintext or ciphertext and a key.
Samsung’s bundled version of Baidu IME encrypts keystrokes by applying AESv1 in electronic codebook (ECB) mode in the following manner. First, the app uses the fixed 128-bit key, kf = “\xff\x9e\xd5H\x07Z\x10\xe4\xef\x06\xc7.\xa7\xa2\xf26”, to encrypt another, generated, key, km. The fixed key kf is the same key the BAIDUv3.1 protocol uses for AESv2 (see Figure 4). The encryption of km is stored in bytes 64 until 80 of each UDP packet’s payload. The key km is then used to encrypt the remainder of a zlib-compressed message payload, which is stored at byte 80 until the end of the UDP payload. We found that the encrypted payload included, in a binary container format which we did not recognize, our typed keystrokes as well as the name of the application into which we were typing them (see Figure 8).
0: [800,
1276,
10,
0,
“92F8EE78F1DDCBE74CFEB1166F70883D%7C0”,
“a1|SM-T220-gta7litewifi|320”,
“8.5.20.4”,
“com.android.settings.intelligence”,
“1012497q”,
“”,
“2你好惨又热大腿”,
“”],
1: [0, “”, “nihaocanyoureadthis”]
Figure 8:
The decrypted and decompressed payload, revealing what we had typed (“nihaocanyoureadthis”, highlighted) and the app into which it was typed (“com.android.settings.intelligence”); on top is a hex dump of, when decrypted and decompressed, the resulting proprietary binary blob, and below it is our understanding of how to parse it.
A vulnerability exists in the BAIDUv3.1+AESv1 scheme that allows a network eavesdropper to decrypt the contents of these messages. Since AES, including AESv1, is a symmetric encryption algorithm, the same key used to encrypt a message can also be used to decrypt it. Since kf is hard-coded, any network eavesdropper with knowledge of kf can decrypt km and thus decrypt the plaintext contents of each message encrypted in the manner described above. As we found that users’ keystrokes and the names of the applications they were using were sent in these messages, a network eavesdropper who is eavesdropping on a user’s network traffic can observe what that user is typing and into which application they are typing it by taking advantage of this vulnerability.
Additionally, in the version of Baidu Input Method distributed by Samsung, we found that key km was not securely generated using a secure pseudorandom number generator (secure PRNG). Instead, it was seeded using a custom-designed PRNG that we believe to have poor security properties, and, instead of using a high entropy seed, the PRNG generating km was seeded using the message plaintext. However, even without these weaknesses in the generation of km, the protocol is already completely insecure to network eavesdroppers as described in the previous paragraphs.
Huawei
We analyzed the keyboards preinstalled on our Huawei Mate 50 Pro test device. We found no vulnerabilities in the manner of transmission of users’ keystrokes in the versions of Huawei’s keyboard apps that we analyzed (see Table 7 for details). Specifically, Huawei used TLS to encrypt keystrokes in each version that we analyzed.
Platform
Application name
Package Name
Version analyzed
Secure?
HarmonyOS 4.0.0
搜狗输入法 (Sogou IME)
com.sohu.inputmethod.sogou
11.31
✔
HarmonyOS 4.0.0
小艺输入法 (Celia IME)
com.huawei.ohos.inputmethod
1.0.19.333
✔
Table 7: The versions of the Huawei keyboard apps analyzed.
Xiaomi
We analyzed the keyboards preinstalled on our Xiaomi Mi 11 test device. We found that they all include vulnerabilities that allow network eavesdroppers to decrypt network transmissions from the keyboards (see Table 8 for details). This means that network eavesdroppers can obtain sensitive personal information, including what users have typed.
Platform
Application name
Package Name
Version analyzed
Secure?
MIUI 14.0.31
百度输入法小米版 (Baidu IME Xiaomi Version)
com.baidu.input_mi
10.6.120.480
✘✘
MIUI 14.0.31
搜狗输入法小米版 (Sogou IME Xiaomi Version)
com.sohu.inputmethod.sogou.xiaomi
10.32.21.202210221903
✘
MIUI 14.0.31
讯飞输入法小米版 (iFlytek IME Xiaomi Version)
com.iflytek.inputmethod.miui
8.1.8014
✘✘
Table 8: The versions of the Xiaomi keyboard apps analyzed.
In this section we detail vulnerabilities in three different keyboard apps included with MIUI 14.0.31 in which users’ keystrokes can be, if necessary, decrypted, and read by network eavesdroppers.
百度输入法小米版 (“Baidu IME Xiaomi Version”, com.baidu.input_mi)
We found that Xiaomi’s Baidu-based keyboard app encrypts keystrokes using the BAIDUv3.1+AESv2 scheme which we detailed previously. When the app’s messages are decrypted and deserialized, we found that they include our typed keystrokes as well as the name of the application into which we were typing them (see Figure 9).
[…]
2 {
1: “nihaonihaoqqwerty”
}
3 {
1: 53
2: 10
3: 1080
4: 2166
5: 5
}
4 {
1: “DC0F75E6809F0FAAB46EDE2F2D6302ED%7CVAPBN4NOH”
2: “p-a1-3-66|2211133C|720”
3: “10.6.120.480”
4: “com.miui.notes”
5: “1000228c”
6: “\346\242\205\345\267\236”
}
[…]
Figure 9:
Excerpt of decrypted information, including what we had typed (“nihaonihaoqqwerty”) and the application into which it was typed (“com.miui.notes”).
Like we explained previously, a vulnerability exists in the BAIDUv3.1+AESv2 scheme that allows a network eavesdropper to decrypt the contents of these messages. As we found that users’ keystrokes and the names of the applications they were using were sent in these messages, a network eavesdropper who is eavesdropping on a user’s network traffic can observe what that user is typing and into which application they are typing it by taking advantage of this vulnerability.
搜狗输入法小米版 (“Sogou IME Xiaomi Version”, com.sohu.inputmethod.sogou.xiaomi)
The Sogou-based keyboard app is subject to a vulnerability which we have already publicly disclosed in Sogou IME (搜狗输入法) in which a network eavesdropper can decrypt and recover users’ transmitted keystrokes. Please see the corresponding details in this report for full details. Tencent responded by securing Sogou IME transmissions using TLS, but we found that Xiaomi’s Sogou-based keyboard had not been fixed.
讯飞输入法小米版 (“iFlytek IME Xiaomi Version”, com.iflytek.inputmethod.miui)
Similar to iFlytek’s own IME for Android, we found that Xiaomi’s iFlytek keyboard app used the same faulty encryption. We found that users’ keystrokes were sent to pinyin.voicecloud.cn and encrypted in this manner.
{“p”:{“m”:53,”f”:0,”l”:0},”i”:”nihaoniba”}
Figure 10:
Excerpt of decrypted information, including what we had typed (“nihaoniba”).
Therefore, a network eavesdropper who is eavesdropping on a user’s network traffic can observe what that user is typing by taking advantage of this vulnerability (see Figure 10).
手機收購oppo
We analyzed the keyboard apps preinstalled on our 手機收購oppo OnePlus Ace test device. We found that they all include vulnerabilities that allow network eavesdroppers to decrypt network transmissions from the keyboards (see Table 9 for details). This means that network eavesdroppers can obtain sensitive personal information, including what users have typed.
Platform
Application name
Package Name
Version analyzed
Secure?
ColorOS 13.1
百度输入法定制版 (Baidu IME Custom Version)
com.baidu.input_手機收購oppo
8.5.30.503
✘✘
ColorOS 13.1
搜狗输入法定制版 (Sogou IME Custom Version)
com.sohu.inputmethod.sogouoem
8.32.0322.2305171502
✘
Table 9: The versions of the 手機收購oppo keyboard apps analyzed.
In this section we detail vulnerabilities in two different keyboard apps included with MIUI 14.0.31 in which users’ keystrokes can be, if necessary, decrypted, and read by network eavesdroppers.
百度输入法定制版 (“Baidu IME Custom Version”, com.baidu.input_手機收購oppo)
We found that 手機收購oppo’s Baidu-based keyboard app encrypts keystrokes using the BAIDUv3.1+AESv2 scheme which we detailed previously. When the app’s messages are decrypted and deserialized, we found that they include our typed keystrokes as well as the name of the application into which we were typing them (see Figure 11).
[…]
2 {
1: “nihaonihao”
}
3 {
1: 28
2: 10
3: 1240
4: 2662
5: 5
}
4 {
1: “47148455BDAEBA8A253ACBCC1CA40B1B%7CV7JTLNPID”
2: “p-a1-5-105|PHK110|720”
3: “8.5.30.503”
4: “com.android.mms”
5: “1021078a”
}
[…]
Figure 11:
Excerpt of decrypted information, including what we had typed (“nihaonihao”) and the application into which it was typed (“com.android.mms”).
Like we explained previously, a vulnerability exists in the BAIDUv3.1+AESv2 scheme that allows a network eavesdropper to decrypt the contents of these messages. As we found that users’ keystrokes and the names of the applications they were using were sent in these messages, a network eavesdropper who is eavesdropping on a user’s network traffic can observe what that user is typing and into which application they are typing it by taking advantage of this vulnerability.
搜狗输入法定制版 (“Sogou IME Custom Version”, com.sohu.inputmethod.sogouoem)
The Sogou-based keyboard app is subject to a vulnerability which we have already publicly disclosed in Sogou IME (搜狗输入法) in which a network eavesdropper can decrypt and recover users’ transmitted keystrokes. Please see the corresponding details in this report for full details. Tencent responded by securing Sogou IME transmissions using TLS, but we found that 手機收購oppo’s Sogou-based keyboard had not been fixed.
Vivo
We analyzed the keyboard apps preinstalled on our Vivo Y78+ test device. We found that the Sogou-based one includes vulnerabilities that allow network eavesdroppers to decrypt network transmissions from the keyboards (see Table 10 for details). This means that network eavesdroppers can obtain sensitive personal information, including what users have typed.
Platform
Keyboard name
Package Name
Version analyzed
Secure?
origin OS 3
搜狗输入法定制版 (Sogou IME Custom Version)
com.sohu.inputmethod.sogou.vivo
10.32.13023.2305191843
✘
origin OS 3
Jovi输入法 (Jovi IME)
com.vivo.ai.ime
2.6.1.2305231
✔
Table 10: The versions of the Vivo keyboard apps analyzed.
The Sogou-based keyboard app is subject to a vulnerability which we have already publicly disclosed in Sogou IME (搜狗输入法) in which a network eavesdropper can decrypt and recover users’ transmitted keystrokes. Please see the corresponding details in this report for full details. Tencent responded by securing Sogou IME transmissions using TLS, but we found that Vivo’s Sogou-based keyboard had not been fixed.
Honor
We analyzed the keyboard apps preinstalled on our Honor Play7T test device. We found that the Baidu-based one includes vulnerabilities that allow network eavesdroppers to decrypt network transmissions from the keyboards (see Table 11 for details). This means that network eavesdroppers can obtain sensitive personal information, including what users have typed.
Platform
Application name
Package Name
Version analyzed
Secure?
Magic UI 6.1.0
百度输入法荣耀版 (Baidu IME Honor Version)
com.baidu.input_hihonor
8.2.501.1
✘✘
Table 11: The versions of the Honor keyboard apps analyzed.
We found that Honor’s Baidu-based keyboard app encrypts keystrokes using the BAIDUv3.1+AESv2 scheme which we detailed previously. When the app’s messages are decrypted and deserialized, we found that they include our typed keystrokes as well as the name of the application into which we were typing them (see Figure 12).
[…]
2 {
1: “nihaonihaonihaoq”
5: 6422639
}
3 {
1: 91
2: 10
3: 720
4: 1552
5: 5
}
4 {
1: “A49AD3D3789A136975C2B28201753F03%7C0”
2: “p-a1-5-115|RKY-AN10|720”
3: “8.2.501.1”
4: “com.hihonor.mms”
5: “1023233d”
7: “A00-TWGTFEV5OFZ7WZ2AFN5TCDE4BPNO7XRZ-BVEZBI4D”
}
[…]
Figure 12:
Excerpt of decrypted information, including what we had typed (“nihaonihaonihaoq”) and the application into which it was typed (“com.hihonor.mms”).
Like we explained previously, a vulnerability exists in the BAIDUv3.1+AESv2 scheme that allows a network eavesdropper to decrypt the contents of these messages. As we found that users’ keystrokes and the names of the applications they were using were sent in these messages, a network eavesdropper who is eavesdropping on a user’s network traffic can observe what that user is typing and into which application they are typing it by taking advantage of this vulnerability.
As of April 1, 2024, “Baidu IME Honor Version”, the default IME on the Honor device we tested, is still vulnerable to passive decryption. We also discovered that on our Play7T device, there was no way to update “Baidu IME Honor Version” through the device’s app store. In responding to our disclosures, Honor asked us to disclose to Baidu and that it was Baidu’s responsibility to patch this issue.
Other affected keyboard apps
Given our limited resources to analyze apps, we were not able to analyze every cloud-based keyboard app available. Nevertheless, given that these vulnerabilities appeared to affect APIs that were used by multiple apps, we wanted to approximate the total number of apps affected by these vulnerabilities.
We began by searching VirusTotal, a database of software and other files that have been uploaded for automated virus scanning, for Android apps which reference the string “get.sogou.com”, the API endpoint used by Sogou IME, as these apps may require additional investigation to determine whether they are vulnerable. Excluding apps that we analyzed above, this search yielded the following apps:
com.sohu.sohuvideo
com.tencent.docs
com.sogou.reader.free
com.sohu.inputmethod.sogou.samsung
com.sogou.text
com.sogou.novel
com.sogo.appmall
com.blank_app
com.sohu.inputmethod.sogou.nubia
com.sogou.androidtool
com.sohu.inputmethod.sogou.meizu
com.sohu.inputmethod.sogou.zte
sogou.mobile.explorer.hmct
sogou.mobile.explorer
com.sogou.translatorpen
com.sec.android.inputmethod.beta
com.sohu.inputmethod.sogou.meitu
com.sec.android.inputmethod
sogou.mobile.explorer.online
com.sohu.sohuvideo.meizu
com.sohu.inputmethod.sogou.oem
com.sogou.map.android.maps
sogou.llq.online
com.sohu.inputmethod.sogou.coolpad
com.sohu.inputmethod.sogou.chuizi
com.sogou.toptennews
com.sogou.recmaster
com.meizu.flyme.input
We have not analyzed these apps and thus cannot conclude that they are necessarily vulnerable, or even keyboard apps, but we provide this list to help reveal the possible scope of the vulnerabilities that we discovered. When we disclosed this list to Tencent, Tencent requested an additional three months to fix the vulnerabilities before we publicly disclosed this list, suggesting credence to the idea that apps in this list are largely vulnerable. Similarly, after excluding apps that we had already analyzed, the following are other Android apps which reference the strings “udpolimenew.baidu.com” or “udpolimeok.baidu.com”, the API endpoints used by Baidu Input Method:
com.adamrocker.android.input.simeji
com.facemoji.lite.xiaomi.gp
com.facemoji.lite.xiaomi
com.preff.kb.xm
com.facemoji.lite.transsion
com.txthinking.brook
com.facemoji.lite.vivo
com.baidu.input_huawei
com.baidu.input_vivo
com.baidu.input_oem
com.preff.kb.op
com.txthinking.shiliew
mark.via.gp
com.qinggan.app.windlink
com.baidu.mapauto
These findings suggest that a large ecosystem of apps may be affected by the vulnerabilities that we discovered in this report.
Coordinated disclosure
We reported the vulnerabilities that we discovered to each vendor in accordance with our vulnerability disclosure policy. All companies except Baidu1, Vivo, and Xiaomi responded to our disclosures. Baidu fixed the most serious issues we reported to them shortly after our disclosure, but Baidu has yet to fix all issues that we reported to them. The mobile device manufacturers whose preinstalled keyboard apps we analyzed fixed issues in their apps except for their Baidu apps, which either only had the most serious issues addressed or, in the case of Honor, did not address any issues (see Table 12 for details). Regarding QQ Pinyin, Tencent indicated that “with the exception of end-of-life products, we aim to finalize the upgrade for all active products to transmit EncryptWall requests via HTTPS by the conclusion of Q1 [2024]”, but, as of April 1, 2024, we have not seen any fixes to this product. Tencent may consider QQ Pinyin end-of-life as it has not received updates since 2020, although we note that it is still available for download. For timelines and full correspondence of our disclosures to each vendor, please see the Appendix.
Legend
✘✘
working exploit created to decrypt transmitted keystrokes for both active and passive eavesdroppers
✘
working exploit created to decrypt transmitted keystrokes for an active eavesdropper
!
weaknesses present in cryptography implementation
✔
no known issues or all known issues fixed
N/A
product not offered or not present on device analyzed
Keyboard developer
Android
iOS
Windows
Tencent†
✘
N/A
✘
Baidu
!
!
!
iFlytek
✔
✔
✔
Pre-installed keyboard developer
Device manufacturer
Own
Sogou
Baidu
iFlytek
iOS
Windows
Samsung
✔
✔*
!
N/A
N/A
N/A
Huawei
✔*
✔
N/A
N/A
N/A
N/A
Xiaomi
N/A
✔*
!
✔
N/A
N/A
手機收購oppo
N/A
✔
!*
N/A
N/A
N/A
Vivo
✔*
✔
N/A
N/A
N/A
N/A
Honor
N/A
N/A
✘✘*
N/A
N/A
N/A
* Default keyboard app on our test device.
† Both QQ Pinyin and Sogou IME are developed by Tencent; in this report we analyzed QQ Pinyin and found the same issues as we had in Sogou IME.
Table 12: Status of vulnerabilities after disclosure as of April 1, 2024.
To summarize, we no longer have working exploits against any products except Honor’s keyboard app and Tencent’s QQ Pinyin. Baidu’s keyboard apps on other devices continue to contain weaknesses in their cryptography which we are unable to exploit at this time to fully decrypt users’ keystrokes in transit.
Barriers to users receiving security updates
Users can receive updates to their keyboard apps on their phones’ app stores, and such updates typically install in the background without user intervention. In our testing, updating keyboard apps was typically performed without friction. However, in some cases, a user may need to also ensure that they have fully updated their operating system before they will receive the fixes to our reported vulnerabilities for their keyboard app through the app store. In the case of the Honor device we tested, there was no update mechanism for the default keyboard used by the operating system through the app store. Honor devices bundled with a vulnerable version of the keyboard will remain vulnerable to passive decryption. In the case of the Samsung Galaxy Store, we found that on our device a user must sign in with a Samsung account before receiving security updates to their keyboard app. In the case the user does not have a Samsung account, then they must create one. We believe that installing important security updates should be frictionless, and we recommend that Samsung and app stores in general not require the registration of a user account before receiving important security updates.
We also learned from communication with Samsung’s security team that our test device had been artificially stuck on an older version of Baidu IME (version 8.5.20.4) compared to the one in the Samsung Galaxy Store. This is because, although the test device was using a Chinese ROM, we were prevented from receiving updates to Baidu IME because the app was geographically unavailable in Canada, where we were testing from. Samsung addressed this issue by adding Baidu’s keyboard app to the global market. Generally speaking, we recommend that Samsung and other app stores do not geoblock security updates to apps that are already installed.
Language barriers in responsible disclosures
We suspect that a language barrier may have prevented iFlytek from responding to our initial disclosure in English. After we did not receive a response for one month, we re-sent the same disclosure e-mail, but with a subject line and one-sentence summary in simplified Chinese. iFlytek responded within three days of this second email and promptly fixed the issues we noted. All future disclosure emails to the Chinese mobile device manufacturers were then written with Chinese subject lines and a short summary in Chinese. Though obvious in hindsight, we encourage security researchers to consider if the company to which they are disclosing uses a different language than the researcher. We suggest submitting vulnerability disclosures, at the very least, with short summaries and email subject lines in the official language of the company’s jurisdiction to prevent similar delays as we may have encountered in disclosure timelines.
Limitations
In this report we detail vulnerabilities relating to the security of the transmission of users’ keystrokes in multiple keyboard apps. In this work we did not perform a full audit of any app or make any attempt to exhaustively find every security vulnerability in any software. Our report concerns analyzing keyboard apps for a class of vulnerabilities that we discovered, and the absence of our reporting of other vulnerabilities should not be considered evidence of their absence.
Discussion
In this section we discuss the impact of the vulnerabilities that we found, speculate as to the factors that gave rise to them, and conclude by introducing possible ways to systemically prevent such vulnerabilities from arising in the future.
Impact of these vulnerabilities
The scope of these severe vulnerabilities cannot be overstated: until this and our previous Sogou report, the majority of Chinese mobile users’ keystrokes were decryptable by network adversaries. The keyboards we studied comprise over 95% of the third-party IME market share, which is estimated to be over 780 million users by marketing agencies. In addition, the three phone manufacturers which pre-installed and by default used vulnerable keyboard apps comprise nearly 50% of China’s smartphone market.
The vulnerabilities that we discovered would be inevitably discovered by anyone who thinks to look for them. Furthermore, the vulnerabilities do not require technological sophistication to exploit. With the exception of the vulnerability affecting many Sogou-based keyboard apps that we previously discovered, all of the vulnerabilities that we covered in this report can be exploited entirely passively without sending any additional network traffic. This also means any existing logs of network data sent by these keyboards can be decrypted in the future. As such, we might wonder, are these vulnerabilities actively under mass exploitation?
Figure 13: Locations of XKEYSCORE servers as described in a 2008 NSA slide deck.
While many governments may possess sophisticated mass surveillance capabilities, the Snowden revelations gave us unique insight into the capabilities of the United States National Security Agency (NSA) and more broadly the Five Eyes. The revelations disclosed, among other programs, an NSA program called XKEYSCORE for collecting and searching Internet data in realtime across the globe (see Figure 13). Leaked slides describing the program specifically reveal only a few examples of XKEYSCORE plugins. However, one was a plugin that was written by a Five Eyes team to take advantage of vulnerabilities in the cryptography of Chinese-developed UC Browser to enable the Five Eyes to collect device identifiers, SIM card identifiers, and account information pertaining to UC Browser users (see Figure 14 for an illustration).
Figure 14: The dashboard of an XKEYSCORE plugin used to monitor for transmissions of sensitive data insufficiently encrypted by UC Browser as described in a 2012 Five Eyes slide deck.
The similarity of the vulnerability exploited by this XKEYSCORE plugin and the vulnerabilities described in this report are uncanny, as they are all vulnerabilities in the encryption of sensitive data transmissions in software predominantly used by Chinese users. Given the known capabilities of XKEYSCORE, we surmise that the Five Eyes would have the capability to globally surveil the keystrokes of all of the keyboard apps that we analyzed with the exception of Sogou and the apps licensing its software. This single exception exists because Sogou cannot be monitored passively and would require sending packets to Sogou servers. Such communications would be measurable at Sogou’s servers and at other vantage points, potentially revealing the Five Eyes’s target(s) of surveillance to Sogou or Chinese network operators. Therefore, targets of outdated Sogou software would be undesirable victims of mass surveillance, even if such non-passive measurements were within the known capabilities of XKEYSCORE or other Five Eyes programs.
Given the enormous intelligence value of knowing what users are typing, we can conclude that not only do the NSA and more broadly the Five Eyes have the capabilities to mass exploit the vulnerabilities we found but also the strong motivation to exploit them. If the Five Eyes’ capabilities are an accurate reflection of the capabilities and motivations of other governments, then we can assume that many other governments are also capable and motivated to mass exploit these vulnerabilities. The only remaining question is whether any government had knowledge of these vulnerabilities. If they did not have such knowledge before our original report analyzing Sogou, they may have acquired after it in the same way that our original research inspired us to look at similar keyboard apps for analogous vulnerabilities. Unfortunately, short of future government leaks, we may never know if or to what extent any state actors mass exploited these vulnerabilities.
Even though we disclosed the vulnerabilities to vendors, some vendors failed to fix the issues that we reported. Moreover, users of devices which are out of support or that otherwise no longer receive updates may continue to be vulnerable. As such, many users of these apps may continue to be under mass surveillance for the foreseeable future.
How did these vulnerabilities arise
We analyzed a broad sample of Chinese keyboard apps, finding that they are almost universally vulnerable to having their users’ keystrokes being decrypted by network eavesdroppers. Yet there is no common library or a single implementation flaw responsible for these vulnerabilities. While some of the keyboard apps did license their code from other companies, our overall findings can only be explained by a large number of developers independently making the same kind of mistake. As such, we might ask, how could such a large number of independent developers almost universally make such a critical mistake?
One attempt to answer this question is to suggest that these were not mistakes at all but deliberate backdoors introduced by the Chinese government. However, this hypothesis is rather weak. First, user keystroke data is already being sent to servers within Chinese legal jurisdiction, and so the Chinese government would have access to such data anyways. Second, the vulnerabilities that we found give the ability not just to the Chinese government to decrypt transmitted keystrokes but to any other actor as well. In an ideal backdoor, the Chinese government would want the desirable property that only they have access to the backdoor. Finally, the Chinese government has made strides to study and improve the data security of apps developed and used in China, attempting to prevent and fix the very sort of vulnerabilities which we discovered. For instance, a 2020 report from CNCERT/CC found that 60 percent of the 50 banking applications that they investigated did not encrypt any user data transmitted over the network, among a litany of other common security issues.
Were Chinese app developers skeptical of using cryptographic standards perceived as “Western”? Countries such as China and Russia have their own encryption standards and ciphers. To our knowledge none of the faulty encryption implementations that we analyzed adhered to any sort of known standard in any country, and each appeared to be home-rolled ciphers. However, it is possible that Asian developers are less inclined to use encryption standards that they fear may contain backdoors such as the potential Dual_EC_DRBG backdoor.
Perhaps Chinese app developers could be skeptical of standards such as SSL/TLS as well. The TLS ecosystem has also only become nearly-universal in the past decade. Especially before broad oversight of certificate authorities became commonplace, there were many valid criticisms of the SSL/TLS ecosystem. In 2011, digital rights organizations EFF and Access Now were both concerned about the certificate authority (CA) infrastructure underpinning SSL/TLS transport encryption. Even today, the vast majority of root certificates trusted by major OSes and browsers are operated by certificate authorities based in the Global North. We also note that all of the IMEs containing vulnerabilities were first released before 2013 and likely had a need for secure network transmission before SSL/TLS became the de-facto standard for strong transport encryption.
Still, it has been a decade since the Snowden leaks demonstrated the global, urgent, and practical need for strong encryption of data-in-transit in 2013, and the TLS ecosystem has largely stabilized, with CA root lists of many major browsers and OSes controlled by voting bodies and certificate transparency deployed. As of 2024, almost 95% of web traffic from users of Firefox in the United States is traveling over HTTPS. In addition, the speed in which both iFlytek and Sogou switched to TLS demonstrates that making the change to standard TLS is not necessarily a time or resource issue. Even if skepticism towards SSL/TLS explains the reluctance to adopt it in the early 2010s, we are not sure why there is much more inertia in the Chinese Internet ecosystem against making the switch to TLS.
Finally, mobile devices and other operating systems are still incapable of guaranteeing the security of data under transmission, despite iOS and Android having introduced restrictions into their APIs. For instance, iOS 9 implemented App Transport Security, a policy placing restrictions on the ability to transmit data without TLS. However, there are two limitations of this technology. First, an app can specify exceptions to this policy in its Info.plist resource. Second, the policy affects high level APIs and leaves communications over lower level socket-based APIs unregulated. Similar to iOS, Android 9 disables cleartext traffic using certain high level APIs by default, but an app may exclude specific domains or avoid the policy by using lower level APIs.
Can we systemically address these vulnerabilities?
Individually analyzing apps for this class of vulnerabilities and individually reporting issues discovered is limited in the scale of apps that it can fix. First, while we can attempt to manually analyze some of the most popular keyboard apps, we will never be able to analyze every app at large. Second, we might not be able to predict which apps to look at in the first place. For instance, before we analyzed Sogou and the keyboard apps featured in this report, we never would have expected that their network transmissions would be so easily vulnerable to interception. In light of the limitations of the methods that we employed in this report, in the remainder of this section we discuss possibilities for how we might systematically or wholesale address apps which transmit sensitive data over networks without sufficient encryption.
By security researchers paying more attention to the Chinese Internet
There appears to be a general failure of researchers to analyze Chinese apps and the Chinese Internet ecosystem at large, despite its size and influence. The Google Play Store and Apple App Store ecosystems, for instance, are commonly studied by privacy researchers, but many Chinese app stores are overlooked, despite that many popular Chinese apps have more users than their counterparts on the Google Play Store. While the vulnerabilities that we discovered were not all trivial to find and many took substantial analysis to attack, most would have been inevitably discovered by any researcher analyzing these apps for data security. A researcher studying network traffic from users of Chinese devices could also have identified strange, non-standard traffic.
By using app store enforcement
One might call on app stores to enforce the use of sufficient encryption to protect sensitive data in transit. App stores already have a number of rules that they enforce through a combination of automated and manual review. Calling on app stores to enforce sufficient encryption of in-transit sensitive data is tempting given the resources of the companies operating the app stores. However, failing any other innovation, the same scaling issues that apply to other researchers studying these apps will apply to those working for these companies.
By using device permission models
On Android devices, installing any keyboard, regardless of whether or how it communicates with servers over the Internet, brings up a pop-up with the following text:
This input method may be able to collect all the text you type, including personal data like passwords and credit card numbers.
The wording of these warning messages is overbroad and does not necessarily help users distinguish between keyboards that transmit keystrokes over the network, keyboards that transmit keystrokes insecurely (using something other than standard TLS) over the network, and keyboards that do not transmit any data at all.
iOS devices, on the other hand, sandbox their keyboards by default. There is a “Full Access” or “open access” permission that must be explicitly granted to keyboards before they have network access, among other privileges. Without this permission, third-party keyboards cannot transmit network data. We recommend Android also adopt a more fine-grained permission model for keyboards.
Furthermore, the vulnerable apps that we studied transmit data using low level socket APIs versus higher level APIs that require the usage of TLS or HTTPS. One might desire that separate system calls be designed for TLS or HTTPS traffic in addition to the lower level socket system calls so that devices could implement an UNSAFE_INTERNET permission that would be required for apps to use the lower level system calls while still allowing TLS-encrypted traffic for apps that do not have this permission.
While this approach may have some merit, it also has certain drawbacks. It makes sense for situations where apps are untrustworthy and the operating system is completely trustworthy, but there are common situations where the operating system could be not as or even less trustworthy than apps that it is running. One common case would be a user who is running an up-to-date app on an out of date operating system, possibly because the user’s device is no longer receiving operating system updates. In such a case, the app’s implementation of TLS is more likely to be secure than that of the operating system. Furthermore, a user’s operating system may be compromised by malware or otherwise be untrustworthy in itself. Introducing a TLS system call would centralize the encryption of all sensitive data and grant the operating system easy visibility into all unencrypted data. In any case, innovating in areas of encryption is an important right of application developers, and it may not make sense to stifle apps like Signal because of their use of end-to-end or other novel encryption by requiring them to obtain an UNSAFE_INTERNET permission.
One might alternatively desire for apps at large to not be able to access the Internet at all. Instead of an UNSAFE_INTERNET permission, what about introducing an INTERNET permission to govern all Internet socket access, similar to the “Full Access” permission which iOS already applies to keyboard apps? Android devices in fact already have such a permission that apps must request to use Internet (AF_INET) sockets, but it is not a permission that is exposed to ordinary users either in the Google Play Store or through any stock Android user interface, and it is automatically granted when installing an app. Unfortunately, given all of the interprocess communication (IPC) vehicles on modern smart devices, restricting Internet socket access may not guarantee that the app could not communicate over the Internet (e.g., through Google Play services). GrapheneOS, an open source Android-based operating system, implements a NETWORK permission. However, denying this permission can lead to surprising results where apps can still communicate with the Internet via IPC with other apps. As such, we recommend that both the developers of Android and iOS work toward a meaningful INTERNET permission that would adequately inform users of whether an app communicates over the Internet.
By international standards bodies better engaging with Chinese developers
We encourage International standards bodies like the IETF to continue to engage and outreach Chinese Internet companies and engineers in good faith to further reduce friction in cross-linguistic knowledge transfer. The presence of these similar but independent vulnerabilities demonstrate that there is a friction in the transfer and implementation of knowledge between the English-speaking cryptography community and the Chinese cryptography community. For instance, Schneier’s Law or the oft-repeated mantra “don’t roll your own crypto” may be common knowledge to cryptographers trained in English, but perhaps lost in translation. A lag across linguistic boundaries means that general information like the recent stabilization of TLS and webPKI infrastructure may travel more slowly, and updating encryption software to reflect new information may lag even further behind. One other possible example of this phenomenon is that, according to Firefox Telemetry, up until 2020, the Japanese Internet ecosystem also significantly lagged behind the global average in HTTPS adoption.
Although protocols put out by IETF and other International standards bodies can be far from bulletproof, these bodies can still help facilitate international communication about the current state-of-the-art in protocol encryption. The burden of cross-linguistic and cross-cultural exchange on technical standards falls on global standards bodies. Western media outlets and researchers tend to uniformly attribute the actions and participation of private Chinese companies within standards bodies to government actors seeking sovereignty over Internet standards. While skepticism may be warranted in certain cases, there is also research that challenges a simplistic and overbroad narrative. As a single data point, we note that we did not find these issues in Huawei’s keyboards, whose employees are often noted as especially active participants in IETF standard-setting.
By using automated static or dynamic analysis
There has been a failure of automated tools to detect insecure traffic at large. Longitudinal TLS telemetry has largely been focused on web-based perspectives (i.e., how many domains support TLS or how many web connections are encrypted by TLS?), and the mobile perspective is often overlooked, despite the increasing dominance of mobile traffic globally. Although there are some research projects that survey TLS usage in Android mobile apps at scale, there is no public longitudinal data from these projects (i.e., they are run as one-off studies), and many focus on the Google Play’s Android ecosystem, thereby excluding the Chinese mobile Internet. There is perhaps a need for public longitudinal TLS telemetry for popular mobile applications globally, via automated static or dynamic analysis at scale.
By using attestations in app stores
Another way for users to gain visibility into the security and privacy properties of their apps is through the use of developer attestations, such as the ones that appear in data safety sections in many popular app stores. Both the Apple App Store and the Google Play Store collect and display such attestations to varying extents, including attestations as to what data an app collects (if any) and with whom it is shared (if anyone). Additionally, the Play Store allows developers the 手機收購opportunity to attest to performing “encryption in transit” (see Figure 15 for an example). These attestations allow users to clearly see what security and privacy properties an app’s developer claims it to have and, like privacy policies, they provide means of redress if violated.
Figure 15: An example of an attestation for Microsoft SwiftKey.
We wanted to evaluate whether the apps that we analyzed lived up to their attestations concerning their encryption in the app stores in which they are available. Among the apps that we analyzed, only Baidu IME was available in the Play Store. At the time of this writing, it does not attest to its data being encrypted in transit. Although other apps that we analyzed were available in Apple’s App Store, to our knowledge, this store does not display an attestation for whether the app encrypts data in transit. As such, across both the Google Play and the Apple App stores, attestations were insufficient for compelling the keyboard apps’ developers to implement proper encryption or in providing users any 手機收購opportunity for redress.
In light of the above findings, we believe that users would benefit from the following recommendations: (1) that app store operators require developers to attest to whether or not an app encrypts data in transit, (2) that app store operators display not only when developers attest to all data being encrypted in transit but also display a warning when they fail to, and (3) that app store operators require apps in certain sensitive categories, such as keyboard apps, to either positively attest to encrypting all data in transit or to attest to not transmitting any data at all.
Since most of the apps that we found perform some type of encryption, even if it were wholly inadequate, one might wonder if attesting that data is merely “encrypted” is enough, since the data arguably did have some manner of encryption applied to it during transit. The Play Store provides some guidance on this topic. Under the question — “How should I encrypt data in transit?” — the documentation notes: “You should follow best industry standards to safely encrypt your app’s data in transit. Common encryption protocols include TLS (Transport Layer Security) and HTTPS.”
Another issue with attestations is that they provide no guarantee that an app behaves as its developers attest, as developers can, after all, make false attestations. While we wish that attestations could guarantee that an app sufficiently implements proper cryptography to the same extent that a permission system can guarantee an app does not use a microphone, false attestations provide an 手機收購opportunity for redress. For instance, apps which are found to violate attestations would be subject to removal from app stores. Furthermore, apps which violate attestations could be subject to fines by regulatory bodies such as the FTC. Finally, apps which violate the attestation could be liable to civil suits.
While the apps we analyzed were predominantly available from Chinese app stores, we equally recommend that Chinese app stores adopt these recommendations in addition to the Apple App Store and the Google Play Store. Moreover, while this report focuses on the problem of poor encryption practices as it applies to Chinese apps, the problem to varying extents applies to apps of all other provenances.
Summary of recommendations
We conclude our report by summarizing our recommendations to multiple stakeholders.
Recommendations to security researchers
Researchers should analyze more apps from the East Asian app ecosystem and from other popular ecosystems which may be outside of their own locale.
Researchers should develop better static and dynamic analysis techniques to recognize the types of vulnerabilities that we discovered in this report at scale.
Researchers submitting vulnerability disclosures to a company should include short summaries and email subject lines in the official language of the company’s jurisdiction.
Recommendations to international standards bodies
International standards bodies should continue to engage with security engineers from Chinese Internet companies.
Recommendations to app store operators
App stores should not require account registration as a condition to receive security updates.
App stores should not geoblock security updates.
App stores should allow developers to attest to all data being transmitted with encryption, similar to the ability in the Google Play Store.
App stores should display not only when developers attest to all data being encrypted in transit but also display a warning when they fail to.
App stores should require apps in certain sensitive categories, such as keyboard apps, to either positively attest to encrypting all data in transit or to attest to not transmitting any data at all.
Recommendations to keyboard app developers
Use well-tested and standard encryption protocols, like TLS or QUIC.
Make every attempt to provide features on-device without requiring transmitting sensitive data to cloud servers.
Recommendations to mobile operating system developers
Android should implement sandboxing by default for keyboard apps, similar to iOS, that prevents a keyboard from transmitting network traffic among other activities until a user grants the app full access.
The developers of Android and iOS should work toward a meaningful INTERNET permission that would adequately inform users of whether any app communicates over the Internet.
Recommendations to device manufacturers
Conduct security audits of third-party keyboards that you intend to pre-install by default on your operating systems.
Recommendations to users
Users of Honor’s pre-installed keyboard or users of QQ pinyin should switch keyboards immediately.
Users of any Sogou, Baidu, or iFlytek keyboard, including the versions that are bundled or pre-installed on operating systems, should ensure their keyboards and operating systems are up-to-date.
Users of any Baidu IME keyboard should consider switching to a different keyboard or disabling the “cloud-based” feature.
Users with privacy concerns should not enable “cloud-based” features on their keyboards or IMEs or should switch to a keyboard that does not offer “cloud-based” prediction.
iOS users with privacy concerns should not enable “Full Access” for their keyboards or IMEs.
Acknowledgments
We would like to thank Jedidiah Crandall, Jakub Dalek, Pellaeon Lin, and Sarah Scheffler for their guidance and review of this report. Research for this project was supervised by Ron Deibert.
Appendix
Known affected software
We recommend that all users keep their operating systems and apps, including keyboard apps, up to date. If you use any of the following software, we especially recommend you update to the most recent version of your OS and application. As of April 1, 2024, the following software has fixes available:
Separately installed, third-party keyboards
Sogou IME / 搜狗输入法 for Android and Windows
Baidu IME / 百度输入法 for Windows (this software has only been partially fixed, see below)
iFlytek IME / 讯飞输入法 for Android
Pre-installed on Samsung devices with Chinese edition ROM
Samsung Keyboard
Baidu IME / 百度输入法
Pre-installed on Xiaomi devices with Chinese edition ROM
Sogou IME Xiaomi Version / 搜狗输入法小米版
iFlytek IME Xiaomi Version / 讯飞输入法小米版
Pre-installed on 手機收購oppo devices with Chinese edition ROM
Sogou IME Custom Version / 搜狗输入法定制版
Pre-installed on Vivo devices with Chinese edition ROM
Sogou IME Custom Version / 搜狗输入法定制版
The following software does not use TLS and may still contain weaknesses:
Separately installed, third-party keyboards
Baidu IME / 百度输入法 for Android, Windows, and iOS
Pre-installed on Xiaomi devices with Chinese edition ROM
Baidu IME Xiaomi Version / 百度输入法小米版
Pre-installed on 手機收購oppo devices with Chinese edition ROM
Baidu IME Custom Version / 百度输入法定制版
The following software has not been fixed and is easily exploitable, and we suggest that users switch to another keyboard entirely:
Separately installed, third-party keyboards
QQ Pinyin IME / QQ拼音输入法 for Android and Windows
Pre-installed on Honor devices with Chinese edition ROM
Baidu IME Honor Version / 百度输入法荣耀版
Disclosure timelines
Baidu Input Method
The Citizen Lab to Baidu — October 3, 2023
We sent the following via email:
To: [email protected], [email protected]
Subject: Security issue in Baidu Input Method
To Whom It May Concern:
The Citizen Lab is an academic research group based at the Munk School of Global Affairs & Public Policy at the University of Toronto in Toronto, Canada.
We analyzed Baidu Input Method as part of our ongoing work analyzing popular mobile and desktop apps for security and privacy issues. We found that Baidu Input Method for Windows includes a vulnerability which allows network eavesdroppers to decrypt network transmissions. This means third parties can obtain sensitive personal information including what users have typed. We also found privacy and security weaknesses in the encryption used by the Android and iOS versions of Baidu Input Method. To address these issues, we suggest using HTTPS or TLS rather than custom-designed network protocols. For further details, please see the attached document.
Background
The Citizen Lab is committed to research transparency and will publish details regarding the security vulnerabilities it discovers in the context of its research activities, absent exceptional circumstances, on its website: https://citizenlab.ca/.
If no response is received to this disclosure, the Citizen Lab will publish details regarding the security vulnerability on its website after 15 calendar days from the date of this communication. In other words, where there is no response from you, Citizen Lab will publish details regarding the vulnerability after October 18 2023.
If a substantive response is received (which excludes, for example, an auto reply) to this disclosure within 15 calendar days from the date of this communication, the Citizen Lab will provide you with 45 calendar days from the date of this communication to fix (whether in whole or in part) the vulnerability before publicly disclosing the issue. In other words, where we do receive a substantive response from you, the Citizen Lab will publish details regarding the vulnerability after November 17 2023.
We reserve the right to publish details regarding the vulnerability to the general public before the expiry of the 45 calendar days set out above in the following situations: (1) you have disclosed the vulnerability to the general public, (2) you have patched the vulnerability, (3) you have taken the position that there is no security vulnerability, or (4) the Citizen Lab observes the vulnerability is under active exploitation.
All communications associated with this disclosure may be included in the Citizen Lab’s public disclosure of this vulnerability.
Next steps
Please communicate what steps you will take to address the vulnerability that we have described, and please provide the timeline you decide upon for the implementation of fixes.
Finally, upon implementation of any fixes, we ask that you communicate the full extent of the vulnerability to the Citizen Lab.
Should you have any questions about our findings please let us know. We can be reached at this email address: [email protected].
Sincerely,
The Citizen Lab
The Citizen Lab to Baidu — November 22, 2023
We sent the following via email:
To: [email protected], [email protected]
Subject: Security issues in Baidu Input Method / 百度输入法高危漏洞
多伦多大学的研究人员发现许多手机预装的百度输入法存在高危漏洞，让网络攻击者可以直接看到用户输入的内容。同时也发现百度输入法的安卓版、iOS版、和Windows版存在另外与安全相关的问题，建议切换到TLS。本文用英文解释了研究人员发现漏洞的细节。
To Whom It May Concern:
The Citizen Lab is an academic research group based at the Munk School of Global Affairs & Public Policy at the University of Toronto in Toronto, Canada.
We analyzed Baidu Input Method as part of our ongoing work analyzing popular mobile and desktop apps for security and privacy issues. We found multiple third-party apps using the Baidu Input Method API include a vulnerability which allows network eavesdroppers to decrypt network transmissions. This means third parties can obtain sensitive personal information including what users have typed. We also found privacy and security weaknesses in the encryption used by the Windows, Android, and iOS versions of Baidu Input Method. To address these issues, we suggest using HTTPS or TLS rather than custom-designed network protocols. For further details, please see the attached document.
Background
The Citizen Lab is committed to research transparency and will publish details regarding the security vulnerabilities it discovers in the context of its research activities, absent exceptional circumstances, on its website: https://citizenlab.ca/.
If no response is received to this disclosure, the Citizen Lab will publish details regarding the security vulnerability on its website after 15 calendar days from the date of this communication. In other words, where there is no response from you, Citizen Lab will publish details regarding the vulnerability after December 7 2023.
If a substantive response is received (which excludes, for example, an auto reply) to this disclosure within 15 calendar days from the date of this communication, the Citizen Lab will provide you with 45 calendar days from the date of this communication to fix (whether in whole or in part) the vulnerability before publicly disclosing the issue. In other words, where we do receive a substantive response from you, the Citizen Lab will publish details regarding the vulnerability after January 6 2024.
We reserve the right to publish details regarding the vulnerability to the general public before the expiry of the 45 calendar days set out above in the following situations: (1) you have disclosed the vulnerability to the general public, (2) you have patched the vulnerability, (3) you have taken the position that there is no security vulnerability, or (4) the Citizen Lab observes the vulnerability is under active exploitation.
All communications associated with this disclosure may be included in the Citizen Lab’s public disclosure of this vulnerability.
Next steps
Please communicate what steps you will take to address the vulnerability that we have described, and please provide the timeline you decide upon for the implementation of fixes.
Finally, upon implementation of any fixes, we ask that you communicate the full extent of the vulnerability to the Citizen Lab.
Should you have any questions about our findings please let us know. We can be reached at this email address: [email protected].
Sincerely,
The Citizen Lab
Baidu to The Citizen Lab — April 24, 20242
We received the following email:
From: input-business
Subject: 答复: Security issues in Baidu Input Method / 百度输入法高危漏洞
Citizen Lab 团队，
您好！
感谢贵团队对全球应用安全和隐私问题的持续研究及关注！很抱歉由于去年的邮件发送到了我们的商务邮箱，我们因此没有留意到并及时答复。近日我们关注到贵方发布的最新调研报告（https://citizenlab.ca/2024/04/vulnerabilities-across-keyboard-apps-reveal-keystrokes-to-network-eavesdroppers/），希望就报告所发布的内容做如下解答和沟通：
1、百度输入法历来非常重视安全和隐私问题，也一向遵循良好的安全实践标准。自去年8月贵团队发布搜狗输入法相关安全问题的报告后，我们也密切关注并进行了自查，发现我们的公版版本没有此类安全问题，但我们早期交付给手机厂商的定制版本由于版本较旧，没有与公版的安全方案保持一致。我们在当下也立即启动了厂商定制版的修复并提供给厂商最新输入法版本。但厂商版本的升级需跟随手机厂商系统OS的更新，一般需要较长的升级覆盖周期，用户也是分批陆续收到升级推送。今年贵方再次测试的结果也显示，大部分厂商定制版本也已更新到最新的安全方案，没有安全漏洞。
本次报告里提及的百度输入法荣耀定制版本的问题，实际我们也已经在2023年9月完成了修复，并由荣耀随OS版本陆续升级推送给用户。因手机存量用户较大，因此推送升级的周期较长，建议贵团队将测试设备升级至荣耀MagicOS 7.0及以上版本、输入法8.2.502.39及以上版本，再次测试进行验证。
2、针对本次报告中提及百度输入法所采用的安全方案，需要说明的是：我们采用当前方案的目的是为了进一步提升云输入的响应速度，进而提升用户输入体验，这也是我们作为中文输入法产品的核心竞争力的体现。
我们理解贵方提出的通用安全方案，但同时我们也认为，在保证用户信息安全的前提下，业务可以根据实际情况适当选择不同的加密方案以提升用户体验。当前百度输入法所采用的椭圆曲线 Diffie-Hellman和AES方案，客户端首次与服务端通信时，为了保证云输入业务的响应（0RTT），百度输入法使用客户端内置的服务端公钥(椭圆曲线) + 客户端随机生成的公私钥对，生成一个共享AES密钥，并直接用这个密钥对业务数据进行加密。这么做，既能够通过椭圆曲线非对称算法保证数据不可被第三方解析，又保证传输过程中无法被中间人攻击，也可以做到无需握手就直接进行业务通信，保证了服务响应的及时性。我们将目前的详细方案放在附录部分供进一步了解和参考。
贵方发布的报告中也表示当前并未找到方法可以利用这些弱点破解传输中的用户输入内容。在此情况下，我们认为，将百度输入法的加密方案以感叹号（“！”）形式标识，可能会引发用户和大众的误解，希望在对外发布的报告中可以将这一展现形式予以优化。
如果能够证明我们采用的加密方案无法保证用户信息安全，会被监听流量或者劫持流量的方法还原加密数据，我们非常愿意学习和改正。此外，我们也在不断探索更安全也更高效的算法，致力于更好的用户体验。
3、对于未及时答复邮件再次致歉！后续可以通过 [email protected] 邮箱与我们做更多技术交流和指导。同时，未来如有针对厂商定制版百度输入法的任何问题，也可及时联系我们，非常感谢！
再次感谢贵团队对百度输入法的关注，期待未来的更多交流！
百度输入法团队
中国 上海
——————————
附录： 百度输入法所采用的 椭圆曲线 Diffie-Hellman和AES方案详细说明
客户端首次与服务端通信时，为了保证云输入业务的响应（0RTT），百度输入法使用客户端内置的服务端公钥(椭圆曲线) + 客户端随机生成的公私钥对，生成一个共享AES密钥，并直接用这个密钥对业务数据进行加密。这么做，既能够通过椭圆曲线非对称算法保证数据不可被第三方解析，又保证传输过程中无法被中间人攻击，也可以做到无需握手就直接进行业务通信，保证了服务响应的及时性。
同时，考虑到我们的业务场景要求高频次、低数据量、快速响应，但相对的容许有少量数据丢失。因此我们使用UDP作为底层通信协议，UDP通信满足了我们上述业务特点的需要。为了确保UDP数据包在网络中传输时降低丢包率，需要尽可能减小数据包大小，因此我们使用了一个修改版本的AES算法，复用了客户端公钥作为IV，并使用修改版本的CTR封装方式。该方式可以减少标准AES在数据块末尾因数据对齐而浪费的几个额外字节，虽然此方案的确和标准方案略有区别，但我们的方案是对用户实际体验进行考虑后的平衡选择，我们的方案避免了在实际业务信息传输前进行密钥协商带来额外延时的体验损失，确保整体较低的响应延迟，尤其是在中国偏远地区或城市地铁中等网络覆盖不佳的场景下，问题改善尤为明显。
方案整体流程如下：
Dear Citizen Lab Team,
Thank you for your continuous research and attention to global application security and privacy issues! We apologize for missing your email last year as it was sent to our business email address. Recently, we have noticed your latest research report (https://citizenlab.ca/2024/04/vulnerabilities-across-keyboard-apps-reveal-keystrokes-to-network-eavesdroppers/) and would like to provide the following answers and communication regarding the content published in the report:
1. Baidu Input Method has always attached great importance to security and privacy issues and has always followed good security practice standards. Since your team released the report on Sogou Input Method’s security issues last August, we have also paid close attention and conducted self-inspections. We found that our public version does not have such security issues, but our early customized versions delivered to mobile phone manufacturers, due to their older versions, did not align with the security solutions of the public version. We immediately initiated the repair of the customized versions for manufacturers and provided them with the latest input method versions. However, the upgrading of the manufacturer’s versions needs to follow the update of the mobile phone manufacturer’s system OS, which generally requires a longer upgrade coverage cycle, and users receive upgrade push notifications in batches. The results of your recent tests also showed that most of the customized versions of the manufacturers have also been updated to the latest security solutions without security vulnerabilities.
The issue mentioned in the report regarding the Baidu Input Method’s customized version for Honor has already been fixed by us in September 2023, and Honor has gradually pushed the upgrade to users along with the OS version update. Due to the large number of existing mobile phone users, the upgrade push cycle is relatively long. We suggest that your team upgrade your testing devices to Honor MagicOS 7.0 or above and the input method version 8.2.502.39 or above for further testing and verification.
2. Regarding the security solution adopted by Baidu Input Method mentioned in this report, we would like to clarify that our current solution aims to further improve the response speed of cloud input and enhance the user input experience, which is a manifestation of our core competitiveness as a Chinese input method product.
We understand the general security solutions proposed by your team, but at the same time, we believe that, under the premise of ensuring user information security, businesses can appropriately choose different encryption solutions according to actual situations to improve user experience. The current elliptic curve Diffie-Hellman and AES solutions adopted by Baidu Input Method use the client-side built-in server-side public key (elliptic curve) + client-side randomly generated public and private key pairs to generate a shared AES key when the client first communicates with the server. This key is then used to directly encrypt the application data. This approach not only ensures that the data cannot be parsed by third parties through the asymmetric algorithm of the elliptic curve but also prevents man-in-the-middle attacks during transmission. It also allows communication to occur without a handshake, ensuring the timeliness of service responses. We have included the detailed current solution in the appendix for further understanding and reference.
Your report also indicates that no method has been found to exploit these vulnerabilities to decrypt user input content during transmission. Under such circumstances, we believe that identifying the encryption solution of Baidu Input Method with an exclamation mark (“!”) may cause misunderstandings among users and the public. We hope you can take another look at this and consider possible adjustments in your future reports.
If it can be proven that the encryption solution we adopted cannot ensure user information security and can be exploited by methods such as sniffing traffic or hijacking traffic to restore encrypted data, we are very willing to learn and correct it. In addition, we are continuously exploring safer and more efficient algorithms to deliver a better user experience.
3. We apologize again for not responding to your email in a timely manner! You can reach us at [email protected] for more technical exchanges and guidance in the future.Meanwhile, if you have any questions regarding the customized version of Baidu Input Method for manufacturers in the future, please feel free to contact us. Thank you very much!
Thank you again for your attention to Baidu Input Method and we look forward to more exchanges in the future!
Best regards,
Baidu Input Method Team
Shanghai，China
————————————
Appendix: Detailed Explanation of the Elliptic Curve Diffie-Hellman and AES Schemes Used by Baidu Input Method
When the client establishes initial communication with the server to ensure the responsiveness of cloud input services (0RTT), Baidu Input Method utilizes the server’s public key (elliptic curve) embedded in the client along with a randomly generated public-private key pair from the client to generate a shared AES key. This key is then directly used to encrypt the application data. This approach not only ensures that the data cannot be decrypted by a third party through the asymmetric algorithm of the elliptic curve, but also prevents man-in-the-middle attacks during transmission. It also allows for direct communication without the need for a handshake, thereby reducing latency.
Meanwhile, considering our usage scenario need high frequency,low data size,and low latency, while tolerating a small amount of packet loss, we have chosen UDP as the underlying communication protocol. UDP meets the needs of our characteristics mentioned above. To minimize packet loss during UDP transmission, it is necessary to reduce the packet size as much as possible. Therefore, we have implemented a modified version of the AES algorithm, reusing the client’s public key as the IV and employing a modified CTR encapsulation method. This approach eliminates the waste of several extra bytes caused by data alignment at the end of data blocks in the standard AES, although our solution differs slightly from the standard. Our solution represents a balanced choice after considering the actual user experience. It avoids the additional delay caused by key negotiation before the transmission of actual application information, ensuring overall lower response latency, particularly in scenarios with poor network coverage such as remote areas in China or subway systems, where the improvement is very obvious.
The overall process of the scheme is as follows:
The Citizen Lab to Baidu — May 15, 2024
We sent the following email:
Hello,
Thank you for your detailed reply. We will send future security disclosures to the [email protected] email address indicated.
We have prepared a response to your email in the following attached document.
Sincerely,
Citizen Lab
Honor
The Citizen Lab to Honor — November 22, 2023
We sent the following via email:
To: [email protected]
Subject: Security issues in Honor keyboard / 荣耀百度输入法高危漏洞
总结：多伦多大学的研究人员发现荣耀预装的百度输入法使用的加密协议有高危漏洞，让网路攻击者可以直接看到用户输入的内容。本文用英文解释了研究人员发现高危漏洞的细节。
To Whom It May Concern:
The Citizen Lab is an academic research group based at the Munk School of Global Affairs & Public Policy at the University of Toronto in Toronto, Canada.
We analyzed Honor pre-installed keyboard apps as part of our ongoing work analyzing popular mobile and desktop apps for security and privacy issues. We found that the Baidu-based one includes vulnerabilities that allow network eavesdroppers to decrypt network transmissions. This means third parties can obtain sensitive personal information including what users have typed. To address these issues, we suggest using HTTPS or TLS rather than custom-designed network protocols. For further details, please see the attached document.
Background
The Citizen Lab is committed to research transparency and will publish details regarding the security vulnerabilities it discovers in the context of its research activities, absent exceptional circumstances, on its website: https://citizenlab.ca/.
If no response is received to this disclosure, the Citizen Lab will publish details regarding the security vulnerability on its website after 15 calendar days from the date of this communication. In other words, where there is no response from you, Citizen Lab will publish details regarding the vulnerability after December 7 2023
If a substantive response is received (which excludes, for example, an auto reply) to this disclosure within 15 calendar days from the date of this communication, the Citizen Lab will provide you with 45 calendar days from the date of this communication to fix (whether in whole or in part) the vulnerability before publicly disclosing the issue. In other words, where we do receive a substantive response from you, the Citizen Lab will publish details regarding the vulnerability after January 6 2024
We reserve the right to publish details regarding the vulnerability to the general public before the expiry of the 45 calendar days set out above in the following situations: (1) you have disclosed the vulnerability to the general public, (2) you have patched the vulnerability, (3) you have taken the position that there is no security vulnerability, or (4) the Citizen Lab observes the vulnerability is under active exploitation.
All communications associated with this disclosure may be included in the Citizen Lab’s public disclosure of this vulnerability.
Next steps
Please communicate what steps you will take to address the vulnerability that we have described, and please provide the timeline you decide upon for the implementation of fixes.
Finally, upon implementation of any fixes, we ask that you communicate the full extent of the vulnerability to the Citizen Lab.
Should you have any questions about our findings please let us know. We can be reached at this email address: [email protected].
Sincerely,
The Citizen Lab
Honor to The Citizen Lab — November 23, 2023
We received the following email:
From: security
Subject: 答复: Security issues in Honor keyboard / 荣耀百度输入法高危漏洞
DEAR Citizen Lab
Thank you very much for your concern about the security of Honor.
Honor always attaches great importance to the security of products and services. In order to respond to your security concerns immediately,
we have set up a professional vulnerability response team to serve you and set up an email ([email protected]) for quick response.
We are analyzing the impact of these security issue and will reach a conclusion as soon as possible.
Once again thank you for your concern about the security of Honor. If you have any questions, feel free to contact us through this email at any time.
Honor Security Response Center
Honor to The Citizen Lab — December 5, 2023
We received the following email:
From: security
Subject: 答复: Security issues in Honor keyboard / 荣耀百度输入法高危漏洞
DEAR Citizen Lab
Thank you very much for your report and your patience.
Honor always attaches great importance to the security of products and services. In order to respond to your security concerns immediately,
we have set up a professional vulnerability response team to serve you and set up an email ([email protected]) for quick response.
After our analysis. Baidu is a vendor of Honor, we relied on the vendor to patch this issue. We recommend that you submit this issue to Baidu and negotiate a disclosure plan with Baidu.
Once again thank you for your concern about the security of Honor. If you have any questions, feel free to contact us through this email at any time.
Honor Security Response Center
The Citizen Lab to Honor — March 7, 2024
We sent the following email:
To: security
Subject: Re: Security issues in Honor keyboard / 荣耀百度输入法高危漏洞
Dear Honor Security Response Center,
We have tried disclosing these issues to Baidu, but Baidu has been so far unresponsive to our disclosures.
We would like to note that our Honor Play7T device is still using an older version (v8.2.501.1) of the com.baidu.input_hihonor app. While the latest version of Baidu’s keyboard does not address all of the issues that we have reported, it does contain fixes for the most serious issues. Therefore, we recommend updating the com.baidu.input_hihonor app to the latest version of Baidu’s keyboard.
Sincerely,
The Citizen Lab
iFlytek
The Citizen Lab to iFlytek — September 8, 2023
We sent the following via email:
To: [email protected]
Subject: Security issue in Xunfei Input Method
To Whom It May Concern:
The Citizen Lab is an academic research group based at the Munk School of Global Affairs & Public Policy at the University of Toronto in Toronto, Canada.
We analyzed Xunfei Input Method on Android as part of our ongoing work analyzing popular mobile and desktop apps for security and privacy issues. We found that Xunfei Input Method for Android includes a vulnerability which allows network eavesdroppers to recover the plaintext of insufficiently encrypted network transmissions, revealing sensitive information including what users have typed.
For further details, please see the attached document.
Background
The Citizen Lab is committed to research transparency and will publish details regarding the security vulnerabilities it discovers in the context of its research activities, absent exceptional circumstances, on its website: https://citizenlab.ca/.
If no response is received to this disclosure, the Citizen Lab will publish details regarding the security vulnerability on its website after 15 calendar days from the date of this communication. In other words, where there is no response from you, Citizen Lab will publish details regarding the vulnerability after September 23, 2023.
If a substantive response is received (which excludes, for example, an auto reply) to this disclosure within 15 calendar days from the date of this communication, the Citizen Lab will provide you with 45 calendar days from the date of this communication to fix (whether in whole or in part) the vulnerability before publicly disclosing the issue. In other words, where we do receive a substantive response from you, the Citizen Lab will publish details regarding the vulnerability after October 23, 2023.
We reserve the right to publish details regarding the vulnerability to the general public before the expiry of the 45 calendar days set out above in the following situations: (1) you have disclosed the vulnerability to the general public, (2) you have patched the vulnerability, (3) you have taken the position that there is no security vulnerability, or (4) the Citizen Lab observes the vulnerability is under active exploitation.
All communications associated with this disclosure may be included in the Citizen Lab’s public disclosure of this vulnerability.
Next steps
Please communicate what steps you will take to address the vulnerability that we have described, and please provide the timeline you decide upon for the implementation of fixes.
Finally, upon implementation of any fixes, we ask that you communicate the full extent of the vulnerability to the Citizen Lab.
Should you have any questions about our findings please let us know. We can be reached at this email address: [email protected].
Sincerely,
The Citizen Lab
The Citizen Lab to iFlytek — September 25, 2023
We sent the following via email:
To: [email protected]
Subject: Security issue in Xunfei Input Method
To Whom It May Concern:
The Citizen Lab is an academic research group based at the Munk School of Global Affairs & Public Policy at the University of Toronto in Toronto, Canada.
We analyzed Xunfei Input Method on Android as part of our ongoing work analyzing popular mobile and desktop apps for security and privacy issues. We found that Xunfei Input Method for Android includes a vulnerability which allows network eavesdroppers to recover the plaintext of insufficiently encrypted network transmissions, revealing sensitive information including what users have typed. For further details, please see the attached document.
On September 8 2023 we attempted to disclose these vulnerabilities to [email protected], an email address listed on the product’s Web page, but we have not received a response. If you are not able to process vulnerability disclosures for this product, please ensure that this disclosure is delivered to someone who can.
Background
The Citizen Lab is committed to research transparency and will publish details regarding the security vulnerabilities it discovers in the context of its research activities, absent exceptional circumstances, on its website: https://citizenlab.ca/.
If no response is received to this disclosure, the Citizen Lab will publish details regarding the security vulnerability on its website after 15 calendar days from the date of this communication. In other words, where there is no response from you, Citizen Lab will publish details regarding the vulnerability after October 10, 2023.
If a substantive response is received (which excludes, for example, an auto reply) to this disclosure within 15 calendar days from the date of this communication, the Citizen Lab will provide you with 45 calendar days from the date of this communication to fix (whether in whole or in part) the vulnerability before publicly disclosing the issue. In other words, where we do receive a substantive response from you, the Citizen Lab will publish details regarding the vulnerability after November 9, 2023.
We reserve the right to publish details regarding the vulnerability to the general public before the expiry of the 45 calendar days set out above in the following situations: (1) you have disclosed the vulnerability to the general public, (2) you have patched the vulnerability, (3) you have taken the position that there is no security vulnerability, or (4) the Citizen Lab observes the vulnerability is under active exploitation.
All communications associated with this disclosure may be included in the Citizen Lab’s public disclosure of this vulnerability.
Next steps
Please communicate what steps you will take to address the vulnerability that we have described, and please provide the timeline you decide upon for the implementation of fixes.
Finally, upon implementation of any fixes, we ask that you communicate the full extent of the vulnerability to the Citizen Lab.
Should you have any questions about our findings please let us know. We can be reached at this email address: [email protected].
Sincerely,
The Citizen Lab
The Citizen Lab to iFlytek — November 3, 2023
We sent the following via email:
To: [email protected], [email protected]
Subject: 讯飞输入法高危漏洞
多伦多大学的研究人员发现讯飞输入法使用的加密协议存在高危漏洞，让网路攻击者可以直接看到用户输入的内容。本文用英文解释了研究人员发现高危漏洞的细节。
To Whom It May Concern:
The Citizen Lab is an academic research group based at the Munk School of Global Affairs & Public Policy at the University of Toronto in Toronto, Canada.
We analyzed Xunfei Input Method on Android as part of our ongoing work analyzing popular mobile and desktop apps for security and privacy issues. We found that Xunfei Input Method for Android includes a vulnerability which allows network eavesdroppers to recover the plaintext of insufficiently encrypted network transmissions, revealing sensitive information including what users have typed. For further details, please see the attached document.
On September 8 2023 we attempted to disclose these vulnerabilities to [email protected], and on September 25 2023 we attempted to disclose these vulnerabilities to [email protected]. We have not received a response to these emails. If you are not able to process vulnerability disclosures for this product, please ensure that this disclosure is delivered to someone who can.
Background
The Citizen Lab is committed to research transparency and will publish details regarding the security vulnerabilities it discovers in the context of its research activities, absent exceptional circumstances, on its website: https://citizenlab.ca/.
All communications associated with this disclosure may be included in the Citizen Lab’s public disclosure of this vulnerability.
Next steps
Please communicate what steps you will take to address the vulnerability that we have described, and please provide the timeline you decide upon for the implementation of fixes.
Finally, upon implementation of any fixes, we ask that you communicate the full extent of the vulnerability to the Citizen Lab.
Should you have any questions about our findings please let us know. We can be reached at this email address: [email protected].
Sincerely,
The Citizen Lab
iFlytek to The Citizen Lab — November 6, 2023
We received the following email:
Subject: Feedback on Xunfei Input Method issue
Hello The Citizen Lab,
Sorry for the delay.
Thank you for your detailed report and responsible disclosure on this issue.
We have analyzed your report and confirmed this is mainly due to server-side improper configuration in Xunfei Input Method that causes data transmission to use the HTTP protocol which can be eavesdropped. For the DES encryption algorithm used, is the result of considering the trade-off between performance and security under massive requests condition. As you mentioned in the mitigation part, data transmission is secure under the HTTPS protocol.
We implemented the fix on November 4th, that is, changing the improperly configured HTTP protocol on the server side to HTTPS, and it has taken effect.
Timeline:
November 4, 2023: Latest report received
November 4, 2023: Fix implemented
Because this is an improper configuration on the server side, the client will not be affected after the server is fixed. So there is no specific APK version extent of the vulnerability.
Best Regards,
Iflytek Team
手機收購oppo
The Citizen Lab to 手機收購oppo — November 22, 2023
We sent the following via email:
To: security@手機收購oppo.com
Subject: Security issues in 手機收購oppo keyboards / 手機收購oppo预装的输入法高危漏洞
总结：多伦多大学的研究人员发现手機收購oppo所有预装的中文输入法使用的加密协议有高危漏洞，让网路攻击者可以直接看到用户输入的内容。本文用英文解释了研究人员发现高危漏洞的细节。
To Whom It May Concern:
The Citizen Lab is an academic research group based at the Munk School of Global Affairs & Public Policy at the University of Toronto in Toronto, Canada.
We analyzed 手機收購oppo pre-installed keyboard apps as part of our ongoing work analyzing popular mobile and desktop apps for security and privacy issues. We found two that include vulnerabilities that allow network eavesdroppers to decrypt network transmissions. This means third parties can obtain sensitive personal information including what users have typed. To address these issues, we suggest using HTTPS or TLS rather than custom-designed network protocols. For further details, please see the attached document.
Background
The Citizen Lab is committed to research transparency and will publish details regarding the security vulnerabilities it discovers in the context of its research activities, absent exceptional circumstances, on its website: https://citizenlab.ca/.
If no response is received to this disclosure, the Citizen Lab will publish details regarding the security vulnerability on its website after 15 calendar days from the date of this communication. In other words, where there is no response from you, Citizen Lab will publish details regarding the vulnerability after December 7 2023.
If a substantive response is received (which excludes, for example, an auto reply) to this disclosure within 15 calendar days from the date of this communication, the Citizen Lab will provide you with 45 calendar days from the date of this communication to fix (whether in whole or in part) the vulnerability before publicly disclosing the issue. In other words, where we do receive a substantive response from you, the Citizen Lab will publish details regarding the vulnerability after January 6 2024.
We reserve the right to publish details regarding the vulnerability to the general public before the expiry of the 45 calendar days set out above in the following situations: (1) you have disclosed the vulnerability to the general public, (2) you have patched the vulnerability, (3) you have taken the position that there is no security vulnerability, or (4) the Citizen Lab observes the vulnerability is under active exploitation.
All communications associated with this disclosure may be included in the Citizen Lab’s public disclosure of this vulnerability.
Next steps
Please communicate what steps you will take to address the vulnerability that we have described, and please provide the timeline you decide upon for the implementation of fixes.
Finally, upon implementation of any fixes, we ask that you communicate the full extent of the vulnerability to the Citizen Lab.
Should you have any questions about our findings please let us know. We can be reached at this email address: [email protected].
Sincerely,
The Citizen Lab
手機收購oppo to The Citizen Lab — November 23, 2023
We received the following email:
From: 手機收購oppo安全中心
Subject: 回复: Security issues in 手機收購oppo keyboards / 手機收購oppo预装的输入法高危漏洞
The Citizen Lab:
The email has been received. We will transfer it to the corresponding team for content analysis and confirmation. We will reply to the content in a timely manner. Thank you very much for your feedback!
手機收購oppo to The Citizen Lab — December 3, 2023
We received the following email:
From: 手機收購oppo安全中心
Subject: 回复: Security issues in 手機收購oppo keyboards / 手機收購oppo预装的输入法高危漏洞
Dear Citizen Lab Team,
Thank you once again for your attention and contribution to the safety of our products.
In response to the security vulnerability you reported, our 手機收購oppo Security Team has swiftly taken a series of measures. We particularly emphasize that for the Sogou Input Method 手機收購oppo Custom Edition, the related security issues have been comprehensively resolved and fixed on the latest ColorOS 14 system.
However, considering the wide range of our product models and numerous versions, to ensure that every device receives equal levels of security updates and maintenance, we need more time to thoroughly implement these fixes. Our team is working hard to ensure that all devices running older versions of ColorOS will also receive this important update as soon as possible.
In the meantime, the repair work for the Baidu Input Method 手機收購oppo Custom Edition is also proceeding intensely. Currently, this application is still in the internal testing phase. Our engineers are making every effort to ensure that it meets our high standards in terms of security and stability. Our goal is to complete the testing and release the update as soon as possible, ensuring the safety of all our users. We plan to comprehensively update and push both Baidu and Sogou Input Method 手機收購oppo Custom Editions by Q1 2024.
We understand that as a technology company, protecting the security and privacy of user data is our primary task. Therefore, 手機收購oppo is always committed to continuously improving the security performance of our products and services. We will continue to maintain close cooperation with security research institutions like Citizen Lab, working together to enhance the security standards of the entire industry.
Should you have any questions about our security measures or progress, please feel free to contact us.
Thank you again for your understanding, support, and cooperation.
Sincerely,
手機收購oppo Security Team
手機收購oppo to The Citizen Lab — December 13, 2023
We received the following email:
From: 手機收購oppo安全中心
Subject: 回复: Security issues in 手機收購oppo keyboards / 手機收購oppo预装的输入法高危漏洞
Dear Citizen Lab Team,
It has been over a week since our response. I am not sure if this has answered your questions. If you need further assistance, please contact me!
December 18 2023We sent the following via email:
From: 手機收購oppo安全中心
Subject: Re: Security issues in 手機收購oppo keyboards / 手機收購oppo预装的输入法高危漏洞
Dear 手機收購oppo Security Team,
Thank you for your response. We are happy to hear that fixes are underway for your products. Our test device runs ColorOS 13.1, so we are currently unable to test the fix for Sogou Input Method 手機收購oppo Custom Edition for ColorOS 14, but please notify us when you have released the fix for ColorOS 13.1 so that we can test it.
Similarly, please let us know when the fix for Baidu Input Method 手機收購oppo Custom Edition is available so that we can test it as well.
Sincerely,
The Citizen Lab
手機收購oppo to The Citizen Lab — December 18, 2023
We received the following email:
From: 手機收購oppo安全中心
Subject: 回复: Security issues in 手機收購oppo keyboards / 手機收購oppo预装的输入法高危漏洞
Dear Citizen Lab Team,
Sincerely thank you for your attention and contribution to the safety of our products.
Regarding the two time points mentioned in the email, we will inform you via email when the actual repair is made. You are also welcome to conduct testing to help us improve the security level of 手機收購oppo products and services.
Sincerely,
手機收購oppo Security Emergency Response Center
Samsung
The Citizen Lab to Samsung — October 16, 2023
We sent the following via email:
To: [email protected]
Subject: Security issue in Samsung Keyboard
To Whom It May Concern:
The Citizen Lab is an academic research group based at the Munk School of Global Affairs & Public Policy at the University of Toronto in Toronto, Canada.
We analyzed Samsung Keyboard on Android as part of our ongoing work analyzing popular mobile and desktop apps for security and privacy issues. We found that Samsung Keyboard for Android includes a vulnerability which allows network eavesdroppers to recover the plaintext of insufficiently encrypted network transmissions, revealing sensitive information including what users have typed. For further details, please see the attached document.
Background
The Citizen Lab is committed to research transparency and wil
（圖／法新社）
今年夏天摺疊手機大爆發！有即將上市的 Google Pixel 9 Pro Fold，還有三星、小米、motorola 均已在台灣帶來新一代摺疊手機。隨著各大品牌逐漸加入競爭，市場也開始產生變化，原本穩坐全球摺疊手機龍頭的三星面臨重大挑戰，更有黑馬達成銷量狂飆 31 倍的成長。
根據研調機構 TechInsights 釋出最新數據，公布 2024 年第二季全球摺疊手機的市占率排名，華為以年成長率 229% 的幅度奪得第一名，三星則是只有 5% 的微幅成長，只暫居第二名，後面依序排名還有 vivo、榮耀、motorola、手機收購oppo、傳音、小米、OnePlus、中興以及 Google。
今年第二季最大黑馬是締造 3150% 年成長率的是傳音，僅管總排名只落在第七名，卻已經成為不可小覷的新勢力，主力銷售地區集中在非洲，是目前僅次於三星、motorola 的第三大品牌。其餘有高度成長的還有榮耀（423%）、vivo（83%）、小米（67%）、motorola（32%），Google 與 手機收購oppo 則是因為該季度未有新機發表，分別呈現 70% 與 59% 的衰退。
（圖／TechInsights）
至於原本是摺疊手機霸主三星，為何成長率僅有 5%？對此外媒《AndroidHeadlines》分析認為，目前市場上的競爭者多一開始增加許多，此外，過去三年的 Galaxy Z Fold、Flip 系列都沒有太多變化，許多規格已經陸續被競品追上甚至超前。
手機收購 手機收購
@saachu86106