针对一次性验证码短信的安全性研究（上）

 

包含一次性密码（OTP，One-Time Password）的短信消息（SMS）是在移动App中执行身份验证的一种广泛使用的机制。实际上，许多流行的App都将通过SMS接收的OTP作为唯一的身份验证因素，完全取代了基于密码的身份验证方案。尽管SMS-OTP身份验证机制为终端用户提供了极大的便利，但是它们也具有重大的安全隐患。在本文中研究了基于SMS-OTP的移动App的身份验证方案，尤其是对本地攻击（Local Attack）所构成的威胁进行了系统的研究，在这种情况下，攻击者可以控制受害者设备上非特权的第三方App。

 

0x01 Introduction

SMS消息（也称为“文本消息”）被广泛用于双因素身份验证机制（2FA，Two-Factor Authentication）。在这些情况下，除用户名和密码外，还要求用户提供通过SMS接收到的Token。此外，在移动App领域，SMS也已开始用作单因素一次性密码（简称1FA OTP）。在这些情况下，要求用户证明所有权或他们自己的电话号码，这是主要的用户标识符：“拥有电话号码”等同于“拥有用户帐户”。通过首先询问用户的电话号码，然后向该号码发送验证码来实现此机制。最后，要求用户插入接收到的验证码，或者App自动从传入的SMS中读取验证码，这时App可以将验证码发送回App的后端。此过程证明了特定电话号码（和相应的SIM卡）的所有权。注意到该协议如何有效地将SMS通道用作验证用户帐户的唯一因素。

不幸的是，由于已多次证明SMS通信通道不安全，因此该机制也带来了重大的安全隐患。攻击者已经多次能够锁定电话网络，并将OTP消息成功重定向到其它的接收者。最突出的例子是SIM交换攻击（SIM-swapping），攻击者可以诱使电话公司获取与受害者电话号码相关的SIM卡。此问题的另一个实例是利用SS7网络（电信公司内部用于路由呼叫和SMS消息的网络）。而且，众所周知，州级攻击者可以通过干扰本地电信公司来拦截SMS OTP消息。最近一项研究显示，许多Android应用程序不安全地实现了在其身份验证协议中使用的SMS OTP的生成和验证。例如，某些App生成的SMS OTP的随机性或长度不足。

针对SMS OTP身份验证方案的本地攻击：尽管先前的工作集中于利用SMS通道本身中的漏洞，但在本文中，集中于针对SMS OTP消息的另一类攻击，将其称为本地攻击。对于本地攻击，本文指出了一种威胁模型，其中攻击者可以控制在受害者设备上安装的恶意第三方App。然后，恶意App的目标是窃取通过SMS发送的身份验证码。这些攻击对于使用上述1FA OTP身份验证机制的App来说是毁灭性的，因为它们允许获取用于身份验证用户的唯一因素。此外，由于它们允许获得两个因素之一，因此它们也削弱了传统的基于SMS的2FA解决方案的安全性。

OS更新以支持SMS OTP自动认证：为了向更安全的SMS OTP验证方式迈进，Android和iOS均采用了保护机制，以防止未经授权的App读取SMS OTP消息。例如，iOS不允许任何第三方App读取或访问SMS消息。另一方面，在Android设备中，第三方App可以请求读取已接收SMS消息（包括可能包含OTP的消息）的权限。但是，从2019年1月开始，已经设置了限制，以限制与SMS相关的权限的使用。

阻止App随意读取SMS消息可提高基于SMS的身份验证方案的安全性，因为它阻止了自动利用（即，无需用户参与）。但是，这也会影响整体用户体验，因为可能要求用户在请求它们的合法App中逐个字符地手动键入这些OTP消息。因此，iOS和Android引入了处理OTP消息的新机制，旨在同时提供更多的安全保证和更好的用户体验。

尽管这些机制作为SMS OTP身份验证的未来主流更加可行和有希望，但在了解这些机制是否确实安全方面做得很少，这对于SMS OTP身份验证是最关键的事情。不幸的是，正如将在本文中展示的那样，这些新机制在使用它们的移动App中引入了一系列新的弱点和漏洞。本文的发现是重要且令人担忧的，尤其是因为这些最新的保护OTP的安全机制是专门设计用来保护免受本地攻击者威胁的模型的。

 

