report from Google I

Hello, my name is Anya and I am an Android developer in KTS. In this article, we will look at what updates to ensure user security were presented in the report Safeguarding user security on Android at Google I/O, and how they will affect development. More about Google I/O wrote here.

A little introduction to 2023:

– more than 2 million applications that violate the rules are not allowed to be published;

– approximately 330 thousand bad accounts were banned;

– about 200 billion applications were scanned every day for malware;

– More than $10 million paid out as rewards for security bugs.

And that is not all. Thanks to Google Play Protect, more than 500 thousand malicious applications have been detected and more than 3 million warnings have been issued.

Google Play Protect may offer to scan apps during installation if they haven't been scanned before. This helps Google track security threats much faster.

Table of contents

New user protection

Android helps users manage their data in many ways: Runtime Permission Control for requesting permissions while an app is running, and Privacy Dashboard, which is available with Android 12 and allows you to see all granted permissions. This year, new features will be added to them to protect data in case of device theft or during screen sharing, as well as several other features.

UX improvements during screen sharing

When users share their screen, they may unintentionally reveal more information than they intended. Attackers can also convince users to share their screen with them in situations where they don't really need to do so – and thus use the demonstration to steal information.

To help prevent such situations, Google will limit your screen sharing area to a single app by default. But the ability to share the entire screen will remain.

With the option to view one application selected, status bars, navigation bars and other UI elements of the system will be excluded from screen sharing. Only the content of the selected application will be shown. Read more about changes to the UI read here.

The changes will also affect the display of notifications. To avoid revealing sensitive information, such as one-time passwords, notification content will be hidden. To display notification content even while screen sharing, you must provide public notification content. If the public version of the content is not provided, the private version without the content will be displayed.

During screen sharing, the platform will detect and hide notifications with one-time passwords. In the screenshot below, the user received a notification with a one-time password and clicked on it. The chat screen opens. However, during screen sharing, the viewer will only see a blank screen.

Attackers can snoop on one-time passwords using applications that have been granted access to use the Notification Listener Service. Starting with Android 15, such apps will receive notifications with the OTP content removed.

Wearable devices connected through Companion Device Manager and other apps that rely on notification content will continue to receive full notification content.

Protecting users during device theft

Google requires authentication when someone tries to change specific privacy settings. And it will block thieves when they fail to log into an application or service several times using a pin or biometrics.

The moment a thief tries to steal your phone, a new detection function is activated. It detects movement when stolen and locks the screen to protect user data.

Often, for users, device theft is a shocking situation. And they don't always remember how to protect data after it's stolen. So Google will add a remote blocking feature. Thanks to it, users will have an easy way to remotely lock their device. Even if they don’t remember their Google account password.

Private Space feature

Private Space is a separate space on the device for applications. You can install in it those applications that you want no one to know about. Or applications that you don't want other people to have access to. This space can be extended to any application. It can be blocked and hidden from view.

This option can be useful for protecting confidential applications in case of device theft, accidental exposure, or surveillance.

Reducing access to photos and videos

Last year they announced a policy related to photo and video permissions. Currently, apps must demonstrate that they are requesting broad access to photos and videos for their primary use case. This policy will begin to be actively implemented in August.

If your application needs photo or video permissions for a custom picker, then Google recommends using the system one Photo picker. For example, when you ask the user to select a profile photo.

The report named Android Photo picker as the best solution for almost every application. It doesn't require any permissions and shows cloud photos and albums from Google Photos. It is easy to add to the application and customize.

Play Integrity API

Play Integrity API will help you check whether user actions and requests to the server come from your unmodified application installed through Google Play and running on a real Android device. The Play Integrity API runs on all versions of the Android SDK and is fully supported on both smartphones, tablets and foldable devices. It can also be used on other Android devices and PCs. Google Play Games.

How it works? You call the Play Integrity Api to obtain an integrity token from Google. Next, you transfer the received token to the backend server of your application. There you can decrypt the token and get a verdict from Play Integrity. And use it to decide whether you trust that the request was made from your genuine application.

If something goes wrong, you can, for example, ask the user to confirm that it is really him. Or deny access to sensitive information. You can read more about how to connect the Play Integrity API link.

Many developers already use the Play Integrity API in production for integrity checks. According to Google, they experience, on average, 80% less unauthorized use compared to unsecured apps.

