【技术分享】印度统一支付接口和支付应用程序的安全性分析

本文通过七个流行的UPI应用程序对该协议的设计进行了逆向，从而对UPI协议进行了详细的安全性分析。发现了UPI 1.0规范中多因素身份验证设计级别的缺陷，当与攻击者控制的已安装应用程序结合使用时，可能会导致攻击。在攻击的最极端版本中，即使受害者从未使用过UPI应用程序，这些漏洞也可能使受害者的银行帐户被关联并清空，潜在的攻击是可扩展的并可以远程进行。

支付应用程序已成为印度的主流支付工具，随着印度政府在2016年将大笔纸币货币化之后，印度政府积极鼓励其公民使用电子支付方式。为了大规模实现数字小额支付，印度国家银行联合会印度国家支付公司（NPCI）引入了统一支付接口（UPI），以实现不同用户的银行帐户之间的免费和即时转账。截至2019年7月，UPI交易的价值已达到约210亿美元。UPI的开放式后端体系结构可轻松实现新支付应用程序的集成和互操作性，这是一个重要的推动力。当前，大约有88个UPI支付应用程序和140多个银行可以通过UPI与这些应用程序进行交易,本文着重于UPI设计中的漏洞以及付款应用对UPI的使用情况。

之前已经对包括印度支付应用程序在内的支付应用程序的分析中发现了漏洞，并且发现印度移动银行服务存在PIN修复漏洞。但是，在这些研究中，移动应用程序没有共享通用的支付接口，以前尚未对多个支付应用程序使用的通用接口进行分析。进行这样的分析非常重要，因为其中的安全漏洞可能会影响多个银行和多个应用程序的客户，而与使用的其他更强的安全功能无关，本文专注于许多印度支付应用程序使用的统一支付接口的安全性分析及其设计选择。

如上表所示是印度最受欢迎的7种UPI应用程序。在分析的7种应用程序中，Google Pay（Tez），PhonePe，Paytm和BHIM这4种UPI应用程序的综合市场份额为88 ％，并在许多购物网站中被广泛接受。在总共88个UPI应用程序中，许多都是BHIM的较小变体，BHIM是NPCI（也是UPI的设计师）发布的旗舰应用程序。今天，有近48家银行发行了BHIM应用的银行品牌版本。由于Android拥有印度移动市场90％以上的份额，因此专注于这些应用的Android版本。

威胁模型假设用户在非root用户的Android手机上谨慎使用授权的付款应用程序，但已安装具有常用权限的攻击者控制的应用程序。尽管社交工程攻击可以简化发现的某些漏洞的利用，但不依赖其成功与否。发现了UPI 1.0协议中的几种设计选择，这些选择可能导致以下类型的攻击：

•攻击1：给定用户的手机号码，未经授权注册：此攻击会泄漏私人数据，例如用户拥有银行帐户的银行集和银行帐号。

•攻击2：根据用户的手机号和部分借记卡卡号，在银行帐户上进行未经授权的交易：在印度使用借记卡购物（无论是在商店内还是在线购物）都要求用户通过输入秘密PIN来授权付款。在这种攻击中，攻击者可以通过知道用户的手机号和打印在卡上的借记卡信息（最后六位数字和有效日期，不带PIN）来对从未使用过UPI的用户的银行帐户进行交易付款应用程式。

•攻击3：没有借记卡卡号的未经授权的交易：这种攻击表明，不知道用户身份验证因素的攻击者如何学习所有因素以对该用户的银行帐户进行未经授权的交易。

工作开始于两年前，当时NPCI发布了UPI 1.0和BHIM，这是分析的重点。考虑到发布调查结果的潜在风险，直到NPCI解决了最近发布的UPI 2.0中的关键攻击媒介才发布。

印度的早期移动支付应用程序仅是钱包应用程序。他们可以通过要求用户输入借记卡号从用户的银行帐户中提取资金，但不能将钱存回该银行帐户。取消货币化后（2016年），为鼓励无现金交易，由印度政府支持的名为印度国家支付公司（NPCI）的印度银行财团推出了统一支付接口（UPI），该接口允许NPCI认证的移动应用程序在不同用户的银行帐户之间进行免费的即时汇款。UPI应用程序可以共享所有相同的支付接口，因此可以相互操作。例如，BHIM的用户可以立即将一笔小额购买的钱从她的银行帐户转移到使用Google Pay的店主的银行帐户中。因此，印度大多数商店都通过UPI应用程序接受移动支付。根据应用程序的不同，用户最多可以无限制地执行每笔交易$ 1500。上图b显示了与上图a中的传统网上银行系统相比的UPI汇款系统。

（1）在UPI应用程序上的用户注册

UPI付款系统要求Alice在带外银行帐户中注册她的主要手机号码，以进行收款。UPI使用手机号（i）作为用户在银行的数字身份的代理，以便在给定手机号的情况下查找银行帐户；（ii）作为通过SMS一次性密码（OTP）进行身份验证的因素；（iii）提醒用户交易。印度政府要求手机提供商获取政府颁发的ID的副本，手动验证ID，并在发出手机号之前进行生物特征验证。要注册UPI服务，Alice必须设置其UPI用户配置文件，添加银行帐户并在该银行帐户上启用交易，如下所示：

1.设置UPI用户配置文件：Alice必须首先通过安装在其银行注册手机上的UPI应用使用UPI创建配置文件。Alice必须首先通过UPI应用将其手机号码提供给UPI进行验证。