0x02 Threat Model and 1FA SMS Schemes

在本节中，首先讨论研究中考虑的威胁模型和假设，然后概述许多流行App采用的基于1FA OTP SMS的身份验证方案，以及本地攻击者如何利用它们的漏洞。

A.威胁模型

攻击者模型和能力：本文着重于本地攻击。这些攻击由攻击者控制，该攻击者控制了受害者移动设备上安装的恶意App。注意到，这是移动安全领域中常见的威胁模型，与先前的工作保持一致。实际上，不幸的是，对于攻击者而言，将恶意功能包含在一个看似良性和有用的App中，然后通过App市场进行分发，是可行和实用的。

还假设恶意App可以通过Internet进行通信，以将SMS OTP消息（或其包含的验证码）发送给攻击者。在Android中，这需要Internet权限。请注意，此权限并不是可疑的，因为绝大多数移动App都要求此权限（例如，最近的一份报告显示Google Play商店中有83％的App需要此权限）。另外，由于联网许可被认为是“正常”的，因此获取它不需要任何用户交互，并且它也没有在允许用户授予/撤消许可的菜单中列出。

为了触发将SMS OTP消息传送到受害者的设备，还假定攻击者知道受害者的电话号码。这个假设与以前的工作中进行的类似攻击是一致的。攻击者可以通过多种方式获取受害者的电话号码。例如，许多消息传递App都使用电话号码作为主要用户标识符。在这些App中，让受害者为“朋友”会自动显示其电话号码。此外，在Android中，恶意App可能会使用Android API getLine1Number( )来获取电话号码（需要READ PHONE STATE权限）。此外，安装在受害者手机上的恶意App可能会显示外观合法的用户界面，并要求提供电话号码以进行身份验证。

尽管上述威胁模型和假设在整篇文章中都是有效的，但将要提出的某些攻击受到不同的约束。特别是将要进行的某些攻击更加困难且不太可能进行，因为例如，它们需要与受害者进行特定的交互，或者需要特定的许可。相反，可以完全自动化的方式进行其他操作）。在讨论每种类型的攻击时，都会精确地指定其他假设。

OS完整性假设：在整个本文中，做出一些其他假设。这些假设在讨论攻击的相关性时很重要（例如，如果其中一些假设不成立，则某些攻击是微不足道的），并且在讨论提出的防御机制的可靠性时，这些假设也很重要。在本文中，假设Android操作系统（包括内核和各种系统组件（例如Android系统服务））没有受到损害。因此，假设App隔离和权限已正确实施。在文中还假设操作系统和App可以建立安全的进程间通信（IPC）通道，并且通过使用专用API（例如，绑定到系统服务，pending intents），App可以安全地与系统服务进行通信，同时，系统服务可以知道与之通信的App的身份。

先前的工作表明，操作系统和App可能容易受到多种攻击，例如广播注入和广播接收器劫持，组件劫持漏洞以及组件泄漏和服务劫持。这些是经过精心研究的漏洞类别，假设App受到了保护。最后，考虑基于范围的基于UI的攻击，这些攻击试图暗中劫持用户交互，例如活动劫持或基于可访问性的攻击。现代的Android版本启用了多种保护机制来防止这些攻击。例如，如果存在任何重叠，用户现在会看到警告，并且恶意App不再知道用户正在与之交互的App。

B.基于SMS的单因素身份验证方案

流行的信息传递App使用的一种常见模式是用电话号码识别用户，该用户应该拥有相应的SIM卡。这旨在替换更传统的用户名。在这种情况下，SMS OTP消息用于证明特定电话号码的所有权。如今，这样的自动加密方案已被许多流行的App广泛采用。具体来说，在2020年5月进行的一项初步研究中，检查了Google Play通信类别中排名前100的流行App，发现有24个App确实使用SMS OTP消息作为唯一的身份验证因素。