App access risk

App access risk is a new integrity verdict. With it, you can check whether there is a risk that your application can be controlled by other running applications. For example, when a user wants to transfer money. Before performing this operation, you can check the verdict on the risk of access to the application. And show a dialog from Google Play asking you to close applications that can take control. This verdict is currently available in public beta test.

The verdict contains information about the validity of the device, application, etc. Looks like a regular json file. You can read more details at the docks.

{
   requestDetails: { ... }
   appIntegrity: { ... }
   deviceIntegrity: { ... }
   accountDetails: { ... }
   environmentDetails: { ... }
}

There are several levels of risk for accessing the application:

1. Capturing response – means that applications are running that can capture the screen.

2. Controlling response means that applications are running that can control the device. Such applications can both capture the screen and control input within your application.

App access risk automatically excludes genuine applications that use the Accessibility API and have undergone a special review process.

Play Protect

Play Protect tells your app where it was launched and whether it found known malicious apps on the device. If malware poses a particular threat to your app or users' data, you can check the verdict and ask users to enable Play Protect. Or offer to remove dangerous applications before continuing with the action.

Checking recent app activity

Recent device activity tells you how often your application has called integrity queries in the last hour. With its help, you can track an abnormally high number of requests – this may be a sign of an attack.

First, you need to check the data to find out the typical level of device activity for your application. After this, you can decide what the application will do if the device sends too many integrity requests.

For example, if activity is a little higher than usual, you can set a timeout and ask the user to make a request later. When activity is too high, enforcement measures can be taken.

All three innovations are available in both standard and classic Integrity API queries. Standard API requests were added last year. They are suitable for most applications and games. Using them you can get an integrity verdict with low latency.

Integrity API report

You can analyze Integrity API reports and check them for anomalies in the Play Console.

The Play Integrity API is available to all Android developers. But some selected Google Play partners still have access to automatic integrity protection in the console. This allows you to add security without the need for backend integration and without additional development.

With Auto-Protect enabled, Google Play will automatically add verification to your app. The strongest version of tamper protection will also be installed.

Changes in Android 15

Updating the target SDK version

Android 15 will prevent the installation of applications with a targetSdkVersion lower than 24. But on devices that update to Android 15, all applications with a target SDK lower than 24 will remain installed.

I think it’s not worth describing in more detail why this is required. Google also says that similar changes should be expected in future versions of Android.

Safer Intent update

Incorrect handling of ints can create vulnerabilities. Android 15 will add tools to help developers determine when their apps' intents don't match other apps' intent filters. The key here is to ensure that the explicit intents sent match the intent filters of the target component.

Why is it important? Let's look at a vulnerability pattern that Google encountered in practice.

Inside the com.victim package there is a manifest file where 2 broadcast receivers are defined. InternalReceiver is not exported, i.e. it cannot be launched from another application. ExternalReceiveron the contrary, is exported.

Package: com.victim
AndroidManifest.xml

<receiver
   android:name=".InternalReceiver"
   android:exported="false">
   <intent-filter>
       <action android:name="com.victim.PRIVATE_INTERNAL_ACTION" />
   </intent-filter>
</receiver>

<receiver
   android:name=".ExternalReceiver"
   android:exported="true">

   <intent-filter>
       <action android:name="com.victim.PUBLIC_EXTERNAL_ACTION" />
   </intent-filter>
</receiver>

InternalReceiver processes sensitive information and ExternalReceiver – public. Inside MainActivity let's create an intelligence handler CentralizedIntentFilter.

Package: com.victim
MainActivity.kt

object CentralizedIntentHolder {
   fun handleIntent(context: Context, intent: Intent) {
       when (intent.action) {
           "PRIVATE_INTERNAL_ACTION" -> // does sensitive stuff
           "PRIVATE_EXTERNAL_ACTION" -> // does normal stuff
       }
   }
}

class InternalReceiver: BroadcastReceiver() {
   override fun onReceive(context: Context?, intent: Intent?) {
       CentralizedIntentHolder.handleIntent(context, intent)
   }
}

class ExternalReceiver : BroadcastReceiver() {
   override fun onReceive(context: Context?, intent: Intent?) {
       CentralizedIntentHandler.handleIntent(context, intent)
   }
}

Next, we define two intents. A private action will send data to a private recipient within the application, and a public action will send data to an external handler in another application.