UPI从用户那里收集此信息的方式可能随每个应用程序而变化。例如，某些应用程序从设备读取手机号，而其他一些则要求用户键入手机号。例如，上图的屏幕截图3显示了BHIM如何从手机中读取Alice手机号码供爱丽斯选择。然后，UPI应用程序将Alice的手机号发送到UPI服务器进行验证。验证后，UPI服务器将在该应用程序上为Alice发布UPI ID。截图2显示了BHIM在验证Alice后如何通知她。如果Alice使用多个应用程序，则UPI服务器为每个应用程序发布一个不同的UPI ID。然后，应用程序会提示Alice设置密码。密码的性质还是特定于应用程序的。例如，BHIM要求用户设置一个4位数的密码，如截图5所示。

2.添加一个银行帐户：设置Alice的个人资料后，她必须添加要用于提取和存款的银行帐户。为Alice提供了支持UPI的银行名称列表（截图6），现在她可以从中选择自己的银行。Alice可能重复此步骤以添加多个银行帐户。

3.启用交易：为了使Alice能够在添加的银行帐户上进行交易，她必须在第一次交易之前为该帐户设置UPI PIN。UPI PIN码是Alice授权以后进行任何交易的秘密。要设置UPI PIN码，Alice必须提供借记卡上打印的信息-银行自动柜员机或借记卡号的最后六位数字和有效期。Alice丝还必须输入从UPI服务器收到的OTP。UPI PIN是一个高度敏感的因素，因为UPI服务器使用它来防止在Alice的银行帐户上进行未经授权的交易。

为了向Bob汇款，Alice首先使用她在用户注册期间设置的密码登录UPI应用。然后，带外，Alice要求Bob提供他的UPI ID，这通常是Bob的手机号码。Alice选择了她先前添加到应用程序中的一个银行帐户（截图7），向Bob发起了交易，并通过提供UPI PIN对其进行了授权。在内部，UPI付款接口将资金从Bob选择的银行帐户直接转到与Bob的UPI ID关联的Bob的银行帐户。

（2）用户注册的UPI规范

NPCI发布的UPI规范为UPI应用程序与UPI服务器之间的客户端-服务器握手提供了“广泛的指导原则”，讨论了可以从规范中获得的协议详细信息。

1.设置UPI用户个人资料：UPI应用获取用户的手机号码后，该应用必须从Alice的手机向UPI服务器发送加密的出站SMS。此过程是自动的，并且不涉及用户，以保证用户的手机与其设备之间的牢固关联。根据UPI的说法，这是该协议的“最关键的安全要求”，因为首先基于此关联来验证来自用户设备的所有金钱交易。UPI将此用户设备（由设备ID，应用程序ID和IMEI编号等参数标识）与其手机号的这种关联称为设备绑定。组合的手机号和设备信息（代表此绑定）称为设备指纹，根据UPI规范，该指纹是身份验证的首要因素。

密码UPI规范认为应用程序密码是可选的，并且不承担密码认证的责任。UPI将其交给UPI应用程序供应商来验证密码。因此，完全验证用户身份的责任由两个服务器共享：UPI服务器（用于验证设备指纹和UPI PIN）和支付应用程序服务器（用于验证应用程序密码）。

2.添加银行帐户：用户添加银行的请求必须来自在UPI注册的设备。在内部，UPI会根据用户的手机号获取所选银行的帐号和IFSC代码，以便以后通过UPI应用进行交易。

3.启用交易：UPI允许使用手机号或帐号以及IFSC代码或任何UPI ID进行交易。UPI规范要求，使用手机（设备指纹）作为第二因素，并且使用UPI PIN作为第二因素，所有交易必须至少为2FA。该规范将手机视为“what you have”的因素，这使UPI可以使用上述两个因素来提供“一键式双因素身份验证”。

对于与UPI集成的应用程序，NPCI通过代码审查和认证过程来增强应用程序安全性。与UPI服务器的所有通信都是通过基于PKI的加密连接进行的。当前，UPI已成为移动交易的事实上的标准。

（3）威胁模型

假设一名普通用户Alice从官方来源（例如Google Play）安装了付款应用；没有一个支付应用程序包含无关的恶意代码。Alice的电话配置合理，带有互联网功能，可以防止不受信任的实体对其进行物理访问。

另一方面，攻击者Eve使用root的手机，Eve可以使用她可以使用的任何工具对支付应用程序进行逆向。假设Eve发行了一个貌似有用的、没有权限的应用程序Mally，该应用程序请求以下两个权限-android.permission.INTERNET和android.permission.RECEIVE_SMS。Alice发现该应用有用并安装了该应用，并授予了必要的权限。

Mally要求的权限在Android上并不罕见。Android的最新版本会自动授予INTERNET权限，而无需用户提示。SMS许可在Android上具有合法用途，大约有15％的Android应用请求它们。每个任务的RECEIVE_SMS仅授予读取传入的SMS消息的权限，而不授予读取以前接收的消息或发送SMS消息的权限。许多流行的社交媒体应用程序（例如Telegram和WhatsApp，SMS /呼叫阻止程序应用程序）以及安全应用程序（例如Kaspersky Mobile Security和BitDefender）都使用此权限。

由于以下原因，认威胁模型是现实的。首先，根据最近两年的Android安全评估，印度是前木马和后门等潜在有害应用程序比例最高的前三名国家，这些应用程序有时预装在Android设备上。Google最近还发布了警告，指出53％的主要攻击是由于预装在低成本智能手机上的恶意应用所致。

为了简化一些攻击描述，使用READ_PHONE_STATE或可访问性权限来描述Mally，这样做是为了显示攻击者获取用户信息（例如，用户的手机号码）的多种方式。但是，在这种情况下，还将显示不需要这两个权限的其他攻击媒介。

（1）方法

在本节中将描述如何对专有协议UPI进行逆向工程以学习其身份验证握手。由于无权访问UPI的服务器，因此选择通过支持该协议的支付应用程序对该应用程序层协议进行逆向工程。