上图显示了SMS OTP身份验证过程的多个步骤。可以看出，在这种情况下，客户端（合法App）首先将电话号码发送到App的后端服务器（步骤1）。然后，App的后端服务器会生成一条OTP码，并使用SMS消息将其发送到请求进行身份验证的电话（步骤2）。之后，合法App在移动设备端获取SMS（步骤3），提取OTP码，然后通过网络连接将其发送回App服务器（步骤4）。最后，该App的后端服务器通过将接收到的OTP码与之前的OTP码进行比较来进行验证，并通过SMS将其发送出去（步骤5）。验证通过后，后端服务器将发送自己使用的Token，以认证与移动App的后续交互，以进行进一步的通信。

在此过程中，需要确保具有不同的属性以确保安全的验证方案。例如，在步骤2中，生成的OTP需要具有足够的熵才能抵抗对手的暴力攻击。同样，在步骤5中，需要将生成的OTP与App提供的OTP进行比较。这些安全属性之前已经过研究和讨论，并发现在某些App的实现中遭到了侵犯。

具体来说，AUTH-EYE表明，在许多情况下，SMS OTP生成不正确（例如，OTP随机性不足或OTP长度不足），或者OTP码验证不正确（例如，允许的重试次数过多或续订间隔太长）。本文的工作是对AUTH-EYE的补充。实际上，在本文工作中，假设OTP生成和OTP验证已正确实现，相反，专注于SMS OTP如何传递到App并从中读取信息。特别是，将重点放在身份验证过程中使用的OTP机密性方面的潜在弱点。更具体地说，在第3步中，至关重要的是只有合法的App才能读取由该App后端发送的OTP消息，而不是该设备上托管的其他App。

C.端到端攻击方案的示例

如果攻击者控制的恶意App能够获得针对另一个App的OTP，则攻击者可以轻松绕过基于SMS的单因素身份验证方案。特别是，控制受害者手机上恶意App的攻击者可以通过以下三个步骤来实现此恶意目标：

1）攻击者使用受害者App的后端启动身份验证，将受害者的后端指定为电话号码；

2）攻击者使用恶意App窃取受害设备通过短信接收的OTP，然后通过恶意App将OTP发送出去（例如，发送到攻击者控制的设备）；

3）当要求在第一步中启动的身份验证过程中插入OTP时，攻击者使用被盗的OTP与App的后端一起完成身份验证过程，实际上是在冒充受害者。

本文的重点是解释攻击者如何恶意获取SMS OTP消息，即上面列表中的第二步。其他两个步骤虽然对于每个受害者的App都略有不同，但可以使用例如由攻击者控制的设备轻松地执行（甚至可能完全自动化）。所呈现的不同攻击可能会在SMS OTP发送到受害者设备的时间与攻击者将OTP发送到App的后端服务器的时间之间造成延迟。尽管正确实施的基于SMS的单因素身份验证方案应为OTP设置最大有效时间，但该值通常在几分钟左右，而本文的攻击所引入的延迟则在几秒左右。

 

0x03 Legitimate Methods To Access SMS OTP Messages

在本节中列举了Android和iOS上App可用来访问收到的SMS OTP消息的不同方法。稍后，将描述不同的方法如何受到不同的攻击。

在本文中，考虑了分别在Android和iOS版本10和12中可用的功能。虽然对于iOS，用于SMS OTP消息的可用方法非常有限，但是Android提供了许多不同的方法，并由不同的API提供支持，有时会有细微的或文献记载不充分的差异。本节（针对两种OS）详细讨论了这些方法，并根据用户要求的交互类型（如果有）分为三个部分：需要按消息用户交互的方法，需要与SMS相关的权限的方法，以及不需要用户交互的全自动方法。

A.与用户互动的访问

App可能会要求用户将收到的短信中的OTP码手动复制（即逐个字符插入）到App的用户界面。此方法不需要任何特定的App许可，也不需要使用任何特定的API。但是，这种类型的用户交互容易受到“phishing attacks”的影响，在这种情况下，用户可能会被诱骗将刚刚接收到的OTP插入前台的App中，这可能是恶意的。此外，此过程涉及一些费力的用户交互，从而在App身份验证过程中引入了“friction”。