An attacker can simply define the intent's action as internal. And send such an intent to an external component. This change will cause the internal handler to be called. Thus, the attacker will successfully cause the internal action to be processed even though InternalReceiver was not exported.

Package: com.attacker
MainActivity.kt

val intent = Intent("com.victim.PRIVATE_INTERNAL_ACTION")

intent.setClassName("com.victim", "com.victim.ExternalReceiver")

sendBroadcast(intent)

On Android 15, you can track such attacks using Strict Mode. When Strict Mode is enabled, mismatches will be shown as violations in the logcat. Based on the data received, developers should update their intentions.

Strict Mode is optional. In fact, to use it, your app must be targeting Android 15.

To see logs with violations, you need to call the following method:

fun onCreate() {
   StrictMode.setVmPolicy(VmPolicy.Builder()
       .detectUnsafeIntentLaunch()
       .build()
   )
}

Sending intents with action null on Android 15 will no longer match any of the intent filters. This change is caused by the following vulnerability pattern.

<receiver
   android:name=".MyReceiver"
   android:exported="true">
   <intent-filter>
       <action android:name="com.example.MY_ACTION" />
   </intent-filter>
</receiver>

//  Creating an intent with NO actions
val intent = Intent()

intent.setClassName("com.example")

// MyReceiver gets the broadcast
sendBroadcast(intent)

Broadcast receiver MyReceiver exported – action is not defined in it. We create an intent with action null. MyReceiver will receive this intent. Many broadcast receivers in real applications do not expect the intent action to be null. And when receiving such intents they fall with Null Pointer Exception.

In Android 15 in class IntentFilter The match method will be updated. So the system converts the nullable action intent into NO_MATCH_ACTION. This will be available as part of Strict Mode.

As for PendingIntents, they also need to be handled carefully. As part of the update to more secure intents, the creator of a PendingIntent will be treated as the sender of the included intent rather than the pending intent.

Launch background activity

Launching unwanted malicious background activity is among the most common problems that security researchers have found.

Google has updated its documentation to include best practices. They will help developers mitigate the risks associated with running background activities.

Let's look at some vulnerable patterns with background activity launching:

1. To display pop-up windows, such as advertisements, the background application runs on top of the active foreground application. And limits user interaction with the device.

2. Another type of vulnerability is tapjacking (analogous to clickjacking from the web). A background application can partially or completely overlap the active application. The attacker tricks the user into clicking on the element. But because of the overlap, the action will happen on something else.

3. Screen phishing is when a background application can show a dialog or full-screen activity after the active application's dialog or activity is closed. This allows background application impersonate a recently used foreground application.

To improve the security of running background activities on Android 15, the creators of PendingIntent will block background activities from running by default. This is done because the system does not prohibit background activities from running. And Google has encountered cases where an application bypassed the launch of background activity by sending system-creator PendingIntent.

Google is also going to update the moment when an activity starts in the background. The task stack will not move to the foreground until the creator or sender of the PendingIntent is allowed to run a background activity.

This is done this way because malicious applications can now receive and run PendingIntents. Because of this, system activity is transferred to the tag stack of the malicious application. What can lead to sudden termination of system activity.

An activity that matches the Top UID can launch new activities, create processes, and move them to the foreground. When a malicious application is in the foreground, it can run the activity of the victim application on top of itself. And then pretend that it is one of the activities of the victim’s application and was launched by it. To prevent such situations, the behavior for the activity matching the Top UID will be updated.

One last thing: how the activity terminates will be updated. If the activity is in the foreground, then the user can return to any last used activity. And if the activity was not at the top, then the user will return to the home screen. This will prevent the user from interacting with the victim application that was launched by the malicious application.

Conclusion

The report examined new opportunities for protecting user data. As well as security-related changes in Android 15.

Let's go over some of the best practices to ensure user safety:

1. Developers should continue to use flag_secure to protect activities with sensitive content.

2. Whenever possible, use the latest SDK as target. This way you can apply the latest security improvements automatically.

3. Check all the functionality offered by the Play Integrity API.

4. Make sure that intents are sent to the correct component and that your application keeps the latest updates running in the background.

I wonder how the detection of device theft will be implemented and whether there will be false positives for simply pulling a smartphone out of your pocket?

More about mobile development: