via here.news
搜狗输入法加密中的漏洞使按键暴露于网络窃听
作者：Jeffrey Knockel, Zoë Reichert, and Mona Wang
日期：2023年8月9日
我们敦促搜狗输入法用户立即更新到最新版本的应用程序（至少是Windows版本13.7，Android版本11.26或iOS版本11.25）。
主要发现：
我们分析了腾讯的搜狗输入法，该输入法是中国最受欢迎的输入法，拥有超过4.5亿的月活跃用户。
通过分析软件的Windows、Android和iOS版本，我们发现了搜狗输入法自定义的“EncryptWall”加密系统以及它对敏感数据进行加密的漏洞。
我们发现，包含用户按键等敏感数据的网络传输可以被网络窃听者解密，揭示用户的实时输入内容。
我们已将这些漏洞披露给搜狗开发人员，并且他们已经发布了修复的软件版本（截至2023年7月20日，Windows版本13.7，Android版本11.26和iOS版本11.25）。
这些发现强调了中国软件开发人员使用得到良好支持的加密实现（如TLS）的重要性，而不是试图自行设计加密系统。
简介：
与输入少量字母的字母语言相比，输入象形文字语言（如中文）更加困难。中文有数以万计的字符，使用频率各不相同，无法全部放在一个键盘上。没有标准的中文输入方法，但随着现代技术的发展，出现了许多互补的方法。最流行的是拼音输入法，基于汉字的拼音罗马化。注音是另一种常用的音标输入法，而形状或笔画输入法（如仓颉或五笔）也常被使用。现代输入法还支持通过手写、语音识别、照片或OCR输入字符。
在本报告中，我们分析了腾讯的搜狗输入法，这是中国最受欢迎的输入法，拥有超过4.55亿的月活跃用户，并且有适用于Windows、Android和iOS等多个平台的应用程序版本。搜狗输入法占据了中国输入法用户的70%，其次是讯飞和百度的产品。麦咖啡在2015年的分析中曾观察到该应用程序的Windows版本在不加密的情况下传输设备标识符，但没有分析该应用程序的加密系统传输的数据的安全性。
我们分析了搜狗输入法的Windows、Android和iOS版本，发现该应用程序的自定义加密系统存在严重的漏洞，使得诸如用户按键等敏感数据可以被网络窃听者解密。我们发现的这些漏洞不仅限于中国的中文作者，根据市场研究估计，访问该应用程序网站的美国用户占比超过3.3%，台湾占近1.8%，日本占超过1.5%。
本报告的其余部分结构如下。在“方法论”部分，我们概述了我们用于分析搜狗输入法的逆向工程工具和技术。在“发现”部分，我们描述了搜狗输入法的自定义加密系统的工作原理，我们发现的漏洞以及受影响的数据传输示例。在“缓解措施”和“协调披露”部分，我们讨论了搜狗如何修复我们报告的漏洞以及我们如何向他们报告漏洞。最后，在“讨论”部分，我们反思了这些漏洞对中国应用程序生态系统中的系统性问题的影响。
方法论：
我们分析了搜狗输入法的Windows、Android和iOS版本。为了获取我们分析的版本，我们在2023年5月从产品网站下载了Windows和Android版本的最新版本（尽管Android版本截至2021年6月3日仍然可用，但目前在Google Play商店中不可用）。我们从Apple的App Store获取了iOS版本（有关分析版本的详细信息，请参见表1）。
平台 搜狗输入法版本 设备
Windows 7 SP1 13.4 虚拟机
Android 9 11.20 Google Pixel 2
iOS 14.8 11.21 iPhone SE 2代
表1：分析的搜狗输入法版本的详细信息。
我们使用静态和动态分析方法分析了这些版本的搜狗输入法。我们使用jadx对Dalvik字节码进行静态分析和反编译，使用IDA Pro对本机机器代码进行静态分析和反编译。我们使用frida对Android和iOS版本进行动态分析，使用IDA Pro对Windows版本进行动态分析。最后，我们使用Wireshark和mitmproxy进行网络流量捕获和分析。
发现：
我们发现搜狗输入法的每个版本都使用一个名为“EncryptWall”的加密系统对敏感数据进行加密。我们发现Windows和Android版本的搜狗输入法在这个加密系统中存在漏洞，包括对CBC填充预言攻击的漏洞，这使得网络窃听者可以恢复加密的网络传输的明文，揭示包括用户输入的内容在内的敏感信息（请参见表2以了解受影响的版本的详细信息）。在Android版本的情况下，我们还能够恢复用于加密流量的对称加密密钥的第二半部分。我们还发现了影响iOS版本的加密的漏洞，但我们目前不知道如何利用我们分析的版本中的这些漏洞。
平台 是否可利用？
Windows 是
Android 是
iOS 没有已知的利用方法
表2：搜狗输入法受影响的版本摘要。
在本节的其余部分，我们详细介绍了对搜狗的EncryptWall加密系统的攻击。我们首先介绍加密系统的背景，然后详细说明我们对其进行的攻击，最后分析我们的攻击如何适用于我们分析的三个平台，以适应EncryptWall系统在不同平台上的实现差异。
搜狗的EncryptWall
我们在本报告中讨论的攻击涉及我们在搜狗的“EncryptWall”加密系统中发现的漏洞，该系统似乎旨在通过明文HTTP POST请求中的加密字段，将敏感流量安全地隧道传输到未加密的搜狗HTTP API端点。在本报告中，我们将外部的明文HTTP请求称为EncryptWall请求，而每个EncryptWall请求封装了隧道请求的单个加密请求。尽管在我们分析的三个平台上的实现存在差异，但我们发现该系统的工作原理通常如下：
EncryptWall请求作为HTTP POST请求发送到搜狗EncryptWall API端点，其中包含至少五个HTTP表单字段，指定用于加密隧道请求以及加密隧道数据的加密参数。两个表单字段与指定用于加密EncryptWall请求中的其他字段的密钥和初始化向量（IV）有关：
“K” - 使用PKCS#v1.5填充，使用硬编码的1024位公共RSA密钥对256位AES密钥k进行加密的base64编码；每个请求随机生成k
“V” - 使用硬编码的128位初始化向量v进行加密的base64编码；每个请求随机生成v
这些字段中的三个字段分别进行zlib压缩、使用k和v进行加密，并根据以下伪代码进行base64编码：
ᴇɴᴄʀʏᴘᴛ(data) = base64_encode(AES_cbc_encrypt(zlib_compress(data, wbits=-15), k, v))
我们一直观察到以这种方式加密的三个字段如下：
“U” - ᴇɴᴄʀʏᴘᴛ(隧道HTTP请求的URL)
“G” - ᴇɴᴄʀʏᴘᴛ(隧道HTTP请求的GET参数，以查询字符串的形式)
“P” - ᴇɴᴄʀʏᴘᴛ(隧道HTTP请求的原始POST数据，如果有的话)
根据分析的平台和正在进行的请求类型，EncryptWall请求可能通过加密的HTTPS或明文HTTP发送。在使用HTTPS发送EncryptWall请求的情况下，我们认为这些请求在网络窃听方面是安全的，尽管EncryptWall请求的底层加密可能存在缺陷，HTTPS的TLS加密还可以提供额外的保护。因此，我们在本节其余部分的发现仅涉及我们观察到的通过不受HTTPS额外保护的明文HTTP发送的EncryptWall请求。
攻击
我们发现EncryptWall系统容易受到CBC填充预言攻击的漏洞，这是一种最初于2002年发表的攻击类型，影响使用密码块链接（CBC）块密码模式和PKCS#7填充的块密码。在这种攻击中，可以逐字节地恢复消息的明文，每个字节最多使用256个消息。我们不打算在此完全重述此攻击的工作原理，该攻击依赖于一种称为填充预言的特定类型的边信道，该边信道明确地显示解密后的接收到的密文是否正确填充。我们在EncryptWall系统中识别到了这样的预言，我们发现在“U”表单字段中发送的密文在包含错误填充时返回HTTP 400状态码，而在正确填充时，根据解密后的URL是否是有效URL，返回200状态码或500状态码。通过进行CBC填充预言攻击，这个填充预言允许我们不仅揭示“U”的整个明文，还可以揭示“G”和“P”的明文，因为它们使用相同的密钥和初始化向量。因此，通过使用这个填充预言，我们可以解密整个EncryptWall请求的内容。
在本节的其余部分，我们将这个攻击适应到Windows和Android平台上EncryptWall系统实现的所有偏差。尽管我们目前无法利用我们在iOS版本中发现的问题，但我们还是详细说明了EncryptWall系统中的问题。
Windows版本13.4
我们分析的Windows版本中实现的EncryptWall系统在一个细节上与上述基本实现有所偏差，即IV v不是公开的，而是以与AES密钥k相同的方式进行加密。由于这种差异，v不是立即可知的，这可能会带来两个潜在的问题：首先，在CBC填充预言攻击中，必须知道IV才能解密第一个明文块。其次，由于在加密之前，EncryptWall请求中的隧道数据被压缩，第一个明文块对于解压缩其余块来说非常重要。
然而，我们开发了一种方法来恢复v，该方法利用v被重用以加密多个明文的事实。具体而言，由于“U”的URL很容易预测，并且始终只有少数可能的端点之一，我们可以通过在第一个密文块“U”上执行CBC填充预言攻击来恢复v，假设初始IV为全零。这种攻击的结果将是URL的第一个明文块与v异或的结果。然后，我们将此结果与我们对URL的第一个明文块的预测进行异或，得到v。一旦我们恢复了v，我们就可以像往常一样对“G”和“P”进行CBC填充预言攻击。
作为此攻击易受攻击的数据的一个示例，我们发现对于发送到 “http://get.sogou.com/q”的EncryptWall请求，当“U”为“http://master-proxy.shouji.sogou.com/swc.php” 时，“G”包含与搜狗软件版本相关的版本信息，“P”是一个包含最近输入的按键的protobuf缓冲区（请参见图2的示例）。我们认为这些传输与基于云的自动完成服务有关。由于这些传输容易受到我们的攻击，搜狗输入法用户的按键可以被网络窃听者解密，从而告知窃听者用户实时输入的内容。
Android版本11.20
我们分析的Android版本采用了EncryptWall的基本实现，但增加了四个额外的表单字段：“R”、“S”、“E”和“F”。字段“R”传输另一个32字节的密钥r。值得注意的是，r的每个字节都是从ASCII大写字母和数字的36个字符集中随机选择的。因此，与25632 = 2256位熵相比，该密钥只有3632 < 2166位熵。此外，与k不同，r不是每个请求随机生成的，而是仅在应用程序生命周期内生成一次，并且缓存在C静态内存中。字段“R”然后作为k ⊕ r的base64编码进行传输。请注意，由于这种传输，k的熵也降低到3632 < 2166位熵。参数k、r和v用于根据以下伪代码对“S”、“E”和“F”进行编码和加密：
ᴇɴᴄʀʏᴘᴛSEF(data) = base64Encode(k ⊕ AES_cbc_encrypt(data, r, “EscowDorisCarlos”))
请注意，与典型的ᴇɴᴄʀʏᴘᴛ()函数不同，ᴇɴᴄʀʏᴘᴛSEF()函数具有硬编码的IV“EscowDorisCarlos”且不进行zlib压缩。此外，尽管ᴇɴᴄʀʏᴘᴛSEF()使用r而不是k作为AES密钥，但k还与AES加密结果进行异或。每个字段“S”、“E”和“F”都根据ᴇɴᴄʀʏᴘᴛSEF()函数进行单独加密和编码。
尽管使用了这种修改后的加密算法，我们仍然能够成功攻击这些字段的加密。我们能够应用CBC填充预言攻击，使用搜狗对“E”表单字段的处理来替代我们通常使用的“U”表单字段，但有以下两个适应：
首先，由于密钥k是32字节，而AES块是16字节，当AES块密码的输出与k进行异或时，我们可以将输出视为与两个密钥k1和k2进行异或的结果，其中k1与奇数块（1、3、…）进行异或，k2与偶数块（2、4、…）进行异或（请参见图3的示例）。因此，在进行CBC填充预言攻击时，我们必须确保我们攻击的块在原始块为偶数时处于偶数位置，原始块为奇数时处于奇数位置。换句话说，我们必须保持块位置的奇偶性。
其次，由于IV是硬编码的，我们无法修改它，因此，类似于Windows版本，CBC填充预言攻击无法在没有适应的情况下恢复第一个明文块p1。换句话说，我们发现p1对于“S”、“E”和“F”字段仍然是可恢复的，通过以下步骤：
我们将固定的IV“EscowDorisCarlos”视为第一个密文块c1之前的一个密文块c0，并将其发送给预言。由于c1必须位于奇数位置，我们确保c0位于偶数位置。因此，在攻击过程中，预言在解密第一个密文块c1时首先将c0与k2进行异或。
结果，解密c1会产生p1'，它等于p1 ⊕ “EscowDorisCarlos” ⊕ c0 ⊕ k2。
由于（根据步骤1）c0 = “EscowDorisCarlos”，p1'仅仅是p1 ⊕ k2。因此，通过应用步骤1-3，我们恢复了“S”、“E”和“F”字段的p1 ⊕ k2。
此外，我们还发现“S”字段的第一个明文块的内容非常可预测。具体而言，它们包含正在使用的搜狗版本，这已经作为EncryptWall请求的HTTP头明文传输，因此任何网络窃听者都可以获得这些信息。因此，在“S”字段的情况下，我们知道p1。在步骤3中，我们恢复了“S”字段的p1 ⊕ k2。由于我们知道p1和p1 ⊕ k2，因此我们已经恢复了k2。
一旦我们知道了k2，它对于“E”和“F”字段也是相同的值，因为（根据步骤3）我们知道了“E”和“F”字段的p1 ⊕ k2，我们也可以恢复“E”和“F”的p1。
此外，我们现在还可以恢复r的第二半部分r2，这对于攻击者很有帮助，因为我们对r2的了解可以在随后的请求中更容易地恢复k2。请记住，“R”字段对k ⊕ r进行编码。因此，在恢复k2后，我们可以通过将“R”字段的编码内容的第二半部分与k2进行异或来恢复r2。一旦恢复了r2，由于r与k不同，每个应用程序生命周期只生成一次，我们可以更容易地通过将“R”的第二半部分与r2进行异或来在将来的请求中恢复k2，从而使攻击更容易进行。此外，这也降低了r的熵，因此也降低了k的熵，使其为3616 < 283位。
作为此攻击易受攻击的数据的另一个示例，我们观察到对于发送到“http://v2.get.sogou.com/q”的EncryptWall请求，当“U”为“http://swc.pinyin.sogou.com/swc.php” 时，“P”是一个包含当前输入字段中的所有文本以及文本所在应用程序的包名的protobuf缓冲区（请参见图4的示例）。这些传输发生在按下放大镜图标时，我们认为这些传输与一种图像搜索功能有关，其中输入的文本将与动画和表情包的数据库进行搜索，并可以插入到输入的消息中。由于这些传输易受我们的攻击，搜狗输入法用户的按键是网络窃听者可以解密的内容，从而告知窃听者这些用户在输入时正在输入什么。
作为此攻击易受攻击的数据的另一个示例，我们观察到对于发送到“http://v2.get.sogou.com/q”的EncryptWall请求，当“U”为“http://update.ping.android.shouji.sogou.com/update.gif” 时，“P”是一个查询字符串，其中包含Android设备上安装的每个应用程序的列表。我们不知道这个数据传输实现的具体功能是什么。虽然可以想象知道用户当前正在使用的应用程序可能有助于在该应用程序中提供更好的输入建议，但很难想象知道用户安装了每个应用程序，甚至是用户不打算与搜狗输入法一起使用的应用程序，如何提供更好的输入建议。
iOS版本11.21
我们分析的iOS版本与基本的EncryptWall实现没有明显的偏差。然而，与我们在某些平台上观察到的一些EncryptWall请求通过加密的HTTPS发送，其他通过明文HTTP发送不同，我们观察到的所有由我们分析的iOS版本发送的EncryptWall请求都通过HTTPS发送，因此我们认为它们在网络窃听方面是安全的。然而，我们注意到，如果没有HTTPS的额外保护，iOS版本将是最容易受到攻击的，因为在EncryptWall的实现中存在另一个缺陷。具体而言，我们发现iOS版本根据以下代码随机选择密钥k和IV v：
请注意，在随机生成密钥之前，随机数生成器以从Unix纪元以来的秒数为种子，向下取整。这种行为有两个后果：首先，推导AES密钥k所需的唯一信息是请求发送的时间，任何网络窃听者都可以轻松记录。其次，由于随机数生成器在生成IV v之前使用几乎总是相同的时间进行重新种子化，v几乎总是k的前128位。由于v是公开的，所有的EncryptWall消息都会在v中公开k的前半部分，尽管k使用公共RSA密钥进行了加密。
然而，我们再次注意到，由于EncryptWall请求在iOS上似乎总是额外包装在HTTPS中，因此目前无法利用这个缺陷。然而，由于这个缺陷的严重性，我们仍然不得不提及它，因为先前的iOS版本可能会受到影响，并且这段代码可能会在其他可能存在漏洞的应用程序中被重用。
缓解措施
为了解决报告的问题，搜狗输入法应该使用流行的、最新的HTTPS或TLS实现来保护所有传输，而不是依赖自定义的加密来保护敏感用户数据的传输。此外，搜狗输入法不应传输对程序功能无关的数据。
协调披露
2023年5月31日，我们在附上的信函中向腾讯披露了我们的发现，遵循我们的安全披露漏洞政策。下表3是我们的披露时间表：
日期 联系方式
2023年5月31日 漏洞披露给IMETS@tencent.com。
2023年6月16日 通过腾讯安全响应中心（TSRC）网门披露漏洞。
2023年6月25日 我们通过TSRC门户收到以下回复：
“感谢您对腾讯安全的关注。对于此问题，没有低或低安全风险。期待您的下一个更令人兴奋的报告。”
2023年6月25日 18小时后，我们通过TSRC门户收到以下回复：
“很抱歉，我之前的回复是错误的，我们正在处理这个漏洞，请不要公开，非常感谢您的报告。”
腾讯对我们的披露的最初拒绝和随后的改变成为本报告标题的灵感。
2023年6月26日 我们通过TSRC门户发送以下消息：
“感谢您的更新。我们将在2023年7月31日之后公开披露此漏洞。”
2023年6月28日 我们通过TSRC门户收到以下回复：
“非常感谢您的报告，修复计划和修复时间已通过电子邮件回复给disclosure@citizenlab.ca。”
2023年6月28日 我们通过TSRC门户发送以下消息：
“我们没有在该地址收到此类电子邮件。然而，我们注意到我们的域名（citizenlab.ca）可能无法从中国访问，因此来自中国的电子邮件可能无法传递到该地址。您能否将您发送到disclosure@citizenlab.ca的电子邮件的副本发送到我的另一个电子邮件地址[已删除]@utoronto.ca？我相信从中国发送电子邮件到这个utoronto.ca地址不会有问题。谢谢。”
2023年6月29日 我们通过TSRC门户收到以下回复：
“我们发送的电子邮件是security@tencent.com，主题是：回复搜狗拼音法漏洞，可能被归类为垃圾邮件？”
2023年6月29日 我们通过TSRC门户发送以下消息：
“不幸的是，我们没有在该地址收到此类电子邮件，甚至没有在垃圾邮件文件夹中收到。您能否尝试将电子邮件的副本发送到我的另一个电子邮件地址[已删除]@utoronto.ca？谢谢。”
2023年7月4日 我们通过TSRC门户收到以下回复：
“您能使用disclosure@citizenlab.ca给security@tencent.com发送一封未经请求的电子邮件吗？然后我将把修复细节发送到[已删除]@utoronto.ca。”
2023年7月4日 我们通过TSRC门户发送以下消息：
“是的，我们现在已经发送了这样一封电子邮件，正在等待您的回复。”
2023年7月4日 我们在[已删除]@utoronto.ca电子邮件地址收到以下回复。在电子邮件回复中，搜狗输入法开发人员概述了他们已经在电子邮件日期之前部署的部分缓解措施，以及将在2023年7月31日之前将所有平台迁移到使用TLS加密的时间表。
2023年7月18日 我们发现搜狗输入法开发人员已经发布了每个平台的应用程序版本，这些版本被确定为修复我们发现的问题的版本。我们发现Windows和iOS版本解决了我们报告的问题，但Android版本没有。因此，我们通过TSRC门户发送以下消息：
“你好。在您发送给我们的电子邮件中，您指出Android应用程序的11.25版本将升级为使用HTTPS发送EncryptWall请求。我们分析了11.25版本（SogouInput_11.25_android_sweb.apk），发现它仍然没有使用HTTPS来传输我们在披露中发现的所有EncryptWall请求，包括我们报告的请求。11.25版本仍然是应该包含这些修复的Android应用程序版本吗，还是将在未来版本中修复？”
2023年7月20日 我们发现搜狗输入法开发人员已经发布了Android应用程序的11.26版本。我们发现这个版本解决了我们报告的所有问题。
2023年7月21日 TSRC门户提示以下消息：
“漏洞已修复，请查看并检查是否仍存在。如果已修复，请点击“已修复”；如果未修复，请点击“未修复”。”
我们点击了“已修复”。
2023年7月22日 我们通过TSRC门户收到以下回复：
“感谢您的反馈。我们将在内部进行调查。”
2023年7月24日 我们通过TSRC门户收到以下回复：
“非常感谢您的反馈，我们的最新修复版本是11.26（SogouInput_11.26_android_sweb.apk），您可以从我们的官方网站https://shurufa.sogou.com/下载。如果您有其他问题，请告诉我们。谢谢。”
2023年7月27日 我们在[已删除]@utoronto.ca电子邮件地址收到以下电子邮件。在电子邮件中，搜狗输入法开发人员向我们提供了包含修复的版本，并询问我们公开披露的“确切时间、网站和具体内容”。
2023年7月27日 我们通过[已删除]@utoronto.ca发送以下回复：
“我们可以确认您已经修复了我们报告的漏洞。我们将在2023年7月31日之后公开披露这些漏洞。我们将在我们的网站https://citizenlab.ca/上发布有关安全漏洞的详细报告。”
2023年7月29日 我们在[已删除]@utoronto.ca电子邮件地址收到以下电子邮件。在电子邮件中，搜狗输入法表示他们致力于隐私和安全，并解释了他们实施EncryptWall系统的最初动机，并提醒我们他们对报告的漏洞的快速解决。
表3：漏洞披露时间表。
2023年7月4日，我们评估了搜狗输入法开发人员在2023年6月30日应用的部分缓解措施，其中，如果出现错误，搜狗服务器始终返回相同的HTTP状态码-400-而不是根据是否存在填充错误或某个更高级别的应用层返回400或500。虽然这减轻了我们对Windows版本搜狗输入法的攻击以及对Android版本的“U”、“G”和“P”字段的攻击，但我们对Android的“S”、“E”和“F”字段的攻击仍然有效，因为它依赖于区分HTTP状态码400和200，其中200是成功代码而不是错误代码，而且这种缓解只是修改服务器，在发生错误的情况下无条件返回状态码400。
平台 修复版本
Windows 13.7
Android 11.26
iOS 11.25
表4：搜狗输入法的修复版本。
在搜狗输入法开发人员的2023年7月4日的通信中，他们表示Windows版本的应用程序的13.7版本和Android和iOS版本的应用程序的11.25版本将解决我们报告的问题。2023年7月18日，我们发现这些版本的应用程序已经发布。请注意，这些更新是在我们强制执行的7月31日截止日期之前发布的。分析更新的Windows版本，我们发现所有EncryptWall流量都使用操作系统的WinHTTP服务提供的TLS实现进行加密，令人满意地修复了我们在Windows版本中报告的漏洞。请记住，我们不知道如何利用我们在iOS版本中发现的问题。尽管最初将11.25版本确定为解决我们报告的漏洞，但我们发现2023年7月20日，搜狗输入法开发人员发布了Android应用程序的11.26版本，并且该版本使用TLS加密所有EncryptWall流量，令人满意地修复了我们在Android版本中报告的漏洞。因此，到2023年7月20日，我们报告的所有问题都已修复（请参见表4以获取修复版本的摘要）。
我们在收到腾讯对我们披露的电子邮件回复方面遇到的困难突显了在向某些司法管辖区的公司披露漏洞时面临的意外挑战。在向腾讯披露漏洞后，我们发现我们的电子邮件域名（citizenlab.ca）在中国被屏蔽。具体而言，我们发现中国的国家防火墙对查询此域名（包括MX记录查询）的DNS回复注入了异常的DNS回复。注入的DNS回复包含一个看似任意的IP地址的A记录，即使查询是针对MX记录而不是A记录。当执行A记录查询的客户端收到其中一个注入的回复时，它将错误地使用注入回复中的虚假IP地址。然而，对于MX记录，这些注入的回复可能会被DNS客户端解释为错误，因为在MX查询中收到A记录，而DNS客户端对注入域名的MX查询可能只是失败，而不是像A查询中那样错误地使用虚假记录。尽管这种注入行为可能旨在阻止中国用户访问我们的网站，但它也妨碍了中国用户发送电子邮件给我们的能力，即使这样的电子邮件是经过征求的。
我们无法确定中国屏蔽我们域名的原因是腾讯的电子邮件未能传递到我们域名的电子邮件服务器，但我们收到了一些后来的证据，进一步加强了这个假设。我们在[已删除]@utoronto.ca上收到的7月27日的电子邮件也发送到了disclosure@citizenlab.ca。最终，disclosure@citizenlab.ca地址在24小时后收到了电子邮件。通过检查电子邮件的标头，我们发现电子邮件在腾讯的邮件服务器和Google的MX服务器之间停滞不前。由于Google是我们的电子邮件提供商在citizenlab.ca MX记录中，这一发现加强了腾讯的邮件服务器在查找我们域名的MX记录时遇到困难的假设。电子邮件可能最终在24小时后被传递，这是由于中国防火墙的间歇性故障或数据包丢失导致防火墙注入的DNS回复丢失，从而使我们域名的MX查询最终成功。因此，我们选择使用另一个我们最了解的在任何国家都没有被屏蔽的域名进行所有未来的披露，以确保我们不会在协调披露期间未能收到关键的沟通。同时，我们要求防火墙操作员考虑阻止域名可能会产生意想不到的后果，例如对那些可能在参与重要对话期间受到防火墙背后的软件漏洞影响的人的持续漏洞的贡献。
限制
在本报告中，我们详细介绍了搜狗EncryptWall加密系统在搜狗输入法中的使用的漏洞。然而，在这项工作中，我们没有对搜狗输入法进行全面审计，也没有尝试全面发现软件中的每个安全漏洞。我们的报告涉及我们发现的一组相关漏洞，我们未报告其他漏洞并不意味着这些漏洞不存在的证据。
讨论
在过去的八年中，我们致力于分析、记录和负责任地披露中国开发的应用程序中涉及敏感数据不安全传输的漏洞。尽管我们在与开发人员协调解决这些问题方面取得了一些成功，但该生态系统仍存在问题，因为我们在这里再次报告一个难以想象的受欢迎的中国开发的应用程序未能采用甚至简单的最佳实践来保护其传输的敏感数据。在这种情况下，搜狗输入法是一个拥有超过4.5亿用户的应用程序，未能正确保护敏感数据的传输，包括用户输入的按键，使得任何网络窃听者都可以恢复这些数据。通过采用常见且成熟的加密协议TLS，而不是使用“自制”加密方法，可以轻松避免这种漏洞。虽然没有完美的加密协议，但TLS实现在2003年已经改善了对CBC填充错误攻击的脆弱性，这已经是本文撰写时的二十年前了。我们已经认识到，协调的安全披露远远不足以保护中国应用程序传输的用户数据。我们认为，需要对软件开发生态系统进行全面的变革，以解决这些系统性问题。
即使已经解决了报告的漏洞，搜狗应用程序仍依赖将键入的内容传输到搜狗的服务器作为其普通功能的一部分。来自世界各地的用户的按键输入被传输到中国大陆的服务器，这些服务器在中国政府的法律管辖下运营。使用搜狗的高风险用户应该谨慎，因为键入的内容可能包含敏感或个人信息。本报告中概述的攻击演示了网络窃听者如何解密这些数据。然而，即使漏洞得到解决，这些数据仍然可以被搜狗的运营商和与他们共享数据的任何人访问。
致谢
我们要感谢Jakub Dalek、Pellaeon Lin、Adam Senft和Mari Zhou对编辑和同行评审的宝贵贡献。该项目的研究由Ron Deibert监督。
没有评论:
发表评论