因此，为了增强用户体验，Android和iOS的现代版本均提供了更友好的SMS STP验证界面。具体来说，在Android（从其默认消息传递App版本3.3+开始）和iOS（从iOS 12开始）中，系统均提供“ask-to-copy”功能，该功能可以自动解析每条传入的SMS消息以查看是否它们包含OTP令牌。如上图（a）所示，对于Android，一旦从收到的SMS消息中识别出了OTP码，系统就会在系统键盘上显示一个“copy”选项，该选项会自动将OTP复制到设备的剪贴板中。这使用户可以将OTP粘贴到当前等待的App中。同样，对于iOS（上图（b）），解析后的OTP码将在输入键盘中列出。一旦用户单击它，OTP码将自动填充到App的当前输入字段中。这两个功能使用户不再需要在等待OTP的SMS收件箱和App之间进行切换，从而简化了身份验证过程。注意到，在iOS中，“ask-to-copy”功能是可用于增强SMS OTP输入的唯一选项。例如，iOS不向第三方App提供任何机制来读取存储在SMS收件箱中的消息。

一键式短信验证：Android还提供了另一种方法，称为用于SMS OTP身份验证的一键式（One-Tap）SMS。与前面提到的方法相比，一键式SMS提供了更多的用户提示，并消除了复制粘贴交互。具体来说，如上图（c）所示，此机制将弹出窗口显示为用户同意的形式，以将给定的OTP码直接填充到特定App中。如果用户允许该App访问并解析包含OTP码的传入消息，则该码将直接传递给该App。但是，这种方法需要开发人员（而不是Android操作系统）进行更多的App侧实现。重要的是要注意，它不同于“ask-to-copy”机制；一键式机制向用户显示App名称，消息将被复制到该App中（比较图（a）和图（c））。此设计可能有助于防止网络钓鱼攻击，但它不能从根本上解决问题。

B.通过请求SMS权限进行访问

在Android中，App可以请求与SMS相关的权限，以编程方式访问SMS收件箱。这两个相关的权限是READ_SMS和RECEIVE_SMS：第一个权限允许App随时读取SMS收件箱，而第二个权限则允许App仅在将“新”传入消息保存到收件箱之前读取它们。

这两种权限都为App提供了敏感的（在安全性和隐私性方面）功能，因为它们允许App读取任意SMS消息，即使这些消息与App功能无关。因此，Android OS将这些权限归类为Dangerous（从Android 6开始），并且在运行时需要一次性用户许可（如下图所示）。

附加限制：考虑到这些权限与安全性的关系，从2019年1月开始，Google对上传到Play商店的任何要求与SMS相关的权限的App都引入了附加限制。第一个限制是这些权限只能由设计为“ SMS handler”的App请求，即替换默认的SMS处理程序App。旨在成为“ SMS handler”的App必须遵循其他政策：

•该App必须适合作为SMS处理程序App（例如，它需要允许用户阅读收到的短信，发送新短信等）；

•该App必须在首次使用时询问用户是否要将当前的默认SMS应用程序更改为该App。

为了实施这些限制，市场对需要这些权限的每个App进行人工人工协助验证。不幸的是，即使有这些限制，仍将证明开发人员仍然可以设法将其恶意App发布到Google Play商店。此外研究还表明，用户并不了解授予向App读取SMS消息的权限所带来的安全隐患。

C.通过现代SMS API进行全自动访问

为了进一步改善App的用户体验，Android引入了三种不同的API，以完全自动化的方式支持SMS OTP身份验证，而无需任何许可和用户交互。在本文的其余部分，将这些API统称为“Modern SMS API”。

关键设计和优势：这些现代SMS API的总体思想是要求App服务器发送带有附加可识别字符串（例如，从加密签名中获得的Hash值）的身份验证SMS消息，该字符串将指示OTP码的预期接收者。可识别的字符串允许OS仅将SMS消息传递给预期的目标App，而不传递给其他目标App。这些机制以自动化方式而不是用户干预（即，要求用户手动输入OTP码）简化上述过程的步骤3。此外，这些机制的设计不需要App要求任何Android许可。这些好处进一步鼓励了App开发人员采用这些方法来实施SMS OTP 1FA，因为App不再由于需要权限而受到限制和限制，也不需要用户交互来复制接收到的消息内容。在这里，介绍了这三种不同的API的详细信息。为简单起见，将分别使用SMS Retriever，SMS Token和SMS Token +来引用这些API。下表总结了这三个API的详细信息。

