Group of Software Security In Progress

GoSSIP @ LoCCS.Shanghai Jiao Tong University

All Your Sessions Are Belong to Us : Investigating Authenticator Leakage Through Backup Channels on Android

论文下载:http://www.comp.nus.edu.sg/~a0091939/Publications/Poaching.pdf

本文的出处为ICECCS’15.

Abstract & Introduction

这篇文章的主要贡献在于分析了Android平台中备份渠道被攻破导致的数据泄露问题,落脚于认证符的泄露。

  • 本文分析了Android app对认证协议中使用的认证符的管理问题。发现大多数app将认证符存储在persistent storage中,托付给底层Android系统,这些认证符可能通过有问题的备份渠道被泄露。
  • 本文发现Google Play上的所有备份软件都会将备份信息暴露给有Internet权限和SD卡权限的app(Poaching attack),恶意app可能窃取到别的app的认证符进而控制认证会话。
  • 作者开发了一个app——AuthSniffer用以证明攻击的可行性。
  • 作者发现117个实现了认证方案的top-ranked app中80个(68.4%)可被攻击。

BackGround

Android中的认证机制

作者分析了Google Play前100的应用,分析它们所使用的认证方式,发现主要分为3种:Basic authenticationSingle Sign-on(SSO)Account Manager based authenticationFig

  • Basic Authentication:即传统用密码认证的方式。 这种情况下Android应用一般会重用与它们对应的Web应用的认证方案,使用相同的认证符如cookie等。区别在于Web应用中cookie由浏览器管理,而Android应用是由应用自己管理。
  • Single Sign-on(SSO):这种认证又细分为两种情况,app认证和WebView认证,其涉及的认证符存储如下图: Fig
  • Account Manager:这是一个Android服务能够帮助管理app的认证符。app可以委托认证和认证管理给Account Manager。它将认证符都存在/data/system/users/0文件夹中的accounts.db中,只能被高权限用户组(system、root)中的应用读取

Android中的备份方案

Android本身不提供备份API给开发者。目前开发者一般使用两种方式:

  • Root-based backup:这种方法要求root设备,备份软件获得root权限后可以访问其它应用的数据。
  • ADB-based backup:借助电脑备份。
    1. 用户adb shell打开一个shell,然后启动一个代理。
    2. 当备份软件需要备份数据时,调用代理来执行相关操作。
    3. 代理调用Android的backup manager进行备份和恢复。“bu 1 backup”/ “bu 0 restore” Fig

Overview of Security Analysis on Backup Apps

  • 备份数据可能被泄露的3个阶段为:
    • 生成:备份软件中哪些模块或代码段是执行备份操作的?
    • 传输:备份软件怎么传输的?
    • 存储:备份数据被存哪儿了?
  • 分析方法:
    • 作者使用一种自顶向下的范式来分析备份软,先分析app的整体架构和工作流程,识别关键模块,然后再深入分析关键模块的安全特性。
    • 作者对字节码白盒分析和对通信流量黑盒分析。
  • 威胁模型及假设:备份数据有很多,本文只关注认证符。
    • 假设攻击者可以欺骗用户安装他的恶意应用
    • 攻击者可以再良性应用中注入恶意代码
    • 攻击者可以将恶意应用假扮为良性应用。
    • 恶意应用需要获得INTERNET和READ_EXTERNAL_STORAGE权限。
  • 当前备份软件现状如下: Fig

Poaching attack on Helium

  • Helium是2013年最佳应用之一,很有代表性。
  • Helium的工作原理:

    • ADB代理名为ShellRunner,运行在一个独立进程中,属于shell用户组。
    • 代理被启动后,创建一个Android local socket server (lsserver)
    • 然后再生成一个token,token在代理整个生命周期内都有效,直到代理被重启。
    • 接着ShellRunner通过一个显示intent启动ShellProxyService服务,ShellProxyService提取出token把它存在settings.db的数据库中。
    • 之后ShellRunner就监听llserver,等待备份软件发过来的请求。 Fig Fig
  • Helium中由两个备份接口:

    • Local backup:用Activity和用户交互,把数据备份在SD卡中。
    • Web backup:在设备中创建一个webserver,允许通过’http://deviceIP:5000‘连接它。数据通过这个server传出设备。
    • 这两个模块都要从settings.db里读取token,利用这个token访问ShellRunner来进行备份操作。 Fig
  • Helium的安全特性:

    • 使用基于token的认证来保护proxy。
    • 理论上备份数据需要用户授权,但Helium通过注入一个点击事件移除了授权提醒。
  • Helium的漏洞及相应攻击:
    • 漏洞1:生命周期管理的不一致性。
      • 由于ShellRunner运行在一个独立进程,它的生命周期和备份软件是不一样的。备份软件被卸载掉了ShellRunner还是在运行。
      • 图5中存在一个环,当N7处发生异常时,ShellRunner会在N8处重启ShellProxyService服务。
    • 攻击1:攻击者可以利用漏洞1获取到token。
      • 首先安装一个恶意应用AuthSniffer检测Helium是否被卸载。
      • 当用户卸载了Helium,AuthSniffer立即通知攻击者,攻击者诱使用户安装里一个恶意应用mHelium,有相同组件ShellProxyService。
      • mHelium安装后,AuthSniffer给ShellRunner发送一个随机密码,导致handlesocket出现异常。
      • ShellRunner重启ShellProxyService服务,把token发送给mHelium。 Fig
    • 漏洞2:任意命令执行。
      • ShellRunner没有封装backup/restore命令,它会直接执行接收到的字符串,它能执行任何ADB代理能执行的字符串。
    • 漏洞3:未保护的Web接口。
      • 备份用的web接口没有访问控制,恶意应用也可以调用它。
      • 这个web server被实现为一个服务,Helium没有在前台运行它也能运行。
    • 攻击2:攻击者可以获取目标app的备份数据。
    • 漏洞4:未保护的数据存储。
      • Helium禁用了对备份数据的加密。
      • 它将备份数据存在SD上没有任何保护措施。
  • 攻击3:备份数据存在/sdcard/carbon文件夹中,可直接被AuthSniffer读取。
  • Poaching攻击只影响那些把数据保存在app自己所有的文件夹中的应用,委托给Account Manager管理的不被攻击。另外,app自身可以拒绝加入备份过程,在manifest里把android:allowBackup设为false。

Measurement and Case studies

  • 实验数据包含两个数据集:(1)top 100的应用。(2)随机选取的10个类别中各自top10的应用。
  • 判断一个app是否受Poaching attack影响:
    • 流量分析识别出认证符。
    • 对目标app进行Poaching attack获取备份数据。
    • 在另一台设备中把备份数据恢复给另一个干净的目标app,看认证会话是否依然合法,合法则该app受poaching attack影响。

Fig

  • 案例1:攻击Facebook app。
    • 流量分析识别认证符。access_token、c_user、xs。
    • 从Facebook app备份数据中提取这3个认证符。它们存在名为prefs_db的Sqlite数据库中,作者在AuthSniffer中嵌入一个Sqlite数据库管理器来提取认证符文本。
  • 案例2:攻击Facebook SSO SDK。只讨论WebView的情况。
    • 流量分析:登录时server返回c_user、xs用以交换得到access token。
    • web cookie被WebView管理,从WebView的文件夹下提取到这些认证符。
  • 案例3:攻击一个使用了Facebook SSO SDK的游戏应用 Candy Crush Saga。
    • 流量分析识别到access_token。
    • token存在shared_prefs里,AuthSniffer可以直接获取到它们。