协议分析：为了对UPI进行逆向工程，首先揭露了客户端-服务器身份验证握手的每个步骤，其目标是（i）了解UPI如何进行设备指纹采集；（ii）建立用户开设帐户和进行交易所需的凭证。除了UPI的默认身份验证工作流之外，还寻找可用于减少攻击者所需凭据的备用工作流或路径。最后，在协议交互过程中寻找任何泄漏的用户特定属性，如果被攻击者拦截，这些属性稍后会被利用。对来自不同工作流程的发现进行分类，以找到合理的攻击媒介并验证潜在的利用。

用于提取协议数据的方法取决于应用程序的规范及其使用的安全防护，由于UPI 1.0规范仅声明了广泛的安全性准则，而不是协议的详细信息，因此检查了多个应用程序，以了解协议在不同应用程序之间是否有所不同们将分析BHIM，这是由维护UPI系统的同一政府组织发布的旗舰应用程序，然后通过分析其他应用程序来确认发现。

App逆向工程：捕获应用发送和接收的协议数据的一种方法是在沙盒中运行它。沙盒工具（如CuckooDroid ）使用仿真器进行动态分析。因此，为了测试UPI应用程序是否可以在沙箱中运行，在Linux主机上的Android SDK内置模拟器中手动运行每个应用程序。但是，发现这些应用程序必须在没有物理SIM卡的情况下才能运行，而该SIM卡在模拟器上不可用。这些应用程序还使用反仿真技术，以防止它们在仿真器中运行。

除了反仿真之外，发现支付应用程序还使用其他几种防御措施。例如，它们所有人都检测到root手机，并阻止用户在root手机上运行应用程序。一些应用程序还寻找hook库的存在，例如Xposed ，它们通常需要root访问权限才能修改系统文件。此外，所有应用程序都被混淆，使用加密通信，强制会话超时和帐户锁定，避免以明文形式存储或传输数据，并避免使用硬编码的凭据或密钥。这些应用程序使用的安全防护程度表明，应用程序开发人员在设计应用程序时就考虑了安全性。

安全评估表明，某些应用程序（例如BHIM）允许重新打包。利用它来静态地检测应用程序的代码，以了解身份验证握手的细节，例如活动名称和生成网络流量的方法。由于这些细节有助于进行精确的分析，因此首先检查应用程序是否可以打包和重新打包。为了对应用程序进行检测，首先使用APKTool 对其进行分解，插入调试语句，然后使用签名对其进行重新打包。

出现的一个问题是，在应用程序的代码中应该插入什么位置，因为这需要了解要插入的应用程序的方法。由于不知道这是先验知识，因此使用JEB和反编译器对应用程序进行了手动逆向。有时，JEB无法反编译被控制流混淆的某些类。在这种情况下，使用JDK的javap命令读取字节码。用来自两个混合分析仪MobSF和Drozer 的静态分量的结果来扩充分析。

无法重新打包某些应用程序，例如Google Pay。在这种情况下，使用称为mitmproxy 的TLS中间人代理来拦截应用程序的网络流量。在Android手机上安装OpenVPN应用，在Linux主机上安装OpenVPN服务，并配置主机的防火墙规则以将流量路由到mitmproxy。该设置还要求在手机上安装mitmproxy的证书。但是从Android Nougat开始，Android不信任用户安装的证书，并且设置系统证书需要root访问权限，这是一个障碍。因此，在Android Marshmallow和Lollipop设备上进行了分析。

（2）BHIM用户注册协议

上图左侧的步骤1-10是客户端服务器在BHIM版本1.3和UPI 1.0服务器之间进行握手的步骤，并显示了最少的相关协议数据。左侧的屏幕数字（带圆圈）指示之前图中生成流量的应用程序的屏幕截图，在下面介绍UPI默认工作流程的十个步骤：

步骤1：当Alice启动BHIM时，BHIM首先请求Alice发送SMS消息的权限（以供以后使用）（截图2）。一旦获得BHIM的许可，BHIM就会以HTTPS消息的形式将Alice的设备详细信息（例如设备的Android版本，设备ID，品牌，制造商和型号）发送到UPI服务器。

步骤2：UPI服务器向Alice发送一个13位的注册令牌，该令牌标识她的设备，并等待以SMS消息的形式从Alice取回该令牌。

步骤3：BHIM应用将注册令牌作为SMS消息发送到UPI服务器。BHIM等待使用sendTextMessage API的deliveryIntent进行SMS传递确认。

步骤4：UPI服务器收到SMS时，（i）得知Alice获得了令牌；（ii）从消息中获取她的手机号码。UPI服务器使用此信息将Alice的手机号硬绑定到她的设备。UPI服务器还向BHIM发送确认已收到SMS。

步骤5：BHIM通过将注册令牌作为HTTPS消息发送回服务器，从UPI服务器请求其设备的硬绑定状态。

步骤6：UPI服务器以包含Alice的客户ID，注册令牌等的验证状态作为响应，将其返回给Alice。到目前为止，UPI服务器已经验证了Alice和她的设备（截图4）。

步骤7：BHIM要求Alice设置密码（截图5）。该应用程序将Alice密码的SHA-256哈希值与她的手机号码连接在一起，并将其作为HTTPS POST请求发送到UPI服务器。

步骤8：UPI服务器向Alice（BHIM）发出登录令牌，该令牌确认其配置文件已设置。

步骤9：然后，BHIM向Alice显示支持UPI的银行列表（截图6）。当Alice从该列表中选择她的银行时，BHIM将银行ID发送到UPI服务器。10.步骤10：UPI服务器将Alice的银行帐户详细信息发送回BHIM，例如她的被屏蔽的帐号，该帐号的哈希，银行名称，IFSC代码等（截图7）。

到目前为止，协议描述中已经考虑了两个因素：a）UPI规范要求的手机（以及设备指纹）；以及 b）密码，BHIM在握手期间将两者都发送到UPI服务器。对于BHIM而言，这意味着用于验证用户密码的支付应用服务器与用于验证设备指纹的UPI服务器是相同的，这一事实不足为奇，因为UPI的设计者也编写了BHIM。最后，要启用交易功能，Alice在她的银行帐户上设置了UPI PIN码，为此她需要她的银行的借记卡号和有效期。

备用工作流程1：在上述默认工作流程中，BHIM将设备注册令牌作为SMS消息发送到UPI服务器，以进行设备硬绑定（步骤3）。如果UPI服务器没有收到SMS，从而无法进行硬绑定，则BHIM提供了另一种硬绑定的工作流程，如上图a所示。BHIM提示Alice输入她的手机号码；BHIM将键入的手机号以及设备注册令牌作为HTTPS消息发送到UPI服务器。UPI服务器将OTP发送给Alice，她必须输入该OTP才能完成设备绑定。协议的其余部分与以前一样进行。

备用工作流程2：如果已经注册的用户Alice更改了她的手机，则UPI服务器必须将她的手机号码重新绑定到新手机。在设备绑定时，UPI服务器发现Alice的帐户已经存在，并将该帐户通知BHIM（步骤6中的accountExists标志）。UPI服务器会提示Alice输入密码，一旦Alice验证完毕（步骤7），服务器就会发回先前添加到BHIM的Alice的银行帐户信息（步骤10）。此工作流程使Alice可以方便地将其银行帐户转移到另一部电话，而无需再麻烦地添加所有她的银行帐户。

a）潜在的安全漏洞—初步分析

在描述针对UPI协议的攻击之前，首先讨论观察到的三个潜在的安全漏洞：

潜在的安全漏洞1：要让攻击者Eve接管Alice的帐户，首先要克服的障碍之一就是UPI的设备绑定机制，该机制将Alice的手机号码与她的手机绑定在一起。为了让Eve解除绑定，Eve必须能够将她的手机与Alice的手机号码绑定。尽管默认工作流程使此工作变得困难，但备用工作流程1提供了潜在的后备功能，使Eve可以从Eve的手机发送Alice的手机号码作为HTTPS消息。

潜在的安全漏洞2：备用工作流程1使用OTP验证进行设备绑定。例如，如果Alice在手机上输入朋友Bob的手机号码，则UPI服务器会将OTP发送到Bob的手机。如果Bob与Alice共享该OTP，则Alice可以向UPI服务器确认OTP，这将把Alice的电话硬绑定到Bob的手机号码。结果，Bob将接收UPI服务器发送给Alice的所有将来的SMS消息。

潜在的安全漏洞3：在UPI的默认工作流程中，Alice丝毫没有提供与银行共享以确认其身份的秘密。不过，UPI服务器会在备用工作流程2中显示现有用户Alice的帐户详细信息。

到目前为止，还没有一个安全漏洞是可利用的，下面讨论这些漏洞导致的潜在攻击。

b）攻击1：根据受害者的手机号码进行未经授权的注册

在这次攻击中，展示了远程攻击者Eve如何在给定受害者的手机号码的情况下设置UPI帐户。为了使攻击成功，Eve只需要做一件事：受害者的手机上安装了Mally应用程序。

攻击设置如下。Eve在手机上安装了重新包装的BHIM版本，该版本已禁用客户端安全检查。Eve建立了命令和控制（C＆C）服务器，在各种应用商店中推出了Mally作为潜在有用的应用，并等待毫无戒心的用户安装Mally。如威胁模型中所述，Mally具有RECEIVE_SMS权限。毫无戒心的用户Alice在非root用户的手机上使用BHIM的合法版本，这是Android的最佳做法。

为了进行攻击，Eve必须有一种方法来发现受害者的手机号码。为了简化攻击描述，假设Mally还具有READ_PHONE_STATE权限，该权限用于从受害者的手机中获取手机号（几乎35％的应用程序使用此权限）。在后面将展示Eve如何在没有READ_PHONE_STATE权限的情况下发现受害者的手机号码。

下面展示了在Alice不经意间在手机上安装了Mally之后，Eve可以如何向UPI服务器注册为Alice。

1.Mally 安装成功：一旦安装在Alice的手机上，Mally就会通过Internet向Eve的C＆C服务器报告（Android自动授予INTERNET许可）。Mally向Eve报告Alice的手机号码，作为Eve（i）发现Alice的手机号码的一种方式；（ii）将Mally的实例与Alice相关联，这对于Eve将攻击扩展到许多用户至关重要。

2.Eve 使用手机号码进行硬绑定：Eve利用BHIM工作流程中的“潜在安全漏洞1”将其设备绑定到Alice的手机号码，如前图b所示。Eve首先将手机置于飞行模式，同时保持通过WiFi的互联网连接。Eve手机上的BHIM应用程序通过发送Eve的设备详细信息开始握手。UPI服务器以Eve的设备注册令牌作为响应。理想情况下，Eve的BHIM必须通过SMS将令牌中继回UPI服务器。但是，由于Eve已关闭SMS消息传递，因此包含令牌的SMS无法传送。BHIM提示Eve键入一个手机号，Eve键入Alice的手机号。BHIM现在将Eve的设备注册令牌和Alice的手机号作为HTTPS消息发送到UPI服务器，以进行硬绑定。然后，UPI服务器将OTP发送给Alice。

3.Mally 拦截OTP：在Alice的电话上，Mally截获了收到的OTP消息，因为其RECEIVE_SMS权限允许该消息。然后，Mally将OTP以HTTPS消息的形式发送给攻击者的C＆C服务器，以及Alice的电话号码。（这里的手机号不是严格要求的。它仅允许C＆C服务器将每个OTP与受害者关联起来，从而减少一些猜测，以防万一它从其他Mally装置接收到OTP。）

4.Eve 确认OTP：C＆C服务器将包含OTP的SMS消息发送到攻击者的电话。请注意，BHIM应用程序通常会检查其收到的OTP消息的来源，并仅在来自已知UPI服务器的情况下才接受OTP。但是，Eve在手机上重新包装的BHIM版本遭到攻击之前就禁用了此防护措施，从而利用了潜在的安全漏洞2。

5.Eve 新的BHIM用户：创建BHIM的密码：在Eve的手机上，BHIM会要求输入BHIM的4位数字密码。现在，Eve不知道Alice是BHIM的新用户还是注册用户。但是，Eve可以从握手的第6步中确定这一点，在该步骤中，UPI服务器为新用户设置一个名为accountExists的标志为false。Eve可以继续为新用户Alice设置新密码。将在攻击＃10中讨论针对现有BHIM用户的攻击的解决方法。

6.Eve 从银行列表中选择银行：Eve接下来在BHIM的银行选择屏幕上逐一选择每个银行，直到找到UPI服务器接受的银行。

如果Alice在该银行有一个帐户并在该帐户中注册了她的手机号，则UPI服务器将接受该银行。UPI服务器似乎没有限制暴力破解-错误只会使用户返回到银行选择屏幕。无论如何，由于银行的名单相对较短，很难防止暴力破解，Eve可以尝试一些大多数人都可以在其中开户的大型银行，例如印度国家银行或ICICI银行。

Eve可以重复第1次攻击，直到她发现了Alice的所有银行帐户并在其中注册。

c）攻击1’：Eve 克服现有BHIM用户的BHIM密码检查

当BHIM提示攻击者Eve输入Alice的BHIM密码时，对注册用户Alice的攻击1停止，提出了三种解决方案来克服密码障碍。

第一个解决方法是让Eve等待Mally拦截并泄漏新密码，发现Mally可以做到以下几点。Mally等待Alice启动BHIM，Mally会检测BHIM的登录活动，以在其上绘制覆盖图。为了绘制叠加层，Mally利用了Toast叠加层漏洞CVE- 2017-0752 ，该漏洞不需要用户提供任何其他权限。一旦Mally拦截了密码，它将密码转发给C＆C服务器。

第二种解决方法是让Mally请求并使用Android的可访问性权限，从而使Mally能够观察用户交互并拦截密码。

此时，攻击者可能选择重置用户的密码，发现BHIM的密码重置工作流程需要用户的银行帐号，而不是借记卡号。从表面上看，Eve似乎不太可能知道Alice的银行帐号，而孤立地看，这可能是一个合理的密码重置过程。但是，正如潜在安全漏洞3中所述，请记住默认的UPI工作流程会显示用户的银行帐号。Eve可以使用银行帐号来重置Alice丝的BHIM密码（由UPI服务器提供）。

攻击1和1’的影响：成功注册后，Eve无法在链接的银行帐户上进行交易。但是，这种攻击会泄漏私人数据，例如Alice拥有银行帐户的银行集以及Alice的银行帐号。还注意到，在协议握手期间，UPI服务器将设备注册令牌，客户标识符，登录令牌，帐号的哈希值和银行的帐号发送回BHIM（客户端）。BHIM会屏蔽银行帐号，但是，UPI服务器仍会发送该银行帐号，Eve可以使用Eve手机上重新包装的BHIM来获取该帐号。攻击1也是攻击2或攻击3的先兆，它们更具破坏性。请注意，使用可访问性仅有助于简化攻击。对于攻击1，不需要它。

d）攻击2：在给定手机号和部分借记卡号的银行帐户上进行未经授权的交易

在攻击1之后的这次攻击中，Eve扩展了先前的攻击，以在不使用任何UPI应用程序的用户Alice的银行帐户上启用交易。为了使攻击成功，Eve需要进一步了解Alice：Alice的借记卡号和有效期的最后六位数。结帐时，印度的商店和饭店中的陌生人不小心将借记卡发给了陌生人（通常带有手机号，因为收银员通常会收集手机号以发送折扣或奖励积分）。印度的大多数借记卡都带有银行名称。使用借记卡在印度的商店或网上购物时，需要用户输入秘密PIN。在这种攻击中，即使没有来自Alice的借记卡PIN，也只能访问借记卡信息，Eve可以设置UPI PIN来启用关联银行帐户上的交易

影响：丢失或共享自己的借记卡信息以及手机号（不是实际的卡，实际的手机或借记卡PIN），可使攻击者设置UPI PIN并在其银行帐户上进行交易。Eve不需要银行帐号或任何Alice的密码。但是，由于Eve需要收集借记卡卡号以及相关的手机号，因此该攻击的可扩展性低于攻击1。对于丢失两段数据给Eve并安装Mally的用户而言，影响是巨大的。Eve可以清空他们的帐户，将资金转移到印度的任何用户。攻击甚至不需要受害者以前使用过UPI应用程序。要重置UPI PIN，Eve需要借记卡号，有效日期和OTP的最后六位数字，而这全部都是她拥有的。

e）攻击3：没有借记卡卡号的未经授权的交易

针对现有用户Alice的攻击是第1‘攻击。这样的用户之前已经设置了密码来登录BHIM和UPI PIN以授权交易。不幸的是，Mally可以使用toast覆盖或通过请求可访问性权限来拦截UPI PIN。作为拦截UPI PIN的替代方法，Eve可以尝试重置UPI PIN（回想一下Eve已经在攻击1’中向银行帐户注册了）。如在上次攻击中所述，重置UPI PIN需要借记卡信息，从而将这种攻击降低为攻击2。简而言之，似乎要求Mally拦截UPI PIN或拥有Alice借记卡信息的Eve。Eve现在拥有使用Alice手机进行交易的所有因素。

影响：Eve可以将资金转入印度任意基于UPI的帐户。请注意，对于现有用户的攻击，Eve不需要任何有关Alice的知识，只有Mally可以拦截的两件事-一条SMS消息和UPI PIN。

f）消除对READ_PHONE_STATE权限的需求

到目前为止，描述的攻击都是依靠Mally知道受害者的手机号并将其发送到C＆C服务器，作为所有攻击的先兆。现在，描述Eve如何在不要求READ_PHONE_STATE权限的情况下将受害者的手机号码与Mally实例相关联。

给定所有目标手机号的集合C（手机号的任何列表-有效或无效），在攻击1之前执行以下步骤：

（i）对于C中的每个手机号码，向该号码发送短信，内容如下：[接收者的手机号码“ SMS TEST”]（或任何此类消息）。

（ii）考虑已经停止了Mally的电话C的子集SC。Mally查找字符串“ SMS TEST”，然后将SMS中的手机号保存为受害者的手机号。

因此，所有收到此类SMS消息的Mally实例都可以了解其受害者的手机号码，并向C＆C服务器报告以启动用户注册协议。

g）谁的问题：Android或UPI？

关于发现的攻击主要是由于Android权限模型的限制还是由于UPI设计中的缺陷（以及应由谁进行修复）存在一个潜在的问题。认为两者都有问题，给定用户的手机号（在任何握手方式中，默认或替代），攻击者都不需要银行相关的凭证即可获得用户的银行帐号。攻击2使用借记卡号和有效日期的最后六位数字，这比使用借记卡进行在线和实体商店购买的门槛要弱，在印度，借记卡通常需要完整的数字和PIN。UPI协议中的替代工作流程对启用攻击做出了重要贡献。当然也利用Android的安全限制，就像任何好的攻击者一样。

（3）其他UPI 1.0应用

现在，讨论对BHIM的攻击是否适用于其他UPI 1.0应用程序的用户。通过测试研究时最受欢迎的三个应用程序（PhonePe，Ola Wallet和Samsung Pay）得出的结论是肯定的。如上图所示，在UPI 1.0时代，BHIM和PhonePe是最受欢迎的UPI应用程序。

PhonePe还是印度最老的支付应用程序之一，没有包括Google Pay（当时称为Tez），因为它并未得到广泛使用，而Paytm因其钱包功能而更加受欢迎。下面讨论在相同威胁模型下的攻击及其细微差别。

首先，这些应用程序不同于BHIM，因为它们是与UPI集成的“第三方”。每个第三方应用程序都使用其自身的因素来设置用户配置文件。因此，如UPI规范中所述，对于第三方应用程序，其支付应用程序服务器对用户进行基于密码的身份验证，而UPI服务器则验证设备指纹和UPI PIN。

NPCI要求第三方应用程序使用NPCI的接口（库）进行设备指纹识别和输入UPI PIN。在手动检查时，这些应用程序内部使用通用的NPCI库与UPI服务器连接。仅在用户通过第三方支付应用程序服务器进行身份验证之后，第三方应用程序才能访问UPI接口。因此，只有在使用付款应用服务器设置了用户密码后，才通过UPI服务器完成设备绑定和UPI PIN设置。

攻击者现在可以通过使用第三方应用服务器设置用户配置文件，然后利用潜在安全漏洞，来进行攻击1（未经授权的新用户注册）。第三方应用程序使攻击者Eve可以轻松设置个人资料。Eve可以通过两种方式做到这一点-Eve可以使用自己的手机号码（直截了当）从手机中创建个人资料，也可以使用Alice的手机号码从她的手机中创建个人资料。

作为后者的示例，PhonePe提供了在设置用户配置文件时键入手机号码的选项。Eve可以使用此选项在应用中键入Alice的手机号码。为了让Eve代表Alice设置密码，Eve需要PhonePe服务器发送Alice的OTP。但是，如果获得Mally的RECEIVE_SMS许可，Eve可以通过Alice的电话通过Mally获得OTP。攻击1的其余部分将像以前一样继续，并且攻击2从攻击1开始。

对于现有用户的攻击1‘，攻击者可以利用第三方应用程序或应用程序服务器上的任何身份验证工作流漏洞。登录后，Eve可以利用潜在的安全漏洞。为了让Eve以现有用户身份登录，Eve要么必须获得Alice的密码，要么必须重置Alice的密码。要获取Alice的密码，Mally可以使用烤面包覆盖攻击或可访问性权限。但是，一种直接的方法是利用应用的密码重置机制。

例如，在PhonePe上，密码重置仅取决于OTP。在Ola Money上，密码重置需要一个秘密，该秘密在用户创建个人资料时设置（可以拦截）。注意到，一旦Eve以Alice的身份登录到Eve的手机上，PhonePe就会从她的手机中注销Alice。但是，在Ola Money中，由于设计使该应用程序允许从许多设备登录，因此Alice将不会收到任何通知。攻击1’的其余部分将像以前一样继续，并且攻击3从攻击1‘开始。

Samsung Pay（SPay）的安全措施略有不同，其安全措施使用了称为KNOX的受信任执行环境（TEE）实现。要使用SPay，用户必须在设置电话时配置一个Samsung帐户，并另外配置其指纹或SPay PIN。SPay不与UPI集成；相反，它与两个UPI应用程序集成在一起-Paytm和MobiKwik。因此，用户可以选择SamsungPay随附的两个应用程序之一（它们也可以在Google Play上单独下载）。

由于Paytm和MobiKwik应用服务器均未与KNOX集成，因此在用户注册时，它们无法使用KNOX的基于硬件的安全功能对设备进行硬绑定。用户的指纹或SPay PIN用于通过设备对用户进行身份验证；支付应用程序服务器和UPI服务器均未使用它进行用户注册。使用MobiKwik测试SamsungPay。Mobikiwk的工作流程与Ola Money相同，只不过其密码重置工作流程使用密码和OTP，都可以截取它们。这使得SPay容易受到与第三方UPI应用程序集成而导致的攻击。