注意到，术语“ API”不是指特定的Java方法，而是指Android框架提供的特定身份验证功能（其用法可能需要调用多个方法）。当引用特定的Java方法（例如，startSMSRetriever( )）时，将改用“方法”一词。

SMS Retriever：SMS Retriever API使用Hash码（例如FA+9qCX9VSu）来指定应将SMS OTP交付给哪个App。此App特定的Hash码是从App的签名证书及其程序包名称开始计算的。具体来说，它是使用以下公式计算的：

其中concat表示字符串连接，而truncate(string，X)表示X个字符后的字符串截断。

Android中的签名证书嵌入在App的程序包文件中，并且与开发人员用于签名App的私钥相关联。程序包名称是一个字符串，用于唯一标识移动设备和Google Play商店上的App（即，同一设备上或Google Play商店中的两个App不能具有相同的程序包名称）。由于开发人员应该安全地持有私钥，因此攻击者无法使用相同的App证书创建有效的签名APK。反过来，这应意味着攻击者无法轻易创建恶意App，从而使其Hash码与良性App的Hash码发生冲突（由于SHA256的弱抗碰撞性）。

如上图所示，在App调用方法startSmsRetriever( )并注册了SmsRetriever.SMS_RETRIEVED_ACTION Android侦听器（步骤0）之后，包含该App特定Hash码的后续文本消息将自动路由到该App。换句话说，App不需要任何Android权限即可读取包含其自己的Hash码的消息。因此，当App使用SMS Retriever API时，在步骤2中，服务器发送一条消息，其中包含OTP码和Hash码。

SMS Token：SMS Retriever的限制之一是仅在Google Play服务可用时才支持它。此限制使某些情况下的某些Android设备（例如中国的未安装Google Play服务的Android设备）不可行。因此，从2017年8月开始，Google提供了一个新API来实现自动SMS OTP身份验证，所有具有Android 8或更高版本的设备都可以使用该API。在本文中，将此API称为SMS Token。

SMS Token的预期用法类似于SMS Retriever。但是，SMS Token在生成特定于App的Token的方式方面有所不同，当该Token包含在SMS中时，会导致操作系统将其重定向到预期的App。具体来说，如上图所示，虽然SMS Retriever使用固定的，特定于App的Hash码，但每次调用cre ateAppSpecificSmsToken( )方法时，SMS Token API都会生成一个随机Token（步骤0）。该Token应该从电话发送到后端服务器（在步骤1中）。此外，基于SMS消息中包含的Token，将SMS OTP消息传递到合法App。例如，如果App程序A获得了随机令牌Eqhn SOxhzw作为createAppSpecificSmsToken( )方法调用的返回值，则随后收到的包含文本Eqhn SOxhzw的SMS消息将被传递到App程序A。

SMS Token+：Android 10引入了另一个与SMS相关的API，可通过使用createAppSpecificSmsTokenWithPack ageInfo( )方法来调用，简称为SMS Token+。此API会生成另一种Token，用于自动SMS身份验证。根据开发人员指南中的API描述，可能会认为此API与SMS Token API的工作方式非常相似。

实际上，根据文档，唯一的区别是，此新API允许开发人员为SMS过滤提供附加的前缀列表。仅以这些指定前缀之一开头的SMS会被传递到呼叫App。

读者可能会注意到指定前缀的可能性如何不会影响此API的安全性。因此，人们会认为此API与先前的SMS Token一样安全（或不安全）。令人惊讶的是，事实并非如此：虽然这两个API似乎以相同的方式工作，并且它们具有非常相似的文档（唯一声明的区别在于能够基于前缀进行过滤），但这两个API在内部以非常不同的方式实现。更加有趣的是，分析发现SMS Token+仍然容易受到攻击。

 

0x04 How To Maliciously Obtain SMS OTPS

如前一节所述，在现代平台中，App可以通过多种方式读取用于身份验证的SMS OTP消息（前文步骤3）。不幸的是，正如在以下各节中详细解释的那样，所有这些方法都包含潜在的陷阱。即使对于旨在使访问SMS OTP更加安全的那些方法，也是如此。具体地说，展示了新引入的简化SMS消息中的OTP复制和粘贴机制，因为它们仍然容易受到欺骗攻击，因此并不能提高总体安全性。

然后，用户可能愿意将READ_SMS权限授予恶意App。结果是对以前关于用户如何（误）理解权限的研究的补充。实际上，研究表明，对于READ_SMS权限的特定情况，大多数用户对它的工作方式都有一般的了解，但是他们不知道能够读取SMS的App也可能会损害其他App的帐户。

最后，将展示为在Android中自动读取SMS OTP消息而引入的新API容易出错，或者本质上是不安全的。因此，许多使用这些API的App很容易受到攻击。此外，攻击这些易受攻击的App可以自动完成，而无需任何用户交互。实

 

0x05 Getting SMS OTPS By Deceiving Users

在本节中，详细介绍了攻击者可以欺骗用户并通过没有任何SMS相关权限的恶意安装的App获取SMS OTP消息的攻击。与以前的网络钓鱼攻击不同，在此网络钓鱼攻击中，恶意App模仿了真实的UI并窃取用户输入，在这里，着重于了解新引入的基于用户交互的机制（例如，一键式机制）会影响UI欺骗攻击的功效。具体来说，首先详细说明攻击情形及其根本原因。然后进行用户研究，以客观地衡量此类基于用户交互的SMS OTP身份验证机制的潜在弱点。

A.假设

本节中提出的攻击假设攻击者能够欺骗用户。为了欺骗用户，攻击者控制了一个恶意App，该App在看似合法的情况下（例如，在SMS OTP 1FA情况下注册新帐户时）请求SMS OTP消息。请注意，如前所述，此攻击与利用OS级漏洞（例如，任务劫持或活动劫持）的其他UI欺骗攻击正交。具体来说，攻击者首先要求用户提供他们的电话号码，这通常是在首次使用SMS OTP与App进行交互时发生的。然后，攻击者通过联系合法App的后端服务器，并指定受害者刚插入的一个作为电话号码，远程请求用户合法帐户（例如，Facebook）的SMS OTP消息。此时，受害者将收到包含合法帐户的OTP的SMS消息，并且由攻击者控制的App将尝试欺骗用户将接收到的OTP插入其中。请注意，由于受害者在插入电话号码后将仅收到一条消息，因此受害者无法通过消息的时间来区分攻击。由于传入消息完全符合用户收到SMS OTP消息的期望，因此受害用户可能会在网络钓鱼App中输入OTP码。合法App后端发送的SMS可能没有明确指出其所针对的App名称的事实，从而使这种欺骗攻击更加严重。

B.了解用户对欺骗攻击的反应

先前的研究已经探索了这种类型的攻击，并根据经验表明，用户很可能会受到他们的吸引。但是，没有人研究过新引入的缓解OTP复制和粘贴用户交互的机制是否可以缓解这种威胁。

因此在本节中，评估了这些新机制在缓解此攻击方面的影响。为此进行了一项用户研究，以测量在不同情况下（包括使用这些新引入的OTP码插入机制的情况）这些欺骗性攻击的有效性。

用户研究设计：为了进行用户研究，获得了机构的IRB批准，并且使用了通过mTurk （一种流行的任务招聘平台）招募的受试者，并成功地将其用于类似的与安全相关的用户研究。通过使用专用的mTurk功能，该功能能够了解不同操作系统的用户体验，选择了熟悉iOS的用户来测试特定于iOS的方案，以及选择熟悉Android的用户来针对Android的特定方案。在评估过程中，删除了那些未完成指定任务或未正确回答验证问题的主题。

要求参加者使用其浏览器访问交互式环境以进行可用性研究，以模拟Android手机或iOS手机。通过使用名为Marvel App的App原型在线工具实现了这种交互式环境。此交互式环境用于模拟网络钓鱼情况，在这种情况下，要求用户在恶意App中注册新帐户。注册过程要求用户输入在SMS消息中收到的OTP。在此过程中，恶意App使用用户的电话号码从另一个帐户（在测试中为流行的通信App程序Telegram）请求OTP消息。在此模拟环境中，参与者可以通过单击OS提供的复制按钮来输入OTP，也可以通过屏幕键盘手动键入OTP。下图介绍了这些方案的详细信息。

将主题分为四类：Android-Manual，Android-One-Tap，iOS-Manual和iOS-Autofill。两个“手册”组中的对象必须专门使用系统键盘来插入OTP。 Android-One-Tap和iOS-Autofill组中的主题分别在Android和iOS中提供了两种用于SMS OTP身份验证的新机制。一旦对象的帐户将OTP码插入恶意App，便认为它们已被盗用。

结果和发现：如上表所示，研究首先确认在不同情况下，在恶意App中插入OTP的主体百分比很高，介于45％至71％之间。更重要的是研究表明，在手动输入和新机制（即Android One-Tap和iOS-Autofill）之间，逃脱攻击的对象所占的百分比没有显着变化。因此得出结论，所有需要用户交互才能获得OTP的当前可用方法，包括新引入的方法，都极易受到欺骗攻击。

作为更具体的示例，请考虑使用Android One-Tap SMS机制。当用户将要插入OTP码时，此机制的界面清楚地显示了App名称。在模拟中，将此名称设置为“ FunnyChat”，而不是“ Telegram”。换句话说，出现在“一键式”界面中的名称就是试图窃取OTP的恶意App的名称。但是，根据用户研究结果，此附加指示仍不能阻止用户将OTP插入恶意App。

此外，还有另一个问题使该机制更容易受到欺骗攻击。具体来说，尽管One-Tap API清楚地向用户显示了要在其中插入文本消息的App的名称，但是验证了恶意App可以任意将其自身命名为目标App，因此在请求目标App的OTP码时很难检测到自身。实际上，能够创建一个在其One-Tap界面上显示名称为“ Telegram”的App，并将其发布在Google Play商店中。总而言之，得出的结论是，在将OTP插入恶意App时，很容易欺骗用户，而新引入的机制（即“询问复制”和“一键式”机制）并不能提高用户的检测能力。这些欺骗性的攻击。

 

0x06 Bypassing OS Permissions and Market Restrictions To Access SMS Messages

对于攻击者而言，在Android中窃取SMS OTP的最直接方法是拥有读取/拦截发送到设备的所有传入SMS的权限。此攻击场景已广为人知，并由先前的研究进行了讨论，现代OS已采用额外的限制作为对策。具体来说，对于攻击者而言，获得此权限既受操作系统级别的限制（这意味着用户必须向App明确授予此权限），也受到市场级别的限制（这要求对请求此权限的App进行额外审查）。但是，在本节的其余部分，将说明由于各种相关的设计漏洞，如何以及在何种条件下仍然可以绕开这些限制。

A.绕过OS级别的限制

利用用户对SMS权限的误解。在Android中，读取SMS的权限被归类为“Dangerous”。因此，想要获取它的App必须显示一个特定的系统管理对话框，用户必须在该对话框上按下“ ALLOW”按钮。

先前的研究表明，由于对技术细节缺乏了解，某些用户将完全忽略有关权限使用的警告，或者无法理解不同权限的含义。但是，在允许阅读短信的特定情况下，情况更加令人担忧。在这种情况下，大多数用户不了解在界面中按“ ALLOW”按钮的全部后果。

为了对这一说法进行实证研究，进行了第二次用户研究，在该研究中询问Android用户，按下“ ALLOW”按钮（在对话框中）会带来什么后果。使用mTurk招募参与者，使用Marvel App模拟与手机的交互，已在与之前的用户研究相同的设置下进行了此用户研究。

在这项研究中，首先显示了Android手机的主屏幕，其中安装了一组著名的流行App（例如WhatsApp，TikTok和Amazon）。然后表明该设备正在安装一个新的App，该App需要具有通过系统对话框窗口发送和读取SMS消息的权限（上图）。最后，要求受试者回答一系列有关在此对话框窗口中按下“ ALLOW”按钮的潜在后果的问题（如下表左列所示）。允许受试者选择多个选项。该调查的详细信息见上图。

总共，从57位有效参与者中收集了答案。从上表中可以看出，由于91％（52/57）的受试者正确选择了option-1，因此可以得出结论，对于绝大多数用户而言，很明显，在权限提示中按下“ ALLOW”按钮允许App读取设备上的所有SMS消息。虽然先前的研究表明许多用户都在努力理解Android权限，但研究表明，对于READ_SMS权限的特定情况，大多数用户对它的工作原理有一个总体的了解。但是，他们中的大多数人都不知道，通过允许某个App读取SMS，该App可能会危害其他App的帐户。实际上，大多数主题都知道权限系统的总体工作原理，但只有39％的主题知道可以读取SMS消息的App也可以读取OTP，因此会损害流行App的帐户。这表明许多用户在Android中做出与权限相关的决定时并未意识到这一特定威胁。

研究认为这是由于以下事实：权限对话框未充分说明此选择的安全性后果。更具体地说，该对话框仅显示“允许（App名称）发送和查看SMS信息？”，但并未提及具有读取SMS消息的能力还使恶意App可以使用1FA SMS OTP破坏这些App的帐户。得出结论，SMS权限提示没有提供足够的信息，有关按下“ ALLOW”按钮的安全后果。

B.绕过市场级别的限制

App版本更新：如前所述，需要权限才能读取SMS收件箱的App在上载到Google Play商店时会受到其他政策的约束。具体来说，该App会由Google Play手动检查，以确保适合作为短信处理程序App。但是发现可以轻松绕过此政策的执行。实际上，能够在Google Play商店中发布不符合这些要求的App。

为了实现这一目标，首先实现了一个App，然后将其上传到市场，等待其批准。获得批准后，对其进行了修改（通过发布更新），并在不显示默认SMS提示的App中对其进行了转换，并且该App能够静默阅读文本消息并在线上传它们。最初的批准花了几天的时间（建议由市场运营商进行全面的分析），而更新则在几个小时内被接受。从理论上讲，还可以通过静态分析来检测添加到上载App中的恶意行为。不幸的是，在实验中情况并非如此。还尝试上传一个请求阅读短信许可的App，但没有遵循市场政策。在这种情况下，该App被拒绝了。

为此，实验表明很可能在更新App时不会执行人工协助验证，因为App更新会在几个小时内被接受，而几天后会接受新的提交。研究认识到，Play商店对待App的方式可能与拥有大量用户的方式有所不同。但是，截至2020年11月，上载的App已被下载了100多次，甚至收到了来自合法用户的一条评论。不过，它没有任何进一步验证的迹象。

请求其他权限：还找到了另一种绕过此审查过程的方法。 Android应用可以获取名为BIND_NOTIFICATION_LISTENER_SERVICE的权限，以读取用户收到的通知。所有收到的SMS消息都会触发包含其内容的通知。因此，具有读取通知权限的App可以有效地读取所有传入消息，包括包含OTP的消息。确实，最近的研究人员在Google Play商店中发现了恶意软件，该恶意软件专门利用通知系统来规避与SMS相关的权限限制，从而窃取其他帐户的OTP消息。除了这项工作已经发现的内容之外，还注意到与READ_SMS权限相比，如何处理读取通知的权限不一致。

具体来说，“reading notification”权限被Android OS视为“特殊”。要获得此许可，App必须要求用户打开专用界面并选择App的名称。因此，从说服用户向恶意App授予此权限的角度来看，获得读取通知的权限比获得读取的SMS许可更困难，因为这需要复杂的用户交互（而不仅仅是按下“允许”按钮）。令人惊讶的是，在Google Play商店上发布请求阅读通知权限的App比发布请求阅读短信权限的App容易，因为它不会触发任何额外的审查。本研究通过向市场提交一个App来确认这一点，该App的唯一行为是要求获得阅读通知的权限。该App已被接受，没有任何特殊要求或延迟。

 

0x07 Conclusion

根据本文的大规模研究发现，共有36个App滥用了这些API，从而使恶意本地攻击者能够完全劫持其帐户。此类易受攻击的App包括Telegram和KakaoTalk，它们是全球一些最流行的消息收发App。最后提出了一种新的更安全的机制来执行基于SMS的身份验证，并使用形式化验证来证明其安全性。在下一文章中，将展示如何在现代Android版本中滥用最新的API以在各种情况下执行自动、隐秘和无用户交互的攻击，以及防御机制。