看雪论坛
发新帖
5

[翻译]利用Hover获取Android用户输入的机密信息

lumou 2017-9-1 20:49 1245


摘要

在本文中我们将证明,在现今许多手机模型上都有的hoverfloating touch,悬浮触控)技术可以被恶意软件滥用,用来记录系统范围内的所有触屏输入。通过这种攻击,运行在Android系统上的恶意软件可以获取用户的敏感信息诸如密码、PIN,记录用户的社交,掌握用户的行为。为评估此类攻击,我们实现了一款POCproof-of-concept,概念验证)恶意软件Hoover,让它在后台运行并记录下前台应用程序的输入。为评估Hoover,我们让20名志愿者在两台不同的Android设备用两种不同的输入方式,触控笔和手指,进行测试。用手指输入,Hoover能在100像素的误差内找到用户的输入点,键盘输入的正确率为79%。触控笔的正确率会更高些,误差为2像素,键盘输入正确率为98%。与现在广为人知的边信道攻击(side channel attack)不同,本文是第一篇证明了hover技术的安全隐患以及它盗取用户输入的潜在可能性。我们也讨论了减轻此类攻击的方法,并发现不能通过简单的限制权限或者提高用户意识来实现,因为这将大大缩减hover技术的使用率。

 

分类

l  安全与隐私→手机平台安全;

 

关键词

Androidhover技术,用户输入,攻击

 

1.引言

近年来输入推理攻击(input inference attack)迅速发展,此类攻击是指盗取用户部分或全部输入。这并不足为奇,因为此类攻击可以让人对用户有大概的了解并且/或者获取用户的敏感信息诸如登录信息,信用卡卡号,私人信件等等。现有的攻击主要是应用程序层面的,通过phishing(钓鱼)或界面伪装(UI redressing(例如[24]clickjacking)诱使用户输入敏感信息[7,27,28,35]。其他攻击利用手机上的传感器作为边信道,通过读取不同传感器,例如,加速器、回转仪和麦克风,推断用户输入。在Android上,读取这些传感器(麦克风除外)的信息并不需要特殊的权限。

本文我们介绍一种新的基于Android设备的输入推理攻击,比起前人的工作,我们这个攻击准确率更高,更通用。我们的攻击同时影响设备上运行的所有应用程序(它是系统范围内的),而且它并不是专门为哪一款应用程序定制。它可以持续以高准确率收集用户输入,而且对环境条件不敏感。之前的方法要么针对特定的输入类型(比如,数字键)是应用程序级别的,是粗粒度的,要么是只在特定条件下有效(有限的手机移动,明确的手机位置,有限的环境噪声)。我们的攻击不是基于软件漏洞或者系统错误配置,而是基于新的未预料到的对新兴的hover技术的使用。

自从Samsung,手机市场的一大巨头,将hover技术应用到Galaxy S4,S5Note系列以后,hover技术方才流行起来。因此本文所提到的攻击会影响到数以万计的用户[5,6,11,15]Hover技术,如图1所示,会引发一种特别的事件(hover eventhover事件),此类事件可以让用户在没有物理接触屏幕的情况下与设备进行交互。我们将展示如何利用此类hover event进行强有力的,系统范围内的输入推理攻击。


1Hover技术。输入设备在没有接触到设备屏幕的情况下引发特殊的事件(hover event)。最右图展示了用户在输入设备没有接触到屏幕的情况下与手机进行交互。

为获取足够的post-tap(点击后)hover event以便正确推断精确点击坐标,在用户对前台app进行每一次点击后,我们的攻击方式是立刻谨慎地创建(create)和销毁(destroy)覆盖窗口(overlay windows)。先前的phishingclickjackingUI redressing技术也创建覆盖窗口,但是都得用到SYSTEM_ALERT_WINDOW权限。我们的攻击方式并不依赖于该权限:我们的攻击不需要任何权限。而且,我们利用覆盖窗口的方式也不一样。我们的攻击是持续的,对用户完全透明,不会影响用户与前台app的交互,也不会将用户重定向到其他的恶意view上,更不会以任何方式欺骗用户——此前的攻击都做不到这点。

为评估此类攻击,我们实现了一款POCproof-of-concept,概念验证)恶意软件Hoover,让它在后台持续运行并记录下前台应用程序的hover输入。但是,要实现我们的攻击我们还得克服一些技术挑战。我们最初的实验表明hover技术,很令人意外,并不直接获取用户点击的位置。相对的,hover 事件散落在更广阔的区域。因此,为成功预测输入事件坐标,我们首先要知道用户是如何与手机进行交互的。为达到此目的,我们进行了一个用户实验,让20个志愿者用安装了hoover的设备进行两项操作:随便在屏幕上点、输入英文。Hoover收集到的hover event将用来训练回归模型以预测点击位置和用来生成一个推断输入键位的分类器。

事实证明,我们的攻击对触控笔和手指输入均有效。而且手指点击的误差为100px,触控笔误差只有2px。而在键盘输入事件中,触控笔和手指的键盘键位推断的正确率分别为98%79%

我们的这种攻击最直观的应用就是获取用户的输入信息,并且是系统范围内的。比如说,Hoover可以记录敏感输入,例如pin,密码还有社交信息(信息类app,邮件)。当然还有其它更微妙的应用。比如,Hoover可以刻画用户与设备的交互方式,也就是形成用户的生物计量学简介。这份简介又可以用来,比如说,仅对设备主人的限制访问,或者帮助敌手绕过现有的基于生物认证技术的按键[20]

针对我们的攻击,我们讨论了应对策略,发现要么不能对抗此类攻击,要么将影响系统或hover技术的使用。