（4）UPI 1.0负责的披露

已将BHIM的漏洞报告给NPCI，CERT-IN和CERT-US，并于2017年6月首次向CERT-IN披露。在2017年10月再次进行了披露。随后，向CERT-US报告了漏洞，并获得了以下CVE：BHIM的CVE-2017-9818，CVE-2017-9819，CVE-2017-9820，CVE-2017-9821。

还从CERT-US向其他应用程序披露了CVE（CVE-2018-15660，CVE-2018-15661，CVE-2018-17400，CVE-2018-17401，CVE-2018- 17402，CVE- 2018-17403）和三星（CVE- 2018-17083）的$ 5k赏金，用于敏感数据泄漏。最初公开的CVE依赖于可访问性权限，尽管后来确定没有这些权限就可以进行攻击。

（5）UPI 2.0协议的初步分析

在首次报告漏洞后，UPI在2018年8月对UPI规范UPI 2.0进行了首次更新。根据披露，UPI 2.0确实可以当前形式阻止攻击。

目前正在进行UPI 2.0的详细分析，遵循与UPI 1.0相同的方法，并使用四个流行应用程序（BHIM，Google Pay，Paytm和Amazon Pay）的UPI 2.0版本对UPI 2.0协议进行逆向工程。Google Pay（GPay）和Paytm是市场的领导者，各自占有36％的市场份额。

一些发现如下，评估了BHIM的UPI 2.0版本（许多银行也以自己的品牌（例如BHIM SBI Pay和BHIM PNB）将其用作其官方UPI应用）。发现NPCI现在强制将BHIM更新为最新版本。在UPI 2.0中，除了在UPI 1.0中看到的设备信息外，BHIM还将设备的IMEI编号，SIM编号，网络类型等发送到UPI服务器以进行设备硬绑定。在BHIM的最新更新中，NPCI删除了备用工作流程1，因此为攻击利用了潜在的安全漏洞1，这是一个积极的变化。但是，其他漏洞仍然存在，如下所述。

在GPay上，可以设置用户个人资料，类似于在第三方UPI 1.0应用中对攻击1和攻击1’所做的操作。根据GPay的流量，发现GPay使用OAuth2对Gmail服务器进行了身份验证。因此，攻击者Eve可以按以下方式设置GPay帐户。Eve可以在手机上使用自己的Gmail ID，并可以在登录GPay时输入Alice的手机号码。Google会向Alice的手机号码发送一次OTP，Mally可以对其进行拦截（获得Mally的RECEIVE_SMS许可）。为了让Eve继续前进，GPay必须将包含Alice的设备注册令牌的SMS消息从Alice的手机发送回UPI服务器。

在没有先前启用攻击的备用工作流程1的情况下探索了SMS欺骗，将其作为Eve向UPI服务器发送SMS消息的一种方法。为了使攻击有效，UPI服务器必须从Alice的电话号码中获取欺骗的SMS消息。为了进行概念验证，使用声称提供非匿名SMS欺骗的几种服务测试了SMS欺骗。但是，它不适用于在印度拥有的测试号码。虽然可以匿名发送SMS消息，也可以使用SMS欺骗服务提供的默认号码发送SMS消息，但无法控制SMS消息的发件人号码，这是进行攻击的必备条件。目前正在探索先前研究中提到的此和其他与SMS相关的攻击媒介。另外，Mally可以请求SEND_SMS许可并通过Alice的手机发送短信。

在Paytm上，通过使用字节码级别的调试语句对应用程序进行检测来研究握手。以下是Paytm在握手期间收到的银行帐户信息的摘要。作者将以下所有详细信息掩盖起来以保护隐私。注意到与以前一样，UPI会发回银行帐户详细信息，而无需用户提供与银行共享的任何凭证，也在Amazon Pay上确认相同的内容。Amazon Pay使用Amazon凭证和用户的Amazon帐户中设置的默认手机号。要创建个人资料，攻击者Eve可以在她的Amazon凭证中设置Alice的手机号码。

因此已经确认，仍然存在敏感信息泄漏（类似于攻击1中的泄漏）,对于其他攻击（例如执行未经授权的交易）的可能性仍然存在一个未解决的问题。

下面总结了UPI 1.0协议设计中可能引起攻击的问题。

1.UPI协议在给定用户的手机号码且没有与银行相关的凭据的情况下，通过任何握手（默认或替代）方式显示用户的银行帐户详细信息。

2.设备硬绑定是第一个因素，它依赖于易于从设备中收集的数据。UPI在此步骤中不使用任何机密。

3.弱设备绑定机制允许用户（或攻击者）将其手机与注册到另一个用户的银行帐户的手机号绑定。

4.设置UPI PIN（第二个因素）需要在卡上打印部分借记卡信息，这不是秘密。从未使用过借记卡PIN（用户与银行共享的秘密）。这是一个较低的栏，因为在线，并且在店内购买需要完整的卡号和借记卡PIN。

5.将现有用户的UPI帐户转移到新电话时，UPI不需要用户提供任何与银行有关的凭证或打印的借记卡信息来授权从新电话进行交易。UPI协议仅依赖于UPI PIN。

6.在第三方应用程序上，密码（第三个因素）由第三方应用程序服务器管理，因此很容易被绕开。攻击者可以通过使用应用设置攻击者控制的配置文件（使用攻击者凭据）来绕过密码要求。在这种情况下，UPI有效地仅取决于两个因素：设备绑定和UPI PIN。

7.从任何第三方应用程序的默认工作流程中泄露的银行帐号足以在另一个应用程序（例如BHIM）上重置用户的密码。

注意到尽管UPI 2.0关闭了上面的弱设备绑定机制，但其他问题仍然存在。UPI的总体弱点在于，用户注册仅需要了解小区号码以及从该号码接收一条SMS消息的能力。

攻击只需要Mally做两件事：在注册期间提供OTP；对于对UPI现有用户的攻击，则窃取其UPI PIN。可以通过两种方式规避对Mally的需求：未经授权将用户的手机号码转移给攻击者，或者通过社交工程攻击。鉴于劳动力成本低廉，这两种做法都是可行的，并且在印度，社会工程攻击的规模可扩大。对于非UPI用户，让他们在注册期间显示OTP就足够了。

依赖手机号作为用户识别的唯一方法存在很大的风险。印度的银行接受用户在其帐户中注册的任何手机号码-无需交叉检查即可确认给定的手机号码是否真正属于用户。例如，一个家庭成员为他们的个人银行账户向银行提供相同的手机号码并不罕见。因此，有权访问家庭成员借记卡号的人可以将其所有银行帐户添加到同一应用程序中进行交易。视个人的观点，可能会将其视为便利或安全与隐私风险。

众所周知，模糊的安全性无济于事。如果UPI在内部审核后发布协议详细信息，则可以更好地解决风险，从而使研究团体可以对其进行进一步分析。本文展示了如何从试图发现未发布的工作流和秘密的攻击者角度进行协议分析，尽管它很重要，但对于应用程序级协议却常常被忽略。

最小化协议数据：攻击显示了如何使用默认工作流程中显示的协议数据来开发备用工作流程。这是可能的，因为UPI服务器发送的数据多于客户端所需的数据。例如，虽然屏蔽的银行帐号可用于在屏幕上显示，但可以从握手中排除银行特定的详细信息，例如银行名称，帐号和IFSC代码（以明文形式发送）。

安全的备用工作流：在攻击中利用了两个备用工作流，尽管UPI 2.0关闭了其中一个流，但其他备用流要么是不安全的，要么是使用弱凭据保护的。例如，替代的工作流程允许用户将她的手机与注册到另一个用户的银行帐户的手机号绑定，即使不提供与该另一个用户有关的任何秘密。

强制加入UPI应用程序：目前默认情况下，与UPI集成的银行用户可以使用UPI服务。UPI指南不要求用户选择加入银行。选择加入的要求将提高风险意识，并降低非UPI用户（如信用卡用户，现金用户或钱包应用程序用户）的安全风险。或者，可能会要求用户在其本地银行支行进行亲自验证，以便在其手机上注册UPI服务。这样可以防止未经授权的用户注册，从而自动消除其他攻击。

提供退出选项：作为上一个缓解措施的后续措施，出于安全和隐私原因，必须允许非用户和希望终止UPI服务的用户退出。使UPI成为可选项的不利方面是它可能对采用UPI产生负面影响。

使用借记卡号+用户知道的一些信息：印度的借记卡是Chip + PIN卡，与它们进行交易始终需要输入PIN码。相反，通过UPI应用程序进行交易既不需要（仅打印在卡上的信息），也不会导致较弱的身份验证路径。不幸的是，如果Mally具有足够的能力来拦截PIN输入，则很难解决此问题。但是，假设可以在Android上确保用户交互的安全，则要求用户输入与银行共享的机密以启用交易的UPI指南将很有用。

需要强大的设备绑定：UPI规范可能要求支付应用程序执行更强大的设备到手机号绑定。由于绑定是协议中最关键的步骤之一，因此银行可以向用户带外发出一次性机密，例如，当用户访问银行进行UPI激活时。用户首次在手机上使用UPI应用时必须输入此密码。此外，UPI服务器必须验证与之通信的UPI应用程序是在未root电话上运行的正式应用程序。如果UPI服务器可以通过某种方式建立该身份，则攻击者可能无法使用UPI应用程序的重新打包版本来注册帐户。不幸的是，这很难执行。

Android缓解措施：在描述的攻击中，攻击始于用户手机上的Mally从攻击者获得SMS形式的用户手机号。可能的防御措施是让Android具有防止应用程序请求SMS权限的策略。Google已经朝着这个方向发展。截至2019年1月，Google宣布除非应用程序是默认的SMS处理程序并获得Google的明确批准，否则它们将无法请求SMS权限。这项政策的有效性如何还有待研究，注意到这不会使攻击变得不可能。它不仅需要安装Mally，还可以接受默认的SMS处理程序（或被Google批准为例外）。此外，该政策仅适用于Google Play商店-其他商店的应用仍然可能带来风险。印度许多受欢迎的运营商都支持备用应用商店，如Aircel和Airtel，这些商店允许SMS触发下载。

用户缓解：由于Eve要求用户的手机号来发起攻击，因此对银行帐户使用私有手机号可能会减慢攻击速度。不幸的是，它并不能完全阻止它。如果用户已经安装了Mally，则Mally足以检测到用户的手机号码。因此，用户还需要注意不要在用于银行业务的电话上安装具有读取或接收SMS权限的应用程序。

在本文中使用了一种有原则的方法来分析UPI 1.0协议，并在未发布的多因素身份验证工作流程中发现了可能严重影响用户的核心设计弱点。展示了具有破坏性影响的攻击，并且仅要求受害者安装了由攻击者控制的应用程序，无论他们是否使用UPI应用程序。

对UPI 2.0的后续软件更新阻止了所讨论的利用漏洞的攻击媒介。不幸的是，鉴于该协议对于印度移动支付的重要性，仍然存在许多潜在的安全缺陷，这表明需要对UPI 2.0进行进一步审查和安全分析，讨论了经验教训和潜在的缓解策略。

- 结尾 -
精彩推荐


戳“阅读原文”查看更多内容