最后,本文有如下贡献:

l  我们介绍了一种全新的、系统范围内的基于hover技术的Android用户输入推断攻击。

l  我们实现了Hoover,一款POC恶意app

l  我们实现了用户测试,证明了Hoove的正确性。

l  我们讨论了可能的应对策略,发现此类攻击很难抵御。

本文后面的组织如下:第二部分我们介绍有关hover技术的相关概念和Android系统的viewUI组件。第三部分,描述本文要考虑的问题以及我们的攻击。接下来,第四部分是Hoover的实现和评估。攻击实现是在第五部分,在第六部分我们讨论可能的抵御策略。第七部分回顾在本领域的相关工作,第八部分总结并展望未来。

2.背景知识

在这部分,我们介绍一些关于hover技术和Alert Window的背景知识。Alert WindowAndroid手机app中比较常用的UI元素。

2.1 Androidhover技术

Hover(或者floating touch,悬浮触屏)技术可以让用户在不物理接触屏幕的情况下与移动设备进行交互。我们在图1已经展示过这个概念了。该技术于2012年由Sony Xperia Device[32]引入,基于结合互电容和自电容感知。被Sony引入后,在201311月下旬,hover技术被Asus用到它的Fonepad Note 6中。最终兴起是在Samsung,手机市场一大巨头,将它用到Galaxy S4,S5Galaxy Note系列。单单是Samsung就出售了超过1亿台支持hover技术的设备[5,6,11,15]——它们都是本文所提到的攻击的潜在目标。

Hover是这么处理的:当用户与屏幕交互时,系统可以在未触摸到它的时候就检测到输入设备的位置。尤其是,当输入设备徘徊在屏幕周围20mm的时候(见图1),操作系统会在规定区域触发一类特殊的用户输入事件——hover eventAppx,y坐标的形式获取输入设备的精确位置。只要获取了输入设备的位置,位置将被发送到View——Android用户接口内置模块——以监听事件。更具体点,就是当用户徘徊在屏幕上方并点击屏幕后,操作系统产生的事件流是这样的:当输入设备接近屏幕(小于20mm,系统就针对(x,y)坐标发起一系列hover event。当触摸到屏幕的时候,hover退出事件(hover exit event)就紧随着按下事件(touch down event)触发。Touch up事件意味着触摸完成。之后,当用户将输入设备带离触摸点的时候其他一系列的hover event会再次触发。最后,当输入设备离开悬浮区域,也就是说,距离屏幕的悬浮高度大于20mm,就产生hover exit event

2.2 View 对象

Android通过WindowManager处理系统可视化和屏幕上的app UI控件。它的工作主要是管理和生成windowviewbuttonimage和在屏幕上出现的其他对象。基于攻击的目的,可以产生不同的view(主动view,例如button;或被动view,例如image)以获取hover event和触摸事件。View的模式是可以改变的,通过设置或不设置特定的标志,可以化被动为主动。这些标志可以通过WindowManager接口的updateViewLayout() API实现。比如说,要将某个view变为被动,需设置FLAG_NOT_FOCUSABLEFLAG_NOT_TOUCHABLE。第一个flag避免view获得键位输入焦点,第二个flag让其无法拦截触摸事件或者hover event。通过设置这两个标志,静态view就不会影响设备的正常使用,即使是它在其他window的上面。另外,通过设置某个viewFLAG_WATCH_OUTSIDE_TOUCH,当屏幕上某处,并且在该view的外面发生点击事件,无需知道点击的位置,也能精确获取该view

在本文中,我们将会用到在其他对象,包括前台appview顶层的view。这些view要么是Alert Window要么是Toast WindowAlert Window不仅用在像短信和电话这种内置app中也用在其他app中——根据IzzyOnDroid对应用商店的爬虫发现,有着上亿次下载的超过600app都用到了Alert Window。要产生Alert WindowWindowManager接口需有SYSTEM_ALERT_WINDOW权限,这部分由产生该viewservice完成。但是,用Toast类的话,实现我们的攻击所需要的功能不用任何权限。但是因为Toast Window的技术更难处理,此类实现比较复杂。因此,我们先用Alert Window实现我们的攻击,稍后在4.6节再解释如何不需要特殊权限实现攻击。

3.攻击

我们攻击的目标是以高精确率(比如,低误差)和高粒度(比如,在按键键位级别)追踪用户的每一次点击。只要用户与之交互的设备支持hover,那么不管输入设备是手指还是触控笔,攻击都有效。而且,攻击不应该被用户察觉,也就是说,攻击不会以任何形式影响用户与设备的交互。

在描述攻击之前,我们先声明假设和敌手模式。

3.1假设和敌手模式

我们假设用户运行的手机支持hover技术。用户用触控笔或手指与设备交互都没有关系。

我们假设的情节是,攻击者控制着在用户设备上运行的一款恶意软件。目标就是,在不被用户发现的前提下获取用户输入信息。在我们第一个攻击,更容易实现的攻击中,该恶意软件只需要两个权限:SYSTEM_ALERT_WINDOW,就如前文所说的,这个权限在很多app中都有,和INETERNET——这个就更常用了,以至于Android将它的保护级别设置位PROTECTION_NORMAL。也就意味着这是无害的,而且所有app都有这两个权限,不需要询问用户。然后我们再讨论不需要SYSTEM_ALERT_WINDOW权限的攻击,这个攻击更复杂些。

3.2攻击概述

为追踪输入设备的点击,我们探索Android操作系统发送hover事件到app的方式。当用户点击屏幕的时候,会以坐标和时间戳的形式形成一系列事件:hover(输入设备悬浮);hover exittouch down(点击时);touch up(点击结束);hover(输入设备再次悬浮)。

为观察这些事件,如果该恶意软件有SYSTEM_ALERT_WINDOW权限的话,它可以生成一个透明的Alert Window覆盖在上面,不然它也可以如4.6节描述的那样用Toast类覆盖实现攻击。注意到在Android系统中,Alert Window是在其他view的上面的(见第二部分)。一旦创建,该覆盖窗口可以获取点击所触发的一系列hover event,如此便可追踪输入设备。以秘密方式做到这些不惊扰用户与app的交互并非微不足道。因为,Android只把hover event发送给收到touch eventview。而且,系统先知touch stream(触摸流)的消耗,所有事件,包括touch downtouch up仅针对一个view。所以,用来追踪输入设备的恶意软件要么可以截取hover event和触摸事件,那这样就影响对实际app的触摸,要么就是截取不到,那这样就无法推断用户输入。

3.3实现隐秘性

由敌手控制的恶意软件不能直接并隐秘的观察点击事件。但是我们可以证明通过观察用户点击之前和之后的hover事件可以隐秘地推断点击。要正确达到此目的,敌手需在不影响用户交互的情况下推断用户输入。

更具体一些,我们的攻击是这么实现的:恶意软件生成一个完全透明的Alert Window覆盖在整个屏幕上。该覆盖窗口位于其他窗口之上,包括用户正在用的app。因此,恶意软件可以追踪hover event。但是恶意view要及时以一种“聪明的方式”化主动(抓取所有事件)为被动(让它们顺利到达下层app)。恶意软件通过WindowManager API,可以在影响用户交互的情况下适时的创建和移除覆盖窗口。

3.4抓取点击事件和Hover event

敌手(恶意软件)是一直运行在受害者设备上的后台服务。之前说过,它的难点在于如何知道将覆盖窗口由主动(将它放到屏幕上)变为被动(将它移除)然后再次变成主动的确切时间。须注意,为保证隐密性,我们只抓取hover event,并不抓取用户与之交互的app的触摸事件。因此,预测用户何时停止悬浮输入设备进行点击并不简单。我们通过如下方法进行处理:通过WindowManager,恶意软件其实是利用了2view。一个是之前提到的完全透明的Alert Window。第二个,我们称之为监听器,其大小为0px,既不抓取悬浮坐标也不抓取点击事件。它存在的意义仅仅是告诉恶意软件何时发生了点击事件。然后恶意软件Hoover将利用这条信息移除/重建透明覆盖窗口。

2Hoover用透明覆盖窗口抓取post-click hover event

3.4.1 推断点击时间。所有用户点击都发生在监听器外面——它的大小是0px。另外,这个view设置了FLAG_WATCH_OUTSIDE_TOUCH,所以当由点击事件引起的touch down event发生是它会收到通知。结果就是,恶意软件可以推断点击的时间戳,虽然它不知道点击位置(见图2步骤1)。

3.4.2 抓取post-click hover event为了推断点击位置,攻击者在touch down event触发后马上激活透明覆盖窗口,点击事件将顺利传送给真正的app。(见图2步骤2)。这就保证了攻击不会影响到正常的设备使用。而覆盖窗口,从此刻起,拦截输入设备从点击位置到下一次点击位置所引起hover event(见图2步骤3)。

与监听器的那个view不一样,监听器不会拦截用户的交互,因为它只有0px,覆盖窗口不能一直是活动的(出现在屏幕上)。不然它会干扰用户的下一次输入。同时,覆盖窗口又必须活跃足够长的时间,以保证能抓取足够多的hover event来推断点击位置。我们的实验表明,用本文所说的设备,系统平均每19ms产生一次hover event。我们还发现,70ms的活跃事件足够获取足够多的hover event去推断点击而不影响用户交互。这70ms包括了app的使用时间,不是点击时间,是像在键盘上输入时提示输入键位的那部分时间。当活跃时间用完,覆盖窗口将再次被移除(见图2步骤4)。


3Hoover收集hover event。用触控笔输入时,hover eventh,h,……,h紧紧跟随触控笔的路径,用手指的话它们就散落在更宽一点的区域。

3.5 推断点击位置

在这一部分,恶意软件已经收集了用户点击所引起的一系列post-click hover event。利用收集到的信息,攻击者的目标是推断用户点击的具体位置。一个方案是只用第一次点击所引起的hover event确定点击位置。但是这个方案虽然对触控笔效果很好,对手指的结果却不太好。原因就是,触控笔的接触面比较下,形成的hover event都仅仅跟随用户的移动(见图3)。所以,第一个post-click hover event(相对的是,点击之前的最后一个hover event)跟事实的点击位置很接近。相反的,手指的接触面比较大,所以hover event,包括那个点击后的,也不如触控笔那样紧密的贴近用户移动轨迹。这在我们最初的实验中就已经证实。该实验结果表明,第一个post-click hover event所抓取的位置很少在点击位置的上方。

出于此,为提高推断点击位置的正确率,我们决定应用机器学习工具,它不单考虑第一个post-click hover event,而是考虑了70ms内所抓取的全部事件。尤其是,为了一般化输入推断攻击我们应用了回归模型。对于有关键盘的攻击(键位推断)我们利用分类器。在高层次上,给定一系列post-click hover eventh,h,……,h),回归模型要回答以下问题:“用户点击的位置在哪里?”同样的,分类器输出最可能是用户输入的那个键位。为评估攻击,我们用了数个回归模型和分类器,这些模型和分类器用的是scikit-learn[25]框架。我们在下一部分的结果中进行描述。

在我们最初的实验中,我们注意到不同的用户有不同的hover event模式。有些用户移动输入设备的速度比较快。就手指而言,手指的形状和大小所产生的hover模式是不一样的。为保证点击预测的正确率和鲁棒性,我们需要用不同的用户所产生的数据训练回归模型和分类器。出于此,我们进行了两类用户实验,将在下一部分进行描述。

表一:实验所用的设备

4.评估

4.1攻击原型(恶意软件)和实验安排

为评估本文所说的攻击,我们针对Android系统设计了一款恶意软件原型,叫Hoover。这个原型按逻辑分为两步:首先收集hover event(如第三部分说的)然后分析它们以预测用户的点击坐标。我们用两个不同的组件来实现这两步。这两个组件可以在用户设备上同时运行。但是因为功能不同,为了方便分析,我们将它们分开了。Hover event收集组件是在用户设备上运行的Android恶意app。分析器用python实现,运行在远程服务器。它们之间的通信通过恶意软件的INETERNET权限来实现,INETRNET权限是普通权限,所有Android app均默认配置,不会惊扰用户。

上传收集到的hover event到远程服务器并不需要多大的带宽。举个例子,一台设备运行四个小时,恶意软件收集到近3800次用户点击所引起的hover event。加密后每次点击的hover event40 Byte,总的就150KB。这样的数据还是大量使用的结果,我们是为了得到一个上界才进行的。所以,我们相信,在实际生活中,一般用户点击产生的数据量会非常小。

最后,为进行实验,我们招募了20名志愿者,他们的数据在在下一节中。评估Hoover分两个场景:一个场景是用户在屏幕上乱点,另一个是明确的点击键盘输入文字。我们用两种不同的输入设备和表一所展示两种不同的设备进行了大量的实验。但是,Hoover所表现的想法是通用的,不依赖于某个设备。因此,我们相信,此类攻击对于其他支持hover技术的Android设备一样有效。

4.2用例和志愿者招募

在这一节我们描述用例的具体细节,同时报告为评估攻击所做的志愿者招募。

用例Ⅰ(常规点击)这个用例的目的是收集用户随意在屏幕点击的信息。因此,我们让志愿者玩一个定制游戏:时不时的点击随机出现在屏幕上的小球。这个用例持续2分钟。

用例Ⅱ(文本输入)这第二个用例主要是键盘输入。志愿者被要求输入乔治ž奥威尔的《1984》的一段文章。每一段,平均有250个英文字母,包括标点符号。

每个用例由志愿者进行3次。第一次用拇指作为输入设备,第二次用食指,第三次用触控笔。我们记录下实验中所有用户点击位置和hover event

表二:志愿者信息

4.2.1 志愿者招募。为进行实验,我们在某个大学校园里招募了20名志愿者。他们的数据在表二中。这些志愿者操作表一所提到的设备,Hoover运行在这些设备的后台持续运行。我们的志愿者(表二)主要是年轻人,他们的输入输入普遍比较快,所以我们相信Hoover的正确率就普通人而言应该会更高一些。这个我们在第八部分再详谈。

20个志愿者进行实验,我们收集到近24000次用户点击。而且,该恶意软件收集每一次点击后70mshover event。其中,17k的点击是键盘敲击,剩下的7K来自用户玩那个球。实验过程中用户没有发现任何延迟或者其他恶意软件存在的标志。

道德考虑。这些实验是我们让志愿者在我们定制的机子上进行的。我们没有让志愿者使用他们自己的设备或提供任何类似用户名或密码的敏感信息。所以,根据IRB政策,我们不需要任何许可。

4.3 post-click hover event的收集时间

研究的第一方面是Hoover在不干扰用户下一次点击的情况下覆盖窗口能保持活跃多久。实验表明,在98%的例子用,点击与点击之间的间隔大于180ms

接着我们研究post-click hover event的数目是如何影响预测的准确率的。出于此,我们让两个志愿者进行一个初步实验研究。最初的实验结果表明正确率随着hover event的数目成比例增长。但是,在前4event之后,正确率的增长小于1%4个事件正确率为78%5个为79%)因此,要评估Hoover原型,我们只需用4post-click hover event。这个选择影响Hoover的覆盖窗口活跃事件,也就是它收集post-click hover event的时间。实际上,我们观察到,70ms已经足够了,因为在前4post-click hover event总是在用户点击后70ms内发生。

最后,注意到相对于我们实验观察到的180ms的点击间隔,我们选择70ms略微保守。但是,如我们在下一节看到的,预测结果的正确率还是很高的。一方面,长时间的收集能增加post-hover event的数量提高恶意软件推断用户输入的正确率。另一方面,当用户点击的速度非常快——比我们实验的用户更快的时候,静态的、长时间的收集会暴露敌手身份。也就是说,更成熟的敌手应该可以开起任意短时间收集窗口并动态适应用户的输入速度。

4.4 Hoover在点击推断的正确率

在这一节我们给出有关Hoover推断用户点击坐标的有效性和准确性的实验结果。一旦Hoover手机到用户的post-click hover event就将他们发送给基于机器学习的运行在运行服务器上的分析器。

4.4.1 推断用户常规点击的坐标。分析器应用回归模型推断用户在屏幕上的点击位置。直观上,正确率取决于预测使用的模型。因此,我们用了几个模型来做实验。包括两个线性模型(Lasso和线性回归),一个决策树,和一个集成方法(随机森林)[25]。每个模型的输入都是Hoover(见第三部分)对每一个用户每一次点击收集到的post-click hover event 的坐标(x,y)。输出是预测的点击位置的坐标。至于benchmark baseline(基准基线),我们应用简单的方法输出第一个观察到的post-click hover event的坐标。

我们用的是留一法交叉验证(leave-one-out cross-validation,也就是说,样本里的所有对象(用户点击)都经历测试和验证。根据对20位志愿者进行实验得到的数据,我们的预测结果如图4a)和4b)所示,分别为触控笔和手指。我们可以看到不同的回归模型的均方根误差(Root Mean Square Error,RMSE)是不一样的。

首先,我们观察到,对于所有的回归模型,手指的正确率均低于触控笔的正确率。这是预料之内的,因为针对触控笔的hover检测技术的正确率就比较高(hover event紧随着其移动),手指的话,hover event散落在更宽的范围。虽然如此,两者的预测也都很不错。尤其是,触控笔的预测误差(estimation error)仅为2px。还要记住,实验所用的最小的设备是Note 3 Neo,其大小是720*1280px.

最后,我们注意到,对于触控笔(见图4a)),简单线性回归模型比其他复杂模型的效果更好。但是对于手指(见图4b))就不是这样。实际上,对于手指来说,预测效果最好的是随机森林模型,其次才是线性模型。我们相信,这依然是因为触控笔抓取到的hover event比较精确,相对于手指来说。

4.4.2推断键盘输入。为在基于键盘的用例中的用户输入键盘推断,我们应用如下方法:(1)用先前的方法论推断对应的点击坐标,(2)观察预测好的点击坐标坐落于那些键位区域,(3)输出预测的键位。

就像之前所说的,对于用线性回归模型进行的触控笔点击预测,其正确率非常高——与真实点击坐标仅有2px的误差。所以,上面的方法对触控笔来说不是问题。但是,对手指的话就不那么使用了,因为误差太大。因此,我们用了另外一种方法,并针对后面的分类提出了一个问题:“根据观察到的post-click hover event,用户按了哪个键?”。同样的,我们应用了几个分类模型:两个基于树(决策树和extra tree),Bagging分类器和随机森林方法[25]。和回归问题一样,我们得用一个基线(baseline)模型作为基准(benchmark)。基线是将第一个post-click hover event转换为包含了这个坐标的键位。实验结果用10折交叉验证(10-fold cross-validation)。

关于用例Ⅱ文本输入的推断结果如图4c)和4d)所示,分别为触控笔和手指。首先,我们观察到,对于两种输入方法在键位预测上随机森林模型(Random ForestRF)的正确率是最高的——手指的是78%(见图4d)),触控笔的是98%(见图4c))。值得一提的是,对于手指,baseline和随机森林模型的结果差距有点大——baseline40%,随机数是79%。但是触控笔的就和正确结果都差不多。尤其是,baseline和表现最好的随机森林模型仅相差1%, 随机森林的是98%(见图4c)).

这些结果表明,Hoover可以正确偷取用户在屏幕键盘上的输入。而且,我们相信,在应用更复杂的基于字典的纠正后正确率会有所提升。


4:对于用例Ⅰ(图4a)和4b))和用例Ⅱ(图4c)和4d))的评估。Base:BaselineDT:Decision Tree决策树;RFRandom Forest 随机森林;LassoLasso回归;LR:Linear Regression 线性回归;ETExtra Trees分类器;BCbagging 分类器。

4.5从其它点击中区分键盘输入

Hoover收集所有类型的用户点击。所以,需要区分屏幕键盘点击和其他类型点击。一种方法是利用边信道,例如,/proc文件夹。Hoover可以用和文献[8]类似的技术获取用户输入。但是出于两个原因,我们不能单单用/proc文件实现键盘检测。第一,它不是完全正确的[8],有一定的假阳(false positive)和假阴(false negative)。第二,我们不能确定/proc文件夹总是可用的,且所有app都可以接触到它。

因此,我们应用一个简单的启发式方法来解决这个问题。这个方法利用屏幕键盘位于设备屏幕底端这一事实。因此,当用户进行输入时,点击更倾向于键盘所在区域。最简单的方法是应用一个estimator(评估者)从所有用户点击中区分目标键盘键位。这个方法不会出现假阴。但是会出现假阳。实际上,用户有很多可能会在屏幕下方进行点击:在需要点击的游戏,有些游戏的开始键就在这个区域,等等。

为过滤会引起假阳性的点击,我们进一步改进我们的方法。想法很简单:如果用户真的是文本输入,她需要在屏幕下方进行大量连续点击。所以我们过滤掉短点击序列(少于4个字母),这甚至不可能是用户名或密码。而且,根据经验,在用户打开输入框开始进行输入,起码有500ms的时间间隔她才会敲击第一个键。这个时间是将键盘加载到屏幕上所花费的。我们把这个条件添加到启发式方法中以减少假阳性。

为评估这个启发式方法,我们收集了一台手机在48个小时正常使用下(例如,聊天,浏览网页,打电话)的数据。我们收集当用户开始(和结束)与键盘交互的点击事件,hover event,时间戳。这两个启发式方法的假阴性均为0。简单版本的假阳性为14.1%,改进版本的下降到10.76%(提升了24%)。

这两个启发式方法仅仅是概念验证(proof-of-concept)。我们相信,包含输入时间与点击触摸时间(也就是用户把输入设备放在屏幕上的时间)差别的更成熟的改进方法能够减少假阳性。但这超出本文范围。

4.6Hoover不依赖于SYSTEM_ALERT_WINDOW

至今为止,我们所说的Hoover是通过Alert Window实现的,需要SYSTEM_ALERT_WINDOW权限。现在,我们证明我们可以不用该权限就实现同样的功能,用一种更复杂的方法:利用Toast[2]

Toast类用来生成通知或者关于系统的快速消息(quick message)。关于Toast的一个例子就是当用户提高或降低音量时出现的音量控制器窗口。他们不需要任何特殊权限而且可以为任意服务或用户app所用。更重要的是,和Alert Window一样,Toast可以抓取hover event,能包含定制的View类对象,而且总是在其他窗口的上面,包括前台app。因此,监听器和透明覆盖窗口都可以由Toast Window生成。

作为概念验证,我们用Toast Window实现了Hoover的一个版本。Android限制Toast的活跃时间仅为几秒。所以要实现监听器就比较困难,因为监听器应该一直在屏幕上。实际上,利用Toast类,Hoover可以在监听器消失之前定期地调用toast.show()。透明覆盖窗口不存在这个问题,因为在之前的章节中我们已经验证过,在监听器检测到点击事件后透明窗口只需出现70ms。收集到hover event以后移除覆盖窗口激活监听器。通过此种方法我们可以让Hoover实现同样的功能而不需任何其他权限。

4.7进一步实现攻击

先前的论述证明hover event可以用来正确推断用户输入,包括常规点击位置和键盘键位。

在这一部分,我们给出两种技术,我们相信,可以提高攻击和正确率。

语言模式。在评估中我们考虑的是最复杂的情况,也就是没有假设输入文本的语言。尽管实验中志愿者们用的是英文,但是对其他任何语言同样适用。更老练的攻击者应该首先检测用户输入的语言,然后在用我们描述的方法进行键位推断,应用误差修正算法提高正确率。

Per-user 模型。在评估中,不管是回归模型还是分类器,我们都是由所有用户实验所得的数据进行训练。也就是说,得到的回归和分类模型之后也用来评估所有用户。这个模式的有点是,如果攻击新用户,攻击结果和我们实验所得结果差不多。但是,我们也可以想一个per-user 模型提高准确率。我们无法用我们的数据库验证这个想法,因为我们没有足够多的per-user数据。但是,我们对两个有最多数据点的用户进行了初步评估。结果显示per-user模型能改进,尤其是针对手指。实际上,就键盘推测正确率,第一个用户从79%(所有用户的数据)提升到了83%,第二个则是86%

4.8另一种键盘输入方法

针对文本输入,我们的攻击非常有效且正确。但是对于滑动输入文本(swiping text)就不是那么有效了。实际上,Hoover只在输入设备离开屏幕时推断坐标。用swiping,仅能推断用户划过的每一个单词的最后一个字母。但是,也需注意到,对于类似密码的文本以及数字或符号,swiping是无效的,须用户输入。因此,就算是有swipingHoover依然能窃取用户的敏感信息,诸如密码或pin码。

在攻击中,我们假设用户使用的是常规键盘。但是,用户也可能应用其他复杂的安全机制,例如定制键盘,在输入敏感信息后重新布置键位。这种输入机制当然能减轻我们的攻击:这样Hoover无法将坐标与键位联系起来。但是当用户发现在那种每次输入后都重置键位的键盘上书写特别痛苦的时候,这种设备的使用率也会下降。最后,这种机制会倾向于保护类似PIN和证书类敏感信息,而短信、email和其他信息序列依然暴露在我们的攻击之下。

5.攻击所引发的后果

攻击的输出是Hoover利用通信时间戳推断的一连串用户点击。在屏幕键盘输入的用例场景中,输出流转换成用户输入的键位。在这一部分,我们讨论可能的攻击实现,技术,以及其中的思想。

5.1侵犯用户隐私

对于我们的攻击,最直观的后果是侵犯用户隐私。实际上,深入分析点击流会暴露设备主人的大量敏感信息。要想知道为什么,来看我们攻击的输出:

john doe<CLICK>hey hohn, tomorrow at noon, downtown starbucks is fne with me.<CLICK> <CLICK>google.com<CLICK>paypal<CLICK>jane.doe<CLICK>hane1984

第一直觉,我们就能知道第一部分要么是email要么是短信。不仅如此,我们还知道收件人——可能是John——他们明天见面,而且我们还知道见面的时间地点。同样的,第二部分我们知道用户在用谷歌搜索paypal,找某一个网站,然后后面她很可能登录网站,她的名字是Jane Doe,她的paypal账号的信息有可能是jane.doe(用户名)和jane1984(密码)。这只是一个简单的例子,显示了Hoover利用一连串用户点击推断用户的敏感信息是多么容易。直观上,也证明了如果敌手能够获取所有用户输入,在其他文本中找到密码比随机猜测要容易。

从上面的例子也可以观察到,输出存在一定的误差,“j”和“h”——这两个键位的位置比较接近。但是,因为是英语,利用基于字典的工具就可以纠正这个错误。如果包含错误的推断键位是密码——通常是无序序列——基于字典的技术可能就帮不上忙了。但是,在这些情况下,我们可以利用移动速度、角度和其他可能的特征定义用户的手指或触控笔在键盘上的移动。很有可能这种措施能提高Hoover的键位推断正确率,还有让类似于‘j’和‘h’的键可以交换。记住这一点,从上面的例子中我们就可以很容易的推断Janepaypal密码可能是jane1984.

深入研究用户习惯对Hoover正确率的影响超出了本文的范围。因此,这也说明这种攻击的强度和广度。

5.2用户的生物学信息

到现在为止我们只是论述了在语义学上,通过联系Hoover手机到的用户点击流,敌手能够获得什么(例如,文本输入,和朋友交换消息,等等)。但是,Hoover收集到的数据还有其他隐患。实际上,它可以用来推测用户的生物学信息并刻画用户用设备的交互方式。这是根据监听器收集到的时间戳。

每次系统发生hover event,监听器就会收集时间戳。尤其是,用户按下(用户点击),提起(输入设备离开屏幕)的时间戳。根据这些时间戳,Hoover可提取到如下特征:(i)点击时长。(ii)两次连续点击的间隔,根据两次touch down的间隔计算。(iii)两次点击之间的悬浮时间,根据touch up event和下一个touch down event的间隔计算。这些特征对于基于用户生物学信息的持续认证机制是必须的[29,36]。而且在[29,36]中提到的机制需要系统级实现,这很困难,而且会增加现有系统的复杂性。据我们所知,Hoover是第一款在app级实现的基于生物学信息的认证机制。Hoover可以持续从点击中提取特征去认证设备主人,以及区分她与其他用户,例如,盗取她设备的小偷。

尽管有关生物学的信息是一种认证的有效方法,但是同样的信息也可能被滥用伤害用户。比如说,文献[20]的作者就证明敌手是如何利用受害者的大量生物学信息训练并绕过基于按键的生物学认证系统。在这一点上,Hoover刻画用户输入方式的潜在可能性在将来可能被人利用以伤害用户。

6 讨论及应对策略

攻击的成功依赖于对hover技术的不正当使用和Alert Window。现在我们来看可能的应对策略。我们发现,很难解决,要么不能对抗攻击,要么会降低系统或hover技术的使用率。

6.1限制使用hover event

本文所提到的攻击利用Android操作系统关于hover event的信息。尤其是,hover event的坐标可以为屏幕上所有的view使用,即使这些view是后台app(像Hoover)创建的。减轻攻击的一种可能的方法是限制对hover event的检测,仅允许前台app形成的组件(包括view)。这样,就算Hoover(运行在后台)有覆盖窗口的存在,攻击者也无法在用户进行输入时追踪输入设备的移动轨迹。但是这种方法会影响已存在的app的使用量,这些app为了更好的用户体验,以不同的方式使用Alert Window。一个例子就是,Facebook MessengerChatHead特性:如果它不能抓取hover event,这个特性就没用,因为它都不能接收用户点击。因此,一个view对象要么同时注册点击(触摸)事件和hover event,要么就都没有。

另一种可能的方法是减少由click引起的hover event,并限制第一个hover event仅为前台Activity所用。这个方案会增加系统处理hover组件的复杂度,而且需要引入并恰当的管理新增的权限。让用户去管理(复杂)权限已经被证明不现实——大多数用户更倾向于静默同意他们要安装的app所申请的所有权限[18]。不仅仅是用户,开发者也发现现有的权限太复杂了,为了正确实现app功能,也更倾向于一次性申请所有权限[9]。所以,在像Android这样的开源系统中,引入额外的权限并不是解决问题的正确方法。最后一种方法就是删除或关掉设备的hover特性。但是这样会影响使用率。这也是为什么Samsung设备对于手指部分允许这种方法,但是对于触控笔还是保留了hover

6.2 Android的触摸过滤特性

本节解释为什么filterTouchesWhenObscured机制不能用来抵御我们的攻击。首先,我们先简要论述它的功能。Android系统的触摸过滤特性对于给定的UI组件,包括view,可以开启或关闭。当给定的view开启该功能时,所有在这个view外发生的点击(触摸)事件会被服务窗口模糊掉,不会收到任何触摸事件。也就是说,这个view不会从系统那里收到关于这些点击的通知。

触摸过滤默认是关闭的,但是app开发者可以通过调用setfilterTouchesWhenObscuredboolean)或android:flterTouchesWhenObscured这个layout属性为true的方式开启。

如果Hoover要在点击时拦截组件,那触摸过滤就会危及它的隐密性——点击要到达的底层组件收不到点击,那么用户就会察觉。但是,Hoover从不在点击时阻挡屏幕区域。(要知道覆盖窗口是及时创建和销毁的,不会影响用户交互,见第3部分)。所以即使所有服务和app都默认开启触摸过滤,Hoover的正确率和隐密性也不会受到影响。

6.3禁止0px view或者对FLAG_WATCH_OUTSIDE_TOUCH的激活

Hoover利用0px view监听屏幕上的触摸事件并告知恶意软件点击的反生以便它能迅速激活透明覆盖窗口。因此,禁止服务创建0px view似乎是一种抵御攻击的简单方法。但是,攻击者也可以通过创建一个非常小的view,并将其置于屏幕上只要它不覆盖前台appUI组件克服此困难。例如,可以是在底部的一条细细的黑线,所有不能和屏幕上的硬件边界区分开来。

监听器也用FLAG_WATCH_OUTSIDE_TOUCH检测用户何时点击。好像如果这个标志是disabled,攻击就会挺直。但是,没有这个flag也可以用其他两种方式替代:第一个是分析来自类似回转仪和加速计等传感器的信息,在Android中接触这些信息不需要权限[22]。第二个就是持续检测proc文件夹中关于键盘处理的信息,这在Android中也不需要权限[17]。已有文献证明这两种方法在推测点击次数上的高正确率[17,22]。不仅如此,很多app都用到这个标志。比如,当用户在窗口外部点击时,该窗口要随时反应(例如,消失)。这是一个很重要的标志,很常用,而且很难说如果这个标志disabled了,多少应用程序会崩溃。

6.4限制透明View合理化或者限制系统服务

这种限制可以阻止利用透明覆盖窗口。然而,高明的攻击者依然有法子克服。比如,在键盘攻击场景中,覆盖窗口可以是非透明的并且是受害人手机上的键盘的复制图。注意到键盘的布局取决于设备的规格(种类,模型,屏幕大小)。在Android中利用公开的WindowManager InterfaceAPI可以很轻易的获取这些信息。那个类似键盘的覆盖窗口就会像透明窗口那样操作,而且不会被用户察觉。如果攻击者知道其设计和组件(例如,广为人知的移动银行或者Facebook的登陆界面),同样的方法也可以用来手机用户点击。

6.5通知用户关于覆盖窗口,可信路径

想法就是通过限制风格让由后台服务生成的view可以为用户识别。限制风格是指在系统级别上应用容易辨认的边框或结构,或者两者。而且,系统应该强制所有的覆盖view遵循这种风格,并限制它使用其他风格。但是,以可信路径增加GUI控件[7,26,34]提醒用户关于可能的攻击(安全指示器)这种策略还没有得到有效的验证。这在文献[7]的大量用户研究中已经被证实:即使真的检测到了可能的攻击,而且应对策略已经准备就绪,依然有42%的用户无动于衷。

这种可信路径方法可以在用户与恶意软件交互时抵抗phishing(钓鱼)攻击。但是,要注意这并不是我们的攻击方式,在我们的攻击中,恶意软件一直在后台运行,而且不会影响用户与前台app的交互。即使安全指示器并不像文献[7]那样基于app,而是基于view出现,也须注意到Hoover不是静态的。相反的,它在点击后出现的时间非常短(70ms),此时用户的注意力并不在安全指示器上。

6.6保护敏感view

这个想法是限制service生成的敏感view或者组件,像登录时的键盘,或者新app的安装按钮,被其他serviceview(包括Alert WindowToast)覆盖。一个可能的实现方案如下:引入在view类中引入新的属性以明确对于给定的实例是否应该“可覆盖(coverable)”。当设置了这个属性,系统就强制屏幕上覆盖它的的其他对象被“推出到”该view的边界,例如,到屏幕上不会覆盖它的其他区域。显然,谨慎设计她的app并坚定需要不可覆盖(non-coverable)是app开发者的责任。另外,这些类型的view应该有一个最大尺寸并且不能覆盖整个屏幕。不然,它就不可以应用其他服务,包括系统服务,在non-coverableview下显示Alert Window。这个方案可以减轻我们的攻击和其它依赖于覆盖窗口的攻击,即使使用的是其他方法,例如phishing或者clickjacking。但是,对于开发者来说负担太大,既要区分UI组件为coverablenon-coverable,还要考虑预料不到其他app或系统服务形成的view,像屏幕上的信息提醒,系统Alert Window,等等。

7.相关工作

要实现推断用户输入这个目标的最大挑战来自Android的基本规则:一次点击只能指向(然后被抓取)一个app。但是,前人的工作已经表明,恶意软件可以利用好几种技术绕过这条规则并推断用户输入(例如,盗取密码)。我们可以将手机应用phishing作为用户输入推断的一个例子,其目标是盗取被钓鱼的软件的键盘输入(通常是登录凭证)。虽然很有效,但是钓鱼攻击的限制就是它不能在官方应用市场发布。而且,和我们的技术不同,钓鱼攻击需要分开对每一个app分别实现。

Hoover不会影响用户体验。相对于UI redressing(例如clickjacking)攻击,它们也能够移动设备上的输入推断[7,14,24,27,28,35]Hover具有更强的鲁棒性和隐密性。UI redressing技术使用覆盖窗口的方法和我们的在概念上不同。它们通常是用Alert Window或者Toast信息覆盖该用户的组件[7,24],在点击时,这样要么将用户指向恶意接口(例如,假冒的钓鱼登录窗口),要么通过阻碍受害程序的功能影响用户输入(例如,覆盖整个屏幕键盘的窗口)。这些攻击会影响正常用户体验:受害程序不能接收输入,那么用户就会察觉。

在系统范围内推断用户输入的另一个方法是利用通过手机平台上类似回转仪,加速器等传感器收集到的数据[10,13,19,21-23,31,33,37]。读取这些传感器信息通常不需要特殊权限。但是,这些传感器提供的信号精确度低,因为它取决于环境条件(例如,用户在运行的大巴上使用回转仪)。所以,根据边信道得到的输入位置一般正确率不足以区分全屏幕键盘按下的键。相对的,已经证明Hoover有高正确率,而且在触控笔的场景下,推断用户键盘敲击的误差为2px。不同的是,在竖屏模式下的基于麦克风的推断用户击键效果很好。另外,它的正确率取决于环境噪声。

8.总结并展望未来

本文我们提出了一种新的用户输入推断攻击。我们实现了Hoover,一款概念验证恶意软件用来记录用户在支持hover技术的设备上的输入,不论是手指还是触控笔。与前人不同的是,Hoover以高精确率和高粒度(在屏幕上点击位置级别上)记录用户的所有输入。这个攻击并不针对于某一给定的app,而是系统范围内的,而且对用户透明:它不以任何方式影响用户与设备的交互。

本文我们并没有区分不同的手指。但是我们最初的实验已经之处训练per-finger模型可以提高攻击正确率。应用技术检测用户使用的是哪一个手指[12],并用正确的手指模型也可以提高正确率。这有待将来。

 

原文链接:https://www.ethz.ch/content/dam/ethz/special-interest/infk/inst-infsec/system-security-group-dam/research/publications/pub2017/WiSec17_ulqinaku.pdf

本文由看雪翻译小组 lumou 编译

本主题帖已收到 0 次赞赏,累计¥0.00
最新回复 (2)
聖blue 2017-9-1 21:47
2
感谢分享!!!!!
开花的水管 2017-9-2 10:37
3
返回



©2000-2017 看雪学院 | Based on Xiuno BBS | 域名 加速乐 保护 | SSL证书 又拍云 提供 | 微信公众号:ikanxue
Time: 0.014, SQL: 9 / 京ICP备10040895号-17